Microsoft SQL Server brought some major enhancements recently one of them was native support for Temporal Design “out of the box”. Temporal Design can sometime be challenging. I have personally spent months writing a Custom Middleware layer for Temporal Support since client had explicit requirements for auditability.And believe me, it was not easy.
Realizing the potential of the feature, soon after Entity Framework Team jump into the bandwagon and we had a fully functional Temporal Design purely “as a code” that can be used directly. Also, the features include querying point in time (and other similar operations) out of the box which are very handy. Some of the major advantages are pointed out below.
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.
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.
Asp.Net Core is one of the gems (I would say) created by Microsoft that has simplified a lot of things and provides a whole lot of things by default out of the box. It based on dot net core which provides inherent capability to run cross platform but to ease out developer life several optimizations were done to enhance productivity.
One such feature is Dependency Injection. Although lately, but Microsoft did included dependency injection as a part of the core product. I have been working Asp.Net MVC since 2010 (or 2011) and started DI with Ninject which was (or is) a wonderful project. During the time I crossed paths with Unity and Autofac during different projects, but more or less the approach remain same. Create a container system, create ‘sort of’ controller factories and then register dependencies. But during all this time one thing that remain constant was additional overhead of creating this shit. So it was a moment of joy (atleast for me) when i say this in recent versions of MVC. And most importantly it is quite stable and performs well out of the box.
Async Await is one of the best feature that has changed a lot of dynamics in the recent past, but it has created same amount confusion and chaos. Lot of bad practices, wrong usage has plagued the very usage. I have refactored a very huge WPF code with lots of out ref and reference based codebase to new pattern, on covering ~80% of it, faced a few challenges reverted back. Then after a month took the task again and completed migration.
I do receive a lot of issues in PRs around this. Based on this feeling that there would be many others who are facing such isssue, this post is more targetted from experiences. There could be log of posts and videos and shit load of resources, but I would try to write it concisely and in simple language/. Again, comments are open for discussion.
< 1minute to readAzure Application Insights provides a detailed Telemetry about the Application during its lifecycle. It can manage all details for application from Exceptions to CPU and Performance Counters.the level of Instrumentation is completely customizable.
In this Podcast, we plan to have a base understanding, with a short demo including the setup and and configurable alerts.
Please ignore the little not so good sound quality issues because of bad mic. will try to fix in next podcast.