casperfabricius.com

I’ve only written two blogs from RailsConf Europe this year, one about Dave Thomas’ keynote; The Art in Rails, and one about David Heinemeier Hansson’s keynote, which has temporarily many-doubled the traffic to my blog after being referenced in Signals vs. Noise – thanks, Jason!

But those two keynotes was far from the only sessions I attended worth blogging about, and I have been taking 2-6 KB notes from each and every session. Sadly though, I can’t seem to find the time to write a full article about each of them right now, albeit now is the time people want to read about the conference. So I thought I’d put out my notes from most of the sessions I attended (those worth reading), with a little description with each of them. There are also select presentation slides available.

A Half-day of Behavior-driven Development on Rails
I enjoyed being taught the concepts of Behavior-driven Development by the creator of BDD, Dan North, as well as I enjoyed getting the rspec plugin explained by its creators, Aslak Hellesoy and David Chelimsky, although I noticed they had given up on trying to pronounce the name of the plugin “respec’”, as Aslak tried in vain when he was interviewed for the Ruby on Rails podcast.
Download notes

Caching in a Multilanguage Environment
Benjamin Krause has been kind enough to write two plugins for handling multilanguage routing and multilanguage caching (link doesn’t seem to be available), respectively. In his talk, he explained why current Rails routing and caching is inefficient for multi-language sites, and the rationale behind his design decisions in the plugins.
Download notes

Meta-Magic in Rails: Become a Master Magician
Dr. Nic put on a great show explaining Ruby meta-programming, stressing that introspection is the ability to look at your own code, while reflection is the ability to change your on code dynamically. He also compared Perl to a puppy (fun, but with no understanding of itself), Java to Keith Richards (not so cute anymore) and Rails to Neo (knows about and can change his environment). Finally, the good doctor demonstrated a quite useless, though fun, plugin he had created written by Chris Shea; guessmethod, which attempts to catch and correct misspelled contant and method names dynamically.
Download notes

The Forgotten Child: Powerful CSS with Rails
At the other end of the frontend-backend scale, but just as entertaining, Geoffrey Grosenbach talked about the possibilities of generating CSS. A simple approach is to add CSS as a format recognized by Rails and then generate stylesheets using ERb, but the Rails Podcast author also explained about the opportunities of SASS, a powerful Rails plugin for simplifying, beautifying and DRYing up stylesheets.
Download notes

Lightning Talks
A cancelled talk opened up the possibility for a lightning talk session, and several of the core team members was on the spot. Marcel Molina started out, demonstrating his forthcoming plugin render_with_presenter, and did an many ways a better job of explaining the presenter pattern than Jay Fields did the following day. As a seemingly more advanced alternative to the Comatose CMS plugin; Sandstone (to be released as open source) was also introduced, and Tobias Lütke did a good job of explaining the benefits of using Liquid as a Rails renderer.
Download notes

Best Practices
Core team members Marcel Molina and Michael Koziarski stressed that while there a plenty of resources telling you what you could do in Rails, they wanted to tell us what we should do. The things they said made a lot of sense (especially the notion of Skinny Controllers – Fat Models), and reminded me that I should probably spend more time learning best practices from The Rails Way.
Download notes

Building Webapps in Europe: Economy, Methodology, and Tips
Nicolas Paton’s was a bit disappointing to me, as most of the things he said was pretty much common sense. I hold a lot of sympathy for the guy though, as his nervousness was quite visible during his talk – and thumbs up for bringing attention to differences between development in US and Europe.
Download notes

Ruby on Rails Security
Heiko Webers of RoRsecurity.info brought our attention to potential security issues not only in our Rails code, but also in the web server and database. The biggest take-away from his talk for me, though, was his mention of three plugins: WhiteListHelper for allowing only select tags in user-generated content, SafeERb reminding you to sanitize all your output of user-generated content and ActiveForm, which allows you to validate e.g. a search query using the ActiveRecord validators.
Download notes

Browser-based Testing of Massive Ajax-using Rails Applications with Selenium
I’ve known for a while now that I ought to improve my test base with Selenium tests, so Till Vollmer’s talk was a nice opportunity to get more into the testing framework. One of Till’s important points was that you’ll have to write your own test helper methods in order to get readable tests when testing massive Ajax applications like his Mindmeister. I also want to mention Cross Check of Neal Ford’s javascript testing talk in this context, as this application are able to emulate most known browsers – including their many bugs and differences!
Download notes

