Entries categorized 'Blog' ↓

Dear Citibank. Last time I checked, JavaScript had a confirm() method. Kthxbai..

OK, why is is it Framework 4 and not Framework 4.0? The differing precisions in this drop-down are playing havoc with my OCD.

Also, I see Scott Hanselman mentioned “C# 4 (not 4.0, the marketing folks say it's .NET 4, etc.)”.

Those crazy marketing folks. I’m sure they just do it to screw with my head. They’ll be sorry come Autumn when they need a .NET 4.1…

Having just upgraded an existing solution to target Visual Studio 2010 and .NET 4.0, I found all of my MSTest unit tests were giving the following error message:

Method TestProject.TestFixture.MyClassInitialize has wrong signature. Parameter 1 should be of type Microsoft.VisualStudio.TestTools.UnitTesting.TestContext.

This was caused by all the test projects still having a reference to version 9.0.0.0 of Microsoft.VisualStudio.QualityTools.UnitTestFramework. Having removed this and added a reference to version 10.0.0.0, all the tests are now working just tickety-boo.

Hope this helps someone…

A couple of weeks ago, early one morning, my friend and fellow coder Scott asked a curious question:

“Do you think that programming computers for a living gives you a negative outlook on life?”

Now, Scott is unfortunately responsible for administering occasional TLC to a codebase that I cut as long ago as 2004, so I assumed he was referring to this and was about to raise some complaints about my hand-rolled query object criteria framework or other coding horror. I steeled myself to defend my work as he continued to explain:

“Well, when coding we have to consider all the potential edge cases and exceptions – what happens if our methods get dodgy inputs etcetera. And it’s spilling over into my real life. We’re moving house at the moment, and I just find myself worrying about what happens if the buyers pull out, if we can’t get the mortgage, if the survey reveals problems… I’m really negative about the whole process.”

At the time I smiled and put this down to the notoriously tortuous British house-buying process, but the more I think about it, the more I think Scott might be onto something.

My wife and I are currently plotting a well-deserved summer vacation in sunnier climes, which theoretically should be an enjoyable task, right? But I can’t simply enjoy it and focus on the “sunny-day scenario”. My mind is full of edge cases (“What if we can’t fit all our stuff in the car?”), unhandled exceptions (“Will we get our passports in time?”), compatibility issues (“will our choice of dates suit my clients?”), unwise over-reliance on dependent components (“Will the airline have any child seats available?”) and of course user errors (“Suppose we book the wrong dates?!”). No focusing on the happy path for this codemonkey.

The more I think about it, the more I see that Scott has a point. Professional software development forces us to anticipate invalid input, stupid users, hackers,  insufficient hardware, unreachable remote services, and whether our software can pass the Turkey test. We consider SQL injection, cross-site scripting, buffer overflows, and countless other common threats and exploits. Not to mention worrying about what happens when other devs get their grubby mitts on our codebase, or when the client inevitably unleashes some game-changing requirements late in the lifecycle. We’re all about expecting the worse, coding defensively, and decoupling ourselves from dependencies. The ever-present potential for high-profile failures caused by something as simple as an inverted boolean comparison, combined with the likelihood of critique and criticism from our fellow coders, DBAs, auditors and sysadmins is enough to turn most devs into a nervous wreck before they’ve so much as initialised a variable. That reminds me, I must check that my Professional Indemnity insurance policy is up to date.

So, anecdotal evidence and my own experience suggests to me that Border’s First Law is a truism. Programming Computers Can Cause Negativity, Cynicism and Pessimism.

Are these necessarily negative traits to have, or can such enforced forethought and consideration of potential issues be a benefit in “real life”, away from the screen? I suspect as with many things, the answer is that there is some balance to be had. So – getting to the airport on time is A Good Thing. Spending a fortnight’s vacation panicking on the offchance that the flight operator goes bust is, probabilistically, a bit silly.

I’m not sure where I’m going with this, or what the answer is, except perhaps to be a little more aware of this mindset and try to adopt a little restrain when applying programming principles to “real-life” conversations. Life, alas, is not a well-defined algorithm, and God knows it doesn’t come complete with a full suite of regression tests.

