Vom 09. bis 11. April 2024 findet die JavaLand am Nürburgring statt. Zwei ereignisreiche Tage gefüllt mit Vorträgen, Community-Aktivitäten, einer begleitenden Ausstellung, Workshops, Austausch und Networking. Am letzten Tag der Konferenz findet ein Schulungstag statt, bei dem Gelerntes intensiv vertieft werden kann.
Der steigende Druck auf Unternehmen, durch den Einsatz von Künstlicher Intelligenz Prozesse zu automatisieren, um konkurrenzfähig zu bleiben, ist unbestreitbar. Gleichzeitig herrscht sowohl auf dem Arbeitsmarkt als auch innerhalb der Unternehmen ein Mangel an KI-Expert*innen, die in der Lage sind, solche Software zu implementieren und produktiv zu halten.
Für Software-Engineers sind Begriffe wie Künstliche Intelligenz, Machine Learning und Big Data zweifellos vertraut, doch werden diese Themen eher beim Plausch an der Kaffeemaschine als während des Pair-Programmings diskutiert. Doch wie groß ist tatsächlich die Kluft zwischen den Welten eines Software-Engineers und eines Machine-Learning-Engineers? In welchen Bereichen gibt es Überschneidungen, und wie geht man grundsätzlich an Machine-Learning-Projekte heran?
Kurzer Spoiler: Die Wahl der Programmiersprache spielt eine untergeordnete Rolle. Vielmehr sind es die Konzepte und Denkweisen, die den eigentlichen Unterschied ausmachen.
„Automatisierte Tests sind doch Standard“, „Unsere Code Coverage ist sogar über 100%“, „Wir haben sie alle: Unit-, Integrations-, System-, Akzeptanz-, E2E-Tests, you name it.“
Häufig haben wir das Gefühl, dass die Wichtigkeit der Testautomatisierung verstanden wurde und auch umgesetzt wird. Doch in den Projekten aus der Praxis sehen wir dann eher mehr Schatten als Licht: Unit-Tests mit hohem Pflegeaufwand, nicht vollständige Integrationstests, viel manueller Testaufwand von Testabteilungen oder Fachbereichen.
Die Gründe sind nachvollziehbar: Viele Abhängigkeiten, Testdaten zu erzeugen ist aufwändig und komplex, fachliche Anforderungen in Assertions zu überführen ist schwierig, Mehrwert von Tests schwer messbar, Prioritäten, etc.
Wir wollen in dieser Session nicht alle Probleme lösen, aber einen Ansatz vorstellen, der bei uns gut funktioniert. Dabei konzentrieren wir uns beim Testen auf die Benutzer-Sicht und zeigen, wie man mit definierten Szenarien und automatisierten Browser-Tests die Software genauso testet, wie der Benutzer sie am Ende auch verwendet.
Eine einzelne Serverless Function zu schreiben und produktiv zu stellen ist dank NoOps-Ansatz denkbar einfach. Nur leider macht eine Schwalbe noch keinen Sommer und eine einzelne Serverless Function noch keinen sinnvollen Anwendungsfall! Wie also konzipiert man eine Anwendung als Zusammenspiel von mehreren Serverless Functions und diversen weiteren Cloud-Komponenten? Gibt es spezielle Architektur-Pattern, die sich im Serverless-Umfeld anbieten? Und wie wirken sich diese auf den Software-Lifecycle aus? Was, wenn die niedlichen kleinen Funktionen sich zur Laufzeit nicht so verhalten, wie gewünscht? Wie sieht das Monitoring der einzelnen Funktionen und des Systems als Ganzes aus? Und was ist mit Testen? Muss die Funktion dazu immer in der Cloud deployt werden oder kann man das produktive System auch lokal emulieren?
Diesen und vielen anderen Herausforderungen wollen wir uns in dem CloudLand-Workshop stellen - Aha-Effekte garantiert!
Die Teilnehmer erlernen ein Verständnis für die Umsetzung von Serverless Szenarien und deren Herausforderungen.
Ein Software-System wird mit der Zeit immer größer und größer. Aus Zeitdruck werden Kompromisse in Design und Architektur eingegangen. Und ehe man es sich versieht, ist ein unwartbarer Monolith entstanden.
Eric Evans hat dieses Problem bereits 2004 in seinem berühmten Domain-Driven Design Buch erläutert. Er schlägt darin vor, die Software frühzeitig zu modularisieren und sogenannte Bounded Contexts zu bilden. Aber was kann ich tun, wenn das Kind bereits in den Brunnen gefallen ist?
Glücklicherweise gibt es in der DDD-Community einige Methoden, wie man (auch im Bestandssystem) Bounded Contexts etablieren kann. Event Storming ist eine solche Methode. Ursprünglich hat sie das Ziel, mit allen Stakeholdern gemeinsam die Fachlichkeit einer Anwendung zu erarbeiten. Richtig angewendet und bis zum Ende durchgeführt, bietet Event Storming aber noch mehr. Das Ergebnis kann nämlich sehr gut verwendet werden, um darauf basierend Bounded Contexte zu identifizieren.
Diese zeichnet dabei aus, dass wenig Kommunikation über Kontext-Grenzen hinweg passiert und das diese Kommunikation insbesondere robust ist.
In der Session stelle ich die Methode Event Storming vor und zeigen, wie man über die Methode Bounded Contexts ermitteln kann und diese so gestalten kann, dass darauf basierend Grüne-Wiese-Projekte aber eben auch Bestandssysteme modularisiert werden können.
- Was sind Bounded Contexte?
- Wie kann ich diese über Event Storming ermitteln?
- Wie kann ich Bounded Contexte in Bestandssystemen etablieren und so die Software sinnvoll modularisieren?
Erfahrungen in einem unwartbaren Monolithen helfen beim Verständnis des Problems ;-)
In der interaktiven Diskussionsrunde werden die Auswirkungen von Künstlicher Intelligenz (KI) auf die Arbeitsweise in der Softwareentwicklung erörtert. Experten und Praktiker aus der Branche, werden Fragen zu diesem Thema diskutieren und ihre Perspektiven teilen. Die Diskussion wird sich darauf konzentrieren, wie KI die täglichen Abläufe von Entwicklern beeinflusst, von der Automatisierung einfacher Aufgaben bis hin zur Optimierung komplexer Prozesse. Es wird debattiert, welche Vor- und Nachteile diese Veränderungen mit sich bringen und wie sich die Rolle von KI in Zukunft weiterentwickeln könnte. Durch den Austausch von Erfahrungen und Einsichten sollen verschiedene Standpunkte beleuchtet und neue Erkenntnisse gewonnen werden. (Autor: ChatGPT)
