Thursday, June 14, 2007

Ok, so I too have been bitten by the arity differences between Proc.new and lambda so a few months ago I tried to find the Ruby spec to get a better understand. It was then I came to realize that the only true Ruby spec is defined by the C implementation. While such a spec may allow for rapid improvements to the language it comes at the cost of warts--and Ruby is not without it's fair share. I stumbled across this site today that is possibly the best 'research' compiled on Ruby's closures that I have seen to date. It does a great job of exposing Ruby's warts while at the same time demonstrating the power of closures in Ruby.

The article (it's really just a script you can feed the interpreter!) was encouraging in that it showed me I really should spend a little time in the MRI perusing the source for these sorts of tidbits. I can really appreciate all the work that the groups heading up the various Ruby implementations are doing to formalize a Ruby spec.

Saturday, June 2, 2007

It seems like the more I watch the Mountain West sessions the more I stumble across solutions to itches I've had recently. Just yesterday at work I was hacking with a friend on a simple CLI for Google Translate and we were struggling a bit getting 'curb' to do exactly what we wanted. After watching James Britt's session on Black-boxing with Ruby I realized that mechanize would probably be a better choice for what we were trying to do. 10 Minutes later:

While these may not be accurate translations, this script definitely works for testing out i18n functionality until the real translations come in. If and whenever Google decides to release an API for their site it will be painless to throw this script away.

"Every problem has already been solved. It is Open Source. And it is the first result on Google"--Ara T. Howard (I don't know if he's actually the one who said that first, someone correct me if I'm wrong)

I spent some time this weekend watching the Mountain West Ruby Conf's videos and I must say what I've seen so far has been great (now I'm really exited about the Ruby Hoedown). The session on Ruby Queue is going to be immediately useful to me in my effort to distribute selenium tests over a linux cluster. It's actually quite amazing that the solution I had cooked up approached the task of clustering from almost the same way--simply using a queue to feed shell tasks to an array of nodes. It's quite ironic in light of Ara's quote on Rule #42 and his project that basically sent mine to the grave.

Luckily my solution was only the product of a few weeks of work off and on. In < style="font-weight: bold;">it's that simple. So, I'm going to take my project off rubyforge and stick it somewhere else. The one thing that I really need that RQ doesn't handle is clustering with Windows machines. Since I need to run tests with IE I'll have to spend some time to see if this is something that could be worked into RQ. I have absolutely zero experience with Windows and NFS so I don't have any idea how much work would be needed at this point.