Im folgenden möchte ich meine Eindrücke der 4 Tage schildern…
Tag 1

Direkt mit einem komplexen Thema ging es Dienstag früh los: Thread, wie funktionieren sie und was gibt es zu beachten. Wir haben eine ThreadGroup erstellt und zu einem eigenem Thread pool ausgebaut. ThreadGroup ist nun leider nicht die allerschönste Klasse. Heinz verglich sie mit einer Art Kinderzeichnung aus den frühen Java Jahren. besonders einfach zu benutzen fand ich die java.util.concurrent Locks, welchen ich bisher weniger Beachtung schenkte. Endlich sind die Zeiten von synchronized() vorbei. Noch vor dem Mittagessen erläuterte Heinz uns seine Gesetze über Nebenläufigkeit, welche er bereits in verkürzter Form auf unserem meet the experts – performance event präsentierte. Dabei stolperten wir über folgenden code:

private boolean running = true;
public void dojob() {
  while(running) {
    // do something useful
 }
}
public void shutdown() {
  running = false;
}

Führt man diesen auf einer Server VM aus (java -server), so kann es passieren daß der Code sich nicht mehr beendet, da die HotSpot engine den Code optimiert, da running scheinbar immer true ist. Um dies zu vermeiden muss es volatile gemacht werden. Da ich nach Debugging fragte versuchten wir in der Schleife anzuhalten und sieh da, der Debugger zeigte und: running = false. Dies hielt aber den laufenden Code nicht davon ab weiterzulaufen, da der Debugger zwar den korrekten Wert sieht, der laufende Code aber nicht. Doch es wird noch interessanter:

public void doJob() {
  boolean myRunning = running;
  while(running){
    // do something useful
    myRunning = running;
  }
}

Nun zeigt uns der Debugger dies:

running = false; myrunning = true;

trotzdem läuft der code weiter. Jedoch nur so lange bis wir mittels F7 die Zeile ausführen ließen. Diese Art von Problemen kann ein Alptraum werden, deshalb ist es wichtig zu wissen was man korrekterweise tun muss.

Auch wissenswert war es zu erfahren, daß

if (Thread.interrupted()) {
  throw new InterruptedException()
}

der erste Code in jeder Methode sein sollte welche eine InterruptedException deklariert.

Wir haben außerdem den CompletionService kennengelernt, welches nach einem interessanten Interface für die Bearbeitung von asynchronen Aufgaben aussieht. Wer braucht da noch closures?

Tag 2

Wir begannen Tag 2 mit Java new (yet another new?) IO, welches recht viele Features mitbringt, aber irgendwie doch selten verwendet wird. Möglicherweise liegt das an der teilweise sperrigen Benutzung der Interfaces. Man sollte doch vielleicht einfache Beispiele probieren bevor man sich an einem asynchronen nichtblockierendem Server versucht (was man aber durchaus nach Besuch des Kurses kann ).

FileChannel fc = new RandomAccessFile("test.txt", "r").getChannel();
MappedByteBuffer buffer = fc.map(FileChannel.MapMode.READ_ONLY, 0, fc.size());

Die zweite Tageshälfte verbrachten wir in den Untiefen der Java Speicherverwaltung. Natürlich ist die Praxistauglichkeit des Themas reduziert, doch das Verständnis ist essentiell um Probleme zu verstehen und zu lösen. Wir sahen uns caching und pooling an und betrachteten warum dies Objekte leaken oder herumlungern lassen kann. Das Thema erinnerte mich an einen alten post über tag pooling in Servlet Containern. Ich habe nie wirklich verstanden warum Tags gepoolt werden müssen, und wieso Tags keine erkennbaren Lifecyclemethoden besitzen anhand derer man das Pooling erahnen könnte. Als Tools setzten wir jVisualVm und HPjMeter ein, um den Garbage Collector bei seiner Arbeit zu beobachten.

Tag 3

Ich lernte einige interessante Verhaltensweisen von bislang von mir nicht benutzten Collection Klassen, wie zum Beispiel PriorityQueue kennen, sowie einige Besonderheiten von Classloading. Heinz schaffte es java.lang.reflect.Proxies hervorragend zu erklären, so daß die Anwendung in der Übung leicht viel. Genaugenomen ist die beste Erklärung Teil der JavaDoc, doch man muss erst verstehen wie man diese zu lesen hat:

Foo f = (Foo) Proxy.newProxyInstance(
		Foo.class.getClassLoader(), new Class[] { Foo.class },
		new InvocationHandler() {
		  public Object invoke(Object foo, Method method, Object[] arguments) throws Throwable {
		    return method.invoke(foo, arguments);
		  }
		});

Nachmittags diskutierten wir über Exceptions, und ich hatte Gelegenheit mir eine begründete Meinung über die Verwendung von checked vs. unchecked Exceptions zu bilden. Ich werde in Zukunft unchecked Exceptions für Entwickler- bzw. Programmierfehler verwenden. Diese zu fangen ist nicht nötig, die Anwendung mag sogar Abstürzen, aber der Fehler muss behoben werden. Jedoch alle umgebungs-, oder installationsrelevanten Besonderheiten werde ich mit checked Exceptions behandeln. Idealerweise bieten diese brauchbare Informationen damit der fangende Code eine brauchbare Fehlerbehandlung durchführen kann. Eine weitere wichtige Erkenntnis: Einfach Exceptions weiter werfen! Ich weiß gar nicht genau warum ich das bisher kaum tat. Wahrscheinlich wollte ich meine Methodensignaturen einfach sauber halten. Dabei ist weiter werfen oft die beste Alternative. Insbesondere die InterruptedException, welche sowieso nur sinnvoll im Threadcode behandelt werden kann (mit Aufruf von interrupted() und dem Verlassen der Schleife).

Tag 4

