JRuby on Rails

Jeder Rails Entwickler kennt RubyForge - und jeder der gerade Gems installieren möchte, wird folgendes Problem festgestellt haben:

ERROR:  While executing gem ... (Gem::RemoteSourceException)
Error fetching remote gem cache: SocketError: getaddrinfo: no address associated with hostname. (http://gems.rubyforge.org/yaml)

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.

Die JRuby-Entwicklung geht trotz oder gerade wegen des Arbeitgeberwechsels (JRuby-Team verlässt Sun) unaufhaltsam weiter.

Gerade wurden, neben den üblichen Bugfixes, 5 Hauptthemen der neuen Version JRuby 1.4 angekündigt.

1. JRuby 1.4 wird kompatibel zu Ruby 1.8.7
   
   
2. Weitere Verbesserungen der Ruby 1.9 Unterstützung.
   
   
3. Ein neuer YAML-Parser wird enthalten sein. (geschrieben von Ola Bini)
   
   
4. Die Java-Integration wird verbessert.
   
   Genauer gesagt soll es möglich sein, präziser zu bestimmen, welche Java-Methoden angesprochen werden sollen.
   Zur Zeit gibt es nämlich das Problem, dass, wenn man z.B. die Methode use() bei dieser Java-Klasse

   public class Overloaded {
    public static void use(int i) { /* ... */ }
    public static void use(long l) { /* ... */ }
   }
   

   mit JRuby aufruft,

    
   Java::Overloaded.use 10
    
   

   die Methode public static void use(long l) genutzt wird. Das jetzige JRuby-Verhalten erzwingt eine Umwandlung von Ruby-Fixnum in einen long-Wert in Java. Daher kann nie die Java-Methode mit dem int-Argument aufgerufen werden.
   
   
5. Die Generierung von echten Java-Klassen aus Ruby wird "experimentell" enthalten sein.
   
   Zum Beispiel wird aus:

   require 'java'
   require 'jruby/core_ext'
   class SimpleTest
    def equals
    raise "not equal" unless 1.0 == 1
    end
   end
   SimpleTest.add_method_signature("equals", [java.lang.Void::TYPE])
   SimpleTest.add_method_annotation("equals", org.junit.Test => {})
   SimpleTest.become_java!
   

   package ruby;
   import org.junit.Test;
   public class SimpleTest {
    @Test
    public void equals() {
    // dispatch back to Ruby code here
    }
   }
   

Ausführlicher kann man sich die Punkte und Beispiele im Engine Yard Blog durchlesen. www.jruby.org
5 Things to Look for in JRuby 1.4
JRuby Ruby-to-Java Compiler

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.

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

Das Tutorial gibt in wenigen Schritten eine kurze Einführung zur Installation von JRuby on Rails unter Windows. Voraussetzung ist ein installiertes JDK 1.4 oder höher und dass selbiges im System-Pfad vorhanden ist. Ob die Voraussetzung erfüllt ist, kann man auf der Kommandozeile mittels "java -version" testen. Wenn eine Java Version angezeigt wird, kann die Installation von JRuby on Rails beginnen.

Folgende Schritte sind nötig:
A. Installation von JRuby
B. Installation von Rails mittels Gem

Willkommen bei JRoR
dem deutschprachigem Blog über Jruby on Rails!

JRuby on Rails (JRoR) verbindet die Agilität der Skriptsprache Ruby mit der ausgereiften Infrastruktur und einer Unmenge an Bibliotheken der Java-Welt. Das ist eine sehr mächtige Kombination, denn die Kunden bekommen eine stabile Webanwendung mit großem Funktionsumfang für einen vergleichsweise geringen Aufwand. Und welcher Kunde will das nicht?

In diesem Blog werden wir Informationen rund um JRuby, Rails und Ruby zusammentragen. Neben Links zu anderen Seiten und interessanten Büchern werden wir auch eigene Lösungen vorstellen und Trends diskutieren. Wir möchten auch andere professionelle Softwareentwickler einladen, sich zu beteiligen, und hoffen so zum Erfahrungsaustausch beizutragen.