Virtuous Code

Jeff Atwood thinks monkeypatching should frighten you:

But if wielding that power doesn’t scare and humble you a little, too, then maybe you should leave the monkeypatching to the really smart monkeys.

And ultimately, that is what this line of code says to me about Ruby. It says that this is a language where the fringe is inventing new things. And to embrace ruby is to embrace the idea of a language being propelled by its user base.

[I’m reposting this from my personal journal as it has development applicability – in so much as it is a tale about how NOT to design software.]

So I’ve been trying to wire money to Kenya. No, I haven’t been contacted by the wife of a former dictator who needs my urgent assistance in moving large sums of money. Just doing someone a favor.

I go to the website. I’ve used it before, so I figure I’ll log in to my account. Try to log in with my usual credentials. Uh oh.

W0500 Sorry you’re having trouble. Please try again later.

This does not bode well. I’m having trouble? News to me. And if the trouble is on my end, what good will trying again later do? Are they suggesting that I am having brain issues which will resolve themselves in a few hours?

OK, assume this is just their eccentric way of saying “login failed”. I have a dim recollection of not being able to use one of my regular passwords because they don’t allow special characters in their passwords (why is it always institutions which handle large sums of money that have poor password policies?) Email customer service, and meanwhile, click the “retrieve password” link. Notice while emailing customer service the lengthy backlog of previous Western Union customer service mail from the last time I tried to wire money through them. Oh dear, I must have blocked those memories.

OK, well, chin up and keep trying. While waiting for customer service, hit the “forgot password” link. Go through the first step, email address, date of birth… that’s odd. This is probably the first site I’ve ever seen where the “Date of Birth” field is a password-style field. Presumably so no potential identity thieves peering over my shoulder witness that top-secret information, and I have to go through all the hassle of changing my birth date to something new.



Anyway, moving on, ah, the Security Question.  OK, what’s it going to be – good ole’ mother’s maiden name?  First pet?  Model of car in which I first got to third base? Nope, not good enough for Western Union security.  They’ve gone the extra mile and required me to guess the question before supplying the answer. Now that’s secure!



Email customer service again. Looks like there’s a response to my first query already.  They are prompt, I’ll give them that.  Let’s see…

We apologize for the inconvenience, due to security reasons the system blocks the access after 2 or more unsuccesfull attempts.

We apologize for any problems you experienced with our site. However, if you are not being able to sign in with your current e-mail address and password, we may offer to deactivate your account so you may register again. Please keep in mind that no one at Western Union knows or can retrieve your password for you. If you wish to have your account deactivated, please send your request in an email to messaging@westernunion.com from the email address you used when you registered, and include your registered name, address and telephone number. Please note that if you have another e-mail address, you may use it to create a new account.

Unfortunately, your e-mail has arrived blank.  Please resubmit your question or comment and we will be happy to assist you. Also, please keep in mind that we are unable to view attachments, enclosures, or hyperlinks.

Usually when this happens, it is because of problems with the server. You may wish to double-check your Internet settings, or try again later. Please note that our site works best with Internet Explorer version 6.0. We are currently not compatible with Mozilla, Firefox nor Safari.

A passage in Charles Nutter’s reaction to MagLev caught my eye today:

First off, they demonstrated its distributed object database automatically synchronizing globally-reachable state across multiple VMs. It’s an amazing new idea that the world has never really seen…
except that it isn’t. This is based on existing OODB technology that Gemstone and others have been promoting for better than a decade. It’s cool stuff, no doubt, but it’s been available in Gemstone’s Smalltalk product and in their Java product for years, and hasn’t seen widespread adoption. Maybe it’s on the rise, I really don’t know. It’s certainly cool, but it’s certainly not new.

Why does Ruby seem to be succeeding in ways that Smalltalk didn’t? Well first of all, Smalltalk did have a fair amount of success in it’s time. It remains to be seen whether Ruby will have better staying power. My guess, though, is that it will. The momentum Ruby has accumulated is pretty impressive.

Why? I can think of a lot of possible reasons. Ruby came of age in a time when Moore’s law had finally made the trade-off in increased development productivity versus relatively slow execution time economically justifiable. The primary Ruby implementation was free and open-source, not proprietary. For that matter, Ruby matured during a time when the Open Source community was exploding into relevance and even dominance, as opposed to the proprietary dominance of previous decades. And Ruby arrived at an inflection point in software development, a time when developers were still finding their legs on a new platform (the Web); and a new Web framework using the power of Ruby to accomplish Web programming tasks more easily had the opportunity to revolutionize the industry.

It could have been some combination of the above, or it could have been other factors entirely. Whatever the reason, a ten year old language based on thirty year old technology suddenly took off. Now turn to the field of data storage: developers are looking at novel new(?) document-oriented systems like CouchDB and StrokeDB, despite the fact that SQL is The Standard. Coders primed by Ruby and Rails to look to unfamiliar sources for solutions are questioning the conventional wisdom in other areas as well. Maybe it is time to reconsider the much-maligned OODB as well.

I guess the point I’m getting at, if there is one, is that sometimes the best new idea is an old one reconsidered in the light of current needs.

Inspired by this talk by Jim Weirich:

Image by scottfeldstein, some rights reserved.

(For the shaving nerds, this poster features the Merkur Hefty Classic, a razor I recently acquired and am so far pretty happy with.)

