It was a dark and stormy night, and one of the web developers looked up from the screen. «There’s something wrong with the Javascript on this page in IE6… I think it’s getElementsByClassName!» As the second web developer quickly did a Google search, he already knew the answer - that the other developer was right, and that he accidentally had used a function from HTML5 not supported in IE6.

This riveting story was taken from real life, and happened to me tonight. Working overtime. On a project long overdue. Kind of not the time you want to find out things like that. Yes, you can blame me for not testing in IE6, and you’re right to do it, but in my mind I was using a perfectly normal Javascript function. Oh well.

In this instance we solved it by finding the right elements with jQuery, $('.classname'), and it works even in IE6. The reason I didn’t do it like this in the first place, is that this is my first project where we use jQuery at all, and we didn’t have such fancy things back in the old days when I first started programming Javascript.

When programming Javascript, the code has a tendency to seem very brittle - like it’ll break horribly by the slightest typo. The somewhat cryptic error messages (“object expected”, anyone) in browsers is probably at fault here, and the write-browse-debug loop feels awkward compared to other programming environments.

Firebug has helped, but there’s still room for improvement. I feel I have to think and write more about this when I get the chance.

Edit: It was actually IE7, not IE6.

This week I’ve been at JavaZone 2008 (pix), the largest software development conference in Scandinavia. Two days of mostly good talks, and even some social interaction.

I was manning our booth most of the time, but I did catch a couple of talks - one about Usemon, a monitoring and analysis system for software with demands for response time and high availability, and one about making enterprise software without relational databases.

Usemon looks interesting, I will definetly check out that for debugging and troubleshooting things at work. Most performance and analysis tools analyze everything, making it fairly expensive to use in terms of processing power and it can also be difficult to find what you’re looking for. Usemon tries only to instrument the interesting classes (i.e. not java.lang.String), and also has mechanisms to drop information if the server is overloaded. It has a client running on the system that needs to be analyzed, and sends data via UDP to a central server.

The talk about enterprise software without relational databases was by a guy who works doing software for large financial institutions, where they struggle with huge XML schemas and documents, and where ORMs work poorly because the models are so huge and interconnected. His newly founded company is making a common API for storing hierarchical data - which will be a part of Spring - and a proprietary store implementing this API. Fascinating to get some insight into some of the challenges in making software for financial institutions, where even milliseconds can be the difference between a few million dollars won or lost.

Look forward to going next year, it’s a great event.