GrinGod [dot] Com

I’ve been developing with SharePoint for about 9 month now, and by developing I don’t mean airy-fairy SharePoint Designer drag-and-drop, I mean proper getting your hands dirty in code because SharePoint doesn’t have an *cough* out of the box *cough* feature that does what you want.

Mostly, deployment is done in two stages, firstly to a UAT box and then to a Live box.  Obviously the most efficient way to do this is to bundle your features into a solution which can easily be deployed onto any number of machines.  But, it does mean you have to make sure you’ve got everything right.  Untangling mistakes in your code can be a right royal pain in the arse.

By the time you’ve developed your solution, tested it out, deployed it to UAT and tested it again you should be fairly confident that when you come to deploy it on the Live server things should go pretty smoothly.  And, touch wood, to date things have gone smoothly.

But I still can’t get over that rush of adrenaline that comes with clicking “Activate Feature” after deploying the solution on Live.  In the second or two whilst the page waits to reload my mind runs through all the possible things that could go wrong and how long it would take me to unpick the changes my code might have got half way though.  Then the page finally loads…..

….. “Feature Activated”, phew!  Time for a lie down to clam my nerves.

I’ve seen this time and time again and I’m sure just about every developer out there has seem the same sort of thing:

try {
    //many lines of code
catch (Exception ex) {
    throw new Exception("Something went wrong dude!");
}

This is probably the single most un-helpful piece of code a developer can write.  All you are doing is making you life and future developers lives harder when it comes to debugging.  The whole point of the try…catch block is for times when you know an exception may happen and it allows you to gracefully handle it without the whole system crashing to the ground.

So lets have a closer look at what’s wrong with this code:

Continue Reading »

Recently I’ve had reason to take an code library written in C++ and port it to C#.  Whilst I dabbled in C++ on a compilers course at university, I hated it then and I still hate it now.  I personally think it’s an abomination and should be consigned to the great garbage collector in the sky.   Whilst I can just about read the C++ syntax there is a lot that I don’t understand about it.

The library I was porting had semi reasonable documentation outlining what classes exist and their methods and a brief description of the overall usage.  This gave me a good starting point, however the documentation didn’t include example usages and expected results, for this I was forced to delve into the code.

One development paradigm I have been interested in but have been unable to find a decent project to test it on is Test-Driven-Development and this seemed like the perfect project to try it on.  So I set to work on the first iteration getting the test set up.   Without knowing exactly what results I should be expecting I was finding it hard going, so once again I dived back into the old code.

Thankfully, the developers of the C++ library had create a fairly comprehensive set of unit tests and with my limited C++ knowledge and a text editor with RegEx Find & Replace I was quickly able to convert their unit tests into NUnit based unit tests.

For example, what started out life as:

 1: void test_row_multiply_change(void)

 2: {

 3:  row r;

 4:  RINGING_TEST( ( r *= change( 6, "X" ) ) == "214365" );

 5:  RINGING_TEST( ( r *= change( 6, "1" ) ) == "241635" );

 6:  RINGING_TEST( ( r *= change( 8, "X" ) ) == "42615387" );

 7:  RINGING_TEST( ( r *= change( 5, "3" ) ) == "24651387" );

 8:  

 9:  RINGING_TEST( row( "214365" ) * change( 7, "5" ) == row( "1234675" ) );

 10: }

Quickly became:

 1: [Test]

 2: public void TestMultiplicationByChange()

 3: {

 4:  Row r = new Row();

 5:  Assert.AreEqual((Row)"214365", r *= new Change(6, "X") );

 6:  Assert.AreEqual((Row)"241635", r *= new Change(6, "1"));

 7:  Assert.AreEqual((Row)"42615387", r *= new Change(8, "X" ));

 8:  Assert.AreEqual((Row)"24651387", r *= new Change(5, "3"));

 9:  

 10:  Assert.AreEqual((Row)"1234675", new Row("214365") * new Change(7, "5"));

 11: }

Now, with a full set of unit tests at my disposal I was quickly able to bash away at the library and very quickly got working code without the need to trawl through ghastly C++ code.

Hooray for Test-Driven-Development and three cheers for Test-Driven-Porting.

ps. The library I’m porting is an open source library for Bell Ringing – yes I know I’m a geek but anyone that has followed everything else in this post must also be a geek .  Once I’m finished I will be releasing my code under an open source license as well, I just need to pick the right one.

pps. I may have exaggerated my hate of C++ a little.  I believe all languages have their place, even the esoteric languages like LOLCode.