Wie schon vor kurzem beschrieben, war ein Team rund um die LessCode-Initiative Teilnehmer des Plat_Forms 2011-Wettbewerbs in Nürnberg.
Bei diesem Wettbewerb geht es darum, diverse Plattformen (Java, Perl, PHP und Ruby) gegeneinander antreten zu lassen anhand der Entwicklung einer WebApp.
Dazu wurde von insg. 16 Teams zu je 3 Personen jeweils die gleiche WebApp entwickelt, welche daraufhin auf unterschiedliche Aspekte wie Produktivität, Security, Erweiterbarkeit etc. untersucht wurde. Genauer: momentan noch geprüft wird, denn die Analyse nimmt einige Monate in Anspruch und wird von der Arbeitsgruppe Software Engineering an der Freien Universität Berlin durchgeführt.

Unser Team, bestehend aus Stefan Botzenhart von der NinjaConcept GmbH, Florian Gilcher von der Asquera GbR und mir, traf sich dort also am Montag, dem 17.01.2011 in Nürnberg.

Die Location – zwei große Konferenzräume – muteten anfangs etwas verloren in dem riesigen menschenleeren Gebäude der Messe Nürnberg an, aber mit der Zeit geriet dies aus verständlichen Gründen in Vergessenheit; außerdem fand am nächsten Tag noch eine Konferenz der Open Source Business Foundation statt.

Dienstag morgens ging’s dann um 9 Uhr los: Die Aufgabe, die für alle Teams identisch war, wurde vorgestellt und hat unser Denken und Handeln der nächsten 30 Stunden zu 100% dominiert. Die Aufgabe bestand aus knapp 200 Anforderungen, unterteilt in Must, Should und May.
Thema war die Entwicklung eines Konferenz-Management-Tools, auf dem Konferenzen angelegt werden konnten, und sich Teilnehmer als Interessenten anmelden konnten. Teilnehmer untereinander konnten sich miteinander verbinden, Konferenzen konnten durchsucht werden usw.

Ca. die Hälfte der Gesamtaufgabe stellte sich somit als CRUD-Funktionen heraus, welche vor allem aufgrund ihrer Menge herausfordernd war.
Die andere Hälfte des Aufwands ergab sich aus mehreren Teilaufgaben: Import von initialen Stammdaten („Factory Reset“), einer Suchfunktion mithilfe eines Formulars und eines Query-Strings im Lucene-Stil („key1:value1a key1:value1b searchword key2:value2“), der Einbindung von Entfernungen (z.B. „welche Konferenzen finden im Umkreis von 100km statt?“) und einer Webservice-API, welche die meisten Funktionen per REST und JSON zur Verfügung stellte.

Wir drei kannten uns vorher nur zufällig von Treffen der Ruby User Group Karlsruhe, daher hatte ich mich einmal für sechs Stunden nur mit Stefan und einmal für drei Stunden zu dritt getroffen. Einerseits um uns wenigstens etwas kennenzulernen und andererseits um wie vorher schon angekündigt eine VMWare-Instanz aufzusetzen, ein initialies Railsprojekt anzulegen und fundamentale Dinge wie das Usermanagement einzubauen.

Wir waren sehr gespannt, wie wir uns schlagen werden im Vergleich zu den vielen anderen, teilweise seit Jahren eingespielten Teams!
Dieser Umstand hat sich aber kaum als störend herausgestellt, es gab praktisch keine Abstimmungsschwerigkeiten oder Missverstädnisse – unsere Charaktere haben wir ziemlich schnell kennengelernt.
Dass wir uns kaum kannten hat sich vielleicht sogar als fördernd herausgestellt, denn jeder von uns hat immer mal wieder ein weiteres, für die anderen überraschendes Knowhow aus der Tasche ziehen können, und die Aufgabe passte wirklich gut auf unsere jeweiligen Kenntnisse!
Grob gesagt fühlte sich Stefan im Frontend wohl, Florian auf der WebService-Seite und ich im Backend. Genauso hatte ich es mir vorgestellt und erhofft, als ich von dem Wettbewerb vor einigen Wochen las und mir überlegte, wen ich bezgl. einer Teilnahme fragen könnte.
Ich war sogar oft positiv überrascht, als z.B. Flo seine Prawn-Kenntnisse auspackte und innerhalb 30 Minuten einen PDF – Export hinzauberte oder wie ich mich immer wieder mit Stefan innerhalb kürzester Zeit abstimmte wer welchen Task als nächstes wie löst, dabei mit Rails-Fachbegriffe nur so um uns warfen und uns trotzdem blind verstanden – obwohl wir wie gesagt nie miteinander zu gearbeitet hatten.

Ein Punkt, der sich langsam zum Running Gag entwickelte, war das Thema Testen. Ich hatte öfters den Eindruck, dass wir uns lange mit technischen Schwierigkeiten beim Testen aufhielten, und ich dann bewusst einen Gegenpol aufbaute im Sinne von „Tests mit vollständiger Testabdeckung sind generell sinnnvoll, aber im Falle dieses 30-Stundenprojektes lieber nur soviel wie nötig“.
Natürlich hatte ich durch die teilweise bewusst ausgelassenen Tests den einen oder anderen vermeidbaren „Fail“, aber mich trieb die Sorge, dass wir unnötig viel testeten und zu wenige der Requirements umsetzen. Ich denke, am Ende hatten wir eine den Umständen entsprechenden immer noch gute Testabdeckung und trotzdem die meisten Punkte umgesetzt.

Am Dienstag Abend um 18 Uhr musste ein VMWare-Image, und der Sourcecode auf einer DVD gebrannt abgegeben sein. Wir hatten schätzungsweise 5-10 der Anforderungen noch offen (u.a. Support für IE6 🙂 und insgesamt ein wirklich gutes Gefühl – einerseits wie beim Marathon einfach nur dabei gewesen zu sein, andererseits aber auch nach Gesprächen mit anderen Teams. Dabei ist mein persönliches Zwischenfazit, dass alle vier Ruby-Teams alle ganz gut abgeschnitten haben, was mich besonders freut, und außerdem dass wir uns als LessCode-Team auch recht gut positioniert haben dürften. Ich bin supergespannt auf die Ergebnisse der Jury, muss ich mich aber wie alle anderen auf eine Monatelange Wartezeit einstellen. Aus den erhobenen Daten entstehen diverse Studien und sogar eine Diplomarbeit.

Zum Abschluss noch ein Riesendankeschön an das Orga.Team, das es so lange mit uns ausgehalten hat und ein wirklich hervorragendes Event auf die Beine gestellt hat, an das ich sicherlich noch sehr lange zurückdenken werde!

• Voriger Eintrag: Plat_Forms-Contest 2011
• Nächster Eintrag: Amazon Partnerprogramm