Jakub Gutkowski
Bartosz Rybacki
Tomasz Ducin
Zbyszko Papierski
Piotr Gankiewicz
Dariusz Pawlukiewicz
Ola Kunysz
Michał Borkowski
Łukasz Reszke
Jakub Koleżyński
Krystian Zybała
Michał Machniak
Anita Przybył
Marcin Zajączkowski
Chris Hasiński
Marcin Samsonowski
Piotr Stapp
Stary Browar Rzeszowski, Rynek, tuż obok Bristolu.
Podczas prezentacji Bartosz wyjaśni, jak podejść do autoskalowania w Kubernetes na przykładzie realnego wdrożenia Trino. Na wstępie nastąpi krótkie wprowadzenie do tematu i przegląd podstawowych mechanizmów, takich jak Horizontal Pod Autoscaler. Prelegent przedstawi również praktyczne spojrzenie na wyzwania przy skalowaniu klastrów Trino. Całość kończy się omówieniem finalnego rozwiązania opartego na własnym operatorze.
To wszystko na podstawie doświadczeń z zakończonego projektu
Bartosz Rybacki
Bartosz Rybacki - od prawie 20 lat robi backend, głównie w Javie. Pracował w korporacjach i startupach, a przez ostatnie lata pisał operatory do Kubernetesa w Go i Javie. Kiedyś zdarzało mu się robić frontend (nawet zanim pojawił się Ajax - czy ktoś pamięta iframe?), ale od zawsze najlepiej czuje się po stronie serwera. Dziś po raz pierwszy po tej drugiej stronie - jako prelegent na konferencji.
“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.
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ł.
Michał Borkowski
Z ponad 10 latami doświadczenia działał już w backendzie, infrastrukturze, architekturze, trochę we frontendzie i prowadzeniu zespołów. Dobiera narzędzie do problemu kiedy trzeba, ale lubi, kiedy problem daje się rozwiązać nie wychodząc z terminala. Automatyzuje rzeczy dla zabawy - w pracy, w domu i w Minecrafcie. Chciałby umieć robić wszystko: spawać, szyć, rzeźbić, budować lepianki i autonomiczne roboty.
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!
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?
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?
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.
Anita Przybył
Trenerka biznesu z z doświadczeniem na sali szkoleniowej od 2006 roku. Uczestniczka wielu szkoleń doskonalących metody pracy z ludźmi oraz wspierających ich rozwój, m.in. Szkoły Coachingu, Szkoły Trenerów Biznesu, Racjonalnej Terapii Zachowań, Terapii Skoncentrowanej na Rozwiązaniach.
Przez kilka lat odpowiadała za szkolenia pracowników w międzynarodowej korporacji. Aktualnie trener freelancer.
Specjalizuje się w szkoleniach z zakresu umiejętności społecznych w biznesie, m.in wspiera liderów IT oraz programistów w temacie kompetencji miękkich. W swoich szkoleniach stawia na naukę przez doświadczenie, kładąc nacisk na interaktywne, warsztatowe formy nauczania oraz intensywny trening umiejętności.
Współorganizatorka i trenerka warsztatów Soft Skille Dla Programistów.
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.
Ola Kunysz
Software engineer, mentorka i autorka treści. W branży IT działa od kilkunastu lat. Doświadczenia zdobywała w Polsce i Stanach Zjednoczonych.
Pracowała w wielu międzynarodowych projektach - od telekomunikacji, przez ubezpieczenia, po e-commerce.
W 2019 założyła Szkolę Testów, gdzie zajmuje się tematyką jakości projektu i uczy programistów nie tylko technicznych, ale i miękkich umiejętności. W 2021 roku wydała książkę "Kierunek Jakość". Obecnie zajmuje się tematem jakości samej pracy w branży IT.
Ma na swoim koncie zwycięską walkę z wypaleniem zawodowym, dlatego dzieli się zdobytą wiedzą i dobrymi praktykami.
W 2022 roku wystąpiła na TEDxKoszalin.
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."
Michał Machniak
I have been passionate about information technology for over 20 years, it is my hobby and my profession.
In those days I work as MCT / SysOps / Architect / DevOps with customers form different sectors like FinTech, E-commerce, Banking, logistics and many more.
I am building and implementing solutions based on Microsoft technology when I use: Windows Server, SQL Server, PowerShell, Azure, Office 365, SharePoint, Teams, Azure DevOps, Git … and many other tools that allow me to complete the task and achieve the goal.
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.
Marcin Samsonowski
"Architect, software engineer, consultant. Eager on learning. Passionate about teaching.
Focused on people and processes, quality and effectiveness.
Having diverse experiences in multiple roles and sectors and tiny to huge companies.
Found his best match in holistic understanding. Chose to keep an eye especially on Enterprise and Solution Architecture.
In free time mostly passionate about music (singing, playing, dancing) and sports (from martial arts to snowboarding)."
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.
Marcin Zajączkowski
Doświadczony architekt realizujący projekty charakteryzujące się wysoką jakością i niezawodnością.
Silnie zaangażowany w promowanie Software Craftsmanship, Clean Code i Test-Driven Development na konferencjach i szkoleniach.
Specjalista w automatyzacji wdrożeń z Continuous Delivery i Continuous Inspection of Code Quality.
Entuzjasta szeroko rozumianej współbieżności, wydajności i dostępności. Po godzinach poszukiwacz "dziur" i innych niebezpieczeństw w Internecie.
Poza tym autor i kontrybutor projektów open source, bloger (https://blog.solidsoft.pl/) i trener (https://www.solidsoft.pl/training/)."
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.
Jakub Gutkowski
Jakub is an independent consultant who works directly with teams on long-running projects. He has worked as a Principal Engineer, Lead Cloud Architect, and Engineering Manager. Jakub has been involved in designing and implementing internal development platforms and SaaS products across different technology stacks. He is a 15th-time Microsoft MVP. When not working, Jakub usually goes outside doing various sports activities alone or with the family.
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.
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.
Jakub Koleżyński
Inżynier oprogramowania i tech lead z backendowymi korzeniami, kwitnącą pasją do frontendu i nieustannym głodem prostych rozwiązań. Z zamiłowaniem rozkłada złożone problemy na czynniki pierwsze, a wyzwania traktuje jak okazję do nauki – swojej i zespołu. Zawodowo pisał kod dla przemysłu ciężkiego, finansów i wszystkiego pomiędzy.
Obecnie doskonale bawi się w NewOrbit, gdzie wspiera zespoły, dzieli się doświadczeniem i nie przestaje szlifować rzemiosła programistycznego – technicznego i ludzkiego.
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ń.
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."
Piotr Gankiewicz
Inżynier oprogramowania z ponad dekadą doświadczenia (wywodzący się z obszaru C# i dotnet), aktualnie używający Rusta w pracy w startupie z zakresu cyberbezpieczeństwa Hugin.io. Kontrybutor OSS, rozwijający platformę do strumieniowego przesyłania wiadomości Apache Iggy. Były Microsoft MVP, trener Bottega IT Minds i współzałożyciel DevMentors.io.
Twoja aplikacja wchodzi na 100% CPU jak do siebie? Wątek główny kręci wiatrakiem jak śmigłowiec Apache? Zamiast debugować „na czuja”, załaduj broń masowego profilowania! W trakcie prezentacji:
- Odpalimy profiler i zajrzymy pod maskę JVM
- Spalimy trochę stosów w flamegraphach (dosłownie)
- Namierzymy złodziei cykli CPU jak prawdziwi profilerowi detektywi
- Zobaczysz, jak zdiagnozować problemy, które „magicznie” znikają po restarcie… ale wracają w piątki po 17:00
Zero nudnej teorii, tylko praktyka i trochę memów. Będzie śmiesznie, będzie merytorycznie, a Twój CPU podziękuje Ci jeszcze dziś.
Krystian Zybała
Specjalista z ponad 10-letnim doświadczeniem w branży IT, specjalizujący się w optymalizacji wydajności JVM w systemach rozproszonych, szczególnie w sektorze finansowym, gdzie priorytetem są low-latency i throughput. Na co dzień pracuje z JVM, nieustannie benchmarkując granice jego możliwości przy porannej kawie. Z pasją zgłębia tajniki wydajności JVM i chętnie dzieli się wiedzą na temat najlepszych praktyk w zakresie optymalizacji oraz rozwiązań klasy enterprise. Hobbystycznie kontynuuje eksplorację zagadnień Performance Engineering, nieustannie dążąc do wyznaczania nowych standardów w obszarze efektywności systemów.