Surprisingly, I find that almost nobody ever bats an eyelid, and I suspect that it’s because I always order a Diet Coke. It helps if you insist on Diet Coke rather than normal Coke, with ice cubes and a slice of lemon: the embellishments have a somewhat distracting effect that makes it easier to overlook the fact that none of them contain C₂H₅OH.

On the other hand, I don’t recommend orange juice, unless you want to draw attention to the fact that you intend to remain sober for the entire evening. In situations like that, it makes you look like a stereotype.

<xsl:element name="foo">
  <xsl:attribute name="bar">
    <xsl:value-of select="/some/xpath/@expression" />
  </xsl:attribute>
</xsl:element>

However, did you know that you can do this instead? Much cleaner and easier to read:

<foo bar="{/some/xpath/@expression}" />

(Hat tip: Ned Batchelder)

The unpleasantries of the rush hour can be alleviated somewhat by choosing your train carefully and getting on at the right place. I always catch the 07:25 train to London Victoria at Horsham and go for the rearmost carriage, and so far I have had a 100% success rate at getting a window seat. Most of the stations between Bognor Regis and Crawley have short platforms, and consequently the front of the train is generally much more packed out than the rear. I do not recommend getting on at Littlehaven: its platform is only four coaches long, but more people get on the train there than at Horsham, and it can be a bit of a crush at times. Then you have to jostle past people through several coaches in order to get a seat.

This effect is even more pronounced on the way home in the evenings. On Thursday I made the mistake of going for one of the front four coaches, and even though I had a seat, it was not a pleasant experience. The entire Littlehaven crowd pile in to the front four coaches right from the word go, rather than spreading themselves more evenly through the train and moving forward once we get to Crawley. This means that the back of the train is definitely the place to be if you are disembarking elsewhere.

I avoid the Underground like the plague. London buses may be a bit of a lottery in terms of overcrowding — I’ve had both good and bad experiences on the 507 — but at rush hour, the Underground is guaranteed to be so packed out that it makes a Kenyan matatu look like an intergalactic void. However, as I am working just under a mile from Victoria, it is cheaper, less crowded and more healthy to walk, as well as giving you a good bit more elbow room at only minimal cost in terms of time.

Finally, the best place to sit in a train is near the middle of a carriage. You get a pretty smooth ride there, whereas by contrast you get jolted about quite a lot near the ends of the carriage. It’s much the same reason as why the middle of a boat is where you’re least likely to be seasick: the carriage acts a bit like a lever, so the ends tend to wiggle about a lot more. Another thing about the ends of the carriage is that they can be a lot noisier if the doors at the end get jammed open.

The logic behind constructing the URLs is fairly complex, and depends not only on the route data that you pass into the ActionLink method, but also on the route data that comes from the original URL that you used to access the page in the first place. If you have routes that are any more complex than the fairly trivial examples that come in the out of the box application templates, it can quickly get pretty confusing. Furthermore, chopping and changing the order in which you register your routes can get things totally out of kilter, so you really need a comprehensive suite of unit tests to be able to tackle it with any hope of retaining your sanity whatsoever.

The subject of unit testing your routes to make sure that you are getting the correct route data out of them has been covered by Phil Haack and Stephen Walther, so I won’t go into any further detail about that aspect here. However, I’m going to expand a bit on Phil’s methods to show how to test things the other way round: making sure that when you pass some route data in to Html.ActionLink, it gives you the URL that you expect.

As with Phil’s sample code, I’ve used Moq to mock the context, request and response, and I’m using Eilon Lipton’s technique of using an anonymous class as a dictionary literal. You can download the code as a Visual Studio solution if you want to get up and running with it straight away. Here’s a quick look at the methods that do all the work:

