From 55b00b5e65d245873c1601c9ab5118c40c6950ae Mon Sep 17 00:00:00 2001 From: Christoph Kroczek Date: Thu, 4 Jul 2019 20:32:55 +0200 Subject: [PATCH] java user forum notizen --- notes/conferences/javauserforum.md | 104 ++++++++++++++++++++++++++++- 1 file changed, 101 insertions(+), 3 deletions(-) diff --git a/notes/conferences/javauserforum.md b/notes/conferences/javauserforum.md index 0bb41c6..38d7b10 100644 --- a/notes/conferences/javauserforum.md +++ b/notes/conferences/javauserforum.md @@ -22,10 +22,108 @@ Phasen des chaos - 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 \ No newline at end of file