AbstractCode

Chain of responsibility using LINQ Extension methods

Colin David Scott — Fri, 03 Jul 2009 15:45:07 GMT

I recently had reason to implement a simple chain of responsibility in order to simplify some logic. Rather than a large number of sequential if statements to implement a sequence of conditional exclusive actions I used this structure to simplify the logic.

The basis of the implementation is a field that is a collection of delegates. The delegate take parameters as needed to determine if an action is applicable and also to implement the action. It also returns bool. For example:

private static readonly ICollection<Func<TestObject, bool>> _chain = new List<Func<TestObject, bool>>
    {
        FirstHandler, SecondHandler, FallbackHandler
    };

This is a simple chain consisting of three actions. Each of FirstHandler, SecondHandler and FallbackHandler are methods that match the delegate signature. In this example they are each methods on the same class but this is not mandatory. I’ve defined them as:

private static bool FirstHandler(TestObject testObject)
{
    if (testObject.TestValue != 1)
    {
        return false;
    }

    Console.WriteLine("First Handler");

    return true;
}

private static bool SecondHandler(TestObject testObject)
{
    if (testObject.TestValue != 2)
    {
        return false;
    }

    Console.WriteLine("Second Handler");

    return true;
}

private static bool FallbackHandler(TestObject testObject)
{
    Console.WriteLine(string.Format(CultureInfo.CurrentCulture, "Fallback: {0}", testObject.TestValue));
    return true;
}

The first two methods do a check to see if they are applicable, returning false if this is not the case and true if it is. FallbackHandler is different and always returns true and applies its action. This makes it the last link in the chain.

In order to execute the chain we use the First method from the LINQ Enumerable class. The following example shows the use of the chain to execute (in order) the SecondHandler, FirstHandler and FallbackHandler methods.

_chain.First(c => c(new TestObject {TestValue = 2}));
_chain.First(c => c(new TestObject {TestValue = 1}));
_chain.First(c => c(new TestObject {TestValue = 5}));

This works by enumerating through the _chain collection, executing each delegate in turn. Each method will check whether it wishes to handle the call, returning a value indicating whether it has chosen to do so. A return value of true indicates that a link has handled the request and that no further processing is required. This causes First to stop enumerating. It also returns to matching delegate but this may be ignored. The last handler is a fallback as it handles everything that was not otherwise handled. This is necessary as the First method will throw an exception if no match is found. It is appropriate to do this when there is always an action to be applied. If it is valid that no action be performed then you can substitute FirstOrDefault which will not error when a match is not found.

Note that the chain does not need to be fixed. It is entirely valid to modify it dynamically at runtime. Care should be taken to ensure that there are no threading issues as a result. You can change the Func delegate used provided you continue to return true.

This works well but is not particularly useful when you need the chain to return a value. In this case we can split the check and the action into separate methods. We can make the chain a collection of KeyValuePair values where the key and value types are delegates. In this case the key is a delegate returning true that performs the check and the value is a delegate that performs the action and returns the required value. The chain becomes:

private static readonly ICollection<KeyValuePair<Func<TestObject, bool>, Func<TestObject, int>>> _chain
    = new List<KeyValuePair<Func<TestObject, bool>, Func<TestObject, int>>>
    {
        CreateLink(FirstCheck, FirstAction),
        CreateLink(SecondCheck, SecondAction),
        CreateLink(FallbackCheck, FallbackAction)
    };

private static KeyValuePair<Func<TestObject, bool>, Func<TestObject, int>> CreateLink(Func<TestObject, bool> key,
    Func<TestObject, int> value)
{
    return new KeyValuePair<Func<TestObject, bool>, Func<TestObject, int>>(key, value);
}

We use a helper method here to simplify things given the nested generics. We define the checks and actions as separate methods:

private static bool FirstCheck(TestObject testObject)
{
    return testObject.TestValue == 1;
}

public static int FirstAction(TestObject testObject)
{
    return testObject.TestValue * 2;
}

private static bool SecondCheck(TestObject testObject)
{
    return testObject.TestValue == 2;
}

public static int SecondAction(TestObject testObject)
{
    return testObject.TestValue * 3;
}

private static bool FallbackCheck(TestObject testObject)
{
    return true;
}

public static int FallbackAction(TestObject testObject)
{
    return testObject.TestValue;
}

Invoking the new chain is slightly more complicated and looks like:

var testObject = new TestObject {TestValue = 2};
var result = _chain.First(c => c.Key(testObject)).Value(testObject);

Again the chain may be dynamically altered at runtime provided that this is done in a threadsafe manner. I would recommend reconstructing the entire chain then substituting it for the existing chain rather than attempting to modify an existing chain in place. Modification in place will generally be more complex and require a more complex locking strategy.

