james mckay dot net

I sent a pull request to the lead developer of an open source project that I’m starting to contribute to. This is the default that both github and bitbucket give you, and the first thing that newbie open source contributors on those sites will think of doing.

I got this response from him:

I’d *massively* prefer patch submission via patchbomb to the … list – that’s generally where they come in, and sometimes people other than me find potential problems in the patch. Can you do that?

D’oh! My bad! It’s the same kind of thing as the rule that you should ask the whole community, not just one of its members. Admittedly I had noticed the existence of the mailing list, but only after I sent off the pull request, so his response did not surprise me.

Moral of the story: if you want to contribute to an open source project, look for a mailing list before you do anything else. And if there is one, use it.

Comments closed »

Posted at 08:47 on 4 September 2010.
Tagged: open source

This blog entry is directed at two individuals in particular. Probably neither of them read my blog though, but those of you who do should take great care not to emulate either of them.

First, to the gentleman who was at the rear of the central section of coach number eight in the 18:32 Southern train from London Victoria to Southampton Central and Bognor Regis this evening, who got off at Three Bridges.

Your favourite TV programme as a child may have been Top Cat. Your favourite TV programme as a thirty-something adult may still be Top Cat. You may think it’s cool to have the Top Cat theme tune as the ringtone on your mobile phone even though you’re in your thirties or forties. But when said mobile phone starts blaring out said ringtone at full volume in a train full of tired commuters for several minutes, it gets extremely annoying. Please, choose something less ingratiating.

Besides, what on earth were you smoking that you slept through a ringtone like that for nearly ten minutes? It must have been pretty potent.

Second, to whoever rang said gentleman no less than ten times round about 7pm this evening.

Unless your problem is genuinely important and genuinely urgent, ringing someone’s phone repeatedly when they don’t answer the first couple of times is rude. They may not be in a position to answer, and by calling them over and over and over and over again for several minutes, you are sending out a signal that you are a demanding, obnoxious type with no respect whatsoever for other people’s personal space. Just leave a message, and if they agree that it’s important, they’ll get back to you. Besides, you could be inflicting the theme tune to Top Cat on a train carriage full of tired commuters on their way home, because the person you’re calling is too non compos mentis to answer.

Comments closed (1) »

Posted at 20:56 on 23 June 2010.
Tagged: commuting

(Update: I’ve updated these instructions for Mercurial 1.6/TortoiseHg 1.1.)

I’m going to get really controversial here and say that I think Mercurial is better than git. My reasoning (as with the reasoning of everyone else who takes sides in this particular debate) is entirely subjective, so we won’t belabour the point here too much. Nevertheless, some of us do have a preference for one over the other, and many Subversion refugees like me who do most of their work in Windows tend to lean towards Mercurial.

But there’s no denying that github is fast becoming the Facebook of open source programming (albeit hopefully without the unethical bits, Farmville, and people tagging you in embarrassing photos for all and sundry to see), and if you want to strut your stuff as a developer, that’s the place to do it. Github is, of course, a hosting facility for git repositories, as one would expect of a site whose name says what it means and means what it says.

Fortunately, it is quite possible to use Mercurial as a client against github repositories via the hg-git extension, and you can pull and push from one to the other pretty much losslessly.

However, setting it all up on Windows is not entirely straightforward, and there doesn’t seem to be a decent guide to it anywhere on the Internet: most of the instructions that you read assume that you’re using either (a) Linux or a Mac, (b) the command line, or (c) both. You also have to figure it out from various places all over the web, and searches on Google and Stack Overflow proved to be surprisingly fruitless. Furthermore, the most comprehensive howto that I came across elsewhere contained several instructions that were just plain wrong.

So, after spending two solid evenings struggling against a myriad of error messages and cryptic dialog boxes, I finally managed to get it working, and for future reference (and anyone else who wants to know how), I’ve documented what I’ve found actually works for me as best I can.

1. Install TortoiseHg and hg-git.

