The Continuous Integration and Testing Conference is coming to Texas! The folks doing this conference (Paul Julius of Thoughtworks and Jeffrey Frederick of Agitar) have done 2 of these before, and all the reports I have heard have been good. I just registered, although it means that I will be out of town, away from family, and doing "work-related stuff" on the day before my 40th birthday!

• What: OpenSpace event discussing all aspects of CI and Testing, together
• Where: American Airlines Training & Conference Center, Fort Worth, Texas
• When: Friday and Saturday, April 27 & 28, 2007
• Who: Everyone interested in CI and Testing
• Cost: Free

Click the link above for all the details and to register. Limited to the first 100 folks, so get going!

---

Update

Argh!!!! I looked at my calendar and it turns out I will not be able to go to this after all. Hopefully someone else from DrillingInfo will be able to go.

Something I needed to know the other day, setting up the screensaver on my electronic photo frame (it runs Windows). The Old New Thing : The .Default user is not the default user

I got an actual test plan for a new feature today - a list of manual test steps. I've been wanting to try out WATIR (Web Application Testing In Ruby) after learning about it from one of its creators, Bret Pettichord, who I had the pleasure of working with at DataCert. This seemed like the perfect chance to do something fun and useful. 

I started by getting confused. I googled "WATIR" and got a couple of links on the first page - one to wtr.rubyforge.org that looked promising, but also a link to openqa.org. After poking around a bit on both sites, I figured out that the current stable production version (and previous versions) are on rubyforge, but the team is moving things over to openqa.

I decided I wanted to start with the stable version of WATIR for now (1.4.1), so from the homepage at OpenQA, I first linked to the ruby installer - some difficulty there, as I got the most recent version (1.8.5-24), but later discovered that the 'modal dialog' functionality in Watir is only supported in an older version (1.8.2-15 is what I ended up installing). The next slightly confusing thing is that there are a couple of ways to install watir. There is an installer, or you can install it as a Ruby 'gem'. The main difference in 1.4.1 is that the installer creates some start menu shortcuts and includes some examples and unit tests. The gem install is pretty much just the core functionality. I went with the 1.4.1 installer at RubyForge.

After getting all that set up, I finally got to start playing with it. I started by just running the watir unit tests. I installed to c:\watir, so just doing start->run and typing in c:\Watir\unittests\all_tests.rb made it start going. When I first did this I discovered the issue with the modal dialogs - there is a test for that, and when it gets to that point a dialog pops up asking you to press OK. You can press OK manually, but after that the test just hangs and you have to use Process Explorer or Task Manager to kill the wayward ruby processes. There is also another issue with the 1.4.1 install - it doesn't copy some of the images used in the html of the tests, so there are some breakages there. I checked out the watir source from subversion (https://svn.openqa.org/svn/watir/trunk/) and then copied the images from there to my watir installation. Some of the docs at the new OpenQA site indicate that the dev team is working on the packaging in the 1.5 version.

Going back to Ruby 1.8.2-15 was supposed to have fixed the problem with the modal dialogs, but so far I haven't been able to get the unit tests to run all the way through. In any case, it is fun to watch them all run!

Next step was to go through the a tutorial I found at http://wtr.rubyforge.org/s101/doc/. I went through several steps, trying out watir interactively using irb. That is pretty cool. Definitely print out the Ruby Cheat Sheet and the Watir Cheat Sheet to help with that. While that is fun, and will probably be a powerful tool in the future, I wanted to be able to move a little faster. A bit more googling led me to some posts by Scott Hanselman about his 'WatirMaker', which has since evolved into a whole watir-recorder project at OpenQA. There are a couple versions of recorders there - WatirRecoirder C#, WatinRecorder C#, and a ruby version. Getting a pre-compiled binary wasn't working for me, so I just checked out the source and ran the ruby version. I wrapped it in a little batch file to redirect the output to a file, and made a small change to the recorder to have all the "puts" calls go through a new method 'record' that did a puts to both $stdout and $stderr so that I could redirect to a file AND see what it was doing. Hacky, I know.

