Ralph von der Heyden

Transkript

1 Westfälische Wilhelms-Universität Münster Ausarbeitung Ruby on Rails im Rahmen des Seminars Ausgewählte Themen des Softwareengineering Ralph von der Heyden Themensteller: Prof. Dr. Herbert Kuchen Betreuer: Christian Arndt Institut für Wirtschaftsinformatik Praktische Informatik in der Wirtschaft

2 Inhaltsverzeichnis 1 Einleitung 1 2 Grundlegender Aufbau 2 3 Ruby on Rails Komponenten ActiveRecord ActionController ActionView Scaffolds Das Rails Testsystem Bewertung 21 Literaturverzeichnis 23 i

3 Kapitel 1: Einleitung 1 Einleitung Gängige Web-Frameworks sind vielschichtig und setzen sich aus zahlreichen Bestandteilen zusammen. Es müssen Template-Systeme, JavaScript-Frameworks, Datenbank- Abstraktionsschichten und weitere Komponenten integriert werden. Der Lern- und Konfigurationsaufwand für solche Systeme ist enorm. Ruby on Rails versteht sich als Gegenstück zu solchen schwergewichtigen Web-Frameworks. Es erhebt den Anspruch, die Entwicklung von Webapplikationen schneller und leichter zu gestalten, indem der Konfigurationsaufwand minimiert wird. Dabei ist Rails ein relativ junges Webentwicklungs-Framework. Trotzdem hat es sich in kurzer Zeit sehr schnell verbreitet. Laut [OR06] stiegen die Verkaufszahlen für Ruby-Bücher zwischen dem 2. Quartal 2005 und dem entsprechenden Quartal 2006 um fast 700%. Ein Großteil dieser Entwicklung wird Rails zugerechnet, das zu dieser Zeit geradezu einen Hype ausgelöst hat. Auch im Bericht zum ersten Quartal 2007 [OR07] wurde Ruby on Rails als das am schnellsten wachsende Themengebiet der Kategorien Programmiersprachen und Webentwicklung genannt. Diese interessante Entwicklung legt nahe, sich genauer mit dem Framework zu beschäftigen und die Stärken und Schwächen herauszuarbeiten. Zunächst werden die Grundlagen von Rails erläutert. Das umfasst die Programmiersprache Ruby und die grundlegende Architektur jeder Rails-Applikation. In einem zweiten Schritt werden die wichtigsten Bestandteile von Rails beleuchtet. Zunächst werden die Kernkomponenten ActiveRecord, ActionView und ActionController vorgestellt. Anschließend wird auf Rails-Besonderheiten wie den Scaffolder und das integrierte Testsystem eingegangen. Im Schlussteil werden die Stärken und Schwächen von Rails im Vergleich zu den Alternativen reflektiert und bewertet. 1

4 Kapitel 2: Grundlegender Aufbau 2 Grundlegender Aufbau Ruby on Rails ist ein quelloffenes Webentwicklungs-Framework, das sein Augenmerk besonders auf die Entwicklungsgeschwindigkeit und die Wartbarkeit von Webapplikationen richtet. Um dieses Ziel zu erreichen, werden verschiedene Mittel eingesetzt. Rails wurde in der im Vergleich zu Java wenig verbreiteten Programmiersprache Ruby geschrieben. Ruby ist ebenfalls quelloffen und wurde 1995 von dem Japaner Yukihiro Matsumoto veröffentlicht. Die Sprache zeichnet sich durch besonders gut lesbaren Quellcode aus. Die Entwickler von Ruby haben die Sprache mit dem Ziel entworfen, eher für den Menschen als für den Rechner ausgerichtet zu sein. Es wird also zu Gunsten der Lesbarkeit auf Ausführungsgeschwindigkeit verzichtet. Dieser Schritt wird durch die stetig sinkenden Kosten für Rechenkapazität begründet, während die Kosten für Software-Entwickler eher konstant sind. Die Ruby-Entwickler nennen ihr Konzept Principle of Least Surprise (POLS). Es soll dazu führen, dass Entwickler während ihrer Tätigkeit nicht durch ein unerwartetes Verhalten der Sprache irritiert werden. Das POLS findet Ausdruck in zahlreichen Programmierkonventionen. Grundsätzlich werden Variablen in Ruby mit Kleinbuchstaben benannt und Wörter mit Unterstrichen getrennt. Klassenvariablen beginnen mit (z. on rails), Objektattribute beginnen mit Zeichen on rails) und heißen im Ruby-Jargon Instanzvariablen. Klassen werden im so genannten CamelCase benannt. Dabei werden alle Wörter groß und zusammen geschrieben, eine Trennung durch Unterstriche gibt es nicht (z. B. NewspaperArticle). Die Ruby-Konventionen fordern zusätzlich, dass eine Funktion, die einen Boolean zurückliefert, immer mit einem Fragezeichen enden muss (z. B. article.is published?). Destruktive Aktionen, wie z. B. das Löschen eines Objekts, sollen dagegen mit einem Ausrufezeichen enden. Weiterhin gibt es Konventionen für den Einsatz von Whitespace, damit die Formatierung des Quelltexts einheitlich wirkt. Ruby ist vollständig objektorientiert, das heißt es gibt keine primitiven Datentypen. Es handelt sich um eine interpretierte Sprache, der Interpreter und die Standard-Bibliothek sind unter allen gängigen Betriebssystemen verfügbar. [Th05] Das Rails-Framework ist nach einer klassischen MVC-Architektur (Model, View, Controller) aufgebaut. MVC ist ein Architekturmuster, das beim Software-Engineering verwendet wird, um eine Applikation in drei Komponenten aufzuteilen. Die Anwendung dieses Musters soll zu einer sinnvollen und sauberen Modularisierung des Quellcodes und somit zu einer besseren Wartbarkeit der Software führen. Die Funktionalität der drei Komponenten ist wie folgt unterteilt: Das Modell repräsentiert 2

