Another .NET Developers Blog

My company favours Java over .NET. Java is seen as a scalable enterprise platform, whereas .NET is seen as a toy platform, only good for rapid prototyping.

I think that .NET is great platform! It is everything that Java is, and more. The base class library is great, with many time-saving and convenient features which ensure that development is (and remains) fun. But in spite of it’s brilliance, there is one area where .NET falls way behind Java…

The .NET open-source community is somewhat anaemic when compared with the Java community. There are some great .NET open-source projects, a lot of them ports of Java open-source projects, and I have a great deal of respect for the contributors. But it’s often the case that a really cool open-source project becomes commercial after it becomes successful.

It seems that I have to pay for so many products just to give me a complete dev environment. Eclipse is a free IDE with refactoring and testing tools integrated. If I want similar functionality in .NET I have to purchase Visual Studio, then purchase ReSharper, and then purchase VisualSVN. Now I have paid roughly £500 to get a development environment roughly equivalent to the basic install of Eclipse. Oh, did I mention that Eclipse is FREE?

If I want extra features, I will most likely have to pay for them!!

So back to the original point of this post… The high cost of entry makes .NET an unattractive choice for development, when compared to Java (and the huge wealth of open-source code out there).

Microsoft’s new found support of the open-source world is great for all .NET developers! I hope they continue to move forward, promoting good programming practices as they go. ALT.NET is also a source of inspiration. I hope that more .NET developers will be happy to give their spare time away to the community.

With your help we can make the world a better place!

ReSharper is a great plugin for Visual Studio! I’ve been using the 4.0 EAPs since they were first released to the public and they have been very stable. But the installer seems to have had a few hickups recently…

The installation starts and everything runs smoothly until devenv.exe is called to update the VS2008 integrations. Shortly after this process starts I am presented with this a dialog box with the message:

The operation could not be completed

Damn!

After a bit of googling I discovered that the error is rooted in UAC. Never mind though, because the solution was very simple…

First I enabled the Administrator account (which is disabled by default on Vista), then logged in as the Administrator and installed ReSharper (build 799).

Voila! No error!

After installing I logged off, logged back in as me, and promptly disabled the Administrator account.

I just read a post by Jean-Paul Boodhoo in which he describes his view of TDD.

From the post:

I feel that test driven development is first and foremost a design activity that is used to flesh out the design of a component by creating a test that first describes the API it is going to expose and how you are going to consume it’s functionality. The test will help shape and mold the System Under Test until you have been able to encapsulate enough functionality to satisfy whatever tasks you happen to be working on.

I think that is a pretty helpful definition. Thanks JP!

Today we came across a very simple rounding problem: round a number up to the nearest 0.05.

A quick search came up with quite a few hints, but no concrete answer. So we rolled our own. Here’s the code.

using System;

namespace Util
{
    public class MathHelper
    {
        public static double RoundNumberUp(double number, double roundingFactor)
        {
            double rounded = RoundNumber(number, roundingFactor);
            if ((number - rounded) > 0)
            {
                rounded = rounded + roundingFactor;
            }

            return rounded;
        }

        public static double RoundNumber(double number, double roundingFactor)
        {
            double rounded = Math.Round(number * (1 / roundingFactor)) / (1 / roundingFactor);

            return rounded;
        }
    }
}

And here are the tests, which show how to use the class.

using NUnit.Framework;
using Util;

namespace Util.Tests
{
    [TestFixture]
    public class MathHelperTests
    {
        [Test]
        public void Should_round_a_number_up_to_the_nearest_0_05()
        {
            double result = MathHelper.RoundNumberUp(6.66, 0.05);
            Assert.AreEqual(6.7, result, 0.001);

            result = MathHelper.RoundNumberUp(6.7, 0.05);
            Assert.AreEqual(6.7, result, 0.001);

            result = MathHelper.RoundNumberUp(6, 0.05);
            Assert.AreEqual(6, result, 0.001);

            result = MathHelper.RoundNumberUp(6.13, 0.05);
            Assert.AreEqual(6.15, result, 0.001);

            result = MathHelper.RoundNumberUp(6.18, 0.05);
            Assert.AreEqual(6.2, result, 0.001);
        }
    }
}