Functional JavaScript Development with Prototype
Ben Nolan managed to explain a lot of important javascript concept through his fast-paced tutorial. I for one didn’t know about javascript binding contexts before this talk, but it explained a lot of previous experiences to me! Whether you like Ben’s functional and very compact style when coding javascript, his tutorial was definitely enlightening and enjoyable.
Download notes

Teaching Rails at a University
While Carsten Bormann’s about his course in agile web development using Ruby on Rails on a German university didn’t attract a very large crowd, those of us who was there were definitely glad to hear the news that it is possible to bring Rails into such old and dusty institutions as universities. I for one feel inspired to attempt to bring it into my own school, Copenhagen Business School, because really Ruby is much better suited as first programming language than Java and C#, I think.
Download notes

This article summarizes some important points from David Heinemeier Hansson’s keynote at RailsConf Europe 2007 in Berlin. Last year, DHH brought us the whole REST way of thinking which I immediately named normalization, but that term didn’t really catch on.

© 2007 Pinar Ozger

This year, DHH noted that he up until now had started all his previous keynotes about Rails celebrating how “freakin’ fantastic we are”. For this keynote, he thought – with Rails being well within in its third year in existence – that it was time to perhaps be happy with what we have.

He explained that new things tend to go through certain phases: First they ignore you, then they laugh at you, then they fight you, and then you win – … and then what? “Ruby on Rails went through these phases way too fast”, DHH said, “I was having a lot of fun going through these phases; I’m kind of sad it is over.”

For the last couple of years, David and the Rails community has pushing new concepts; Convention over configuration, AJAX and REST, but these focal points were adopted very fast, so there is no big cause to fight for right now. That leaves Rails 2.0 in a really weird spot, since it won’t have any groundbreaking new concepts.

This is not a bad thing, though, DHH stressed. “Even though [the lack of a great cause] is an off-switch for me, it’s not about me anymore”, he said. “Rails are moving from big revolutions to tiny evolutions” – a statement that was underlined when David went on to demonstrate new features in Rails; features that were definitely more tiny evolutions than big revolutions.

But before we get to the Rails 2.0 code examples of the keynote, let me just mention something that was news to me: The new policy for how to get a patch into Rails, also known as Report #12. The idea is basically that you, once you have written a patch and submitted it to the Rails trac, should get three other Rails developers to check out your patch, verify that your tests run, and then add a “+1″ in a comment in trac. Once you have your three “+1″‘s, you tag your patch with the keyword “verified”, and the patch will appear in Report #12: Verified Patches. The core team should then – theoretically – be able to very fast to accept the patch into Rails.

Moving on to the, in my opinion, most interesting part of the presentation: What’s new in Rails 2.0 – show me the code! Migrations has been updated to support a new syntax known as “sexy migrations”, which basically allows even shorter and more readable migrations by grouping fields of the same type:

create_table :blogs do |t|
	t.string :title, :subtitle
	t.text :body, :description
	t.integer :category_id
	t.timestamps # Adds created_at and updated_at fields
end

Notice how another evolutionary improvement has been sneaked in: Tired of always adding created_at and updated_at timestamps to most tables, a timestamps method has been added as a shortcut. Also this new syntax, including the timestamps, is now standard in the model and scaffold generators.

A small, but to me significant improvement has also found its way to Rails 2.0: You can now create the needed databases with a rake command. By running this command, all referenced databases in your database.yml will be created:

rake db:create:all

Another interesting, and perhaps generally quite invisible improvement, is that session data are now stored in a encrypted cookie instead on each server, which makes it easy to partition applications across multiple servers without having to put session data in the database. This requires, of course, the session data to be quite compact (storing id’s, not entire objects), as a cookie can contain 4 KB of data the most.

My favourite point of DHH’s keynote was his solution to the common pattern of a resource, which you both need to display to the common user (usually index and show) and to the admin user (usually index, new, create, edit, update and destroy). The normal RESTful solution to this leaves with a problem, because we are only allowed one index action, and we need two; one for the common user and one for the admin user. Also, the admin actions will usually have a different layout than the common user actions, and they require some kind of authorization.

