JRuby on Rails

Aus der Java-Welt sind wir mit großen IDEs wie Eclipse oder IntelliJ IDEA verwöhnt - hat man doch eine große Anzahl an Funktionen, die dem Entwickler viele Standardaufgaben abnehmen und aktiv beim Programmieren unterstützen. Das geht dank der dynamischen Natur von Ruby dort nicht so einfach, es gibt aber Ansätze, zumindest Teile der erreichten Bequemlichkeit von Java-IDEs auch für Ruby-Entwickler zur Verfügung zu stellen. So auch JetBrains RubyMine 1.0, das an IntelliJ anlehnt und seit gestern verfügbar ist.

Viele von Euch haben sicherlich schon eine Ausgabe des RailsWay Magazins in den Händen gehabt und die interessanten Ruby, JRuby und Rails Artikel gelesen.

Die Macher des Magazins stehen auch hinter der ersten RailsWay Konferenz. Die RailsWayCon 2009 findet vom 25. - 27. Mai in Berlin statt. In der aktuellen Ausgabe des Magazins und auf www.railswayconference.com kann man sich die beeindruckende Liste der internationalen Referenten und Vortragsthemen ansehen. Wir sind gespannt, welche Neuigkeiten und coole Erfahrungen uns dort begegnen.

Für die Verwaltung der Änderungen an der Datenbank gibt es in Rails das mächtige Konzept der Migrationsskripte. Da dies Ruby-Skripte sind, steht einem der volle Funktionsumfang von Ruby und Rails zur Verfügung. Allerdings benötigt man zum Durchführen einer Migration eine Rails-Umgebung mit Zugriff auf die Datenbank, in der man die Migrationsskripte ausführen kann. Während der Entwicklung ist das keine Hürde, aber bereits in Test- und spätestens in Produktionsumgebungen könnte das zum Problem werden.

Besonders wenn man Rails mittels JRuby in eine Java-Umgebung eingeführt hat, wird in der Produktionsumgebung auf der Konsole kein Rails verfügbar sein. Viele Unternehmen reglementieren zudem den Zugriff auf die Datenbank, so dass Entwickler die Produktionsdatenbank nicht erreichen können oder die Zugangsdaten nicht kennen. Die Anwendung kann aber auf die Datenbank zugreifen - warum nicht die Migration über die Anwendung auslösen?

Seit gestern kann man JRuby auch bei dem in der "Ruby on Rails" Gemeinde weit verbreiteten und bekannten GitHub Repository herunterladen. Das wird, wie Nick Sieger in seinem Blog mitteilt (JRuby Moves to Git), durch die erfolgreiche Umstellung der JRuby Entwicklung auf das freie verteilte Versionskontrollsystem Git ermöglicht.

Googles Web-Hosting-Plattform "AppEngine" erweitert sein Sprachangebot und unterstützt jetzt Java-Anwendungen und alle Sprachen, die auf Javas virtueller Maschine laufen. Der Weg ist also frei für JRuby.

Wie man seine JRuby on Rails-Anwendung auf Googles "AppEngine" zum Laufen bringt, zeigt Ola Bini ausführlich in seinem Blogeintrag "JRuby on Rails on Google App Engine".
Google App Engine und JRuby on Rails
Seriously this time, the new language on App Engine: Java™
Google integriert Java in AppEngine

Anhand verschiedener Ansätze zur Performanceoptimierung zeigt Charles Nutter in seinem Blog (How JRuby Makes Ruby Fast), dass Ruby und JRuby sehr wohl schnell sein können. Allerdings ist die Optimierung der Performance unter Beibehaltung der Kompatibilität deutlich schwieriger.
Die mit dem relativ einfachen „tak"-Benchmark gemessenen Ergebnisse zeigen z.B. von Ruby 1.8.6 auf 1.9.1 eine Steigerung der Performance um den Faktor 5. Ein JRuby 1.3 ohne jegliche Optimierung kann allerdings 30-50% schlechter sein als Ruby 1.8.6. Nach zwei Optimierungsschritten ist es allerdings bereits besser als Ruby 1.9.1, mit leichten Einschnitten bei der Kompatibilität wird es fast dreimal so schnell.
Wie erwähnt, die Zahlen gelten für „tak". Inwieweit sie in der Realität erreichbar sind, steht auf einem anderen Blatt. Mit Charles' aktueller Spielsprache Duby, deren Code ähnlich wie Ruby aussieht, läuft „tak" übrigens zwei Zehnerpotenzen schneller...

Anlass des Artikels war ein Post über MacRuby mit Angaben zur Performance von MacRuby 0.5. Die konstruktive Kritik wurde bereits berücksichtigt. Charles Nutters Blog
Antonio Cangianos Blog
MacRuby

DB-Konfiguration im Team - JRuby mit JNDI

Rails stellt einen einfachen Zugriff auf alle Konfigurationsdaten zur Verfügung. So stehen auch unsere Datenbank-Zugänge in der database.yml. Dies ist wunderbar, wenn man schnell ein Projekt aufsetzen will und anschließend allein mit seinem eigenen Webserver entwickelt. Doch was ist, wenn ein etwas größeres Team an einer Anwendung entwickeln möchte, aber nicht jedes Mitglied ein Login-Passwort Paar der Art "test" - "test" auf seiner lokalen Test-Datenbank vergeben möchte?
Hier bietet Doug Alcorn eine elegante Lösung, in dem er Blöcke innerhalb der YAML-Datei verwendet: Er definiert einen Standard-Loginblock, den er dann in die jeweilige Datenbank-Konfiguration für Development, Test und Production einfließen lässt. Allerdings wird vorher noch der Inhalt einer zweiten Datei eingefügt, die jeder Entwickler in sein config-Verzeichnis legen kann. In dieser kann der Loginblock beliebig überschrieben werden.