james mckay dot net

One thing that is vital when deploying web applications is that you should be able to reduce the process of deploying upgrades and changes to as few steps as possible. Furthermore, every step should be a no-brainer — so simple that the scope for fat fingering something is strictly limited.

This kind of thing is acceptable:

1. Get the appropriate stable build from your daily build server.
2. FTP it onto the web server into a directory in an appropriate location. (Even better: have an option in your build script to do this automatically.)
3. Change the IIS settings to point to the new version.
4. You’re done!

Now in order to do this effectively, you need to build some foundations into your project. You need to isolate every setting that varies between your production environment and your developer box and put them in a separate location outside the website’s hierarchy that does not change from build to build.

These settings are purely concerned with server-specific configuration settings. They change from one machine to the next and will be different between developer machines and the production server. Examples include connection strings, SMTP server details, custom errors and trace settings. They aren’t necessarily stored in your source control, except as a sample file for documentation purposes, and they should definitely not be deployed afresh to the server with every build.

There are other settings that are tied much more closely to the code itself. Examples include HTTP handlers and modules, assemblies referenced in the <compilation> section, and all the additional stuff that ASP.NET Ajax or ASP.NET 3.5 adds to tell it that you’re using the C# 3.0 compiler, not the C# 2.0 compiler. These settings may change from one build to the next, but they are the same on every machine where they are used. They are, to all intents and purposes, code, and should be treated as such, kept in your source control, and deployed unmodified to the server with every new build.

Unfortunately, web.config mixes the two willy-nilly in a thoroughly cavalier way, with the result that there are several additional, more complex and error-prone steps that you need to take:

1. Locate the previous build.
2. Copy the web.config file into the new build.
3. Merge in the changes manually.

These steps are less straightforward and provide much more scope for error. What if you forget to do them, make a dog’s dinner of merging in the changes, or worse, introduce some subtle and mysterious bug that isn’t there on your development machine?

ASP.NET 2.0 added a new feature to sort this mess out. You can now specify an alternative file for your <appSettings> section. By doing <appSettings file="..\myappsettings.config" /> you can even specify a file outside your web application root. Whoopee! Problem solved!

Not so fast. What about the settings that don’t fit in to <appSettings>? For example, connection strings now go in the <connectionStrings> section; custom errors should be enabled on the server but disabled on your development box; tracing should be enabled on your development machine but not on the server; and so on.

It turns out that these too have an option to allow you to reference external files. You can set, say, <connectionStrings configSource="blah" /> to put your connection strings in a separate file. Unfortunately, unlike with <appSettings>, you can’t put this outside your application root.

Meh. Why not??? This is a major pain in the neck — especially for <connectionStrings>.

To make matters worse, there are some elements that straddle both camps. <compilation> is the most obvious example. It needs to have the attribute debug="true" on a development server, but in production you will need to insert debug="false" for improved performance. However, within your <compilation> element, you have a list of additional assembly references for things such as the ASP.NET Ajax extensions. And you can’t put these in a separate file.

All in all, configSource and <appSettings file="blah" /> go some of the way towards solving the deployment problem. Unfortunately, they still have limitations that are awkward and hobble the process and are a major annoyance.

Comments closed (1) »

Posted at 13:35 on 30 April 2008.
Tagged: ASP.NET, configuration, deployment

The standard instruction that tends to get bandied about on when to throw exceptions is probably the most useless piece of non-advice that I have ever come across.

“You should only throw exceptions in conditions that are exceptional.”

What on earth is that supposed to mean? It’s like saying “You should only eat food that is edible.” And that doesn’t tell you, for instance, that Agaricus bisporus is edible but Amanita phalloides isn’t.

However, there are actually two very simple guidelines that tell you, in terms that are much easier to understand, exactly when to throw an exception and when to catch one. They are:

1. Throw an exception when your method can’t do what its name says it does.

Scott Hanselman blogged about this a while ago and it is probably the best piece of advice I’ve read on the subject:

