Plat_Forms 2011

In meinem ersten Gastartikel möchte ich euch etwas über unsere Teilnahme am Plat_Forms-Wettbewerb erzählen. Bei  diesem Wettbewerb treten Teams bestehend aus drei professionellen Entwicklern, die sich vorher für eine Entwicklungsplattform entschieden haben, gegeneinander an. Dieses Mal waren es vier PHP-, vier Ruby-, vier Java- und drei Perl-Teams. Außer Konkurrenz ist noch ein node.js-Team angetreten. Die Teams bekommen eine vorher unbekannte Aufgabe, bei der eine Webanwendung entwickelt werden muss. Die Teams haben zwei Tage (netto ca. 20 Stunden) Zeit, die Anforderungen umzusetzen. Externe Hilfe durften sich die Teams nicht holen. Es war aber erlaubt jeglichen Code, der vorher entstanden war, zu verwenden.

Den Organisatoren geht es darum, die in diesem Experiment messbaren Vor- und Nachteile der antretenden Plattformen gegeneinander abzugrenzen. Dazu werden verschiedene Aspekte wie Anzahl der umgesetzten Anforderungen, Sicherheit, Erweiterbarkeit, Usability, Performance etc. untersucht. Nach einer Auswertungsphase, die mindestens ein halbes Jahr dauern wird, werden die Organisatoren der FU-Berlin eine wissenschaftliche Arbeit dazu publizieren. Nach 2007 hat dieser Wettbewerb zum zweiten Mal stattgefunden.

Wir sind Ilja, Alex und ich, drei Entwickler, die bei der mindworks GmbH in Hamburg angestellt sind. mindworks entwickelt seit 1996 professionelle, individuelle Webanwendungen auf der Basis von PHP. Natürlich sind wir für PHP in den Ring gestiegen, um uns und der Firma Ruhm und Ehre zu verschaffen ;-).  Als Framework haben wir symfony 1.4 mit Doctrine 1.2 als ORM eingesetzt. Wir haben in dieser Konstellation auch schon einige Kundenprojekte zusammen gewuppt.

Nachdem klar war, dass wir an dem Wettbewerb teilnehmen, haben wir uns einen Server als Virtual-Maschine gebaut, auf dem wir die Webserverumgebungen für drei Entwickler, einen Integrationsserver und das SVN-Repository vorbereitet haben. Wir haben außerdem im Repository schon mal ein „leeres“ symfony-Projekt mit unseren Standardanpassungen und einer laufenden Unittest-Umgebung angelegt. Optimistischerweise haben wir auch noch einen Hudson-Server installiert. Im Laufe des Wettbewerbs haben wir den dann aber gar nicht benutzt.

Mit dem Gefühl ganz gut vorbereitet zu sein, haben wir uns dann am Montag den 17. Januar morgens um 7 beim Autovermieter getroffen und nachdem wir dann unsere Laptops, Monitore, das Netzwerkequipment etc. verladen haben, sind wir – natürlich nicht ohne noch ein ordentliches Frühstück einzunehmen – auf die Autobahn Richtung Mittelfranken gedüst. Während der Fahrt hatten wir noch Gelegenheit uns ein wenig strategisch und taktisch abzustimmen. Von den drei Vollsperrungen auf der Gegenfahrbahn unbeeindruckt sind wir dann gegen 14 Uhr an der Messe in Nürnberg angekommen.

Es waren ein großer und ein kleinerer Raum für die 16 Teams vorbereitet. Nach dem Füllstand der Räume waren wir eher eines der früher ankommenden Teams. Nachdem wir zuerst den kleineren Raum favorisierten,  haben wir uns dann doch für einen Fensterplatz im großen Raum entschieden. Diese Entscheidung haben wir auch nicht bereut. Wir wurden nicht durch Lärm gestört und haben so mehr vom allgemeinen Treiben mitbekommen, sofern wir nicht bis zu den Ellenbogen in Konzepten oder Code steckten.

