Ruby on Rails and Rapid Application Development

Transkript

1

2 Ruby on Rails and Rapid Application Development Hans Hasselberg 8. Juli 2008 Inhaltsverzeichnis 1 Ruby Einleitung Objektorientiert Open-Source Multi-Paradigma interpretiert Konzepte Typen Variablen, Klassen, Objekte Blöcke Reflection, Distrubuted Ruby Bestandteile Kritik Ruby on Rails Einleitung Konzepte Model-View-Controller Don t repeat yourself Convention over Configuration Komponenten ActiveRecord Kritik agile Methoden Fazit 12 4 Quellen 12 1 Ruby 1.1 Einleitung Ruby ist ein Multi-Paradigmen, Open-Source, interpretierte und hohe Programmiersprache. Die Sprache wurde von Yukihiro Matsumoto zwischen 1993 und 1995 entwickelt, weil die 2

3 vorhandenen Programmiersprachen seinen Ansprüchen nicht genügten. Dabei orientierte er sich an zahlreichen vorhandenen Sprachen, unter anderem Smalltalk, C, C++, Java. Außerdem orientierte er sich stark an Perl(Perle), nichtnur an dem Namen Ruby(Rubin) erkennbar, den er in Anspielung darauf gewählt hat. Interessanterweise besteht noch eine andere Verbindung: Die Perle ist der Geburtsstein des Monats Juni und der Rubin von Juli. Abgesehen von der Namensverwandtschaft sind laut dem Entwickler die Klassen-Bibliotheken zwischen Perl und Ruby sehr ähnlich, bis hin zu den Variablen $ und $&, die Matsumoto inzwischen als ugly style variables bezeichnet. Am 21. Dezember 1995 veröffentlichte er die erste Version Weil Ruby nur Japanisch dokumentiert war, erlangte es auch zunächst nur in Japan an Bedeutung und hatte einen ähnlichen Stellenwert wie Perl und Python. Seit 2000 wird versucht Ruby auch im Rest der Welt zu verbreiten und seitdem existiert auch eine englische Dokumentation. Dank dieser Bemühungen gelang Ruby inzwischen zu erheblicher Bekanntheit. Die Implementierung von Yukihiro Matsumoto ist jedoch nur beispielhaft und aktuell wird Ruby in einem Open Source Projekt weiter gepflegt und von diesem wird auch das nächste große Release erwartet. In den folgen Kapiteln werde ich verschiedene Konzepte in Ruby erläutern und ein wenig auf die sprachlichen Fein- und Besonderheiten eingehen. Zuerst werde ich kurz die Ojektorientierung und die Verfügbarkeit verschiedener Paradigmen erklären, bevor ich dann Konzepte wie Typen und Klassen erläutere. Abschließ gehe ich auf die Bestandteile von Ruby ein und bewerte diese Skriptsprache Objektorientiert Wie schon erwähnt ist Ruby objektorient und zwar von Anfang an und nicht wie z.b. bei PHP, wo es erst nachträglich hinzugefügt wurde. Somit ist alles ein Objekt(und zwar im wörtlichen Sinn, denn alle Objekte in Ruby erben von der Klasse Object) und natürlich auch nil, true und false. Ein Vorteil ist, dass Informationen über Objekte direkt an ihnen abgefragt werden können z.b.: 4 2. c l a s s => Fixnum 4 2. s i z e => 4 ohne Konstrukte, wie sizeof(42), bemühen zu müssen. Ruby unterstützt natürlich auch Vererbung, ein Beispiel wird im nachfolgen Kapitel gezeigt Open-Source Yukihiro Matsumoto hat Ruby entwickelt und auch gleich beispielhaft implementiert und dann unter der GPL veröffentlicht. Wie schon erwähnt wird Ruby nun in einem Open-Source Projekt weiterentwickelt Multi-Paradigma In Ruby kann jeder Programmierer so coden, wie er es gewohnt ist. Es wird sowohl objektorientiertes und prozedurales als auch funktionale Programmieren unterstützt. Ersteres ist klar und schon im vorhergehen Abschnitt erklärt. 3

