Die 140 Teilnehmer des zweiten Startup Weekends in Hamburg hatten nur ein Ziel vor Augen: In 48 Stunden zum eigenen Startup [1]. Cem Basman und Jason Frankling-Stokes hatten die Veranstaltung organisiert.

Dieses Vorhaben war eine Gratwanderung zwischen organisatorischer Effizienz und sinnvoller Zuordnung von Ressourcen. Die 140 Individuen galt es so zu organisieren, dass paralleles Arbeiten möglich war. Dabei kannten sie sich größtenteils nicht und hatten noch nie zusammen gearbeitet.

Ausgangslage: Darum ging’s

Eines der beiden Projekte des Weekends war Indawo: Eine Plattform, auf der Nutzer Orte („Locations“) anlegen und suchen können, die für besondere Anlässe und Ereignisse geeignet sind. Die Anwendung besteht aus drei zentralen Anwendungsfällen:

1. Anlegen von Locations. Locations sollen Kategorien zugeordnet werden, die auch Überschneidungen zulassen: Eine Bar kann beispielsweise sowohl für eine Firmenfeier als auch für die Entspannung geeignet sein. Außerdem werden zahlreiche Attribute gespeichert, die einen Vergleich der Features zulassen. Dazu gehören u. a. Preisniveau, technische Ausstattung und Anzahl der Plätze.
2. Suche innerhalb der Daten. Diese soll einen Wizard-ähnlichen Prozess anbieten, in dem sich der Nutzer die Daten zusammenstellen kann, die er sucht. Wenn der Nutzer fündig geworden ist, kann er sich die Location anzeigen lassen.
3. Ausgabe der Daten.

Darüber hinaus waren weitere Funktionen umzusetzen: Registrierung, User-Management, Administration, Uploads und Geo-Codierung.

Fogende Faktoren waren dabei wichtig:

• Der Prototyp musste noch am selben Wochenende fertiggestellt sein, weil sich danach die Gruppe auflöste.
• Frühzeitiges Feedback war gefordert, damit sich Produktentwicklung, IT, Marketing und Recht untereinander koordinieren und die Einzelmaßnahmen besser planen konnten.
• Vorgehen in Iterationen (Entwicklungszyklen) wurde angestrebt, weil ständig Verbesserungsvorschläge bearbeitet werden mussten.

Ruby on Rails eignet sich perfekt, um schon in einer frühen Phase des Projekts klickbare Prototypen zur Verfügung zu stellen. Mit Hilfe eines „Scaffold“ lassen sich zu einem Datenbank-Model sämtliche Methoden generieren, die für die Eingabe und Bearbeitung von Daten benötigt werden (die so genannten CRUD-Operationen). Zudem werden „Views“ erzeugt, die sich im Browser anzeigen lassen.

Die Einhaltung von Konventionen und Prinzipien (wie DRY = „Don’t repeat yourself“), die saubere Schichtenarchitektur und die Möglichkeit „Migrations“ zu benutzen helfen dem Entwickler dabei, dass er zu einem späteren Zeitpunkt problemlos Änderungen vornehmen und somit iterativ vorgehen kann. Vorteilhaft an Rails ist auch die Lernkurve: Beim Startup Weekend konnten Leute mit Programmiererfahrung angelernt werden.

In Ruby arbeitet man typischerweise weniger mit Klassenhierarchien. Stattdessen integriert man Module in den eigenen Code (auch „mixen“ genannt). Das ist wesentlich flexibler. Besonders beliebt sind die Plugins, deren Integration sich mit dem Prinzip "Don’t repeat others" beschreiben lässt. Anders gesagt: Man muss nicht für jeden Anwendungsfall das Rad neu erfinden, wenn es bereits tragfähige Lösungen gibt. Plugins lassen sich per Script-Aufruf aus dem Internet laden und installieren.

Das indawo-Entwicklungsteam bestand während des Wochenendes aus zehn Leuten: sechs Rails-Entwickler, davon vier mit Erfahrung und zwei „Angelernte“, sowie vier Designer. Der erste Tag lief bereits sehr produktiv ab. Neben der Produktidee und den Screendesigns wurde der erste Prototyp entwickelt und auf dem Server bereitgestellt ("Deployment"). Schon gab es eine lauffähige Version, die alle Teilnehmer testen konnten, um Verbesserungsvorschläge zu machen. Den zweiten Tag verwendete man, um Features auszubessern und zu erweitern. Zudem wurden Texte geschrieben und rechtliche Aspekte geprüft. Nach den zwei Tagen waren mit der Ein- und Ausgabe von Locations zwei der drei zentralen Anwendungsfälle implementiert. Das Layout basiert auf Grids und entspricht somit dem aktuellen Trend. Das Video der Abschlusspräsentation dokumentiert die Ergebnisse des Wochenendes und zeigt den damaligen Stand der Entwicklung [2].

