Presentations
"Exactly-Once Delivery" i inne kłamstwa Event-Driven Architecture
Jak głosi branżowy żart: "Są tylko dwa trudne problemy w systemach rozproszonych:
2. Dostarczenie dokładnie raz. 1. Gwarancja kolejności. 2. Dostarczenie dokładnie raz".
Na szczęście jako branża wypracowaliśmy sprawdzone sposoby radzenia sobie z tymi wyzwaniami. W tej prezentacji skupię się na tym, co zrobić, żeby nie paść ofiarą tego dowcipu na produkcji.
After 25 Years of Test-First, I Started Pairing with an AI
AI pair programming gets a lot of hype. Does it work?
I started pairing with Claude on Test-Driven Development and Behavior-Driven Development in mid January 2026. I did not know what would happen. The plan was to drop it if Claude slowed me down.
In practice, Claude can join a TDD or BDD cycle. I have used it to draft specifications, write failing tests, make them pass, and refactor afterwards. The output is good enough that I keep coming back to it.
Today I can tell you that I ship faster and that I trust more of my tests. That has less to do with Claude than you might think. A coding assistant amplifies whatever habits you bring. Bad habits get worse. Good habits compound. Mine were already test-first.
I will show examples from real production code. You will see where Claude pulls its weight and where it does not. By the end you should know what AI pairing is worth in test-first work, and what habits you need before you start.
AI-Assisted SDLC – AI jako partner w całym procesie wytwarzania oprogramowania
Większość zespołów używa AI do generowania kodu. To dobry start – ale tylko ułamek możliwości. Co jeśli AI mógłby uczestniczyć w całym cyklu: rozumieć kontekst projektu, wspierać analizę i planowanie, pisać testy, dbać o dokumentację i zapewnić stosowanie właściwych konwencji i dobrych praktyk używanych w projekcie? Zobacz jak może wyglądać proces, w którym AI przestaje być narzędziem do pojedynczych zadań, a staje się częścią SDLC.
Archetyp reguł wzbogacony o algebrę logiki rozmytej
Wiele razy podczas projektów doradczych musiałem zastosować archetyp modelu biz. reguł. Niestety opracowania z literatury były niewystarczające. Ale naginając rzeczywistość lub poświęcając wydajność działały wciąż lepiej niż ordynarne kaskady ifów ponieważ pozwalały dynamicznie sterować regułami. Podczas prezentacji pokażę ci mocno zmodyfikowaną implementację archetypu reguł, która pozwala odseparować strukturę reguł od sposobu przetwarzania reguł. Zastosujemy podejście, w którym stworzymy własne algebry, pozwalające na wyjścia poza logikę boolowską.
Be more productive with IntelliJ IDEA
IntelliJ IDEA is designed to help developers stay in the flow while working. It has a powerful editor, refactorings, navigation, and all kinds of smart features to help you write and read code. At the same time, it is jam packed with tools professional developers need, like Maven, Gradle, Spring, Git, Databases, Test tools and more. And did I mention a fantastic debugger? In this talk, you will see how IntelliJ IDEA supports your workflow without having to leave the IDE, and learn how you can be a happier and more productive developer.
Bytecode Without the Black Magic: Java’s Class-File API in Practice
Bytecode manipulation has long been seen as a dark art reserved for compiler writers, framework authors and JVM tooling experts. But with Java’s Class-File API working with .class files is becoming more approachable, standardized and expressive. In this talk we’ll explore how the Class-File API lets developers read, generate and transform Java class files using a modern JDK-supported model. We’ll start with a quick look at what class files contain and why bytecode matters in real-world Java applications, from frameworks and agents to build tools and static analysis. Then we’ll move into practical examples: inspecting compiled classes, exploring methods and bytecode instructions, generating a simple class, and applying basic transformations. Along the way, we’ll discuss where this API fits compared to tools like ASM or Byte Buddy, what problems it can solve and what limitations developers should keep in mind. By the end of the session, attendees will have a clearer mental model of Java bytecode and a practical understanding of how to use the Class-File API without treating bytecode as black magic.
Dancing with Uncertainty: Challenges of Distributed Systems
Systemy rozproszone są wszędzie, a mimo to wyzwania, które ze sobą niosą, są wciąż niedoceniane. W tej prezentacji przyjrzymy się fundamentalnym problemom, które sprawiają, że przetwarzanie rozproszone jest naprawdę trudne.
Na start przypomnimy (i rozszerzymy) sobie CAP, zastanowimy się, dlaczego dostarczenie wiadomości dokładnie jeden raz jest takie trudne, oraz jak unikać pułapek dual-writes.
Na koniec zajmiemy się samym czasem: dlaczego zegary kłamią, oraz do czego służą zegary logiczne.
Engineering Resilience for the Hardware Your Career Runs On
Every resilience pattern you ship — redundancy, feedback loops, graceful degradation, anti-fragility — was borrowed from the most battle-tested system in existence: the human body. We're brilliant at applying these patterns to machines and apply none of them to ourselves. We fight for a maintenance budget at work and allocate zero for the one system we can never rewrite, migrate, or redeploy.
This talk runs the borrowing back the other way — and I don't run it alone. My AI sidekick, Loyal, shares the stage — and doesn't just nod along. Together we'll trace how sitting quietly remodels you around your chair, why the developer identity fossilized around a constraint that no longer exists, and why nobody is watching the slow stretch where a resilient body becomes a fragile one. Then we build the maintenance system for it — identity, environment, a sustainable start, feedback, accountability, recovery — with the same discipline you give production. Fair warning: you won't spend it sitting still, and you'll leave with a contract you wrote yourself for the maker, not just the machine.
Fast && pain-free, Java and native code,
Java and native code (think C/C++) interop has always* been fun**
We will look at FFM***, the modern way to for programs to interact and work on shared data. How to call C from java - without JNI, and associated dark magic. We will also call java from C without touching javah****, header generation, magic compiler flags and a myriad of issues.
Once you can call C… Lua? Rust? Python? AI inference? Sky is the limit. We'll prove it with examples. It will be fun!** :-)
FFI is great, FFI is the future! Ah, and did I mention it's also faster than JNI?
- subjective ** for some specific values of fun *** Project Panama, you're right! **** technically, javac -h now, but the memory remains
From skeptics to power users: how to adopt AI Across Engineering Teams in companies
Everyone talks about AI adoption. Fewer talk about what happens when you actually do it, the resistance, the dead ends, the quiet wins, and the cultural shifts that nobody put in the roadmap. This talk draws on firsthand experience rolling out AI tools across multiple engineering teams in an organisation. We'll skip the vendor demos and go straight to the messy middle: how habits change (or don't), how you get skeptical engineers on board, what leadership gets wrong, and where AI genuinely earned its place in daily engineering work. You'll leave with patterns you can bring back to your org on Monday.
From Theory to Practice: Real-World Lessons in Post-Quantum Cryptography Migration
Quantum computing is no longer a distant concept—it’s an imminent challenge to today’s cryptographic standards. The shift to Post-Quantum Cryptography (PQC) is not optional; it’s inevitable. Yet, the practical steps for adapting existing applications to PQC, and the critical considerations for ensuring compatibility, remain largely unclear. This session goes beyond theory. We’ll start with a concise overview of PQC fundamentals, then dive into real-world migration experiences—what worked, what didn’t, and why. Attendees will gain actionable best practices drawn from hands-on projects, offering guidance not only for those planning future migrations but also for developers designing new applications today. If you’ve ever wondered, “Where do I start?” or “What pitfalls should I avoid?”, this talk will provide the answers—grounded in real-world experience and focused on practical success.
By the end of this session, participants will be able to:
- Understand the fundamentals of Post-Quantum Cryptography (PQC) and why early adoption is critical in the face of quantum computing threats.
- Identify key challenges and pitfalls encountered during real-world PQC migration projects.
- Apply proven best practices for adapting existing applications to PQC while maintaining security and performance.
- Develop a practical roadmap for integrating PQC into both legacy systems and new application designs.
How being a dungeon master helped be to become a better architect
About 20 years ago, my parents were convinced I was wasting time on "silly stuff" like "playing with little figures and casting fireballs". They had no idea those RPG sessions were teaching me something far more valuable than just how to play a game.
Fast-forward two decades: when I run modelling workshops today, I’m using the exact same skills I built while leading RPG campaigns all those years ago.
In this talk, I’ll show how facilitation patterns used by dungeon masters can help you guide teams, uncover insights and design better architecture.
Jak marnujemy czas, budując API — moment, w którym DDD zaczyna mieć znaczenie
Czy DDD to tylko teoria?
Pracując „w okopach”, większość zespołów nie zaczyna od Bounded Contextów ani Context Map. Zaczyna od ticketów, kryteriów akceptacji i… potrzeby dowiezienia API.
Z czasem API rosną. Pojawiają się nowi konsumenci. Współdzielone zasoby. I nagle zespoły zaczynają mierzyć się z pytaniami takimi jak:
Kto jest właścicielem tego API?
Czy możemy zmienić ten kontrakt?
Dlaczego każda drobna decyzja wymaga zaangażowania architekta?
W tej prezentacji opowiem historię tego, jak zespoły naturalnie rozwijają API w chaosie — i dlaczego nie jest to porażka.
Pokażę moment, w którym Domain-Driven Design przestaje być teorią, a zaczyna być praktycznym narzędziem podejmowania decyzji: pomagającym rozumieć relacje między bounded contextami, odpowiedzialność i autonomię zespołów — bez „robienia pełnego DDD”.
To nie jest tutorial.
To prowokacyjne spojrzenie na to, jak strategiczne DDD może wspierać ewolucyjny design API i autonomię zespołów w dużych systemach.
Keeping data private in real-time pipelines
We all love real-time data — clicks, payments, rides, messages — but most of it comes with a catch: it contains personal information we’re not supposed to leak, such as names, emails, locations, or even small clues that can identify someone. The challenge: how do we keep streaming data useful and safe at the same time?
In this talk, we’ll explore practical ways to protect privacy in streaming systems using Apache Kafka, Apache Flink, and Apache Iceberg. We’ll cover:
- simple tricks like masking and tokenizing PII;
- why “anonymous” data often isn’t anonymous (the re-identification problem);
- techniques like bucketing, k-anonymity, and adding noise;
- how to balance privacy with data utility (too much hiding makes data useless).
Along the way, we’ll look at real-world stories: from public data leaks to surprising deanonymization attacks, and show live demos of pipelines that anonymize data before it’s written to storage. If you’ve ever wondered how to build privacy-aware pipelines, this talk will give you practical patterns you can use right away.
Kiedy Programista Java spotyka C
Java od lat żyje z łatką języka, który absolutnie nie nadaje się do pisania bardzo wydajnych systemów. Jako programista nie masz kontroli nad tym, kiedy GC, JIT czy JNI postanowią zniszczyć Twoje sny o niskim latency. A mimo to ktoś wciąż próbuje budować na tym bazy danych i systemy "bliżej metalu". W tej prezentacji pokażę, że wraz z Java 22 dostaliśmy potężne narzędzie: Foreign Memory & Foreign Function API. Dzięki tym API praca z off-heap staje się bezpieczna (oczywiście w pewnych granicach — ale to Ty je określasz), co pozwala pozbyć się pauz GC. A Foreign Functions umożliwiają bezpieczne wywoływanie kodu w C z poziomu Javy, bez potrzeby używania javah, kompilatorów C i całęgo zestawu zaklęć potrzebnych, by JNI łaskawie zadziałało. Zobaczycie, jak te nowe API przybliżają JVM do świata bare-metal — i dlaczego mogą stać się przyszłością systemów data-intensive, baz danych, a nawet narzędzi ML/AI. A wszystko oczywiście doprawione niedziałającymi przykładami i benchmarkami przygotowanymi pięć minut przed prezentacją.
Java od lat żyje z łatką języka, który absolutnie nie nadaje się do pisania bardzo wydajnych systemów. Jako programista nie masz kontroli nad tym, kiedy GC, JIT czy JNI postanowią zniszczyć Twoje sny o niskim latency. A mimo to ktoś wciąż próbuje budować na tym bazy danych i systemy "bliżej metalu". W tej prezentacji pokażę, że wraz z Java 22 dostaliśmy potężne narzędzie: Foreign Memory & Foreign Function API. Dzięki tym API praca z off-heap staje się bezpieczna (oczywiście w pewnych granicach — ale to Ty je określasz), co pozwala pozbyć się pauz GC. A Foreign Functions umożliwiają bezpieczne wywoływanie kodu w C z poziomu Javy, bez potrzeby używania javah, kompilatorów C i całęgo zestawu zaklęć potrzebnych, by JNI łaskawie zadziałało. Zobaczycie, jak te nowe API przybliżają JVM do świata bare-metal — i dlaczego mogą stać się przyszłością systemów data-intensive, baz danych, a nawet narzędzi ML/AI. A wszystko oczywiście doprawione niedziałającymi przykładami i benchmarkami przygotowanymi pięć minut przed prezentacją.
Lock, Stock, and Two Smoking Pods: Locking in Distributed Spring Applications
Three pods. One scheduled job. One database. What could go wrong? Clean logs, monitoring green - and yet customers receive duplicate emails, records silently disappear, and that critical nightly cleanup job quietly failed while your storage filled up overnight. These aren't exotic edge cases. Distributed systems and scalability don't come without cost. More instances mean more potential for race conditions, deadlocks, and coordination failures that only surface under real load - long after the code looked fine in review.
In this talk you'll learn how to lock without being locked out - recognizing, diagnosing, and preventing locking failures in your Java application with available tools and techniques.
Keywords: DB, Java, Spring, Locking, ShedLock, Deadlocks, Distributed Systems, Scheduling
Maps and territories
When you planned how to get to the conference venue, you probably used digital maps and a routing app. They are ubiquitous now, but how do they work under the hood?
We’ll explore the fascinating world of maps and location services. We’ll start with the data - the format, the sources, then explore some of the most interesting/cool algorithms and show how they are used in many more or less known tools and applications.
Why? Not only because maps are fascinating, but also because all of the developers can learn a lot about the power of open data, efficient data structures, and composable tools!
Maszynka do Mielenia Złudzeń: Cztery Kręgi Testowego Piekła dla Kodu Współbieżnego w Javie
Zielone testy jednostkowe to za mało, żeby ufać kodowi współbieżnemu — a mimo to większość zespołów na nich poprzestaje. Ta prezentacja pokazuje, dlaczego to złudzenie, i jak je systematycznie rozbić.
Na przykładzie cyklicznego bufora Lamporta — czterech implementacji tego samego interfejsu, z których dwie są celowo złamane i wszystkie cztery przechodzą CI — przechodzimy przez cztery warstwy testowego rygoru: JUnit (weryfikacja logiki algorytmu), Fray (systematyczna eksploracja wszystkich przeplotów wątków), jcstress (weryfikacja poprawności względem Java Memory Model na prawdziwym hardware'ze) i JMH (koszt poprawności w ops/s).
Każda warstwa łapie inne demony. Fray konstruuje konkretny splot prowadzący do NPE w "zoptymalizowanej" szybkiej ścieżce — i pozwala go odtworzyć deterministycznie z debuggerem. jcstress wykrywa ~35 000 wykonań z niewidocznym zapisem producenta spośród 600 milionów prób — błąd widoczności pamięci, którego Fray strukturalnie nie może zobaczyć. JMH zamyka pętlę: lock-free volatile bije lock-based 3× przepustowością, ale tylko wtedy, gdy implementacja jest wcześniej udowodniona jako poprawna.
Słuchacze wychodzą z konkretną mapą decyzyjną: które narzędzie zadaje jakie pytanie i czego bez pozostałych nie widzi. Prezentacja zawiera działające demo repozytorium z kompletem testów.
Obiekty bez tożsamości: Value Object w JEP 401
Od samego początku swojego istnienia, Java traktowała każdy obiekt jako byt posiadający tożsamość, nawet jeśli z punktu widzenia modelu domenowego był on jedynie wartością. Project Valhalla i JEP 401 wprowadzają klasy wartościowe - obiekty pozbawione tożsamości, dzięki czemu JVM może je skalaryzować i spłaszczać w polach oraz tablicach.
Podczas prezentacji przyjrzymy się idei stojącej za klasami wartościowymi, ich powiązaniu z obiektami wartości (Value Objects) w DDD oraz temu, jak mogą one zmienić sposób projektowania niezmiennych modeli domenowych w Javie. Omówimy, dlaczego warto rozdzielić pojęcia „wartości” i „tożsamości”, gdzie klasy wartościowe znajdują zastosowanie w nowoczesnych aplikacjach Java oraz jakie praktyczne korzyści i ograniczenia wiążą się z ich wykorzystaniem.
Od metryk do przyczyny: diagnostyka JVM w świecie observability
Metryki wyglądają poprawnie, alerty nie wskazują nic krytycznego, a mimo to użytkownicy zgłaszają timeout'y i spadki wydajności.
W tej prelekcji pokażę, jak w praktyce diagnozować problemy JVM na środowiskach produkcyjnych, gdy nie ma czasu na restart aplikacji ani eksperymenty na żywym systemie. Zamiast skupiać się na konkretnych narzędziach, przejdziemy przez sposób myślenia i kolejne decyzje prowadzące od pierwszego objawu do rzeczywistej przyczyny problemu. Na przykładach z realnych incydentów omówię, jak interpretować sygnały płynące z metryk, zachowania wątków i presji pamięci oraz jak łączyć je w spójny obraz działania systemu.
Celem prelekcji jest pokazanie, jak traktować observability jako proces diagnostyczny wspierający podejmowanie decyzji w systemach produkcyjnych, a nie jako kolejny zestaw dashboardów.
Panel Dyskusyjny
Panel dyskusyjny z udziałem ekspertów z branży IT, którzy podzielą się swoimi spostrzeżeniami na temat aktualnych trendów, wyzwań i przyszłości technologii.
Profiling Hibernate-a - czyli "learning Hibernate the hard way"
Podstawowe problemy związane z wydajnością Hibernate-a, takie jak problem "n+1" były już wałkowane wielokrotnie na konferencjach. Takimi rzeczami nie będziemy się zajmować.
Na prelekcji pokażę jak za pomocą profilingu i analizy heap dump-ów można zrozumieć co dzieje się w "bebechach" Hibernate-a. Omówię co z owymi problemami można zrobić w istniejącej aplikacji, oraz jak projektować nowe aplikacje, żeby takich problemów unikać.
Rate Limiting: making everyone equally unhappy!
Everyone knows about "429 Too Many Requests" HTTP status, but few teams stop there. This session dives into the realities of protecting modern APIs: choosing the right rate-limiting algorithms, handling traffic spikes, coordinating limits across regions, and preventing cascading failures with circuit breakers. We'll discuss quotas, burst handling, bucket refill strategies, and the operational challenges of distributed deployments. We'll also touch on API evolution and sunset policies, because sometimes the best way to manage traffic is to retire what no longer belongs in production. By the end, you'll know how to build systems that stay available when demand exceeds expectations.
Resilience w erze AI: jak zostać niezastąpionym developerem, którego nie zastąpi model
Rok 2025 i 2026 przyniosły dwie sprzeczne narracje. Pierwsza: AI zastąpi programistów, czas się przekwalifikować. Druga: nic się nie zmienia, to kolejny hype. Dane mówią coś trzeciego i mniej wygodnego. Część zadań rzeczywiście przejmują modele, część developerów wypala się od c nadzorowania AI, a firmy zaczynają mierzyć wpływ agentów na produktywność i wyciągać wnioski kadrowe. Pojawia się też efekt, o którym mało kto mówi: nadmierne poleganie na asystencie obniża samodzielność, powoduje deskilling i utrudnia rozwój.
Przedstawie kompetencje developera jak i strategie myślenia na trzy koszyki: te, które AI przejmuje już teraz, te, które wzmacnia, i te, których wartość rośnie właśnie dlatego, że AI jest powszechne. Pokażę, gdzie kończy się rola pisania kodu, a zaczyna rola projektowania systemów, weryfikacji i decyzji, których nie da się oddelegować modelowi.
Co wyniesiesz?
Sposób myślenia o własnej karierze jako o portfelu kompetencji z różnym profilem ryzyka. Konkretne kryteria, w co inwestować czas w najbliższych dwóch latach, a co odpuścić. Świadomość pułapek, w tym wypalenia od nadzorowania AI i utraty samodzielności, oraz sposoby ich uniknięcia.
Dla kogo?
Mid i senior, którzy używają AI na co dzień i zadają sobie pytanie, gdzie będzie ich wartość za kilka lat. Bez znajomości machine learningu, to perspektywa rynku pracy i kompetencji, nie budowy modeli.
Structured Concurrency – odczarujmy wielowątkowość!
Programowanie wielowątkowe nigdy nie jest łatwe dla początkujących. Szczególnie częstym problemem, z jakim możemy się spotkać, jest wyciek wątków i utrata kontroli nad ewentualnymi błędami, które się w nich pojawiają. Strukturyzowana współbieżność wprowadzona jako funkcja zapowiedzi w JDK 21 i przemodelowana w JDK 25 może pomóc nam uporać się z obydwoma powyższymi wyzwaniami. Podczas prezentacji poznamy ogólną koncepcję structured concurrency, poznamy różne polityki obsługi błędów i postaramy się wykorzystać zdobytą wiedzę w rozwiązaniu rzeczywistego problemu biznesowego.
System design na rekrutacji: jak myśleć szeroko
Masz sekundę. Dosłownie. System musi odpowiedzieć użytkownikowi, integrując się z trzema zewnętrznymi serwisami. Klasyczne zadanie rekrutacyjne, które zdradza poziom kandydata. Kto widzi tylko oczywiste wyjście, a kto zaczyna zadawać pytania i otwierać nowe warstwy problemu?
W tej prezentacji wezmę na tapet ten przykład i pokażę, jak ten sam problem może wyglądać oczami juniora, mida i seniora. Zobaczymy, co się zmienia, gdy dołożymy kolejne ograniczenia: brak dostępności jednego z serwisów czy limit requestów. Wyjdziesz z konkretnym wzorcem myślenia, który możesz zastosować już na następnej rekrutacji.
Tag. Publish. Hope.
Think about how carefully we ship applications. Staged rollouts, canary analysis, automated rollback, observability at every step. Now think about how we ship libraries. Tag a version. Publish. Hope.
At Netflix, this blind spot caught up with us across thousands of libraries and 5,000+ repositories. Upgrades broke services overnight because nobody could see the blast radius beforehand. Security patches took days because we couldn't answer "which libraries actually matter." Teams deprecated libraries with no way to tell consumers "hey, start planning your move." So we set out to build a paved road for libraries.
Once we started digging, things got uncomfortable. Many libraries we considered "actively maintained" hadn't had a real human change in over a year, just bots keeping the lights on. We kicked off a major migration and couldn't tell which repos would be affected for over half the fleet. Basic questions, no answers. But the hardest part wasn't technical. It was cultural: how do you bring lifecycle governance to an org that values speed and autonomy without becoming the team everyone routes around?
This talk is about what we're learning as we build that paved road. It's an ongoing effort, not a finished product. I'll walk through the five things we think it needs: stability signals, compatibility validation, impact visibility, lifecycle communication, and proportional escalation. I'll share why we bet on tools that inform instead of block, why we started small and earned trust before scaling, and why "people decide, tools guide" became our north star.
We're also still figuring some things out. Where's the line between healthy maintenance and slow-motion abandonment? When should advisory become enforcement? How do you measure library health without turning it into a vanity metric?
We're done tagging, publishing, and hoping.
The Great Fusion of Skills — How to Architect Your Growth When the Bar Rises Faster Than Ever
The bar for developers hasn’t just been raised — the entire discipline has changed. Product Engineering, Forward Deployed Engineers, AI agent managers and harness engineering combine skills that used to belong to developers, analysts, architects and team leads. The age of mastering a single narrow specialization is ending. The age of skill fusion has begun.
The good news? You probably already have much of the fuel you need. Analytical thinking, business communication, managing complexity or juggling multiple responsibilities may now be as valuable as your technical skills. In my talk, I’ll show how to combine these strengths, where skill fusion creates the most business value and how to architect your growth around your cognitive strengths rather than temporary trends. You’ll leave with concrete ideas about what to learn, what to practice and where to grow next.
Thinking in Tables: Replacing Hibernate Magic with Exposed Logic in Spring Boot
The database you use does not consist of objects, so why do developers continue to act as though it does? For many, Hibernate's abstraction layer has created more conflict than it solved due to the "magical" behaviour that even an AI cannot debug.
Exposed is a Kotlin SQL framework that appeals to those who enjoy SQL but also appreciate type safety. This presentation will demonstrate how to replace the "magic" of JPA's heavy use of annotations with a more pragmatic and Kotlin-first methodology. The presentation will provide live code examples of how to create Spring Boot applications with an explicit, readable and fast persistence layer. Attendees will learn how to take advantage of Kotlin's language features to build their data layer in a way that is understandable to them, their compiler, and their database.
Thread Pool i czas czekania w kolejce: Bottleneck, którego nawet AI nie znalazł
Wiele różnych systemów zachowuje się zaskakująco podobnie: działają na wątkach lub pulach wątków, wysyłają żądania HTTP w trybie blokującym lub nieblokującym oraz parsują JSON-y, aby wykonywać logikę biznesową. Jednak prędzej czy później zaczynają zwalniać - niczym jazda przez miasto w godzinach szczytu, gdzie każda ulica codziennie kryje kolejny korek. Nie ma znaczenia, czy korzystamy z programowania reaktywnego, wirtualnych wątków czy zwykłych wątków platformowych - w każdym z tych modeli mogą pojawić się korki. W tym wystąpieniu przyjrzymy się, gdzie pojawia się czas oczekiwania w kolejce przy naszych pulach wątków i jak go mierzyć. Oczywiście dowiemy się też, co robić, gdy czas czekania jest większy niż 0. Wszystkie wnioski pochodzą bezpośrednio z rzeczywistych danych produkcyjnych.
To Be Announced
To Be Announced
Use your event bus creatively
Distributed persisted transaction logs, like Kakfa, Event Hub, Pulsar, Kinesis, MSK are everywhere and most companies either have them already, or can get them as managed services right away. Yet, developers do not understand the power those provide and instead treat them just as another boring queue. If you are not an expert on those tools, let me open up your mind a little bit with a few real life examples from production on what you can do with them creatively. There’ll be a lot of architecture, I’ll explain how to think about those tools, and how they work underneath the surface. If you’ve never used any of those, or you’ve just treated them as dumb pipes (which they are), this talk is for you.
What's New and What's Next for GraalVM
The latest GraalVM release brings major improvements for easy migration, even higher performance, and better developer experience. In this session, we’ll look at what’s new in GraalVM 25, how it helps build faster and more secure native executables, and what’s coming next.
Some of the new features we will cover:
– Easy migration with -H:Preserve
– ML for high performance out of the box
– Performance profiling
– Security by default
– New tools
We’ll also take a sneak peek at Project Crema, which will lift native compilation’s default closed-world assumption by allowing dynamic loading and execution of classes at run time, and Native Image Layers, a brand-new way to build native applications.
If you are curious about GraalVM and want to make the most out of its latest features, this session is for you.
Why Didn't We Use the Inbox Pattern? Aligning Architecture with Organizational Trust
In a mature organization with a long-running production system, software architecture is rarely just about the tech.
Using a real-world migration case study, this talk explores why we walked away from an obvious technical pattern in favor of an alternative driven by organizational trust. Discover why non-technical constraints are valid architectural drivers, and how to navigate them without compromising system stability.