Einführung und Überblick in die Webentwicklung mit Ruby on Rails

Rails erweitern

Sollte das per Konvention vorgegebene Defaultverhalten von Rails im konkreten Fall nicht den eigenen Bedürfnissen entsprechen, kann Rails angepasst werden. Oft besteht bereits die Möglichkeit, die Konvention per Konfiguration anzupassen. Darüber hinaus können eigene Generatoren oder Plug-ins entwickelt werden. Eine ganze Reihe von Beispielen findet sich auf der Rails-Homepage. Letztlich erlaubt die Sprache Ruby die Änderung und Erweiterung aller Klassen (auch der Ruby-Core- und -Standard-Bibliothek) um domainspezifische Features. Dabei wird keine neue Klasse durch Vererbung erzeugt, sondern die bestehende Klasse nachträglich angepasst. Auch Rails macht hiervon starken Gebrauch, was zu aussagekräftigem Code wie z.B. dem Folgenden führt:

# the ruby way :
time = 2.days.from_now
time = 14.minutes.later
time = 7.hours.ago
Entwicklungsumgebung

Rails und Ruby sind für alle gängigen Plattformen erhältlich und für die Installation findet sich ausreichend Dokumentation im Internet. Außerdem existieren eine Reihe von Installationshilfen wie InstantRails für Windows oder Locomotive für Mac OS usw. Für die Entwicklung werden eine Datenbank, ein Browser, ein Editor und ein Webserver benötigt. Rails liefert den in Ruby geschriebenen Webserver Webrick mit aus, der sofort lauffähig ist und sich für die Entwicklung anbietet. Mittlerweile ist aber auch Lighttpd für die lokale Entwicklung sehr beliebt. Unter Mac OS hat sich Textmate als Editor etabliert, unter Linux gibt es z.B. jEdit und für Windows gibt es u.a. RadRails.
Eine IDE (wie z.B. Eclipse) die hilft, komplexe APIs, XML-Konfigurationen, umfangreichen Quellcode usw. vor dem Entwickler zu verbergen, wird bei Rails nicht benötigt. Ruby und Rails lassen erst keine Komplexität und Kompliziertheit aufkommen. Und wann haben Sie das letzte Mal eine professionelle, kommerzielle Webanwendung mit einem einfachen Editor erstellt?

Produktion

So weit, so gut. Aber taugt Rails auch für richtige, produktive und kommerzielle Anwendungen? Was wird für eine Produktionsumgebung benötigt? Wie steht es um die Performanz? Skalieren die Anwendungen denn überhaupt? Und eignet sich eine dynamisch typisierte Sprache für große Anwendungen oder ist die Gefahr von Laufzeitfehlern einfach zu groß?
Eine typische Rails-Anwendung läuft entweder unter Apache oder Light-tpd in Verbindung mit FastCGI. Im Gegensatz zu gewöhnlichem CGI bleiben bei FastCGI die Prozesse im Speicher, sodass keine Performanzverluste durch den Neustart des Prozesses erfolgen. Außerdem können FastCGI-Prozesse auf einem anderen Rechner als dem des Webservers laufen, wodurch die Skalierung der Anwendung gewährleistet wird.
Es gibt mittlerweile eine Reihe auf Rails basierender Webanwendungen. Eine Liste von Beispielen findet sich auf der Rails-Hompage oder auf der deutschen Rails User Group. Teilweise haben diese Anwendungen über 100.000 Nutzer und liefern mehr als 1 Million Page Impressions pro Tag aus. Bei allen Anwendungen ist die Performanz mehr als ausreichend und kann durch entsprechende Skalierung den Anforderungen angepasst werden. Selbst wenn im Vergleich zu einer Java-Anwendung tatsächlich ein oder zwei weitere Server benötigt werden, der Preis hierfür wird durch die geringeren Entwicklungskosten mehr als wettgemacht. Es wird sich sicher der ein oder andere Punkt gegen den Einsatz von Rails finden lassen, aber Performanz gehört mit einiger Sicherheit nicht dazu.

Deployment

Für das Deployment auf die verschiedenen Rechner (Web-, Applikation-, Datenbankserver) steht das Ruby-Programm Capistrano zur Verfügung. Einmal für das Projekt konfiguriert, erfolgt das Deployment auf alle oder ausgewählte Rechner mit einem Befehl. Capistrano kann dabei Aufgaben wie Auschecken der letzten Revision, Erzeugen der Wartungsseite, das Herunter- und Hochfahren der FastCgi-Prozesse, die Datenbankmigration usw. durchführen. Die Erweiterung um einige Tasks ist möglich.
Der Einsatz einer dynamisch typisierten Sprache für eine kommerzielle Anwendung hat den Autoren am Beginn Sorge bereitet. Zu häufig hörten wir von Typfehlern zur Laufzeit und damit dem K.o. für professionelle Anwendungen. Aber wie viele andere sind auch wir eines Besseren belehrt worden. Unserer Erfahrung nach ist die Fehlerhäufigkeit in einer Anwendung nicht abhängig vom Einsatz einer dynamisch oder statisch typisierten Sprache, sondern alleine von der Entwicklung eines umfangreichen und guten Netzes an Tests. Und hier bietet Rails eine optimale Unterstützung.