If your method is called “Save” and it can’t Save, then throw. If it’s called DoSomething and it can’t DoSomething, throw. The idea is that the method name is a verb and a contract. It’s promising to do its best and if it can’t do it, it’s very likely exceptional.

It’s clear, unambiguous, to the point and easy to understand. Each method should do one thing, its name should say what that one thing is, and if it can’t do that one thing, that is when you throw an exception.

2. Don’t catch an exception unless you intend to do something about it.

Now the first rule is about throwing exceptions; it doesn’t say anything about catching them. However, Patrick Cauldwell, whom he links to, has this to say:

Never catch Exception

• If it’s not a problem you know about, delegate up the call stack, because you don’t know what to do about it anyway

Far too often I see code that catches and silently discards all exceptions. This may give your program a superficial appearance of being more robust, but in actual fact, it is merely masking over a problem that may need to be addressed and dealt with.

Remember that an exception means that something has gone wrong. Unless you know exactly what to do about it to recover from the situation, you should let it propagate up to the top level of your program, where you should log it, and, if appropriate, fire off an e-mail to the developers and/or systems administrator to let them know about it.

There may be times when you need to catch Exception. Transactions may need to be rolled back, resources may need to be disposed, and so on. However, unless you can recover from the situation that caused the exception in the first place, you should re-throw it. And even if you do swallow exceptions for any reason (and you shouldn’t do so unless you have a good reason), you should never do so silently: the very least you should do is record a warning in the application’s event log.

Comments closed »

Posted at 23:39 on 23 April 2008.
Tagged: best practices, conventions, exception handling, exceptions

I’ve been thinking a bit recently that many other programmers’ blogs do a much better job of handling code snippets than mine does. Since time immemorial I’ve been using a very simple plugin called Code Auto Escape, which merely allows you to type code verbatim into your posts without having to go through all the rigmarole of HTML encoding them. I’ve never looked for anything fancier mainly because I never got round to it.

However, if you are geeky enough to post code on your blog in the first place, you need to do it properly, and that means syntax highlighting. Fortunately, it’s a simple case of finding and installing the right WordPress plugin. So, this morning, I finally got round to doing a bit of googling for one.

There are several such plugins to choose from. Most of them are based on GeSHi, a popular and very well supported PHP library which offers syntax highlighting for almost every programming language you can think of. It runs on the server, injecting extra markup into your code to achieve the desired effect.

In the end I settled for Syntax Highlighter. It takes a different approach, using JavaScript in your browser to render the highlighting and add a little toolbar at the top of each snippet with options such as copying it to the clipboard:

var highlightColour = "#ffff00";
var normalColour = "#ffffff";

$(document).ready(function() {
  $("#my-table tr").hover(
    function() {
      $(this).css("background-color", highlightColour);
    },
    function() {
      $(this).css("background-color", normalColour);
    }
  );
});

Personally I think this is a better, cleaner approach: it delegates the heavy lifting involved from the server to your browser, and reduces the size of the markup in your posts. It is also semantically cleaner: while the output from GeSHi is valid XHTML strict, it does jumble up content and presentation a bit, which is the reason why table-based layouts, the <font> tag and inline CSS tend to be frowned upon these days.

Unfortunately, none of these plugins address the biggest problem with writing code on your blog: that it is so fiddly and awkward with a rich text editor. Both Windows Live Writer and TinyMCE in WordPress take a perverse delight in messing up your indentation, your line breaks, and sometimes even with what gets HTML encoded and what doesn’t.

Comments closed »

Posted at 10:23 on 19 April 2008.
Tagged: syntax highlighter, WordPress

I have a friend who does not use source control for his programming projects. As far as I can tell, it’s a conscious and deliberate decision on his part, and although he has his reasons, I’ve never got round to asking him what they are. However, I doubt if they are very good ones.

Source control is the very bedrock of modern software development, yet it’s surprising how many developers there are like him, who still don’t see the value of it. One common argument that crops up from time to time is “I don’t use source control on any of my projects because I’m the only person working on them.” This is really a rather lame excuse, because no-one making such an argument would say “I don’t back up my projects because I’m the only person working on them,” nor would they say “I don’t use the undo button because I’m the only person working on my projects.”

