We did that anyway, obviously, but mostly we were learning, tweeting, chatting, coding, emailing and taking notes at a conference where the wifi actually worked and power strips were easily available. I’m not going to reference all the talks that I went to here, but I have uploaded my notes here. Also, I’ve written a detailed summery of David Heinemeier Hansson’s keynote and a few select talks that I attended for RailsMagazine, but the free PDF-edition won’t be available for another two weeks now freely available for download … slides from all the presentations can be found here.

So what did I take away from RailsConf from the top of my head? The first that springs to mind, is that I got to try RubyMine, a new IDE for Ruby on Rails. At first glance this might look like another Aptana or Netbeans, but the Rails Envy guys gave a stunning demonstration of the power of this new IDE: From TextMate keymapping and navigation, over code completion and refactoring that actually works, to automatic diagramming of models and their relationships, this product looks like a real productivity booster. I’m going to try it out the minute I get home.

Rack kept popping up everywhere. Lots of talks on Rack and Rails Metal (which is really just a wrapper for a “raw” Rack handler), and now Rack suddenly doesn’t feel so scary anymore. It just a way to do cool things on a raw request and/or response without the (full) overhead of the Rails stack. JRuby was another popular topic, as well as clouds – how to deploy to server environment that will seamlessly scale with your needs.

I have been following IronRuby with great interest since the project was started 2-3 years ago, and I was a bit disappointed to hear that the .NET implementation of Ruby is still nowhere near completed. I asked Jimmy Schementi from the Microsoft IronRuby team what took them so long (to be honest, I was a bit rude, sorry Jimmy), and asked that things simply took time. He said that JRuby had been 6 years underway. The positive news, however, was that the IronRuby team is still very committed to making their implementation fully Ruby 1.8 compliant, and that are using Rails to measure their success against.

I’d love to tell you more, but my plane is leaving soon, so you will have to make do with my notes.

Community Day 2009 is free 1-day event May 28 in Copenhagen sponsored by Danish developer communities. Besides my two cents, it also features presentations on Android, Flex, Air, Silverlight, LINQ, Drupal, jQuery and ASP.NET MVC – in other words it looking to be a lot of buzzwords and popular technologies explained. As if that wasn’t enough, the day also include three geek-friendly meals, friendly competitions and lots of free beer.

The course I will be teaching at Copenhagen Business School is called Agile Development in Practice, and builds upon a theoretic platform of agile methods. The course focus is on giving the students practical experience with Scrum and Ruby on Rails through a combination of traditional teaching and working with real-life examples. The course is free to attend for all Danish students, and counts for either 7,5 or 15 ETCS points. Others can also enroll in the course for a fee. The course description is not yet available on the CBS homepage, but I will link to here as soon as it is ready.

But before all that, I myself will hopefully learn many new and useful things about Ruby, Rails and all things geeky at RailsConf in Las Vegas. See you there? :)

I wish I could claim to have been playing with Merb for a while and have some real insight into the framework, but to be honest, I haven’t. I still think this a very interesting news, though, and in my opinion this can only be good news for the Rails community. Already, the brilliant Merb guys are optimizing and improving Rails, for instance this 8% speed boost in using respond_to.

So, how can we expect the the merge to affect the Rails framework we know and love? Let’s peek into the possibilities of combining these two frameworks.

One change that seems certain, is changes to the routing system. “Plans are already underway to port the Merb router over to Rails. At the very least, you will have the option to use the Merb DSL syntax instead of the Rails hash-based syntax. We’ll see which one becomes the default.” Katz says. David explains how Merb concepts for rendering resources in different formats will be used in Rails 3, but with more intuitive or “Rails-like” naming.

Another change which is likely to make it into Rails 3 is slices, as indicated by Katz in a response to his own announcement. Slices are “similar to what Rails-Engines promise, except merb-slices are built into the framework” as Ezra Zygmuntowicz explains. This is exiting news! I’ve always been interested gaining leverage by having reusable application slices, and I’ve actively built and used both Rails Engines and Radiant extensions. Engines has previously been frowned upon by leading figures in the Rails community, but it has been improved to work in a quite clean and easy-to-understand manner since the release of Rails 2.0, and are in fact compared to Merb slices here. Radiant extensions are obviously only for Radiant CMS-based websites, but the diversity of these extensions illustrates the potential of getting support for real full-stack application slices into the Rails core. A project like Adva CMS also illustrates how it is possible to build high quality reusable application slices for the common good.

