Red Squirrel Reflections
Dave Hoover explores the psychology of software development

Dave Hoover
dave.hoover@gmail.com

Categories
All [Atom]
Craftsmanship [Atom]
Dynamic [Atom]
Intersection [Atom]
Learning [Atom]
Links [Atom]
Polyglot [Atom]
Projects [Atom]
XP [Atom]
Old Blog

Obtivian Blogs

Andy Maleh
Colin Harris
Fred Polgardy
Jim Breen
Kevin Taylor
Todd Webb
Turner King
Tyler Jennings

Archives

March 2009 (1)
January 2009 (1)
December 2008 (1)
October 2008 (3)
September 2008 (1)
June 2008 (4)
April 2008 (3)
March 2008 (1)
February 2008 (1)
August 2007 (1)
July 2007 (1)
June 2007 (1)
May 2007 (4)
April 2007 (3)
March 2007 (5)
February 2007 (6)
January 2007 (6)
December 2006 (10)
November 2006 (5)
October 2006 (8)
September 2006 (8)
August 2006 (5)
July 2006 (12)
June 2006 (7)
May 2006 (5)
April 2006 (5)
March 2006 (4)
February 2006 (2)
January 2006 (5)
December 2005 (5)
November 2005 (3)
October 2005 (3)
September 2005 (6)
August 2005 (4)
July 2005 (7)
June 2005 (14)
May 2005 (6)
April 2005 (8)
March 2005 (9)
February 2005 (11)
January 2005 (16)
Old Archives

 

Tue, 25 Apr 2006

Watir, the Lazy Programmer's Friend

My current client was in need of a functional test suite for their web site to raise our confidence that we wouldn't break anything when we upgraded to Hibernate 3. Despite being a Selenium fan, I wanted to give Watir a try (for various reasons, it felt like a good fit). People were hesitant about the introduction of a new language (Watir is a web testing DSL in Ruby), but after I spent a day getting a bunch of test scenarios scripted, Watir proved its worth. Every developer I paired with said the same thing: "I'm never going to type into a browser again."

There were things I could do with Watir that I would be hard pressed to do with Selenium, like outsmarting CAPTCHA, abstracting common code by opening Watir::IE, and switching between dev, test, and staging by changing a single variable. That last point is one of the big wins of Watir over Selenium, you never touch the server, it's dead simple to setup. That said, the achilles heel of Watir is that it currently only runs on Windows and IE, while Selenium runs virtually anywhere on any browser. So I'll stick with Selenium for my Rails project on my MacBook, while Watir seems to be a good fit for our Windows workstations at my client site.

Abstracting common code into Watir::IE has worked beautifully so far. We created a WatirHelper module that includes code like this:

module Watir
  class IE
    def login_admin
      text_field(:name, "name").set("jerryQ")
      text_field(:name, "pass").set("bletch")
      button(:name, "Sumbit").click
    end

    def fill_out_problem_form(last_name, email)
      select_list(:name , "dateMonth").select("December")
      select_list(:name , "dateDay").select("25")
      select_list(:name , "dateYear").select("2008")
      
      text_field(:name, "firstName").set("F")
      text_field(:name, "lastName").set(last_name)
      text_field(:name, "email").set(email)
      text_field(:name, "confirmEmail").set(email)
    end
  end
end
Which allows our Watir scripts to look like this.
require 'watir'
require 'watir_helper'
include Watir

# update this to point to any server you want
server_name = "localhost" 

ie = IE.new
ie.goto("http://#{server_name}/admin")
ie.login_admin
ie.link(:text, "Tell us your problem").click
ie.fill_out_problem_form("Foo", "foo@bar.org")
...
assert ...
Over time, we had become so lazy (thanks to Watir) that we couldn't tolerate filling out the lengthy forms on the site when we needed to try something out but didn't want to run the tests. So we developed some smaller scripts that didn't test anything, but would fill out forms and click through a series of pages so we could get on with the more interesting stuff. This worked beautifully, mostly because we had already removed enough duplication to give us coarse-grained operations with which we could construct short, powerful scripts to do our bidding.

But then I got tired of running scripts. I wanted a Watir dashboard. Ruby/Tk to the rescue! Here's my quick spike of how to drive Watir from a GUI.

require 'tk'
require 'watir_helper'

root = TkRoot.new { title "Dashboard" }
button = TkButton.new(root) do
  text "Start Google"
  command proc do
    ie = IE.new
    ie.goto("http://google.com/")
  end
end
button.pack
Tk.mainloop

