Frameworks and Way Out

Frameworks are a very big part of software today. Framworks often provide much of the architecture of a system because a framework comes with a large number of design decisions alreay made. E.g. a Grails project uses MVC and active record patterns, it runs on java infrastructure, and so on.

In this essay in design by Len Bass, three sources of initial design hypothesis for a future system are listed: Existing similar systems, frameworks, and patterns. The essay points out that existing similar systems probably provide most guidance for the new systems, frameworks a bit less guidance and patterns least guidance. This makes frameworks a more desirable source of initial design/architecture than patterns.

While I agree with this overall, I want to point out a particular caveat in this post: Frameworks should always provide a way out. E.g. a Grails project might start out being served well by active record, but at some point active record may turn out to be too constrained for a few parts of the system. It is crucial to be able to bypass the framework in those few parts while still using the framework in the rest of the system. To continue the example Grails opens the possibility to drop down to Hibernate if active record is too constrained, and Hibernate in turn opens the possibily to drop down to SQL if so needed. Not all frameworks open these ways out, which means that you have to work against and around the framework when the framework becomes too constraining. Doing so invariably results in something quite unmaintainable, because those workarounds are weird and hard to understand, and because new versions of the framework likely will invalidate the workarounds.

Lastly, in my experienc projects always run into a few of those cases where the chosen framework is too constaining. So my advice here is to remember to consider what the frameworks you conisder allows in thoses cases where you want a way out.

Divide and Accumulate with Scala Actors

In Scala we can easily do things in parallel with actors; actors are easily started up, they are cheap, and they can easily send objects to each other
.
Here I'll look at how to use actors to parallelize in situations where we need to do some sort of calculation and aggregation over a collection of objects. E.g. given a collection of RSS or ATOM feeds pull down the list recents items from each one and build the aggregated list of items from all the feeds ordered by publication time. Doing that sequentially is sort of trivial, and involves waiting for a request to each feed one at a time. It would by nice to fire all those requests in parallel, then wait for them to return thier results and build the aggregated list as the results arrive. The following diagram shows how to do that with actors:

Let the program start an actor per feed. Let each actor go do a request for current items to the feed it is in charge of, and then send that list as an immutable object to the accumulating actor. The accumulating actor will maintain the aggregated list of feed items. When a new list of items is received from one of the other actors it merges that list into its aggregated list and at the end it has the full aggregated list.
Going a step further; why not have the accumulating actor send an immutable copy of the aggregated list to e.g. the view every tiume the aggregated list has been updated. That us allows us to show the user the partial results as they arrive.

Notice that the above did not involve any explicit starting of threads, no synchronization of threads, and no locking. Those things are handled behind the scenes by the actors and their message queues. Furthermore there is only mutable state in one place; inside the accumulating actor. Everything sent from one actor to another is immutable. So we've parallelized safely and easily.

The problem we're solving here is - admittedly - fairly easy to parallelize, but nonetheless I think the solution I described is nice because it is easy to understand and to code.

Why Do I Like Spec-Style Unit Tests?

As I've written about earlier I've been spending some time lately learning Scala. A side effect has been learning and using two test frameworks I haven't used before; ScalaTest and Scala Specs. Both offer what I think of as a spec style of writting tests. That is, tests along the lines of:

"A unit under test" should {
  "be tested by specs like this" in {
     // Code  for the first actual case
  }
 
  "and like this one" in {
    // Code for the second test case
  }
}

where a string is used to tell what's under test, and strings are also used to give each test case a name. In contrast "traditional" [J|N]Unit tests use method names to give each test case a name, and either don't point out the unit under test or use a class name for that.

The spec style of testing, I find, makes a test first workflow feel more natural, and makes my red/green cycles shorter, leading to more interaction between tests and code, and to better coverage. Very nice :-). I noticed this after using ScalaTest for a while, and found the same later when I started using Specs. Somehow both these frameworks gently nudge me towards a more clean TDD workflow.

I think the reason is that the unit under test is very explicitly named and that the test cases are named with strings rather than method names. Using a strings rather than method names makes me write longer names, and makes me write names that form full sentences when combined with the unit under test and the 'should' from the 'should' method. As in the example above which reads as "A unit under test should be tested by specs like this and like this one". The full sentences turn the tests into something a bit closer to specs, or rather, for me, the full sentences turn the tests into the place where I think about what exactly I want my classes to do, which makes it natural to write them first. On the other hand the natural language of full sentences makes me a little more aware of details, and therefore makes each test smaller and more focused which is what makes my red/green cycles shorter when using the spec style.

Smaller red/green cycles and a more test first approach has the usual benefits of turning the test into a design tool that leads to low coupling and high cohesion in the code under test, of creating high test coverage, and of catching coding bugs very early on.

That's why I like the spec style approach to unit testing.