4 Prozedurales Vorgehen impliziert, dass keine Klassen erstellt werden müssen. Gelöst wurde das durch eine globale Klasse in der alle Programme gestartet werden. Dadurch wird für den Programmierer die Illusion erzeugt, ohne Klassen zu programmieren. d e f quaken quak quak quaken => quak quak Das ist schon ein vollständiges Ruby-Programm. Das Zeichen = nach einen Aufruf zeigt das Ergebnis an. Weil in Ruby jeder Ausdruck einen Wert hat, kann man auch funktional Programmieren. h e l l o = case s p r a c h e when Deutsch then H a l l o Welt when E n g l i s c h then Hello, world e l s e r a i s e Unbekannte Sprache Diese Vielseitigkeit ist für Einsteiger natürlich von Vorteil, da er seinen Programmierstil nicht zu ändern braucht. Ausserdem kann man den Stil wechseln, sobald es nötig ist, denn für bestimmte Problemstellungen ist Funktionale und andere Prozedurale prädestiniert interpretiert Ruby wird interpretiert. Dafür benutzt man einen Interpreter, der den Ruby Quellcode zur Laufzeit einliest und ausführt. Dabei wird nicht wie von Compilern direkt maschinelesebarer Code vor der Laufzeit erzeugt. Der Interpreter leistet zwar ähnliche Arbeit wie ein Compiler, jedoch erst zu Ausführungszeit, was das ganze bedeut langsamer macht. Der Vorteil von interpretierten Sprachen ist die Plattformunabhängigkeit, unter der Voraussetzung, dass der Interpreter auf der Zielplattform läuft. Ausserdem erhöht die Interpretation die Flexibilität, da unter anderem zur Laufzeit Klassen modifiziert werden können. Das betrifft dann natürlich nur die nach der Modifikation erstellten Objekte und nicht die vorher existieren. Es gibt verschiedene Lösungen zur Erhöhung der Geschwindigkeit eines Interpreters z.b.: JIT-Compiler und Bytecode. Im Gegensatz zu einem normalen Compiler übersetzt der JIT(Just in Time)-Compiler das Programm erst zur Laufzeit in Maschinencode. Diese Methode ermöglicht eine bessere Maschinencode Optimierung. Zudem werden durch Zwischenspeicherung von Maschinencode, sich wiederhole Abschnitte nicht mehrfach übersetzt. Damit ist der JIT-Compiler jedoch nicht mehr plattformunabhängig, da er Code für eine bestimmte Architektur generiert. Eine weitere Möglichkeit ist die Erzeugung von Bytecode entweder vor oder zu Laufzeit. Bytecode ist eine einfache Zwischensprache, die dann von dem Interpreter schneller ausgeführt werden kann. In diesem Fall wird der Interpreter auch Virtual Machine genannt. Dieses Verfahren wird auch in Java erfolgreich eingesetzt und ist auch für die nächste Ruby Version 1.9 geplant. Dafür wurde das Projekt YARV(Jet Another Ruby VM) in den offizielle Ruby Projekt integriert und der Entwickler von YARV arbeitet jetzt direkt für Ruby. 4

