a little madness

A man needs a little madness, or else he never dares cut the rope and be free -Nikos Kazantzakis


Archive for June, 2008

Zutubi @ CITCON Asia-Pacific 2008

Just a quick note to mention that Daniel will be carrying the torch for Zutubi at CITCON Asia-Pacific 2008 in Melbourne this weekend. After enjoying the event last year we signed up to sponsor this time around. Catch up with Daniel and ask him about Pulse 2.0 beta!

Sadly I won’t make it, on account of being on the other side of the planet…

Tag Clouds: Why?

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!

Easier Stubbing With Mockito

Ever need to stub just a method or two of some interface to nicely isolate a unit to test? In the past I have used classic mock object libraries to help, but these suffered from a few problems:

  1. The use of strings to specify method names to stub, which breaks refactoring.
  2. Awkward syntax to specify parameter values to match.
  3. Compulsory verification of the order and number of calls to the stub.

Some time ago EasyMock came along and solved the first two problems. By using a new record-replay interface for defining expected calls, EasyMock tests were both more intuitive and more maintainable. However the third problem remained: sometimes I just want to stub the methods, and not verify that they are called in any specific order or number of times. Some contraints can be relaxed with EasyMock but it always seemed a pain to do extra work when I just wanted the library to do less!

Well, last week I discovered Mockito, a more recent library inspired in part by EasyMock. The difference with Mockito is that stubbing and verification are separated. Instead of recording expectations, you:

  1. Stub the methods of interest.
  2. Run your test.
  3. Selectively verify the calls to your stub as you choose.

This separation works brilliantly when you don’t want to verify everything by default. When the test is unconcerned with exactly how the stub is called, there is no need to verify at all.

You can read more about how Mockito came about on the author’s blog. I highly recommend checking it out!

Debugging JavaScript in Internet Explorer

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.