Oliver Kießler’s Weblog

Rollacastr Rails 2 Upgrade Story

Kurz vor Weihnachten hatte ich beschloßen, die rollacastr Anwendung von Rails 1.2.6 auf 2.0.2 zu migrieren. rollacastr ist ein Social Network für Podcast Hörer und hilft dir neue Podcasts über Freunde zu finden. Der Grund für das Upgrade war das verbesserte View Rendering/Mimetype System, mit dem es in Rails 2 möglich ist, neue Formate neben html, xml und js selbst zu definieren und eigene Views dafür zu nutzen.

Da wir bei rollacastr eine iPhone Variante entwickeln wollten, war dieses Feature sehr wichtig für uns und sollte den Aufwand für das Upgrade rechtfertigen.

Gesagt, getan… rollacastr ist eine überschaubare, standard-konforme Rails 1.2 Anwendung, die mit einer Handvoll gängiger Plugins (acts_as_taggable, open_id_authentification, restful authentification etc.) auskommt und größtenteils auf den Restful Ansatz verzichtet.

Nach der Installation des rails 2.0.2 Gem’s ging es im ersten Schritt daran, den Source Code und die Konfigurationsfiles auf den neusten Stand zu bringen. Für diese Umstellung habe ich mich an diesem hilfreichen Blog Post orientiert. Die meisten der dort beschriebenen Vorgehensweisen habe ich durchgefürt. Zuerst habe ich im Anwendungsroot “rails .” ausgeführt, um Konfigurationsfiles, Javascript Libs etc. auf den neusten Stand zu bringen. Seit Rails 2 wird standardmäßig ein Cookie-basiertes Sessionmanagement verwendet, worauf wir bei rollacastr (derzeit noch) verzichten, da wir unsere Sessions in der Datenbank speichern (Cluster). Der Cookie Session Ansatz ist sicherlich auch interessant, sehr schnell, aber auf eine Maximal Größe von 4096 Bytes beschränkt.

Danach habe ich einen Deprecation Check durchgeführt und ein paar View Methoden aktualisiert. Auf das Umbenennen aller Views habe ich verzichtet, da ich festgestellt habe, dass das nicht zwingend nötig ist. Denn es wird eine View eines spezifischen Formats verwendet, wenn sie vorhanden ist, auch wenn der Rest der Anwendung dieser Konvention nicht folgt. Daher habe ich mich darauf beschränkt, nur die wenigen iphone Views in der neuen Schreibweise zu verwenden (”NAME VIEW”.”FORMAT”.”BUILDER” also zum Beispiel: index.iphone.erb oder show.js.rjs).

Zudem habe ich festgestellt, dass wenn man alle Views in der neuen Schreibweise verwendet, die RJS Actions Probleme machen, da diese nicht mehr per Default verwendet werden, wenn sonst kein View Format vorhanden ist, was dazu führen würde, das man bei allen Actions die entsprechende “respond_to” Anweisung für “js” einfügen müsste…

Nach der Umstellung liefen alle Testfälle durch und die Anwendung funktionierte im Development Modus (unter OSX Leopard) einwandfrei.

Nun ging es daran, die Server für die Umstellung vorzubereiten. Dafür wurde auf allen Cluster Nodes, die unter Debian Etch Linux laufen, das Rails 2.0.2 Gem installiert. Danach habe ich dann das Deployment mit Capistrano angestoßen und dieses lief ohne Fehlermeldung durch. Leider musste ich zu meiner Überraschung feststellen, dass die Anwendungsprozesse nicht liefen… Keine Ruby Prozesse auf den Application Cluster Nodes und kein Eintrag in den entsprechenden Production bzw. Staging Logfiles. Hmmm….

In so einem Fall ist es immer gut, im Anwendungsroot eine Console zu öffnen, in der man meistens sinnvolle Hinweise bekommt, da dort auch das Rails Environment geladen wird. Hier bekam ich dann auch genau den Hinweis, den ich brauchte. Rails 2 benötigt eine Rubgems Version >= 0.95! (Debian Etch läuft aber unter Rubygems 0.9.0 und es gibt kein aktuelleres (stabiles) Paket) Zudem wurde empfohlen gem update —-system durchzuführen. Diesen Befehl hätte ich lieber nicht ausgeführt, denn danach musste ich festzustellen, dass der “gem” Befehl nun gar nicht mehr funktionierte!

