Gitlab Badges for Maven Jacocoo Test Coverage

1. Integrate Jacoco into your Maven pom.xml.
2. Add into your file .gitlab-ci.yml: echo -n "Total:" ; cat target/site/jacoco/index.html | grep -o 'Total[^%]*%' | grep -o -E '[0-9]+%$
3. Add Badge in Gitlab under Setting.
4. Gitlab scan the console for the Regex you given in Point 3.

Vertikalisierung der Softwareentwicklung und Micro Services

Die Vertikalisierung der Softwareentwicklung ist ein erfolgreiche Modell für die Skalierung der Softwareentwicklung. Dabei betreut ein Entwicklerteam eine Kunden-Domäne und entwickelt die Software für diese Domäne autonom. Dies wird gerne durch das Share Nothing Prinzip umgesetzt. Das Entwicklerteam kann ohne Rücksicht auf andere Teams, also ohne Abstimmungsaufwand und Meeting-Marathons die Software für die Kunden-Domäne entwickeln. Dies spart Zeit und bring schnell gute Erfolge, es ist sehr effizient.

Vertikalisierung führt oft dazu, das das Team die Kunden-Domäne als einen Micro Service umsetzt. In der Praxis stösst dieses Vorgehen: eine Domäne, ein Team, ein Micro Service, recht schnell an seine Grenzen. Der Grund ist die Komplexität dieses fetten Micro Services, der verscheiden Aufgaben erfüllt. Oft kommt es zu komplexen Deployments, weil der fette Micro Service in verscheiden Funktionen deployed wird, z.B. zur Datenversorgung und Kunden-App. Aus meiner Erfahrung ist das Deployment und der Betrieb sehr komplex und führt zu zusätzlichen Fehlern. Ein Codebasis führt zu funktional unterschiedlichen Micro Services, die durch Konfiguration unterschieden werden. Diese funktional unterschiedlichen Micro Services sind nicht unabhängig von einander. Es kann zu fehlerhaften Konstellationen kommen, oft hilft nur eine gezieltes Überwachen des Betriebes diese Klasse von neuen Fehlern zu erkennen. D.h. wir haben eine neue Klasse von Runtime Fehlern, die schwerer zu erkennen sind und dazu noch sehr spä erkannt werden. Diese Fehler sind erst nach dem Deployment erkennbar. Dann ist der Service für den Kunden aber schon gestört. Oder aus einer anderen Perspektive, wenn wir die 12 Factors App Kriterien heranziehen, wäre dies ein Bruch mit dem Faktor 1!

Eine erfolgreiche Alternative ist es aus diesen fetten Micro Service in einzelne kleine, in sich geschlossene, Micro Services zu zerlegen. Zum Beispiel kann man die Datenversorgung von der Bearbeitung von Kundenrequest trennen. Oft wird als Gegenargument angeführt, das es gemeinsamen Code gäbe. In der Praxis hat sich gezeigt, das die Menge des gemeinsamen Codes sehr gering ist. Das Problem des gemeinsame Codes kann bei Bedarf über Bibliothek gelöst werden.

Zusammengefasst die Vorteile der Zerlegung von fetten Micro Services einer Vertikalen in schlanke Micros Services:

• Vereinfachung des Deployments
• Vereinfachte Konfigurationen
• Keine Fehler durch Fehlkonfigurationen, die Instanzen der Applikation sind unabhängig voneinander
• Höhere Robustheit, Fehler in einem Micro Service stört nicht die gesamte Applikation, so führt der Ausfall der Datenversorgung nicht dazu das der Kunde nicht mehr bedient wird
• Ein negativen Performance-Einflüsse durch Daten-Imports oder Wartungsjobs.
• Bessere Wartbarkeit, Codebasis beleibt schlank und übersichtlich

Vortrag bei der Java User Group Dublin - Fotos

Jetzt sind die wirklich guten Fotos von meinen Vorträgen, IoT mit Tinkerforge und Software Robustheit, bei der Java User Group Dublin da:
https://www.flickr.com/photos/139932355@N08/albums/72157674941628376

Danke an die beiden netten Hosts: Barry und Gerry und an die Firma Tinkerforge für die Unterstützung.

Dieser Briefkasten (Dublin, Temple Bar) stammt aus der Zeit als George König war. GR bedeutet George Royal und nicht wie es einem die Iren erzählen George Rules. Man beachte das der Briefkasten irisch Grün und nicht Englisch rot ist!

Run All Test on File Change

