Sam Newman's site, a Consultant at ThoughtWorks

Archive for ‘April, 2005’


That’s me that is

Normally a much longer list, but right now the things that annoy me most are:

  • People who correct my punctuation. Like a 3 foot high Fox News presenter, it’s not big and it’s not clever. It’s not my fault english is so sodding inconsistent.
  • People who correct my spelling while I’m half-way through writing the sodding word. Kiss my ass, smart boy.
  • People who respond to stuff I write, but don’t let me know via email, or trackback, and provide no way of responding to their response because they don’t have comments, so I have to find out from other people (see? I’m pinging you with this post – just how hard is it?).

    This has been a public information broadcast from the angry kitten party.

When Java first arrived, the initial hype was all about “write once, run anywhere”. It’s language a mess of compromises born out of it’s heritage as a language for embedded machines and a desire to keep C++ programmers happy. Once people got over the novelty of inherently portable code, the attention then fell (initially favourably) on Applets, followed by protests against the non-portable nature of AWT. Penetration outside of the web was minor.
Continue reading…


In the world of Those Who Cut Hair, there are Barbers, and there are Stylists. Barbers tend to be cheaper, and will be fairly limited in what they do. When you turn up at a barbers you tell him exactly what you want (which he may or may not be able to do) – if you ask for something he can’t do, chances are you’ll getting a short-back and sides. Stylists are more expensive. When you go to a stylist, you can say things like “Well, I’m not quite sure” or “Something more – funky!” or “Whatever haircut David Beckham’s got this week”, and the stylist can hopefully use their skills to give you the haircut you need. What’s the difference? Apart from price, barbers are only capable of giving you want if you tell them exactly what you need. Stylists can work out what you need – and believe me it won’t always be what you’d expect.

So where am I going with this? Those of us who work for consultancies (or even freelance) have to decide whether or not we want to be the development equivalents of barbers or stylists. Do you want to be told what the problem is, even what the solution is, and go off and do it? Or do you want to spend the time working out what the problem really is, even if your clients don’t know. Being a software-stylist is harder – it’s more work, and some clients really don’t want to be told what the problem is (“I’m telling you, I want a mohawk!”), but you should end up with a better solution that is what they really need. The other good news? If your the software development equivalent of a stylist, you can charge more. At the same time, prospective clients need to make sure they aren’t hiring barbers in disguise…

Since I lost the use of the subscribe to post plugin (for reasons known only to the Perl gods) I’ve wanted to add some other way for people to stay tuned to changes made to interesting posts – especially to see if replies are made to comments they’ve left. The obvious solution was staring me in the face – RSS feeds for each post. Using phil ringnalda’s similar template, I’ve updated the template to RSS 2.0, added a full HTML version of the post itself, and using MTSimpleComments include both trackbacks and comments. So now if you see a post that interests you, you can subscribe and get updated when the post changes, or someone leaves a comment or trackback.

Anyway, here is the template – if you don’t have MTSimpleComments you’ll have to replace it with standard Movable Type tags:


    <title>: </title>

    Copyright  by the authors
    Movable Type



        <title>Trackback from <a>"></a></title>


        <title>Comment: </title>


Darren Hobbs

This is the primary reason I have mostly lost interest in tools such as Hibernate and Neo. Where the documentation says things like ‘Autogenerate your mapping layer and persist your domain objects’, I see ‘Tightly couple your code to your database’.

Which I don’t think really follows. Firstly, if you’re in the envious position of being able to have complete control over your schema, I don’t see why generating a schema from your domain objects is a problem, as long as your domain objects don’t become polluted by the underlying persistence mechanism. It’s not the tools fault if you end up with this tight coupling – it’s the fault of your architecture.
Lets look at my current project. We’re using JDO for persistence, but that’s a trivial implementational detail. Our domain objects exist in their own layer, and are completely clean POJO’s. All persistence is performed by a repository layer. Currently we’re using our JDO providers mapping tool to create our Object->Schema mapping tool – our mapping tool is also capable of generating a schema based on the mapping file.

Relational databases are hard to change. Especially once they’ve gone live. They very quickly foster an ecosystem of reports and queries, and almost always become an ad-hoc integration point for several applications, making schema changes very difficult.

There will come a time when we’ll lose control over our schema – this may happen after our first release (when we’ll have historical data that will need to be migrated) but in all likelihood we’ll fix our schema once our DBA has given it the all clear. At that point we’ll stop using the domain object to create the schema – it’s a pain, but a necessary evil. But with the right structure of your code and a decent build, I can’t see why your code ends up tightly coupled to your database.