Auch ein Downgrade auf die alte Gem Version durch “apt-get” funktionierte nicht mehr! Dadurch war ich leider gezwungen mir die benötigte rubygems Version selber zu kompilieren, was ich normalerweise um jeden Preis vermeide, um alle Cluster Nodes mit dem geringsten Aufwand zu installieren, aktuell zu halten und zu automatisieren. Da gerade Rubygems 1.0 rausgekommen war, wollte ich direkt die aktuellsten Version nutzen.

Damit ging die Leidensgeschichte dann leider weiter, denn ein paar der Gem Abhängigkeiten, die rollacastr benötigt funktionieren leider mit Rubygems 1.0 nicht. Das waren das feedtools und das ruby-openid Gem, die beide leider den “require_gem” Befehl nutzen, der aus Rubygems 1.0 entfernt wurde!

Das feedtools Gem ist gnadenlos veraltet und darauf könnte rollacastr gegegenbenfalls auch verzichten, aber ruby-openid Gem wird in jedem Fall benötigt. Für das ruby-openid Gem gab es neuere Version, die mit Rubygems 1.0 konform ist, leider funktionierte das neue Gem aber nicht mehr mit dem älteren Rails Plugin… Also war das auch kein gangbarer Weg…

Daher habe habe ich Rubygems 1.0 wieder entfernt und mir Rubygems 0.9.5 selbst kompiliert. Danach liefen alle benötigten Gems und Plugins und die Anwendung ließ sich starten…

Puh, eine Menge Ärger für ein paar iPhone spezifische Views…

Mein Fazit: Prüft eure Produktionsumgebungen genau, ob sie für die neuen Gegebenheiten ausgelegt ist! Natürlich ist das eigentlich eine Selbstverständlichkeit, aber ich hatte die Rubygems Anforderung überhaupt nicht erwartet und eine solche Anforderung einer speziellen Rubygems Version bisher auch noch nicht mit Rails erlebt. Ich hatte mir eher ein “Drop In Replacement” des neuen Rails Gem’s vorgestellt…

Das Rollacastr Projekt

Am Ende des letzten Jahres hatte ich die Idee ein Social Network für Podcast Hörer ins Leben zu rufen. Es war die Zeit, in der Twitter gerade populär wurde und ich festgestellt habe, das es eigentlich eine “Art Twitter für Podcasts” geben müsste. Denn mal ganz ehrlich, wie findet Ihr eigentlich neue Podcasts? Indem ihr durch endlose Podcast Verzeichnisse stöbert oder die langweile iTunes Podcast Top 10 betrachtet…? Also ich nicht. Ich finde neue Podcasts durch Freunde und andere Podcast Hörer. Durch die einfache Frage “Sag mal, was hörst du eigentlich für Podcasts?”

Das ist rollacastr in einem Satz zusammengefasst. rollacastr ist eine Site, in der man eine Liste der Podcasts, die man hört, pflegen und schon in rollacastr bestehende Podcasts (z.B. die der Freunde) der eigenen Liste hinzufügen kann. Durch die Freunde in rollacastr bleibt man ständig auf dem Laufenden, was die zur Zeit hören oder welche Podcasts sie wie kommentieren. Es ist eine Site zum Entdecken von neuen Podcasts, Shows und digitalem Content.

Anfang diesen Jahres habe ich dann ein Team formiert und das Projekt ins Leben gerufen. Neben unserem Tagesgeschäft haben wir dann rollacastr konzipiert, gestaltet und in Rails programmiert. Da Podcasts in meinen Augen ein globales Thema sind, haben wir uns dazu entschlossen die Anwendung komplett in Englisch aufzusetzen, mit der Hoffnung die Kernmärkte USA, UK und Deutschland zu erreichen. Die Nutzung von rollacastr ist sehr einfach und benötigt keine herkömmliche Registrierung, sondern es wird lediglich eine eigene OpenID Identität vorausgesetzt. Wer noch keine OpenID besitzt, kann sich hier eine Kurzeinführung durchlesen und sich bei einem kostenfreien OpenID Provider anmelden. Mit dieser OpenID Identität können dann auch noch viele andere Websites benutzt werden, ohne dass man sich ständig neue Benutzerkonto anlegen muss. rollacastr erfasst also nur sehr wenige Benutzerdaten und alle Profilangaben sind optional.

rollacastr wird in Kürze in die Private Beta Phase gehen (Invitation Only). Bei Interesse kann man mich gerne zu diesem Thema kontaktieren.

Meine Eindrücke von der Railsconf Europe 2007 in Berlin

