Kielce JUG #22

• Talk #1 REST by Mariusz Nartowski

Abstract

Prawie każdy programista w swoich projektach tworzy serwisy RESTful — raz są to zwykłe serwisy w komunikacji pomiędzy frontendem a backendem w standardowej aplikacji przeglądarkowej, w innym przypadku są to duże i autonomiczne internetowe systemy serwujące dostęp REST API do danych biznesowych. Popularne frameworki, w których banalnie tworzy się serwisy REST, jak również sam protokół HTTP dają dużo swobody i nie wymagają większej wiedzy o architekturze REST. Pozostaje więc pytanie czy tworzone przez nas serwisy są na pewno zaprojektowane zgodnie ze sztuką oraz obowiązującymi standardami?

Co to za standardy i o czym mówią, jak powinno wyglądać dojrzałe API —

o tym opowiem podczas mojej prezentacji. Te podstawowe zagadnienia architektury REST każdy z nas powinien znać, a często giną one w gąszczu innych nowinek technologicznych.

Bio

Z IT po raz pierwszy zetknąłem się w okresie, gdy nie było ogólnodostępnego internetu, a wiedzę pozyskiwało się z czasopisma Bajtek. Swoją komercyjną przygodę z programowaniem zaczynałem w czasach, w których Java raczkowała, a Springa jeszcze nie było.

Na mojej drodze zawodowej był zarówno backend jak i frontend. Od kilku lat jestem liderem technicznym projektów IT, ale kodowania na szczęście nie porzuciłem i nieustannie próbuję nadążyć za nowinkami ze świata IT.

Aktualnie zaawansowane frameworki i narzędzia programistyczne rozpieszczają nas i wykonują za nas dużo pracy obniżając technologiczną barierę wejścia. Uważam, że mimo ich zaawansowania musimy wracać do źródeł i znać podstawy danej technologii czy architektury, aby świadomie podejmować trudne decyzje.

• Talk #2 Budowanie kultury code review by Emil Hornung

Abstract

Jaki jest Twój stosunek do code review? Jaki jest stosunek do code review Twojego zespołu, Twojej firmy?

Czy jest to tylko nieprzyjemny obowiązek, który robisz, bo to tzw. “dobra praktyka” i wszyscy to robią?

Czy może czujesz pod skórą, że to ma sens i daje korzyści, ale nadal to nie jest to co lubisz robić i najczęściej odkładasz review tak długo jak tylko się da?

A może robisz code review codziennie, widzisz, że przynosi efekty, ale napotykasz też różne problemy np. to, że trwa to bardzo długo lub to, że ludzie w zespole się kłócą i chciałbyś wiedzieć jak sobie z tym radzić i co zrobić, żeby code review było bardziej efektywne?

Jeśli odpowiedziałeś “tak” na co najmniej jedno z powyższych pytań, zapraszam Cię na moją prezentację, gdzie pokażę Ci jaki jest główny cel code review (i dlaczego nie jest to wyłapywanie błędów), jak robić review efektywnie i z większą przyjemnością oraz jak radzić sobie

z powszechnymi problemami związanymi z tą techniką. Bardzo chętnie poznam też Twoją opinię i doświadczenia w tym temacie.

Bio

Jestem programistą z ponad 9-cio letnim doświadczeniem. W ciągu tych lat zajmowałem się głównie tworzeniem, rozwijaniem i utrzymywaniem aplikacji webowych opartych o Javę, początkowo jako fullstack developer

a w ostatnich latach jako backend developer. Od ponad 4 lat pełnię również rolę tech/team leadera (w różnych firmach i zespołach). Na co dzień jestem entuzjastą TDD i BDD jak również takich technik jak SOLID, KISS czy YAGNI. Przede wszystkim cenię sobie prostotę i zdrowy rozsądek.