string FindUrlToRoute(string currentPage, object routeData)
{
	var mockContext = new Mock<HttpContextBase>();
	var mockRequest = new Mock<HttpRequestBase>();
	var mockResponse = new Mock<HttpResponseBase>();

	mockContext.Expect(c => c.Request).Returns(mockRequest.Object);
	mockContext.Expect(c => c.Response).Returns(mockResponse.Object);
	mockRequest.Expect(c => c.AppRelativeCurrentExecutionFilePath)
		.Returns(currentPage);
	mockResponse
		.Expect(c => c.ApplyAppPathModifier(It.IsAny<string>()))
		.Returns((string s) => s);

	var route = routes.GetRouteData(mockContext.Object);

	var requestContext 
		= new RequestContext(mockContext.Object, route);
	var url = new UrlHelper(requestContext);
	var dict = new RouteValueDictionary();

	foreach (PropertyValue property in GetProperties(routeData)) {
		dict[property.Name] = property.Value;
	}

	var path = routes.GetVirtualPath(requestContext, dict);
	return (path != null ? path.VirtualPath : null);
}

protected void AssertRouteUrl(string currentPage, string expectedUrl, 
	object routeData)
{
	var str = FindUrlToRoute(currentPage, routeData);
	Assert.AreEqual(expectedUrl, str, "URL was wrong!");
}

The sharp eyed among you will note that I am not actually calling Html.ActionLink() itself, but a different method, routes.GetVirtualPath. When you construct an action link, or when you use Url.Action(...) in your views, ASP.NET MVC ends up one way or another running your data through the GetVirtualPath method of your route table. You have to mock the Response.ApplyAppPathModifier method — a fact that wasn’t immediately obvious, and it took a bit of digging around in the System.Web.Routing assembly with Reflector to find out exactly what needed to be done.

You can then check to see whether you are getting the correct URL out by calling in to the AssertRouteUrl method as follows:

[Test]
public void TestBlogPath()
{
	AssertRouteUrl(
		/*
		 * currentPage is an app-relative URL, so it must be
		 * prefixed with a tilde (~). Note that this is required
		 * and must point to a valid route.
		 */
		"~/blog/2008/10/25",
		/*
		 * expectedUrl, on the other hand, is an absolute path,
		 * so it shouldn't.
		 */
		"/blog/2008/10/10",
		/*
		 * The route data. Note that you specify your controller and
		 * action here as the controller and action properties 
		 * respectively.
		 */
		new { 
			controller = "blog",
			action = "index",
			year = "2008",
			month = "10",
			day = "10"
		}
	);
}

Download: Unit testing route URL generation - Visual Studio solution

Now people who say this kind of thing have a valid point. You can’t learn to be a good programmer overnight — it takes years of experience, trial and error, constantly honing your skills, and so on, and I don’t think you’ll ever reach a point where you stop learning. However, I don’t think it’s fair to turn this point into a criticism of books such as the 24 hours series. To be sure, these books won’t turn you into an expert programmer in a weekend, but if you think that’s what they’re all about, you’ve completely misunderstood the title. Their aim is to give you enough knowledge to bootstrap your understanding of the subject in that period of time to a point where you can actually start to Get Things Done, and then give you a platform to build on.

In that respect, I think they play a very important role. Whenever I come to a completely new technology, I see a mysterious black box, with everything hidden away behind a facade of whatever user interface you have, and if that happens to me as a particularly techno-savvy type, it’s certainly going to happen to lesser mortals as well. However, I often find that it just takes a little bit of an idea of what’s going on under the hood for me to get started finding my way around it in earnest. Somehow, the first part of the learning curve often seems the steepest.

There’s another reason why they’re important too. Computer programming these days — certainly, programming in the Real World — often requires you to get a handle on new technologies and languages very quickly. It’s a fast paced world, with new technologies coming out left, right and centre, and if you don’t keep up you’ll fall behind. Add a few over-enthusiastic sales guys into the mix, convincing the clients that you’re the world’s greatest SharePoint expert on the basis of the fact that you threw a default installation of MOSS 2007 onto a server and set up a couple of custom lists, and things get all the more interesting. Very often, you need to get up to speed with something in only 24 hours.

In this respect, I’ve found the 24 hours books to be some of the best introductory texts on computer programming related subjects that you can get. I originally learned XML from Michael Morrison’s Teach Yourself XML in 24 hours. I have two books on UML: Martin Fowler’s UML Distilled and Joseph Schmuller’s Teach Yourself UML in 24 hours, and I find Schmuller’s book the easier and clearer of the two to follow. It doesn’t particularly dumb the subject down either — both books cover the same material in similar depth. Given that Martin Fowler is one of the best tech writers around today, that speaks quite favourably for Joseph Schmuller.