In our last episode we were augmenting FMTP::Message classes to deal with messages split across multiple packets. As is often the case, fixing one problem revlealed another. What with the unstable weather patterns in Oz – you never know when a spacetime-ripping tornado will appear out of nowhere – our flying monkeys sometimes get blown off course, and arrive out of order. This results in jumbled messages and angry Wicked Witches.

We’ve submitted a revised FMTP RFC to the Flying Monkey Transport Protocol Working Group, but it’s anyone’s guess how long that will take to become an offcial recommendation. Until then, we’ve taken to embedding another bit of metadata in the message text itself. Messages now look like this:

  {{3 OF 5}}
  .... MESSAGE TEXT ...

In order to work conveniently with these enhanced messages, we need some new accessors on the FMTP::Message class:

1. A revised #end? method which uses the new header instead of the now-deprecated “ENDENDEND” token.
2. A new #seq_num accessor to tell us which message in a multi-message sequence this is.
3. A new #total_num accessor to tell us how many total messages are expected as part of the sequence.

1. A modified #data accessor which will return just the message data, minus the message ordering header.

Sounds like it’s time to inject some more methods. But not so fast. I prefer to use the inject method pattern when I only need to add one trivial method. When I need to add or modify more than one method, a few other techniques are better suited. One of the most powerful techniques is delegation.

Delegation has a long history of use in object-oriented languages. In some languages using it can be quite labor-intensive to implement. In Ruby it is so trivially easy that it’s a little surprising it isn’t used more often.

Here’s an example of a delegate class that implements the requirements above:

  require 'delegate'
  class OrderedMessage < DelegateClass(FMTP::Message)
    HEADER_PATTERN = /\{\{(\d+) OF (\d+)\}\}/
 
    def seq_num
      @seq_num ||= matches[1].to_i
    end
 
    def total_num
      @total_num ||= matches[2].to_i
    end
 
    def data
      # Implemented this way to demonstrate use of 'super'
      @data ||= super.gsub(HEADER_PATTERN,'').strip
    end
 
    def end?
      seq_num == total_num
    end
 
    private
 
    def matches
      HEADER_PATTERN.match(__getobj__.data)
    end
  end

We use this class by replacing the line that previously read:

  message = extend_message(super)

With this code:

  message = OrderedMessage.new(message)

There are a few things worth noting about this approach:

1. Using a delegate gives us a safe namespace sandbox to play in. This code defines four methods, a constant, and three instance variables. In particular, note that we define our own @data instance variable. If we were monkey patching, or even subclassing, FMTP:Message, we would run the risk of inadvertently overriding or overwriting one of the FMTP::Message constants, methods, or instance variables. With delegation, however, we can define pretty much anything we want without having to be concerned with collisions.
2. Note that #data uses super to delegate to FMTP::Message, just as if we were writing a subclass. This is a convenience of using the standard delegate library.
3. [NEW] While it’s not really demonstrated in the code above, I should point out that any FMTP::Message methods not explicitly overridden on OrderedMessage will be delegated directly to the wrapped FMTP::Message object.

1. An added benefit of using the delegate pattern is that it is very easy to test our additions to FMTP::Message in isolation. Here is the actual RSpec spec I used to develop the code above:

  describe "any ordered message", :shared => true do
     it "should have the correct sequence number" do
      @it.seq_num.should == @m
    end
 
    it "should report the correct total of messages" do
      @it.total_num.should == @n
    end
 
    it "should have the correct data" do
      @it.data.should == @payload
    end
  end
 
  describe OrderedMessage do
 
    def construct_test_data(m, n, data)
      <<-END
  {{#{m} OF #{n}}}
  #{data}
  END
    end
 
    def make_message
      @data = construct_test_data(@m, @n, @payload)
      @base_message = stub("Base", :data => @data)
      @it = OrderedMessage.new(@base_message)
    end
 
    describe "given message 1 of 3 with data FOO" do
      before :each do
        @m       = 1
        @n       = 3
        @payload = "FOO"
        make_message
      end
 
      it_should_behave_like "any ordered message"
 
      it "should not be the last message" do
        # Using '@it.should_not be_end' interacts badly with DelegateClass
        @it.end?.should_not be_true
      end
    end
 
    describe "given message 3 of 5 with data BAR" do
      before :each do
        @m       = 3
        @n       = 5
        @payload = "BAR"
        make_message
      end
 
      it_should_behave_like "any ordered message"
 
      it "should not be the last message" do
        # Using '@it.should_not be_end' interacts badly with DelegateClass
        @it.end?.should_not be_true
      end
    end
 
    describe "given message 4 of 4 with data BAZ" do
      before :each do
        @m       = 4
        @n       = 4
        @payload = "BAZ"
        make_message
    end
 
      it_should_behave_like "any ordered message"
 
      it "should be the last message" do
        # Using '@it.should_not be_end' interacts badly with DelegateClass
        @it.end?.should be_true
      end
    end
  end

Using delegation to extend FMTP::Message, we don’t need to instantiate an actual FMTP::Message object in order to test our modifications. All we have to do is stub the methods of FMTP::Message that we actually use in the delegate. This can be a real win when we are working with a third-party library which has extensive and/or poorly-documented dependencies.

Applicability

Consider using delegation when:

• Vendor code controls instantiation of the target.
• Your code is the primary client of the target.

• You need to make more than one addition or modification to the target’s interface.

Caveats

Be aware that delegates produces with the delegate library are not perfect stand-ins for their target objects. In particular, by default the delegate object will have a different id and object_id. This is easy to correct, but you should be aware of it, especially when working with ActiveRecord, which uses id to associate objects with rows in the DB.