These days it seems to be conventional wisdom to build "skinny" controllers in your Rails app. Skinny controllers help you to consolidate your business logic into one place (the model) which allows for easier maintenance and testing. If you're still not convinced, perhaps you should watch this informative public service announcement.

I've been using the excellent resource_controller plugin by James Golick for well over a year now. Its an excellent tool for handling the standard RESTful controller actions that one normally codes by hand (or generator.) We currently use it in the Spree project and yesterday I was curious to compare the size of these controllers to those of a project that does not use resource_controller. First lets look at the results of running "rake stats" on the Spree project.

As you can see, there are 44 controllers in this project. Yeah, that's a lot of controllers but Spree is a pretty huge project (its a full featured e-commerce platform.) Now notice that out of 44 classes we only have 111 methods. That's an average (rounding down) of only 2 methods per class! The methods themselves are also pretty skinny with an average of 8 lines of code per method.

Now lets take a look at Fat Free CRM. I chose this project because it is similar to Spree in that its a full featured platform (not just a little plugin.) DISCLAIMER: I've never used this application but I've heard good things about it. I'm in no way trying to disparage another person's work here - I just need a point of comparison.

You can see that this project's controllers are pretty fat. There are only 12 of them but they have more lines of code then in the 44 controllers of Spree. There are 11 methods per controller (compared to 2 in Spree), with the typical method size being the same as Spree. Don't let the equivalent method size fool you. For instance, take a look at this typical 4 line method in a Spree controller.

create do
  flash nil 
  wants.html {redirect_to edit_order_url(@order)}
end

This is an example of how we override the default resource_controller behavior. In this specific case we did not want to include anything in the flash, nor redirect to show after object creation. If you're happy with the resource_controller defaults, this method is not even needed.

If you're interested in a thorough overview of resource_controller, Fabio Akita has produced a very detailed screencast on how it works. Its one of the longest screencasts I've ever seen (about 1 hr) but its well worth the time if you're struggling to wrap your head around how REST works in Rails (both with and without resource_controller.)

@GreggPollack put together an excellent RubyHeroes presentation before the keynote.  In addition to recognizing some of the great contributions these individuals made, Gregg suggested that we all take a moment to thank at least three people whose work has made our lives that much easier.  So instead of getting caught up in minor complaints about the accomodations or speeches, I decided to throw out some more positive energy.

1. GitHub - I'm not going to waste a lot of space talking about how much of an impact GitHub has made on the Rails community.   Its not like these guys are toiling away in anonymity but their contribution has been so important that I'm just going to go on record as saying "Thanks."

2. Phusion - Again, everyone knows what these guys have done for simplifying Rails deployment.  Just because they get plenty of "Thank Yous" doesn't mean I can't throw my own two cents in here.  I also had the opportunity to thank one of the Phusion guys in person at dinner this evening.

3. ResourceController - James Golick's plugin finally convinced me to embrace REST.  If you're not familiar with it, its a great way to simplify the implementation of your standard RESTful controller.  My controllers became way more DRY as a result.  Again, saw James at dinner and shook his hand in person but it doesn't hurt to say it here.

Honorary Mentions:

• DHH and RailsCore for Rails (DUH)
• Chad Fowler and company for organizing RailsConf
• Gregg Pollack for the Ruby Heroes presentation, conference videos and the entertaining RailsEnvy podcasts (along with Jason Seifer.)