There are libraries, frameworks, languages and runtime environments that seek to shield software developers from having to understand concurrency–or at least are said to do so. In my experience, this doesn’t work.
I’m all for making developers’ lives easier and sparing users the effects of concurrency-related implementation errors. But tool support gets us only so far: we might succeed in making concurrency-related concerns invisible to developers, but they still need to understand concurrency issues on a conceptual level–maybe doubly so if they’re invisible in code. Failing that, we likely end up with beautifully looking code that blows up in amazing ways at runtime.
Been there, done that, yet another t-shirt is being printed as we speak.
Fred Wilson‘s video of the week was “Simon Singh on Confirmation Bias“. I learnt about cognitive biases in formal education, read and heard about them on different occasions, and certainly experienced my share of them the hard way. I even knew about the specific example used by Simon Singh.
Despite all of this I was completely floored by the powerful experience delivered in this video…enough to make a hard man humble…
But what are practical implications of this? Say, for the next time we analyse anomalies in an information system? Or about the production problem we analysed last Friday, and the consequences we drew from that analysis?
Better stay away from that tool shed…
A colleague introduced me to Nightwatch.js which is described on its website as follows:
Nightwatch.js is an easy to use Node.js based End-to-End (E2E) testing solution for browser based apps and websites. It uses the powerful Selenium WebDriver API to perform commands and assertions on DOM elements.
And it seems to do what it says on the tin in a refreshingly simple way. We took Nightwatch.js for a spin on an e-commerce site and where amazed how quickly we achieved some promising initial results.
I’m sure there are other, perhaps more sophisticated, test solutions that can do all sorts of interesting things, but I think Nightwatch.js might be very useful in quickly building a safety net of automated tests for a new website being built or for an older one with insufficient test coverage.
I’m looking forward to spending more time with this tool and I’d be interested in hearing about others’ experiences with it.
Just so that I said it explicitly: I haven’t yet used Nightwatch.js in anger or for a longer period of time, so please read the above in this context.