Brian Hartsock’s Blog

The older I get, the more paranoid I get about things I download. Today I downloaded a freeware program from a 3rd party download site, since the publisher doesn’t actually allow downloading from their site. All they give is an MD5 checksum.

Well, I decided to write a quick Powershell script to do the checksum for me. (Got some pointers from another blog writing a cmd-let to do the same thing)

param
(
    $file
)
 
$algo = [System.Security.Cryptography.HashAlgorithm]::Create("MD5")
$stream = New-Object System.IO.FileStream($file, [System.IO.FileMode]::Open)
 
$md5StringBuilder = New-Object System.Text.StringBuilder
$algo.ComputeHash($stream) | % { [void] $md5StringBuilder.Append($_.ToString("x2")) }
$md5StringBuilder.ToString()
 
$stream.Dispose()

I probably should add a try/catch for the stream disposal and file existence validation. But, you get the picture.

Last night I was reading Agile Software Development, Principles, Patterns, and Practices (freaking amazing book) and came across the Liskov Substitution Principle. I had never heard of this principle, so it got me intrigued.

What it is…

The idea is very simple. For any client using a base class, any child class should be able to be substituted in that client. It seems very straightforward, but the example Martin gives blew my mind.

Is a Square subclass of a Rectangle a valid model? Maybe. It depends on how clients use it. If a client expects to be able to change the height and width independently, then this model actually breaks down. Martin sums it up better than I,

This leads us to a very important conclusion. A model, viewed in isolation, can not be
meaningfully validated. The validity of a model can only be expressed in terms of its clients.

He follows this up by saying that the Is-A relationship actually applies to the behavior of an object and not how we may envision an object relationship. A square Is-A rectangle because it has 4 sides and each side has a 90 degree angle between them. A square Is-Not-A rectangle because its height and width can change independently.

How many times have I created an object hierarchy based on how I perceive the objects vs how the behave? Too many. This principle is really easy to violate, and causes an application to become fragile when violated.

How to prevent it…

The book goes on to talk about Design by Contract, which can help prevent this behavior by specifying pre-conditions and post-conditions on any given method. These conditions are published with the base class. The oddity of Spec# makes a lot more sense when thought of in regards to the previous example.

Another way to accomplish this without built-in language support is to create a test fixture hierarchy similarly to the object hierarchy. That way, any expectations on the base class can be verified on all sub classes.

[TestFixture]
public abstract void RectangleBaseTests
{
    protected abstract Rectangle { get; }
 
    [Test]
    public void ChangeWidth()
    {
        int oldHeight = Rectangle.GetHeight();
 
        Rectangle.SetWidth(5);
 
        Assert.That(Rectangle.GetHeight() == oldHeight);
        Assert.That(Rectangle.GetWidth() == 5);
    }
 
    /* More Rectangle tests .... */
}
 
[TestFixture]
public void SquareTestFixture : RectangleBaseTests
{
    private Square _square;
 
    protected override Rectangle
    {
        get { return _square; }
    }
 
    [SetUp]
    public void Setup()
    {
        _square = new Square(5,5);
    }
 
    /* more Square only tests... */
}

This still isn’t optimal because it requires developers to actually create the tests that verify functionality, but it is better than nothing.

In the end, the solution doesn’t matter as much as understand the problem. I highly recommend any developer read up on the Liskov Substitution Principle.

I have read over Scott Hanselman’s Tool List at least a dozen times. The first time I read it, I saw that Powershell was on his top 10. I knew a little about Powershell from Exchange 2007 but hadn’t taken any time to look at it.

About a month ago, I had to write some server maintenance scripts. Things like deleting files older than X days, SQL Server maintenance, etc. These tasks were perfect for scripting, so I picked up a Powershell book and went to town. It took a while to pick it up, but my overall impression of Powershell is wow. Powershell fills that void in the soul of Windows that developers hate. Now scripting in Windows doesn’t have to involve Cygwin and Perl, even though Perl will always stay close to my heart.

Powershell combines the ease of scripting with the power of .NET. It is a loosely typed language that can work with strongly typed objects from .NET. For me, it boils down to scripting objects instead of text. In Bash, grep and awk had to be used when parsing the output of any program. In Powershell, the output of a program is usually an object, which is much easier to work with.

The following line sums up why I love Powershell. It deletes files older than 14 days in a directory. While this is a trivial example, it is so simple, and so elegant.

gci c:\directory |  where { $_.LastWriteTime.AddDays(14) -lt [DateTime]::Now } | ri