I often need to output debugging info in specs when something just isn't working. No sweat, just put in a puts or two, and run the spec.

Of course I'm usually doing this in Textmate using the RSpec bundle, which displays the results in a nice window formatted with html.

But that causes problems with my debugging output

The problem is that the puts output is just raw text so the HTML formatter ignores line breaks.

At one of the Radiant hack fests, either John Long or Adam Williams taught this old dog a simple new trick. The suggestion was to define a new Kernel#rputs method as a wrapper for puts which 'wraps' the arguments in an html <pre> tag. Then just call rputs (the r is for rspec of course) in the spec and or code under test.

This works great as long as you run the specs under RSpec. But if you run them in the shell you see something like this:

I've been putting up with this minor annoyance for a while, but this morning it struck me that I could define rputs conditionally depending on whether the spec was being run in Textmate or not. The trick is that Textmate defines one or more environment variables whose name starts with 'TM_'. So, without further ado, here's the new fragment from my spec_helper.rb:

  module Kernel
    if ENV.keys.find {|env_var| env_var.match(/^TM_/)}
      def rputs(*args)
        puts( *["<pre>", args.collect {|a| CGI.escapeHTML(a.to_s)}, "</pre>"])
      end
    else
      alias_method :rputs, :puts
    end
  end

With this change, running in the shell now looks like this:

A nice refinement to my bag of tricks!

Update 27 Sept 2009

One slight change. I notice that String#start_with? only exists in Ruby 1.8.7, 1.9 and is apparently also defined the activesupport gem for <1.8.7. I changed the spec helper to use a regular expression match instead which works in all cases.

I've been in a lot of programming shops in my days, some fostered an agile mindset, some less so.

One feature which aids agile development is having something which gives the team visible feedback to the overall state of the project. One major real-time status item is the state of the continuous integration testing.

You are doing continuous integration testing aren't you? There are good lightweight tools and services which make this easy, I use run>run>run to test my open source projects like RiCal every time I commit to its publicly visible repository on github. Run>run>run provides free service for public open source projects, and range of paid plans to suit just about any budget.

And that's just one option, it just happens to be the one I use.

The continuous "integration" testing mindset can also be seen fractally. In between commits, something like autotest out of the ZenTest gem, or the autospec variation which is part of RSpec, can keep a continuous eye on the state of your code as you change it.

Thinking back on some of those programming shops, a couple of them had something I really liked, they had adapted real traffic lights to show build test status. Google for traffic light and you'll find that you can get them for fairly reasonable prices.

Or you could build your own. For a smaller scale version, consider this miniature traffic light built by a maker for his kids using typical maker supplies like, an Altoids tin, a cigar box, some L.E.D.s and a minimal microcontroller. When I saw this yesterday, I immediately thought how cool it would be to hook this up to a computer for C.I. feedback.

A small "confession." Until recently, I had a green-red status light for RiCal in the sidebar of this blog, using Glenn Vanderburg's runcoderun-badges but had to turn it off temporarily when someone told me that the UI for commenting to the blog was no longer working.

It turns out that the badge (which uses JQuery), was fighting with the Prototype flavored Javascript. I'm sure it wouldn't be that hard to fix using JQuery's noConflict function, I just need to find the time to try it and test it. For the time being it was more pragmatic just to remove the badge.

Of course the downside is that I once again have blogspam comments showing up for moderation, I'd been wondering where they went!

A tweet from Ward Cunningham yesterday led me to watch a very interesting video of a lunch time demo of exploratory testing by Elisabeth Hendrickson , while visiting Pivotal Labs. Ms Hendrickson shows how she forms a model of how the software works in order to find issues more productively. During the session someone says that they always heard that testers should be like typical "dumb" users and treat the software as a black box, but Elisabeth says that getting information about the actual implementation from the developers is fine. She also talks about her process of forming hypotheses about how the system works, and doing experiments which confirm or refute those hypotheses.

Does this sound familiar? We're talking about the scientific method here. In an interesting coincidence, I also stumbled upon another web video this weekend, an interview in which Richard Feynman describes science with an analogy of learning the rules of chess, simply by observing games being played, with no explanation.

I found myself thinking about the roles of the exploratory test. It seems to me that one of these roles is to act as a mock for the end user.

And despite the common epigram, users are usually far from dumb. A typical user forms a mental model of how a system operates, and use that to inform their use of the system. The model starts from a base of expectations about how similar systems operate, and the user adapts the model as he/she encounters behavior which doesn't fit. Very much like Feynman's hypothetical chess student, who first observes that Bishops only move to squares of the same color, and Kings move one square, and then has to adapt the model when they encounter a pawn being promoted to a Bishop, or castling.

When the user's model and the implementation model don't align, interesting things can happen, often unpleasant. It's usually desirable to eliminate such misalignments, and the conversations between an exploratory tester and a developer about misapprehensions about how either the system or the user works are valuable in achieving this.

