Simon Rumble

Navigation

Blog

FireBug tab opening delay redux

Ben, having read my last post about FireBug, notes that you only get the delay opening a new tab if you have FireBug disabled. if it's disabled it checks a whitelist to see if it should be enabled in the new tab... should be a simple fix.

Hopefully this will be fixed soon. In the meantime, however, FireBug seems to incur no performance hit if you keep it enabled, somewhat paradoxically.

05 Dec 2007 14:14 [category: /geek] #

Howie's Firefox extension suggestion

Howie suggested FireBug as a must-have extension. While I agree it is amazing for debugging web pages, the reason I've had it uninstalled is what I'd call a bug. When you have it switched off for all pages, it still causes a very noticable lag when you open a new, blank tab. I'm not the only one either.

If this could be fixed, I'd probably keep it installed. As it is, I install it when I'm doing hardcore dev stuff, but keep it disabled most of the time.

In other Howie news, if you've seen Control, Howie lives just around the corner from where Ian and Deborah Curtis live in the film. How he justifies living in Sunny Macclesfield after living in Sydney or so long, I don't understand, but each to their own. If you haven't seen Control, go and see it. Best movie of the year.

05 Dec 2007 11:01 [category: /geek] #

Testing Google Analytics

Google Analytics is a great tool for tracking users on your site, and it's incredibly easy to set up the basic features. You just bung a bit of JavaScript on every page in your site which, if your site is sensibly designed, should only mean editing one file. You then get access to a plethora of amazing data about what your users are doing.

The more advanced features, particularly tracking ecommerce transactions, are a lot harder to implement and test other than on the live site. The help is somewhat minimal and hidden on a different page, without being stated quite explicitly, is the fact that it will drop any transactions coming from a domain other than the one the account lives in.

If it's not a subdomain of the main domain, you have to do some JavaScript link shenanigans to get GA to recognise it. This wouldn't be an uncommon problem for people using third-party shopping carts, and the solution there is quite well described.

What's less well described is how the hell you can test this thing. For example, our test server sites inside the domain of our parent company, which bears no resemblance to our live domain. Fortunately, we'd already configured our test web servers to respond to the live domain when we were testing for going live.

So what you do is edit the c:\WINDOWS\system32\drivers\etc\hosts file in Windows XP, or /etc/hosts in Unix-like systems. Put in a line like this:
192.168.1.1 www.mycompany.com.au

This overrides the name server lookup for "www.mycompany.com.au" to "192.168.1.1" and, providing the web server at that IP address has been configured to serve for that domain, you'll see your test site as if it's live and, crucially, that's what the cookie management and JavaScript in your browser will think too.

You might be behind a firewall that requires use of a proxy. Hopefully you can get to your test web server directly, otherwise you're kinda screwed. You can just turn off proxy use for the domains you're testing, leaving it in place for everything else. This is crucial since you still need to be able to get to the Google Analytics server to send the data.

Another wrinkle might be if you're using the GA IP filtering to filter out users from your own network. We do this to reduce the false data from our own staff on the site, but that means it's hard to test things. For this purpose I use a FoxyProxy rule to push hits to the analytics system via an ssh tunnel that pushes the data through my own proxy server sitting in the US. That way the data comes from a different IP range than the ones that are filtered out.

As you can see, there's quite a bit to think about when trying to test this stuff. It's all exacerbated by the fact that processing of the data occurs overnight, rather than anything close to real time. It means every time you make a change, you have to wait until the next day to see if it worked. Then when it didn't, you've got no feedback as to why, so you try again and wait another day.

Over the Xmas break, if I get the time and energy, I'm thinking of making a dropin test replacement to the Google Analytics JavaScript code. This would give you a real-time view of the data hitting the analytics server, with helpful hints on diagnosing why it's not working. We'll see if I get the time.

The other Firefox extension that I've found invaluable for testing has been Live HTTP Headers, for watching what's going to the remote servers. This handy tool is useful and quick for doing the URL decoding so it's more readable.

05 Dec 2007 10:47 [category: /geek] #