Dev Day 2022

In Eric Evans' Book über Domain-Driven Design taucht der Begriff "Closure of Operations" auf als Design-Prinzp für Domänenmodellierung. "Definiere Operationen, deren Rückgabetyp der gleiche ist wie der ihrer Argumente!" steht da. Das ist so obskur, dass es kaum jemandem aufgefallen ist - die meisten DDD-Bücher erwähnen "Closure" gar nicht.

Die Kernbausteine des taktischen Designs in Domain-Driven Design (DDD) definieren atomare Designkonzepte für Domänenmodelle. Sie definieren Semantik, Regeln und leiten Entwickler:innen dabei, Domänencode zu strukturieren und so komplexe Geschäftslogik zu implementieren. Die Umsetzung in Java birgt dabei jedoch einige technische Herausforderungen.

„Datenschutz ist mir egal, ich habe nichts zu verbergen!“

Jede Firma, die Software entwickelt, kämpft mit hoher Komplexität, technischen Schulden, unklaren Anforderungen und zu geringer Entwicklungsgeschwindigkeit - Punkt. Wer etwas anderes behauptet, lügt das blaue vom Himmel herunter.

2021 hätte eigentlich ganz entspannt ausklingen sollen. Wäre da nicht eine Serie an Sicherheitsproblemen in der Log4j 2 Bibliothek für Java gewesen — die gravierendste Schwachstelle ist auch als Log4Shell bekannt.
Der Vortrag gibt einen Überblick wie die Schwachstelle funktioniert, aber auch warum es relativ trickreich ist das Problem überall richtig zu erkennen. Zusätzlich sehen wir uns an, wie man sich generell dagegen hätte schützen können und was (nicht) funktioniert.

Das arc42-Architektur-Template verleitet dazu alle Kapitel von oben nach unten durchzuarbeiten. Ein Architektur-Review offenbart aber eine sinnvollere Herangehensweise, um Softwarearchitektur zu erarbeiten. Dabei wird zuerst der In-Scope und Out-Of-Scope des Vorhabens definiert, anschließend Qualitätsattribute aufgenommen um schließlich konkrete Qualitätsszenarien abzuleiten.

Dieser Vortrag stellt eines der weniger bekannten OpenSSH Features vor: signierte Schlüssel. Neben einer kleinen Live-Demo gehe ich dabei auch auf praktische Fragen ein und erkläre, wie sich Teamwechsel, Schlüsselwechsel, Keyrevocation usw. umsetzen lassen.

Qualität bildet die Existenzberechtigung für Softwarearchitektur: Zuverlässig, performant, skalierbar und benutzerfreundlich sollen unsere Systeme sein, das alles kosteneffektiv und zukunftssicher. Alle IT’ler wissen dass diese Kombination von Eigenschaften harte Arbeit bedeutet. Lernen Sie hier, wie sie systematisch Qualität konstruieren können, so dass Ihre Systeme "richtig gut" werden!

Fehler passieren, sie sind weder gut noch schlecht. Nur unser Umgang mit ihnen entscheidet darüber, ob wir uns weiterentwickeln, oder im Teufelskreis gefangen bleiben. Noch komplizierter wird das Ganze, wenn wir im Team, oder gar mit mehreren Teams, arbeiten. Da wir nicht alle Fehler selbst machen können (und wollen ;) ), müssen wir miteinander und voneinander lernen. Ich möchte euch gerne vorstellen wie wir bei uns an dieses Problem herangehen. Der Vortrag ist zweigeteilt, zuerst stelle ich die aus unserer Sicht nötige Denkweise vor und im zweiten Teil gibt es ein praktisches Handwerksmittel, das "Blameless Post Mortem", welches ihr direkt bei euren Projekten anwenden könnt.

