Programmieren wie auf Schienen

gedacht
getan
Published

13.02.2008 22:34

Demnächst steigt die vierte Auflage des firmeninternen Kickerturniers, und ich als Ausrichter will bis dahin eine kleine Software geschrieben haben, die uns die gröbsten Arbeiten bei der Berechnung der nächsten Spiele abnimmt. Zuletzt standen immer ein paar leicht angetrunkene Entwickler vor einem Whiteboard und haben versucht, den Algorithmus im Kopf auzuführen - dies muss nicht sein. Da auch keine verfügbare Software unseren Ansprüchen genügt muss es also etwas eigenes sein.

Da ich schon immer einmal den Hype um Ruby on Rails hinterfragen wollte und das Video Lust auf mehr machte, habe ich schnell alles geladen, was die Seite bietet, eine passende IDE installiert und los ging es. Ruby on Rails ist eigentlich eine Kombination aus der Skriptsprache Ruby in Verbindung mit dem Webframework Rails. Dieses bietet von Haus aus alles, was man für eine Client-Server-Web-Software mit Datenbank-Backend benötigt: Ein objektorientiertes MVC-Schichtenmodell mit Object-Relational-Mapper und modernen Webtechniken an der Oberfläche.

Dies alleine würde heute niemandem mehr hinter dem Ofen vorlocken. Doch da sind noch die ungewöhnliche Leitmotive von Rails, “Less Software” und “Konvention statt Konfiguration”. Diese führen dazu, dass viele der häufig wiederverwendeten Code-Elemente durch die breite Palette an Codegeneratoren automatisch erzeugt werden (Controller, Donain-Stubs und sogar Formularviews für die Domainobjekte). Allerdings wird der Programmierer auch gezwungen, sich hart an diese Scaffolding-Vorgaben zu halten. Doch wer dies nicht scheut soll mit keinem anderen Framework schneller Web-Software entwickeln können. Jedenfalls hat diese Behauptung zu dem Hype um Ruby on Rails beigetragen.

Theorie und Praxis liegen jedoch wie immer nicht allzunah beieinander. Zum Einen sind Konventionen eine gute Sache, vor allem wenn mehrere Menschen an einer Software arbeiten. Doch Rails weicht an einigen Stellen von gewohnten Konventionen ab. Hibernate zum Beispiel verwendet den Namen des Domainobjektes als Tabellenbezeichner, Rails ist jedoch auf die Mehrzahl eines englischen Begriffes in der Datenbank beschränkt, während die Domainobjekte wieder zwingend Einzahl sind und Controller und Views erneut die Mehrzahl verwenden. Mein bestehendes deutsches Datenbankschema habe ich also als Erstes übersetzt, da die Bildung des Plurals im Deutschen wohl zu komplex für das Framework ist.

Zum Anderen wurden einige wichtige Konventionen mit Version 2.0 von Rails abgeändert, so dass momentan fast alle Tutorials im Netz Fehler enthalten - dies erschwert die Einarbeitung deutlich. Es fängt damit an, dass man die Standard-Datenbank von MySQL auf SQLite3 geändert hat - da man Rails aber nicht konfigurieren kann, muss man das gesamte Projekt mit rails -d mysql myapp erst wieder auf die eigene Datenbank umstellen. Die größte Veränderung ist jedoch, dass der scaffold-Generator nunmehr keine Formulare und Ansichten für die Felder des aus der DB generierten Domainmodells erzeugt (die Domainobjekte enthalten leider generell keine generierten Membervariablen). Es hat mich einige Zeit gekostet diese Verhaltensänderung, auf der alle wichtigen Anleitungen im Netz basieren, herauszufinden. Wie viele Leute werden sich noch vor den ersten Aha-Effekten von Ruby on Rails abwenden, nur weil dieses wichtige Feature für Einsteiger gestrichen wurde?

Mittlerweile geht die Entwicklung bei mir recht flüssig voran; die Oberfläche meiner kleinen Anwendung steht. Jetzt muss ich nur noch den Algorithmus implementieren. Wenn man die Einarbeitungszeit abzieht, dann ging die Umsetzung wirklich fix, weil einem Rails einiges an Arbeit abnimmt. In dieser Hinsicht ist der Hype also berechtigt. Ob das Framework aber für einen Produktiveinsatz geeignet ist kann ich noch nicht abschätzen. Im Vergleich mit dem Rivalen PHP überzeugt Rails aber aufgrund der durchgängigen Nutzung moderner Entwurfsmuster und Webtechnologien, während es dem firmeninternen Framework aufgrund des schnellen Test-Korrektur-Zyklus überlegen ist. Ich werde mich also noch etwas mit dem “Programmieren auf Schienen” beschäftigen.