Like most programmers starting a new gig, I spent my first day at 37signals setting up my work environment. I thought it might be interesting to keep track of what I installed along the way…

SizeUp for managing windows

Alfred for launching applications

Here’s what happened in Campfire when I found out Noah, our stats guy, uses a calculator that came out in 1981:

Related: Reverse Polish notation [Wikipedia]

A week ago, it took about 15 minutes to run all of Basecamp’s tests.

Now, if you adhere to the test-driven development (TDD) philosophy, you’ll know that tests are meant to be run often. Like, every few minutes, preferably. The tests are what give you confidence in your code, and the ability to refactor with impunity, not fearing that your changes are breaking existing features. They are the safety net for our daily tight-rope walk across our code base.

But if your test suite takes a quarter of an hour to run, that puts a severe damper on your willingness to run it often, or even at all. Those tests definitely don’t get run every few minutes. They might get run before you commit a change. More likely, they get run around the end of a development cycle, when the new work is preparing for deployment. Although they can still be marginally useful when run like that, they are a far cry from what they might be.

At the beginning of this latest development cycle, I begged leave to spend a few days digging into our test suite to see what could be done. Just about all of the programmers here have had a turn looking into the tests, but with other responsibilities it was hard to find enough time to do more than prove the hypothesis-du-jour wrong. I hoped that with some dedicated time I might be able to make some significant improvements.

Sometimes you need to take shortcuts to quickly prove a concept. I’m experimenting with a new view on Basecamp and I need some data to generate that view. I want all the messages on a project, grouped by day, and also the latest comment per message per day. I don’t know the “right” and performant way to put that query together. But I don’t need to worry about that. I’m just testing a concept here.

So I wrote a totally ugly, awkward implementation that gives me @posts_and_comments. And that’s ok. If this design is successful, the fact that I want @posts_and_comments isn’t going to change. What will change is the implementation that pulls that data out of the database and populates the instance variable. In order to make that future step as easy as possible, I’m hiding my ugly implementation behind a clearly named private method on the controller. The controller action calls `find_posts_and_comments_for_log` and as far as the view is concerned, nothing untoward is happening.

If the concept doesn’t work out, no problem. I didn’t spend too much time on the implementation. If the concept does work, the ugly implementation will be easy to replace later because it’s tucked behind a clearly defined method.

When your implementation is a total hack, put it behind a good interface. Then you can swap the implementation later without rethinking the design.

Among the things that people new (and old!) to Ruby find delightful are the little things it does to make the language feel intuitive. Case in point: unless.

The unless keyword is just if in reverse. It’s a conditional statement that executes only if the condition is false, instead of true. This lets you write little gems like this:

  i += 1 unless i > 10

  unless person.present?
    puts "There's no such person"
  end

However, as with anything that gives you a little power, it can be abused. The following abomination is but a sample:

  unless !person.present? && !company.present?
    puts "do you even know what you're doing?"
  else
    puts "and now we're really confused"
  end

I do not doubt that there are people out there who can decipher the logic above without breaking a sweat. But for most folks, combining negations, multiple conditions, and (gasp!) else clauses with an “unless” statement makes for challenging reading. It also makes it far too easy to introduce bugs into the logic.

Some rules of thumb when using unless:

1. Avoid using more than a single logical condition. unless foo? is fine. unless foo? && bar? is harder to parse.
2. Avoid negation. “Unless” is already negative. Piling more on only makes it worse.
3. Never, ever, ever use an else clause with an unless statement.

Not only will others thank you when they have to read your code, you’ll thank yourself when you have to return to that code a month or two down the road.