5 Kapitel 2: Grundlegender Aufbau den inneren Zustand der Applikation, indem es die verwalteten Daten kapselt. Es stellt Methoden zum Auslesen und Verändern der Daten bereit. Weiterhin können Modelle Logik enthalten, um z. B. gewisse Anforderungen an die Daten sicherzustellen. Dadurch sind die Daten immer in einem konsistenten Zustand. Die View bzw. die Ansicht ist eine Repräsentation des Modells für den Benutzer. Es wird auf die Daten des Modells zugegriffen, um diese in einem ansprechenden Format anzuzeigen. Dabei kann es auch verschiedene Sichten auf die selben Daten geben, z. B. für verschiedene Benutzergruppen. Controller sorgen für die Steuerung der Anwendung. Sie nehmen Benutzereingaben entgegen und kommunizieren mit dem Modell. Anschließend wird dem Benutzer wiederum eine geeignete Ansicht gezeigt. [Fr04, S. 529 ff.] Auch Rails erzwingt eine MVC-Struktur für jede damit entwickelte Anwendung. Die drei Komponenten müssen als separate Funktionsbereiche entwickelt werden. Um das Integrieren von Modell, View und Controller so einfach wie möglich zu gestalten, werden jedoch keine umfangreichen Konfigurationsdateien benötigt. Es gibt dagegen durchdachte Vorgaben, mit deren Hilfe zusammengehörige Komponenten verknüpft werden. Diese Vorgehensweise ist ein Beispiel für die Rails-Philosophie Konvention über Konfiguration. Es muss zum Beispiel nicht definiert werden, in welcher Datenbank-Tabelle eine Modell gespeichert wird. Rails ermittelt den Tabellennamen aus dem Namen des Modells und stellt automatisch die Verbindung her. Der Einsatz solcher Namenskonventionen kommt dem natürlichsprachlichen Denken des Entwicklers entgegen. Weiterhin wird der Umfang des Quellcodes reduziert. Trotzdem ist es jederzeit möglich, sich über die Konventionen hinwegzusetzen. Ein weiteres Konzept in der Rails-Philosophie ist das DRY-Prinzip. DRY steht für Don t Repeat Yourself und bedeutet, dass jedes Quellcodefragment nur einmal ein einer Stelle auftauchen sollte. Der Entwickler wird dazu gezwungen, den Quellcode sinnvoll zu strukturieren. Die Rails-Konventionen und eine vorgegebene Verzeichnisstruktur erleichtern diese Aufgabe. Muss eine Funktion der Applikation geändert werden, ist oft ein Eingriff an nur einer Stelle des Quellcodes notwendig. [Th06, S. 11 ff.] Das Bearbeiten eingehender Anfragen geschieht mit Rails wie folgt: Eine Anfrage ist immer an eine Aktionsmethode eines bestimmten Controllers, genannt Action gerichtet. Der Controller nimmt die Anfrage entgegen und reicht sie an die entsprechende Action weiter. Die Action greift wiederum über das Modell auf die Daten in der Datenbank zu. Nachdem die Bearbeitung abgeschlossen ist, wird eine Repräsentation der Daten an den Client geschickt. Das Aussehen dieser Repräsentation wird durch die View bestimmt (Vgl. Abb. 1). 3

6 Client (Browser, NewsReader, WebService-Client...) 1 Controller: Action (Geschäftslogik) 4 3 2a View (Repräsentation der Daten in HTML, XML, JavaScript...) Model (ORM-Abstraktion der Daten in der DB) 2b Daten im RDBMS Abbildung 1: Verarbeitung einer Anfrage durch die MVC-Architektur von Rails. Quelle: in Anlehnung an [Th06, S. 12 f]. 3 Ruby on Rails Komponenten 3.1 ActiveRecord ActiveRecord ist die ORM-Schicht des Ruby on Rails Frameworks. ORM steht für Object-Relational-Mapping und bezeichnet das Abbilden von Datenbanktabellen auf Klassen sowie von Tabellenzeilen auf Objekte. Die einzelnen Attribute der Objekte entsprechen dann einer speziellen Zeilen-Spalten-Kombination in der Tabelle. Vom Datenbank-Management-System wird dabei abstrahiert. Es kann also während der Entwicklung gegen das Produkt eines anderen Herstellers ausgetauscht werden. Die Operationen zum Zugriff auf die Daten können in das so genannte CRUD- Schema einsortiert werden. Die einzelnen Buchstaben des Akronyms CRUD stehen für Create, Read, Update und Delete. Es wird also festgelegt, ob eine Funktion neue Datensätze anlegt oder bestehende Datensätze liest, verändert oder löscht. ActiveRecord stellt für alle Operationen des CRUD-Schemas objektorientierte Methoden zur Verfügung.[Th06, S. 200 ff.] Rails geht davon aus, dass Tabellen- und Spaltennamen 4

7 wie Ruby-Variablen benannt sind. Der Name der Tabelle ist der Plural des Namens der Modellklasse. Rails kann automatisch nur den englischen Plural bilden, kennt dafür allerdings auch den unregelmäßigen Plural vieler Begriffe. Dateinamen sind ebenfalls wie Variablen benannt. Da alle Controller und Modelle Klassen sind, werden sie nach den Ruby-Namenskonventionen im Camel Case geschrieben. Sollen z. B. mehrere Zeitungsartikel verwaltet werden, ergeben sich folgende Namenskonventionen: [Th06, S. 191 ff.] Klassenname des Modells: NewspaperArticle Dateiname der Modellklasse: newspaper article.rb Name der Tabelle: newspaper articles Rails geht davon aus, dass die Datenbankverbindung konfiguriert und die oben genannte Tabelle angelegt ist. Ist dies der Fall, stehen sämtliche Spalten der Tabelle als Modellattribute zur Verfügung. Für das Mapping der Modellattribute auf die Spalten der Tabelle (ORM) ist dadurch keine Konfiguration erforderlich. Rails weiß durch die Namenskonventionen, auf welche Tabellen und Spalten ein Modell zugreifen möchte. Die Attributnamen des Modells entsprechen den Spaltennamen, die Typen der Attribute werden automatisch aus den SQL-Typen gebildet. Sollte es mit dieser Art der Assoziation zu Problemen kommen, beispielsweise durch einen unbekannten, unregelmäßigen Plural oder weil bestehende Datenbanktabellen verwendet werden, dann können die von Rails gebildeten Datentypen sowie Spaltenund Tabellennamen überschrieben werden.[th06, S. 191 ff.] Die folgende Tabelle ist ein mögliches Beispiel für eine einfache Artikelverwaltung: id:int title:varchar(255) description:text created at:datetime 1 Mein Titel Eine lange Beschreibung :08:07 2 Ein weiterer Titel Sehr viel Text :27:48 Tabelle 1: Tabelle newspaper articles in der relationalen Datenbank Die Modellklasse kann mit Hilfe eines UML-Diagramms visualisiert werden. Der folgende Ausschnitt aus der Software-Architektur entspricht dem Modell mit der oben genannten Tabelle: Das Modell einer einfachen Artikelverwaltung benötigt durch die Konventionen nur sehr wenig Quelltext. Es muss als eine Spezifikationsvererbung von der Klasse ActiveRecord abgeleitet werden. Eine weitere Konfiguration ist an dieser Stelle nicht erforderlich.[th06, S. 200.] 5

