The Classroom Performance System by eInstruction provides students with wireless remotes allowing teachers to get quick feedback from their class. It can be used for anything from opinion polls during lectures to administering standardized tests.

The original application was written in J++ and was ported to C# in 2007. While I worked on a number of areas in the codebase, I spent most of my time in the delivery pipeline - functionality around presenting questions to students and processing the responses from our custom hardware.

I helped mainline a starter unit test effort and was involved in a few large refactoring efforts to help reduce coupling problems in the codebase, including moving the codebase from one large executable to several smaller assemblies, some of which were subsequently re-used in a smaller application.

Prior to the C# port, the company was interested in producing a version of the application to work as a PowerPoint Add-In, and was considering outsourcing the work to another firm, with the goal of having them reproduce much of the core delivery functionality in a new .NET codebase. I found a way to re-use our current J++ codebase with J# and IKVM, saving the company the money and hassle of outsourcing.

During the C# port, I added a plug-in system. While we didn't have resources to produce production plug-ins, I developed a handful of utility and diagnostic plug-ins to aid in development and QA.

The Receiver SDK grew out of the original CPS J++ codebase. After a couple of large refactorings, another developer and I had isolated the code for communicating with our hardware into a rough API. I eventually became sole maintainer and developer of the API and later worked to remove any lingering J++ dependencies leaving us with a pure Java solution.

Over my time working with the code, I built up a good suite of tests, including integration tests to help ensure thread safety in portions of the code.

While prototyping our PowerPoint Add-In, I ran across IKVM.NET and started using it to cross-compile our API. In late 2006, we began providing the SDK to third parties for integrating our hardware in both Java and .NET. Today, it runs on Mac OS X (Java) and Windows (Java, .NET and Mono).

ChrismoControl is the tongue-in-cheek name for the collection of custom Ruby scripts I wrote to provide continuous integration for our J++ application. It included all of the CI basics - pulling sources from version control, detection of changes, incrementing build versions, code compilation, test execution, deployment and email and rss notifications. Not the prettiest thing in the world, but it worked well. A co-worker added build automation for our installers and a simple web front end to allow single button push builds by anyone in our department.

Before porting to C#, some of the CI scripts bled into aids for TDD, including an Eclipse plug-in that would (via some coarse means) trigger Visual Studio 6 to compile the J++ code, then run a specific unit test with the JUnit text runner (GUI runner was not J++ compatible) and report the results in an Eclipse output window.


Hindsight is a simple code review workflow server written in Ruby (WEBrick, YAML and native serialization persistence) that monitors FishEye and notifies developers of new commits needing review, notifies assigned reviews, and reports on outstanding changesets as a big visible chart for progress. Since our group did not have a strong pairing culture, this was a decent substitute.

DocuTIME is a custom timecard processing system written in Delphi against a SQL Server database. DocuTIME was built to replace an aging DOS application used in many Snelling branches and franchises for sending payroll data to corporate on a weekly basis to get checks cut for temporary employees. The system includes DocuTIME proper, a Windows client/server application that integrates with the database of a third party application called eEmpACT; DocuTIME Extraction and Transmission module for weekly transmissions of data to corporate; and DocuTIME Gateway, a multi-threaded Windows service for receiving all branch office transmissions, queuing them for import into PeopleSoft and notifying end users of status. I wrote a good portion of the front end piece, plus all of the Transmission module and DocuTIME Gateway.

The Extraction and Transmission module was the most complicated piece, being responsible for identifying all records in the branch database that had been changed that could play a part in the records in the flat file required for transmission, while simultaneously rejecting any changes that weren't crucial in order to keep the data size as small as possible.

I was working at Snelling around the time I became interested in XP and started introducing test automation to my work. After we released version 1.0 into a few branches, the project manager (who was also my only QA person) left the project. Before version 2.0, I spent 3 weeks building a thorough integration suite for the Extraction and Transmission module. After 2.0 was released, the only bugs we encountered were related to unexpected use cases or bugs in the 3rd party system. We eventually had regular integration tests running against two different versions of the third party application and 3 versions of SQL Server.

By the time I left the project, over 175,000 timecards and 50 million dollars in money paid had been processed. The project has since been ported to .NET and is still in production.

As DocuTIME was deployed to more branch locations, we accrued issues with supporting the installed schema. Out of this work I developed a simple schema DSL in Ruby that would generate different T-SQL scripts for validation, installation and upgrades.

At times I helped support our in-house web app development, at one time building a small, home rolled VBScript unit test framework, and another using (what later became) Watir and DRb to do execute some web tests against 3 different versions of Internet Explorer on separate machines (not being able to have multiple versions installed on the same machine).

