In my previous post, I explored how to create a minimalistic ReSharper plugin. After I published it, one of my colleagues inquired if it is possible to use this or any other plugin from ReSharper Gallery with inspectcode.exe from ReSharper Command Line Tools (RCLT). I didn’t know and decided to try it out. Here is what I learned.
Prerequisites: VS2017 and ReSharper 2018.1.0
When I started to work on a compiled ReSharper extension aka plugin, I quickly realized how hard it is to set up an initial infrastructure. Reasons:
- Official DevGuide is great, but it is often a step behind.
- Existing plugins on GitHub contain too much stuff in them, and it is hard to extract relevant pieces, especially when you are new to it.
- Lack of my own experience in building NuGet packages.
This post does not pretend to be an ultimate guide. On the contrary, it contains 20% of the knowledge you need to get started, and the remained 80% are links to useful information.
When the plugin is installed into a Visual Studio, it checks if a class name contains ‘Foo’ and displays a warning:
This is a work of fiction. Any resemblance to existing software companies is entirely coincidental.
Johnny is a programmer. He likes to solve difficult problems: eliminating race conditions, improving performance, and fixing issues everyone else gave up on. In this way, he expresses loyalty to his company. Colleagues respect Johnny, as does his boss, Jessica. That makes Johnny a happy programmer.
One day, Jessica calls him into her office. Continue reading
Prerequisites: Basic knowledge of C# and Entity Framework is desired.
When I was working on Test Analytics Solution, I did not expect to use any stored procedures for the project. However, as the database grew, the ORM framework became inefficient for some of the use-cases, relying on joining and aggregating data from many tables. No matter what I tried, SQL profiler showed extremely slow, dynamic SQL statements, bloated as Trump’s ego. The performance was a victim of generalization.
From the other side, a stored procedure (SP) completed the job perfectly. It took fractions of seconds instead of minutes. Obviously, I had to go forward using the stored procedure. It meant leaving a critical part of the business logic in a SQL world, poorly testable and exposed to regressions. It was one of those moments, as I explored in my previous post, that I struggled to apply TDD practices.
Whether you think you can, or you think you can’t–you’re right. Henry Ford
In this blog post, I would like to share my experience of transition from the TDD-sceptic to the TDD supporter. It is not about convincing you to use TDD. There is no chance I’ll do it better than Uncle Bob. Instead, it is about transition itself. It could be very unpleasant, and I believe it when the most of the people give up. My transition was not an exception. It was long, painful, and full of ‘burn it all in hell!’ moments.