4 minutes to read read

Around four years ago when .Net Core was in its early stages, I wrote back a Configuration provider for .net core 1.x. This has been a long time. The package did picked up very well and there were multiple downloads and a few queries as well. Many people would never know that .net core started with json project files. But since then a lot changed and my package went obsolete.

A few days back got some time and bandwidth and wised to revise the package. This would not only update the latest package but would also help me understand what changes have been done as in framework as a whole. So, my fellow countrymen let me present you the MongoDbConfiguration Provider for .net Core (😁) /s

Read on further to get the details as I explain the “simple” steps to write a custom configuration provider for .net core 3.1.

Continue reading

5 minutes to read read

In the modern everything is evolving very rapidly, and so is Web and standards. From SOAP to REST, standards have been shifting, but they seemed to have been stuck for a while while with the REST. Well, now again the ball is getting rolling with gRPC, the latest kid in the town. Not only it has all the latest and cool gadgets in its pocket, it is fast, really fast secure and can solve some of the typical problems that have been with since ailing the normal REST communications.

But.. There is always a but.. But, there are always two side of coin with all flexibility, there are some challenges. This is first part of the 3 article series on gRPC, what – why and how series including the handon demo. So without wasting time, lets dive in. This is a bit theoretical shit. For quick codies, you can jump to implementation in next article.

Continue reading

2 minutes to read read

I have been struggling for some time to manage multiple GIT repos. Like me there could be multiple cases you need to manage and pull multiple GIT repos. This is the tools which can easily manage and do that. Just define it once and good to go always. Personally for me, its like a daily routine. In the morning, connect and pull all and get all repos at once, without firing pull in cd(ing) each repo and issuing git pull.

Continue reading

4 minutes to read read

Some time back as I remember, AWS was the biggest (and probably only leading) cloud provider. But with each gone day, Azure is increasing its product base in competition to AWS. Many of these products are inspired (don’t read as copy) originally from AWS. Also, in most of the Azure products, you will find a small asterisk hidden somewhere and cost is something which is more or less equal or expensive.

Despite all these facts, slowly and gradually with a pace approaching AWS and could takeover in a few years. Well, this seems to be a little too much from a developer without understanding of deeper market dynamics, but rather this is from the heart and trouble ship that I have faced, and probably many of the other developers facing. Alert, this post contains no code, but theory.

Continue reading

5 minutes to read read

With the advent of .Net Core, web Api have become more common. Apologies to my non-dotnet background friends, but with .net hands-on, its always inclined towards .net. Coming straight to the point, be it Mobile Apps, SPAs (Single Page Applications), micro-services or name whatever, you will see REST everywhere. In background of this post, old kishore kumar songs are running, so don’t offend a bit of nostalgia 😊.

But as in most cases, everyone is so busy in implementing the APIs, many of my friends don’t ever pay attention on how an API be named. Or rather, not an API but the endpoints and methods (hate to call them methods). Well, for an API the problem there is no standard as such, but rather some best practices, that should be followed ‘ideally’. Lets discuss them one by one. Most importantly, in this post shall be talking only on the API naming. I also had OpenApi in mind, but lets leave it for another post. So lets dive in.

Continue reading

4 minutes to read read

Working with several customers over the past years, one of the NFR being enforced by customers is Code Coverage, some customers push for 80% while some others ask for 90%. Even had a client which asks for 95% in older days. Also, there is significant cost and effort involved with increasing coverage compliance. And once the said coverage is achieved, its assumed the code is good and safe. Testability of code is a whole story alltogether that deserves a post separately, this post targets more of coverage part.

Offcourse 100% is something next to impossible and thats what nobody dares it to ask or enforce. And this gives a margin for 5 or 10% or even 20% and here comes the problem set of problems. Lets deep dive in, consider the following code.

Continue reading