Zostaw Feedback

CRAFT-IT
Zostaw feedback dla nas!
zostaw feedback

Stowarzyszenie CRAFT.IT

Menu

  • Zespół
  • Regulamin
  • Polityka Prywatności

Archiwum

  • 2022
  • 2019
  • 2018
  • 2017
  • Galeria zdjęć
  • Relacja video

Social

  • rg-dev
  • rrug

© 2023 Craft-IT na podstawie Project Zeppelin

Jarosław Pałka Software Consultant/Architect/Trainer

Od ponad 20 lat w branży IT jako administrator baz danych, programista, architekt, manager i „inżynier od spraw katastrof”. Brałem udział w małych, średnich i nonsensownie dużych projektach, prowadzonych zgodnie zasadami „waterfall”, Agile oraz przy braku jakichkolwiek metodyk - z tym samym zawsze skutkiem. Wszystko to doprowadziło mnie do wniosku, że nieważne co robisz, ważne byś robił to dobrze, w najprostszy z możliwych sposobów i przy użyciu właściwych narzędzi, które wykonają pracę za Ciebie. W międzyczasie dałem się porwać ideom TDD oraz Software Craftmanship, do granic możliwości wyeksploatować tak piękne w swej prostocie pomysły jak REST i NoSQL. Porzuciłem je, by zgłębić tajniki „system thinking” i zachwycić się siłą, jaką niesie ze sobą „metafora” oraz by odkryć, że rządzą nami te same prawa „natury”. Niepokorny wyznawca kościoła JVM, badacz bytecode’u i JIT oraz wszelkiej maści parserów, interpreterów i kompilatorów. Na co dzień walczący o lepszą wydajność w Neo4j. Od czasu do czasu można usłyszeć moje niskiej jakości żarty na temat architektury na konferencjach w Polsce. W wolnych chwilach trener w Symentis, autor bloga na http://geekyprimitives.wordpress.com/ oraz samozwańczy dyktator w Radzie Programowej konferencji SegFault.

25 lat mijania się z prawdą

PREZENTACJA

Kto nie chciałby zobaczyć, jak tym wystąpieniem niszczę swoją karierę? Minęło 25 lat, co brzmi jak wyrok za ciężką zbrodnię z mrocznych zakątków kodeksu karnego, ale dla mnie to czas podsumowań. Prezentacja, stand-up, coaching? - nazwijcie to jak chcecie. Będzie o naszej branży, biznesie i o nas samych, o "uniwersalnych kłamstwach", które często powtarzane stają się prawdą. To będzie brutalny przewodnik po karierze w IT. Wielu z was zapewne poczuje się urażonych, ale jestem gotów na to poświęcenie. Czy wybór technologii ma znaczenie? Dlaczego większość stanowisk to "bullshit jobs"? Czy greenfieldy naprawdę są takie fajne? Komu potrzebne są estymaty? Co się dzieje, kiedy nie udaje się dowieźć sprintu? Jak feedback stał się rakiem toczącym organizacje? Dlaczego duża część z nas ma wrażenie, że ciągle robi to samo? I jak w tym bajzlu zachować szacunek do siebie, zdrowie psychiczne i dobrze bawić się przez 25 lat? Postaram się odpowiedzieć na te i inne pytania, które sam sobie stawiam od dłuższego czasu. Ci którzy odsieją śmiech przez łzy w tej prezentacji, odnajdą kilka cennych rad jak pokierować swoją karierą.

Wydajność aplikacji Java dla ciekawskich

WARSZTAT

Celem tego warsztatu jest łagodne wprowadzenie Cię w świat wydajności na platformie JVM. Nie wiesz nic o JMH, JFR, async profiler, dlaczego twój kod musi być wygrzewany? Nigdy nie widziałeś "flamegraph"?

Spokojnie. Tego wszystkiego dowiesz się podczas jednodniowego warsztatu. Skupimy się nie tylko na narzędziach, ale także na procesie i technikach optymalizowania wydajności. Weźmiemy na warsztat jeden z sztandarowych modeli przetwarzania danych, "map reduce". Od prostej jednowątkowej implementacji, po wielowątkowe monstrum oparte o fork-join pool, będziemy poznawać techniki i narzędzia pracy z testami wydajnościowymi ( w skali micro, znanymi także jako "microbenchmark").

Będzie też czas na zapoznanie się z mechanizmami JVM, takimi jak just-in-time compiler, garbage collector czy adaptive locking. Więcej informacji na stronie https://jvmperformance.pl/.

Wymagania

  • JDK 20
  • Docker
  • Maven
  • Zaznajomienie się z biznesowymi i technicznymi metodami modularyzacji systemu.
  • IDE


Krzysztof Kędzierski Engineering Leader

Swoją przygodę z IT rozpoczynał od ról developerskich, stopniowo wchodząc w role liderskie/managerskie. Pracował w firmach o różnej specyfice jak software house, startup/scaleup, duża firma produktowa, bank inwestycyjny. Specjalizuje się w architekturze na przecięciu z zarządzaniem zespołami i organizacją. Prywatnie: wielki fan piłki nożnej.

Wolni jak ślimaki, pasywni jak rurkowce

PREZENTACJA

Jest rok 2023. Postęp technologiczny, który widzimy robi wrażenie. Mimo to pytanie, które w kuluarach zadaje sobie wiele (większość?) firm wytwarzających oprogramowanie brzmi “Co zrobić by software development był u nas szybszy? Okazuje się, że jako ruch Software Craftsmanship mamy odpowiedź na to pytanie.

W trakcie prezentacji spojrzę na temat szybkości wytwarzania oprogramowania – problemy, przyczyny i rozwiązania z różnych perspektyw. Pokażę kto znajduje się w centrum tego zagadnienia i jak może sprawić by było lepiej 😉


Michał Borkowski

Michał tworzy oprogramowanie w Xebia. Kiedy nie programuje, lubi dzielić się wiedzą ze studentami i przypadkowymi przechodniami. W wolnym czasie lubi eksperymentować z niszowymi technologiami i robić proste rzeczy od podstaw - wynajdować koło na nowo. Zwykle używa narzędzia odpowiedniego do zadania, ale jego ulubione środowisko programistyczne to vim + tmux + czarno-biała konsola. Słynie z tego że dzieli się swoją skromną wiedzą z innymi w formie anegdotek, czy tego chcą czy nie.

Dyskrecja DevOpsa. Co robimy w ukryciu?

PREZENTACJA

Bezpieczeństwo danych, wdrożenia na produkcję, milionowe biznesy i dostęp tylko w razie potrzeby. Wszystkie aspekty automatyzacji budowania i wdrażania aplikacji w zabezpieczonym środowisku składają się na obraz zadania, które jednocześnie ma dobrze znane prawidłowe rozwiązania i bardzo łatwo zrealizować je źle. A ponieważ konsekwencje zaniedbań mogą spowodować nagłe zmiany w karierze, to warto o nich pomyśleć wcześniej. Zróbmy to teraz.


Jakub Pilimon

