How can a deterministic function possibly give random results? We will find out and learn how to use various random number distributions.
Random numbers haven't changed much since C++11, though new features can make these easier to use. Card games and similar need randomness to be fun and make good teaching examples. We will also discover a way to code ourselves (or blobs at least) out of a paper bag in the process.

Target Audience: intermediate. There will be some code and simulations of blobs escaping paper bags
Prerequisites: None but there will be some algorithms and C++
Level: Advanced

Extended Abstract:
Most of us need a random number at some point if we write code. We will discover how they are generated. We will see how to ensure simulating a dice roll makes the numbers 1 to 6 equally likely, and note some pitfalls to be aware of in some programming languages.
We will have a brief aside into stochastic outcomes from deterministic models, also known as chaos. Applying a function iteratively can’t possibly give non-deterministic results, right? We shall see.
After this aside, we will return to using random numbers. We will consider common mistakes and how to think clearly about "random" code. To round off, we will think about how to test code which uses random numbers.
By the end we’ll be familiar with terms like pseudorandom number generator (PRNG), linear congruential generator and random distribution. Finally, we’ll use various distributions to race some blobs out of a paper bag. Seeing a visual demonstration will solidify some the learning outcomes.

In this session we will walk through various techniques to significantly reduce the resource consumption of regular Spring Boot applications, including using Spring AOT for regular Spring apps, compiling Spring Boot apps to native images (using GraalVM), and using CRaC for instant startup (for scale-to-zero scenarios). We will compare the different approaches, discuss pros and cons for each technology, and share concrete numbers from real-world applications to give the audience an idea of what can be achieved using these technologies.

Target Audience: Developers, Architects
Prerequisites: Basic Spring Boot knowledge required
Level: Advanced

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/martin.lippert

User-centred design is one of the default modes of teams working with software, but the consequences are often unsustainable in a densely networked world as we privilege users over all other stakeholders and systems. How might teams approach building products, services and organisations from a more sustainable standpoint than 'user-centricity'? This talk looks at how the techniques of game design, community development, platform operations and security practices can support a practice focused on hyperobjects for multi-centric design.

Target Audience: Leaders, Builders, Architects, Designers, Community Members
Prerequisites: No previous knowledge, only enthusiasm for systems, building things and design
Level: Advanced

Extended Abstract:
The key feature of a 'tragedy' is when everybody does the right thing but it goes wrong anyway. The aim of this session will be to look at why user-centred design goes wrong even if everyone's intentions are pure. This talk (gently!) brings in ideas from feminism, design thinkers, political science and anthropology to focus on very practical, grounded approaches to sustainable design in software teams. We'll look at how building things and designing organisations that have increased levels of friction can improve users' experience and how 'seamless' design can lead to disempowerment. And we'll also draw on the speaker's practical experience of building products used by millions of citizens as part of the UK's digital transformation. By the end of the session we'll have a sense of what might replace the shallow seamlessness of 'user-centred' design — a multi-centric, transcendental design aimed at manufacturing enthusiastic consent.

Je mehr sich die Arbeit der Menschen vom Taktilen in Richtung digitaler Arbeit verschiebt, desto wichtiger wird das Design der Oberflächen für die Interaktion mit dem Digitalen. Wir haben uns in den vergangenen Jahren gefragt: Wie kann der Designprozess so in agile Software-Entwicklung integrieren, dass ein gut verwendbares System mit einer auf Dauer flexiblen und anpassbaren Software-Architektur entsteht? Wir haben auf verschiedenen Ebenen Antworten gefunden, die wir den Zuhörern in diesem Vortrag gerne vorstellen wollen.

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Manager:innen
Voraussetzungen: Erfahrung mit Software-Entwicklung
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Je mehr sich die Arbeit der Menschen vom Taktilen in Richtung digitaler Arbeit verschiebt, desto wichtiger wird das Design der Oberflächen für die Interaktion mit dem Digitalen. Wir haben in den vergangenen Jahren in verschiedenen Anwendungsbereichen mit zwei Fragen gerungen: Wie lässt sich Arbeit in ein Interaktionsmodell überführen, bei dem die bisherigen Arbeitsabläufe wiedererkennbar sind, aber hilfreiche neue digitale Features eine echte Verbesserung darstellen? Wie kann der Designprozess für solche Interaktionsmodelle in agile Software-Entwicklung integriert werden, so dass ein gut verwendbares System mit einer auf Dauer flexiblen und anpassbaren Software-Architektur entsteht? Wir haben auf verschiedenen Ebenen Antworten gefunden, die wir den Zuhörern in diesem Vortrag gerne vorstellen wollen.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/carola.lilienthal

In meinem Vortrag analysiere ich Statistiken zum Scheitern agiler Übergänge und enthülle dabei die entscheidenden Erfolgs- oder Misserfolgsfaktoren. Im Zentrum steht das Produkt-Management – der Schlüssel, um diese Transitionen zu meistern. Wir decken nicht nur Hindernisse auf, sondern präsentieren auch praxiserprobte Ansätze, um diese zu umgehen und den Weg zum Erfolg zu ebnen. Erleben Sie eine kompakte Reise durch die Welt der agilen Transitionen, die Ihnen wertvolle Erkenntnisse für die Zukunft bietet.

