I love a cold beer. Not just because it’s refreshing and makes me worry less about the world’s problems, but also because of beer’s fungibility. Let me explain; I can go down to the store and buy a beer and it’s pretty much the same as any other beer I might purchase elsewhere. Sure, there are different standards of beer and I’m going to pay a few dollars more for my favourite Little Creatures than I am for VB but in essence I’m still getting hops and yeast with some water.

The point about fungibility is that beer is the same basic product no matter which one it is you’re drinking. In short, beer is a commodity.

I was a little confused this week as to why ReSharper was recommending using implicitly typed variable declarations in a VS2010 solution targeting .NET 2. Somewhere in my mind I had directly associated the “var” keyword with the release of .NET 3.5 so this looked a little odd to me:

As it turns out, the var keyword is a feature of the compiler, not the .NET CLR. The same is true for automatic properties and object initialisers. The bottom line is that you can use these features in VS08 or VS2010 and the compiler will happily go along with it and translate the code to .NET 2.0 compatible syntax in the object code.

There’s an excellent post on Shahar Gvirtz's blog where he disassembles code using this syntax in Reflector to reveal plain old .NET 2.0 syntax. So in short, implicit typing is fine for anyone running a recent version of Visual Studio and, as usual, ReSharper is correct in identifying this as an opportunity to polish the code.

Here’s another one of those Subversion idiosyncrasies which threw me the other day and I couldn’t readily find an answer for. When committing a changeset I kept getting the error “Can’t create directory” followed by the the path of the repository on the server then “The system cannot find the path specified”.

The first thing to get clear is that this is a Subversion error, it’s not related to the local working directory nor is it related to Tortoise SVN.

It starts with that sinking feeling and all sorts of questions running through your head:

When did I last backup?

Did I include everything?

Does the backup actually work?

When did I last try restoring it?

How much unrecoverable data could I have lost?

Losing data can be an absolute stomach churning experience. Those first moments when the penny drops and you realise you’ve got a big, big problem are absolutely nightmarish and without a robust backup strategy it’s just a matter of time until you experience this firsthand.

This last happened to me a couple of years ago when a disk had a catastrophic failure and refused to boot. Slaving the disk off another machine didn’t do much good so it was off the data recovery specialists and let me tell you, this is not cheap and it’s not fast. I used a group in Sydney called Payam Data Recovery and whilst their service was fantastic, I always felt like each conversation was akin to speaking to your doctor and expecting him to tell you you’ve got a terminal illness and that you need to “start making arrangements”.

Anyway, I got to thinking about the whole backup strategy thing again recently after both Jeff Atwood and Phil Haack suffered data loss on their blogs after a server hardware failure. Being pretty popular guys this lead to a lot of feedback and suggestions from the community as to how to both retrieve their data (some very innovative feedback there!) and how to implement a suitable backup strategy in the future. It brought the whole disaster recovery topic back into focus for me so I thought I’d share my approach which personally, I think works pretty well.