Z manuskryptów starożytnych inżynierów – bazy danych

Kolejne warstwy frameworków, abstrakcji i pudru. Pozwalają nam dostarczać skomplikowane rozwiązania w skończonym czasie. Nasi dziadkowie mogliby nam pozazdrościć łatwości z jaką udaje nam się budować złożone systemy. Jednak często zapominamy o tym jak wiele zawdzięczamy starożytnym inżynierom. Spróbujmy poznać ich tajemnice, zapisane w manuskryptach.

Bazy danych są sercem naszych systemów, gdyż dane są krwiobiegiem naszych organizacji. Zabiorę Was w cudowną i nostalgiczną podróż przez świat architektury baz danych. Rozłożymy bazy danych na poszczególne komponenty by w pełni docenić piękno tych cudów inżynierii.

Zaczniemy od szybkiego kursu historii najnowszej, czyli dlaczego i kiedy pojawiła się koncepcja baz danych. By następnie przejść do technik organizacji danych na dysku. Poznać tajniki zarządzanie pamięcią i techniki zapewnienia izolacji zapisów czyli locking protocols.

Dowiesz się jak bazy danych zapewniają spójność i trwałość danych z pomocą „transaction logs” i „write-ahead logs”. Nie pominiemy też dyskusji o indeksach (w tym B+tree), wykonywaniu zapytań i optymalizacji planów zapytań.

Mam nadzieję, że ta prezentacji pozwoli wam lepiej zrozumieć jak budować aplikacje i optymalizować wydajność systemów. Dzięki zrozumieniu jakie prawa rządzą światem baz danych.

Będzie też czas na filozoficzne rozmyślania o sensie istnienia i odpowiedź na pytanie dokąd zmierzamy.

Anatomia warunków biznesowych

“If” – małe słowo, wielkie konsekwencje. Instrukcje warunkowe są z nami od pierwszych linii kodu, ale to, jak ich używamy, może zadecydować o losach całego projektu.

W tej prelekcji Łukasz zabierze Cię w podróż po świecie “ifów” – pokaże, jak je klasyfikować, jak wyciągać na światło dzienne ukryte decyzje i jak użyć DDD, by wprowadzić je w kod bez chaosu.

Git jakiego nie znacie

Commit, push, merge - tyle już znasz. Ale Git ma w zanadrzu o wiele więcej!

Masz kod rozrzucony po wielu repozytoriach? Rozmiar projektu zaczyna utrudniać pracę? Git log przestaje wystarczać żeby coś znaleźć?

Taki problem to nie problem! Wystarczy że poznasz ze mną kilka gitowych trików, które nie raz ratowały mi skórę - i mogą uratować Twoją.

Opowiem o rebase, shallow clone, submodules i bisect. Ogarnij Gita i uwolnij swój potencjał.

Od selfie do AI: Jak nauczyć Stable Diffusion swojej twarzy i nie tylko

Na co dzień w social media widzisz obrazki generowane przez AI.
Jednak nawet najnowsze np: w stylu studia Ghibli odbiegają znacząco od rzeczywistości.
Rodzi się więc pytanie, czy da się wygenerować siebie samego w określonym stylu? A jeżeli tak, to ile to będzie kosztować?
Zapraszam Cię na techniczną sesję, w której pokażę, jak nauczyć Stable Diffusion generowania tego, co chcesz na swoim komputerze lub w chmurze.
Sesja będzie pełna praktyki ze szczyptą teorii. Gotowi? No to akcja!

Human-Sized Code

As engineers we think it's important to follow so-called best practices. We often rewrite code for modularity and ease of testing. But we tend to forget that our writing is made for someone to actually read.

What is readability and how can we make our code more comprehensible to another human?

Skazani na bycie liderem?

Istnieje przekonanie, że oczywistym wyborem dla wybitnych inżynierów jest powierzenie im zarządzania własnym zespołem, w często daremnej próbie „przekazania” ich umiejętności innym. To oczywiście błędne podejście i często staje się obiektem szyderstw doświadczonych inżynierów. “Jest świetnym programistą, więc niech programuje mniej!” — mówimy sarkastycznie z cynicznym uśmiechem na naszych twarzach.

