For quite some time now, I’ve been thinking of the design of a so-called Running Mate application. I decided that it was time to implement it and the trigger that set me of was to have a fun example to use at a performance tuning presentation. So beneath is what I have in mind as blog topics although it can change somewhat as I go ahead:

1. The Running Mate – What is it and why?
   This is a personal touched blog post with the background story as to why on earth I think the Running Mate application is a nice thing. Off course, this blog post also lets you know what the application is actually doing
   
2. The Running Mate – Code available at Codeplex
   Source code available and some words about what is provided and what is not provided in the repository as well as some file structure information.
   
3. The Running Mate – The geometry calculations
   In order to implement this application some interesting geometric calculation is needed. This blog describes these calculations.
   
4. The Running Mate – The Super Hack implementation
   Sometimes I start off by doing a rather quick and dirty implementation of the application and then refactor my way into a more nice design. I didn't actually do this for this one, but I needed super hack implememntation for my presentation. So this is breif presentation of a quick and dirty implementation.
   
5. The Running Mate – The Domain Driven Design approach
   In this blog post I transform the application into a design that is closer to a Domain Driven Design.
   
6. The Running Mate – The O/R Mapper Repository
   The repositories built in the previous blog post uses a classical database access layer wrapped in repositories with inline (ad hoc) SQL. Here’s an alternative approach with the MindScape LightSpeed O/R mapper.
   
7. The Running Mate – The loosely coupled Domain Layer
   Most O/R mappers integrate into the Domain Model rather tightly and make it a bit more difficult to switch from one O/R mapper to another one. This is a bit strange since O/R mappers themselves make the choice of underlying database very flexible. In this blog post I describe how you can decouple a domain model from the application so that you can have several different versions of domain layers that the application can utilize. The loosely coupled domain model is not always that useful in reality, but it is a nice experiment.   

I may change the topic names slightly as I go ahead and write about them, but I hope you can live with this. There are actually many more blog posts that I can write based on this application. For instance I would like to write some more about the LightSpeed O/R mapper and how you can wrap the basic CRUD stuff to make these methods really easy to access with a simple API. Also, there is a lot of stuff on performance tuning this application that I would like to write about eventually. But I better not promise too many blog topics in advance since you never know what lies round the corner.

So. Basically, I am back in the blogosphere for another round.