Der letzte Kurstag begann mit einer echt harten Nuss. Es galt die Performance einer Methode drastisch zu verbessern. Doch Heinz ließ uns nicht an die Optimierung, bevor wir nicht alle Zahlen in verschiedenen Szenarien hatten. Zuvor galt es sogar noch zu beweisen, daß unser Testcode keinerlei Auswirkungen auf die Performance des zu testenden Codes hatte. Ich fand dies besonders lehrreich, da ich durchaus manchmal vergessen habe das Problem zu beweisen, bevor ich mit der Lösung begann. Als Randnotiz betrachteten wir die verschiedenen Modi der JVM und fanden heraus wie langsam java -Xint ist. Nachdem ich endlich den Code auf 10% seiner Laufzeit kürzen durfte gingen wir über zu den letzten Themen des Kurses. So behandelten wir kurz Datum und Zeit, wobei ich doch lieber jodatime oder icu4j nutze und versuche java.util.Date zu vermeiden. Zuletzt sahen wir uns noch Logging und einige Kniffe zur Optimierung von Loggingausgaben an. Die wichtigste Botschaft bei Logging ist Code Wächter zu verwenden. Zwar war mir die Technik bekannt, der Name dafür jedoch neu:

if (log.isDebugEnabled()){
  log.debug(complexObject.toString() + expensive.toString());
}

Wrap-Up

Ich kann den Kurs bedenkenlos weiterempfehlen. 4 randvoll mit Informationen und Übungen gefüllte Tage sind derartig gestaltet, daß sie auch für erfahrene Entwickler herausfordernd sind. Als Teilnehmer sollte man unbedingt einige Zeit mit Java gearbeitet haben um die Nuancen und Besonderheiten zu erkennen. Anfänger könnten zwar folgen, verpassen aber interessante Aspekte, da das Tempo recht hoch ist. Ferner empfehle ich den Kurs in Deutsch zu besuchen, da Heinz unterhaltsamen Akzent hat

Andrew Hunt und David Thomas haben 2001 mit dem „The Pragmatic Programmer“ bereits ein Standard-Werk über den modernen Anwendungsentwickler geschrieben. Der Fokus liegt dabei aber auf Praktiken, Werkzeugen und Design-Paradigmen die dem Programmierer helfen besseren Code zu entwickeln.

Für agile Projekte reicht es aber aus meiner Sicht nicht aus nur ein „Pragmatic Programmer“ zu sein und in diesem Artikel möchte ich daher den Fokus auf den Entwickler in einem Scrum Team setzen. Ich sage hier explizit nicht „Programmierer“ sondern „Entwickler“, weil der Begriff Programmierer aus meiner Sicht zu sehr auf das codieren beschränkt ist und weniger die Tätigkeiten beschreibt, die zusätzlich notwendig sind, um guten Code zu erzeugen. (beispielsweise Design und Test)

Die Wurzeln von Scrum liegen laut Ken Schwaber (einem der Erfinder von Scrum) vor allem in einem Artikel der im Januar 1986 im Harvard Business Journal erschienen ist: „The New New Product Development Game“. Der Artikel beschäftigt sich damit, welche Kriterien eine erfolgreiche Produktentwicklung ausmachen und leitet daraus eine Kernthese ab:

„Stop playing the relay race – play rugby“.

Was frei Übersetzt bedeutet, dass man nicht mehr sequenziell („Wasserfall“), sondern ganzheitlich Produkte entwickeln soll.

Scrum hat die grundsätzliche Characteristiken für erfolgreiche Produkt Entwicklungen aufgegriffen und integriert. Beispielsweise Selbstorganisation der Teams, überlappende Entwicklungsphasen und unterschwellige Kontrolle. Diese Ansätze wurden um Ideen aus der iterativen, inkrementellen Entwicklung und der „Lean“ Welt erweitert. Die Scrum Alliance bietet heute Schulungen und Zertifizierungen zum Scrum Master und Product Owner an – nur was ist mit dem Entwickler? Liegt der Erfolg eines Projekts nicht vor allem im Team? Was bedeutet eigentlich Selbstorganisation, lauffähige Software alle 2-4 Wochen und überlappende Entwicklungsphasen für den Entwickler in einem Scrum Team?

Grundsätzlich glaube ich, dass die Arbeitsweise des Entwicklers in agilen Projekten im Vergleich zum Wasserfallmodell fundamental anders ist und deshalb auch andere, neue Fähigkeiten verlangt werden.

Beginnen wir mit einem der wichtigsten Dinge innerhalb agiler Projekte: Die Selbstorganisation des Teams – Selbstorganisation bedeutet, dass man als Entwickler nicht mehr von außen gesteuert wird, sondern sich mit den Teammitgliedern über die Zusammenarbeit abstimmt. Es bedeutet aber auch, dass man viel mehr Verantwortung übernimmt, mehr miteinander reden und diskutieren muss, Konflikte löst, sich selber organisiert, Aufwände schätzt und Commitments einhält. Dinge die in klassischen Projekten andere Rollen ausgeführt haben und aus meiner Erfahrung nicht gerade die Kernkompetenzen eines Programmierers sind. Es ist aber für den Erfolg von agilen Projekten fundamental erforderlich, dass sich Teams selber organisieren können – weshalb man auch die Entwickler mit entsprechenden Skills ausstatten sollte. Von vielen Organisationen weiß ich, dass Sozialkompetenztrainings vor allem den Führungskräften vorbehalten sind. Durch die Umkehr von „Command and Control“ müssen aus meiner Sicht vor allem auch die Teammitglieder, also auch die Entwickler geschult werden, im Team zu arbeiten. Dazu gehören beispielsweise Konfliktfähigkeit, Kommunikationsfähigkeit, Kompromissfähigkeit, Kritikfähigkeit, Toleranz und Verantwortung. Teammitglieder müssen die Stärken und Schwächen der Kollegen besser einschätzen zu können, was beispielsweise durch Methoden wie das Team Management System oder DISG erreicht werden kann. Wir haben nach der Einführung von Scrum bei codecentric festgestellt, dass wir neben den technischen und methodischen Skills auch die Sozialkompetenz schulen müssen, wenn wir erfolgreiche, agile Projekte durchführen wollen. Mit Hilfe externer Trainer haben wir ein spezielles Programm für uns ausgearbeitet, um die beschriebenen Fähigkeiten jedes Mitarbeiters nachhaltig zu verbessern.

