Life would be simpler if I had the source code

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!

Benny George, our precocious two-year-old, is quite the fan of Mister Maker, and enjoys spending time doing arty crafty stuff with his mum. Now, the great thing about the BBC is that they tend to suggest projects which can be created using bits and bobs that you’re likely to have around the home – old cereal boxes and the like. But occasionally some specialist resources have to be procured in the name of Ben’s art, and so it was that Joce today spent £1.99 on a pack of the “googly eyes” so beloved of Maker.

Here’s the thing though – I couldn’t help but noticing that these 20mm googly eyes come in packs of seventeen. Joce charitably suggested that this was simply the number of eyes that could fit in the packet, but I am more cynical. Can it really be a coincidence that eyes – which are surely generally found in pairs – are sold in an odd quantity, forcing the purchaser to buy slightly more than they required?

And we’re not just looking at an odd number here – 17 is prime too, so even if you happened to be creating models of, say, the three-eyed Tuatara lizard, you’re still going to end up with some product left over or feel obliged to buy another pack.

Cunning folk, these googly eye marketers, and it makes me wonder why other manufacturers stick to selling their products in multiples of integers with many divisors. Ease of packaging, perhaps.

What other products are sold in prime quantities?

I’m sure it will come as no surprise to you to learn that I prefer to receive online bills and invoices from service providers rather than have hardcopies dropping through our letterbox. It’s not just for the obvious environmental and cost benefits – I’m also simply better at managing such stuff electronically rather than having to faff around with piles of paper. Fortunately, most of the companies I deal with have offered online billing since I became a customer.

A few years ago, just before we were set to move home, I made a point of contacting all the companies who still regularly sent me hardcopy bills to request that I switch to online if possible. Some were able to fulfil this request without a problem, others apologetically advised me that they did not yet have systems in place to offer online billing – which was a fair enough response, particularly for smaller operations.

But from Barclaycard, who have over 10 million customers in the UK, I got a most curious response:

From: customer.services@barclaycard.co.uk
To: ian@ianfnelson.com
Date: Sat, Jul 1, 2006 at 09:14

Dear Mr Nelson,

Thank you for your e-mail.
Unfortunately we are unable to stop sending out paper statements by post.
As a financial institution, we are legally bound to send hard copy statements to all
cardholders if there is a balance owing on their account.
Should you have any further queries, please do not hesitate to contact me again.

Kindest regards
Ranjith Mathew Kurian (Mr)
Customer Account Manager
Barclaycard Online Service

Really? A legal obligation to send hard copy statements to all cardholders if there is a balance owing? I took them up on the offer of contacting them with  a further query – namely, asking why the other credit card providers I used were apparently not hindered by the same legislation:

From: ian@ianfnelson.com
To: customer.services@barclaycard.co.uk
Date: Sat, Jul 1, 2006 at 09:19

American Express do not send me hardcopy statements, they just email me each month.
Are you suggesting that Amex are breaking the law?
Ian

A day later, this response:

From: customer.services@barclaycard.co.uk
To: ian@ianfnelson.com
Date: Sat, Jul 2, 2006 at 11:26

Dear Mr Nelson,

Thank you for contacting us again.
May I inform you that we are unable to comment on other credit card
providers policies. However, as advised earlier, we send out statements to all our
customers if there is a balance owing on the account.

I apologise for any inconvenience caused.

I must also advise you that should we not hear from you within eight
weeks of the date of this e-mail, we will assume that your complaint is resolved.

Kindest regards
Vineetha N (Miss)
Customer Account Manager
Barclaycard Online Service

I didn’t bother responding, figuring that life is too short, and they clearly weren’t interested in the idea of paperless billing at that time.

So, spin on three years, and I was pleasantly surprised to log on to Barclaycard’s website recently and see this graphic:

Yay! Great job Barclaycard, what took you so long? Spending all your time and money on that fancy advert with the guy on the water slide, I suppose? ;-)

After signing up for the paperless billing, I couldn’t resist sending this cheeky reply to the email thread from three years previous:

From: ian@ianfnelson.com
To: customer.services@barclaycard.co.uk
Date: Sat, Oct 10, 2009 at 23:00

Well done on finally offering paperless statements!

What happened to the legal obligations to send out hardcopy statements mentioned in the email thread below?! ;-)

Ian

I didn’t really expect any reply, but was amused by this bizarre response which came through a few hours later:

From: customer.services@barclaycard.co.uk
To: ian@ianfnelson.com
Date: Sun, Oct 11, 2009 at 06:11

Dear Mr Nelson,
Thank you for your e-mail.
You must make a request in writing stating they want a copy of their credit agreement, included with this must be a £1 cheque/postal order payable to Barclaycard, sent to:

Barclaycard House
PO Box 5592
Northampton
NN4 1ZY

I hope this information will help you.

Kind Regards
Dinesh Moolchandani
Customer Advisor
Barclaycard Customer Service Team

The mind, it truly boggles. What did they think I was asking? I hope I never need to contact Barclaycard Customer Services for anything important.

I always knew my lifestyle choices would come back to bite me some day…

I’ve been making heavy use of the Castle Windsor container to handle dependency and configuration management in the shiny new system that I’m currently developing. For the most part it’s been an absolute blast, allowing me to easily create a loosely-coupled system architecture and focus my efforts on what the system should be achieving for the client, rather than worrying about how it all hangs together.

But recently I encountered a bit of a gotcha which made me think that perhaps I should spend some more time understanding exactly what Windsor is doing in the background.

See, it turns out that the default lifestyle for components registered with Windsor is Singleton. So, every time I asked Windsor for an IFooRepository, it supplied me with exactly the same concrete instance of FooRepository. Which would have been fine if it weren’t for the fact that FooRepository happened to indirectly hold a private reference to a thread-afine NHibernate session context. Ouchy.

The system I’m developing is a WCF service, and I’m using a Unit of Work pattern to open an NH session before the operation is invoked, and close it afterwards. To make this work, I simply needed to make sure that FooRepository (and any Castle-fulfilled component which has an IFooRepository dependency) has a transient lifestyle. Indeed, on further reflection, for most of the systems I develop, the transient lifestyles should be my default choice, and I do wonder why the Windsor developers chose to make singleton the default.

Davy Brion has more info on this topic in this blog post – Windsor and Component Instance Lifetimes.

So, moral of the story – understand how your IoC container is fulfilling your requests, and be prepared to specify non-default behaviours if necessary. Convention over configuration is only a benefit if you’re happy with the conventions.

Now admittedly I’ve had a glass of wine this evening, but c’mon Microsoft, I’ve read through this dialogue box thrice and I still don’t understand what you’re trying to tell me!

I’ve just found 22 examples of this anti-pattern in a small .NET project:

Oh yes, the empty catch block. Joy of joys.

Declaring an empty catch block is equivalent to professing that:

"Sometimes this code I’ve written fails. I don’t know why. I don’t really care. Please don’t tell me when it happens. I can’t hear you. La la la…"

*sigh*

If I ruled the world, empty catch blocks would be invalid in C#. Is there ever any reason for using them?

Improvements to the Execution Plan UI in SQL Server Management Studio 2008 sure do make it a doddle to improve query execution time.

A client just reported that a particular stored procedure kept timing out.

Viewing the Estimated Execution Plan for this query displayed a nice green message advising of a potentially missing index which could improve performance by >95%:

Right-clicking and selecting “Missing Index Details” then brings up a new query window containing the index creation DDL (I had changed the index name by the time I grabbed this capture):

Dead easy. Repeating the process identified a second index which could further improve performance by >80%.

Of course, you still need to bear in mind other queries which access the table, and the effects on inserts/updates of creating additional indexes, but even so, this really helps the workflow.

The suggested indexes functionality was actually available in SSMS 2005 too, but the results were buried away in the XML version of the execution plan, and obscure properties windows, rather than being so in your face.

I know it should no longer come as any surprise to me, but I just found this method (and several others like it) lurking in a Data Access Object. Grrr…

/// <summary>
/// Send an email to notify that accrual data has been successfully uploaded
/// </summary>
/// <param name="accrualUpload"></param>
/// <param name="recipientAddresses"></param>
public void SendSuccessfulUploadEmail(AccrualUpload accrualUpload, Collection<MailAddress> recipientAddresses)

Much of software design / architecture isn't technically difficult, it just requires a little thought - "where does this functionality belong?"; - rather than forcing code into the first class you come across.

Did I mention how useful NDepend is in exposing idiocy like this? I think I did. And I really should get round to blogging about how handy CodeRush and Refactor Pro are for cleaning up such smells.