Garry Pilkington

Well the holiday season is finally upon us, and I would like to take this opportunity to post a list of applications that I personally have found useful over the past 12 months. There are some classics in there, but a few surprises. Have a look, there may be something of interest to you. So, have yourself a ‘Merry Christmas and a Happy New Year’.

In previous posts I have covered getting cc.net up and running, combining NUnit reports with cc.net and generating documentation automatically as part of the build process. In this post I want to briefly describe how to get your unit test code coverage integrated with cc.net.

It is funny how things work out, a disaster can lead to opportunities. Last month my main pc at home somehow got a corrupt hard drive and at first I thought I had lost all my private data (family pictures, documents etc), the drive wasn’t backed up as it was a mirrored drive, which I had thought would be an alright disaster recovery mechanism. It happened while I was upgrading to Server 2008. I broke the mirror and disconnected them. So the drives themselves weren’t connected at the time of upgrade, it was when I reconnected them after the upgrade was successful, the OS just couldn’t see them, maybe a corrupt partition table. I even rolled back to Server 2003, but nothing. The most important thing was that I had to recover that data somehow. This lead me to a piece of software called Active File Recovery which is just so simple to use. To cut a long story short I managed to recover all my missing data. But one thing that really made me think was the fact that this software could see my data and all previous owners data (it was a 2nd hand drive bought from a computer fair).

This morning I read a post by Davy Brion who was explaining a technique to test private methods. Although the post was interesting, it was a comment by Rafferty Uy that got me thinking. He suggests that you make your method protected instead of private and have the testing class inherit from this class. There is much debate as to whether you should be testing private methods at all, and as I am fairly new to unit testing, I have only ever tested my public methods.

If you don't already know, the Synchronization Framework team has just released the CTP for v2.0

The time comes in every developers life when a higher up requests what they think is a minor change. You think about it and agree also thinking that it would not take too much time. It is only when you get back to your desk, check out the code and look to where the change is going to happen when you realise the worst. If you make a change here what repercussions will you introduce, is it possible you could introduce a defect in the code which could then go on to really crap up the application. This happened to me last week, luckily I already had some unit tests in place covering the code which was in need of changing. I knew what the method in question was going to return, and so did the unit tests. I made the necessary changes and re-run the tests. Fantastic they all pass. The code checked in, the tests passed again and the nightly build was successful. The moral to this little tale? Introduce unit tests as soon as you can to test your code. As Ian Cooper points out:-

I had one of those 'wow that's cool' moments last weekend. This sounds really sad and you may think that I need a life, but I was playing with the code for a basic singleton pattern found at:-

It is in the news so much recently that there is no avoiding the fact we are either in or about to go in to a recession (here in the UK that is). There is already job losses in the tech industry, wether these losses were going to happen anyway, and now is a good time to blame the economic outlook is not a topic I am trying to cover; this has been covered here. What I am trying to address really is how do you protect your job? And if you do loose your job, how do you improve your chances of getting straight back in to employment?