james mckay dot net

About a month or so ago, elite C# gurus such as Eric Lippert and Jon Skeet were discussing the new async and await keywords that are forthcoming in C# 5. Eric Lippert introduced them with a series of blog posts on continuation passing style programming that I haven’t yet got round to reading properly.

People who are into continuation passing tend to wax lyrical about it, portraying it as the latest cure for cancer. But I’m wondering just how much of my time I should spend on it. To me, it looks a bit whacked out — isn’t it just some kind of nonlocal goto, and aren’t goto statements considered harmful? How will it help me write code to keep the Great British Public informed about what their elected representatives are discussing in Select Committees?

You never know. No doubt in a few years’ time, I too will be passing continuations around like sweets at a children’s party. I had similar thoughts a few years back when I first read about LINQ. Why would anyone want to embed SQL statements in their C# code, I thought? It sounded a bit like the bad old days of tag soup in classic ASP. But nowadays I use LINQ all the time and I’ve long since figured that LINQ is not LINQ to SQL. In fact, I don’t see how you can get anything done without LINQ. It’s just so much cleaner than writing a whole bunch of for loops. And it gives you lazy evaluation, which can give you massive performance benefits if you use it properly.

This is a common paradox in programming. Once you get to grips with a new programming language feature, concept or tool, you wonder how on earth you managed to write any code at all without it. But on the other hand, when you look at all the concepts, features and tools that people are waxing lyrical about in those terms, they all look weird, if not completely scary. And when you wax lyrical about something or other, as sure as eggs are eggs, someone will tell you your tool is the weird and scary one.

In his essay, “Beating the Averages,” Paul Graham calls this the Blub Paradox:

Blub falls right in the middle of the abstractness continuum. It is not the most powerful language, but it is more powerful than Cobol or machine language.

And in fact, our hypothetical Blub programmer wouldn’t use either of them. Of course he wouldn’t program in machine language. That’s what compilers are for. And as for Cobol, he doesn’t know how anyone can get anything done with it. It doesn’t even have x (Blub feature of your choice).

As long as our hypothetical Blub programmer is looking down the power continuum, he knows he’s looking down. Languages less powerful than Blub are obviously less powerful, because they’re missing some feature he’s used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn’t realize he’s looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.

When we switch to the point of view of a programmer using any of the languages higher up the power continuum, however, we find that he in turn looks down upon Blub. How can you get anything done in Blub? It doesn’t even have y.

I guess the best definition of “Blub” is the collection of programming language features, concepts and tools that you know and understand — or at least, that you can see might come in useful, so you really ought to get round to learning about them. It’s what makes sense from your vantage point. But when you look up and see someone waxing lyrical about something unfamiliar, don’t just write it off as weird. They may quite possibly be right.

Comments closed »

Posted at 08:00 on 13 December 2010.
Tagged: jargon, programming

If you add a WCF service to a web project in Visual Studio, it will dump a whole lot of garbage in your web.config file to make it work. If you want to keep your web.config file slim and clean (and you should), there is an alternative. You can of course create the services programmatically in a console application, but how do you do it in a web application?

Simply open the .svc file itself (not the .svc.cs codebehind file) in a text editor (you can right-click on the file and choose “Edit markup” on the context menu), and add the following attribute to the <%@ServiceHost %> tag:

Factory="System.ServiceModel.Activation.WebServiceHostFactory"

This will give you something like this:

<%@ ServiceHost
    Language="C#" Debug="true"
    Service="My.Wcf.Service"
    CodeBehind="Service.svc.cs"
    Factory="System.ServiceModel.Activation.WebServiceHostFactory"
%>

You can then remove all the extraneous cruft that Visual Studio adds to the <system.serviceModel> section in your web.config, thereby keeping it cleaner and more manageable.

Comments closed »

Posted at 08:00 on 9 December 2010.
Tagged: .net

The question of the command line is a controversial one, with some people declaring that it should be a core competency without which you should be considered an automatic “no hire,” and others claiming that it’s an anachronistic irrelevance in these days of graphical user interfaces, drag and drop, and integrated everything in Eclipse and Visual Studio.

Now I’ve repeatedly described command line instructions as a bad marketing strategy, and I stand by that. The command line is pretty intimidating if you aren’t already familiar with it: it has a much steeper learning curve than GUI tools, it lacks discoverability, and it only gives you a narrow view of what you’re doing that can seem like peering down the wrong end of a telescope at first. Consequently, there are also some tasks for which it is simply not suited. Furthermore, its support on Windows is abysmal.

