if I had a lot more time I think I might write a book on my ideas about "adversarial automation".
The idea that the point of computers is to help the humans do their job faster and easier, and sometimes the computer or the software on it is the enemy in that battle.
because I see a lot of people approaching automation from this attitude of "software/sites should have APIs so that users can write software to automate it!"
and while that's not wrong, exactly, it's also not the attitude I think makes the most sense, you know?
We do not ask for access. We don't need to get permission to be able to automate our tasks.
There is always API 0: acting like a human/browser/user.
The first API is "fuck you I'm doing it anyway". Any additional API the program provides is merely a helpful shortcut
like, if your API doesn't provide me a follow_user() call, but the user can follow anyone by clicking one link?
Your lack of a follow_user() call is not going to stop me. I'm just going to click the link, automatically.
Having an API 1.0 doesn't mean API 0 goes away.
my point is that every program, every website, DOES expose an API, you just need to know how to best use that API.
That API being "the access they provide for humans"
I think of this as a short term vs long term thinking sort of problem. Like, a lot of programmers are stuck in the "should" part of thinking about programs and sites.
Yes, the program SHOULD be open source, so you can just fix the UI. Yes, the website SHOULD have an extensive API so you can easily automate it.
I agree with all that!
but... it doesn't.
by all means, try to switch to open source alternatives or get them to fix it or add an API.
But at the end of the day that's asking "the enemy" to do something for you, and they are under no obligation to listen to you.
(They may not even exist anymore, given that a lot of the times when I've used this sort of Adversarial Automation it's been focused on software from decades ago)
But the fact is, often times people have jobs where they aren't self-employed and have to work for other people, and those other people can be like "you need to use FooBaz 2007 for this job".
Would it be easier to automate if you were using OpenBaz? Certainly! But your boss can still tell you "no, we're not switching to OpenBaz, we need to use FooBaz 2007"
@foone there is a reason i like "automate the boring things" book and recommend it widely
And why AHK is such a massively installed piece of software
@Di4na @foone I wrote some AHK to start an application, click a few buttons to get to an "open file" dialog, tab over to the correct field, type in the file name, click the "Load" button, click a few more times to get back to the main screen, and click "Run", then gracefully closing the application.
Someone wrapped completely usable Fortran code with a VB6 UI and didn't provide a way of running the original code or running cases in bulk. (They cant rebuild their GUI now so I'm not sure what that means for NQA-1 compliance - this is sold as qualified safety-related code...) Uncertainty quantification takes at least 93 runs to get the statistics we need. There are around 20-30 sample problems used as installation/acceptance tests so have fun testing that the code still works after major OS patches or installing it on new hardware.
Nuclear-grade jank, but AHK solves a very important problem.
@arclight @Di4na @foone this is so cursed that it's genius again!
Content warning: cartoon violence against software
Alice Averlong🏳️⚧️
Thomas Depierre
arclight
Kevin Karhan 