has_many :thoughts: Tag RailsConf07

Skinny Controller, Fat Model

Colin A. Bartlett — Fri, 01 Jun 2007 21:07:00 -0400

One of my favorite talks from RailsConf was by the team behind The Rails Way. Now back from the road trip and settled in, they have updated their site with some more details about one of the ideas they pushed: Controllers should be simple, basic, and generally have a lot less code then most of us use now. Most of your logic should end up in the model.

There’s many reasons for this but the three I like the most:

It forces you to write code that more easily reused. Limits your temptation to copy/paste from one controller action to another.
Your templates can become more details. @order.total instead of @total (which would have to be mapped to something logic in the controller.)
The code is more easily tested. You can programmatically access the results of the methods in your model without having to munge HTML output from a controller.

Their post has all the details and code samples.

RailsConf Wrap Up

Colin A. Bartlett — Tue, 22 May 2007 07:24:00 -0400

Here’s a wrap up of all my posts from RailsConf 2007. (The ones with actual useful substance, that is.)

All in all, it was a fantastic convention. As can be expected, some presentations were better then others. Suggestions for next year include:

Better descriptions of the sessions and of the speaker’s experience.
Perhaps repeating some sessions at multiple times.
Better planning of expected attendance at each session so proper room size could be selected.

There’s a number of talks I didn’t get to see that I really wanted to. In the coming days, I hope to find their presenting materials online to see if there’s anything I can glean.

The Rails Way

Colin A. Bartlett — Mon, 21 May 2007 11:01:00 -0400

Sunday’s morning keynote at RailsConf was by Jamis Buck and Michael Koziarrski, both committers to the Rails core. The format was quite useful: a series of short code reviews from a variety of submitters to their website, The Rails Way.

Jamis asked for a show of hands for who had read his “Skinny Controller / Fat Model” article. I, ashamedly, have not, but I intend to. I’ve heard the “fat model” concept more and have been trying to emphasize putting as much as makes sense into the Model, and less into the controller.

They mentioned how you can override the #to_param method on an ActiveRecorded descendant in order to control what is used as the “id” string when building a URL in Rails. This would work perfectly with the pretty URLs I have been trying to use more and more.

Jamis stresses how we should all strive to make our code “intention revealing”. One of the beauties of Ruby is the flexibility and expressiveness it allows you. Wherever possible, we should structure our code to be readable and even self-documenting. And where our code does not clearly reveal our intentions, we should document liberally with comments.

#with_options seems to be a pretty slick little method that I have to try. It’s a method on Object that allows you to prevent repeating the same options on a series of method calls.

Many people forget to actually use the ActiveRecord associations they setup. For instance, instead of People.find(:all, :conditions => [“company_id = ?”, 99]) one can do something like @company.people which can make your code much more readable and DRYer, too.

And finally, they showed a code example that used the #returning method wrapped around several lines of code in a method that was to return something. Even after an explanation, I didn’t quite get how this worked. So that’s something to investigate.

Javascript Fu

Colin A. Bartlett — Mon, 21 May 2007 10:56:00 -0400

Londoner Dan Webb, creator of the UJS4Rails.com website with plugins for Unobtrusive Javascript, presented about some tips and tricks for dealing with Javascript in Rails. He revealed that he’s not maintaining the Unobtrusive Javascript plugin but instead has been focusing his free cycles on an extension to Prototype called LowPro.

I actually had a bit of a hard time following much of the technical nitty gritty of this talk. Mostly because my Javascript skillz are lacking. But also because it was packed as hell and pretty uncomfortable to sit still.

Dan did stress that we should all do a better job of making sure our Rails apps at least still function when Javascript is not available. He presented an example of an acquaintance who was unable to use any site using the standard AJAX frameworks because they all used the eval function of Javascript which the corporate security nazis frown upon.

His recommendation was to think about how your app can work, albeit with reduced functionality, when Javascript is not available to the user. One should build their app without any AJAXishy features at first, and then layer on the Javascript, AJAX, and “interface sheen” as he called it. I agree, although I think a decision about how much functionality to provide fo non-javascript-enabled browsers needs to be carefully considered in the context of the project at hand.

Dealing with Designers

Colin A. Bartlett — Mon, 21 May 2007 10:54:00 -0400

Well known blogger Amy Hoy presented about interaction between designers and developers. She claims to be both a designer and a developer and chatted about the processes that she and others use to successfully integrate the work of coders and artists. My take-away points:

Teaching your designer about Rails, even just a little bit, can go a long way to a successful working relationship. Get them comfortable with what they will expect to see in View templates when reviewing erb (or haml, etc.) templates created by the Rails developers.
Have the designer use subversion (or CVS, in our case…. for now). If the designer is using OS X (as most are), it won’t take more than a half hour lesson to educate them as to the virtues of source code control and the how-to of checking out, checking in, updating, etc.
Design cannot be an afterthought. Get the designer involved early in the process so that their perspective can be incorporated into the decision making process as much as possible.
Use wireframes to mock up the pages of your site. The wireframes can start as simple as napkin sketches, but should ultimately be fleshed out in some kind of box/text format. This is far quicker then any kind of direct-to-Photoshop process.
There are several “hand off” points that can be utilized to switch the process from designer to developer. This was sort of a no-brainer. Obviously, some designers can handle HTML, others can’t, and the process of cutting Photoshop files down to HTML and CSS can either be handled by the developers or designers. I would love to find a really good designer that embraces XHTML/CSS as much as I’d like them to. But until that point, I think we’ll stick to doing the HTMLification ourselves.

Splunk

Colin A. Bartlett — Sun, 20 May 2007 11:47:00 -0400

A talk yesterday entitled “Leveraging the IT Community” talked mostly about a service called Splunk. It’s an application that runs locally on your network and gobbles up log files into one big central management interface. You can search through log files with handle AJAXish web based interface and trace events as they move from one level of software to another. It’s pretty neat.

It’s available free for users processing less than 500 MB of log files a day (which doesn’t seem like very much).

The “community” part of this is essentially a Wiki/form/blog/social networking website that can hook into Splunk and allow you to post and view information about log file events that you encounter.

My reactions to this are summarized here:

First of all, the talk was pretty much a pitch for this product. I still thought it was interesting, but this wasn’t a sponsored talk and therefore should have presented other info besides just a pitch for Splunk.
The product seems like a neat idea, but what about Google? Why wouldn’t I just use Google to search for other people with the same problem?
Why limit this to just log files? Seems like that’s only one part of troubleshooting any IT problem. Places like ExpertS-exChange.com provide a way for people to find out about anything IT problem, not just log files. (shitty site, I know, example only)

Business of Rails

Colin A. Bartlett — Sat, 19 May 2007 16:21:00 -0400

The theme of the first two talks I attended at RailsConf today was more business-y and less technical. There was a chat called “Teascript: A Homesteader’s Story” and one called “The Business of Rails”.

The former was a case study by a developer who decided to make his own niche web app and start selling a service around it. The content was interesting, however the talk itself was frustrating as he took all manner of questions all the time and there were zillions of interruptions with dull questions.

Some interesting points I took away:

Get the idea out there fast and start getting feedback. This has always been my view, as opposed to bottling it up fearing that someone will steel your idea.
Read 37 Signals book, Getting Real. Apparently this is the bible of developing web apps the Rails way. I was ashamed when a show of hands indicated nearly everyone had read this book except me.
Start small. The speaker discussed the benefits of starting your application small with only essential features to get it out there. I’ve been thinking more and more this is the way to go so I was glad to hear this point.

The latter was a panel discussion with open questions from the audience and a panel of owners of Rails development shops large and small. This one was a bit dry because a lot of it was about how to quit your job and take the plunge. Which I did 6 years ago now.

Reading code

Colin A. Bartlett — Fri, 18 May 2007 19:12:00 -0400

Believe it or not there was actually a talk about how to read code. There’s more to it then I realized and there were some interesting handy tips presented, although there wasn’t as much actual substance to this talk as I had envisioned. Here’s some tips:

When reading ruby or Rails code beginners often might not even know where to start. Here’s a pretty good track to follow:

Read the URL of the page in question. In simple apps that aren’t using fancy routes, the URL will tell you the action/controller.
Check out the routes.rb file for any fancy route configurations to find the controller/action.
Open the controller and find the method. Read through it.
Look for any filters on the controller. Usually declared at the top. Find them and see if there is stuff running before or after your method.
See what methods on the model are invoked and read through the model method.
Look for callbacks on the model. Stuff like before_create can add functionality that you might not have realized was there.
Application controller and application helper files often contain other stuff you should look through before doing any spelunking.
Seek out observers. Often declared in environment.rb and residing in the models folder, these are callbacks that often attach themselves to multiple models.
Plugins and libraries in /lib are good to look at, too.

Some other tidbits about finding the method you’re looking for:

Check for normally defined methods
Find any method_missing implementation
Grep through files for any metaprogramming like define_method.