Eines der besten Instrumente um Code zu verbessern sind Test, speziell Unit Tests. Unit Test sind für alle erdenklichen Programmiersprachen verfügbar und wenn nicht, dann schreibt man sich den Test selbst, ohne Frame Work. Mit Hilfe der Unit Test können Fehler einfach aufgedeckt werden dazu muss man nicht nur die Test haben, sondern sie auch permanent ausführen. Dieses permanente Ausführen ist die Aufgabe des Continouse Integration Servers, z.B. Jenkins. Alternativ gibt es auch die Unit Integration in die IDE. Wem selbst der Jenkins oder die IDE zu langsam ist, schnelle Roundtripzeiten bedeuten effizientes Entwickeln, der kann sich mit Hilfe eines einfachen Scripts seine Test ausführen, wenn sich etwas am Quellcode der Software oder der Test geändert hat (File save).

Hier ein Beispiel für den Mac, dass Unit Test für R ausführt und den Entwickler per Notification auf Fehler bei der Testdurchführung hinweist. Zuerst muss per Homebrew fswatch installiert werden. Dann muss dieses Script ins Root Verzeichnis deines Projektes abgelegt werden. Dann muss es starten. Es läuft ohne Unterbrechung solange, bis man via CRTL + C abbricht. Alternativ kann man das Script für andere Umgebungen anpassen.

#!/usr/bin/env bash

runX=true

finish (){

    runX=false

}

trap finish SIGINT

