QOTD: Hans Küng

From The Catholic Church: A Short History:

Those who deliberately step in all the puddles should not complain too loudly about how bad the road is.

Bad RSpec! BAD RSPEC!!

My first gig as a consultant for ThoughtWorks has been a whirlwind of security lines, flights to Texas, and Ruby on Rails. I'm very pleased that they were able to make me billable so quickly; to be getting paid to work on Rails again after two years in the Java mines is an extra added bonus.

My pair and I spent today upgrading one of our apps to Rails 2.2, as a sort of trial run for eventually upgrading all our apps. This involved the usual amount of concomitant upgrades to plugins, with no shortage of "great, this is broken...now something else is broken...not that too!" hijinks. The best part of the day, though, was the RSpec tests that kept failing no matter what we tried to throw at them.

Long story short, we have a controller that uses a rescue_from handler to redirect in the event of a connection error. Works like a charm when we're clicking through the app. But after upgrading RSpec and RSpec-Rails it simply refused to pass the specs that verified the redirect behavior.

It turns out that the latest version of RSpec has some secret sauce that defeats rescue_from, instead going directly to raising the exception that needed rescuing from in the first place. I guess I wouldn't mind so much if we didn't have several behavior-driven tests that, you know, tested behavior.

Not too cool, Rudy.

There is, of course, a workaround. Simply add controller.use_rails_error_handling! to your test and you can defeat RSpec's defeating of rescue_from. But, just as double negatives fail to not clutter English prose (see what I did there?), having to demand that RSpec get out of the way of Rails' standard and -- in this case -- reasonable behavior just uglies up my code. I would much rather the maintainers of RSpec had elected to make the ability to bypass the rescue handler and skip straight to the underlying exception an "opt-in" behavior.

One of These Things is Not Like the Others...

I (heart) Amazon's recommendations service, but...


...I'm not entirely sure what the message is here. For me or any other fans of programming languages and/or algorithms.

QOTD: Donald Knuth

Ripped directly from this interview:

...I trust my family jewels only to Linux.

I'm a Mac guy myself, but...respect, brother. Respect.

Regarding Ruby, instance_of?, kind_of?, and ===

So I was reading through some Ruby source code tonight -- primarily because I haven't in a while, thanks to a busy stretch of Java work -- and I ran across an idiom that I found a little confusing at first. The Ruby source code belongs to Why the Lucky Stiff's Shoes project, "a very informal graphics and windowing toolkit" (according to the official website).

One of the first files I looked at, lib/shoes.rb, opens right up with this interesting bit of interestingness:

class Range 
  def rand 
    conv = (Integer === self.end && Integer === self.begin 
        ? :to_i 
        : :to_f)
    ((Kernel.rand * (self.end - self.begin)) 
        + self.begin).send(conv) 
  end 
end

Okay. So we're defining a rand() method on the built-in Ruby class Range, which will return a random value from within the begin and end values of the Range. Neato. And apparently the use of conv is meant to produce a result of a float or an integer, depending on the nature of the endpoints of the Range. Again: neato. But I hadn't seen the use of the === operator in this context before.

The docs and the Pickaxe book are a little obtuse on this, so I did some irb spelunking:

>> r = (1..27)
=> 1..27
>> r.class
=> Range
>> r.begin
=> 1
>> r.begin.instance_of? Integer
=> false
>> r.begin.class
=> Fixnum
>> r.begin.kind_of? Fixnum
=> true
>> r.begin.kind_of? Integer
=> true

Hmm. So instance_of() doesn't mean quite the same in Ruby as, say, the instanceof operator in Java does. (That, or Fixnum doesn't truly inherit from Integer in Ruby.)

Also, as it turns out:

>> Fixnum === r.begin
=> true
>> Integer === r.begin
=> true

So it would seem that the [class] === [value] syntax is syntactic sugar for [value].kind_of? [class]

It's the bit about:

>> r.begin.instance_of? Integer
=> false

that surprised me most, being the pathetic Java programmer that I am. And being that (according to the documentation for Integer on ruby-doc.org):

Integer is the basis for the two concrete classes that hold 
whole numbers, Bignum and Fixnum.

Apparently "is the basis for" != "is a superclass of".

Or is that "!==="...?

Fixing Eclipse's Workspace Dialog: A Unix One-Liner in Only Three (Okay, Four) Lines

