This is 50/50 a real post and a service announcement. The short version is that I’ve removed Google Analytics from this site (and redstar.be, my legacy project blog for non-technical people). I’m also using Brave and DuckDuckGo now. Read on for the long version. Google Chrome For some time, I have felt fairly (but not alarmingly) uneasy with the amount of data Google collects by me using Chrome. I’m somewhere in the middle of the whole privacy debate: between “don’t

This may not be new to you, but I recently discovered another cool feature of Git. Rebasing with the autosquash option allows me to keep a clean log with minimal effort. I’ve written about interactive rebasing before. This makes it even easier. Interactive Rebasing You want to do an interactive rebase when you have a series of commits that need be squashed together or when you want to change the order. Let’s say you have the following commits: But then

I recently saw a tweet on my Twitter-feed about failures and how we should also share our failures, not just our successes. Everyone experiences failure, but if we don’t share them, new developers will feel it’s not OK to make mistakes. So here are some of my mistakes and what I learned from them. This is the respective tweet: Be sure to read the rest of the thread. It’s a good and short read. Updating the Production Database Too Early

This post was written for the NCrunch blog. You can find the original here. Unit tests help developers write better code and provide a faster way of getting feedback compared to testing manually. But unit tests are also another piece of code that must be maintained and taken care of. Unit tests can become a mess just like production code can. Here are some tips on how to improve your tests and avoid such a situation. Keep Your Tests Small

This post was written for the NCrunch blog. You can find the original here. There are many ways of testing your application or library. The test pyramid provides a good starting point to the most common types of tests—unit tests, integration tests, end-to-end tests, and manual tests. But there are other types of tests, like contract tests, load tests, smoke tests, and what we’ll be looking at in this article—property-based tests. What’s the Idea? Property-based testing is where you test

Here I am again with a follow up post in my series on fixing a real world legacy application. I’ve been continuing my work with NDepend and wanted to give an update on what it has helped me do. Just a small reminder: the application is a web application to make forecasts about the World or European championship football/soccer. You can read more about it in my first post. Mutable Statics I had a large class containing all the teams

In my series of fixing a real-world legacy application, I’ve already improved the code in some big blocks: updated Bootstrap introduced dependency injection removed unnecessary cruft added logging But fixing legacy applications often means making many smaller improvements. Many of these are often a matter of personal opinion. And when multiple developers do agree on an issue, they might not agree on a particular solution. The best way to avoid these nonconstructive discussions, is to have a tool to automate

I’ve written multiple posts about legacy code and automated tests. I believed both are closely connected in that one can help solve the other. I also enjoy working on legacy code, improving software development practices and improving code quality. But this blog has always been geared towards developers, and it seems managers don’t always follow. Which is why I’ve started a new blog, aimed at managers dealing with legacy code. Over time, I’ve come to like improving the situation around

This application contains absolutely no logging. In many legacy enterprise application, there usually is some logging, but it’s often not very useful. In some cases, there is no logging at all. This makes it hard to troubleshoot when things go wrong. In .NET, the first logging frameworks that come to many developer’s minds is log4net or NLog. I’d recommend NLog over log4net because the documentation seems better to me. In my position as consultant, I often encounter custom logging frameworks.

Continuing my series on fixing my real-world legacy application, I will now introduce dependency injection. First, I simply installed the Autofac.Mvc5, Autofac.Mvc5.Owin and Autofac.WebApi2.Owin NuGet packages. This changes nothing of course. So next, we tell ASP.NET to let Autofac handle the creation of the controllers. In our Startup class, we add: This is basically what’s in the Autofac documentation. Notice how we need to set up Autofac for both MVC and WebAPI. This is because this application is using both. I’m using