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. Co doprowadziło mnie do wniosku, że nieważne co robisz tak długo, jak robisz to dobrze, w najprostszy z możliwych sposobów i używasz właściwych narzędzi, które wykonają pracę za ciebie. W międzyczasie dałem się porwać ideą TDD oraz Software Craftmanship, do granic możliwości wyeksploatować tak piękne w swej prostocie pomysły jak REST i NoSQL, by potem porzucić je, by zgłębić tajniki „system thinking” i zachwycić się siłą jaką niesie z sobą „metafora” i 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 http://symentis.pl i autor bloga na http://geekyprimitives.wordpress.com/ oraz samozwańczy dyktator w radach programowych konferencji.
Powszechnie znaną prawdą jest, iż niewielu z nas przejmuję się wydajnością naszego kodu, jeszcze mniej z nas miało do czynienia z testami wydajnościowymi. Wśród tych z nas, którzy toczą nierówną walkę z wydajnością, wąska garstka z nas jest świadoma jak wiele kryję się w nich kłamstw, niedomówień i fałszywych obietnic. Podczas prezentacji poznamy antywzorce w testowaniu wydajności oraz kilka sprawdzonych w boju praktycznych rad jak nie dać się omamić wynikom testów.
Łukasz Szydło
Programista pasjonat, fan “Software Craftsmanship” i zwinnego podejścia do wytwarzania oprogramowania.
Lubi proste rozwiązania skomplikowanych problemów. Na codzień zajmuje się tematami z zakresu architektury aplikacji biznesowych, Domain-Driven Design, Continuous Delivery, technologii Java oraz testowania automatycznego. Prywatnie mąż, ojciec piątki dzieci.
Skąd wiesz czy piszesz dobry kod?! Bo jest zgodny z konwencjami? Bo statyczna analiza nie wykrywa błędów? Bo przestrzega SOLID, CUPID, DRY, KISS?
Wszystkie te kryteria są niesamowicie subiektywne, bo czy zgadzamy się wszyscy czym jest pojedyncza odpowiedzialność, albo ile linii ma krótką metoda, czy dana klasa wystarczająco enkapsuluje?
I tu pojawia się pytanie, czy da się obiektywnie oceniać kod? W 100% raczej nie, ale da się dużo bardziej niż do tej pory.
Michał Bartyzel
Pracuję w branży IT od 20 lat jako programista, team leader, architekt, przedsiębiorca. Przez wiele lat pomagałem zespołom refaktoryzować kod, od jakiegoś czasu zajmuję się reorganizacją procesów dostarczania oprogramowania oraz usprawnianiem współpracy z klientem. Napisałem kilka książek min. “Oprogramowanie szyte na miarę. Jak rozmawiać z klientem, który nie wie, czego chce?” i “Getting Things Programmed. Droga do efektywności”. Więcej o mnie i o mojej pracy dowiesz się na stronie https://michalbartyzel.pl
Niektórym inżynierom/-kom w pewnym momencie przychodzi do głowy, że są traktowani jako podwykonawcy biznesu. Jeśli jest to klient wewnętrzny to inżynier jest dla biznes po prostu dostawca, a jeśli są w jednej organizacji, to IT jest dla biznesu wewnętrznym podwykonem. Tyle, że Ci inżynierowie/-ki chcą być dla klienta partnerem, nie podwykonem i nie wiedzą jak to zrobić.
Jeśli to, co wyżej napisałem w jakiś sposób odzwierciedla Twoje wewnętrzne przemyślenia, wpadnij na moją prezkę. Podam Ci kilka punktów, na które warto zwrócić uwagę, jeśli chcesz budować partnerską relację z biznesem.
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.
Forget about the spine-chilling tales of managing large–scale systems. It doesn’t have to be a daunting task. We’re here to advocate for battle’s proven simplicity with a pinch of fun. We’ll slice through the Gordian knot of complexity, juggle scalability patterns while uncovering their dark sides, and turn time modelling into a time-travel adventure.
No sale of silver bullets here; instead, we arm you with practical solutions and actionable strategies based on real-world examples and the dark sides of rapid-scaling problems.
Join us to transform your approach to evolving system architecture, leaving you with insights immediately applicable to your work.
CTO Morning Coffee na żywo
Konrad Kokosa
Założyciel https://crowdpub.org, na nowo definiujący sposób pisania i czytania książek. Współzałożyciel inicjatywy https://dotnetos.org mającej na celu nauczanie w obszarze .NET, w szczególności o wydajności aplikacji. Niezależny konsultant programujący od kilkunastu lat, prelegent konferencyjny i autor książki Pro .NET Memory Management. Sceptyczny fan technologii Web3 i blockchain. Microsoft MVP.
Przewidywanie przyszłości na ogół wychodzi kiepsko. Dlatego spróbujmy to zrobić ponownie. Przyjrzymy się pokrótce technologiom, na które hype ostatnio był, jest i będzie - takim jak AI, Web3 czy quantum computing - i zastanowimy się co może przynieść nam, deweloperom, bliższa i dalsza przyszłość.
Oczywiście odpowiemy m.in. na pytanie, czy AI zastąpi programistów, czy era blockchaina już się skończyła, co będzie następnym "hitem" i co z tego wszystkiego wynika dla nas.
Szymon Warda
W IT od czasów kiedy Internet Explorer 6 uchodził za "lepszą" przeglądarkę. Po zrealizowaniu marzenia każdego informatyka, czyli stworzeniu gry, buduję systemy rozproszone. Pasjonat modelowania danych, ewolucyjnego podejścia do architektury i znajdywania balansu między rozwiązaniami białkowymi a technologicznymi. 1/2 PatoArchitektów.
Od zera do wewnętrznej platformy developerskiej. Czyli przejście przez to czego potrzebujemy żeby na koniec mieć wewnętrzną platformę developerską. Jak uzyskać alignment w organizacji, jakie standardy zdefiniować i jak je wdrożyć? Jak wdrażać, monitorować i testować? Kubernetes, zarządzany Kubernetes, czy coś innego? Jak zabezpieczyć? Do czego dalej wykorzystać i jak rozwijać?
CTO Morning Coffee na żywo
Łukasz Kałużny
Pracuje jako doradca technologiczny w zakresie strategii i architektury IT w Protopii, głównie związanych z technologiami chmurowymi i kontenerowymi - z Azure od 2013, Dockerem od 2014, a K8s - 2016/2017. Prowadzi podcast Patoarchitekci.io o technologii skierowany seniorów deweloperów, architektów IT. Od 2012 roku wyróżniany corocznie nagrodą Microsoft MVP.
Pewnie już dziesiątki razy słyszałeś/słyszałaś, że aplikacja ma być niezawodna, wysokodostępna, bla bla bla... że Google ma SRE i jest to super! Serio?!
W trakcie odczarujemy ten marketingowy bełkot i zdefiniujemy, co to w ogóle jest ta cała niezawodność. Do tego dorzucimy kilka dobrych rad, jak tego użyć w praktyce.
A crème de la crème sesji: jeżeli jesteś programistą, usłyszysz, co powiedzieć do adminów i DevOpsów, i vice versa ;-)
CTO Morning Coffee na żywo
Kamil Gałuszka
W branży IT od ponad 15 lat. Organizator (i uczestnik) wielu hackathonów takich jak HackSilesia, Koduj dla Polski, Hacktoberfest, Hackfest itd. Sympatyk i okazjonalny kontrybutor wielu różnych projektów otwartego i wolnego oprogramowania (open source & free software). Współzałożyciel już nie istniejącego Hackerspace Silesia, z sympatią patrzy na środowisko Hackerspace-ów na świecie i w Polsce. Zafascynowany analizą danych.
Na codzień pracuje jako Software Architect w FLYR Inc. Jako prosty człowiek pisał większość życia w Pythonie, ale lubi czasami pisać w innych językach.
Nie zna się na Unikernelach, ale chętnie się o nich ostatnio uczy.
Dzisiaj można bez zmiany kodu:
Mariusz Gil
Software architect interesujący się złożonymi systemami o wysokiej wartości biznesowej, związany głównie z platformami webowymi. Ex-CTO, konsultant, speaker i trener w Bottega IT Minds. Z branżą IT związany od ponad 18 lat. Od kilku lat wykorzystuje EventStorming jako narzędzie do komunikacji pomiędzy zespołami developerskimi i biznesowymi, a także do modelowania oprogramowania w oparciu o DDD, CQRS czy EventSourcing. Uczestnik EventStorming Summit 2017, gdzie wspólnie z innymi zaproszonymi przez Alberto Brandoliniego osobami pracował nad rozwojem tej techniki. Po godzinach oddaje się swoim innym pasjom, fotografii i gitarze elektrycznej.
DDD i jego pozytywy odmieniono już w prezentacjach chyba na wszystkie możliwe przypadki. „Wdrażanie” DDD często może być marszem ku klęsce, bo rzeczywistość nie jest już tak różowa jak na slajdach… Nie mówmy więc kolejny raz o roli i znaczeniu agregatów czy bounded-contextów, ale na konkretnych przykładach pokażmy, jakie pułapki tu czekają i jak można je skutecznie ominąć, aby uniknąć tytułowej porażki i kolejnych szram z Wietnamu.
Grzegorz Piwowarek
Founding Engineer w Quesma, niezależny konsultant/trener, blogger (4comprehension.com). Interesują go systemy rozproszone, bebechy, wydajność i architektura systemów. Krążą plotki, że istnieje tylko w czasie kompilacji.
Mikrousługi już od dłuższego czasu nie są rzadkością na rynku - przez ten czas branża odkryła tysiące sposobów jak wdrażać je źle. Przykładowo: poprzez przywiązanie do starych nawyków przyjaznych monolitom, złych praktyk wdrożeniowych, groteskowej polityki bezpieczeństwa firmy itp.
Podczas tej prelekcji będziemy uczyć się na błędach innych i przypomnimy sobie najważniejsze wnioski wyciągnięte z udanych i nieudanych wdrożeń mikrousług. Skupimy się na kwestiach, które nie zostały poruszone w podobnych prezentacjach.
Tomasz Onyszko
Tomek, jak w wielu przypadkach w swojej karierze, w CTO Morning Coffee obsługuje śrubokręt i taśmę klejącą.
CTO w firmie professional services, którą z braku pasującego mu miejsca do rozwoju sam sobie stworzył (no z kolegami), przez większość swojej kariery odpowiadał "to zależy", różnym firmom na całym świecie (od małych, do tych gigantycznych) jako konsultant. Przez ostatnie kilkanaście lat, łączył budowanie firmy, z decyzjami co do tego jakiej technologii użyć i gdzie jest następne "złote runo IT" i obecnością w szeroko pojętej sieci. Jak sam powiada - "Mam opinię, i nie zawaham się jej użyć", co też często można usłyszeć w "Coffee".
Strona techniczna Coffee, spojrzenie od strony budowania organizacji i biznesu jak i kariery "solo", to to, czego możecie się od niego spodziewać w Coffee.
CTO, Architekt, Konsultant… wszystkie te tytuły brzmią jak wspaniałe pozycje – można robić niesamowite rzeczy i napędzać wdrażanie nowych technologii. Można zobaczyć wspaniałe światy, poznać wspaniałych ludzi i...
Ale czy warto? Czego potrzeba, żeby dojść do jak to się określa "leadership?" Co to wogóle oznacza? Czy to same benefity czy ból istnienia i zgryzota?
Byłem tam, robiłem to to, poniosłem porażki i odniosłem sukcesy jednocześnie. W tej sesji podzielę się doświadczeniami związanych z rozwojem kariery w świecie technologii. 20+ lat w branży, od podstaw, do CTO i prowadzącego firmę.
CTO Morning Coffee na żywo
Sebastian Gębski
Sebastian Gębski, jak sam się określa na swoim blogu "No Kill Switch" - engineering leader (at scale).
Zaprawiony w świecie IT w różnych miejscach i pozycjach, od mrocznego świata konsultingu, przez dynamiczny świat rosnących i upadających startupów, po architekturę w chmurze. Sebastian to nie tylko "No Kill Switch", ale też "no bullshit" podejście do technologii i organizacji. Niejedną organizację i technologię ma za kołnierzem, jasno wyraża swoje przemyślenia i nie bierze jeńców.
Jeżeli zastanawiacie się, kto przygotowuje nasze błyskotliwe pytania i riposty na spotkaniach Coffee, to człowiek, na którego powinniście spojrzeć.
Startup's early days aren't easy: there are always too many topics on your plate and everything is of the highest priority. As a first-time CTO you have to pick your battles wisely - I'll try to help by sharing my experience as a former startup CTO and a person who cooperates with startups on daily basis. There is no single blueprint to follow, but we'll go through major decision points, key concerns to be addressed, most pressing questions to be answered. To illustrate the challenges covered and make it an interactive experience, we will create an artificial startup and take it for a virtual spin together.
CTO Morning Coffee na żywo
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/.
Zastanawiasz jak podnieść swoje deweloperskie kwalifikacje i mieć większy wpływ na projekt? Może kodowanie jeszcze szybciej, czy kolejny framework nie wydają Ci się właściwym kierunkiem rozwoju? A może po prostu szukasz pomysłu na swoją karierę? Jeśli tak, to zapraszam Cię na tę prezentację. Chciałbym Cię zachęcić do zrobienia kolejnego kroku na deweloperskiej ścieżce.
Podczas tej prezentacji opowiem jak poza sprawnym kodowaniem możesz przyczynić się do sukcesu Twojego zespołu. Porozmawiamy co zrobić, żeby zespół inżynierów zabierając się do pracy lepiej rozumiał co ma dostarczyć: jak odkrywać wymagania, jak rozmawiać z właścicielami produktu, jak sprawić, żeby powiedzieli nam o wymaganiach, których sami sobie nie uświadomili.
Podzielę się własnymi doświadczeniami i opowiem w jaki sposób możesz mieć kluczowy wpływ na sukces projektu. Po tej prezentacji będziesz znacznie lepiej rozumieć jak analizować i interpretować wymagania, jakie pytania zadawać i ostatecznie -- co zrobić, żeby Twój zespół mógł szybciej dostarczać lepsze oprogramowanie.
Dawid Pereira
Programista z wieloletnim doświadczeniem w technologiach Microsoft, specjalizujący się w projektowaniu aplikacji skoncentrowanych na potrzebach biznesowych ponad potrzebami realizacji skrytych marzeń architekta. Miłośnik trudnych pytań i prostych rozwiązań. Zwolennik metodyki „5 Why”, Domain-Driven Design oraz pragmatycznych rozwiązań. Przekonany o możliwości utrzymania prostoty kodu dłużej niż przez pierwsze trzy miesiące projektu. Prywatnie szczęśliwy mąż, niespełniony filmowiec, zakochany w Japonii i Natto.
Dlaczego jedne projekty są łatwiejsze od innych i na czym właściwie ta łatwość polega? Czy więcej, "lepiej", mądrzej faktycznie zawsze znaczy lepiej?
Nie wszystko musi być zawsze najnowsze i najlepsze, a dodawanie ficzeru za ficzerem po tygodniu pracy nad nowym projektem niekoniecznie oznacza, że jesteś programistą sigma. Brak fancy wzorców projektowych wbrew pozorom może poprawić czytelność kodu i efektywność pracy, a z czasem wszyscy możemy pokochać bycie STUPID.
Co to znaczy, że mój kod jest prosty/trudny.
Jak minimalizować ryzyko powstania trudnego kodu.
Jak korzystać z wzorców, a nie być przez nie wykorzystywanym.
Jak pokochać bycie STUPID
Jeśli spytasz dowolnego programisty jak wyglądał jego pierwszy projekt to najprawdopodobniej usłyszysz, że był bardzo łatwy/trudny, - niepotrzebne skreśl. Jeśli spytasz o drugi, trzeci i kolejny projekt, znowu dostaniesz jedną z tych dwóch opcji, ale niekoniecznie będą one zawsze takie same.
Od czego to zależy?
Co to właściwie znaczy, że projekt jest łatwy bądź trudny?
Czy system zarządzania linią lotniczą może być łatwiejszy od prostego CRUDa?
O czym będziemy rozmawiać:
Dlaczego jedne projekty są łatwiejsze od innych i na czym właściwie ta łatwość polega? Czy więcej, "lepiej", mądrzej faktycznie zawsze znaczy lepiej?
Nie wszystko musi być zawsze najnowsze i najlepsze, a dodawanie ficzeru za ficzerem po tygodniu pracy nad nowym projektem niekoniecznie oznacza, że jesteś programistą sigma. Brak fancy wzorców projektowych wbrew pozorom może poprawić czytelność kodu i efektywność pracy, a z czasem wszyscy możemy pokochać bycie STUPID.
Co to znaczy, że mój kod jest prosty/trudny.
Jak minimalizować ryzyko powstania trudnego kodu.
Jak korzystać z wzorców, a nie być przez nie wykorzystywanym.
Jak pokochać bycie STUPID
Zaraz, zaraz, prosty do bólu kod, brak wzorców projektowych? A co z DDD, TDD, BDD, DRY, SOLID, (...) - tu wstaw dowolny inny akronim, który lubisz albo fajnie brzmi? Wszystkie z tych technik są pomocne i bardzo często niemalże konieczne do osiągnięcia celu. Przecież wszyscy wiemy, że skomplikowane problemy, wymagają skomplikowanych rozwiązań. Czy na pewno to jest zawsze prawdą, a przede wszystkim czy na pewno Twój problem jest tym z natury skomplikowanych i specyficznych?
Po tej prezentacji spojrzysz na swoje zadania z nowej perspektywy i zyskasz narzędzia, które pomogą Ci pisać "głupi", nudny kod.
Bartosz Pałka
Kiedyś myślał, że odnajdzie się w roli dewelopera. Dzisiaj spełnia się jako Delivery Manager w Xebia Poland. Odpowiada za efektywne dostarczanie rozwiązań w szerokim spektrum technicznych projektów, od aplikacji webowych i mobilnych, przez rozwój backendu, aż po data science. Pasjonat informatyki związany z branżą IT od 10 lat, w tym od 7 lat w ramach projektów komercyjnych. W swojej karierze współpracował zarówno z globalnymi korporacjami, jak i z lokalnymi startupami, wszędzie zauważając zbliżone problemy wpływające na zdolności zespołów do dostarczania na czas...
Jeżeli Twoje estymacje zawsze są idealnie trafione, to nie jest to prezentacja dla Ciebie.
Jeżeli jednak zauważasz, że mimo szczerych chęci często zdarzają Ci się niedoszacowania, a zakres realizowanych projektów z jakiegoś powodu rośnie, to po tej prezentacji będziesz znacznie lepiej rozumieć skąd te problemy się biorą, a także co zrobić, żeby poprawić sytuację w Twoim zespole.
Wieloletnia współpraca z software house’ami pozwoliła mi zauważyć, jak powszechne są wyzwania związane z estymacjami. Okazuje się, że w podobnym stopniu dotyczą one zarówno małych, lokalnych inicjatyw, jak i przedsięwzięć na dużą skalę. To wszystko dlatego, że te problemy często mają wspólny mianownik. Na prezentacji dowiesz się więcej i poznasz praktyczne techniki, które można zastosować, aby zwiększyć szanse na swój projektowy sukces.
Michał Borkowski
Michał tworzy oprogramowanie w Xebia. 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. Lubi kiedy rzeczy działają, a jeszcze bardziej kiedy działają automatycznie i bez nadzoru - nawet jeśli automatyzacja zajmuje więcej czasu niż sama czynność.
Stanowisko DevOps jest tak niedookreślone, że w każdej firmie, może się wiązać z całkiem innym typem pracy. To daje okazję do pracy w bardzo różnych warunkach, z bardzo różnymi typami osób, nierzadko w stresującej atmosferze. Programista, tester, project manager, czy nawet inny DevOps - może być opoką zespołu, albo kijem w szprychach. Kierownik Jiry? Programista-kowboj? Wymienię kilka dobrze znanych antywzorców i propozycje rozwiązań. Znając je, łatwiej sobie z nimi radzić... i nie tworzyć ich samemu.
Powszechnie znaną prawdą jest, iż niewielu z nas przejmuję się wydajnością naszego kodu, jeszcze mniej z nas miało do czynienia z testami wydajnościowymi. Wśród tych z nas, którzy toczą nierówną walkę z wydajnością, wąska garstka z nas jest świadoma jak wiele kryję się w nich kłamstw, niedomówień i fałszywych obietnic. Podczas prezentacji poznamy antywzorce w testowaniu wydajności oraz kilka sprawdzonych w boju praktycznych rad jak nie dać się omamić wynikom testów.
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. Co doprowadziło mnie do wniosku, że nieważne co robisz tak długo, jak robisz to dobrze, w najprostszy z możliwych sposobów i używasz właściwych narzędzi, które wykonają pracę za ciebie. W międzyczasie dałem się porwać ideą TDD oraz Software Craftmanship, do granic możliwości wyeksploatować tak piękne w swej prostocie pomysły jak REST i NoSQL, by potem porzucić je, by zgłębić tajniki „system thinking” i zachwycić się siłą jaką niesie z sobą „metafora” i 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 http://symentis.pl i autor bloga na http://geekyprimitives.wordpress.com/ oraz samozwańczy dyktator w radach programowych konferencji.
Skąd wiesz czy piszesz dobry kod?! Bo jest zgodny z konwencjami? Bo statyczna analiza nie wykrywa błędów? Bo przestrzega SOLID, CUPID, DRY, KISS?
Wszystkie te kryteria są niesamowicie subiektywne, bo czy zgadzamy się wszyscy czym jest pojedyncza odpowiedzialność, albo ile linii ma krótką metoda, czy dana klasa wystarczająco enkapsuluje?
I tu pojawia się pytanie, czy da się obiektywnie oceniać kod? W 100% raczej nie, ale da się dużo bardziej niż do tej pory.
Łukasz Szydło
Programista pasjonat, fan “Software Craftsmanship” i zwinnego podejścia do wytwarzania oprogramowania.
Lubi proste rozwiązania skomplikowanych problemów. Na codzień zajmuje się tematami z zakresu architektury aplikacji biznesowych, Domain-Driven Design, Continuous Delivery, technologii Java oraz testowania automatycznego. Prywatnie mąż, ojciec piątki dzieci.
Niektórym inżynierom/-kom w pewnym momencie przychodzi do głowy, że są traktowani jako podwykonawcy biznesu. Jeśli jest to klient wewnętrzny to inżynier jest dla biznes po prostu dostawca, a jeśli są w jednej organizacji, to IT jest dla biznesu wewnętrznym podwykonem. Tyle, że Ci inżynierowie/-ki chcą być dla klienta partnerem, nie podwykonem i nie wiedzą jak to zrobić.
Jeśli to, co wyżej napisałem w jakiś sposób odzwierciedla Twoje wewnętrzne przemyślenia, wpadnij na moją prezkę. Podam Ci kilka punktów, na które warto zwrócić uwagę, jeśli chcesz budować partnerską relację z biznesem.
Michał Bartyzel
Pracuję w branży IT od 20 lat jako programista, team leader, architekt, przedsiębiorca. Przez wiele lat pomagałem zespołom refaktoryzować kod, od jakiegoś czasu zajmuję się reorganizacją procesów dostarczania oprogramowania oraz usprawnianiem współpracy z klientem. Napisałem kilka książek min. “Oprogramowanie szyte na miarę. Jak rozmawiać z klientem, który nie wie, czego chce?” i “Getting Things Programmed. Droga do efektywności”. Więcej o mnie i o mojej pracy dowiesz się na stronie https://michalbartyzel.pl
Forget about the spine-chilling tales of managing large–scale systems. It doesn’t have to be a daunting task. We’re here to advocate for battle’s proven simplicity with a pinch of fun. We’ll slice through the Gordian knot of complexity, juggle scalability patterns while uncovering their dark sides, and turn time modelling into a time-travel adventure.
No sale of silver bullets here; instead, we arm you with practical solutions and actionable strategies based on real-world examples and the dark sides of rapid-scaling problems.
Join us to transform your approach to evolving system architecture, leaving you with insights immediately applicable to your work.
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.
Przewidywanie przyszłości na ogół wychodzi kiepsko. Dlatego spróbujmy to zrobić ponownie. Przyjrzymy się pokrótce technologiom, na które hype ostatnio był, jest i będzie - takim jak AI, Web3 czy quantum computing - i zastanowimy się co może przynieść nam, deweloperom, bliższa i dalsza przyszłość.
Oczywiście odpowiemy m.in. na pytanie, czy AI zastąpi programistów, czy era blockchaina już się skończyła, co będzie następnym "hitem" i co z tego wszystkiego wynika dla nas.
Konrad Kokosa
Założyciel https://crowdpub.org, na nowo definiujący sposób pisania i czytania książek. Współzałożyciel inicjatywy https://dotnetos.org mającej na celu nauczanie w obszarze .NET, w szczególności o wydajności aplikacji. Niezależny konsultant programujący od kilkunastu lat, prelegent konferencyjny i autor książki Pro .NET Memory Management. Sceptyczny fan technologii Web3 i blockchain. Microsoft MVP.
Od zera do wewnętrznej platformy developerskiej. Czyli przejście przez to czego potrzebujemy żeby na koniec mieć wewnętrzną platformę developerską. Jak uzyskać alignment w organizacji, jakie standardy zdefiniować i jak je wdrożyć? Jak wdrażać, monitorować i testować? Kubernetes, zarządzany Kubernetes, czy coś innego? Jak zabezpieczyć? Do czego dalej wykorzystać i jak rozwijać?
Szymon Warda
W IT od czasów kiedy Internet Explorer 6 uchodził za "lepszą" przeglądarkę. Po zrealizowaniu marzenia każdego informatyka, czyli stworzeniu gry, buduję systemy rozproszone. Pasjonat modelowania danych, ewolucyjnego podejścia do architektury i znajdywania balansu między rozwiązaniami białkowymi a technologicznymi. 1/2 PatoArchitektów.
Pewnie już dziesiątki razy słyszałeś/słyszałaś, że aplikacja ma być niezawodna, wysokodostępna, bla bla bla... że Google ma SRE i jest to super! Serio?!
W trakcie odczarujemy ten marketingowy bełkot i zdefiniujemy, co to w ogóle jest ta cała niezawodność. Do tego dorzucimy kilka dobrych rad, jak tego użyć w praktyce.
A crème de la crème sesji: jeżeli jesteś programistą, usłyszysz, co powiedzieć do adminów i DevOpsów, i vice versa ;-)
Łukasz Kałużny
Pracuje jako doradca technologiczny w zakresie strategii i architektury IT w Protopii, głównie związanych z technologiami chmurowymi i kontenerowymi - z Azure od 2013, Dockerem od 2014, a K8s - 2016/2017. Prowadzi podcast Patoarchitekci.io o technologii skierowany seniorów deweloperów, architektów IT. Od 2012 roku wyróżniany corocznie nagrodą Microsoft MVP.
Dzisiaj można bez zmiany kodu:
Kamil Gałuszka
W branży IT od ponad 15 lat. Organizator (i uczestnik) wielu hackathonów takich jak HackSilesia, Koduj dla Polski, Hacktoberfest, Hackfest itd. Sympatyk i okazjonalny kontrybutor wielu różnych projektów otwartego i wolnego oprogramowania (open source & free software). Współzałożyciel już nie istniejącego Hackerspace Silesia, z sympatią patrzy na środowisko Hackerspace-ów na świecie i w Polsce. Zafascynowany analizą danych.
Na codzień pracuje jako Software Architect w FLYR Inc. Jako prosty człowiek pisał większość życia w Pythonie, ale lubi czasami pisać w innych językach.
Nie zna się na Unikernelach, ale chętnie się o nich ostatnio uczy.
DDD i jego pozytywy odmieniono już w prezentacjach chyba na wszystkie możliwe przypadki. „Wdrażanie” DDD często może być marszem ku klęsce, bo rzeczywistość nie jest już tak różowa jak na slajdach… Nie mówmy więc kolejny raz o roli i znaczeniu agregatów czy bounded-contextów, ale na konkretnych przykładach pokażmy, jakie pułapki tu czekają i jak można je skutecznie ominąć, aby uniknąć tytułowej porażki i kolejnych szram z Wietnamu.
Mariusz Gil
Software architect interesujący się złożonymi systemami o wysokiej wartości biznesowej, związany głównie z platformami webowymi. Ex-CTO, konsultant, speaker i trener w Bottega IT Minds. Z branżą IT związany od ponad 18 lat. Od kilku lat wykorzystuje EventStorming jako narzędzie do komunikacji pomiędzy zespołami developerskimi i biznesowymi, a także do modelowania oprogramowania w oparciu o DDD, CQRS czy EventSourcing. Uczestnik EventStorming Summit 2017, gdzie wspólnie z innymi zaproszonymi przez Alberto Brandoliniego osobami pracował nad rozwojem tej techniki. Po godzinach oddaje się swoim innym pasjom, fotografii i gitarze elektrycznej.
Mikrousługi już od dłuższego czasu nie są rzadkością na rynku - przez ten czas branża odkryła tysiące sposobów jak wdrażać je źle. Przykładowo: poprzez przywiązanie do starych nawyków przyjaznych monolitom, złych praktyk wdrożeniowych, groteskowej polityki bezpieczeństwa firmy itp.
Podczas tej prelekcji będziemy uczyć się na błędach innych i przypomnimy sobie najważniejsze wnioski wyciągnięte z udanych i nieudanych wdrożeń mikrousług. Skupimy się na kwestiach, które nie zostały poruszone w podobnych prezentacjach.
Grzegorz Piwowarek
Founding Engineer w Quesma, niezależny konsultant/trener, blogger (4comprehension.com). Interesują go systemy rozproszone, bebechy, wydajność i architektura systemów. Krążą plotki, że istnieje tylko w czasie kompilacji.
CTO, Architekt, Konsultant… wszystkie te tytuły brzmią jak wspaniałe pozycje – można robić niesamowite rzeczy i napędzać wdrażanie nowych technologii. Można zobaczyć wspaniałe światy, poznać wspaniałych ludzi i...
Ale czy warto? Czego potrzeba, żeby dojść do jak to się określa "leadership?" Co to wogóle oznacza? Czy to same benefity czy ból istnienia i zgryzota?
Byłem tam, robiłem to to, poniosłem porażki i odniosłem sukcesy jednocześnie. W tej sesji podzielę się doświadczeniami związanych z rozwojem kariery w świecie technologii. 20+ lat w branży, od podstaw, do CTO i prowadzącego firmę.
Tomasz Onyszko
Tomek, jak w wielu przypadkach w swojej karierze, w CTO Morning Coffee obsługuje śrubokręt i taśmę klejącą.
CTO w firmie professional services, którą z braku pasującego mu miejsca do rozwoju sam sobie stworzył (no z kolegami), przez większość swojej kariery odpowiadał "to zależy", różnym firmom na całym świecie (od małych, do tych gigantycznych) jako konsultant. Przez ostatnie kilkanaście lat, łączył budowanie firmy, z decyzjami co do tego jakiej technologii użyć i gdzie jest następne "złote runo IT" i obecnością w szeroko pojętej sieci. Jak sam powiada - "Mam opinię, i nie zawaham się jej użyć", co też często można usłyszeć w "Coffee".
Strona techniczna Coffee, spojrzenie od strony budowania organizacji i biznesu jak i kariery "solo", to to, czego możecie się od niego spodziewać w Coffee.
Startup's early days aren't easy: there are always too many topics on your plate and everything is of the highest priority. As a first-time CTO you have to pick your battles wisely - I'll try to help by sharing my experience as a former startup CTO and a person who cooperates with startups on daily basis. There is no single blueprint to follow, but we'll go through major decision points, key concerns to be addressed, most pressing questions to be answered. To illustrate the challenges covered and make it an interactive experience, we will create an artificial startup and take it for a virtual spin together.
Sebastian Gębski
Sebastian Gębski, jak sam się określa na swoim blogu "No Kill Switch" - engineering leader (at scale).
Zaprawiony w świecie IT w różnych miejscach i pozycjach, od mrocznego świata konsultingu, przez dynamiczny świat rosnących i upadających startupów, po architekturę w chmurze. Sebastian to nie tylko "No Kill Switch", ale też "no bullshit" podejście do technologii i organizacji. Niejedną organizację i technologię ma za kołnierzem, jasno wyraża swoje przemyślenia i nie bierze jeńców.
Jeżeli zastanawiacie się, kto przygotowuje nasze błyskotliwe pytania i riposty na spotkaniach Coffee, to człowiek, na którego powinniście spojrzeć.
Zastanawiasz jak podnieść swoje deweloperskie kwalifikacje i mieć większy wpływ na projekt? Może kodowanie jeszcze szybciej, czy kolejny framework nie wydają Ci się właściwym kierunkiem rozwoju? A może po prostu szukasz pomysłu na swoją karierę? Jeśli tak, to zapraszam Cię na tę prezentację. Chciałbym Cię zachęcić do zrobienia kolejnego kroku na deweloperskiej ścieżce.
Podczas tej prezentacji opowiem jak poza sprawnym kodowaniem możesz przyczynić się do sukcesu Twojego zespołu. Porozmawiamy co zrobić, żeby zespół inżynierów zabierając się do pracy lepiej rozumiał co ma dostarczyć: jak odkrywać wymagania, jak rozmawiać z właścicielami produktu, jak sprawić, żeby powiedzieli nam o wymaganiach, których sami sobie nie uświadomili.
Podzielę się własnymi doświadczeniami i opowiem w jaki sposób możesz mieć kluczowy wpływ na sukces projektu. Po tej prezentacji będziesz znacznie lepiej rozumieć jak analizować i interpretować wymagania, jakie pytania zadawać i ostatecznie -- co zrobić, żeby Twój zespół mógł szybciej dostarczać lepsze oprogramowanie.
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/.
Dlaczego jedne projekty są łatwiejsze od innych i na czym właściwie ta łatwość polega? Czy więcej, "lepiej", mądrzej faktycznie zawsze znaczy lepiej?
Nie wszystko musi być zawsze najnowsze i najlepsze, a dodawanie ficzeru za ficzerem po tygodniu pracy nad nowym projektem niekoniecznie oznacza, że jesteś programistą sigma. Brak fancy wzorców projektowych wbrew pozorom może poprawić czytelność kodu i efektywność pracy, a z czasem wszyscy możemy pokochać bycie STUPID.
Co to znaczy, że mój kod jest prosty/trudny.
Jak minimalizować ryzyko powstania trudnego kodu.
Jak korzystać z wzorców, a nie być przez nie wykorzystywanym.
Jak pokochać bycie STUPID
Jeśli spytasz dowolnego programisty jak wyglądał jego pierwszy projekt to najprawdopodobniej usłyszysz, że był bardzo łatwy/trudny, - niepotrzebne skreśl. Jeśli spytasz o drugi, trzeci i kolejny projekt, znowu dostaniesz jedną z tych dwóch opcji, ale niekoniecznie będą one zawsze takie same.
Od czego to zależy?
Co to właściwie znaczy, że projekt jest łatwy bądź trudny?
Czy system zarządzania linią lotniczą może być łatwiejszy od prostego CRUDa?
O czym będziemy rozmawiać:
Dlaczego jedne projekty są łatwiejsze od innych i na czym właściwie ta łatwość polega? Czy więcej, "lepiej", mądrzej faktycznie zawsze znaczy lepiej?
Nie wszystko musi być zawsze najnowsze i najlepsze, a dodawanie ficzeru za ficzerem po tygodniu pracy nad nowym projektem niekoniecznie oznacza, że jesteś programistą sigma. Brak fancy wzorców projektowych wbrew pozorom może poprawić czytelność kodu i efektywność pracy, a z czasem wszyscy możemy pokochać bycie STUPID.
Co to znaczy, że mój kod jest prosty/trudny.
Jak minimalizować ryzyko powstania trudnego kodu.
Jak korzystać z wzorców, a nie być przez nie wykorzystywanym.
Jak pokochać bycie STUPID
Zaraz, zaraz, prosty do bólu kod, brak wzorców projektowych? A co z DDD, TDD, BDD, DRY, SOLID, (...) - tu wstaw dowolny inny akronim, który lubisz albo fajnie brzmi? Wszystkie z tych technik są pomocne i bardzo często niemalże konieczne do osiągnięcia celu. Przecież wszyscy wiemy, że skomplikowane problemy, wymagają skomplikowanych rozwiązań. Czy na pewno to jest zawsze prawdą, a przede wszystkim czy na pewno Twój problem jest tym z natury skomplikowanych i specyficznych?
Po tej prezentacji spojrzysz na swoje zadania z nowej perspektywy i zyskasz narzędzia, które pomogą Ci pisać "głupi", nudny kod.
Dawid Pereira
Programista z wieloletnim doświadczeniem w technologiach Microsoft, specjalizujący się w projektowaniu aplikacji skoncentrowanych na potrzebach biznesowych ponad potrzebami realizacji skrytych marzeń architekta. Miłośnik trudnych pytań i prostych rozwiązań. Zwolennik metodyki „5 Why”, Domain-Driven Design oraz pragmatycznych rozwiązań. Przekonany o możliwości utrzymania prostoty kodu dłużej niż przez pierwsze trzy miesiące projektu. Prywatnie szczęśliwy mąż, niespełniony filmowiec, zakochany w Japonii i Natto.
Jeżeli Twoje estymacje zawsze są idealnie trafione, to nie jest to prezentacja dla Ciebie.
Jeżeli jednak zauważasz, że mimo szczerych chęci często zdarzają Ci się niedoszacowania, a zakres realizowanych projektów z jakiegoś powodu rośnie, to po tej prezentacji będziesz znacznie lepiej rozumieć skąd te problemy się biorą, a także co zrobić, żeby poprawić sytuację w Twoim zespole.
Wieloletnia współpraca z software house’ami pozwoliła mi zauważyć, jak powszechne są wyzwania związane z estymacjami. Okazuje się, że w podobnym stopniu dotyczą one zarówno małych, lokalnych inicjatyw, jak i przedsięwzięć na dużą skalę. To wszystko dlatego, że te problemy często mają wspólny mianownik. Na prezentacji dowiesz się więcej i poznasz praktyczne techniki, które można zastosować, aby zwiększyć szanse na swój projektowy sukces.
Bartosz Pałka
Kiedyś myślał, że odnajdzie się w roli dewelopera. Dzisiaj spełnia się jako Delivery Manager w Xebia Poland. Odpowiada za efektywne dostarczanie rozwiązań w szerokim spektrum technicznych projektów, od aplikacji webowych i mobilnych, przez rozwój backendu, aż po data science. Pasjonat informatyki związany z branżą IT od 10 lat, w tym od 7 lat w ramach projektów komercyjnych. W swojej karierze współpracował zarówno z globalnymi korporacjami, jak i z lokalnymi startupami, wszędzie zauważając zbliżone problemy wpływające na zdolności zespołów do dostarczania na czas...
Stanowisko DevOps jest tak niedookreślone, że w każdej firmie, może się wiązać z całkiem innym typem pracy. To daje okazję do pracy w bardzo różnych warunkach, z bardzo różnymi typami osób, nierzadko w stresującej atmosferze. Programista, tester, project manager, czy nawet inny DevOps - może być opoką zespołu, albo kijem w szprychach. Kierownik Jiry? Programista-kowboj? Wymienię kilka dobrze znanych antywzorców i propozycje rozwiązań. Znając je, łatwiej sobie z nimi radzić... i nie tworzyć ich samemu.
Michał Borkowski
Michał tworzy oprogramowanie w Xebia. 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. Lubi kiedy rzeczy działają, a jeszcze bardziej kiedy działają automatycznie i bez nadzoru - nawet jeśli automatyzacja zajmuje więcej czasu niż sama czynność.
CTO Morning Coffee na żywo
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.
Szymon Warda
W IT od czasów kiedy Internet Explorer 6 uchodził za "lepszą" przeglądarkę. Po zrealizowaniu marzenia każdego informatyka, czyli stworzeniu gry, buduję systemy rozproszone. Pasjonat modelowania danych, ewolucyjnego podejścia do architektury i znajdywania balansu między rozwiązaniami białkowymi a technologicznymi. 1/2 PatoArchitektów.
Łukasz Kałużny
Pracuje jako doradca technologiczny w zakresie strategii i architektury IT w Protopii, głównie związanych z technologiami chmurowymi i kontenerowymi - z Azure od 2013, Dockerem od 2014, a K8s - 2016/2017. Prowadzi podcast Patoarchitekci.io o technologii skierowany seniorów deweloperów, architektów IT. Od 2012 roku wyróżniany corocznie nagrodą Microsoft MVP.
Tomasz Onyszko
Tomek, jak w wielu przypadkach w swojej karierze, w CTO Morning Coffee obsługuje śrubokręt i taśmę klejącą.
CTO w firmie professional services, którą z braku pasującego mu miejsca do rozwoju sam sobie stworzył (no z kolegami), przez większość swojej kariery odpowiadał "to zależy", różnym firmom na całym świecie (od małych, do tych gigantycznych) jako konsultant. Przez ostatnie kilkanaście lat, łączył budowanie firmy, z decyzjami co do tego jakiej technologii użyć i gdzie jest następne "złote runo IT" i obecnością w szeroko pojętej sieci. Jak sam powiada - "Mam opinię, i nie zawaham się jej użyć", co też często można usłyszeć w "Coffee".
Strona techniczna Coffee, spojrzenie od strony budowania organizacji i biznesu jak i kariery "solo", to to, czego możecie się od niego spodziewać w Coffee.
Sebastian Gębski
Sebastian Gębski, jak sam się określa na swoim blogu "No Kill Switch" - engineering leader (at scale).
Zaprawiony w świecie IT w różnych miejscach i pozycjach, od mrocznego świata konsultingu, przez dynamiczny świat rosnących i upadających startupów, po architekturę w chmurze. Sebastian to nie tylko "No Kill Switch", ale też "no bullshit" podejście do technologii i organizacji. Niejedną organizację i technologię ma za kołnierzem, jasno wyraża swoje przemyślenia i nie bierze jeńców.
Jeżeli zastanawiacie się, kto przygotowuje nasze błyskotliwe pytania i riposty na spotkaniach Coffee, to człowiek, na którego powinniście spojrzeć.