Technik

Da es “Virtual” heißt, kann man schon erraten, dass es sich nicht um eine normale Konferenz handelt. Vielmehr wurde alles über das Netz gestreamt und somit konnte man weltweit aus dem trauten Heim der Veranstaltung folgen. Als Basis diente die Vuze Meeting Seite. Über einen Link gelangte man in den entsprechenden Raum und über eine Skype Verbindung zu Vuze Meeting wurde die Tonspur bereitgestellt. Somit wurde eine bewährte Technik für den Audio-Stream genutzt, was ich recht schick finde. Es bestand auch die Möglichkeit den Stream über die Webseite zu beziehen aber laut den anderen Teilnehmern war die Skype-Lösung tendenziell besser. Die Einwahl per telefon wäre auch möglich gewesen, aber von Deutschland her wenig sinnvoll. Support wurde über einen IRC-Channel im freenode-Netz geleistet. Hierüber konnte man auch Fragen an die Referenten weitergeben.

Speaker

Es gab 4 Referenten, die jeweils ca. eine Stunde Sprechzeit hatten. Genutzt wurde zumeist für den Vortrag zwischen 45 und 50 Minuten. Danach gab es noch die Möglichkeit Fragen zu stellen.

David Collier – “Basics of Git”

Der Vortrag von David war eine sehr gute Einführung zu den Grundlagen von Git. Vergleiche zu Subversion wurden gezogen und die Befehle vorgestellt, die einen Entwickler bei der täglichen Arbeit begleiten. Auf der Tonspur gab es sehr viele Informationen zu den recht übersichtlichen Folien. Leider gab es beim Screensharing ein paar technische Probleme und so musste eine Alternative gefunden werden. Diese war recht suboptimal und hat die Live-Vorführung etwas überflüssig gemacht. Der Bildaufbau war einfach zu langsam, oder David zu schnell. Aber die Grundlagen kann man natürlich auch leicht selbst ausprobieren.
Folien: http://speakerdeck.com/u/davidcoallier/p/git-basics

John Mertic – “Subversion to Git: A Sugar Story”

Hier ging es schon ein bisschen weiter und John hat einige Anekdoten aus seiner Entwickler-Zeit erzählt. Wie man von Subversion zu Git migriert und welche Herausforderungen dadurch an ein Entwicklerteam gestellt werden. Insgesamt sehr spannend und unterhaltsam. Leider gab es einige Aussetzer im Audio Stream.
Folien: http://www.slideshare.net/jmertic/the-virtual-git-summit-subversion-to-git-a-sugar-story

Chris Hartjes – “You’ve Decided to Use Git as Your VCS for Your Team…So Now What?”

Chris Vortrag ging noch einen Schritt weiter und das Thema war im Großen, wie man mit Git Branches organisiert. Dabei ging es um Feature-, Bugfix-, Staging-Branches und den Master. Er hat somit aus dem Leben eines Entwicklers berichtet der nach diesem Muster branched. Diesmal gab es keine technischen Schwierigkeiten und der Vortrag war ebenfalls sehr gut und auch recht locker gehalten.
Folien: http://speakerdeck.com/u/grumpycanuck/p/youve-decided-to-use-git-as-your-vcs-for-your-teamso-now-what

Travis Swicegood – “Git’s Meat Cleavers”

Travis hat schon auf einer höheren Ebene begonnen und hat mich als Git Laien nach ca. 15-20 Minuten vollkommen abgehängt. Es ging um die Themen Rebase und Bisect. Wer mit Git arbeitet wird in den Folien sicher wertvolle Informationen finden, ich werde diese wohl erst zu einem späteren Zeitpunkt zu schätzen wissen. Der Vortrag an sich war sehr strukturiert und nach jedem Abschnitt gab es die Möglichkeit für das Publikum Fragen zu stellen. Die Technik spielte auch diesmal mit und somit war der Vortrag ein gelungener Abschluß.
Folien: http://speakerdeck.com/u/tswicegood/p/gits-meat-cleavers