Wir hatten dann bis ca. 18 Uhr Zeit unser Equipment aufzubauen und finale Vorbereitungen zu treffen. Alles ging relativ problemlos. Die Strom- und Internetversorgung  funktionierten einwandfrei. Wir haben noch ein paar letzte Tweaks an unseren Umgebungen vorgenommen und sind dann ins Hotel gefahren. Nach dem Einchecken haben wir uns noch mit einer Pizza in der Umgebung gestärkt und sind dann zeitig ins Bett entschwunden.

Nach einem guten Frühstück im Hotel ging es dann am Nächsten Morgen um 9 Uhr los. Nach einer kurzen Einführung durch die Organisatoren wurden die Spezifikationen für die zu erledigende Aufgabe verteilt. Es sollte eine Community implementiert werden, in der Konferenzen gepflegt, diese Kategorien zugeordnet und Benutzer sich für diese anmelden und diese mit pflegen können. Die Benutzer sollten außerdem Netzwerke bilden können.

Von jetzt ab wurde jeder von uns alle 15 Minuten von einem aus dem Organisatorenteam befragt, was er gerade vor 10 Sekunden gemacht hat. Die Antwort darauf wurde nach einem bestimmten Muster erwartet und mit einem Diktiergerät aufgezeichnet. Eine Antwort hätte zum Beispiel „Coding: JSON-Daten-Import, PlatformsDataImporter.class.php“ oder „Reading: Spezifikation, Kapitel 3“ lauten können. Auch wenn Team-Mitglieder nicht am Platz waren, wurde z.B. „M2 macht Pause“ auf das Diktiergerät gesprochen. Mich persönlich haben diese regelmäßigen Unterbrechungen nicht so gestört. Mir hat es eher klar gemacht, wie lange ich schon an gewissen Aufgaben zu Gange bin. Manchen Entwicklern ging es wohl anders.

Nachdem wir eine gute Stunde mit dem Lesen der Spezifikation verbracht haben, sind wir in eine ruhige Sofaecke umgezogen und haben über die Anforderungen gesprochen und uns ein grobes Konzept gemacht. Die Spezifikationen waren ziemlich vollständig und widerspruchsfrei, also das Gegenteil von dem, was man normalerweise von einem Kunden „vorgesetzt“ bekommt. Die Anforderungen waren sauber in MUSTs, SHOULDs und MAYs aufgeteilt. Das Design des Frontends wurde als zweitrangig eingestuft. Die Anforderungen enthielten eine Menge Stoff. Nachdem wir die initialen Arbeitspakete verteilt haben, sind wir an unsere Arbeitsplätze zurückgekehrt und haben „losgelegt“.

Auch wenn man ja am Anfang eines Projektes wenig im Frontend sehen kann, hatten wir das Gefühl ganz gut voran zu kommen. Relativ bald waren das Model und die Benutzerauthentifizierung (Login, Registrierung mit dem sfDoctrineGuardPlugin) implementiert und die notwendigen Routen, Controller und Templates als Dummys angelegt. Es folgten einige zeitaufwändigere Tasks wie die Implementierung des Imports der mitgelieferten Fixtures im JSON-Format und der Freundschaftsanfragen. Parallel entstanden die CRUD-Funktionalitäten für Konferenzen und Kategorien. Alex hat außerdem das sfiCalCreatorPlugin aufgetan, mit dem man komfortabel die geforderten Kalender-Exporte im iCal-Format erstellen konnte.

Gegen 17 Uhr waren wir an einen Motivations-Tiefpunkt angekommen, da wir das Gefühl hatten, dass wir die MUST-Anforderungen auf keinen Fall in der verbleibenden Zeit fertigstellen würden. Wir haben uns aber einfach weiter durchgebissen und als wir gegen Mitternacht das Messegelände verließen und zum Hotel zurückkehrten, hatte sich dieses Gefühl wieder etwas relativiert und wir glaubten wieder ganz gut im Rennen zu sein. Anders als bei dem Wettbewerb 2007, bei dem die Teams selber entscheiden konnten, wie viel sie schlafen möchten und die, die sich zu wenig Schlaf eingeplant hatten, es am nächsten Tag bereuten, hatten die Organisatoren beschlossen, die Räume zwischen Mitternacht und 8 Uhr morgens zu schließen.

