Der letzte Tag begann im Gegensatz zu gestern und vorgestern ohne eine Keynote. Stattdessen ging es um 9:25 Uhr direkt mit Vorträgen los. Ich besuchte zuerst den Vortrag Webrat: Rails Acceptance Testing Evolved, in dem Bryan Helmkamp einen Überblick über Webrat gab. Viele Details für Einsteiger, wenig Neues für Fortgeschrittene. Danach ging ich zu Building a Video Portal in Rails - Or How the Teenage Mutant Ninja Turtles Started Streaming und erlebte meinen persönlichen Tiefpunkt während der Konferenz. Ich hatte erwartet, dass die Vortragenden eine eigene Video-Plattform entwickelt hatten, stattdessen verwendeten sie thePlattform und die Präsentation drehte sich im Wesentlichen um dessen Anbindung an ein Rails-Projekt. gähn Stefan hatte mehr Glück bei seiner Wahl, zuerst war er bei HTTP's Best-Kept Secret: Caching, dann bei When to Tell Your Kids About Client Caching. Seine Notizen zufolge beides sehr gute Vorträge mit diversen Tips und Anregungen zum Thema Caching. Danach trafen wir uns beim letzten Vortrag am Vormittag, It's Not Always Sunny In the Clouds: Lessons Learned. Mike Subelsky, Mitbegründer von OtherInbox, beschrieb seine Erfahrungen mit Amazon EC2 bzw. S3 und erläuterte diverse Maßnahmen, um Probleme beim Deployment und Betrieb zu vermeiden.

Es folgte das Mittagessen und damit aus meiner Sicht einer der größten Schwachpunkte der Konferenz. Schon das tägliche Frühstück war wenig berauschend, die Auswahl beschränkte sich auf getoastete Bagels, dazu Butter, Marmelade und Doppelrahmkäse (Cream Cheese) sowie mittelmäßiger Kaffee. Kein Müsli, kein Obst oder etwa warme Optionen bzw. ein gekochtes Ei. In gleicher Weise ging es mittags weiter, an allen vier Tagen gab es dieselben Lunchpakete mit einem Sandwich (Salami/Käse, Hähnchen, Truthahn und eine vegetarische Option, die wir nicht probiert haben), Nudelsalat, Chips, zwei Cookies und einem Apfel. Die Sandwiches waren ausnahmslos kalt, nahezu tiefgefroren, der Nudelsalat mit Oliven und Essig verhunzt.

Am Nachmittag folgte der letzter Vortag, wir hörten The Russian Doll Pattern: Mountable apps in Rails 3, wo Yehuda Katz und Carl Lerche, die derzeit beide an Rails 3 arbeiten, die kommende Möglichkeit zur Einbindung einer oder mehrerer Apps in eine andere App beschrieben. Die Präsentation war hauptsächlich auf Konzepte und Pseudo-Code beschränkt, was schlicht daran lag, dass die Implementierung in Rails 3 noch nicht abgeschlossen ist. Offenbar gibt es in der Rails-Community auch Leute, die die Vermengung mehrerer Apps zu einer neuen App mit gemischten Gefühlen sehen, jedenfalls gab es in der die Konferenz abschließenden Podiums-Diskussion prompt folgende Frage aus dem Publikum: "Are you guys letting Yehuda turn Rails into Drupal?" Die übrigen Fragen und Antworten an das Rails Core Team gaben einen guten Überblick über die Arbeiten an Rails 3 (wenn auch keine Termine genannt wurden) und damit endete dann RailsConf 2009 um kurz nach 16:00 Uhr.

Den Rest des Nachmittags nutzen wir mit Einkaufen im Las Vegas Premium Outlets Center, Abendessen in der 888 Noodle Bar und einem kleinen nächtlichen Ausflug an den Stadtrand von Las Vegas, um von dort die Skyline zu fotografieren.