Konventionen über Konfiguration

Wie beschrieben kommt Rails im Vergleich zu anderen (Web-)Frameworks ohne umfangreiche Konfiguration aus. Statt dem Entwickler möglichst viele Freiheiten durch die Konfiguration des Frameworks bzw. seiner Anwendung zu geben, definiert Rails per Konvention ein Defaultverhalten und schränkt den Entwickler damit ein. Was sich zunächst wie ein Nachteil anhört, stellt sich schnell als Vorteil heraus. Der Entwickler wird nämlich davon befreit, sich um immer wiederkehrende Punkte zur Konfigurationen oder Struktur seines Projekts zu kümmern. Die Lösungen sind per Konventionen vorgegeben. Wo andere Frameworks teils umfangreiche und häufig fehleranfällige (XML-)Konfigurationen nutzen, regelt Rails dies über Konventionen, die das Entwicklerleben deutlich einfacher machen.

Alles aus einem Guss

Während bei der Entwicklung von Webanwendung in Java unterschiedliche Frameworks wie z.B. Struts, JSF, Spring, Hibernate usw. zum Einsatz kommen, erhält man bei Rails alles aus einem Guss. Die einzelnen Frameworks sind auch unabhängig voneinander verwendbar, bilden aber im Zusammenspiel eine homogene Einheit. Für die Programmierung wird neben HTML und CSS ausschließlich Ruby eingesetzt. Von der „Logik“ in den Views über die Controller, die Modelle bis hin zur Beschreibung der Datenbankschemata und der Daten. Auch dies befreit vom Umdenken zwischen unterschiedlichen Frameworks und der Integration der einzelnen Frameworks.

Feedback und Agilität

Ein weiterer wichtiger Punkt ist das Feedback, welches uns bei Rails auf verschiedenen Ebenen begegnet. Aufgrund der dynamischen Typisierung von Ruby entfallen die Kompilierung und das Deployment in einen Webserver. Während der Entwicklung erhält man durch ein einfaches Reload im Browser ein ummittelbares Feedback auf Änderungen im Model, Controller oder View.
Die effiziente Entwicklung gepaart mit Scaffolding (s.u.) ermöglicht eine ständig lauffähige Anwendung. Vorausgesetzt der Kunde spielt mit, können Anforderungen auf diese Weise direkt am Live-System erarbeitet werden, was zu einem sofortigen Feedback führt. Ein unschätzbaren Vorteil, den wir Autoren in unseren Projekten schon mehrfach erlebt haben.
Ebenso erlauben die einfachen Unit Tests für alle Komponenten ein schnelles Feedback. Durch die saubere MVC-Architektur, die konsequente Einhaltung des DRY-Prinzips, die wenige bis gar nicht vorhandene Konfiguration, den wenigen Code und die hohe Testbarkeit ist die Anwendung sehr gut auf Änderungen vorbereitet. Rails unterstützt damit im hohen Maße die agile Softwareentwicklung.

Wo lauern Probleme?

Ein Problem bei der Verwendung von Rails könnte die Integration in eine bestehende Infrastruktur sein. Müssen viele Drittsysteme angebunden werden, so ist dies aktuell über Web Service oder per C-Anbindung möglich. Die Anbindung an Java, z.B. über JRuby ist im Gange. Die Performanz ist hier sicher nicht optimal, aber es wird daran gearbeitet.
Ebenso kann die Anbindung einer bestehenden Datenbank problematisch sein, wenn diese wenig oder gar nicht dem Active-Record-Muster entspricht. Ruby und Rails sind zwar sehr flexibel, aber alles hat seine Grenzen.
Ein oft angeführter Punkt ist das Thema Ruby, Rails und Standards. Keine Frage, Standards sind sinnvoll. Werden diese jedoch auf Basis von Theorie festgelegt, fehlt es ihnen häufig an Praxistauglichkeit. Standards haben vor allem dann den optimalen Nutzen, wenn sie aus der praktischen Erfahrung entstanden sind. Für einige Bereiche in Ruby und Rails (z.B. Internationalisierung) fehlt diese Erfahrung jedoch. Daher sind Standards zum jetzigen Zeitpunkt verfrüht, mittel- bis langfristig aber auf jeden Fall notwendig und wünschenswert. Das ist jedoch kein Grund, mit dem Einsatz von Rails zu warten.

Reaktionen aus der Java-Welt