Here is a case in point. We’ve found out that for strategic reasons we need to change over to Hibernate (personally I prefer JDO). The impact on our code? A single new implementation of our primary store (that’s one single class) – the real work is in rolling all the hibernate bindings, and even then it’s a one-time cost.


SpamLookup’s DNSBL Configuration

I was about to roll me sleeves up and get busy with mod_security this weekend with a view to further tackling my trackback spam issues, but luckily (for my Apache install if nothing else) Movable Type hacker extraordinaire Brad Choate has released SpamLookup to save me the effort. Where Jay Allen’s well-known MT Blacklist plugin uses centralized URL filters to block spam, SpamLookup concentrates instead on looking at where the trackbacks/comments come from. First among its arsenal of spam fighting techniques is the ability to talk to DNS-based blackhole lists such as the default Blitzed list and the Blog Spam Blocklist. These services publish a regularly updated list of IP addresses – in the case of blitzed and the blog spam blacklist, these IP addresses are known open relays which spammers love to use to cover their tracks.

SpamLookup also checks incoming trackbacks to make sure that the originating IP address matches the weblog the ping is supposedly coming from – it even goes so far as to allow blocking or moderation depending on how close a match there is between the IP address of the trackback and the weblog. Throw in blocking or moderation based on the number of URL’s in the comment, word lists, pass-phrases and support for TypeKey and you have a variety of powerful features.

SpamLookup - Test Form.jpg

The build-in test client

To round the whole package off, Brad has thrown in the excellent test feature. Once you’ve configured SpamLookup (although the defaults are probably good enough for most), you can use the test to see how SpamLookup reacts to a variety of trackbacks and comments. Some default test cases are provided, or you can roll your own – with the sheer number of configurations possible being able to test your individual setup is very important.

SpamLookup - UI Features.jpg

It’s spam prevention features aside, I’d still consider using SpamLookup because of a simple UI feature. When looking at either comment or trackback views, you can select all those entries which have ben moderated. After a wave of trackback spam, I can often have several moderated trackbacks (thanks to MT Approval) to remove – the ability to select all of them with a click of a button is greatly appreciated.

It was with some interest I spotted a positive mention of something called Context IoC (a new type of IoC apparently) on Dion Hinchcliffe’s Blog. The while topic really bores me right now as IoC stopped being something fancy a long time ago, and to me it’s now nothing more than “calling a proper constructor”. I investigated further as Dion normally writes very sensibly, does some very nice diagrams and has impeccable taste.

Contextual IoC is outlined in a ServerSide piece by Sony Mathew. It’s not surprising I missed it the first time round as I stopped reading the ServerSide a while back. It turned out I really wasn’t missing much. He starts off on shaky ground:

IOC seems to be at odds with the fundamental paradigm of object encapsulation. The concept of upstream propagation of dependencies is indeed a contradiction to encapsulation. Encapsulation would dictate that a caller should know nothing of its helper objects and how it functions. What the helper objects do and need is their business as long as they adhere to their interface – they can grab what they need directly whether it be looking up EJBs, database connections, queue connections or opening sockets, files etc..

He almost makes a point here, but ends up saying “Objects should interface with things with interfaces”. To those of us who create interfaces to reflect the role a concrete class has in a system, this is nothing new. Quite who this is “at odds with the fundamental paradigm of object encapsulation” I’m not quote sure.

Things then look up a bit:

The benefits of IOC are that objects become highly focused in its functionality, highly reusable, and most of all highly unit testable.

That I agree with. Then we’re off again:

The problem with exposing dependencies via constructors or Java bean properties in general is that it clutters an object and overwhelms the real functional purposes of the constructor and Java bean properties.

I agree with exposing setters purely to provide dependencies – but constructors? At this point it’s clear that Sony and I disagree on what a constructor is – apparently creating an object with the tools it needs to do its job is not what a constructor is for. At this point we’re waiting for Sony’s solution – and the solution is Contextual IoC.

Let’s look at Sony’s example of this:

public class PoolGame {

  public interface Context {
    public String getApplicationProperty(String key);
    public void draw(Point point, Drawable drawable);
    public void savePoolGame(String name,
      PoolGameState poolGameState);
    public PoolGameState findPoolGame(String name);

