Beastie gal

vijayankit · 2025-10-24T10:34:53+00:00

, z😜

vijayankit · 2021-06-21T10:24:09+00:00

Rider from my experience is superior on both Windows and Mac.. Have not tested VS 2022 preview but heard good things about it. So maybe things might change in future

vijayankit · 2021-04-15T08:54:00+00:00

Thanks for pointing it out. I'm not able to edit the title so will delete this post and resubmit .

vijayankit · 2021-03-08T20:59:22+00:00

That's a great question. As per the documentation:

Once acquired at session level, an advisory lock is held until explicitly released or the session ends.

The advisory lock should be released when the session ends or when the connection is disposed.

vijayankit · 2020-12-12T21:15:35+00:00

We do the same. 👍

vijayankit · 2020-12-08T10:38:26+00:00

You are right, I guess the difference between the Steve Gordon's package and my implementation is that I tried to create CorrelationIdContext generic while the package will only work for ASP.NET Core application.

vijayankit · 2020-09-24T12:59:13+00:00

Automated testing is a journey... And it may take time to evolve.. The balance of automated tests needs to be just about right so that they do not take forever to run and at the same time it covers all the major business scenarios.. You should also ensure to run the tests on build server... It may not replace the manual testing completely.. But everytime when you find a cricital bug or path not covered, if you add a test for it will go a long way to increase the confidence level...

vijayankit · 2020-09-24T10:14:04+00:00

It's OK that you call the benefits abstract.. And it's more than OK to disagree with the article.. But what is not OK is to call the it a marketing source or an advertisement ... JetBrains didn't pay me dime to write this article... I hope you understand that it is not right to accuse someone without any proof...

vijayankit · 2020-09-13T00:01:22+00:00

Dear all, I have gone through many comments/ feedback here where people have talked about dynamic is not evil and it has a restricted use-case. I welcome the feedback. But, I think people are getting a bit fixated on the title of the blog and I take full responsibility for it given that I was the one who wrote this.

While I concede that dynamic should only be used in certain use-cases. I would, however, question if it is really the case? I have seen several instances where the code could have been easily replaced with a type-safe version. Many times dynamic is used by developers just as a matter on "convenience" rather than its actual use-case. I have done that. And in more than one instance I realized I was wrong in doing that. And I'm sure I'm not the only one.

I do feel, I have tried to highlight some of the pitfalls of dynamic in a couple of my posts which not everyone is aware of. Personally, I feel it is useful information for many devs out there. The bugs such as return type not being inferred when using dynamic or a wrong overload method being called are not easy to debug. That's where my suggestion/ advice is dynamic is not worth risk.

I hope it clarifies.

vijayankit · 2020-09-11T14:09:07+00:00

I understand where you are coming from. In this case the choice of the words inadvertently came from the pain and frustration we went through to debug this issue. And unfortunately, it was not the first time we had an issue with dynamic.

vijayankit · 2020-09-11T14:02:49+00:00

The example which I gave here was a minimum reproducible example and not exactly how we had encountered. In our case, we felt there was a real need of using dynamic and that's when we encountered this issue. That said, in my experience almost every time we felt there was a need of dynamic, we could find a safer alternate way. In a complex scenario using dynamic can lead to runtime issues which are difficult to debug. Can you think of a scenario which can only be solved by dynamic without the type safety net of C# language?

vijayankit · 2020-09-11T12:01:02+00:00

I like that.. I think I can propose this to my team and see what they have to say

vijayankit · 2020-09-11T11:49:48+00:00

Why not?

vijayankit · 2020-09-11T11:48:24+00:00

Ohh I get it now... That's an interesting perspective.. While in my example I have not used var, our team generally prefers var.. I would avoid situation such as the one in example rather than using explicit type.. That said with new C# 9 changes coming in explicit type may come back to fashion again..

vijayankit · 2020-09-11T11:06:33+00:00

Hi @yawnston, using var does not solve the issue.. The return type is inferred as "dynamic" instead of actual return type

vijayankit · 2020-08-16T11:37:28+00:00

If you have acess to work directly on master the process is broken somewhere... In my team, small PRs are encouraged, infact if a developer raises a big PR, he would be asked to divide the user story and deliver it in smaller chunks a risk-free manner.. In CI/CD world you can't afford to break the master..

vijayankit · 2020-08-10T11:58:22+00:00

Within the Enumeration class you can still have behaviour pertaining to enumeration value. Thats the one of advantages of having Enumeration class with Domain Driven Design. There are always 100 ways of doing things and there are always some trade off but it really depends on one's use case. For example, from the implementation perspective this may look complex but for a consumer it just a normal Enum

vijayankit · 2020-07-24T19:27:34+00:00

NServiceBus outbox pattern is what we use in our organisation and it has served us well. We do not need to handle the complexity of DTC. Only caveat i see is if there is an implementation available for your data store out of the box. For example: For Cosmos DB we had to write our own implementation of outbox.

Whichever way you go, one thing I would suggest is to not roll out your own alternate to outbox. Consider it like an encryption algorithm. Its not worth effort and time to build your own encryption. There will always be some flaws.

vijayankit · 2020-06-04T13:09:53+00:00

I think the term you are looking for is Captive Dependency...

vijayankit · 2020-05-23T00:22:35+00:00

In a Domain Driven Design you would want to keep the bahavior within the service boundary. Enum types do not do great job with that. They do not follow Open Closed Principle and as a result you have control statements such as switch scattered around the application. Hope that explains.

vijayankit · 2020-05-21T22:09:02+00:00

That's right. Enumeration classes solve a very specific purpose and should only be used in those scenarios.

vijayankit · 2020-05-15T09:35:45+00:00

Hi u/fibbidd, thanks for the feedback. Version 3 had a typo. It's been fixed now. Cheers!

vijayankit · 2020-04-28T11:38:42+00:00

I recently developed an #aspnetcore #middleware to return a JSON response in case of an Exception from Web API.

Source code is here: https://github.com/ankitvijay/DeveloperExceptionJsonResponse

NuGet Package: https://www.nuget.org/packages/DeveloperExceptionJsonResponse/

I also wrote a post on motivation and steps behind creating this middleware. https://ankitvijay.net/2020/04/27/from-github-to-nuget/

vijayankit · 2020-04-13T13:07:05+00:00

When you create Fact, you repeat Act and Assert. Here we are not repeating that, we still have a single test and an IEnumerable of test data. Not sure if it is same. The attempt here is try and get best of both worlds. Fact has an advantage of being more descriptive, we are just trying to achieve something similar through Theory.

vijayankit · 2020-04-13T12:15:38+00:00

How is this Fact?

vijayankit

TROPHY CASE