July 6, 2010: Opinions are Bad For Business
The title, by the way, is from a favorite scene in a favorite movie.
Status
Now definitely working on the “dealing with legacy code” chapter, which I am hoping will be substantially more useful than the Lulu version, in that it will cover a few more techniques.
I should know later today what the timeline is for beta 4.
Links
Let’s see what we’ve got today.
Nick Quaranto over at Thoughtbot wants you to stop leaving time bombs in your tests. The answer is to use Timecop, or set dates in your tests implicitly. Be sure and check out the comments for some other good ideas.
Kent Beck has the results of a poll on how often teams deploy to production and how often teams run their functional tests. The deploy results are pretty interesting in that more teams deploy far less often than I might have expected.
So I’m still finishing up a post on pairing, but I did want to point out what Will Read suggests, which is that in a pairing environment, developers have more choice over what they do and who they work with. Hmm… that reflects well on Pivotal. My experience is being able to choose is somewhat team dependent. I’ve certainly seen paring environments where the developers didn’t feel like they had much choice in day-to-day tasks.
Ruby 1.9.2 release candidate 1 came out over the weekend, and we’re getting to a point where we’re not going to be able to ignore it any more. And by “we”, I mean “me”. Apparently they keep sneaking in new methods into Enumerable, ranging from the nifty to the seemingly insane. I won’t say which is which, though, go guess for yourself.
Back over at Everyday Rails, Aaron Sumner has a nice set of sensible advice for going from beginner projects to real projects. I’d be linking to it anyway – the fact that one of the pieces of advice is to buy my book is just gravy.
I think this post by Xavier Shay is mis-titled. It’s called, “The Perils of Opinionated Software (like Rails)", but in argument, it’s more like “Rails Doesn’t Share My Opinions About Database Constraints”. As it happens, I don’t agree with Shay, but then I’m probably not sufficiently enterprise-y. Or, to be more specific, I do agree that database constraints can do what he says and that is sometimes useful, but I’d argue that there is also a cost involved with relying on database features (infrastructure lock-in, more complicated to set up test data, business logic distributed across levels) that I’ve generally found kind of high. This would make a very interesting debate with somebody who is heavily into a NoSQL database.