has_many :thoughts

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.

1. It forces you to write code that more easily reused. Limits your temptation to copy/paste from one controller action to another.
2. Your templates can become more details. @order.total instead of @total (which would have to be mapped to something logic in the controller.)
3. 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.

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

• DRYing up Views
• Rails 2.0 details from DHH’s Keynote
• Clean Code
• Adding tests to legacy rails apps
• Reading code
• Business of Rails
• Splunk
• Dealing with Designers
• Javascript Fu
• The Rails Way

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

1. Better descriptions of the sessions and of the speaker’s experience.
2. Perhaps repeating some sessions at multiple times.
3. 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.

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.

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

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

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

1. #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.

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

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

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.

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:

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.

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:

1. 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.
2. 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?
3. 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)