Zielpublikum: Leiter:innen, Product Owner:innen, Product Manager:innen, Agile Coaches, Entscheider:innen
Voraussetzungen: Projekt-, Produktmanagement-Erfahrung, Produkt-Owner-Erfahrung
Schwierigkeitsgrad: Experte

In großen Unternehmen entwickeln viele Teams REST APIs. Dabei gibt es einige Aufgaben, die sich wiederholen: z.B. Validierung, Test und Publikation. Der Aufbau einer API Operations Pipeline zur Automatisierung dieser Aufgaben ist aufwändig. Dieser Talk zeigt am Beispiel von Azure DevOps Templates, wie so eine Pipeline als Service angeboten werden kann. So kümmert sich ein spezifisches Team um die Entwicklung und Wartung der Pipeline, während alle anderen sich auf das Design und die Entwicklung ihrer APIs fokussieren können.

Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: OpenAPI, DevOps
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Folgendes lernen die Zuhörenden in der Session:

• Welche Vor- und Nachteile hat es, eine API Operations Pipeline zentral zur Verfügung zu stellen?
• Welche Aufgaben kann eine API Operations Pipeline übernehmen?
• Wie können konkrete Aufgaben wie Validierung und Test umgesetzt werden?
• Wie können Azure DevOps Templates für eine API Operations Pipeline als Service eingesetzt werden?
• Wie kann das Einbinden und die Nutzung dieser Pipeline für andere Teams vereinfacht werden?

Der Talk enthält eine interaktive Live-Coding Session zu API Contract Testing.

Programmierer:innen der Mainstream-Programmiersprachen sind schon sehr erstaunt über die Mächtigkeit eines Lisp-Makrosystems. Wir können dadurch Sprachfeatures ganz einfach selbst implementieren und die Programmiersprache auf natürliche Art und Weise erweitern.
Racket, ein besonderer Lisp-Dialekt, geht noch weiter: Nicht nur ist das Makrosystem besonders ausgefeilt (Stichwort Hygienic Macros) – die Sprache ist sogar darauf ausgelegt, Makros zu schreiben, die eigene Subsprachen (DSLs) realisieren und reibungslos zu integrieren.

Zielpublikum: Entwickler:innen, Architekt:innen
Voraussetzungen: Kein Vorwissen erforderlich
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Wir entwickeln damit komfortabel für verschiedene Domänen eigene Sprachen mit eigener Syntax. Dieser Stil wird deshalb "Language Oriented Programming" genannt – wir passen die Sprache ultimativ an die Domäne und die Anwenderin an.
Dieser Talk gibt eine kurze Einführung in Racket, dann wird das Makrosystem vorgestellt und die #lang-Funktionalität.
Es ist kein Vorwissen erforderlich.

Microfrontends are a popular concept for development in an enterprise project, where a large number of teams want to work independently.
But what is the cost achieving run-time integration and independent framework versions?
JS frameworks intended to build SPAs have solved many problems like deep-linking between pages without reloading the application.
This talk will give you some real life experience which challenges are to be considered using different integration patterns, using webcomponents, module federation and "classic" libraries.

Target Audience: Architects, Developers, Project Managers
Prerequisites: Basic knowledge of Angular or other JS SPA Frameworks
Level: Advanced

Extended Abstract:
How often do project managers wish for a microfrontend architecture? Contrary to microservices in the backend, microfrontends are not always the recommended future choice.
You might have to solve a lot of problems, that have already been solved in frameworks like Angular or React.
If we start separating UI elements in encapsulated webcomponents, we risk a lot of effort re-creating capabilities like deeplinking (routing) or event handling across components.
Or: we need to add additional frameworks that solve the challenges of navigation, context transfer and layouting.
The talk provides an overview, what default architecture patterns Angular provides and how to mitigate problems that might come with classical architectures or a monorepo.
The talk will mention use cases, when the usage of microfrontends is feasible and recommended. It will also provide workarounds if a microfrontend architecture is needed.

Statische Analysetools liefern Security-Findings, aber ihre Wirksamkeit wird durch hohe Fehlalarme beeinträchtigt. Entwickler ignorieren diese, während das Management sie als kritisch betrachtet, sowohl aufgrund möglicher Angriffe als auch im Hinblick auf Security-Audits. Dadurch entstehen unnötige Kosten und Verzögerungen. In unserem Vortrag teilen wir 10 Jahre Erfahrung, präsentieren typische Sicherheitsprobleme und effektive Analyseansätze. Zudem stellen wir bewährte Methoden für kontinuierliches Monitoring und Schwachstellenabbau vor.