I also worked a few months on a greenfield web application that included a C# code generated data layer (code gen in Ruby) and forms with both ASP.NET and Windows.Forms versions that could be tested via the same test scripts (based on early-Watir code). Unfortunately, the project was shelved for business reasons.

As one of the original developers of TIMS (v 1.0-2.4), an electric utility application to record, transmit and store inspection data of transmission line assets, I built a custom interactive 3D graphics engine in addition to some general OOP development. Written in Delphi, the field app was designed for hand-held pen-based systems. I was also responsible for much of the schema design, the installer and build engineering, and eventually was lead developer on a team of 5 coders.

DVAssist is a utility for toggling between Qwerty and Dvorak layouts on Windows with a configurable hotkey. I originally wrote it because the built-in toggling support in earlier versions of Windows was flaky and not easy to use. Version 1.0 also included a stay-on-top window displaying the current layout, to aid with heads-up training. To help serve the international Dvoraker, version 2 is no longer hardwired to US Qwerty and will toggle between any layout and Dvorak. While Windows support for toggling layouts has improved, the tool has remained popular with users on public machines (typically at universities) that do not have access to change the keyboard layout through regular means.

Earlier versions of Outlook had no way to turn off the new mail tray icon. This drove me crazy because I subscribed to many mail lists and all of that activity rendered the notification icon useless for me. I wanted to be able to restrict it to only displaying when I had email that stayed in my Inbox (mail list messages getting filtered off to other folders) -- that usually meant important business email that I did want to be notified for.

I wrote Outlook Monitor to (a) kill off the existing Outlook tray icon (which involved a fun little hack) and (b) replace it with one that would only light up when messages stayed in the Inbox. It's served a small niche of like-minded anal retentives rather well, though I've not kept up with it since switching to Thunderbird.

At some sweet spot in the recent past where I had big enough drives to make it easy for large dirs of temp folders to sneak about stealing space, but not big enough drives for me to ignore the leeches, I wrote cLabs Disk Usage for Windows, based on a nifty utility called DUW by Markus Seger. Both tools will show recursive totals starting at the top level folders for a drive and allow you to drill down. The first improvement I made on Markus's tool was to compensate for amount of disk space used by files, not just file size. Some other improvements followed at later dates, including file count data and data by file extension. Despite its lacking in good (meaning 'any') UI feedback during the time consuming calculation phase, I continue to use this tool to hunt down unexpectedly large folders wasting space on my drives.

Near the end of 1999, the short-lived Borland Developer News published an article on DUnit, written by the guy who'd ported it from JUnit, Juancarlo Anez. This article was the beginning of all things Agile for me and I quickly started using his work. Not long after that I started whining about his work and Juanco was foolish enough to make me a co-admin on the project. I began making my first commits around August of 2000. I stayed fairly active with the project while I could still afford the time by doubling up during my day job working in Delphi. I've since left Delphi behind and DUnit with it - but I still browse the mailing list and Juanco hasn't kicked me out of the SourceForge project yet. Many thanks to Juanco for his introductions to a better way of doing things.

Build a better MouseKeys and the world will beat a path to your door -- unless you forget to actually post the thing anywhere. I'm a keyboard junky and got beat down one day fooling around with XP's built-in MouseKeys accessibility tool, so I decided to write my own. Mine, I think, has some better options for jumping around the screen faster when you need it, sort of like the acceleration settings for mouse movement. If you're curious, hit me up and I'll send you a copy.

I had the privilege in the early oughts of hanging around Dave Thomas and other smarties on a regular basis via the DFW XP group. In addition to interesting process discussions, we got to hear tales of Dave and Andy's initial endeavors into Ruby. At the time I'd heard of Perl and Python, but not had the wherewithal to check them out. Hearing him talk about Ruby convinced me to check into it.