You will probably also want to sign up for the wtr-general mailing list to get your questions answered.

So here is the step-by-step:

1. Install Ruby 1.8.2-15 from RubyForge
2. Install Watir 1.4.1 using the installer (Also on RubyForge)
3. get the watir recorder from OpenQA
   http://svn.openqa.org/svn/watir-recorder/trunk
4. Write and/or record tests!

So far, I am pretty excited about this. I've shown it to several people in my company, and that excitement is spreading. I even showed it to one of our internal users, and suggested that they might be able to use the recorder to document bugs - wouldn't that be cool? We still have a long way to go - coming up with a way to structure the tests, integrate them into our build system, and (if we record tests) refactoring the tests to start creating a library of common functions that could be re-used across tests - but it looks like a good start.

Here is the batch file I used to wrap WatirMaker.rb, which I got from https://svn.openqa.org/svn/watir-recorder/trunk/Ru...

@echo off
if .%1.==.. goto :GET_NAME
set TestName=%1
if exist %TestName% echo That test already exists & goto :EOF
goto :RECORD_TEST

:GET_NAME
set /p TestName=Please enter the name of the test:

:RECORD_TEST
title Recording %TestName%
ruby WatirMaker.rb > %TestName%


If you do a search/replace in WatirMaker.rb and replace "puts" with "record" and then add the method below, it will work for you like it did for me. Next thing is to have it take a command line argument that is the name of the file so that ruby itself can write to the file rather than using shell redirection.

##//////////////////////////////////////////
##
## send the output to stdout and to stderr,
## to allow the script to show the recording
## as it is happening as well as to a file.
##
##//////////////////////////////////////////
def record(message)
$stdout.puts message
$stderr.puts message
end

I have written before about using subversion to provide source control for FitNesse tests, but we eventually abandoned that process because of difficulties with using the refactoring support built into FitNesse. We moved to a system where all edits to test pages were made on the shared FitNesse server, and if a developer needed to get those to their machine, they would use the wiki import feature. The problem was that we lost version control of the tests. Mike Roberts has also written about a system that is a little closer to what Jeffrey and I did.  

Here is another suggestion from Andrew McDonagh that was posted to the FitNesse users list. I've formatted his email and removed some of the location details.

We have always checked our FitNesse pages into source control....

This is how we do it....

The Shared Server
The FitNesse server for testing <our app> currently runs on http:/some.server. This server is a read only server and the wiki pages should not be updated here. The Acceptance Test pages on this server are automatically updated every few minutes from subversion.

Editing the FitNesse Wiki Pages
If you wish to edit the Acceptance Test pages, you need to install FitNesse locally on your machine. Please see the <our app> FitNesse Install instructions on how to do this (basically we have version controlled the download from fitnesse.org).

Setup
The next step will be to get the AcceptanceTest directory from subversion onto your local machine. To do this, use svn checkout from <subversion URL> to S:\AcceptanceTest. Under this directory is a file and a folder that are used for editing these pages.

S:\AcceptanceTest\FitServer.bat - this is a batch file that will start the fit server on your machine.
S:\AcceptanceTest\FitNesseRoot - this is the directory that contains all the files for the wiki pages.
Start the FitNesse server on your own machine by running the FitServer.bat file.

Local edits
To edit the pages on your machine, please use the fitnesse wiki interface provided. Connect to your machine and make the relevant changes. After you have finished your changes, and you will need to commit the changes for them to be visible to other users.