Neben der Selbstorganisation erfordert aber auch die Überlappung der Entwicklungsphasen ganz neue Denkweisen bei uns Entwicklern. In den klassischen, sequentiellen Vorgehensmodellen wurden die Anforderungen im Detail ausgearbeitet, i.d.R. in ausführlichen Anforderungsdokumenten und detaillierten UML Diagrammen. Als Entwickler hat man diese Spezifikationen dann in lauffähigen Code umgesetzt und „Entwickler-getestet“ – für die eigentliche Qualitätssicherung waren andere Teams verantwortlich. Bei agilen Projekten verschwimmen die Grenzen zwischen Anforderungsmanagement, Analysten, Testern und Programmierern und als Entwickler muss man sich auch mit den „ungeliebten“ Randgebieten rumschlagen. D.h. aus meiner Sicht beispielsweise, dass man nicht nur mit Unit-Test auskommt, sondern in die Testgetriebene Entwicklung auch eher fachliche Integrations- und Akzeptanztests integrieren muss – i.d.R. werden diese dann gemeinsam mit Domänen Experten und erfahrenen Testern erstellt. Gerade wenn diese Tests für spätere Regressions-Phasen automatisiert werden (aus meiner Sicht ein Muss bei iterativ, inkrementeller Entwicklung), muss der Entwickler stärker involviert werden, um die speziellen Herausforderungen bei der Automatisierung, wie beispielsweise Testdaten-Setup, zu entwickeln. Geht man sogar soweit, dass man nicht nur bei Unit-Tests Test-Driven entwickelt, sondern auch bei den Integrations- und Akzeptanztest, sind entsprechendes Wissen um Vorgehen und Werkzeugen essentiell. Seien wir mal ehrlich: Man ist doch schon froh, wenn man Entwickler dazu bekommt TDD für Unit Tests anzuwenden oder überhaupt gute und ausreichende Unit Tests zu schreiben – das müssen wir durch entsprechendes Training/Coaching ändern.

Um diese Akzeptanztests zu erstellen und die wenig detaillierten User Stories umsetzen zu können, muss sich ein Entwickler viel intensiver mit der Fachlogik und den entsprechenden Personen im Team auseinandersetzen. Hierfür sind Kommunikationsfähigkeiten, aber auch entsprechende Praktiken, wie beispielsweise Domain Driven Design notwendig. In vielen Projekten sehe ich leider, dass sich Entwickler weniger mit der Domäne und mehr mit Frameworks wie Spring oder Hibernate beschäftigen; Generatoren, die aus Datenbankmodellen ein Objektmodell generieren sind eine nette technische Spielerei, hilfreich bei der Strukturierung und Kommunikation der Domäne sind sie allerdings  nicht. Das objekt-relationale Mapping wird dann zu einer relationalen Objektgenerierung und oftmals zu einer Wartbarkeits-Falle. Auch das ist aus meiner Sicht auf die zu starke Technologiefokussierung zurückzuführen, die man dann auch in der Struktur der Komponenten wiederfindet, die eher auf Basis von Maven-Vorgaben oder Technologie-Layern geschnitten werden, als auf Basis fachlicher Zusammenhänge und Service-Grenzen. Hier ist es meiner Meinung nach unbedingt notwendig Entwickler dahingehend zu schulen und zu coachen, dass Sie die Domaine als Kommunikationsinstrument mit den Fachabteilungen nutzen – so entstehen ganz „natürlich“ fachlich sinnvolle Strukturen und Domainen.

Um alle 2-4 Wochen fertige Software auszuliefern, darf man als Entwickler aber auch nicht die Technologien, Werkzeuge und agilen Entwicklungspraktiken vernachlässigen. Continuous Integration (z.B. Hudson, CruiseControl), automatisierte Build-Werkzeuge (z.B. Maven, Ant), Code Qualität Werkzeuge (z.B. Findbugs, PMD, Checkstyle), automatisierte Testwerkzeuge (z.B. JUnit, Robotframework, easyMock, DBUnit, JMeter), Codeverwaltung (z.B. git, Subversion), Bugtracker (z.B. Jira, Trac), Dokumentationswerkzeuge (Wiki, UML-Toos, Javadoc, etc.) sind dabei nur ein Auszug aus dem Portfolio eines modernen, agilen Entwicklers. Um dieses Portfolio optimal nutzen zu können und in eine „Definition of Done“ zu gießen, müssen die Teammitglieder auch im Umgang mit diesen Werkzeugen und Praktiken geschult werden. Dave Thomas, Co-Autor des „Pragmatischen Programmierers“, spricht sogar von „Code Katas“: Er zieht damit eine Parallele zum Karate, wo Katas bestimmte Trainingseinheiten sind, die immer und immer wieder wiederholt werden, um sie zu perfektionieren. Als Organisation müssen wir den Entwicklern also nicht nur entsprechendes Basis-Training geben, sondern auch Freiräume, um zu üben.

Neben ScrumMaster und Product Ownern müssen natürlich auch die Teammitglieder in Scrum geschult werden, denn die meisten Dinge in Scrum betreffen das Team und dieses muss über das Verständnis den Nutzen erkennen können. Beispielsweise, dass das Daily Scrum nicht für den Scrum Master gehalten wird (dieser muss ja nicht einmal mit anwesend sein, sondern nur dafür sorgen, dass es stattfindet), sondern um sich im Team auf den neusten Stand zu bringen und ggf. Probleme transparent zu machen. (Oft sieht man, dass der Scrum Master reihum die drei Fragen stellt und sich Antworten abholt…ein großes Missverständnis des Daily Scrums!) Oder dass das Burndown-Diagramm nicht zur Kontrolle des Teams durch Scrum Master oder Product Owner (oder sogar den Chef) gedacht ist, sondern als Hilfsmittel für das Team, die eigenen Commitments besser einhalten und überwachen zu können.

