Here is the exact schedule for the day.
What if orchestration could be written as a pure function? The somewhat steep learning curve of modern workflow engines, either in terms of programming model, deployment aspects or testability can put a damper on writing them and obfuscate the very process they are trying to automate. In this talk you’ll learn about a simple, readable and testable way to write them, with full retention of the decisions made over time, using a practical example as our guide. We’ll touch on simple patterns to help one deal with failure, time, and continuation.
Cloud native technologies have changed the way we build and run software. Kubernetes, containers, cloud services, and modern delivery practices give teams incredible possibilities, but let’s be honest: they also introduce a new level of complexity.
As organizations adopt more and more cloud native technologies, new challenges appear. How do we give developers the freedom to move fast while still keeping things secure, reliable, and manageable? How do we avoid every team having to reinvent the same solutions over and over again?
This is where platform engineering comes in.
In this talk, we’ll explore why organizations are moving towards internal developer platforms, how platform teams can create reusable capabilities and golden paths, and what a modern cloud native platform looks like in practice.
The goal is not to build another abstraction layer, but to create a foundation that helps teams focus on what really matters: delivering valuable software faster and with more confidence.
With the rise of LLMs, it’s now possible to generate features and even entire software products in just a short amount of time. What once took weeks or months can now be done in hours or days. Yet, despite this acceleration in code generation, the outcomes delivered by software teams remain quite low.
Decades ago, we’ve already learned that individual productivity often conflicts with team productivity. Writing more code faster doesn’t automatically translate into usable, high-quality software that delivers real value to users.
“Going faster” is not going to lead us to better outcomes. What does help high-performing teams are strategic constraints.
In the early 2000’s, Extreme Programming (XP) introduced a number of core practices that are fundamental to building high-quality software: small releases, rapid feedback, continuous everything (design, testing, code reviews, refactoring, integration, etc.) that contribute to a safe environment where software teams can thrive.
In an era where LLMs accelerate output, the core practices as defined by XP remain critical for effective software teams.
When agents lie, when communication is unreliable, when no one has a complete picture, what can we actually agree on? Byzantine consensus says: only with enough nodes. Hofstadter says: it depends on whether the other party is rational or a sociopath. The green-eyed islanders say: sometimes a tiny piece of common knowledge is the key.
This talk connects logical puzzles to distributed system design, explaining how software systems have to make decisions with incomplete information. We’ll explore how knowledge hierarchy shapes protocols, how protocols become a recipe for what agents can come to know, and how theoretical limits constrain your database replication, blockchain validation, and microservice coordination. And what to do about that.
After leaving this talk you will probably not acquire any new skills to feed into your coding agent, but you might appreciate the inherent complexity of distributed systems more, including humans and machines.
No mathematics degree required. Just common sense.
Content Security Policy, or CSP, has been around for more than a decade. We’re all familiar with it in one way or another: struggling to implement it, being called out for missing it, or debating whether ‘unsafe-inline’ is really unsafe. In a nutshell, CSP is messy and complicated. But it doesn’t have to be. In this session, you will learn why most CSP policies are ineffective, how to configure CSP correctly, and how to build a backwards compatible policy.
Building an event-driven system is anything but trivial. However, once you make it past the sea of pub-sub vs. command-response debates and the service boundaries conundrum, you’ll soon face the inevitable: change. The conversations that follow sound all too familiar… “Who’s subscribed to this message?” “Do other services depend on this field in the payload?” “Why on earth is that thing in the payload?” “That service should never rely on this data!” And, of course, the obvious “Can’t we -just- remove this?”
But are those the right questions to ask? As software developers, we aim to be agents of change, not chaos. To achieve this, we need to understand the impact of tweaking a message contract without breaking half of the system or forcing other teams beyond their deadlines. We should prioritize techniques that ensure compatibility while also considering how long that compatibility needs to be sustained. Oh, and let’s not forget that we’re supposed to solve this problem with zero downtime, as our users are spread across every time zone. In this session, we’ll discuss practical techniques and tooling that can enable the evolution of your event-driven system so that, next time a stakeholder approaches with a change request, your heart doesn’t sink to the floor.