Komprovisation

Nachdem unsere kleine Sonntagsreihe vorige Woche aufgrund der Auswirkungen des Jetlags von Las Vegas ausgefallen ist, haben wir diese Woche wieder drei Links. Thema ist MacRuby:

1. MacRuby.tmbundle - TextMate bundle for MacRuby
   Wer MacRuby lieber in TextMate als in Xcode schreiben will, sollte sich das MacRuby-Bundle für TextMate ansehen.
2. Hillegass-MacRuby
   Wer die Programmierung in Cocoa über den Klassiker Cocoa Programming for Mac OS X von Aaron Hillegass gelernt hat, findet in diesem Git-Repository einige der Beispiele in MacRuby transferiert.
3. Macruby Support in any Cocoa Application
   Wer MacRuby in ein beliebiges Cocoa-Projekt einbinden will, bekommt hier eine kurze Anleitung sowie ein Beispiel-Projekt.

Zum Schluss noch ein Link zu einem eigenen Projekt, dass wir kürzlich auf GitHub eingecheckt haben. MacRubyTwitterApp ist ein einfacher Twitter-Client, geschrieben in MacRuby.

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.

Der 3. Tag begann mit einer kurzen "sponsored" Keynote von Engine Yard, in der drei Mitarbeiten das neues Cloud Interface vorstellten. Mit diesem kann man per Klick neue Instanzen zu einem Cluster hinzufügen oder auch den ganzen Cluster klonen, um diesen als Real-Life Staging-Instanz zu benutzen. Dank Amazon AWS alles innerhalb von Sekunden. Sehr nett.

Danach gab es eine Keynote von Chris Wanstrath (Mitbegründer von GitHub). Die Keynote begann damit, wie man ein Programmierer-Rockstar wird, was Chris sehr spaßig erzählte. Im Grunde ging es aber darum, dass man seine Reputation eher durch Code (auf GitHub) als durch Blogs, Twitter usw. aufbauen sollte. Sehr sympatischer Kerl, sehr gute Keynote.

Nach einer kurzen Kaffepause ging Thomas zu Using metric_fu to Make Your Rails Code Better, ich besuchte Rails Metal, Rack, and Sinatra. Beide Vorträge waren sehr gut. Rack, Metal und auch Sinatra könnten in Zukunft sicherlich bei dem einen oder anderen unserer Projekte sehr hilfreich sein. Zusammen ging es dann zu Rails3: Step Off of the Golden Path, wo ein Teil der neuen Möglichkeiten von Rails 3 angerissen wurden. Besonders DataMapper sah vielversprechend aus.

Nach dem Mittag, die selbe Sandwich-Auswahl wie am Montag, ging es weiter mit Rails in the Large:How We're Developing the Largest Rails Project in the World. Zwei Mitarbeiter von ThoughWorks erklärten, wie sie das größte Rails-Projekt der Welt entwickelt haben: http://www.ove.com. Der Fokus des Vortrags lag weniger auf der eigentlichen Programmierung als auf dem Entwicklungsprozess. Im Anschluss besuchten wir Advanced Performance Optimization of Rails Applications, wo das Thema Performance anhand von Code-Beispielen diskutiert wurde. Ein Beispiel war, dass die Verwendung der Klasse Date 16 mal langsamer als ist als die von Time. Abhilfe schafft das Gem date-performance, welches einige Methoden von Date in C statt Ruby implementiert. Einfach das Gem installieren und schon hat man mehr Performance. Wir werden das und einige weitere Tipps aus dem Vortrag in den nächsten Tagen mal in unseren eigenen Projekten testen. :)

Thomas entschied sich dann für einen kurzes Nickerchen, ich ging zu %w(map reduce).first - A Tale About Rabbits, Latency, and Slim Crontabs. In diesem Vortrag wurde RabbitMQ vorgestellt und die passenden RubyGems dazu. Quasi alles, was man für "High Performance Messaging Queues" benötigt. Sehr interessant, wieder ein paar gute Anregungen, wie man in Zukunft bestimmte Task anders und vor allem besser umsetzen kann.

Nach dem wir mit dem Auto zum Abendessen im Sushi Fever waren, besuchten wir die Lightning Talks, spontane Vorträge mit maximal 5 Minuten Länge, für die sich seit heute morgen Freiwillige anmelden konnten. Eine großartige Veranstaltung und Pflicht für jeden, der nach neuen Inspirationen sucht. Hier einige der Themen und die passenden Links dazu:

• Cloud Gem - RubyGem zur Erzeugung einer Wortwolke ähnlich zu Wordle
• Typheous - RubyGem zur Parallelisierung von HTTP-Requests
• Jeweler - Macht das Erstellen von RubyGems auf GitHub und RubyForge zum Kinderspiel
• Cookpad - Eine japanische Rezepte Seite die jede zehnte Japanerin regelmässig benutzt
• MoodLog - How do you feel right now?

Insgesamt ein sehr interessanter Tag, auch wenn ich mehrere andere spannende Vorträge verpasst habe. Ich hoffe, dass diese per Video aufgezeichnet wurden und in den nächsten Tagen veröffentlicht werden.

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:

1. 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

2. Der Branch wird nun in die Arbeitskopie als Unterverzeichnis rack eingehängt:

   $ git read-tree --prefix=rack/ -u rack_branch

   Auf diese Art und Weise lässt sich Rack als Unterverzeichnis in das eigentliche Projekt einchecken:

   $ git add rack
   $ git commit -m 'added rack code'

3. 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 master

   Die 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.