A third change I hope to see as a result of the merge is controller-based mailers and partials. ActionMailer has always been a bit of an ugly stepchild in the Rails framework, and the positioning of a Mailer as a sort-of model, but with templates, doesn’t seem logic to me. Merb has an AbstractController class that both mailers and partials (called parts in Merb) inherit from, which allows for a more intuitive control in rendering mails and parts.

I was curious to find out how the Merb community has reacted to this decision. The Rails community doesn’t seem to be overly concerned. Perhaps it’s because the merge of Merb and Rails are called “Rails 3″. Not “Merb 2″, not “MerbRails” – the names clearly signals that the merge will be done on Rails’ terms. While it has become popular in the Rails community to dissociate one self with David Heinemeier Hansson, I still think people sees him as a good security for not letting the Rails principles go in the merge.

I browsed through the more than 100 comments to Yehuda Katzs announcement of the merge, and while about half of the commenters simply expresses their happiness and agreement with the decision, the objections of the other half falls roughly into three categories: Technical, personal and economic.

The technical concerns are of course fully expected, and some of the more interesting are:

• “Does merging a lightweight framework into a bloated framework make the bloated framework any lighter?”
• “I really hope that merb will be able to continue it’s ‘no-magic’ attitude and bring that to rails without compromises”
• “I would have liked to see merb go further on its own just to push the envelope further”
• “How many planned advancements are being put on hold while Rails catches up?”

The personal objections is about one very visible person: David Heinemeier Hansson. I hold no grudge against David, so I shall only repeat one of the more curious comments in this category: “The big problem, as always with Rails, is DHH: a vainglorious, two-faced prima donna with a massive and fragile ego. He’s good, but not nearly as unique and amazing as he thinks he is. I went to Merb to get away from DHH. Ugh.” If many people in the Merb community feels like this guy, I understand if they are concerned that David will simply steamroller the philosophy of Merb. David has been fast to address these concerns, but the question is if just saying everyone should work on what the care about is enough.

The economic perspective of the merge is where things gets interesting. Rails is trademarked by David and synonymous with 37signals, while Merb is very closely linked to EngineYard. Two commenters really nail it down:

• “How has the ‘Opinionated Software’ philosophy of “Fuck You (DHH)” Rails become aligned with the ‘open’ and democratic philosophy of Merb? Is this some kind of preemptive marketing in advance of a joint investment in both Engine Yard and 37 Signals by a common investor?”
• “My suspicion turns to the fact that almost every Merb core team member is owned by Engine Yard. Something doesn’t smell right.”

It’ll be interesting to follow not just the architectural design choices made on the technical front during the merge process, but also how this will change the positioning of 37signals and EngineYard, and if the two companies are really warming up to some kind of close relationship.

The timeline for a first peek at Rails 3 – the union of Merb and Rails – is said to be RailsConf 2009 – 4 months from now.

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.

© 2008 James Duncan Davidson

Rails has been around for 5 years now, and that’s an eternity in software, David said. People who are moving to Rails, see the platform as a salvation for their legacy applications, and as an excuse not to have to think anymore. That’s wrong, David pointed out with a big read slide.

People use the term legacy as though it is a well-defined attribute of code base, but it is really an personal opinion. “PHP is legacy! Java is legacy! – well, that one may be right”, David said jokingly, but really legacy is about your own evolvement of your taste, your knowledge and your personal preferences. Most people who wrote legacy code, thought the code was great when they wrote it. Later people’s perspective change, and even though the code hasn’t changed, it is suddenly considered legacy.

David compared code to a tomato. In the beginning you have a beautiful red tomato, but before you know it, it has turned into a rotten tomato. But it is not the software that change, it doesn’t rewrite itself. The code is not making itself worse, it is our perception that change. So why see legacy as a rotten tomato? Why can’t it be about you? You got smarter. You learned more. When that tomato got rotten, that was a process in you. That’s not something to feel sad or depressed about, that’s cause for celebration. Legacy software is not a negative thing, it’s a positive thing, as it shows that you have grown as programmer.

If you don’t accept that your code will become legacy, you will be disappointed again and again. The best programmers write the most legacy software. The more software you are writing, the more you are looking back thinking: “This feels stale and old”, the better you have become. Howver, you don’t change your perceptions as much when you have working with a platform for 5 years. The better you become, the longer you must spend on a project to learn something.

