Skip to content

Don't Panic! Posts

Maven 1 to Maven 2

I’ve been using Maven 1 for close on to five years now.  I’ve been meaning to upgrade to Maven 2 for pretty much all of that time but never quite got round to it. A combination of my starting work on a new project and finding some nasty bugs in Maven 1  has finally nudged me towards Maven 2.

Surprisingly, in my team of around a dozen developers, we’ve had only minimal exposure to Maven 2. Everyone has stuck loyally to the now completely obsolete and unsupported Maven 1. I think everyone hopes someone else will do the hard work first.

As we have dozens of build projects in our repo I can’t migrate them all at once. I’m just doing my project and its immediate dependencies. Unfortunately, this causes problems for the old Maven 1 projects as Maven 2 repos are not compatible with Maven 1. So during the transition period I must ensure that both old style Maven 1 projects and new style Maven 2 projects have access to their dependencies from one or other of the repos.

Resizing a virtual hard disk

No matter what size hard disk you have, sooner or later you’ll find it’s too small. This is just as true for virtual hard disks as it is for physical ones. One of the benefits of virtialization is that you can change your ‘hardware’ setup on a whim. Want an extra gigabyte of memory? No problem, just assign it in your virtual machine config. So long as your host machine has capacity and the guest O/S supports it, this is easy to do.

Frustratingly though, none of the main VM software vendors (VMWare, Microsoft Virtual PC / Server and Sun VirtualBox) offer a way to resize a disk from the standard user interface. It is possible, but it takes a little fiddling to get it to work.

Memory usage

A year or two back I was working on a web application which was expected to have moderate use – around 50 concurrent users. The product was generally getting thumbs up from our QA guys. It did everything we expected it to do. Then we had a go at testing under load.


We found that if we had only a few users hammering the system for any length of time, the memory usage became unacceptable. Simple maths showed that the problem was to do with the number of open sessions. Each session required 20-30MB of memory from the app server. This is a piddly small amount when we have a handful of test users. It went completely unnoticed against the background noise of a typical server’s memory use. However, once just a hundred sessions have been opened (not necessarily at the same time) we’re chewing gigabytes at a time.

Bugs part 3: Don’t shoot the messenger

I’ve spent the last couple of posts discussing developers’ attitudes to bug tracking. More often than not, it could be better. In this third and final post on how developers deal with bugs, I’ll discuss how we might improve our attitudes. Forgive me, but just this once I want to go all hand-wavey and go on about positive attitudes, constructive criticism and so on.

Would it come as a surprise to you if I said that developers see bugs in a negative light? Yes, when we see other people criticising our software, telling us that it’s not good enough, saying “no mate, it’s broke”, we take it as a personal insult. I can’t imagine why.

Bugs part 2: Towards perfection

There is an expectation placed on developers – and pretty much everyone else – that they must strive towards perfection. Failure is not an option. There’s a general attitude anyone who makes mistakes is not good enough. When mistakes are made, heads should roll.

There’s a nasty cycle where mistakes are ignored or at least forgotten about. First, we all assume that we are good at what we do. When mistakes (inevitably) happen, we assume therefore that they’re someone else’s fault. If the system does not behave the way the customer expects it to, we assume it was poorly specified. If a bug makes it to production, we assume that the tester failed. Even if it’s decided that the bug is our fault and our fault alone, we assume it was a one-off mistake – a bad code day or whatever. Or else assume that it’s the sort of mistake that we’d have made a year or two ago but we’re too experienced to let that sort of thing happen again. Either way, we assume it won’t happen again. Because we’re good at what we do.

The big problem is that we assume that we’re perfect. We’re not. There’s a simple test: Have you ever made a mistake? If the answer’s yes, you’re not perfect. If the answer’s no, you’re a liar. And not perfect.

Bugs part 1: Don’t mention the war

My wife – a doctor – has been looking recently at safety systems in the aviation industry and their applications to the health service. In particular, how errors are reported and followed up. Apparently, NASA’s Aviation Safety Reporting System (ASRS) is the way to go. Every industry wanting to improve safety and reduce errors looks to NASA and ASRS.

Software is usually not quite as safety critical as aviation or health but one of the key targets for a software business is quality. Even if people would not die as a result of buggy software, we usually want high quality bug free software as the long term cost is lower and so profits are higher. Yet I often find the general attitude to bugs and mistakes is all wrong. The standard attitude is:

My boss wants bug-free software. Bugs make my boss unhappy. Therefore, my boss will be happier if he doesn’t know about the bugs.

It’s slightly simplistic perhaps, but who can honestly say that they’ve discovered some obscure bug in the system and felt absolutely happy about bringing it to the attention of management or other developers? Have you never considered just conveniently forgetting all about it?

JUnit testing Hibernate and Spring

Here’s a nice recipe for unit testing Spring configured Hibernate. It allows me to neatly test my Spring configured DAOs and reuse a lot of the Hibernate Session and Transaction configuration beans from my production code. This saves having to rewrite it for my tests and also makes the tests more realistic. I’d rather test my production code rather than use mocks as far as possible.

Less is More and other cliches

We’ve recently released the latest version of our product. A relatively minor change – just a couple of months dev plus same again in QA. As we get closer to the release date, we’re less inclined to make major changes to the codebase. Unit tests or no, it’s just not appropriate to perform major refactor work in response to a bug report the week before release. So we tiptoe round the code, tweaking this and adjusting that with only one eye on how maintainable it will be in future.

For example, a few days before release I found that a few text fields on a web form were completely redundant. Whatever they wired up to has been replaced by something that can work out the value for itself. Should I have removed the text area? I was 99% sure it was safe to do so, but I must have made judgement calls like this 80 or 90 times in my career. I’m due to get one wrong soon. And the consequences would be another phase of QA, making the project late or (worse) releasing a broken product.

The result of this is that beautifully designed code is written during the dev phase, it’s carefully rationalised and refactored. Should anything be found not to hang together quite right during QA, out comes the gaffer tape.

Installing WordPress

This is post number four and I’m going off topic already. This post is a technical note on how to install WordPress on a desktop PC.

After installing WordPress on my hosting service (hosted on Easily if you’re interested) I wanted a copy on my home PC as an offline backup and to generally fiddle with. As I’m likely to zap my PC soon (Vista is dead, long live Windows 7) , I’m keeping a note of how I did this.