Segmentation fault (Naruszenie ochrony pamięci); zdarzenie wykrywane przez sprzęt, polegające na korzystaniu przez program z pamięci poza zaalokowanym dla niego obszarem.

W dniach 25-26 listopada 2019 w krakowskim hotelu Metropolo Krakow by Golden Tulip, odbyła się druga edycja (pierwsza znana pod nazwą CoreDump) “niekonferencji” SegFault. Miałem okazję uczestniczyć w tym wydarzeniu, którego hasłem przewodnim było “wszyscy jesteśmy architektami”. Czym tak na prawdę było to wydarzenie, jakie tematy zostały poruszone i co wyróżnia ją w porównaniu do pozostałych, na których miałem okazje być do tej pory? Zapraszam do krótkiej relacji.

Dzień pierwszy – Konferencja jak każda inna

Niestety nie miałem możliwości przybyć dzień wcześniej na “before party”, ale na szczęście udało się to nadrobić. W Krakowie pojawiłem się już o 8 rano jako jeden z pierwszych uczestników wydarzenia. Szybka rejestracja, przy której poza standardowym zestawem notesu, długopisu i plakietki, otrzymaliśmy świetny prezent od organizatorów. Kawa sygnowana logiem SegFault oraz opakowanie ciastek (były pyszne!). Czy dzień mógł zacząć się lepiej? Tak więc platkietka na szyję i ruszamy!

Pierwszy dzień rozpoczął się o 9:15, krótkim wprowadzeniem i przywitaniem uczestników przez Chief Procrastinator Officera Jarka Pełkę . Już 15 minut później zaczynały się pierwsze prezentacje. Do wyboru były dwie ścieżki, na których do wyboru mieliśmy zarówno tematy techniczne jak i soft skille.

Tematyka

Tematami wiodącymi był oczywiście EventSourcing, CQRS, DDD i mikroserwisy. To pokazuje trend, jaki obecnie panuje w programowaniu.

Loosely coupled architecture – jak pozbyć się efektu domina

Prezentacja przygotowana przez Radosława Maziarka,skupiała się przede wszystkim na zaznaczeniu problemu, jak rzadko przykuwamy uwagę do odseparowaniu od siebie komponentów w naszym systemie. Efektem takiego podejścia, bardzo często jest stworzenie trudno zarządzanej “kobyły”, w której każda zmiana powoduje efekt domina – cały system przestaje działać.

W swojej prezentacji Radek pokazał jakimi zasadami należy kierować się w podejściu Loosely coupled architecture – czyli architekturze luźno-powiązanej. W trakcie całej prelekcji poznaliśmy etapy krok po kroku, jak powinna powstawać aplikacja w architekturze luźno powiązanej, a także jak cały nasz wysiłek zepsuć. Poruszane również były tematy budowania zespołu dookoła takiej architektury. Jak należy współpracować, aby ład i porządek już na zawsze panował w naszym systemie.

Konkluzją całej prezentacji była świadomość – na jak mało rzeczy zwracamy uwagę w trakcie projektowania i tworzenia naszej aplikacji, oraz jak wiele elementów ma wpływ na cały system.

EventSourcing & CQRS – zima nadchodzi!

Kolejną prezentacją, na którą się wybrałem była o EventSourcingu i CQRSie. Jej autorem jest Sławomir Jachowicz. Ciekawa prelekcja o tym w jaki sposób stwierdzić, czy CQRS i EventSourcing to rzeczywiście to, czego potrzebujemy w naszym projekcie, czy tylko ulegamy trendowi i chcemy zaimplementować to co modne.

Sama prezentacja dla odmiany nie słodziła jaki to CQRS i ES jest cudowny i nadaje się do wszystkiego. Celem było przedstawienie “ciemnej strony” obu tematów. Sławek pokazał wiele miejsc, w których czyhać mogą na nas pułapki, o których nawet możemy nie mieć pojęcia. Obok problemów, widzieliśmy także wskazówki, jak sobie z nimi poradzić i “przetrwać zimę”.

Cienie i blaski Event Driven Design

Kolejna prezentacja i znów eventy. Ktoś by powiedział nuda… Nic bardziej mylnego. Autorem trzeciej prezentacji, na której miałem przyjemność być, był Oskar Dudycz. Oskar idealnie dopełnił wcześniejszą prelekcję o EventSourcingu i CQRSie odwołując się do tego, co przedstawił Sławek. W wielu miejscach odwoływał się do slajdów poprzednika i wskazywał miejsca, w których bardzo często książkowe przykłady mijają się z prawdziwym życiem.

Oskar w trakcie prezentacji opowiedział o realnym projekcie, w którym brał udział i opisał realne problemy, z jakimi przyszło zmierzyć się programistom. Przykład, który został przedstawiony wskazywał przełomowe momenty, w których system przekształcał się w kierunku rozproszonego monolitu. Bez owijania w bawełnę, Oskar pokazał, w którym momencie trzeba być bardziej pragmatycznym.

SR9KRA-6:=BOOT NR 65536