Am Ende bleibt noch festzustellen, dass insbesondere die Organisationen umdenken müssen. Das Spektrum des Agilen Entwicklers ist deutlich größer als die Summe der Technologien und erfordert viel Training und Übung – zudem einen hohen Erfahrungsaustausch im Team und innerhalb der Organisation, was schon bei „The New New Product Development Game“ festgestellt wurde: „Multilearning“ und „Organizational Transfer of Learning“ sind zwei der sechs wichtigen Erfolgsfaktoren in der Produktenwicklung! Agile Organisationen müssen also lernen, dass Training kein „Incentive“ ist, sondern ein absolutes Muss für alle Team Mitglieder eines agilen Projekts. Dazu gehören neben den Technologien und Werkzeugen auch Schulungen und Coachings um die Sozialkompetenz im Team nachhaltig zu stärken und agile Methoden, Praktiken und Paradigmen zu verstehen. Damit sich das aufgebaute Wissen der Entwickler auch außerhalb des Teams positiv wirken kann, müssen zudem Foren geschaffen werden, so dass sich die Entwickler im Unternehmen regelmäßig treffen und austauschen können. Diese Investition in die eigenen Mitarbeiter wird sich sehr schnell auszahlen!

Die Planung für dieses Jahr sind schon fast abgeschlossen und ich kann versprechen, dass wir wieder absolute Top Speaker verpflichten konnten – beispielsweise Dana Bredemeyer von Bredemeyer Consulting zum Thema Architekur und Elisabeth Hendrickson von Quality Tree zum Thema Agiles Testen. Details werden in diesem Monat bekannt gegeben und dann kann der “run” auf die 100 Plätze je Workshop beginnen.

Wer letztes Jahr nicht dabei war, kann sich die Speaker und Ihre Vorträge auch in der Meet The Experts Mediathek runterladen. Beim Workshop zum Thema Agilität haben wir die Vorträge mit der Videokamera mitgeschnitten und mit Adobe Presenter so bearbeitet, dass Video und Präsentation synchronisiert sind – so kann man sich einen guten Eindruck von der Qualität der Vorträge und Speaker machen:

• Hennig Wolf mit dem Thema “Agile Methoden im Überlick“
• Boris Gloger mit dem Thema “going LARGE by staying small“
• Simon Roberts mit dem Thema “Making Scrum Stick“
• Andreas Ebbert-Karroum mit dem Thema “Scrum Best Practices“

Über Feedback zu den Videos würde ich mich sehr freuen – es steckt viel Arbeit darin und mich würde interessieren, ob die Aufbereitung mit Adobe Presenter einen Mehrwert liefert. Wir überlegen in Zukunft alle Präsentationen in der Form zu veröffentichen.

1. Maven

Statt das Startskript manuell zu pflegen, kann jybot direkt aus Maven gestartet werden. Die Beispiel pom.xml weiter unten zeigt die Details:

• Mit dem maven-dependency-plugin werden alle libraries in ein Verzeichnis kopiert, welches nachher in den Classpath eingebunden wird. So können auch Bibliotheken von Drittanbietern bequem genutzt werden.
• Das exec-maven-plugin ruft in dem Phase integration-test ‘jybot’ auf. Dies erfordert natürlich, dass jybot auch im PATH der jeweiligen Umgebung eingebunden ist. Auf ein explizites .sh oder .bat kann hier zum Glück verzichtet werden.
• Der Classpath wird auf
  

  ${project.build.directory}${file.separator}classes${path.separator}
  ${project.build.directory}${file.separator}dependency${file.separator}*

  gesetzt. Das heißt er beinhaltet

  1. Die kompilierten Klassen der eigenen Java Keywords
  2. Alle jar-Dateien der in der pom.xml angegebenen dependencies. (Die Wildcard-Notation funktioniert nur mit Java 6!)
• Dann wird das jybot-Skript entsprechend parametrisiert:
  • -C off stellt die farbige Ausgabe ab
  • –variable … übergibt einige Variablen. Diese werden im properties-Element der pom.xml auf entwicklerfreundliche Defaultwerte gesetzt. Ist die Umgebungsvariable “env” auf “ci” gesetzt, d.h. läuft der Maven Build im Kontext des CI-Servers, wird das entsprechende Profil aktiviert, welches die Variablen auf die für das Testsystem relevanten Werte setzt.
  • –variable RESOURCES:${project.basedir}/src/main/robot/resource Dadurch können Resources in den Testfällen einfach mit ${RESOURCES}/keyword-file.txt referenziert werden.
  • –exclude inprogress Dies schließt alle Testfälle aus, die momentan in Bearbeitung sind. Dadurch kann ein Entwickler Zwischenstände commiten, ohne dass der CI-Server diese Tests schon ausführt. Sobald ein Test funktioniert, muss das Tag natürlich entfernt werden.
  • –include author-* Alle Tests sollten meiner Meinung nach mit einem author versehen werden. Dieses include schließt somit alle tests ein, bietet aber dem Entwickler die Möglichkeit die Tests auf wenige einzuschränken, an denen er aktuell arbeitet. Dies ließe sich auch durch Maven Properties und Profiles weiter vereinfachen. Es gibt momentan noch einen Bug in Jython, der jeden Parameter versucht zu passenden Dateinamen zu expandieren (Jython Issue 1567) – es sollte also keine Datei geben, die auf author-* matched.
  • ${ROBOT_TESTS} Dies gibt letztlich an, welche Tests ausgeführt werden sollen. Normalerweise sind das alle Tests in ${project.basedir}/src/main/robot/suite. Durch die Möglichkeit des Tagging und der Verzeichnishierarchie hat man somit zwei unanbhängige Möglichkeiten die Testfälle zu verwalten und zur Ausführung auszuwählen. Das sollte ausreichend Flexibilität bieten.

Langfristig wäre es natürlich schöner, gleich ein Plugin für maven zu schreiben, statt umständlich das Skript zu parametrisieren. Bis es soweit ist, sollte die hier vorgestellte Lösung aber hinreichend sein.

...
 
 
 
        org.apache.maven.plugins
        maven-dependency-plugin
        2.1
 
 
            get dependencies
