Die Challenge stieß bei Canoo in Basel erst auf zurückhaltendes Echo. Sollten wir neben dem Tagesgeschäft auch noch "zum Spaß" programmieren? So haben wir zunächst abgewartet, ob sich nicht ein anderes Grails-Team anmeldet. Als Sebastian Meyen dann aber twitterte "Wie? Die Grails Community kneift?" (oder so ähnlich), war klar, dass wir etwas tun mussten.
Die Einreichungsfrist war aber schon fast abgelaufen und so haben wir die Applikation nahezu vollständig am Wochenende vor dem Abgabetermin fertiggestellt - im Rahmen des Canoo Code Camps. Diese Veranstaltung nutzen wir, um zweimal im Jahr aus dem Tagesgeschäft auszubrechen. Wir reisen mittwochs abends ins Berner Oberland und programmieren bis Samstagmittag gemeinsam neue Ideen aus. Der Zeitaufwand war also 2,5 Tage, wobei man die Nächte auch mitrechnen muss! Lediglich die Ausgestaltung des Spiels haben wir vorher in einigen abendlichen Runden grob festgelegt.
Die sechs Teilnehmer organisierten sich in drei Paaren, denn im Code Camp ist Pairing Pflicht. Das Team bildeten vier Canooeys, ein ehemaliger Kollege und ein Student aus dem Begabtenkolleg des Karlsruher Institute of Technology (KIT), das Canoo fördert.
Die Wahl der IDE stand jedem Pair offen. Wir haben eine gemeinsame Arbeitsinsel gebildet und uns auf Zuruf synchronisiert. Zusätzlich haben wir mit JIRA die Anforderungen an das Spiel verwaltet. Integriert wurde per SVN mit Teamcity für die Continuous Integration. Weil wir auf der Grails-Plattform aufsetzen, war das automatische Build-System gesetzt, denn das kommt ja mit Grails bereits mit.
Wir haben also Grails als Plattform und programmieren Applikationscode vollständig in Groovy. Die erste Stärke dieser Wahl zeigt sich beim Team: Obwohl nur ein Teammitglied nennenswerte Erfahrung in Groovy hat, konnten alle sofort produktiv werden. Mit guten Java-Kenntnissen ist der Einstieg in Groovy sehr leicht.
Der zweite große Vorteil resultiert aus dem Ansatz von Groovy, die Reichhaltigkeit der Java-Plattform auszunutzen. Wir verwenden die Grails-Plug-ins für Spring Security, Mail, Canoo WebTest und Canoo ULC, Letzteres zusammen mit Erweiterungen für OpenGL: JOGL und SwOGL. Das heißt wir bekommen Authentisierung und rollenbasierte Autorisierung geschenkt, können Mails für vergessene Passwörter verschicken, haben funktionale Tests für unseren HTML-Kanal und können interaktive und animierte Komponenten bauen.
Wir setzen auf eine klassische Webapplikationsarchitektur, die sämtlichen applikationsspezifischen Code - auch die Präsentationslogik - auf der Serverseite hält. Das schlanke Domänenmodell und das daraus automatisch abgeleitete Persistenzschema bestücken drei Benutzerkanäle, die von je einem Pair implementiert werden:
- einen Canoo-UltraLightClient-(www.canoo.com/ulc)Kanal für Power User
- einen iPhone-Kanal für mobiles Tippen per AJAX
- einen klassischen HTML-Kanal für die Administratoren
Alle Kanäle folgen einem klassischen MVC-Ansatz.
Views und Controller werden für den HTML-Kanal dynamisch zur Laufzeit erstellt, d. h. sämtliche Standard-Views und Aktionen zum Anzeigen, Anlegen, Editieren und Löschen werden effektiv zu einem Einzeiler wie in:
import com.canoo.cats.Userclass UserController {static scaffold = User}
Businesslogik ist dem Vorgehen des Domain-driven Designs folgend mehrheitlich in Services ausgelagert.
Die Wahl von Grails als Framework erlaubt es uns, bequem und schnell die Businesslogik zu erstellen und durch den Verzicht auf materialisierte Controller und Views eine hohe Änderungsfreundlichkeit und einen schnellen Mikroentwicklungszyklus umzusetzen.