For that is exactly what source control does. It provides you with a complete history of the changes you’ve made to your project, when you made them, and (assuming you’ve filled in the comments with each commit), why. If you have ever spent three days working on your code, only to find that your changes aren’t working out or are becoming very messy, and you’ve needed to roll back, only you don’t have a suitable snapshot to roll back to, you will know exactly what I mean.

Sadly, there is a fairly widespread misconcepton knocking around that source control is only useful for large development teams. This isn’t helped by the fact that companies such as Microsoft promote it as such. Visual Studio only includes source control with the (more expensive) Visual Studio Team System, whose very name says to solo developers, “Nothing to see here, move along please.” And many articles on source control (even including Joel’s comments on the subject) concentrate more on the team aspects of source control than on what it can offer for solo developers.

Another widespread misconception is that setting up a source control system is too much effort, or too expensive, or requires a separate server, and is overkill for small projects. Again, this is completely false. Subversion, probably the most popular source control package in the world, is free and open source. TortoiseSVN is a Windows client for it that installs as a shell extension and gives you a whole lot of easy to use source control features from within Windows Explorer. You can even create a repository in any empty folder on your hard disk with only a couple of mouse clicks:

I’ve been using source control with Subversion/TortoiseSVN for three years now, and I am embarrassed that I didn’t get started much earlier. To be sure, there is a bit of a learning curve, and there are a few gotchas that you need to watch out for, but really, it isn’t rocket science by a long shot, and it certainly isn’t overkill even for fairly minor projects and scripts. If you are writing any kind of software and aren’t already using source control, I strongly recommend you get started. And if you think you don’t need it, I recommend you take another look at it, because you’ve almost certainly misunderstood something.

Comments closed »

Posted at 13:00 on 14 April 2008.
Tagged: best practices, source control, Subversion, Visual Studio

Over the past few months I’ve been rather intrigued by some of the reports that I’ve read about Windows Vista speech recognition.  For example, Scott Hanselman claims an increase in speed from approximately 72 words per minute when typing to about 125 words per minute with voice recognition—an improvement of approximately 75%.

Now Hanselman works for Microsoft, so it is only natural that he would give something to do with Windows Vista a glowing report, and let’s face it, a typing test is actually a very artificial way of trying out this kind of thing—you’re not chopping and changing all the time but reading verbatim off the screen.  Other people are less complimentary.  Microsoft’s ill fated demonstration of Vista’s speech recognition went down in history, with the immortal phrase “Dear aunt, let’s set so double the killer delete select all” appearing on the evening news and geek T-shirts.

I haven’t actually used Windows Vista that much until recently.  My old laptop only had Windows XP on it, and I use Windows Server 2003 at work.  However, a couple of weeks ago I got a new laptop, complete with Windows Vista, so I thought I might as well put it through its paces, and so today, I’ve been trying it out.  I’ve set myself the goal of writing a complete blog entry without using the keyboard or the mouse: opening Windows Live Writer, navigating Firefox and Google Reader, finding other pages that I want to reference, and inserting hyperlinks, using speech alone.

My experience so far has been more along the lines of the ill fated demonstration than Hanselman’s glowing report, but to be fair, it’s still early days.  Initially it was painfully awkward, and after a few hours it’s still pretty clunky, but it does seem to be learning from its mistakes and it does get it right about 80% of the time.  The problem is that the 20 per cent of the time when it doesn’t get it right, or when you want to chop and change things, it is very slow and fiddly.  Some things don’t even work: “show numbers” doesn’t show numbers correctly for hyperlinks on Ajax enabled sites in Firefox, and your blog’s category names don’t appear in the “categories” drop down list in Windows Live Writer.

Yes, it’s more comfortable than using the keyboard, but it does take a lot longer, and thoughts only trickle from your brain into your document rather than flowing.  It is also pretty frustrating if you keep chopping and changing things, as I do when I’m writing. Perhaps if I persevere at it I might find it improves, but I don’t think we’re going to be dispensing with our keyboards anytime soon. 