But these sentiments of mine are only about marketing, and do not extend to day-to-day use. Over the years, I’ve actually come to appreciate the benefits of the command line. This is probably because I did a lot of work with Linux at my last job, so I had to get to grips with it. (One will recall that I was thrown in right at the deep end by being told to install Gentoo on a spare server.) And in fact, once you’re familiar with it, it offers some significant advantages for many tasks. These are they.

1. Ergonomics and speed.

The command line is keyboard-centric. GUI tools, on the other hand, are mouse-centric.

Mouse-centric environments have a nasty habit of forcing you to reach to and fro between your keyboard and mouse the whole time, which not only slows you down considerably, but can also cause repetitive strain injury. The fact that your keyboard puts a numeric keypad in the way doesn’t help much, and with some otherwise ergonomic keyboards such as the Microsoft Natural 4000, the stretch can be horrendous. That’s why many power users prefer command line instructions and keyboard-focused text editors such as emacs or vim: your hands stay in one place and let you work a lot more quickly and fluently.

Distraction is another factor. When you have to move your hand between the keyboard and the mouse all the time, it can be tempting to focus on mouse-centric tasks such as sorting out your e-mail inbox and surfing the web. On the other hand, when you’re spending most of your time on the keyboard, it’s much easier to stay focused on what you have to do without getting distracted.

2. Scriptability.

Most command-line haters think nothing of writing a long, complex howto document outlining the instructions needed to carry out a particular repetitive task, such as setting up a new project in source control, or building your project, or adding a new component from a template. The only problem with this is that when someone new comes onto the team, they have to follow these instructions through step by step, and the more steps there are to follow through, the more likely they are to misunderstand them, get one of them wrong or out of order, and end up deleting all their files by mistake.

You could write a PowerShell script to automate it — provided, of course, that the tool concerned actually exposes enough functionality through PowerShell or the command line to let you do so — but they generally don’t because that would require going to the trouble of learning a whole new language for something that you don’t do very often. But on the other hand, if you’re used to using the command line (or PowerShell) all the time in the first place, you already have a suitable language at your fingertips, and you don’t need to learn anything new. Scripting your repetitive tasks becomes the easy, logical and natural thing to do.

3. Cut and paste.

Command line instructions are much easier than screenshots to copy and paste into an e-mail, or a howto guide, or a blog post, or an instant messaging conversation. While this is inappropriate for introductory tutorials, it can save a lot of time when you need to Get Things Done.

For the past few days I’ve had to work from home because of the snow. At one point, I had to give a colleague some instructions on how to do one or two simple things with Mercurial. If we had only had TortoiseHg, I would have had to set up a remote assistance session with him, which would have been overkill for what he needed to do. However, with the command line, I was able to simply type the necessary command line instructions straight into Microsoft Office Communicator, and it was all very simple, quick and painless.

In conclusion.

The command line is not a golden hammer. There are some tasks for which it is not well suited, or which it makes considerably more difficult. But for a lot of tasks, it can provide significant benefits. Agility with the command line can still be a useful skill in a developer’s toolkit, and it is quite wrong to write it off completely.

Comments closed (1) »

Posted at 08:00 on 6 December 2010.
Tagged: programming, tools

This is the first in an irregular series of blog posts about jargon that you’ll find from time to time being bandied about by programmers who read blogs, such as my good self.

I’ll start off with a tale first told by the physicist Richard Feynman. The story goes that during the Second World War, various Pacific islands were invaded first by the Japanese then by the Americans. They set up Air Force bases, with runways and control towers and ground traffic controllers with headphones and batons to direct the aeroplanes to where they had to park up and drop off supplies. The natives were amazed: they had never seen anything like it.

Eventually, the Second World War came to an end, and the Japanese and the Americans packed up and went home. The natives, however, built their own runways, bamboo control towers and large bamboo mock-ups of aeroplanes, and stood wearing bamboo headphones and waving bamboo sticks in a vain attempt to summon the aeroplanes from the sky with their cargo. Needless to say, no planes came. They had copied the form of what the Americans were doing, but they didn’t understand why they were doing it.

Sounds far fetched? Apparently it’s a true story, and some of these cargo cults are still in existence today.

In a programming context, the term “cargo cult” is used to refer to someone doing something without properly considering why they’re doing it, or whether what they’re doing is even appropriate. Blindly copying and pasting code from tutorials and code samples on the web is one example. If you’ve ever seen something like this:

void Page_Load(object sender, EventArgs e)
{
    try {
        DoSomething();
    }
    catch (Exception ex) {
        Console.WriteLine(ex.ToString());
    }
}

and wondered what that Console.WriteLine statement is doing in a web application, which doesn’t even have a Console to WriteLine to, it’s because someone has cargo culted something over from a console application in a code sample on MSDN. Another example is claiming that stored procedures are the answer to SQL injection vulnerabilities, when in actual fact it’s all to easy to subvert this by smashing strings together in your stored procedure and exec-ing the result:

create procedure ListStudents(@OrderBy varchar(100)) as
begin
    declare @sql varchar(200)
    set @sql = 'select * from Students order by ' + @OrderBy
    exec @sql
end

One thing about cargo culting is that we all do it at some stage or another when we’re getting to grips with a new and unfamiliar technology. This is why code reviews are such a good idea: someone more knowledgeable about the technology concerned will be able to pick up on mistakes such as these and fill in the gaps in our knowledge. But the important thing is that we should always ask why we’re doing what we’re doing, and not just stick around indefinitely at the cargo cult level.

Comments closed »

Posted at 08:00 on 18 November 2010.
Tagged: jargon, programming

Getting worked up about tabs versus spaces and consistent indentation may sound completely over-the-top OCD to some people, but there are very good reasons for it. It doesn’t matter too much whether you prefer tabs or spaces, but you must never mix the two in your code. Here’s why.

Inconsistent indentation is a menace when you’re trying to see what your code does.

The reason why we indent code in the first place is so that we can see unambiguously, at a glance, where a block of code, such as an if statement or an HTML <div> tag, begins and ends. It helps us to speed-read code and zoom out from the details to the higher level design with less cognitive overload. Without clear, consistent, unambiguous indentation, it’s easy to end up getting your code muddled up and introducing bugs.

Another problem is that different editors and other tools treat the tab character within your file in different ways. Some of them display it as four spaces, some of them as eight, and some people configure it to display as something completely different altogether. If you’re mixing tabs and spaces within the same function, it can look really confusing if for some reason someone has to load it up into an editor or other tool that behaves differently from what you’re normally used to. Such as, for instance, your source control’s diff/merge tool, or a web-based system such as Trac.

Inconsistent indentation is a menace when you’re merging changes.

If your indentation is inconsistent, sometimes my only option is to reformat it just to make sense of what’s going on. Even when I don’t, the chances are high that Visual Studio will do it for me. But this causes other problems. When your source control tool merges changes, whether you’re using svn update or hg merge or whatever, it does so by comparing your code on a line-by-line basis. If you change a line from tabs to spaces or vice versa, or increase or decrease the indentation by so much as a single space, it views it as deleting one line and replacing it with another. Consequently if you’re changing between tabs and spaces all over the place, you’re going to be setting yourself up for Big Scary Merges.

Most visual diff tools give you the option to ignore whitespace when you’re comparing files, but it still makes it much more difficult to carry out the merge, since you will get more conflicts when you attempt to merge the changes automatically.

Always turn on visible white space.

The first thing I do whenever I install a new editor is to turn on visible whitespace, and I always recommend other people to do the same, so you don’t miss monstrosities such as this:

Some people object to this, saying that all the extra dots and arrows makes their source code look cluttered. This is a valid point — Visual Studio’s default colour scheme does make it look rather intrusive. If you find this to be a problem, try changing the colour of your visible whitespace to something a bit lighter. You can get away with it being quite faint: just as long as it is enough to bring to your attention any inconsistency between tabs and spaces here, or trailing whitespace at the end of a line:

Even so, working with visible whitespace can take a bit of getting used to. But get used to it you must. Otherwise you’re just going to cause confusion and make life difficult not only for yourself but also for anyone else who has to work with your code.

Comments closed (3) »

Posted at 08:00 on 15 November 2010.
Tagged: programming

A lot of people complain about the stress of the daily commute. Far fewer people research the different options that can make it less stressful however.

For example, travelling into London from Horsham, everyone piles onto the same train at 07:25, or at 07:29 at Littlehaven. It’s a reasonably fast train, getting you to London Victoria in only 50 minutes, but it’s probably the most overcrowded service on that route. I was once told (by a conductor on a different train to whom I once got chatting) that the Southern Railway staff refer to it among themselves as “the sardine can.”