I somehow wonder if there’s an element of snobbery involved in criticising books such as these. It seems to me that most of the criticism comes from very experienced and knowledgeable computer science-y types — the kind of people who think that Scheme is the best language to start with for teaching programming to ten year olds. It’s a bit like the world of church music: some traditionalist classical musicians get very dismissive of modern Charismatic worship albums. You can easily understand why: if you’ve spent several years studying for multiple degrees in music or computer science, no doubt working up a massive student loan in the process, you aren’t going to take too kindly to the idea that someone can be just as successful in your field without having gone to the same amount of expense and trouble.

So don’t be embarrassed about reading books in the 24 hours series. Everyone has to start somewhere with new technologies, and for getting started, these books are every bit as good as any.

Hopefully this will attract some more talent back to the .NET platform. It’s been the case for a while now that the best, most passionate web developers — the ones who come up with the all-singing, all-dancing Ajax-y websites and eye candy — have generally been shunning the Microsoft stack in favour of PHP, Django and Ruby on Rails. You can easily understand why — the web forms postback model may be good for simple, fairly generic things, but if you really want to make your website sing, it has restrictions and leaky abstractions that get in the way a lot, such as the limitation of one server-side form per page, or the convoluted id attributes that it sticks in all over the place making CSS and DOM manipulation a major headache, or the monster that is view state.

However, with the ASP.NET MVC framework on the go, we have finally got back the control over our HTML that we need, and now with jQuery forming an official part of it, ASP.NET is becoming an even more exciting prospect again. It’s especially so since in many ways you can really push the boundaries with .NET a lot further than with most other frameworks. Languages such as PHP or Ruby are good in themselves, but they do have their limitations, and it’s not a good idea to try to use them for image manipulation, or genetic algorithms, or Bayesian spam filtering, for instance — they are just too slow for computationally intensive stuff such as that, and in those cases you would need to drop down to C++. On the other hand, in C#, you can do it all in one integrated end-to-end framework, and with Visual Studio, you have what is probably the best IDE on the market to help you on your way.

I’m looking forward to seeing a lot more all-singing, all-dancing websites written in ASP.NET.

It seems like any time you try to measure the performance of knowledge workers, things rapidly disintegrate, and you get what Robert D. Austin calls measurement dysfunction. His book Measuring and Managing Performance in Organizations is an excellent and thorough survey of the subject. Managers like to implement measurement systems, and they like to tie compensation to performance based on these measurement systems. But in the absence of 100% supervision, workers have an incentive to “work to the measurement,” concerning themselves solely with the measurement and not with the actual value or quality of their work.

is also one of the faces behind a programmer website which does exactly what he is railing against.

I’m talking about the Stack Overflow reputation and badge system. Granted, it was more Jeff Atwood’s idea than Joel’s — he took his inspiration for it from the Xbox 360 — but the big problem is that when you try to turn a serious system that is supposed to be all about Getting Things Done into a game, people just game the system and turn it into an unusable mess that is not fit for purpose.

If you want to see what I mean, just take a look at this question, which I asked yesterday afternoon. I’ve been looking for a bug tracker system which can work as an integrated system for both developers and project managers for a while now, and none of the ones I’ve looked at so far have the particular feature I’m asking for.

The first so-called answer came within seconds and didn’t answer the question properly, which isn’t surprising since you would need at least 2-3 minutes just to read the question in the first place. It was followed by a string of about ten or so responses over the next half hour, again, very few of which made much effort to read the question, let alone answer it. Most people seemed to treat it as saying “What is your favourite issue tracker?” and one busybody even tagged it as “subjective” when I was asking for something very specific. And nobody so far has reported any success or otherwise with using an issue tracker of any description to integrate both the developer’s-eye view and the project manager’s-eye view.

This is a BIG problem with Stack Overflow, and I’ve seen it to an extent on other questions too. The system doesn’t favour good answers or correct answers or answers that actually make any attempt to answer the question, it favours quick answers. Being the first off the mark with something that at least looks like it could plausibly be an answer to the question means you’re most likely to get voted up. Getting voted up means appearing at the top of the list of answers, and it’s kind of self perpetuating because then you get more votes, and each vote means that you get ten reputation points, and if you get enough reputation points, you automatically become the Stack Overflow equivalent of a Wikipedia administrator.

