Keeping a development journal

Since I started working as a programmer, I’ve always taken notes in meetings, and jotted things down during the day to remember, but these were all usually on an A4 notepad, which I’ve always used as a daily scratch pad, and until recently I have never kept a proper journal which I could refer back to at a later time.

A colleague of mine with whom I have been working on a project together, has for a long time kept a development journal, or diary, of things that have happened in his work day. Examples are:

  • Meeting notes, who was present, salient points of what was said and what was agreed
  • Design ideas, diagrams, pseudo code
  • Technical notes on gotchas in the language and application
  • Noteworthy events connected to the project

The event which got me interested in his note keeping was one day when the Produce Owner made a decision about the scope and importance of a particular feature. The colleague in question looked back over his notes and was able to prove that the PO had made a different decision about the same thing a few weeks before. When things like this happened a few more times, I really sat up and started to ask some questions.

“If it isn’t written down, it didn’t happen”, was the response.

If you write it down, you are more likely to remember it. There is a large body of evidence that suggests that the simple act of physically writing notes helps aid memory retention. There are a lot of articles and blogs about this subject, but I’d never paid it much attention. After all, I’d kept enough notes when at school and university, and I didn’t think I need to when I was working.

I could not have been more wrong.

So I started taking notes. I got an A4 lined hardback notebook and started writing stuff down.

And: It works.

So for example, I can tell you who made the decision in a meeting thirteen months ago which meant a feature in the application was developed in a particular way which now makes it upsettingly difficult to modify that part of the application. I can produce my design notes from six months ago where I planned the refactoring of some functionality, and the implications of said work, and which developers on the project I’d talked it through with to get some sanity checking that what I was proposing wasn’t stupid. I can tell you who brought cakes in on a particular day last month and who said which particular funny thing last week that is now part of the project slang.

What I’ve found is that if you write stuff down during the day, about what you are doing, it helps you remember (like the research says it will), and makes you think about what you have done already, and what you need to do in the future. This is all stuff that is required for a Scrum stand-up, if you have to do those. It also provides amunition for those of you who have to suffer through the dreaded annual performance appraisal; or, helps remind you what to list on the invoice when billing for the hours you’ve worked.

Lastly, it helps (me, anyway) remember what I was doing on my latest pet project that I haven’t touched for eight months. Which I should get back to.


For anyone keeping score, I haven’t updated my blog for over a year.

Insert excuses here

I know that I should do, Hanselman and Somnez both recommend it.

Anyway, I’ve come up with some goals for myself for the next year:

  • Get on Hanselminutes
    • Failing that, any other developer focused podcast will do
  • Blog more regularly
  • Contribute more to open source
  • Release an open source project of my own
  • Become rich and famous

So we shall see what happens.

You don't always need an IOC library

The principle of YAGNI should always apply, and I was recently reminded of that when I had to build a small application to give to a user for a small one off task. We’re talking a single screen application with a single button on it. Idiot proof.

So, File > New > Winforms application - doesn’t have to be anything fancy. Then I caught myself: My first instinct was to add StructureMap to it.

I thought to myself that it’s only going to have a few classes, I mean just because it’s a small winforms app doesn’t mean I’m going to shit up the code behind with business logic and data access, so why bother with the overhead of adding a IOC library?

It doesn’t mean I don’t have to use dependency injection. Mark Seemann calls this “Poor Man’s DI”.

    static class Program
        static void Main()

            var service = new Service(new Database(), new Other());
            Application.Run(new Main(service));

It’s short and sweet, and there is no IOC container configuration to worry about. Because I don’t need to.

What about when….

Requirements change. “Can it just do this as well…?” More dependencies required, perhaps another form, maybe another service or two. I think I’d see how far I could push Poor Man’s DI before I brought in a proper IOC container to help manage things.

Configuring SignalR in StructureMap

Configuring SignalR in ASP.NET MVC, using StructureMap as the IoC container is fairly straightforward, but not without some subtleties that caught me out.

For the purposes of this post, I’m going to assume that you are familiar with both SignalR and StructureMap, and that you know how to configure them in an ASP.NET MVC application. I will also assume that through some google-fu you have seen the Dependency Injection in SignalR guidance, and have worked through it and got to the “Using IoC Containers in SignalR” section.

I would assume, although I’ve not tested it, that much of this could also be applied to a self-hosted SignalR server.

Library versions used

This post is based on:

  • Asp.Net MVC 5.2.3
  • SignalR 2.2.0
  • StructureMap
  • StructureMap.MVC5

Follow the guidance up to the section on using Ninject, at which point we now want to configure StructureMap.

Replace the SignalR Dependency Resolver

The implementation is nearly identical, with some obvious StructureMap specific differences:

public class StructureMapSignalRDependencyResolver : DefaultDependencyResolver
    private readonly IContainer _container;
    public StructureMapSignalRDependencyResolver(IContainer container)
   	    _container = container;
    public override object GetService(Type serviceType)
   	    return _container.TryGetInstance(serviceType) ?? base.GetService(serviceType);
    public override IEnumerable<object> GetServices(Type serviceType)
   	    var objects = _container.GetAllInstances(serviceType).Cast<object>();
   	    return objects.Concat(base.GetServices(serviceType));

The behaviour is fairly similar. TryGetInstance will attempt to resolve the type, and if it doesn’t know about it, will return null, in which case we call the base resolver, which does.

Register this with StructureMap:


In your Startup, where you configure SignalR, we need to use this new resolver implementation:

var resolver = DependencyResolver.Current.GetService<Microsoft.AspNet.SignalR.IDependencyResolver>();

var hubConfiguration = new HubConfiguration
    Resolver = resolver

/* other options as required */

Here, we are using the MVC DependencyResolver, which has already been replaced by StructureMap thanks to StructureMap.MVC5, to resolve an instance of the SignalR dependency resolver we’ve registered, which we then tell SignalR to use with a hub configuration object.

Now we just need to configure the StructureMap registry, and teach it how to resolve IHubConnectionContext<dynamic>:

    .Is(ctx => ctx.GetInstance<IDependencyResolver>()

As in the guidance, we want the StockTicker instance to be a singleton, and we have specify how to resolve the IHubConnectionContext<dynamic> which the StockTicker requires. In the Is, I’m using the context to resolve the default SignalR connection manager we’ve registered. This isn’t in the guidance, but I couldn’t get it work without doing this.

If anyone has comments/improvements on this, I’d love to hear them.

MSBuild Code Analysis (on a build server)

It is possible to setup your build server to run code analysis on your solution/projects, without having to install VS on your build server.

The answer is here:

I’m not going to reproduce the code here, there is no point. This post is just a reminder to myself as to where I found the solution to this.

Gitlab and Active Directory

Gitlab is an open source ‘clone’ of Github, although I don’t think it’s much of a clone anymore, to be fair. The Enterprise edition has full Active Directory support, and the Community edition does not.

The integration with Active Directory is of great benefit. To get the most out of it, I think that you would need to upgrade to the Enterprise edition, as it adds a number of additonal integrations which look to be really usefull for larger organisations with multiple projects and development teams.

It is possible to configure the Community edition to integrate with Active Directory, to the extent that you can restrict exactly who is allowed to login in. You have to manually configure the users permissions on groups/projects though. In the Enterprise edition, the tighter integration means that you can match up Active Directory groups with groups in Gitlab, and control access both to the server, and groups/projects, all through Active Directory.

Here is the ldap section from my gitlab.yml (please be aware, I’m no Active Directory expert):

enabled: true
      label: 'domain'
      host: ''
      port: 389 
      uid: 'sAMAccountName'
      method: 'plain' 
      bind_dn: 'CN=Git Lab,OU=AB,OU=example,DC=example,DC=com'
      password: 'secret'
      allow_username_or_email_login: true
      active_directory: true
      base: 'OU=example,DC=example,DC=com'
      user_filter: '(memberOf=cn=devs,ou=groups,dc=example,dc=com)'

The bind_dn is for a user called ‘Git Lab’, and you must suppoly the password. This user was expressly setup just for this, but you can use any user. The base is the level of Active Directory that Gitlab searches for users from. Finally, the user_filter states that users must members of devs in order to be able to login.

ASP.Net Bootstrap 3 form control width

Having just been stumped on this for longer than I care to admit, and only finding the answer to my problem buried in a comment on StackOverflow, I’m posting it here for my own future reference:

Q: Using ASP.Net MVC with Bootstrap 3, why won’t my <input> stretch to the full width of a <div class="form-group">, even though I am putting form-control on the css class?

A: Because Microsoft override input, select and textarea to have max-width: 280px in the default Site.css which is added to new projects. Removing this will allow the 100% width from form-control.

Fluent NPoco mappings with StructureMap

I like using NPoco, it’s a really nice library that allows you stop having to write raw ADO.NET. Recently I just switched one of my projects at work to use the Fluent Mapping features, essentially so that my POCO’s do not need to have the mapping attributes in them.

I started wth the example on the NPoco wiki of creating a database factory, and adding the mapping class to the fluent configuration. As the number of mapping classes has grown, this has quickly become unwieldy and a bit of a maintainance issue.

As I already utilise Structuremap in the application, I wanted to configure it to automatically pick up my mapping classes and build the configuration object for me. This is easy to in the registry:

public DefaultRegistry()
		scan =>
			scan.With(new ControllerConvention());

	For<FluentConfig>().Use(context => FluentMappingConfiguration.Configure(context.GetAllInstances<IMap>().ToArray()));
	For<IDatabase>().HttpContextScoped().Use(context => context.GetInstance<DatabaseFactory>().GetDatabase());

The mapping classes must inherit from Map<T>, which itself inherits from IMap. Thus we can confidently add all types of IMap in the scan.

Then an instance of FluentConfig must be registered, which can be done with an overload of .Use, from which we get the StructureMap context and pull out all the types of IMap which have been found and pass it to the static .Configure method of the FluentMappingConfiguration, which constructs the instance.

The DatabaseFactory (see below) is then registered, and it accepts a ‘FluentConfig’ instance in its constructor. As per the original example on the NPoco wiki, it is marked as a singleton to ensure that only one instance is created, so that the mappings do not get registered more than once. I don’t know what would happen if the mappings were to be registered more than once, but I assume that it would be a Bad Thing™.

Then, for the NPoco IDatabase instance that we register, we want to always create it using the instance of the DatabaseFactory that has already been registered, which again is accessible using the overload of .Use to get the Structuremap context. It’s marked as .HttpContextScoped(), but I’m honestly not sure if that’s required or not given that I’m using Structuremap.MVC5 nested containers.

For completeness, here is the DatabaseFactory:

public class DatabaseFactory
	private static NPoco.DatabaseFactory _internalFactory;

	public DatabaseFactory(FluentConfig fluentConfig)

	private static void Configure(FluentConfig fluentConfiguration)
		_internalFactory = NPoco.DatabaseFactory.Config(x =>
			x.UsingDatabase(() => new Database("ConnectionString"));

	public NPoco.Database GetDatabase()
		return _internalFactory.GetDatabase();

Learned so much about Vim that I should already know

I’ve been a user of Vim for several years now. I use it as my go-to standard editor. As I primarily write C# code, I obviously use Visual Studio, a lot, and I have the wonderful VsVim extension installed, which provides a lot of the power of Vim, from within Visual Studio.

I thought I was pretty good at using Vim, until the other day when I saw Vim being used in some screencasts and I immediately thought that I suck at using Vim.

It turns out, that I learned enough about using Vim that got me a good increase in productivity, that I basically stopped learning how to use it. My brain must have decided that I learned all I needed to know to get me through my day, and stopped me wanting to learn anymore.

I have now found a great source of screencasts about using Vim, here, which are split into Beginner, Intermediate and Advanced. I learned how to do new stuff with Vim that is in the first beginner video.

I wish that I had found these videos several years ago when I was first starting out with Vim, as watching them then would probably have saved me a lot of time over the last several years.

About those view locator conventions

As I mentioned in a previous post, I do not like some of the default PRISM view location conventions.

As a refresher, these are:

  • View models to be located in a folder called ViewModel, named MyAwesomeViewModel
  • Views to be located in a folder called Views, named MyAwesome

It’s the view naming that I don’t like: In my world (which is based on Caliburn.Micro and ReactiveUI), views should be named MyAwesomeView. This is a simple distinction, but an important one for me because I automatically expect view names to end in View.

Fortunately in PRISM 5, this is easy to change:

ViewModelLocationProvider.SetDefaultViewTypeToViewModelTypeResolver(viewType =>
    var viewName = viewType.FullName;
    var viewAssemblyName = viewType.GetTypeInfo().Assembly.FullName;
    var viewModelName = string.Format(CultureInfo.InvariantCulture, " {0}Model, {1} ", viewName.Replace("Views", "ViewModels"), viewAssemblyName);
    return Type.GetType(viewModelName);

We get the full name of the view, and the full name of the assembly, and then replace “Views” for the “ViewModels” folder, and add “Model” to the end. I would call this somewhere in your applications startup, such as in the bootstrapper Run.


Something else that you can do in PRISM 5, is autowire the view model and view such that the DataContext of the view is automatically populated.

ViewModelLocationProvider.SetDefaultViewModelFactory(type => Container.GetInstance(type));

I’m using StructureMap here (of which I am a big fan), but you should be able to get to work with your favourite IoC library.

This though, means that you have to tell StructureMap about all your views in order for it to be able to resolve them. That’s too much messing about remembering having to update a Registry everytime I add a view. StructureMap can solve that for us no problem:

public class ViewRegistrationConvention : IRegistrationConvention
    public void Process(Type type, Registry registry)
        if (!type.Name.EndsWith("View") || ! type.IsConcrete()) return ;


Here we say that if the name of the type being resolved ends with “View”, and it is a concrete type (i.e. not an abstract class or interface), then add it to the registry. The trick with PRISM is that it is asking to resolve an object with a specific name, it doesn’t try to resolve the type of the view, so adding something to the registry as For<MyAwesomeView>().Use<MyAwesomeView>() won’t work, you have to use For(typeof(object)) and make it a named instance, using the name of the type.

And then just register the convention when you configure the container:

Container.Configure(configure =>
    configure.Scan(scan =>

Then from the region manager, you can RequestNavigate("AwesomeRegion", new Uri(typeof(MyAwesomeView))), or use the extension method in my previous post.