Version control for the masses

Version control is one of those weird, geeky things that never really gained much ground in non-geek fields, despite the fact that it’s blindingly useful. Even educational institutions (at least the ones I’ve been able to observe) seem to prefer to omit so much as a mention of it in their technical courses. I can’t really give a reason for this, but it does at least give me the excuse to write a post about version control and kick it off with a rant.

So what’s this version control thing?

Version control (or source control) is nothing more arcane than keeping copies of your work as you make changes to it. On the surface, it’s all straight-forward; make a copy of every file you have before you make any changes to it. That way, if you seriously mess up, you can always fall back to something that worked before, or at least compare your broken copy with one that used to work so you can figure out where it went off kilter. Your client wants the image he told you to throw away two days ago? No problemo – out comes the backup. Accidentally deleted half your thesis and closed the word processor? No problem – out comes the backup.

Now, in the real world, it’s not so easy. Unless you have an iron will, a black belt in filing, and a zen-like ability to name files in a sensible way, you’ll be swamped with a huge number of backups with similar looking names. Something that’s impossibly difficult to find, might as well not exist at all. We want to get the goodies, but really need to keep all those backups out of our way. Luckily there are like, loads of version control systems out there to do the heavy lifting for you.

The rest of this post will be about how to set up a version control system for a single user. We’ll use Subversion, because it’s free, works great, and because I like it. Since we want to keep things as slick as possible, we’re not going to use raw Subversion though – we’re going to use TortoiseSVN, which is also free, also works great, and has nice coloured icons to boot. This neat tool lets you do most of the stuff you want Subversion for, but it lets you do it from Windows Explorer, rather than the command line.

Read more »

In the beginning were the words, and the words were "It sucks"

In his Tech-Ed session “Why software sucks”, David Platt was explaining why, in fact, software sucks. The reasons were not some mystical ramblings, or some pseudo-scientific best guesses. It was all solid common sense; problem being that, since designers and developers often know the conventions too well, we will often assume, without a second’s thought, that our users know the same conventions. I was sufficiently impressed by the session (Delivered in an hour long chunk of what can be called good stand-up comedy entertainment. Reminded me a little of George Carlin, really 🙂 ), to buy his book.

Do you really want to delete this file? Hmm, no, what I really wanted to do was give it a back massage…

To take one of the examples from “Why software sucks” and give it shape: consider a confirmation box. You know the kind… “Do you really want to …?”. Can’t stand the damn things myself. Platt makes a few well considered arguments against them; the main ones being:

1. If a user clicked the button, he or she REALLY wants to do that action.

2. Unless the button was clicked accidentally, in which case, your user interface design sucks.

I’ve been working on a WordPress contact management plugin recently, and decided to slip this idea in. The delete button for each contact starts off disabled, and it is only enabled while the user holds down the CTRL+D key combination:


And that’s that, once you’ve clicked, it’s deleted with no further confirmation. Once this gets tested for a while, I’ll post any further observations here.

I’ll probably change the delete icon to a more conventional x, since the little guy with a stop sign doesn’t strike me as being an obvious “delete” indicator. Then again, I guess I’ll wait to see what comes out of the test. I’m not my user, so I’ll see what they think first.

Is this thing on?

Download sample code here (New window)

There’s been a project knocking around the back of my head for a while. I keep putting it off, doing some work on it now and again but never really settling down to really do it. This long weekend turned out to be one of those occasions; I’ve just finished playing Fallout 3 (Awesome game, the ending left a slightly bitter taste in my mouth though) and ended up with nothing to do. Visual Studio to the rescue…

Now what?

If you ever worked on an application that requires Internet connectivity, you will have had to handle situations where the connection may be unavailable for certain periods of time. Sometimes you can get by that by trapping an exception; I know I have, though I still find that particular solution to be somewhat inelegant. What I wanted was some way to monitor the state of the connection and keep track of it. This way, if you need to send a message for example, you can have your application decide whether it should try to send it right away, or whether it should stash it away till the connection becomes available. This post is about how to determine whether a connection is up or down, and notify the application when the state changes.

Doing it the managed way

