What happened next was not a shining recommendation of the airline. The pilot explained that there was a warning indication on one of the engines. We were kept on the plane another 2 hours while they worked out if they could make repairs. The air conditioning wasn’t working, and it was getting extremely hot on the plane. They finally decided the repairs could not be completed, and we were told that we’d have to stay the night in a hotel in Bangkok. Note that this is a city that is currently having violent clashes between anti-government protesters and the police. Tourism advice centres recommend to avoid this city, and now I’m being forced to stay here.

In the end we were sent back to the terminal (this was about 3am). We where herded through Immigration (they had to organise a special visa for us), and sent on a bus to one hotel, but we actually ended up at a completely different hotel (apparently the first hotel couldn’t fit us all in). They gave us food vouchers, and that was it. It was 5am, I was stuck in a strange city, with no idea of when I was going to be able to get home, and no way of contacting anyone in the airline to ask questions, and realising that I’d left my laptop on the plane. This was on top of the stress of being exiled from London for the previous 11 days, and desperate to get back home. It was one of the worse days in my life, and I’m afraid I didn’t react very well to the situation.

I pestered the hotel staff for information, but they weren’t really able to help at all. It was finally around 10am that I found a letter from BA sitting on the counter in the lobby, which said that the flight was rescheduled for 11pm later that day. It was a relief to finally have some concrete information, and I was finally able to relax slightly.

At 3pm the BA airport manager came to the hotel to talk to us all. He explained that the problem was due to the fuel injection monitoring system on engine 4, and a part need to be replaced, which was being flown in from Hong Kong. At this point I realised that I might not event get home that day, which made me more upset. When questioned, the manager said that there was a 30% chance that the repairs would not be complete. However, they would still have to assume everything would be ready, and get us through check in, emigration and security to ensure we could hit the take off window. It was a lively meeting: there were a lot of people in the same situation as me, and this was the first airline representative that anyone had actually met face-to-face through the entire SNAFU.

Suffice to say that the plane actually did take off, with much cheers from everyone on board (and my lost laptop was returned!). However, there was one more insult to injury: when we (finally!) landed in Heathrow, our baggage got stuck for about 90 minutes. No one had thought to organise baggage handlers and a carousel to return our luggage to us, on top of which there were two BA10 flights landed within minutes of each other (our delayed flight, and the next day’s flight), so there was a lot of confusion about where to go. Eventually, we had about 300 people crowding 10 deep about the smallest carousel in the airport, while next to us the biggest carousel was empty.

Anyway, I’m home now. I now have a fun letter to write to BA customer relations.

The End.

I’ve been helping out with interviewing candidates for a senior developer/technical lead/technical architect role at my current client. To my dismay, there is a very consistent problem across all the canditates I’ve met: they all like the Singleton pattern. The converstation usually runs along these lines:

Me: Can you name any design patterns?

Candiate: Singleton
(they will usually name a few more patterns, but Singleton is almost always the first one named)

Me: Can you tell me about the pros and cons of Singleton?

Candidate: They’re really useful, I use them all the time! They ensure that you only have a single instance of an object at any one time. Also, you don’t need to pass references to them, because they can be accessed directly.

Me: OK, are there any problems with the use of singletons?

Candidate: Umm… you can sometimes get multiple instances if you use multiple JVMs.

I’m starting to use this as a weeder question in interviews now. I don’t care if your resume says you have 8 years of experience in enterprise Java. If you’ve got that much experience, I’m hoping you’ve heard (or discovered yourself) that Singleton make code brittle and harder to maintain. I don’t mind if you use Singletons on rare occasions (I do it myself sometimes), but you really need to be fully aware of the problems that they cause.

You can view my previous post for a list of links with more details, but in summary, some of the problems are:

• You lose control over memory management. It’s basically a resource leak.
• It promotes tight coupling. Need an implementation? Go to the singleton over there! However, by hard coding the singleton class, it makes it harder to mock, stub out or otherwise change.
• It hides dependencies. It is harder to spot from the public methods of a class that it makes use of a singleton service.
• By mixing the responsiblities of providing a service, and managing the object lifetime (badly), a singleton violates the Single Responsibility Principle. If you only want a single instance of a class, create one at the start of the program and pass it objects that need it. If you use something like Spring, you can even declare in configuration that an object is a singleton. No need to hard code that policy in code!
• A Singleton in a multithreaded environment can be tricky. Make sure that you handle all the edge cases!
• As Stevie says, the Singleton “pattern” encourages you to forget everything you know about OO design, since OO is hard, and procedural is easy.

There are more problems, but that’s a good start.

Short answer: No

Slightly longer answer: Not yet.

Long answer: As a matter of policy, after Ant 1.8 is released, I will avoid making use of any 1.8 specific features for a relatively long period. I will definitely make sure that the ASL is fully compatible with Ant 1.8, but it will still be fully compatible with Ant 1.7.