It is possible to get a decent seat on it (i.e. a window seat at a table in one of the nicer carriages) from Horsham, but you need to know exactly where to stand on the platform, arrive in plenty of time, and exercise a streak of me-first hubris which doesn’t endear you to your fellow passengers. If you get on at Littlehaven, it’s even worse, because thanks to a short platform, you have to walk the entire length of the train, and even then it’s a bit of a lottery what kind of a seat you’ll get. On a typical day, perhaps a hundred or so people pile onto the train at Littlehaven, most of them through a single carriage at the end of the platform, which doesn’t endear them to the Southern Railway staff who are constantly nagging us to “please use all available doors.” As you can imagine, this is also a pretty high-stress exercise, and consequently I’ve generally tried to go from Horsham rather than Littlehaven, even though it’s the best part of a mile further and I have to leave the house ten minutes earlier.

Just the other week, however, I decided as an experiment to try a slightly different train, which leaves seven minutes earlier. It’s the stopping service which calls at almost every station between Horsham and Croydon, and it arrives ten minutes after the fast train, but it’s almost totally empty when it arrives at Littlehaven at 07:22, so you get the pick of the seats. The additional fifteen minutes also makes it much easier for me to get some extra sleep on the train (this makes a massive difference to my day, especially if I haven’t had too good a night’s sleep), and because it arrives in London Victoria at 08:30, it still lets me arrive at my desk by nine o’clock. All in all, it’s been such a resounding success that I’ve started making it my regular train.

And of course, this is also a win for people who take the sardine can, because it means that there’s one more seat available for them.

Comments closed »

Posted at 08:00 on 25 October 2010.
Tagged: commuting

No matter which source control tool you’re using, sooner or later you’ll encounter a merge conflict. When this happens, a decent graphical merge tool is a must-have.

There are two different types of merge tools. Two-way merge tools show you your version of the file and the other person’s version of the file side by side. Three-way merge tools also show you the original file in the middle. This helps clear up a lot of confusion, since you can see what the original file looked like before anyone did anything to it.

So far, I’ve been using TortoiseMerge as my merge tool of choice, since it comes with TortoiseSVN, it’s familiar, it’s reasonably usable, and it is not too ugly. The only downside is that it’s two-way, rather than three-way. TortoiseHg gives you kdiff3 by default instead, which is a three-way merge tool, but it’s an absolute eyesore and its usability leaves a lot to be desired. Up to now, I’ve always switched it out in favour of TortoiseMerge.

Recently I came across the Perforce merge tool P4Merge (hat tip: Novaleaf Game Studios) and I must say that I’m impressed. It gives a very clear, intuitive view of what’s changed, with a text editor underneath that lets you resolve the conflicts easily. The icons to the right hand side of the text editor allow you to select which version you want to cherry pick. Oh, and visually, it looks fantastic.

P4Merge comes with the Perforce client tools which are a free download: if you’re not using Perforce itself for source control, select only the merge tool on the installation wizard and deselect everything else.

Once you’ve installed P4Merge, TortoiseHg will automatically detect it and list it as an option in the TortoiseHg configuration dialog or merge wizard. If you’re using Subversion or Git with their respective Tortoises, you need to specify the command line in the options dialog: Using a cool merge tool with SVN or GIT tells you how. Team Foundation Server is somewhat more complicated, but still doable: Using P4Merge with Visual Studio 2008 and TFS explains how to tackle it.

The only downside next to TortoiseMerge is that the option to cherry-pick changes only works on the block level, rather than on a line-by-line basis. However, since the resolution panel at the bottom is of course a free-form text editor, you can easily copy and paste as necessary, so this is no big deal. I think I’ll be using it as my merge tool of choice from now on.

Comments closed »

Posted at 08:00 on 4 October 2010.
Tagged: source control, tools

Programming is full of dilemmas.

You’ll be deep in concentration, working on your new application, adding some new payment options, when all of a sudden you notice a potential race condition in a nearby method that might cause customers to be billed twice. You know it’ll take all of two lines to fix, so you pop in the fix and carry on with your new functionality.

A few minutes later, you notice that another method is pulling in an RSS feed from a hard coded, and outdated, source, so you stop to extract it to a configuration setting and use the more up to date feed.

You finish fixing up your new functionality, then you come to check in your code. Now, you have a problem. You have three separate changes tangled up in your working copy.

Most developers would simply bundle all three changes into a single commit, possibly only leaving a commit summary (you do fill in your commit summaries, don’t you?) saying “Added some new payment options to application.” This is misleading, because it doesn’t say anything about the race condition or the RSS fix.