cd /Applications/eclipse_3_3/configuration/.settings 
  && sed '/RECENT_WORKSPACES/d' org.eclipse.ui.ide.prefs 
    > org.eclipse.ui.ide.prefs.fixed 
  && mv org.eclipse.ui.ide.prefs.fixed org.eclipse.ui.ide.prefs

I usually (heart) Eclipse, but sometimes I just want to smack it upside its virtual head. One of those times is when it's starting up and I change focus to some other app and start typing something and Eclipse at some point grabs focus and inserts whatever I thought I was typing somewhere else and prepends it to its "which workspace do you want to use?" dialog and promptly creates a new workspace with a name of whatever nonsense text ended up in the dialog box. You know?

So I now have this little bit of bash magic saved as zapEclipseWorkspaceSelection.sh in my home directory. The downside is that it zaps all of your prior workspace selections, not just the smack-Eclipse-upside-the-head ones. You could maybe modify it to, say, ask for input on what invalid workspace names it should delete. Not me, man. Subtlety is not one of my vices.

HOWTO: Display a Custom Boot Message for Your VMWare Appliance

So I'm building a VMWare appliance for Stratavia's Data Palette data center automation application, and I want it to be like all the other cool appliances that print out some system-specific configuration information (e.g., IP address) when it finishes booting. This is useful for when, say, your appliance runs a webapp via an HTTP server like Apache or Mongrel or Tomcat and you want to tell the user where to point his browser to see it in action.

I happen to be using the latest Ubuntu JEOS as the base OS for this appliance. As such, in order to hook in to the boot process, I am adding my changes to the /etc/rc.local file.

(Author's Note: The exact location and name of this file vary -- sometimes wildly -- between Linuxen. Some flavors use /etc/rc.d/rc.local. Gentoo uses /etc/conf.d/local.start. I paraphrase the immortal Daffy Duck in "The Scarlet Pumpernickel": "Fancy, thy name is Linux. To coin a phrase.")

Let's say you want your user to visit http://[whatever the IP address ends up being] following bootup to get the virtual ball rolling. But you don't know what that IP address will be when you bundle your appliance; it's going to be assigned dynamically at bootup (as it should be). No problema. Simply write a bit of script to scrape the IP address in your Linux flavor's version of rc.local, thusly (Note: The following bit of awesome is directly ripped off from the rc.local file of the MindTouch Deki Wiki appliance):

IP=`ifconfig eth0 | grep "inet addr" | awk -F ' ' '{print $2}' 
  | awk -F ':' '{print $2}'`

If you're Richard Stallman or some other Unix guru and you already know what the heck all this does, you can just smile smugly and skip the next few paragraphs. For the rest of us:

ifconfig eth0 -- Run the system command ifconfig to print out the general networking information for this box (specifically, the first ethernet interface), and send ("pipe") its output to the grep command. The output for ifconfig eth0 will look something like this:

eth0      Link encap:Ethernet HWaddr 00:0c:29:2d:f7:73
          inet addr:172.16.139.130  Bcast:172.16.139.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fe2d:f773/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          [et cetera]

There are several more lines, but all we care about is the second line. The next command in the chain, grep "init addr", will filter out all the stuff we don't want, leaving us with just the second line. This is then fed to the first of two awk scripts.

The first awk script uses a field separator of "space" (-F ' '); this splits the inet addr line into its constituent "words", like "inet" and "addr:172.16.139.130". We just want the "addr:" word, so we print it as the output of the first awk script and send it to the second ({print $2}).

The second awk script splits its input using the colon as its field separator (-F ':') and prints the second word, which is -- tada! -- the IP address of the virtual machine. Whew.

The Rubyistas reading this blog (assuming I have any left) may have downloaded Ezra Zygmuntowicz's way-cool EngineYard Express VMWare image. Its bootup a little more involved, asking for input from the user on initial boot, and displaying several bits of information after every boot thereafter, such as the randomly-generated root and express user passwords. EY Express is running on Gentoo, so its startup hook is in /etc/conf.d/local.start.

EY being EY, they delegate all the heavy lifting to Ruby via some custom Ruby Gems: ey_reporter, config_system, and system. You have to do some serious filesystem spelunking to get there, but you can find the Ruby code that figures out the IP address (the equivalent of the bash script above) in

/usr/lib/ruby/gems/1.8
  /gems/system-[version]/lib
  /system/info/info.rb