How can a programmer be happy working with manual tasks? The obvious answer is 'by automating them.' I always like to remind myself that I should delegate to the machine that which it is supposed to do: automatable, computable, or mechanical tasks.
One difficulty we face with iScala is the lack of programmatic APIs to deal with things from Administration such as User Permissions and menu items, to Functional such as receiving a purchase order (GRN). We get around these by accessing the database directly, circumventing the application altogether as we have no choice when it comes to our need to integrate with other applications and processes (think of a new modern application that needs to communicate/affect/manipulate/get a respond from a legacy application for example).
For some situations, we are able to use the database because we have access to it, we understand it at least to some extent, we have documents describing it, and we have a test environment on which we can change things in the UI and see how they reflect on the database. We have to do this, despite it being a malpractice, because we don't have proper APIs. This topic reminds me of an architectural principle called Service Oriented Architecture (SOA), which is almost always on my mind when thinking of systems.
I admit I was not very excited with my latest task of backing up iScala modules through the application. There is nothing in the SQL Server database that I can invoke to have that done (iScala application backup is dissimilar from SQL Server backup which can be automated using SQL Server Management Objects (SSMO)). At first, I felt that there is no hope to automate this task, despite my strong feelings that the task should be automated as it is clear, repetitive, and surely specifiable algorithmically for a computer to be able to do it. I was upset because automation of this kind of tasks is an integral part of my professional philosophy and perspectives, and I felt I will only be able to do this task by mundanely clicking my way through.
That's when my semi-random experiments during college came into play: I recalled that one can programmatically move the mouse cursor, simulate clicks and keyboard presses using the native Windows APIs. So I wrote an application that was able to find the iScala application window and the buttons inside of it, move the mouse to them and click them in the sequence required to create backups. Once the backup is complete, the application would log-off iScala and change the company and logon again to repeat the process of backup. All I had to do last night was to check whether it was running as expected every once in a while.
It wasn't easy and required a lot of experimentation but it was fun and well worth it because this unpleasant task will always be a constant reminder that I can make a choice: approach something negatively and do it the "normal" way, or take risk, invest time and effort, and try to do it in an innovative time saving way.
This philosophy reminds one that software is not merely a job, but a beautiful tool that empowers the person wielding it.
Although nowadays having a programmatic interface to the software is as important as having a user interface to it. Imagine a program with no user interface that allows users to perform the functions of the program? Now, the same rhetorical question applies to application programming interfaces: imagine a program with no API that allows programmers to access the functions of the programs, programmatically.