Analyzing gradle projects using SonarQube without gradle plugin

SonarQube makes static code analysis easy for a plethora of languages and environments. In many of our newer projects we use gradle as our buildsystem and jenkins as our continuous integration server. Integrating sonarqube in such a setup can be done in a couple of ways, the most straightforward being

  • Integrating SonarQube into your gradle build and invoke the gradle script in jenkins
  • Letting jenkins invoke the gradle build and execute the SonarQube scanner

I chose the latter one because I did not want to add further dependencies to the build process.

Configuration of the SonarQube scanner

The SonarQube scanner must be configured by property file called by default:

# must be unique in a given SonarQube instance
# this is the name and version displayed in the SonarQube UI. Was mandatory prior to SonarQube 6.1.
sonar.projectName=My cool project



# Encoding of the source code. Default is default system encoding

After we have done that we can submit our project to the SonarQube scanner using the jenkins SonarQube plugin and its “Execute SonarQube Scanner” build step.

Optional: Adding code coverage to our build

Even our gradle-based projects aim to be self-contained. That means we usually do not use repositories like mavenCentral for our dependencies but store them all in a lib directory along the project. If we want to add code coverage to such a project we need to add jacoco in the version corresponding to the jacoco-gradle-plugin to our libs in build.gradle:

allprojects {
    apply plugin: 'java'
    apply plugin: 'jacoco'
    sourceCompatibility = 1.8

    jacocoTestReport {
        reports {
            xml.enabled true
        jacocoClasspath = files('../lib/org.jacoco.core-0.7.9.jar',


Our jenkins build job consists of 2 steps:

  1. Execute gradle
  2. Submit project to SonarQube’s scanner

By default gradle stops execution on failure. That means later tasks like jacocoTestReport are not executed if a test fails. We need to invoke gradle with the --continue switch to always run all of our tasks.


Some tricks for working with SVG in JavaScript

Scalable vector graphics (SVG) is a part of the document object model (DOM) and thus can be modified just like any other DOM node from JavaScript. But SVG has some pitfalls like having its own coordinate system and different style attributes which can be a headache. What follows is a non comprehensive list of hints and tricks which I found helpful while working with SVG.

Coordinate system

From screen coordinates to SVG

function screenToSVG(svg, x, y) { // svg is the svg DOM node
  var pt = svg.createSVGPoint();
  pt.x = x;
  pt.y = y;
  var cursorPt = pt.matrixTransform(svg.getScreenCTM().inverse());
  return {x: Math.floor(cursorPt.x), y: Math.floor(cursorPt.y)}

From SVG coordinates to screen

function svgToScreen(element) {
  var rect = element.getBoundingClientRect();
  return {x: rect.left, y:, width: rect.width, height: rect.height};

Zooming and panning

Getting the view box

function viewBox(svg) {
    var box = svg.getAttribute('viewBox');
    return {x: parseInt(box.split(' ')[0], 10), y: parseInt(box.split(' ')[1], 10), width: parseInt(box.split(' ')[2], 10), height: parseInt(box.split(' ')[3], 10)};

Zooming using the view box

function zoom(svg, initialBox, factor) {
  svg.setAttribute('viewBox', initialBox.x + ' ' + initialBox.y + ' ' + initialBox.width / factor + ' ' + initialBox.height / factor);

function zoomFactor(svg) {
  var height = parseInt(svg.getAttribute('height').substring(0, svg.getAttribute('height').length - 2), 10);
  return 1.0 * viewBox(svg).height / height;

Panning (with zoom factor support)

function pan(svg, panX, panY) {
  var pos = viewBox(svg);
  var factor = zoomFactor(svg);
  svg.setAttribute('viewBox', (pos.x - factor * panX) + ' ' + (pos.y - factor * panY) + ' ' + pos.width + ' ' + pos.height);


Embedding HTML

function svgEmbedHTML(width, height, html) {
    var svg = document.createElementNS("", "foreignObject");
    svg.setAttribute('width', '' + width);
    svg.setAttribute('height', '' + height);
    var body = document.createElementNS('', 'body'); = 'none';
    return svg;

Making an invisible rectangular click/touch area

function addTouchBackground(svgRoot) {
    var rect = svgRect(0, 0, '100%', '100%'); = 0.01;

Using groups as layers

This one needs an explanation. The render order of the svg children depends on the order in the DOM: the last one in the DOM is rendered last and thus shows above all others. If you want to have certain elements below or above others I found it helpful to use groups in svg and add to them.

function svgGroup(id) {
    var group = document.createElementNS('', 'g');
    if (id) {
        group.setAttribute('id', id);
    return group;

// and later on:

Recap of the Schneide Dev Brunch 2018-02-11

brunch64-borderedOn Sunday, February 11th, we held another Schneide Dev Brunch, a regular brunch on the second sunday of every other (even) month, only that all attendees want to talk about software development and various other topics. This brunch was well-attended, with two new guests that seemed to feel comfortable after just a few minutes. The table provided just enough space for us. As usual, the main theme was that if you bring a software-related topic along with your food, everyone has something to share. Because we were a larger group, we discussed with an agenda. As usual, a lot of topics and chatter were exchanged. This recapitulation tries to highlight the main topics of the brunch, but cannot reiterate everything that was spoken. If you were there, you probably find this list inconclusive:


Our first topic was a presentation of the asciidoc syntax and the asciidoctor converter. The asciidoc syntax can be used to describe structured textual content in a concise manner with a few funny special characters. It looks like markdown at the first glance, but has the benefit of being fully standardized and extensible instead of one of several competing dialects.

The asciidoctor is an active rewrite of the first asciidoc converter. Given the right set of formatters, you can generate a PDF, a self-contained interactive HTML presentation and a static web page from one single source. This follows the “one true source, many derived artifacts”-approach that every software developer should know by heart (Don’t Repeat Yourself!).

Because setting up a productive asciidoctor environment is still some manual work, one of our attendees has published a github repository that automates the manual work as much as possible: asciidoc presentation.

If you need an alternative to markdown or even TeX/LaTeX, have a look at asciidoc. It seems specifically aimed at software developers and is probably already integrated in your favorite IDE (the integration in IntelliJ is seamless).


We discussed the two extreme approaches to handle dependencies for your project. The first extreme is to only include links to other projects/repositories that need to be fetched manually or automatically. Most modern build tools orientate towards this approach, even if there are some disadvantages like the recent Go/Github disturbance.

The second extreme is to include everything that’s needed in your repository. For a Javascript project that means that you provide your own, probably out-dated version of leftpad and thousand other libraries. You need a way to deal with transitive dependencies and keep an eye on all the versions to mitigate the risk of long-fixed vulnerabilities.

The second extreme is extremely helpful if you don’t have internet access but want to develop.

A good compromise is the local offline mirror, something that build tools/dependency managers like maven have for over a decade. This local repository is filled with all the leftpads and apache-commons that your projects need. If you checkout a new project, remember to make the build tool download the dependencies to your local repository before you go offline.

for Javascript, this concept seems a bit foreign. Who would develop for the web without the web, anyways? Yarn seems to provide a working offline mirror functionality for npm packages, though. Perhaps it is worth a look.

Opt-Out explained with groceries

During out dependency management discussion, we also compared downloadable installers with malware droppers. But that’s not where our comparisons stopped. We also came up with a good metaphor for Opt-In vs. Opt-Out methods.

If you enter a grocery store and grab a shopping cart, only to find that it already contains two or three packages of sweets and some overpriced milk, you chose an Opt-Out store. Your responsibility is to return the goods to their aisle or to buy them.

You’re probably used to Opt-In type grocery stores.

Book review: Functional Programming in Java

We took a look at Pierre-Yves Saumont’s book “Functional Programming in Java”. This book is a little bit odd in that you shouldn’t read it, you are meant to program it. Or at least try to solve the numerous training exercises and riddles. This makes it hard to read the paper version of the book, because it’s a pick-two situation of keyboard, mouse and book on your desk.

The book explains real functional programming and not the functional additions of Java 8. It explains it on top of the JVM, using Java’s language constructs. But, you will learn it from the origins and develop abstractions like Function oder Supplier yourself. Imagine you had all compiler magic of Java 8 but no JDK classes to leverage it – this book tells you how to use it.

It’s a good book, but unique in its style. It grounds on exercises and your own understanding of the material. It isn’t spoon-fed, you have to work for it yourself. It didn’t chose any existing pure functional language, but plain Java for this. So you have no excuse about weird syntax or unfamiliar ecosystems. It’s boring old Java turned in an exciting new way.

And if you are lazy and don’t feel like writing your own functional groundwork toolkit, you might want to look at vavr, a functional programming library for Java.

Polyglot language idioms

We discussed the portability of language idioms and highlighted the Curiously Recurring Template Pattern (CRTP) from C++. Then we spent some time explaining and understanding the CRTP and finally comparing it to similar things like Java’s Enum<E extends Enum<E>>. It can get wicked complex fast with those constructs.

Laser printer identification

Since 2011, we know that every single page of a color laser printer can be individually identified and traced back to your printer. This is common knowledge as stated on Wikipedia, but it still was a surprise to some of us. Why do we need such tracking? On request of many goverments.

Spectre and Meltdown

We didn’t repeat the fresh common knowledge about the nearly universal CPU security vulnaribilities Meltdown and Spectre. But we noted that it got eerily quiet, as if everybody holds their breath and waits for the morning clock to wake them up.

Some rumors has it that the current prototypes of ARM and Intel CPUs are not vulnerable, as if the manufacturers changed their speculative code execution unit long before the exploits came to light. Maybe they circumvented the problem by pure luck?

We hope to hit snooze soon.

Planned obsolescence

We discussed the notion of planned obsolescence. Typical consumer products have a flaw or weakness that is bound to break soon after manufacturer guarantee is void. Or it is deliberately incorporated into the product like page counters, waste tanks with limited capacity or the infamous short-lived light bulb.

A good start on the topic is the documentary “buy it for the waste” or “Kaufen für die Müllhalde” on german.

Given the recent noise around Apple battery life, we are now in an era where planned obsolescence is sold like a feature. Twenty-five years ago, this was Science Fiction. The author of this blog entry remembers a science fiction story by Robert Sheckley (“Utopia mit kleinen Fehlern” or “A Ticket to Tranai” in english). The protagonist reaches a planet that seems to be perfect. It is so perfect that nothing breaks anymore. The industry is desperate and sees the protagonist as a genius when he invents “planned obsolescence” and “designed discomfort” as means to raise sales. The planet has several other flaws as well. The story and the whole book is worthwhile and right on topic.

Book review (again): Clean Architecture

At last, we spoke about Robert C. Martin’s (Uncle Bob’s) new book “Clean Architecture”. I’ve already published my book review on our blog, but added some impressions and context after thinking about the book for some more time. Summary: The book is good, even if nearly half the pages might qualify as filler material and there are only two main messages. If the announcement of Uncle Bob on the last page in the Appendix becomes true, you might want to skip his next book, though.

Another book review for the future might be the new Effective Java, 3rd edition.


As usual, the Dev Brunch contained a lot more chatter and talk than listed here. The number of attendees makes for an unique experience every time. We are looking forward to the next Dev Brunch at the Softwareschneiderei in April. We even have some topics still on the agenda (like a report about first-hand experiences with the programming language Rust). And as always, we are open for guests and future regulars. Just drop us a notice and we’ll invite you over next time.


Oversimplified C++ Project FAQ 2018

If you are starting a new C++ project, you’re faced with a few difficult decisions. C++ is not a ‘batteries-included’ language, so you need to pick a few technologies before you can start.
Yet worse, the answer to most of the pressing questions is often ‘it depends’ and changing one of the choices mid-project can be very expensive.
Therefore, I have compiled this list to give totally biased and oversimplified to the most important questions. If you want more nuanced answers, feel free to do your own research.
This is meant to be a somewhat amusing starting point.


1. Which OS should I pick?



Usually, not a choice you can make yourself – but if you do: dependency management is easier with a package manager, and it seems to be the most dominant OS in the C++ community. Hence you will get the best support and easiest access to technologies.

2. Which build system should I use?



This is what everyone else is using, and those that are not are a real pain. For better or worse, the market is locked in. With target based properties in modern CMake, it’s not even that bad.

3. Which IDE should I choose?

Visual Studio 2017 on Windows, CLion everywhere else.


CLion is getting more robust and feature rich with every release. Native CMake support and really cool refactoring capabilities finally make this a valid contender to Visual Studio’s crown. However, the VS debugger is still the best in the game, so VS still comes out on top on Windows – tho not by a huge margin.

4. Which Language version should you use?



C++17 is not quite there yet with library, tool and platform support. Also, people do not really know how to use it well yet. C++14 builds on the now well-established C++11, which a few rather important “fixes” – and support is ubiquitous.

5. Which GUI toolkit should you use?



No other toolkit comes close in maturity. Qt’s signal/slot system almost seamlessly integrates with C++11 lambdas, making the precompile step needed for SLOTs a non-issue. Barring the license costs for closed-source projects, there is really no reason not to use it.

6. Should you use Boost?



Boost is a huge and clunky dependency that will explode your build times as soon as you even touch it. And it’s ‘viral’ enough that you can distinguish a Boost project from a non-Boost project. Boost.Optional, Boost.Variant and Boost.Filesystem prepare you for a smooth transition to C++17, but there are other more lightweight alternatives available.

Closing thoughts

There you have my totally biased opinion but hopefully entertaining. YMWV, but I think this is a good starting point if you don’t want to exeriment too much.


OPC-UA Performance and Bulk Reads

In a previous post on OPC on this blog I introduced some basics of OPC. Now we’ll take look at some performance characteristics of OPC-UA. Performance depends both on the used OPC server and the client, of course. But there are general tips to improve performance.

  • to get maximum performance use OPC without security

OPC message signing and encryption adds overhead. Turn off security for maximum performance if your use case allows to use OPC without security.

  • bulk reads increase performance

Bulk reads

A bulk read call reads multiple variables at once, which reduces communication overhead between client and server.

Here’s a code example using Eclipse Milo, an open-source OPC-UA stack implementation for the Java VM.

final String endpointUrl = "opc.tcp://localhost:53530/OPCUA/SimulationServer";
final EndpointDescription[] endpoints = UaTcpStackClient.getEndpoints(endpointUrl).get();
final OpcUaClientConfigBuilder config = new OpcUaClientConfigBuilder();

final OpcUaClient client = new OpcUaClient(;

final List<NodeId> nodeIds = IntStream.rangeClosed(1, 50).mapToObj(i -> new NodeId(5, "Counter" + i)).collect(Collectors.toList());
final List<ReadValueId> readValueIds = -> new ReadValueId(nodeId, AttributeId.Value.uid(), null, null)).collect(Collectors.toList());

// Bulk read call
final ReadResponse response =, TimestampsToReturn.Both, readValueIds).get();
final DataValue[] results = response.getResults();
if (null != results) {
	final List<Integer> values = -> (Integer) result.getValue().getValue()).collect(Collectors.toList());


The code performs a bulk read call on 50 integer variables (“Counter1” to “Counter50”). For performance tests you can put the bulk read call in a loop and measure the times. You should, however, connect to the server over the target network, not on localhost.

With a free (however not open-source) OPC UA simulation server by Prosys and Eclipse Milo for the client I measured times around 3.3 ms per bulk read of these 50 integer variables. I got similar results with the UA.NET stack by the OPC Foundation. Of course, you should do your own measurements with your target setup.

Keep also in mind that the preferred way to use OPC UA is not to constantly poll the values of all the variables. OPC UA allows you to monitor variables for changes and to get notified in case of a change, which is a more event-driven approach.


Gradle projects as Debian packages

Gradle is a great tool for setting up and building your Java projects. If you want to deliver them for Ubuntu or other debian-based distributions you should consider building .deb packages. Because of the quite steep learning curve of debian packaging I want to show you a step-by-step guide to get you up to speed.


You have a project that can be built by gradle using gradle wrapper. In addition you have a debian-based system where you can install and use the packaging utilities used to create the package metadata and the final packages.

To prepare the debian system you have to install some packages:

sudo apt install dh-make debhelper javahelper

Generating packaging infrastructure

First we have to generate all the files necessary to build full fledged debian packages. Fortunately, there is a tool for that called dh_make. To correctly prefill the maintainer name and e-mail address we have to set 2 environment variables. Of course, you could change them later…

export DEBFULLNAME="John Doe"
export DEBEMAIL=""
cd $project_root
dh_make --native -p $project_name-$version

Choose “indep binary” (“i”) as type of package because Java is architecture indendepent. This will generate the debian directory containing all the files for creating .deb packages. You can safely ignore all of the files ending with .ex as they are examples features like manpage-generation, additional scripts pre- and post-installation and many other aspects.

We will concentrate on only two files that will allow us to build a nice basic package of our software:

  1. control
  2. rules

Adding metadata for our Java project

In the control file fill all the properties if relevant for your project. They will help your users understand what the package contains and whom to contact in case of problems. You should add the JRE to depends, e.g.:

Depends: openjdk-8-jre, ${misc:Depends}

If you have other dependencies that can be resolved by packages of the distribution add them there, too.

Define the rules for building our Java project

The most important file is the rules makefile which defines how our project is built and what the resulting package contents consist of. For this to work with gradle we use the javahelper dh_make extension and override some targets to tune the results. Key in all this is that the directory debian/$project_name/ contains a directory structure with all our files we want to install on the target machine. In our example we will put everything into the directory /opt/my_project.

#!/usr/bin/make -f
# -*- makefile -*-

# Uncomment this to turn on verbose mode.
#export DH_VERBOSE=1

	dh $@ --with javahelper # use the javahelper extension

	export GRADLE_USER_HOME="`pwd`/gradle"; \
	export GRADLE_OPTS="-Dorg.gradle.daemon=false -Xmx512m"; \
	./gradlew assemble; \
	./gradlew test

# here we can install additional files like an upstart configuration
	export UPSTART_TARGET_DIR=debian/my_project/etc/init/; \
	mkdir -p $${UPSTART_TARGET_DIR}; \
	install -m 644 debian/my_project.conf $${UPSTART_TARGET_DIR};

# additional install target of javahelper
	LIB_DIR="debian/my_project/opt/my_project/lib"; \
	mkdir -p $${LIB_DIR}; \
	install lib/*.jar $${LIB_DIR}; \
	install build/libs/*.jar $${LIB_DIR};
	BIN_DIR="debian/my_project/opt/my_project/bin"; \
	mkdir -p $${BIN_DIR}; \
	install build/scripts/ $${BIN_DIR}; \

Most of the above should be self-explanatory. Here some things that cost me some time and I found noteworthy:

  • Newer Gradle version use a lot memory and try to start a daemon which does not help you on your build slaves (if using a continous integration system)
  • The rules file is in GNU make syntax and executes each command separately. So you have to make sure everything is on “one line” if you want to access environment variables for example. This is achieved by \ as continuation character.
  • You have to escape the $ to use shell variables.


Debian packaging can be daunting at first but using and understanding the tools you can build new packages of your projects in a few minutes. I hope this guide helps you to find a starting point for your gradle-based projects.


For your last project ask yourself: What did the stakeholders learn

At the start of a new project we like to begin with a naive mind, a beginner’s mind. In it we try to avoid our assumptions and start with a blank slate. Our clients do not. They are expert in their respective domain and know a lot. It’s naturally that during the project we learn lot about them and their domain, their work and their daily struggles. We see how they work around the limitations of their tools and cope with software written more than 30 years ago.
But besides us learning something about the domain, the stakeholders learn something about their domain, too. Because to develop the domain, the use cases and the daily work, we have to know details and reasons. Why is this step before that? Is it optional? Are these all the formats which are allowed? How long is the text usually? Why is there an exception to the rule? How often does it happen?
Usually we ask questions which cover the most traveled path, the happy trail. But in order to understand we need to get to the edges as well. The dark edges. Sometimes the number of objects we deal with is so big, nobody has all the answers. Our work, even before we write the software, enables collaboration. People and different departments have to work together. We work with all of them. Our software helps them to reach their common goals. But before that we need to know. And in order to tell us that the stakeholders need to dig deeper in their respective domain. Sometimes we need to look at the history in their domain, their work history, the decisions other stakeholders made in the past. It’s like archeology without the shovels, well, most of the time :).
Luckily the people we work with enjoy getting to know more about their work. They are astonished what depth the details have. How much different types of things, where gaps are. It is not always easy to light up areas that were kept in the dark so long. That were done just the way they were done. No we come and ask sometimes uneasy questions. We need to know. We need to know exactly. We need to know deeply.
This curiosity is not for its own sake. Our clients can confirm that the new software is so much better than the old. Not technical, but most importantly more adapted to their daily work.

That’s what’s important.