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.
Pair programming in pre-COVID 19 used to be somewhat easier because we were all in the same office space. COVID-19 changed all that…
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.
Couple of days ago, we had an outage in one of our production APIs that’s built with ASP.NET Core 2.0 and all we got to see in all our logging was something similar to this which doesn’t really help reveal the root cause: After much debugging hassle for several hours we found that it was […]
Many articles talk about the what of this style but in my view, not enough talk about the how. In this post, I am going to try and show one way to actually structure the solution to be more in line with the hexagonal ports and adapters style.
…the whole business process can be divided into smaller asynchronous sub-processes with each one feeding i.e. “piping” its output into the input of the subsequent process(es). At each stage some processing is done for e.g. data enriching, filtering etc and this processing generically is termed as a “filter”.
The way logging and instrumentation in code has traditionally been done is something like the below, say, I want to profile my application service method called “PeriodCloseReportAsync()” that gets called from my MVC controller action: This can be ok to a certain extent as long as the application is simple enough and you only intend […]