One of the interesting things about web development is the number of different layers involved. On a low-down technical level, there are bits clogging the tubes, higher up you have TCP/IP then HTTP. A little further up still and you have the HTML of the page and eventually, on the top, there's what it looks like when it arrives on the user's screen. A lot of debugging can be done at the source code level but there is a level between that and the way it looks - the Document Object Model (DOM). This is web page as it appears in the 'mind of the browser' and some of the most useful debugging tools allow you to look directly at it.

All the main browser platforms have tools either built-in or available as easy-to-install add-ons which allow you to play with the DOM, add elements to it, take them away, change behaviours or styles on-the-fly and generally feel like a brain surgeon sitting with an electrode in one hand and a nice, squishy brain in the other. Playing with your pages at this level is an extremely useful way to get a good feel for the structure of a page and how the browser 'thinks'.

Some of these DOM analysis tools allow access to another behind-the-scenes level of the process - network traffic. Every file - HTML, JavaScript, image, CSS, XML, etc - starts at the server at one end and finishes at the browser. Using a network analysis tool is like standing at the front door of a party watching everyone come in. You can see where they came from and what they looked like when they arrived so that if they look different later on, you can tell they've had a few too many trips to the punch bowl. Or something. I think the analogy went a bit wrong somewhere. You know what I mean.

There's a good in-depth but understandable article of how browsers actually work on the HTML5 Rocks site.

Last year, I had an idea for a Web Development Podcast Breakfast Show. The idea was that I'd get up early-ish in the morning GMT, catch up on the overnight tech news and record a short, 15-minute-or-so podcast. By the time I had tidied it and uploaded, it'd still be early for the US so listeners over there would be able to listen to it over breakfast. There might even be a tie-in app which would automatically play it as an alarm clock. It was a great idea.

The only downside was that recording, editing and uploading a podcast daily is a heck of a lot of work and requires a serious commitment. I managed to do an offline dry run of it for a week before I woke up, turned over and went back to sleep. It turns out the only downside is a major one.

Bearing that in mind, I have a lot of respect for the guys that run The Forrst Podcast, Mike Evans and Kenneth Love. True, they don't always manage to make the four-episodes-a-week they aim for but they do record more often than not. At the time of writing this, they've just publish episode 115 having been going for about 8 months.

Last week, I got in touch with them and mentioned that if they ever wanted a guest presenter they should give me a shout. Being the nice fellas they are, less than 24 hours later, I was recording with them. They actually would have had me on the same day I got in touch but I was balancing a drooling, sleeping, slightly sickly Oskar on me at the time and he has a tendency to gunk up the keys if I'm too close to the computer.

Long story short, if you're interested in tech, design and development news on a more-or-less daily-ish basis, I recommend subscribing to the Forrst Podcast. And, of course, if you're looking for a sample to find out what it's like, I can only recommend Episode 113 featuring a guest presenter who, hopefully, will be allowed back some day...