Zielpublikum: Entwickler:innen, Architekt:innen und Manager:innen mit Verantwortung für Security
Voraussetzungen: Interesse an hoher Sicherheit von Software
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Es gibt inzwischen viele statische Analysetools, auch kostenlose, die Security-Findings für die eigene Code-Basis erzeugen. Diese potenziellen Sicherheitslücken werden jedoch sehr unterschiedlich wahrgenommen: Aus Entwickler-Perspektive ist es oft frustrierend, wie hoch der Anteil an False Positives (also Fehlalarmen) ist. Daher sehen wir in vielen Projekten, dass die Findings ignoriert oder im Analysetool abgeschaltet werden. Aus Management-Perspektive werden solche Findings jedoch oft als kritisch bewertet. Einerseits, weil einige davon tatsächliche Angriffe ermöglichen. Andererseits, weil solche Findings bei einem (vorgeschriebenen) Security-Audit oft selbst dann aufschlagen, wenn es sich um False Positives handelt. Allerdings sind diese Findings dem Management oft bis zu einem konkreten Audit unbekannt. In Kombination führen diese beiden Perspektiven dazu, dass die Findings ignoriert werden, bis es knallt. Das ist nicht nur schmerzhaft für alle Beteiligten, sondern auch unnötig teuer, da die späte Behebung von Findings viel teurer ist, als ihre frühe Vermeidung. Im Vortrag fassen wir 10 Jahre Erfahrung aus der Analyse von vielen Systemen in unterschiedlichsten Branchen zusammen. Dabei geben wir einen Überblick, welche Security-Probleme wir typischerweise finden und durch welche Analyseansätze sie aufgedeckt werden können. Außerdem präsentieren wir ein Vorgehen zum kontinuierlichen Monitoring und Abbau von Schwachstellen, das sich bei verschiedenen Teams bewährt hat.

This technical session aims to unravel the unique facets of Rust's memory management, including Ownership/Borrowing, Stack/Heap allocation, Reference Counting, and Lifetimes. Rainer Stropek aims to provide an in-depth understanding of these core elements and their interplay in providing memory safety, concurrency, and abstraction in Rust. This session, designed for developers with a strong programming background, will provide insight into the mechanisms that help Rust minimize common runtime errors.

Target Audience: Developers
Prerequisites: Strong development background
Level: Expert

Extended Abstract:
In the arena of systems programming, memory management is a fundamental concern. How a language approaches memory safety, concurrency, and performance has substantial implications for the efficacy of the programs it produces. Rust's unique approach to these concerns through its intricate yet robust memory management system is the focus of this technical session.
We will explore Rust's ownership rules which hinge on three key concepts: ownership, borrowing, and lifetimes. Rust's Ownership system is unique in its way of maintaining a clear distinction between mutable and immutable references and strictly enforces a single ownership policy to ensure safe memory access. We'll delve into the 'borrow checker' system, which keeps track of scopes to enforce these rules at compile-time, effectively minimizing runtime errors.
Next, we'll look at how Rust deals with memory allocation on the Stack and Heap, providing a safer and more explicit interface to these lower-level details. A clear understanding of these processes allows developers to write efficient, error-free code.
The session also takes an in-depth look at Reference Counting (Rc and Arc), Rust's form of memory management for data that has multiple owners. This approach ensures the automatic cleanup of resources, contributing to Rust's promise of memory safety.
Lastly, we'll dissect Lifetimes, a powerful concept Rust introduces to ensure references are always valid. By defining and enforcing Lifetimes, Rust ensures that memory safety is guaranteed without any cost to runtime performance.
This session is tailored for developers who already have a strong programming background and are considering delving deeper into Rust or are interested in the unique aspects of its memory management.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/rainer.stropek

Python befindet sich seit Jahren unter den Top 3 der populärsten Programmiersprachen. Spätestens seit dem anhaltenden Hype um maschinelles Lernen führt selbst für normalsterbliche Entwickler praktisch kein Weg mehr an Python vorbei.
Aber wieso ist die Sprache eigentlich so beliebt – selbst außerhalb von Machine Learning? Welche Eigenschaften zeichnet sie aus? Ist es sinnvoll – und funktioniert das überhaupt –, so einfach von Java, .NET oder C++ auf Python umzusteigen?

Zielpublikum: Erfahrene Software-Entwickler:innen und -Architekt:innen
Voraussetzungen: Erfahrung in einer Hochsprache, typischerweise aus der Java-, .NET-Welt oder C++-Welt
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Als langjähriger Java-Entwickler ist dem Vortragenden natürlich v.a. die Java-Sicht sehr gut bekannt, sodass (hoffentlich) ein möglichst wertneutrales Bild davon gegeben werden kann, was Java von Python unterscheidet und wo beide Sprachen jeweils ihre Stärken und ihre Schwächen haben. Wie bitte? Schwächen? – Ja, auch die gibt es. ;-)

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://sigs.de/autor/christian.heitzmann

Die Business-Verantwortlichen sind oft unzufrieden mit der Software-Entwicklung: "Wenn die Entwicklungs-Teams nur schneller arbeiten würden, wären wir viel erfolgreicher!" Und obwohl die Teams Feature um Feature ausliefern, will sich der Erfolg nicht einstellen – die Build Trap.
Meist ist in dieser Situation gar nicht klar, welches Ziel das Produkt eigentlich erreichen soll, weil es immer nur um Output geht und kaum Outcome. Ich zeige in dem Vortrag anhand praktischer Beispiele, wie man die Build Trap erkennt und wie man ihr entrinnt.