8 NewspaperArticle title: String description: String created_at: Time Abbildung 2: UML-Darstellung des Beispielmodells class NewspaperArticle < ActiveRecord::Base end Weiterhin sorgt ActiveRecord dafür, dass bestimmte Anforderungen an die Daten immer erfüllt sind. So kann z. B. sichergestellt werden, dass eine Postleitzahl immer aus fünf Ziffern besteht. Die Validierung findet automatisch beim Anlegen oder Verändern der Datensätze statt. Sie kann auch manuell aufgerufen werden, z. B. wenn sich die Anforderungen an die Daten verändert haben. Da das Anlegen von Zeitungsartikeln nur Sinn macht, wenn Titel und Text vorhanden sind, sollte die Präsenz dieser Attribute sichergestellt werden:[th06, S. 261 ff.] class NewspaperArticle < ActiveRecord::Base validates presence of :title, :description end Mit ActiveRecord lassen sich auch Beziehungen zwischen Tabellen abbilden. Grundsätzlich sind 1:1, 1:n und n:m Beziehungen möglich, die in den jeweiligen Modellen definiert werden. Das Definieren von Assoziationen geschieht mit Hilfe der Schlüsselwörter has one, has many, belongs to und has and belongs to many im Modell. Der Name der Fremdschlüsselspalte bildet sich in diesem Fall aus dem Namen des fremden Modells in Variablenschreibweise mit dem Suffix id. Um die Zeitungsartikel z. B. einer bestimmten Kategorie zuordnen zu können, ist folgender Code erforderlich:[th06, S. 224 ff.] In der Datei app/models/newspaper article.rb: class NewspaperArticle < ActiveRecord::Base belongs to :category end In der Datei app/models/category.rb: class Category < ActiveRecord::Base has many :newspaper articles end 6

9 Der newspaper articles-tabelle ist zusätzlich die Spalte category id hinzuzufügen. Ist die Fremdschlüssel-Spalte vorhanden und ausgefüllt, kann von dem einen Modell auf das andere über objektorientierte Methoden zugegriffen werden. Z. B. liefert my newspaper article.category die zu einem Artikel gehörende Kategorie, my category.newspaper articles ein Array der zu einer Kategorie gehörenden Zeitungsartikel. ActiveRecord füllt einige Datenbankspalten automatisch aus. Unter anderem wird in jeder Tabelle eine Spalte id erwartet, um die Objektidentität sicherzustellen. Auch die Fremdschlüsselreferenz other model id wird automatisch ausgefüllt, sobald eine Assoziation zwischen Objekten hergestellt wird. Weiterhin werden automatisch Zeitstempel gespeichert, wenn eine oder mehrere der Spalten created at, created on, updated at oder updated on vorhanden sind. Dabei beziehen sich die Spalten mit dem Namenspräfix created auf den Erstellungszeitpunkt, die Spalten mit dem Präfix updated auf den Zeitpunkt der letzten Aktualisierung. Das Suffix at erzeugt einen Zeitstempel mit Datum und Uhrzeit, während sich das Suffix on auf das Datum beschränkt. Ist die Spalte child model count vorhanden, wird die Anzahl der Kindobjekte eines Modells gespeichert. Diese Vorgehensweise vermeidet einen zusätzlichen Zugriff auf die Kindtabelle, wenn nur die Anzahl und sonst keine weitere Information benötigt wird.[th06, S. 290.] Die Spalte lock version wird zur Anwendung eines optimistischen Sperrverfahrens verwendet. Greifen z. B. zwei Prozesse lesend auf die selben Daten zu, liegen zwei transiente Kopien dieser Daten im Speicher vor. Sobald ein Prozess eine Änderung dieser Daten durchführt und die Daten zurückspeichert, sind die transienten Daten des anderen Prozesses veraltet. Der noch laufende Prozess kann nicht erkennen, dass die Daten in der Zwischenzeit von einem weiteren Prozess verändert wurden und überschreibt die bereits erfolgten Änderungen mit eigenen Daten. Dieser Umstand wird auch Racing Condition genannt, da der zuletzt schreibende Prozess die vorigen Prozesse verdrängt. Ein optimistisches Sperrverfahren schließt solche Kollisionen nicht von vornherein aus, bietet aber Mechanismen zu deren Erkennung. Falls in einer Tabelle die Spalte lock version vorhanden ist, wird sie beim Anlegen neuer Daten mit 0 initialisiert und bei jeder Änderung inkrementiert. Beim Speichern wird der Zähler des transienten Objekts mit dem Zähler in der Datenbank verglichen. Kommt es zu einer Racing Condition, kann diese erkannt und eine Exception ausgelöst werden.[th06, S. 221 ff.] Desweiteren wird die Spalte position ausgefüllt, wenn das Modell die Anweisung acts as list enthält. Diese Anweisung sorgt dafür, dass sich die Objekte des Modells wie Einträge einer Liste verhalten. Rails stellt in diesem Fall Methoden 7

10 zur Verfügung, um einzelne Objekte innerhalb der Liste zu verschieben oder die benachbarten Objekte zurückzuliefern. Die Listenpositionen können global für alle Objekte oder unter dem Einflussbereich eines Elternobjekts, z. B. einer Kategorie, gespeichert werden. Ähnlich funktioniert die Spalte parent id, wenn die Anweisung acts as tree im Modell vorhanden ist. In diesem Fall verhalten sich die Modellobjekte zueinander wie die Knoten eines Baumes. Es sind Methoden zum Zugriff auf das Kindknoten-Array, den Elternknoten und die Wurzel vorhanden. Damit zum Bestimmen der Anzahl der Kindknoten nicht der gesamte Baum durchgesehen werden muss, wird die Spalte children count automatisch ausgefüllt und genutzt, falls sie vorhanden ist.[th06, S. 249 ff.] Bei der objektorientierten Programmierung werden häufig komplexe Datentypen verwendet. Diese bestehen aus mehreren primitiven Datentypen, die wiederum atomar sind und sich nicht weiter unterteilen lassen. Da relationale Datenbanken nur ein begrenztes Spektrum an Datentypen haben, muss die ORM-Schicht in der Lage sein, komplexe Datentypen auf elementare Tabellenspalten abzubilden und umgekehrt. Die Behandlung komplexer Datentypen geschieht in Rails im Modell. Im komplexen Datentyp müssen Getter- und Setter-Methoden für sämtliche in der Datenbank zu speichernden Attribute vorhanden sein. Im Modell wird der Zusammenhang zwischen dem komplexen Datentyp und den Tabellenspalten mit der Deklaration composed of hergestellt. 01 class NewspaperArticle < ActiveRecord::Base 02 composed of :title, 03 :class name => Title, 04 :mapping => 05 [ 06 [:main title, :main], 07 [:sub title, :sub] 08 ] 09 end Die genannte Deklaration erwartet bis zu drei Parameter. Der erste Parameter ist obligatorisch und und bestimmt den Attributnamen des zusammengesetzten Datentyps. Falls der Attributname mit dem Klassennamen identisch ist, kann der zweite Parameter entfallen, andernfalls muss der Klassenname angegeben werden. Der dritte Parameter ist ein Array aus Zuordnungen zwischen Tabellenspalten und Attributen des komplexen Datentyps. Er muss ebenfalls nur angegeben werden, wenn die Attributnamen von den Spaltennamen abweichen. Nachdem die composed of- 8

