Java Streams

Ich habe mich lange gedrückt um einen Artikel über Java Streams zu schreiben, jetzt nach Jahren ist es so weit. 

Als ich das erste Mal Java Streams sah, ich glaube es war in einem Meetup, kamen mir zwei Gedanken:

1. Wow, cool
2. Welches Problem wird durch Java Streams gelöst.#
3. Parallelisierung für lau

In den nächsten Jahren sickerten die Streams so in die allgemeine Java Programmierung. Streams waren ja nicht Neues, ich habe Streams (Pipes) exzessiv mit BASH and Splunk eingesetzt.  

Meine anfänglich Begeisterung sank recht schnell auf den Nullpunkt. Java Streams schienen in der Praxis mehr neue Probleme zu verursachen, als sie lösten, und welches Problem sollten Streams nochmal lösen.

Jetzt nachdem der Hype weitergezogen ist, hier in aller Ruhe ein paar Tipps und Antworten zu Java Streams. 

Frage: Welches Problem löst Java Streams?

Streams sind eine weitere From oder Alternative zu Schleifen (for, while). Sie bieten zwei Vorteile gegenüber den normalen Schleifen. Bei grossen Datenmengen kann man Streams parallelisieren, was auf Multi-Prozessorsystemen einen Geschwindigkeitsvorteil bringt. Dazu zwei Anmerkungen, in Cloud Umgebungen ala Marathon, Kubernetes, AWS - schaut in euere Configs ob ihr Überhaupt mehr als eine CPU habt, wenn nicht, bringt die Parallelisieren von Streams nichts. Die zweite Anmerkung, nur bei grossen Datenmengen ist die Parallelisieren sinnvoll, weil sonst der Overhead durch die Verteilung des Codes und der Daten über mehrere Cores die Geschwindigkeitsgewinn der Parallelisieren aufrisst.

Hier ein Beispiel für eine super simple Parallelisierung mit Java Streams: https://www.adam-bien.com/roller/abien/entry/java_8_from_ordinary_for

Das zweite Vorteil von Java Streams gegenüber normalen Schleifen ist, das die Abarbeitung strukturierter erfolgt (stream -> (filter -> map)* -> collect). Das war für mich eher selten das Problem, aber es eindeutig ist das ein Vorteil von Java Streams. Das Problem sind die Streams, das Problem sind die Programmier die mit Java vertraut sind. Sie fangen jetzt an das bekannte Exception Handling in den Streams einzubauen. Das ist generell ein Fehler oder besser der Fehler beim Umgang mit Streams. 

Streams behandeln nur positive Fälle. Ein Exception Handling oder ein Handling von Alternativen führt zu extrem schwierig zu lesendem Code. So etwas sollte in einem zweiten Stream gemacht werden. Streams sind verzweigungslos. Das macht sie so elegant und verständlich. 

Java Entwickler die es gewohnt sind Exceptions nahe am Ursprung zu behandeln, müssen umdenken und diese Funktionen in Filter und einem zweiten Stream auslagern.

Zusammenfassung:

1. Streams sind ein sinnvolles Pattern für die Softwareentwicklung
2. Streams sind verzweigungsfrei zu bauen, entsprechende Filter, ggf. Mappings und alternative Streams sind umzusetzen

Video: The Future of Programming von Robert C. Martin

Robert C. Martin aka Mister Clean Code von seiner besten Seite. Ein schönes Video über die Vergangenheit, den aktuellen Stand und die Zukunft der Sofwareentwicklung. Aber ich will nicht spoilern, seht selbst.

 

Default Values

Um Default Values gibt es immer wieder Diskussion unter Softwareentwicklern und oft sieht man das es scheinbar nicht ausreichend darüber nachgedacht wurde. Bezüglich der Default Values haben sich folgende zwei Regeln bewährt:

1. Ein guter Name, der keinen Interpretationsspielraum lässt.
2. Less Surprising Value

Hier ein Beispiel, in Kafka  gibt es ein  Replaction-Factor=1 der dazu benutzt wird die Replikation der Kafka Topics zu konfigurieren um so eine robuste Umgebung zu erhalten.

Was ist daran nun sub-optimal?

1. Schnellen Programmierern werden leicht übersehen das es sich um den Faktor und nicht die Anzahl der Replikas handelt. So könnte man annehmen das es mindesten ein Replika gibt. Diese Annahme trügt, beim Wert 1 gibt keine Topic Replikation, weil 1 * 1 = 1 ist . Besser wäre wenn das Property nicht Replica-Factor heissen würde sondern Replica-Count. Der Softwareentwickler muss nicht die Hürde der Multiplikation überwinden. Je weniger mentale Barrieren, desto besser.
2. Der Wert ist 1, das klingt erstmal gut. Trotzdem würde ich erwarten, das wenn man Kafka einsetzt, das die Replikation aktiv ist und das ist hier nicht der Fall. Besser wäre also hier der Wert 2 als Default Value.

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.