Fair warning: I shamelessly stole this story from a colleague. Let’s call him Jimmy. He doesn’t have a web presence though, and I think it’s worth sharing.
Jimmy was working on a web application. This particular web application had a feature that only activated on a double-click. Don’t be too harsh on Jimmy; he didn’t have a choice in the matter. Sometimes, you have to do what you have to do.
Somehow, the ticket bounced back and forth between the two a few times with no suitable reproduction steps, and Jimmy was at his wit’s end. After several code re-writes and testing across both supported and unsupported browsers, Jimmy gave up and asked Sandra if he could see the problem in action. Once he found Sandra’s desk, he asked for a demonstration.
Sandra brought up the UI and found the feature in question. Jimmy was bristling with excitement, at least until he saw the problem. Sandra hovered her cursor over the button in the UI and clicked with fierce tenacity. A moment later, and no sooner, she clicked again, with equal tenacity. A wry grin must have crossed Jimmy’s face as he explained the difference to Sandra between a double-click and two clicks in succession.
If you learn nothing from my posts, learn these two lessons:
- Never put a double-click event in a web app
- Walk to the user’s desk to identify mysterious problems that only they seem to have
Now that I’ve had the opportunity to work on a continuous integration infrastructure for both Mirth Connect interfaces and a MarkLogic-powered REST API. The Mirth interface testing software was built with Perl and TAP (Test Anything Protocol). The ML REST API testing software was built on MarkLogic itself. What they both had in common is that Jenkins was used to build the environments and run the tests.
I’ve really come to appreciate how useful Jenkins can be. Jenkins can aggregate jUnit style reports out of the box, and Jenkins can give you meaningful textual and graphical representations of those reports. It will tell you how many tests failed, how many tests passed, what class and packages were being tested, and it give you this information over the course of many builds.
However, since neither CI testing software was actually built on Java, I was unable to leverage the actual jUnit testing framework. In addition, neither the Mirth Connect interfaces nor MarkLogic/Xquery have a concept of grouping code into packages and classes as a Java programmer may expect. Because of these two issues, I had to generate jUnit output programmatically. Even though I was able to start with someones stab at the jUnit XML schema, I found that Jenkins does not parse and display the jUnit output exactly as I would have expected. For the time being, it is probably easier to ignore the jUnit schema and instead listen to what I’m about to say 🙂 Read more »
A couple of weeks ago, I had the opportunity to attend MarkLogic World 2012. The overall theme of the conference was converting Big Data into Big Ideas. Big Data is a paradigm shift for many in the IT industry; briefly, Big Data saves everything, whether it’s usefulness is obvious or not, in hopes that decisions can be made on that data. In theory, the traditional data model would be unable to make informed decisions because the data set would not be large enough accurately describe super-complex issues.
Psychohistory, then, as defined by Isaac Asimov in his novel Foundation, goes something like this:
Branch of mathematics which deals with the reactions of human conglomerates to fixed social and economic stimuli; implicit in all these definitions is the assumption that the human conglomerate being dealt with is sufficiently large for valid statistical treatment.
Read more »