11 Deklaration eingefügt wurde, kann auf den komplexen Datentyp nach dem Muster model.complex datatype.elementary datatype zugegeriffen werden.[th06, S. 253 ff.] Weiterhin besteht die Möglichkeit, strukturierte Daten wie Arrays zu serialisieren. Dazu wird eine String-Repräsentation der Daten in der Datenbank gespeichert. Das Serialisieren beim Schreiben und Lesen kann automatisch erfolgen, so dass der Zugriff für den Programmierer vollkommen transparent ist. Das Speichern strukturierter Daten widerspricht jedoch der ersten Normalform, da die Attribute einer Relation in diesem Fall keinen atomaren Wertebereich haben. Das Serialisieren ist also so weit wie möglich zu vermeiden.[th06, S. 205 ff.] Eine weitere objektorientierte Technik ist die Vererbung. Die Anzahl und der Typ der zu speichernden Attribute ist innerhalb der Vererbungshierarchie variabel, so dass grundsätzlich mehrere Möglichkeiten zum Speichern der Objekte verschiedener Klassen existieren. Bei der Single Table Inheritance (STI) werden sämtliche Objekte aller Klassen einer Vererbungshierarchie in einer Tabelle gespeichert. Ist ein Attribut in einer Klasse nicht vorhanden, so wird die entsprechende Spalte der Tabelle nicht ausgefüllt. Die STI ist einfach zu realisieren und bietet sich für Vererbungsstrukturen von geringem Umfang an. Datenbankabfragen sind sehr performant, dafür enthält die Tabelle zahlreiche nicht ausgefüllte Felder und verschwendet somit Speicherplatz. Als eine weitere Möglichkeit kann für jede konkrete Klasse eine separate Tabelle angelegt werden, die außer den eigenen Attributen auch alle Attribute der Oberklasse enthält. Die Performance entspricht in diesem Fall der STI, jedoch sind die Attribute der Oberklasse in mehreren Tabellen vorhanden. Wenn eine konkrete Oberklasse vorliegt, werden zusätzlich die Daten redundant gespeichert. Bei Modifikationen müssen so zahlreiche Tabellen und Klassen angepasst werden. Die dritte Möglichkeit ist das Anlegen einer individuellen Tabelle für sämtliche abstrakten und konkreten Klassen, die jeweils nur die eigenen Attribute enthält. Da dieser Entwurf sehr nah am objektorientierten Konzept der Vererbung liegt, sind Änderungen in der Oberklasse mit minimalem Aufwand durchzuführen. Bei Abfragen müssen die Daten jedoch aus zahlreichen Tabellen zusammengefügt werden, so dass die Performance deutlich schlechter ist als bei den anderen beiden Möglichkeiten.[Ba00, S ff.] Rails selbst unterstützt nur die STI. Wenn ActiveRecord-Klassen vererbt werden, erwartet Rails in der Datenbank die Spalte type, die den Datentyp des gespeicherten Objekts enthält. Beim Anlegen neuer Objekte wird die Spalte automatisch ausgefüllt. Bei dieser Umsetzung ist es nicht möglich, dass zwei Unterklassen ein Attribut mit dem selben Namen bei gleichzeitig unterschiedlichem Typ verwenden, da beide Attribute auf die selbe Tabellenspalte abgebildet werden.[th06, S. 258 ff.] 9

12 3.2 ActionController ActionController ist der Teil von Rails, der Anfragen von Clients entgegennimmt und weiterverarbeitet. In einer Rails-Applikation existieren eine globale Controller- Klasse und zahlreiche spezifische Controller, die intern eine starke Kohäsion aufweisen. Es ist z. B. sinnvoll, für die Ressource Zeitungsartikel einen eigenen Controller anzulegen. Laut [VH06, S. 120 f.] sollten Klassen immer eine eng zusammengehörige Funktionalität bieten, da sie auf diese Weise übersichtlich und fokussiert bleiben. Die Methoden eines Controllers werden im Rails-Jargon Actions genannt. Öffentliche Actions können direkt über URLs aufgerufen werden, geschützte Actions stehen nur Controller-intern zur Verfügung. Eine eingehende Anfrage muss immer einer bestimmten Controller-Action-Kombination entsprechen. Diese Zuordnung wird in der Routing-Karte einer Rails-Applikation konfiguriert. Die Routing-Karte ist eine Konfigurationsdatei, die eine Liste möglicher URLs und den dafür verantwortlichen Controller-Action-Kombinationen enthält. Für jede eingehende Anfrage wird die Liste von oben nach unten abgearbeitet und der erste zutreffende Eintrag gewählt. Weniger spezifische Einträge sollten sich also am Ende der Liste befinden. In der Standardkonfiguration erwartet Rails eine URL nach dem folgenden Schema: aufgerufene URL: Eintrag in der Routing-Karte: map.connect ':controller/:action/:id' Abbildung 3: URLs werden auf Controller und Actions abgebildet Der erste Teil nach der Adresse des Servers bestimmt den Controller, der die Anfrage bearbeitet. Sie wird in diesem Fall an den NewspaperArticlesController weitergeleitet. Der nächste Teil show ist für die Action innerhalb des Controllers verantwortlich. Der letzte Teil ist die id des Zeitungsartikels, der angezeigt wird. Er wird als Parameter an die gewählte Action übergeben. Sämtliche Parameter der URL sind optional, wenn kein weiter rechts liegender Parameter angegeben ist. Es 10

13 kann z. B. der Parameter id wegfallen, wenn die Action angegeben ist, nicht jedoch die Action, wenn die URL noch einen Parameter id enthält. Ansonsten wird die id für den Namen der auszuführenden Action gehalten und ein Fehler ausgegeben, weil keine solche Action vorhanden ist. Es kann Actions geben, die keine weiteren Parameter benötigen, wie z. B. new zum Anlegen neuer Zeitungsartikel. Ist nur der Controller, jedoch keine Action angegeben, dann wird automatisch die Action index des Controllers ausgeführt. Das Fehlen eines Controllers wird explizit in der Routing-Karte mit einem Eintrag behandelt, der in der Prioritätenliste vor dem allgemeinen Routing-Eintrag liegt. Für diesen Fall kann eine bestimmte Controller- Action-Kombination ausgewählt werden. Individuelle Routen werden neben der Anzahl der Parameter auch durch die Art der Parameter identifiziert. Durch reguläre Ausdrücke kann z. B. ein Datum in der URL erkannt und die Anfrage zum Zeitungsarchiv-Controller weitergeleitet werden, obwohl die URL von der Anzahl der Parameter auch auf den allgemeinen Routing- Eintrag passen würde. Eine solcher spezieller Eintrag muss in der Liste wiederum weiter vorne stehen. Die Routing-Karte wird auch zur URL-Erzeugung verwendet. Der Befehl url for gehört zur Klasse der so genannten Helfer, die den Umgang mit häufig genutzten Funktionen erleichtern sollen. Mit url for kann eine URL unter der Angabe der benötigten Parameter erzeugt werden. Der folgende Befehl erzeugt z. B. die URL zu einem bestimmten Zeitungsartikel: url for(:controller => newspaper articles, :action => show, :id => 1 ) Die URL wird dabei so einfach wie möglich gehalten. Soll zur index-action eines Controllers verlinkt werden, so enthält die erzeugte URL nur den Controller, da index die Standard-Action eines jeden Controllers ist. Falls bestimmte Parameter, z. B. der Controller weggelassen werden, dann werden die Parameter der aktuellen Anfrage verwendet. Das vereinfacht das Verlinken innerhalb eines Controllers, da nur die Action und gegebenenfalls die id angegeben werden muss. Für eine gut strukturierte Applikation mit fokussierten Actions werden Weiterleitungen benötigt. Um z. B. den Lesern einer Online-Zeitung das Kommentieren der Artikel zu ermöglichen, kann unterhalb des Artikels ein Kommentar-Formular eingebunden werden. Nach dem Abschicken des Formulars soll der Benutzer wieder die Artikelansicht mit dem eingefügten Kommentar präsentiert bekommen. Falls die Action zum Speichern des Kommentars den Browser nicht weiterleitet, wird der Artikel nach dem Abschicken unter der Adresse der add comment-action angezeigt. Betätigt der Leser die Aktualisieren-Schaltfläche seines Browsers, um die Kommentare anderer Leser zu sehen, wird der selbe Kommentar erneut an den Server übertragen. Der 11

