casperfabricius.com

© 2008 Jacob Lauemøller

We had meeting in Copenhagen Ruby Brigade the other night with a theme of “Present something interesting from this year’s RailsConf Europe”. Three had found the time to prepare a presentation, and I was one of them. I gave a summary of the Juggernaut presentation, not only because it was interesting and entertaining (the original presentation, not my summary!), but because it really made me feel like start coding an application using Juggernaut right away. Juggernaut is a small server and a Rails plugin that allows the web server to push information in real time to clients using an open Flash socket. The syntax for pushing data (typically javascript or JSON) to client is very similar to RJS, e.g.:

render :juggernaut do |page|
    page.insert_html :top, 'chat_data', "#{h(params[:chat])}"
  end

When a client wants to broadcast to other clients, it simply fires an ordinary AJAX request to a controller, which in turn passes the message on through Juggernaut. The presenters showed a running example where the audience could place their home towns on a Google Map, which updated in real time as people used it. There is something fundamentally fun about coding real time interaction between multiple clients, at least that’s how I feel. Perhaps it goes back to my time as a developer on a large-scale European chat site, but ironically I worked on everything but the real time communication during that time.

I had looked forward to the talk about the new localization (l10n) and internationalization (i18n) features of Rails 2.2, and especially to see and meet Sven Fuchs. We never managed to meet before the presentation or talk much after (sorry Sven, my bad!), but the presentation was well-structured and well executed, and the prospects of having a default interface for i18n in Rails are great! Sven explained that he and the other i18n contributors had (after long discussions) made three key decisions:

• Do the simplest thing that could ever work for Rails
• Make a 100% swappable back end
• Do not aim for a full-blown l10n solution

These are three very important decisions. The very different approaches various i18n plugins for Rails have had clearly show that people’s needs are very different when it comes to l10n and i18n. Some really just need to run their application in a single language that is not English. Some like to have translations stored in YAML files for easy versioning and others like to have them in the database for easy changes through a web interface. Some need full blown i18n of currency, dates, times and even the layout of content.

This has resulted in a simple, yet powerful i18n API that centers around the I18n class. I18n.translate (aliased as I18n.t) returns a translated string. I18n.localize (aliased as I18n.l) returns a localized time, date, currency etc. The I18n class is completely back end / plugin agnostic, but Rails ships with SimpleBackend which allows English and other latin languages with English-like grammar to be loaded from YAML-files. However, Sven underlined that he hopes that people will start building many small i18n and l10n plugins serving specific needs, and get away from big plugins that tries to serve all, but never does so satisfactory. Globalize2 is on its way, he said, but that will be a complete rewrite and a much smaller plugin than the current.

I also took a lot away from the talk on advanced REST. Most of us understand the basics of RESTful architecture and modeling by now, but in a number of cases the whole resource/CRUD paradigm doesn’t seem to fit so well. Ben Scofield took us through a number of such cases and suggested solutions for each:

• Password resets: map.resources :users, :has_one => :password (password is a resource by itself, and each user has one)
• Previews: map.resources :posts, :has_one => [:preview] (preview is a seperate resource that is not created in the database)
• Search: map.resource :search (use the index action with a query, not post)
• Wizards: Take the user past different resources, e.g. /galleries/new -> /restaurants/:id/photos/new -> /restaurants/:id/photos/edit

Ben also recommended the make_resourceful as his preferred plugin for handling common RESTful tasks Ben said the RESTful controller plugins was too much magic for him, but he recommended the audience to take a look at the projects Sinatra, Waves and Halcyon.

There where many other talks that I liked, but as we discussed at the Copenhagen Ruby Brigade meeting, the technical level was a bit too low, there weren’t many really new insights and woah! moments, and there where many empty slots! One must wonder how we could end up with I think around 6-8 empty slots during just two days? There was, after all, presentaion proposals enough to arrange a RejectConf. Anyway, RailsConf US will be in Las Vegas next year, so … I mean … do we have any choice, really? Rumors also say that RailsConf Europe will take place in Barcelona next year – another tempting destination!

One final note: I put a new design on my blog – what do you think? I made the change because I am now an independent Ruby on Rails developer, and I like the swirly light design of this theme as well as the orange box (also an awesome game bundle) where I can present myself.