JRuby on Rails

Seit der ersten Veröffentlichung von RubyMine arbeiten wir mit dieser coolen IDE und sind sehr zufrieden. Seit einigen Wochen konnten wir nun schon Beta-Versionen des neuen Releases testen und können sagen, dass JetBrains hier nochmal richtig gute Erweiterungen geschaffen hat: Oft verwendete Ruby- und Rails-Techniken wie HAML, RSpec, Cucumber und die Rails-I18n-API werden direkt von der IDE unterstützt und die Editoren wissen noch mehr über den Aufbau der Rails-Projekte, sodass viele neue Refactorings und Code Inspections möglich wurden. Außerdem wurde die JRuby-Unterstützung verbessert - so lassen sich nun zum Beispiel auch unter Windows die gestarteten Server ohne den Umweg über den Task-Manager beenden.

Die Arbeit mit den Betas machte schon Spaß, das fertige Release freut uns um so mehr.
Zum Download geht es hier.

Erst neulich berichteten wir von Kommentaren in Erb-Files, die das Layout zerstören. Heute haben wir eine unserer Anwendungen testweise auf reinem Ruby laufen lassen und mussten hier folgenden Unterschied feststellen. Wenn man in einem Erb-File einen einzeiligen Kommentar mit
<% # comment %> oder <%- #comment %>
schreibt, geht das unter JRuby - unter Ruby aber nicht. Dort werden in merkwürdiger Weise Teile von nachfolgenden Statements abgeschnitten, sodass dann Teile des HTML-Quellcodes auf der Webseite landen. Hier sollte also nur die korrekte Form <%# comment%> verwendet werden.

Heute mal ein Bericht von einer Merkwürdigkeit, über die wir soeben gestolpert sind:

<% my_helper do #comment %>
 <div>Text</div>
 <%= function() %>
<% end %>

my_helper ist ein normaler Helper - in unserem Fall sollte er sich den Code nehmen und auf der Webseite als Text anzeigen, was auch klappte. Nur im Produktivsystem war lediglich die Ausgabe von function() zu sehen. Wieso?

Was hier falsch ist, ist der Kommentar direkt nach dem do. RubyMine zeigt zwar eine korrekte Syntax und auf meinem localhost-System funktioniert es auch. Warum es nur produktiv nicht klappte, bleibt ein Rätsel, wir konnten bisher nur rausfinden, dass es nicht an der Environment liegt.

Da wir unsere Projekte meist im Team bearbeiten, standen wir schon öfter vor folgendem Problem:
Ein Entwickler startet ein neues Projekt und legt das Model User an. Da das Projekt am Anfang steht, hat der User erst mal nur ein Login. In der Migration wird auch gleich ein "admin"-User angelegt. Ein paar Tage später wird entschieden, dass beim User auch Vor- und Nachname benötigt werden. Also legt der Entwickler eine Migration an, die dem User diese Felder hinzufügt und das User-Model erhält Validierungen, damit die Vor- und Nachnamen auch befüllt werden.

Nun kommt ein zweiter Entwickler zum Projekt hinzu. Er checkt die Sourcen frisch aus und will seine Entwicklungs-DB migrieren. Schon die erste Migration schlägt fehl, da diese den "admin"-User ohne Vor- und Nachnamen anlegen will. Auch später im Produktivsystem funktioniert diese Migration nicht mehr.
Noch spannender wird es, wenn im Laufe der Zeit durch ein Refactoring ein Model ganz entfernt wurde. Alle vorangehenden Migrationen, die irgendwie auf die Klasse zugreifen wollen, schlagen fehl. Kurzum: Die Anwendung entwickelt sich dynamisch, während die Migrationen zum jeweiligen Anwendungsstand in Stein gemeißelt werden.

Vor einigen Tagen haben die Jungs von JetBrains RubyMine 1.1 veröffentlicht und einige neue Features eingebaut. Unter anderem werden jetzt auch Projekte mit Rails 2.3.2 unterstützt und Cucumber-Spezifikationen haben einen Runner spendiert bekommen. Wir arbeiten nun seit einem Monat RubyMine und werden immer noch ab und zu mit kleinen Dingen positiv überrascht. Gerade die gute Integration dieser netten Features bewegen immer mehr Entwickler bei uns zu RubyMine zu wechseln. Unser Chef hat schon eine Ladung Lizenzen besorgt ;-)

Vom 25. Mai bis zum 27. Mai sind wir in Berlin zur RailsWayCon. Die Konferenz hält einige interessante Vorträge und Workshops bereit. Mal sehen was für Neuigkeiten und Ideen wir mitnehmen können.

Unter http://railsmagazin.de/railswaycon-in-6-minuten-1411 findet man auch ein cooles Video mit Eindrücken der RailsWayCon.

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.

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