14 Einsatz von Weiterleitungen ist also wichtig für die Konsistenz der Anwendung und der URLs. Die Action zum Speichern benötigt keine eigene View, sondern sollte den Benutzer nach dem Speichern des Kommentars auf die ursprüngliche Seite weiterleiten. Eine Weiterleitung besteht aus einem Weiterleitungsziel und einem Statuscode. headers["status"] = "301 Moved Permanently" redirect to(:action => "show", :id Das Weiterleitungsziel ist in diesem Fall die ursprüngliche Artikelansicht. Mit dem dreistelligen Statuscode teilt der Server dem Client mit, um welche Art von Antwort es sich handelt. Der Statuscode von Weiterleitungen beginnt immer mit der Ziffer 3. Handelt es sich um eine temporäre Umleitung, kann die explizite Angabe des Statuscodes entfallen.[th06, S. 281 ff.] 3.3 ActionView Nachdem eine Controller-Action ihre Bearbeitung beendet hat, muss eine Antwort an den anfragenden Client gesendet werden. Im Falle eines Webbrowsers wird das Ergebnis normalerweise in Form einer HTML-Seite präsentiert. Für das Generieren oder Rendern dieser Seite zeichnet sich ActionView verantwortlich. Die HTML- Ausgabe wird dabei aus bis zu drei Komponenten zusammengesetzt: Der Grundaufbau einer Seite ist in einem Layout gespeichert. Das umfasst diejenigen Elemente einer Internet-Seite, die sich über viele Seiten hinweg nicht ändern, z. B. die Kopfzeile oder das Navigations-Menü. Ein Layout kann für die gesamte Applikation oder pro Controller festgelegt werden. Innerhalb einer Action kann wiederum ein anderes Layout als die Standard-Auswahl des Controllers gewählt werden. Templates dagegen arbeiten auf Action-Ebene. Es gibt also pro Action ein Template, das nach dem Aufruf der Action gerendert wird. Das kann z. B. ein Formular zum Anlegen eines neuen Zeitungsartikels sein. Partielle Templates eignen sich für Seitenelemente, die mehrfach auf einer Seite und innerhalb einer Action vorkommen. Sie können z. B. angewandt werden, um dem Benutzer eine Liste veröffentlichter Zeitungsartikel zu präsentieren (siehe Abb. 4). Views sind in der Rails Verzeichnisstruktur unter app/views zusammengefasst. Innerhalb dieses Verzeichnisses gibt es weitere Verzeichnisse für Layouts, für Controllerübergreifende Templates und Partials sowie ein Verzeichnis für jeden Controller. Die Templates jeder Action werden innerhalb des Controller-Verzeichnisses gespeichert. Partials unterscheiden sich von regulären Templates, indem ihrem Dateinamen ein Unterstrich als Präfix vorangestellt ist.[th06, S. 327 ff.] 12

15 Layout Template Partial Partial Partial Abbildung 4: Gestaltungsbereich von Layout, Template und Partial Innerhalb der Templates stehen zahlreiche Helfer zur Verfügung. Besonders sind hier die Formular-Helfer hervorzuheben, die es dem Entwickler erlauben, auf einfache Art und Weise Formulare zur Eingabe oder zum Anpassen von Daten zu schreiben. Das folgende Formular ist z. B. zur Eingabe neuer Zeitungsartikel geeignet: 01 <% form for(:newspaper article, :url => newspaper articles path) do f %> 02 <p> 03 <strong><%= f.label for :title %></strong><br /> 04 <%= f.text field :title %> 05 </p> 06 <p> 07 <strong><%= f.label for :description %></strong><br /> 08 <%= f.text area :description %> 09 </p> 10 <p> 11 <%= submit tag "Abschicken"%> 12 </p> 13 <% end %> In Zeile eins wird das Formular initialisiert. Es wird ein Modell angegeben, auf 13

16 dessen Attribute sich die folgenden Formularelemente beziehen. Einzelne Formularelemente können diese Beziehung jedoch überschreiben, um z. B. die Daten eines assoziierten Objekts zu verändern. Weiterhin ist die URL anzugeben, an die die Daten per HTTP-POST geschickt werden. Zum Aufruf des Formulars muss ein neues NewspaperArticle-Objekt im Controller erzeugt werden, das in einer Instanzvariable des Controllers gespeichert wird. Es ist möglich, die Instanzvariable bei der Initialisierung anzugeben. Fehlt diese Angabe, erwartet Rails das Objekt in einer Instanzvariable, die wie das Modell in Variablenschreibweise benannt ist. Im oben genannten Beispiel muss die Modellinstanz in einer Variable article enthalten sein. In Zeile drei wird ein Textfeld für die Zeitungsartikel-Überschrift, in Zeile acht ein mehrzeiliges Textfeld für den Haupttext des Artikels definiert. Beim Laden des Formulars werden die Attributwerte des Modells in der Instanzvariablen in die entsprechenden Formularfelder übernommen. Beim Bearbeiten eines bestehenden Zeitungsartikels erscheinen die bisherigen Daten also automatisch in den entsprechenden Formularfeldern. Der Automatismus eignet sich ebenso zum Definieren von Standardwerten für neue Zeitungsartikel. Neben den bereits genannten Formularhelfern bietet Rails Unterstützung für Optionsfelder, Kontrollkästchen, Auswahllisten und weitere Formularelemente. Datumsund Uhrzeit-Felder werden durch Auswahllisten für die einzelnen Komponenten der Daten modelliert, so dass das fehleranfällige Parsen entfällt. Wie weit die möglichen Optionen in die Zukunft bzw. in die Vergangenheit reichen ist konfigurierbar. Falls bei der Validierung der Formulardaten Fehler auftreten, z. B. weil kein Titel eingegeben wurde, wird das Formular erneut angezeigt. Die fehlerhaften Felder werden durch ein umschließendes <div>-tag der Klasse fieldwitherrors markiert. Dadurch kann es mit Hilfe von CSS sichtbar gemacht werden. Zusätzlich können die bei der Validierung auftauchenden Fehler an zentraler Stelle mit einem entsprechenden Helfer zusammengefasst werden. Erst wenn die Validierung erfolgreich verläuft, können die Formulardaten in der Datenbank gespeichert werden.[th06, S. 340 ff.] Der entsprechende Code im Controller, der die Formulardaten entgegennimmt und einen neuen Zeitungsartikel erzeugt, kommt ohne Ausnahmebehandlung mit sehr wenigen Codezeilen aus: 01 def create article = NewspaperArticle.new(params[:newspaper article]) article.save 04 end Neben den Formularhelfern gibt es noch zahlreiche weitere Hilfsmethoden. For- 14

17 matierungshelfer sind für die korrekte Darstellung bestimmter Daten verantwortlich. Unter anderem können die Formatierungen der Uhrzeiten, Daten und Währungen an individuelle Bedürfnisse angepasst werden. Textbereiche können so dargestellt werden, dass Zeilenumbrüche und Absätze in der HTML-Ansicht sichtbar sind. Mit dem Seitennummerierungshelfer können die aufzulistenden Objekte in Seiten zusammengefasst werden, durch die der Benutzer mit seinem Browser blättern kann.[th06, S. 332 ff.] Neben HTML-Seiten können Views die Daten auch in beliebigen weiteren Formaten an den Client senden. Beispiele hierfür sind VCards, XML, NewsFeeds und zahlreiche weitere. Zum Erzeugen eines weiteren Formats wird normalerweise ein zusätzliches Template-System benötigt. Das Template-System muss in der Lage sein, aus einem View eine Antwort im vom Client gewünschten Format zu erzeugen.[th06, S. 367 ff.] Rails 1.2 kann in der Standarddistribution HTML, JavaScript und XML generieren. Eine Action kann dabei verschiedene Formate ausliefern. Das vom Client erwartete Format kann entweder im HTTP-Header der Anfrage enthalten oder als Suffix an den Anfragefragestring angehangen sein. Rails kümmert sich dann automatisch um die Auswahl des richtigen Templates für das geforderte Format und setzt den entsprechenden Content-Type in der Antwort an den Client.[WB07, S. 7 ff.] 3.4 Scaffolds Um schnell mit etwas Lauffähigem starten zu können, bietet Rails so genannte Code-Generatoren. Ein neues Rails-Projekt mit der Standard-Verzeichnisstruktur und sinnvollen Konfigurationsdateien kann mit einem einzigen Befehl erstellt werden. Weiterhin gibt es die Möglichkeit, ein Grundgerüst zur Bearbeitung von Daten über eine Web-Oberfläche anzulegen. Dieses Grundgerüst wird im Rails-Jargon auch Scaffold genannt. Der Scaffolder erstellt unter anderem die benötigten Klassen für das Model, den Controller und die Views. Der Entwickler kann sofort sämtliche Grundoperationen auf die zu verwaltenden Daten mit einem Webbrowser ausführen. Der erzeugte Code kann ganz normal editiert, also angepasst oder ersetzt werden. Tatsächlich läuft es meistens darauf hinaus, dass der gesamte vom Scaffolder erzeugte Code mit der Zeit ersetzt wird. Trotzdem ist der Einsatz des Scaffolders sinnvoll. Während z. B. die Aktion zum Anlegen neuer Artikel angepasst oder ersetzt wird, kann immer noch auf die übrigen Methoden, z. B. zum Löschen von Artikeln, zurückgegriffen werden. Die Entwicklung ist so insgesamt flüssiger.[th06, S. 57 ff.] 15

18 Abbildung 5: Eine mit dem Scaffolder erstellte Artikelverwaltung. 3.5 Das Rails Testsystem Um die Qualität eines Softwaresystems zu sichern, werden während der Software-- Entwicklung verschiedene automatisierte Tests durchgeführt. Unit-Tests überprüfen eine isolierte Basis-Einheit oder Komponente des Systems. Dagegen überprüfen Integrationstests das Zusammenspiel mehrerer Einheiten.[Ba97, S. 488 ff.] Im Rails- Jargon wird das Testen von Modellen als Unit-Test bezeichnet, das Testen von Controllern als funktionaler Test. Rails unterstützt den Entwickler durch Testkonventionen und so genannte Test-Helfer. Im Unterverzeichnis test werden funktionale Tests, Integrationstests, Unit-Tests, Pseudoobjekte und Testdaten, genannt Fixtures, verwaltet. Die Testdaten werden im YAML-Format (YAML Ain t Markup Language, ursprünglich Yet Another Markup Language) abgelegt. Der in den YAML-Dateien enthaltene Ruby-Code wird jedoch ausgeführt. So kann z. B. ein dynamisches Datum gesetzt werden, das vom Testzeitpunkt aus zwei Tage in der Zukunft liegt, um gewisse zeitgesteuerte Aktionen der Applikation zu testen. In jedem Test muss zunächst angegeben werden, welche Testdaten geladen werden müssen. Bei Unit- und funktionalen Tests sind das die Daten des zu testenden Modells. Wenn die Interaktion mit weiteren Modellen getestet werden soll, werden häufig zusätzliche Daten benötigt. Weiterhin gibt es in jeder Testklasse eine Setup-Methode, die vor allen in der Klasse enthaltenen Tests ausgeführt wird. Die Objekte der zu testenden Klassen können so in einen bestimmten erwarteten Zustand versetzt werden. In den konkreten Tests stellt Rails Hilfsmethoden zur Verfügung, um das Verhalten des Benutzers zu simulieren. So können GET, POST, PUT und DELETE-Anfragen gesendet und empfangene Daten analysiert oder gespeichert werden. Mit anderen Helfern kann der Zustand der während des Tests erzeugten Objekte überprüft werden. Weiterhin bietet Rails viele Zusicherungen, die in Webapplikationen häufig verwendet werden. Mit Zusicherungen oder Assertions kann spezifiziert werden, was für ein Verhalten von der Applikation auf bestimmte Benutzereingaben erwartet 16

19 wird. Unter anderem sind Assertions für Umleitungen, Statuscodes und Formulare vorhanden. Zusätzlich können die während der Tests erstellten Internetseiten über das Document Object Model (DOM) analysiert werden. DOM [Do05] ist eine vom World Wide Web Consortium (W3C) definierte Programmierschnittstelle für den Zugriff auf HTML- oder XML-Dokumente.[Th06, S. 139 ff.] Abbildung 6: Ein vom Scaffolder erstellter funktionaler Test für die Artikelverwaltung Interessant ist das Zusammenspiel der Tests mit dem Ruby-Breakpointer. Breakpoints können überall in der Applikation und auch innerhalb der Tests gesetzt werden. Trifft der Ruby-Interpreter während der Ausführung auf einen Breakpoint, dann springt er automatisch in die Breakpointer-Konsole. In dieser Konsole kann der Benutzer Ruby-Befehle ausführen und aktuell gesetzte Variablen untersuchen. So entfällt der lästige Trial-and-Error Prozess beim Debuggen, bei dem zunächst der Quelltext geändert und anschließend der Test wiederholt werden muss.[kc06] Der rake-befehl führt immer alle vorhandenen Tests aus. Das kann bei zahlreichen Tests sehr lange dauern, deshalb gibt es auch die Möglichkeit, nur einzelne Testkategorien, z. B. nur alle Unit-Tests zu durchlaufen. Da Testklassen ganz nor- 17

20 Abbildung 7: Vom Scaffolder erstellte Fixtures male Ruby-Klassen sind, kann man sie auch einzeln laufen lassen. So kann z. B. nur eine ganz bestimmte Unit-Test-Klasse ausgeführt werden. Das Ruby-Testsystem erlaubt sogar das Selektieren einzelner Tests innerhalb einer Klasse. So kann der Entwickler beim Durchlaufen der Tests zwischen besonders schnell und besonders umfassend variieren. Alternativ kann ein Continous Integration Tool wie z. B. CruiseControl [CC07] verwendet werden. Diese Programme nutzen die Leerlaufzeit des Rechners, um regelmäßig Tests auszuführen. Während dessen werden Statistiken über die durchlaufenen Tests und deren Ergebnis erstellt.[kc06] Auch beim Schreiben der Tests sollte auf ein sauberes Design geachtet werden. Oft macht es Sinn, ähnliche Tests durch das Erstellen einer eigenen Hilfsmethode zu refaktorisieren. Das Ruby-Testsystem führt nur Methoden aus, deren Name mit test beginnt. Alternativ kann vor Hilfsmethoden das Schlüsselwort protected gestellt werden, um das selbstständige Ausführen der Methode während der regulären Tests zu verhindern.[th06, S. 160 ff.] Der Rails-Scaffolder erstellt automatisch einige Tests bzw. Teststümpfe. Um die Controller zu testen, werden funktionale Tests für alle CRUD-Actions generiert. Diese müssen während der Entwicklung ergänzt und gepflegt werden, um weiterhin zu funktionieren. Sobald die Funktionalität der Applikation erweitert wird, müssen eigene Tests hinzugefügt werden. Der Scaffolder weiß nichts über Wertebereiche oder Einschränkungen der Modellattribute, deshalb werden zunächst keine Unit-Tests erstellt. Um dem Entwickler das Hinzufügen eigener Tests so einfach wie möglich zu machen, legt der Scaffolder einen so genannten Test-Stumpf an. Hierbei handelt es 18

21 Abbildung 8: Die Ausgabe des rake-befehls im sehr frühen Stadium eines Projekts sich um eine Testklasse mit einem Pseudotest, der immer erfolgreich verläuft. Sobald der Entwickler Funktionalität zur Modellklasse hinzufügen oder Wertebereiche für Attribute konfigurieren möchte, sollte er eigene Unit-Tests schreiben.[wb07, S. 28 ff.] In einem eigenen Verzeichnis können so genannte Mock-Ups oder Pseudo-Objekte untergebracht werden. Diese werden anstatt der Realen Objekte der Applikation während der Tests verwendet. Einerseits ist dieses Vorgehen sinnvoll, um Funktionalität zu testen, die von externen Applikationen abhängt. Das können Kreditkarten- Dienstleister oder Mashups wie Google Maps [GM07] oder Flickr [Fl07] sein. Andererseits können auf diese Art unfertige Teile der eigenen Applikation simuliert werden, um davon abhängige Teile vorab zu testen.[th06, S. 169 ff.] Für die Testumgebung von Rails gibt es zahlreiche Plugins, z. B. zum Überprüfen der erstellten Seiten auf valides XHTML 1.0 [Xh02]. Die in allen Tests verwendeten Plugins können in einer globalen Konfigurationsdatei aktiviert werden. Schwierig dagegen ist das Testen von AJAX-Funktionalität. AJAX steht für Asynchronous JavaScript and XML und bezeichnet ein Konzept zur asynchronen Datenübertragung zwischen einem Server und dem Browser. Dadurch ist es möglich, innerhalb einer HTML-Seite eine HTTP-Anfrage durchzuführen, ohne die Seite komplett neu laden zu müssen.[bb05, S. 14 ff.] Mit den Rails Test-Helfern lässt sich zwar die DOM- Struktur einer zurückgelieferten Seite untersuchen. Sie sind allerdings nicht in der Lage, das Ergebnis ausgeführter AJAX-Operationen in einen bereits empfangenen 19

22 Quelltext einzubauen. Für diesen Fall gibt es externe Testapplikationen, die die Anwendung unabhängig von Rails aus der Sicht eines Webbrowsers betrachten, z. B. Selenium [Se07] oder Watij [Wa07]. Alternativ gibt es das Test-Plugin ARTS (Another RJS Test System), das die vom Rails eigenen RJS-System (Ruby to JavaScript) [Fa06] erzeugten AJAX-Aufrufe testen kann. Selbst geschriebene JavaScripts können mit dem Plugin nicht überprüft werden, falls diese über die Funktionalität von RJS hinausgehen.[ar06] Insgesamt ist das Testen unter Rails aus Entwicklersicht sehr komfortabel, obwohl das Testen von AJAX-Aktionen noch wenig ausgereift ist. 20

23 Kapitel 4: Bewertung 4 Bewertung Rails ist insgesamt sehr gut zum Entwickeln dynamischer und datenbankgestützter Webapplikationen geeignet. Die Konfiguration wird auf ein Minimum begrenzt, und durch den Scaffolder sind sehr schnell Ergebnisse sichtbar. Für neue Entwickler macht sich nach den ersten Erfahrungen eine steile Lernkurve bemerkbar. Einsteiger müssen sich mit der bislang wenig verbreiteten Sprache Ruby und zahlreichen weiteren ineinander verzahnten Konzepten einarbeiten. Nachdem diese Hürde genommen ist, verläuft die Entwicklung schneller als bei den meisten anderen Frameworks zur Webentwicklung. Auch die Wartbarkeit wird nicht vernachlässigt. Durch die Konzepte DRY, Konvention über Konfiguration und die ausdrucksstarke Programmiersprache Ruby müssen mit Rails weniger LOC geschrieben werden, als mit Pendants aus dem Java- oder PHP-Bereich. Der Wartungsaufwand korreliert laut [VH06, S. 56 f.] wiederum mit der Größe des Quellcodes. Tim Bray, der wesentlich zum XML 1.0 Standard beigetragen hat und aktuell beim Java-Erfinder Sun arbeitet, sieht Rails im Vorteil gegenüber Java-Pendants. Seiner Meinung nach wird sich die Webentwicklung in Zukunft auf die Umgebungen Rails, PHP [PH07], Java [Ja07] und.net [DN07] verteilen. Einzelne Webapplikationen werden unabhängig von ihrer Implementierung über Webservices miteinander kommunizieren können. Ein Webservice ist ein Server-Dienst, der direkt mit weiteren Clients interagieren kann. Die Kommunikation geschieht über den Austausch standardisierter XML-Nachrichten. Es ist z. B. möglich, Bilder mit Geoinformationen des Fotodiensts Flickr [Fl07] auf einer Karte des Kartendiensts Google Maps [GM07] anzuzeigen. Rails unterstützt solche Webservices ab der Version 1.2 mit der Schnittstelle RESTful Rails. Dabei kann Rails sowohl von fremden Webservices gebrauch machen, als auch die eigenen Dienste als Webservice anbieten. Der Konfigurationsaufwand ist in diesem Fall minimal, für die XML-Repräsentation der Modelle müssen z. B. keine Views angelegt werden. Rails ist demnach aus der Sicht von Bray für die Zukunft gut gerüstet [Br06]. Die Rails-Entwickler sehen Rails als ein ganzheitliches Konzept, um Webapplikationen zu entwickeln. Obwohl es möglich ist, einzelne Komponenten wie Active- Record ohne die anderen Teile des Rails-Frameworks zu verwenden, sind die Bestandteile eng miteinander verknüpft. Der Einsatz eines ganzheitlichen Frameworks hat den Nachteil, dass einzelne Komponenten nicht einfach austauschbar sind. Eine mit Rails entwickelte Webapplikation ist mit dem Framework verwoben, ein Wechsel des Frameworks bedeutet das Neuschreiben der ganzen Applikation. Im Gegensatz dazu setzen sich andere Web-Frameworks eher aus mehreren unabhängig voneinander entwickelten Komponenten zusammen, wie z. B. Spring [Sp07] und Hibernate 21

24 Kapitel 4: Bewertung [Hi07] im Java-Bereich. Einzelne Komponenten sind dadurch austauschbar und weniger stark von einzelnen Herstellern abhängig. Andererseits erhält man mit Rails ein Framework aus einem Guss und einzelne Komponenten sind sehr fein aufeinander abgestimmt. Durch die Minimierung des Konfigurationsaufwands und die einheitliche Konzeption muss sich der Entwickler nicht in einzelne unabhängige Produkte hineindenken, sondern arbeitet mit einem schlüssigen Gesamtkonzept. Da einzelne Komponenten nicht einfach austauschbar sind, konzentriert sich die Arbeit zahlreicher freiwilliger und kommerzieller Entwickler auf die Verbesserung des quelloffenen Rails-Frameworks. Die MIT-Lizenz erlaubt es Benutzern, die eigenen Änderungen nicht wieder zu veröffentlichen. Dadurch wird die Hemmschwelle zur Mitarbeit niedrig gehalten, und es gehen trotzdem zahlreiche qualitativ hochwertige Patches beim Rails-Kernteam ein. Das führt wiederum zu einer hohen Qualität und einer guten Anpassungsfähigkeit an eigene Bedürfnisse. Weiterhin wurden mit Rails schon zahlreiche kommerziell erfolgreiche Softwareprojekte, wie z. B. Basecamp von 37signals [BC07] erstellt. Der Erfolg dieser Projekte unterstreicht die Praxistauglichkeit. Durch das Aufstellen allgemein gültiger Konventionen für jedes Rails-Projekt wird die Anzahl der projektinternen Konventionen gering gehalten, so dass sich neue Entwickler schnell in ein vorhandenes System einarbeiten können. Bei der Evaluation verschiedener Alternativen muss schließlich abgewogen werden, ob der Nutzen des Frameworks den Nachteil überwiegt. Die Wahrscheinlichkeit, dass das Rails- OpenSource-Projekt innerhalb der nächsten Jahre eingestellt wird oder stagniert ist als sehr gering einzuschätzen. Mit Rails entwickelte Applikationen gelten demnach als zukunftssicher. 22

25 Literaturverzeichnis Literatur [Ar06] Kevin Clark: Test Driven RJS with ARTS. URL: guide-test-driven-rjs-with-arts, [Ba97] Helmut Balzert: Lehrbuch der Software-Technik: Software-Management, Software-Qualitätssicherung und Unternehmensmodellierung, Spektrum Akademischer Verlag, [Ba00] Helmut Balzert: Lehrbuch der Software-Technik: Software-Entwicklung, Spektrum Akademischer Verlag, [BB05] Olaf Bergmann, Carsten Bormann: AJAX: Frische Ansätze für das Web- Design, SPC Teia Lehrbuch Verlag, [BC07] 37signals: Project collaboration, management, and task software: Basecamp. URL: [Br06] Tim Bray: Issues in Web Frameworks. URL: [CC07] The CruiseControl Project: CruiseControl Continuous Integration. URL: [DN07] Microsoft Corporation:.NET Framework Developer Center. URL: [Do05] World Wide Web Consortium: W3C Document Object Model. URL: [Fa06] Cody Fauser: RJS Templates for Rails, O Reilly, [Fr04] Eric Freeman, Elisabeth Freeman, Kathy Sierra, Burt Bates: Head First design patterns, O Reilly,

26 Literaturverzeichnis [Fl07] Yahoo! Inc.: Flickr API URL: [GM07] Google Inc.: Google Maps API. URL: [Hi07] JBoss, a division of Red Hat: Hibernate: Relational Persistence for Java and.net. URL: [Ja07] Sun Microsystems Inc.: Java Technology. URL: [KC06] Steve Kellock, Chris Carter: A Guide to Testing the Rails. URL: [OR06] Tim O Reilly: State of the Computer Book Market, Q206, Part 2: Category Winners and Losers, Weblog des O Reilly-Verlags. URL: state of the computer book mar 4.html, [OR07] Mike Hendrickson: State of the Computer Book Market, Q107, part 1 - Overall Market, Weblog des O Reilly-Verlags. URL: of the co 6.html, [PH07] The PHP Group: PHP: Hypertext Preprocessor. URL: [Se07] The OpenQA team: OpenQA: Selenium. URL: 24

27 Literaturverzeichnis [Sp07] The Spring project: Spring Framework. URL: [Th05] Dave Thomas, Chad Fowler, Andy Hunt: Programming Ruby: The Pragmatic Programmers Guide, Pragmatic Bookshelf, [Th06] Dave Thomas, David Heinemeier Hansson: Agile Webentwicklung mit Rails, Hanser, [VH06] Venkat Subramaniam, Andy Hunt: Practices of an Agile Developer, Pragmatic Bookshelf, [Wa07] The Watij project: Watij - Web Application Testing in Java. URL: [WB07] Ralf Wirdemann, Thomas Baustert: RESTful Rails Development, B-Simple, [Xh02] World Wide Web Consortium: XHTML 1.0 The Extensible HyperText Markup Language (Second Edition). URL: 25

28 Ich versichere hiermit, dass ich meine Diplomhausarbeit Ruby on Rails selbstständig und ohne fremde Hilfe angefertigt habe, und dass ich alle von anderen Autoren wörtlich übernommenen Stellen wie auch die sich an die Gedankengänge anderer Autoren eng anlehnenden Ausführungen meiner Arbeit besonders gekennzeichnet und die Quellen zitiert habe. Münster, den Ralph von der Heyden