Sep 20, 2010

Is The Way Hiring Happens Changing?

For those who don’t know (or just plain forgot) I run a weekly podcast for developers at and in one of the episodes I talked with Matthew Wills about an idea I blogged about – the Developer Experience Index and wether we need one or not to improve the way we find and hire talent and raise the general skill level of the industry.

Interestingly I just ran across an opinion piece on GigaOm about the way hiring is changing and wether resumes are headed the way of the dodo -

It’s worth having a read, and most interestingly talks about the social networking aspects of hiring and how LinkedIn and your online presence in open source efforts can be a reflection of how well respected you are and wether you’re a good potential hire or not.

I still don’t think we’re there yet, but the aggregation of social networking information into a ranking of some kind is a very interesting approach to finding people, though likely will tend to favour those with the best connections or most popular projects, not necessarily the best developers for your team.  Still, if nothing else, it reflects passion and involvement, and without passion for what they do a developer is pretty much worthless.

Sep 15, 2010

How To Fix Branches After Migration to TFS2010

Let’s say you’ve just migrated your code from another version control system to TFS2010 by grabbing the old code, copying it into your workspace as is, and then checking it in to TFS as a single massive import.  It’s a really easy and common way to do tip migration.

When you do this, you will notice that all your branch relationships are missing and source control will look something like this:


The old system had Trunk branched to Feature X and Version 1, etc, but now there’s no relationships and trying to merge from Trunk to a branch brings up a dialog with no targets.


Bummer, huh?  Yeah, but what did you expect would happen? You’ve just imported a bunch of folders from the file system and TFS has no way of knowing that they’re branches.

We need to let it know which folders the branches are and the relationships between them.  Here’s how we do it:

Step 1: Convert Folders to Branches

Right click the trunk folder (or whatever your root branch folder is) and convert it to a branch.


It should now look like this:


Do this for all the other target branches you have.  e.g. Feature X and Version 1.

Step 2: Perform a Baseless Merge

Next, perform a TFS baseless merge to establish a relationship between the parent branch and the child branches.  Don’t worry about the contents, we’re only going to merge the folder, not it’s contents.

TFS baseless merges are performed via the command line, so open up your VS2010 command prompt and do the following:

cd <workspaceFolder>
tf merge /baseless <trunk> <childBranch>

Check in your pending changes.

Step 3 Reparent Child Branches

At this point we have a loose link between the branches but the relationships are still not finalised.  We need to fix that.

Select your child branch in Source Control Explorer and from the File menu choose Source Control –> Branching and Merging –> Reparent...  NOTE: This is not available via the context menu in Source Control Explorer.


In the dialog box, choose the appropriate branch as the new parent.  There generally should only be one, unless you have done multiple baseless merges.


Now look at the properties of your child branch and you should see something like this:


Excellent!  If you go to your Trunk branch and in the branch context menu choose View Hierarchy. You should see something like this:


Brilliant.  Now we’re all done.  You can carry on using TFS as you normally would.


Sep 13, 2010

Aw, Snap! (or How I got Hacked)

So there I am surfing the web and catching up on some blogs and news when I notice my Skype icon blinking away at me in the windows taskbar.  Hmm, someone’s sent me an IM, thinks I only to discover that Skype logged me out.

That’s weird I say to myself.  I guess I’ll just log in again. Click.  What? Invalid login?  Hmm.  Try again. Click! Click!! Click!!!  Dammit! What’s going on. Oh look – I just got an email.  It’s from Skype.


Aw, Snap!!!  (or insert expletive of your choice).

Yes, my Skype account had been hacked and on gaining entry the attackers had immediately changed the account password and email address on me, blocking me out.

Long story short, the good news is that after immediately contacting Skype they restored my account to me (thank you!!) in less than 2.5 hours and it only cost me a few euro in Skype credits and a few hours of panic.  Yet the whole thing was entirely preventable.

But How?

So the obvious question: how did it happen? Simple – I was stupid and lazy and forgot some of the basics of online security.  Doh!

You see, when I’d first used Skype years and years ago, it was way back in it’s early days and at that time I used an insecure password.  It was a dictionary word of all things – I know! I know! You don’t have to tell me! But because I was just trying the thing out I figured that if it was useful then I’d go back and change my password later on.  At the time I’d also clicked the auto-login option and let Skype sign itself in for me.

Unfortunately, because I never used it much early on I never went back and changed the password, and over time forgot what it was.  Kind of like when we tell ourselves we’re going to write those unit tests once we get this code working.  The reality is that we get distracted or do something else, forgetting to go back and clean up after ourselves. As the saying goes, the road to hell is paved with good intentions.

Of course, at any point I could’ve done the “I forgot my password” routine, but as Skype kept logging itself in, I just forgot about it and fixing the password drifted to the bottom of my “stuff I should really do to be a good human being but that I’ll likely never get around to doing because I’d rather be sleeping or eating or having s..” well, cough, ahem, you get the idea.

Using a real word for a password all those years ago and not taking the one measly minute needed to fix it is pretty lazy of me, huh? Yet so many people do it.  And it could’ve turned out so much worse.  Thankfully that password wasn’t used anywhere else, so I didn’t have to worry about the hackers using that to break into other accounts of mine.

Of course, what irks me most is that these days I use KeePass and I’ve even blogged about it in the past (though I now use DropBox instead of Mesh for syncing), and I’ve read plenty of tales in the past of accounts being hacked and how easy dictionary based attacks are to pull off.  And yet here I am.  A victim.  Grrr. Dumb, Richard. Dumb!

So what are my lessons?  What do I learn from my dumbicity?

1. NEVER.  Not ever.  Not even on my deathbed will I use a weak password for anything.  Even if it’s a throw away account to register for some software trial that I’ll never use again.  I have Keepass and it can generate  passwords for me that are safe.

2. Never reuse passwords across sites.  Once a password is compromised on one site it’s compromised everywhere.

3. Keep my OpenId accounts extra secure.  If I lose an OpenId account I’d be really messed up, especially as these days the use of OpenId is increasing and more and more sites are accessed only via OpenId accounts.

4. Go and change all those other passwords I have just in case.  I can’t think of how many other sites I’ve used over the years that I no longer visit and where I may have old passwords laying around.  If one of those sites was compromised and I’ve reused that password elsewhere and not realised it, what else can the attackers get to?

So, enough beating myself up about this. I’ve learned my lesson.  Hopefully you can learn from my mistake as well and avoid being a statistic like me.