  public PoolGame(Context cxt) {
    this.context = cxt;


Right, so what’s happened here is that we’ve taken dependencies (in the form of method calls – the PoolGame requires and folded them into an inner interface. Question 1 – how is this different from passing in the roles as separate interfaces? It seems to me with have the need for 3 distinct roles, something along the lines of PoolRepository (for savePoolGame() and findPoolGame()), Display (for draw()) and ApplicationConfig (for getApplicationProperty()). My version of the code would be:

public class PoolGame {
  public PoolGame(
    PoolRepository rep,
    Display display,
    ApplicationConfig config) {

So Sony’s code is dependent on having implementations of four methods, my code as a dependency on a implementations of three roles in the system. Lets look at the “benefits” of this approach:

The Context interface removes the clutter of exposing dependencies via constructors or Java bean properties

Does my constructor look any more cluttered than Sony’s inner Context interface? I know my object is going to be easy to create too – how easy is it to create Sony’s? Will it look as simple as constructing my version? So I dispute that benefit. Next:

It provides better clarity by organizing an object’s dependencies into a single personalized interface unique to that class. The PoolGame.Context interface is unique to the PoolGame class.

And that’s a benefit how? It’s a simple matter to see where my roles are used in the system – with contextual IoC you have to look for Context implementations that use things like PoolRepository, which would still need to exist. You’d still need to create things that perform storage and queries of games, things that display the games, or access application properties. But with contextual IoC you also have to create context objects to wrap them up.

Yes, you heard it here first folks, but Sun has finally woken up and decided to include a micro IoC container in the next version of Java! Using a special keyword, the container lets you create an object that can be used straight away, by passing all dependencies in.
Continue reading…

I like unchecked exceptions. Here’s why – I like to know something went wrong without having to explicitly handle every possible error. I like checked exceptions. Here’s why – when I decide that an error should be handled in my system, I want to force it to be handled as a defensive measure. We can argue back and forth about the merits of checked exceptions – Java chose it’s path, .NET another, some people don’t like exceptions at all – but that is a discussion for another place. What I want to look at is how these two types of exception get used on our current project.

As I mentioned before, we’re using unchecked exceptions for error conditions we cannot handle, and checked exceptions we can handle. Unchecked exceptions are allowed to bubble up to the top level, where they are logged.

Checked exceptions are never logged and rethrown – if we had to rethrow the exception because we cannot properly handle it, it means it really should be unchecked, and we should allow the top level to catch and log it. For example we don’t have examples of the following code in our code base:


public void doSomething() {

try { doSomeOtherMethod(); } catch (SomeCheckedException e) { log(e); throw new UncheckedException(e); } }

Instead, if we can’t handle doSomeOtherMethod’s exception, it should be unchecked and we should rely on the top-level to catch and log it:


public void doSomething() {

... doSomeOtherMethod(); .. }

If we can handle the error generated by doSomeOtherMethod, then the code should be more clearly written as:


public void doSomething() {

try { doSomeOtherMethod(); } catch (SomeCheckedException e) { log("Error occurred, but we'll handle it<a href="" <5>>, e); handleErrorState(e); } }

We’ve handled it immediately, in place, and haven’t propagated any exceptions.

There are of course exceptions to this rule (no pun intended). In the case of third party API’s, we may find that the exceptions they throw don’t match the context in which we are using them. Our JMS-based system assumes messages will be Java objects (de)serialized using XStream and sent as XML. The XStream code is pretty simple:


XStream xstream = new XStream(); Object anObject = xstream.fromXML(xmlToDeserialize);

XStream throws unchecked exceptions only – not that you could work that out from the Javadoc (I’m all in favour of lightly documented code, but external API’s should really document the unchecked exceptions they can explicitly throw). For us, we want to be able to handle the fact we gave our deserializer some dodgy XML – which implies we need a checked exception. To handle this, we explicitly catch the StreamException, but not Throwable:


XStream xstream = new XStream(); try {

Object anObject = xstream.fromXML(xmlToDeserialize); } catch(StreamException e) { throw new DeserializerException(e); }

The reason we don’t catch all exceptions, is that we are happy we can handle the outcome if a StreamException can be thrown – we understand that scenario. If XStream started throwing NullPointerException’s however, it’s a brand new scenario we haven’t planned for – we have to assume we can’t handle that one. Put another way, what if we were using a new version of the XStream library that had a bug in it? By assuming any unchecked exception thrown by XStream was down to bad XML, we could end up throwing away lots of valid data.

and Catching uncaught exceptions )

Ian Griffiths has a similar take on exception handling, with more emphasis on application tiers/layers. Also note that I don’t claim that I as a person (or the development team as a whole) came up with this approach – as Ian’s post shows there is bound to be plenty of prior art out there 🙂

We’re currently working on a JMS-drived application, which is being used as an integration point between several systems. We’ve defined a standard exception handling process – checked exceptions for those errors that can be handled by the system, unchecked exceptions for those errors that cannot be handled. The unchecked exceptions are all allowed to bubble up, where they are caught at the top level (and the top level only).

Given that the entire system is driven by received messages, the “top” of our application is our MessageListener, which before today looked a little like this:


public void onMessage(Message m) {

try { process(m); } catch (Throwable t) { log(t); } }

As per our exception handling strategy, this is the only place where unchecked exceptions are caught. Today we started implementing the various sad-path scenarios, the first of which was “what happens if processing the message fails?”. In our case this scenario translates as process throwing an unchecked exception. This being our first scenario, we’ve assumed that any runtime exception is a transient error – possibly down to one of the systems we’re integrating with being down. As such we decided that we’ll want to attempt to process the message again.

The simplest way to re-try a message is to use a transactional JMS session and rollback the session, as this returns the message back on to the topic/queue – we’d then specify a maximum number of times a message can be retried. It also follows that when using a transactional session you need to commit the session if the message was successfully processed.

Adding the code to commit a transaction is straightforward – but we do have to expose the session inside the listener (we’re using a topic here for monitoring purposes):


public OurMessageListener(TopicSession topicSession) {

this.topicSession = topicSession; }

public void onMessage(Message m) {

try { process(m); //if we get here, we've processed the message topicSession.commit(); } catch (Throwable t) { log(t); } }

Adding the code to roll a session back is a bit more work:


public void onMessage(Message m) {

try { process(m); topicSession.commit(); } catch (Throwable t) { log(t); topicSession.rollback(); } }

Great so far, but our next “sad-path” scenario is going to give us a little more trouble. What if we receive a message that we can’t translate into something meaningful? We don’t want to re-try the message, as we know we’re not going to be able to handle it later – the message is just plain bad. To handle this case, we separated out the message processing and had it throw a checked exception:


public void onMessage(Message m) {

try { Object command = new MessageHandler(m); process(command); topicSession.commit(); } catch (MessageInvalidException e) { log(t); //we don't want to retry the message topicSession.commit(); } catch (Throwable t) { log(t); topicSession.rollback(); } }

This works as far as it goes, but up to this point I’ve been oversimplifying things a little. We’d abstracted our use of JMS behind two simple methods, which so far had been good enough for use in all our tests, and both client and server code:


public interface MessagingFacade {

void subscribe(MessageListener listener); void publish(String xmlToSend); }

The subscribe call hides all the JMS plumbing – including the creation of the session itself. If we want to pass our session into the message listener, we need to expose it from the MessagingFacade or create it ourself – either way we kind of defeat the object of the facade. If we don’t use the facade, we end up complicating much of our code.

The solution we came up with was to create a TransactionalMessagingListener like so:


public class TransactionalMessagingListener

implements MessageListener { public TransactionalMessagingListener( TopicSession topicSession, MessageListener delegate) { ... } public void onMessage(Message m) { try { delegate.onMessage(m) topicSession.commit(); } catch (Throwable t) { log(t); topicSession.rollback(); }


Our underlying message listener is no longer the top of our system so doesn’t need to log throwable. Nor does it need to worry about the TopicSession, so becomes much simpler – we catch and log the checked exception related to message processing and let any unchecked exceptions bubble up to the TransactionalMessagingListener:


public void onMessage(Message m) {

try { Object command = new MessageHandler(m); process(command); } catch (MessageInvalidException e) { log(t); } }

And finally we change our MessagingFacade a little, making the subscribe method more specific by calling it subscribeWithTransaction, and wrapping the listener with our new TransactionalMessageListener:


public void subscribeWithTransaction(

MessageListener listener) { ... TransactionalMessageListener txnListener = new TransactionalMessageListener( topicSession, listener ); ... }

And there we have it. All the code is simple and testable – and not a dynamic proxy in sight (take that AOP nut-cases!). I still can’t help thinking there was a simpler way of handling this though…