Miłośnik DDD, OOP oraz TDD. Developer/Architekt pod kątem inżynierskim głównie zainteresowany modelowaniem oraz architekturą. Swój wysiłek skupia na czytelności kodu, skalowalności oraz wydajności.

Podczas dotychczasowej kariery projektował oraz implementował systemy dla branży finansowej, medycznej, telekomunikacyjnej oraz energetycznej

Prywatnie fanatyk piłki nożnej, narciarstwa i jazdy motocyklem

Beyond Clean Code: Ethernal architectural practises

PREZENTACJA

In this talk we will cover: thinking in terms of abstractions, placing the right language in the right places, fighting with cognitive load and biases, what kinds of coupling can we see and which one is the worst, how to overcome the fear of having many small classes, hot to explain cohesion to a junior developer and more. Those evergreen rules can help you become more efficient and persuasive at work.

(Nie)trudna sztuka modelowania agregatów

WARSZTAT

Agregaty to chyba natrudniejszy element konstrukcyjny taktycznego Domain-Driven Design. Czy naprawdę chodzi tylko (lub aż) o dobrze skrojone programowanie obiektowe?

Dobrze zaprojektowany agregat potrafi wyeliminować potrzebę dokupowania chmury dla naszych czterdziestu mikroserwisów. Źle zaprojektowany agregat potrafi sprawić, że używanie systemu jest koszmarem.

W tym praktycznym warsztacie przejdziemy przez typowe przypadki modelowania i implementacji agregatów. Tak, typowe, bo... nasze projekty mocno się nie różnią. Zahaczymy też o archetypy.

Wymagania

  • Laptop
  • GIT
  • Większość warsztatu odbędzie się na platformie miro.com, więc dobrze się z nią zapoznać (zajmuje sie jakieś 2 minuty)
  • Dodatkowo warto mieć zainstalowane ulubione IDE, ulubiony język oraz klienta git (bo może pojawi się nasz wspólny kod)
  • będziemy pracować w grupach (2-4 osobowych, w zależności od liczby osób)


Jakub Nabrdalik

20 years of designing, building, coding, and operating systems on production. 200+ workshops and lectures. More at nabrdalik.dev

Best practices in practice: things that work for me so well I cannot believe you are not using them

PREZENTACJA

There’s a lot of “best practices” around, but after 20 years of work I’ve found a set that really helps get my systems done well. I’d like to share those tools and methods and why they work in my context. While they are not a novelty (some of them have years of history), I see even experienced developers ignoring them. These include: how to use BDD to work with requirements, using a scientific method to fix problems in production (as opposed to shotgun debugging), verifying observability during development (before going to production), making the most interesting parts visible via higher order functions, and more. Nothing groundbreaking, but perhaps those will also work in your context.


Wojtek Ptak

Wojtek works as Head of Product Engineering at Revolut. Before, he worked as CTO for several companies, provided consulting, training, and assisted in building various data collecting, analytics, and applied ML/AI solutions, including Big Data implementations, data stream processing systems, and data insight projects.

He worked with multiple Forbes 500 brands in the US, UK, and the Netherlands, including The Coca-Cola Company, the American Bankers Association, Macy’s, Bloomingdales, Heineken, Saks 5th Avenue, BP, Boots, Polo Ralph Lauren, Porsche, HSBC, and others.

Hypergrowth scaling made simple

PREZENTACJA

This presentation will present a counterintuitive, straightforward, and business-friendly approach to creating a hyper-scalable systems using surprisingly simple architecture and patterns.

In the presentation, I will discuss how extraordinary simplicity can boost your growth with examples of Revolut's architecture, its advantages, and potential challenges. We will look into what does it mean that a system is complicated, complex, and how to make good architectural decisions to enable fast growth at the hypergrowth stage.

A promise: You will never look at systems of this scale the same way again.


Wiktor Sztajerowski

Wiktor określa się jako cynik, wielbiciel marnych dowcipów i koneser chemexa. Obecnie skupiony na technologiach blockchain. Bywalec salonów konferencyjnych (czasami nawet udaje, że coś wie i mądrzy się ze sceny). Na co dzień programista, architekt lub konsultant - w zależności od potrzeb. Jeden z ojców założycieli konferencji SegFault oraz członek kapituły łódzkiego JUG.

Rewolucja w cyfrowych tożsamościach za sprawą Web3 i Self-Sovereign Identity

PREZENTACJA

Obecnie w kontekście zarządzania naszymi cyfrowymi tożsamościami królują Facebook i Google z swoimi wtyczkami "Zaloguj z...". Takie podejście do zarządzania danymi osobowymi niesie sporo niebezpieczeństw, a nade wszystko oddala użytkownika od jego własnych cyfrowych tożsamości.

Self-Sovereign Identity (SSI) to ruch mający na celu oddać użytkownikowi kontrolę nad własną cyfrową tożsamością oraz tym, komu i jakie dane przekazuje. Pod parasolem SSI, poza ruchem społecznym, kryje się także stos technologiczny implementujący zdecentralizowanych model zarządzania tożsamościami.

Podczas prezentacji porównamy modele zarządzania tożsamościami, czym różni się SSI od już istniejących rozwiązań i - co najistotniejsze - o szczegółach samego SSI. Pomówimy o DID, Verifiable Credentials, Governance Frameworks i co w tym wszystkim robi blockchain.


Barbara Kozioł

Specjalistka do spraw zachowania jakości, fanka podejścia TestOps oraz testów Accessibility. Dbaniem o jakość zajmuje się ponad pięć lat. W Xebia oprócz pracy projekcie zajmuje się koordynowaniem działań Gildii Accessibility. W wolnym czasie spaceruje lub czyta książki.

Dla kogo my to robimy?

PREZENTACJA

Nasza praca to robienie oprogramowania. W pędzie codziennych zadań często myślimy o kolejnych wymaganiach do zaimplementowania, kolejnych pull requestach do wystawienia, o jakości kodu i o tym, żeby wyrobić się w czasie. Czy pamiętamy wtedy o użytkownikach końcowych? Kim są? W jakim wieku są? Skąd pochodzą? Czy mają jakieś specjalne potrzeby? I dlaczego warto rozważać te pytania? Spotkajmy się i porozmawiajmy. Na prezentacji poznacie Darka, personę, która w swojej ewolucji będzie reprezentować wielu z nas.


Piotr Stapp

Programista, inżynier, rzemieślnik, projektant i rowerzysta oraz Microsoft MVP. Korzysta z każdej technologii, która prowadzi do celu. Wierzy w ludzi, a nie w papiery. Tworzy i projektuje oprogramowanie, a to czasem bywa trudne.

Dlaczego buzzwordy szczęścia nie dają

PREZENTACJA