5 1.2 Konzepte Typen Vorab nochmal zur Erinnerung: in Ruby ist alles ein Objekt und Variablen müssen nicht deklariert werden. Doch das heißt nicht, dass alles generisch ist oder keine Typen existieren. Davon gibt es nämlich einige (String, Number, Range, Regular Expression,...) die jedoch nicht wie z.b. in C alleinsteh sind, sondern natürlich alle von Object erben. Diese Typen sind das Grundgerüst aller Ruby Programme und müssen deshalb besonders intuitiv zu benutzen sein und nicht nur dafür ist es praktisch, dass alle Typen von Object erben. Unter den einfachen Typen, die auch schon aus anderen Programmiersprachen bekannt sind, treten besonders die Regular Expression - die Regulären Ausdrücke - hervor. Laut Wikipedia ist das eine Zeichenkette, die der Beschreibung von Mengen beziehungsweise Untermengen von Zeichenketten mit Hilfe bestimmter syntaktischer Regeln dient. Die Regex werden für verschiedene Aufgaben verwandt, zum Filtern und als Schablone. Beim Filtern geht es darum aus einem Text eine Zeichenkette herauszusuchen und gegebenenfalls zu ersetzten, was ebenfalls mit Regex möglich ist. Weiterhin können Regex als Schablone für Zeichenketten dienen, ohne dass diese explizit angegeben wird. Die Entwickler haben die erkannt, wie nützlich die Regex sind und eine mächtig Bibliothek in Ruby integriert und dafür sogar Typen geschaffen. Die Erstellung eines Regex ist in Ruby denkbar einfach: p a t t e r n = /ˆha [ nu ] s / hans = p a t t e r n => 1 haus = p a t t e r n => 1 maus = p a t t e r n => 0 In diesem Beispiel, sieht man, wie ein Pattern erzeugt wird und mit = auf einen String angewet. Das Ergebnis entspricht unseren Erwartungen. Für die Regex gibt es zahlreiche Anwungsfälle, von der Validierung einer Eingabe bis hin zum Suchen und Ersetzten in Texten Variablen, Klassen, Objekte In Ruby können Klassen definiert und instanziert werden, wobei die Instanzen der Klassen auch Objekte genannt werden. Objekte wiederum können in Variablen gespeichert werden. In der Variable ist jedoch nie das Objekt selbst gespeichert, sondern nur ein Zeiger auf dasselbe. Das ist das gleiche Verhalten, wie in Java. Zusätzlich gibt es noch Konstanten, das sind Variablen, die ihren Wert nach der Initialisierung nicht mehr ändern. Konstanten erkennt man daran, dass der erste Buchstabe des Namens groß geschrieben ist. Im Gegensatz dazu fangen alle normalen Variablennamen mit einem kleinen Buchstaben an. Im folgen Code- Beispiel wird eine Klasse Duck und Donald erstellt, wobei Duck von Object erbt (denn das ist Fall, wenn nichts angegeben ist) und Donald von Duck. Die Vererbungsbeziehung wird in Ruby mit dem kleiner-zeichen angezeigt. 5

6 c l a s s Duck def quak quak quak c l a s s Donald < Duck def s l e e p ZZZzzzzzz donald = Donald. new donald. quak => quak quak donald. s l e e p => ZZZzzzzzz. In diesem Beispiel ist Donald eine Ente, die nicht nur quaken, sondern auch schlafen kann. Ein weiterer Bestandteil dieses Abschnittes ist Duck Typing. Duck Typing bedeutet, dass Objekte nicht anhand ihrer Klasse identifiziert werden, sondern anhand der Methoden, die es anbietet. Es gibt einen vielzitierten Ausspruch von James Whitcomb Riley: If it walks like a duck and quacks like a duck, I would call it a duck. Das führt dazu, dass Objekte nicht wie in streng typisierten Sprachen anhand ihres Typs unterschieden werden, sondern nur noch anhand der Methoden. Wie schon erwähnt unterstützt Ruby zwar Vererbung, aber keine Mehrfachvererbung. Doch es gibt einen Mechanismus um den selben Effekt zu erzielen, nämlich mithilfe von Mixins. Das sind Module, die Methoden zur Verfügung stellen und dann von mehreren Klassen inkludiert werden können Blöcke In diesem Abschnitt geht es um Code-Blöcke und zwar ist das Code, den man an Methoden sen kann. Das ist ein sehr mächtiges Feature und kann benutzt werden, um Callbacks zu implementieren, Code zu versen und Iteratoren zu erstellen. Dazu gleich mal ein kleines Beispiel, damit man sieht, was passiert. def c a l l puts s t a r t y i e l d puts c a l l { puts i n the b l o c k } s t a r t i n the b l o c k => n i l 6

