Ruby on Rails Exchange, London

Last Friday, a couple of us from “SonicIQ”:http://www.soniciq.com went to the first “RoR eXchange hosted by Skills Matter”:http://www.skillsmatter.com/rorexchange.

It was a great day with some interesting talks from:

* Chad Fowler
* Tom Locke
* Paul Battley
* James Cox
* Damien Tanner
* Ben Griffiths
* Eleanor McHugh

h3. Chad Fowler – Quick and -Dirty- Clean: Well factored Rails

Chad kicked off with a talk on “Quick and -Dirty- Clean: Well factored Rails”. For me it was one of those talks where you think “If only I heard this 6 months ago!”. The reason I say this is that a great deal of what he was talking about, we now implement on a day-to-day basis, but we have gotten there the hard way through making the mistakes that he mentions.

He talks about never using instance variables in views, I love that someone has confirmed this as I find it generally bad practice. For a while now we have been replacing them with helpers giving much more flexibility when the controller logic changes.

One great point that was made, was that SQL should never be used in controllers, not even in :order options. I have to admit, in the past I have done this a lot but the suggestion of custom finders in the model are a much better alternative and it keeps with the whole “Skinny Controller, Fat Model”:http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model idea.

One thing I really must get into the habit of using are association proxies for has_many and such like. Chad showed some great examples of this.

I like one phrase that Chad came up with… “Bare Model Finds” which made me chuckle. What he was getting at was something like an account based site where everything should be found via the given account i.e. @account.projects.find(:all)

as opposed to a “Bare Model Find” of Project.find(:all, :conditions => [‘account_id = ?’, @account.id])

The main points I have taken away from this talk (which I am also going to put in a large poster on the office wall) are the folowing:

* No instance variables in views
* No SQL in controllers
* No more than 4 lines in controller actions

h3. Tom Locke – Experiments with Very Rapid Development in Rails

Tom gave a demo of his “Hobo”:http://hobocentral.net/blog/ project which is very similar to a plugin we use in-house (which also may go open source at some point).

One thing I like about Hobo is the incremental nature of the “dryml” views, meaning that you can override certain elements in a default view bit-by-bit, i.e. if you just want a different header for a certain page you don’t need to create a duplicate of the view and change it, you only need to redefine certain elements of the page.

I completely agree with Tom’s views on generators, although he was slightly more diplomatic than I would have been. I am going to be slightly controversial and say that I really don’t like generators except for creating stub files. What happens if you have an authentication system generator which you have used in 50 projects and you suddenly find a security hole?? …You now have to go back through those 50 projects to fix it! [end generator rant]

h3. Paul Battley – Rerouting Rails

Paul attempted to explain how he believes the rails routing system should be re-written. I could see a lot of merit in what he was saying, however I don’t believe it lent itself very well to this type of presentation.

h3. James Cox – Managing a high performance rails app without tearing your hair out

James gave some great tips on easy ways to increase the overall performance of Rails apps. We are in the process of configuring a new server so these tips came at a good time.

h3. Damien Tanner – Extend your Rails application using Domain Specific Languages

Damien explained a roundtrip his company went on with DLS’s explaining that they are great in certain situations but can be taken too far or overused. In the example he gave, it turned out that the DSL he created was overkill for the business problem he was trying to solve.

h3. Ben Griffiths – Are your tests working for you?

For me, this and Chad’s were the presentations that made the trip to London worth while. I am ashamed to say that until now, I have not gotten into TDD (I’ve been using Rails for over a year and a half). It’s not through lack of trying but with clients constantly on your back to get projects out the door, it’s all to easy to dive straight into coding the application and neglecting the tests.

He started with a comparison between testing and the film Predator. This sounds like a strange comparison however it really helped to illustrate the need for a good set of tests.

My main problem with tests were “what do I test?” and “my fixtures need too much maintenance!”. I breathed a sigh of relief when Ben suggested not using fixtures at all as maintaining a load of fixtures really turned me off testing.

This was a great talk and I could bang on for hours on the benefits of testing with Ben’s techniques and his whole take on modular design but I’ll save that for another post. As a side-note, I have been doing TDD ever since this talk.

h3. Eleanor McHugh – Where’s my SQL? Platform-independent database design using Migrations

Eleanor gave some examples of how migrations could be extended with plugins. A lot of the examples she gave were based on what has been implemented in Hobo. There were some interesting points in the talk although my concentration levels were frayed by this point.

