Leisure - WH Davies

What is this life if, full of care,
We have no time to stand and stare.

No time to stand beneath the boughs
And stare as long as sheep or cows.

No time to see, when woods we pass,
Where squirrels hide their nuts in grass.

No time to see, in broad daylight,
Streams full of stars, like skies at night.

No time to turn at Beauty's glance,
And watch her feet, how they can dance.

No time to wait till her mouth can
Enrich that smile her eyes began.

A poor life this if, full of care,
We have no time to stand and stare.

Useful System Messages

An somewhat not so helpful error message.

A little local admin rights and away with the error.

Client site ethics

Image by Hamed Saber via Flickr

Is it within the bounds of ethical behavior to write about the antics of the people at a client site? Is impersonalization sufficient?

Ethics cover a very wide range of behavioral patterns. Generally the normal set of modes is defined by a person's social upbringing. The set is initially imprinted by the parents or caregivers. The next layer is added by the immediate social network in which the parents run as well as the bonds formed in going through schooling. Ethics therefore evolve around the initial values imprinted as a very young age.

All well and theoretical, but not really going towards answering the question. Ultimately though it does bring to the fore that the answer is individual. It is not a question with an answer for all situations and any two people may quite readily disagree on the answer.

Impersonalization does add a level whereby the direct reference to a specific person or corporation is muddled. The indirection however is superficial as a correlation can be made through personal identifications.

From my perspective, the core answer is no - at least in the current situation. My current feeling is that the only good part at the current client would be to never go there again. Despite this, some events will have to make their way out as they're just too surreal.

Correlations

Image via Wikipedia

This article brought a few analogies to the fore.

Test automation is usually implemented in a bulk manner - more tests, faster, get coverage. What you ultimately get is a huge load of tests with a maintenance nightmare and possibly dodgy execution. Even the leaner approach of only automating what makes sense doesn't remove the underlying issue.

It is only with a smarter implementation strategy that one can achieve the purported benefits of test automation. An engine provides a stack of reusablity. Reusable components have been vouchsafed within software programming as being an ideal since the advent of the first function.

While the marketers try to spin the opposite story, test automation is effected by writing a program to test a program. Why then are the basic premises of good software design so commonly avoided in test automation?

I will continue to advocate an approach to test automation that results in a fitter test suite than a test suite bulking program.

A lesson in error trapping

Image by ViaMoi via Flickr

One would think that this is something that doesn't require much. If you don't handle errors in your code it will turn into a nightmare. Sure I do know this but today I discovered that there's still the odd lesson out there.

The situation... quite simple really. Have a call to a function that gets a value from an Excel spreadsheet using the ADO interface. If things go wrong the function returns the error as reported by ADO. So everything is just peachy. Even more so when you notice that there is a check on an error state to the function. All handled - or so it would seem.

The "where the heck is Kansas" question arose out of the fact that the call on a specific spreadsheet was always had a null value. Pointing to a different spreadsheet and a value is suddenly there again. Very surreal situation. File name changes, different values being queried, copying the values into a new file as well as changing the search key values refused to change the situation. Believing that the file itself was whacked didn't help when a copy of the content to a new workbook also returned the same lovely blank entry.

Eventually went back to the function call and added code to display the function return value. The light in the tunnel. There is an error on the query and it quite cryptically claims that there is too much data. Back in the spreadsheet and one Ctrl-End later we find that there is a white space character in column IV (the limit in Excel 2003). Few hundred deleted columns later the script is working as it should.

With a little "else" added to the function code and suddenly tracking this error would not have been such a surreal journey. The error is now being nicely reported in the execution report and this likely solves some of the frequent mysterious errors (like "Object required in appDict(...)") that pop up.

If's really can not divorce the catch all else.

Pity that VBScript doesn't have cool tools like a unit test module as well as some form of mock objects (for dealing with QTP GUI interaction results).

Getting to SWIFT

Image by ucumari via Flickr

SWIFT has been a background idea. Ultimately what is needed is a means of generating a message with known input as well as checking a received message against some expectations. After running into WIFE last year I figured that the process was imminently simplified. Time, however, can be a nasty thing.

With two projects boiling away with furious vigor, it has become time to get the basic SWIFT message validation tool written. This is not due to father time having changed his ways but both systems I'm working with showing an impending need for it.

I must say there's been an auspicious start... the OS library hadn't been touched in a while. Not much to fear though since SWIFT doesn't change all that often. False confidence on my part. After popping a sample into Eclipse all that would return was a simple class not found error.

Yay for open source in that I could pop the source into a project and try figure it out. Turns out that there was a dependency on Java 1.4. Ultimately a simple update to the Java version and the classes can no longer hide from the compiler.

So now I just need to figure out how the library works... It would probably help to get a good understanding of how SWIFT messages are put together before doing this, but the clock is ticking. Heck now that I have undone my assumption that the newlines between tags within the message fields are simply there for readability the way forward is looking almost too good to be true.

A use for spam