3 Reasons Why Every Toolsmith Needs a Mac Mini

1. With VMWare Fusion, you can run any operating system in the universe, including 64-bit ones. Perfect for your multiplatform development environment. Of course you have to soup it up to low latency 4GB (3GB usable, before I get corrected. The 1 GB is for that extra millisecond) and 7200 RPM drive if you want to do any serious virtualizing.
   
2. It's very small (see the CD case I put on my Mac Mini for reference on the photo) and very quiet. Your desk is already littered with many gadgets you have to play with evaluate, you need this one to be unobstrusive.
   
3. Oh, you're not developing on Mac? Well in case you haven't heard, just letting the programmers touch a Mac will guarantee 20% increase in code production (of course you have to give the 20% back as "official private time", Google style).

P.S. If like me you are using a KVM and keeping your non-Mac computer, switching back and forth, you will quickly be annoyed by how lame the non-Apple keyboard support is (I sense fanboy wrath coming... I better duck).

CruiseControl.NET 1.4 RC1 now available.

If you are using .NET, and are doing Continuous Integration, you have probably heard of CruiseControl.NET (frequently referred to as CCNet, and not to be confused with it's original Java cousin which is just CruiseControl or CC). I have used it for several years now, often working off a locally built version so I could take advantage of unreleased enhancements. Depending on where you work, you may not have that luxury, in which case you may be interested to know that CCNet 1.4 RC1 is now available.

CCNet runs (at least in my case) on a dedicated build machine. It just sits there in the background watching for changes to the source code. Shortly after a change is observed the code is retrieved from source code control, built, unit tested, and has a few other tools such as FxCop run against it. Assuming the code meets a set of predefined criteria (code builds successfully, all unit tests run, code coverage is greater than 80%, and there are no major concerns indicated by FxCop) the build is considered a success and made available to others for additional testing (and eating our own dog food). If not, possibly because of an unforeseen interaction with other code, a build failure is signaled and work can immediately start to resolve the problem.

Before we go much further, in the interest of full disclosure I should mention that I am probably a bit biased about CCNet. I don't have code commit rights, but you may notice my name on the contributors page, and on documentation pages from time to time! With that out of the way, I guess perhaps I should get on with the main reason for writing this entry... my experience migrating from our current (1.3 locally built) version to the new one.

Getting CCNet is simple enough, you can choose to download it as an installer, a simple zip file, or a source-code snapshot. There is also a fourth item on the download page at SourceForge which is a stand-alone installer for the CCTray utility which I will talk more about later. I use the zip version because I like to keep the CCNet executables we are using under the same version control software as our source code. That way if I ever have to recreate a particular build I know that I will be using the same versions of the tools.

For me, the experience was completely painless because there have been no breaking changes between version 1.3 and 1.4 RC1. All I had to do was shut down the server (and IIS which is typically used to provide a web interface), unregister the CCNet service, copy over the new files, register the new CCNet service, then start the servers again.

The first thing I noticed about the new version (or at least the web interface) was the graphs which are now available. They provide a great way for you and/or your managers to get a quick overview of how your project is progressing over time. For example, typically you would want (and expect) the number of unit tests to increase over time, and number of FxCop warnings to stay the same or decrease. I was shocked to see that for one of my projects there had been a sudden jump in FxCop messages which occurred about a month ago, and I could quickly look back in the revision history to see what had caused the increase (a new rule had been enabled). The responsiveness of the web view has also been improved, but had never been a significant problem for our team anyway.

One long-requested feature now present in CCNet is the ability to use parameters in the configuration file. Previously if you had common configuration options you would either have to repeat the option in the CCNet configuration file, or understand enough about XML to use DTD entities. (You could also have done what I did and write a quick tool to auto-generate your CCNet configuration file, but that choice wasn't mentioned in the documentation :-)) Now, defining reusable chunks of configuration is as simple as adding an XML namespace reference and a define element or two, then referencing them with a $(entity_name) as needed. I haven't done it yet, but I'm planning to refactor my CCNet configuration file to take full advantage of this feature very soon!

Another feature which has been improved is the email notification mechanism, but I get quite enough emails every day anyway and prefer to use CCTray which provides a real-time view of the current status for one or more CCNet projects in your system tray. A very useful enhancement to CCTray, which requires a little work to enable, allows it to show what stage the build is in. Previously, that was somewhat difficult because all CCNet (and therefore CCTray) knew about was the process it had most recently launched - often NAnt or MSBuild. The new release adds a mechanism where progress information can be passed back to CCNet from any process via an XML file. Helper libraries are provided for both NAnt and MSBuild allowing them to provide the information CCNet needs to provide a richer build progress indication.

In the "just for fun" section, the latest version of CCTray can talk to you! Using the text to speech API, CCTray will announce when a build starts, and when it finishes. I suspect this may soon become annoying for the person who shares an office with me, but for now I quite like it! The X10 integration is possibly a little more useful. I have heard of a couple of teams who use X10 to control a lava lamp. A build failure turns on the lamp, and it is the team's goal to fix the build (turning the lamp off) before the first glob of goo bubbles to the top!

Hopefully if you didn't already have an automated build process in place you are now asking yourself if it is worth getting get a similar system up and running. Well there are even tools to help you do that too, and next time I hope to tell you about my experiences with Jay Flower's CI Factory

Simplicity... It's a good thing!

It's not directly related to the role of an Agile Toolsmith, but I found Andrew Binstock's essay in the May 15th issue of Software Development Times fascinating. The same article is also on his blog.

Very briefly, it describes a set of "rules" to help you think in a more object-oriented manner when writing code. While the rules are (IMHO) not applicable for large-scale projects, such rules guide you towards simpler code, and as most developers are reminded daily the simpler the code the easier it is to maintain.

In a similar way the toolsmith should always aim for the simplest possible set of tools needed to get the job done. For example, if you are already using MSBuild (probably as a by-product of using Visual Studio), it may be appropriate to use msbuildtasks instead of NAnt. On the other hand, NAnt offers certain benefits - like cross-platform capability and the fact that it is open-source which may make it a better tool, depending on your project's unique needs.

How well can you recreate a specific build?

"Hey, Richard! You know that special build we created for Joe Jackson a few months back?"

I knew it well. Joe's business was mostly conducted online and required a special scenario that would cost him thousands of dollars if our software didn't recognize and handle it properly. He was also one of our most loyal customers. As a result, a co-worker had postponed his retirement to work on it.

"Well Joe's web host went up in flames last night, and nobody had an off-site copy of the CD. For some reason it's not in the release archives either. Do you have a copy of it somewhere?"

For some teams, a scenario like that would be a complete nightmare - especially if the outgoing developer had chosen not to use a reproducible build process. Even worse, the now departed developer may not even have used source code control, and the IT department may have reformatted the disk and given the computer to someone else.

So how good is your process? If this was one of your projects could you recreate the special build on demand to help your customer? If you couldn't, do you think the customer would be as willing to do business with you again in the future?

For the Agile Toolsmith, this type of request holds no major horrors. In an ideal scenario, not only is the product source code available from version control, but also the applicable unit tests, dependent libraries, build and publication scripts, and sometimes even the build tools themselves. Recreating a specific product becomes as simple as retrieving the right revision from source code control, and triggering the build process. No additional interaction should be needed until the process completes, at which time you are left with a CD image, ready to be converted into a physical CD, or a setup file which can be sent to the customer.

For a reproducible process, the following will typically be true:

• After it has been launched, the process requires no user interaction.

• The process verifies any prerequisite which is not available from source control.

• The process does not change any source controlled files.

• The process does not depend on any machine specific settings. (It should be possible to perform the build on any machine, even a completely new one, as long as the prerequisites are met.)

• The process is complete. (There should be no additional manual steps which always need to be performed).

• If a part of the process fails, that failure is clearly indicated. (Ideally, the process also halts as soon as possible after such a failure has been detected.)

Of course, not all of these goals will be possible for all projects. In particular, automated testing (especially of a user interface) can be very difficult and/or costly. As a toolsmith, especially an agile one, you must always remember that a tool's purpose it to help do your job. It should never get in the way of getting the job done. A tool will also not do your job for you, no matter how good it is.

Revision Control: The Only Tool You Absolutely Need

Forget the hype from those tool vendors that costs gazillions of dollars/pounds/yen/euro/rupiah.

The only indispensable, must have, no question about it, development tool you want is revision control system, sometimes also called source control system.

Whatever other tools, integrated development environment (IDE), or you only ever use Emacs and vi to write your program, you need to have revision control.

Not surprisingly then there is a huge market for revision control systems. Not just from an economic point of view, but also from a technical point of view. There are several free and open source systems such as Subversion, cvs, git, Mercurial. Proprietary systems with free for few users: Perforce, SourceGear Vault. And also systems that cost hundreds and thousands of dollars per user. Then you have centralized or distributed (leave your view on this on my new How to Be An Agile Toolsmith lens)

So your mission, should you choose to accept is to become the guru on source control systems.

• If your team is not using one, run, don't walk, to whoever is in charge, camp out in front of his desk/room/office until you get one. Or if that doesn't work, just get a free one and start using it.

• If you already have on your team, learn it. Hack it. Push it to the limit. If you don't have good support from the programmers/vendor/open source project/management, ditch it and get a new one.

During your time as a toolsmith, the source control system will take over your life, so be prepared to live together.

I would really like to hear from people who think source control is for wimps. Leave a comment please!

Distributed Version Control Systems: Why You Need One

 

We will introduce the concept of Distributed Version Control, see when to use it, why it may be better than what you're currently using, and have a look at three actors in the area: git, Mercurial and Bazaar.

InfoQ: Distributed Version Control Systems: A Not-So-Quick Guide Through

A very good introduction, for me at least, as I am very much in the dark regarding distributed version control systems.

Why Your Team Needs a Toolsmith

Ever since I started programming professionally in the early 90s, I always had rules to follow. "Use these switches to compile". "Name your output in a certain format" (of course back then it would be an arcane mix of letters and numbers because it was limited to 8.3 format. Remember those?).

As my career progresses, I was the one making the rules. Proper folder structures. How to document testing. Finding new tools to make life easier for everyone (almost two decades later, it hasn't! More on this as the blog develops.)

I've now realized this role, is fullfilled by a Toolsmith. Like in the real factories with real machinery, the toolsmith would use all his engineering creativity to keep it running. Sometimes it means ordering new machines. Sometimes it means hooking two things that were not meant to be together.

But the toolsmith is sometimes so invisible, always taken for granted. If things are working well, the toolsmith looks idle. If things are breaking apart, the toolsmith gets the blame.

That's why this blog is born. I want to highlight the art of software toolsmithing. I want development managers and programmers to know that when things are working well, the toolsmith is most probably designing new enhancements to make life even easier for them. And when things are breaking apart, it is most probably due to underinvestment in the development infrastructure.

I will be touching a lot on the issue of building software, as the role of Buildmaster. But there is also what they formally call Software Configuration Management. I don't really like the term myself, programmers, team leaders and managers don't click with it. I would call it Software Release Management instead. That's because everybody understand that releasing software is the most important thing a team will do. It is the whole point of their existence.

I will also touch on how to nurture a development environment that both programmers and managers like. Easier than it sounds, and it's more than dual screens and free coffee (although that helps a lot...).

I guess that's enough for a first post. I look forward into developing this blog. Any comments and suggestions always welcome.