Peter Williams

The Power of Ruby (and Semantic Markup)

I haven’t written much about Ruby lately. That is mostly because the piece of software I am working on is written in Java, with a little PHP on the side. I do write Ruby code, though mostly in the form of small scripts. In the last few months, I have started using Ruby in places where in the past I would have used shell scripting. It turns out that just about anything you can do with a unix shell you can do with Ruby more easily and faster. And there are a lot of things you can do with Ruby that just cannot done, easily, with a shell.

For example, yesterday we had a minor issue here at work. We fixed the problem quickly but there were are few orders that we needed to watch, just to make sure there were no residual issues. So I grabbed my trusty Emacs and IRB and wrote a little, 50-ish lines long, ruby script to mash-up information from a little web application and a bunch of files on disk to let me easily keep track of how things were progressing. I would not have even tried that with shell scripting (or with any other language I know, for that matter) but it saved several hours and completely removed the risk that something important would slip through the cracks.

This mash-up was almost completely based on open-uri and REXML. Both open-uri and REXML are petty sweet, but together they are enough to send you into diabetic shock from across the room. If you are not familiar with them already you definitely should be. Those two libraries combined with the semantic markup used by the web app (or should I service?) made the whole thing fairly straight forward.

Elliot is 2

Happy second birthday, Elliot!

Elliot turns two today. He has changed so much in the last year. He has grown from a baby into a little boy. Compare these pictures an you will see what I mean.

Elliot and I a couple of days before his second birthday.

Elliot at the beginning of this year (only seven months before).

The goodness of curl (and REST)

Tim Bray, in an post about testing atom protocol, said

We got two different clients to talk to it; one was a Big Secret Project from a Big Famous Company based on all sorts of slick infrastructure. Mine was curl. […] Those who know what curl is are probably snickering now. But I think the fact that you can debug a nontrivial application with curl -X -i -d -H is a significant weapon in the quiver of RESTafarians.

We are only snickering because we have done the same thing. When you are testing a RESTful application a big sophisticated client mostly just complicates things.

There is a huge advantage to technologies that can be worked with using existing, generalized and scriptable tools. That ability allows for easy testing and debugging, as Mr. Bray points out, but the advantages do not end once you are done debugging.

These days most people are employed to deal with abnormal situation. The normal situations are mostly automated and require very little human intervention. Having software that can be worked with and monitored by existing, scriptable, tools means the you have to write less code to handle those abnormal situations when they arise. If you are a RESTafarian, you just grab curl and a few minutes later you are done. Even better, if that abnormal situation is common enough to warrant it, you can even wrap it up in a script so that anyone can handle it.

An XML Design Dilemma

Recently the following XML was proposed during a design session of which I was part. This document basically says that something has happened that cannot be automatically handled. A program receives this XML and asks a human which of the available actions to take.

<event>
    <identifier>1234</identifier>
    <type>ForkReached</type>
    <description>
      There is a fork in this path.  Which way do you want to go?
    </description>
    <action name="TakeMoreTraveledPath">
      ...
    </action>
    <action name="TakeLessTraveledPath">
      ...
    </action>
    <action name="ReturnHome">
      ...
    </action>
  </event>

I responded by proposing encapsulating the action elements in a availableActions element like this.

<event>
    <identifier>1234</identifier>
    <type>ForkReached</type>
    <description>
      There is a fork in this path.  Which way do you want to go?
    </description>
    <availableActions>
      <action name="TakeMoreTraveledPath">
        ...
      </action>
      <action name="TakeLessTraveledPath">
        ...
      </action>
      <action name="ReturnHome">
        ...
      </action>
    </availableActions>
  </event>

To me the second is obviously better. However, I found that I was unable to come up with a single concrete reason why the second form is better than the first. Both are easy fairly to understand. Iterating over all of the actions is not hard (the same number lines of code) in either case. I can think of no functional difference between the two. So why, then, does the first form make me feel dirty?

While pondering this, I found this in a post on an unrelated topic.

I think there's a watershed moment in every developer's career when they start look more at their code as a structure and less as a bag of statements. — Jeremy Miller

I agree with Jeremy that there is a lot to be gained by focusing less on the the details and more on the structure. (The smalltalk people have know that for years, apparently.) Since I was still pondering my XML dilemma I immediately thought, “I like the availableActions element because it results in a document with a better structure.” But I did not manage to completely convinced myself. We usually think that one structure is better than another for some fairly concrete reason, like it will be more reliable or extensible. But in this case I cannot put my finger on why one of the options feels so much better than the other.

I wonder if this is common for developers to feel that one design is distinctly better than another without being able to articulate, in concrete terms, why. Does that happen to you often? If so how do you deal with it, especially in an XP environment where the design that feels better may, at least arguably, be a little bit less simple?

In this particular case am I wrong that the second flavor feels better than the first flavor? If I am correct about the second flavor feeling better is there some concrete reason why that I am overlooking?

Autumn

It is autumn here in Denver. The light has changed. The last couple of days have been really cool and crisp. This morning there was snow on the mountains. This is, by far, my favorite time of year. This year, though, I feel like I am missing autumn, a bit. I stopped smoking two and a half months ago so I am going outside a lot less often. I know I could go outside when ever I want but I rarely do.

I am not the only one appreciating autumn in Denver. [btw, thanks]