PS – You know, I just remembered that I blogged about this topic before!

Courtesy of Google Analytics, here are my top 10 most-read blog posts from 2009:

Posts published in 2009 only:

1. SOLID Development Principles in Motivational Posters (12 February)
2. Empty Catch Blocks (11 June)
3. TFS: Using Alternative Diff/Merge Tools (19 May)
4. ASP.NET Just Became a Legacy Platform (22 March)
5. Welcoming Barclaycard to the 21st Century (21 October)
6. Bohemian Rhapsody in Digg Comments (06 February)
7. Moo.com – Customer Service Done Right (07 May)
8. New Office Photos (22 May 2009)
9. On 64-bit TFS, Virtualization and Conchango SCRUM (23 January)
10. .NET Coding Standards (23 January)

All Posts:

1. Team Foundation Server – Sharing Binaries and Class Libraries across Multiple Projects (17 March 2007, Last Year #1).
2. A Serializable KeyValuePair Class (17 September 2006, Last Year #2).
3. Is My String Empty? Some C# Performance Metrics (30 July 2004, Last Year #3).
4. Spot The Misleading Graph (19 February 2007, Last Year #5).
5. Postcode Validation (23 May 2007, Last Year #4).
6. MSB3247 – Dependent Assembly Conflicts (04 December 2008, Last Year #22).
7. A C# Postcode Struct With Parser (29 May 2007, Last Year #6).
8. Getting Daemon Tools to Install on Windows Vista Beta 2 (08 June 2006, Last Year #9)
9. SOLID Development Principles in Motivational Posters (12 February 2009)
10. Empty Catch Blocks (11 June 2009)

Here’s what was waiting for me under the tree this year:

• Chunky pure silver cufflinks featuring fingerprints of my two beloved children.
• Lagavulin
• Jura
• Malcolm Gladwell – Outliers
• Dara O’Briain – Tickling The English
• Red Next Jumper
• Calvin Klein Pants
• Case Logic USB Drive Case
• Laptop cushion desk

Thanks to all those who gave Santa a helping hand!

Previous years – 2008, 2007, 2006, 2005.

Oh, the irony!

I’m really enjoying being a Spotify customer, especially since they released an app for the Android mobile platform (I’m the proud owner of an HTC Magic). I was planning to write a quick blog post simply enumerating the things I love about Spotify, but first, to give some historical context I thought it might be interesting to consider how I consumed music just a decade or so ago.

The Way It Was

When I started university fifteen years ago, I did the only sensible thing with my first grant cheque. I took it to Richer Sounds and blew the lot (and then some) on a bloody big hi-fi separates system.

For many years it was my pride and joy, and I diligently performed all of the standard audiophile tricks in an effort to make the music it played sound as close to perfection as was humanly possible. The speaker stands were weighted with sand, the components were loving joined together with high-quality directional interconnects, and the amp was always turned on after the sources. Basically, I spent as much time trying to attain musical nirvana as I ever did cramming for my exams on Game Theory and Combinatorial Counting.

From where did the music come that I played on this hi-fi? Religiously each Wednesday I bought and scoured the Melody Maker and New Musical Express, reading the reviews, editorials and adverts and obsessively making lists of the vinyl and CDs that I had to buy the next week. When the following Monday arrived, I would cycle to SelectaDisc, procure my weekly fix, and cycle back to digs as fast as my legs would carry me.

And then there was the whole glorious experience…

Slide the inner sleeve out of the outer sleeve. Slide the vinyl out of the inner sleeve. Blow it. Dust it down carefully with carbon fibre brush. Drop the disc on the platter. Set the turntable going. Drop the needle into the run-in groove. Turn the amp on, and the volume up. Lie back, be surrounded by sound, and inspect the artwork. Aaaahhh…

The Way It Is

Well. That was then, this is now. I’m pleased to say that the hi-fi still works fine, but I no longer have the time to give it the attention that it deserves, so I’ve given it to my eldest nephew.

Of course I still love music, but quantity, time and convenience are now of higher importance to me than sound quality and overall experience. And this is where Spotify fits perfectly into my current lifestyle.

For example, a few minutes ago I read that a new Sufjan Stevens LP has recently been released. A few keypresses later, and I’m listening to it. A few more touches on my Android-powered phone, and it’s downloading over wifi for me to listen to at the office tomorrow. The simplicity and ease of use is staggering.

Unlike with managing a large collection of MP3s, I have no files to organise, backup, and worry about losing. Unlike with CDs, there is no physical media to be ripped, stored, and worry about the kids scratching. There’s just the music, on demand, whenever I want, at the touch of a few buttons, and all for just a tenner a month (roughly the price of an album, then).

As a result, I find myself listening to an increased variety and quantity of music once again. On the one hand I can rediscover long-forgotten gems from my younger days, and then on the other I can be more adventurous, the subscription model rendering tracks and albums free of risk. It’s an absolute joy.

No Downside?

Hardcore record collectors must be turning in their graves, and indeed I can’t bring myself to get rid of all the cherished vinyl languishing in my loft. But, for hassle-free accessibility to the music itself, Spotify is difficult to beat.

If I had to pick holes in the service, then the obvious starting point would be the holes in the collection. Nothing at all by The Beatles, Led Zep or Pink Floyd. No sign of Arcade Fire’s first album, or The Proclaimers' “Persevere” and “Born Innocent” opuses. I can’t see any Ian McNabb, which is unfortunate as I have a soft spot for “You Must Be Prepared To Dream”. Older Snow Patrol albums are missing, as is Prefab Sprout’s “Jordan – The Comeback”, and Mull Historical Society’s “This Is Hope”. I’m sure there are many, many others, these are just the omissions that are bugging me at the moment.

The mobile app doesn’t scrobble to last.fm, and the fact that I sorely miss this makes me realise how weak Spotify’s whole recommendation and social networking story is. But this can easily be enhanced over time, and in the short term I think the company are right to focus on extending the catalogue and improving the overall quality of the service (increased bitrate, offline capability, availability on mobile platforms).

Now.. what to do with all those CDs gathering dust on the shelves…?

@Jez tweeted last night:

@ianfnelson admit it: you use Castle Windsor primarily to highlight and lampoon Google's poor selection of adwords?!

Funny, but not true. I am enamoured with the Castle Windsor project because its power makes it fairly simple for me to develop loosely-coupled systems which are easily maintained and tested. The wide range of Facilities and Contrib projects also integrate nicely with the other parts of my current development stack (NHibernate, WCF, WF, log4net).

Whilst there is a lot of material on the web about the Dependency Injection capabilities of Windsor, the Aspect-Oriented Programming (AOP) features don’t seem to get as much exposure, so I thought I’d quickly blog about one way in which I’ve been making use of those in the system I’m currently developing.

Earlier this year Davy Brion posted an excellent C# implementation of the Circuit Breaker pattern described in Michael Nygard’s equally excellent book Release It! Design and Deploy Production-Ready Software.

For the uninitiated, this pattern advocates protecting your system from issues affecting any remote service on which it depends by wrapping your calls to that service with a circuit breaker component. This component notes any failed service invocations, until some threshold is reached, causing the circuit to trip. Subsequent attempted service invocations then “fail fast”, throwing a custom exception rather than passing the method call on to the remote service. This benefits your system, as it prevents you from tying up valuable threads creating expensive remote service calls which may be slow to timeout. And it benefits the remote system as you avoid piling further pressure on a service which is already down or unresponsive.

For more details of this pattern, and some entertaining war stories of situations in which they would have proved useful, I encourage you to read Michael Nygard’s book.

Now, I like Davy’s implementation of this pattern a lot, particularly since it is implemented as an interceptor for Castle Windsor, which as mentioned I’m already making heavy use of in my current projects. But my only concern is that it is configured to trip after the number of failed invocations reaches a specific figure, irrespective of how long it takes to reach that threshold. I want an implementation which is able to sense the difference between infrequent exceptions over a prolonged period, and a sudden flurry of exceptions – the latter causing the circuit breaker to trip.

To achieve this I’ve tweaked Davy’s implementation slightly by adding an extra parameter to the constructor specifying the historical period over which to total the number of exceptions. That is, you can configure it such that a certain number of failures within the preceding y minutes causes the circuit breaker to trip.

I look forward to seeing what adverts Google sees fit to stick at the bottom of this post… :-)

/// <summary>
/// Castle Interceptor Circuit Breaker.
/// 
/// Used in an AOP-style to wrap calls to protected methods.
/// If the number of unhandled exceptions that occur within a specified period
///  exceeds a specified threshold, then invocations will cease to be passed to the 
///  protected code until a specified timeout has elapsed.
/// Instead, OpenCircuitExceptions will immediately be thrown when invocations are
///  attempted.
/// 
/// Based on code by Davy Brion (http://davybrion.com) and Ayende Rahien (http://ayende.com).
/// 
/// For background on the Circuit Breaker pattern, see "Release It! - Design and Deploy
///  Production-Ready Software" by Michael Nygard (Pragmatic Bookshelf, 2007).
/// </summary>
public class CircuitBreaker : IInterceptor
{
    private readonly object monitor = new object();

    private CircuitBreakerState state;
    private List<DateTime> failures;
    private TimeSpan period;
    private TimeSpan timeout;
    private int threshold;

    /// <summary>
    /// Initializes a new instance of the CircuitBreaker class.
    /// </summary>
    /// <param name="threshold">Number of permissible exceptions within period before circuit breaker blows.</param>
    /// <param name="period">Historical period over which to log exceptions.</param>
    /// <param name="timeout">Timeout after blowing of Circuit Breaker for which the circuit will stay open and throw OpenCircuitExceptions.</param>
    public CircuitBreaker(int threshold, TimeSpan period, TimeSpan timeout)
        : this()
    {
        this.threshold = threshold;
        this.period = period;
        this.timeout = timeout;
    }

    /// <summary>
    /// Initializes a new instance of the CircuitBreaker class.
    /// </summary>
    public CircuitBreaker()
    {
        this.failures = new List<DateTime>();
        this.MoveToClosedState();
    }

    /// <summary>
    /// Intercepts the planned method invocation.
    /// </summary>
    /// <param name="invocation">Original method call.</param>
    public void Intercept(IInvocation invocation)
    {
        using (TimedLock.Lock(monitor))
        {
            state.ProtectedCodeIsAboutToBeCalled();
        }

        try
        {
            invocation.Proceed();
        }
        catch (Exception e)
        {
            using (TimedLock.Lock(monitor))
            {
                // Add current datetime to list of failed invocations.
                failures.Add(DateTime.UtcNow);
                state.ActUponException(e);
            }
            throw;
        }

        using (TimedLock.Lock(monitor))
        {
            state.ProtectedCodeHasBeenCalled();
        }
    }

    private void MoveToClosedState()
    {
        state = new ClosedState(this);
    }

    private void MoveToOpenState()
    {
        state = new OpenState(this);
    }

    private void MoveToHalfOpenState()
    {
        state = new HalfOpenState(this);
    }

    private void ResetFailureList()
    {
        this.failures.Clear();
    }

    private bool ThresholdReached()
    {
        // Remove log of any failed invocations that occurred earlier than period in which we are interested.
        this.failures.RemoveAll(f => f < DateTime.UtcNow - period);

        // Have number of failures breached the allowed threshold?
        return failures.Count > threshold;
    }

    private abstract class CircuitBreakerState
    {
        protected readonly CircuitBreaker circuitBreaker;

        protected CircuitBreakerState(CircuitBreaker circuitBreaker)
        {
            this.circuitBreaker = circuitBreaker;
        }

        public virtual void ProtectedCodeIsAboutToBeCalled() { }
        public virtual void ProtectedCodeHasBeenCalled() { }
        public virtual void ActUponException(Exception e) { }
    }

    /// <summary>
    /// Represents a closed CircuitBreaker - this is the "normal" behaviour,
    ///  with invocations passed through to the protected code.
    /// </summary>
    private class ClosedState : CircuitBreakerState
    {
        public ClosedState(CircuitBreaker circuitBreaker)
            : base(circuitBreaker)
        {
            circuitBreaker.ResetFailureList();
        }

        /// <summary>
        /// Called when an exception occurs in the protected code.
        /// </summary>
        /// <param name="e"></param>
        public override void ActUponException(Exception e)
        {
            // If the threshold has been breached, open the circuit.
            if (circuitBreaker.ThresholdReached()) circuitBreaker.MoveToOpenState();
        }
    }

    /// <summary>
    /// Represents an open CircuitBreaker - in this state we do not pass the 
    ///  invocation to the protected code, but instead throw OpenCircuitExceptions
    ///  until the timeout expires.
    /// </summary>
    private class OpenState : CircuitBreakerState
    {
        private readonly DateTime expiry;

        public OpenState(CircuitBreaker circuitBreaker)
            : base(circuitBreaker)
        {
            // Keep a note of the time at which the circuit should be moved
            // to half-open state.
            expiry = DateTime.UtcNow + circuitBreaker.timeout;
        }

        public override void ProtectedCodeIsAboutToBeCalled()
        {
            // Has the timeout expired?
            if (DateTime.UtcNow < expiry)
            {
                // Not yet, so throw an eppy.
                throw new OpenCircuitException();
            }

            // yes, timeout has expired, so move to half-open state.
            circuitBreaker.MoveToHalfOpenState();
        }
    }

    /// <summary>
    /// Represents a CircuitBreaker in the "Half-Open" state.
    /// In this state a timeout has just expired and we are tentatively calling
    ///  the protected code again. If all goes well, we will move to the closed state.
    /// However, if this first dipping of our electronic toe into the water is met by
    ///  the shock of an unhandled exception, we shall quickly open the circuit again
    ///  for a further timeout period.
    /// </summary>
    private class HalfOpenState : CircuitBreakerState
    {
        public HalfOpenState(CircuitBreaker circuitBreaker) : base(circuitBreaker) { }

        public override void ActUponException(Exception e)
        {
            // Eek, problems remain. Open the circuit again quickly.
            circuitBreaker.MoveToOpenState();
        }

        public override void ProtectedCodeHasBeenCalled()
        {
            // Things seem to be OK now. Close the circuit.
            circuitBreaker.MoveToClosedState();
        }
    }
}

The shiny new system which I’ve recently been developing makes heavy use of the Chain of Responsibility pattern, and as such a number of service classes take an array of objects in the constructor:

/// <summary>
/// Initializes a new instance of the LeadAllocationService class.
/// </summary>
/// <param name="leadAllocators">Array of Lead Allocators.</param>
public LeadAllocationService(params ILeadAllocator[] leadAllocators)
{
    this.LeadAllocators = leadAllocators;
}

I’m using Castle Windsor for dependency management, so I’ve been fluently registering all instances of ILeadAllocator:

container.Register(
    AllTypes
    .Of<ileadallocator>()
    .FromAssemblyNamed("Marshalls.Leads.ApplicationService")
    .WithService
    .FromInterface(typeof(ILeadAllocator))
    .Configure(c => c.LifeStyle.Transient));

Easy, right? And yet at runtime Windsor surprised me by throwing this exception in my face:

Castle.MicroKernel.Handlers.HandlerException: Can't create component 'Marshalls.Leads.ApplicationService.LeadAllocationService' as it has dependencies to be satisfied.
Marshalls.Leads.ApplicationService.LeadAllocationService is waiting for the following dependencies:
Keys (components with specific keys)
- leadAllocators which was not registered.

Huh?! What gives? Well, a little Googling revealed this post from Castle founder Hamilton Verissimo explaining that by default the Castle MicroKernel expects me to define what should be included in the array. But he goes on to explain that the behaviour I desire can be achieved by registering a custom subresolver with the microkernel. That subresolver has since been included in the Castle Windsor distro, so in actual fact all I needed to do was add the following line of code when configuring my container:

container.Kernel.Resolver.AddSubResolver(new ArrayResolver(container.Kernel));

So now, when new implementations of ILeadAllocator are added to the codebase, they are immediately available to the CofR pattern within the LeadAllocationService, with no additional work required by the developer. Hurrah!