Die Konzepte von Rails haben Spuren hinterlassen. Projekte wie Trails oder Grails versuchen, die Ideen und Prinzipien von Rails in die Java-Welt zu portieren. Dies ist mit Sicherheit sinnvoll. Eine Reduzierung der umfangreichen und oft fehleranfälligen (XML)-Konfigurationsdateien ist sicher mehr als hilfreich. Das DRY-Prinzip konsequent umzusetzen ist kein Rails-spezifisches Thema, sondern hat Allgemeingültigkeit. Ebenso die Testbarkeit der Anwendung durch das Framework von vornherein zu unterstützen. Die Handhabung komplexer Low-Level APIs durch einfachere Schnittstellen zu erleichtern ist ebenso überall wünschenswert.
Allerdings wird eine statisch typisierte Sprache wie Java niemals eine solch effiziente Entwicklung ermöglicht, wie dies mit einer dynamischen Sprache wie Ruby möglich ist. Da Rails einen Großteil seiner Qualität durch Ruby gewinnt, wird Rails diesen Vorteil gegenüber Java-Web-Frameworks immer besitzen. Möglich, dass sich hier durch den Standardisierungsprozess JSR 292 sich in Zukunft einiges bewegt (Standard zur Ausführung von dynamischen (Skript-)Sprachen in der JVM). Es ist ohnehin fraglich, ob der Einsatz einer statisch typisierten Sprache für die Entwicklung einer Webanwendung wirklich sinnvoll ist. Vielleicht ist eine Kombination aus Java und Ruby für die Zukunft denkbar.
Häufig hört oder liest man die Frage, ob Rails oder Ruby eine „Gefahr“ für JEE bzw. JEE-Welt darstellt. Hintergrund der Diskussion ist sicher auch die Befürchtung, dass das eigene (Java-)Know-how in Zukunft weniger gefragt ist und der eigene Marktwert sinkt. Dies ist für die Autoren aber keine Frage von Rails, Ruby und Java. Sie stellt sich im schnelllebigen IT-Bereich eigentlich ständig und ist eher eine Frage der persönlichen Einstellung. Die Autoren haben selbst lange Jahre im JEE-Bereich gearbeitet und sehen Rails und Ruby nicht als Gefahr für sich, sondern als weiteres sehr gutes Werkzeug in ihrem Werkzeugkoffer. Sie sind froh über Rails, da das Framework eine Lücke zwischen eher schneller Entwicklung mit PHP und eher sauberer Architektur mit Java schließt. Außerdem bieten neue Entwicklungen immer auch die Möglichkeit, die eigene Arbeit (z.B. mit Java) aufs Neue zu reflektieren und zu verbessern.

Fazit

Wer sich einmal etwas intensiver mit Ruby on Rails beschäftigt hat, wird so einfach nicht mehr loskommen. Durch die konsequente Umsetzung der Konzepte und durch die Verwendung von Ruby und seinen Möglichkeiten führt Rails zu einer Konzentration auf das Wesentliche, nämlich die Umsetzung der Geschäftslogik. Die bei anderen Frameworks und Sprachen notwendige Auseinandersetzung mit technischen Details, Konfigurationen und Deployment werden erheblich reduziert. Wird die einfache Testbarkeit der Anwendungen entsprechend genutzt, ist eine wartbare und langlebige Webanwendung das Ergebnis. Die Performanz und Skalierung ist für den Großteil aller Webanwendungen mehr als ausreichend und stellen kein K.o.-Kriterium dar. Bei einer Integration von Rails in die bestehende Infrastruktur ist sicher ein genauerer Blick auf die Möglichkeiten der Anbindung sinnvoll.
Um Rails ist ein großer Hype entstanden, aber zu Recht. Wenn die Welt ein weiteres Web-Framework braucht, dann ist es Ruby on Rails. Jedenfalls lautet das Fazit der Autoren nach eineinhalb Jahren Rails: In Punkto effiziente und saubere Entwicklung, Performanz und Skalierung und damit letztlich Kosten ist Ruby on Rails für den Großteil aller Webanwendungen mehr als nur eine Alternative. Mit Ruby on Rails war Unproduktivität gestern.

Thomas Baustert und Ralf Wirdemann sind freiberufliche Berater und Coaches aus Hamburg. Sie sind Autoren des Buches „Rapid Web Development mit Ruby on Rails“ (Hanser, 2006) und haben mehrere kommerzielle Rails-Anwendungen entwickelt sowie Tutorials und Workshops zum Thema Ruby on Rails durchgeführt. Für eine Kontaktaufnahme stehen sie unter info[at]b-simple.de jederzeit gerne zur Verfügung (s.a. Homepage der Autoren).
Kommentare
  1. Michael Beierl2016-10-28 23:26:00

    Ich bin begeistert - habe geschafft meine erste Seite zu erstellen....

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.