7 Hier wird eine Methode call definiert, die start und zurückgibt und dazwischen steht yield, was der Platzhalter für den Block ist. Beim Aufruf von call mit einem Block(der in den geschweiften Klammern steht), wird zuerst start ausgegeben, danach yield ausgeführt und dann ausgegeben. Der Block kann zusätzlich Parameter enthalten, was dazu führt, dass er gern als Iterator benutzt wird: [ 1, 2, 3 ]. each {i p uts i } => [ 1, 2, 3 ] In der ersten Zeile wird ein Array mit dem Inhalt 1-3 erstellt und auf diesem each aufgerufen. Each wird hierfür mit dem Block { i puts i} aufgerufen, wobei zwischen den Strichen der Parameter steht und danach die Anweisung Reflection, Distrubuted Ruby Nachdem die Basis von Ruby erläutert wurde, geht es jetzt um Themen, die entweder noch nicht angesprochen oder mit Absicht übergangen wurden. Der Begin ist Reflection. Das bedeutet wörtlich die Spiegelung und bedeutet, dass Objekte Informationen über sich selbst, wie als wenn sie in den Spiegel sähen, kennen. name = hans name. respond \ t o?( r e v e r s e ) => true Das zeigt, dass das name-objekt selbst überprüfen kann, ob es eine Methode reverse besitzt. 1.3 Bestandteile Ruby besteht aus verschiedenen Komponenten, wie der Interactive-Ruby-Shell(irb), rdoc und den rubygems(gem). Die irb ist ein sehr nützliches Tool um kleine Ruby Experimente durchzuführen. Ausserdem kann man mit ihr auch debuggen, indem man in seinem Script einen breakpoint setzt, der sich wiederum in eine aktive irb einklinkt, falls vorhanden. Über die irb kann man dann auch die aktuellen Variablen zugreifen und alles machen, was man vom normalen debuggen gewöhnt ist. Zu rdoc gibt es nichts weiter zu sagen, als dass ein ganz normales Tool zum generieren von Dokumentationen ist, vergleichbar mit javadoc oder doxygen. Rubygem ist wiederum ein interessantes Tool, es ist nämlich eine Paketverwaltung für Ruby. Damit kann man alle Pakete, Plugins etc. installieren, verwalten und updaten. Es eignet sich vor allem, um die Plugins zu verwalten, die man ansonsten von unterschiedlichen Webseiten zusammen suchen müsste. 1.4 Kritik Kritik an Ruby gibt es nicht viel. Vor allem wird die Performance bemängelt und das zu Recht. Da Ruby interpretiert wird, gibt es diese Probleme. 7

8 Abbildung 1: Rails 2 Ruby on Rails 2.1 Einleitung Ruby on Rails(RoR) ist ein Web Application Framework, dass 2004 von David Heinemeier Hansson der Öffentlichkeit vorgestellt wurde. Es ist in Ruby programmiert und Open Source. Im folgen werde ich die Bezeichnungen Ruby on Rails, Rails und RoR benutzen und meine immer Ruby on Rails. Interessant ist, dass Rails aus der Webapplication Basecamp extrahiert wurde und nicht einfach entwickelt. Das liefert schonmal den Beweis der Nützlichkeit und praxisnähe, denn es stammt ja aus der Praxis. Seit Dezember 2007 gibt es Rails in der Version 2.0 die viele Neuerungen einführt. In diesem Text werde ich bemüht sein die Änderungen der neuen Version zu berücksichtigen und kennzeichne, falls das nicht möglich ist, diejenigen Eigenschaften, die die Version 1.x betrifft. Um die Funktionalität voneinander abzugrenzen wurde Rails in verschiedene Komponenten, hauptsächlich ActionPack, ActiveRecord und ActiveRessource aufgeteilt, wobei nur ActiveRecord aufgrund seiner Besonderheiten extra behandelt wird. Weiterhin gibt es in Rails die Konzepte DRY und Convention over Configuration, denen auch ein Kapitel gewidmet ist: 2.2. Bevor ich die Relevanz und Einsetzbarkeit von Rails in Projekten mit agilen Entwicklungsmethoden behandle, werde ich die Nachteile von diesem Framework erläutern. Das Bild 1 zeigt die Architektur von Rails. 8

