Neu: Das englische Ruby on Rails 4.0 Buch.

3.1. Einleitung

Nachdem Sie sich mit Kapitel 2, Ruby-Grundlagen mühsam in die Ruby-Grundlagen eingelesen haben, können wir jetzt spannender weitermachen. In diesem Kapitel starten wir ein erstes Rails-Projekt und arbeiten uns damit Stück für Stück in die Materie ein.
Auch in diesem Kapitel wird es manchmal hoppla-hopp zugehen. Wir stoßen auf typische Henne-Ei-Probleme.

Arbeits-Umgebung (Development)

Rails kennt drei verschiedene Arbeits-Umgebungen (Environments):
  • Development
  • Test
  • Production
Wir arbeiten in diesem Kapitel nur mit der Development-Umgebung. Sobald Sie ein besseres Gefühl für Rails bekommen haben, beginnen wir mit Tests und benötigen dafür die entsprechende Umgebung (dort wird z. B. beim Start eines Tests die Test-Datenbank neu gefüllt und danach gelöscht). Später erkläre ich Ihnen dann die verschiedenen Szenarien, wie Sie Ihre Rails-Applikation aus der Development-Umgebung in die Production-Umgebung ausrollen können.
Die Development-Umgebung bringt bis auf einen Editor und einen Webbrowser alles mit, was Sie zum Entwickeln benötigen. So müssen Sie nicht extra einen Webserver installieren, sondern können den eingebauten Rails-Webserver benutzen. Der besticht nicht durch extreme Performance, aber das benötigen wir bei der Entwicklung ja auch nicht. Später kann man dann auf große Webserver wie Apache umsteigen. Das Gleiche gilt für die Datenbank.
Um in der Development-Umgebung zu arbeiten, müssen Sie erst mal nichts verändern – alle Befehle arbeiten per Default.

SQLite-3-Datenbank

Auch bei der Datenbank geht es in diesem Kapitel nicht um optimale Performance, sondern um einen einfachen Einstieg. Deshalb benutzen wir die SQLite-3-Datenbank. Dafür haben Sie bereits alles fertig installiert und müssen sich um nichts kümmern. Später erkläre ich Ihnen dann, wie Sie andere Datenbanken (z. B. MySQL) ansteuern können.

Warum alles auf Englisch?

Ganz tief im Herzen liebt Rails die englische Sprache. Das ist fast ein wenig ironisch, weil der Erfinder David Heinemeier Hansson (DHH) ja aus Dänemark stammt (er lebt und arbeitet heute in Chicago).
Rails' Liebe zur englischen Sprache muss man akzeptieren und sollte sogar versuchen, sie zu übernehmen. Vieles wird dadurch einfacher und logischer. Ein Großteil des Codes ist dann fast normal zu lesen. So verwenden sehr viele Mechanismen automagisch Plural oder Singular von englischen Wörtern. Wenn man sich damit anfreundet, Datenbank-Felder und -Tabellen mit englischen Begriffen zu benennen, dann kann man die ganze Macht dieser Magie ausnutzen. Diesen Mechanismus nennt man Inflector [18] oder Inflections (Beugungen/Flexionen[19]).
Im Buch verwende ich für Variablen, Klassen und Methoden englische Namen. Die Kommentare sind auf Deutsch geschrieben. Falls Sie bei internationalen Projekten mitmachen, sollten Sie logischerweise auch die Kommentare auf Englisch schreiben. Ja, ja, … gut geschriebener Code braucht keine Kommentare. ;-)