Wikis weren't exactly cutting edge by then, but I decided the world needed another one anyway and it'd be a good thing to cut my Ruby teeth on. (You can still see the teeth marks if you look at the source - though I'd rather you not). I wanted a wiki that would be file-based, without any metadata storage, so in case using a wiki as a knowledge store failed (or my Ruby coding skills failed), those wanting to spelunk my data could do so with Explorer and Notepad. I also decided it needed to support unlimited hierarchy, which turned into an interesting design exercise, one I'm not sure I'd repeat. (The biggest problem seems to be people treating the hierarchy as a bread crumb trail, which quickly introduces problems - much like OOP design - prefer composition over inheritence).

The wiki was successful enough for my own use that I built clIndex, a standalone DRb server, to help with fast indexed searches. That code I'm a bit more proud of, as it was written after I knew my way around Ruby a bit, and I think does a good job of serving up multiuser thread-safe results (though I'm sure it doesn't scale too well). Both released under a BSD license.

clWiki and clIndex require clUtil.

In 2002 I started working on an XML serialization library for Ruby. There were existing ways of doing this at the time, but I wanted to make a library that was simple to use. Not long after, YAML caught the attention of many, including myself, so my interest in maintaining the library waned. Check out its home page for details. BSD license.

In 2001, I released a small Ruby lib for manipulating Internet Explorer with the sexy name of ClIEController. Brian Marick and Bret Pettichord picked up on it for some of their QA automation training and by 2003 a small group formed. I hosted a wiki for it -- still up for historical purposes (i.e. I'm too lazy to take it down). Bret and I did a presentation of the tool at Bret's 5th Annual AWTA in 2004. By August of that year, Bret made the push to evolve things into the Watir project and a thriving community has gathered around the tool. Bret has been the real backbone behind the project throughout and my involvement since these beginnings has waned as I've had less opportunity to do web work on my day jobs, but I'm hopeful future opportunities will give me time to contribute more to the tool as it continues to grow.

casegen is a handy test tool for generating use case combinations. It's written in Ruby and uses a simple external DSL. The goal of the tool is to generate all possible combinations from sets of variables, then eliminate certain combinations based on rules. While it can be difficult to figure out how to define the sets of variables, I've found the tool invaluable in certain situations for helping to provide good use case coverage. Rather than starting from a few positive cases and working in my head outward to think of some negative cases, the tool forces me to think through all cases to begin with and then define the rules that should eliminate cases the software should prevent or otherwise deal with.

Eclipse's call hierarchy tool is one of my favorites to work with. In some cases, though, it can be too much information to grok in the tree view widget. After a few manual trips taking the copy/pasted output and massaging it in a text editor into dot source, I decided to make a plug-in to do the work for me. Here's a screenshot of it in action. Open sourced under a BSD license.

clParticle is simple 2D particle system I wrote in Java, and partikil is a game I built on top of it; both are open sourced under a BSD license. Each player starts with a small group of stationary particles of their color and a particle they can move in any direction, N, S, E, W. At any time each player can activate one of two actions at their current location, either drop an additional lump of stationary particles or drop a bomb to blow away any particles in the blast radius. The longer the player waits to do anything, the bigger the lump or the bigger the bomb. Also, the longer a player waits to do anything, the older and weaker (less blast resistant) their existing particles become. Once a player has all their own particles blasted off the board, they're out. Last one remaining on the board wins. partikil supports 3 simultaneous players on one keyboard.

The original intent for partikil was to then extend the game on the job at eInstruction and make one called partiklik ('klik' a play on 'clickers', a common name for the student response remotes) -- this one to support up to 10 players or more. I got the game working with the remotes, but there were performance issues with them since the real-time feedback required from a game controller was never designed into remote firmware. I did get our RF manufacturer to cut me a special firmware that helped quite a bit, but it still didn't remove the latency problem.

As games and particle systems go, there's nothing much to write home about. The source however (which is included in the distributed jars) I think is a good sample of my design skills.

Back when I was first studying XP, I decided to write a paper about it in hopes of presenting it at a Borland Developer's Conference to help further the cause within the Borland community, having already gotten involved with the DUnit framework. Unfortunately, my schedule wouldn't permit me to attend, so I only submitted the paper for inclusion on the conference's CD, but they did decide to publish it there. The Case for XP is a pretty straight-forward (i.e boring) read, but I think it a decent summary of Agile from the XP perspective.

One part of the job I enjoy is tackling nasty debugging problems. I've written a few of these bug hunts up in my blogki (Martin Fowler has a bliki, I have a blogki. Mine sounds more Russian and macho, even if it doesn't have its own Wikipedia entry). Prepare yourself for mind-numbing details:

• The Case of the Intermittent Buffer
• The Case of the Inconsistent Parent
• SQL Server 7, ODBC and Temp Tables

Here's a sample of articles detailing techniques and tool configuration.

• Retrofitting Test Automation
• Optimizing Visual Studio For TDD
• Introduce Parameter Object
• Introduce Parameter Object Refactoring in Eclipse (pre 3.3)
• Current Thread Not Owner (Java)
• Split Subtleties (Ruby)
• Validation Coding Techniques
• Apache LDAP and Active Directory

One of the things I like to collect in my blogki is articles that try to help capture the complexity of the craft.

• Code and Contracts
• The Cost of the Luxury of Ignorance
• Emergent Angst
• Immaturity Is Inevitable
• Lousy Error Messages
• SQL Sets

Finally, a sample of entries on design and the craft in general.

• The Key to Success
• Grow Yourself
• Making Bad Programmers Care
• Resisting Change
• Eyes Over Buckets
• Learning is Good
• Serve the User
• Paul Graham on Design
• Design Precision
• On Rewrites