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.