a little madness

In an earlier post, many moons ago, I related some struggles with Ajax page updates and browser caching behaviour. Today I have had to revisit the same problem again, thanks to Firefox 3.

The good news is that this time it was very easy to spot via the “Net” tab of Firebug. I could clearly see that no request was being made when I expected an Ajax-based panel update. I could also see that the response headers on the previous request for the same panel, whilst including some Cache-Control parameters, didn’t seem to include every header I expected. A bit of searching around led me to a useful comment on a Mozilla bug report. The bug report suggests there may be some issues when specifying multiple Cache-Control headers, with a specific header ordering to fix the problem. So I updated the headers set to:

So far this update appears to work: at the very least it solves the panel update problem I was seeing. Hopefully it can save someone else wasted debugging time!

Maybe my brain just doesn’t work in a way that appreciates them, but I really don’t see the point of tag clouds. Sure, adding a cloud makes your site feel oh-so 2.0, but does it really accomplish anything? Is there some advantage over a sorted list? Do people actually use tag clouds?

I find them annoying because they:

1. Take up excess space (especially for the larger font sizes).
2. Are hard to decipher, as the text is in a variety of sizes and is thus difficult to scan.
3. Feel like a trend, followed mindlessly.

When the information is useful I would prefer it to be presented as sorted and/or coloured list of a uniform font size. I for one would be quite happy to see these useless jumbles of letters disappear!

Anyone who does web development, particularly involving a significant amount of JavaScript, knows what a boon Firebug has been. The ability to debug your code in Firefox is a huge time saver. Unfortunately, those doing web development also know that they need to support Internet Explorer. Not only does IE have a host of quirks, it also has almost no support for debugging JavaScript.

For a long time I have been relying on Microsoft Script Debugger to debug IE-specific JavaScript problems. By installing this debugger and configuring IE to allow external script debugging (by unchecking Tools > Internet Options > Advanced > Disable Script Debugging (Other)), you could trap errors in an external debugger window. The biggest gain from this was the ability to determine the exact line where the error occurred - something that could be impossible to decipher from the built-in error dialog in IE. The script debugger also provides a call stack and a rudimentary command window allowing some inspection of the program state. However, the interface is clunky at best, making navigation through the code and inspection difficult.

Now, though, I have finally stumbled upon a Better Way. For some time Microsoft have made limited “Express” versions of Visual Studio tools available for free (with registration). One such free tool is Visual Web Developer Express. Like the other Visual Studio tools, Web Developer includes a decent debugger - in this case one that understands JavaScript. The only trick is getting the Express version of Web Developer to debug an external IE process for you. Thankfully, someone has figured out how to do just that and blogged about it. Essentially, you create a dummy project in Web Developer and configure it to point at your external web application. Now when you “Debug” the project Web Developer will launch IE and any errors will be trapped by the debugger. Happy debugging!

Note for FireFox users: If, like me, FireFox is your default browser, you may also need to set IE as your default browser in Web Developer. You can do this by opening an HTML file, then going to “File > Browse With …” and setting IE to the default.