Tuesday 13 December 2011

Out of band caching

One of the things we try and do is always keep our site up, sounds simple right? One way to achieve this is to have a good caching policy.

Here's what we do:
  • Cache a response from some external service (be it a db or web service, whatever)
  • When a user request the resource ALWAYS serve it from cache if it's there
  • Then "out of band" (i.e. on a different thread) make a call to get it from the external service and update the cache if you get a valid response.
  • But only do this if the cache is stale
Simple right? That way if your external service goes down you can still serve it from cache. Your user will always get the fastest possible response (i.e. they wont be the sucker who has to go and get it). And your service remains up as much as possible.

Thursday 24 November 2011

Double Entry Accounting and TDD

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?

Well you should be using different ways to make your assertions from your implementation, particularly when you talk about integration tests.

Lets say your writing some integration tests for a repository. Lets say you're using Simple.Data to access your database. Your tests should then use something else. You should probably get as close to the metal possible. In this case you should probably use the SqlCommand class.

Put some data in your database using SqlCommand. Then assert that you can retrieve it using Simple.Data.

That way you are making a Double Entry Assertion in your tests. The chances of both systems being broken in the same way are reduced.

Sunday 13 November 2011

Red feature tests are pointless

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?

We improved the reliability of the tests that we could and removed the ones we couldn't. Now you may think this is a bit of a cop out, but the amount of feedback we were getting from the tests was negligible. The best think you can get from your tests is something you don't expect. you should expect them to pass and be surprised or shocked when they don't.

Stop the line and fix the problem. Don't just keep running them again.

Tuesday 21 June 2011

MVC and our interpretation at 7digital

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.

Queries(GET)/Commands(POST)

* Contain all the information required to perform an action.
* Data should be bound onto the query before it hits the controller action.
* They are POCO and contain no logic.

Controllers

* Marshall request to handlers and mappers
* Creates the view model from the handler result

Handler

* Process queries/commands
* returns various types (Model/Entity/API DTO)

View Models

* Contains data that you are using in the view, should not expose anything other than view models/value types.

View

* Stuff you show the user, should only contain logic that is required to get the stuff displaying correctly.

Wrappers

* Wrap calls to external api

Services

* Do things that aren't simple, pull together bits and bobs and package them up. Take care of business logic that have cross cutting concerns.

Mappers

* Mappers simply convert one object to another. They DO NOT perform any other logic.

Charts Example from http://www.7digital.com/b/charts

ArtistChartController

* Takes the query from the web request (which has been bound in the pipeline)
* Passes the query to a handler
* Maps response from handler to view model using auto mapper

ArtistChartQueryHandler

* Takes the query
* Does some work to get some configuration options
* Builds up the query further to execute against the API wrapper
* Returns API DTO

Api Wrapper

* Takes query
* Executes against external API
* Parses responses and maps into API DTO object

Friday 14 January 2011

Resolving an open generic type with Castle Windsor

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<T>
{
    void Handle(T instance);
}

public class FileNotFoundHandler : IHandler<FileNotFoundException>
{
    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<T> : IHandler
{

}

public interface IHandler
{
   void Handle(object instance);
}

public class FileNotFoundHandler : IHandler<FileNotFoundException>
{
    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.