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…

Erste Fortschritte mit meiner OpenSocial Container Implementation

Wie bereits in diesem früheren Blog Post angedeutet, habe ich nun angefangen einen OpenSocial Container in Ruby on Rails zu implementieren. Die OpenSocial API besteht aus Sicht des Anwendungsentwicklers auf einer clientseitigen JavaScript und einer serverseitigen XML Rest API. Ich habe für mich entschieden, mich nur auf die serverseitigen Data API’s zu konzentrieren.

Die clientseitige JavaScript API soll Anwendungsentwicklern grundsätzlich den Einstieg in das Thema OpenSocial erleichtern und mit Kenntnissen von HTML und JavaScript ermöglichen, vollständige Social Apps für einen OpenSocial Container zu schreiben. Nunja, nach der Betrachtung der JavaScript “Interfaces” und der Sample Container Implementation, muss ich gestehen hatte ich wenig Lust mehr, einen eigenen Container zu entwickeln. Die JavaScript API basiert auf dem Google Gadgets Prinzip. Als serverseitiger Entwickler muss ich gestehen, dass mich die JavaScript API nur wenig reizt und ich finde sie auch außerhalb des Google Anwendungskontextes schwer umsetzen. Zudem finde ich es schlicht gesagt den falschen Ansatz und ich bin wirklich erstaunt, dass die OpenSocial kompatiblen Sites und Social Networks sich auf diese API eingelassen haben…

Ich für meinen Teil habe ich mich auf die Data API’s und die OpenSocial Authentifizierung konzentriert. Diese sind straightforward und basieren zum Größtenteil auf dem standardisierten Atom Syndication Format. Hier sehe ich auch den eigentlichen Benefit für den Anwendungsentwicklern, der die serverseitige API nutzt: Der Client ist mit Hilfe einer Atom Client API schnell erledigt! Selbst Firefox kann die Datafeeds direkt darstellen.

Die Authentifizierung funktioniert bereits und auch die People und Activities API sind schon teilweise umgesetzt. Bei der Acitivities API habe ich bisher nur den Readonly Teil umgesetzt, also die Ausgabe eines Userlevel Feeds. Zuletzt steht dann noch die Persistence API an.

Was übrigens in den OpenSocial Data API’s nicht durch die Atom API abzubilden ist, wird beispielsweise durch Elemente der Google Commons API ergänzt. Insgesamt ist die ganze OpenSocial Data API eine Mischung aus bestehenden Datenformaten und Spezifikationen. Ich würde sogar vermuten, dass hier nichts Neues entwickelt wurde, sondern nur “schnell” bestehende API’s miteinander kombiniert wurden. Hier sollte wohl schnell “ein Mittel” gegen Facebook gefunden werden…

Leopard TimeMachine Troubles…

Ein Feature von OSX Leopard, auf das ich sehr gewartet hatte, ist TimeMachine. Das Prinzip ist, dass man eine externe Festplatte anschließt und das ohne Aufwand sofort ein Backup des Systems erstellt wird. Es wird pro Stunde ein neues (inkrementelles) Backup erstellt, zudem ein tägliches und wöchentliches Backup solange bis die externe Platte voll ist (danach werden ältere Backups ersetzt).

Und genau dieser Zustand, dass die externe Platte voll ist, ist bei mir relativ schnell eingetreten (ich hatte eine 120GB 2,5 Zoll USB Platte benutzt). Ohne große Überlegungen habe ich mir dann eine neue 250GB Trekstor 2,5 Zoll Platte zugelegt. Diese kurzerhand mit dem MacOS Extended (Journal) Filesystem formatiert und los sollte es gehen… Aber direkt beim ersten Backup meines Macbook Pro 100GB ist das Backup gescheitert (nach etwa 10 GB gesicherten Daten). Das habe ich dann verschiedene Male wiederholt, immer mit dem selben Ergebnis: Backup gescheitert! Leider immer komplett ohne sinnvolle Fehlermeldung zur Analyse…

Nach einigem Googeln habe ich feststellen müssen, dass auch andere das Problem haben. Es wurde immer dazu geraten, die Festplatte mit einem neuen “Partitionstable” zu initialisieren. Meine Festplatte hatte den Aufkleber “Ready for Vista” auf der Verpackung, das hätte mir zu denken geben sollen… Nunja, man kann also eine Festplatte mit dem “Guid” Partitionstable (mit dem Festplattendienstprogramm) anlegen und damit soll es funktionieren…

Das Backup ist danach einiges weiter durchgelaufen, aber trotzdem immer gescheitert… Danach war ich es leid und habe mir eine weitere externe Platte (allerdings 3,5 Zoll mit 500GB) zugelegt, diese mit dem Guid Partitionstable ausgestattet und das Backup lief sofort durch… Hm, heisst das also, das meine 2,5 Zoll Festplatte “ready for Vista”, aber nicht “ready for Leopard” ist?