Po przerwie obiadowej czas wracać do słuchania. Kolejnym przystankiem na SegFault był dla mnie wykład Alicji Kubery zatytułowany “SR9KRA-6:=BOOT NR 65536”. Jak można wywnioskować z samego tytułu prezentacji, łatwo domyślić się, że tym razem nie będzie to CQRS. Tym razem zamiast “bujać w obłokach” i marzyć o utopijnej architekturze w naszym projekcie, schodzimy na ziemię i porozmawiamy o kosmosie. A dokładniej wysłuchaliśmy historii zespołu KRAKsat, która 17 kwietnia tego roku wysłała satelitę na orbitę (oczywiście fizycznie zrobiła to NASA).

Pierwsza prelekcja, która oderwała mnie od tematów, które stricte dotyczą moich projektów. Wysłuchałem historii jak Alicja z web developera, stała się członkiem zespołu, który chciał wysłać satelitę w kosmos. Alicja przedstawiła uczestnikom, ile wysiłku cały zespół musiał włożyć w to, aby wysłać małą kostkę 10x10cm na orbitę. Pełna historia, w której zespół musiał zmierzyć się z ogromną ilością przeciwności losu i problemów, aby nawiązać połączenie, gdy satelita był już w górze. Niestety mimo tak wielkiego wysiłku, do tej pory nie udało się przeprowadzić eksperymentu. Zespół ma czas do kwietnia 2020 roku, aby tego dokonać. Trzymam kciuki, aby się udało i mam nadzieję, że na jakiejś konferencji w 2020 roku zobaczę prezentację “SR9KRA-6:=BOOT NR 65536: Episode 2”.

Był to bardzo ciekawy wykład o tym, jak wiele elementów musi zadziałać, aby udało się przeprowadzić bardzo prosty eksperyment w kosmosie.

Mikroserwisy – od HTTP do Kafki

Prezentację Wojciecha Rząsy chciałem wysłuchać z dwóch powodów. Pierwszym to naturalna chęć poszerzenia swojej wiedzy na temat mikroserwisów, drugą – zobaczenie byłego wykładowcy ze studiów w wykładzie poza zajęciami. Nie zawiodłem się. Sama prezentacja przedstawiała realne problemy, z jakimi w FLYR Inc. zespół Wojtka napotkał. Jakie decyzje w trakcie realizacji komunikacji asynchronicznej podjęli oraz co zrobili, aby to co postanowili, nie było ostateczne.

W trakcie prezentacji przedstawione zostały nie tylko narzędzia, ale także informacje, jak krok po kroku, powstawała cała architektura. W jaki sposób kolejne elementy układanki, doprowadziły zespół do miejsca, w którym są dzisiaj, a także plany odnośnie dalszego rozwoju.

Is your feedback meeting about money?

Jest i ona! Pierwsza (i niestety ostatnia) nietechniczna prezentacja na mojej liście. Wykład Rafała Makara poświęcony całkowicie temu, czego programiści często nie robią. Rozmowie… Ale nie rozmowie o nowym “fjuczerze” jaki wprowadzą w najbliższym sprincie w swoim projekcie przy piątkowym piwie na skypie z kolegami.

Rafał opisał typy feedbacku, z jakimi często możemy się spotkać podczas okresowych “rozmów” w firmie. Od tych najbardziej “korpo”, w których od ilości lukru, aż robi się nam niedobrze, aż po te najprostsze, wyrażające więcej niż 1000 słów “Ile?”. Prezentacja w bardzo prosty, a jednocześnie wymowny sposób eksponuje nam problem rozmów, z jakimi często musimy się zmierzyć. Rafał pokazuje jak ważnym i niedocenianym narzędziem, jest feedback. W jaki sposób, źle dobrane słowa mogą wpłynąć negatywnie nie tylko na relacje miedzy dwiema osobami czy zespołem, ale także samą produktywność i samozadowolenie z własnej pracy.

Immutable tests

Testy… nic odkrywczego. Przecież każdy je pisze i zawsze wszystko świeci się na zielono. Prawda? Gdzieś w idealnym świecie zapewne tak jest. W moim niestety nie, dlatego moim kolejnym wyborem, była prezentacja Grzegorza Miejskiego zatytułowanej “Immutable tests”.

Grzegorz w swoim wystąpieniu poruszył tematykę testów, które po lekkim refactoringu, świecą się bardziej, niż światełka na choince w wigilijny wieczór. Podstawowe zasady i porady, jak uniknąć takich sytuacji, pokazany w praktycznej formie – testów mikroserwisu w Go.

Sama prezentacja może nie była odkrywcza, ale na pewno bardzo przydatna. Po co? Po to, aby przypomnieć sobie podstawy, o których tak często zapominamy. Do czego tak naprawdę służą testy i jak poprawnie je napisać.

Jak DDD ma się do Architektury?

Myślę, że większość zna temat DDD. DDD, którego nas otacza, a czasem nawet osacza. Temat DDD na ostatnim już wykładzie poruszał Marcin Markowski. Marcin DDD rozłożył na części pierwsze, pokazując jednocześnie jak często implementujemy coś, czego nie rozumiemy.