pre-integration-test
 
              copy-dependencies
 
 
 
 
 
        org.codehaus.mojo
        exec-maven-plugin
        1.1.1
 
 
            robot
integration-test
 
              exec
 
 
 
 
          jybot
 
            ${project.build.directory}${file.separator}classes${path.separator}${project.build.directory}${file.separator}dependency${file.separator}*
 
 
            -C
            off
            --variable
            SYSTEM_UNDER_TEST:${system-under-test}
            --variable
            DB_PORT:${db.port}
            --variable
            RESOURCES:${project.basedir}/src/main/robot/resource
            --outputdir
            ${project.build.directory}/robot
            --output
            ${project.groupId}-${project.artifactId}-${project.version}-output.xml
            --log
            ${project.groupId}-${project.artifactId}-${project.version}-log.html
            --report
            ${project.groupId}-${project.artifactId}-${project.version}-report.html
            --exclude
            inprogress
            --include
            author-*
            ${ROBOT_TESTS}
 
 
 
 
 
 
 
      ci-common
 
 
          env
          ci
 
 
 
        1234
        testservername
 
 
 
 
 
    ${project.basedir}/src/main/robot/suite
    4711
    localhost

2. Struktur des Projektes

Mit der oben angegebenen pom.xml ergibt sich in Eclipse die folgende Projektstruktur – entweder durch das m2eclipse-Plugin oder durch die Verwendung des eclipse:eclipse Goals des maven-eclipse-Plugins.

3. Robot Starten

Die Ausführung der automatisierten Fachtests ist dann nur noch eine Frage des Aufrufs des entsprechenden Maven-Lebenszyklus:

4. Selenium Server

Werden mit Robot auch Browser-Tests durchgeführt, bietet es sich an, den Seleniumserver als “External Tool” in Eclipse zu integrieren:

5. Kompletter Workflow

Anhand des konkreten Beispiels soll in einem kleinen Screencast vermittelt werden, wie in Eclipse die Testfälle entwickelt und gestartet werden. Da man die Details bei dem eingebettetem Video schlecht erkennen kann, habe ich auch eine Fullscreen-Version bereitgestellt.

Gespielt wurde von jedem Spieler jeweils eine Runde der Spiele Agricola, ein anspruchsvolles, komplexes Strategiespiel, Stoneage, ein rundenbasiertes Rohstoffsammelspiel, Dominion, ein spannendes Kartenspiel, bei dem die Spieler selbst anhand der verfügbaren Karten ihre Strategien zusammenstellen, sowie Heckmeck am Bratwurmeck, ein einfaches Würfelspiel, bei dem man hervorragend Wahrscheinlichkeitsrechnung üben kann.

• Der Start in das Turnier lief bei Dominion gut. 2 erste Plätze und ein Zweiter boten eine gute Basis. Lediglich ein Spiel ging, bedingt durch eine Hexe und viele Flüche, verloren.
• Agricola bot über 2 Stunden Spannung und war ein geistig sehr forderndes Spiel. Leider konnten wir uns gegen die sehr guten Gegner nicht durchsetzen. Sowohl Rancher- als auch Farmer-Strategie wurde von uns probiert. Es reichte zu einem 2. Platz, 2 Dritten und einem 4. Platz.
• Nach einer Snackpause gab es dann noch mehr geistige Erholung beim Heckmeck am Bratwurmeck. Glücksspiele sind nicht unser Metier. 3 Vierte Plätze bezeugen das deutlich. Auch der weitere 2. Platz konnte das Ergebnis nicht retten.
• Zuletzt wurde Stoneage gespielt. 1 Erster Platz wurde mit Bauern eingefahren. Die anderen 3 spielten “Verhungern” und wurden mit 2 dritten und einem vierten Platz nicht entlohnt. Den Gesprächen entnahmen wir daß viele unserer Mitspieler schon auf deutlich raffinierten Taktiken setzten.

Trotz des nicht guten Abschneidens war dies ein sehr unterhaltsamer Tag; und Motivation für nächstes Jahr, dann vielleicht doch mit etwas mehr Vorbereitung?

Gestern abend wurde jetzt das Release 1.0 der Datenbank Testbibliothek fertig und es ist super, dass diese bereits auf der Robot Framework Homepage gelistet wird. Wie bei jedem Projekt wird es natürlich erst richtig spannend, wenn die ersten Benutzer anfangen dieses zu nutzen und ich hoffe auf reges Feedback für weitere Features. Mit meinem Kollegen Fabian ist auch ein weiterer Committer zum Projekt gestossen, so dass wir für weitere Entwicklungen und potentielle Bugfixes gut gerüstet sind.

Die Implementierung der Datenbank-Zugriffe basiert auf JDBC, was schon wie ein kleiner Anachronismus anmutet in Zeiten von Hibernate und JPA. Aber für die Testbibliothek ist JDBC genau passend und die Möglichkeit Treiber für verschiedene Datenbanken über deren (Klassen-)Namen einzubinden ermöglicht es problemlos viele verschiedenen Datenbanken zu unterstützen. Dank HyperSql lässt sich die Bibliothek auch perfekt per JUnit testen.

Natürlich gibt es bereits Ideen für weitere Entwicklungen, wobei insbesondere eine Unterstützung für die Robot Framework Remote Library interessant ist, die es ermöglicht Testbibliotheken auf verschiedene Rechner zu verteilen.

Anfang dieser Woche war es dann endlich soweit. Der Kurs begann Sonntagabend mit einer kurzen Einführung zu theoretischen Themen wie z.B. Lenkradhaltung und Sitzposition und einem Ausblick auf die Übungen der kommenden zwei praktischen Tage. Diese Einführung haben wir dann beim anschließenden gemeinsamen Abendessen mit den Trainern und den übrigen 14 Kursteilnehmern schnell wieder verdaut . Die Unterbringung im Steigenberger Hotel in Kaprun war während der gesamten Zeit hervorragend und die zentrale Lage im Ortskern erlaubte spät Abends sogar den Besuch der ein oder anderen örtlichen Kneipe.

