Das Entwicklungs-Framework Ruby on Rails erfreut sich einer immer größer werdenden Anhängerschaft. Vor allem die Philosophie dahinter hört sich sehr verlockend an: weniger, schneller und sauberer Web-Applikationen programmieren und dabei noch Spaß an der Sache haben. Dies wird erreicht durch den Nutzen von Konventionen und dem Motto “Weniger ist mehr”. Diese Grundeinstellungen gehen zurück auf den Erfinder des Rails-Frameworks: David Heinemeier Hansson.
David Heinemeier Hansson studierte 2004 noch an der Universität in Kopenhagen, Dänemark, als er die erste Version seines Frameworks “Ruby on Rails” veröffentlichte. Er arbeitete zu der Zeit als Freelancer für die in Chicago ansässige Firma 37signals. Die 1999 gegründete kleine Webdesign-Firma stand kurz vor dem Schritt sich von einer Internetagentur zu einer Produkt-Firma zu wandeln. Heinemeier Hansson sollte helfen das Flaggschiff von 37signals zu entwickeln: Basecamp - ein Projektmanagement WebApp für kleine Entwicklerteams.
Die Wahl der Programmiersprache
Eigentlich wollte Heinemeier Hansson Basecamp in PHP schreiben, da PHP schnell zu Resultaten führt. Aufgrund der Mischung von Design und Funktionalität zählt PHP (damals noch in Version 4) zu den eher “unsauberen” Sprachen. Der Gedanke sich die nächsten Jahre in dieser Sprache Tag ein, Tag aus zu bewegen, missfiel Heinemeier Hansson. Auf der anderen Seite hatte er während seines Studiums viel Erfahrung mit Java und J2EE gemacht und kannte somit auch die andere Seite: den “sauberen” Ansatz. Dieser hatte jedoch den Nachteil nicht unbedingt schnell zum Ziel zu gelangen. Warum konnte es nicht eine Programmiersprache geben, die schnell und sauber war? Das beste von beiden Welten - vereint in einer Sprache.
Aus dem Feld der agilen Softwareentwicklung rund um Martin Fowler sah Heinemeier Hansson immer häufiger die Nennung von Ruby, welches bisher hauptsächlich im asiatischen Bereich zum Einsatz kam. Als dann noch ein Freund ihn aufforderte doch einmal Ruby anstatt PHP einzusetzen, wurde Ruby näher unter die Lupe genommen. Nach nur einer Woche stand fest, dass Ruby der richtige Kandidat war, um Basecamp umzusetzen. Jetzt fehlte nur noch ein Template-Sytstem, welches Heinemeier Hansson nutzen wollte, um die Arbeit mit Ruby zu vereinfachen.
Knappe Zeit und ein kleines Team als Vorteil für die Entwicklung
Die Entwicklung von Basecamp und der Gleichzeitigen Erschaffung des Ruby on Rails Frameworks (oder wie Heinemeier Hansson es nennt: “Template”-System) war eine sehr zeitkritische Angelegenheit. Heinemeier Hansson verfolgte hauptsächlich sein Bachelor-Studium und das Team von 37signals hatten jede Menge Kundenaufträge abzuarbeiten. Das Duo aus Basecamp und Ruby on Rails musste quasi neben der Alltagsarbeit entstehen.
Außerdem war der Zeitunterschied von 8 Stunden zwischen Dänemark und Chicago ein weiteres Problem. Es waren keine großen Feature-Meetings möglich bei der wenigen Zeit, die beiden Parteien zur Verfügung stand. Der Vorteil war jedoch, dass das Entwicklungsteam überschaubar war. Mit zwei Designern und Heinemeier Hansson als Programmierer gab es nur ein kleines und somit leicht zu koordinierendes Team. Der geplanter Zeitaufwand für Basecamp war nichtsdestotrotz eine Herausforderung: 2-Mann-Monate.
Die Philosophie der Einfachheit
Durch die knappe Zeit musste sich das Team auf die wichtigsten Features beschränken. Nur was absolut nötig war, sollte implementiert werden. Dieser Ansatz wurde kein Nachteil der entstehenden Applikation, sondern deren Vorteil. Das Wichtige hervorheben, in dem man das Unwichtige weglässt. Dies wurde zum Grundsatz des gesamten Projektes und später auch der ganzen Firma: Weniger ist mehr!
Achten sie nicht was sie hier an Code sehen. Achten sie vielmehr darauf was sie nicht sehen!
Rails basiert stark auf den Grundsätzen sich nicht zu wiederholen und lieber Konventionen zu nutzen, als bestimmte Bausteine immer wieder aufwändig per Hand zusammensetzen zu müssen. Letzteres ist zwar flexibler und viele sehen auch hier den Nachteil von Ruby on Rails, jedoch ist es in 80-90% der Anwendungsfälle genau das Richtige und zeitlich gesehen die produktivste Methode.
Parallelen mit Apple
Was überflüssig ist, kann weggelassen werden. Reduktion auf das Wichtigste, ohne Schnörkel, Spielereien und Sonderfälle. Konzentration auf das, was die meisten Menschen an dem Produkt schätzen werden. Dieser Ansatz ist nicht nur ein Ansatz für eine Art des Programmierens. Auch Apple begeht diesen Weg mit seinen Produkten. Wie viele Knöpfe gibt es am iPhone, wie viele Einstellungsmöglichkeiten beim iPod? Apple Produkte sind simple, und sehen aus wie aus einem Guss, ohne viel Zusatz. Keep it simple.
Heinemeier Hansson ist bekennender Apple-Fan. Es ist möglich, dass die Firma aus Cuppertino ebenfalls unterschwellig einen Einfluss auf die Festlegung der Prioritäten bei der Rails-Entwicklung hatte. Heinemeier Hansson sagt sogar in einem Interview, dass Ruby on Rails wahrscheinlich nicht entstanden wäre, wenn er nicht auf einem Mac gearbeitet hätte. Wie groß dieser Einfluss ist oder war, ist natürlich reine Spekulation, aber er hat bestimmt seine Rolle bei der Entwicklung gespielt.
Ruby on Rails wiederum hat definitiv bei Apple Anklang gefunden. Schließlich ist das Framework in der neuesten Version von OS X schon mit integriert und kann schnell und einfach benutzt werden, ohne etwas zu installieren.
Der Werdegang von David Heinemeier Hanson
2005 zog der damals 26 jährige Heinemeier Hansson nach seinem Abschluss an der Kopenhagener Business School nach Chicago, um Vollzeit mit dem Team von 37signals an weitere Produkten wie z.B. Highrise, Backpack oder Campfire zu arbeiten, die alle auf Ruby on Rails aufbauen. Er war Co-Autor von Büchern wie z.B. “Agile Webdevelopment with Rails” und ist Stammgast bei den verschiedenen Rails-Konferenzen rund um den Globus (z.B. Rails Conf 2008).
Interessant ist dabei auch zu sehen, wie sich sein Vortragsstiel verändert hat: Vom Informatik-Liebhaber zum American Business Man (hinter den beiden letzten Links verbergen sich zwei Videos, die man sich nicht entgehen lassen sollte).
Ruby on Rails gibt es mittlerweile in Version 2.0 und wird von einer Gruppe rund um Heinemeier Hansson weiterentwickelt. Dabei bleibt Heinemeier Hansson seinem Grundsatz treu: “Ich übersehe lieber aus Versehen einen guten Patch, als dass ich drei schlechte aufnehme”.