David Chelimsky, welcher u.A. durch seine Tätigkeit als Lead-Developer von RSpec bekannt ist, zeigte gestern eine Präsentation zum Thema Mock-Objekte. Erwähnung fand darin u.A. das Tool Stubble, das über GitHub zu beziehen ist (Installation und Konfiguration sind in der Datei README.rdoc beschrieben). Das Ziel von Stubble ist es, das Testen von Controllern zu vereinfachen. Angenommen, wir haben eine Rails-App mit einem Model Recipe und dem passenden RecipesController. Die update-Methode hat typischerweise folgenden Aufbau:

class RecipesController < ApplicationController # ...

def update
@recipe = Recipe.find(params[:id]) if @recipe.update_attributes(params[:recipe]) redirect_to recipes_path else render :action => :edit end end

# ... end

Die Specs von sowohl if- als auch else-Zweig dieser Methode sehen mit Stubble wie folgt aus:

describe RecipesController do context "successful update" it "redirects to the recipes" do stubbing(Recipe) do put :update response.should redirect_to(recipes_path) end end end

context "failed update" it "re-renders the edit page" do stubbing(Recipe, :as => :invalid) do put :update response.should render_template('edit') end end end end

Der Aufruf von stubbing(Recipe) erzeugt dabei Stubs für die Methoden new, find, create, *all, find, valid, save und update_attributes (sowie die Varianten mit Ausrufezeichen), wobei die letzten drei Stubs true zurückliefern. Durch die Option s => :invalid wird dies zu false geändert (und die Varianten mit Ausrufezeichen werfen Exceptions). Als Resultat werden die Specs von Controllern lesbarer und das DRY-Prinzip noch konsequenter verfolgt.

Einer der bisher besten Vorträge wurde am heutigen Nachmittag von Scott Chacon zum Thema "Advanced Git Tricks" gehalten (Foliensatz, Cheat-Sheet). Bemerkenswert war insbesondere seine Lösung in Bezug auf Submodule, bei denen in Git normalerweise kein push auf den Remote-Host möglich ist. Tatsächlich verwendet Scott kein richtiges Submodul, sondern umgeht das Problem in der nachfolgend beschriebenen Vorgehensweise:

Ausgehend von einem Projekt mit Git-Repository soll ein weiteres Repository als Subprojekt eingebunden werden. Als Beispiel verwendet Scott einen Fork des Rack-Projektes, welches er dem eigentlichen Projekt als zusätzliche Quelle hinzufügt: $ git remote add rack_remote git@github.com:schacon/rack.git $ git fetch rack_remote Anschließend wird ein lokaler Branch erzeugt $ git checkout -b rack_branch rack_remote/master und dann wieder auf master zurück gewechselt: $ git checkout master Der Branch wird nun in die Arbeitskopie als Unterverzeichnis rack eingehängt: $ git read-tree --prefix=rack/ -u rack_branchAuf diese Art und Weise lässt sich Rack als Unterverzeichnis in das eigentliche Projekt einchecken:$ git add rack $ git commit -m 'added rack code' Angenommen, der lokale Benutzer führt nun Änderungen in Rack durch: $ vim rack/lib/rack.rb $ git commit -am 'added awesome to rack'Um diese Änderungen in das ursprüngliche Repository zu schieben, muss im Anschluss auf den Branch gewechselt werden: $ git checkout rack_branch $ git merge -s subtree --no-commit --squash masterDie Merge-Strategie subtree erlaubt es, den master von Rack in den Branch im Unterverzeichnis zu mergen. Außerdem werden durch die Option --squash mehrere Commits im Branch zu einem einzigem Commit zusammengefasst, so dass die lokale Historie keinen Übergang in das möglicherweise fremde Projekt findet.

Für weitere Tipps zu Git lohnt sich auf jeden Fall ein Blick in das Cheat-Sheet.