Fazit

Das “Virtual Git Summit” hat wirklich Spaß gemacht und einen guten Motivations-Schub gegeben, sich mehr mit Git zu beschäftigen. Interessant war die Tatsache, dass die ersten 3 Referenten Github sehr gelobt haben und im Chat auch eine ähnliche Meinung vorherrschte. Nicht nur wegen der Opensource-Projekte, sondern vor allem im Firmenumfeld als Ersatz für ein Inhouse-Repository. Wenn Zeit und Themen passen, werde ich sicher bei weiteren virtuellen Summits dabei sein.

Was ist der QR-Code eigentlich?

Der Begriff QR-Code steht für Quick Response Code und es handelt sich um einen 2-dimensionalen Code, der von Denso Wave im Jahre 1994 entwickelt wurde. Die Größe ist abhängig von der Datenmenge und von der Güte der Fehlerkorrektur. Die kleineren Quadrate werden von der Erkennungssoftware zur Bestimmung der Ausrichtung genutzt. Im Code selbst werden Daten transportiert. Smartphones haben die Software zur Erkennung schon installiert oder aber sie lässt sich im jeweiligen AppStore/Market finden. Ich persönlich nutze Google Goggles unter Android.

Welche Daten werden hinterlegt

QR-Codes findet man inzwischen an vielen Stellen, an denen man eine Brücke zwischen einem Offline- und einem Online-Medium schlagen möchte oder muss. Werbung in Zeitschriften bspw. verweist auf die entsprechende Internetseite des Herstellers. Es können aber auch Telefonnummern, vCards oder speziellere Daten hinterlegt werden. Wlan-Zugangsdaten werden u.a. gerne in einem QR-Code für die Gäste eines Cafes hinterlegt.
Die Erkennungssoftware ist normalerweise so programmiert, dass sie bestimmte Muster in den Daten erkennt und davon abhängig eine entsprechende Software startet. Solche Muster sehen bspw so aus:

Webseiten

• http://www.phpmonkeys.de
• market://details?id=com.google.android.apps.unveil

Email

• mailto:user@example.com
• mailto:user@example.com?subject=Readme

Telefon

• tel:012345678

Kontaktdaten (vCard)

• siehe vCard Spec
• Kurzübersicht (Wikipedia)

QR-Codes generieren im Netz

Wie so ein Code aussieht ist rudimentär klar und welche Daten darin enthalten sein können haben wir auch gesehen. Jetzt geht es an die Generierung. Der einfachste Weg ist eine entsprechende Seite zu nutzen. Dies bietet sich vor allem dann an, wenn man nicht viele Codes benötigt oder wenn man die Generierung auslagern möchte.

Kaywa

Ein besonders einfaches Formular zum Erstellen solches Codes findet man bei Kaywa. Dies ist auch der Hersteller von entsprechender Software, die die Codes analysieren kann. Dort kann man ein paar Informationen angeben und schon wird ein QR-Code generiert. Einen statischen Link dazu gibt es auch. Besonders nett an dem Formular ist die Auswahl nach den verschiedenen Möglichkeit. Vorlagen für URL, Telefon und SMS sind bereits vorhanden und ein generelles Text-Eingabefeld gibt es auch noch. Leider gibt es aber einige Limitierungen und das Formular ist auch nur für die private Nutzung erlaubt. Für die ersten Tests reicht dies aber allemal aus.
Link: http://qrcode.kaywa.com/

Google Chart API

Möchte man QR-Codes dynamisch erzeugen so bietet Google eine entsprechende API an. Über den Generator für Charts kann man neben schönen Diagrammen auch die QR-Codes generieren. Hierbei muss man im Gegensatz zu kaywa aber wissen, welchen textlichen Inhalt man im Code unterbringen muss. Wie sieht ein Telefonnummer-QR-Code aus? Und dann ist die Google API ein gutes Stück interessanter.
Der Aufruf ist sehr überschaubar:

https://chart.googleapis.com/chart?chs=150x150&cht=qr&chl=Hello%20world

Die Parameter ergeben sich folgendermaßen:

• chs: Die Größe des Codes im Format BreitexHöhe
• cht: Hier steht qr, weil das eben der Typ ist
• chl: Der Inhalt des QR-Codes in einem URL-Encoded Format

Netterweise kann man statt der GET-Syntax auch die Daten per POST übermitteln. Hierbei wird dann natürlich ein Formular oder eine Zwischenschicht benötigt, die die Daten per POST übermitteln kann. Zum Beispiel mit cURL auf der Kommandozeile oder natürlich mit PHP, wie man das Übermitteln von POST-Daten ja kennt.
Dadurch ist man auch in der Lage komplexere Daten in einem QR-Code unterzubringen und die Menge der Daten erhöht sich ebenfalls. Denn üblicherweise ist eine GET-Anfrage auf ca 2k beschränkt, POST hingegen kann 16k übermitteln. Unter dem angegebenen Link finden sich einige Beispiele für die Benutzung.
Link: http://code.google.com/intl/de-DE/apis/chart/infographics/

PHP QR Code Library

Die vorgestellten Methoden benutzen beiden den Service eines Dritten. Wer nun seine Codes selbst erstellen möchte, muss auf eine entsprechende Bibliothek zurückgreifen. Als Beispiel dient hier PHPQRCode. Um einen QR-Code zu generieren muss man nur qrlib inkludieren. Die Generierung geschieht dann über den Aufruf einer statischen Methode. Hierbei sind einige Parameter verfügbar. Beispielhaft sieht dies so aus:

require 'qrlib.php';
QRcode::png('http://www.phpmonkeys.de', 'code.png', QR_ECLEVEL_H, 10);

Die Daten werden als erster Parameter übergeben, dann folgt der Dateiname, die Fehlerkorrektur und die Größe. Fehlerkorrektur und Größe sind optional.

Fazit

Das eigentliche Geheimnis der QR-Codes liegt in den Daten und in der Formatierung dieser. Wenn eine Software ein spezielles Format unterstützt, so kann man viele Eingaben vereinfachen.
Eine kommende Alternative könnten die NFC-Tags sein. Diese Aufkleber lassen sich ebenso mit Daten befüllen. Jedoch sind QR-Codes sehr viel einfacher und günstiger herzustellen und können von jedem Gerät mit Kamera gelesen und ausgewertet werden.

Ergänzend für nk hier noch 4 Testdateien. Diese haben 1k bis 4k an Daten als Inhalt. Wobei als letztes Zeichen ein A angegeben ist und alle Zeichen zuvor eine 1 sind. Dadurch kann man einfach sicherstellen, dass alle Zeichen im QRCode vorhanden sind.

• QR Code 1k
• QR Code 2k
• QR Code 3k
• QR Code 4k

Für unser Daily Scrum arbeiten wir mit einer herkömmlichen Scrumwall. Dort befinden sich dann auch die Karten aus Papier. Diese werden entsprechend des Zustandes verschoben und sind mit einer kurzen Beschreibung versehen und mit einer Referenz auf unseren Bugtracker.

Durch den Bugtracker haben wie die Möglichkeit Arbeitszeiten, zusätzliche Informationen, fachliche und technische Anmerkungen an der jeweiligen Aufgabe anzuhängen. Diese Aufgaben werden natürlich nicht als Bug erfasst, sondern haben einen eigenen Typ. Als Tool wird Jira benutzt. Wir nutzen die Greenhopper Erweiterung nicht, sondern haben für die Aufgaben eigentlich in der digitalen Fassung nur 3 Zustände.

1. Aufgabe liegt beim Product Owner und ist noch nicht bereit für die Entwicklung
2. Aufgabe wird von einem Entwickler bearbeitet und ist diesem zugeordnet
3. Aufgabe liegt beim PO ist aber als geschlossen markiert, d.h. die Aufgabe ist erledigt

