Am vergangenen Freitag ist Globago.com in die (Private) Beta gelauncht. Globago ist eine Plattform für Geschäftsreisende, die verschiedene Informationen über das jeweilige Reiseziel bereitstellt und Funktionen etwa zur Anzeige von Hotels etc. auf Google Maps sowie zur Erstellung eines persönlichen Reiseplans bietet.
Die Plattform wurde in nur 6 Wochen from scratch entwickelt. Ausgangslage waren lediglich ein mehr oder weniger grobes Konzept sowie ein darauf basierendes und damit zwangsläufig zu Anfang ebenso grobes Design. Eine Vielzahl von wichtigen Entscheidungen zu Design und Funktionalität wurde also erst relativ spontan während der Entwicklungsphase getroffen.
Dieser Artikel geht auf einige technische Aspekte des Projekts ein und zeigt auf wie viel man mit Rails in kurzer Zeit bei hoher Qualität und Flexibilität erreichen kann.
Infrastruktur
Am Anfang eines jeden Projekts steht das Aufsetzen der Infrastruktur wie Versionskontrolle, Ticketing System etc. Hier muss man sich entscheiden ob man alles selbst aufsetzen möchte (SVN, Trac etc.) oder lieber auf SaaS Angebote zurückgreift. Diese haben den Vorteil, dass keinerlei oder nur sehr geringer Aufwand entsteht und sie (evtl. mit Ausnahme von github 
zuverlässig laufen.
Für dieses Projekt habe ich mich für die Kombination aus gihub, Lighthouse und Hoptad entschieden, die sich auch in vergangenen Projekten schon bewährt hat. Insbesondere die Integration der einzelnen Services ist dabei ein großer Vorteil. So kann man bspw. in Commit Messages Lighthouse-Tickets referenzieren oder sogar modifizieren und seit neuestem auch aus in Hoptoad angezeigten Backtraces direkt auf den entsprechenden Code in der entsprechenden Revision auf github wechseln.
Testing
Obwohl ich selbst ein großer Freund von Testing bzw. Specs bin (siehe auch meinen Vortrag zu RSpec) muss man bei einem Projekt wie diesem, mit straffem Zeitrahmen und zunächst mehr oder weniger ungenauen Anforderungen, abwägen zwischen Flexibilität und Entwicklungsgeschwindigkeit auf der einen und gut getestetem Code auf der anderen Seite. Wenn die Anfoderungen nicht einigermaßen eindeutig bekannt und insb. formuliert sind, ist es fast kontraproduktiv, zunächst eine umfassende Test- bzw. Spec- Suite zu schreiben, da das durch eine solche Suite spezifizierte Verhalten ja noch gar nicht ausreichend bekannt ist. Es fließt in diesem Fall also viel Arbeit in die permanente Aktualisierung der Specs so dass es sicher mehr Sinn macht, mindestens den Prototypen quasi auf althergebrachte Art und Weise zu entwicklen und die Anwendung erst in der Konsolidierungsphase umfassend zu testen. Ich habe daher weitestgehend auf Specs verzichtet und lediglich Dinge wie Validations etc. spezifiziert um sicherzugehen, dass das grundlegende Model korrekt ist. Das eigentliche Acceptance Testing wurde jeweils zum Abschluss der einzelnen Milestones vom Kunden selbst durchgeführt. So erhält der Entwickler frühzeitig Feedback vom Kunden, der widerum frühzeitig einen Blick auf seinen zukünftige Anwendung werfen und den Entwicklungsverlauf verfolgen kann.
Per Scaffolding zum (fast) fertigen Backend
Das oftmals zu recht kritisierte Scaffolding kann für prototypische Anwendungen und insbesondere Backend-Funktionalität gute Dienste leisten. Bei einem Content getriebenen Dienst wie Globago.com, bei dem die Hauptaufgabe des Backends das Anlegen, Bearbeiten, Löschen etc. von unterschiedlichem Content ist, kommt man per Scaffolding – selbst wenn man die generierten Controller, Views etc. noch anpassen muss, innerhalb kürzester Zeit zum fertigen Backend. Alternativ macht sicher auch der Einsatz von Plugins wie Hampton Catlins make_resourceful Sinn, die im Gegensatz zu ./script/generate scaffold ... DRY- konformer sind, allerdings nicht das manuelle Anlegen von Views ersparen.
Deployment
Für das Deployment von Rails Anwendungen gibt es mittlerweile eine Vielzahl von Optionen. Die mit dem geringsten Aufwand ist aber sicherlich Passenger, das in der neusten Version jetzt auch für Nginx verfügbar ist. Gegenüber anderen Ruby Webservern wie Mongrel oder Thin hat Passenger zwar keinen signifikanten Performance Vorteil, in der Regel aber einen deutlich kleineren Memory Footprint. Vor allem wird aber das Deployment deutlich vereinfacht. Anstatt mongrel_cluster oder thin start --socket ..., wobei man ggf. noch darauf achten muss, die einzelnen Prozesse zeitversetzt neu zu starten um Downtimes zu vermeiden (siehe auch Poor mans rolling restart for thin + god), genügt bei Passenger ein einfaches touch restart.txt im RAILS_ROOT und Passenger startet die Anwendung automatisch neu, spawnt Prozesse etc. Auch ist kein Monitoring von Prozessen mehr nötig wie es bei Mongrel oder Thin praktisch unverzichtbar ist. Auch die Konfiguration von Passenger ist denkbar einfach – insbesondere in Kombination mit Nginx:
http {
passenger_root /opt/ruby-enterprise-1.8.6-20090201/lib/ruby/gems/1.8/gems/passenger-2.2.1;
passenger_ruby /opt/ruby-enterprise-1.8.6-20090201/bin/ruby;
...
server {
listen 80;
server_name *.globago.com;
root <path to RAILS_ROOT/public>;
passenger_enabled on;
}
...
}
Fazit
Das Projekt Globago.com zeigt deutlich, wie viel sich in kurzer Zeit mit Rails realisieren lässt. Es lassen sich extrem schnell Features umsetzen (auch ohne die komplette Anwendung einfach zu scaffolden ohne dass die Qualität des Ergebnisses leidet. Mit anderen Frameworks mag sich ebenso viel in ebenso kurzer Zeit realisieren lassen, das Ergebnis ist aber mit relativ hoher Sicherheit minderwertiger. Auch existiert mit github, Lighthouse, Hoptoad und anderen Diensten eine hervorragende Projekt- Infrastruktur als SaaS.
Das Projekt
| Entwicklungszeit | 6 Wochen |
|---|---|
| Entwicklerteam | 1 Entwickler in Vollzeit, 1 Designer in Teilzeit, PSD2HTML |
| Projekt-Infrastruktur | github, Lighthouse, Hoptoad |
| Plugins | acts_as_list, hoptoad_notifier, paperclip, rspec, thinking_sphinx, geokit, will_paginate |
| Deployment | Capistrano, Passenger, Nginx |
Schlagworte: success story
(6 Bewertung(en), durchschnittlich: 4.33 (max. 5)
Loading ...
28. April 2009 um 18:49
Prima! Danke für den Artikel und die klare Aussage hinsichtlich TDD bei “high volatile startups” die ich teile
29. April 2009 um 15:18
Interessant – und eine success story, an der wir definitiv Spaß haben, weiterzuschreiben…
5. Mai 2009 um 10:26
Wie habt ihr mit psd2html zusammengearbeitet? Haben die direkt in die Rails views hineingearbeitet? So hatte ich das mal mit XHTMLized gemacht, die haben einen Zugang zu SVN bekommen das Design direkt reinimplementiert.
6. Mai 2009 um 08:22
@Stephan: PSD2HTML hat einfach die PSDs bekommen und dann HTML zurückgeliefert. Das Aufsplitten in Views und Layouts habe ich dann selbst gemacht. Ich kann mir auch nicht vorstellen, dass die mit github klar gekommen wären bzw. wäre mir das ohnehin nicht recht gewesen wenn die in meinem Code gearbeitet hätten
6. Mai 2009 um 12:23
@Marco: Danke für die Info. Warst du eigentlich mit der Qualität von psd2html (CSS/HTML) zufrieden? Waren die Ergebnisse z.B. einfach erweiterbar bzw. wiederverwendbar für neue, ähnliche Pages?
7. Mai 2009 um 10:55
@Stephan: Ja, im Grunde waren die Ergebnisse so weit in Ordnung. Man darf natürlich kein semantisches HTML/CSS erwarten, da PSD2HTML die Semantik hinter der Seite ja nicht kennt bzw. nur soweit wie sie unmittelbar aus dem PSD ersichtlich ist. Man muss in jedem Fall aber schauen was für PSDs man denen schickt. Für die Darstellung irgendwelcher Daten bspw. sollte man evtl. mehrere Fälle schicken (alle Daten vorhanden, einige optionale Daten nicht vorhanden etc.) Ansonsten muss man ggf. schon einiges anpassen. Das ist aber PDF2HTML dann eigentlich nicht vorzuwerfen.