Z jednej strony mówmy wszystko jako kod, z drugiej czasem do szczęścia brakuje nam dwóch kliknięć i gotowe, a kod zajmie nam godziny.
Z jednej strony mówimy HA, redundancja czy mikro-serwisy, a z drugiej nasza aplikacja ma load 300RPH (Request Per Hour w przeciwieństwie do Request Per Second) i przynosi niezłe pieniądze
Z jednej strony walczymy jak lwy w dyskusjach o SOLID, DRY czy YAGNI, a z drugiej siedzimy jak myszki pod miotłą, gdy ktoś porusza temat RODO/GDPR, ochrony danych czy przesyłania danych przez SFTP w plikach CSV.
Z jednej strony budujemy pipeline, które budują docker i wdrażają je na Kubernetes z użyciem Terraform i sprawdzają wszystkie podatności CVE, a z drugiej wypuszczamy naszą aplikację raz na 6 miesięcy i wszędzie musimy robić upgrade.
Z jednej strony na prezentacjach padają te wszystkie buzzword, a z drugiej człowiek wraca do biura i ....
No właśnie "co", o tych 3 kropkach będzie ta prezentacja. Z przykładami z życia, podejściem "na chłopski rozum" i w formie lekkiej dyskusji z Tobą słuchaczu.


Wojciech Rząsa

Informatyk z zamiłowania i z zawodu. Inżynier z doktoratem, administrator, tech-lead, architekt. Od początku kariery blisko systemów rozproszonych, wytwarzania oprogramowania i po prostu programowania. Po 15 latach pracy akademickiej i badania systemów rozproszonych, obecnie tworzy oprogramowanie dla FLYR Inc.. Współtworzy Rzeszowską grupę użytkowników języka Ruby (RRUG.pl). Więcej na linkedin.com/in/wrzasa/.

Microservices, Data, Decoupling and Messages

PREZENTACJA

Co nas czeka, gdy już zrealizujemy naszą nową doskonałą architekturę mikroserwisową? Jakie nieoczekiwane problemy odkryjemy, gdy nasz kod trafi na produkcję?

Rok temu mieliśmy we FLYR monolityczny backend RESTowej aplikacji i powstające wokół niego nowe serwisy. Wiedzieliśmy, że część funkcjonalności tego monolitu będzie potrzebna w nowych produktach tworzonych przez nowe zespoły. Poświęciliśmy sporo czasu i uwagi, żeby nauczyć się jak zaprojektować łatwą w utrzymaniu, skalowalną i luźno powiązaną architekturę mikroserwisów do przetwarzania opartego na danych. Teraz, gdy część pracy jest za nami i działa na produkcji, chciałem Wam opowiedzieć nie tylko, jak to zaprojektowaliśmy, ale przede wszystkim czego się nauczyliśmy już po pierwszych produkcyjnych wdrożeniach.

Chciałbym, żebyście z tej prezentacji dowiedzieli się przede wszystkim, jakie pułapki czekają po wdrożeniu mikroserwisów i na jakie szczegóły warto zwrócić uwagę – problemy, o których często nie mówi się na prezentacjach, bo rzekomo "to oczywiste" i "wszyscy to wiedzą". Ale czy rzeczywiście?


Artur Molendowski Microsoft Azure MVP, Microsoft Certified Trainer (MCT)

W Sii Polska pracuje na stanowisku DevOps/Cloud Engineer. Na co dzień wykorzystuje usługi Microsoft Azure. Buduje i programuje roboty z klocków Lego. Prowadzi podcast „Chwila dla Admina” (chwiladlaadmina.pl) skupiający się szeroko na obszarach IT i nowych technologii. Organizator meetupów Microsoft Azure User Group Poland, prelegent na konferencjach i webinarach.

GitHub Action i GitHub Copilot w pracy DevOps’a

PREZENTACJA

Zadania DevOps’a skupiają się m.in. na pracy z infrastrukturą oraz kodem. Coraz częściej jednak stajemy przed zadaniem automatyzacji wytwarzania oprogramowania czy infrastruktury. Prezentacja skupi się na dwóch narzędziach wspomagających te działania.

W trakcie prezentacji przygotuję workflow w oparciu o GitHub Action wraz z integracją z chmurą Azure i wdrożeniem aplikacji. Przejdziemy przez przykłady automatyzacji pisania kodu infrastruktury wykorzystując GitHub Copilot.


Jakub Koleżyński

Inżynier oprogramowania, dotnetowiec, full stack. Dociekliwie chce wszystko rozłożyć na czynniki pierwsze, a wyzwania traktuje jako szansę do rozwoju. Posiada backendowe korzenie i rozkwitającą pasję do frontendu, ale najbardziej uwielbia po prostu budować - wspólnie, samodzielnie, z potrzeby czy dla eksperymentu, zawsze chce znaleźć najprostsze rozwiązanie. Zawodowo pisał dla różnorodnej widowni, od przemysłu ciężkiego po korporacje finansowe, a aktualnie doskonale bawi się w NewOrbit, wymieniając się doświadczeniem i szlifując swoje rzemiosło.

Autostopem przez JavaScript - Poradnik dla Backendowców

PREZENTACJA

W świecie backendu dość łatwo przychodzi znajomość wielu języków. Paradygmaty się powtarzają, konwencje są podobne, a języki czerpią pomysły od siebie nawzajem. Doświadczeni takim stanem rzeczy, backendowcy coraz chętniej sięgają w stronę full-stacku, po JavaScript. Przecież z roku na rok JavaScript wygląda coraz bardziej znajomo - ma już klasy i w ogóle!

Nie trzeba jednak bardzo się starać, żeby natknąć się na jeden z wielu przypadków, w których JavaScript zachowa się zupełnie inaczej niż byśmy się tego spodziewali. Co? Dlaczego? Kto to wymyślił?! - Na te I inne pytania odpowiedź znajdziemy po drodze do nowej intuicji w tym jakże odmiennym świecie JavaScriptu.


Paweł Zajączkowski

Siedzi we Wrocławskim IT od 2009. Rozgrzebywał kod w fińskim telecomie, niemieckiej logistyce, szwajcarskim banku, fabryce aut, podróżniczym startupie, brytyjskim compliance oraz wynajmie willi. Aktualnie zszedł na ciemną stronę mocy i zajmuje się opieką nad stadkiem programistów i team leaderów, programem mentoringowym, gildiami oraz wtykaniem wszędzie swojego nosa. Prywatnie lubi czytać, grać w planszówki, RPG papierowe i komputerowe, trenuje trójbój siłowy oraz kolekcjonuje stare Lego Technic. Gdy najdzie go wena, pisze o technologii, ludziologii i smokach na HowToTrainYourJava.com.

Syndrom Oszusta w IT

PREZENTACJA

Czy dopada Cię czasami to okropne uczucie, że nie jesteś wystarczająco dobry, żeby robić swoją robotę? Że brak Ci umiejętności, inteligencji i talentu? Że wszyscy wokół Ciebie wiedzą, co robią, a Ty prześlizgujesz się wyłącznie dzięki szczęściu, przypadkowi i sprawianiu wrażenia, że jesteś lepszy, niż w rzeczywistości? Czy żyjesz w strachu, że to jedynie kwestia czasu, aż ktoś wreszcie odkryje, że jesteś zwyczajnym oszustem?

