CodeBlog.ch

Schon länger liest und hört man viel von Ruby, vorallem von Ruby on Rails. Man will sich als Programmierer ja schliesslich auf dem laufenden halten, so auch ich. Die Prioritäten haben den Ruby Start oft verschoben, als nun aber Redmine bei einem Projekt zum Einsatz kommen wird, und je nach Ergebnis in Zukunft auch bei anderen Projekten, wurde es doch Zeit mit Ruby on Rails zu starten!

Allgemein

Ich versuche eigentlich immer, Dinge am Anfang selber zu erforschen. Nicht das ich das Gefühl habe, dass dies zum perfekten Ergebnis führt, aber wenn man am Anfang ein paar Stunden investiert und einige Probleme ohne fremde Hilfe oder Literatur lösen kann, so versteht man die Philosophie hinter einer Technologie besser.

Bei Ruby hat auch dies bis zu einem gewissen Punkt funktioniert, bei Rails sind dann aber doch einige Fragen aufgetaucht, bei der man mindestens ein Tutorial lesen sollte. Alles der Reihe nach…

Installation

Installationsanleitungen zu Ruby und Rails gibt es zahlreiche. Leider scheint es aber immer ein paar Unterschiede bei der Installation zu geben. Ich hatte mir hier erhofft, dass eine so hoch gelobte Sprache eine ebenso solide Installationsroutine mitliefert.

Unter Windows scheint InstantRails sich bewährt zu haben. Dies mag für einen Einsteiger sehr praktisch sein, bekommt man doch gleich alles was man für den Ruby Start benötigt.

Da ich aber zu den Leuten gehöre, die nicht nur Auto fahren, sondern auch gerne verstehen wieso das Auto überhaupt fährt, wollte ich alles selber installieren. Zudem arbeite ich mit einem Debian Linux auf einem alten Mini Mac PPC, Windows läuft hier nur über QEMU und das mit einer völlig inakzeptablen Performance.

Google hat mir hier als erstes einen älteren Artikel angezeigt, der erklärt wie man Ruby mit Apache2 unter Debian installieren kann. Viele Ruby Anhänger bevorzugen lighttpd und einige, wie ich, arbeiten auch mit nginx. Apache2 war aber bereits installiert und ob nginx nun etwas weniger Speicher benötigt, lighttpd etwas schneller ist- funktionieren sollte es ja mit Apache2 auch und das ist bei einem Einstieg ja wohl die Hauptsache.

Der Artikel aus dem Jahr 2006 – http://www.technixblog.de/archives/linux/debian/tutorial-ruby-on-rails-fur-debian-sarge hat bei mir einwandfrei geklappt, abgesehen von zwei kleinen Modifikationen:

• Ich musste das rewrite Module explizit aktivieren “ln -s /etc/apache2/mods-available/rewrite.load”
• Ich musste .htaccess anpassen, und diese Zeile am Anfang einfügen: “RewriteEngine On”

Anschliessend hatte ich aber bereits eine komplett lauffähige Ruby on Rails Umgebung.

Literatur

Wie anfänglich beschrieben, funktioniert Ruby als Programmiersprache sehr intuitiv. Vieles funktioniert einfach, am besten einfach mal schreiben und schauen ob eine Fehlermeldung ausgegeben wird. Das Design der Sprache scheint wirklich durchdacht zu sein.

Bei Rails gibt es allerdings ein paar Kleinigkeiten wie zum Beispiel die Generatoren, die man einfach kennen muss. Ob man hier ein Tutorial, ein Magazin oder gleich ein Buch verwendet, sei jedem selbst überlassen.

Ich hatte mir, da ich gerade eine längere Zugfahrt vor mir hatte, das Magazin “RailsWay” gekauft. Ein paar Artikel die einen ersten Eindruck geben, viel Inhalt ist aber nicht vorhanden. Ist allerdings auch schwierig sämtliche Bedürfnisse von Rails Entwicklern abzudecken. Allerdings war im Magazin eine DVD beigelegt mit einigen PDF’s. Unteranderen das OpenBook “Praxiswissen Ruby on Rails”.

Man findet dieses Buch übrigens auch im Internet – http://www.oreilly.de/german/freebooks/rubyonrailsbasger/

Die Sprache des Autors, Denny Carl, ist einfach zu lesen und teilweise auch relativ unterhaltsam. Das Buch beginnt ziemlich am Anfang, so dass auch Personen ohne grosse Programmiererfahrung ihre ersten Schritte meistern können. Da ich mich aber doch ein Weilchen mit Programmiersprachen auseinandergesetzt habe, hab ich die ersten Seiten im Tempo eines Schnellzuges, davon kommt übrigens auch der Name “Ruby on Rails”, gelesen.

Man muss im PDF bis zur Seite 165 gehen, um den Einstieg in Rails zu finden. Ein paar Hintergrundinformationen und anschliessend ein hübsches Beispiel, das Schritt für Schritt erklärt wird. Einziger Kritikpunkt hier – der Autor bezieht sich relativ stark auf die Entwicklungsumgebung RadRails. Diese ist zwar ganz hübsch, wenn man aber wie ich alles verstehen möchte, so wäre es teilweise praktisch, wenn man die Befehlszeile auch lesen könnte. Die Generatoren von Ruby werden schliesslich standardmässig per Konsole gestartet.

Konzept / Idee von Rails

Ruby on Rails basiert einerseits auf dem MVC- und DRY-Konzept.

MVC steht für Model View und Controller und beschreibt eine Architektur von Software. Ich geh davon aus, dass dies bekannt ist, ansonsten empfehle ich an diesem Punkt ein Tutorial oder Buch zum Thema MVC zu lesen.

