Der wichtige Punkt ist, das man die Parameter einer Methode angeben muss. Man kann entweder einen festen Wert (oder genauer Objekt) angeben, oder einen Matcher nutzen. Matcher erlauben eine gewisse Varianz. Es ist somit möglich zu überprüfen, ob als Parameter eine Klasse des Typs Foo benutzt wurde. Ob das Objekt als valide Eingabe akzeptiert wird, hängt von der Implementierung des Matchers ab.
Nur der Sinn des Tests und die Lesbarkeit sind die Grenze dessen was man machen kann.

Richtig spannend ist der ArgumentCaptor. Dieser erlaubt es dem Entwickler einen allgemeingültigen Matcher für eine Klasse implizit zu definieren und man erhält auch noch Zugang zum eigentlichen Objekt. D.h. wenn ich wie im unten angeführten Beispiel weiß, dass meine UI im Test ein ResizeEvent feuert und ich den genauen Inhalt des Events benötige, ist der ArgumentCaptor genau die richtige Art und Weise, um den Inhalt relativ leicht zu bekommen.

ArgumentCaptor<ResizeEvent> resizeEventCaptor
   = ArgumentCaptor.forClass(ResizeEvent.class);
Mockito.verify(eventBusMock)
   .fireEvent(resizeEventCaptor.capture());
Assert.assertEquals(testPresenter.getMaxW(),
   resizeEventCaptor.getValue().getWidth());

In der ersten Zeile wird programmatisch der Captor erzeugt. Dessen capture Methode geben wir als Matcher an und nutzen verify wie wir es gewohnt sind. Da wir auf static-Imports verzichten ist der Aufruf etwas umständlich Mockito.verify. Danach kann man mit assertEquals den Inhalt des Captor-Werts vergleichen. Da der Captor mit Generics arbeitet kann man sich das Casting sparen.

Als kleine Ergänzung kann man statt des programmatischen Aufrufs auch mit Annotationen arbeiten. Dann gibt man @Captor an und schon wird das Attribut in einen Captor verwandelt. Man sollte hierbei nicht die Verarbeitung der Annotationen vergessen wie man sie von @Mock kennt.

Also benötigt man zuerst eine Identitätsregel, damit die Eingabe-xhtml-Datei zur Ausgabe-xhtml-Datei umkopiert wird. Eine solche Regel sieht bspw so aus:

<xsl:template match="@*|node()">
	<xsl:copy>
		<xsl:apply-templates select="@*" />
		<xsl:apply-templates />
	</xsl:copy>
</xsl:template>

Nun ergänzt man Regeln, die auf bestimmte Elemente oder Elementkonstellationen reagieren. Beispielhaft entfernen wir einfach alle input-Elemente, da wir für diese keine Verwendung haben. Möglich sind natürlich beliebige andere Regeln.

<xsl:template match="input" />

Setzt man dieses Stylesheet auf eine xhtml-Datei an, läuft man in das obige Problem. Da eine xhtml Datei üblicherweise einen Namespace hat, wird das Stylesheet nur die Identitätsregel anwenden können. Wir müssen also noch im Header des Stylesheets Modifikationen vornehmen, wie sie hier beschrieben sind.

Dadurch erhalten wir folgendes Stylesheet und dieses funktioniert dann auch wie gedacht:

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet
	xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"
	xmlns:xhtml="http://www.w3.org/1999/xhtml"
	xmlns="http://www.w3.org/1999/xhtml"
	xmlns:xs="http://www.w3.org/2001/XMLSchema"
	exclude-result-prefixes="xhtml xsl xs" >
	<xsl:output encoding="utf-8" method="xml"/>

	<xsl:template match="xhtml:input" />

	<xsl:template match="@*|node()">
		<xsl:copy>
			<xsl:apply-templates select="@*" />
			<xsl:apply-templates />
		</xsl:copy>
	</xsl:template> 

</xsl:stylesheet>

Besonders zu beachten ist, das man entsprechende Namespace Prefixe in den Regeln verwenden muss. Und wie sooft gilt: Wenn man es weiß, ist es eigentlich ganz einfach.

Aber eins nach dem anderen. Möchte man im Fehlerfall eine angepasste Fehlerseite ausliefern kann man zu dem jeweiligen Fehlercode eine Seite angeben. Dies passiert mit einem Codestück ähnlich diesem:

<error-page>
    <error-code>404</error-code>
    <location>/error404.html</location>
</error-page>

Der Error-Code entspricht dem Statuscode und die Location ist die Seite, die statt der Standard-Fehlerseite ausgeliefert werden soll.

Der Servlet-Filter wird vor und/oder nach dem eigentlichen Servlet, das den entsprechenden Request verarbeitet gesetzt. Es handelt sich dabei einfach um eine Klasse die von Filter abgeleitet werden muss. In der web.xml wird ein solcher Filter in etwa so verankert:

<!-- define the filter -->
<filter>
   <filter-name>MyMightyFilter</filter-name>
   <filter-class>org.example.util.filters.MightyFilter</filter-class>
</filter>

<!-- now map this filter to a URL-pattern -->
<filter-mapping>
   <filter-name>MyMightyFilter</filter-name>
   <url-pattern>/*</url-pattern>
</filter-mapping>

Der Filter behandelt nun alle Urls und kann mit den Request und Response Daten etwas tun. Jetzt ist der Filter aber auch noch auf bestimmte Dispatcher eingeschränkt. Nur wenn ein Request oder Forward ausgeführt wird soll er aktiv werden. Somit sieht das Mapping ein wenig anders aus:

<filter-mapping>
   <filter-name>MyMightyFilter</filter-name>
   <url-pattern>/*</url-pattern>
   <dispatcher>REQUEST</dispatcher>
   <dispatcher>FORWARD</dispatcher>
</filter-mapping>

Nun kommen wir zu dem eigentlich Problem. Der Filter greift in diesem Fall nicht, wenn eine ErrorCode-Seite (wie oben definiert) ausgeliefert werden soll. Wenn bspw. die Verzeichnisse im Request umgeschrieben werden ist die Auswirkung recht eindeutig. Die Fehlerseite kann ihrerseits nicht gefunden werden. Wo liegt nun das Problem?

Die Lösung ist recht einfach. Man muss dem filter Mapping auch noch den ERROR-Dispatcher mitgeben, denn genau der wird betrachtet, wenn eine Fehlerseite ausgeliefert werden soll. Eigentlich ist das logisch und auch sinnvoll, da man so im Fehlerfall einen Filter umgehen kann. Der korrekte Code für das Problem lautet somit:

<filter-mapping>
   <filter-name>MyMightyFilter</filter-name>
   <url-pattern>/*</url-pattern>
   <dispatcher>REQUEST</dispatcher>
   <dispatcher>FORWARD</dispatcher>
   <dispatcher>ERROR</dispatcher>
</filter-mapping>

Struktur

Die Grobstruktur umfasst die Themenbereiche Coaching, Planen, Qualität und Feedback. Die einzelnen Themenbereiche sind in weiter Kapitel unterteilt. Diese haben immer einen sehr ähnlichen Aufbau. Einleitend gibt es eine Beschreibung, welches Thema betrachtet wird. Anschließend wird das Thema weiter vertieft. Sehr spannend ist der wiederkehrende Abschnitt über mögliche Hindernisse. Hier wird man als Coach auf bevorstehende Probleme vorbereitet. Und alle Kapitel werden mit einer Checkliste abgeschlossen, die die wichtigsten Ideen des aktuellen Kapitel noch einmal zusammenfasst.

Die Kapitel umfassen den gesamten agilen Prozess. Neben Themen wie User Stories, Aufbau eines agilen Teams, Daily Standup, Retrospektive kommt auch der Bereich Entwicklung nicht zu kurz: Continuous Integration, Unit Tests, Refactoring und Clean Code sind nur ein paar Beispiele.

Um das Ganze abzurunden gibt es in jedem Kapitel Beispiele aus der Praxis der beiden Autoren und weitere hilfreiche Tipps.

Wem die ganzen Informationen noch zuwenig sind, findet mit den Quellennachweisen weitere Bücher und Links, mit denen sich das Thema agile Softwareentwicklung und der agile Prozess vertiefen lässt.

Fazit

Mir hat das Buch sehr gut gefallen, da neben der durchdachten Struktur das Lesen auch richtig viel Spaß macht. Ich kann das Buch agilen Coaches empfehlen, aber auch die üblichen Mitglieder eines agilen Teams können hier viele nützliche Informationen finden, die die tägliche Arbeit verbessern können.

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 ^^^[_]^^^