Nie jesteś sam.

Według badań, Syndrom Oszusta dotyka niemal 90% osób pracujących w IT. W tej prezentacji opowiem czym ów syndrom jest, czemu jest tak dominujący w naszej branży, jak wpada się w błędne koło i dokąd można się stoczyć. Omówię, jak znajomość prostych mechanizmów pomoże Ci dostrzec swoje kompetencje oraz jakie triki stosować, żeby nie dać się pokonać demonom niepewności.

*Może zawierać śladowe ilości gumowych kaczuszek.


Michał Żurawski Architekt IT w Fabrity

Michał jest architektem oprogramowania. Zarządzaniem zespołami i prowadzeniem ich pod kątem technicznym zajmuje się od przeszło 5 lat. Na co dzień stara się łączyć prace stricte techniczną z zarządzaniem. Pasjonat czystych i rozszerzalnych rozwiązań. Prywatnie mąż, ojciec i akrobata.

7 grzechów głównych tech leada

PREZENTACJA

Zostałeś tech leadem i co dalej?

W idealnym świcie przejmujesz idealnie zgrany, autonomiczny zespół, który pracuje nad projektem bez grama legacy. Co miesiąc żonglujecie nowymi technologiami, a jedyną sytuacją kryzysową jest brak kawy w biurowej kuchni.

Rzeczywistość wygląda zupełnie inaczej. Zróżnicowany, niezgrany zespół, niskie morale, a może projekt, który jest legacy od momentu pierwszego commita? Czasami to dowolna konfiguracja tych problemów, a czasami wszystkie na raz.

Podczas prezentacji spróbujemy odpowiedzieć sobie na pytania jak prowadzić zespół tak, aby nie zwariować oraz po co i czy, w ogóle, warto zostać tech leadem.


Kamil Mrzygłód

Programista, konsultant, trener, architekt oraz tech lead (w dowolnej kolejności, zależnej od potrzeb). Backgroundowo .NET developer, od wielu lat specjalizuję się w chmurze Azure popełniając po drodze dwie książki na temat wykorzystania jej w kontekście administracji oraz developmentu aplikacji. Pracował z tymi najmniejszymi, jak i największymi klientami w różnych rolach i z różnymi technologiami. W wolnych chwilach rozwija swoje projekty na GitHubie albo robi kolejne podejście do napisania własnej gry komputerowej.

Teściowa potrzebowała Toyotę Yaris więc kupiliśmy jej BMW X6

PREZENTACJA

Praca nad systemem dla nowego klienta to zawsze wyzwanie. Nowe środowisko, inny zakres kompetencji, odmienne oczekiwania. Doradzamy, rozmawiamy, zastanawiamy się – krok po kroku tworzymy nowe usługi oraz komponenty. Mijają tygodnie, potem miesiące, a my coraz bardziej naginamy rzeczywistość, aby zmieścić się w wycenach, estymacjach, celach. W końcu nadchodzi upragniony koniec, idziemy na produkcję i patrzymy z boku na nasze dzieło. Sukces! Skończyliśmy z małym potworkiem, do którego ciężko się przyznać, ale na szczęście mamy kolejny projekt na horyzoncie. Pyk, nowa pozycja w CV a nasza abominacją na całe szczęście zajmie się kto inny.

W trakcie prezentacji porozmawiamy o tym jak bardzo nasze ego przeszkadza w delivery, o czym zapominamy podczas analizy potrzeb klienta i dlaczego musieliśmy przebudować garaż tytułowej teściowej.


Artur Morawski

Od blisko 12 lat zajmuję się tematami związanymi z jakością i oprogramowaniem, w tym testami, automatyzacją, procesami oraz zarządzaniem zespołami QA. Pracowałem przy pełnym spektrum projektów, od embedded, przez aplikacje biznesowe, bankowe i użytkowe, zarówno w chmurze jak i w piwnicy, dla startupów, a także dużych korporacyjnych organizacji. W wolnych chwilach żegluję, a jak spadnie śnieg, rozpoczynam sezon narciarski.

Rola QA w starciu z nadciągającym AI - Czy to koniec testów jakie znamy?

PREZENTACJA

Temat sztucznej inteligencji coraz odważniej wkracza w przestrzeń wytwarzania oprogramowania. Obietnice, jakie składa AI, zawładnęły głowami zarządów wielu firm w naszej branży, co jest wyraźnie widoczne na dzisiejszych rynkach pracy. Artykuły i eksperci opowiadają o korzyściach wynikających z testów z wiodącym udziałem AI, ale czy nie są one składane tylko na kredyt? Czy to koniec testów manualnych, a testerzy staną się zbędni? Czy automatyzacja testów w projektach stanie się standardem? Czy może to tylko kolejne zamieszanie, które dostarczy jeszcze więcej oprogramowania do testów?


Sławomir Sobótka

Od 12 lat jestem trenerem i konsultantem w firmie Bottega IT Minds.

W codziennej pracy integruję Domain Driven Design, Event Storming, style architektoniczne, zwinne procesy wytwórcze i zdrowy rozsądek. Stosuję nadrzędną zasadę: rozpoznać klasę problemu z jaką mamy do czynienia i dobrać do niej odpowiednią klasę narzędzia. Hobbystycznie interesuję się psychologią pozytywną i kognitywistyką. Lubię myśleć o sobie jako entuzjaście Software Craftsmanship.

Modularyzacja - miało być tak pięknie a wyszło jak zwykle

PREZENTACJA

Przepiszmy to! - to hasło padło w niejednym projekcie. Zaciągany latami dług technologiczny i złe decyzje nawarstwiały się, utrudniając coraz to bardziej efektywne rozwijanie projektu i dostarczanie nowych funkcji. Niestety po przepisaniu sporej części systemu często okazuje się, że choć kod jest nowszy, to pierwotne problemy cały czas istnieją dalej... Skuteczna refaktoryzacja to piramida działań na wielu poziomach. W designie kodu, architekturze, rozmowie, organizacji. Jeśli problem jest na wyższej warstwie, na niższej często maskujemy jego skutki. Weźmy więc pod lupę piramidę refaktoryzacji i na bazie realnych doświadczeń z projektów zobaczmy, w jaki sposób i jakimi narzędziami można naprawiać projekt na poszczególnych poziomach.


25 lat mijania się z prawdą