Ein paar Tage nach der Railsconf Europe 2007 in Berlin komme ich nun endlich mal dazu meine Eindrücke aufzuschreiben. Zuerstmal fand ich die Konferenz alles in allem ziemlich gelungen. Die Organisation durch O’Reilly war im Prinzip fehlerlos, das Umfeld deutlich besser als letztes Jahr und die Anzahl der Besucher hatte sich verdoppelt. Die Qualität der Vorträge und Sprecher war in Ordnung, allerdings auch nicht umwerfend.

Angefangen mit der Keynote von DHH wurde relativ schnell klar, dass Rails sehr bald in eine neue Richtung geht bzw. in eine neue Phase eingetreten ist. Rails ist in der kommerziellen Welt angekommen. Es gibt (erstmal) keine “großen Revolutionen” mehr, sondern es ist nun Zeit die Benefits von Rails zu geniessen und anzuwenden. Rails 2.0 steht vor der Tür und wird sehr bald in einem Preview Release verfügbar sein. Darin wurde aufgeräumt, ausgelagert, an Details verbessert und weniger gute Konzepte über Bord geworfen.

Firmen wie Sun und IBM sind nun eindeutig auf den Rails Zug aufgesprungen. Aus reinem Interesse am Framework? Sehr unwahrscheinlich… Klar wurde auf der Railsconf, dass diese Firmen nun um unsere Gunst buhlen, wenn es darum geht Services, Support, Tools, Produkte und Expertise in große Enterprise Projekte einzubringen.

Naja, die Übermacht von Apple Notebooks auf der Railsconf war mal wieder unglaublich. Manchmal saß man in einer Reihe, wo bis zu 8 Macbook Pro’s nebeneinander aufgeklappt waren. Komisch, dass Apple kein Sponsor ist. Mal ehrlich, eine bessere Zielgruppe kann man wohl kaum mehr erreichen…

Inhaltlich habe ich nicht so viel gelernt, aber es ist immer wieder interessant zu sehen, wohin sich das Umfeld bewegt und womit sich Leute beschäftigen. Ich bin weiterhin der Auffassung und das wurde auch durch die Railsconf klar, dass (J)Ruby, Rails und Java zusammen eine Killerkombination sind. Die Entwickler Gemeinden sollten sich wirklich auf eine friedliche Koexistenz einigen. Selbst der Struts Erfinder und Java Server Faces Mitverantwortliche Craig McClanahan war von der Partie und sprach in den höhsten Tönen von Rails… Irgendwie verkehrte Welt… Es scheint, dass man nicht mehr versucht Rails in die Enterprise Welt zu pressen, sondern die Enterprise Welt sich Rails annähert, akzeptiert und natürlich auch davon profitieren möchte…

RailsConf Europe 2007 in Berlin

Ich fahre auch dieses Jahr wieder zur RailsConf Europe. Ich bin mal gespannt, wie sich die Konferenz gegenüber dem letzten Jahr verändern wird. Es werden deutlich mehr Teilnehmer da sein (doppelt soviele wie in London) und O’Reilly ist der Veranstalter, was einen professionellen Ablauf erwarten lässt.

Ich habe gerade mal durch die Sessions geschaut, die geboten werden. Davon interessieren mich folgende Sessions:

Caching in a Multilanguage Environment
Benjamin Krause

Meta-Magic in Rails: Become a Master Magician
Nic Williams

Utilizing Amazon S3 and EC2 in Rails
Jonathan Weiss, Peritor Wissensmanagement GmbH

JRuby on Rails: A Path to Adoption
Thomas Enebo

Really Scaling Rails
Alex Payne

JRuby on Rails at ThoughtWorks
Ola Bini, ThoughtWorks

Building Rich Internet Applications with Flex and Ruby on Rails
Simeon Bateman

Wir sehen uns in Berlin!

Java ist doch nur Junk…

