Long time no blog...

So the last blog entry I had was way back in February of 2008...a lot has happened since then.

In the real world, some skunkworks projects I've been playing around with have included:

1. Tapping into POSIX message queues on Linux by using a custom shared library interposed via LD_PRELOAD. By intercepting calls to mq_open() and mq_send() it's possible to create "shadow" message queues and send messages to both the intended and shadow queue. This allows for non-invasive analysis of messaging between software components.
   
2. Playing around with Python again. GDB 7.x now supports Python as a scripting language, so it is possible to develop application-specific pretty printers as well as other GDB commands in python. Also developed some Python code to parse Link16 messages in textual form to support post-mortem analysis.
3. Using Mercurial for managing source code of my own software projects. In the past I'd used RCS, CVS, or a little SVN for managing projects on my home systems; those have all since been replaced by Mercurial (hg) repositories. Mercurial supports a wide range of usage scenarios ranging from single-user projects to distributed projects on the scale of Solaris.
   
4. Played more with VirtualBox and with VMs running a slew of guest OSes: OpenSolaris, NetBSD, FreeBSD, and newer Fedora releases.
   
5. Contributed to Illumos, a new open-source project taking the last available source code drop of OpenSolaris before Oracle closed it. It had been 5 years since I last used Solaris, and a lot had chanced since then. The goal for Illumos is to "liberate" the remaining closed-source pieces and serve as the foundation for any number of open distributions. So far I've ported the FreeBSD 'tail', and applied fixes in the CIFS area of Illumos. Time permitting I'm on the lookout for other user-space things to work on, though that may change soon due to the "day job". After years of doing C++ development it's been an interesting challenge going back to straight C again.
   

Professionally I'm still a Software Architect on a Tactical Data Link program (CLIP) developed at Northrop Grumman; we've been in prolonged test/integration mode but are now approaching some new development. In the spirit of continuous improvement I've had some time in the background to think about things that can be done differently this time around, as it's always great to avoid a "Death March":

1. Leveraging things from open-source development. While we won't be able to take advantage of a distributed CM tool like Mercurial, there are some other lessons to be learned and tools to consider: continuous integration via a build manager like Hudson, web-based peer review of changes using something like the Webrev tool from OpenSolaris development, and a web-based source browser like OpenGrok also from OpenSolaris.
   
2. Looking into improved testing and test coverage of new and existing code. In previous lives I've used PureCoverage and on the current project we have had C++Test available as a unit test framework. On the topic of test coverage, something that looks promising is the gcov instrumentation option available with GNU g++ along with the lcov front-end from the Linux Testing Project, which is capable of generating web-based reports on code coverage.

VirtualBox Rocks!

I just had the chance to play around with VirtualBox (http://www.virtualbox.org) as different virtualization application. Using my Windows laptop (running XP) I was able to set up virtual machines running Fedora Core 8 and Solaris Express (Build 79). Including Cygwin that makes for 4 different OS environments without having to reboot!

I'd had mixed success with VMWare on boxen at home, but was impressed with the ease of use of VirtualBox on Windows. Once I upgrade my Linux box to a more recent Fedora version it should be a better host for VirtualBox (more CPU horsepower, memory, and disk space).

Wagner Power Sprayer: Friend or Foe?

One of my birthday presents this year was a Wagner Power Sprayer. It got christened this weekend as I repainted the fence at our house - going from faded redwood to a color actually approved by the HOA (but that's the topic for another blog someday). I haven't used any sort of sprayer before so I was sort of winging it and guessing on how much more/less paint it would use than painting with brush or roller. Nevertheless I had visions of a quick/smooth/effortless painting job.

The sprayer has two modes of operation: a tube attachment that theoretically lets you draw the paint right out of the can, or a smaller container that attaches to the sprayer directly and holds about 1/3 gallon. My first inclination was to save some cleanup time and use the tube attachment, so I tried that for the first half of the job. The biggest problems I found were: 1. The sprayer is now on two "leashes" - the extension cord and the 4 foot tube running to your paint can; this can be pretty awkward depending on the area you're painting. If you're not careful you can actually tip your paint can over with the tube. 2. The plastic clip that is supposed to hold the suction tube (actually separate intake and return tubes) in place in the can is really lame and doesn't work at all. Several times the sprayer ran "dry" because the clip came loose and the intake tube was no longer submerged in paint. A couple houses ago I did a lot of interior painting with Wagner's Paint Stick, which had a plastic cover that completely covered the top of a 1-gallon paint can, except for where the tube ran into the can. This seems like a much better solution. 3. With the tube attached there's not an easy way to set the sprayer down while keeping it upright (e.g. to scramble to grab a can of paint that just tipped over :o).

Problems aside, the first half of the fence got painted in about 5 1/2 hours, including some painting by hand in exposed areas where I was worried about overspray. This was a definite time saver over fence painting with roller/brush, but I was still somewhat frustrated with using the sprayer. Cleanup was pretty fast and easier than I was expecting. Any time that I saved in not having to clean the attached paint container was lost in trying to clean the tube.

Day 2 I ditched the tube attachment and went with the attached container. This made a huge difference in productivity and usability of the sprayer. I found that the container needed changing every 10-12 feet of fencing, which was ok. Problems I noted on day 2 were: 1. The sprayer handle has an extended "foot" that matches the bottom of the attached container, so you can set the combination down without it tipping over. That doesn't help much when you've got the container removed to refill it :(. 2. The instructions seemed to imply that the snap-on handle on the top of the sprayer shouldn't be removed once it was installed...I had it come off several times during the painting session, including a couple times with a full container attached.

The last half of the fence was painted in 4 hours; again this included time painting certain fence sections by hand to avoid overspray. Cleanup again was very straightforward, including cleaning the paint container.

In summary I'd say that I'm very happy with the sprayer and how it helped me finish this job much faster than if I painted with brush/roller. I could see it helping on some interior painting jobs as well, though the current house's vaulted ceilings will probably save me from doing some of them myself.

Maybe I should have been a plumber...

Lest there be any confusion I really enjoy the challenges of software engineering, even when they are more "real world"/schedule-induced than technical.

However, after having moved into a new house and had a fair number of plumbing tasks done for us over the past couple months I think there's something to be said for having a set of specific always-in-demand skills that allow you to charge outrageously. But then I guess the same could be said for some consultants these days ...

Stressful events in twos or threes (or more?)

They say that some of the most stressful events in life include (in no particular order): getting married, having a baby, buying a house, selling a house, moving, changing jobs, work (needs no explanation). That said, I'm wondering why I/we have been prone to endure 2 or more of these high-stress periods in each of the last few years. Just to recap:

2003: get married, get laid off, sell house, move cross country, new job
2004: buy house, move (local), survive startup hell
2005: have baby, change jobs to escape startup hell
2006: survive work
2007: have baby, survive work, sell house, buy house, move (local)

To be fair, we've really been blessed in terms of selling our house in 2 weeks in a down market, and finding a wonderful new house (and not getting outbid on it!). Still, things will be so much more calm when the smoke clears and the move is done.

Time for a new "startup"

David Christopher Love (aka Baby Dave) was born on Feb 23. He joins big sister Abby at home in Poway, California. Contrary to popular belief, his initials are not a tribute to the Digital Computer Lab at UIUC.

Reading "Death March"

I just picked up a copy of Ed Yourdan's Death March. Haven't had a chance to read it yet (being too busy at work), but am hoping to read it during the down time when baby Dave arrives. I definitely agree with the conclusion that software death marches are becoming the norm rather than the exception, having survived them at several different companies. I'll add additional entries as I read the book.