Antony Denyer

Double-entry bookkeeping system A double-entry bookkeeping system is a set of rules for recording financial information in a financial accounting system in which every transaction or event changes at least two different nominal ledger accounts. At it’s simplest you have two ledgers when you make an account transaction you make an entry in both ledgers. Then at the end of the month you reconcile these two ledgers and they should be the same. Essentially from an accounting point of view we’re saying that by using two different ways of doing something we come to the same answer. Why is the useful from a TDD perspective? [Read More]

We’ve spent a lot of time recently on fixing up our automated feature tests (AATs). The problem has been that these failing tests have blinded us to real problems that have crept into live systems. The usual answer is to ‘just run them again’ and eventually they go green. The main problem is our attitude to the tests, we don’t respect them and we don’t listen to them, as such they provide no feedback and are completely pointless. The response to broken feature tests would normally range from the test environment is down, the data is in contention, the database is down etc etc, but never something I’ve done has broken something. So what is the solution? [Read More]

Introduction The following details concepts that have been adopted on the site I’m currently working on. This was born out of a discussion that took place among the devteam at the time. Differences in phraseology and meaning were ironed out to come up the following definitions and responsibilities. [Read More]

One of things I wanted to do the other day was resolve an open generic interface. Or more specifically resolve a generic type at runtime. This is what we came up with: var argumentsAsAnonymousType = typeof(IHandler) .MakeGenericType(instance.GetType()); var concrete = IoC.Container.Resolve(argumentsAsAnonymousType); The first problem was resolving an open generic type, this was solved using MakeGeneric. This returns a type object which you can pass to windsor to resolve for you. But now you’re left in a situation where you don’t know what the returning type is. You could use reflection to call the method.  The good thing about this is in the type you’re declaring you can afford to use a generic type. public interface IHandler { void Handle(T instance); } public class FileNotFoundHandler : IHandler { public void Handle(FileNotFoundException exception) { _logger.Warn(fileNotFoundException.FileName) } } The downside is, you’re using reflection! The alternative is to use a non generic interface and utilize interface inheritance. public interface IHandler : IHandler { } public interface IHandler { void Handle(object instance); } public class FileNotFoundHandler : IHandler { public void Handle(object exception) { var fileNotFoundException as FileNotFoundException; _logger.Warn(fileNotFoundException.FileName) } } That way when you resolve the handler you can cast it. var argumentsAsAnonymousType = typeof(IHandler) .MakeGenericType(instance.GetType()); var concrete = IoC.Container.Resolve(argumentsAsAnonymousType) as IHandler; concrete.Handle(exception) The benefit now is that you don’t need to use reflection. The down side is that you need to unbox your object inside the handler, however this shouldn’t be an issue as you’ve already guaranteed the type when you resolve the object.