There is a method in .net, NetworkInterface.GetIsNetworkAvailable(). This method will tell you whether there is a connection going out of the machine, and it seemed to be the ticket. Unfortunately (or fortunately – this would have been a really short post otherwise), in my case, it wasn’t. You see, when we’re working off a LAN, we can have local only connectivity, or low connectivity. This means that the machine can talk to the router, but cannot access the Internet at large; the method still returns true in this case. If you’re working on an intranet application, this may be ok for you, but I wanted something bigger.

Going native

My friends have a long standing joke. It goes something like, “If someone invents a piece of hardware to wipe your bottom, the Windows API probably already supports it.” (The exact quote is unsuitable for mixed company). The windows API does, indeed, grant you nearly god-like powers over your system, and nearly anything Windows can do, the API can too. Since Windows can tell when there is no connectivity to the web (the dreaded “local only” icon), I figured that would be the next port of call in my search. Sure enough, wininet.dll defines a function InternetGetConnectedState

Ouch. We still have the same issue… it doesn’t really care about the “local only” business. At least, it gives us some additional information, such as whether the connection is through a modem or a LAN.

Hackety-hack-hack time

I’m still fairly confident that there’s a direct way to get to this information, but since I just want to get this to work right now, I’ll fudge it up a bit.

Using the wininet.dll function, we can tell whether we’re connected to a modem, connected to a LAN, or not connected at all. Not connected means just that, so that’s easy. For modem connections, I’ll assume that it’s either connected to the Internet, or not connected at all (You’ll have to excuse my blatant ignorance of networking hardware. Drop me a comment if you know this is the case). This just leaves us with the LAN condition to deal with.

The machine that goes PING!

When we know we’re connected to a LAN, but not how far we can go, we have to resort to the time honoured mechanism of the PING. All hail the mighty PING.

A ping is simply a very short message that’s sent to the server. If the server accepts the ping, it just echoes it back. It’s a protocol for machines to determine if they can see each other over a network. In .net, the ping is represented by a Ping class, and returns a PingReply:

   1: if (isLan)
   2: {
   3:     PingReply reply = pingOfLife.Send(PingTarget, 3000);
   4:     return reply.Status == IPStatus.Success;
   5: }

This sends a ping to a URL identified by the PingTarget property, and waits up to 3 seconds for a reply. The URLs for Ping don’t take a protocol specifier, so you’d use, say, rather than

You will notice that in the sample code and the example above, we’re only assuming a successful connection if the reply to the ping is successful. This is a simplification. In reality, the ping is checking whether we can access the ping target, irrespective of whether the rest of the Internet is accessible. If the target server is down, you’ll get a “No connection” result.

When you think about it, it doesn’t matter in most cases. You only care about whether your application can reach its server, not whether it’s got access to random web pages.

What else?


This seemed to sort it out for me. You can find the entire source code in the sample project. The ConnectionState class in the sample also contains events you can hook into so your application will get notified of state changes.

Download sample code here (New window)

kick it on

Entity framework learning guide

Christmas is here early this year! Zeeshan Hirani has released his 514 page pdf guidebook about the Entity Framework. Thanks!

Keep code behind clean

Download the sample code here

Last week, Marlon blogged about how to avoid adding command binding code to code-behind files. The idea is both simple and great, and allows you to keep your code behind nice and clean, and your layers separated. There’s only one (and yes, I’m being very anal here) thing that bugged me with it:

DataContext = new ViewModel(new SampleModel());

or, for that matter, “DataContext = anything”, is still in the code behind class. This can easily be sorted out with some easy data binding and a supporting class.

First, create a class that will contain your controllers. You can create a factory class, or, simply a class which exposes your controllers. To demonstrate this, I’m only using a class with a static property:

public class ControllerProvider
    static ControllerProvider()
        WindowController = new WindowController();
    public static WindowController WindowController { get; private set; }

They don’t get much simpler than that.

Next, bind the data context in your window:

<Window x:Class="Commands.Window1"
    DataContext="{x:Static local:ControllerProvider.WindowController}"
    Title="Commands" Height="200" Width="200">
        <Button Command="{Binding MyCommand}" Content="Execute command"/>

If we look at the codebehind for this, we have only the usual, Visual Studio generated code:

public partial class Window1 : Window


    public Window1()


Is this really worth it?

Yes. No. Maybe. I think it is, because I prefer to keep everything together. Besides, the idea is to keep the code behind as clean as possible. If people have to touch this class to add the data context, they may be tempted to add more stuff in there. Then again, it’s very probably a matter of preferences.

Download the sample code here