Ein großer Vorteil des Vorgehens ist für uns, dass man über die Jira-Referenznummern die Aufgaben schneller findet und so auch in weiteren Dokumenten verlinken kann.
Mitarbeiter die nicht vor Ort arbeiten können so auch alle Informationen ihrer Aufgaben im Blick haben und der Verwaltungsoverhead wird möglichst gering gehalten.

Nun kommen wir aber zurück zur eingangs gestellten Frage. Wie sieht das bei euch aus? Benutzt ihr eine spezielle Software und wenn ja, welche? Benutzt ihr nur Papier und Whiteboard?

Was ist REST?

REST steht für REpresentational State Transfer und wurde von Thomas Roy Fielding in seiner Dissertation benannt. REST benutzt URLs um Ressourcen bereitzustellen und das Hypertext Transfer Protocol um Manipulationen an diesen Ressourcen durchzuführen. Die einzelnen HTTP-Methoden werden für verschiedene Operationen genutzt dabei entspricht GET Lesen, PUT Update, POST Create und DELETE Löschen.

REST-Service in PHP – das Slim-Framework

Möchte man einen solchen REST-Service erstellen bietet sich das Slim-Framework an. Die Sourcen können bei Github gefunden werden. Der Aufbau eines Hello-World-Services ist denkbar einfach.

require 'Slim/Slim.php';
$app = new Slim();
$app->get('/hello/:name', function ($name) {
   echo "Hello $name";
});
$app->run();

Die interessante Zeile ist $app->get(). Hier wird ein Pfad und ein Parameter mit einer Funktion verknüpft. Das ganze verwendet die GET-Methode von HTTP.

Wenn man einen umfangreicheren Service anbieten will, werden weitere Methoden verwendet wie zum Beispiel PUT, DELETE, POST.

Als Beispiel sei ein Service für die Verwaltung einer Person zu nennen der so aussehen könnte:

require 'Slim/Slim.php';
$app = new Slim();
$app->get('/person/:id', function ($id) {
   // retrieve person
});
$app->post('/person', function () {
   // create person
});
$app->put('/person/:id', function ($id) {
   // update data
});
$app->delete('/person/:id', function ($id) {
   // delete data
});
$app->run();

Das Framework bietet neben der REST-Funktionalität auch noch eine Logging Komponente und alles ist mit Unittest abgedeckt.

Testen mit Chrome und FF

Um den REST-Service zu nutzen benötigt man normal einen REST-Client. Für Tests ist es natürlich überaus praktisch, wenn man die einzelnen Funktionen manuell triggern kann.

Hierfür gibt es eine Chrome Erweiterung, die den Entwickler die Methode, Header Information und Daten (bspw POST) setzen lässt.

Eine Firefox Extension gibt es auch, die ich aber bisher nicht getestet habe.

Webservice Tipp

Beim Entwerfen eines REST-Webservices sollte man gleich die Versionierung der API bedenken. So sollten Ressourcen dann bspw. über URLS wie /v1/person/1234 bereitgestellt werden.