Install TortoiseHg 1.1 or later. If you are using an earlier version, upgrade: these instructions may work if you don’t, but I can’t make any guarantees.

I downloaded hg-git by cloning the repository. You can get it from either github and Bitbucket. The advantage of cloning the repository is that you can upgrade to the latest version quickly and easily by hg pull then hg update, or use the graphical tools if you prefer. You can also easily switch between the bleeding edge version of the code and a stable release if you like.

hg clone http://bitbucket.org/durin42/hg-git c:\abc\mercurial\hg-git

I downloaded hg-git into the directory c:\abc\mercurial\hg-git. If you put it elsewhere in your filespace, alter these instructions to suit.

2. Update to the appropriate version of hg-git.

If you are using TortoiseHg 1.1, you will need to use hg-git 0.2.3. If you ignored my advice to upgrade, and are still using version 1.0, you will need to use hg-git 0.2.1. Don’t use version 0.2.2: it doesn’t work with either version of TortoiseHg.

The official hg-git documentation tells us that we also need to download and install Dulwich 0.4.0 or later. The latest version of hg-git requires Dulwich 0.6.0. In any case, Dulwich is included with TortoiseHg (version 0.6.0 with TortoiseHg 1.1; version 0.5.0 with TortoiseHg 1.0) so you don’t need to do anything else there. Open up the TortoiseHg repository explorer on your clone of hg-git, choose the “Tagged” radio button to show only tagged releases, and update to version 0.2.3:

3. Configure Mercurial to use hg-git and an appropriate SSH client.

To do this, you need to edit your mercurial.ini file. You can get to this simply by choosing “Global Settings” on the TortoiseHg context menu in Windows Explorer, and clicking “Edit file” to bring it up in Notepad. Add the following lines to your configuration file:

[extensions]
hggit = C:\abc\mercurial\hg-git\hggit

[ui]
ssh = "C:\Program Files\TortoiseHg\TortoisePlink.exe"

The [extensions] section loads hg-git into Mercurial; the ssh option in the [ui] section specifies an SSH command line client to use to communicate with github. TortoiseHg gives us TortoisePlink, which works fine for me.

4. Create a public key/private key pair.

There are some instructions on github on how to create a public key/private key pair. Unfortunately, these don’t tell you that key pairs come in two formats: OpenSSH (as used by git itself and github), and PuTTY (as used by Tortoise Everything).

A simpler approach is to download PuTTY (you can get it from here) and use PuTTYgen to generate your key pair:

Once you have generated your SSH key, copy and paste the “Public key for pasting into OpenSSH authorized_keys file” into github. Save your public key and private key to your hard disk somewhere.

5. Start Pageant

Pageant is a program that stores all your private keys in memory, where the SSH client used by Mercurial, that we configured above, can find them. It comes with both PuTTY and TortoiseHg. You can set it to load in your private key(s) when you log on to Windows by creating a new shortcut in the Startup folder of your Start menu with this command:

"C:\Program Files\TortoiseHg\Pageant.exe" "c:\abc\github.ppk"

Note that if you don’t start Pageant first and load in your private key, you will not be able to push to github.

6. Clone a repository and start pushing!

You should make sure that you get the format of your repository URL correct. It should be:

git+ssh://git@github.com/your-github-username/your-repo-name.git

The rest from there on is all plain sailing. All being well, you should now be able to pull from your github repository and push changes back up as if it were a Mercurial repository.

Things to check if it goes wrong.

Now all this is a bit of a fiddly process, there is plenty of room for error, and some of the error messages you are likely to get can be a little bit cryptic. However, most of it was due to me trying things that weren’t properly documented, and they all boiled down to a few things that you can check if you’ve followed the above instructions:

• Are you using the correct version of hg-git? While you can use versions later than 0.2.1, you need to use a later version of Dulwich than that which comes with TortoiseHg 1.0.
• The “ssh” option in your mercurial.ini file should only specify the name of the executable, without command line options. Some articles tell you that you can fill in the path to your private key in this option. Personally, I couldn’t get this to work, so I just stuck with Pageant.
• Is Pageant running?
• Is your private key loaded into Pageant?
• Do your public and private keys match?
• Is your private key saved in PuTTY format? If you generated your key pair using git, as per the instructions on github, it will be saved in OpenSSH format instead, and Pageant can’t handle that.¹
• Have you specified the URL to your github repository correctly? The version I gave above works, while missing out various parts of the URL (e.g. using “github.com” instead of “git@github.com“) doesn’t.

-----BEGIN RSA PRIVATE KEY-----
<transmission line noise>
-----END RSA PRIVATE KEY-----

PuTTY-User-Key-File-2: ssh-rsa
Encryption: none
Comment: imported-openssh-key
Public-Lines: 6
<transmission line noise>
Private-Lines: 14
<transmission line noise>
Private-MAC:
<transmission line noise>

Comments (4) »

Posted at 08:00 on 21 June 2010.
Tagged: open source, source control

The Daily Telegraph reliably informs us that we should expect the mother of all solar storms in 2013, which will unleash power cuts, the apocalypse, and Visual SourceSafe on us all.

New Scientist, meanwhile, reliably informs us that not only is the sun unusually quiet at the moment, with its current solar minimum carrying on much longer than normal, but that it could possibly remain that way for much of the rest of the 21st century.

One of them must be wrong.

Comments closed »

Posted at 08:00 on 17 June 2010.
Tagged: science

It’s World Cup time again. For the next few weeks, a certain sport will be celebrated, broadcast, and grossly over-hyped worldwide 24 hours a day by all and sundry.

It is to this particular game that the word “football” refers. Not, as they seem to think on the other side of the Atlantic, to some pretender to the name.

This one should be a no-brainer. Since the word “football” is a combination of the words “foot” and “ball,” logically it should be used to describe the game that involves the greatest amount of direct interaction between foot and ball. Running around with a vaguely haggis-shaped object under your arm just doesn’t quite cut it somehow, unless you reject the idea that words should say what they mean and mean what they say.

Perhaps in the interests of semantic integrity, we should rename American football to something like “arm haggis.” It’s more of a mouthful, and might confuse people into thinking it’s Scottish, but even so it’s a more accurate description of their particular sport than “football.”

Comments closed (2) »

Posted at 08:00 on 11 June 2010.
Tagged: miscellaneous

Dependency injection is one of those concepts in computer programming that looks weird and complex when you don’t understand it, but once you do, you wonder how you managed without it. A bit like distributed source control. Unfortunately, if you don’t understand it properly and implement it incorrectly, you can end up losing the benefits of it and end up wondering, “What was the point?”

For developers new to the concept, David Hayden has a series of video tutorials that provide what’s probably the best introduction to it that I’ve come across. He uses Microsoft’s Unity Container for most of his examples, but the concepts can easily be adapted for other libraries such as Ninject, Autofac, or Castle Windsor. He explains in some detail how to use them properly within both ASP.NET and WebForms, and demonstrates what kind of things they can achieve:

• Unity IoC and Dependency Injection Screencast
• Unity IoC and ASP.NET Screencast – Dependency Injection into Web Pages
• Unity and ASP.NET Web Pages Dependency Injection Part II with Special Guests – Autofac and Ninject
• Unity IoC and ASP.NET MVC Framework – Dependency Injection of Controllers
• Unity Nested Containers – IUnityParentContainer and CreateChildContainer
• UnityContainer and UnityConfigurationSection – Populating Unity Container via App.config or Web.config
• Unity IoC Dependency Injection and ASP.NET Model-View-Presenter

Comments (1) »

Posted at 08:00 on 10 May 2010.
Tagged: .net

Scott Hanselman says that if you’re using XCopy for deploying web applications, you’re doing it wrong. He is talking, of course, about the web deployment features of Visual Studio 2010, which constitute Microsoft’s attempts to solve a problem that is a lot less trivial than it looks.

