A Model of Automating
A Model of Automating
I automate tasks by using tools and writing code. Understand what they abstract to learn more.
Join the DZone community and get the full member experience.Join For Free
The need for DevOps innovation has never been greater. Get the results from over 100 business value assessments in this whitepaper, Digital Darwinism: Driving Digital Transformation, to see the positive impact of DevOps first hand.
What do you automate?
I Automate Tasks
Sometimes I use a tool to automate tasks. Sometimes I write code. But of course my model that underlies that statement doesn’t have as clear a separation as the words suggest.
My ‘tool’ and ‘code’ models do not have a clear separation. They overlap. I use tools when I code. I can write code to extend some tools. I can wrap tools in code.
I can model ‘Tools’ and ‘Code’ as a ‘spectrum’. For example:
- Tool <-> Code
- “Easy Entry Point” <-> “Longer Learning Curve”
- “Limited to Tool Features” <-> “Ultimate Flexibility”
I value flexibility in my work.
- I try to learn “Tools”, “Code”, and their intersection rather than limit myself to one extreme.
- I try to learn what the “tools” abstract to reveal gaps in my knowledge.
- I try alternative implementations, e.g. different tools, different languages.
How do you automate?
I Use Tools
I generally have no choice, but to use tools. Since most of my work involves computers, I can’t really interact with the software without using tools. Hardware tools like:
To access a web application I have to use Software tools:
At a minimum, to do my work, I have to use tools.
My Work Starts Partly Automated
We could call my work ‘tool augmented’ or ‘tool assisted’ and leave ‘automated’ to describe a less interactive process. Or I could describe my work as ‘automated’ right from the get go. I don’t think that helps me. I automate tasks. I need to know what tasks I perform, then automate them. I can prioritize what I automate based on relationship attributes between myself and the task: how time consuming, risky, boring, complicated, easy, etc.
Tools Provide Abstractions
Each tool provides a different abstraction. Our choice of tool can provide a different abstraction of the task. For example, if I want to move a file from one computer to another, I might use FTP.
- FTP is a prototocol, it defines how tools will talk to each other to transfer a file
- ftp is a tool which abstracts the protocol so that humans can get something done.
- FileZilla is a tool with a GUI, which has more features and abstracts the process of 'ftp’ing files further.
- Intellij Synchronization abstracts it further. I might forget it implements using FTP.
Abstractions Can Make It Easier to Start
The features that tools provide to abstract away the ‘real task’ can make it easier to complete a task, without knowing the exact details of how the tool implements the task.
If I stopped to consider it then I would generally view a tool that provides a higher level abstraction as a ‘more automated’ task.
Tools Make It Easy to Get Started
While tools can make completing a task easier, because they provide an abstraction, they hide details, and that can make it harder to increase our knowledge about what ‘is really’ going on. We might not care about what ‘really’ happens, because we have work to do, and completing this task simply fulfills a precondition to allow our work to continue.
However, we can increase our options and flexibility about how we fulfill preconditions by learning the details of the abstractions. As we do so, our ‘technical knowledge’ increases, and we may find new ways to complete tasks. Tools can make it easy to avoid doing this work and it will leave gaps in our knowledge. This may not manifest as a problem. I like to use a combination of tools:
- tools which target the low level abstraction e.g.
- tools which make it easy and allow access to lower level abstractions e.g. ‘enter custom command’ in FileZilla
- tools which hide the abstraction and make my life easier
When I Code, I Use Tools
I often write code using Java, this requires me to have knowledge of:
- Programming in general
- Java programming languages
- Various protocols and technology implementations, e.g. HTTP, Web Architecture, etc.
I also need to use tools:
- Byte Code Interpreter
- Unit Test Framework
I know ‘in theory’:
- How a compiler works
- What byte code does
- What the IDE does
I know ‘in practice’:
- How an interpreter works
- How the unit test framework works
- What the libraries I use do, and how they do it
I have broken through some of the abstraction layers in this ‘coding in Java’ system, or gestalt, or abstraction. But not all. I don’t need to decompose all abstraction layers to increase my productivity. But I know that the gaps in my knowledge mean that I don’t always write the most efficient code. But that gap doesn’t really negatively impact the type of code that I write… Code to support a testing process. I have tried multiple libraries that abstract HTTP, and I pretty much default to using RestAssured, simply because it made my work easy. But I know that alternative libraries exist, I haven’t had time to evaluate them properly.
Code Gives Me Ultimate Flexibility
Coding provides me with the ultimate flexibility. I don’t have to look for a tool. I can write custom tools to do what I need. Sometimes, I might embed, or wrap, a ‘tool’ in my code. If I wanted to use
ftp in my code I might eventually look for a library. But I might also start by using
.exec, and using the existing
ftp tool to implement FTP for me. Knowledge of ‘tools’ and ‘code’ provides me flexibility and choice around my implementation approach.
Some Tools Allow Me to Write Code
Even if I don’t plan to use a feature, I prefer to use tools that allow me to extend them or build on them.
- Script FreePlane using Groovy
- Script Fiddler using JScript.NET
I prefer to use tools that have an API:
- Google Spreadsheets
I prefer to use tools that have an open file format:
- FreePlane and FreeMind use XML
- Leanpub.com uses Markdown
- Scripting in a tool means I can add ‘insitu’ adhoc features very quickly
- API means I can ‘build on’ the tool to support my workflow
- Open file formats mean I can write code that processes the tool models for other purposes
I often use a combination of tools to provide the flexibility:
- Command line tools to wrap in simple shell scripts or call from compiled code
- Different tools for the same task but with different features
I Use a Combination of Tools and Programming
- I tend not to talk about ‘test automation’ because I automate tasks.
- I use a combination of tools and programming because I value flexibility.
- I generally start with a ‘tool’ and then work towards understanding the abstraction and identifying lower level and alternative tools.
- I know of some of my technical limitations, and the risk they provide to my process.
- I reduce the risk and limitations prioritised based on the projects I work on, and the technologies I want to work with.
How do you automate your work?
- Look at the tools you use
- Identify what they abstract
- Find a tool, or tool feature, which targets the lower levels of the abstraction
e.g. surfing the web -> HTTP/HTML -> wget/curl/grep
- How can you fit your tool in your workflow?
- Does it have an API? How does it work?
- Can you script your tool? Try it
- Does it have an open file format? What do you learn by viewing it?
- Does your tool miss a feature?
- Find an alternative tool that has that feature.
- Can you use a combination of tools and API/File format to create that tool?
- Identify a task you perform
- Pick a programming language
- Automate that task
- Repeat all of the above
If you know any other related reading then let me know.
Published at DZone with permission of Alan Richardson , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.