Composing an ambient track is a very soothing experience for me. There’s complexity, experimentation, and simplicity, and I find that my mood is sharpened, made clearer, in the writing.
This is how I’m feeling.
Audio clip: Adobe Flash Player (version 9 or above) is required to play this audio clip. Download the latest version here. You also need to have JavaScript enabled in your browser.
In this post, I’ll outline some of the web developer tools available in the major browsers: Firefox, Internet Explorer, Opera and Safari. This is a wholly subjective post, based on my experience as one of two developers on a very large AJAX application at Saron Education.
Firefox has arguably got the best web development tools available, all of which can be downloaded from the Firefox Addons site. The two which I find most useful are the Web Developer Toolbar, by Chris Pederick, and the often-copied Firebug (official website), which itself sports a variety of addons.
The web developer toolbar is useful for quickly enabling and disabling features of your site, checking CSS, emulating mobile browser rendering, and controlling Firefox more precisely. Personally, I find its most useful features are the ability to:
Download the Web Developer Toolbar
I sometimes wonder how I ever managed to develop web applications without Firebug. Firebug allows you to alter CSS styles on the fly, edit the HTML contents of the page on the fly, visually watch the DOM being changed by your scripts, debug your scripts, type and run JavaScript straight from the browser, visualise network activity, inspect XMLHttpRequests, and much much more besides. Firebug is, in my experience, the most mature, stable, and efficient of all the tools in this survey.
The features of Firebug which I find most useful are:
Until IE 8, the tools available to developers in IE were woeful at best. Fortunately, however, Microsoft has got their act together, and mimicked Firebug for version 8. The features made available in this tool include
Unfortunately, these tools are still very much in beta, and are very buggy. As I mentioned, altering element attributes and styles hardly has any effect. Also, the CSS inspection system is poorly laid out and often just plain wrong. The console is well-implemented. The entire system is definitely a step in the right direction, but it suffers from bugs and lack of innovation. Also, it seems to slow down and destabilise the entire browser.
Internet Explorer 8′s developer tools are built in; access them with the F12 key.
Opera’s developer tools, codenamed ‘Dragonfly’, sit between Firebug and IE in terms of functionality and facility. The DOM inspection and manipulation tools work really well (as well as Firebug), and are more immediately configurable, thanks to a variety of toolbar buttons. Dragonfly doesn’t have a console; rather, it uses a ‘command line’ interface. The difference is that where the console in Firebug and IE has seperate areas for input and output (what you type and what it does), the command line mixes these two together, much like a Unix shell or DOS. Personally, I prefer the console paradigm, but it’s much of a muchness.
Opera’s Dragonfly is built in; access it by going to Tools -> Advanced -> Developer tools.
As with most Apple products, the developer tools in Safari are very pretty. There is a console akin to that in Firebug and IE, and you can inspect and manipulate the DOM. Unfortunately, however, the tools are quite buggy, and often fall down. Whilst the tools are very pretty, they don’t seem to be as stable even as IE 8′s.
Safari’s web developer tools are built in; access them enabling the develop menu from the Advanced tab of the config, then choosing the appropriate menu item from the Develop menu.
Whilst Firebug is still by far the best tool available for web developers, the widespread development of tools by browser developers means that cross-browser debugging and development is becoming ever easier. Hopefully the tools will foster competition, so that feature sets and stability improve in all the tools.
You may have noticed that Windows has a rather haphazard way of applying the fonts specified in Visual Styles. That is to say, whilst a particular visual style may attempt to enforce a particular font, Windows will often ignore this in applications and dialogs.
The problem is a registry key, which enforces font substitutions in Windows. Now, most applications specify their font as MS Shell Dlg or MS Shell Dlg 2. By default, these two fonts are replaced by Microsoft Sans Serif and Tahoma, respectively. To achieve a more uniform feel across your system, all that you need to do is edit these substitutions.
To do this, run ‘regedit’ from your Start menu. Then navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontSubstitutes. You should see a list of key/value pairs on the right. Simply double-click on the entries for MS Shell Dlg and replace their contents with the font of your choice — make sure, however, that you spell it exactly right.
That’s it! The change will be in effect once you restart. Bear in mind that this is a change made to the entire Windows installation, not just your user settings.
I admit, I didn’t envisage this track going quite the way it did. 
Comments and criticisms are, as always, more than welcome.
Audio clip: Adobe Flash Player (version 9 or above) is required to play this audio clip. Download the latest version here. You also need to have JavaScript enabled in your browser.