Ich wünsche euch allen ein Frohes Fest und ein schönes, erfolgreiches und gutes neues Jahr 2012.

             *
            /.\
           /..'\
           /'.'\
          /.''.'\
          /.'.'.\
   "'""""/'.''.'.\""'"'"
     jgs ^^^[_]^^^

Ein Interface sieht bspw so aus:

import com.google.gwt.i18n.client.Constants;
public interface I18nMainPageConstants extends Constants {
    @DefaultStringValue("Alle")
    public String all();
    @DefaultStringValue("Einstellungen")
    public String settings();
}

Nun ist es aber so, dass man als Entwickler beim programmieren der Anwendung Konstanten über den Code hinzufügt. D.h. man ruft eine nicht existente Methode eines i18n-Interfaces auf und wird (hoffentlich) von der IDE darauf hingewiesen, dass die Methode nicht existiert. Diese kann man sich dann automatisch anlegen lassen und muss nur noch den Defaultwert definieren. Also wächst das Interface. Wenn man nun weitere Sprachen nutzen möchte, benötigt man eine properties-Datei. Zum einen, weil man neben der Defaultsprache auch andere anbieten möchte und weil diese Key-Value-Dateien gut an ein Übersetzungsbüro gegeben werden können.

Die Generierung kann man händig durchführen, oder man nutzt die Boardmittel von GWT. Es wird eine Annotation bereitgestellt, die man an das Interface schreibt und somit angibt, das eine properties-Datei erzeugt werden soll. Somit sieht das Interface so aus:

import com.google.gwt.i18n.client.Constants;
import com.google.gwt.i18n.client.LocalizableResource.Generate;
@Generate(format = "com.google.gwt.i18n.server.PropertyCatalogFactory")
public interface I18nMainPageConstants extends Constants {
    @DefaultStringValue("Alle")
    public String all();
    @DefaultStringValue("Einstellungen")
    public String settings();
}

Tipp:
Wenn man beim Aufruf des gwtc noch die Option -extra angibt mit einem entsprechenden Verzeichnis, bspw “extras”, dann werden in dieses Verzeichnis die properties Dateien generiert. Dies hilft insbesondere dann, wenn man viele solcher Dateien nutzt.

Normalerweise sind die Vorstellungen eines Kunden eher unstrukturiert und vor allem unvollständig. Wenn man ein Vorgehensmodell nutzt, dass die Vorstellungen systematisch plant und strukturiert, werden Kundenanforderungen gefunden, die bei der Planung berücksichtigt werden müssen.

Die Anforderungen werden in verschiedene Kategorien sortiert.
eindimensional: Features die die Akzeptanz des Benutzers positiv beeinflußen, deren Nicht-Vorhandensein dann aber auch negativ aufgefasst werden. Performance einer Anwendung kann man hier einordnen.
obligatorisch: Wenn das Nicht-Vorhandensein eines Features den Benutzer unzufrieden macht, das Vorhandensein die Zufriedenheit aber nicht beeinflusst, so ist das Feature obligatorisch. Als Beispiel sei hier die Sicherheit erwähnt.
attraktiv: Ein Feature, das auf den Benutzer positiv wirkt, dessen Nicht-Vorhandensein dagegen als neutral oder als wenig negativ angesehen wird. Ein Beispiel ist vielleicht die Möglichkeit eine Anwendung mit einem mobilen Endgerät zu nutzen, obwohl sie nicht augenscheinlich dafür gedacht ist.

Wie man die Features in diese Kategorien einordnet ist dann die spannende Frage. Hierfür wird ein spezieller Fragebogen benutzt, der durch seinen Aufbau die Informationen für die Zuordnung liefert.

In diesem Fragebogen werden alle Features in 2 Varianten abgefragt. Einmal funktional und einmal dysfunktional. Die Antworten sind in 5 Stufen gestaffelt und in beiden Fällen gleich. Beispielsweise fragt man funktional: “Wie würden sie sich fühlen, wenn das Produkt das Feature X hat”, dysfunktional heißt die Frage: “Wie würden sie sich fühlen, wenn das Produkt das Feature X nicht hat”. Die vordefinierten Antworten sind in etwa “Das finde ich sehr gut” (5), “Das ist okay” (4), “mir egal” (3), “damit kann ich leben” (2), “das mag ich nicht” (1).

Die Auswertung des Fragebogen erfolgt über eine spezielle Matrix, die wie folgt aufgebaut ist:

A: Attraktiv
O: Obligatorisch
E: Eindimensional
N: Neutral
F: Fragwürdig
G: Gegenteilig

Beim Auswerten der Antworten entsteht so über die Anzahl der befragten Teilnehmer eine Statistik. Man sieht wie häufig ein Feature X ein A, O, E, N, F und G erhalten hat. Die Einordnung geschieht dann über den Wert, der am häufigsten ausgewählt wurde. Eine solche Liste könnte so aussehen:

Die Anforderungen werden nun sortiert (O > E > A > N) und anhand dieser Informationen priorisiert.

Wenn befragt man, um an diese Daten zu kommen. Hierfür gibt es mehrere Varianten. Einerseits kann man Personen befragen, die einen guten Einblick in die Welt der Benutzer haben. Alternativ kann man auch eine Umfrage unter den Benutzern starten.

Auf jeden Fall loggt man sich oftmals im Webinterface über eine teilweise sichere Verbindung ein. Man weiß nämlich nicht unbedingt, was auf dem Rechner alles läuft. Darum gibt es von Google die 2-Step-Verification. Hierbei werden 2 “Geheimnisse” genutzt, die dem Benutzer auf 2 Wegen mitgeteilt werden. Bzw wird das Passwort um eine zweite Methode ergänzt. Wer OnlineBanking nutzt kennt die Geschichte von den TAN-Listen. Man benötigt neben der Online-PIN (was gleichzusetzen ist mit dem Passwort) ein zweites Geheimnis, das mir auf einem anderen Weg mitgeteilt wurde und am besten auch nur einmalig zu benutzen ist. Beim Onlinebanking gab/gibt es die TAN-Listen die auf Papier dem Kunden vorliegen und inzwischen sind auch die TAN per SMS oder TAN-Generatoren sehr beliebt.

Wenn man nun ein Handy besitzt kann man seinen Google Account so einstellen, dass nach Angabe von Login und Passwort eine 6-stellige Zahl per SMS zugestellt wird, die man dann zum eigentlichen Login angeben muss. Das funktioniert soweit ganz gut, ist aber immer etwas zeitaufwendig, da die SMS unter Umständen etwas Zeit benötigt, bis sie beim Handy ankommt.

Besitzer eines Smartphones haben hier einen Vorteil. Es gibt den Google Authenticator. Dies ist ein Generator für die 6-stelligen Schlüssel. Und da diese auch noch zeitbasiert sind, kann man hier auch gleich sehen, wann der Schlüssel abläuft. Die Einrichtung ist sehr einfach. Man aktiviert die Option in seinem Google Konto und scannt den angezeigten Barcode mit dem Google Authenticator. Somit ist dieser für den Account eingerichtet. Hat man mehrere Accounts, so kann man diese alle im Authenticator hinterlegen.

Das Programm (oder App) gibt es für iOS, Android und Blackberry.

Hat man sein Google Konto umgestellt auf diese Methode so hat man natürlich ein Problem mit Programmen, die damit nicht umgehen können. Zum Beispiel ein Mail-Programm, das über IMAP die Mails verwaltet, einen Jabber Client etc. Hierfür gibt es die “anwendungsspezifischen Kennwörter”. Das sind Kennwörter die man für eine spezielle Anwendung nutzt. Diese werden von Google generiert und sind um die 16 Zeichen lang. Nach der Generierung kann das Kennwort im Google Konto nicht mehr eingesehen werden. Für jedes gibt man einen kurzen Text an, der es beschreibt und man sieht, wann es zuletzt genutzt wurde. Ist man nun der Ansicht, dass ein Gerät kompromitiert wurde, so kann man es deaktivieren und der Zugang der Anwendung ist somit nicht mehr möglich.

Unterstützt die genutzte Zeiterfassung einen mobilen Zugang oder gibt es eine eigene “App“?

Update (26. Oktober 2011):
Da in den Kommentaren viele gute und interessante Links vorhanden sind, habe ich diese einfach mal hier gesammelt:

• Billings
• Billings Pro
• Mite
• Billomat
• Jira mit Tempo Plugin
• mdProjektTimer
• Projektron BCS
• Freckle
• eputime
• activecollab mit Timer
• Siwapp
• Android App Zeiterfassung
• Allnetic Time Tracker
• todoyu