Zielpublikum: Entwickler:innen, Architekt:innen, Product Owner:innen
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Für ein modernes Web-Frontend greift man am besten zu Angular, React & Co., oder? - Nicht unbedingt! Auch native Bordmittel, zusammen mit ein paar Libraries, können eine echte, leichtgewichtige Alternative sein. Und man kann sogar schrittweise dorthin migrieren. Basierend auf konkreter Projekterfahrung, möchte ich den Blick für diesen Ansatz schärfen, Vor- und Nachteile aufzeigen und das Ganze anhand von Codebeispielen illustrieren.

Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: Wer schonmal etwas von JavaScript, HTML und Angular/React/... gehört hat, ist richtig
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
„Ein modernes Web-Frontend kann man nur mit Angular, React o. ä. bauen, weil die HTML- und JavaScript-Bordmittel bei Weitem nicht ausreichen. Da helfen auch ein paar kleine Libraries nicht.“
Dieser häufig anzutreffenden Ansicht möchte ich in diesem Vortrag widersprechen und dem reflexartigen Griff zu Angular & Co. eine Alternative gegenüberstellen: WebComponents ... also doch die nativen Bordmittel!
Mit WebComponents lässt sich eine Web-Applikation aus unabhängigen, wiederverwendbaren Komponenten entwickeln, ohne sich an ein schwergewichtiges Framework zu binden. Frameworks sind Gesamtpakete, die bequem sein können, aber auch Nachteile mit sich bringen. Zum Beispiel können sie durch ihren All-In-One-Charakter unflexibel sein und eine große Abhängigkeit auf sich einfordern, von der es sich zu lösen lohnen kann. Der vorgestellte Ansatz tut dies. Die üblicherweise vom Framework bereitgestellten Features und Tools werden dabei durch kleine Libraries ersetzt, die zu den individuellen Anforderungen des Projekts passen und jederzeit unabhängig voneinander aktualisiert/ersetzt werden können.
Basierend auf konkreter Projekterfahrung möchte ich aufzeigen, dass man auch ohne Framework ein voll- und hochwertiges Web-Frontend entwickeln kann. Sogar dass man Schritt für Schritt unter Beibehaltung der Lieferfähigkeit von einem Framework wegmigrieren kann, ganz im agilen Sinne. Ich bin auf jeden Fall glücklich damit, dass mein Team den Mut dazu aufgebracht hat, und dass wir dadurch bei einem besseren Frontend mit einer nachhaltigen Architektur herausgekommen sind.
Welche Vorteile bietet dieser Ansatz? Wie geht das denn konkret mit den WebComponents? Wie ersetzt man die „unverzichtbaren“ Vorteile eines Frameworks? Was genau verstehen wir hier eigentlich unter einem Framework? Wie schmerzhaft ist eine Migration weg von einem Framework, hin zu einer reinen WebComponent-Lösung? Geht eine solche Lösung nicht mit viel mehr Komplexität einher? Auf diese Fragen möchte ich eingehen, Live Coding inklusive.

Many developers evoke technical debt to explain the misfortunes and troubles of their codebase and delivery. While unmanaged technical debt weighs down an architecture and exerts drag on its schedule, it is more often an effect than a cause. In this talk, we will look at what is and is not meant by technical debt with a view to properly attributing the root and recurring cause as technical neglect than technical debt. Without seeing technical neglect for what it is, we will continue to misattribute our problems to an effect rather than a cause.

Target Audience: Developers, Architects, Technical Managers
Prerequisites: Responsibility for software development, whether implementing it, guiding it or managing it
Level: Advanced

Extended Abstract:
Many developers evoke the mischievous spirit and day-to-day burden of technical debt to explain the misfortunes and troubles of their codebase and delivery. While unmanaged technical debt weighs down an architecture and exerts drag on its schedule, it is more often an effect than a cause. In this talk, we will look at what is and is not meant by technical debt — and other metaphors — with a view to properly attributing the root and recurring cause as technical neglect than technical debt. Without seeing technical neglect for what it is, we will continue to misattribute our problems to an effect rather than a cause.

Although the term "Cloud Native" in the context of Java has been repeated ad nauseam for years, the JVM as a platform has only recently entered a phase where everything truly aligns with how cloud-native architectures are designed. Let's trace the path Java has already taken in recent years and take a look at what lies ahead in the future. During this presentation, you will learn about projects such as Leyden, CRaC, and GraalVM, and how they can realistically influence the way applications are developed.

Target Audience: Cloud Java Architectural Leads
Prerequisites: Basic Knowledge od Java, Cloud Challenges Experience
Level: Advanced

Extended Abstract:
The goal of the presentation is to provide a comprehensive overview of the evolution of Java in relation to cloud-native architectures. The presentation aims to educate the audience about the progress Java has made in recent years and shed light on the future prospects of the language.
By discussing key projects like Leyden, CRaC, Microprofile and GraalVM, the presentation intends to demonstrate their relevance and potential impact on application development. Ultimately, the goal is to inspire the audience to embrace cloud-native principles in their Java projects and adapt their development practices accordingly.