Tylko czy to faktycznie złe podejście? Jako inżynierowie chcemy rozwijać nasze talenty, awansować i oczywiście zarabiać więcej. Aby zarabiać więcej, musimy jednak wnieść większą wartość do firmy, w której pracujemy. Jak bardzo jesteśmy w stanie przeskalować nasze umiejętności, żeby faktycznie tą wartość dostarczyć? Będziemy programować 100% szybciej? Szybciej projektować? Czy istnieje w ogóle tutaj droga dla tak zwanego indywidualnego kontrybutora?

W tej prezentacji zastanowimy się właśnie nad tym i spróbujemy odpowiedzieć sobie na tytułowe pytanie—czy jesteśmy skazani na bycie liderem?

Subiektywnie o liderach IT

Opowiem Wam o liderach, o tym w jakie pułapki najczęściej wpadają, z jakimi najczęściej trudnościami i błędami mierzą się chcąc sprostać swojej roli.

Pracuję z liderami od kilku lat, przeprowadziłam wiele szkoleń liderskich. Łącznie to około 3000 osób, które piastują stanowiska liderskie albo pretendują do tej roli.

O błędach liderów powiedziano już wiele. Moja perspektywa, to perspektywa trenera, który spotyka liderów, kierowników, menedżerów z różnym poziomem doświadczenia, słucha ich historii, trudności, bolączek i wspiera ich w zakresie kompetencji miękkich. To także perspektywa psychologa, który dostrzega mechanizmy, jakie się za tymi trudnościami kryją.

Podzielę się z Wami moimi osobistymi spostrzeżeniami. Kto wie, może dzięki nim Wy, stając się liderami, popełnicie mniej błędów w przyszłości.

Debugging burnout: jak nie wypalić się w IT i odzyskać satysfakcję z pracy

Masz wrażenie, praca przestała dawać Ci satysfakcję, a po godzinach nie masz już ochoty na rozwój? Pracujesz na wysokich obrotach, ale zamiast dumy z dobrze wykonanej pracy czujesz coraz większe zmęczenie? Wypalenie zawodowe w IT to efekt uboczny ciągłego przeciążenia, presji i braku kontroli nad własnym rozwojem.

W tej prezentacji zrobię debugging wypalenia i pokażę, jak:
- zidentyfikować pierwsze „logi błędów” sugerujące, że zbliżasz się do krytycznego obciążenia,
- przejąć kontrolę nad swoją pracą i rozwojem, zamiast działać w trybie ciągłego gaszenia pożarów,
- unikać pułapki perfekcjonizmu i syndromu oszusta, które często prowadzą do prokrastynacji i frustracji,
- znaleźć sposoby na skuteczny „refactor” kariery i przywrócenie radości z pracy.

Jestem programistką, mentorką i osobą, która kiedyś sama się wypaliła. Wiem, jak to jest czuć, że nigdy nie robi się wystarczająco dużo, a równocześnie nie ma się siły na więcej – i wiem, jak z tego wyjść. Ta prezentacja to nie kolejna teoria o work-life balance, ale konkretne strategie, które możesz wdrożyć od razu.

Jeśli Twój mentalny CPU zaczyna się przegrzewać od nadmiaru tasków i ciągłej presji, przyjdź – pomogę Ci zoptymalizować wydajność, zanim system padnie.

DevOps bez sekretów: Managed Identity i System Assigned Identity w praktyce

W tej prezentacji pokażę, jak wykorzystać Managed Identity i System Assigned Identity w Azure, aby budować bezpieczne, skalowalne i bezkluczowe pipeline’y. Na konkretnych przykładach z życia codziennego DevOpsa zobaczymy, jak:
- Uwierzytelniać się do usług Azure bez potrzeby zarządzania hasłami czy tokenami.
- Konfigurować tożsamości zarządzane dla Azure DevOps, Azure Pipelines i maszyn wirtualnych.
- Zapewnić zasobom dostęp zgodny z zasadą najmniejszych uprawnień (Least Privilege).
- Monitorować i audytować użycie tożsamości w środowisku chmurowym."

Automate your software design. How far we can get and how the AI changes the game?

Creating good software design requires careful thought. It's easy to fall into traps that cause us to stray from the intended solution. Some may avoid the necessary effort, while others might overcomplicate things. Let’s explore how to strike the right balance and find the proper direction in software design by making the most of available possibilities.

