Tim Jeanes: Microsoft TechEd (Wednesday)

Today we took a look at the some of the methods for making web pages run asynchronously - using AddOnPreRenderCompleteAsync or RegisterAsyncTask. Though these techniques won't make pages build any more quickly, they do keep threads free in the IIS thread pool, thereby ensuring other page requests aren't blocked. Without using these techniques, just one or two frequently-used but slow-loading pages can severely impact on the experience of everyone else using the whole of the rest of the website.

Unfortunately (in my mind) these methods aren't flexible enough. The asynchronous tasks can only sensibly be triggered during the PreRender event of the page - this is far too late to do anything other than displaying data. It's not possible to create controls input dynamically at this stage, for example, which you may well want to do based on the results of a slow-running database query. Though the RegisterAsyncTask method does allow you to call ExecuteRegisteredAsyncTasks at any time, this pauses the main page thread without releasing it - thereby negating any benefit you hoped to achieve from using an asynchronous page.

What I'd like to see is a number of points within the page lifecycle at which asynchronous tasks can be launched. PreRender is fine (and often desirable) for data display, but being able to launch them during the Init event would be far better if you need any kind of page interaction.


A seminar on building maintainable solutions highlighted some pretty cool features in Team System - both in the current 2005 edition and the soon-to-be-released 2008.

There's a nice performance profiling tool that can work light a strobe light against your code: you set your problematic slow-running method running and it'll report on where it found it was spending most of its time. The report it produces shows the entire call stack at each interval so it's dead easy to identify your bottlenecks.

The code coverage tools for unit tests aren't anything particularly new, but a nice feature is to provide the parameters for your tests (input and expected output) from a csv or xml file. I know I have a lot of tests that I wrote with a whole lot of cut 'n' pasting, so this will provide a much cleaner solution. As a bonus you have the tests be in the order given in the file or randomly. I'm a big fan of randomness in unit tests - not knowing what the test is that you're running is a great way of uncovering unforeseen errors.

The code metrics (new in 2008) are something I've not seen before. These analyse your code on a per-class or per-method level, measuring things like the number of lines of executable code, the number of branches, depth of class inheritance and how much one class relies on another. Each of these statistics are reported (providing useful pointers to good candidates for refactoring, for example), along with an overall maintainability score.

This gives me the fear slightly because I immediately know which parts of my code would produce the most "interesting" stats. Apparently studies have shown there's a direct correlation between the calculated maintainability score and the number of customer-reported bugs. The classes I'd least like to be analysed are the ones with the most unit tests (and thus the ones with the fewest reported bugs) - but was that just me compensating for what I know deep down to be unmaintainable code? We'll see...

On the flip-side of maintainability always lies performance. A seminar on producing scalable websites produced some handy pointers (I'll definitely be downloading the YSlow Firefox add-on to show me which parts of my page are taking time to load and to what degree caching is working for me. However our speaker was not a fan of LINQ at all: he hates the way it takes control away from the database layer and thus diminishes the performance benefits that compiled T-SQL stored procedures can give you.

I can see where he's coming from - and it does tie in with some of the debate we Compsoft TechEd delegates have been having amongst ourselves - but I think that LINQ will win for the way we work and the type of sites that we produce. Maintainability has always been more important to our customers than squeezing out every last drop of performance; it's far more common that they ask for a few fields to be added to their database than for them to want a page to load a half-second faster.


Speaking of design patterns - before we came out here, the Model View Controller design pattern was looming dimly on my radar but I wasn't too sure whether it was for us. It'd be quite a change from the way we work and though it initally looks quite beautiful from a purist standpoint, I wasn't really sure that it would work in my day-to-day real life job.

However, having attended a session on the new features of WCF in .NET 3.5 I'm suddenly very excited. It makes it very easy to handle specific HTTP verbs on URIs that match patterns you define, and easy to have it return your choice of XML, JSON or byte streams.

I think what troubled me most about MVC was that whilst it fitted the basic CRUD pages of an application very tidily, it's those tricky fringe cases that would be a headache: where you want to allow the user to spend some time on a single page building up a graph of objects before they hit the save button and actually cause an action that we want to handle in any persistent manner on the server side. These WCF features fit into place beautifully here: such a page would make WCF calls to the controller, returning (probably) JSON objects that we can handle in AJAX. We'd still be able to do any the tricky server-side logic we need to ensure the customer experience is a coherent one, but could delay any database interaction until that final save button click sends a POST to another URI that triggers a save action in the controller. Man, I just can't wait (either to play around with MVC - whenever it comes out - or at least to find out if my suppositions are on the right track)!


Seminars today: WEB401 (Stefan Schackow); TLA329 (Marc Popkin-Paine, Conor Morrison); DES304 (Guillaume Renaud, Dick Lantim); WEB02-IS (Stephen Forte); SBP312 (Steve Maine)