Archive for July, 2009

Building a Firefox extension

Thursday, July 2nd, 2009

Over the past couple of days I’ve been experimenting with building a Firefox toolbar to work with our upcoming Lexascope API.  As normal with these things a quick bing of the web (yeah I switched to Bing for a couple of months to see if is any better / worse that Google) pointed me in the direction of some excellent articles that really helped me get up and running, so in the tradition of the web I thought I’d share the best ones.

Tutorials

There are a few step by step guides that enable you to get up and started but not one that covers everything.  However reading these should at least get you to the position of having something that works

and my personal favourite

Reference Guides

If you don’t know XUL (and beyond existing Firefox devs, who does?)

https://developer.mozilla.org/index.php?title=En/Firefox_addons_developer_guide/Introduction_to_XUL%E2%80%94How_to_build_a_more_intuitive_UI

https://developer.mozilla.org/en/XUL_Reference

 

So hopefully those resources will help you as much as they helped me, using these I was able to get my toolbar up and running in just a few hours, going from complete newb to slightly less than compete newb.

QA, QA my kingdom for some QA

Wednesday, July 1st, 2009

As anyone who has worked with me over my career will know, QA is something that I don’t pay a massive of amount of attention to.  Sure its something that has to be done, but customer pressures have generally meant that its been an afterthought rather than something that is front and centre.

That’s not to say things went out untested, just that the testing would generally happen in one of two ways

  1. The developer would build a test harness to make sure that the code performed the way that they wanted it to.  Of course the major problem with this is that the testing would normally take place on the developers own machine, and that if you wrote the code you are naturally going to write a test harness that exercises it in the way it is supposed to be used. 
  2. Ask the rest of the company to test a forthcoming release in a sort of beta testing mode.  Of course what normally happens is that the rest of the company is busy as well and if you are lucky one or two people will give it a quick once over.

Recently this has all changed however with Carl and Paul putting some serious time into building both test frameworks and more importantly coming up with both tests for new functionality, as well as a set of regression tests.  And its worked fantastically, with the tests being able to catch several bugs and functional problems before any code went out the door, even in a beta state.  This can only be good news.

Having a concrete set of tests with associated numbers has also enabled us to give a lot more accountability to our lords and masters who sign the pay checks, which is frankly a win win all-round.  They get to see what we have been doing and we get to show how clever we have been!

So consider me a convert and bring on the tests – just so long as I don’t have to write them :)