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.
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ą.
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
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.
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.
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
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.
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
Jakub Nabrdalik
20 years of designing, building, coding, and operating systems on production. 200+ workshops and lectures. More at nabrdalik.dev
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.
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.
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.
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.
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/.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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/.
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.
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
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
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
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.