Hope this comes in handy! Bye for now.

Earlier this month me and a few guys at work decided to delve head first into test driven development. We had always done things the old fashioned way and decided it was time to catch up with more robust development techniques.

We knew it would be painful at the beginning, but the rewards of TDD are too good to ignore. And painful it was… At first development was extremely slow! Thinking about what to test was difficult. Thinking about how to test was also hard! But we persevered, moving slowly from one test to the next, and testing each new class and method as we invented them.

I think it was about one week in, that this experiment started to bear real fruit. We started to notice that, in the process of developing the tests, we were designing our program from the outside in. This reminded me of something Jean-Paul Boodhoo has repeated over and over in various screencasts: In writing the tests for our programs we are actually driving out the design of our programs!

The most obvious benefit of the TDD approach is adherance to the YAGNI agile principle. It is often very tempting to write some code which solves a problem that you have anticipated. The problem with this is that you may well NOT need this code! TDD overcomes this anticipation by dictating that you write only the code needed to satisfy your tests. At the start this can feel restrictive, but as you move on this becomes liberating.

The second obvious benefit of TDD is that you tend to write functional, loosely coupled code. By starting from class names, then filling in the gaps with the methods you need, I have found that I am creating more useful classes with less bloat. When you specify a method you are forced to think carefully what parameters you should be passing to it and what object, if any, it should return.

The approach of designing classes from the outside is totally different than designing them from the inside. I’d say you get a birds eye view over your software when using TDD. This is far better than forever being bogged down by tiny details…

All in all I’d say I’m now a huge fan of TDD!! I’m still taking baby steps, but the more I use agile development techniques the more I see the huge benefits!

Recommendations:
Agile Principles, Patterns, and Practices in C# by Robert C. Martin.
dnrTV! - Check out the episodes with JP Boodhoo and Venkat Subramaniam!
DotNetRocks! - A twice weekly .NET podcast.

I recently had the need to store strings in a database in a compressed format. I wanted to store some potentially long strings in a SQL server image type column. After some time searching the internet for solutions I came across a neat .NET namespace called System.IO.Compression which looked like it could be the answer to my problem…

Here is the helper class I wrote to perform compression and decompression:

using System.Collections.Generic;
using System.IO;
using System.IO.Compression;
using System.Text;

namespace Utility
{
    public static class CompressionHelper
    {
        public static byte[] CompressText(string text)
        {
            byte[] buffer = Encoding.UTF8.GetBytes(text);
            MemoryStream compressedStream = new MemoryStream();
            DeflateStream compressedZipStream = new DeflateStream(compressedStream, CompressionMode.Compress, true);
            compressedZipStream.Write(buffer, 0, buffer.Length);
            compressedZipStream.Close();
            compressedStream.Position = 0;
            byte[] compressed = new byte[compressedStream.Length];
            compressedStream.Read(compressed, 0, (int)compressedStream.Length);
            return compressed;
        }

        public static string DecompressText(byte[] compressed)
        {
            MemoryStream compressedStream = new MemoryStream(compressed);
            DeflateStream zipStream = new DeflateStream(compressedStream, CompressionMode.Decompress);
            List<byte> bytes = new List<byte>();
            int offset = 0;
            while (true)
            {
                byte[] temp = new byte[offset + 100];
                int bytesRead = zipStream.Read(temp, offset, 100);
                if (bytesRead == 0)
                {
                    break;
                }
                for (int i = offset; i < offset + bytesRead; i++)
                {
                    bytes.Add(temp[i]);
                }
                offset += bytesRead;
            }
            return Encoding.UTF8.GetString(bytes.ToArray());
        }
    }
}

Of course you could argue that this class is too specialised right now. It served my purpose well, but you could take and return byte arrays or streams as parameters to make it more general and re-use friendly.

Please let me know if you find any bugs…

Enjoy!