It’s a bit of a strong statement, and I’m not sure that I agree with it. For the past four years or so, I’ve used a variant of XCopy deployment that I’ve found to be very effective. I put each release of the website into a separate folder, numbered after the version reported by Subversion, Mercurial, CruiseControl or TeamCity, depending on which of the above I’m using, and I just switch the directory in IIS, or on Linux it’s just a case of changing a symlink. This all but eliminates downtime for the vast majority of upgrades, as well as allowing you to roll back in seconds to any previous version that you still have available if things go pear shaped.

I’d like to see how Web Deploy handles upgrades like this. My experience of software upgrades is that they are rarely that seamless and usually involve several seconds of downtime, though having said that, if your website is so busy that half a minute of downtime is a serious problem, the chances are that you have failover servers that you can bring in while you upgrade.

A more serious issue, however, is rollback. Some of the sites I work on are pretty high profile, and the ability to roll back in seconds if things don’t work out is a deal breaker as far as I’m concerned. That’s why I’ve found the XCopy/IIS settings switchover approach to be such a winner.

I am not impressed with the approach that Visual Studio 2010 adopts to managing web.config files, however. This approach sets your connection strings etc at build time, which can be pretty painful since you have to have different builds for development, integration, test, production and so on, and once you start branching and merging, and have to have separate connection strings for separate branches, it can completely blow up in your face if you’re not careful. No, configuration is a deployment time operation and needs to be treated as such. The best place for your configuration settings is outside your application root, in a common location easily accessible to every version of your site.

Finally, one last tip. Never deploy on a Friday. There are two reasons for this: first, it’s the end of the week, you’re tired, you just want to go home, and you’re much more likely to make a mistake than on a Monday when you’re fresh. Second, if something does go wrong, it will really, really, really ruin your weekend.

Comments closed »

Posted at 08:00 on 26 March 2010.
Tagged: .net, deployment

I mentioned this in passing in a recent blog entry, and I thought I’d expand on it a bit.

I do not like NAnt.

I do not like MSBuild either.

I’ve used both of them, and quite frankly, I don’t see the point of either of them. To be sure, MSBuild allows you to build Visual Studio solutions from the command line, but that’s MSBuild the program. MSBuild the language, on the other hand, is a completely, utterly pointless reinvention of NAnt, which itself is probably the most completely, utterly pointless domain specific language in widespread use that I’ve ever come across.

Neither language does anything that you can’t do in Python. In fact, most of the time, Python does it better, with a cleaner syntax because it isn’t XML-based. XML is fine for some things, but the foundation for a scripting language is not one of them. When you’re using XML as the basis for your scripting language, you’re getting dangerously into “all you have is a hammer, so everything looks like a nail” territory.

Besides, neither of them are used anywhere for anything other than writing build scripts. If you use Python, at least you can leverage your knowledge for other domains, such as web development, game development, OS scripting, and much, much more.

I say Python here purely because I happen to know it. There are other decent, popular, multi-purpose languages that you can use to write build scripts. There’s no reason why you can’t use Ruby, or PowerShell, or even good old fashioned batch files, for instance. But having to learn and use a fiddly, awkward new language solely for the purpose of setting up or changing your build scripts—something that you only do relatively infrequently—simply doesn’t make sense.

Comments closed (1) »

Posted at 08:00 on 23 March 2010.
Tagged: .net, antipatterns, programming languages

I have a long-standing gripe about web.config files. They are where you are “officially” supposed to put all your application’s configuration settings, but the framework throws in a whole lot of other so-called configuration settings that are, to all intents and purposes, code. Such as HTTP modules, assembly references, which version of the C# compiler to use, and so on.

This is bad. A well-designed application configuration file will only contain settings that vary from one deployment to the next. Anything that is the same across the majority of deployments should be set in your code either by convention or by default values. Anything that doesn’t change from one deployment to the next is not configuration, but code.