9 Abbildung 2: Model-View-Controller 2.2 Konzepte Model-View-Controller Model-View-Controller(MVC) ist ein Architekturmuster und beschreibt die Aufteilung der Software in die drei Einheiten: Model (Datenmodell), View (Präsentation), Controller (Programmsteuerung). Abbildung 2 ist eine Abbildung des Musters, das die Komponenten und deren Beziehungen zeigt. Das Model repräsentiert in diesem Muster die Daten. Hier werden alle Anwungsdaten gespeichert und verwaltet, die im Betrieb der Application anfallen. Diese Einheit ist manchmal eng mit der Geschäftslogik verknüpft, in Rails ist das jedoch nicht der Fall. Im Gegensatz dazu ist das Model aber immer unabhängig von View und Controller.Diese Komponente wird durch ActiveRecord verwaltet. Der View ist die Ansicht, die der Nutzer auf das System hat und ist für die Anzeige der Daten aus dem Model zuständig und leitet dann Anfragen des Nutzers an den Controller weiter. Für diese Einheit ist ActionView zuständig, was ein Teil des ActionPacks ist. Der Controller ist der Kern der Anwung, hier findet die Datenverarbeitung statt. Er nimmt Benutzeraktionen vom View entgegen und reagiert entsprech. Ausserdem ist er für die Zuordnung zwischen Modell und Präsentation zuständig. In Rails ist der Controller ein Teil von ActionPack Don t repeat yourself Don t repeat yourself (DRY) bedeutet, dass man sich nicht wiederholen oder jede Information nur einmal im System vorhanden sein soll. Dieses Konzept ist relativ allgemein und findet sich auch in anderen Anwungsgebieten wieder, z.b.: in den Normalformen der Datenbank. Im Zusammenhang mit Rails bedeutet das, dass das Framework den Programmierer dabei zu unterstützen versucht. ActiveRecord bietet solche Möglichkeiten an (doch dazu mehr im Kapitel 2.3.1) und Ruby im allgemeinen. Ein weiterer Mechanismus, der dieses Konzept unterstützt ist das scaffolding(engl.: Gerüstbau). Rails stellt Generatoren zur Verfügung, die aus einem Model ein CRUD(Create-Update-Delete)-Interface erstellen. Dazu mal ein kleines Beispiel: 9

10 ruby s c r i p t / g e n e r a t e s c a f f o l d Movie t i t l e : s t r i n g Hier wird das generate-script mit dem Parameter scaffold, Movie und title:string aufgerufen. Daraus baut der Generator zuerst das Modell Movie mit dem Attribut titel, was ein String ist. Danach wird der Controller erzeugt und dann der View. Mit einem Einzeiler wird also in Rails ein CRUD-Interface erstellt, ohne sich selbst zu wiederholen, da man mit dem Generator natürlich CRUD-Interfaces für beliebig viele Modelle erstellen kann. DRY ist wichtig um Redundanz zu verhindern und Wartbarkeit und Fehlervermeidung zu unterstützen und hilf so direkt bei der Implementierung qualitativ hochwertiger Software Convention over Configuration Auch dieses Konzept ist sehr allgemein und beschreibt den Verzicht auf Konfiguration, wenn sich an die Konvention gehalten wird. Das kann man vielleicht am Beispiel eines Fahrstuhl verdeutlichen: Ein Fahrstuhl in einem Bürogebäude mit 10 Etagen wird von 98% der Mitarbeiter benutzt um in den 7. Stock zu gelangen. Wenn die Software Convention over Configuration(COC) unterstützt, würde der Fahrstuhl immer automatisch in die 7. Etage fahren, falls der Benutzer nichts anderes vorgibt. Das hat den enormen Vorteil, dass 98% der Mitarbeiter den Fahrstuhl nicht mehr konfigurieren müssen, währ für die restlichen 2% alles beim Alten bleibt. Ähnlich verhält es sich in Rails vor allem mit ActiveRecord, aber auch mit der Klassenbibliothek von Rails und den Tools, die mitgeliefert werden. Die Vorteile dieses Konzepts sind vor allem weniger Aufwand bei der Konfiguration, da die meisten Einstellungen durch Konventionen abgedeckt sind. 2.3 Komponenten ActiveRecord ActiveRecord ist das Datenbankabstraktions-Framework von Rails und basiert auf dem gleichnamigen Muster von Martin Fowler. Dieses Muster beschreibt die Abbildung der Tabellen, Zeilen und Spalten auf Klassen, Objekte und Attribute. Die nächsten Erwähnungen von ActiveRecord beziehen sich immer auf das Framework, das Teil von Rails ist und nicht auf das Pattern. ActiveRecord implementiert dieses Pattern und bietet damit die Möglichkeit leicht eine Verbindung zwischen Domäne-Objekten und der Datenbank herzustellen. Eine ActiveRecord-Klasse repräsentiert dabei eine Datenbank-Tabelle, ein Objekt eine Zeile und die Attribute des Objekts die Spalten. Im Unterschied zu Hibernate werden die Attribute nicht durch getter und setter in der Klasse definiert, sondern durch die Spalten in der Datenbank. Die Java-Implementation wäre eine DRY-Verletzung im Rails-System, weil für ein Attribut zwei Methoden benötigt werden, währ ActiveRecord zuerst die Datenbank ausliest und danach die Getter und Setter generiert. Auch hier können die Klassen zur Laufzeit erweitert werden, wie schon in... beschrieben. ActiveRecord generiert jedoch nicht nur die Getter und Setter, sondern auch spezielle Finder, die einfaches Suchen ermöglichen. Wenn zum Beispiel in der Tabelle Studenten ein Feld Name und Jahrgang existiert, so kann man den folgen Finden benutzen: Student. f i n d b y n a m e ( hans ) 10