Kto nie chciałby zobaczyć, jak tym wystąpieniem niszczę swoją karierę? Minęło 25 lat, co brzmi jak wyrok za ciężką zbrodnię z mrocznych zakątków kodeksu karnego, ale dla mnie to czas podsumowań. Prezentacja, stand-up, coaching? - nazwijcie to jak chcecie. Będzie o naszej branży, biznesie i o nas samych, o "uniwersalnych kłamstwach", które często powtarzane stają się prawdą. To będzie brutalny przewodnik po karierze w IT. Wielu z was zapewne poczuje się urażonych, ale jestem gotów na to poświęcenie. Czy wybór technologii ma znaczenie? Dlaczego większość stanowisk to "bullshit jobs"? Czy greenfieldy naprawdę są takie fajne? Komu potrzebne są estymaty? Co się dzieje, kiedy nie udaje się dowieźć sprintu? Jak feedback stał się rakiem toczącym organizacje? Dlaczego duża część z nas ma wrażenie, że ciągle robi to samo? I jak w tym bajzlu zachować szacunek do siebie, zdrowie psychiczne i dobrze bawić się przez 25 lat? Postaram się odpowiedzieć na te i inne pytania, które sam sobie stawiam od dłuższego czasu. Ci którzy odsieją śmiech przez łzy w tej prezentacji, odnajdą kilka cennych rad jak pokierować swoją karierą.


Jarosław Pałka Software Consultant/Architect/Trainer

Od ponad 20 lat w branży IT jako administrator baz danych, programista, architekt, manager i „inżynier od spraw katastrof”. Brałem udział w małych, średnich i nonsensownie dużych projektach, prowadzonych zgodnie zasadami „waterfall”, Agile oraz przy braku jakichkolwiek metodyk - z tym samym zawsze skutkiem. Wszystko to doprowadziło mnie do wniosku, że nieważne co robisz, ważne byś robił to dobrze, w najprostszy z możliwych sposobów i przy użyciu właściwych narzędzi, które wykonają pracę za Ciebie. W międzyczasie dałem się porwać ideom TDD oraz Software Craftmanship, do granic możliwości wyeksploatować tak piękne w swej prostocie pomysły jak REST i NoSQL. Porzuciłem je, by zgłębić tajniki „system thinking” i zachwycić się siłą, jaką niesie ze sobą „metafora” oraz by odkryć, że rządzą nami te same prawa „natury”. Niepokorny wyznawca kościoła JVM, badacz bytecode’u i JIT oraz wszelkiej maści parserów, interpreterów i kompilatorów. Na co dzień walczący o lepszą wydajność w Neo4j. Od czasu do czasu można usłyszeć moje niskiej jakości żarty na temat architektury na konferencjach w Polsce. W wolnych chwilach trener w Symentis, autor bloga na http://geekyprimitives.wordpress.com/ oraz samozwańczy dyktator w Radzie Programowej konferencji SegFault.

Wolni jak ślimaki, pasywni jak rurkowce

Jest rok 2023. Postęp technologiczny, który widzimy robi wrażenie. Mimo to pytanie, które w kuluarach zadaje sobie wiele (większość?) firm wytwarzających oprogramowanie brzmi “Co zrobić by software development był u nas szybszy? Okazuje się, że jako ruch Software Craftsmanship mamy odpowiedź na to pytanie.

W trakcie prezentacji spojrzę na temat szybkości wytwarzania oprogramowania – problemy, przyczyny i rozwiązania z różnych perspektyw. Pokażę kto znajduje się w centrum tego zagadnienia i jak może sprawić by było lepiej 😉


Krzysztof Kędzierski Engineering Leader

Swoją przygodę z IT rozpoczynał od ról developerskich, stopniowo wchodząc w role liderskie/managerskie. Pracował w firmach o różnej specyfice jak software house, startup/scaleup, duża firma produktowa, bank inwestycyjny. Specjalizuje się w architekturze na przecięciu z zarządzaniem zespołami i organizacją. Prywatnie: wielki fan piłki nożnej.

Modularyzacja - miało być tak pięknie a wyszło jak zwykle

Przepiszmy to! - to hasło padło w niejednym projekcie. Zaciągany latami dług technologiczny i złe decyzje nawarstwiały się, utrudniając coraz to bardziej efektywne rozwijanie projektu i dostarczanie nowych funkcji. Niestety po przepisaniu sporej części systemu często okazuje się, że choć kod jest nowszy, to pierwotne problemy cały czas istnieją dalej... Skuteczna refaktoryzacja to piramida działań na wielu poziomach. W designie kodu, architekturze, rozmowie, organizacji. Jeśli problem jest na wyższej warstwie, na niższej często maskujemy jego skutki. Weźmy więc pod lupę piramidę refaktoryzacji i na bazie realnych doświadczeń z projektów zobaczmy, w jaki sposób i jakimi narzędziami można naprawiać projekt na poszczególnych poziomach.


Sławomir Sobótka

Od 12 lat jestem trenerem i konsultantem w firmie Bottega IT Minds.

W codziennej pracy integruję Domain Driven Design, Event Storming, style architektoniczne, zwinne procesy wytwórcze i zdrowy rozsądek. Stosuję nadrzędną zasadę: rozpoznać klasę problemu z jaką mamy do czynienia i dobrać do niej odpowiednią klasę narzędzia. Hobbystycznie interesuję się psychologią pozytywną i kognitywistyką. Lubię myśleć o sobie jako entuzjaście Software Craftsmanship.

Dyskrecja DevOpsa. Co robimy w ukryciu?

Bezpieczeństwo danych, wdrożenia na produkcję, milionowe biznesy i dostęp tylko w razie potrzeby. Wszystkie aspekty automatyzacji budowania i wdrażania aplikacji w zabezpieczonym środowisku składają się na obraz zadania, które jednocześnie ma dobrze znane prawidłowe rozwiązania i bardzo łatwo zrealizować je źle. A ponieważ konsekwencje zaniedbań mogą spowodować nagłe zmiany w karierze, to warto o nich pomyśleć wcześniej. Zróbmy to teraz.


Michał Borkowski

Michał tworzy oprogramowanie w Xebia. Kiedy nie programuje, lubi dzielić się wiedzą ze studentami i przypadkowymi przechodniami. W wolnym czasie lubi eksperymentować z niszowymi technologiami i robić proste rzeczy od podstaw - wynajdować koło na nowo. Zwykle używa narzędzia odpowiedniego do zadania, ale jego ulubione środowisko programistyczne to vim + tmux + czarno-biała konsola. Słynie z tego że dzieli się swoją skromną wiedzą z innymi w formie anegdotek, czy tego chcą czy nie.

Beyond Clean Code: Ethernal architectural practises

In this talk we will cover: thinking in terms of abstractions, placing the right language in the right places, fighting with cognitive load and biases, what kinds of coupling can we see and which one is the worst, how to overcome the fear of having many small classes, hot to explain cohesion to a junior developer and more. Those evergreen rules can help you become more efficient and persuasive at work.


Jakub Pilimon

Miłośnik DDD, OOP oraz TDD. Developer/Architekt pod kątem inżynierskim głównie zainteresowany modelowaniem oraz architekturą. Swój wysiłek skupia na czytelności kodu, skalowalności oraz wydajności.

Podczas dotychczasowej kariery projektował oraz implementował systemy dla branży finansowej, medycznej, telekomunikacyjnej oraz energetycznej

Prywatnie fanatyk piłki nożnej, narciarstwa i jazdy motocyklem

Best practices in practice: things that work for me so well I cannot believe you are not using them