David quoted Joel Spolsky: “Good software takes 10 years to write”, but then rephrased it to: “Truly successful software takes 10 years to write”. If you want to make something successful, you are going to have work with it for a long time. “Now is the time where Basecamp is having the most impact and reaching most people, so now is the time where I should be most engaged in it”, David said. The goal for everybody should be to be involved with software that could take 10 years to write, and be happy about it.

Another Joel Spolsky quote is: “The single worst strategic mistake that any software company can make: Rewrite the code from scratch”, and I fully believe in this, David said. “Basecamp was the very first project I wrote in Ruby, along with Rails. In so many ways, Basecamp felt so legacy to me.” But you can’t solve all your legacy decisions in one big swoop, you have to do it step by step.

As a rule of thumb for cleaning up legacy code, David used: “You have to leave the code you touch in a better condition than you found it”. As an example, he showed the ApplicationHelper from Basecamp: 500 lines of different helper methods for a broad variety of purposes. The ApplicationHelper was introduced to solve the problem that helper methods, used in multiple controllers, had to be extracted into modules and included everywhere they where needed. Unfortunately this has turned ApplicationHelper into a garbage can – a broken window. Today, we can just write helper :all in our controllers, and this allows us to extract methods into separate helpers with describing names such as LayoutHelper. In fact, ApplicationHelper is supposed to be empty. It is a staging point, where you put things you don’t really know where to put. Just like you put things in lib before you put them in a plugin. But eventually, methods in ApplicationHelper should be put into separate helpers.

Then David introduced the notion of a concern. As an example, he showed the Person object of Highrise, which has a relation to configuration. This is only used for recording if the has seen a certain system notice, and is not really a core part of what defines a Person. For this reason, the code should be extraced into a concern, which is nothing more than a module with certain aspects of Person. A concern is not introduced for the purpose of reuse, but to heighten comprehension and coherence in your application.

A last point in the keynote was that exceptions from the DRY principle (Don’t Repeat Yourself) exists. It can be really hard to change just one thing a completely DRY application. As an example, David explained that Highrise has the abstract class Recording, which fits pretty well with three subclasses, but was giving him problems when a fourth subclass, quite different from the others, was introduced. This resulted in a very complicated view partial for recordings, and a more pragmatic solutions was to create a separate view for the new subclass, duplicating some code, but eliminating a lot of checks in the original partial.

Legacy ain’t so bad, David finished off, it keeps you honest about yourself and how you are growing as a programmer.

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

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

See, my problem is, that while I seem to do pretty good on referencing what really, really smart people say and adding a bit of my own pocket philosophy, I find it a wee bit harder to provide genuinely usable Rails knowledge on my own. I have plans for posts about my on-going experiences with Substruct, and about my struggles with actually being RESTful when developing, but for now, as a way to scare most of my newly gained audience away again, I’ve decided to write a completely non-technical and probably quite un-insightful blog about some the great people I met at RailsConf.

Always taking the analytical approach to things, I have divided those people into two categories: The VIPs and the VFPs. The first are VIPs of the Rails community; key note speakers, widely read bloggers, authors, etc – people I wanted to meet because I admired they work, but who won’t actually remember they met me afterwards. The second are some of the Very Friendly People I met at the conference, that is; people that I didn’t know beforehand, but that I ended of talking a lot to during the event. Of course the VIPs where also friendly, and the VFPs are probably also important (to some people), but most likely being a clever geek, I’m sure you get the idea.

VIPs

David Heinemeier Hansson: Of course everybody at the conference wanted to meet DHH, and my twist was supposed to be to surprise him by talking Danish to him. In fact I happened to be talking to David Black when DHH came along, and Black was so kind as to introduce us and take our picture, but there wasn’t any time to talk further, so I can’t say I have any insight on DHH I can share.

Geoffrey Grosenbach: I had a great deal of respect for Geoff because of this persistent work with the Ruby on Rails podcast and his many insights about deploying, so I really looked forward to attending this talk and meeting him. It was strange to look at the guy and hear his unique voice I knew so well from the podcasts; kind of like meeting some one talking like Darth Vader.

Amy Hoy: Amy is – literally speaking – a colorful part of the Rails community. Probably the most well-known girl in the community and the only female speaker at the conference, I of course had to meet her. I did, and she willingly lined up for a photo. What I don’t like about Amy is that she keeps reminding me that good – and fun – writing is hard work, and I just don’t have the patience to rewrite a sentence five times like she does, which means that my blogs will never match hers in enjoyability, I’m afraid.