In meiner Präsentation "API Thinking: Ein Paradigmenwechsel im digitalen Zeitalter" erörtere ich die zunehmende Bedeutung von APIs in der modernen Software-Entwicklung. Ich beleuchte, wie durch API Thinking Geschäftsmodelle agil und skalierbar gestaltet werden können, und zeige anhand praxisnaher Beispiele, wie die Integration von APIs zur Optimierung von Prozessen führt. Darüber hinaus diskutiere ich, wie durch API Thinking neue Geschäftschancen entstehen, und gebe Einblicke in mögliche Herausforderungen und Lösungsansätze.

Zielpublikum: Architekt:innen, Projektleiter:innen, Manager:innen, Entscheider:innen
Voraussetzungen: Keine
Schwierigkeitsgrad: Anfänger

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/daniel.kocot

Henning (OO to the core) and Mike (ferociously FP) agree on all the fundamentals of software architecture, but when it comes to designing models, they can't seem to find common ground.
OO and FP folks like to congratulate themselves on how well they go together - and how OO languages are accreting one feature after another from the FP world.
Henning and Mike will highlight how OO and FP approaches to design differ, and offer possible approaches to unifying both for mutual gain and insight.

Target Audience: Architects, Developers
Prerequisites: Experience in OO or FP
Level: Advanced

Extended Abstract:
Much work remains to unify these two worlds:

1. OO folks are weary of premature abstractions, whereas FP folks tend to abstract early.
2. While both camps prefer operation-rich models, the approaches to designing these operations are incompatible. Specifically, the BDD and TDD approaches favored by the OO folks are incompatible with the design recipes approach preferred by the functional camp.
3. Paradoxically, OO - which is supposed to be about objects - espouses BDD which is about functions, whereas FP has a rich tradition in data design, i.e. objects.
4. In OO, objects populate the domain, and they are encapsulated and thus isolated, whereas in FP this encapsulation is an emergent (or not emergent) phenomenon.
5. OO is inherently stateful, and FP is inherently stateless. This naturally leads to very different approaches to interface design, and more importantly, to the use of types.

Mehr Inhalte dieser Speaker? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/michael.sperber; https://www.sigs.de/autor/henning.schwentner

Das Sicherstellen der Softwarequalität in Microservice-Architekturen ist eine echte Herausforderung: Unsere bewährten Ansätze skalieren nicht mehr für komplexe Systeme mit zahlreichen Komponenten.
Wir präsentieren unseren Ansatz, der die Softwarequalität in komplexen Microservice-Architekturen beherrschbar macht. Wir sammeln und visualisieren verschiedene Metriken an zentraler Stelle, setzen auf Alerting bei Anomalien und unterstützen damit unsere Teams, frühzeitig zu erkennen, wohin wir unsere Aufmerksamkeit gezielt lenken müssen.

Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Mit einer geschickten Kombination von Open-Source-Tools haben wir unser Problem gelöst, den Überblick über zahlreiche verteilte Repos und Komponenten zu behalten.
Wir betrachten dabei verschiedene Metriken: sowohl die Codequalität, als auch fachliche und technische Schulden, die Einhaltung von Architekturvorgaben und viele weitere.

Most current UI libraries provide great user experience with a vast of components. But when it comes to heavy customization and non-standard scenarios, especially for E-Commerce, they become hard to manage, scale or even slow down performance. How to create a UI library that provides users the most possible freedom in customizing components, while keeping our performance and scalability to the fullest? How much customization freedom is enough? That's what my talk is about.

Target Audience: Developers, Architects, Project Leader
Prerequisites: JavaScript
Level: Advanced

Last year in open source, we saw the compliance threat shift from license violation to contract violation, we saw the rise of the bill of material as a purchasing requirement, and we saw the continued growth of source-available licenses. If you don't know what I'm talking about, you really need to attend, because your business is at risk if you don't understand these changes. In this annual talk, I will review the last year and speculate about what the future may bring.

Target Audience: Product Leaders, Engineering Leaders, Architects, Developers, Enthusiasts
Prerequisites: Basic understanding of open-source software development
Level: Advanced

During the talk, we'll dive into the historical context of Generative AI and examine their challenges. From legal compliance to fairness, transparency, security, and accountability, we'll discuss strategies for implementing Responsible AI principles.
It's important to note that the landscape for AI-driven products is still evolving, and there are no established best practices. The legislative framework surrounding these models remains uncertain, making it even more vital to engage in discussions that shape responsible AI practices.

Target Audience: Decision Makers, Developers, Managers, Everyone - AI-driven products require cross-functional teams
Prerequisites: None
Level: Basic

Extended Abstract:
Foundation models like GPT-4, BERT, or DALL-E 2 are remarkable in their versatility, trained on vast datasets using self-supervised learning. However, the adaptability of these models brings forth ethical, socio-technical, and legal questions that demand responsible development and deployment.
During the talk, we'll delve into the history of AI to better understand the evolution of generative models. We'll explore strategies for implementing Responsible AI principles, tackling issues such as legal compliance, fairness, transparency, security, accountability and their broader impact on society.
It's important to note that there are currently no established best practices for AI-driven products, and the legislative landscape surrounding them remains unclear. This underscores the significance of our discussion as we collectively navigate this emerging field.