Saving changes back to the repository
Using TortoiseSVN, right-click on the S:\AcceptanceTest\FitNesseRoot directory and select SVN Commit. You will be presented with a log message window. In the bottom half of this window, there will be a list of 'unversioned' files. You need to right-click add these directories and files except for *.zip files. The ZIP files are the incremental revisions that the Wiki (it's own internal revision control system). For these ZIP files, after you have added the directory that they live in, you can use svn ignore to hide these files (right-click->TortoiseSVN->add to ignore list).

Running Tests-The Official Way
If you want to run the current suite of tests, please use the shared server.

As with our system, this will also have difficulties when you use the wiki refactoring tools (which are great to have). In this case, however, since each developer/tester is doing subversion commits manually (rather than the automatic commits on the server that we were doing in our system), people can note that certain files are missing and mark them as deleted in subversion, and add the new files as if they were brand new. Sounds like a pretty good setup.

It was so nice of Jeremy to include me in the game. The hard part for me will be coming up with 5 people I know who have blogs and who haven't already been tagged! Here's my list:

1. I consider myself an above-average woodworker. I used to do a lot more before I had kids, but I do still find some time to build things. Here are just a few of my projects:
   
   drop leaf table and cabinet
   
   
   trestle table (has seen lots of use!)     
   
    
   bookshelf for the kids' school (#7 of 8!)
   
2. My brother won a silver medal diving from the 10M platform at the 1992 Barcelona Summer Olympics, and got 4th on 3M at the 1996 Atlanta games. I was also a diver from the time I was 7 until I was about 13, when he started getting better than me :-). I retired from diving for several years, but got back into it in High School so I wouldn't have to take 'regular' PE.
3. I started high school in New Jersey, where I grew up. Since I had retired from diving, I took up wrestling my freshman year. I was quite small - I wrestled in the 95 lbs and under category my whole freshman year. I had a winning season. Then we moved to Texas, where boys play football, they don't wrestle.  
4. I used to race SCCA Autocross when I was in college. I had a 1985 Dodge Omni that I had painted black and put low profile tires on, along with the ground effects kit that Dodge used on what they called the "GLH". It was a Carroll Shelby project, back when he worked at Chrysler. It was a fun car, and I raced it for a couple of seasons on and off until I threw a connecting rod in the engine one day (not while racing - just pulling  into a gas station). I had to borrow money from my parents to get a rebuilt engine put in it, and decided to give up the racing. One day I intend to get back into it - several guys at my current job are quite active in the Austin Spokes Sports Car Club.
5. When I was at the Air Force Academy, in between my freshman and sophmore years, we had to take two 'classes' during the summer. One (SERE, or Survival, Evasion, Resistance, and Escape) was required. The other part you could choose between freefall parachuting and gliders. I chose gliders and got to solo a glider (or sailplane, as they are sometimes known) during the class. Another thing that I would love to have the time and money to do again!

OK, there are my five things. Now I'm supposed to 'tag' 5 more. I know 3, so here they are, in no particular order...

Scott Bellware, Daniel Massey, Blake Caraway

I've recently started playing with geotagging - adding location information to my photos. The basic idea is that you have a GPS keeping track of your location while you are taking photos, and then when you get back you can look through the GPS logs to see where you were when a picture was taken and add that information to the photo. I found a tool called GPSU that downloads the data from my Magellan SportTrak, and can save it as a .gpx file (GPS in XML). Then I run a perl script called gpsphoto that looks at a directory full of photos and the GPX file and finds the photos that have a time stamp matching timestamps in the GPX file. The final output is that each photo gets EXIF tags of Lat, Long, and altitude, plus a google earth .kml file that shows the track as well as 'pushpins' for each photo. Pretty cool. Here are my first two. If you have Google Earth installed, these will open in that.

Lake Travis Trip

Lake Austin Trip

I got a nice email from Jay Flowers a few weeks ago about my post on "Enterprise Continuous Integration". He also showed me some things he is doing around using cc.net and nAnt to do packaging of an ISO image. Pretty cool stuff! Anyways, I'll let Jay write more about his stuff - what I want to write about is the system we put together for deployment. I told Jay about it in email, now I will share it with you.

For a while, we had been using WiX to create deployment packages, and if you have the right kind of project, I highly recommend it. It was a bit too much power for our needs though - we are developing server-side applications, and we only have 1 production box to deploy to. Maintaining the WiX files was getting to be a pain, so we went with a much simpler solution - zip files. We are pretty much an 'XCOPY' deployment at this point, but we do use nAnt to drive it. The thing that has made us happiest though, is the way we deploy to our development and testing environments.