There’s a lot of “best practices” around, but after 20 years of work I’ve found a set that really helps get my systems done well. I’d like to share those tools and methods and why they work in my context. While they are not a novelty (some of them have years of history), I see even experienced developers ignoring them. These include: how to use BDD to work with requirements, using a scientific method to fix problems in production (as opposed to shotgun debugging), verifying observability during development (before going to production), making the most interesting parts visible via higher order functions, and more. Nothing groundbreaking, but perhaps those will also work in your context.


Jakub Nabrdalik

20 years of designing, building, coding, and operating systems on production. 200+ workshops and lectures. More at nabrdalik.dev

Rewolucja w cyfrowych tożsamościach za sprawą Web3 i Self-Sovereign Identity

Obecnie w kontekście zarządzania naszymi cyfrowymi tożsamościami królują Facebook i Google z swoimi wtyczkami "Zaloguj z...". Takie podejście do zarządzania danymi osobowymi niesie sporo niebezpieczeństw, a nade wszystko oddala użytkownika od jego własnych cyfrowych tożsamości.

Self-Sovereign Identity (SSI) to ruch mający na celu oddać użytkownikowi kontrolę nad własną cyfrową tożsamością oraz tym, komu i jakie dane przekazuje. Pod parasolem SSI, poza ruchem społecznym, kryje się także stos technologiczny implementujący zdecentralizowanych model zarządzania tożsamościami.

Podczas prezentacji porównamy modele zarządzania tożsamościami, czym różni się SSI od już istniejących rozwiązań i - co najistotniejsze - o szczegółach samego SSI. Pomówimy o DID, Verifiable Credentials, Governance Frameworks i co w tym wszystkim robi blockchain.


Wiktor Sztajerowski

Wiktor określa się jako cynik, wielbiciel marnych dowcipów i koneser chemexa. Obecnie skupiony na technologiach blockchain. Bywalec salonów konferencyjnych (czasami nawet udaje, że coś wie i mądrzy się ze sceny). Na co dzień programista, architekt lub konsultant - w zależności od potrzeb. Jeden z ojców założycieli konferencji SegFault oraz członek kapituły łódzkiego JUG.

Dla kogo my to robimy?

Nasza praca to robienie oprogramowania. W pędzie codziennych zadań często myślimy o kolejnych wymaganiach do zaimplementowania, kolejnych pull requestach do wystawienia, o jakości kodu i o tym, żeby wyrobić się w czasie. Czy pamiętamy wtedy o użytkownikach końcowych? Kim są? W jakim wieku są? Skąd pochodzą? Czy mają jakieś specjalne potrzeby? I dlaczego warto rozważać te pytania? Spotkajmy się i porozmawiajmy. Na prezentacji poznacie Darka, personę, która w swojej ewolucji będzie reprezentować wielu z nas.


Barbara Kozioł

Specjalistka do spraw zachowania jakości, fanka podejścia TestOps oraz testów Accessibility. Dbaniem o jakość zajmuje się ponad pięć lat. W Xebia oprócz pracy projekcie zajmuje się koordynowaniem działań Gildii Accessibility. W wolnym czasie spaceruje lub czyta książki.

Dlaczego buzzwordy szczęścia nie dają

Z jednej strony mówmy wszystko jako kod, z drugiej czasem do szczęścia brakuje nam dwóch kliknięć i gotowe, a kod zajmie nam godziny.
Z jednej strony mówimy HA, redundancja czy mikro-serwisy, a z drugiej nasza aplikacja ma load 300RPH (Request Per Hour w przeciwieństwie do Request Per Second) i przynosi niezłe pieniądze
Z jednej strony walczymy jak lwy w dyskusjach o SOLID, DRY czy YAGNI, a z drugiej siedzimy jak myszki pod miotłą, gdy ktoś porusza temat RODO/GDPR, ochrony danych czy przesyłania danych przez SFTP w plikach CSV.
Z jednej strony budujemy pipeline, które budują docker i wdrażają je na Kubernetes z użyciem Terraform i sprawdzają wszystkie podatności CVE, a z drugiej wypuszczamy naszą aplikację raz na 6 miesięcy i wszędzie musimy robić upgrade.
Z jednej strony na prezentacjach padają te wszystkie buzzword, a z drugiej człowiek wraca do biura i ....
No właśnie "co", o tych 3 kropkach będzie ta prezentacja. Z przykładami z życia, podejściem "na chłopski rozum" i w formie lekkiej dyskusji z Tobą słuchaczu.


Piotr Stapp

Programista, inżynier, rzemieślnik, projektant i rowerzysta oraz Microsoft MVP. Korzysta z każdej technologii, która prowadzi do celu. Wierzy w ludzi, a nie w papiery. Tworzy i projektuje oprogramowanie, a to czasem bywa trudne.

GitHub Action i GitHub Copilot w pracy DevOps’a

Zadania DevOps’a skupiają się m.in. na pracy z infrastrukturą oraz kodem. Coraz częściej jednak stajemy przed zadaniem automatyzacji wytwarzania oprogramowania czy infrastruktury. Prezentacja skupi się na dwóch narzędziach wspomagających te działania.

W trakcie prezentacji przygotuję workflow w oparciu o GitHub Action wraz z integracją z chmurą Azure i wdrożeniem aplikacji. Przejdziemy przez przykłady automatyzacji pisania kodu infrastruktury wykorzystując GitHub Copilot.


Artur Molendowski Microsoft Azure MVP, Microsoft Certified Trainer (MCT)

W Sii Polska pracuje na stanowisku DevOps/Cloud Engineer. Na co dzień wykorzystuje usługi Microsoft Azure. Buduje i programuje roboty z klocków Lego. Prowadzi podcast „Chwila dla Admina” (chwiladlaadmina.pl) skupiający się szeroko na obszarach IT i nowych technologii. Organizator meetupów Microsoft Azure User Group Poland, prelegent na konferencjach i webinarach.

Autostopem przez JavaScript - Poradnik dla Backendowców

W świecie backendu dość łatwo przychodzi znajomość wielu języków. Paradygmaty się powtarzają, konwencje są podobne, a języki czerpią pomysły od siebie nawzajem. Doświadczeni takim stanem rzeczy, backendowcy coraz chętniej sięgają w stronę full-stacku, po JavaScript. Przecież z roku na rok JavaScript wygląda coraz bardziej znajomo - ma już klasy i w ogóle!

Nie trzeba jednak bardzo się starać, żeby natknąć się na jeden z wielu przypadków, w których JavaScript zachowa się zupełnie inaczej niż byśmy się tego spodziewali. Co? Dlaczego? Kto to wymyślił?! - Na te I inne pytania odpowiedź znajdziemy po drodze do nowej intuicji w tym jakże odmiennym świecie JavaScriptu.


Jakub Koleżyński