We will dive into real-life scenarios, identify common problems, and work on finding solutions. Along the way, we’ll discuss topics from the SDLC cycle to architecture. We will start with basic diagrams, then move on to widely used notations like UML and BPMN, incorporating automation tools such as Markdown, Docusaurus, Mermaid, PlantUML, C4 and more. Finally we will let the AI take over.

Czy hakerzy z Korei Północnej zagrażają także Tobie i Twojej firmie? Jakie techniki stosuje grupa Lazarus*, by przełamać nawet najskuteczniejsze zabezpieczenia?

Przerażające statystyki cyberataków na całym świecie nie pozostawiają złudzeń: zagrożenie jest realne, a skala strat liczona jest już w dziesiątkach miliardach dolarów rocznie. Jakie techniki stosują hakerzy, by przekraczać kolejne granice cyberbezpieczeństwa? Jaki aspekt generuje największe ryzyko dla firm?

Poznaj techniki i sztuczki używane przez północnokoreańską “państwową” grupę Lazarus* przy atakach, wobec których nie można pozostać obojętnym. W skrócie opowiem oczywiście o ich największych i najbardziej bolesnych akcjach, którymi ofiarami padały instytucje finansowe, firmy medialne, koncerny farmaceutyczne, czy giełdy kryptowalut. Najwięcej uwagi poświęcimy jednak atakom grupy, które mogą stanowić niebezpieczeństwo w 2025 roku zarówno dla MŚP, jak i wielkich korporacji.

Celem prezentacji jest zwiększenie świadomości uczestników (bez wchodzenia w niskopoziomowe szczegóły techniczne) na temat skali i natury tych zagrożeń. Jest to pierwszy krok do skutecznego zabezpieczenia Twojej firmy. Przygotuj się, bo jutro celem możesz być Ty.

The Four R

A TDD tool for tackling hard conversations before they happen. As our responsibility grows, our communication starts to matter more. We need to align works across teams or even across whole organisations; we need to talk to stakeholders, CxOs, VPs, Engineers Directors, Product people and Engineers. Not all conversations will be smooth; how can we prepare if we know that the next important meeting with our VP might go sideways? One of the tools that helped me a lot was the Four R's - record, reflect, revise, and roleplay.

In the talk, I will walk through the framework, what it is based on, and how to use it effectively.

To co NIE ukryte i tak będzie użyte, czyli architektura w cieniu Hyrum’s Law

W świecie złożonych systemów, granica między tym, co "wewnętrzne", a tym, co "publiczne", często bywa iluzoryczna. Hyrum's Law głosi, że „z wystarczająco dużą liczbą użytkowników każda obserwowalna cecha twojego systemu będzie wykorzystywana – niezależnie od tego, czy była częścią publicznego API, czy nie”.

W tej prezentacji pokażę, jakie konsekwencje to prawo niesie dla projektowania systemów oraz jak może (i powinno) wpływać na decyzje architektoniczne. Omówimy, dlaczego ukrywanie szczegółów implementacyjnych to za mało, jak radzić sobie ze zmianami bez łamania kontraktów i jak tworzyć systemy odporne na nadmiarowe zależności ze strony użytkowników.

Biohacking w zespołach zwinnych

Agile Team to nie tylko tablica w Jirze i daily o 9:15. To system rozproszony, pełen edge-case’ów, zależności ukrytych w ludziach i niespodziewanych timeoutów w komunikacji.

„Biohacking” w tym kontekście to nie suplementy i trackery, ale świadome podejście do najważniejszego — i często najdroższego — zasobu w projekcie: ludzi.

Porozmawiamy o tym, jak zwiększyć efektywność zespołu bez zmiany stacku technologicznego czy przebudowy architektury, za to z solidną refaktoryzacją komunikacji.

To sesja zarówno dla tych, którzy prowadzą zespoły, jak i dla tych, którzy dopiero zaczynają swoją drogę w IT. Dobre praktyki nie mają seniority.

Architektura MikroFrontendowa - (nieudane) lekcje z produkcji.

Architektura MikroFrontendowa (MFE) ma na celu zmierzenie się z bardzo konkretnymi wyzwaniami - i wbrew pozorom chodzi bardziej o organizację pracy zespołów, niż o sam kod frontendowy. Jest to też architektura dość niejednorodna, a mnogość rozwiązań niejednego doprowadziła do... błędnej, jak się potem okazało, decyzji. Dodatkowo, MFE współdzieli pewne cechy z Mikro Serwisami, są jednak między nimi dość istotne różnice - w szczególności wynikające z innego środowiska uruchomieniowego.

