Noel Rappin Writes Here

Book Status

Still working on the legacy chapter. The sidebar here is that deliberately writing bad legacy code for purposes of using as examples in a book is a little challenging. It’s got to be tangled enough to make the point that it’s hard to clean, but small and clear enough to work in the context of a book example. My tired brain was fighting it last night.

Training!

I mentioned this recently, but I want to mention it again. I’ll be teaching Obtiva’s Advanced Ruby on Rails course Aug 30 - Sep 2. This is going to cover a lot of non-novice topics. We’ll be building in Rails 3 and (I hope) Ruby 1.9.2, and covering security, performance, rich experience tools, deployment, and the like. It’s a new course, and I’m excited to put it together. I’ll most likely be quizzing early registrants to determine exactly what to cover. Follow the link and enter your information on the form.

The Smallest Thing

So I was talking yesterday, and later twittering, about the smallest issue that I might see in a potential candidate’s code sample that would almost disqualify that person in my eyes.

My first answer to this for Ruby is 4-space indent. Because it’s totally trivial on the one hand, but on the other goes against an extremely well-established community norm, indicating that either the person isn’t engaged with the Ruby community or is really, really stubborn. Neither of these is a recommendation.

Other people suggested different things – here are some of the most trivial:

@wxwill said “for and while loops”. Yeah, that would be an issue for me as well, same reason.

@aberant: suggested STATEMENT rescue "". I might give somebody a pass if that was used reasonably once, but it would look weird in a code sample.

@johnashenfelter suggested Hungarian notation, which would probably disqualify a developer for me in almost any language that was not actually C. He also suggested CamelCase, which would also act like four-space indent for me.

@mileszs mentioned explicit return statements. I sort of agree, although I see that as less of a problem than some of the others, in part because it’s easy for an explicit return to slip into code, at least for me. I find when teaching Ruby that this particular community quirk is particularly hard to justify to people coming from, say Java. To them, it feels like deliberate obscurity. Though I think once you get the hang of expression-based Ruby, it seems perfectly natural.