You could say “Added some new payment options to application, fixed a race condition and used a more up to date feed.” But this doesn’t make it all that clear which part of your commit fixes which problem. Someone looking through your history six months later might see your race condition fix has introduced a regression, not realise that it is there to fix a race condition, and revert it to what it was before.

You really need to observe the Single Responsibility Principle, and split the three tasks into separate commits.

So, what do you do?

With traditional source control tools, you are likely to be told, “You should have shelved your changes, reverted your working copy, and performed these tasks as separate commits. Or, if your source control tool doesn’t support shelving, you should save a patch, then revert your working copy, then make the new change, then re-apply the patch.”

There’s just one problem with this bit of advice. It is inefficient, and a total mismatch to the way your average programmer’s brain works.

To see why, let’s rewind your last half hour of coding and start again.

You’ll be deep in concentration, working on your new application, adding some new payment options, when all of a sudden you notice a potential race condition in a nearby method that might cause customers to be billed twice. You know it’ll take all of two lines to fix, but you need to keep these changes separate.

So you shelve your changes, revert your working copy, getting prompted to save/reload/merge your files in the process, and then Visual Studio insists on reloading your entire solution because you had changed something in the .sln file. And since your solution contains more than three projects and they reference more than two assemblies that aren’t in the GAC, it takes forever to reload and you’ve got distracted onto something else while you’re waiting.

By the time you manage to start editing your project again, you’ve been completely knocked out of the zone, and you’ve forgotten why you shelved your changes in the first place.

You see? All the so-called best practice advice about shelving, reverting your working copy, and all that, overlooks one very important fact about programming, namely that it is a mentally intensive discipline that often requires you to juggle several complex details in your mind at once, and even small diversions, such as having to save files and wade through menus to find your shelving tool then think of a name for your shelve set, can have a detrimental effect on your workflow. It adds to the mental burden on you and makes your job more difficult. It’s not a best practice at all, but a workaround for the fact that you don’t have the right tools for the job.

Wouldn’t it be better to just to get the changes down as you notice them and then use a tool that lets you sort out your commits later, going through all the changes you’re checking in, cherry-picking them into a series of separate patches?

Git users wax lyrical about the index, or staging area, because it is designed to solve just this problem. It provides an intermediate store between your working copy and your history, where you can stage your changes, not just one file at a time, but one hunk at a time, using the command git add -p. Once you’ve staged your changes in this way, you can then commit them as a separate, logical change set.

Mercurial has a similar feature in TortoiseHg called “hunk selection.” By double-clicking on a change in the “Hunk selection” tab on the commit dialog, you can include or exclude it from the check-in. If you’re a command line freak, the record extension does something similar, and the crecord extension allows you to take it down to the line-by-line level.

You can click on “Commit preview” once you’re done to see what’s going to go in your commit.

There’s just one problem with all this though. As Eric Sink points out, you’re checking in a version of your code which you’ve never tested. This is a bad practice, and it can bite you if you ever need to run git/hg bisect to track down a regression.

So let’s sum up what your options are so far.

• Check in everything in a single commit at once. This is bad practice.
• Use git add -p or hg record/TortoiseHg’s hunk selection to separate out your changes into separate commits. This is also bad practice.
• Use shelving and patches to separate out your changes. This is a hack, which slows you down and risks knocking you out of the zone and making you lose track of your changes altogether.

So is there anything we can do to fix this? As a matter of fact, it turns out that there is.

One of my favourite features of Mercurial is the mq (Mercurial Queues) extension. This may sound a little esoteric, but what it does is quite simple. You can put a whole series of commits into a separate staging area, where you can edit them, reorder them, apply them, unapply them, chop and change them, split them up or combine them together, and of course, most importantly, run your unit tests on them, to your heart’s content before applying them to your master repository.

Let’s just say I am working on some changes to my Comment Timeout WordPress plugin. I’ve done two different things: updated the version number to 2.1.2, and tidied up some code formatting. I want to separate these into two different commits. First of all, I select the hunks that I want to go into the first commit, and then I type a name for the patch into the “QNew” box (keep this short, a couple of words should do):

You’ll note that the “Commit” button changes to “QNew” to indicate that your next commit goes into the patch queue. Clicking this will automatically show you the patch queue and change the button to “QRefresh”:

You can change the message, or edit the files, or select and unselect hunks to your heart’s content, then click QRefresh. Then you can add a second commit by typing another name into the QNew box:

Clicking the “QNew” button creates a second patch:

Okay, so now we have a whole series of patches. It’s a bit like the Git index, except that rather than having just one staging area, you have several, all stacked one top of each other. In the Repository Explorer, these revisions appear as a regular part of your DAG:

The yellow label “qparent” indicates the parent revision on top of which the patch queue is being applied; “qbase” indicates the first patch in the queue; “qtip” indicates the last; and the blue labels give the names of the patches. You could push them to another repository if you wanted, but I don’t recommend this. Keep them on your own machine for the time being.

Now that we’ve separated out our commits into a series of patches, we can get on with the job of placating the people who are worried about best practices. Namely: testing each patch before applying it.

First, double click on “[qparent]”:

You’ll note that our two patches have both dropped below the line, and they’re now greyed out. If you take a look at the repository explorer, you’ll see that there’s no sign of them:

The last revision has been marked in bold to indicate that that’s the one where your working copy is at.

If you double click on “tidy up” it will move above the line and turn blue again, to indicate that your working copy has been updated to this version:

That patch is now where your working copy is at. Do whatever testing you want to do on it, then click on the next one to apply it:

Once you’re satisfied that all your patches are ready, right-click on any of them and choose “Finish applied”:

Hey presto! Your work is now all committed to your repository, ready to be pushed, pulled or otherwise shared with the big wide world.

There are other things you can do with patches in your queue which I haven’t covered here, such as reordering them, or combining two or more of them into one.

Patch queues and hunk selection are two extremely powerful features of Mercurial. While they require a little bit of care and attention in order to adhere to best practices, this is no more arduous than the discipline needed for any source control tool, and they can provide a significant productivity boost, simply because they let your tools work around you rather than forcing you to work around your tools.

Comments closed (3) »

Posted at 08:00 on 30 September 2010.
Tagged: source control

A lot of developers love code generation. Some pretty smart ones hate it. The following is my observation on the matter.

Code generation done right can save masses of time. Code generation done wrong has the exact opposite effect.

Here is what code generation done wrong looks like. I am asked to help out with your project, and told that it’s corrupting data. After a bit of rootling around, I find two hundred business service classes, each containing numerous very similar looking methods that all follow this pattern:

public bool SaveWidget(Widget widget) {
    try {
        dataSession.Save(widget);
        return true;
    }
    catch (Exception) {
        return false;
    }
}

Pffft. Pokémon exception handling all over the place. No wonder it’s corrupting data.

If you’d left your templates in your solution, with a comment explaining where to find them, I could get rid of Pikachu and Bulbasaur and friends in five minutes. But since you didn’t, I have the thankless task of spending the rest of the week going through the whole lot by hand.

Here’s how to do code generation right:

1. Do include a header at the top of each autogenerated file, indicating (a) that it has been autogenerated, and (b) what it was autogenerated by.
2. Do include your template files and/or scripts in source control.
3. Do re-generate your autogenerated files as part of your build process, before running your unit tests.
4. Don’t edit autogenerated files manually. Use partial classes and partial methods instead.

By following these four simple rules, you can ensure that if someone comes to your project at a later date and finds that there is a fundamental flaw in your generated code, they can easily fix it.

Comments closed (2) »

Posted at 08:00 on 20 September 2010.
Tagged: antipatterns, tools

I was hoping that Diaspora would prove to be a Facebook killer, but somehow, I don’t think that’s going to happen. Their choice of technology stack — Ruby on Rails with a MongoDB back-end — has seen to that.

Rails is something of a darling among geeks, and it is great for web applications that you only install on your own servers. So too are the plethora of NoSQL databases that seem to be all the rage among that kind of crowd these days. However, they are totally unsuitable for distribution to the general public.

Why? Simply because most cheap’n’nasty web hosts do not support them.

This is something that the WordPress core developers understood. Their decision to continue supporting PHP 4 long after its end of life brought howls of derision from WordPress plugin developers everywhere, but they were thinking first and foremost about their users — people with only limited computer skills who would deploy WordPress on their own shared hosting accounts. They wanted to get the widest possible audience.

Diaspora should be targetting run-of-the-mill Facebook users, not geeks. If it had been written in PHP with a MySQL back end, it would be more likely to see widespread adoption. However, by opting for Ruby on Rails, they’ve placed a barrier to adoption in front of the kind of technically-capable-but-not-particularly-geeky users on a tight budget who would otherwise set up Diaspora seeds for local schools, churches, clubs and so on. They risk turning it into a geek ghetto.

Sigh. Perhaps I’ll just have to put up with Faceborg after all.

Comments closed »

Posted at 08:00 on 17 September 2010.
Tagged: programming languages, social networking