This approach demonstrates an implementation that is suitable for many circumstances where a classic chain of responsibility is called for. The use of LINQ methods may have performance implications in some applications and this should be considered before committing to it. In general use however this is a simple way to apply this pattern and avoid verbose for/foreach statements.

Conditional references using MSBuild

Colin David Scott — Fri, 03 Jul 2009 12:22:41 GMT

I’ve been using SQLite in a personal project and have encountered an issue with referencing the assembly. The .NET assembly references the unmanaged SQLite proper assembly, and this varies between 32 and 64 bit systems. Hence when building the project on my netbook a number of tests fail.

The solution lies in the following XML places in the project file.

<Choose>
    <When Condition="$(PROCESSOR_ARCHITEW6432) == 'AMD64'">
        <ItemGroup>
            <Reference Include="System.Data.SQLite, Version=1.0.62.0, Culture=neutral, PublicKeyToken=db937bc2d44ff139, processorArchitecture=AMD64">
                <SpecificVersion>False</SpecificVersion>
                <HintPath>..\..\..\external-lib\x64\System.Data.SQLite.DLL</HintPath>
            </Reference>
        </ItemGroup>
    </When>
    <Otherwise>
        <ItemGroup>
            <Reference Include="System.Data.SQLite, Version=1.0.62.0, Culture=neutral, PublicKeyToken=db937bc2d44ff139, processorArchitecture=x86">
                <SpecificVersion>False</SpecificVersion>
                <HintPath>..\..\..\external-lib\x86\System.Data.SQLite.DLL</HintPath>
            </Reference>
        </ItemGroup>
    </Otherwise>
</Choose>

This conditionally includes the 32 or 64 bit SQLite assembly based on evaluating the PROCESSOR_ARCHITEW6432 variable which contains the current processor architecture. Checking the PROCESSOR_ARCHITECTURE environment variable was a seemingly obvious choice but evaluates incorrectly (for this purpose) in 32 bit MSBuild on a 64 bit system.

Measuring developer productivity

Colin David Scott — Thu, 02 Jul 2009 14:09:19 GMT

Much has been written on the failure of counting lines of code (LOC) as a metric for productivity. I won’t further expand on this except to note that what I consider the most compelling argument against LOC is that it will penalise a superior design that can be expressed more succinctly. But if we don’t use LOC, what do we use?

I’m of the opinion that the best low level metric for the development of new features is the rate at which unit tests are being added or modified. Unit tests form an executable specification of the behaviour of software which is built up over time. Each test specifies a behaviour of the software independent of the amount of code we actually end up using to provide the behaviour. We can therefore correlate development progress with the number of unit tests we have.

That sounds great, a metric that relates directly to what we want. Unfortunately its not really that simple. Tracking the number of unit tests produced for new features may track the development of those features but not all development activity is adding features. Maintenance is critical concern and when modifying a system we may not end up modifying many tests at all. In some cases we may even remove them as they become irrelevant to the new shape of the application. Clearly implying a developer has negative productivity in this scenario is invalid yet this is what the metric would have us believe.

Defect resolution is similarly problematic. You may write some tests to prevent the reoccurrence of an issue but the total number of tests added per unit time will be significantly below that experienced with developing new code.

Additionally there are some types of code that do not readily lend themselves to unit testing such as UI or integration code. Developers are still productive when writing this code yet would not be writing tests.

To return to my contention that unit tests are “the best low level metric for the development of new features”, I make this claim with an assumption that the metric is used primarily for tracking new development and that it is used in context with other information. In particular it is important to understand that the raw unit test numbers are by themselves potentially misleading. This is due to differing styles of writing tests and differing levels of complexity.

I personally favour many small tests that each validate a single criteria, with multiple tests for each element of an action that I wish to validate. On raw numbers this would indicate hugely increased productivity over someone who writes larger, heavier tests. I would argue such tests are less effective, but not that they necessarily represent many times lower productivity. Scaling to account for these differences may be necessary and the resultant numbers will need intelligent interpretation. Using the metric on its own would also be open to abuse by less scrupulous developers who could write many unnecessary tests.

What this ultimately means is that unit test velocity can be an effective guide provided that it may be correctly interpreted. As such it is a good local measure to help teams track their progress. Individual developers may consider their velocity to identify potential problems. This provides team members and direct project management with useful information to track the state of their project and take early corrective action. However given the limitations above it is not a suitable measure against which ultimate performance can be judged.

Installing Windows 7 on a HP Mini 2140

Colin David Scott — Sat, 27 Jun 2009 08:27:27 GMT

As the 2140 does not contain a DVD drive it’s necessary to do the install off a USB key. The interblag contains a number of articles describing how to accomplish this (for instance here) however to install I found a small modification to be necessary. The USB key I was using is 4Gb which the BIOS turns out to be unable to read. During the partition of the USB key specifying SIZE=3072 enables the BIOS to read it and is sufficient to contain the Windows 7 install files.

