ronin

Dejan Bosanac over at O’Reilly points out a style of initializing singletons which I hadn’t seen before.

I think there’s 3 things worth saying about this:

1. Don’t use the Singleton pattern if you can avoid it. I should really dig up some references for this comment but I can’t be arsed.
2. Use a static initializer if you can. It avoids having another class involved and I think it reads a bit easier.
3. If you really need to have the Singleton inited on the getInstance call, then go ahead and use the on demand holder. In my experience the first call to a Singleton is the getInstance method so the static initialiser will be called at that stage anyway.

Tom Coates: Social Whitelisting with OpenID.

Scott Kveton: MyOpenID: New anti-phishing tools available

Sxipper: Sxipper is a free plug-in for Firefox that lets you log into any website with a single click

Kim Cameron: Integrating OpenID and Infocard.

Looks like there is going to be a miniseries of Neal Stepenson’s “The Diamond Age”. The book is good, as are most of Stepenson’s, and hopefully the tv adaption lives up to the same quality.

via: Chris Petrilli

Yo! Sushi is running a half price campaign, you can pick up your voucher here.

Stuff has finally redesigned, it’s about time too. Only thing is, still no sign of any syndication via RSS or Atom.

It isn’t good reading if you’re a NZ cricket fan.

This competition is all about New Zealand vs. England, it isn’t worth even worrying about beating Australia until either team is in the final.

If New Zealand can find more than one batsmen to score their runs during an innings then we have a chance, otherwise we’re going into 2007 with a disappointing result against Sri Lanka, and no result from the Tri Series.

Elliotte Rusty Harold responds to Charles Miller’s post about writing an anti-test:

That’s a recipe for disaster if I ever heard one. Five years down the line some new programmer is going to finally fix the line of code that causes the bug, and then carefully reintroduce the bug to get back to the green bar.

I have to disagree. As Charles states

Make sure you annotate it with the issue that it’s verifying. That way your continuous integration environment will let you know immediately if something’s suddenly worse than it was before.

5 years after you write the test, the lucky programmer who’s going to fix the problem gets a present, a little bit of context and knowledge about the intended behaviour. If annotated with enough context, maybe a decent text description in the assertion and some documentation around the test code, it should be clear enough what’s going on. If it doesn’t apply anymore the test can be fixed, removed, or whatever makes sense.

Keeping the Bar green all the time is impossible, and undesirable really. On your machine hovering between red and green is healthy, to me it shows I’m making progress. I also like seeing the number of tests climb. Keeping the bar green in a CI build is also impossible, but that’s why we do CI, to integrate and find the problems and in my experience if the build stays red for too long developers are less likely to try and fix the problems because “the build is always broken”.

Actually, maybe I agree with both Charles and Elliotte?