Podczas prelekcji przyjrzymy się projektowaniu, wdrażaniu, uruchamianiu oraz organizowaniu pracy wielo zespołowej wokół architektury MFE - wszystko związane z: modułowością, zarządzaniem stanem, podziałem poziomym i pionowym, praktykami DevOps, topologiami zespołowymi i stosowaniem strategicznego DDD.

Przeanalizujemy realne przypadki zarówno sukcesów jak i porażek zastosowania mikro frontendów, budując solidne rozumienie "tradeoff-ów" które za nimi stoją. Zwalczymy przy okazji kilka mitów, które narosły wokół tej architektury, będące skutkiem niezrozumienia konceptu i... nieudanych wdrożeń.

Zbudujmy własną platformę do strumieniowego przesyłania wiadomości

Mechanizm strumieniowania wiadomości nierzadko stanowi nieodzowny element infrastruktury w systemach rozproszonych. Od klasycznej integracji za pomocą zdarzeń (event-driven architecture) w architekturze mikroserwisowej, po zaawansowane systemy tradingowe typu HFT wymagające możliwie niskich opóźnień (low latency).

Niezawodna (i możliwie szybka) komunikacja pomiędzy niezależnymi aplikacjami ma krytyczne znaczenie dla poprawnego działania systemu.

Jak wygląda message streaming od podstaw? Z jakimi wyzwaniami musi zmierzyć się inżynier oprogramowania rozwijający takie narzędzie? Skąd bierze się przepustowość rzędu milionów wiadomości na sekundę? Jak duży wpływ może mieć kernel Linuxa na wydajność takiego rozwiązania?

Chciałbym podzielić się tym, czego nauczyliśmy się przez ostatnie 2 lata, rozwijając od podstaw Apache Iggy — projekt, służący do strumieniowego przesyłania wiadomości."

Z manuskryptów starożytnych inżynierów – bazy danych

Kolejne warstwy frameworków, abstrakcji i pudru. Pozwalają nam dostarczać skomplikowane rozwiązania w skończonym czasie. Nasi dziadkowie mogliby nam pozazdrościć łatwości z jaką udaje nam się budować złożone systemy. Jednak często zapominamy o tym jak wiele zawdzięczamy starożytnym inżynierom. Spróbujmy poznać ich tajemnice, zapisane w manuskryptach.

Bazy danych są sercem naszych systemów, gdyż dane są krwiobiegiem naszych organizacji. Zabiorę Was w cudowną i nostalgiczną podróż przez świat architektury baz danych. Rozłożymy bazy danych na poszczególne komponenty by w pełni docenić piękno tych cudów inżynierii.

Zaczniemy od szybkiego kursu historii najnowszej, czyli dlaczego i kiedy pojawiła się koncepcja baz danych. By następnie przejść do technik organizacji danych na dysku. Poznać tajniki zarządzanie pamięcią i techniki zapewnienia izolacji zapisów czyli locking protocols.

Dowiesz się jak bazy danych zapewniają spójność i trwałość danych z pomocą „transaction logs” i „write-ahead logs”. Nie pominiemy też dyskusji o indeksach (w tym B+tree), wykonywaniu zapytań i optymalizacji planów zapytań.

Mam nadzieję, że ta prezentacji pozwoli wam lepiej zrozumieć jak budować aplikacje i optymalizować wydajność systemów. Dzięki zrozumieniu jakie prawa rządzą światem baz danych.

Będzie też czas na filozoficzne rozmyślania o sensie istnienia i odpowiedź na pytanie dokąd zmierzamy.

Anatomia warunków biznesowych

“If” – małe słowo, wielkie konsekwencje. Instrukcje warunkowe są z nami od pierwszych linii kodu, ale to, jak ich używamy, może zadecydować o losach całego projektu.

W tej prelekcji Łukasz zabierze Cię w podróż po świecie “ifów” – pokaże, jak je klasyfikować, jak wyciągać na światło dzienne ukryte decyzje i jak użyć DDD, by wprowadzić je w kod bez chaosu.

Git jakiego nie znacie