David Black: I meet Black at “day 0″, where I didn’t get to participate in the Guidebook session, so I went early into the room reserved for improvised events, where he sat all by him self with his Mac. I didn’t know who he was – in fact, I thought he looked completely wrong in the setting (remember, the conference wasn’t started yet, and I hadn’t yet realized that Ruby gurus generally mature, bearded men), but he explained to me that he was the organizer. Later that day, I bought Black’s book in Chicago and got it signed by him – nice!

VFPs

Tim Trautmann: Migrated from Germany, Tim was the closest thing to a European I got to know at the conference. We enjoyed a nice dinner Friday, and he was part of the drinking buddies sitting outside the bar. Tim is a consultant, having a one-man company with a funny name I seem to have forgotten.

Jeremy Seitz & John: When I realized that nothing was going to happen at “day 0″ besides the Guidebook, I went to Chicago. I met Jeremy and John waiting for the shuttle bus, and we ended up buying a brand new Macbook for John at the Chicago Apple Store. I can’t seem find John’s last name or blog, but both of J’s was great fun to hang out with through out the conference days.

Brian Eng & Jeff Cohen: Meeting the Softies was definitely one of my goals at the conference since I really like their blog, and they turned out to be extremely friendly and great company. These guys actually works in cubicles like they do in Dilbert (which only seems to amusing to Europeans), so you’d think they be grumpy and bitter, but they where all smiles and even paid for our dinner at Chilies – I owe you one, guys!

Hisa: This cool Japanese actually wrote the RubyCocoa framework, which I definitely want to try out once I get my hands on a Macbook, and we talked many times during the conference. Hisa wasn’t bothered about his English being a bit rusty, and a really funny thing he explained to me, was that he found it just as to distinguish between western people, as we often find it to distinguish between Asians. Fair enough!

Jim Greer: Once the conference ended Sunday afternoon, Jim was one the people that – like me – was staying at the hotel till Monday. A minor hack fest formed in the bar that evening, and I sat opposite to Jim, writing on my blog about DHH’s key note. I discussed the whole normalization issue with him, and this actually inspired Jim to start up his blog and write his first post, which was later referenced in DHH’s blog about the issue. Jim is starting a web game company in England, and I’m pretty sure he will be a success.

Victoria: I had a great conversation about everything from the Rails community to the differences between USA and Denmark with one of the very few girls at RailsConf, while I was trying to spot James Adams, the creator of Rails Engines, with out any luck. Victoria was attending the 37signals workshop the following week, and I believe she promised to blog about it…

I met plenty of other nice and friendly and important people, but this has to end some where. I wish I could finish telling you how I much I look forward to RailsConf 2007 and seeing some of these people again, but the fact is that it’s very unlikely that I’ll be there. The conference is in May, and I’m in school – what do you do in school in May? You have exams. Tough break.

I’d been looking forward to David Heinemeier Hanssons (DDH) key note in the same way I’m guessing people looks forward to hearing Bill Gates and Steve Jobs talking at the big Microsoft and Apple conferences. Any community needs its mythical founder amongst whom the community can revolve, and DHH makes a good job of filling that role, backed up by wise men such as the Fowlers and the Pragmatics.

DHH had just returned from a trip to a Ruby conference in Japan, and – still very much jetlagged, as he explained later that evening in the bar – introduced the topic of his key note: CRUD. Create, Read, Update, Delete. An idiom so widespread that they even teach it in my Java-centric school, an abbreviation that lays out the four basic operations of manipulating database tables. DHH explained that he has lately started seeing all his code in the light of CRUD, in fact, he starts to spot “crudness” everywhere – perhaps CRUD can be used as the basic pattern for making beautiful code?

DHH pointed out the similarities between CRUD, database operations, Rails actions and – last but not least – the http methods:

• Read, SELECT, find and GET
• Create, INSERT, create and POST
• Update, UPDATE, update and PUT
• Delete, DELETE, destroy and DELETE

When you browse to a url like GET /people/show/1, you are basically repeating yourself: show is redundant, because the http method sent by the browser has already specified that you want to do a GET. So the beautiful version of the url would be GET /people/1, just as PUT /people/1 is more beautiful than POST /people/update/1.

