Deliberate and thoughtful architectural decisions that solve real business problems and mitigate enough of the real risks, is the RIGHT and the MIDDLE PATH way to go.
In this post I present some finer grained lessons we’ve learned (a. k. a burn marks) since then having solved some foundational problems that surfaced due to not paying enough attention to the failure modes inherent in EDAs, upfront
Using C# Source Generators to generate DTOs could potentially save a lot of developer time, so in this post I am going to attempt to write just such a generator.
We built an event driven system in my team over 2 years ago that sometime back ran into database transaction deadlock problems which puzzled me enough to want to take a deeper look into what happened. This mini-post is a bit of documentation of that investigation.
The central idea around Blazor auth is for the UI system to be able to query the authentication state of the user and render different views. Blazor uses AuthenticationStateProvider to query this auth state via the AuthorizeView component.
Given the fact that there is no shortage of SPA frameworks and libraries like Angular, React, Vue, Knockout ad inifitum, for building the new frontend app for my app, I decided to go with Blazor.
I have a personal expense tracking app that for the last few months I’d been working to migrate away from MVC towards more modern client apps whilst reusing the backend code and logic.
Not long ago we completed the migration of all our services to .NET Core. Of note was a mission critical full .NET framework legacy Windows Service and in this post I would like to share how we completed that migration.
There are many posts and articles that expound the virtues of paying back the tech debt and philosophise at great lengths about the various design patterns that can improve the design of the code. In this post I’d like to tackle the more pragmatic and real life aspects around tech debt from my perspective.
A few weeks ago I came across this Mars Rover programming challenge/kata and being a bit of a space buff, I thought I will take a crack at it.
In this post I will share some of the TDD heuristics that I have found useful on when you should use mocking to verify interactions and when should you resort to state verification.
Recently a planned AWS Aurora database failover/master reboot caused database connection failures in one of our services which caused me to delve deeper into how MySql driver manages connections under the hood.