Switching to Windows 7 for communications

Colin David Scott — Sat, 27 Jun 2009 08:21:03 GMT

I recently accidentally purchased a HP Mini 2140^* onto which I have installed Windows 7. I’ve decided to try using it for all my primary communication; including instant messaging, Skype, email and blogging. So far its working pretty well. My only concerns at the moment are:

Windows 7 seems convinced that I have a minimum 2 Live Messenger windows open at any point, one of which is my display picture.
Live Writer won’t display correctly using my blog’s theme (which works fine on Vista)
The carry case for the Mini looks rather too much like a purse.
The doubling of home/end/page up/page down on the cursor keys will take some getting used to.

Windows 7 itself works very well. I’m one of the (apparently few) people who prefer Vista to XP (on decent hardware) and 7 is an improvement again. Very fast on what is a fairly low spec machine.

^* By accidentally driving to the store, accidentally asking for one, accidentally paying for it and accidentally driving off with it.

On the building of frameworks

Colin David Scott — Sat, 27 Jun 2009 08:05:20 GMT

Over the years I’ve written or maintained a number of frameworks for a variety of projects. From this I have come to the following conclusions:

Unless no third party framework exists to cover your scenario you are in almost all scenarios better off using an existing framework than writing your own
When building an application the most effective framework code is that used to apply existing third party frameworks to the application. This will often consist of code to make multiple frameworks play nicely together.
Building a reusable framework is difficult. Build the system to meet the needs of your own application and consider making it more generically applicable only as necessary.
Concepts and design patterns are of much greater utility than framework code.

Organisations will sometimes build their own frameworks (something I’ve been guilty of in the past). It is my contention that an organisation will get more benefit from internal knowledge transfer and training on existing frameworks than will generally be returned from a similar effort to construct them. This may not hold for bleeding edge practitioners where existing frameworks may be incomplete, buggy or non-existent. However when a practice or technology becomes more mainstream an organisation should consider whether their own custom systems continue to deliver value in excess of that provided by now (hopefully more common, stable and feature rich) third party options.

NDepend tip: Exclude that which the code generator hath wrought

Colin David Scott — Sat, 20 Jun 2009 14:14:47 GMT

I’ve been running NDepend over some of my projects recently and have noticed a tendency for it to pick up on things in code generated by Visual Studio (which admittedly is of highly variable quality). I’m not going to write my own version of the generated code but I would like to clear out the noise. You can do so by editing the CQL and adding something like:

AND

!FullNameLike ".*Properties.Resources.*"

This criteria excludes anything that matches the common pattern of the standard resource files produced by Visual Studio. You can substitute your own regular expression (just be careful not to exclude your own types) .

This is mainly a post so I don’t have to work out how to do this again. Hopefully someone will either point out where the option to exclude this generated code is in NDepend or add such a feature to the next version.

Today’s Simple Question: Should I use the GAC?

Colin David Scott — Tue, 16 Jun 2009 14:40:05 GMT

No.

Look around you. Are you working at Microsoft? If so, are you working on .NET itself? Congratulations, your assembly may actually be justified going into the GAC. If you answered No to either of these questions it’s highly unlikely that your assembly is going to be sufficiently widely used that software using it will assume its presence rather than include it with its own binaries.

The benefits of installing into the GAC in the general case are relatively small and doing so incurs additional complexity. It also prevents scenarios such as allowing your application to be dropped into a directory and run without installation. Just say no.

My current development platform and tools of choice

Colin David Scott — Sun, 07 Jun 2009 06:08:10 GMT

Effective software development is all about leveraging the effort of others so that you can focus the majority of effort on the problem your system is to address. The following are the frameworks and tools that I choose to use (as is appropriate) when I get to decide what goes into a system.

I’m not going to try to enumerate all the features, advantages and disadvantages of my choices. I’m always looking for additional or improved options for my list so make any suggestions in the comments below.

Frameworks

NHibernate

Although I’ll acknowledge it has a near vertical learning curve in places nothing else I’ve seen comes close to the power and feature set of NHibernate. I’m currently working on a project with LINQ-to-SQL and I miss the additional features a lot (I do like LINQ though, but only for a certain query complexity).

http://nhforge.org/

StructureMap

Currently my DI framework of choice. I’m particularly fond of the Registry DSL and Auto Registration and Type Scanning, which is so much more effective than long and difficult to maintain XML files. These features aren’t unique to StructureMap but it provides a simple and effective solution that works well in the scenarios I’ve encountered.

http://structuremap.sourceforge.net/

Tools

Integrated Development Environment

Visual Studio 2008