Are Large Language Models (LLMs) sophisticated pattern matchers ('parrots') without understanding or potential prodigies that eventually surpass human intelligence? Drawing insights from both camps, we attempt to reconcile these perspectives, examines the current state of LLMs, their potential trajectories, and the profound impact these developments have on how we engineer software in the years to come.

Target Audience: Developers and Architects
Prerequisites: A basic understanding of Large Language Models is helpful but not required
Level: Basic

Extended Abstract:
Large Language Models (LLMs) are complex 'black box' systems. Their capabilities remain largely mysterious, only beginning to be understood through interaction and experimentation. While these models occasionally yield surprisingly accurate responses, they also exhibit shocking, elementary mistakes and limitations, creating more confusion than clarity.
When seeking expert insights, we find two diverging perspectives. On one side, we have thinkers like Noam Chomsky and AI experts such as Yann LeCun, who view LLMs as stochastic 'parrots' — sophisticated pattern matchers without true comprehension.
In contrast, AI pioneers like Geoffrey Hinton and Ilya Sutskever see LLMs as potential 'prodigies' — AI systems capable of eventually surpassing human intelligence and visionaries like Yuval Noah Harari that view LLMs as substantial societal threats.
Regardless of whether we see LLMs as 'parrots' or 'prodigies', they undeniable are catalyzing a paradigm shift in software engineering, broadening horizons, and pushing the boundaries of the field.
What are the theories underpinning these experts' views? Can their perspectives be reconciled, and what can we learn for the future of software engineering?
To answer these questions, we examine the current capabilities and developments of LLMs and explore their potential trajectories.

Artificial Intelligence (AI) has become integral to software development, automating complex tasks and shaping this field's future. However, it also comes with challenges. In this talk, we explore how AI impacts current software development and possibilities for the future. We'll delve into AI language models in programming, discussing pros, cons and challenges. This talk, tailored to both supporters and skeptics of AI in software development, doesn't shy away from discussing the ethical obligations tied to this technology.

Target Audience: Software Engineers, Architects and Project Leaders in an enterprise environment
Prerequisites: Basic Understanding of Software Development
Level: Advanced

Extended Abstract:
The integration of Artificial Intelligence (AI), especially AI language models, is fundamentally reshaping the landscape of software development. This transformative technology offers exciting possibilities, from enhancing developer productivity to simplifying complex tasks. However, it is crucial to acknowledge and address the inherent challenges that accompany these advancements.
In this session, we delve into AI's role in software development, emphasizing both the potential benefits and potential drawbacks of AI. We will also examine the ethical implications of this technology.
By the end of the session, attendees will have a comprehensive understanding of AI's role in software development, reinforced by practical demonstrations. Participants will gain insight and skills for their daily roles as well as strategies for adopting and applying AI within their software development context.
As AI continues to permeate software development, understanding its potential and preparing for its challenges has become vital. My session, directly tied to the conference theme of "Expanding Horizons", provides unique, practical insights to help attendees navigate an AI-integrated future. Join me in encouraging the responsible and effective use of this transformative technology.

Kubernetes ist omnipräsent. Entweder laufen die Anwendungen in Kubernetes oder sollen in Kubernetes laufen. Entwickler mögen sich jetzt denken "Aber was hat die Kubernetes-Infrastruktur mit mir als Entwickler zu tun?"
Dieser Vortrag gibt eine Kurzeinführung, was Kubernetes ist und aus welchen Komponenten es besteht. Beim Durchgehen der Komponenten und Konzepte steht die Sichtweise eines Entwicklers im Vordergrund. Am Ende nehmen die Zuhörer Good Practices anhand von Beispielen mit nach Hause.

Zielpublikum: Entwickler:innen, Architekt:innen
Voraussetzungen: Allgemeine Software-Entwicklungskenntnisse
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Kubernetes ist omnipräsent. Entweder laufen die Anwendungen in Kubernetes oder sollen in Kubernetes laufen. Entwickler mögen sich jetzt denken "Aber was hat die Kubernetes-Infrastruktur mit mir als Entwickler zu tun?"
Mit der Einführung von Kubernetes bekommen die Entwickler aber oft die Aufgabe, neben dem Anwendungscode jetzt auch noch Deployment-Skripte in Form von Kubernetes-Deskriptoren zu schreiben. Dafür brauchen sie ein Grundverständnis der Kubernetes-Komponenten.
Dieser Vortrag gibt eine Kurzeinführung, was Kubernetes ist und aus welchen Komponenten es besteht. Beim Durchgehen der Komponenten und Konzepte steht die Sichtweise eines Entwicklers im Vordergrund. Am Ende nehmen die Zuhörer Good Practices anhand von Beispielen mit nach Hause.