Like many shops, we have a development environment, a testing environment, a staging environment, and a production environment. Our production environment consists of a completely separate domain, with a Windows domain controller, plus a web server, app server, and database server. To replicate this in our dev and test environments, we have a beefy host machine that runs all those as Virtual Machines. The pain in the neck turned out to be copying things between the build machine and the development environment - IT wouldn't let us do anything like set up a trust relationship between the dev environment domain and the corporate domain, so just copying files was a pain - the machines could see each other, but the permissions weren't there. So here's what we did...

After creating the zip file that contains the images of the web server and app server, we then wrote a simple 'bootstrap' nAnt file that extracts the zip to a temporary directory and then runs a separate nAnt file that is embedded inside it. We then installed CruiseControl.net on the development environment app server. It has one project, "Deploy App Server Dev" that first does an SVN update to get the latest zip file, then executes the bootstrap build. The bootstrap build extracts the zip file contents to a temporary directory, and then runs the nAnt build inside that zip to actually do the deployment. The environmental settings needed (names of the servers, database connection information, etc.) is all part of the deployment build file, and is customized for each of the 2 environments we set this up in - dev and test. At the end of the deployment, we use the StructureMap verification tools to ensure that the environment settings are correct.

When we are going pretty fast, we'll set up the cruise control on the dev environment to actually do a deploy automatically when it sees that a new build is ready. When we want more control, we leave the CC.Net triggers block empty to make it be 'manual only'. We keep it as a manual step on the test environment as well.

So now, to deploy the latest build to dev or test is just a matter of opening up our CCTray app, selecting the "Deploy App Server Dev" project, and forcing a 'build'. That makes things so much smoother.

Now, if we could only get the IT folks to allow us to do this on the production environment...

I recently switched to gmail for my personal email needs, and I have been really pleased with it. They have also recently introduced the Google Calendar, and I started using that as well. My latest discovery, though, was that you can share calendars and include other calendars in your 'view'. I did a search for Austin related calendars and came across the Austin Coding calendar, which listed a few programming-related events. I emailed the owner and asked him to allow me to add things, so I present to the programmers in Austin the new and improved Austin coding calendar!

If you would like to add this calendar to your set of google calendars, there is a small button at the bottom right with a 'plus sign' that will do the adding for you.

I've added a lot of the events that I know of - email me if you know of anything else that should be added. I would love for this to become a widely used resource.

 My lovely wife Julie has been working really hard for the past two  years to get into better shape, and now she is going to try something new. She's going to be running in the Susan G. Komen Foundation Race for The Cure here in Austin. The race is a 5K, and will be on Sunday November 4th. She'd really love some support. Visit her race page and make a donation today!

When I first started at my current company I had the pleasure of meeting Jason Cohen, who had worked for the company previously. After leaving, he started a company called SmartBear Software that develops code collaboration tools. One of their primary products is CodeCollaborator - a tool that integrates with your software version control system to enable developers to do lightweight code reviews all online. Here is the description from their website:

CodeCollaborator enables peer review of source code changes before or after files are checked into version control. Automate audit trails and metrics, enforce workflow rules, and generate reports. Integrates with SCM, issue-tracking, reporting, and other external systems.

I went to a demo he gave not too long ago, and what he has is pretty slick. If you aren't doing pair programming, this is probably the next best thing, especially if you have team members that are not co-located.

Well, today I got an announcement from Cenqua announcing the latest release of FishEye, which is a cool web-based tool for seeing what is going on in a source code control system. I first evaluated it several years ago at a previous employer. At the time it only supported CVS, but it now also supports Subversion and they have Perforce support in beta. It is a very slick tool.

ANYWAYS... Looks like Jason is in for some competition. Cenqua is currently doing a closed beta of something they call Crucible that sounds like it wants to do the same thing as CodeCollaborator.