Automation Via Tools

READING:
The Writing Life
Annie Dillard

A short (~100 pgs) book about the craft of writing.

Written in Dillard’s signature style – introspective, non-linear, metaphysical – it’s an interesting take on the life of a writer: Why we do what we do; how it happens; what are the results?

While not as satisifying as her other books (such as Pilgrim at Tinker Creek), it’s still a difficult but rewarding read.

All books

Tools that automate are really the single most powerful reason to use tools.

While automated tools can be part of an app, I’m going to concentrate on those tools that may be in some way divorced from a given application.

Basically, automation tools are a way of spending some time up front to make a repetitive task unnecessary or greatly simplified. A very simple example of this would be a ping tool that periodically pings a remote server to make sure it’s running. Sure, a developer can do this via the command line or through a browser, but does this developer want to do this every five minutes 24×7?

Of course not – and that’s where a tool comes in. Add a few more hours of work, and this tool may be able to do the following:

  • Ping remote server every X minutes
  • Log result (up/down/latency)
  • Fire off e-mail(s) if down for more than Y minutes
  • Hook into another tool that will graph the results for easy viewing for the suits; perhaps set to e-mail out every morning or whatever.

All these tasks can be done manually, and putting together this tool will take some time and effort, so why bother?

Because – once the initial work is done – the tool just keeps on running, never getting sick, taking a vacation or a new job and so on.

In the long run, tool creation generally pays off (there are always the inefficient and/or unnecessary tools). Do it once, and then every time it’s used it saves some seconds of work. All those small seconds added together suddenly start to pile up.

Anyone reading this blog (and if you are, seek professional help) knows all this, but I’m using these tool entries to help clarify my view of the subject, so bear with me.

Some other simple examples of automated tools are the following:

  • Backups
  • Auto-updates of a site (change the feature of the day on a static site by pushing the change to the remote server)
  • E-mailing: This tool is called whenever some other tool detects an event that should trigger an e-mail. By having a single tool (with params) handling this, each tool does not have to re-invent the wheel.
  • Trigger future events: Think of Outlook reminders. Schedule an event in the future, go away for the week and all the tasks occur as you scheduled them automagically.
  • Parsers – Example: Pull down the product list of a vendor daily and parse out the necessary data to put in the database. Parsers are a huge subset of tools (log analysis is basically parsing, for example)

There are hundreds more, but this should give one an idea.

One of the unseen benefits of tools is the way that they can become more than tools (dumb, automatic servants) – they may become decision drivers.

Take the example, listed in my previous entry, of log analysis. Pretty basic stuff, but – as noted there – if the log runs against list of current/potential clients and so on, some patterns may well develop. This comparison tool may drive – actually create – a list of clients to call based on business logic embedded in the comparison tool. Results such as these are powerful and only possible in a medium such as the Web.

And if you take the time to create the tools necessary to potentially uncover these patterns…