Spontanvortrag Model-View-Presenter von Johannes Link

Nachdem Johannes am Montag krank war und den Powerworkshop nicht mit Informationen zum Model-View-Presenter versorgen konnte (und dann am Dienstag in seiner Session auch nicht genug Zeit dafür war), habe ich ihn genötigt, uns doch mal an unserem Flipchart am Stand einen Model-View-Presenter-Vortrag zu halten.
Das war sehr interessant, denn mittels Model-View-Presenter schafft man genau die richtigen Abstraktionen, um möglichst große Anteile auch der Oberfläche testbar zu halten und die eigentliche View mit technischen Abhängigkeiten sehr klein und ohne Fachlogik zu gestalten.
Nähere Infos zu Model-View-Presenter bei Martin Fowler:
http://www.martinfowler.com/eaaDev/ModelViewPresenter.html
(Nicht erschrecken, er hat da jetzt 2 Pattern draus gemacht, Johannes hat das vorgestellt, das Fowler jetzt Passive View nennt: http://www.martinfowler.com/eaaDev/PassiveScreen.html)

Vielen Dank, Johannes!

Selenium

Der Vortragende Neal Ford ist von ThoughtWorks, der Vortrag auf englisch.

Selenium ist ein funktionales Open-Source Testtool für Webanwendungen, geschrieben in JavaScript.

Man schreibt die Tests ähnlich wie bei FIT-Action-Fixtures auf. Ausgeführt wird der Test im Browser. Dabei wird alles mögliche unterstützt, z.B. auch Popup-Fenster.

Im Test muss man natürlich die Elemente auf der HTML-Seite adressieren. Das geht über IDs und Namen und den DOM. Letzteres braucht man vor allem für Elemente, denen man keine IDs gibt, wie z.B. Ausgabetabellen.

Es gibt ein Firefox-Plugin namens XPather: Damit clickt man auf ein Element auf der Seite und bekommt den DOM-Pfad angezeigt, den man dann in den Test einpasten kann.

Bei der String-Prüfung werden auch Wildcards und Regexps unterstützt.

Das Adressieren der Elemente und die Prüfung der Seiteninhalte ist also sehr flexibel.
AJAX geht auch.

Es gibt ein paar Geschichten, die doch nicht gehen: z.B. wenn man in Java-Script als Reaktion auf onload einen Dialog öffnet. File-Upload funktioniert nur in Firefox.

Variablen werden unterstützt. So kann man einen Wert, den die Anwendung generiert, in einer Variablen starten und woanders wieder einfügen. Variablenwerte kann man auch durch JavaScript berechnen lassen.

Der Referent rät dazu, hart-codierte Werte in Akzeptanztests zu vermeiden. Ich habe aber nicht verstanden, wie er die umgeht.

Selenium lässt sich in automatic-builds integrieren. Dazu muss man anscheinend nur den Browser mit der URL des Tests aufrufen. Ich bin nicht ganz sicher, aber es scheint so, dass Selenium das Ergebnis dann an den Integration-Server POSTet.

Normalerweise muss man die Anwendung zum Testen serverseitig mit dem Browser-Bot starten. Mit Remote-Control-Selenium braucht man das nicht und kann so Seiten testen, die dafür nicht vorbereitet sind (z.B. Google). Das läuft über einen Proxy-Server. Damit kann man nicht nur die Tests ausführen, sondern auch über die Kommdozeile die Web-Anwendung fernzusteuern. Also kann man die Selenium-Tests auch als JUnit-Tests oder in Ruby oder sonstwas schreiben. Jetzt zeigt er einen Selenium-Test in JUnit. Das sieht eher unübersichtlich aus - die HTML-Version des Tests ist übersichtlicher. Vielleicht helfen beim JUnit-Test auch ein paar Extract-Methods.

"Web Developer Toolbar"-Plugin für Firefox und Internet-Explorer ist nützlich.

Es gibt eine Selenium-IDE als Firefox-Plugin. Damit kann man Tests aufzeichnen und wieder ausführen. In dem Test gibt es natürlich kaum Asserts. Die fehlenden Asserts kann man direkt in der IDE ergänzen. Da gibt es auch Auto-Completion. Den aufgezeichneten Test kann man als HTML-Test oder JUnit-Test oder, oder, oder exportieren.

Jetzt wird gezeigt, wie man eine Google-Maps-artige AJAX-Anwendung testet - Selenium kann alles testen, wo man draufclicken kann. Beeindruckend!

So gehen sie bei Thought-Works vor: Wenn eine Story implementiert ist, zeichnet der Business-Expert den Durchlauf durch die Anwendung auf und die Entwickler ergänzen fehlende Asserts.

In Kürze soll eine Integration mit FIT kommen.

Es wird gefragt, wie es mit der Wartbarkeit der Tests steht: Neal exportiert die Tests nach Java bzw. Ruby und bearbeitet sie dort weiter. Ohne diese "Aufarbeitung" sind die Tests sehr fragil.

Man kann HTML und JavaScript testen, aber kein Flash, ActiveX etc. iFrames gehen aber. Für HTTPS muss man das Zertifikat einmalig importieren.

Load-Testing geht (noch) nicht. "We kill only one Mercury product at a time."

(Der Referent benutzt nicht nur einen Mac, sondern auch IntelliJ - sonst sieht man ja immer nur Eclipse.)

Fazit
Selenium ist sehr mächtig. Das bezahlt man mit Komplexität. Die Tests, die man als Web-Seiten beschreibt wirken fast wie eine eigene Programmiersprache. Ich kann mir nicht vorstellen, dass Anwender solche Tests selber schreiben. Sie können sie aufzeichnen, aber anschließend nicht mehr warten / verstehen.

Für Tests, die die Entwickler schreiben, ist Selenium sicher interessant.

Angriffe auf Webanwendungen

Jetzt mache ich mal Werbung für die Konkurrenz: Unserem Stand gegenüber steht "Optima bit". Die machen mehrfach am Tag Live-Vorführungen, wie man Web-Anwendungen angreifen kann mit SQL-Injection und Cross-Site-Scripting. Die Vorführung ist kurz, knackig, leicht verständlich und etwas beunruhigend.

BOF. Die Zukunft der Programmiersprachen

Der Raum war ausgerichtet auf eine Art Panel-Diskussion - vorne Stühle für die Speaker und hinten Stühle für die Zuschauer. Markus Völter meinte, ein BOF sei anders. Mehr so, dass Speaker und Teilnehmer zusammen im Kreis sitzen und miteinander diskutieren.
Dazu waren aber definitiv zu viele Leute (100?) da. Also hat Markus vorne Zettel mit Thesen hingelegt. Wir sind dann einmal nach vorne gegangen, haben uns ein Thesenpapier genommen und das dann "vertreten". Natürlich waren die Zettel nur die Startpunkte für die Diskussion.
Die Diskussion selbst war lebhaft, aber dann doch auf wenige beschränkt. Manchmal driftete sie vom eigentlichen Thema ab, aber das haben die Speaker dann wieder eingefangen.
Zuerst ging es um das Thema AOP. Ca. die Hälfte der Anwesenden nutzt AOP. Die meisten aber nur dadurch, dass sie Spring einsetzen. Nur ein kleiner Teil benutzt AspectJ. Niemand benutzt AOP für was anderes als die üblichen rein technischen Beispiele Logging, Tracing, Transaktionshandling und Security. Die meisten finden AOP eine interessante Technologie, hatten aber im Ansatz eine Vorstellung davon, wie man funktionale Aspekte definieren soll. Ein Teil der Teilnehmer fand AOP in Gesamtgröße a la AspectJ auch viel zu kompliziert.
Bei der Komplexität fanden einige, dass Java zu kompliziert wird. Dierk König (sinngemäß): "Für mich hat JDK 1.4 gereicht. Java 5 ist für mich zu kompliziert." Es gab eine ziemliche Einigkeit darüber, dass die Zukunft der Programmiersprachen in Einfachheit liegen müsste. Dabei gingen die Meinungen auseinander, ob man ein einfacheres Java braucht, eher was Dynamisches a la Ruby oder Groovy oder gar etwas Funktionales a la Scala. Dabei gab es ein erstaunliches Interesse an funktionaler Programmierung. Das rekursive Programmieren sei vielleicht am Anfang gewöhnungsbedürftig, aber das sei OO auch. Außerdem bieten funktionale Programmierung den Vorteil, dass man das Programm transparent parallel ausführen kann. Das ist vor der Diskussion um Multi-Core-Prozessoren und ihre Auswirkungen auf die Programmierung natürlich ein echtes Argument - jedenfalls, wenn man glaubt, dass man in seinen Programmen die Multi-Core-Fähigkeit ausnutzen muss und nicht sowieso durch die Datenbank ausgebremst wird.
Dann gab es noch eine Diskussion um Closures. Alle wollen Closures. Dierk sagt, dass noch nicht raus ist, ob und wenn ja in welcher Form Closures in Java 7 enthalten werden. Er glaubt, dass man in Java über anonyme Inner-Classes letztlich nicht herauskommen wird.
Insgesamt war es eine interessante Session.

XP-Live-Demo

it-agile hat in der XP-Live-Demo in einer Mischung aus Vortrag und "Theater" ca. 100 Teilnehmern vorgeführt, wie XP funktioniert. Matthias Lübken spielte den Kunden, Robert Beeger und Sebastian Sanitz die testinfizierten pair-programmierenden Entwickler. Stefan Roock moderierte.

XP-Live-Demo

it-agile hat in der XP-Live-Demo in einer Mischung aus Vortrag und "Theater" ca. 100 Teilnehmern vorgeführt, wie XP funktioniert. Matthias Lübken spielte den Kunden, Robert Beeger und Sebastian Sanitz die testinfizierten pair-programmierenden Entwickler. Stefan Roock moderierte.

BOF: Rubik`s Wuerfel - Marketing fuer Softwareunternehmen

Der Speaker, Ashley Steele, kündigt an, er will seine Session wirklich als BOF gestalten, also nicht frontal, sondern interaktiv mit vielen Nachfragen und Erfahrungsaustausch.

So wie der Rubik´s-Würfel drei Dimensionen hat, hat auch das Marketing drei Dimensionen:

1. Zielgruppe: Wem möchte ich etwas sagen?
   
2. Inhalt: Was möchte ich den Leuten sagen?
3. Methode: Wie möchte ich den Leuten das sagen?

Zu 1): Man muss die Probleme der Zielgruppe verstehen, nicht seine eigenen Leistungen in den Vordergrund stellen. Die Zielgruppe lässt sich segmentieren nach a) business - technisch, b) Größe des Unternehmens, c) Marktsegment - was stellt der Kunde her?

Zu 2): Es gibt 4 Phasen, um den Kunden zu gewinnen: a) Generate awareness (blogs, events, news), b) Engage (read a whitepaper), c) Try, d) Convince User. Man muss den Kunden an die Hand nehmen und ihn von Schritt zu Schritt führen. Es muss klar sein, was der Kunde tun soll, und was man ihm verspricht, muss man auch einhalten können.

Zu 3): Man muss die richtigen Kanäle für seine Zielgruppe aussuchen: Blogs für Entwickler, aber nicht für Manager. Man muss Mechanismen haben, um zu messen, ob meine Bemühungen Erfolg haben: Wie viele Downloads habe ich, wie viele Lizenzen verkauft usw. Diese Messungen müssen *vorher* in die Planung einbezogen werden.

Als Fazit wird gezogen: Marketing muss RELEVANT, RELEVANT, RELEVANT sein. Wenn ein CEO auf eine Entwicklerseite gelangt, dann ist er innerhalb von Sekunden wieder weg. Man sollte aber nicht versuchen, alle potenziellen Kunden auf einmal anzusprechen, sondern sich lieber auf die wichtigsten beschränken.

Bei der Fragerunde ergibt sich ein interessanter Punkt: Alle auf der JAX wissen, warum Techologie A besser ist als Technologie B. Aber deswegen darf man auf keinen Fall darauf schließen, dass das für andere Gruppen (z.B. CEOs) auch relevant ist. Unter Umständen muss man denen Sachen erklären, die man für völlig selbstverständlich hält.

Inhaltlich war es für mich nichts relolutionär Neues, aber es schadet natürlich nichts, die wichtigen Dinge immer wieder zu hören. Warum das Ding BOF hierß und was der Unterschied zu einer normalen Session war, bleibt mir verborgen. Aber macht ja nichts.

Concurrency, past and present

Ein paar Gedanken zu Concurrency, past and present von Brian Goetz:
Auf der JAX höre ich das nun zum zweiten mal: Als Java-Entwickler muss man sich in Zukunft auf Nebenläufigkeit einstellen. Auch wenn einige Kollegen noch nicht so richtig davon überzeugt sind ("So lange mich die Datenbank ausbremst, brauche ich mir um Threads keine Gedanken zu machen"), glaube ich dass das Thema sehr wichtig wird. In zwei Jahren wird JEDER mehrere Prozessoren in seinem Rechner haben. Und wenn dann Anwendungen anfangen diese Prozessoren zu nutzen, werden wir uns sehr schnell an die Geschwindigkeit gewöhnen. Single-Threaded Java-Anwendungen werden sich anfühlen wie die ersten Java-Anwendungen auf dem Desktop: Laaaaaangsam.

Brian hat zum Schluss noch ein paar Tipps zu Nebenläufigkeit gegeben:

• Minimize ammout of code that has to deal with concurrency
• use immutable objects wherever you can
• sometimes it's cheaper to share

Hmm. Das wird sicherlich noch die ein oder andere Architektur-Diskussion nach sich ziehen.

Der Jax-Innovation-Award...

...geht an Groovy!

RSS-Feed für die Kommentare dieses Blogs...

findet sich hier: http://jax2007blog.it-agile.de/feeds/comments/default

Nachtrag zum Hotelbesuch

Ich habe natürlich ein neues Zimmer bekommen und dann noch ein Entschuldigungsschreiben mit Essensgutschein. Auch wenn ich wohl nicht dazu komme, den Essensgutschein einzulösen - ich wohne schließlich in Hamburg - zählt die Geste.
Ich wollte auch keineswegs das Hotel bashen oder Ähnliches. Ich vermute, dass sowas eben nicht 100%ig verhindert werden kann. Ich habe mal gehört, dass es in jeder Bäckerei Ratten gibt. Man kann die sie nicht ganz loswerden, sondern nur im erträglichen Rahmen halten.
In diesem Sinne sehe ich ganze Angelegenheit als unangenehme Panne, die auch mal passieren darf - wir sind halt alle nur Menschen. Abgesehen von dieser Panne war das Hotel sehr gut.

Business-Zuschnitt von SOA-Services

Ich komme etwas zu spät. Die Folien sind im Retrostyle. Der Referent ist gerade dabei, konzeptionelle SOA-Grundlagen zu erzählen. Alles wie bei den anderen SOA-Vorträgen auch: Unmengen von Zeug und Abkürzungen, die ich allenfalls in Ansätzen verstehe.

Das Verhältnis von WSDL und BPEL ist nicht ganz klar definiert. Vor allem ist häufig nicht klar, wo man welche Sachem am Besten definiert.

Man braucht für SOA-Projekte einen sehr großen organisatorischen Overhead und es müssen Unmengen Leute und Abteilungen einbezogen werden.

Am Ende kommen ein paar Empfehlungen:
1. Keine Transaktionen über mehrere Services verwenden. Das ist schwer zu handeln und macht das System langsam. Nach Möglichkeit soll man optimistisches Locking verwenden und ggf. inverse Operationen. Letzteres sei auch der Weg, den BPEL nahelegt.
2. Wichtig ist, dass die Services nicht technisch orientiert sind (service.updateCustomer), sondern fachlich (service.createNewCustomer, changeCustomerAdresse, etc.). Ansonsten ist es für den Geschäftsprozessmodellierer sehr schwer, die genaue Funktionsweise und Seiteneffekte der Operationen zu verstehen. Außerdem landet dann Fachlogik (was bedeutet es, umzuziehen) in den Geschäftsprozess-Definitionen.
3. Granularität: Nicht zu grob, nicht zu fein. Aha.

Schneller fahren auf mehr Spuren

In dieser Session wurde zunächst darauf eingegangen, dass man sich nicht mehr wie früher darauf verlassen kann, dass mit der nächsten Rechnergeneration die eigene Software automatisch schneller wird.
Es ist nicht mehr so, dass neue CPUs immer schneller werden. Hier scheint man an die Grenzen des Machbaren zu stoßen. Statt dessen geht der Trend hin zu Mehrkern-CPUs. Will man diese ausnutzen, müssen die eigenen Anwendungen multithreaded programmiert werden.
Java-Threads werden wo möglich auf Betriebssystem-Threads abgebildet. Unter Windows XP ist das zum Beispiel der Fall.
Aus Java heraus kann man nicht selbst bestimmen, auf welchem Prozessor welcher Thread läuft, aber das ist auch in den meisten Fällen nicht nötig. Man verlässt sich darauf, dass das Betriebssystem die Threads richtig verteilt. Die meisten Entwickler würden das auch nicht besser optimiert bekommen.
Die Referenten stellten die Features des java.util.concurrent-Packages vor, die in Java 5 dazugekommen sind. Diese vereinfachen die Entwicklung mit Threads deutlich. Es ist nicht mehr notwendig, sich mit der low-level Threading-API von Java herumzuschlagen. Für häufig vorkommende Situationen gibt es jetzt in dem neuen API Unterstützung. Ein Kollege von mir soll mal gesagt haben "Mit Threads kommst du in die Hölle." Möglicherweise ist das jetzt nicht mehr ganz so schlimm ;)
Ein spannender Vortrag, der zeigte, dass es lohnt, sich mit diesem Thema wieder mehr zu befassen.

REST - das bessere Web-Services-Modell

Der Referent dieser Session - Stefan Tilkov - nutzte einen großen Teil der Session, um mit markigen Zitaten zu zeigen, warum Web-Services schlecht sind. Da wurde mir gleich wohler. Irgendwie konnte ich mich noch nie für WSDL, UDDI, Axis etc. begeistern.
REST ist hierzu ein krasses Gegenstück. Praktisch ist es nichts anderes als HTTP oder teilt zumindest einen großen Teil der Konzepte mit HTTP. Ein REST-Service wertet die Anfrageart aus. Bei der Servlet-Programmierung wird meistens nur GET und POST verwendet und nur danach ausgewählt, ob die Parameter der Anfrage im Browser in der URL erscheinen sollen. Bei REST würden bei GET zum Beispiel die Daten zurückgeliefert werden, die unter einer bestimmten URI verfügbar sind. POST würde verwendet werden, um neue Daten unter einer URI zu speichern.
Eine Kritik an REST ist, dass es sich nur für CRUD-Operationen eignen soll, was aber nicht der Fall ist, da es von der Anwendung abhängt, wie eine Anfrage interpretiert wird. REST macht hier weder Annahmen noch Vorgaben.
Der Referent erwähnte auch JSR 311: "JAX-RS: The Java API for RESTful Web Services", das eine API zum Zugriff auf Web Services bieten soll, und Restlet, das dies bereits tut. Seiner Meinung nach sind aber beide nicht wirklich aufregend, weil die Arbeit mit REST so einfach ist, dass solche APIs nicht notwendig sind.

Besuch im Hotel, 2. Teil

Gerade komme ich ins Hotelzimmer und habe sie überrascht. Wieder ganz nackt, aber diesmal vor Schreck erstarrt, sitzt sie mitten im Badezimmer. Ich finde, das Hotelzimmer ist zu klein für zwei und außerdem kriege ich Ärger mit meiner Frau, wenn ich eine andere im Zimmer habe. Also erlebt sie die Ankunft das großen schwarzen Schuhs.



Viele Leser des Blogs, haben sich gefragt, woher ist wusste, dass es eine "sie" ist. Ganz einfach: Entweder war es "sie", die Kakerlake oder "sie", die Küchenschabe :-)

Und dann bekonmme ich noch eine Lektion über die Anatomie von Küchenschaben/Kakerlaken. Man kann sie nicht im Klo runterspülen. Die haben zuviel Auftrieb.



Ich komme langsam zu der Überzeugung, dass sie eine Küchenschabe ist, äh war. Denn unter dem Waschbecken hängt das hier:



Scheint nicht so richtig gut funktioniert zu haben.

Stefan und Matthias chatten über Jazz

7:35 PM matthias: Hallo Stefan. Ich sitze hier und warte auf Erich Gamma. Bist Du schon da?
stefan: Ich bin auch schon da.
7:36 PM Aber Erich ist zu spät. Schon 4 Minuten.
matthias: Die Musik ist ja ganz schön "hip".
stefan: Ja, die "burnt".
7:37 PM matthias: Der Saal ist aber ganz schön voll für die Uhrzeit. Was meinst Du, 800 Leute?
7:38 PM 19:38 es geht los.
7:39 PM stefan: Kann sein.
matthias: Sebastian Meyen ist auf der Bühne und spricht in Englisch.
stefan: Faszinierend :-)
7:40 PM matthias: Applaus. Erich kommt auf die Bühne.
stefan: Und er spricht auch Englisch.
7:41 PM matthias: Ein wenig erinnert er mich an Steve Jobs.
7:42 PM stefan: Titel des Vortrags ist "How I Learned to Stop Worrying and Love Process". "Process" ist durchgestrichen und durch "Practices" ersetzt.
matthias: Und es geht um seine Geschichte.
7:43 PM stefan: Zuerst haben sie Eclipse gebaut. Dabei ist ein Entwicklungsprozess entstanden "The Eclipse Way" und dann haben sie Tools für den Prozess gebaut. Hört sich erstmal nach einem Rezept für ein Desaster an.
matthias: Er beschreibt Jazz als Tool um den Eclipse Way durchzuführen.
7:45 PM Stefan bekommst Du auch mit wenn Builds in deinen Projekten fehlschlagen?
7:46 PM stefan: Nicht, wenn ich auf einer Konferenz bin.
7:47 PM matthias: Im Moment redet über transition from closed to open source.
Viele Bugs bedeuten viel "Liebe" aus der Community.
7:48 PM stefan: Für Open-Source ist es wichtig, eine Community aufzubauen.
7:49 PM Wenn man In-House-Software entwickelt, bilden die Anwender auch auch Community?
matthias: Gute Frage. Vor allem: Sind wir auch so transparent wie Eclipse?
7:51 PM stefan: Wie transparent sollte man bei Anwendern sein? Würden die wirklich wöchentliche Builds ausprobieren?
matthias: dict.leo.org: accountabiliy: Haftung / Rechenschaft / Verantwortlichkeit
7:52 PM stefan: Wenn bei Eclipse 0,1% der Anwender die Builds und Milestones ausprobieren, ist das viel. Wenn 0.,1% unserer Anwender das tun, ist das keiner.
matthias: Für Erich ist accountability wichtig.
stefan: Jetzt kommt das Bild mit den Practices aus "The Eclipse Way". Der Prozess ist agil und inkrementell.
7:53 PM "Continuity" ist wichtig. Continuous design, refactoring, testing etc.
7:54 PM Nur wenn man überall "continuous" ist, kriegt man "continuous health" und das ist notwendig, um die Community aufrecht zu erhalten.
7:55 PM matthias: Kontinuität finde ich auch wichtig. Für mich steht das ein wenig dafür dass man sich nicht ausruhen sollte.
7:56 PM stefan: Der Eclipse-Way nutzt Best-Practices aus vielen Bereichen. Der Eclipse-Way ist nicht "low ceremony". Es gibt approvals, verifications und reviews.
7:57 PM matthias: Für sind practices wichtig und diese peu a peu hinzufügen.
Hmm hat Beck das nicht anders gesagt?
stefan: Ich glaube, "continuity" ist mehr als "sich nicht ausruhen". Auch wenn ich ständig hart arbeit, kriege ich nicht automatisch "continuity", allenfalls "continuous overwork".
7:58 PM Und das ist je Team sehr unterschiedlich.
7:59 PM matthias: Und seine Windows-Taskleiste ist voll mit Icons.
stefan: Irgendwas Interessantes dabei?
Der Eclipse-Way ist komponentenorientiert und funktioniert auch für verteilte Teams.
8:00 PM Die Komponenten werden auch für die Planung verwendet.
matthias: Innerhalb von einer Komponente kann man wesentlich schneller entwickeln, als Komponenten übergreifend.
stefan: Es kommt ein Popup, dass der Eclipse-Build gerade fehlgeschlagen ist.
8:01 PM matthias: Es popt schon wieder ein Test-Build auf.
8:02 PM Nachdem sie gesehen haben dass sie einen eigenen Weg eingeschlagen haben, wollten sie diesen auch nach aussen beschreiben.
Er legt ne Folie über Eclipse EPF auf.
8:03 PM http://www.eclipse.org/epf/
stefan: EPF = Eclipse Process Framework
8:04 PM Was ist ein PMC?
matthias: Eclipse hat selbst organisierende Teams.
8:05 PM Martin sagt: project management commitee
8:06 PM stefan: Aha
matthias: Er hat mich gerade abgehängt.
stefan: Sie wollten den Eclipse-Way in EPF beschreiben.
8:07 PM Im ersten Versuch haben sie die Kooperation "vergessen". Die Prozessdarstellung war rein hierarchisch und so ist der Eclipse-Way nicht.
8:08 PM matthias: Ahh. jetzt habe ich Dich auch gesehen.
8:10 PM stefan: Außerdem lesen die Entwickler längere Texte nicht. Daher hat auch die Beschreibung der Practices nicht funktioniert.
8:11 PM Werkzeuge zur Prozessunterstützung sollten den Entwicklern die langweilige Arbeit abnehmen, so wie ein Refactoring-Browser langweilige Arbeit abnimmt.
Jazz heißt das Tool.
8:13 PM Jazz soll eine Kooperationsplatform für die Softwareentwicklung sein, die die verschiedenen Aufgaben während der Entwicklung nahtlos integrieren soll.
8:14 PM matthias: Jetzt aber, bin wieder da.
8:15 PM stefan: Kannst Du noch lesen, was auf der Folie steht?
matthias: Nein.
8:16 PM Keylesson: If you are modular, you can be agile.
8:17 PM stefan: OK, dann brauche ich noch keine neue Brille.
matthias: Jetzt stellt er Eclipse im Detail vor.
8:18 PM Als erstes das Team.
stefan: Ich dachte, Jazz...
8:19 PM Wenn man größere Projekte braucht, reicht es nicht mehr aus, nur zwischen privaten Workspace und dem globalen Codebestand zu unterscheiden.
8:20 PM matthias: ... Man braucht einen Workspace pro Team.
Teams können aus Teams bestehen.
stefan: Einmal pro Woche werden die Team-Workspaces zusammengeworfen.
8:21 PM Jedes Team hat seine eigene Dynamik. Daher besitzt jedes Team seine Prozesse und Praktiken.
8:23 PM matthias: Und Jazz unterstütz das irgendwie.
8:25 PM Jazz hat viele Quick-Fixes. Cool Strg-1 rules.
stefan: Und Jazz wird mit Hilfe von Jazz gebaut: "Eat your own dogfood."
Jetzt kommt die Demo.
8:26 PM Erich benutzt Windows und keinen Mac!
8:27 PM matthias: Er demonstriert Jazz und findet 100 Sachen die er direkt sieht.
stefan: Der Demo kann ich nicht folgen. Wirkt für mich wie zufälliges Rumgeclicke.
8:28 PM matthias: Hmm wenn mein Projektmanager so viel so schnell sieht, fühle ich mich dann nicht ein wenig sehr beobachtet?
Er versucht die letzten Minuten noch schnell Inhalten zu füllen und wird zu schnell.
8:29 PM stefan: Die "letzten Minuten"? Seine Redezeit ist schon seit über 10 Minuten abgelaufen - laut Programm :-)
8:30 PM matthias: "Wir machen auch kein Pair-Programming"
8:31 PM Die Tatsache wurde auch schon vor ein paar Tagen zusammen mit Jutta Eckstein diskutiert.
Der Talk ist vorbei.
stefan: Und was kam da raus?
matthias: "And now it's party time"
stefan: Jazz wird ein kommerzielles Produkt werden, wenn ich das richtig verstanden habe.
matthias: Alle waren ein wenig entäus
cht.
8:33 PM So der Stefan unterhält sich schon wieder. Damit erkläre ich diesen Chat für beendet.

MDRE - Model Driven Requirements Engineering

Ich war auf einem Vortrag von Erwin Tratar zu "Model Driven Requirements Engineering - die nächste Generation des Requirements Engineering" und war entsetzt.
Der Herr Tratar scheint ein netter und kompetenter Mensch zu sein, aber was er da vorgestellt hat, war ein erneuter Versuch aus IT-Sicht sich das Requirements Engineering so schön zu modellieren, wie man es gerne hätte, wie aber Kunden damit nicht umgehen können.

Aber der Reihe nach:
Bei der Beschreibung des Ist-Zustands habe ich schon Zweifel, weil es zum Glück heute auch schon viele andere Projekte gibt, auch agile Projekte. Also, die Beschreibung ging wie folgt: Kunde liefert mülliges Word-Dokument ab, Architekt macht daraus Grobdesign oder irgendwie UML-Zeug und die Entwickler müssen dann beides lesen, um die Anforderungen umzusetzen. Wie und warum so ein Architektur aus Müll Modelle baut, ist mir ein Rätsel. Heißt es nicht so schön "Müll rein - Müll raus"?

Dann ging die Argumentation ungefähr so (und eigentlich raffiniert), dass wir ja bei der Softwareentwicklung heute prima Unterstützung durch Tools hätten und uns von Lochkartenstanzern zu Rational entwickelt haben (also, nicht nur Eclipse als IDE, sondern natürlich mit UML). Da seinen die RE-Tools nicht so weit (was ich gar nicht beurteilen kann, aber mir reichen ja im Zweifelsfall auch ungelochte Lochkarten ;-)
Die notwendigen Schritte seien dann Integration, Standardisierung und Abstraktion, denn so sei es bei den IDEs ja auch gelaufen.
Das klingt erstmal schlüssig, geht aber davon aus, dass Softwareentwicklung und Requirementsengineering ähnliche Prozesse wären, was sie meiner Meinung nach nicht sind!


So, jetzt wird es lustig: Benutzer verstehen Fachlichkeit und Word-Dokumente und ein bißchen UML in abnehmender Reihenfolge während Entwickler UML, Architekturen und Code in zunehmendem Maße gut beherrschen. Die einzige Überschneidung sei also UML, was also die Basis für das neue RE sein müsste plus Ergänzungen.
Meine Nachfrage: "Warum können Entwickler keine Worddokumente lesen?"
Leichte Heiterkeit im Saal.
Antwort: "Doch, aber es käme ja drauf an, was da drinsteht!"
Aha, klar, wenn ich da Code reinschreibe... (im Ernst: Nachher wurde klar, dass der Vortragende wohl meint, es müsste für Entwickler hierarchisch und mit festen Formularfeldern organisiert sein; es fiel sogar etwas wie "der Mensch denkt ja immer hierarchisch" - fiel mir gerade ganz assoziativ ein!)

Gut, diese Anreicherung des UML-Zeugs sind also dann so Formular und strukturierte Dokumente und sowas wie EPKs (Ereignis-Prozess-Ketten), was der normale Anwender nach meiner Meinung auch nicht unbedingt versteht.

Jetzt kam mal ein schönes UML-Diagramm, in dem die Entitäten Use-Cases, Change-Requests, Project-Overview, Use-Case-Packages, Milestones und Decisions in Beziehung gesetzt wurden (als Klassendiagramm, also auch was für Anwender?). Lustig, aber nix Neues, dachte ich.
Das kann man dann aber auch datenbankifizieren und jetzt nur noch diese Entitäten vollhämmern elektronisch und dann das Lastenheft generieren!
Wozu man das tun soll, wo das doch keiner lesen mag/kann, aber kostet ja nix, wird ja generiert. Man kann dann auch anderes Zeug anreichern und Projektfortschritt und Tests und sonstwas da noch mit aufnehmen. Klar. Hat dann aber was mit Tracking zu tun und nix mit RE, denn wie kommt das Zeug da so strukturiert rein.

Die haben das mal in einem Projekt mit >3.000 Use-Cases eingesetzt, was sicher auch gut funktionert hat, denn der Kommentar zum Aufwand der Use-Cases mit max. 5 PT Aufwand macht ja deutlich, dass es auch agile "User-Stories" sein könnten. Und die Datenbank mit den Stories haben bestimmt nicht die Anwender gefüllt.

Insgesamt fand ich die transportierte Grundeinstellung "Entwickler interessieren sich nicht für Fachlichkeit und sind dafür ggf. auch zu blöd" ziemlich schlimm.

Es scheint also immer noch nichts wirklich Neues zu geben an der RE-Front, was mal den Anwendern erlaubt, das Zeug anders aufzuschreiben, damit die ITler das verstehen.

Da fällt mir ein, dass man doch auch anders vorgehen könnte: Wenn man kleinere Häppchen unverständlichen Zeugs mal versucht in Software zu gießen und das dann den Anwendern zum Beurteilen wieder übergibt, dann könnte man doch toll Rückkopplungen bekommen und so schrittweise besser werden!

Ach, geht nicht, weil es ja exakt werden soll für 2 Jahre im Voraus? Na, gut, dann eben "Müll rein, Müll raus"! (scheint ja zu klappen)

Der etwas andere it-agile-Messestand

Der it-agile-Messestand hebt sich von den anderen Messeständen ab. Der Stand verfolgt ein offenes und pragmatisches Konzept. Alles, was aushängt, ist handgezeichnet. Ein Sofa bildet den Mittelpunkt und soll zum ungezwungenen Gespräch einladen.

Fotos...

...finden auf auf Flickr: http://www.flickr.com/groups/jax-conference/

Standup

Eben haben wir an unserem Stand unser erstes Stand-up-Meeting durchgeführt, um uns gegenseitig über den Fortschritt der Konferenz auf dem Laufenden zu alten. Dabei haben wir in guter alter Scrum-Manier die drei Fragen beantwortet:

1. Was habe ich seit dem letzten Stand-up getan?
2. Was hat mich dabei behindert?
3. Was werde ich bis zum nächsten Stand-up tun?

Spontan hat sich Tobias Widmer von IBM Rational Research Lab Zürich dazugestellt und beim Stand-up mitgemacht.

Quo Vadis Eclipse Ecosystem

Die Session ist eine Art Opening Keynote für das Eclipse Forum Europe. Mike Milinkovich eröffnet die Session mit einem kurzen Überblick über seinen eigenen Hintergrund und wie sich Eclipse in den letzten Jahren entwickelt hat. Er legt viel Wert darauf, dass es mehr als 800 Committer gibt, sehr viele Firmen Eclipse unterstützen und es viele Projekte gibt, die mehr und mehr Sprachen für die Eclipse IDE unterstützen.

Erich Gamma folgt und erzählt, dass Jazz ein gutes Beispiel dafür ist, wie man mit Eclipse Business generieren kann und beide Seiten davon profitieren können. Viele Dinge sind aus der Jazz-Entwicklung zurück in die Eclipse-Entwicklung geflossen und umgekehrt. Als nächstes spricht er über das "Pipelining", dass neue Leute hineinwachsen und das Eclipse-Ecosystem mit neuen Gedanken und Impulsen versorgt und das die alten Hasen langsam die Projekte verlassen. Er hält dies für einen Weg innerhalb des Eclipse-Ecosystems.

Mik Kersten kommt als nächstes dran und erläuert, was Mylar ist und erzählt, warum man mit der Task-Orientierten Arbeitsweise schneller und besser entwickeln kann. Mylar unterstützt task-orientierte Arbeit in Eclipse und erlaubt, nur das einzublenden, was zum aktuellen Arbeitskontext gehört. Dadurch wird die Arbeit übersichtlicher. Diesen Kontext eines Tasks kann man mit Team-Kollegen austauschen. Er erzählt, dass sich immer mehr Leute für Mylar interessieren und damit das Projekt stark von dem Eclipse-Ecosystem profitiert. Man bekommt innerhalb des Ecosystems sehr schnell Feedbackm, die Feedback-Zyklen sind sehr kurz. Mylar konnte sich so sehr schnell weiterentwickeln und auf die Wünsche der User eingehen. Die Art und Weise, wie man bei Eclipse mit Projekten umgeht, macht es außerdem einfach, zu Projekten direkt beizutragen (Bug schreiben, Bugfix attachen, etc.). Außerdem erzählt er, dass das Plugin-Modell und die Abstraktionen in Eclipse es sehr einfach machen, so etwas wie Mylar zu integrieren.

Ralph Müller (Director Eclipse Ecosystem Europe) berichtet, dass er in seiner Rolle viel durch die Gegend reist und mit Leuten spricht. Er muss immer wieder den Leuten klarmachen, dass es sich bei Eclipse um ein ernst zu nehmendes Projekt handelt und kein Spielprojekt. Er untermauert diese Sichtweise gerne durch Beispiele aus der Industrie, die bereits Eclipse verwenden. Dabei handelt es sich teilweise auch um sehr konservative Unternehmen. Er erzählt, dass sich viele Leute für Eclipse interessieren und Projekte mit Eclipse machen wollen, es aber an Leuten mangelt, die diese Projekte durchführen können. Es ist also Arbeit genug da. :-)

Als letztes in der Runde spricht Stephan Wilczek (WeigleWilczek GmbH) über seine Arbeit und dass sie Unternehmen helfen, Projekte mit Eclipse durchzuführen. Er berichtet, dass Eclipse eine Reihe von sehr nützlichen Konzepten und Implementationen liefert, die es ihnen deutlich einfacher macht, Projekte zu realisieren. Es ist im Prinzip eine kleine Danksagung an das Eclipse-Projekt.

Nun beginnt die offene Diskussions-Runde. Sebastian Meyen moderiert die Runde und beginnt auch, eine Frage zu stellen. Er fragt Stephan, ob die Foundation ihm hilft. Stephan antwortet, dass die Foundation ihm hilft, Eclipse bekannt zu machen und Kontakte herzustellen. Er sieht aber den Bedarf, Eclipse in Management-Kreisen und in wirklich großen Unternehmen zu bewerben, um den Einstieg bei Unternehmen zu bekommen. Mir scheint dies irgendwie ein Ansatz zu sein, mit einer Technologie reinzugehen und nicht so richtig die passende Technologie für ein Problem zu nehmen, aber dafür ist es ja auch ein Eclipse-Forum hier. Er erzählt auch, dass es zu wenig Leute gibt, die sich mit Eclipse auskennen. Wir brauchen mehr Eclipse-Experten.

Mike beobachtet, dass Eclipse mehr und mehr auch im Management-Bereich bekannt wird, aber eher als tolle IDE und nicht als Plattform oder Ersatz für .NET. Das muss verbessert werden. Er legt Wert darauf, dass das Ecosystem, alle Leute, die hier gerade sitzen, Teil des Ecosystems sind und jeder einen Beitrag leisten kann.

Sebastian fragt, ob es schwierig ist, Eclipse in Europa großen Unternehmen schmackhaft zu machen. Ralph entwortet, dass es überraschend ist, dass selbst große und konservative Unternehmen wie Airbus teilweise eigene Software open-source machen und sehr aufgeschlossen für open-source sind. Andere Unternehmen hingehen sind völlig anders und fürchten Open-Source als Gefahr und Geld-Verschwendung. Hier möchte er ansetzen und den Unternehmen klarmachen, dass open-source ein Modell für sie sein kann. Er glaubt aber auch, dass dieser Prozess viel Zeit in Anspruch nehmen wird.

Sebastian fragt, ob es in Amerika anders ist. Mike antwortet, dass es in Amerika sehr ähnlich ist. Er führt das noch ein wenig aus und beschreibt einige Stufen, die ich aber nicht so richtig in der Kürze der Zeit aufnehmen konnte. Erschwerend kommt in den USA hinzu, dass einige Firmen Angst haben, Patente zu verlieren. Im Prinzip sieht er das Problem aber ähnlich, wie in Europa.

Aus dem Publikum kommt die Frage, wie man im Eclipse-Kontext mit Problemen umgeht, die nicht im Fokus einer Firma stehen, die Entwickler im Eclipse-Bereich bezahlen. Erich antwortet, dass es ein Dilemma gibt: Produkt-Entwickler haben andere Anforderungen an eine Plattform als die Leute aus der Community, die Innovation wollen. Ein Fokus ist Stabilität, ein andere Fokus ist Innovation. Er berichtet, dass es Überlegungen gibt, diese beiden Seiten getrennt zu bedienen und getrennte Wege für diese unterschiedlichen Ziele zu gehen. Mir wird mal wieder klar, dass diese ganze Rückwarts-Kompatibilität, Published-API-Problematik super super super drückend für das Projekt ist. Wenn es einfacher wäre, neue Produkte einfach auf Breacking-Changes zu migrieren (oder gar automatisch), würde man dem Eclipse-Projekt wirklich helfen und dieses Dilemma lösen. Es gibt inzwischen einfach super viel Legacy-API in Eclipse, aber die Produkt-Entwickler und Firmen fordern, dass diese APIs nicht gebrochen werden. Sehr schwierige Situation.

Die Frage bezieht sich auf die Roadmap und Planungsdokumente von Eclipse. Mike erläutert, dass es einen Unterschied gibt zwischen der Roadmap des gesamten Eclipse-Projektes und dem Projekt-Plan für das Eclipse-Top-Level-Projekt. Und dass diese Dinge, die dort drinstehen, nicht viel mehr als ein Jahr im voraus gehen. Den Rest der Antwort habe ich nicht mehr mitbekommen.

Sebastian fragt nach Eclipse 4 und Erich eräutert, dass es noch sehr früh ist, über Eclipse 4 zu sprechen. Es gibt noch keine konkreten Pläne gibt, sondern man gerade erst anfängt, in einem sehr offenen Prozess die Community zu befragen und einzubeziehen. Also keine echten Infos zu Eclipse 4.

Die nächste Frage zielt auf Patente und IP ab. Mike erläutert, dass Eclipse einen sehr ausführlichen IP-Prozess hat (das habe ich selbst schon auf der EclipseCon erfahren und das Zeug ist wirklich professionell und gut organisiert), aber keine Patent-Checks stattfinden. Die Eclipse-Foundation hält selbst aber kein IP für den Code auf Eclipse. Es gibt niemanden bei Eclipse Foundation, der Patente oder ähnliches für den Code hält.

Sebastian fragt nun, ob es irgendwas für Eclipse Projekte gibt, an dem man den Status eines Projektes ablesen kann. Mike erläutert, dass es eine Übersicht gibt und vor allem den Incubation-Status gibt. Alle Projekte sollten deutlich sichtbar machen, wenn sie in diesem Status ist. Erst danach sollte es das 1.0-Release geben. Ralph ergänzt, dass man zusätzlich eine Übersicht anbietet, auf der man für jedes Projekt sehen kann, wieviele Leute daran arbeiten, wieviele Commits es gibt, wieviele Bugs gemeldet und gefixt werden, etc. Dadurch bekommt man einen Eindruck, wie aktiv ein Projekt ist: http://dash.eclipse.org/.

Nächste Frage: Welche Projekte sind besonders interessant und werden in der Zukunft besonders wichtig werden? Mike sagt, er findet alle Projekte prima, aber er persönlich findet interessant: Mylar, Higgins (er erläutert ein bisschen was über Higgins, aber ich komme nicht mit), Dynamic Languages, AJAX Toolkit Framework. Ralph ergänzt, dass viele sich für Eclipse für Embedded Devices interessieren und das wirklich schon machen. Viele von diesen Firmen implementieren zusätzlich IDEs für die Entwicklung von Software für Embedded Devices und dass diese Firmen einen sehr hohen Bedarf an Entwicklern haben, die ihnen helfen, IDEs oder IDE-Erweiterungen auf Basis von Eclipse zu realisieren.

Die nächste Frage habe ich nicht mitbekommen, meine Konzentration schwindet so langsam...

Sebastian kommt zurück zu Eclipse 4 und fragt, wie man Ideen für Eclipse 4 submitten kann. Mike antwortet, dass es einen Eclipse-4-Blog geben soll, auf dem man die Diskussion dazu verfolgen können soll. Außerdem kann man Bugs schreiben.

Man spricht noch ein wenig über die Größe des Eclipse-Ecosystems und Mike erzählt, dass sie auch viele Projekte wieder dichtmachen. Ein wichtiger Faktor, finde ich. Sonst wird es irgendwann ein riesiger Urwald werden.

Die letzte Frage habe ich nicht mehr mitbekommen, dafür ist die Session jetzt aber vorbei und ich schicke den Eintrag ab. Jetzt brauche ich erstmal ein wenig Entspannung... ;-)

Session: Eclipse Ecosystem

Diese Session ist mehr ein Panel und die kleine Keynote für Eclipse.
Speaker stellen sich vor:

• Mike (Director Eclipse Foundation):
  
• Erster Mitarbeiter der Foundation. Verantwortlicher für die Foundation.
  
• Anmerkung: Alle Sprint-Handys die nächstes Jahr raus kommen müssen OSGi installiert haben
• Erich Gamma (ich glaub ich hab den Namen schon mal gehört):
• Er macht Eclipse und Jazz
• Er vergleicht Eclipse und Jazz mit Rasierklingen: Eclipse sind die Rasierer die man umsonst bekommt. Jazz sind die Rasierklingen die man bezahlt.
  
• Eclipse profitiert durch Jazz.
  
• Mik Kersten (Mylar Lead):
• Stellt Mylar vor: Alle Aktivitäten drehen sich um Tasks die verlinkt sind.
  
• Er hat Plugins für Netbeans, JBuilder etc. geschrieben. Eclipse hat das beste Modell für Module
• Ralph Müller (Director Ecosystem):
  
• Versucht Entwickler/Firmen zu helfen Eclipse zu etablieren
• Stephan Wilczek:
• Consulting und Training zu RCP
  

Interssante Fragen:
Wo kann die Eclipse-Foundation helfen?
Stephan: Mehr Word-spreading. Es gibt zu wenige Leute die sich mit Eclipse auskennen.
Mike: Eclipse Marketing hat ein Budget von 30.000$. Wir als Eclipse Entwickler müssen das wett machen in dem sie über Eclipse als Plattform reden.

Wie geht die Eclipse-Foundation mit neuen Anforderungen
Erich: Dilemma Produkte vs Comunity. Produkte wollen Stabilität und Community will Features. Im Moment ist es sehr schwer neue Änderungen einzubauen, da man viel Legacy-API hat die man nicht ändern will.

Ausblick auf Eclipse 4
Erich: Es gibt viele Ideen, die im Moment gesammelt werden. Noch kann man nichts dazu sagen.
Mike: Es wird einen Blog über Eclipse 4 geben.

Wie bewertet man bestehende Eclipse-Projekte?
http://dash.eclipse.org

Interessante Projekte aus der Sicht von Mike:
Mylar, Groovy-IDE*, ATF (Ajax Tooling),

Was ist Eclipse?
Eclipse is a community. All projects have Equinox as the architectual basis.

*an Stephan: Wieder Groovy.

GWT: Google Web Toolkit

Sie zeigen erstmal zwei Beispiele: Eine E-Mail-Anwendung und eine Bilderverwaltung. Ist alles schnell und reaktiv a la Desktop-Anwendung - AJAX eben.

Verschiedbbare Popup-Dialoge sind möglich. Drag&Drop wird per Default nicht unterstützt. Man kann es aber trotzdem bauen - ist in den Beispielen auch drin.

Jetzt kommen die GWT-Konzepte.

GWT folgt dem "Avant-garde"-Ansatz. Das bedeutet, dass man fast ausschließlich in Java programmiert. Dazu wird der Java-Client-Code nach JavaScript, HTML und CSS "compiliert". (Fragt mich nicht, warum der Ansatz "Avant-garde" heißt.)

GWT stellt eine Reihe von UI-Komponenten bereit und AJAX-Support. Zusätzlich enthält das GWT einen Java-To-JavaScript-Compiler. Für den Client-Code darf man nur JDK 1.4 verwenden und Teile aus java.lang und java.util. Mit der Hosted Mode Shell kann man in Eclipse debuggen.

Jetzt wird ein Hello-World-Beispiel programmiert. Mit der Hosted-Remote-Shell kann man die Anwendung gefakt ausführen. Dann werden die Benutzeraktionen mit Default-JavaScript abgefangen und direkt an die Java-Klasse umgeleitet. So kann man das auch leicht testen und debuggen.

Wie jetzt so eine Java-Klasse aus? Man holt sich ein Element aus dem DOM einer Tenplate-Seite und fügt dort UI-Komponenten ein (RootPanel.get("xxx").add(button)). An den Elementen registriert man Listener a la Swing. Wenn man mehrere Elemente hinzufügen will, braucht man Layout-Manager, die sehr an Swing erinnern. Da scheint mir ein Bruch zu sein, weil man das Layout eigentlich ja über CSS machen will.

Sieht ja soweit ganz einfach aus. GWT scheint einiges an Abstraktion über HTML/HTTP zu legen, ähnlich JSF. Wie viele Probleme das in der Praxis macht, ist eine interessante Frage.

Zum Thema Browser: Das GWT verbirgt die Browser-Inkompatibilitäten.

Jetzt werden die Elemente des GWT vorgestellt. Neben den Standards gibt es Menüs, Tabs, Trees, Popup-Dialoage. Eigenes Widgets kann man in Java selbst erstellen.

Der Aufruf vom Client an den Server wird als Remote-Procedure-Call angeboten. Nachrichten werden im JSON-Format und nicht als XML verschickt. Man muss ein Subinterface von RemoteService definieren, dass der Client aufrufen muss. Und dann muss man ein eigenes Servlet als Subklasse eines GWT-Servlets bauen. Die Folie ist zu schnell weg, so dass mir nicht ganz klar ist, wie das Servlet aussehen muss.

Auf Basis des Interfaces erzeugt GWT einen Proxy, der dann an das Servlet delegiert. Sieht dem EJB-Konzept ähnlich.

Wenn man selbstdefinierte Klassen an der RPC-Schnittstelle verwenden will, müssen die nach JSON serialisierbar sein. Dazu muss man wohl nur ein spezielles Marker(?)-Interface implementieren.

Dummerweise ist AJAX asynchron und das schlägt bis auf das RPC-Interface durch.

Mit JSNI (JavaScript Native Interface) kann man Client-Java mit JavaScript integrieren. So kann man z.B. reine Web-Widget-Libs von Drittherstellern verwenden.

Es gibt natürlich eine Integration mit Spring. Dazu braucht man die GWT Widget Library. Deren Verwendung ist dringend empfohlen, auch weil das GWT doch nicht alle Eigenartigkeiten des IE verbirgt. Das holt das GWT Web Toolkit nach.

Fazit der Referenten:
* Man muss keien JavaScript programmieren. JavaScript ist so mächtig und flexibel, dass viele Entwickler überfordert sein werden.
* Browser-Eigenheiten werden eingekapselt.
* Man könnte auch AJAX-Frameworks a la Dojo oder Prototype verwenden. Das ist ein eigenes Look&Feel angeblich schwer zu bauen.
* DWR (Dynamic Web Remoting) wäre noch eine Alternative. Dort programmiert man den Client in JavaScript und den Server in Java.
* OpenLaszlo ist sehr mächtig, aber man braucht ein Flash-Plugin.
* XUL geht auch nur, wenn der Browser XUL unterstützt.
* GWT funktioniert bei einfachen Sachen ganz einfach. Man muss aber doch viele Eigenheiten des GWT erst erlernen.
* GWT kapselt die Browser-Eigentheiten bzgl. JavaScript weg, aber nicht bzgl. Rendering und CSS.
* Google verwendet GWT bisher gar nicht selbst. ("Google doesn't eat its own dog food!")
* Java 5 geht in GWT (noch) nicht, so dass man für Client- und Server-Java doch wieder unterschiedliche Compiler und Sprachfeatures hat.
* Es gibt in GWT kein MVC-Framework. Da muss man sich selbst was ausdenken.
* Es gibt viele Widgets. Die gehen deutlich über HTML-Forms hinaus, kommen aber nicht ganz an andere Web-Widget-Libs heran.
* GWT ist natürlich Open-Source.
* Es gibt eine große GWT-Community und gute Doku.
* Bei einfachen Web-Anwendungen sollte man GWT nicht verwenden. GWT ist nur interessant, wenn man Desktop-artige Software braucht.

Java-To-JavaScript-Compiler wirkt auf mich wie Rocket-Science. Das ist beeindruckend und auch ein wenig unheimlich. Wenn da mal was nicht funktioniert...

P.S.: Die Referenten haben irgendein cooles Tool, mit dem man Markierungen auf den Bildschirm malen kann - und das unter Windows! Das ist nützlich, wenn man was außerhalb von Powerpoint zeigen will - z.B. Code in Eclipse.

P.P.S.: Wenn man mit dem eigentlichen Inhalt des Vortrags fertig ist, ist nicht der geeignete Zeitpunkt, um seine Firma vorzustellen. Dann gehen die Leute nämlich raus :-)

Flashfilm "Die agile Chance" ist online

Henning hat seinen Vortrag "Die agile Chance für Kunden" als Screencast aufgezeichnet und einen Flash-Film daraus gemacht. Der Film ist hier zu sehen.

Johannes Link, Marco Klemm: Testgetriebenes AJAX

Wie geht man testgetrieben vor, wenn man AJAX einsetzen will oder muss?

Eine Möglichkeit, JavaScript zu testen ist GWT: GWT übersetzt Java-Code nach Java-Script. Dann muss man nur den Java-Code testen.

Rhino als JavaScript-Engine kann helfen, ohne Browser zu testen.

JsTester erlaubt das JavaScript-Testen mit der Rhino-Engine ohne Browser. JsTester ist in JUnit integriert.

Scriptaculous ist ein Test-Framework, das die Tests im Browser ausführt. So kann man direkt auch die Browser-Unterschiede adressieren. Die Automatisierung ist über Rake (so eine Art Ruby-Ant) möglich. Auf jeden Fall ist die Automatisierung von Test-Suiten, z.B. im Continuous-Build, nicht ganz einfach.

Mit Scriptaculous schreibt man den Unit-Test als Java-Script-Code mit in die Web-Seite. Der Test sieht dann JUnit sehr ähnlich.

JsMock ist ein Mock-Framework für JavaScript. JsMock ist Easy-Mock sehr ähnlich.

Jetzt kommen Kunden-/Akzeptanztests. Selenium erlaubt das "Fernsteuern" des Browsers. Die Art und Weise, wie man die Tests aufschreibt, sieht der ActionFixture aus FIT sehr ähnlich.

Mit Canoo-WebTest ist was Ähnliches möglich. Neuerdings kann man WebTest auch mit Groovy einsetzen. (Ich bin jetzt insgesamt im vierten Vortrag und in allen vier Vorträgen kam Groovy vor.)

Aha, jetzt kommen auch FIT und Fitnesse, wo man die Tests in HTML-Tabellen beschreibt.

Jetzt kommt die Demo "Party Locator" mit Google-Maps-Meshup. Der Test wird mit Scriptaculous geschrieben. Der Test nutzt Mocks für den Google-Maps-Zugriff. Dafür braucht man erstmal gar kein Framework, weil man in Java-Script Objekte immer ganz einfach ersetzen kann - weil JavaScript Prototype-basiert ist. Der Test sieht entsprechend elegant aus.

Wie testet man asynchroner Code?
Variante 1: Man schaltet die Asyhchronität für den Test aus, mit der Hilfe von Mocks.
Variante 2: Die Testframeworks kennen immer nur den Hauptthread. Man kann also im Unittest Asynchronität testen. Also testet man die Asynchronität mit Akzeptanztests.

Ajax-Aufrufe testet man natürlich auch mit Mocks.

Der Akzeptanztest ist mit FIT formuliert. Die Fixtures steuern den Browser direkt mit Selenium an. Sieht alles sehr cool aus.

Was ich noch nicht kannte, ist dass man in den FIT-Tests am Anfang globale Imports machen kann. Dann hat man es einfacher und übersichtlicher, wenn man am Anfang der HTML-Tabellen die Fixture-Klasse benennt.

Die FIT-Tests schreibt man i.d.R. mit Word - insbesondere wenn die Kunden die Tests schreiben oder ändern. Fitnesse ist auch lustig, aber i.d.R. ungeeignet, wenn der Kunde auch Tests schreiben oder ändern soll.

Debugging im Browser macht man heute mit Firebug für Firefox. Für andere Browser gibt es ähnliche Lösungen, die aber nicht ganz so gut sind.

Fazit: Unit- und Akzeptanztests und testgetriebenes Vorgehen funkioniert auch mit JavaScript und AJAX. Natürlich muss man weiter auch manuell testen, um z.B. die Darstellung zu prüfen.

Zitat aus der Eröffnungsrede: "Niemand von uns will JavaScript programmieren müssen." Der Vortrag von Johannes und Marco zeichnet ein anderes Bild. Die Code-Beispiele sehen nicht weiter schlimm aus. Als Programmiersprache ist JavaScript nämlich eigentlich gar nicht schlecht.

Session: NetBeans: Open Source Java IDE and More

Ein Sun-Evangelist versucht uns von Netbeans zu überzeugen. Netbeans ist nicht nur eine IDE, sondern auch ne Plattform. Vorteile: Modulare Anwendung und Wiederverwendung.
Netbeans als IDE:
OpenSource, verschiedene Plattformen, verschiedene Sprachen.
Demo: GUI-Builder mit GroupLayout und Matisse, Guide-Lines zum positionieren von Elementen. Macht einen guten Eindruck, auch bei kleineren Problemen Ja, aber: Kein Sourcecode editing und die GUI wird in XML gebaut.
Demo: Integrierter Profiler. Demo: Webservice. - Nett.
//Während die verschiedene Server hochfahren, stellt er Fragen und verteilt er T-Shirts.
Verschiedene Demos für Handys.

Viele Ideen für Änderungen scheinen von Eclipse zu kommen. Beispiel: In Zukunft soll es einfacher sein andere Sprachen einzubinden.
Meine Frage nach der Netbeans-Plattform wurde auf heute nachmittag verwiesen. Dhooo. Warum war ich hier?
Zusammenfassung: Netbeans kann man sich mal anschauen, muss man aber nicht.

Matthias JAX Track - Montag

Folgende Sessions scheinen interessant. Leider kann ich nicht bei allen dabei sein.

10:00-11:15 Uhr
NetBeans: Open Source Java IDE and More
Roman Strobl Sun Microsystems
Saal 12d
http://jax.de/konferenzen/etage07/sessions_popup.php?id=5728

11:45-13:00 Uhr
Architekturen mit Spring
Eberhard Wolff Interface21 Germany
Halle 1
http://jax.de/konferenzen/etage07/sessions_popup.php?id=4830

The Eclipse Way - Part 1: The Eclipse Way explained
Tobias Widmer IBM Rational Research Lab Zurich
Martin Lippert akquinet agile GmbH
Saal 1Aa
http://jax.de/konferenzen/etage07/sessions_popup.php?id=4714

14:15-15:30 Uhr
Architekturmanagement am Beispiel des Spring-Framework-Projektes
Jürgen Höller Interface21
Halle 1
http://jax.de/konferenzen/etage07/sessions_popup.php?id=5026

General Session: Quo Vadis Eclipse Eco System
Sebastian Meyen Software & Support Verlag
Mike Milinkovich Eclipse Foundation, Inc.
Mik Kersten University of British Columbia
Erich Gamma IBM OTI Labs, Zürich
Saal 12bc
http://jax.de/konferenzen/etage07/sessions_popup.php?id=5467

17:00-18:15 Uhr
Simplifying Enterprise Applications with AOP and Spring 2.0
Rod Johnson Interface21
Saal 11b
http://jax.de/konferenzen/etage07/sessions_popup.php?id=5187

Keynote von Tim Boudreau (SUN): Using the Right Tool for the Job

Tim erzählt über die Geschichte von Programmiersprachen und geht auf das Problem ein, dass wir immer strukturiere Daten brauchen. Natürlich seien aber unstrukturierte Daten. Seiner Meinung nach wäre das nächste große Ding der Umgang mit unstrukturierten Daten.

Und dann sind wir bei NetBeans (wie der Übergang zustande gekommen ist, habe ich verpasst).

Man soll sich den aktuellen Milestone 6 von NetBeans ansehen. Dort wird nicht nur Java unterstützt, sondern z.B. auch JRuby und Rails. Er zeigt eine kurze Demo, in der er Code-Completion und einfache Refactorings für Ruby zeigt. Sieht cool aus.

Die Spring-Vorträge...

...hat Eberhard Wolff in seinem Blog beschrieben:

Eröffnungsrede

Zwei Thesen aus der Eröffnungsrede sind interessant:
1. Java hat von den Script-Sprachen a la Ruby on Rails nichts zu befürchten. Die hätten einfach noch nicht verstanden, wie schwer Anwendungsentwicklung wirklich ist.
2. Java ist im Web 2.0-Bereich ganz vorne mit dabei.

Ich weiß nicht so recht...

Besuch im Hotel

Heute morgen hatte ich im Hotel überraschenden Besuch im Bad. Es war eine SIE. Sie war vollkommen nackt. Sie war ca. 5 cm groß und hatte 6 Beine. Die genaue Gattung konnte ich nicht erkennen, weil sie sich schnell hinter dem Heizkörper versteckt hat.

Panel-Diskussion zum Agility-Day

Als Abschluss des JAX-Agility-Day findet eine Panel-Diskussion statt. Im Panel sitzen im wesentlichen die Vortragenden des Agility-Day.

Die erste Frage betrifft die Frage, wie ein Product-Backlog aussieht. Das ist natürlich je Projekt sehr unterschiedlich. Eine Variante ist, mit einem Prosa-Text der Anforderung in FIT/Fitnesse zu beginnen und daraus schrittweise Akzeptanztests zu machen. Die FIT-Tests und die Features im Issue-Tracker werden wechselseitig über URLs verlinkt.

Danach geht es um Stressfaktoren und die Frage, ob agiles Vorgehen mehr Stress schafft als klassisches Vorgehen. Jens Coldeway vertritt die These, dass agile Methoden erstmal mehr Transparenz bringen. Das kann im Einzelfall zu Stress führen. Dann müsste man aber gucken, wie man besser mit der Transparenz umgehen kann.

Dann kommt eine Frage nach Entwurf. Dem Frager erscheint der Entwurf nur entlang von Features wird als sehr gefährlich. Was ist dann mit der Infrastruktur? Die Antwort von Henning Wolf lautet, dass man eben anders mit Entwurf umgehen muss. "Inkrementeller Entwurf" und "testgetriebene Entwicklung" sind die Schlüsselwörter. Jens Coldeway sagt, er habe gut entkoppelte Systeme nur dort gesehen, wo man testgetrieben vorgegangen ist. Sich am Anfang sehr viele Gedanken über Architektur und Entwurf zu machen, führt zu Overdesign und damit unnötig hohen Kosten.

Aus dem Publikum wird nachgehekt: Was ist mit sehr großen Projekten (mehrere 100 Entwickler), die am Rande des Machbaren stattfinden? Antwort aus dem Panel: Prototypen, Spikes, Machbarkeitsstudien können natürlich auch in agilen Projekten stattfinden. Wichtig sei aber, dass man die Spikes möglichst an Business Features koppelt. Jutta Eckstein beginnt häufig mit einem Release 0, dass maximal 3 Monate dauert. In diesem Release 0 werden Architektur und Technologien anhand von Prototypen evaluiert. Nach Release 0 wird auf jeden Fall mit Produktiv-Releases weitergemacht, auch wenn die Entwickler eine Verlängerung des Release 0 wünschen.

Jetzt wird gefragt, ob der Overhead für Standup-Meetings, Release- und Iterationsplanung und Release-/Iterationsreviews nicht zu hoch sei. Das Panel meint, dass dieser Planungsaufwand eher unter dem Planungsaufwand im Wasserfall liegt. Bei den agilen Methoden wird der Aufwand nur explizit.

Passen denn agile Methoden zu CMMI etc., wird gefragt. Jens Coldeway sagt, die offizielle Stellungnahme von Watts Humphrey sei, dass XP auf CMM-Level-3 steht. Jutta meint provokant, dass mit Retrospektiven die agilen Methoden sogar auf Level 5 stehe :-) Insgesamt hält sich die Begeisterzung der Panel-Teilnehmer für CMMI etc. sehr in Grenzen. Jens Coldeway möchte sich eher am Geschäftswert orientieren als definierten Prozessen hart zu folgen.

Es wird gefragt, wie Teams untereinander "Verträge" schließen können, was die Schnittstellen und Protokollen zwischen ihren Systemteilen angeht. Jens Coldeway hat gute Erfahrungen gemacht mit ausführbaren Spezifikationen (Unittests mit Mocks).

Dann wird gefragt, wie man Teams synchronisiert. Wenn ein Team besonders schnell ist, sind die früher fertig als die anderen Teams. Daher planen agile Projekte immer grob eine zweite Iteration in die Zukunft. Wenn das Team sehr schnell ist, kann es mit den Folgefeatures weitermachen. Diese Doppelplanung verhindert auch, dass die Entwickler übrig gebliebene Zeit für rein technische Geschichten verwenden.

Was macht man, wenn der Kunde sich nicht so stark engagieren will oder kann, wie gefordert - der Kunde kann z.B. nur 2 Tage pro Monat ins Projekt investieren? Dann muss man die Kundenrolle substituieren, z.B. indem der Softwarelieferant einen "virtuellen" Kunden bei sich definiert. Das ist suboptimal, kann aber funktionieren. Man muss sich aber auch die Frage stellen, ob der Kunde seiner Aufgabe überhaupt sinnvoll nachkommen kann und ob man das Projekt nicht lieber ablehnen sollte.

AgileDay: Agile Softwareentwicklung in großen Projekten - Jutta Eckstein

Jutta versteht unter großen Projekten Projekte ab ca. 30 Entwicklern.

Agiles Manifest, Agilität ist ein Wertesystem, untermauert durch Prinzipien.

Die Folien sind übrigens englisch, aber das dürfte kaum jemandem was ausmachen.

Teams nicht nach Standorten schneiden oder anhand technischer Kriterien oder Rollen (Tester, Analysten, Entwickler), sondern anhand Features schneiden.

Bei großen Projekten gibt es nicht den einen Kunden/Anwender, man arbeitet oft für eine anonyme Kundengruppe, aber schwierig ist es, wenn die unterschiedliche Ziele und Vorstellungen haben. Oft gibt es eben nicht den einen Repräsentanten. Deshalb: "Customer on-site office", wo die (Akzeptanz-)Tests erstellt und durchgeführt werden.

Der Product Owner soll die Kundenentscheidungen treffen und Feedback liefern, meist sind das aber eben bei großen Projekten mehrere Product Owner, die dann unterschiedliche fachliche Teams betreuen, ggf. auch nur eins je Product Owner.


Entwicklungszyklen: Eigentlich sollte man gerade bei großen Teams auch keine längeren Entwicklungszyklen haben, weil das Risiko der Fehlentwicklung viel teurer ist (absolut). Zwei-Wochen-Iterationen sind immer möglich.
Erfahrungswert: 3 Iterationen braucht ein Team, damit der Zyklus eingespielt ist.
Erfahrungswert: Teams schätzen erst nach 5 Iterationen realistisch.
Verteilte Teams sollten den selben Zyklus/Herzschlag haben.

Jedes Teilprojekt/Teilteam plant für sich, dann müssen sich aber ggf. mehrere Product Owner sich gut abstimmen. Möglichst persönliche Treffen.

Iterationen sollten in der Mitte der Woche starten, damit das Iterationsende nicht über das Wochenende verlängert wird.


Iterationstracking mit Informative Workspaces und Karten, die Zustände durchlaufen, sind gut. Toolempfehlungen: Trac, XPlanner

Tägliche Synchronisation der Beteiligten innerhalb der Teams per Standup. Verteilt und mit vielen Teams schwierig: Scrum of Scrum oder Telefon. An Timebox 10-15 Minuten halten. Ggf. dann Wiki-Einträge, weil nicht alle immer da sind, ggf. beachten, dass verschiedene Sprachen der Teams zum Einsatz kommen.

Erfahrungswert: 10% Aufwand für Builds spendieren, jemanden verantwortlich machen dafür.

Retrospektiven: Sehr wichtig, agiler Kern. Bei großen Teams ähnlich Scrum of Scrums organisieren.

Veränderungen begrüßen: Veränderungen/Change Requests bedeuten, dass der Kunde was dazugelernt hat. Aber umsonst gibt es das trotzdem nicht.

Homogene Entwicklungskulturen: Spielregeln etc. im Wiki notieren, von den Teams ergänzt.

Zusammenfassung:

• Kommunikation ist in großen Projekten noch wichtiger.
• Häufiges Abstimmen hilft. Ggf. muss man reisen.
• Häufiges und regelmäßiges Feedback mit kurzen Zyklen.
• Teams nach Features schneiden.
  

TDD für Fortgeschrittene - Teil 3: Legacy-Code, UIs, Web, MVP, Groovy

Nach dem Mittagessen kommt Testabdeckung dran. Für Eclipse ist ECLEMMA ein neues Plugin, dass nett aussieht - vor allem die direkte Integration in Eclipse. Dann zeigt Tammo die Testabdeckung für sein Easy-Mock und sagt: "Das ist Posing. Die Testabdeckung sagt gar nichts aus." Schließlich zeigt die Testabdeckung nur an, dass der Code durchlaufen wurde. Ob überhaupt irgendwas getestet wurde, ist nicht erkennbar. Allenfalls gibt Testabdeckung also eine Aussage darüber, was auf jeden Fall nicht getestet wurde - die nicht durchlaufenden Anweisungen. Etwas mehr kann man ableiten, wenn man Jester verwendet.

Die Frage nach dem Umgang mit Legacy-Code adressiert Tammo noch explizit. Michael Feathers sagt: "Legacy-Code ist Code, für den es keine automatisierten Tests gibt." (aus "Working Effectivly with Legacy Code"). Daraus folgt für die Wartbarkeit: "Lieber schlechten Code mit guten Tests als guten Code ohne Tests." Für die nchträgliche Ausstattung von Code mit Tests bieten sich verschiedene Ansatzpunkte:

• beim Hinzufügen neuer Features


• beim Entfernen von Bugs


• bei Designverbesserungen / Refactorings


• beim Optimieren

Dann muss man immer mind. ein Teil der Programmierung machen, ohne Unittests als Sicherheitsnetz zu haben. Dann eignen sich Akzeptanz- und Integrationstests (z.B. mit FIT). Diese grobgranularen Tests lassen sich relativ einfach für existierenden Code erstellen.

Ein weiterer Ansatzpunkt für das nachträgliche Tests ist aspektorientierte Programmierung (AOP). Dann kann man z.B. nach Ende einer Methode automatisch Werte zu testen. Das hört sich interessant an. Allerdings habe ich bisher noch keinen Fall gesehen, wo das viel genützt hätte. AOP wäre immer nur eine Notlösung, weil der Entwurf unverändert schlecht testbar bleibt.

Dann programmieren Tammo und ich am Beamer etwas vor: Ungetester Code soll erweitert werden. Das ist auch deshalb interessant, weil Tammo den Beispielcode auch nicht kennt. Wir brauchen ca. 30 Minuten, um an einer Stelle eine Entkopplung von der Datenbank herzustellen. Da kommt die Frage auf, ob sich der Aufwand überhaupt lohnt. Tammo antwortet: "Ich warte immer noch auf das Projekt, das von sich sagt, dass zuviel in Qualität und Tests investiert wird. Ein Testproblem ist auch immer ein Entwurfsproblem." Also wird der Aufwand nicht nur für den Test investiert, sondern auch in den Entwurf. Daher wird sich der Aufwand i.d.R. lohnen. Er gibt dann auch die Empfehlung, das Testen und Refaktorisieren in die Entwicklung zu integrieren. Dann "versteckt" man die Aufwände und muss sich nicht dafür rechtfertigen, dass man testet.

Für den Entwurf und das Testen von Anwendungen mit Benutzungsoberflächen stellt Tammo das Model-View-Presenter-Muster (MVP) vor. Beispiel: Es gibt einen BookSearchDialog, der Books sucht.

interface BookSearchView {
  void displayBooks(List books); 
}

interfaces BookSearchPresenter {
  void searchBooks(String name);
}

class BookSearchDialog implements BookSearchView {
  // kennt BookSearchPresenter
}

BookSearchFacade implements BookSearchPresenter {
  // kennt BookSearchView 
}

Der Benutzer tippt den Buchnamen im BookSearchDialog ein und drückt dort auf "Search". Daraufhin ruft der BookSearchDialog am BookSearchPresenter die searchBooks-Methode auf. Diese sucht die passenden Bücher. Das Suchergebnis liefert die searchBooks-Methode nicht direkt zurück, sondern injiziert das Ergebnis in die displayBooks-Methode des BookSearchViews. Der Effekt ist jetzt, dass man den BookSearchDialog testen kann, indem man BookSearchPresenter wegmockt. Und man kann BookSearchFacade testen, indem man den BookSearchView wegmockt.

Das MVP-Muster wirkt auf mich erstmal gewöhnungsbedürftig. Dass man das Zeug gut testen kann, ist allerdings auch ein gewichtiges Argument. Außerdem adressiert das MVP-Muster möglicherweise ein Problem, dass häufig anzutreffen ist: Es gibt vielfältige ungetestete Methoden in den UI-Klassen, die Daten konvertieren. Das MVP-Muster kann dem entgegen wirken, weil die Transformationen in der BookSearchFacade durchgeführt werden. Und nicht zuletzt könnte es Entwürfe nach Quasar sauberer machen. Häufig sind in Quasar-Anwendungen alle UI-Komponenten R-Komponenten und damit "schmutzig". Die Dialog- und View-Klassen nach dem MVP-Muster könnten reine T-Komponenten sein.

Jetzt kommt Groovy dran. Tammo gibt eine Kurzeinführung in Groovy und es gibt eine Diskussion über den Nutzen von Closures. ("Ist Groovy eine Art Java für schreibfaule Entwickler.") Dann werden die Vorteile klarer und ein Teilnehmer stellt die Frage, ob Groovy das kommende Java sei. Wer weiß :-)

Tammo zeigt, wie man sich durch Tests mit Groovy auf Mock-Frameworks vezichten kann. Closures reichen häufig vollkommen aus.

Und dann habe ich ein neues Schlagwort von Tammo gelernt: "Hippie-Completion" bezeichnet die semantikfreie Auto-Completion im IDE. Typischweise guckt der Editor dann nur, ob es gleich beginnende Wörte in der Datei gibt. Diese Art der Completion ist insbesondere bei dynamischen Sprachen wie Groovy sinnvoll.

agile Methoden in Projekten im Großrechner-Umfeld - Dr. Jan Mütter

Herr Dr. Mütter ist vom Landesamt für Datenverarbeitung und Statistik aus NRW.

Großrechnerumfeld.

On-Site Customer als Bringer, nachdem man dicht zusammengezogen ist. (Davor ging es gar nicht.)

Planning Game ging gut incl. Priorisierung, dabei vor allem dann gut, wenn zwischen Requirementsengineering und Build und Funktionstest liegen!

Weekly Test: Bringt viel, weil wöchentliches Build von echten Anwendern getestet wird.

Refactoring konsequent eingesetzt (war auch wegen der neuen Anforderungen nötig).

Änderungsmanagement: Toolgestützte Änderungsverfolgung, insg. ca. 2.500 Änderungen. Extra-Planungsrunde, um das zu priorisieren.

Pair-Programming: Hat bei denen keiner mehr Bock drauf. (Anmerkung von mir: Erstaunlich, dass doch so viele was gegen Pair-Programming haben...)

Fazit:
Warum nicht auch im Großrechnerbereich agil?
Teamgröße schwieriger, weil 70 Projektmitarbeiter. (Dann eben auch die Frage: Wer spricht mit wem, welche Regeln gelten für die Kommunikation?)



Mein Fazit: Netter Vortrag. Schon interessant, insgesamt scheinen sich zu Recht heute viele Leute einfach in den agilen Methodenbaukästen zu bedienen, ohne konsequent einer und stur einer Methode zu folgen. Entscheidend ist dabei wohl, dass immer gelernt wird und man für sich funktionierende Lösungen (Prozesslösungen!) findet!

AgileDay: Rund 250 Teilnehmer

nur mal so zur Info, der Raum des AgileDay ist ordentlich gefüllt. Rund 250 Teilnehmer.
Das Interesse an Agilität ist nach wie vor groß (und ist vielleicht sogar noch gestiegen)!

AgileDay: XP pragmatisch - Böhme und Müller-Rohde

Dirk Böhme, DBV winterthur (Entwicklungsleiter)
Martin Müller Rohde, Scoop Software GmbH (GF)

Neues Java-System für Krankenversicherung ab 2002, dabei XP eingesetzt(wegen graphischer Frontends, neuer Produkte wie DMS einzubinden, Java-Programmierer besser verfügbar).

Der Vortrag ist grafisch schön gestaltet, enthält viele Bilder und veranschaulicht, welche Probleme so auftauchen, wenn man in einer Organisation wie einer Versicherung XP einführen will.
(U.a. lustige Visualisierung, welchen Typ Projektleiter man gerne hätte: Von Stromberg über Indiana Jones zu James Bond)

XP wurde nicht an die große Glocke gehängt, sondern eben einfach angewendet.
(Und dabei das Management wie gehabt mit Krawatten, Ampeln, Statusberichten und Businessplänen befriedigen.)


Eingesetzt: Unit-Testen, Nightly Builds(mit "Night-Build-Master" als Rolle), Standups (aber nachgelassen, nicht mehr), Planung mit Karten (auch an der Wand, aber aktuell nicht mehr in der Wartungsphase), Pair-Programming (anfangs, aber die wollten nicht, was die Vortragenden verteidigen, ist ja auch egal, woran auch immer es wirklich gelegen hat), On-Site-Customer als ganz wichtigen Erfolgsfaktor (aber man muss nah beieinander sitzen!)

Grund für die ganzen eingeschlafenen Sachen: Jetzt in Wartung, nicht mehr kritisch, sowieso schon erfolgreich und die Disziplin schient zu anstrengend! (außerdem ist der XP-Coach weg)

Das Fazit war: Der Prozess ist uns eigentlich egal, Hauptsache es funktioniert. Aber war es vielleicht nur Glück, dass es geklappt hat?

TDD für Fortgeschrittene - Teil 2: Unittests mit Mocks

Tammo kommt beim Thema Unittests sehr schnell zu Testen mit Mocks und stellt EasyMock vor. Mit Java 5 ist Easy-Mock nochmal ein ganzes Stück eleganter als mit JDK 1.4. Jetzt sollen die Teilnehmer das Taschenrechner-Beispiel mit Unittests programmieren. Die Teilnehmer können entweder neu beginnen oder ihren bereits erstellten Code refaktorisieren.

Tammo zitiert Frank Westphal mit einem ebenso einfachen wie nützlichen Ausspruch: "Jedes Test-Problem lässt sich durch eine zusätzliche Indirektion lösen." Tatsächlich führen z.B. Mock-Tests häufig dazu, dass man Factories einführen. Die Annahme der testgetriebenen Entwicklung ist dabei stets, dass die so entstehenden Strukturen auch für den Produktionscode einen guten Entwurf darstellen.

Die Diskussionen zwischendurch kreisen immer wieder auch um die Frage, wie man mit existierendem Code umgehen kann. Meine persönliche Meinung dazu ist, dass es häufig nicht sinnvoll ist, Unit-Tests auf existierenden Code aufzusetzen. Das wird zu aufwendig. Dann verlieren die Entwickler die Lusts am Testen und werden es auch nicht mehr richtig tun. Sinnvoller ist es, Akzeptanztests für den existierenden Code zu schreiben und die Unit-Tests schrittweise zusammen mit dem Refaktorisieren des existierenden Codes einzuführen.

AgileDay: Scrum: Fallstricke in der Implementierung - Jiri Lundak

Jiri trägt aus der Praxis vor. Der Hintergrund ist Softwareentwicklung für die schweizerische Sozialversicherung.
Früher war dort alles sehr klassisch. Vor 3 Jahren mit Scrum begonnen.

Prolog: Kurze Scrum-Vorstellung.

Episoden:
Gefährliche Degenerationen:

• Sprints werden verlängert
• Sprints liefern nichts aus
• 6-Wochen-Aufgaben für einzelne Entwickler
• Features werden zu früh fertig gemeldet, sind aber ungetestet
  

Teilweise wird stur dem Scrum-Prozess gefolgt, ggf. sogar ein Scrum-Handbuch gefordert und Scrum klappt nicht trotz Durchführung aller Praktiken:
--> es kommt halt auch auf das Verstehen der Ideen dahinter an!

Aufpassen, dass durch das Hierarchiedenken nicht der Scrum-Master zum Projektleiter wird. (O-Ton mancher Entwickler: "Verantwortung ist nicht teilbar.")

Aufpassen beim Aufteilen der Entwicklungsaufgaben: Eigentlich alles lässt sich in kleine Teile aufteilen. Aber auch die Zuordnung auf Entwickler sollte so laufen, dass die Kommunikation noch Sinn macht und nicht jeder seine Insel hat.

Psychologiehürden gegen Veränderung bei der Einführung von Scrum: Bequemlichkeit, Ängste etc.

Generell berichtet Juri viel von den Schwierigkeiten der Einführung von Scrum, vor allem, weil viele nicht verstehen, warum sie etwas ändern sollten oder eben nicht wollen.

Epilog:
Scrum ist ein Verbesserungsprozess, kein Softwareentwicklungsprozess!
Aber durch die Transparenz und das Feedback hat man große Chancen.

Großer Andrang beim RCP-Workshop

Auf dem heutigen RCP-Workshop war der Andrang so groß, dass wir in einen größeren Raum umziehen mussten. Ganze 5 erfahrene RCP-Entwickler haben die Workshop gestaltet und so konnten Fragen jederzeit ad hoc beantwortet werden und alle Probleme konnten sofort behoben werden. Folgende Themen wurden besprochen:
- Einleitung / RCP Begriffe
- Eclipse Helloworld / Eigene Workbench
- Views / JFace
- Eigener Extension-Point
- Mehrere Plugins
- Product
- Update


Vielen Dank an Ben, Bernd, Tobias und Stefan für den netten Workshop.
Der Source der Beispiele folgt später.
Auf Flickr finden sich noch mehr Bilder des Workshops.

Der Spring-Day hat begonnen

Ich sitze heute im Spring-Day auf der JAX. Zu Beginn hat Eberhard Wolff eine kurze Einführung gegeben, was heute alles auf dem Spring-Day vorgtragen wird und in welche Richtung die Spring-Entwicklung so geht. Er legt einen Schwerpunkt auf die Kombination von Spring und der OSGi-Technologie und verweist gleich mehrfach auf den Vortrag, den ich zusammen mit Gerd Wütherich und Bernd Kolb halte. Das legt die Meßlatte hoch, das Publikum erwartet jetzt mehr als nur mal ein paar nette Worte... :-) Außerdem wird mir mal wieder klar, dass es viele kleine Spring-Sub-Projekte gibt, die fertige Implementationen für diverse Technologien liefern, echt nett.

Anschließend erläutert Jürgen Höller, was sich in Spring 2.1 tun wird. Er erzählt viel über neue Features und kann irgendwie erstaunlich gut eine Balance halten zwischen möglichst viele neue Features und Eigenschaften zu präsentieren und trotzdem nicht oberflächlich zu werden. Beeindruckend. Schlussendlich sind aber keine bahnbrechenden Neuerungen zu erwarten, stattdessen viele Detail-Verbesserungen.

Nun sind wir dran, ich fange an und versuche das Publikum für OSGi zu begeistern und erzähle, was es damit auf sich hat. Gerd zeigt anschließend ein nettes ein Beispiel und Bernd beendet den Vortrag mit einem kleinen Ausblick auf verschiedene Modelle, die Kombination von Spring und OSGi im Web-Kontext zu verwenden. Das geht ja mit der aktuellen Implementation von Spring-OSGi noch nicht, aber in der nächsten Meilenstein-Version wird da sicherlich Support drin sein. Ich bin gespannt.

TDD für Fortgeschrittene - Teil 1: Motivation und Akzeptanztests

Der ganztägige Power-Workshop zum fortgeschrittenen Testen wird von Johannes Link und Tammo Freese organisiert. So steht es zumindest in der Ankündigung. Johannes ist aber krank. Also unterstütze ich Tammo bei der Betreuung der Übungen - so gut es eben ohne Vorbereitung und Kenntnis der Folien geht. Die Konferenzleitung hat 75 Teilnehmer geschätzt. Das passt auch ungefähr zur tatsächlichen Teilnehmerzahl.

Tammo beginnt mit der Motivation für Testen: Qualität der internen Struktur erhalten. Bei der testgetriebenen Entwicklung wird erst der Test geschrieben und dann der Produktivcode, der den Test erfüllt. Die Automatisierung der Tests stellt sicher, dass man die Tests mit wenig Aufwand immer wieder ausführen kann. So kann sichergestellt werden, dass bei der Weiterentwicklung des Systems keine unerwünschten Seiteneffekte auftreten. (Refactoring spielt natürlich auch eine wichtige Rolle beim testgetriebenen Vorgehen.)

Tammo unterscheidet zwischen Unittests, die Entwickler schreiben und Akzeptanztests, die Kunden schreiben. Beide Testarten müssen automatisiert werden. Die Akzeptanztests müssen am Anfang i.d.R. von den Entwicklern geschrieben werden. Schrittweise versuchen die Entwickler dann, die Kunden immer stärker einzubeziehen, so dass die Kunden die Tests schließlich selbst schreiben.

Unittests werden mit JUnit (für Java) und die Akzeptanztests mit FIT erstellt. Bei FIT werden die Tests als HTML-Tabellen beschrieben. Die Tabellen kann man in einem Wiki erstellen. Die meisten Kunden bevorzugen aber Word. Neben Java unterstützt FIT eine Reihe weiterer Programmiersprachen.

Jetzt geht Tammo genauer auf Akzeptanztests mit FIT ein. Er stellt die Column-Fixture, die Action-Fixture und die Row-Fixture vor. Column-Fixtures definieren eine Reihe von Eingabewerten, rufen eine Systemfunktion auf und prüfen, ob der Rückgabewert stimmt. Action-Fxutures verfolgen einen eher einen Flow-Ansatz: Man füllt mit Einzelbefehlen Felder, startet Systemfunktionen und prüft Feldwerte. Die Row-Fixture ist geeignet, wenn man eine Menge von Daten prüfen möchte. Und dann gibt es noch die Möglichkeit, sich eigene Fixtures zu definieren, wenn keine der vorhandenen Fixtures passt. Für das Schreiben eigener Fixtures bietet FIT ein Framework, mit dem man leicht HTML-Tabellen parsen und beschrieben kann.

Im Power-Workshop werden nur Column-Fixtures verwendet. Das erste Beispiel ist der obligatorische Taschenrechner. Der Test ist da, läuft aber nicht durch. Die Aufgabe besteht darin, die Tests zum Laufen zu bekommen. Das ist natürlich viel schwieriger als gedacht :-) Das ist aber auch einer der anvisierten Lerneffekte: Akzeptanztests helfen beim Entwurf der Software wenig. Dazu sind sie zu grobgranular.

AgileDay: Freud und Leid beim Vorantreiben von Agilität - Gero Seifert

Gero Seifert kommt von Nokia Siemens Networks.

Agiler Hype Cycle: Nicht irgendwo auf einem Cycle, sondern Schwankungen im Projekt, ständiges auf und ab bezogen auf die Einstellung zu agiler Softwareentwicklung.

Großes Projekt mit 3 Standorten (incl. einem in Indien), rund 150 Mitarbeiter.

Warum eigentlich agil?
"Wir wissen doch wie man ein Netzwerk-Management-System entwickelt." Früher stabile Anforderungen. Reibungsverluste zwischen Teilprojekten, Lösung durch häufige Integrationen. Termine früher nicht gehalten.

Große Ziele für neues Projekt durch geänderte Hardware und neue Technologien (UMTS/3G).

"Der Stress hört ja gar nicht mehr auf!" mit Agilität. ;-)

Agilität skaliert nicht. 8-Leute-Teams OK, aber Scrum of Scrum schwierig, erst recht, wenn nicht mit Co-Lokation.

Ehrlichkeit, weil es schnell aussieht, aber manchmal nicht wirklich was ausgeliefert werden kann.

Außerdem: Wenn man in Projekten Agilität einführt und auf Probleme stößt, dann muss man sich immer fragen, ob es überhaupt an Agilität liegt oder nicht auch so das Problem aufgetaucht wäre...

Build-Manager eingeführt, weil Build ständig kaputt.

Zusammenfassung:

• Schnell&deutlich sichtbare Arbeitrsgergebnisse
• Ausrichtung auf Kundenfeatures statt Techno
• Aktivere und schnellere Kommunikation

AgileDay: Optimierung der Geschäftsausrichtung mit agiler Organisation - Jens Coldewey

Jens hebt in seinem Vortrag weniger auf agile Softwareentwicklung im Allgemeinen ab, sondern vor allem auf die Vorteile, die Organisationen/Unternehmen erreichen können, wenn sie als Organisation agil werden.
Letztlich argumentiert er darüber, dass man sich am Markt abgrenzen muss durch Alleinstellungen und das kann man nur, wenn man flexibel und schnell etwas umsetzen kann. Dazu muss an agile Grundwerte berücksichtigen, also vor allem die Rückkopplungszyklen und das Lernen. Die Ausrichtung auf allen Ebenen, von der Strategie bis runter in die Softwareentwicklung. Maßgabe ist immer der Geschäftswert bzw. das Geschäftsziel.

Zusammenfassungsfolie:

• Strategische Prozesse werden oft von individueller IT unterstützt
• Strategische Prozesse müssen schnell am Markt agieren können
• Agile Verfahren bieten die nötige Kombination von Reaktionsvermögen und Stabilität
• Um das volle Potenzial zu nutzen, muss auch die Organisation umgestellt werden

Ich fand den Vortrag sehr interessant, allerdings befürchte ich, dass damit die Latte für den Einstieg in Agilität für viele Organisation noch höher hängt.
Andererseits beschreibt Jens ziemlich gut, was wir als Firma berücksichtigen müssen, und was man allen Startups nur empfehlen kann. Das scheint ja auch für viele kleine Unternehmen ein großer Vorteil zu sein, dass sie eben so flexibel sind und schnell reagieren können.

AgileDay: Die agile Chance

Zum ersten Mal habe ich heute einen Lessig-Style-Vortrag gehalten, also im sehr schnellen Takt Folien mit sehr wenig Inhalt vorgetragen. Das hat dank intensiver Vorbereitung auch ganz gut geklappt.
Inhaltlich ging es darum, dass agile Softwareentwicklung für Kunden und Anwender und für Entwickler viele Vorteile hat. Außerdem habe ich ein paar Tipps gegeben, wie man mit agiler Softwareentwicklung startet.

Ich habe den Vortrag auch aufgenommen und sobald der Screencast fertig ist, werde ich das hier veröffentlichen und einen Link zur Verfügung stellen.

Hallo und Willkommen

Herzlich Willkommen auf unserem Blog zur JAX 2007 von der akquinet agile GmbH.
Wir sind mit insgesamt 7 Kollegen auf der JAX und halten Vorträge, schauen uns aber auch Vorträge an. Unsere Eindrück wollen wir mit diesem Blog gerne teilen.

Alle Einträge geben persönliche Eindrücke oder Meinungen wieder.