Installing Ruby 1.8.6 using MacPorts

Do this:
sudo port install ruby186

Because this:
sudo port install ruby

… will install Ruby 1.8.7

And don’t forget:
sudo port install rb-rubygems

And if you’re trying to get Ruby with MySQL going read this.

I’ve moved to San Francisco

I moved here 2 weeks ago, on the 1st of November, to work for the awesome Pivotal Labs and it’s been a really good start.

I’ve found a nice apartment in SOMA with a really cool roommate. The apartment even has a view of sorts of the Bay Bridge and is about a 20 minute walk to work. This means I’m easily getting my 10000 steps a day.

My first week at Pivotal was spent in the Tracker team, the electronic backbone of Pivotal’s XP flavored methodology (you can also use Tracker for free).

The team has been really great – they’re all really strong developers, quietly confident but balanced, focused and pragmatic. This seems to consistent with everyone I’ve met at Pivotal. Everyone has been very warm and welcoming, and they all seem like well adjusted individuals – a good sign.

Good times.

Screen sharing client in OS X Leopard

Because I keep forgetting how to start it.

open /System/Library/CoreServices/Screen\ Sharing.app/

And it seems much better than COTVNC.

Testing instance methods in a Module with Object.extend()

A common type of mixin I’ve encountered involves a Module with instance methods which is included into a Class.

Writing an orthogonal test for a target Class is easy enough, you simply mock/stub any methods the Module provides.

Testing the Module elegantly however is less obvious, atleast it wasn’t obvious to me.

One approach I’ve used is to create a fake class for the test, include the Module and finally instantiate this for the test. But there’s the issue of testing the Module’s interaction with the including Class. For this you could partially mock/stub the test class instance, but there’s a simpler approach that avoids the test class altogether: create an ordinary rSpec mock instance and extend it with the Module.

Metakoans

Looking to exercise your Ruby muscles? Why not try the Metakoans RubyQuiz. I did this recently and found it helped my understanding of Ruby’s meta programming facilities.

My solution’s here.

Use before reuse

Please.

Why I test, and why do you test?

This is most of an email I sent to an internal Cogent mailing list after an entertaining exchange between a couple of the guys about testing styles/philosophies. Craig suggested I post it here, so here ’tis :)

– snip –

First about unit and integration tests.

• I write unit tests for focused feedback; i.e. tell me exactly what broke. To keep them focused I try to keep them orthogonal which usually means using fakes of any collaborators.
• I write integration tests where I need more safety than a unit test will offer. They seem even more important when I’m stubbing and mocking a lot in a dynamically typed language like Ruby.
• I write both types of tests to help convey intent and understand the problem better. I TDD with either a unit test or integration test, whichever feels natural.

Then about interaction and state based testing.

• I pick the approach that feels natural at the time, favouring neither by default. I struggle with rules about when to use which.
• I dislike interaction tests that look suspiciously similar/symmetrical/coupled to the code they refer to. I expect a test to earn its right to exist, and therefore add to the size of the codebase and build’s time, by either conveying intent that is difficult to express in the code itself (which is why I love the term ‘example‘) or addressing some other consciously identified risk.

Your thoughts?