Commit, push, merge - tyle już znasz. Ale Git ma w zanadrzu o wiele więcej!

Masz kod rozrzucony po wielu repozytoriach? Rozmiar projektu zaczyna utrudniać pracę? Git log przestaje wystarczać żeby coś znaleźć?

Taki problem to nie problem! Wystarczy że poznasz ze mną kilka gitowych trików, które nie raz ratowały mi skórę - i mogą uratować Twoją.

Opowiem o rebase, shallow clone, submodules i bisect. Ogarnij Gita i uwolnij swój potencjał.

Od selfie do AI: Jak nauczyć Stable Diffusion swojej twarzy i nie tylko

Na co dzień w social media widzisz obrazki generowane przez AI.
Jednak nawet najnowsze np: w stylu studia Ghibli odbiegają znacząco od rzeczywistości.
Rodzi się więc pytanie, czy da się wygenerować siebie samego w określonym stylu? A jeżeli tak, to ile to będzie kosztować?
Zapraszam Cię na techniczną sesję, w której pokażę, jak nauczyć Stable Diffusion generowania tego, co chcesz na swoim komputerze lub w chmurze.
Sesja będzie pełna praktyki ze szczyptą teorii. Gotowi? No to akcja!

Human-Sized Code

As engineers we think it's important to follow so-called best practices. We often rewrite code for modularity and ease of testing. But we tend to forget that our writing is made for someone to actually read.

What is readability and how can we make our code more comprehensible to another human?

Skazani na bycie liderem?

Istnieje przekonanie, że oczywistym wyborem dla wybitnych inżynierów jest powierzenie im zarządzania własnym zespołem, w często daremnej próbie „przekazania” ich umiejętności innym. To oczywiście błędne podejście i często staje się obiektem szyderstw doświadczonych inżynierów. “Jest świetnym programistą, więc niech programuje mniej!” — mówimy sarkastycznie z cynicznym uśmiechem na naszych twarzach.

Tylko czy to faktycznie złe podejście? Jako inżynierowie chcemy rozwijać nasze talenty, awansować i oczywiście zarabiać więcej. Aby zarabiać więcej, musimy jednak wnieść większą wartość do firmy, w której pracujemy. Jak bardzo jesteśmy w stanie przeskalować nasze umiejętności, żeby faktycznie tą wartość dostarczyć? Będziemy programować 100% szybciej? Szybciej projektować? Czy istnieje w ogóle tutaj droga dla tak zwanego indywidualnego kontrybutora?

W tej prezentacji zastanowimy się właśnie nad tym i spróbujemy odpowiedzieć sobie na tytułowe pytanie—czy jesteśmy skazani na bycie liderem?

Subiektywnie o liderach IT

Opowiem Wam o liderach, o tym w jakie pułapki najczęściej wpadają, z jakimi najczęściej trudnościami i błędami mierzą się chcąc sprostać swojej roli.

Pracuję z liderami od kilku lat, przeprowadziłam wiele szkoleń liderskich. Łącznie to około 3000 osób, które piastują stanowiska liderskie albo pretendują do tej roli.

O błędach liderów powiedziano już wiele. Moja perspektywa, to perspektywa trenera, który spotyka liderów, kierowników, menedżerów z różnym poziomem doświadczenia, słucha ich historii, trudności, bolączek i wspiera ich w zakresie kompetencji miękkich. To także perspektywa psychologa, który dostrzega mechanizmy, jakie się za tymi trudnościami kryją.

Podzielę się z Wami moimi osobistymi spostrzeżeniami. Kto wie, może dzięki nim Wy, stając się liderami, popełnicie mniej błędów w przyszłości.

Debugging burnout: jak nie wypalić się w IT i odzyskać satysfakcję z pracy

Masz wrażenie, praca przestała dawać Ci satysfakcję, a po godzinach nie masz już ochoty na rozwój? Pracujesz na wysokich obrotach, ale zamiast dumy z dobrze wykonanej pracy czujesz coraz większe zmęczenie? Wypalenie zawodowe w IT to efekt uboczny ciągłego przeciążenia, presji i braku kontroli nad własnym rozwojem.

