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.

Datenschutz ist Freiheit

Aus gegebene Anlass (Heise Online), weil demnächst der deutsche Saat alle Passwörter abfangen darf und damit nicht nur die Kommunikation aller Bürger mitlesen kann sondern auch gezielt falsche Informationen verbreiten kann hier ein Hinweis auf die Electronic Frontier Foundation, kurz EFF. Die EFF hat eine Seite zum Thema Survillance Self-Defence mit kurzen Anleitung zu sicheren Benutzung von Diensten übers Internet.

Unnützes Wissen:
Die EFF, bzw. ein EFF Aufkleber ist in der brillanten britischen Serie The IT Crowd zu sehen.

Git house keeping

Über die Entwicklungszeit eines Projektes sammeln sich im Git viele Feature Branches, die man oft vergisst wegzuräumen. So geht es:

Löschen von lokalen Branches:

1. git checkout master
2. git branch -l | grep --color=never -v master | xargs git branch -D

Löschen von remote Branches:

1. git branch -r | grep --color=never -v master | xargs git push origin --delete

Kurz und Gut: Software Metriken

Metriken helfen den Zustand von laufender Software zu überwachen (Monitoring) und Fehler frühzeitig zu erkennen. Das passiert dann mittels Alerts, die meist auf Metriken aufsetzen. Man kann in der Regel drei grundsätzlichen Arten von Metriken unterscheiden:

1. Counter
2. Meter bzw. Histogramm
3. Gauge

Aber wo ist der der Unterschied zwischen den Metrik Typen? 

Hier ein Real Word Beispiel:

Ein Gauge gibt an wie hoch der Wasserstand in deiner Badewanne ist.

Ein Counter dagegen gibt an, wie oft jemand mit einem Eimer Wasser die Badewanne befüllt.

Hier jetzt das Software Beispiel:

Ein Gauge gibt an wie viele Einträge in deiner Datenbank sind.

Ein Counter gibt an wie viele Elemente hinzugefügt wurden.

• Gauges:
• Benutzter Speicherplatz (RAM, Heap, Disk, ...)
• CPU Usage
• Anzahl von Einträgen in einer Datenbanktabelle
• Load
• Counter:
• Requests
• Laufzeit
• Fehler
• Transaktionen
• Logzeilen 

Kurz gesagt:

Ein Gauge zeigt einen Zustand an, ein Counter zählt Events.

Ich empfehle die Benutzung von Countern und Gauges.

Warum ich den dritten Metriktyp Meter und Histogramm nicht empfehle.

Meter neigen dazu zu lügen, oft werden die zusätzlichen Informationen nicht gebraucht und sie erhöhen den Aufwand. 

Das Hauptproblem ist aber das die oft wenigen Daten die in einem Metrikpunkt akkumuliert werden. Sie erzeugen bei den verwendeten Aggregationen wie in Histogramm und Meter ein falsches Bild von den Daten. Ein ist Quantilberechnung über 5 Werte ist 95% Sinn frei.

Zusammenfassung 

1. KISS: Keep it simple an stupid - eine Metrik ist nur ein Float Wert und ein Name. So sollte auch der Code aussehen.
2. Benutzt Counter und Gauge, je nach Anwendungskontext.
3. Vermeidet die Metrik-Typen  Meter und Histogramm, es sei denn ihr wisst genau was ihr tut.
4. Metriken helfen den Zustand von laufender Software zu überwachen und Fehler frühzeitig zu erkennen.
5. Metriken ersetzen kein Logging.
6. Metriken sind nicht mit Observability zu verwechseln.

Einfache Bewegungserkennung auf dem Raspberry Pi

Mit dem Thema Bewegungserkennung wird gerne KI in Verbindung gebracht, aber Bewegungserkennung geht auch mit normalen Computer Vision Mitteln.

Es ist sehr einfach möglich, Bewegungserkennung mit einfachen UNIX Programmen durchzuführen. Ich benutze hier ImageMagic. Folgend ein Beispiel, das auf einem Raspberry Pi Zero W läuft. Hier ein Auszug aus dem BASH Script:

raspistill -o                      camImages/$DATE.jpg

convert    -normalize -blur 0x8    camImages/$DATE.jpg blur/$DATE.jpg

compare    -fuzz 8%   -metric RMSE nb3.jpg nb4.jpg x.jpg