Montag morgen ging es dann endlich zum Trainingsgelände in Saalbach: Eine große präparierte Eispiste auf der bereits 10 laufende S4 Kombi auf uns warteten. Die erste Ansage “Zwei pro Fahrzeug” hörten wir allerdings aus dem Inneren unseres S4 gar nicht mehr. Zuerst standen Übungen zum Thema Fahrsicherheit auf dem Plan, die uns auch mit der Fahrdynamik der S4s auf Eis vertraut machen sollten. Bewusstes Herbeiführen von Untersteuern und Übersteuern machte den Anfang, gefolgt von Übungen zur korrekten Reaktion darauf. Beim Vergleich mit und ohne eingeschaltetem ESP kamen die ersten Aha-Effekte (ESP ist schon eine verdammt krasse Technik). Es folgte eine ABS-Gefahrenbremsung mit anschließendem Ausweichmanöver (inklusive Reaktionszeitmessung und Anzeige der dabei gefahrenen Strecke). Gefahren wurde während der beiden Tage übrigens meistens in zwei Gruppen zu vier Autos und dazu jeweils einem Instruktor. Diese analysierten und kommentierten jede Fahrt, Fehler wurden direkt angemahnt. Und die Jungs haben wirklich alles gesehen: “Wo hast du hin geschaut?” – “Zum Kurvenrand?” – “Richtig. Und wo solltest du hinschauen?” – “Zur Kurvenmitte?” – “Vielen Dank … und der Nächste bitte”.

Nachmittags durften wir dann die ersten Driftübungen absolvieren. Ausweichen (ohne Vollbremsung) bei 60-70 km/h mit Rückführung führten dann zu den ersten Pirouetten und brachten Lars den Titel “Kreiselkönig von Saalbach” ein . Beim Übersteuern mit ersten Driftversuchen durfte ich mir dann meine Tadel abholen: Mit 20 km/h in eine Kurve, runter vom Gas und dann so lange warten bis das Heck kommt ist gar nicht so einfach. Kurze Gasstöße um nicht einzuparken machten oftmals jeden Versuch zunichte und waren bei den Instruktoren nicht gern gesehen . Abgeschlossen haben wir dann den ersten Trainingstag mit einem Rundparcours, gespickt mit Elementen der vorherigen Übungen inklusive Wertungsrunde. Wir landeten bei den Zeiten zwar nur im Mittelfeld, haben ohne ESP bei der Spaßwertung aber locker gewonnen. Abends ging es dann mit dem gesamten Kurs zum gemütlichen Hüttenabend im “Jagawirt” und natürlich zum obligatorischen Bier in kleinerer Runde in der örtlichen Kneipe danach.

Dienstag morgen ging es dann direkt mit Driftübungen weiter: Die Übung “Links/Rechts Lastwechsel in eine Kurve mit Übersteuern und kontrolliertem Drift” hat mich einige meiner wenigen noch verbliebenen Haare gekostet. Gott sei Dank haben die letzten Versuche geklappt und ich hatte direkt wieder gute Laune. Das Driften durch einen 8-förmigen Rundparcours war dann sogar noch anspruchsvoller. Hier verloren wir dann auch direkt zwei Kursfahrzeuge an die äußeren Eismauerbegrenzungen (natürlich aus der anderen 4er Gruppe ). Ersatzfahrzeuge standen aber sowieso immer auf dem Platz und so konnten die Drift-Rowdys schnell wieder Gas geben. Lars und ich haben Gott sei Dank ab und zu nur mal innen auf den weichen Schneebegrenzungen “geparkt” und den Rundkurs neu abgesteckt, unserem S4 Baby haben wir aber kein Haar gekrümmt. Die letzte Übung “Driftslalom” hat dann wieder um so mehr Spaß gemacht, die Eispiste war an der Stelle wesentlich griffiger und zum Driften war genug Platz. Zum Abschluss des Trainings gab es dann wieder einen Rundparcours, diesmal in der großen Variante und mit Elementen aus allen Übungen der vergangenen zwei Tage.
Lars belegte dabei sogar den dritten Platz, ich habe leider in meiner schnellen Runde nach einem Kommentar ala “bis hierher war’s richtig gut” direkt den nächsten Drift ins Eis gesetzt. Danke, Lars.

Heute ist bereits Donnerstag und damit das Training leider schon wieder seit zwei Tagen vorbei. Wir blicken zurück auf zwei spaßige, anspruchsvolle, einfach “coole” Tage auf dem Eis in einem ebenso coolen Auto. Die Durchsicht der geschossenen Fotos und Videos trieb mir gestern Abend direkt wieder das Grinsen ins Gesicht.
Das Training ist eigentlich für jeden Autofahrer empfehlenswert, gleichermaßen geeignet für jung und alt, Männlein und Weiblein. Bei uns im Kurs war z.B. ein älterer Herr, der alle paar Jahre ein Fahrertraining macht, um auszuloten, ob er es noch drauf hat. Respekt. Man lernt sein Auto auch mal in Grenzsituationen kennen und zu handhaben, bekommt dabei aber auch wieder Respekt beim gewollten Überschreiten dieser physischen Grenzen.
Natürlich reichen zwei Tage nicht aus, um einem 15 Jahre antrainierte Autobahnraserei abzugewöhnen, dafür gibt es dann aber z.B. weiterführende Kurse über 3-4 Tage in Schweden und Finnland .

Abschließend bleibt uns nur noch ein Riesendank an die Chefs auszusprechen für dieses super Incentive
die Benziner Lars und Christian

Meine Erwartungen an den Kurs sind hoch. Den Newsletter von Heinz lese ich schon lange und auch als ich ihn bei unserem Meet The Experts kennen lernen durfte gewann ich gleich einen positiven Eindruck von ihm. Er kennt wirklich die fiesesten Details über Java, und ich hoffe er kann mir einige zeigen. Der Kurs verspricht “Extreme Java”. Ich freue mich also auf sehr esoterische Feinheiten ohne echten Praxiswert. Und auf ebenso viele Fallstricke mit echter Praxisrelevanz.