Montagmorgen, 8:30 Uhr. Nach schneller und unkomplizierter Registrierung sowie mittelmäßigem Frühstück beginnen die ersten Tutorials von RailsConf 2009. Wir haben uns für jQuery on Rails in Pavillon 9/10 entschieden. Schon beim Betreten des Saals fällt uns auf, dass an den Tischen keine Steckdosen verlegt wurden und auch an den Seitenwänden keine Spur von Stromversorgung. Rasch folgen diverse Tweets und @railsconf verspricht, dass in Kürze die entsprechenden Verlängerungsstrippen bzw. -dosen verlegt werden (unsere Reihe kriegt nach ca. 30 Minuten tatsächlich Strom, andere warten vergeblich).

Inhaltlich geht es zunächst mit den Grundlagen von jQuery los, Yehuda Katz und Andy Delcambre sind gut vorbereitet und stellen Folien sowie Übungsdateien als Git-Repository zur Verfügung. jQuery erlaubt die Verwendung diverser CSS3-Selektoren, die miteinander verkettet werden können ("Chaining"). Nachfolgend drei Beispiele:

// Alle div-Elemente $("div")

// Alle p-Elemente, die zu einem div gehören $("div p")

// Alle Links, die jquery.com enthalten $("a[href*=jquery.com]")

Das Tutorial ist so aufgebaut, dass nach jedem Themenblock kurze Übungseinheiten folgen, in denen das Gelernte anhand von einfachen Aufgabe wie "Select any text areas and their labels" geübt wird.

Es folgen Themenblöcke zum Document Object Model, zur Manipulation von Dokumenten, zu Events und Effekten, zu AJAX und einer Auswahl von Plugins. Die Verwendung von jQuery im Zusammenspiel mit Rails nimmt am Ende nur 6 der 86 Folien und damit relativ wenig Umfang ein, gerade hier hätten wir uns mehr Informationen gewünscht.

In den letzten 20 Minuten wird dann noch das Blue Ridge Javascript Testing Plugin vorgestellt, allerdings sind die Erklärungen und Hintergründe dazu eher dürftig und führen so zu einem negativen Eindruck einer ansonsten recht guten Präsentation.

In Deutschland ist zwar schon Montag, wir halten uns jedoch gerade in Las Vegas auf, so dass uns noch 15 Minuten bleiben, um die Links zum Sonntag noch rechtzeitig abzuliefern.

RailsConf 2009 Der Grund, warum wir uns derzeit in Las Vegas aufhalten. Hoover Dam Bevor die Konferenz startet, hatten wir heute Zeit für einen kleinen Ausflug. Der Hoover Dam war unser erstes Ziel, die ca. 50km von Las Vegas schafften wir in einer knappen Stunde, wobei wir geschätzt 20 Minuten vor der Staumauer im Stau standen. Vor und hinter uns diverse Teilnehmer des Gumball 3000, die prompt im selben Parkhaus Pause machten. Grand Canyon Skywalk Nach weiteren 150km Autofahrt erreichten wir den Grand Canyon Skywalk am westlichen Rand des Grand Canyon. Am Eingang des Reservats mussten wir das Auto parken, um dann $30 pro Person für 10 Minuten Busfahrt und $35 pro Person für den Skywalk zu bezahlen. Trotz der horrenden Preise waren am späten Nachmittag noch ca. 30 Besucher mit uns unterwegs, der Skywalk selbst eher enttäuschend, die Ausblicke von verschiedenen Aussichtspunkten wesentlich spannender, vor allem, weil man ohne jegliche Absperrung bis direkt an die Klippen laufen kann. Empfehlung: Auf den Skywalk verzichten und nur die Aussichtspunkte mitnehmen = halber Preis, besseres Erlebnis.

Ab morgen werden wir hier dann direkt von RailsConf 2009 berichten, am Vormittag haben wir uns für das Tutorial jQuery on Rails registriert, am Nachmittag steht Building Next Generation Web Apps with Rails and SproutCore auf dem Plan.