11 Für die meisten Standartabfragen reichen diese generierten Finder vollkommen aus, zumal sie auch kombiniert werden können: Student. f i n d b y n a m e a n d j a h r g a n g ( hans, 1983) Da die meisten Methoden der Datenbank-Klassen generiert werden, ist diese Klasse meist leer. Für die Arbeit mit ActiveRecord arbeitet man häufig direkt auf der Datenbank, da das die Stelle ist, woher ActiveRecord die Informationen bezieht. So müssen unter anderem Join-Tabellen für n:m-beziehungen manuell angelegt werden. Diese Arbeitsweise betrachten einige als Nachteil im Vergleich mit Hibernate, wo man alles in den Klassen erledigen kann. Letztlich ist es jedoch nur eine Frage der Präferenz. Die Vorteile von ActiveRecord liegen jedoch auch in der einfachen Benutzung durch COC(siehe 2.2.3). In einem Rails-Projekt kann man sofort anfangen zu programmieren, da schon alles vorkonfiguriert ist, einschließlich ActiveRecord. 2.4 Kritik Die Nachteile von Rails beschränken sich hauptsächlich auf Geschwindigkeit und Performance im Vergleich zu den deutlich schnelleren HTML/PHP/JS-Lösungen. Das liegt zum Einen daran, dass Ruby interpretiert wird und andererseits an dem hohen Abstraktionsgrad, den es nicht umsonst gibt. Rails wäre nicht Rails, wenn es dafür keine Lösung gibt. Erstmal werden zwei Probleme unterschieden: Performance und Skalierbarkeit. Performance beschreibt das Antwortzeitverhalten des Systems, währ Skalierbarkeit die Eigenschaft des Systems beschreibt auch steiger Last nicht an Performance zu verlieren, bzw in einem Rahmen zu bleiben. Um performanter zu werden, unterstützt Rails verschiedene Caching Mechanismen. Caching bewirkt, dass der Server das Ergebnis einer Anfrage nicht jedesmal neu generiert, sondern beim ersten Mal speichert und es danach nur noch aus seinem Zwischenspeicher (Cache) holt. In Rails gibt es unter anderem das Seiten Caching, bei dem bestimmte - meist statische Seiten - markiert werden und nach dem ersten Erstellen direkt von Webserver zurückgeliefert werden. Ähnlich funktioniert auch das Fragment-Caching, bei dem jedoch nicht ganze Seiten, sonder nur Abschnitte markiert und gecached werden. Bezüglich dem zweiten Problem gibt es einen Ausspruch: Rails skaliert horizontal. Das bedeutet nichts weiter, als dass bei steiger Last die Anzahl der Server, die die Anfragen bearbeiten erhöht werden muss. Dafür wird ein Load-Balancer eingesetzt, der die Last auf die Server verteilt. An der Rails Applikation müssen dafür je nach System entweder keine oder nur kleine Änderungen, wie zum Beispiel an der Speicherung der Session, vorgenommen werden. 2.5 agile Methoden Dieses Kapitel behandelt, inwiefern sich Rails für die Software Entwicklung in Projekten mit agiler Vorgehensweise eignet und ob die Entwicklung mit Rails auch in großen Projekten möglich ist. Die Frage nach der generellen Eignung von Rails für die agile Entwicklung kann eindeutig bejaht werden, es ist sogar so, dass Rails nur dafür entwickelt wurde. Gegenstand vieler agiler Methoden sind die vielen Iterationen, das Prototyping und eine ständig lauffähige Version und die Kundenzufriedenheit. 11