The solution is to used RESTful namespaced routes, referring to two different controllers with the same name, but in different namespaces. To use DHH’s eternal blog example:

./script/generate controller posts # => /controllers/posts_controller.rb
./script/generate controller admin::posts # => /controllers/admin/posts_controller.rb

Now we have two different controllers working in the same model; Post, but offering different actions, layouts, authorization and so on. This nice thing about this solution, is that it is very easy to understand and fits well into the Rails structure. The catch is that we have two controllers with the same name, so we need to explicitly express the namespace when referring to the admin controller:

form_for([:admin, post]) do |f|
	...
end

DHH also pointed out that HTTP authentication is a perfect way of doing authentication for administration pages (which I’d already realized). You don’t really need nice-looking form-authentication and remember me checkboxes for that, and it is so very easy to implement with Rails 2.0:

# In a controller or module shared between admin controllers
before_filter :ensure_administrator
def ensure_administrator
	authenticate_or_request_with_http_basic('Blog admin') do |username, password|
		username == 'dhh' && password == '123'
	end
end

A very visible change in Rails 2.0 is the naming of views. The .rhtml, .rxml etc. file endings has been discarded to replaced by the form [name].[mime-type].[renderer]. This leaves the road open for file names such as:

• index.html.erb
• index.xml.builder
• index.html.liquid
• index.iphone.erb

The last example needs a little additional configuration, since iphone is not a “real” mime-type, but we can easily make Rails treat it like such:

# In mime_types.rb:
Mime::Type.register "application/x-iphone"

# In application.rb:
before_filter :adjust_format_for_iphone
def adjust_format_for_iphone
	if request.env["HTTP_USER:AGENT"] ~= /iPhone/
		request.format = :iphone
	end
end

# In specific controllers
respond_to do |format|
	...
	format.iphone do
		render :text => 'Hello iPhone', :content_type => Mime::Html
	end
end

Notice how content_type must manually be set to Mime::Html, as the iPhone browser – as well as any other browser – doesn’t recognize our fake x-iphone mime-type, and Rails will always default to respond with the request mime-type.

My second favourite point was about the “new” debugging support in Rails 2.0. As I understood it, the well-known ruby-debugger library has been baked into Rails 2.0, so that we write debugger instead of breakpoint, and need to start the server with a --debugger prefix (./script/server --debugger) to enable these breakpoints. This debugger also support more advanced commands such as “cont” (continue), “list” (view current code) and “up” (step out).

David Heinemeier Hansson rounded off his keynote by announcing the release of a Rails 2.0 Preview Release (how Microsoft-ish does that sound?) either during or shortly after the conference.

You can download my full notes from the keynote here.

UPDATE: My other notes from RailsConf Europe 2007 are now available.

Dave Thomas officially kicked off RailsConf Europe 2007 in Berlin with his keynote; The Art in Rails. He was fast to point out the fact that he, during the first ever RailsConf in Chicago last year, made major mistake talking about Rails itself, and that he hadn’t done that at a RailsConf since then.

Dave Thomas went on to reinforce a point he, and many others, has made before; that software engineering is like art, and that the programmer is like a poet. Like a poet, a programmer can suffer from a writers block, and the best way to get out of that is to use prototyping. He pointed out exploratory testing as his favorite way of doing prototyping; a way of realizing prototypes through unit tests and mock objects.

His two other major points about the programmer as a poet was that you have to know when to stop, and that you must satisfy the customer. For the former, he stressed modularization and iterations as perfect ways for breaking up the development process into fixed pieces of functionality, and into a fixed amount of time.

For the latter, Dave Thomas explained the difference between taking a picture and making a portrait for artists. Painters rarely just paint a person reflecting the reality exactly as it is; they try to look deeper into that person and let his or hers personality into the painting – this process transforms the painting from merely a picture to an actual portrait.

The same thing goes customers of software projects. “We all need to get into the habit of not listing to our clients” Dave Thomas said, meaning that we need to dig out the customer’s real needs by looking beyond the surface and always ask why, why, why?

Finally the notorious author and speaker made the point that there is art in engineering, ad engineering in art. Ruby is the paint and Rails is the canvas. Dave Thomas urged everyone: “Treat your next project as if it was a work of art”:

• Be an Artist
• Create Something Great
• Create Something Beautiful

You can download my full notes from the keynote here.