'The game' is the heart of this system. It's important to understand how user actions relate to each other and how to maintain a valid state of the game. Now I'm not a DDD expert, but I know Domain Models are a pretty nice way to do validation and propagate changes to 'a system'. So in this blog post, I'll discuss the design of the domain model.

This is part 2 of my game development blog. It's all about friendships. Keez is a game you play with friends. So when logged in, you need to be able to make friends in order to play the game. At first, the game requires exactly four players, meaning you need three friends in order to create a new game. In case you have no friendships, you can still be someone else's friend and thus be invited to games. This means that friendships are not (yet) bi-directional. Now how do we do this?

This blog post is part one of what I expect is going to be a large series. It's my opportunity to build stuff in the Azure Cloud while ending up with a cool online playable game. It's a board game, played against others. The game is not even half-way finished and I don't know when it's going to be finished. I don't want to spend _all_ my spare time. In this series, I will blog about my progress, how I designed the game from an architectural perspective, and how I solved problems as a (C#) developer.

The migration of software to the cloud has begun, a long time ago... In fact, when I started writing software for the cloud somewhere in 2010, I expected us to be a lot further by now. Now, ten years later, cloud services are very mature, fairly cheap compared to on-premises hosting, and very secure. All this, makes me ask why some companies still don't embrace the cloud. One example is scaling. It's almost impossible to host a service on-premises and make it scale as it could in the cloud. Distributed systems leverage this power which makes it almost too easy to build software systems that scale extremely well. But every huge advantage comes with a downside. In this story about eventual consistency, I will show how how to tackle this problem using the Azure Service Bus.

Because we want to keep work items as small as possible, it's not always possible to deliver value when you're using CI/CD, simply because a feature is just not done yet. Yes, you did finish the story and yes you added value. But it's simply not good enough for production yet. More and more stories are completed and merged to the main branch, now what do you do? Release a partially finished feature along with the bug fixes, or wait for the entire feature to complete before you release. The real answer is feature toggles. And once you worked with them, you'll probably never go back.

The term DevOps is already here for a couple of years now, and so is DevSecOps. But the term DevSecOps is not commonly heard. Is it because nobody uses it? Or is it that the Sec in DevSecOps is so natural, that it's not worth mentioning? I don't know, but let's dig into the Sec of DevSecOps!

As all developers know, caching stuff can boost system performance here and there. Caching is a super-fast mechanism that allows you to store stuff (for a certain amount of time). That stuff is now available for fetching in a super-fast way. In the Cloud, no difference. However, the approach does change a little bit.

There are various ways to host your Angular SPA in Azure, I believe I found the cheapest solution right here. It takes some time to configure but it's definitely worth the effort.

I'm struggling for a long long time with ARM templates. Now I got some time to work with them and found that they are still quite complicated, but explainable. I could not find a convenient A to Z tutorial or blog, so I decided to make one.

For demo's, I host my code in GitHub. It's easy, fast and allows interested people to download and use your code in no-time. However, for some of these projects I like to build, test and even deploy stuff to test or demo environments so I can show them.