DRY steht für “Don’t repeat yourself”. Man soll die gleichen Dinge nicht mehrfach tun. Ganz einfach in der Theorie, Rails hat aber ein paar Tools die dieses Konzept unterstützen, wichtig an diesem Punkt ist vorallem, dass man versteht und verinnerlicht hat, dass Ruby on Rails Dinge nicht mehrfach tun möchte. So banal das klingt, so oft wird bei zahlreichen Projekten dagegeben verstossen.

Ein Beispiel: Wenn Sie mit CSS arbeiten, haben Sie sicherlich schon den Farbwert verändert, sei es die Schriftfarbe oder eine Hintergrundfarbe. Das mit das CI (Corporate Identity) stimmt, kommt diese Farbe oft an zahlreichen stellen vor, Sie schreiben also #A0B3EF ziemlich oft, CSS kennt keine Variablen. Dies mag jetzt vielleicht etwas übertrieben wirken, ist es doch wirklich kein Weltuntergang, dass man einen Farbwert mehrmals schreiben muss – einverstanden! Ruby on Rails wäre hier aber vermutlich weiter gegangen und hätte da einen anderen Weg gewählt. Nicht dass ich das wüsste, ich behaupte es lediglich! Nur zur Veranschaulichung wie und wo man Dinge doppelt tut.

Hello World

Etwas altbacken, aber ein “Hello World” gehört auch heute noch zu jedem Einsteiger Tutorial.

In der Installationsanleitung haben wir bereits ein Rails Projekt angelegt. Dazu haben wir diese Befehlszeile ausgeführt:

rails /home/rails/meineApp

Es sollte eine längere Ausgaben von Informationen angezeigt werden, und hoffentlich keine Fehler.

Wo schreiben wir nun den Code? Wie ein paar Zeilen weiteroben erwäht, Rails bietet sogenannten “Generatoren”, die einen Basis-Code automatisch generieren können. In diesem Fall kann der Befehl zum Beispiel so aussehen:

ruby script/generate controller SagHallo

Auch hier sollten erneut ein paar Zeilen angezeigt werden, die erklären welche Dateien erstellt wurden.

Adressen in Rails funktionieren generell nach diesem Prinzip:

http://server/controller/action

In unserem Fall also http://localhost/sag_hallo/sali

Den Controller haben wir ja gerade erst angelegt, was aber ist die “Action”? Ein Aufruf der Adresse zeigt uns auch gleich, dass wir da noch etwas vergessen haben:

Da fehlt eine Action! Die gehört in den Controller und ist eigentlich nicht viel mehr als eine Methode.

Action erstellt, nächster Versuch:

Auch nicht das was wir wollen! Wir arbeiten mit einem MVC Framework, wir haben bisher ja erst den Buchstaben “C” (Controller) angelegt, das “M” (Model) ist nicht zwingend, das “V” (View) hingegen schon, wir wollen ja schliesslich etwas anzeigen!

Wir erstellen also noch eine Datei:

Wenn wir nun die Seite öffnen, so sehen wir endlich etwas:

Damit die Seite nicht komplett statisch ist, hab ich noch die aktuelle Zeit ausgegeben.

Fazit

Die Installation hat etwas mehr Zeit in Anspruch genommen als geplant, ansonsten scheint Ruby on Rails wie Ruby selbst, sauber strukturiert und durchdacht aufgebaut worden zu sein.

Das praktische an Rails ist, dass man quasi zwangsweise die MVC Architektur verwenden muss. Zwang klingt negativ, ist es in diesem Fall aber selten. Ein gewisser Zwang führt dazu, dass sämtliche Entwickler “gleich arbeiten” – ob Sie wollen oder nicht.

Viele Leute vergleichen eine Programmiersprache wie “PHP” mit einem Framework wie “Ruby on Rails”. Bei diesem Punkt bin ich immer etwas skeptisch, schliesslich hat man ja schon als Kind gelernt, dass man nicht Äpfel mit Birnen vergleichen soll. PHP ohne Framework erlaubt es einen bunten Wildwuchs an Funktionen einzubauen, ohne dass man eine saubere Struktur aufbauen muss. Klar dass dann eine unschöne, umfangreiche und schlecht zu wartende Software entsteht.

Allerdings gibt es auch für Sprachen wie PHP MVC Frameworks. Mit CakePHP und CodeIgniter sind nur zwei der zahlreichen Frameworks genannt.

Positiv ans Ruby finde ich, dass Rails eigentlich fast so bekannt ist, wie Ruby selbst. Dies hat wohl dazu geführt, dass einige Programmierer die mit Ruby gestartet haben, gleich Rails verwendet haben, und so “schönere Applikationen” entwickelt haben.

Ob Ruby, PHP oder Java, mit allen Sprachen kann man gut strukturierte Software entwickeln. Ruby und Rails sind relativ moderne Technologien, so dass man sich nicht mit sämtlichen Altlasten rumschlagen muss. Dies ist sicherlich ein positiver Aspekt, ob es genügt, dass ich in Zukunft weniger C#, PHP, PL/SQL Code schreibe, wird sich zeigen.

Bis jetzt scheint es eine gute Alternative zu sein, allerdings hab ich bis jetzt noch nichts gefunden, dass ich mit anderen Sprachen nicht auch tun könnte, mit Ruby geht’s vielleicht teilweise eleganter, aber schliesslich habe ich in meiner Firma einiges an Know-How mit anderen Sprache aufgebaut, auch das ist etwas wert!