Im Hotel haben wir noch ein kleines Bier verhaftet – anders als in Hamburg darf man in Bayern wohl kein Bier auf der Straße trinken 😉 – und sind dann ab ins Bett. Ich persönlich hatte so meine Probleme einzuschlafen, da ich in Gedanken noch Implementierungslösungen durchgespielt habe. Am Ende sind es dann aber doch 4,5 Stunden Schlaf geworden. Nachdem wir uns noch die Zeit für ein gutes Frühstück genommen haben, waren wir pünktlich um 8 wieder an unseren Rechnern.

Als erstes haben wir mal zu dritt eine Projektinventur gemacht, um zu gucken, welche MUST-Features wir noch nicht umgesetzt hatten. Dabei ist dann die geforderte Webservice-Schnittstelle inklusive einer HTTP-Authentifizierung als größtes Paket herausgekommen. Außer einer Konferenz- und Mitgliedersuche fehlten hier und da noch einige kleine Punkte. Alex hat dann mit dem Webservice begonnen, Ilja hat sich um die Suchen gekümmert und ich habe den Kitt in die noch bestehenden Lücken gefüllt. Nachdem Ilja mit der Suche fertig war, hat er sich dann mit auf den Webservice gestürzt. Es war uns dann aber ziemlich schnell klar, dass wir den Aufwand dafür deutlich unterschätzt hatten und den Webservice wahrscheinlich nicht vollständig umsetzen würden.

Jedes Team durfte einen Integrationsserver von außen erreichbar machen, den sich jeder angucken durfte und „Helfer“ aus Benutzersicht Bugs und Usability-Probleme an uns melden durften. Ich habe gegen Mittag darauf die aktuelle Version aufgespielt und diese über den Plat_Forms-Blog bekannt gemacht (Ich durfte auch Mails und IMs dazu an beliebige Leute schicken). Ich habe diverse Rückmeldungen bekommen. Habe mir aber nur die Zeit genommen einige wenige davon zu berücksichtigen. Nachmittags habe ich den Stand nochmal aktualisiert und das wieder bekannt gegeben.

Das Catering war übrigens super. Mittags und abends gab es leckere, warme Speisen und zwischendurch gab es immer irgendwelche kleineren und größeren Snacks. Auch alle möglichen Getränke waren jederzeit kalt und heiß verfügbar.

Da der Abgabetermin um 18 Uhr feststand, haben die Organisatoren uns um 17 Uhr daran erinnert, dass wir noch unsere Server-VM, das SVN-Repository und den Quellcode zur Abnahme einpacken und eine Checksumme darüber bilden mussten. Wir haben dann zeitnah ein Ende bei der Entwicklung gefunden und um 17:15 Uhr mit dem Packen begonnen. Die ersten Prognosen, die Windows für das zippen der 8 Gigabyte großen VM abgab, waren eher beängstigend. Zumal das dann entstehende Zip nochmal mit den zwei anderen Archiven zusammen gezippt werden sollte und wir dann noch die Checksumme berechnen sollten, wurden wir langsam nervös. Am Ende haben wir aber dann pünktlich um 17:45 Uhr abgegeben. Die Anspannung wich sofort einer latenten Grundeuphorie, die durch Schlafmangel und das Bier, welches wir freundlicherweise vom Typo3-Team geschenkt bekommen haben, noch angeheizt wurde. Einfach ein super Gefühl, das die Anstrengungen der letzten zwei Tage sofort vergessen machte. Auch der Umstand, dass wir gefühlt nur 80-90% der MUST-Anforderungen abgeliefert haben und Gerüchten zufolge zwei oder drei Teams Feature-Completeness gemeldet haben, waren in dem Moment irrelevant.

