refactoring

readingcorner/conferences/javauserforum.md

@@ -0,0 +1,129 @@
+# Vortrag "Chaos Engineering"
+- BUgra Derre von Dailmer TSS
+- Daimler TSS -> Freitag Nachmittag frei für eigene Projekte
+
+Sinnbild:
+Der Affe stört SW-Engineers happy life. Er sorgt für chaotische Zustände
+
+Lustige Frage: Wer würde sich trauen einen Herzschrittmacher für sich selbst zu programmieren , kaum Hände oben ;-)
+
+Leslie Lamport:
+Systemausfälle als Regel.
+Verteilte Systeme führen dazu das das eigene System nicht mehr funktioniert, transitive unbekannte Abhängigkeiten!
+
+
+Chaos kann man trainieren.
+Chaos erzeugt nicht fehler es deckt sie auf.
+
+Phasen des chaos
+- Hypothesen formulieren (Szenarien)
+- Experimentieren veränderungen vornhemen z.B. Latenzen einführen
+- lernen
+- anpassen
+
+Methodik eher für Cloud Dienste?
+Buchempfehlung - Release It
+Gamedays -  Vollautomatische Durchführung von Chaos tests die z.B. ein Team Treffen
+-> SH ist unser Monkey ;-)
+Schon durch das blosse durchdenken der Experimente können Fehler gefunden werden bzw. man erkennt ohne Experiment dass es fehlschalgen wird.
+
+
+# Embedded raus aus dem Bett  (Bosch)  Harald Göttlicher
+Cooler/ Netter Typ, Bosch Kollege , Zuständig für Coninous Delivery
+Embedded Entwicklung hat spezielle Anforderung z.B. Hardwarebindung
+
+Wer wenig oft liefert macht viel manuel und ist ineffizient
+Niedriger Durchsatz
+Hohe Fehlerraten weil große Releases mehr Inhalt haben was zum mehr Komplexität bedeutet
+Aussagen basieren auf einem Report -> siehe state of devops report
+
+Lernen von DevOps, passen diese Methoden für Embedded?
+
+Vision : Monolithen in ganz viele einzelne Kompnenten aufteilen -> Microservices
+Wir brauchen einen Paradigmenwechsel von Schichtenarchitektur zu Komponentenarchitektur für einzelne Funktionen. Schneide kleiner als du gedacht hast.
+Viele Komponenten bedueten viel Aufwand für Automatisierung -> Lösung Automatisierung der Automatisierung. Es gibr auch tools dafür z.B. Ansible , Chef , Puppet
+Umgebungen zum bauen in Container kapseln.
+
+Der näcshte Schritt man denknt nicht mehr in layern sonder in Komponenten.
+Inkrementeller Build, es wird eine BOM von letzter Version gemacht und ein Diff zur aktueller gemacht, es werden nur aktualiesierte Artefakte aktualisiert.
+
+Tests müssen passend zu Komponenten geschnitten werden.
+
+
+# Implementation Patterns Dr. Frank Gerhardt
+Buch Implementation Patterns von Kent Beck
+Implementation Patterns sind zwischen Desgin PAtterns und Style Guide
+
+andere Leute sind wichtig , andere Perspektiven Berücksichtigen. So programmieren dass andere den Code auch verstehen.
+
+Programmieren is wie Jeopodardy.
+
+3 Werte & 6 Prinzipien:
+
+## Werte 
+- Kommunikation , liteerate programming, 
+- Simplicity, keine goldenen Wasserhähne
+- Flexibiiliät, kann auch missbraucht werden, es macht vorab keinen Sinn vorab zuviel zu abstrahieren. Keep options open
+
+## Prinzipien
+- locale consequences
+- keine wiederholung
+- logik anda data together
+- symmetrie / Integriät
+- ..
+
+Kosten für code entstehen nicht in der Entwicklung sondern später beim erweitern und pflegen
+
+Conditional, if / if / if / else sollten symmetrisch sein
+
+Gemeinsame sprache entiwcklen verinfacht feedback in Code Reviewees
+
+Message pattern: compute() input,process,output
+
+single exit , nicht mehr relevant heute
+
+
+Erkenntnis: Implementation pattterns viel wichtiger als Programmiersprachen Konzepte ( lambdas, predicates,)
+
+ 
+# DSL mit Kotlin FRank Scheffler
+Code in Github
+Kotlin Konzepte: val macht immutable variablen, keine null Zuweisung wenn überhaupt denn Deklaration Fragezeichen? 
+String templating 
+Man Klassen Funktionen andichten  (Extension Functions)
+
+
+
+# Dr. Elmar Juergens / Meine Erfahrungen aus 10 Jahre Entwicklung von Qualitätsanalysen
+- Gründer von Firma welche Qulaitätsanalysesoftware erstellt / nutzt
+
+Software Inelligence
+Test Gap Analyse - 
+Tickets können auch als Datenquelle zur Priosierung von zu testenden Modulen verwendet werden.
+
+Die Herausforderung ist die Testfälle zu identifizieren die den geänderten Code durchlaufen. Optimiert den Testdurchlauf hinsitlich zeit.
+Beim REview muss der Test nachgewiesen werden.
+
+Nur auf dem master/develop branch alle tests durchführen, auf dem feature brach reicht es aus nur die impaktierten TEsts auszuführen, bei uns dauert es 20 Minuten und es wird immer gebaut.
+
+
+Code peer reviews:
+Review abgeschlossen wenn alle Probleme abgeschlossen sind.
+Unit of review ist ticket! Jira Zustand für REview und Rework
+
+Nutzen von Reviews:
+- Code wird besser es kommt nichtmal drafau an funktionale FEhler zu finden
+- Haupfaktor Wissenstransfer
+
+
+
+# Zum Nachschlagen
+- Kubernetes
+- Circuit Breaker Pattern, wiederkehrende Verbindung die erfolglos sind behandeln -> fallback lösung
+- Wie testet man einzelne Bundles? 
+- Dokumentation der einzelnen Bundles mit Sinn und Schnittstellen
+- Mit Kotlin experimentieren
+- Mit Predicates arbeiten
+- Funktionale Interfaces
+- Generics
+- DSL Buch Fowler