Posts

I’ve been making great use of the Model Context Protocol (MCP) as part of our AI stack at work, using it to expose functionality within our platform as MCP tools that can then be used by our LLM. In particular, I’ve been leveraging the official Model Context Protocol C# SDK to build out our MCP server. Unfortunately, this project is still fairly young so there hasn’t been a lot of knowledge shared out about how to do more “exotic” things with the SDK when it comes to building MCP servers.

A very common development strategy with Git is to create a new branch for every feature and bug you work on, then once the code passes code review, to then merge it to the correct shared branch. The problem then becomes that you end up with a bunch of branches over time that you no longer need. We can use some simple shell commands to clean up these branches.

The Code

# Stop tracking any remotes that no longer exist
git fetch -p

# We output the branch list to a file so we can edit it and 
# decide which branches we wish to remove
git branch -vv | grep ': gone' | awk '{print $1}' > branch-list

# Remove the orphaned branches
cat branch-list | xargs git branch -D

If you are using the Fish shell, you can also use this function to turn this into a one liner:

ASP.NET Core makes it extremely easy to configure authentication right out of the box with a choice from a plethora of different built-in authentication handlers. Everything from Single Sign On with Facebook to JWT to simple cookie authentication is available right out of the box. Where I found the ASP.NET Core documentation lacking was when attempting to use multiple authentication handlers at the same time. I was already using the JWT handler in my application, but I wanted to have my custom API key authentication handler run and handle authentication if no Authorization header was supplied as part of the request. Finding the answer to how to accomplish that took longer than it should have, so hopefully this blog post will save others from that same fate.

SignalR poses some small challenges when running in a load balanced environment. When you have multiple servers then some users will have SignalR connections open to one server and then some users will have SignalR connections open to another. The usual solution is to use a SignalR backplane so that all the servers in your cluster can see every SignalR message that was sent, then forward the message to the appropriate users connected to each server. This way users connected to Server B can see SignalR messages sent from Server A. Then you smack a load balancer in front of all the SignalR servers so that you can evenly distribute traffic across all of them, the only problem is that traditionally you have to use sticky sessions on your load balancer in order to make SignalR work.

One of the things that has been long overdue on my personal to-do list is to get back into blogging. With the general availability of the new .dev domain last week, I decided it was finally time to take the plunge after buying a fancy new vanity domain. This blog post will describe how I setup a new blog using Hugo for the static site, Docker and NGINX for deployment, and Amazon ECR and ECS for hosting.

Although there are some special considerations, designing for testability largely involves following well established software design principles. In this blog post I’ll cover these design principles and how they help with testability and also cover any special considerations that you’ll need to keep in mind.

Useful Software Design Principles

• Single Responsiblity Principle

For those not familiar with the Single Responsiblity Principle (SRP), it was originally proposed by Uncle Bob Martin and states that a class should have a single responsibility or reason to change. The most important thing about this principle is that it promotes the separation of concerns. Consider the example below:

For the rest of the articles in this series, we’ll be using the excellent xUnit.net unit testing framework to write tests. This is the unit testing framework with the greatest amount of mindshare at the moment, with Microsoft having recently adopted it for the various ASP.NET projects that they have open sourced.

Before we begin, we’ll need to cover some simple concepts around how to write your tests. When writing a unit test, the thing being tested is called the System Under Test (or SUT for short). The SUT can be just be about anything but is typically a method in a particular class. Since a unit test should only test a single thing then it follows that each of your tests should only have a single SUT.

Let’s be honest, manually testing software sucks. When developing a new feature, you’ll often have to manually test your changes multiple times to ensure everything is working. If you are a web developer, this usually means jumping through hoops in order to test your code through the UI. What you really want is a way to automate these tests and run them whenever you make a change. Even better would be a way to run these tests everytime someone else makes a change to the software as well. This is where unit testing and automated testing in general comes in.