The scientific method is also useful for exploratory development, such as when writing code which interfaces with or implements a complex API or standard, but that's fodder for a future article.

Last night there was a very interesting extra meeting of the local AgileRTP group. Johanna Rothman was in town and Jared Richardson arranged an extra meeting so that she could present some of the issues which arise in adopting agile methods, and how to deal with them. Johanna is very knowledgeable and gave an interesting and thought provoking thought.

One of the issues she talked about was "distributed" agility. This is a hot button as many companies are outsourcing some development to "offshore" locations. Johanna talked about the issues in following agile practices, and I'm vastly oversimplifying here, pointed at time zones as the major issue.

Someone in the audience, who works in a distributed team with members across the US, questioned her on this. As the discussion unfolded, other issues came up, such as dealing with a team in China which had one person fluent enough in English who acted as the "email-translator", as well as cultural differences affecting communication.

Language and cultural differences certainly can inhibit the free exchange of information which is the coin of the realm in Agile practices, but I had to observe that these are not really geographical or time zone issues. I've seen similar difficulties with co-located teams.

Distributed development using agile methods can indeed work, I've seen it. OTI was quite good at it. We did timeboxed projects with development spread across the globe. A given project might comprise team members in Ottawa, Zurich, Sydney, Raleigh, and Vancouver. Large projects might use a "team of teams" but smaller ones had individual members who were geographically dispersed. There was lots of communication by phone and email, and it worked quite well.

OTI had one "stand-up" meeting every year, usually in February in the balmy clime of Quebec, an annual Tech Conference where everyone in the company got together at a sort of internal "OOPSLA" to talk about what they were doing and to exchange interesting ideas, and just get to know each other better.

Now the main thing that made this work was that we shared a common culture when it came to development. Although not everyone at OTI was a native English speaker, all were fluent.

"Big Dave" had a tendency to hire good people wherever he found them. Often such a person would seed a new multi-person laboratory, but sometimes a "lab" would be a single person.

So distributed development can work, and work well, given the right people.

Some agility advocates stress the need for co-location, a notable exception is Kent Beck, the founder of eXtreme Programming, who now spends most of his time based a his farm in southern Oregon, and does remote pair-programming using VNC and Skype, with programmers around the world.

And Kent is currently auctioning off a two-hour pairing session this is a good opportunity to sample distributed agility at a high level.

I wish I could afford to bid, the current bid is at $200, which is cheap. I've learned a lot every time I interacted with Kent personally in the past. Someone is going to get a deal, whatever the winning bid turns out to be.

Here's another video from Ward in which he shows the working environment at AboutUs and talks a bit about the connection between his conception of wikis and agile programming.

In an evolution of the recommended extreme programming workspace setup. AboutUs gives everyone a desk on wheels rather than undedicated pairing stations, so that developers can rearrange the configuration to match who they want/need to work with at the time.

"Once I built a railroad, now it's done
 Brother, can you spare a dime?"

A couple of evenings ago at the monthly meeting of Agile RTP Jason Tanner from Enthiosys led a discussion of experience in introducing agile development methods to companies.

He led off by encouraging the audience to make index cards inscribed with impediments to the adoption of agile methods which the attendee had encountered, and tape them to a whiteboard. He then took the cards off and discussed them.

One of the first was something like, “people who can’t work without a detailed long-range plan.”

For some, reason, the old depression-era song “Brother can you spare a dime?” popped into my head as soon as that discussion started.

"Driving is not about getting the car going in the right direction. Driving is about constantly paying attention,
 making a little correction this way, a little correction that way."

Once I built a railroad, but it went to the wrong place.

Well, that’s the saying. One thing is for sure. You can’t expect to get what you don’t pay for.

I got an IM from a buddy this afternoon looking for a second opinion on a Rails application. Someone had paid for 100 hours of work (I don’t know at what rate), for a Rails project which wasn’t progressing to his liking. He’d asked my buddy to give an opinion of what had been done, and I was asked to have a look as well.

I only spent about a half hour or so looking at the code, since I was doing this as a courtesy. I spend quite a bit of pro-bono time helping others by writing here and contributing on public fora, but I’ve got my limits.

The executive summary: I wasn’t impressed.

def self.average(currency, date_range)
     first = find(:first, :conditions => ["currency = ? AND issued_on = ?", currency, date_range[0].to_date])
     first ||= find(:first, :conditions => ["currency = ?", currency] , :order => "issued_on"
     last = find(:first, :conditions => ["currency = ? AND issued_on = ?", currency, date_range[1].to_date])
     first ||= find(:first, :conditions => ["currency = ?", currency] , :order => "issued_on ASC"

     median(first.rate, last.rate)
end

protected
def median(a, b)
    (a + b) / 2
end

I just discovered that my old friend, Ward Cunningham has started putting some short interviews, and “video essays” up on YouTube