12 Ruby on Rails ist für iteratives Vorgehen, wie schon gezeigt wurde, geeignet. Unter anderem durch die vielen Möglichkeiten die Klassen nachträglich oder zur Laufzeit zu verändern. Die Entwicklung mit Rails findet meistens featurebasiert statt, indem eins nach dem anderen implementiert wird. Schnell eine lauffähig Version einer Software zu erstellen ist mit Rails auch kein Problem durch die Umfangreiche Unterstützung durch die Generatoren und durch Convention over Configuration. Wenn es regelmäßig neue Prototypen gibt ist die Kundenzufriedenheit fast gewährleistet, da sich die Kunden die Prototypen ansehen und Änderungswünsche direkt einbringen können. Ein weiteres wichtiges Thema in der agilen Entwicklung das Testen wird ebenfalls von Rails vorbereitet indem für die benutzen Controller und Modelle initial Testscripte angelegt werden, die nur noch implementiert werden müssen. Auch hier funktioniert alles dank CoC ohne etwas zu konfigurieren. Nachdem klar ist, dass sich Rails zum Entwickeln mit agilen Methoden eignet ist die Frage, ob es skaliert in Hinsicht auf die Anzahl der Entwickler. Die Beantwortung der Frage ist nicht leicht, da es zu diesem Thema kaum Erfahrung gibt, geschweige denn Quellen. Hinweise können Erfahrungsberichte sein, die es von großen Rails-Projekten gibt, wobei deren Anzahl relativ gering ist. Der Grund dafür liegt aber eher in den Performance- und Skalierbarkeitsproblemen, die Rails hat. Doch leider gibt es keine öffentlichen Erfahrungsberichte dieser Projekte, sodass es bei Spekulationen bleibt. Spekulativ würde ich sagen, die Entwicklung mit Rails ist auch in einem großen Team möglich. Eigentlich ist es im Prinzip ja nichts anderes als bei Java oder ähnlichem. Die Entwickler bekommen Aufgaben und bearbeiten Klassen. Die Unterstützung durch Tools ist natürlich nicht so massiv wie bei Java vorhanden und das ist ein großer Nachteil. Abgesehen von diesem fallen mir jedoch keine Nachteile auf, die Rails in großen Teams haben soll. Ausgenommen natürlich die Nachteile agiler Methoden in großen Teams, die natürlich immer präsent sind, aber nichts mit Rails zu tun haben. 3 Fazit Abschließ möchte ich sagen, dass die Entwicklung mit Ruby on Rails zwar auf Web Applications beschränkt ist, mir dort aber sehr viel Spass gemacht hat. Für andere Anwungsgebiete kann man nur Ruby benutzen, was natürlich genausoviel Freude bringt. Der Spass und die Freude entstand bei mir dadurch, dass alles problemlos funktioniert hat, Ruby so einfach ist und alles klappt, wie ich es erwartet habe. Natürlich gibt es auch beim Programmieren mit Ruby on Rails Probleme, doch für diesen Fall gibt es eine freundliche Community. 4 Quellen Dave Thomas: Prorgamming Ruby 2. Auflage, The Pragmatic Programmers, 2005 Ralf Wirdemann, Thomas Baustert: Ruby on Rails 2. Auflage, Hanser, 2007 Jeremy McAnally: Ruby Book on Rails 12