Luke Melia

Good for a chuckle and for a good point. Time Ottinger on the generally silly practice of reusing variables:

I suppose somebody forgot to clue me in to the Great Variable Shortage that is coming. I have seen people recycling variables to mean different things at different times in the program or different states of the containing object.

Next thing you know, we’ll here stories about how the old-timers had to carry their variables to work with them. “Up the call stack both ways!”

Aaron at the Eleutian Dev Blog has an excellent post on Loosely-coupled Mocks.

That said, I do have a few ground rules for when I write tests with Rhino Mocks that sort fall into the whole one assertion per test topic and the mocks vs. stubs thing. Here they are…

The tips he covers are definitely ones that my team has learned or is in the process of (sometimes painfully) learning. It’s very easy for tests with mocks to be difficult to understand and also to yield false failures. If your tests are brittle or intimidating to work with, you’re contrary to the goal of a test suite enabling change and refactoring.

Great to see more people blogging about Rhino Mocks!

Whenever Trotter presents at nyc.rb, I always pick up some new ruby idea that I can put to use immediately. His most recent presentation, "Refactoring teh Rails" [sic], was no exception.

Let's start with the end result. ProjectsController#index in Tracks before applying the idea:

There's nothing terribly wrong with this method except for the fact that it is a little long and is difficult to read because of the nested blocks. Trotter suggested thinking of the main CRUD methods in your Rails controllers as dispatchers. I had independently reached the same conclusion -- the answer is Extract Method. But because my Ruby skills are still developing, I couldn't figure out how to do it. After the presentation, I understood it. Here's the after code:

The key is this lambda keyword. In Ruby (and other languages), lambda lets you define a block -- it might help to think of it as an anonymous method body. What you get back is a Proc object, which you can pass around and treat like any other reference. To get it to work as an argument to a method expecting a block, throw an ampersand on the front of the variable name. Eli Bendersky explains all about Ruby blocks and procs better than I can.

Simple but satisfying. While I was passing on the leg of lamb at dinner last night (I don't eat most animals), I couldn't help but think "lambda... yummy."

We've opened up ticket sales for Gotham Ruby Conference. If you're planning on attending, I'd encourage you to waste no time in getting your ticket!

My colleague Ken Judy has started a fantastic blog. Ken has been an inspiration to me with regard to the ethics of software development. He's as passionate about Scrum as I am about XP. And as you'll see when you subscribe to his blog, he's a great writer:

Meaningful products can emerge from horrible process. But a way of working that tears down talented people’s desire to work is tragic. To repeatedly participate in this is to sap the world of it’s limited supply inspiration, creativity and joy. This is evil. Now that I have authority, my main goal is to avoid this evil.

Amen, brother.

I'll be giving a talk at Code Camp NYC II on March 3rd. The title is "Supercharging the WPF Command Pattern with Dependency Injection". Turns out that XAML and Castle IoC is a nice combo and I'll walk through an example that Saturday.

My colleagues Wendy (blog) and Oksana (no blog) are also doing two joint presentations at Code Camp. One is on pair programming and one on testing with Rhino Mocks. Wendy is a great TDDer, and if the pair of the them are half as entertaining as they are in our team room every day, those talks will be a blast.

Code Camp is at Microsoft's NYC office near Columbus Circle. Registration is free and now open.

Speaking of conference registrations, we're opening up registration for Gotham Ruby Conference this Tuesday evening. We have a limited capacity, so it's probably a good idea to buy a ticket early.

If you're one of the bilingual C#/Ruby people who are attending both of these, I'm sure we'd have a lot to chat about!

While sipping from the firehose that is the ruby-talk mailing list, I came across this sweet bit of code:

This is a nice illustration of ruby's elegance. So much nicer than calling something like Math.Factorial(6).

While working on Tracks, I've been writing and running a lot of tests. The project has a 181 tests so far (not including Selenium tests). A while back, I switched to using a sqlite3 in-memory database for my tests in an effort to speed them up (about 15% faster for this project).

Tonight, after some planning for Gotham Ruby Conference, I queried the group about something that had been bugging me. While running my tests, I was getting messages like this:

Creating sqlite in memory database
-- create_table("contexts", {:force=>true})
   -> 0.0041s
-- add_index("contexts", ["user_id"], {:name=>"index_contexts_on_user_id"})
   -> 0.0012s

These went on for a screenful, and happened before every test run (which is a lot with autotest -rails!).

Bryan, who works at East Media, suggested that the problem might be specific to sqlite3, and sure enough it went away when I switched to mysql. After that, some targeted searching revealed a solution. It turns out that a more recent version of topfunky's memory_test_fix plugin than the one I had has a feature to quiet/silence this annoying output. Thanks to Kakutani Shintaro for contributing this!

test:
  adapter: sqlite3
  database: ":memory:"
  verbosity: silent

I upgraded and am now happy as a clam with my concise, colorful test output.

Now I just have to refactor out these Rails 1.2 deprecation warnings!