Speaker

Peter Butzhammer

Peter Butzhammer

Dotnet enthusiast and cofounder of B3

Dotnet Enthusiast und Mitgründer von B3

Regensburg, Germany

Actions

Peter Butzhammer has been working as a software developer for 20 years. He specializes in software development and architecture in the industrial environment. He writes code for data acquisition and analysis, process control and communication in distributed systems. He is one of the founders of B3 GmbH and thrives on projects that demand meticulous attention to technical detail and uncompromising quality.

Peter is organizer of the Dotnet User Group in Regensburg.

Peter Butzhammer arbeitet seit 20 Jahren als Softwareentwickler. Seine Schwerpunkte sind Softwareentwicklung und -architektur im Industrieumfeld und in der Veranstaltungstechnik. Er schreibt Code für Datenerfassung und -Analyse, Prozesssteuerung und Kommunikation in verteilten Systemen. Er ist Mitgründer der B3 GmbH und blüht auf bei Projekten, die Liebe zu technischen Details und hohe Qualität erfordern.

Peter organisiert die Dotnet User Group Regensburg mit.

Area of Expertise

  • Information & Communications Technology

Topics

  • dotNet
  • Software Deveopment
  • Data analysis

Sessions

Homemade Asynchronous Programming – Building your own Task en de

In the .NET world, async and await are fundamental, and Tasks are at the core of this. However, the Task type is often seen as magical, with many developers unaware of the underlying mechanics. In this talk, we will step back and build our own Task and ThreadPool from scratch, examining how they interact with each other to enable imperative asynchronous programming.

By deconstructing these foundational components, we’ll explore how asynchronous code really works under the hood. You'll come away with a deeper, more practical understanding of Task-based asynchronous programming — which could come in handy for your next debugging session.

This is a live coding session where I create a Task implementation from scratch while explaining details.

The talk is targeted for intermediate level developers (200), but I think even most expert level developers have some things to learn.

I held this talk at ADC2025 in Regensburg and at the Dotnet Day Franken 2025, where it received the Best Session Award.

If I submitted multiple talks and you are not sure which one to choose: This is currently my favourite talk.

Selbstgemachte asynchrone Programmierung – Wir bauen unseren eigenen Task en de

async und await sind in der .NET-Welt allgegenwärtig – und Tasks spielen dabei eine zentrale Rolle. Doch oft bleibt unklar, was genau ein Task bewirkt und wie sich async und await im Detail verhalten. In diesem Vortrag werden wir gemeinsam eine einfache Implementierung eines Tasks und eines TaskPools entwickeln und deren Zusammenspiel im Detail untersuchen.

Ziel des Vortrags ist es, ein tieferes Verständnis für die Funktionsweise von async und await zu vermitteln sowie grundlegende Konzepte der asynchronen Programmierung zu erklären.

Dieser Vortrag ist eine Live-Coding-Session. Ich werde einen vereinfachten Task implementieren und dabei wichtige Konzepte erklären.

Der Vortrag ist für Intermediate (200) Softwareentwickler geeignet, aber vermutlich auch für viele Experten interessant.

Ich habe den Vortrag bereits bei der ADC 2025 in Regensburg und beim Dotnet Day Franken 2025 gehalten. Beim Dotnet Day wurde er zur "Besten Session" gewählt.

Dieser Vortrag ist im Moment mein Lieblingsvortrag.

Inter-Process-Communication – Kommunikationsmuster verstehen und bewusst einsetzen de en

REST, Kafka, gRPC, NATS, … – die Liste an Technologien für Inter-Process-Communication ist lang. Doch wenn wir einen Schritt zurücktreten und den Informationsfluss betrachten, lassen sich nur zwei grundlegende Muster erkennen: Request-Reply und Fire-and-Forget.

In diesem Vortrag beleuchten wir die Unterschiede dieser beiden Ansätze und zeigen, welche Auswirkungen sie auf Fehlerbehandlung, Versionierung und Skalierbarkeit haben. Dabei wird deutlich, dass der logische Kommunikationsmodus weitgehend unabhängig von der eingesetzten Technologie ist. Ziel ist es, Entwickler für die impliziten Designentscheidungen hinter Inter-Process-Communication zu sensibilisieren – und ihnen konkrete Denkanstöße für robuste, zukunftsfähige Systeme mitzugeben.

Inter-Process Communication – Applying Communication Patterns Consciously de en

REST, Kafka, gRPC, NATS… The list of technologies for inter-process communication is long. But when we take a step back and look at how information flows, we find just two fundamental patterns: Request-Reply and Fire-and-Forget.

This talk explores the differences between these two approaches and highlights their impact on error handling, versioning, and scalability. We’ll see that the logical communication mode is largely independent of the technology in use.

The goal is to raise awareness among developers about the implicit design decisions behind inter-process communication – and to offer concrete insights for building robust, future-proof systems.

I've seen developers choosing between Request-Reply and Fire-and-Forget without considering that this choice has implications on error handling, versioning, retry strategies and so on. Sometimes this leads to unnecessarily complicated designs during the project, and I want to bring this to the developers attention.

This is a new talk, intended for intermediate level software developers and architects.

Sicherheitslücken – und was Entwickler daraus lernen sollten de en

“Sicherheitsprobleme? Doch nicht bei uns! Wir haben Prozesse, Tools und Best Practices – was soll da schon passieren?“ Diese Haltung ist weit verbreitet, doch die Realität sieht oft anders aus. In diesem Vortrag werfen wir einen Blick auf echte Sicherheitsvorfälle und analysieren, wie Schwachstellen entstehen und von Angreifern ausgenutzt werden.

Anhand konkreter Fälle zeigen wir, dass viele Sicherheitslücken nicht auf klassische Bugs zurückzuführen sind, sondern auf Designentscheidungen, Architekturfehler oder unbedachte Annahmen im Entwicklungsprozess. Entwickler und Architekten spielen dabei eine zentrale Rolle – oft ohne es zu merken.

Mit diesem Vortrag schaffen wir ein Bewusstsein dafür, wie Sicherheitslücken im Entwicklungsprozess entstehen und was Entwickler dagegen tun können – gerade dort, wo Prozesse und Tools an ihre Grenzen stoßen.

Security Incidents – What developers can learn from them de en

Security issues? This wouldn’t happen to us. We have all those processes and tools in place, after all. Well, ok – there might be the occasional bug, but how should that be exploited.

In this talk, we’ll examine real-world security incidents, breaking down how vulnerabilities emerge and how attackers exploit them. Through case studies and analysis, we will uncover classes of common security flaws and discuss the practical steps developers can take to prevent these issues – and these are not always “bugs”.

We will see that it is the developers and architects that create security issues and some of them are very hard to foresee and avoid. The goal is to create awareness for the mechanisms of exploits. That might help us to avoid some pitfalls – even ones that are hard to avoid with our processes and tools.

This talk is a slide presentation about the background of a handfull of security incidents that occured over the last years with special focus on the role of developers, rather than the development process.

I held this talk at the Digital Crafts Day 2025 in Weiden.

Peter Butzhammer

Dotnet enthusiast and cofounder of B3

Regensburg, Germany

Actions

Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.

Jump to top