It took me a couple more minutes to get a real dashboard up and running and now I can drive around my client's webapp with a push of a button!

[/projects/watir] permanent link

Just capture requirements as fake Ruby code

One of Kent Spillner's reflections on Rich Kilmer's talk at the Silicon Valley Ruby Conference...

He spent the first day on the project pairing with the domain expert, writing everything they said in Ruby assuming the DSL already existed, and then spent the remainder of the project back-filling what was needed to make the DSL work and building the UI. via Obie
Mostly posting this to remind myself that now is the time to adopt this approach.

[/dynamic] permanent link

Fri, 21 Apr 2006

XP doesn't stand for XPlanner

My current client (Retail X) and my former client (Bank Y) both use XPlanner to manage their XP processes. If one must store stories electronically, then XPlanner seems to be the most stable free software around to do that, so thank you XPlanner developers for your work. One aspect of process management software is that it (inevitably?) embodies the opinions of its creators. Is process management software inherently opinionated software? While opinionated software is not bad, it does expose differences of opinions between users and creators, and this is where I find myself with XPlanner.

Bank Y began adopting XP prior to using XPlanner, and I think this gave them an advantage over Retail X. Bank Y had established its XP process through researching XP, hiring ThoughtWorks to lead the effort, and adapting it via iteration and project retrospectives. When the need arose for story tracking from remote locations, XPlanner was installed and we used it in the best way we could. Which meant we ignored/hijacked some of the ways it tried to make us work. For instance, it wants us to estimate in hours, but we used days. It wants us to track actual time spent, but we never did.

I could be wrong, but my new client, Retail X, seems to have started doing XP by installing XPlanner and giving it what it wanted. Velocity is tracked by using actual time and estimates are in hours. Basically, the process has conformed to the opinion of XPlanner. Guess what? It doesn't quite fit right. I'm reminded of one of my favorite Cockburn quotes:

If you follow a methodology out of the box, you will have one that fits some project in the world, but probably not yours. --Agile Software Development, Alistair Cockburn

If you're going to use software to manage your software development process, realize that you're going to run into differences of opinion. I hope that Desi, Obie and Aslak can continue their work in this area, because I know our opinions about XP are well aligned.

[/xp] permanent link

Mon, 17 Apr 2006

The Interactive Canvas and Internet Explorer

I wrote up a simple example of how to create interactive canvas applications. I used ExplorerCanvas to ensure compatibility on all major browsers.

[/projects/interactivecanvas] permanent link

Tue, 11 Apr 2006

New Ventures

Yesterday was my first day working for Obtiva Corp., a small agile software development consulting company based in Naperville, Illinois. Kevin Taylor, the founder of Obtiva, lives in Wheaton, Illinois, about a mile from my house. My client is about 10 miles in the opposite direction. My commute yesterday morning ... was surreal. I've never in my life had a commute so short. I am excited about Obtiva for many reasons, and if you read this blog, you'll be hearing about those in the future. But first I want to relate another recent surreal experience ... leaving ThoughtWorks.

Two years ago I left the American Medical Association to work for ThoughtWorks. Getting hired at ThoughtWorks was my big break, and I will always appreciate ThoughtWorks for believing in me, and for hiring someone like me: someone with no CS education and only three years of programming experience. I met an unbelievable number of exceptional programmers there, and established friendships and collaborations that will endure for many years to come. Most of all, I learned ... so many different types of things. I obviously learned about technology, but more importantly, I learned about myself and my needs and limitations. One critical need I have is to tuck my kids into bed at night. And thankfully I had been working at ThoughtWorks and tucking my kids into bed at night for all of 2005-2006. But it couldn't last forever, and I wanted to be in a company that aligned more naturally with this need.

Despite my excitement about Obtiva, it was with a heavy heart that I left ThoughtWorks, which is surreal for me because I've always had a "don't look back" sort of mentality about former employers.

That said, my need to tuck my kids into bed at night was not the primary impetus for my job search. I will be blogging more about it in the future, so for now, I'll say that Obtiva isn't my only new venture. Some friends and I are working on a web site that we're hoping to launch in the not-too-distant future. On top of that, my canvas/Ajax work has attracted some attention and some interesting happenings are in the works there. So, I guess you could say that bubble 2.0 is the real culprit.

The work on the apprentice to journeyman patterns has slowed, and will be picked back up again after a couple of these ventures stabilize. Thankfully the content of the patterns is not going to get out of date, and therefore can be set down for a while. Ade is continuing to make progress on them, and will be presenting on them tonight at Xtc.

[] permanent link


powered by blosxom