Notes and impressions from RailsConf 2009

I’d never have guessed that the first time I’d visit Las Vegas, the gambling and the drinking, the shows and the shopping would be a minor thing, something that I’d squeeze in between what really mattered. But RailsConf 2009 had such a comprehensive and interesting program that this ended up being the case. From the casual networking at breakfast and lunch over packed keynotes and high-quality talks to late-night Birds Of a Feather sessions, RailsConf did give the attendants any reason to step out if the air-conditioned Hilton and into the sun and lights of the Strip.

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.

Continue reading

Introductions to Ruby on Rails

You have at least two chances to get introduced to Ruby on Rails by yours truly this year. I do a presentation on Rails with a focus on ActiveRecord, the ORM of Rails, on Commity Day 2009 in Copenhagen. I am also teaching Rails used with agile methods at Copenhagen Business School this fall.

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? :)

Hello Merb

Merb is getting merged into Ruby on Rails. Together they will become Rails 3, as announced by David Heinemeier Hansson here and Yehuda Katz here.

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.

Continue reading

RailsConf Europe 2008 write-up

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])}"

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.

Continue reading

David’s RailsConf Europe 2008 keynote: Legacy, concerns and DRY exceptions

Be proud of your legacy code. Extract concerns. Make exceptions from DRY. David Heinemeier Hansson’s keynote at RailsConf Europe 2008 was titled “Living with legacy software”, and centered around the notion of how to deal with your own old code. The articles summarizes the talk.

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.

Continue reading

Notes from RailsConf Europe 2007

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

RailsConf: The DHH keynote – Rails 2.0 update

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.

David Heinemeier Hansson
© 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

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|

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'

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

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

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.

RailsConf: The Art in Rails

Dave Thomas

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.

RailsConf: People I met

RailsConf was a blast. But I barely had the time to consume all the impressions, since my vacation was just after the event in Chicago. So I went directly to Roskilde Festival, North Europe’s biggest festival with 100.000 partying people near Copenhagen, Denmark, and from there I got on a bus to Rumania as part of choir singing Danish songs in the Rumanian churches. When I got back, I realized my blog had gained quite a lot of attention (at least compared to its very silent past), not at least my posts on David Heinemeier Hansson’s and Paul Graham’s key notes. While 70 subscribers and 200 visitors a day doesn’t sound like much to some, it fills me with a certain amount of humility: “Surely people will expect my future to be of high professional quality and deep insight”, I think.

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.


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!


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.

RailsConf: Create, Read, Update, Delete: Normalize

(Looking for DHH’s keynote at RailsConf Europe 2007? Find it here)

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 = do |p|
	p.uri “”
	p.credentials :name => “dhh”, :password => “secret”
matz = Person.find(1)

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


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