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
Michał Bartyzel
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.
Konrad Kokosa
Szymon Warda
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ć?
Łukasz Kałużny
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 ;-)
Kamil Gałuszka
Mariusz Gil
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.
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ć.
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/.
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.
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
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
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
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.