Tagged: tips and tricks

0

10 tips for conducting code reviews

Code reviews are a common part of most development teams workflow these days and for good reason. Code reviews give us a process of keeping code quality high, sharing knowledge. catching mistakes and keeping a consistent code base. If you use git, you probably already heard about pull-requests, which basically is a merge request with a code review requirement. I help teams learn to conduct productive and positive code reviews, so the process becomes an enjoyable part of their development life-cycle. Here are my 10 tips for conducting a productive and positive code review, that gives value to both the reviewer and the author(s). 1. Figure out what the goal of the code review is Something that often happens in teams that are new to code reviews, is that the scope of the review is not set. So anything the reviewer finds “off” gets commented. And it often ends up in nitpicking that doesn’t give any real value, and might just seem as an attack on the author. Therefor, before ever starting to use code reviews, you should talk internally in your team about what you want out of the code review. My recommendation is: Architecture Does the added feature fit into the architecture? Is it consistent with the rest of the implementations of the system? Is the architecture of the feature fitting for the short term and long term goals of the product (be pragmatic, not everything needs to be perfect) Coding style There are as many coding styles as there are developers. But...

0

You don’t need a IDesignTimeDbContextFactory

If you have ever gotten the error message, that tells you to add IDesignTimeDbContextFactory to your project, when doing EF Core migrations. This particular one: Unable to create an object of type ‘MyContext’. Add an implementation of ‘IDesignTimeDbContextFactory’ to the project, or see https://go.microsoft.com/fwlink/?linkid=851728 for additional patterns supported at design time. You will probably be scratching your head, asking some questions and maybe even swear a little. Because the console will tell you to implemnt a IDesignTimeDbContextFactory so that is But don’t fret, you don’t need one. You can avoid it by having making sure of the following: The entire solution must be buildable and be able to run! If you have a project that cannot build, you can exclude it with the build configuration manager. Default constructor For the system to be able to build migrations from your context, it needs to be able to instantiate it with a default constructor! Implement the correct overloaded constructor! DbContextOptions<TContext> instead of DbContextOptions. ASP.NET Core If you are running an ASP.NET Core application, and you use the ServiceProvider (IoC) that is built in, then you must make sure that your DbContext and its’ dependencies are registered. You must also make sure that you are using the DbContextOptions<TContext> overloaded constructor and not the DbContextOptions overloaded constructor. When do I need a IDesignTimeDbContextFactory? When your DbContext exists in another project, like a shared library. Meaning that is has no context to run from. EF Core migrations works by actually running your code, if that is not possible, then you need to...

2

Hunting .NET memory leaks with Windbg

Recently a client called me about an issue where one of their production servers would run out of memory, every other week. The application in question was a .NET Framework 4.5 Windows service, that runs in an Azure VM, and ever so often it would become unstable and start causing trouble. I have previously helped this client set up an ELK stack, so it was quick for me to go into Kibana, look at metricbeat data, and see that their server indeed slowly was eating up memory over time. And every time the application was restarted, the memory would return to normal, and slowly creep upwards again. As you can clearly see, the application uses gradually more and more memory over time. Every time the line drops, was a restart of the server, where it went back to normal operation at about 150 MB. When they initially called me, they had just restarted the application, so I had no real practical way of finding out what caused the memory right there and then, but I logged on to the server and created a memory dump for the recently restarted application, so I would have a baseline for how it looks during normal operation. Creating a memory dump file The best way to figure out what is causing a memory leak, is to analyse the memory of the running application. To do that, we need to make a “memory dump”, and thankfully on Windows this is straight forward. Open Task Manager. Go to the Processes(older) or...

Software consultant 1

10 tips and tricks for solving software problems

As software consultants, we are often faced with bugs or problems the client cannot fix themselves. We are expected to quickly figure out the problem, and propose or implement a solution. Through my career I have developed a sort of mindset to get to the bottom of issues without wasting time hunting deadends or non-issues, and deliver results and value more efficiently. Here is my list of 10 tips for how I go about solving software problems 1. Focus A common problem I saw in myself, and I see very often in software developers, is a lack of focus. If you are trying to solve too many issues at once, you will probably fail at all of them. The first thing you must do, is figure out what you are actually trying to solve, and then stay on target. Usually my clients, have some sort description of what should be happening, and what isn’t happening. The description of the issues are often vague, but can be boiled down to tangible issues. As developers, we have a tendency to hunt any bug we find. If for example you are dealing with communication issues between two services, it might not be relevant to your current task, to start debugging the datalayer or refactoring a calculation algorithm. A side effect to lack of focus, is that your git history becomes unclear and kind of a mess. All of a sudden you have two or more half-done fixes staged, which means that either you can’t commit the first fix,...