The result is that you get a whole lot of knuckleheads gaming the system trying to pimp their reputation. They put up a response that looks fairly plausible and seems right to other knuckleheads but which either (a) doesn’t answer the question, or (b) is plain wrong. If the person asking the question is also a knucklehead, their answer gets marked as the accepted answer, which means even more reputation points. In the meantime, someone who arrives several days or weeks later with the correct answer doesn’t get any attention because their answer gets buried in all the other zeros. It’s particularly worrying because it’ll be the knuckleheads who end up running the show and deciding what goes and what doesn’t.

It’s as broken as lines of code per day, and it really really annoys me.

It really annoys a lot of other Stackers too — a request to fix it is the most popular user request on the Stack Overflow uservoice forums, though the problem is that there is no consensus about what needs to be done to stop it. I do hope they come up with some fix for it, otherwise the site could end up with no more value than its arch-nemesis, expertsexchange.

Well perhaps I was a bit too hard on it, and no doubt I’ll get another firestorm of comments from the fanboys here, because I’ve started using it again.

I’m not using it all the time, mind you. I tend to use my laptop at home, and in my experience, Colemak and laptop keyboards simply do not mix. But I’ve been using it increasingly at work with my Microsoft Natural 4000 keyboard, and the two of them seem to go together fairly well. I really can’t emphasise this strongly enough: if you want to get the most out of Colemak, get a split ergonomic keyboard.

Switching between the two layouts also seems more comfortable in the long run, once you get used to it. They exercise different muscles in your hands and arms, so I find that when I get tired working with one, switching to the other helps a lot. I also seem to be picking up a bit of speed with it too, and though I haven’t got round to testing myself again, I wouldn’t be surprised if I’m managing to hit 70 a bit more consistently.

Now if only someone would treat me to an Aeron chair…

There are some pretty interesting people in the network, such as Joe Anderson, who writes about a variety of issues related to general technology, Web 2.0 and “the” Wikipedia, and Lorelle van Fossen, whose blog about blogging is very well regarded within the WordPress community. Check out neverhappen.com too — it’s a daily photoblog with some absolutely stunning photography.

Needless to say, this will keep the pressure on me to come up with good quality content. The fact that I’m working in London for one of our Very Important Clients for the next three months puts even more pressure on my time as well — I have to set my alarm for half past five in the morning in order to catch the 07:25 train. However, a 55 minute commute each way does give me an opportunity to jot down some ideas for interesting content, even though the train can be pretty full and elbow room can be at a premium sometimes.

Scenario 1: direct request for a web form.

Just suppose for a minute that you have been contracted to rewrite Wikipedia in ASP.NET. So, for instance, you may end up with the page “What Wikipedia is Not” (aka “WP:NOT” or “Wikipedia’s attempt to get into the Guinness Book of Records for the most lies per kilobyte on a web page”) at http://en.wikipedia.org/wiki.aspx/WP:NOT.

In this case, you have several different properties of HttpContext.Current.Request containing different representations of it.

• Request.RawUrl = "/wiki.aspx/WP:NOT" represents the path and query string parts of the URL. In this case, of course, there is no query string, but if there were, you might see it set to something like "/wiki.aspx/WP:NOT?mode=edit".
• Request.Path = "/wiki.aspx/WP:NOT" represents the path part of the URL.
• Request.FilePath = "/wiki.aspx" represents the part of the path to the file (in this case wiki.aspx) that is handling the request.
• Request.PathInfo = "/WP:NOT" is a diff of Request.Path and Request.FilePath, giving the extraneous bit of the path that does not refer to a file in the file system.
• Request.PhysicalPath = "c:\inetpub\wwwroot\wiki.aspx" is the physical path to the file that is servicing the request.

Case 2: Server.Transfer() and Server.Execute()

Sometimes, you may want to transfer control from one file to another. Let us suppose, for instance, that you decide to use several Web forms: one for articles, one for special pages, and one for article history. You do a few simple checks in wiki.aspx and decide to transfer control to another file, say, article.aspx, using Server.Transfer(). Then, another property of Request comes into play.

