In a previous post I detailed hosting Foundry VTT in Azure. I didn’t go into detail about how the actual deployment was executed, as I thought it would make a post of its own, particularly as I ended up throwing Circle CI into the mix. So here is that post.

I bought the excellent web based virtual table top Foundry VTT last year in order to play the TTRPG Cyberpunk Red remotely, and also to learn how to run it.

I don’t like to use .Verify too much in Moq, but recently I have found it useful to be able to verify something has happened by checking an invocation on an ILogger<T>. To achieve this I use the following utility method:

I had some legacy code which required that an int be reserved and a bool be returned if it failed. The int would be returned via an out parameter. For the purpose of the test I also wanted to increment the int every time it was requested.

Leader Election is useful in distributed systems as it gives sole responsiblilty to a single node for things which can’t be performed concurrently in a safe manner. This is particularly useful in Kubernetes where we will be running multiple instances of the same app spread across pods. An example would be reserving resources on behalf of the entire deployment.

In 10 years of working with MongoDB I’ve found that developing against it is great, but putting changes live is not so great, due to the fact it’s impossible to say for sure how the live database compares to the database you’ve been developing against.

The number one issue I’ve seen when people start using Git is dealing with submodules in existing projects. Recently I’ve been considering moving everything to subtrees, but I don’t see that as a direct replacement. In this post I explain why.