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.