Entries categorized 'Blog' ↓

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!

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.