CAP Theorem, PACELC, and Microservices
CAP Theorem generally applies to distribute databases. PACELC builds on CAP and describes system behavior when no network partition exists. Both of these can be applied in the context of microservices.
MANY articles on a wide array of topics. You’ll find a lot of my newer content is going to my YouTube channel first, but I do still blog occasionally.
CAP Theorem generally applies to distribute databases. PACELC builds on CAP and describes system behavior when no network partition exists. Both of these can be applied in the context of microservices.
If you're going to be using GitHub actions a lot, it may be worthwhile to create reusable templates you can create from the dotnet command line interface.
Estimates are, unfortunately, sometimes necessary. Despite being wrong, frequently a waste of resources, having a short shelf life, and being non-transferable. Sometimes you just need them in order to make a plan.
If you're seeing an error that says " An attempt was made to access a socket in a way forbidden by its access permissions." this may fix it.
Unknowns are inherently risky. Known risks you can plan for; unknown risks you need to learn more about so that you can mitigate them. Shifting risk left means taking actions that allow you to de-risk unknowns now, …
Estimates are perishable. As soon as they're made, new information makes them obsolete. Unless updated frequently, whatever value estimates provide quickly diminishes.
Estimates are at best educated guesses, and the further out in the future they are, the less likely they are to reflect reality. Ignore this fact at your peril.
Estimates are made by individuals, with individual assumptions. As such, they don't transfer well between individuals, even within the same role or skillset.
Estimates are waste, in that time spent estimating is often time that could have been spent producing something with business value. The first of the 5 laws of software estimates, this one is easy to demonstrate in the …
Postel's Law, also known as the Robustness Principle, states that TCP implementations should be conservative in what they do (send), but liberal in what they accept from others. It's credited with helping the early …