Wir zeigen einen Ansatz, der es ermöglicht, mittels eines neuronalen Netzes automatisiert Selenium Testfälle zu erstellen. Wir zeigen, worauf beim Training neuronaler Netze geachtet werden muss, um GUI-Elemente annähernd so gut zu erkennen wie ein Mensch. Neben der stabilen Elementerkennung spielt Robustheit bei Ausführung und Wartbarkeit der Testskripte eine entscheidende Rolle. Wir zeigen einen multidimensionalen Identifier Ansatz, um diese Stabilität und Robustheit in der Testautomatisierung zu erreichen. Anhand einer Live-Demo unseres Produktes ai4test veranschaulichen wir, wie ai4test den Alltag eines klassischen Testautomatisierers vereinfachen soll und wo es noch nicht unterstützen kann.

"Never touch a running system" ist ein Anti-Pattern! Indem du dein System nicht pflegst, verurteilst du es zum Scheitern. Genauso wie menschliche Muskeln trainiert werden müssen um auf zukünftige Belastung vorbereitet zu sein, muss die Software "trainiert" werden um den kommenden Herausforderungen gewachsen zu sein. In diesem Talk möchte ich das Konzept der Antifragilität, dessen Auswirkungen auf die Softwareentwicklung und wie diese Tatsache zu einem Vorteil genutzt werden kann vorstellen.

Seit vielen Jahren wünschen sich vor allem unsere Software- und System-Engineers einen Linux-Client, um ihre Arbeit schöner, freier, effizienter und näher an der Zielumgebung für ihre Software verrichten zu können.

„Softwarearchitekt“ – in Zeiten agiler Entwicklung wirkt dieser Begriff fast schon angestaubt und veraltet, vermittelt er doch den Eindruck man würde vorrangig Blaupausen erstellen, die dann von anderen Personen in Beton gegossen und nie wieder verändert werden. Dies ist nicht korrekt. Software verändert sich kontinuierlich und evolutionär. Beachtet man dies nicht, kann es zu erheblichen Problemen kommen.

• spielerisch Angreifer verstehen und teste dein Wissen in verschiedenen Bereichen rund um das Thema Cyber Security
• Vermittlung von theoretischen und praktischen Kenntnissen zum Thema Cyber Security
• Hauptpreis: Schulung: Pentest zum Anfassen und weitere Preise

begleitend:
- Sessions mit aktuellen Live Hackings und Demonstration von Angriffsvektoren
- Bestimmung des individuellen Sicherheitsniveaus und -risikos

"Mit der zusätzlichen Technologie wird alles viel einfacher und besser. Das neue Framework lässt uns schneller entwickeln und mehr Features umsetzen. Wenn wir das Modul nochmal neu bauen, machen wir gleich alles richtig."

Typen sind zur Laufzeit weg. Das lernen wir schon von Tag 1 an, wenn wir uns mit TypeScript beschäftigen. Im Laufe der Zeit hat die Community dennoch viele Wege gefunden, wie wir Konstrukte zwischen der Typ- und der Werte-Welt hin und her transportieren können. Begleitet mich auf einer Reise durch die Zeit und lernt mit mir, wozu TypeScript noch alles fähig sein kann.

In der Praxis arbeiten Softwareentwickler häufig an über Jahre gewachsenen Anwendungen, deren Architektur über die Zeit erodiert und damit weder im Code erkennbar noch verlässlich in der Dokumentation auffindbar ist. Wartung und Erweiterung sind daher meist kostenintensiv.
Im Kontrast dazu implementieren derartige Systeme eine große Menge an Wissen und stellen häufig einen unverzichtbaren geschäftlichen Wert dar. Die Ablösung des Altsystems kommt schon allein aufgrund der entstehenden Kosten nicht in Frage. Doch ist man damit der Legacy schutzlos ausgesetzt?
Am praktischen Beispiel soll gezeigt werden, wie Software Analytics und moderne Tools die tägliche Arbeit unterstützen und wie Wissen über das System wiedererlangt, dokumentiert und zur Planung von Refactorings verwendet werden kann.