Visual Studio is a relatively solid IDE (at least as of Visual Studio 2008, 2005 had some significant quality issues). By itself it’s fairly average; the code navigation options are limited and the refactoring support so weak it’d be preferable not to have it at all. Its redeeming virtue is that it supports extensions and is sufficiently popular that a great many exist. Plug in in a few extensions and what was an average environment becomes something highly productive.

I use Team Edition for Software Developers. Of the additional features this provides over time I’ve reduced my usage to Team Coverage only (and that used through an extension). Unless you have an unlimited budget, go for the Professional edition.

ReSharper 4.5

If you add no other extension to Visual Studio, add ReSharper. The additional options it gives to navigate your code are alone worth the price. On top of this it has effective refactoring, improvements to Intellisense, code analysis, improved templates, code cleanup, editing enhancements and more.

http://www.jetbrains.com/resharper/

TestDriven.Net

ReSharper provides a test runner which is superior to that in Visual Studio. TestDriven.Net is a Visual Studio extension superior to them both. It supports a wide variety of test frameworks and integrates with a number of coverage tools. I’m particularly impressed with how it integrates Team Coverage with non-Microsoft unit test frameworks.

http://www.testdriven.net/

Utilities

Beyond Compare

My comparison tool of choice. Powerful, easy to use and excellent value. Also has amusing price breaks where an additional licence seems to have a large negative cost (try changing from 99 to 100 licences). Works with every source control system I’ve used.

http://www.scootersoftware.com/

Static Code Analysis

FxCop

This is the standalone version of the static code analysis tool built into Visual Studio Team Edition for Software Developers and Team Suite. When working with Continuous Integration I find the standalone version to be easier to work with. It’s important to remember that as a static analysis tool it’s not always right and intelligence is required in interpreting its results. Despite this its a valuable tool for finding potential issues and ensuring the quality of your code.

http://msdn.microsoft.com/en-us/library/bb429476.aspx

NDepend

For analysing code structure and examining how code fits together I turn to NDepend.

http://www.ndepend.com/

Continuous Integration

TeamCity

It’s hard to go past TeamCity. It’s easy to install and configure and supports a wide variety of build agents. It supports a variety of build tools for multiple platforms as well as many source control systems. Plus it has a free professional edition that supports up to 20 build configurations. I’m particularly fond of the ability to have a dependent build that automatically runs FxCop over the output of my primary build.

http://www.jetbrains.com/teamcity/

Unit Testing

Gallio and MbUnit

I’ve used (and abused) a number of unit testing frameworks, including NUnit and MSTest. MbUnit is my current preference due to effective design and a powerful feature set. When combined with Gallio it provides an effective and easily automatable unit testing solution. It also includes integration with my preferred team runner and CI server (TestDriven.Net and TeamCity).

Source Control

My current source control preference can be best expressed as “Not Visual Source Safe”. I’ve used Team Foundation Server and Subversion on projects with a fair amount of success, although I consider neither ideal. I’m also considering Mercurial although tool support may be an issue. Really the important thing here is to have a solid source control system and to ensure your team uses it well.

Naming and Redundancy

Colin David Scott — Tue, 02 Jun 2009 14:15:31 GMT

I’ve just encountered one of those wonderful bugs caused by Windows path length limits. In this case a large part of the problem was a file with a name over 100 characters long. Most of this name duplicated information already known due to its context, such as the namespace it belonged to. When moving between environments a longer base path in the new environment resulted in an over-long file path and hence breakage in what was previously a working codebase. The base path in the new environment was not excessively long, the fault here is purely with a poorly chosen filename.

Another area I see this is naming projects within Visual Studio solutions. I’ve always favoured short(ish) names comprised or two or three words describing the purpose of the project. This conveys some relevant meaning and can be kept reasonably concise. I’ve also worked on systems where the project name matches the base namespace of the generated assembly. I find a number of problems with this approach:

This immediately introduces duplicate information. Generally the first elements of a namespace are the client and/or project. This is almost always identifiable by the solution in which the project resides. Adding it to every project adds no value.
The more relevant component to a developer is the specific project but this information is given less precedence than the common (irrelevant) portions. Depending on tool window size it may be obscured.
Not all projects contain a single root namespace. (Such projects should be minimised but are not always avoidable).
Adding the redundant information wastes character from a sometimes limiting 260 character maximum. This increases the risk that moving to a different environment (say a development machine to a build server) will fail due to path lengths.

I’ve mostly encountered this problem with build servers, but it can be a problem even if you never chose to automate your build process (note: you should automate your build process). In the past I’ve had issues caused by an installer generator that ran out of path length when building its own temporary directory structure while I was attempting to build an installer for a relatively standard system that had some excessive file lengths.

In an ideal world we could assign names as long as we’d like and everything would just work. Windows is not this ideal world and we need to deal with its reality. Additionally the kind of redundancy I’ve just discussed does nothing to convey useful information and may therefore be considered overhead. Pruning it to size is therefore a win in multiple ways.