This is because the ASL is intended to be used as an add-on library to an existing ant infrastructure. However, in my experience many companies and IDEs are quite conservative in upgrading their Ant installations. Probably in a year or two after Ant 1.8 is released, I might feel comfortable in adding dependencies on the latest features (probably keeping a 1.7 compatible branch of the ASL available for a longer time). By that time I expect that Ant 1.8 will have made inroads to corporate build installations and IDEs. However, I’ve worked in places where Ant 1.7 (now 3 years old!) is still under consideration. If history is anything to judge, there will be a long period before Ant 1.8 makes it into some development shops.

I would regard this as probably the major difference in philosophy between ASL and EasyAnt:

• EasyAnt is a replacement for Ant. It extends the internals of Ant to add non-standard features (e.g. “phases”). It is invoked by calling a completely different front end script. It contains an embedded and modified version of Ant, which must be installed separately. This gives them the freedom to make full use of new features, but it means a full switchover is required.
• ASL is less ambitious (it’s just a library), but I think it makes it easier to accept in more conservative organisations that are happy with Ant, but are looking for a way to control build script complexity. For this reason, the ASL must be more conservative, too (though I might end up having two versions of the ASL, one for Ant 1.7 and another for Ant 1.8)

During the session proposals, Ivan Moore originally suggested a talk on better builds for Java programs. There were later proposals for sessions regarding improvements to Maven, so I proposed my own session “Better Ant Builds” to differentiate it from the Maven sessions.

My main goal was to promote by own contribution to this area: the Ant Script Library. JTF knew about this, and asked some leading questions when I proposed the talk about my library, which I thought was funny. I thought it would have been a bit too cheeky to give a great big marketing pitch, but then again I’m not the best marketer. Thanks for the push, Jeff!

Despite there being no projector available, I was able to talk a fair bit about the ASL, along with some of it’s background and design. People seemed interested, which I’m taking as a good sign. I won’t go into details, the website already has everything I discussed.

Jeff also pointed out the Ant Master Build Scripts, which at a glance seems to be a very similar project to the ASL. Looking at them, I’m pretty impressed. The author of those scripts presented a session at JavaOne called “Object Oriented Ant Scripts for the Enterprise“, which I think nails the leading design principles for reusable Ant scripts. I’d say the the master build scripts have a higher emphasis on J2EE projects, which the ASL leans more to building Java libraries, applications and static analysis. Plenty of room for both projects to grow!

The main question I had for the group was this: “How do you test an Ant script”? Historically, this has not been a problem. You wrote a script for a specific project. You ran the script, and it either worked or it didn’t. However, the Ant Script Library doesn’t have it’s own project – it is reused to build other projects. From my point of view, I really want to be able to set up an “integration test”. The answer is pretty obvious: set up a real project that you can use to run the ant script against. After running the script, you should be able to assert that artifacts are created in the expected locations. Duh! (in hindsight, anyway)

One more good tip: GitHub is a good place to set up an open source project. Another alternative might be Google Code. Currently, I’m running ASL from my own Subversion server. I’m thinking about moving to a location that can handle proper project infrastructure (version control, wiki, mailing lists, etc). Personally, I really like subversion, and I think it’s a pretty nice way to integrate ASL with your own project using svn:externals (assuming you’re using Subversion, too). Google Code uses Subversion, but GitHub uses another version control system I can’t remember (oh, wait: Git). Food for thought; I’ll think about that one for a bit.

For more details of the session, there is a write up on the wiki.

Update: The Build Doctor was actually taking good notes (as opposed to my vague recollection from 2 days later), and has a lot more detail in his own blog post on the discussion.

1. The conference is run in a open space format. This virtually guarantees that the most interesting and important subjects are represented
2. The conference is free to attend, and runs over the weekend. This has the affect that people who attend are extremely engaged with the topic at hand. Pretty much everyone who attends contributes to each discussion. There are not really any people there just to make sure that training budget is used.

A huge thanks to Jeff and PJ for starting this conference, and developing a great community around continuous integration and testing.

There were 5 sessions during the day. I’ll go into more detail about specific sessions in later posts.

There are quite a number of small enhancements throughout the library, and I’ve been filling in missing documentation, too. Here’s a summary of the major changes between version 1.0.2 and 1.1.0:

• Added new release module asl-release.xml.
• Added application package module asl-java-package.xml.
• Updated documentation for reports module
• New Java static analysis reports:
  • Checkstyle report
  • FindBugs report
  • Copy/paste detection report
• Added new SCM modules:
  • Subversion module
  • Perforce module
• New introductory tutorial
• Enhancements to the Ivy tasks
• Link generated JavaDoc to JRE JavaDoc

Please go to the download page if you want to try it out.

There was much more to the discussion, and I suggest you go to the horses mouth to get a proper view of what BDD involves.