Inżynier oprogramowania, dotnetowiec, full stack. Dociekliwie chce wszystko rozłożyć na czynniki pierwsze, a wyzwania traktuje jako szansę do rozwoju. Posiada backendowe korzenie i rozkwitającą pasję do frontendu, ale najbardziej uwielbia po prostu budować - wspólnie, samodzielnie, z potrzeby czy dla eksperymentu, zawsze chce znaleźć najprostsze rozwiązanie. Zawodowo pisał dla różnorodnej widowni, od przemysłu ciężkiego po korporacje finansowe, a aktualnie doskonale bawi się w NewOrbit, wymieniając się doświadczeniem i szlifując swoje rzemiosło.

Syndrom Oszusta w IT

Czy dopada Cię czasami to okropne uczucie, że nie jesteś wystarczająco dobry, żeby robić swoją robotę? Że brak Ci umiejętności, inteligencji i talentu? Że wszyscy wokół Ciebie wiedzą, co robią, a Ty prześlizgujesz się wyłącznie dzięki szczęściu, przypadkowi i sprawianiu wrażenia, że jesteś lepszy, niż w rzeczywistości? Czy żyjesz w strachu, że to jedynie kwestia czasu, aż ktoś wreszcie odkryje, że jesteś zwyczajnym oszustem?

Nie jesteś sam.

Według badań, Syndrom Oszusta dotyka niemal 90% osób pracujących w IT. W tej prezentacji opowiem czym ów syndrom jest, czemu jest tak dominujący w naszej branży, jak wpada się w błędne koło i dokąd można się stoczyć. Omówię, jak znajomość prostych mechanizmów pomoże Ci dostrzec swoje kompetencje oraz jakie triki stosować, żeby nie dać się pokonać demonom niepewności.

*Może zawierać śladowe ilości gumowych kaczuszek.


Paweł Zajączkowski

Siedzi we Wrocławskim IT od 2009. Rozgrzebywał kod w fińskim telecomie, niemieckiej logistyce, szwajcarskim banku, fabryce aut, podróżniczym startupie, brytyjskim compliance oraz wynajmie willi. Aktualnie zszedł na ciemną stronę mocy i zajmuje się opieką nad stadkiem programistów i team leaderów, programem mentoringowym, gildiami oraz wtykaniem wszędzie swojego nosa. Prywatnie lubi czytać, grać w planszówki, RPG papierowe i komputerowe, trenuje trójbój siłowy oraz kolekcjonuje stare Lego Technic. Gdy najdzie go wena, pisze o technologii, ludziologii i smokach na HowToTrainYourJava.com.

7 grzechów głównych tech leada

Zostałeś tech leadem i co dalej?

W idealnym świcie przejmujesz idealnie zgrany, autonomiczny zespół, który pracuje nad projektem bez grama legacy. Co miesiąc żonglujecie nowymi technologiami, a jedyną sytuacją kryzysową jest brak kawy w biurowej kuchni.

Rzeczywistość wygląda zupełnie inaczej. Zróżnicowany, niezgrany zespół, niskie morale, a może projekt, który jest legacy od momentu pierwszego commita? Czasami to dowolna konfiguracja tych problemów, a czasami wszystkie na raz.

Podczas prezentacji spróbujemy odpowiedzieć sobie na pytania jak prowadzić zespół tak, aby nie zwariować oraz po co i czy, w ogóle, warto zostać tech leadem.


Michał Żurawski Architekt IT w Fabrity

Michał jest architektem oprogramowania. Zarządzaniem zespołami i prowadzeniem ich pod kątem technicznym zajmuje się od przeszło 5 lat. Na co dzień stara się łączyć prace stricte techniczną z zarządzaniem. Pasjonat czystych i rozszerzalnych rozwiązań. Prywatnie mąż, ojciec i akrobata.

Teściowa potrzebowała Toyotę Yaris więc kupiliśmy jej BMW X6

Praca nad systemem dla nowego klienta to zawsze wyzwanie. Nowe środowisko, inny zakres kompetencji, odmienne oczekiwania. Doradzamy, rozmawiamy, zastanawiamy się – krok po kroku tworzymy nowe usługi oraz komponenty. Mijają tygodnie, potem miesiące, a my coraz bardziej naginamy rzeczywistość, aby zmieścić się w wycenach, estymacjach, celach. W końcu nadchodzi upragniony koniec, idziemy na produkcję i patrzymy z boku na nasze dzieło. Sukces! Skończyliśmy z małym potworkiem, do którego ciężko się przyznać, ale na szczęście mamy kolejny projekt na horyzoncie. Pyk, nowa pozycja w CV a nasza abominacją na całe szczęście zajmie się kto inny.

W trakcie prezentacji porozmawiamy o tym jak bardzo nasze ego przeszkadza w delivery, o czym zapominamy podczas analizy potrzeb klienta i dlaczego musieliśmy przebudować garaż tytułowej teściowej.


Kamil Mrzygłód

Programista, konsultant, trener, architekt oraz tech lead (w dowolnej kolejności, zależnej od potrzeb). Backgroundowo .NET developer, od wielu lat specjalizuję się w chmurze Azure popełniając po drodze dwie książki na temat wykorzystania jej w kontekście administracji oraz developmentu aplikacji. Pracował z tymi najmniejszymi, jak i największymi klientami w różnych rolach i z różnymi technologiami. W wolnych chwilach rozwija swoje projekty na GitHubie albo robi kolejne podejście do napisania własnej gry komputerowej.

Rola QA w starciu z nadciągającym AI - Czy to koniec testów jakie znamy?

Temat sztucznej inteligencji coraz odważniej wkracza w przestrzeń wytwarzania oprogramowania. Obietnice, jakie składa AI, zawładnęły głowami zarządów wielu firm w naszej branży, co jest wyraźnie widoczne na dzisiejszych rynkach pracy. Artykuły i eksperci opowiadają o korzyściach wynikających z testów z wiodącym udziałem AI, ale czy nie są one składane tylko na kredyt? Czy to koniec testów manualnych, a testerzy staną się zbędni? Czy automatyzacja testów w projektach stanie się standardem? Czy może to tylko kolejne zamieszanie, które dostarczy jeszcze więcej oprogramowania do testów?


Artur Morawski

Od blisko 12 lat zajmuję się tematami związanymi z jakością i oprogramowaniem, w tym testami, automatyzacją, procesami oraz zarządzaniem zespołami QA. Pracowałem przy pełnym spektrum projektów, od embedded, przez aplikacje biznesowe, bankowe i użytkowe, zarówno w chmurze jak i w piwnicy, dla startupów, a także dużych korporacyjnych organizacji. W wolnych chwilach żegluję, a jak spadnie śnieg, rozpoczynam sezon narciarski.

Microservices, Data, Decoupling and Messages

Co nas czeka, gdy już zrealizujemy naszą nową doskonałą architekturę mikroserwisową? Jakie nieoczekiwane problemy odkryjemy, gdy nasz kod trafi na produkcję?

