Ruby on Rails wird zehn Jahre alt

Inhaltsverzeichnis

Das Webframework Ruby on Rails feiert sein zehnjähriges Bestehen. Dazu erscheint nun mit Rails 4.2 das zweite Minor-Release in diesem Jahr. Es bringt iterative Verbesserungen und einige neue Features mit.

Nachdem Rails vor einigen Jahren durch progressive Ansätze fast schon eine Revolution in der Welt der Webentwicklung auslöste und damit unzählige Nachahmer fand, wurde es in den letzten Jahren etwas ruhiger um das Framework. Es hat sich mittlerweile als Standard etabliert, an dem Alternativen und Nachahmer – auch aus anderen Sprachen – gemessen werden. Dieser Artikel blickt auf die Meilensteine und Verdienste des Frameworks zurück und wagt einen Ausblick, wie die Fahrt auf Schienen weitergeht.

Wie alles anfing

Die dynamische Programmiersprache Ruby war unter westlichen Entwicklern bis 2004 noch weitgehend unbekannt. Erste Popularität erlangte sie zwar durch das Buch der Pragmatic Programmers (wegen des Titelbilds unter dem Namen "Pickaxe" bekannt), richtig bekannt wurde die Sprache jedoch erst, als David Heinemeier Hansson (auch bekannt als DHH) 2004 die erste Version von Ruby on Rails quelloffen bereitstellte und damit einiges an Aufsehen erregte.

Das Framework entsprang aus der Entwicklung der Projektmanagement-Software Basecamp von 37signals (heute ebenfalls: Basecamp), der Firma, in der DHH bis heute als Partner agiert. Dadurch dass Rails aus der Entwicklung einer realen Webanwendung extrahiert wurde, war es von Beginn an durch einen starken Pragmatismus geprägt. Anwender des Frameworks sollten sich nicht weiter damit beschäftigen müssen, wo sie welchen Quellcode ablegen und wie sie ihre Konfiguration verwalten. Gepaart mit der Syntax und den Sprachmitteln von Ruby sollte das für eine bis zu diesem Zeitpunkt unbekannte Produktivität in der Entwicklung von Webanwendungen sorgen.

Letzten Endes sorgte DHH dann mit dem berühmten Screencast "Creating a Weblog in 15 Minutes" für einen Paukenschlag unter Webentwicklern: In dem Video führte er eindrucksvoll vor, wie schnell sich mit Ruby on Rails lauffähige Webanwendungen erstellen lassen. Wichtiger jedoch als die Möglichkeit, mit einer Demo zu beeindrucken, war und sind jedoch immer die grundlegenden Entwurfsprinzipien, denen das Framework folgt.

"It's all about managing complexity"

Steve Jobs hatte 1997 in seiner Abschlussrede zur WWDC vom Komplexitätsmanagement in der Softwareentwicklung gesprochen. Dieses spielt auch heute noch eine wichtige Rolle. Wartbarer Programmcode sollte cleverem Code stets vorgezogen werden – Rails begegnet diesem Credo mit den Prinzipien "Don't repeat yourself" (DRY) und "Convention over Configuration". Die beiden Konzepte stehen im Mittelpunkt der gesamten Entwicklung und haben das Framework in seiner Evolution geprägt.

Das DRY-Prinzip wurde zum ersten Mal 1999 in dem Buch "The Pragmatic Programmer" erwähnt. Es besagt, dass innerhalb eines Systems jeglicher Zustand nur eine eindeutige, verbindliche Darstellung besitzt. Durch Befolgen dieses Prinzips lassen sich Redundanzen und Code-Duplizierungen vermeiden. Bei Rails können deswegen Entwickler Änderungen isoliert und einmalig an zentraler Stelle vornehmen. Zum Beispiel gibt es keine Duplikation zwischen den Spalten einer Datenbanktabelle und den Attributen von Ruby-Objekten, die für die Verarbeitung von Tabellenzeilen zum Einsatz kommen.

Das Prinzip "Convention over Configuration" ist damit eng verzahnt. Es definiert Regeln und Konventionen, durch die sich Entwickler bei der täglichen Arbeit auf die wesentlichen Aufgaben fokussieren können sollen, ohne jedoch die Freiheit einzuschränken. Halten sie sich an diese Regeln, entfällt oder vereinfacht sich die Konfiguration und erlaubt ihnen die zügige Umsetzung von Anforderungen. DHH begründet das Prinzip mit der Aussage, dass Menschen für sie getroffene Entscheidungen bevorzugen, statt sie selbst immer wieder neu zu fällen.

Dieser Sachverhalt lässt sich wieder gut mit dem objektrelationalen Mapping von ActiveRecord erläutern. Modellklassen werden in Rails per Konvention immer im Singular bezeichnet (z. B. "customer"), Instanzen der jeweiligen Klasse hingegen auf eine Datenbanktabelle mit einem Namen im Plural abgebildet ("customers"). Ein weiteres Zusammenspiel stellt die Verwendung von Datenbankrelationen dar: Das Framework erwartet hier standardmäßig eine Fremdschlüsselspalte mit dem Namen "customer_id" und versucht, die Relation über die Datenbanktabelle "customers" mit der Spalte "id" aufzulösen.

Für das beschriebene Verhalten ist keine explizite Konfiguration notwendig. Sollte das Standardverhalten nicht ausreichen oder nicht den Anforderungen entsprechen, lässt es sich einfach anpassen und zentral überschreiben.

Shared Tool, Shared Solution

Früher lebten viele Entwickler in dem Glauben, sie bräuchten für ihre Anwendungsfälle Spezialwerkzeuge, um ihre spezifischen Anforderungen umzusetzen. Das Rails Framework hingegen ist kein Spezialwerkzeug, sondern eher ein Standardbaukasten für die Webentwicklung. Erprobte Techniken sollen die Antwort auf sich oft ähnelnde Fragen und Anforderungen bieten.

So wächst das Framework seit dem ersten Release um Techniken für wiederkehrende Problemstellungen. Das Core-Team ist der Meinung, dass Webanwendungen meist Daten persistieren. Daher ist die Persistenzschicht in Form von ActiveRecord Teil des Frameworks. Seit Version 3.1 bietet die sogenannte Asset-Pipeline eine Methode zum Preprocessing sowie zur Zusammenführung und Minifizierung von JavaScript- und Stylesheet-Dateien – eben weil eine solche Funktion häufig benötigt wird. Das Vorgehen spiegelt sich auch in der anstehenden Veröffentlichung der Version 4.2 durch die Einführung einer generischen API für Hintergrundprozesse wider.