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.

Die nutzloseste Software: Terraform

Terraform ist eine Software mit der man Infrastruktur as Code definiert und dies unabhängig vom Cloud Anbieter. Soweit die Idee von Terraform.

Immer wenn ein Kollege mit einem neuen Tool, Lib, Programmiersprache um die Ecke kommt, die die endgültige Erlösung aller Softwareprobleme ist, dann frage ich: "Welches Problem löst es?"

Linus Torwalds sagt mal das Subversion das sinnloseste Softwareprojekt sei (Link). Heute hat er Unrecht, das sinnloseste Softwareprojekt ist Terraform. Warum?

Terraform löst keine Probleme, Terraform ist selbst ein Problem. 

Punkt 1: Falsche Grundannahme

Die Grundannahme das nur Terraform selbst Cloud Ressourcen verändern kann, ist falsch. Das Terraform State-Handling erinnert an die Idee aus UML automatisch Code zu erzeugen und so Projekte als reines UML Konstrukt zu realisieren. Schon diese Idee scheiterte am Code Roundtrip und so scheitet Terraform an seinen eigenen States. Heute bauen wir Stateless Mikro Services und Terraform kommt mit einem komplexen State Modell daher. Wenn sich dieses State Modell von den Cloud Ressourcen unterscheidet ist Terraform und der Entwickler am Ende. Das Reparieren dieses inkonsistenten Zustandes ist kaum sinnvoll möglich. Terraform ist nicht robust. Vor allem bräuchte Terraform kein State Modell sondern nur die Referenz auf die Cloud Ressource selbst und könnte den State selbst ermitteln. Warum tun sie das nicht? Die Benutzung von Terraform schliesst alle anderen Cloud Tools und Consolen aus.

Punkt 2: Inkompatibilität

Instabile Terraform Versionen, inkompatible Konfigurationen und Plugins. Warum sind neue Terraform Versionen inkompatibel mit alten Plugins und Konfigurationen? Warum wurde nicht auf Kompatibilität geachtet? Warum wurden hier am laufenden Meter Breaking Changes implementiert?

Punkt 3: Nutzlos, kein Zusatznutzen vorhanden

Und zum Schluss, welchen Nutzen hat Terraform. Infrastruktur as Code als Code kann man bei der AWS sehr gut über die aws-cli oder andere AWS Libs realisieren. Bei Digital Ocean kann man das per Rest Calls. Jeder Cloud Anbieter hat entsprechende Schnittstellen. Diese Schnittstellen sind in der Regel hervorragend dokumentiert. Jetzt könnte man anführen, das Terraform eine Abstraktionsschicht über all diese verschiedenen Cloud Anbieter Schnittstellen legt. Das stimmt nur zum Teil weil die Terraform Features natürlich vom Provider und dem Provider Plugin abhängen. Also auch dieses Argument stimmt nicht. Dazu die Frage, wie oft wechselst du am Tag den Cloud Provider und zwischen wie vielen Cloud Providern wechselst du? Genau, Terraform löst ein Problem das gar nicht existiert! Zusätzlich verschwendet Terrafom Zeit durch seine eigenen Probleme, siehe Punkte 1 und 2. Terraform ist nutzlos und kontraproduktiv.

Noch eine kleine Anmerkung, auch vor der AWS wurde schon Infrastruktur als Code geschrieben und betrieben, damals mit BASH, SSH, SCP , DD und dem Paketmanager.