W tej prezentacji zrobię debugging wypalenia i pokażę, jak:
- zidentyfikować pierwsze „logi błędów” sugerujące, że zbliżasz się do krytycznego obciążenia,
- przejąć kontrolę nad swoją pracą i rozwojem, zamiast działać w trybie ciągłego gaszenia pożarów,
- unikać pułapki perfekcjonizmu i syndromu oszusta, które często prowadzą do prokrastynacji i frustracji,
- znaleźć sposoby na skuteczny „refactor” kariery i przywrócenie radości z pracy.

Jestem programistką, mentorką i osobą, która kiedyś sama się wypaliła. Wiem, jak to jest czuć, że nigdy nie robi się wystarczająco dużo, a równocześnie nie ma się siły na więcej – i wiem, jak z tego wyjść. Ta prezentacja to nie kolejna teoria o work-life balance, ale konkretne strategie, które możesz wdrożyć od razu.

Jeśli Twój mentalny CPU zaczyna się przegrzewać od nadmiaru tasków i ciągłej presji, przyjdź – pomogę Ci zoptymalizować wydajność, zanim system padnie.

DevOps bez sekretów: Managed Identity i System Assigned Identity w praktyce

W tej prezentacji pokażę, jak wykorzystać Managed Identity i System Assigned Identity w Azure, aby budować bezpieczne, skalowalne i bezkluczowe pipeline’y. Na konkretnych przykładach z życia codziennego DevOpsa zobaczymy, jak:
- Uwierzytelniać się do usług Azure bez potrzeby zarządzania hasłami czy tokenami.
- Konfigurować tożsamości zarządzane dla Azure DevOps, Azure Pipelines i maszyn wirtualnych.
- Zapewnić zasobom dostęp zgodny z zasadą najmniejszych uprawnień (Least Privilege).
- Monitorować i audytować użycie tożsamości w środowisku chmurowym."

Automate your software design. How far we can get and how the AI changes the game?

Creating good software design requires careful thought. It's easy to fall into traps that cause us to stray from the intended solution. Some may avoid the necessary effort, while others might overcomplicate things. Let’s explore how to strike the right balance and find the proper direction in software design by making the most of available possibilities.

We will dive into real-life scenarios, identify common problems, and work on finding solutions. Along the way, we’ll discuss topics from the SDLC cycle to architecture. We will start with basic diagrams, then move on to widely used notations like UML and BPMN, incorporating automation tools such as Markdown, Docusaurus, Mermaid, PlantUML, C4 and more. Finally we will let the AI take over.

Czy hakerzy z Korei Północnej zagrażają także Tobie i Twojej firmie? Jakie techniki stosuje grupa Lazarus*, by przełamać nawet najskuteczniejsze zabezpieczenia?

Przerażające statystyki cyberataków na całym świecie nie pozostawiają złudzeń: zagrożenie jest realne, a skala strat liczona jest już w dziesiątkach miliardach dolarów rocznie. Jakie techniki stosują hakerzy, by przekraczać kolejne granice cyberbezpieczeństwa? Jaki aspekt generuje największe ryzyko dla firm?

Poznaj techniki i sztuczki używane przez północnokoreańską “państwową” grupę Lazarus* przy atakach, wobec których nie można pozostać obojętnym. W skrócie opowiem oczywiście o ich największych i najbardziej bolesnych akcjach, którymi ofiarami padały instytucje finansowe, firmy medialne, koncerny farmaceutyczne, czy giełdy kryptowalut. Najwięcej uwagi poświęcimy jednak atakom grupy, które mogą stanowić niebezpieczeństwo w 2025 roku zarówno dla MŚP, jak i wielkich korporacji.

Celem prezentacji jest zwiększenie świadomości uczestników (bez wchodzenia w niskopoziomowe szczegóły techniczne) na temat skali i natury tych zagrożeń. Jest to pierwszy krok do skutecznego zabezpieczenia Twojej firmy. Przygotuj się, bo jutro celem możesz być Ty.

The Four R

A TDD tool for tackling hard conversations before they happen. As our responsibility grows, our communication starts to matter more. We need to align works across teams or even across whole organisations; we need to talk to stakeholders, CxOs, VPs, Engineers Directors, Product people and Engineers. Not all conversations will be smooth; how can we prepare if we know that the next important meeting with our VP might go sideways? One of the tools that helped me a lot was the Four R's - record, reflect, revise, and roleplay.

In the talk, I will walk through the framework, what it is based on, and how to use it effectively.