Warum reden Entwickler und Operator so oft aneinander vorbei?
Warum können sich viele Entwickler gar nicht vorstellen, wie die IT abseits ihrer JVM tickt?
Warum stoßen Entwickler auf Probleme, sobald es hardwarenaher wird?
Warum ist das Anbinden von Hardware für viele Entwickler ein Problem?
Warum versuchen viele Entwickler, alle Fehler mit dem Debugger in ihrer IDE zu finden?

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen
Voraussetzungen: Projekterfahrung als Entwickler hilfreich
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Das Phänomen, dass viele junge Entwickler keinerlei Erfahrungen mit der "Welt da draußen" haben, beobachte ich immer wieder. Wie kommt dies?
Die IT ist zu komplex geworden! Beim Einstieg in die praktische IT kommen diese Themen gar nicht vor. Der Grund, warum ältere Entwickler dieses Wissen haben, ist nur, dass sie früher geboren wurden. So war es üblich, seine Homecomputer oder PCs selbst zusammenzubauen. Nicht weil es schick war, sondern weil man es machen musste.
Viel Wissen wurde so quasi "nebenbei" angeeignet.
Schaut man auf die Maker-Szene, so erlebt dieses Wissen wieder ein Revieval. Schließlich ist jeder Maker mit seinem Raspberry Pi nicht nur Entwickler, sondern auch gleich Operator bzw. Hardwaredesigner.
Dieser Talk zeigt einige Aspekte, wie Entwickler dieses Wissen mit viel Spaß und Vorgehen aus der Makerszene für ihre tägliche Arbeit nutzen können.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/thomas.ronzon

High traffic during business hours, no traffic at night, weekends and vacations, multiple teams, and several staging environments - these characteristics of a typical enterprise application. Pay-as-you-go, "scale-to-zero" and managed services make serverless architectures appealing for enterprise applications.
On-premise, on the other hand, you get the maximum flexibility and full access to machines with less automation and so more plumbing.
I will compare both approaches with focus on architecture and answer your questions in real time.

Target Audience: Developers, Architects
Prerequisites: Basic Cloud and Java Knowledge
Level: Advanced

Die digitale Barrierefreiheit nimmt Fahrt auf und ist ein absolutes Trendthema. Eigentlich ist dazu alles schon gesagt worden, es muss nur noch realisiert werden. Es ist entscheidend, Barrierefreiheit systematisch in Arbeitsabläufe von Designern und Entwicklern zu integrieren. Drei Hauptfragen stehen im Fokus:

1. Warum wird Barrierefreiheit in Projekten oft nicht priorisiert?
2. Welche Bedürfnisse und Herausforderungen haben Designer & Entwickler?
3. Wie kann Barrierefreiheit in Entwicklungsprozesse integriert werden?

Zielpublikum: Designer:innen, Entwickler:innen, Projektleiter:innen, Manager:innen, Entscheider:innen
Voraussetzungen: Keine
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Unser Lösungsvorschlag:
Je weiter ein Projekt fortgeschritten ist, desto schwieriger wird es, Barrierefreiheit miteinzubeziehen. Das Problem vieler Ressourcen und Tools ist ihre retrospektive Natur: Sie beurteilen die Barrierefreiheit eines Produkts, wenn es bereits fertig ist. Zu diesem Zeitpunkt sind Änderungen oft zu aufwändig oder die Zeit zu knapp. Doch wie gewährleistet unser Ansatz, dass Barrierefreiheit in jede Prozessphase einfließt?

1. Handlungsorientierte Aufgaben bereitstellen: Designer und Entwickler benötigen umsetzbare Informationen. Oft sind Richtlinien und Standards zu abstrakt formuliert, um sie in Prozessen zu operationalisieren.
2. Klarheit über Verantwortlichkeiten schaffen: Jede Aufgabe wird einer konkreten Rolle zugewiesen. Barrierefreiheit ist die Verantwortung aller Teammitglieder, nicht nur von Entwicklern.
3. Aufzeigen von Aufgabenabhängigkeiten: Das fördert die Zusammenarbeit der Projektbeteiligten. Es wird aufgezeigt, welche Aufgaben voneinander abhängig sind.
4. „On-demand“ statt Informationsflut: Jede Aufgabe wird einer konkreten Projektphase zugeordnet. So stellen wir sicher, dass nur wesentliche Informationen der richtigen Person zum richtigen Zeitpunkt zur Verfügung stehen.

Können wir Agilität nutzen, um die UN Sustainable Development Goals (SDGs) zu erreichen? Welche ergänzenden inneren Fähigkeiten können uns dabei helfen?
In dieser Session stellen wir Ideen vor, wie wir zu den SDGs beitragen können: in der Produktentwicklung, mit unseren Teams und Organisationen, aber auch in unserem Privatleben. Wir werfen einen Blick auf die Inner Development Goals (IDGs) und betrachten, wie sie unsere agilen Kompetenzen zur Erreichung nachhaltiger Ziele erweitern können.

