One of the first topics you will encounter when studying functional programming will probably be currying. For an imperative programmer not used to mathematical notations, chances are you will find the concept hard to grasp. Then let this be the day you will remember as the day you completely understood currying!
The time is right. Your work is done. The last letter of your Java code has been written. You let the IDE compile the code and a new running version of your app is ready to be released. You’ve done this a thousand times, there’s nothing new on the horizon. The question of what lies beneath, what happens under the hood, has never occurred to you. Until now!
Since beginning of time mankind has been looking for a way to separate right from wrong. Where the primeval man judged righteousness by the contributions of the tribe, the current day programmer judges right by the wishes of the customer. For many years the average programmer wrote a bunch of logic to check if the boundaries defined by the client where uphold. As time went on and programming languages involved, metadata could be added to enrich functions, methods, classes and the like.
Of course for Java, these metadata are called annotations. Very soon they were used for a lot of things. Surpressing warnings, managing transactions, building XML/JSON structures and injecting dependencies. And, as you might have guessed by now, validating objects by a set of specific rules. One of the most commonly used frameworks would be the Jakarta Bean Validation framework. But what if I told you the provided annotations of that framework could be very easily expanded.
At the time of writing the coronavirus is raging the earth. Very soon after the outbreak, visualizations of both the virus and the effect of the disease started to appear everywhere. As I partially graduated in the subject of data visualization, I have always been interested in those graphs. Lately, I followed an introduction course to visualize data with D3.js. After I completed this course, I wanted to draw some meaningful graphics with this library. So follow along when I explain a little bit about D3 and then draw a simplified version of the coronavirus molecule.
As a developer, you are familiar with Docker. You push your images to the Hub, use Compose locally and know a thing or two about Kubernetes. Or… Well… To be honest… You don’t. And you are ashamed you don’t know anything about it. You browse the internet and it’s so overwhelming. So you stop looking and continue what you’ve been doing all the time. Deep inside, you still wonder. Can’t anyone not just explain Docker in simple terms? Is it really this hard? Or am I just missing something really obvious?
Adding code coverage to SonarQube is quite easy for any Maven project nowadays. Just add the jacoco-maven-plugin dependency to your pom.xml, add the prepare-agent execution task, and you are good to go. Even for multiple modules this works out of the box. But time goes on and your application grows as well. You start moving code to other modules, and somehow SonarQube no longer seems to pick up the covered code. What the heck is going on?
The answer is shamefully simple. You did not write proper unit tests, but component tests. JaCoCo assumes at default every module has its own set of tests. So, as soon as your test covers multiple modules, only the 'current' module is counted as covered code.
