The first talk of the day, by Stefan Norberg, was frustrating for me as it really brought home how much we constantly re-invent the wheel with software. The talk described “domain events” and “Event Driven Architecture”. This is a centralised event system, whereby events are dispatched, stored in a message queue and then sent to all interested listeners. There is no concept of subscribing to a dispatcher, just to an event. What made it frustrating for me was that Stephan basically described something very similar to a system that I helped develop 13 years ago. Goes to show that developing something counts for nothing if you don’t give it a fancy name, publish it and talk about it at conferences. 🙂
Test-Driven Development of Asynchronous Systems
Next up was Nat Pryce with a talk about using Test Driven Development with asynchronous systems. It started well with an interesting suggestion. To use TDD on an entire system, write a failing system test, then use TDD to write unit tests and sufficient code to make those unit tests and the system test all pass. Sadly the rest of the talk was more disappointing as I didn’t like Nat’s solution.
Asynchronous systems are difficult to test as asynchronous systems by their very natural have complex – and possibly non-deterministic – timing issues. Nat’s solution was to therefore impose synchronisation on the system via the tests and to “test for success”, such that if tests get the expected result before timing out, they are deemed to have passed.
He offered good advice on what can go wrong when testing asynchronous events, such as timing causing all sorts of problems, and flicking tests that sometimes pass and sometimes fail. From my experience though, flickering tests are often due to trying to synchronise an asynchronous system. So I was not convinced by Nat’s methods, as they seemed to be geared around forcing synchronisation upon an asynchronous system. Nat insists he is imposing synchronisation upon the tests, not the system, but I remain sceptical.
Cogs in the machine: testing code embedded in an impenetrable framework
Staying on the testing track, the next talk was by Roy Osherove. The title is slightly misleading as it wasn’t so much about impenetrable systems as core systems that cannot be mocked. Roy used the example of the Silverlight framework and demonstrated that it was penetrable if one tried hard enough.
One way of testing against such frameworks is to develop a “wrapper” around the framework that adds a facade between your code and that framework. That way one can replace the framework with a mock when testing. There are though two caveats to this:
- It can be a huge task that takes a very long time to write.
- If the framework is part of the core system, it cannot be replaced.
Roy offered up an alternative that he called “excavation”. The process of excavating involves treating a method in the system as stateless and naively calling it. This would then likely cause exceptions. One then delves in to the system to figure out the dependencies and then through various hacks, bypasses those dependencies and injects default state. The process is repeated until the method can be called in a stateless fashion without problems arising. At that stage, the method can then be called as part of an integration test. Roy used the term “excavation” as he likened it to an archaeologist working down through the layers of functionality. To my mind, his technique seemed more akin to hitting the system with a sledgehammer until it stopped moving!
In an ideal world, we shouldn’t have to do any of this. To tie in with the Software Craftsmanship ideas of day 1, the development community should really be demanding that framework developers always make a mock of their framework available from day one. We should hold up those that don’t as examples of lazy sods who do not deserve the title ” Software Craftsman”. However. we instead live in the real world. As such, Roy’s approach is an interesting solution to the problem of unmockable frameworks.
Modeling Concurrency with Actors in Java – Lessons learned from Erjang
Kresten Krab Thorup kicked off the afternoon with a “Cool Stuff with Java ” talk on a version of Erlang that runs on the JVM, which he’d entitled “Erjang”.
Kresten started off by suggesting that Java was reaching the end of its life, but that there was plenty of life left in the JVM. This is something I’ve suggested before on this blog, so it was a view that sat well with me. His reasoning was that seriously parallel CPUs were coming and that Java’s threads and locks concurrency model just wasn’t up to the job. Erlang is a language designed for massive parallelism and thus is a contender for a Java replacement, or so Kresten argued. Of course this argument assumes that Oracle will not follow Microsoft’s .NET parallel extensions path and bolt better parallel support onto Java. My guess is this is a reasonable assumption though. I remain sceptical though of the idea that Erlang is the language of the future.
Kresten used the term “Actor Orientated” (AO?) programming to describe what the future might look like. In the 90s, Java dramatically transformed the lives of C programmers by offering built-in solutions to error handling and memory management. This made Java code far simpler than the equivalent C code. Now, in the 10s, Erlang’s actor model could similarly transform development practices by offering a simple way of implementing concurrent solutions. However, Erlang is not the only language to offer actors, Scala for example does so too. Kresten pointed out though that there were flaws in the Scala actor model, as it let you violate actor state encapsulation for example.
The talk was nicely wrapped up with a call to the community to develop the idea of “AO” and to develop AO-centric patterns to help push the idea along. All in all, a really good talk.
Death by accidental complexity
This was the last talk of the conference – by Ulf Wiger -and my first “red card” as this was the worst talk of the conference for me. The talk can be summarised as 3/4 hour of showing us badly designed Erlang code that used to reside in Ericsson telephone switches and then telling us they’d rewritten it to fix the mess. And that was about it. Don’t worry though, the conference didn’t end on a low as there was free beer straight after to wrap the event up! Beer for the win 🙂