Comments closed (1) »

Posted at 20:06 on 12 April 2008.
Tagged: speech recognition, typing

One of the systems that we have developed serves up WMA files dynamically and plays them in an embedded Windows Media Player. Because this system has been around for a few years now, it still uses the old classID for Windows Media Player 6.4 rather than the newer one for versions 7-11. That was all very well: this works fine with the later versions, it doesn’t have to do anything particularly fancy, and besides, it did the job admirably well.

Until Microsoft rolled out their latest set of Windows updates this week, that is. All of a sudden, users were reporting that Internet Explorer was crashing all over the place. However, if they rolled back to IE6, everything worked fine.

It turned out that we were serving up some of our sound files with a content type of “application/octet-stream” rather than with the expected “audio/x-ms-wma”. This was fair enough: Postel’s Law says that you should be liberal in what you accept, but conservative in what you do. So even if we weren’t getting it quite right, Windows Media Player was forgiving us.

Unfortunately, on Patch Tuesday, Postel’s Law went out the window at Microsoft’s end as well as ours. And rather rudely, to boot. No “invalid content type” messages or anything: Internet Explorer would just freeze.

To fix the problem, you need to do one of the following (preferably all three, despite the fact that there may be certain logistical issues with the third):

1. Make sure you are serving up the correct MIME type with your media files. For WMA audio files it should be “audio/x-ms-wma”. For other media types see here.
2. Change your web pages to use the newer class ID for Windows Media Player. It should be 6BF52A52-394A-11D3-B153-00C04F79FAA6 rather than 22D6F312-B0F6-11D0-94AB-0080C74C7E95. Note that some properties change names between versions: in particular, you use “url” rather than “src” in the later version.
3. Tell your users to jettison Internet Explorer altogether and switch to Firefox or Safari.

Talking of point 3: can someone please explain why the Windows Media Player Firefox Plugin doesn’t install on Windows Server 2003? Windows Server 2003 is just supposed to be Windows XP on steroids with a bunch of configuration tweaks and extra bells and whistles and an inflated price tag, surely? Or is there some genuine good technical reason for this seemingly inexplicable design decision?

Comments closed »

Posted at 14:20 on 10 April 2008.
Tagged: Windows, Windows Media Player

Astute readers of my blog will note that I turned off my Comment Timeout plugin at the start of this year. I had begun to suspect that its effect on spam was minimal, while at the same time there were still some posts that, according to Google Analytics, attract a bit of attention — in particular, my posts about SharePoint seem to feature rather prominently in searches by people who find the subject even more confusing than I do.

Sooo… now you can even leave comments on my very first blog entry if you are that way inclined.

In the end, I found that turning it off did not result in a noticeable increase in spam comments. I am now using only three plugins to manage spam on my blog and together they put in a stellar performance. Akismet and Bad Behavior stop almost everything dead in its tracks, and beyond that, a blanket rejection of comments that contain BBCode or more than two hyperlinks keeps your spam queue short, makes it easy to check for false positives, and reduces the load that it places on Akismet and your bandwidth consumption. As far as I can tell, 80-90% of spam comments contain either BBCode, or three or more hyperlinks.

However, this raises a question: what is the future of Comment Timeout?

Unfortunately, I have had quite a lot on at work recently and I have other projects that I want to move on to that I simply haven’t had time for so far, so since I am no longer using Comment Timeout myself, maintaining it further now has a very low priority.

There are some things that could still be done on it, such as localisation, but as far as I can tell, it is stable, it works with any version of WordPress since 2.0, and pretty much all the bugs that have been brought to my attention have been ironed out. I haven’t tested it thoroughly against WordPress 2.5, but as far as I can tell it should work properly.

If anyone would like to develop it further, I have no objections. It’s dual licensed under both the GPL and the MIT/X11 licence, so you don’t even need to ask for permission, though it would obviously be nice to get a heads-up.

Comments closed (1) »

Posted at 13:06 on 5 April 2008.
Tagged: Comment Timeout, spam, WordPress