Nach dem Wochenende wurde noch acht weitere Tage an indawo entwickelt, wobei sich die Ressourcen erheblich reduziert haben, zumal alle Entwickler ihren normalen Jobs nachgehen mussten. Die Entwicklungssprints wurden über Skype, die aufgesetzte Mixxt-Plattform und tägliche Abstimmungen („Daily-Scrum-Meetings“) organisiert. Ein Tagessprint dauerte wegen der zeitlichen Engpässe in der Regel nicht länger als drei Stunden. Trotz aller Beschränkungen reichte die Zeit aus, um mit der Suche den dritten zentralen Anwendungsfall umzusetzen. Zudem konnte das Team zahlreiche Detailverbesserungen vornehmen, die während der Entwicklung aufgekommen waren. In Anbetracht der knappen Ressourcen wurde in den zehn Tagen Entwicklungszeit sehr viel erreicht. Das Ergebnis lässt sich auf indawo.de betrachten.

Sicherlich hätte die Entwicklung länger gedauert, wenn nicht so viele Plugins zur Verfügung gestanden hätten. Deshalb stellt der folgende Abschnitt die verwendeten Plugins vor und beschreibt ihren Einsatzzweck bei indawo.

Folgende Plugins wurden bei indawo verwendet:

Die Installation und Einbindung eines Plugins ist sehr einfach. Das folgende Beispiel illustriert dies anhand von Geokit.

Mit Geokit [3] werden bei indawo zu Adressen die zugehörigen Geo-Koordinaten ermittelt. Das Beispiel geht davon aus, dass in einem Rails-Projekt ein Location-Model vorhanden ist, das die Felder name, street, zip, city, lng und lat enthält:

ruby script/generate model location name:string street:string zip:string city:string lng:float lat:float

Danach die Migration ausführen, damit die Datenbanktabelle angelegt wird:

rake db:migrate

Um Geokit zu installieren, muss man folgendes Skript im Projektordner ausführen. Danach muss man zum Beispiel einen Google-Map-Key in der Datei environment.rb eintragen:

ruby script/plugin install svn://rubyforge.org/var/svn/geokit/trunk

Als letztes verändert man das User-Model:

class Location < ActiveRecord::Base
	before_save :geocode_address # Callback, welches die Methode geocode_address vor dem Speichern aufruft
	acts_as_mappable # Einbindung des Plugins
	def geocode_address
		geo=GeoKit::Geocoders::MultiGeocoder.geocode(self.street.to_s << ", " << self.zip.to_s << " " << self.city.to_s << " Germany") # Aufruf, um Koordinaten abzufragen
		self.lat, self.lng = geo.lat,geo.lng if geo.success # Die Werte für lat und lng werden dem User-Objekt hinzugefügt
	end
end

Nach diesen wenigen Schritten werden beim Anlegen einer Location die Koordinaten der Adresse in der Datenbank mitgespeichert. Aus Vereinfachungsgründen wurde der Umfang des Beispiels auf das Wesentliche reduziert und deckt sich somit nicht mit der Implementierung von indawo. Was aber deutlich wird: Die Umsetzung einer solchen Aufgabe geht sehr schnell von der Hand.

Mit Ruby on Rails konnte die Plattform indawo in sehr kurzer Zeit entwickelt werden. Rapid Prototyping und die Möglichkeit des schnellen Feedbacks sowie der Einsatz von Plugins haben dazu beigetragen, dass beim Startup Weekend bereits ein Prototyp vorgestellt werden konnte. Gewiss lassen sich an der Plattform noch einige Dinge verbessern – beispielsweise die Usability, die Suchmaschinenfreundlichkeit und die Beschreibungstexte. Dennoch sind alle Beteiligten davon überzeugt, dass es sich um ein erfolgreiches Experiment handelt. Vor Jahren hätte man sich nicht vorstellen können, dass man in zehn Tagen ein Startup-Projekt aufsetzen kann. Wenn man bedenkt, dass sich die Entwickler vorher noch nicht kannten und noch nie zusammen gearbeitet haben, kann man sich vorstellen, wie produktiv und schnell ein eingespieltes Rails-Team sein kann.

Der Autor

Peter Grosskopf entwickelt mit der Zweitag GmbH (zweitag.de) Webanwendungen mit JRuby/Ruby on Rails sowie iPhone-Apps. Zudem berät er Enterprise-Kunden, wie sie Elemente des Web 2.0 für ihre Unternehmensanwendungen nutzen können. Mit brainr.de gründete er eine Plattform für Online-Brainstormings und war bis Anfang des Jahres CTO bei „A better Tomorrow“.