45 minut zupełnie innego podejścia do tematu. Prezentacja pokazuje jak ważne jest zrozumienie biznesu oraz wiedza, w poprawnym doborze technologi, z której chcemy skorzystać. Jak łatwo można popełnić błąd, gdy na siłę chcemy zaimplementować coś, co tak na prawdę nie jest nam potrzebne.

Co jeszcze?

Niestety z powodu dwóch ścierzek, nie mogłem być na wszystkim. Poza wyżej wymienionymi tematami, poruszane również były:

Have you ever wondered about code review? – Sebastian Rabiej
Stres, pies i wypalenie – Joanna Lamch
#ąęszcz – Piotr Przybył
Relatywizm języków programowania – Marek Będkowski
Jestem oszustem – Iwona Kubowicz
Shell, tmux, vim – krótka historia o ostrzeniu piły – Michał Borkowski
Mów do mnie czule – jak się komunikować i przyśpieszyć swoją karierę. – Piotr Stawirej
Nie tylko dla ojców – jak wychowując dzieci nauczyłem się być lepszym programistą – Krzysztof Seroka

Jeśli chcecie dowiedzieć się nieco więcej o powyższych tematach to zapraszam do linku tutaj

Po całodniowych wykładach o godzinie 20:30 zaczął się najważniejszy punkt dnia. After party. Ale to co działo się na After party, zostaje na After party.

Dzień drugi – tu zaczyna się magia

Dzień drugi rozpoczął się o 9:30. Krótkie wprowadzenie, rozdanie nagród konkursowych i jedziemy dalej.

Na początek krótka prezentacja Piotra Nabielca zatytułowana “Produktywny programista”. Jak łatwo się domyślić – Piotrek mówił o tym jak być produktywnym. Przedstawione zostały narzędzia, jakie w wielu przypadkach pozwalają nam zwiększyć naszą produktywność. Zdradzę wam sekret – każda wymaga sporo wysiłku włożonego w pracę nad samym sobą. Sama prezentacja bardzo ciekawa, ale ciężko jest ją w jakiś sposób opisać. Jeśli chcecie popracować nad swoją produktywnością, najlepiej będzie jak sprawdzicie projekt Piotrka produktywni.pl.

Unconference

I przyszedł najważniejsza część dnia. Krótkie wprowadzenie od organizatorów. Na czym to polegało? Na początku każdy, kto chciał porozmawiać na jakiś temat, pisał go na karteczkach, następnie karteczki lądowały na tablicy. Tematy agregowane były w jednym zbiorze i w ten sposób powstały stoliki dyskusyjne. Każdy zainteresowany siadał w grupie, która rozmawiała na konkretny temat i rozmawiał. Zadawał pytania, dzielił się doświadczeniem lub słuchał. Wszystko zależało już od samych uczestników.

Jakie tematy były poruszane? Było ich na prawdę dużo. Od EventSourcingu, przez mikroserwisy, DevOpsy, języki programowania, aż po tematy programowania niskopoziomowe na potrzeby satelity (tak temat z wykładów). Co chwile powstały nowe grupy, zadawane były coraz to trudniejsze pytania i co najważniejsze – padały odpowiedzi. To jak dużo udało się wynieść z tej konkretnej części, zależało już od nas samych. Jeśli uważaliśmy, że temat został wyczerpany – wstawaliśmy od stolika i szliśmy dalej. I tak przez 5 godzin z przerwą na obiad.

W między czasie zorganizowany został jeszcze pokaz live połączenia z satelitą. Niestety spóźniłem się na to wydarzenie.

Ostatnią częścią był “Boiling water – the hard way” prowadzony przez Macieja Nowaka, Marcina Drobika i Tomka Martyniaka. Tę część z powodów osobistych musiałem pominąć, ale patrząc na poziom dwóch dni, obstawiam, że temat był interesujący.

Podsumowanie i podziękowania

Pierwszy raz miałem przyjemność uczestniczyć w wydarzeniu SegFault, i jednego jestem pewien – nie będzie to ostatni raz. Cieszę się, że mogłem być nie tylko uczestnikiem, ale również partnerem medialnym.

Sama konferencja była rewelacyjna. Interesujące tematy, ciekawi prowadzący, dużo informacji. Sporo odpowiedzi i jeszcze więcej zadanych pytań. Luźna i bardzo kameralna atmosfera. Świetni ludzie, z którymi udało się wymienić wiele spostrzeżeń.

Jedyną rzeczą, do której mógłbym się przyczepić, była długość pierwszego dnia. 8 tematów jednego dnia, dało się we znaki. Muszę przyznać, że sam walczyłem ze zmęczeniem przy dwóch ostatnich prezentacjach, starając się wynieść z nich jak najwięcej.

Na sam koniec chciałbym podziękować całej ekipie SegFault i wszystkim uczestnikom. Do zobaczenia jak najszybciej!

P.S. Poniżej garść statystyk i kilka zdjęć.