Good Software Practices Scale Down

Today I revisited some scripts I last touched on December 5, 2011 for very very carefully archiving research data with checksums, an audit trail, and other very very careful things like that.

One of the requirements for this project is that the first phase of my processing needs to accept input data from a provider. Unfortunately, this input format has never been the same twice. Grr.

Upon receipt of the second variation on July 12, 2011 (six days after I started the project), I took the time to make the script somewhat configurable with an external file.

This was handy in November 2011 when I needed to do a similar set of work for a second research dataset. I put everything in a configuration file stored alongside the input data. Date format strings, headers, fields of interest, key/values for data types, etc. That meant I could share code between datasets as they emerged from the wild.

So last week, I got another set of input data. Yep, another unique format. I haven’t thought about this in over a year, and I have a terrible memory. Today, I got the input data parsed and validated in five minutes after editing a config file, because:

  1. I had one place to do customization
  2. I took steps to encourage code reuse
  3. I wrote good comments and gave myself a -h option

All this despite knowing that I was probably the only one who would ever look at this again. And I have those dates because everything is in a Subversion repository. Did I mention that I wrote it in a language I don’t know very well?

Granted, this is a tiny little thing in the universe of computer things, but my point here is that it’s often worth doing the right thing for the next guy, even for small things, even if the next guy is you. Perhaps especially if it’s you.

I Did Not Know: multitail

I think I once knew this, but forgot about it. Still, the fact remains:

I Did Not Know about multitail.

I’m watching eight different log files from a Windows server through CIFS on my Windows 7 desktop where I’m running Cygwin and multitail. This is both pleasant and awesome-looking, which is not normally the case for watching eight different log files, especially on Windows.

Mac OS X 10.6 Automator Services: Awesome

I’ve been enjoying how Automator in Mac OS X 10.6 lets you easily create services for simple little annoying things.  I expect it’ll take about three times longer to write about what I just did than it did to actually do it.

I’m always writing emails containing computer hostnames, and sometimes I want to include the full DNS name and IP address in those emails.  That’s especially handy when you’re writing about firewall rules, as I just was.

I created this simple Automator Service workflow in about 60 seconds.

When I select some text in a text editor and run this Service (context click, select the Service name), this happens:

“foo” -> “foo.domain.com [192.168.1.200]”

A few notes:

  1. “Get Specific Text” is grayed out because it’s disabled.  As you’ll find when writing Automator Services, you have to have some dummy text available to substitute for the selected text when developing your workflow.  You just disable this when you save the Service.  Easy, but confusing if you don’t know what’s going on.
  2. Be sure to check “Replaces selected text” at the top.  That means whatever you have selected in your text editing window will be replaced with the output of this script.
  3. Be sure to change “Pass input” in the “Run Shell Script” task to “as arguments”.  That makes $1 become your selected text.
  4. There is zero error checking.  You will probably blow up your computer and the Internet.

It actually took much longer to write this post, especially because WordPress didn’t want to create an image link for me.  Thanks, WordPress!