Well, what a great time to be a .NET developer! With all the changes that have been happening over the last year or so - with the new cross platform .NET Core, Azure, Microsoft's embracing of open source, and so much more!

Whilst I've used Docker in the past, it has only really been for development and prototyping - mainly to host 3rd party software - eg. MongoDB, Neo4j, etc. I've tended to have my webapp itself outside of Docker - partly due to not using the Core version of ASP.NET, which isn't cross platform. So I decided it was about time I had a go at setting up ASP.NET Core in Docker! It turns out that this is actually extremely easy!

Whilst most projects are quite different from one another, the project management tools used are usually very similar. For example, most projects (hopefully!) store the source code in some form of source control system, like Git. Also, most projects involve some form of bug tracking system - eg. JIRA, Mantis, Redmine, etc.

Following on from my previous post about dependency injection, the topic of IoC containers feels like a nice continuation. I wanted to keep the two posts separate, because it's important to understand that you do not need an IoC Container just because you want to inject your dependencies. Dependency injection itself is a very simple concept - all you're doing is passing an instance of the dependency into your code as an abstraction (ie. via an interface or abstract class the dependency implements). You do not need an IoC container to do this. An IoC Container is just a library to help you manage doing so.

Following on from my post about why you should write automated tests, I wanted to talk about how to write code that is testable. Unfortunately, unless you explicitly know how to write testable code, and are familiar with the SOLID principles (which from my experience, the average developer isn't!) - then the natural way we write code, and the way we typically learn to code makes it very hard to write unit/integration tests against our code.

Well, 2015 was definitely quite an interesting year - with two job changes, and the start of my own company! But far more importantly - we had the very exciting news that we're going to have another little baby boy mid 2016!

Seven weeks ago we were told that our company was going into administration due to financial difficulties. Whilst at the time, this didn't necessarily mean the company was closing down, and there was chance of finding a buyer, unfortunately on Friday we were informed that the decision had been made to liquidate the company. There were a few interested parties, but the investors had decided to cut their losses and close the company rather than risking putting more money in.

My last post was focused around a problem in Git which occurs when the rebase command isn't used, and developers blindly use pull/push. The problem is that it creates pointless merge commits, and also stops the Git history from being linear, ie. the branches are diverging and remerging back in all the time. It makes the history extremely hard to read and understand.

I'm a huge fan of Git, but have certainly found it has a bit of a learning curve when first starting off. Whilst I now feel extremely confident using it, there were quite a few 'aha' moments required to get here. Git gives you a huge amount of power and flexibly - but it is frustrating that unless all developers working on a codebase properly understand it - especially rebasing - then the codebase tends to have LOTS of erroneous merge commits, making the Git history a complete mess.

I'm sorry, but this post has been born purely our of frustration. Yesterday, as part of a support ticket with my domain provider about an old account, they sent me my login details...