• Request.CurrentExecutionFilePath = "/article.aspx" represents the path to the file that is currently handling the current part of the request.
• Request.FilePath = "/wiki.aspx", however, remains unchanged.
• Request.PhysicalPath = "c:\inetpub\wwwroot\wiki.aspx" also remains unchanged.
• Request.AppRelativeCurrentExecutionFilePath = "~/article.aspx" is the same as Request.CurrentExecutionFilePath, but relative to the root of the web application, as defined in IIS. If your application were rooted at, say, "/wiki" then Request.CurrentExecutionFilePath would be "/wiki/article.aspx".
• Everything else remains unchanged.

Note that Request.CurrentExecutionFilePath is always in use: if there has been no call to Server.Transfer it will be the same as Request.FilePath.

Case 3: URL rewriting

So you have this lovely new ASP.NET version of Wikipedia up and running, it works much more smoothly, has much less downtime, and runs on only a dozen or so servers rather than a hundred. Then, you start getting hate mail from irate Wikipedians, many of whom are open source zealots who are definitely not NPOV on Microsoft Windows. Jimbo and the Arbitration Committee get involved and demand you rewrite those URLs to cover up the fact that the Wikimedia Foundation has gone over to the Dark Side.

So, you take the original URL http://en.wikipedia.org/wiki/WP:NOT and transmogrify it into http://en.wikipedia.org/wiki.aspx?ns=Wikipedia&pg=What_Wikipedia_is_Not using a discreet call to Context.RewritePath.

Suddenly, everything changes!

• Request.RawUrl = "/wiki/WP:NOT" represents the original path and query string parts of the URL. In actual fact, Request.RawUrl always represents exactly what you typed into your browser.
• Request.Path = "/wiki.aspx" represents the path part of the URL.
• Request.FilePath = "/wiki.aspx" represents the part of the path to the file (in this case wiki.aspx) that is handling the request.
• Request.PathInfo is blank. When you use URL rewriting you have to point to a real file: you can’t use a PathInfo — that’s why you need to use a query string instead.
• Request.CurrentExecutionFilePath = "/wiki.aspx" until you call Server.Transfer, when it changes.
• Request.QueryString = "ns=Wikipedia&pg=What_Wikipedia_is_Not" is of course changed after the URL rewrite.
• Request.PhysicalPath = "c:\inetpub\wwwroot\wiki.aspx" is, again, the physical path to the file that is servicing the request.

Case 4: ASP.NET MVC

So how on earth, you may be asking, does all this work with ASP.NET MVC? After all, it doesn’t use Web forms in the same way — URLs map to controllers, which then decide which views to render themselves.

Well here’s the skinny:

• Request.RawUrl = "/wiki/WP:NOT" contains the raw URL (path and query string) as before.
• Request.Path, Request.FilePath, and Request.CurrentExecutionFilePath, all contain the “path” part of the URL without the query string. They will all be set to "/wiki/WP:NOT"
• Request.PathInfo is blank. ASP.NET MVC handles path info through the routing engine and passes it in the parameters for your controller.
• Request.PhysicalPath = "c:\inetpub\wwwroot\wiki\WP:NOT" is NOT the physical path to the file that is servicing the request. Controllers may decide to render one of any number of views or other results, and they need not even be Web forms — they could be raw text content (from a ContentResult), or a redirect (from a RedirectResult or a RedirectToRouteResult) or a JSON string (from a JsonResult) and they aren’t associated with a physical file on the filesystem at all.

Case 5: ASP.NET MVC with URL rewriting and/or Server.Transfer

I shall leave this one as an exercise for the reader. No doubt there is someone, somewhere, who is doing this, for reasons that completely befuddle me. After all, I’d have thought that the whole MVC pattern renders URL rewriting and Server.Transfer pretty much redundant.

Case 6: Requests for a directory’s home page

This is much the same as the above, except that ASP.NET inserts the name of the home page — typically default.aspx — into Request.RawUrl, and, by extension, everything else. Obviously, this does not apply to ASP.NET MVC.