Freitag, 21. Juni 2019

Die Evolution der Datenaustausch-Formate: Binary, CSV, XML, Properties, JSON, YAML

Es gibt eine Reihe von Datenformaten für den Datenaustausch zwischen Programmen bzw. für deren Konfiguration. Hier eine Übersicht über gängige Formate, deren Vor- und Nachteile.


BinaryCSVXMLJSONYAMLProperties
Geeignet für DatenauschJaJaJaJaJaSchlecht
Geeignet für KonfigurationNeinNeinJaJaJaJa
Verständlichkeit beim Lesen für den EntwicklerNeinGutGutSehr gutSehr gutSehr gut
SpeichereffizienzSehr gutGut bis Sehr gutSehr SchlechtSchlechtGutSchlecht
Unetrsctüzung in der BASHNeinSehr gutGutGutSchlechtSehr gut
Parser GeschwindigkeitSehrt hochHochGeringGeringGeringHoch
NachteileEingeschränkte Kompatibilität


Kein Kommentare


Vorteile

Sehr hohe VerbreitungSchema Definition



Dienstag, 18. Juni 2019

Was ist die optimale Sprint Länge in SCRUM?

Die klassische Zeitspanne eines SCRUM Sprints sind 4 Wochen. In meinen letzten Projekten wurde die Sprintdauer auf 2 Wochen genutzt. Die Idee den 2 Wochen Sprints war, durch kürze Iterationen soll das Produkt zielgenauer für den Kunden entwickelt werden. Die Idee ist gut und funktioniert auch.

Leider gibt es auch Nachteile dieser kurzen Sprints. Hier die typischen Symptome, wenn die Sprints zu kurz sind:

  1. Die Sprint Velocity springt extrem, weil 95% fertige Stories in den nächsten Sprint kommen.
  2. Auch kurze Ausfälle von Software Entwicklern sind deutliche in der Sprint Velocity zu erkennen.
  3. Dies führ aus Sicht der Project Owner zu einer schlechten Planbarkeit und Frustration.
Wenn diese Symptome wiederholt Auftreten, verlängert die Sprintdauer, Frust bei den Project Owner und beim Entwickler Team wird abgebaut und vermieden.

Die optimale Sprintlänge ist die kürzeste Zeitspanne, die euch ermöglicht eine stabile Menge an Features an den Kunden auszuliefern. Dann habt ihr die Balance zwischen Planbarkeit und zielorientiertem Arbeiten und Performance erreicht.

Der oft hervorgebracht Kritikpunkt, aber die anderen Teams arbeiten im z.B. 2 Wochen Sprint Takt, ist irrelevant, weil die Teams unabhängig arbeiten und unabhängig ihr Produkt-Increment deployen.

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

Mittwoch, 12. Juni 2019

Bad Developer

Über schlechten Code gibt es viel zu Lesen. Aber es gibt nicht nur Bad Code und Clean Code sondern auch Bad Developer. Hier eine Episode aus meinem Alltag als Softwareentwickler.


Gestern im SCRUM Planungsmeeting.

Softwareentwickler Jack: "Ich bin hier nicht um zu programmieren, ... "

Ich: ??? (fassungslos)


Im Nachhinein hatte der Entwickler Jack sogar recht, er hat innerhalb von über zwei Monaten keinen einzigen Story-Punkt abgearbeitet. Die Frage, warum bezahlt der Kunde für solche Softwareentwickler? Um die die Sache zu verschlimmern arbeitet der Entwickler keine Stories ab sondern er raubt auch noch den anderen Entwicklern die Zeit. Ein absolutes Minusgeschäft.


Hier mal als O-Ton von der Velocity, was für ein Unterschied in mentalen Einstellung.

"There are only two things your organization should be spending time on: making your customers happy, or making your people happy.". -@lizthegrey at o11y meetup. #velocityconf

Freitag, 7. Juni 2019

Datenschutz: Es dürfen keine persönlichen Daten geloggt werden.

Ein Hauptquelle für das Exponieren von persönlichen Daten ist das Logging. Programmierer loggen einfach Objekt zu Debug-Zwecken oder in Fehlerfall. Diese Daten landen in Log-Dateien oder im ELK Stack. Dort gehören sie nicht hin.

Hier ein Weg dies zu verhindern. Für das Logging wird in der der Regel die toString() Methode in Java benutzt. Diese muss man bei allen Klassen deren Objekte persönlich Daten enthalten überschreiben. Hier ein Beispiel:

    @Override
    public String toString() {
        return "DATENSCHUTZ";
    }
    

Mit diesem einfachen Overwrite der toString() Methode verhindert man das persönliche Daten geloggt werden und gleichzeitig kann man die Verwendung potentiell kritischer Aufrufe im Log finden und diese Stellen entfernen. Bei Bedarf sollte man auch die Methode asString() genauso überschreiben.