The article shows an interesting illustration of the disconnect between programmers and normal computer users. Like the author says at the beginning, any experienced developer knows that automating interaction with a GUI is a crazy idea. It's a painful, fragile way to move data around. But to the author and anyone who's done data entry, it's an improvement to their workday that demonstrates the power of programming.
So much programming instruction seems designed to teach people who already understand programming how to solve problems that nonprogrammers wouldn't even understand. A tutorial that started with automating tasks like this might be more effective than all the ones that start by demonstrating how to do basic arithmetic in $LANGUAGE and go on to a detailed explanation of $LANGUAGE's object system.
This is why I like http://www.sikuli.org/ and Mechanize-style DSLs so much. They translate programming, web requests and parsing/processing into plain english "click [here]" concepts.
I know several places where software components or systems software is tested against real-world applications, games, and whatnot, and... guess how it's often done? Yup, with a combination of injecting artificial keyboard/mouse inputs and looking things at the screen. And these guys aren't beginners but professionals. You can't really automate something that doesn't have the APIs for it.
I'd be interested in seeing an accompanying article by the author or another developer laying out how you would solve the same problem if you were an "experienced" developer; I have done a little of the same type of programming at my job, and a side-by-side comparison of the 'novice' and 'pro' approach would be extremely helpful.
Maybe I was too vague. I meant that a programmer would always use an API rather than scripted interactions with a GUI. An ordinary user might assume that programs use interfaces designed for humans, because the concept of an API doesn't even have a place in his mental model of how computers work.
> all the ones that start by demonstrating how to do basic arithmetic in $LANGUAGE and go on to a detailed explanation of $LANGUAGE's object system.
the fact that i knew exactly what you're talking about as soon as i read it is pretty good evidence that you're right.
the best tutorials i've ever seen are ones that start with a moderately complex program and step through it line by line, explaining in plain english why things are being done. this is how both human beings and computers parse programs, so i'm not sure why a tutorial writer would do it any other way!
i think the current trend of embedding documentation within your program as markdown on github is a pretty close approximation of that.
I can imagine trying to solve a problem like this in either; in theory, this is exactly the sort of thing the automation APIs should be good for...
In practice, you would get close and then hit a wall because something critical isn't exposed by the object model and the language itself offers no way around save for the ability to call down to components written in something else. At which point you're dealing with a lot more headaches.
The author illustrates something I think many of us too often forget: ease of use is often determined not by the intended use of the tooling, but by how easily they can be put to unintended uses - which in turn depends heavily on the ability of user to try stuff and observe what happens as a result.
I see more and more people - not programmers - poking around with JavaScript in their favorite web apps for the same reasons: low barrier to entry, low cost to failure, immediate gratification when they hit upon something that works.
This is a really great post. For me, the recurring theme is knowing what's possible.
From a class he took in high school, Vik knew that some sort of automation was possible. That spurred some reading and exploration, which led to some success.
Success led to thinking about other opportunities for automation and more exploration of what's possible, which in turn led to more success.
To me, it absolutely doesn't matter that things could have been done in other ways. Nothing to cringe about here. A developer can only use approaches that he/she knows or suspects are possible.
In the day-to-day work of a developer, knowing what's possible is perhaps the most important thing. Anything else can be googled.
Equally important to knowing what is possible is to not know what is considered impossible, or at least considered very hard. Automation is often considered futile, and knowing that can be intimidating. We are often limited by what we think is impossible, but really isn't.
It is said that most Nobel prizes are earned for research done before 30, since any older and they would know the breakthrough they are trying to accomplish is impossible :)
I had a government job and my boss loved me for doing automation stuff. All of the documentation and data requirements seemed to be written as though a person had to manually do everything -- like they expected a human brain to be making decisions at every step of the process.
It just reeks of a lack of care not only for the power of automation systems, but disrespect for the people who have to do that work. Design your processes in such a way that easy stuff can be done easily and important stuff can be done by people who have some authority.
This is my biggest (personal) problem with bureaucracy. "You have to do it this way because it's the only way _I_ know how to do it, and I don't care if you know a better way, because you don't get paid enough to have good ideas."
Yea my university IT job was like that too. Except automating things was part of my job description and I still wasn't given much lee-way to automate things much.
A few years ago I had a brain-numbingly monotonous "navigate here" then "click here" then "record output here" type job. Unfortunately, mine was on a military base and the "record output here" was an Access database. I tried to automate the whole process in Access, but military restrictions prevented me from automating most of the process.
Oof. Had a hilariously similar experience doing data entry at my first internship, which was at a financial services firm.
I knew nothing about programming, but I had taken an intro stats class that had a few assignments in R. A super simple R script did half of my day's work in seconds (plus some debugging because of course I did next to no error handling).
In retrospect, I've realized that if I knew a thing of two about regular expressions at the time, I would have been able to automate my whole summer internship.
I haven't seen much discussion of a more ideal way to solve this problem (to say: as a one-off like the author was doing, not reusable software), so I thought I'd just think about how I'd do something similar.
Luckily there are libraries that are great at interacting with a web page or multiple pages at the same time without needing to actually have a browser instance open. There's selenium and its various scripting environments, which are meant for browser testing but work just fine for many automation tasks:
http://www.seleniumhq.org/
This is golden. I've wondered more often than once myself what would it be like to have a "normal" office job.
For instance, take some city department or some big firm where things generally flow at a slow pace and require a lot of time spent on work items, doing possibly repeated tasks each week. What would a programmer do? Exactly as described in the article:
- learn what kind of tasks the job consists of
- identify repeated actions and patterns in work
- think of a way to automate the easiest parts, still requiring human to finalise the task
- gradually learning more and automating the harder and harder parts and building tools bottom-up based on earlier blocks
- finally ending up with a software mechanisation puppet that I can instruct and program to do my work
- gradually spend first some of my time doing the automation and as it would slowly take over I could devote more and more of my time automating the rest, and when all is done, I would feel the job is "completed" and get bored.
This is something that feels so natural to a programmer: I have dozens of little tools to aid in doing my programming job at work. The goal of a programmer is to program anything that can be automated and only work himself on the hard tasks that can't.
It's intriguing to imagine how you could apply those skills outside programming jobs.
Love it. I started my career in International Development and one of my team's first projects was figuring out how many miles our organization's 1000+ staff flew in a year (why is a separate story). The travel agent could only provide records in PDF. 1000's of them.
The intern I shared an office with was assigned to go through each record, type the origin and destination airport codes into an online flight distance calculator, and enter the results in a spreadsheet. After two days of watching this I volunteered to take over and spent a few nights learning enough Java to read/write CSV and make the HTTP request. Saved days of pain for the intern and was a satisfying accomplishment as a novice.
Brings up old memories reading this. I remember my first job about 20 years ago at NEC as a data entry operator. It was 8 hours each day of taking a bunch of mal-formatted CSV files from some reports the previous day and importing it into excel and drawing graphs. I was just getting into learning C at the time and ended up writing an importer (parsing and formatting in C and ODBC to write back to excel along with excel macros to draw graphs). Very hacky and ugly but got the job done. It got the 8 hour job done in about 30 minutes - most of which was detecting patterns in the input and adding rules for those, which was fun in itself.
Before you knock on "writing code that clicks things" remember that on Windows clicking things is the primary if not solitary interface to most of the system. Even the administrative interfaces are secondary to the visual interface. A lot of programs don't offer an API available to outside processes.
The most important thing about any program is correctness: does it work and do what it is supposed to do. The only thing cringe-worthy about having to script GUI interactions is that fact that the operating system and environment requires it.
For the server versions, Windows finally leaves this path, making PowerShell (that admittedly also takes some getting used to) a first class configuration system. You even can do something in the GUI and then check in a log what PowerShell commands were executed under the hood.
It was practically made for this use case, and has an active community behind it. It even has its own script editor (SciTE4AutoHotkey) and was recommended as a Kevin Kelly-approved Cool Tool (http://kk.org/cooltools/archives/4147).
this reminds me of when i started to code - find the first solution to the problem that comes to mind and hack it until it works, even if was something as abstruse as manipulating the UI. of course the outcomes were incredibly fragile and broke at the first possible moment, but in the end they still did the job they were supposed to do most of the time.
today i couldn't do that anymore; i've grown too uptight to try any of those inefficient "solutions". i guess i'd rather give up and admit defeat if there were no APIs or passable hacks (i'd say using phantom.js would be a passable hack) i could work with than solve the problems this way.
i'm usually unable to follow the advice given by the xkcd automatisation timetable described here: http://xkcd.com/1205/ "is it worth the time?" - if a dirty hack is destined to run more often than once, i just have to make it passably elegant, readable and efficient. i'm sure nine out of ten times the effort is pretty much wasted.
I thought this way before, and looked down on what I had made, but I'm slowly coming around to the idea that its more about how well the approach works and what it teaches you than about the technical details. I definitely wouldn't code it the same way today, but it worked well and taught me a lot. I wouldn't stop anyone who's in a similar position from doing the same.
I also have to wonder if you even could have used a api-approach, especially for that second db which was it's own program and was likely monkeyed together by interns over a summer.
The problem of course would have been interacting with the second DB considering the fact that it was a "separate program" as the author states. If the program wasn't offering an interface to interact with it outside of the GUI and especially if it wasn't making any network calls upon querying (although hacking network calls could have been quite difficult for a beginner) I am not sure how the process could have been done differently.
Clicking on things is the primary and often only interface that most Windows programs support. And frankly it can be much easier to script some actions with something like Java's Robot class than to dig through the cesspool that is MSDN trying to figure out how to get the same simple things done with the overly-complicated and poorly documented COM interfaces that might or might not exist.
Also, I'm not sure which is more embarrassing, having to write code to interact with the GUI or having to write VBA code.
I cringed too, but then I realized this is probably the best way to start out. It's only a 'problem' because it's a bit more glue code (but less 'figuring things out' time).
The only truly cringey part is not knowing about CSV!
that said, CSV is not without its own problems - i mean, it's not well defined. if you're down to automate a bunch of windows programs by moving around the cursor programatically and faking keyboard events, using excel over ODBC is far from cringey.
The biggest problem is not the lack of code and automation.
The biggest problem is that apparently Guyana allows the US embassy to search their criminal records system:
> Search a different database with a separate program (“DB2”) for criminal and other history
So either Guyana allows the US wholesale access to its criminal records system or the US systems gather this data more or less illegally from somewhere.
I have no idea what DB2 was. It's my understanding that every country in the world wants to know the criminal history of anyone asking for a visa for any reason (the host country may ignore that history, if it believes the crimes were politically motivated). And it's my understanding that INTERPOL allows countries to get at least some criminal records information. And there is clearly some system in place for countries to make extradition requests -- which would require some criminal history information.
So it's not clear to me that the US must have wholesale access to Guyana's criminal records system, or that it must be illegally gathering data to populate DB2.
Even without INTERPOL, I would expect countries to have treaties to share some criminal records information. If Guyana is trying to capture a criminal, clearly it's in Guyana's interest to ask countries to help prevent that criminal from fleeing.
> It's my understanding that every country in the world wants to know the criminal history of anyone asking for a visa for any reason
I'm actually fine with that. And if I ever apply for a visa, I gladly sign a waiver allowing the respective country to request the data from my country. But I am not fine with any government in the world being able to research my criminal record without authorization! Push, not pull.
> If Guyana is trying to capture a criminal, clearly it's in Guyana's interest to ask countries to help prevent that criminal from fleeing.
There's a system for this: take away the criminal's passport and don't let him out of the country. That's a job of regular Guyana border police.
edit: oh, and who guarantees that (e.g.) the US respects expiration dates? In Germany, records have to be entirely wiped after certain dates (5-20 years, http://www.gesetze-im-internet.de/bzrg/__46.html) - but I highly doubt that the US respect this and just keep the data instead.
>But I am not fine with any government in the world being able to research my criminal record without authorization!
Criminal records are a matter of public record in most countries (including the US). That means that anyone can search your criminal history, not just governments.
There may not always be a central database, but the information is out there.
Back when the rules placing criminal records in public were drafted, these records were usually kept at a courthouse, thus greatly restricting their use to those who actually traveled to the courthouse/archive and manually searched.
These days, everything can be searched online and especially copied and stored everywhere, far after expiration. And this is not a good development at all.
Yes, they used to be stored in a courthouse, but most people didn't leave the area they were born in either, so for the average person everyone you were likely to meet knew about your past.
Criminal records were always meant to be as public as possible.
I do have a huge problem with the content of criminal records, because I have a huge problem with what we consider criminal--drug offenses mostly.
I also worry a lot more about the non-criminal mistakes we make being available for anyone and for all time.
> I do have a huge problem with the content of criminal records, because I have a huge problem with what we consider criminal
While the US wants to know immigrants' criminal history, the US isn't required to care about all of the crimes that show up on the record. For instance, convictions for performing or having an abortion (say, in Brazil) probably won't result in a denied visa.
> I do have a huge problem with the content of criminal records, because I have a huge problem with what we consider criminal--drug offenses mostly.
In the US you also have lots of really bad laws about sexual offenses (which aren't real offenses by any sane standard; like teenagers sending each other nude pictures).
So much programming instruction seems designed to teach people who already understand programming how to solve problems that nonprogrammers wouldn't even understand. A tutorial that started with automating tasks like this might be more effective than all the ones that start by demonstrating how to do basic arithmetic in $LANGUAGE and go on to a detailed explanation of $LANGUAGE's object system.