Und ich hoffe auf dem Training andere Java Profis zu treffen die ebenso wie ich Spaß an kniffligen Aufgaben haben. Bist Du auch dabei?

Ich bin der Meinung, dass es sehr schwer ist herauszufinden, wer recht oder unrecht hat … tatsächlich glaube ich, dass das weitestgehend unmöglich ist. Sogar in unserer kleinen Firma finden wir keinen gemeinsamen Konsens darüber, was genau Architektur und was Design ist. Und wenn es schon nicht möglich ist, einen Konsens unter so wenigen Leuten zu erzeugen (selbst wenn einige davon recht starke Persönlichkeiten sind … ), wie soll es dann möglich sein, einen Konsens in der gesamten IT Community zu erzeugen? Das ist höchstwahrscheinlich unmöglich.

Deshalb versuche ich erst gar nicht, eine präzise Antwort auf die Frage zu finden. Stattdessen werde ich versuchen, das Thema von einem anderen Standpunkt aus zu betrachten. Zunächst: Warum ist es so schwer, die Frage zu beantworten? Ich denke, ein großer Teil des Problems liegt darin, dass es keine zufriedenstellende Definition für die beiden Ausdrücke gibt, weder für Architektur noch für Design. Wann immer sie mit einer anderen Person über Architektur oder Design reden, können Sie sich deshalb schon nahezu sicher sein, dass die andere Person über etwas anderes spricht als Sie.

Es gibt *jede Menge* Definitionen, aber die meisten davon sind meines Erachtens entweder so spezifisch, dass sie das Thema nicht wirklich erfassen oder sie sind so vage, dass sie einem überhaupt nicht weiter helfen. Nur ein Beispiel: Robert Martin (der nebenbei gesagt eine Menge sehr schlauer Dinge gesagt und geschrieben hat) hat einmal gesagt “Bei Architektur geht es um die wichtigen Dinge; was auch immer das ist.”. Nun, das sagt alles und nichts. Bedeutet das, dass es bei Design um die unwichtigen Dinge geht? Wahrscheinlich nicht. Und, wenn Kaffee für die Entwickler ein sehr wichtiges Thema ist (was es fast immer ist), bedeutet das, dass es bei Architektur um Kaffee geht? Wahrscheinlich nicht. Wie Sie sehen können, bringt uns diese Definition nicht weiter.

Ich verzichte darauf, andere Definitionen näher zu betrachten, weil ich denke, dass das nirgendwohin führt. Es wird nicht möglich sein, eine Definition für Architektur und Design zu finden, der alle zustimmen *und* die uns hilft, den Unterschied zwischen Architektur und Design herauszufinden. Insbesondere glaube ich, dass es nicht möglich sein wird, eine klare Trennlinie zwischen Architektur und Design zu finden, wo das eine endet und das andere beginnt. Jeder zieht die Linie an einer anderen Stelle und viele Leute haben wahrscheinlich eher eine Art unscharfer Wolke als eine klare Linie in ihrem Kopf. “Irgendwo innerhalb dieser Wolke endet Architektur und beginnt Design” werden sie sagen.

So weit, so gut. Aber es muss doch etwas geben, das uns weiterhilft. Oder zumindest sollte es etwas geben …

Vielleicht hilft es, die Frage für einen Moment beiseite zu schieben. Im Laufe der Zeit habe ich herausgefunden, dass es zwei grundsätzliche Aufgaben gibt, aus denen diese ganze “Architektur-und-Design-Sache” besteht (ohne zu versuchen, eine Trennlinie zu finden). Insgesamt geht es bei der Sache darum, alle existierenden Anforderungen in eine Lösung zu transformieren. (Und sollte jemand fragen, wo dabei die Codierung geblieben ist, möchte ich es demjenigen überlassen, die Trennlinie zwischen Design und Codierung zu finden; ich denke, dass ist eine ähnliche Fragestellung … ).

Im ersten Teil dieser Transformation geht es darum, die ganzen Anforderungen zu verstehen (nicht nur die Anforderungen der Fachbereiche und Anwender, sondern auch die Anforderungen des Managements, der Projektleitung, des Entwicklungs-Teams, des Betriebs, der Systemplanung, der Sicherheitsabteilung, der Tester, und so weiter), die Anforderungen wirklich zu verstehen, sie auszubalancieren (es gibt immer widersprüchliche und inkonsistente Anforderungen über die verschiedenen Domänen und Stakeholder hinweg, mit denen man umgehen muss) und eine geeignete Lösungsidee für all diese ausbalancierten Anforderungen zu finden. Ich pflege diesen Teil der Arbeit “Alignment” oder auch “Einklang” zu nennen.

Der zweite Teil der Transformation in eine funktionierende Lösung besteht daraus, die Lösungsidee in eine geeignete Struktur zu bringen, die Wartbarkeit und Änderbarkeit unterstützt und diese Struktur weiter und weiter bis herunter auf Code-Ebene zu verfeinern, ohne die zuvor beschriebenen Eigenschaften zu verlieren. Diesen Teil der Arbeit pflege ich “Strukturierung” oder einfach nur “Struktur” zu nennen.

Nun, ist es wichtig, diese beiden Aufgaben zu unterscheiden? Ich denke, ja! Der Grund dafür ist, dass ich bemerkt habe, dass diese beiden Aufgaben sehr unterschiedliche Skills erfordern. Während Einklang viel mit Kommunikations- und Konflikt-Management-Skills zu tun hat, erfordert Struktur eher formale Stärken. Einklang erfordert auch ein recht breites Wissen über all die verschiedenen Anforderungsdomänen, während Struktur ein eher tiefes Wissen in der Lösungsdomäne erfordert. Als eine Konsequenz daraus findet man nur relativ wenige Personen, die beide Aufgaben mit der gleichen Stärke wahrnehmen können (oder wollen), und wenn man eine der beiden Aufgaben vernachlässigt, erhält man höchstwahrscheinlich kein befriedigendes Ergebnis.

