A Brand Name ||Official Url :: Software UI Designer| Contents Designer | OS | W€B | Server | Programming | Computing Technology ::




Automating Software systems reminds me of teaching a kid to ride a bicycle. A hands – on phase, in which you directly control the process, segues into a hands – off phase as the kid, having internalized the skill, asserts control. During that segue, however, there is a complex negotiation. Control is traded back and forth in varying degrees, governed by a sensitive two-way feedback mechanism.

Web software is easy to automate because there’s often a one – to – one correspondence between a hands – on action — “download transactions for these dates” — and its hands – off equivalent: the scriptable URL that expresses that action. This, for me, is the supreme benefit of the Web’s REST (Representational State Transfer) model, and the reason why I consider myself to have been a user of Web services since well before the advent of SOAP. 

On the other hand, GUI Software, doesn’t naturally display this one – to – one correspondence between actions and statements that describe actions. Yet, it’s still achievable or realizable. Using the macro – recording features of Microsoft Office I can, for example, convert a hands – on action — “build up the lines for each data series in the chart” — into a hands-off equivalent: the VB code that expresses that action. 

Either way, what’s missing is the sensitive feedback. To automate a task I turn on the macro recorder, self – consciously perform the task, analyze it, fiddle around with the script and then package it for reuse. So long as the context remains the same, the script will continue to work. Of course, the context never does remain the same, and I’ll end up adjusting the data sources read by my account exporter and tweaking the charts created by my log visualizer. 

It only takes a light touch to get the kid on the bicycle to sense and react to my cues, but I have to clobber my software to make it pay attention. Getting applications and services to share a common message bus should help. Easier said than done.




In a multiprogramming environment, it is not unusual for several programs to require the same I/O device. For example, two or more programs may be competing for the printer. Rather than hold up the processing of a program by waiting for the printer to become available, both programs are execute & the printer output for one is temporarily loaded to magnetic disk. As the printer becomes available, the output is called from magnetic disk & printed. This process is Spooling.