Zielpublikum: Alle, die zu einer nachhaltigen und regenerativen Form der Agilität beitragen wollen
Voraussetzungen: Keine
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Agilität wird im Rahmen unseres Wirtschaftssystems eingesetzt, um das Unternehmen am Laufen zu halten und möglichst wachsen zu lassen. Aber seien wir ehrlich: Genau dieses System ist die Ursache für die Klimakrise und andere damit verbundene Nachhaltigkeitsprobleme. Können wir Agilität auch nutzen, um die UN Sustainable Development Goals (SDGs) zu erreichen? Mit welchen kleinen Schritten können wir starten, um damit eine nachhaltige Wirkung zu erzielen? Brauchen wir dazu zusätzliche, innere Fähigkeiten, die bisher wenig Beachtung im agilen Kontext finden?
Unsere Session soll ein Bewusstsein für diese komplexen Herausforderungen schaffen – und für die Verantwortung, die damit einhergeht. Als Inspiration zeigen wir konkrete Beispiele von Agilist:innen, die sich bereits auf einen nachhaltigen Weg begeben haben. Wir werfen einen Blick auf die Inner Development Goals (IDGs) und betrachten, wie sie unsere agilen Kompetenzen zur Erreichung nachhaltiger Ziele erweitern können, zum Beispiel durch langfristige Orientierung und Fürsorge für andere.

Das Serverless-Paradigma existiert seit fast 10 Jahren. Und obwohl es für passende Szenarien extreme Vorteile mit sich bringen kann, trauen sich bisher nur wenige Cloud-Anwendungen, den Schritt Richtung Serverless zu gehen. Zu Recht?
Im Rahmen des Workshops wird ein komplexes Anwendungsszenario Schritt für Schritt aufgebaut und dabei in jedem Schritt ein Serverless-Pattern eingeführt und in seiner Motivation diskutiert. Darüber hinaus wird gezeigt, wie sich eine solche stark verteilte Anwendung sinnvoll testen und monitoren lässt.

Max. Teilnehmendenzahl: 30
Laptop (mit AWS-Account) wird benötigt. Ein einfacher Test-Account (https://aws.amazon.com/de/free/) reicht aus.

Im Workshop werden wir gemeinsam an einem Demo-Projekt arbeiten. Wer möchte kann gerne im Vorfeld schon einmal das Beispiel aus dem GIT Repository laden und den dortigen Anweisungen zur Installation der benötigten 3rd Party Libraries folgen. 

https://github.com/mobileLarson/serverless-workshop 

ACHTUNG: Das Demo-Projekt ist zwar in Java programmiert, aber auch Interessierte, die nicht aus der Java-Welt kommen, können problemlos an dem Workshop teilnehmen. Die dazu benötigten Deployables für die AWS Cloud liegen ebenfalls im Projekt. 

Bei Fragen im Vorfeld bitte einfach melden:lars.roewekamp(at)openknowledge.de 

Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: Keine
Schwierigkeitsgrad: Anfänger

Extended Abstract:
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-Patterns, 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 Workshop stellen - Aha-Effekte garantiert!

Fachliche Komponenten in Code auszudrücken ist und bleibt eine fundamentale Herausforderung in Softwareprojekten. Der Workshop zeigt, wie mithilfe von Spring Modulith Java-Applikationen strukturiert werden können und diese Struktur kontinuierlich validiert werden kann. Des Weiteren werden verschiedene Formen der Interaktion zwischen Anwendungsmodulen diskutiert, insbesondere die Kompromisse einzelner Varianten, und wie Module isoliert und in Zusammenarbeit getestet werden können.

Max. Teilnehmendenzahl: 30

Zielpublikum: Architekt:innen
Voraussetzungen: Java, Spring (Boot)
Schwierigkeitsgrad: Experte

Extended Abstract:
1 – Grundlagen

• Applikationsmodule und deren Design
• Architekturevidenter Code
• Module und Hexagonale-, Onion und Clean Architecture
• Modulstrukturverifikation
• Modulares Design

2 – Modulinteraktion

• Interaktionsvarianten und -muster
• Konsistenz
• Synchrone und asynchrone Interaktion
• Eventbasierte Interaktion
• Die Event Publication Registry

3 – Testen

• Grundlagen des modularen Integrationstestens
• Das PublishedEvents API
• Das Scenario API

4 – Observability & Dokumentation

• Entwicklerdokumentation aus Code extrahieren
• Dokumentation anpassen
• Observability von Applikationsmodulen
• IDE- und Deploymentplattformintegration

Seit vielen Jahren ist es möglich, nebenläufig (mit mehreren Threads) zu programmieren. In Bezug auf wichtige konzeptionelle Details von Nebenläufigkeit gibt es bei Programmierern allerdings erhebliche Lücken.
Wer kennt "Out-of-order Updates" und "Spurious Wakeups"?
Was unterscheidet Prozess-Scheduling von Thread-Scheduling?
Am Beispiel von C++ gibt dieses Tutorial einen Überblick über die wichtigsten konzeptionellen Aspekte von Multi-Threading und Concurrency und zeigt, wie man in C++ mit ihnen umgeht.

Zielpublikum: Entwickler:innen
Voraussetzungen: Grundkenntnisse von Threads
Schwierigkeitsgrad: Fortgeschritten