Rok temu mieliśmy we FLYR monolityczny backend RESTowej aplikacji i powstające wokół niego nowe serwisy. Wiedzieliśmy, że część funkcjonalności tego monolitu będzie potrzebna w nowych produktach tworzonych przez nowe zespoły. Poświęciliśmy sporo czasu i uwagi, żeby nauczyć się jak zaprojektować łatwą w utrzymaniu, skalowalną i luźno powiązaną architekturę mikroserwisów do przetwarzania opartego na danych. Teraz, gdy część pracy jest za nami i działa na produkcji, chciałem Wam opowiedzieć nie tylko, jak to zaprojektowaliśmy, ale przede wszystkim czego się nauczyliśmy już po pierwszych produkcyjnych wdrożeniach.

Chciałbym, żebyście z tej prezentacji dowiedzieli się przede wszystkim, jakie pułapki czekają po wdrożeniu mikroserwisów i na jakie szczegóły warto zwrócić uwagę – problemy, o których często nie mówi się na prezentacjach, bo rzekomo "to oczywiste" i "wszyscy to wiedzą". Ale czy rzeczywiście?


Wojciech Rząsa

Informatyk z zamiłowania i z zawodu. Inżynier z doktoratem, administrator, tech-lead, architekt. Od początku kariery blisko systemów rozproszonych, wytwarzania oprogramowania i po prostu programowania. Po 15 latach pracy akademickiej i badania systemów rozproszonych, obecnie tworzy oprogramowanie dla FLYR Inc.. Współtworzy Rzeszowską grupę użytkowników języka Ruby (RRUG.pl). Więcej na linkedin.com/in/wrzasa/.

Hypergrowth scaling made simple

This presentation will present a counterintuitive, straightforward, and business-friendly approach to creating a hyper-scalable systems using surprisingly simple architecture and patterns.

In the presentation, I will discuss how extraordinary simplicity can boost your growth with examples of Revolut's architecture, its advantages, and potential challenges. We will look into what does it mean that a system is complicated, complex, and how to make good architectural decisions to enable fast growth at the hypergrowth stage.

A promise: You will never look at systems of this scale the same way again.


Wojtek Ptak

Wojtek works as Head of Product Engineering at Revolut. Before, he worked as CTO for several companies, provided consulting, training, and assisted in building various data collecting, analytics, and applied ML/AI solutions, including Big Data implementations, data stream processing systems, and data insight projects.

He worked with multiple Forbes 500 brands in the US, UK, and the Netherlands, including The Coca-Cola Company, the American Bankers Association, Macy’s, Bloomingdales, Heineken, Saks 5th Avenue, BP, Boots, Polo Ralph Lauren, Porsche, HSBC, and others.

(Nie)trudna sztuka modelowania agregatów

Agregaty to chyba natrudniejszy element konstrukcyjny taktycznego Domain-Driven Design. Czy naprawdę chodzi tylko (lub aż) o dobrze skrojone programowanie obiektowe?

Dobrze zaprojektowany agregat potrafi wyeliminować potrzebę dokupowania chmury dla naszych czterdziestu mikroserwisów. Źle zaprojektowany agregat potrafi sprawić, że używanie systemu jest koszmarem.

W tym praktycznym warsztacie przejdziemy przez typowe przypadki modelowania i implementacji agregatów. Tak, typowe, bo... nasze projekty mocno się nie różnią. Zahaczymy też o archetypy.

Wymagania

  • Laptop
  • GIT
  • Większość warsztatu odbędzie się na platformie miro.com, więc dobrze się z nią zapoznać (zajmuje sie jakieś 2 minuty)
  • Dodatkowo warto mieć zainstalowane ulubione IDE, ulubiony język oraz klienta git (bo może pojawi się nasz wspólny kod)
  • będziemy pracować w grupach (2-4 osobowych, w zależności od liczby osób)


Jakub Pilimon

Miłośnik DDD, OOP oraz TDD. Developer/Architekt pod kątem inżynierskim głównie zainteresowany modelowaniem oraz architekturą. Swój wysiłek skupia na czytelności kodu, skalowalności oraz wydajności.

Podczas dotychczasowej kariery projektował oraz implementował systemy dla branży finansowej, medycznej, telekomunikacyjnej oraz energetycznej

Prywatnie fanatyk piłki nożnej, narciarstwa i jazdy motocyklem

Wydajność aplikacji Java dla ciekawskich

Celem tego warsztatu jest łagodne wprowadzenie Cię w świat wydajności na platformie JVM. Nie wiesz nic o JMH, JFR, async profiler, dlaczego twój kod musi być wygrzewany? Nigdy nie widziałeś "flamegraph"?

Spokojnie. Tego wszystkiego dowiesz się podczas jednodniowego warsztatu. Skupimy się nie tylko na narzędziach, ale także na procesie i technikach optymalizowania wydajności. Weźmiemy na warsztat jeden z sztandarowych modeli przetwarzania danych, "map reduce". Od prostej jednowątkowej implementacji, po wielowątkowe monstrum oparte o fork-join pool, będziemy poznawać techniki i narzędzia pracy z testami wydajnościowymi ( w skali micro, znanymi także jako "microbenchmark").

Będzie też czas na zapoznanie się z mechanizmami JVM, takimi jak just-in-time compiler, garbage collector czy adaptive locking. Więcej informacji na stronie https://jvmperformance.pl/.

Wymagania

  • JDK 20
  • Docker
  • Maven
  • Zaznajomienie się z biznesowymi i technicznymi metodami modularyzacji systemu.
  • IDE


Jarosław Pałka Software Consultant/Architect/Trainer

Od ponad 20 lat w branży IT jako administrator baz danych, programista, architekt, manager i „inżynier od spraw katastrof”. Brałem udział w małych, średnich i nonsensownie dużych projektach, prowadzonych zgodnie zasadami „waterfall”, Agile oraz przy braku jakichkolwiek metodyk - z tym samym zawsze skutkiem. Wszystko to doprowadziło mnie do wniosku, że nieważne co robisz, ważne byś robił to dobrze, w najprostszy z możliwych sposobów i przy użyciu właściwych narzędzi, które wykonają pracę za Ciebie. W międzyczasie dałem się porwać ideom TDD oraz Software Craftmanship, do granic możliwości wyeksploatować tak piękne w swej prostocie pomysły jak REST i NoSQL. Porzuciłem je, by zgłębić tajniki „system thinking” i zachwycić się siłą, jaką niesie ze sobą „metafora” oraz by odkryć, że rządzą nami te same prawa „natury”. Niepokorny wyznawca kościoła JVM, badacz bytecode’u i JIT oraz wszelkiej maści parserów, interpreterów i kompilatorów. Na co dzień walczący o lepszą wydajność w Neo4j. Od czasu do czasu można usłyszeć moje niskiej jakości żarty na temat architektury na konferencjach w Polsce. W wolnych chwilach trener w Symentis, autor bloga na http://geekyprimitives.wordpress.com/ oraz samozwańczy dyktator w Radzie Programowej konferencji SegFault.

Rejestracja uczestników


Rozpoczęcie konferencji


Przerwa obiadowa


Zakończenie konferencji


Przerwa kawowa


After Party

Stary Browar Rzeszowski, Rynek, tuż obok Bristolu.