Our latest upgrade of SonarQube took far more time than expected. I did a few upgrades in the last two years, but none was such a challenge. Everything that can go wrong has gone wrong, and without my prior experience, I may have given up. Let me point out the obstacles you may encounter and give you a few tips to find the cause of these problems.
With every commit you do, Git not only registers the change in your code, but marks you as the author of this change as well. It uses the settings user.name and user.email to create an entry like this one in the log:
commit aeaeb9e927592e907ae1a7f5c381876e05109a80
Author: John Doe <john@doe.org>
Date: Mon Jun 10 20:11:11 2019 +0200
Your commit message
As long as you use Git only to manage your source code, this behaviour does not require any attention. You write your code, commit and push as you like, and everything works. However, if you intend to do any form of data mining on your Git repository, you need to look deeper on how authors of Git commits are tracked.
I seldom use the IIS logs and whenever I must use them, I have the same question: What file matches the site I am interested in? The answer to that question is easy to find, but it is not that obvious to remember it. Maybe this post does the trick for me.
This year I did not just attend NDC Oslo, I got the chance to contribute as a speaker to this great conference. That shift of perspective made me much more appreciative of the hard work that goes into a talk and how much it takes to stand in front of such a great and welcoming audience.
The five talks I selected for this post had an impact on me that went far beyond of being entertained for an hour. I spend a lot of time thinking about what I heard and I guess so will you. Those presentations may look as if they are at the wrong place for a tech conference, but trust me, they are as important as any technical talk. I am glad the organizers put them in. They challenge how we think, not only about the systems we use and build, but also about how we work with others and make our world a better place.
SonarQube gives us a good and honest overview on the quality of our code. It's most likely not as good as we hoped for and much work will be needed to get it to an acceptable level. But where do we start? And what can we do when we have many projects?
If you follow along with the last few posts on SonarQube, you will now have a working installation that continuously monitors the quality of your code. Today we link Visual Studio to SonarQube using SonarLint.
Running SonarQube manually is a sure way to not running it at all. Sometimes you forget it, other times you know that it's not going to give an "adequate" report and so you better wait a bit with the next run – the only problem is that this next run never happens. If you want to take SonarQube seriously, you must integrate it into your build. This post shows you how you can use SonarQube with your Visual Studio Team Services (short VSTS) builds.
Our first steps with SonarQube could be done without much thought on security, reliability and how we can protect it. If you want to use SonarQube beyond your pet projects, you should start making some changes to your installation.
There are a few rules in SonarQube I find a bit special. I understand their reasoning but believe that the resulting errors aren’t correct or helpful. Should you reach the same conclusion you can follow along to create your own custom set of rules.
Lines of Code (short LOC) are an often used metric to compare projects by their size. All you need to do is to count the lines of source code to figure out if project A is bigger than project B. However, that is only true when they use the same programming language. Only then can you do the same work in a line of code. If you compare Ruby with C or Assembler your LOC metric may differ by many orders of magnitude to get the same things done.