To co NIE ukryte i tak będzie użyte, czyli architektura w cieniu Hyrum’s Law

W świecie złożonych systemów, granica między tym, co "wewnętrzne", a tym, co "publiczne", często bywa iluzoryczna. Hyrum's Law głosi, że „z wystarczająco dużą liczbą użytkowników każda obserwowalna cecha twojego systemu będzie wykorzystywana – niezależnie od tego, czy była częścią publicznego API, czy nie”.

W tej prezentacji pokażę, jakie konsekwencje to prawo niesie dla projektowania systemów oraz jak może (i powinno) wpływać na decyzje architektoniczne. Omówimy, dlaczego ukrywanie szczegółów implementacyjnych to za mało, jak radzić sobie ze zmianami bez łamania kontraktów i jak tworzyć systemy odporne na nadmiarowe zależności ze strony użytkowników.

Biohacking w zespołach zwinnych

Agile Team to nie tylko tablica w Jirze i daily o 9:15. To system rozproszony, pełen edge-case’ów, zależności ukrytych w ludziach i niespodziewanych timeoutów w komunikacji.

„Biohacking” w tym kontekście to nie suplementy i trackery, ale świadome podejście do najważniejszego — i często najdroższego — zasobu w projekcie: ludzi.

Porozmawiamy o tym, jak zwiększyć efektywność zespołu bez zmiany stacku technologicznego czy przebudowy architektury, za to z solidną refaktoryzacją komunikacji.

To sesja zarówno dla tych, którzy prowadzą zespoły, jak i dla tych, którzy dopiero zaczynają swoją drogę w IT. Dobre praktyki nie mają seniority.

Architektura MikroFrontendowa - (nieudane) lekcje z produkcji.

Architektura MikroFrontendowa (MFE) ma na celu zmierzenie się z bardzo konkretnymi wyzwaniami - i wbrew pozorom chodzi bardziej o organizację pracy zespołów, niż o sam kod frontendowy. Jest to też architektura dość niejednorodna, a mnogość rozwiązań niejednego doprowadziła do... błędnej, jak się potem okazało, decyzji. Dodatkowo, MFE współdzieli pewne cechy z Mikro Serwisami, są jednak między nimi dość istotne różnice - w szczególności wynikające z innego środowiska uruchomieniowego.

Podczas prelekcji przyjrzymy się projektowaniu, wdrażaniu, uruchamianiu oraz organizowaniu pracy wielo zespołowej wokół architektury MFE - wszystko związane z: modułowością, zarządzaniem stanem, podziałem poziomym i pionowym, praktykami DevOps, topologiami zespołowymi i stosowaniem strategicznego DDD.

Przeanalizujemy realne przypadki zarówno sukcesów jak i porażek zastosowania mikro frontendów, budując solidne rozumienie "tradeoff-ów" które za nimi stoją. Zwalczymy przy okazji kilka mitów, które narosły wokół tej architektury, będące skutkiem niezrozumienia konceptu i... nieudanych wdrożeń.

Zbudujmy własną platformę do strumieniowego przesyłania wiadomości

Mechanizm strumieniowania wiadomości nierzadko stanowi nieodzowny element infrastruktury w systemach rozproszonych. Od klasycznej integracji za pomocą zdarzeń (event-driven architecture) w architekturze mikroserwisowej, po zaawansowane systemy tradingowe typu HFT wymagające możliwie niskich opóźnień (low latency).

Niezawodna (i możliwie szybka) komunikacja pomiędzy niezależnymi aplikacjami ma krytyczne znaczenie dla poprawnego działania systemu.

Jak wygląda message streaming od podstaw? Z jakimi wyzwaniami musi zmierzyć się inżynier oprogramowania rozwijający takie narzędzie? Skąd bierze się przepustowość rzędu milionów wiadomości na sekundę? Jak duży wpływ może mieć kernel Linuxa na wydajność takiego rozwiązania?

Chciałbym podzielić się tym, czego nauczyliśmy się przez ostatnie 2 lata, rozwijając od podstaw Apache Iggy — projekt, służący do strumieniowego przesyłania wiadomości."

Rejestracja uczestników

Rozpoczęcie konferencji

Przerwa obiadowa

Zakończenie konferencji

Przerwa kawowa

After Party

Stary Browar Rzeszowski, Rynek, tuż obok Bristolu.