JRuby on Rails

Nutzer lieben Webanwendungen, die PDF-Dateien erzeugen. PDFs sind wie sauber ausgefüllte Papierformulare und Nutzer können sie ausdrucken, abheften, mit in ein Meeting nehmen, ... Kurz: Nutzer können weiter so arbeiten wie vor der Webanwendung, nur irgendwie moderner. Und genau das lieben sie.

Entwickler lieben Einfachheit und wollen Aufwände gern gering halten. Mit CSS muss man sich ja in jedem Falle auseinandersetzen. Wie wäre es, auch PDFs über CSS zu gestalten, nur eben mit Seitenzahlen, Kopf- und Fusszeile, ...

In unserem Artikel JRuby on Rails PDF Generierung haben wir schon vorgestellt, wie man einzelne Partials in PDFs bringen kann. Nun zeigen wir, wie eine normale Rails-Action einfach statt Anwendungs-HTML eine PDF-Datei erzeugt.

JRuby

Die meisten JRuby-Nutzer kommen bekanntlich aus dem Java-Umfeld. Sie nutzen die Agilität der Scriptsprache Ruby mit der ausgereiften Infrastruktur und einer Unmenge an Bibliotheken der Java-Welt. Daher werden die meisten auch Ant kennen. In der Ruby-Welt heißt Ant Rake!

Thomas Enebo zeigt nun in seinem Blogeintrag wie man

• Ant-Tasks mit Rake aufruft
• Rake mittels Ant nutzt
• Rake-Tasks als aufrufbare Ant-Targets importiert (und umgekehrt)

Ein weiterer interessanter Artikel von Charles Nutter gibt Tipps um eine bessere JRuby-Startzeit zu erreichen. Im Artikel JRuby Startup Time Tips zeigt er, wie man mittels JVM Java_OPTS die Startperformance beschleunigen kann.

Ruby on Rails 3

Die Rails 3 Beta ist nun schon eine Weile zum Ausprobieren freigegeben. Falls Euch vor dem geplanten Update eurer Rails 2.3.x Anwendung Fragen wie

• Was muss man beim Update beachten?
• Wo finde ich Anleitungen zur Rails 3 Umstellung?
• Welche Plugins und Gems laufen schon mit Rails 3?

durch den Kopf gehen, hier ein paar interessante Links zu Rails 3.

Auf rubyonrails.de gibt es eine super Sammlung von Tutorials, Screencasts und Blogeinträgen.

Die Webanwendung http://railsplugins.org/ bietet eine gute Übersicht, welche Plugins schon für Rails 3 bereit sind. Diese Liste kann von allen aktiv erweitert und aktualisiert werden. Des Weiteren wird zu jedem Plugin angegeben, ob es threadsicher ist, mit Ruby 1.9 und/oder JRuby läuft.

RailsWayCon 2010

Wer sich lieber selbst ein Bild von der aktuellen JRuby/Rails-Entwicklung machen will, findet sicherlich wieder viele interessante Vorträge auf der diesjährigen RailsWayCon vom 31. Mai bis zum 2. Juni in Berlin.

Das GlassFish-Gem von Vivek Pandey ist in der Version 1.0.0 erschienen.

Neuerungen sind neben einigen BugFixes:

1. die Implementierung mittels des neu erschienen Glassfish v3 Servers
2. die Startzeit wurde um ca. 15% verbessert
3. die Unterstützung von Rack (Ruby Webserver Interface) ist komplett
4. es ist möglich, Glassfish mittels eines Codeblockes auszuführen

   GlassFish::Server.start(:address=>"127.0.0.1", :port=>4000) do
     use Rack::CommonLogger
     use Rack::ShowExceptions
     map "/hello" do
       use Rack::Lint
       run Proc.new {[200, {"Content-Type" => "text/html"}, "Hello"]}
     end
   end
   

5. der Sinatra-Support wurde verbessert
6. auf der Kommandozeile kann die IP Adresse mitgegeben werden
7. die Konfiguration von Grizzly (NIO based HTTP Lib) kann mittels der glassfish.yml festgelegt werden
8. man findet es nun auch bei GemCutter

Was ist eigentlich das GlassFish-Gem?

Branding und Customizing einer JRuby on Rails Anwendung

Wenn man Rails-Anwendungen für Kunden betreibt, muss man frühzeitig an kundenspezifische Anpassungen denken. Neben dem kundenspezifischen Design (Farben und Logos aus dem Corporate Design, "Branding") spielen dabei auch konfigurierbare Feature-Sets ("Customizing") eine wichtige Rolle. Natürlich wird jeder Kunde sowohl seine eigene Datenbank bekommen als auch seinen eigenen Rails-Server: Sicherheit geht vor! Jedoch will man als Entwickler nicht deswegen mehrere Kopien des Quelltextes auf dem aktuellen Stand halten müssen. In diesem Artikel wollen wir unser Branding-Konzept am Beispiel unserer Zeiterfassung ObjectTime vorstellen. An den Stellen, wo wir es einsetzen, hat es sich bereits ausgezahlt.

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.

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?

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.

Viele Rails-Entwickler werden früher oder später auch einmal PDF-Dateien aus einer Anwendung heraus erzeugen wollen. Dafür gibt es viele denkbare Ansätze: angefangen von PDF::Writer über Prawn bis hin zu kommerziellen Produkten. (Ein Beispiel für PDF-Generierung mit Prawn findet man Ryan Bates Railscasts). Was uns an den meisten dieser Ansätze stört, ist der Aufwand, der mit dem neuen Layout für die PDF-Datei verbunden ist. Warum kann nicht auch hier eines der Grundprinzipien von Rails gelten - DRY (Don't Repeat Yourself)!
Unser Ziel war, bestimmte Bereiche der Rails-Views als Partials zu erzeugen, um genau diese Partials auch im PDF verwenden zu können -> Don't Repeat Yourself

Dank JRuby ist die Lösung dafür nicht schwer. In JRuby stehen uns ja neben den Ruby- und Rails-Bibliotheken auch die Vielfalt und Breite der Java Welt zur Verfügung. In dem Artikel Generating PDFs for Fun and Profit with Flying Saucer and iText wird an mehreren Beispielen sehr gut erläutert, wie man PDFs mittels Java erzeugt.

Durch die Java-Bibliothek iText und das "Flying Saucer"-Projekt ist man in der Lage, XML und CSS zu rendern und als PDF auszugeben. iText ist eine Java Bibliothek zum "on the fly" Generieren von PDF-Dateien. Sie benötigt mindestens JDK 1.4 und ist frei erhältlich. Das "Flying Saucer"-Projekt stellt einen XML/CSS Renderer zur Verfügung, der einen XML-Input mittels CSS formatiert und daraus eine Darstellung als Bild-, PDF- oder Bildschirmausgabe erstellt.

Das Ganze muss nun also nur noch in eine Rails-Anwendung eingebettet werden. Auf geht's!

Standardmäßig wird Rails mit der Prototype Javascript-Bibliothek und der Effekt-Bibliothek Scriptaculous ausgeliefert. Das Zusammenspiel der Ajax-Rails-Methoden (z.B. link_to_remote, observe_field ...) funktioniert auch hervorragend. Doch immer öfter fällt mir die Javascript-Bibliothek JQuery auf. Sei es auf anderen Seiten oder in Tutorials, es kommt mir so vor, als ob JQuery so langsam die Vorreiterrolle übernimmt. Wie kann man nun JQuery in Rails benutzen, ohne auf die hilfreichen Rails Methoden verzichten zu müssen.

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