Dave McDermid

A few months ago, maybe around November time last year when ASP.NET MVC 2 was being previewed, I was looking for excuses to build something to take advantage of as many new features as possible. Building a test site gets very dull very quickly, it just ain’t the same as a real project with real world problems. So I took the current site I was working on and decided to implement a small part of it in MVC. I figured it might be interesting, and had this crazy idea that I could one day convince everyone we should move the whole site.

The benefits of such a migration to a developer are clear, but I’m not naive. The site in question is our flagship e-commerce site built on tried-and-proven classic ASP (VBScript) technology, with huge amounts of legacy code, multiple franchise systems, admin systems, and large numbers of paying customers. If it ain’t broke, there’s no chance we’ll be spending months on a risky rewrite. So I knew I had to be cunning.

My goal was simple. If I could get a small part of the front-end site to run under MVC, and show significant benefit to our client, it might just happen. The bait? Performance. One of the big benefits of moving from a scripting language to a modern framework is the tools available for various levels of caching. The other main drive was to move from using several 3rd party tools (such as Java and ISAPI ReWrite) to a common language and framework (C#.NET). This would make site maintenance less of a headache for everyone.

Over the course of a few lunchtimes, evenings and Saturday mornings I threw together a test site. A few demos and a series comparison stats later and we had a proposal.

Over the course of a series of blog posts, I’ll be outlining the various challenges associated with this project and how we tackle them. This will include advanced and customised routing, caching, best practices and running new code side-by-side with legacy code. Enjoy.

Christmas eve. Work was off to a slow start, hindered first by the office Wii, then by table football, and it was only 9.30am. While the rest of the company was at home winding down and preparing for Christmas, Craig & I decided to spend our last few hours on a side project, an Adobe AIR app. We’re the life and soul of Headscape, there’s no doubt.

Although I’d delved into the world of AIR before, I hadn’t really had a proper reason to create something. Our idea was simple, a site watcher. All it had to do was fire off requests to various sites and check the response code. Easy. We could build this with HTML and Javascript no problem. Throw in JQuery and you’re laughing.

The great thing about writing for AIr is that you’re coding for one rendering engine, and it’s webkit. This means writing webkit specific CSS rules completely guilt free. Rounded corners and RGBA can make your design pretty without many images. JQuery’s AJAX library is fantastic, it takes the pain out of requests and helps the code stay clean and readable. Within an hour we had a simple app running.

So we kept going. Using a plugin for JQuery the list became sortable, and the list of sites to watch was imported from an XML file. We created a private twitter account to keep a history of changes, and allow notifications via any standard twitter client. We also added a notification window so the app could be run in the background.

The experience was quite enjoyable, and relatively pain free. The only minor annoyances are having to develop CSS / JS without Firebug, but we managed. Aptana studio made for a competent IDE, and it’s code assistance is handy. Would definitely recommend giving it a whirl if you’re at all interested.

The AIR app is now available to download form Boagworld.com: Download site watcher AIR application

Not original, but here are 5 short stories revolving around my iPhone. This isn’t meant as an iPhone glorifying article, but a collection of examples illustrating the cleverness of such devices.

I was up in London catching up with friends and enjoying the Great British Beer Festival, which was good fun. Happened upon Facebook, and started chatting to a friend I’d met over the summer, while climbing Kilimanjaro. Ended up going for sushi together the next day, had a marvellous time. Funny how things turn out.

I was at a friends house party, things were still warming up, and the guy with the tunes hadn’t turned up. Instead of faffing with laptops and playlists, we just fired up the Last.fm app, picked an artist and started a radio station. Not high quality, but plenty good enough and dead easy.

As server admin at Headscape, it’s sometimes my unfortunate responsibility to tend to a poorly server out of hours, particularly if it’s a production box. Often, a system restart is all that’s required, but this means firing up a remote desktop connection. Handily, I can VPN to work and remote onto a box, even over 3G. VPN on the iPhone is surprisingly easy.

Recently while in Brighton, we decided on going to the cinema. Flixter movies does an excellent job at finding cinema times of nearby cinemas (and providing trailers – could you ask for more?). Then by hitting the map location, find route -> by bus, we had all the info at our finger tips. Google took care of making sure we got to the cinema in time, and clued us all up on the busses home again.

While at Future of Web Apps earlier this year, I joined the rest of the email-addicted crowd, inseparable from work. Handy for my boss. However, the power was in using pdaNet / Netshare to have access on my MacBook in the evenings. One must question the wisdom of replying to urgent requests at 1am after rinsing a free bar, but it all worked out.

I’m not obscessed with my iPhone, I don’t need it or cry when the battery dies. Its just a nice little gadget. I do however compulsively check the app store for the latest new toy, and am regularly impressed with what I find. It seems it’s still new enough for developers to be excited / inspired / payed generously to build for.

Here at Headscape we’re quite keen on XML, in fact our CMS is heavily based on it, to the point of ignoring a few relational (normal form) database rules. This gives us a lot of flexibility, along with a number of interesting problems. This will no doubt be the first in a series looking at how we tackle these issues, and why.

First off, a brief introduction to how we manage our data. Fragments of data that are used to build a web page are stored as XML in separate records in one table and associations are stored in another. That’s the basics. Meta data (such as created dates, published flags etc) are fields in the table, but the page data itself (title, category, body) is stored in a single XML field. To generate a web page, the required XML is collected, nested, transformed, and returned. Simple.

This allows us to deploy a generic database for a website and customise the fields that the user wants to use in XML schemas that we define. We have a nifty CMS that reads our XML schemas and provides the user with the forms to manipulate the data. The XML schemas are file system based, so are easily source controlled and transferred between projects.

When it comes round to styling the front-end site we transform the data in whatever format is required. We can create HTML, RSS, Atom or bespoke pages by defining new transforms. The hidden benefit here is that the XML, regardless of content, follows consistent patterns across our sites, allowing developers to switch between projects with ease.