Das Interview mit David Heinemeier Hansson ist nicht mehr ganz neu, aber ich wollte doch nochmal die Gelegenheit nutzen darauf hinzuweisen. Großartig! Ich liebe es wenn Leute “starke Meinungen” haben und eine ganze Industrie (Hersteller von Java und .NET basierten Architekturen) mit einem Begriff (Junk) völlig politisch inkorrekt abstrafen. Ein weiteres Beispiel ist Linus Torvalds, der Linux “Erfinder”, der immer wieder mit seinen völlig arroganten Bemerkungen (z.B. über CVS) unangenehm auffällt.
Ich bin zwar überhaupt nicht einer Meinung mit David, aber ich finde es gut, dass er weiterhin unangepasst ist und an seine Idee glaubt. Ich denke allerdings, es ist nur vorteilhaft, dass eine Java Implementation von Ruby gibt, denn die (in Konzernen vorhandenen) J2EE/JEE Umgebungen (Applikationserver) sind in Sachen Skalierbarkeit, Clusterfähigkeit, Ausfallsicherheit, Connection Management etc. dem üblichen Rails Stack deutlich überlegen. David sieht JRuby und andere Lösungen als Nischen und ich denke, darin täuscht er sich. Ich denke, die Zukunft sieht gut aus für diese Lösungen.

Mehrere Ruby Versionen auf einem Rechner

Meine Ruby (on Rails) Entwicklung mache ich hauptsächlich unter OSX. Da das von Apple mitgelieferte “Ruby” oft Probleme gemacht hat, bin ich anfangs auf DarwinPorts bzw. MacPorts ausgewichen. Dort habe ich mir mittels “port install ruby” die aktuelle Ruby Version installiert. Und danach habe ich alle Ruby Gem’s “händisch” installiert, was soweit auch immer funktioniert hat.

Um den Ablauf bzw. diese Installation auch auf anderen Maschinen reproduzieren zu können, habe ich dann dafür ein Bash Skript geschrieben. In ersten Skript wird die Umgebung automatisiert eingerichtet (für OSX mit “port”, unter Ubuntu mit “apt-get”… also subversion, mysql, image magick etc.) und im zweiten Skript die Ruby spezifische Installation inklusive einem selbstkompilierten Ruby und aller Ruby Gem’s.

Wenn man allerdings mehrere Rails Anwendungen entwickelt, die auf verschiedenen Produktionssystemen mit unterschiedlichen Ruby Versionen betrieben werden, war der Ansatz nicht mehr flexibel genug. Teilweise gab es kleinere Unterschiede zwischen den Ruby Versionen. Lokal lief es, aber im Produktionssystem nicht… Danach bin ich dazu übergegangen, das Bash Skript entsprechend anzupassen die derzeit gängigen Ruby Versionen (1.8.4, 1.8.5 und 1.8.6) automatisiert in Unterordnern zu installieren und nur noch bei Symlink auf die jeweils benötigte Ruby Version zu verweisen. Die Ruby Versionen sind dann auch in meinem Homeverzeichnis unter “bin”, so dass ich beim “gem” Befehl kein “sudo” einsetzen muss. Je nach Anwendung kann man dann bequem den Symlink umswitchen und hat alle benötigten Ruby Gem’s zur Verfügung.

Naja, nicht spektakulär, aber doch praktisch…

Swiftiply

Ich hab gestern ein bisschen mit Swiftiply rumgespielt. Swiftiply ist ein Clustering Proxy für Webapplikationen. Das besondere daran ist, dass Swiftiply kein Wissen von seinen Backends hat und vor allem keine Konfiguration von diesen benötigt. D.h. wenn ein Backend (wie z.B Mongrel) startet, meldet es sich dynamisch an einem (der möglichen) Swiftiply’s Backend Ports an und wird somit dem Cluster zugewiesen. Swiftiply kann mehrere Domains und Anwendungen über verschiedene Backend Ports verwalten.

Das Konzept findet ich sehr spannend. Bei einem überschaubaren Cluster macht das Ganze vielleicht noch keinen Sinn, aber sobald man Lastspitzen durch das dynamische Hinzufügen von Application (Cluster-) Nodes abfangen will (z.B. mit Amazon EC2) macht das Ganze viel Sinn und praktisch keinen Aufwand in der Systemadministration. Und vor allem benötigt es keine händischen Konfigurationsanpassungen und Neustarts.

Swiftiply funktioniert bestens mit Ruby und Rails und bietet eine angepasste Version von Mongrel an, die sich beim Starten automatisch mit dem Swiftiply Proxy verbinden.

So könnte eine ganz simple Swiftiply Konfiguration aussehen:
cluster_address: localhost
cluster_port: 80
daemonize: true
epoll: true
epoll_descriptors: 20000
map:
- incoming:
- meine-domain.de
outgoing: 127.0.0.1:30000
default: true
docroot: /var/apps/meine_app/public


So startet man 3 Swiftiply Mongrel Instanzen für seine Anwendung:
swiftiply_mongrel_rails -h 127.0.0.1 -p 30000 -n 3