Nach einer kleinen Runde mit Danksagungen und einem Gruppenfoto mussten wir unser Equipment wieder abbauen und verstauen. Aber auch das ging recht zügig und wir ließen die Messe in Nürnberg hinter uns.

Abends war dann noch eine kleine Party in einem Laden direkt am Hauptbahnhof organisiert. Da nicht sofort ersichtlich war, wo der Eingang wohl war, irrten wir ein bisschen im Hauptbahnhof rum. Das nahmen zwei Polizisten in Zivil zum Anlass, uns auf Drogen zu untersuchen. Und ich dachte erneut: „Willkommen in Bayern“. Die Party war dann ganz gut. Der Laden war ein bisschen „schicki“ und ein bisschen zu hell. Ich habe mich aber ganz gut mit Leuten aus zweien der Ruby-Teams und einigen der Organisatoren unterhalten. Lange habe ich aber nicht durchgehalten und war schon gegen 11 im Bett.

Am nächsten Morgen stand die Rückfahrt auf dem Programm. Wir alle hatten relativ wenig Lust nochmal 6 Stunden auf der Autobahn zu verbringen. Aber auch auf dem Rückweg hatten wir Glück und blieben von Staus verschont.

Das Ergebnis unserer Arbeit kann man übrigens hier bewundern. Den Sourcecode habe ich auf Github zur Verfügung gestellt (das symfony-Framework ist nicht enthalten).

Ich bin sehr gespannt auf die Ergebnisse. Mein Gefühl ist, dass wir uns – was die Anzahl der umgesetzten Features angeht – ganz OK geschlagen haben. Was die anderen Aspekte wie Sicherheit, Erweiterbarkeit etc. angeht, habe ich gar kein Gefühl. Um Performance konnten wir uns gar keine Gedanken mehr machen. Aber das ging den anderen Teams sicher ähnlich.

Insgesamt war die Aufgabe so dimensioniert, dass wir eigentlich gar keine Zeit hatten „professionell“ zu entwickeln. Ich glaube schon, dass wir ordentlichen Code abgeliefert haben. Aber dadurch, dass der Focus bis zum Ende auf der Umsetzung von Features lag, hatten wir keine Zeit, alles nochmal final glatt zu ziehen (Usability, Refactoring, Testen, Aufräumen). Schön musste die Anwendung ja laut Anforderungen sowieso nicht aussehen. Unit-Tests, Code-Reviews und Continuous-Integration zahlen sich in einem Projekt, das insgesamt ca. 9 Personentage dauert, auch nicht aus.

Als Learning ziehe ich aus dem Projekt, dass wir noch mehr Best-Practices in wiederverwendbaren Code gießen müssen. Wir passen symfony und die Plugins, die wir verwenden,  oft an den gleichen Stellen an. Dies müssen wir noch mehr als jetzt z.B. in eigene Plugins auslagern, die quasi ein mwSymfony als Basis bereitstellen. Nachdem ich mich ja auch vorher mit den Ergebnissen des Plat_Forms-2007-Wettbewerbs beschäftigt hatte, bestand eine gute Chance, dass wir eine Benutzerverwaltung brauchen würden. Diese hätten wir schon vorbereiten können, um ein wenig Zeit zu sparen. Auch wenn es mit uns dreien gut geklappt hat, die Arbeit mit relativ wenig Abstimmung aufzuteilen, hätten wir vielleicht grobe Schätzungen für die einzelnen Aspekte der Software machen können. Eventuell hätten wir dann festgestellt, dass der Webservice größer ist, als wir am Anfang dachten. Unter Umständen hätte man auch durch Ausnutzen von Synergieeffekten zwischen Webservice und JSON-Importer etwas Zeit sparen können.

Es kristallisiert sich heraus, dass es auch im nächsten Jahr wieder einen Plat_Forms-Wettbewerb geben wird. Ich werde wieder gerne dabei sein. Wahrscheinlich ist dann auch Symfony2 soweit und wir so damit vertraut, dass wir damit als Basis antreten können.