But why not just stop using web.config for your app settings and connection strings altogether? There’s nothing stopping you from writing your own configuration class which pulls in all your application settings and connection strings from a JSON file in the parent directory to your application root, or in the Windows registry, if that’s what you need to do.

Build scripts are another example. What language do you use to write your build scripts? Chances are, you either use NAnt or MSBuild. But both of these are XML-based, unwieldy, tricky to learn and use, and somewhat limited. What’s to stop you using Python or Ruby instead, or even batch files, for instance? They can do everything that NAnt and MSBuild can do and more, they are much simpler to understand and edit, and you can leverage the knowledge involved elsewhere.

Just because the framework provides you with an “official” way of doing something, it doesn’t mean you have to use it. Using a different approach to the officially touted way may sound a bit radical or perhaps even iconoclastic at first, but it makes perfect sense once you think about it. After all, if the accepted wisdom passed down from Redmond is not fit for purpose, blindly sticking with it even though it gets in the way is just cargo cult programming.

Comments closed »

Posted at 08:00 on 15 March 2010.
Tagged: antipatterns, programming languages, tools

Dear fellow Mercurial fans,

Please stop using the command line when you’re writing articles telling us how wonderful Mercurial is.

I don’t need to be convinced that it is superior to Subversion. I’ve been using it for about nine months alongside our central Subversion repository at work, as well as for my private projects at home, and there’s no doubt in my mind which is better by a long shot. Easy branching and merging, and local versioning for experimental development and refactoring, are killer features as far as I’m concerned. And ease of use is supposed to be its big selling point over git.

But other developers do need convincing, and if you’re apparently fanboying the command line, it doesn’t help. In fact, it’s downright embarrassing. Remember, you may be a Linux geek who writes code for fun at weekends, but most of them are nine to five Windows developers who switch out of code mode the minute they leave the office and don’t want to have to learn anything new unless it’s strictly necessary. To them, it looks elitist, arrogant, off-putting, and Luddite.

When I first heard about Mercurial and git about two years ago, neither of them had any form of graphical user interface to speak of. It was a case of hg this, hg that, git this, git that in a command shell versus TortoiseSVN’s repo-browser, show log and commit dialogs. You know, like, where you can actually see what you’re doing? Where you can frequently figure out what you need to do by experimentation and educated guesses rather than having to wade through a morass of man pages? Forget it, I thought. Come back to me in a year or two’s time when you have a decent graphical front end for it. In the meantime, I’m sticking with TortoiseSVN.

Heck, I’m the kind of developer who likes to try out new things. I like Linq, and MVC, and jQuery, and Python, and IOC containers, and Colemak keyboards. I know Linux and I’m not afraid to use it. If I was put off by the impression that Mercurial was command-line only, what hope do you have of convincing the rank and file Windows developers who are scared of the command prompt?

Nowadays, of course, we have TortoiseHg, which gives it a decent, powerful and intuitive front end. In fact it was TortoiseHg that sold me on Mercurial in the first place, because it lets you see exactly what you’re doing when you’re branching and merging, as well as flattening out the learning curve dramatically. Just take a look at its repository explorer, for instance:

See? You even get a nice little graph showing you exactly where all your branches are. Context menus make it easy to figure out what to do next and actually do it. Oh, and it shows you the most recent changes first, rather than just vomiting everything out onto the screen and leaving you staring at changeset zero, like you get when you run hg log:

To a seasoned developer, there are advantages to the command prompt. It’s easier to type into your blog, easier to copy and paste, and easier to script. But there is a time and a place for everything, and introductory tutorials for tools with perfectly good graphical front ends are not the time and place for a command prompt. Doing a screen capture, firing up Paint.net and cropping your image to the right size may be more of a faff, but in an introductory tutorial, merely typing hg push instead is either outright elitism or sheer laziness. Please, cut it out. Use TortoiseHg to introduce Mercurial, and keep the command line for more advanced tasks.

Comments closed (1) »

Posted at 08:00 on 8 March 2010.
Tagged: antipatterns, marketing, source control, tools