Having toyed with the ideas from Getting Things Done and not really getting much out of it, I thought I’d revisit David Allen’s ideas with a little more rigour. I’d causally read some articles, skimmed the book, downloaded the app but all I ended up with was a bunch of lists on my phone. I’d look at them every now and then but I didn’t exactly achieve the zen like effectiveness Allen talks about. This time, I thought, I’d have a proper go; practice the principles across all aspects of my life and reflect my experience in a few short articles. Here I go.

In this first post, I’ll talk a little about Allen’s ideas, summarising the first section of the book. In the second post, I reflect a little on it’s application and the changes I made to my personal approach to getting things done.

If you haven’t had the opportunity to pair much in your day job, it may seem a little unfair to be tested on the subject. More and more, people are trying to recreate working environments in order to assess candidates and that means pairing. The trouble is, pair tests are often not an accurate recreation and it takes some skill from both candidate and interviewer to get through a pair test smoothly.

This post talks a little about what to expect from a pair test and offers a few tips to surviving the process.

What’s the difference between URL Encoding and Form URL Encoding?

Apache’s HTTP client libraries (version 4.x has a very different API than 3.x) are fairly involved to configure and require a lot of boilerplate code. Making a simple HTTP GET request usually ends up with way too many lines of code. Working with HTTP should be simple, so I’ve been working on a library offering a straight forward API with sensible defaults. Typically, you’ll make HTTP requests with just one line of code.

HttpResponse response = anApacheClient().get(new URL("http://baddotrobot.com"));

If you’re using a version of JMock prior to 2.6.0 and use @RunWith(JMock.class) you may have spotted that your @Rules are actually being ignored when running JUnit tests. This could mean false positives. It’s because older versions of the JMock.class extend JUnit4ClassRunner and JUnit4ClassRunner ignores rules.

The good news is that JMock 2.6.0 and above use the newer BlockJUnit4ClassRunner and this does support rules. Bear this in mind when working with any class and the @RunWith as they may also extend the rule ignoring runner.

Scala is often described as a functional language but its as much object-oriented language as it is functional. In fact, functions in Scala are objects. It’s important to realise that Scala can be used to write programs in an imperative style as well as a functional style and to understand the context your working in. If you’re clear about the style you’re applying, you can get the most from the approach. Functional programming isn’t a panacea and to build effective systems, you’ll need to blend the approaches.

We’re very used to Java’s notion of checked exceptions. If we want to force the developer to consider exceptional behaviour then we typically throw a checked exception. The problem is that despite our best intentions, we can’t force the developer to actually deal with the exception sensibly. Java tries to help by forcing a compilation error onto the developer so they at least forced to choose a course of action. The trouble is though it’s all too tempting to swallow exceptions or just rethrow. We tend to either bury our heads in the sand or litter our code with addition noise.

Scala has taken a different approach. Scala has done away with checked exceptions; all exceptions are effectively RuntimeExceptions and so its left to the developer to decide when to handle them. This obviously leads to less noise but puts more responsibility on the developer. Scala makes it easy to avoid the issue but without a clear system wide policy for exception handling, we can still get into trouble.

In a previous post, I’ve described a general approach to understanding when and how to deal with exceptions in Scala or Java. In this post, we’ll take a quick look at Scala’s syntax around exceptions and how pattern matching is employed.

In the previous post, we looked at being more explicit about a system’s exception handling policies. By identifying the boundaries within your system, you isolate the points at which you handle exceptions.

This post takes the idea further by talking about exceptions as real objects and suggests only ever creating sub-classes of RuntimeException for your application exceptions. Once exception handling points are isolated, testing becomes more straightforward and we reduce the noise of checked exceptions. When we get it right, we should never need to assert against exception messages.

It’s not ok to handle exceptions in an ad-hoc way. Exception handling should be a system wide concern. That means catching an exception, arbitrarily logging it before rethrowing isn’t a good idea. We should be carefully considering when and how to handle exceptions. With a high level strategy, things just become easier. You focus exception handling to just a few places making it easy to test and easy to apply consistently.

In this post, we’ll take a closer look with some examples.

To make an assertion that an exception was thrown with JUnit, it’s fairly common to use the try/fail/catch idiom or the expected element of the @Test annotation. Despite being more concise than the former, there is an argument that using expected doesn’t support all the cases you may want to test. The example being to perform additional testing after the exception or testing against the actual exception message.

JUnit 4.7 introduces the next progression, a @Rule that offers the best of both worlds. This articles weighs up the pros and cons of each approach and takes a closer look at the syntax of each.