I’ve been spending the last few days heads-down with ruby’s build tool rake. In my days, I’ve used equivalent build tools such as make, ant, and … old skool nothing.   I like rake in that it overcomes the blatantly obvious flaws of make and ant. For example, make’s fixed position line declaration and yet-another-layout-language to learn with ant’s overly-verbose, hard-to-read-enterprise-large-file XML format.

In the past, I’ve always written a build target called clean. The goal of this target was to remove all generated files so that any remaining file is explicitly known to version control.

In various rake examples, I’ve come across a conflicting pattern… clean and clobber. In rake-speak, clean means “remove temporary generated files but preserve the primary output of the build.” In other words, this will clean up the release. Clobber, as one might suspect, will remove any and all generated artifacts reducing the codebase to all known by version control.

I’ve debated the nature of “clean” for a few days.. it still rages on in my head. But so far, I’m in favor or the original meaning. After all, why should rake’s clean remove temp files that the build target should be removing anyway! I don’t care about interstitial files.. just produce the build!

I just returned from a consulting engagement in Seattle and traded banter with release engineers about “nightmare builds.” I’ve had these same discussions with other companies and it’s interesting how keyboard proximity has played a (vital) role in disasterous realtime, internet-based software release situations.

For example:

• 0 and O : Setting an env config file to PR0D instead of PROD
• 1 and ! : embedded config file regex for pattern matching
• E and 3 : dislexia at 2am
• = and == : Testing a runtime conditional only to “set” it
• - and = : dislexia at 2am
• l and | : meant a ‘pipe’ but fingers returned to homerow and hit an ‘el’ with the same finger