The problem is, however, that even though the http protocol specifies all of the mentioned methods, only GET and POST has achieved wide spread use, and thus, specifying PUT or DELETE as the method on a form tag won’t work as intended, since browsers just ignores it and defaults to GET, and if even if it is capable of passing the method on, many web servers and proxies sees the use of methods like PUT and DELETE as unsafe and rejects them. No problem, DHH said, we’ll just fake it in Rails using a hidden field to specify PUT and DELETE methods. This should raise some alarm bells, he continued, and it certainly did with me. By using a hidden field I get ugly flashbacks (well, wish they were flashbacks, I’m still doing loads of .NET) to the heavy use of hidden fields in .NET which result in 500 KB pages – excluding images – so asked, at the Rails Core Q&A session, if this wasn’t a slippery slope taking Rails in a wrong direction?

No, DHH answered without hesitating, we’ve done plenty of things that could be a slippery slope before. It’s a hack, and we might be able to take it away eventually, but right now it’s the way to go. I guess I’ll just have to try it out, since the Simply Restful plugin, which promotes this kind of urls, will be implemented in Rails 1.2, according to the Rails Core team (and they should know it).

Tightly connected to the point about restful urls, is DHH’s newly found desire to promote controllers that only do the four CRUD operations. Basically, he argues, if you have more than the default actions in a controller; index, show, list, new, create, edit, update and delete, you haven’t thought enough how to structure your controllers and actions. If have “scoped” actions like add_user or post_comment, you haven’t “crudified” your application, and you should move those actions to a UserController or a PostController.

As I discussed later with Victoria, many of the brilliant people at RailsConf are self taught college drop outs doing cool projects their own way, instead of worrying about learning the “right way” at school. But with this “crudness” or “crudiness” DHH wants the controllers to respect, I actually think he is trying to phrase a concept both of us learned about, while getting our bachelor’s degree in Business Administration and Computer Science at the Copenhagen Business School: Normal form. Normal form is known concept throughout logic, language and mathematics theory, but from my education, I know it from database theory. It’s all about optimizing your database by normalizing your tables into a certain normal form, and I’d guess that’s what DHH wants us to do: To normalize our controllers.

I realize DHH is not too interested in databases – during the Rails core team Q&A he said in fact: “I don’t like databases. I pretty much use them as hashes.” – but I like the analogy, and I propose we start talking about normalization in this context, because really, normalization is just another word for beauty. However, beauty is a bit unspecific and it’s widely used to describe anything good in Rails, so why not instead say: I’ve normalized my controllers and action to the CRUD normal form. There are in fact things we can learn from traditional school paradigms such as relational algebra or object oriented design, or maybe it’s just general programming wisdom which has some how snuck into education, and one of those things is this: “If you think about it a bit harder, a simpler approach will appear.” (DHH). You do this when you normalize databases. You do this when draw UML diagrams. And now you should do it when you normalize controllers – think simpler, think CRUD!

But: CRUD is not a goal in itself, it’s an aspiration, a design technique, DHH emphasized, and normalizing (“crudding”) won’t be the answer to everything. Basically though, you can normalize anything, and DHH gave examples with the state of case having its own model and its own controller – this way, the CaseController was normalized, and didn’t have to had any add_state actions or something like that – instead, these actions was implemented in the StateController through the standard CRUD actions. At first, DHH explained at the Rails Core Q&A, he thought login was an example of actions that couldn’t be normalized, but Jamis Buck had the solution for this, implementing CRUD actions on a SessionController, since that’s basically what a login does; adding and removing stuff in the session.

Enough with the theory. The big revelation of the key note was a new API DHH started hacking away at two days before the key note; Active Resource. The API is basically all about describing things as resources, and as I understand it after discussing it with Geoffry Grosenbach and Chris McGrath, it’s basically an alternative to Action Webservice based on the REST concept. Since it’s still work in progress, I’m not really sure it’s going to work at all, but it seems like it will usable for both providing an API as well as consuming it. I guess DHH don’t want to repeat the work on the Basecamp API now that he is doing Sunrise, but also, he wants to emphasize that almost anything can be viewed as a resource. Active Resource will be released as a small, compact plugin as part of Rails 1.2.0, and basically, it sounds like that release will very much focus on the REST principles, and on making the Rails core smaller by pulling thing out in plugins.

The example DHH gave on using Active Resource was based on his notion on viewing XML basically as a hash. So perhaps your code would look like this:

Person = ActiveResource::Struct.new do |p|
	p.uri “http://www.example.com/people”
	p.credentials :name => “dhh”, :password => “secret”
end
matz = Person.find(1)

- and Active Resource will automatically wrap the XML response, which could look like this:

<person>
	<name>Matz</name>
</person>

For now, we’ll just have to wait and see what turns up in Edge Rails and try it out.