1. Zuerst muss ein Bild aufgenommen werden.
2. Dann wir das Bild bzgl. des Histogramms normalisiert und mit dem Weichzeichen wird das Bildrauschen des Kamerasensors eliminiert.
3. Zuletzt wird das aktuelle Bild mit dem Vorgängerbild verglichen. Die Metrik gibt an, wie stark sich die Bilder unterscheiden, hier muss ein passender Schwellwert (-fuzz 8%) eingestellt werden.

Mit dieser Lösung werden Bewegungen in Bildern zuverlässig erkannt. Hier ein Beispiel für ein Differenzbild.

Die Nachteile:

1. Dieser Lösung ist die hohe Laufzeit von ca. 75 sec auf Raspberry Zero W. 
2. Die Normalisierung ist noch nicht optimal, Änderungen in der Beleuchtung werden häufig als Bewegung erkannt, das kann zur Zeit nur durch ein Anhaben des Schwellwertes kompensiert werden.

Update:

Einige Optimierungen wie die Verringerung der Bildauflösung führen zur einer Reduktion der Laufzeit von 90 sec auf 75 sec auf 23 sec. Durch die jetzt kürzeren Abstände zwischen den Bildern werden Fehlerkennungen noch weiter reduziert.

Programmiersprachen die ich gelernt oder benutzt habe

Programmiersprachen die ich gelernt oder benutzt habe:

1. Assembler
2. BASIC
3. BASH
4. C
5. Go
   
6. Groovy
7. JavaScript
8. Java
9. Lingo
10. MS-DOS Scripting
11. Objevtive-C
12. Pascal
13. Pearl
14. Python
15. R
16. Ruby
17. SAS
18. Scala
19. SPS

Programmiersprachen die ich extrem gut beherrsche:

1. Java
2. BASH
3. R

Programmiersprachen die gerne probieren würde:

1. GO

Java, XML und Performance

XML ist ein populäres Datenformat für den Datenaustausch zwischen Systemen. Der Vorteil von XML ist, es gibt sehr stabile Parser. Aber wie sieht es mit der Performance aus? Folgende Aufgabe: Einlesen einer XML Datei mit 100T Elementen,  die einige Unterelemete besitzt, die Tiefe ist 4, Dateigrösse 60Mb, Java 8.

Zum Performancevergleich wurde mit einem Subset von 350 Elementen gearbeitet.

Test 1: Java, XML, DOM, Xpath, 350 Elemente in Datei

1. Laufzeit pro Element: 20ms
2. Verhältnis XML Parsen/DB Speichern: 25, das XML Verarbeiten verbraucht primär die Zeit
3. Geschätzte Gesamtlaufzeit: 33 min

Test 2: Java, XML, DOM,  Jaxen 1.2 Xpath, 350 Elemente in Datei

1. Laufzeit pro Element: 3ms
2. Verhältnis XML Parsen/DB Speichern: 15, das XML Verarbeiten verbraucht primär die Zeit
3. Geschätzte Gesamtlaufzeit: 5 min
4. Jaxen Xpath ist deutlich schneller als das normale Java Xpath

Beide Tests waren erfolgreich. Jetzt der Test mit voller Datenmenge.

Test 3: Java, XML, DOM,  Jaxen 1.2 Xpath, 100T Elemente in Datei

1. Manueller Abbruch des Test, weil die Laufzeit unglaublich schlecht war.

Test 3: Java, XML, DOM,  Xpath, 100T Elemente in Datei

1. Manueller Abbruch des Test, weil die Laufzeit unglaublich schlecht war.
2. Performance ist aber besser als Jaxen.
3. Bei einer Detailanalyse sieht man das die Laufzeit für die XPath Evaluierung nach oben schnellen, das obwohl ausreichen RAM (XMX) vorhanden ist. Der Schluss daraus ist, das die Auswertung von XPath ausdrücken eine hohe Komplexität hat, es werden scheinbar Listen durchlaufen. Übertragen auf relationale DBs, XPath Evaluierung entsprechen sequential Scans. Java XPath kann also nicht die Element-Adresse im Speicher berechnen, sondern muss sie suchen, indem (mehrere) Listen sequentiell durchlaufen werden.

Zusammenfassung

1. Die Verarbeitung grosser XML Dateien mittels DOM und XPath ist ineffizient. Das gilt wahrscheinlich auch für andere DOM basieret Formate wie JSON.
2. Jaxen XPath ist deutlich schneller als Java XML XPath für kleine und normale DOMs.
3. Lösungen: 
1. Alternativen wäre Streaming XML via SAX oder StAX.
2. Wechsel von XML zu CSV.