Noel Rappin Writes Here

July 26, 2010: A Hammer, A Nail, and A Giant Squid

Perl, Rails, testingNoel RappinComment

Book Status

Beta 5 should be out early this week, featuring a mostly new chapter on testing legacy projects, and also updating the code setup and the initial walkthrough chapters to Rails 3. Over the next couple betas any remaining Rails 3 incompatibilities will also be fixed.

Book Reviews

Something new for you on a Monday, a couple of novels that I liked in the last couple of weeks.

Kraken, by China Mieville. I'm a huge Mieville fan, so I was excited for this one.

The story starts when the preserved remains of a giant squid are stolen from a London museum, and the curator of the museum is dragged into a world where an apocalyptic squid cult is one of the least weird things going on. It's much more loose and jokey than Mieville's other stuff, something like a cross between Mieville's (oustanding) YA novel Un Lun Dun, Gaiman's Neverwhere, with the magical sub-world, and a Tim Powers novel a la Last Call or Expiration Date, filled with supernatural creatures who obey obscure and and convoluted supernatural worlds.

Overall the book is a lot of fun -- Mieville freely calls it a "shaggy god" story, which should give you an idea of the tone. It's not perfect; it takes forever to get started, and the flip side of loose and jokey is that sometimes Mieveille spends a lot of time on characters or conceits that don't tie in. But there are at least five really outstanding, audacious ideas or moments in the book, and for all that it's loose verbally, the plot comes together nicely at the end. Plus Mieville unironically uses the phrase "squid pro quo". So how can you go wrong?

Go Mutants!, by Larry Doyle. Doyle is a former Simpsons writer who has written a satirical mash up of pretty much every 50's B movie. I mean all of them. You've got your alien wanting to take over the user, a radioactive ape, a woman who's head is on a pan, atomic cars, teenage angst, flying saucers. There's a lot going on, and if you don't like one of the jokes, wait about a paragraph and there's another one coming.

Most of the jokes land, and liked the book a lot more than I thought I would once it became clear where it was going. It's got some heart, and some satirical bite. It's a little too willing to compromise tone for a quick joke to be truly great, but it's fun, and if you've sat through enough MST3K to see a lot of the referenced movies, you'll probably like it. It's got some clever alternate history bits too, for example, the initial alien contact takes place at the Polo Grounds, interrupting the famous "The Giants Win The Pennant" moment.


The Rails Best Practices web site opened up, which is affiliated with the rails-bestpractices gem. Vote for best practices, and they might wind up incorporated in the gem. As I write this, leading the pack is "N+1 Queries" -- presumably avoiding them. Don't see testing yet, though, he said, banging that thing that looks like a nail with that hammer...

Speaking of tools, the Software Craftsmanship North America 2010 conference is October 15 and 16 at the Mariott Chicago O'Hare. Speakers include Dave Astels, Michael Feathers, and "Uncle Bob" Martin.

Aaron Sumner at Everyday Rails has a meta-tutorial of resources for various Rails command line tools, including the Rails command, generators, Rake, and the Unix command line. Take a look if you'd like to get better at navigating from the console.

Tim Bray from OSCON has a true essay on what all of us owe to Perl and to Desperate Perl Hackers. He's right about what Perl has brought, although it'd still be about my eleventeenth choice of language to use.

I have kind of mixed feelings about this Emma Lindsay post at Thoughtbot's Giant Robot's blog. It's about taking time in a TDD process to consider the overall design of the code. Which you should do, but which I think is already part of the TDD process. I completely agree with the workflow laid out in the post.

Two quibbles. I disagree with the sentence "Test Driven Development rests on the assumption that you basically know the optimal way to make your tests pass in advance." -- I've used TDD many times when I had no idea how the tests were going to pass, it works great in that case. Where TDD falls down is when you don't know the output of the code -- if you know the output, but don't know the algorithm then TDD works fine. Also, the list of TDD steps doesn't include a refactoring step, which is where, in practice, most of these design decisions would take place. All that said, writing a quick spike is sometimes needed to figure out the problem you want to solve and the tests you need to write.