August 11, 2010: An Abundance of Options
Book Status
Shoulda chapter fixes made. The next decision is whether to push that as a beta by itself, or wait until the RSpec chapter is also done.
Also
Today is the last day to get early bird pricing for WindyCityRails.
Book Status
I did not know that Ruby 1.9 had its own coverage tool. Aaron Patterson shows how to use that tool and a little code to create useful output for coverage testing.
I’m really happy to see some discussion of what good style is for Cucumber tests. Jonas Nicklas argues in favor of what I call in the book the implicit style of testing. He closes with “A step description should never contain regexen, CSS or XPath selectors, any kind of code or data structure”. I think that’s got it right. I was just deciding not to add a Cucumber/Factory add-on to my project and decided not too for reasons articulated pretty well by Jonas. The goal of Cucumber is not to write as few step-definitions as possible.
Dane Harrigan discusses handling Rails exceptions from Ajax calls. It involves what may be the first actual use case of an around_filter I’ve ever seen.
Xavier Shay argues that database constraints make it easier for new developers to understand your code. Hmm… I tend to be not a fan of database constraints. Or more accurately, I tend to be very cognizant of the development costs of adding database constraints, so I only add them when they seem necessary. It’s hard to argue, though with the idea that the code and database should not actually conflict.
The Silence is Foo blog gives an almost obsessive amount of love to the splat operator. Yay! The splat operator is one of my favorite corners of Ruby (as it was one of my favorite corners of Python). Even so, I learned a couple of new splat tricks from this article.
I’ll close here with a little debate on choices in Ruby and Rails. Kevin Gisi has a satirical little number on how hard it is to be a new Ruby developer and choose among the various options for everything. Peter Cooper at Rails inside offers not a rebuttal exactly, but a slightly different take on the issue. Kevin is obviously writing tongue-in-cheek, so you can’t exactly get worked up about him going overboard, and I agree with Peter’s take that things could be improved with better presentation. I do think that both Ruby and Rails have gotten a bit less novice friendly (as many projects do over time as complexity gets added). I don’t think it’s an unsolvable problem, but we can always make it easier for new people to come on board.