runTests(){

    for SCRIPT in src/test/*

    do

        if [ -f $SCRIPT -a -x $SCRIPT ]

        then

            $SCRIPT

            if [[ $? -ne 0 ]] 

            then

                FAILEDTESTS=${FAILEDTESTS}"\n"$SCRIPT

            fi

        fi                                                      

    done

    if [ ${#FAILEDTESTS} -ge 1 ]

    then

        osascript -e 'display notification  "'"$FAILEDTESTS"'" with title "R Test failed"'

        FAILEDTESTS=""

    fi

}

while $runX; do

    fswatch src/main/*.R src/test/*.R | runTests 

done

The 2nd Most Important Task of a Software Developer

The most import task of a software developer is to write code. Well, this answer was pretty easy. Really, yes! But what is second most important skill. I ask my colleagues, first guy says, watching youtube - nice but wrong, 2nd guy: write good documentation - good shot but also wrong.
For me and I'm confident that I'm right, the second most important task of a software developer is to delete code. The first important task is to write code and the second important task is to delete code.
I don't mean delete bugy code, I mean delete working code. Why should you do this?

We have limited time and limited count of developer, this means, we have a more or less constant velocity developing code. If our code base grows, we spend time for maintenance code an we have less time for developing new features, an so on and so on util we reached standstill.

To avoid the standstill, we suggest following tasks to reduce the code size, it a little bit like the Simplify your Life Literature

1. remove dead code
2. refactor code to build simpler and shorter code
3. reimplement code in an effective way, change tools, ... 
4. delete working code if there is users don't require the function anymore

If somebody say's that we keep this function because, we may use them - then remove the code. The word may is the indicator to remove the code. If we delete to much code, don't worry. Most of the times it cheaper to rewrite a little peace of code instead of keeping all old code fragments.

Here some link illustrating the problems:

1. Linux Maintainer needed, because of heavy load and huge Code base http://www.golem.de/news/linuxcon-dem-linux-kernel-fehlen-maintainer-1510-116749.html
2. Linux is planning to remove EXT3 filesystem http://www.pro-linux.de/news/1/22532/ext3-dateisystemtreiber-soll-aus-linux-entfernt-werden.html

Robust Code: Security Counter and Endless Loop

Eines der typischen Probleme bei der Entwicklung von Code sind Endlos-Schleifen. Von Ausnahmen mal abgesehen sind Endlos-Schleifen in der Regel nicht erwünscht. Leider entstehen sie durch scheinbar einfachen Code, der scheinbar korrekt ist. Hier ein Beispiel, von der Initialisierung eines Objektes, das selbst ein externes Subsystem (ZAP) initialisiert und dem entsprechend darauf wartet:

private void waitForStart() {
    while(!this.isZapDaemonUp() ) {
  sleep(1000);
        }
}

Das Problem an dieser Schleife ist, dass wenn das Subsystem nicht startet, dann hängt das eigentliche Programm in einer Endlosschleife. Der Benutzer kann das nicht erkennen. Eine robuste Lösung besteht darin einen Sicherheit-Counter einzuführen, der nach er gewissen Menge an Versuchen den Code abbricht.

private void waitForStart() {
     def secCounterStartup = 0;
     while(!this.isZapDaemonUp() ) {
         secCounterStartup++;
         log.debug "waiting for ZAP"
         sleep(1000);
         if (secCounterStartup > 20){
                throw new Exception("Zap does't start up.");                                           
         }
  }
  sleep(2000)
}

Unit Test mit R, ganz einfach

Auch wenn R oft nicht als richtige Programmiersprache gilt, so gibt es auch in R die Möglichkeit Unit Test zu schreiben. Dafür stehen verschiedene Packages zur Verfügung:

• RUnit
• testthat

Hier ein minimales Einsteigerbeispiel mit testthat:

source("main/analyzeXltReport.R")

library(testthat)

test_that("Error Rates", {

  xltreport = loadXltXmlReport("test/testreport.xml")

  expect_that( getTranscationErrorCount(xltreport), equals(24) )

  expect_that( getAtionErrorCount(xltreport), equals(24) )

})

Zuerst wird die zu testende Datei geladen und dann das Testframework. Danach ruft man die Testmethode test_that auf mit einem guten Namen und dem eigentlichen Testcode.

Wenn man jetzt den Test ausführt liefert er beim Erfolg kein Ergebnis:

> source('~/git/lhotse-nfa/loadtest/analysis/test/analyzeXltReportTest.R')

> 

Bei Fehlern sieht es dann z.B. wie folgt aus:

> source('~/git/lhotse-nfa/loadtest/analysis/test/analyzeXltReportTest.R')

Fehler: Test failed: 'Error Rates'

Not expected: getTranscationErrorCount(xltreport) not equal to 20

Mean relative difference: 0.2.

Eine kleine Anmerkung, die Pfade in den R Scripten auch im Unit Test beziehen sich auf das aktuelle Directory!

Weitere Informationen zum Unit Testing mit R findet Ihr hier: 

• http://adv-r.had.co.nz/Testing.html
• http://www.johnmyleswhite.com/notebook/2010/08/17/unit-testing-in-r-the-bare-minimum/
• http://www.johndcook.com/blog/2013/06/12/example-of-unit-testing-r-code-with-testthat/

Anzahl der Java Klassen in einem Projekt zählen

Man sehr einfach mit der BASH die Anzahl der Klassen in einem Projekt zählen. Dazu baut man zuerst ein JAR Datei, z.b. mvn package.  Dann zählt man die die class Einträge in der JAR Datei: unzip -l target/scale-performance-check-1.22.jar | grep .class | wc -l
Es geht auch ein bisschen einfacher: find src/ -name "*.java" | wc -l
Hier werden aber nur die Java Dateien gezählt. Abweichungen entstehen z.B. durch innere Klassen.

Wenn man die LOC zählen möchte kann man dies mit: find src/ -name '*.java' | xargs wc -l
Hierbei werden leere Dateien und Kommentare mitgezählt.

Codeanalyse ganz einfach

Für die Code Analyse bzw. für die Analyse der Codequalität gibt es eine Reihe von Werkzeugen wie PMD, Findbugs, Emma, Sonar und und und. Die Werkzeuge sind mehr oder weniger einfach zu bedienen und lassen sich meist gut in bestehende Entwicklungsumgebungen wie Eclipse, Ant oder Maven integrieren. Aber es geht noch einfacher. Man kann Codeanalysen auch in der Kommandozeile machen. Hier ein paar Beispiele:

Beispiel 1: Finden von Null Rückgabewerten, ein typischer Codestinker
grep -e "return null"  projectXX/net/ffreax/**/*.java | wc -l

Beispiel 2: Finde die Dateien mit den meisten Zeilen, potentielle Gottklassen bzw. überladenen Klassen
wc -l projectXX/net/ffreax/**/*.java | sort -nr | head

Ab jetzt wird PMD hinzugenommen, duz muss PMD heruntergeladen (Link) werden.

Beispiel 3: Code Duplikate finden, hier für PHP
bin/run.sh cpd --files ~/Documents/ME_Code_Review/projectXX-Web/Classes/ --minimum-tokens 120 --language php | less

Beispiel 4: Gott Klassen finden

bin/run.sh pmd -d ~/Documents/ME_Code_Review/projectXX-Android/net/  -l java   -R rulesets/java/design.xml | grep GodClass

Beispiel 5: Alle Basic Probleme

bin/run.sh pmd -d ~/Documents/ME_Code_Review/projectXX-Android/net/  -l java -r design -f text -R rulesets/java/basic.xml | less