Okay, kommen wir zurück zu initialen Fragestellung. Helfen uns Einklang und Struktur, eine Trennlinie zu finden. Nun, ich denke, in gewisser Weise …

Aus meiner Sicht ist Einklang auf jeden Fall Teil einer guten Architektur und Struktur ist auf jeden Fall Teil eines guten Designs. Man kann kein guter Architekt sein, ohne viel an Einklang zu arbeiten und man kann kein guter Designer sein, ohne viel an Struktur zu arbeiten. Wie viel Struktur zusätzlich in Architektur benötigt wird und wie viel Einklang in Design – ich denke, das ist gewissermaßen eine Geschmacksfrage und darauf wird es keine endgültige Antwort geben.

Zusammenfassend kann ich auch nicht “die” Antwort auf die initiale Fragestellung bieten. Aber ich weiß, wenn jemand über Architektur redet, ohne über Einklang zu reden, macht er etwas falsch und wenn jemand über Design redet, ohne über Struktur zu reden, macht er auch etwas falsch. Und das ist das Wichtigste aus meiner Sicht …

PS: Ein dickes “Sorry” an Robert Martin, weil ich ausgerechnet auf seiner Architektur-Definition herumgehackt habe. Wie ich bereits zuvor geschrieben habe, hat er eine Menge sehr schlauer Dinge gesagt und geschrieben, auch wenn ich nicht allen davon zustimme. Wenn Sie also die Gelegenheit haben sollten, etwas von ihm zu lesen oder einen Vortrag von ihm zu hören, dann tun Sie es! So, das sollte genug der Wiedergutmachung sein …

Angelehnt an die IT-Landkarte und den damit verbundenen Reisezielen von Gernot Starke (vergleiche Dr. Gernot Starke- Publikationen) kann ich festhalten, dass meine Tagesausflüge nach Architektionien oder Analytistan sehr viele positive Erfahrungen und Eindrücke hinterlassen haben.

Im Unterschied zu anderen Konferenzen, wie z. B. der Jax, fokussiert die OOP für mich viel stärker die “Business Aspekte” im Zusammenhang mit IT. Die Veranstaltungen bieten Erfahrungen und Modelle, um die gefühlte, als auch erlebte meine „Grenze“ zwischen der Business-Welt und der IT-Welt besser zu verstehen, sowie Ideen, Tendenzen, Lösungen und Entwicklungen um die Beziehungen dieser beiden „Welten“ zu verbessern.

In meiner bisherigen Tätigkeit in der IT, erst als Entwickler und mittlerweile als Architekt, habe ich die technischen Aspekte beim Design und der Entwicklung fokussiert. Diese sind nicht nur interessant und spannend, sondern haben einen großen Coolness-Faktor (vergleiche die Keynote „Nachbars Garten – Wo Architekten lernen„ von Gernot Starke). Nun arbeite ich „auf einmal“ viel enger und intensiver mit fachlichen Domänenexperten, Projektleitern oder Businessanalysten, mit jeweils individuellen Anforderungen, unterschiedlichen Interessen und eigentümlichen Sprachen. Ich muss feststellen, dass „coole Technik“ nicht ausreicht um als Architekt im Grenzgebiet zu „überleben“. Aus diesem Grund habe ich eine Veranstaltung gesucht die mir neue Ideen, sowie Impulse für meine Arbeit bietet.

Nachdem ich das Programm zum ersten Mal überflogen habe, war meine Neugier sofort geweckt. Einige bekannte Namen wie z. B. Philippe Kruchten oder Eric Evans kündigten interessante Vorträge und Tutorials an. Letzt endlich sind mir unter anderem die Veranstaltungen dieser beiden Sprecher nachhaltig in Erinnerung geblieben.

Veranstaltungen dieser Art und der spezielle Architektur Tag (Donnerstag den 28.01.2010), organsiert von Peter Hruschka und Gernot Starke (zwei weiteren bekannten Personen im Umfeld Architektur), bestärken mich, das Architektur wesentlich mehr ist als z. B. Design. Zu den Themen Architektur oder der Beziehung von IT zur (Fach) Domäne, habe ich eine Menge Ideen, sowie Erfahrungsberichte von den dortigen Bewohnern und anderen Reisenden mitgenommen. Vor allem der direkte Kontakt während der Vorträge, der anschließenden Q&A Runden, sowie den Diskussionen und Gesprächen mit den Sprechern und anderen Teilnehmern im Nachgang, z. B. beim Mittagessen, hinterlassen einen positiven Eindruck. Diese sind nicht nur interessant, sondern haben mir gezeigt, dass sich viele der „Herausforderungen“ denen ich in meinem täglichen Leben und auf meinen Reisen im “Grenzgebiet” begegne, sich dabei sehr ähneln. Das Lachen kam dabei auch nicht zu kurz.

Unter dem Slogan “Software meets Business” und dem Motto “Productivity: People, Process, and Technology” bietet meines Erachtens die OOP eine Möglichkeit, Architektur (neben anderen Schwerpunkten) von verschiedenen Standpunkten und Sichtweisen zu betrachten. Wer mehr über die Facetten von Architektur erfahren und diskutieren möchte, dem empfehle ich einen Besuch dieser Konferenz.

Besonders hervorheben möchte ich die folgenden Veranstaltungen, meine persönlichen Top 3:

• Tutorial mit Philippe Kruchten: “Software Architecture Knowledge Management – Theory and Practice, Methods and Tools”
• Keynote mit Gernot Starke: “Nachbars Garten – Wo Architekten lernen“
• Tutorial mit Eric Evans, Hans Dockter: „Domain-Driven Design: The Basics / Strategy”

Die Ideen und Impulse für das Überleben als Architekt, die ich in meinen vielen Tagesausflügen gesammelt habe, werde ich sicherlich in meiner Arbeit im „Grenzgebiet“ weiterverfolgen. Somit sind sicherlich nicht nur meine “Top 3″, sondern auch die Erfahrungen und Erlebnisse weitere Blogeinträge wert. To be continued …