h3. Group Discussion

The main point of discussion was views. I think everyone was in agreement that something needs to change with the way Rails handles it’s views. I personally believe that they should be purposefully limiting so that it is hard to do bad things in the view. I am looking forward to seeing views taken to the next level and believe that there will be some large changes before 2.0 based on the comments during this discussion.

h3. After Party

The guys at “Skills Matter”:http://www.skillsmatter.com put on the first 100 drinks at “Liquid” – a Japanese-themed bar. We had a chance to mingle and discuss a few of the points that we forgot to ask after the talks.

Thanks to all the speakers, all in all a great day out.

Videos of some of the talks are now “available online”:http://skillsmatter.com/menu/479. Also, my colleague “Andy”:http://darkliquid.co.uk has blogged about his take on the day: “Part 1″:http://darkliquid.co.uk/2007/2/10/ruby-on-rails-exchange, “Part 2″:http://darkliquid.co.uk/2007/2/11/ruby-on-rails-exchange-part-2.

Published by

Jamie

Hi, I am the Managing Director of SonicIQ Limited in the UK. I have been working in the web development industry since 1999 and have been running SonicIQ since 2001. Currently Ruby On Rails is my preferred development platform. I am experienced in designing with web standards, HTML5, CSS3 and Javascript.

2 thoughts on “Ruby on Rails Exchange, London”

  1. Long time no speak, I would have dropped by to say my quick hi over Xmas. Hope the the move to the new office went fairly smoothly. How many times how you moved office now?

    Interesting that Chad mentioned about avoiding instance variables. I must say I disliked the use of instance variables, In the odd little pet projects I’ve been playing with I’ve often made private controller methods to avoid the nasty use of @, and made them helper methods occasionally. I can’t say say I’ve gone all the way to eleminate their use though. It’s good to see other people think alike.

    Association proxies is something I’ve been pretty poor with, and I’ve often not though about my design and ended up with slightly bloated/disjoint models, despite knowing about the AssociationProxys for well over a year now. It does help avoid some of the clumsy use of SQL. I don’t suppose you’ve seen a lib called Squirrel? I’ve skimmed through it at ….

    http://giantrobots.thoughtbot.com/2007/2/13/a-convenient-squirrel-addition

    It’s got a nice elegant syntax to replace common SQL queries. I wonder if it would work on the find method found in associations because it qould kill a lot of nasty find criterias. My main concern is how robust the plugin is as it’s not heavily used.

    About your point about how Rails deals with views, I must agree there. One of my issues I have found when I’ve occasionally bothered to do any coding is that I end up moving a number of methods into models because what I am trying to do is common to a number of views. I think a lot of other people do the same, and especially now that Jamis made a point of it in the Skinny Controller, Fat Model post on his blog. Thinking back in retrostect the other day I thought it’s probably best to move this sort of stuff into helpers, because this sort of code doesn’t really belong in views nor models. It’s almost like like the paradigm of MVC is slightly lacking unless there is decent use of helpers. Certainly I would argue in Jamis’ post http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model that methods like age, name etc might be better as helpers.

    Interestingly, it looks like controllers will support multiple view folders in version 2.0… http://weblog.rubyonrails.org/2007/2/4/new-feature-for-rails-2-0-multiple-controller-view-paths which might prove handy for applications that need slighly more flexible skinning.

    Certainly I agree with the fact that views are due for some changes. After all Rails 1.2 was mainly controller and routing changes, and rails 1.1 was mainly ActiveRecord association changes (I guess some view stuff was touched on with the introduction of RJS).

    As for testing, it’s good to see you’ve picked up on using it. (though I gotta say I rarely think about making proper test myself, and if I do they are normally just for tedious model related things). I seem to remember preching about testing back in the days when we used PHP. Like mainy, I’ve found fixtures a pain in the backside. My biggest issue with fixtures is they are a global dataset. This basically means that when you change/add some fixture data to suit the needs of a new test you end up breaking some other tests that rely on the same fixtures. On the odd occasions I’ve bothered to write tests, I’ve kept fixtures to a minimum. The other pain with fixtures is the fact if you change you DB tables (i.e. add or remove rows) fixtures need to be cleaned up.

    Chad’s point about SQL’less controllers is a really good point. It’s never crossed my point, but I must agree that controllers are the wrong place for SQL.

    Anyway, hope you are all keeping well and hope you aren’t having to do too much overtime!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>