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.

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.

My solution’s here.

(How do you punctuate around a smiley?)

Feeling even more (irrationally) intolerant than usual, I convinced Mark to let us switch away from the reams of text produced by rSpec’s ‘specdoc’ format to its more succinct ‘progress’ format and we immediately noticed something odd. Each example was being run 7 times, in fact the entire suite was being run several times with runs interleaved!

Some perplexed investigation and educated guessing finally revealed the cause.

While rSpec gives you a SpecRunner for free via an at_exit hook, we use a script to explicitly invoke a CommandLine::SpecRunner. This is in part because our project is built by Ant (it’s a polygot-project; a mishmash of Java, Ruby, Python and, somewhat unfortunately IMO, Bash) and in part just because …

rSpec’s at_exit hook allows you to run your specs directly via the ruby command (e.g. $ ruby three_is_greater_than_four_spec.rb) and is responsible enough to ensure you haven’t already run these specs with a custom runner. Except if you call Process.fork during an example.

When you fork in an example the at_exit hook gets replicated in the child process and when this child process tries to exit, you guessed it, it runs your specs. Turns out we had quite a few unstubbed forks in our unit level specs. The immediate remedy was to stub these; they are unit level specs which should after all be orthogonal.

To make sure we aren’t inadvertently bitten again we’ve intercepted rSpec’s at_exit hook from any child processes by creating our own at_exit hook which exits without executing any other at_exit blocks, i.e. :at_exit { exit! }

Our 830ish specs now run in 15 seconds. The numbers don’t quite add up (200 seconds / 7 processes > 15 seconds), but since I’m certain none are being skipped, I’m content with this outcome.

Found via the Ruby on Rails weblog.

“UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things.” – Doug Gwyn

I think you could say the same about Ruby.

In my case it turned out that this was because the default order of the PATH environment variable had ‘/opt/local/bin’ after ‘/usr/bin’. This meant that the older version that came with OS X Tiger which was in ‘/usr/bin’ was being used in preference to the newer version installed by MacPorts in ‘/opt/local/bin’.

The solution: simply change PATH in ~/.profile so ‘/opt/local/bin’ appears before ‘/usr/bin’.

Finally, it turns out that on my shiny new Macbook Pro the PATH is ordered this way by default.

Ruby

• I love its clear & succinct syntax. As several people have already said, it looks great for creating DSLs.
• Runtime/dynamic type checking. No opinion yet, other than ‘interesting’.
• Lexical blocks, yeehaa!
• A million different ways to define class level members (and other things, I think), why? I think I just need to understand this better.
• A culture of unit testing, goodo.
• The tutorials, docos and a hugely passionate & welcoming community. Mind-blowing. Kathy Sierra loves this, I do too. It’s infectious.
• Lack of a decent IDE (I haven’t found one yet anyway), considering the last statement I’m sure there’ll be one along soon. RDT looks promising.
• Rubgems. Rocks! I can’t believe how easy it is to download & install with gems. But then I guess I haven’t spent in a lot of time in Debian land recently, it could be that I’m just easily impressed. I’ve also heard this stuff is super-easy in the Mac world, can’t wait to find out when I finally get my Powerbook.
• Multi-platform – means I continue to use it on my Mac, yay!

Rails

• The seemingly “impressive” demos that show web pages automatically update themselves when a database table is updated. Misleading, but then Four Days on Rails appears to make up for this.
• Scaffolding, interesting, “feels” open to abuse to an extent but so are so many other powerful tools I suppose. A case of Spider-manesque – “with great power come great responsibility”?
• The Generators that come with Rails, I *love* these.
• More tutorials, docos, videos etc, excellent again.
• Included Webrick – I cannot understate how great this is, when I was first learning about JSPs, Servlets etc getting Tomcat running just right was a pain. At the time, I gave up and went with Resin. I don’t mean to bag Tomcat, just saying that having a webserver all included with the framework makes it much easier for a nube like me to focus on a higher level of abstraction initially.
• Trails – Rails for Java? Rails has piqued my curiosity enough for me to add Trails highish on my To Research list at RememberTheMilk.
• R.I.P. ugly MS Access home grown databases. Here’s a low barrier of entry alternative that’ll allow you to build a much better engineered application.
• Watchout Java/Struts/Webwork/Spring/J2EE etc? I don’t think so. I believe that each of these technologies still has their place (I just wish I could say I understood them all well enough to state what this is in each case :P)

Finally, a disclaimer. As I said before, these are very early, nascent thoughts. To say that I’ve only scratched their surface is probably an exagerration. So, please forgive, but point out any (and I’m sure there are a few) errors, misconceptions or gaps in this post.