Czego nauczyłem się na Web Summer Camp 2018?

Wraz z pierwszym jesiennym deszczem, w miniony weekend oficjalnie pożegnaliśmy lato – czas urlopów, plażingu i oczywiście letniego dokształcania się i rozwijania swoich umiejętności m.in. na Web Summer Camp, w którym miałem przyjemność uczestniczyć. Było dużo nowych doświadczeń, wrażeń i całkiem sporo konkretnej wiedzy, którą chciałem od razu po powrocie zastosować w projekcie. Nie wiedzieć czemu, wywołało to u kolegów z zespołu nerwowe uśmiechy.

Teraz, po kilku tygodniach, kiedy pogoda za oknem wywiała już z głowy tę całą gorączkę, mogę spróbować obiektywnie odnieść się do czysto technicznego aspektu mojego uczestnictwa w tym wydarzeniu. Spróbuję podsumować czego się nauczyłem, czy udało mi się to zastosować to w praktyce i koniec końców czy rzeczywiście warto było jechać.

Nie można mieć wszystkiego

Tego typu konferencje – czy może raczej ogólniej wydarzenia dla programistów – mają to do siebie, że kupując bilet przed ogłoszeniem agendy, nie masz pewności co konkretnie zobaczysz. W przypadku Web Summer Camp jest jeszcze trudniej bo musisz podjąć decyzję odnośnie ścieżki w której będziesz uczestniczył. W przeciwieństwie do klasycznych konferencji, gdzie masz możliwość przemieszczania się między salami pomiędzy wykładami. Więc jeżeli jesteś osobą o wielu zainteresowaniach to masz problem.

Ja wybrałem oczywiście PHP, zgodnie ze specjalizacją, aczkolwiek trochę żałowałem, że automatycznie rezygnuję z JS. Większy problem pojawił się gdy już pojawiła się agenda całej imprezy. Okazało się, że dla PHP będą dwie równoległe ścieżki, czyli nawet w ramach tej jednej specjalizacji nie ma szans aby uczestniczyć we wszystkim co nas interesuje. Nie jestem człowiekiem, który ma problemy z podejmowaniem decyzji, było mi po prostu szkoda. Cóż jest to coś z czym trzeba się pogodzić. Ważne jest, aby, jak już zaplanujemy sobie warsztaty w których będziemy uczestniczyć, nie zmieniać decyzji, ale o tym później…

Każde rozwiązanie jest dobre

Wykładowcy z którymi miałem pracować byli różni. Niektórzy to starzy wyjadacze konferencji i warsztatów jak Stefan Priebsch, inni to młodzi starający się wyrobić dla siebie markę jak Hugo Hamon czy Tobias Nyholm. Nie każdy z nich radził sobie równie dobrze. Przypuszczam, że do przekazywania wiedzy potrzebny jest jakiś talent. Niemniej na wszystkich warsztatach w jakich uczestniczyłem, każdy z nich podkreślał, że nie ma idealnych czy też poprawnych rozwiązań. Każdy z nich podchodził do swojego kodu z pokorą, mówiąc, że ja to rozwiązałem tak, jeżeli ty to zrobiłeś inaczej a działa po poprawnie to świetnie.

Doświadczenie takiego podejścia ze strony, jakby nie patrzeć celebrytów świata programowania, w pewnym sensie odpowiedników „dyktatorów mody”, otworzyło mi oczy i utwierdziło mnie w tym co czułem podskórnie od dawna. Najważniejsze aby kod działał i żadne działające rozwiązanie nie może być z gruntu złe, bądź niewłaściwe. Choć może nie jest to nic niezwykłego, dla mnie osobiście było to niezwykle pozytywne i bardzo motywujące doświadczenie. Uważam, że warto to przesłanie nieść i przekazywać dalej.

Nie unikniesz kiepskich wykładów, ale warto wyciągnąć z nich lekcję

Dwa pierwsze dni warsztatów były strzałem w dziesiątke. Trzymałem się zaplanowanego kursu, nawet jeżeli miało to oznaczać pozostawienie kolegów samym sobie (obaj wybrali drugą ścieżkę). Oba warsztaty były interesujące i pełne nowych doświadczeń, więcej zaraz.

Niestety trzeciego dnia w ostatniej minucie zmieniłem pierwotny plan. Trochę to wina kolegów ;), a trochę intrygującego tematu – „Server side rendering of React with Symfony”. Tym samym zrezygnowałem z dwóch bloków o PHP Security, które również zapowiadały się ciekawie.

Na wybranej ścieżce (z Reactem) w drugim bloku miał wystąpić Tobias Nyholm z „Knowing your state machines”, przed którym (muszę im to przyznać) koledzy mnie ostrzegali. Ale jako, że nie lubię wchodzić na zajęcia w połowie (a alternatywą była tylko druga część „PHP Security”) postanowiłem zostać na tej ścieżce i pójść na maszyny stanowe.

Pierwsza część zajęć (do przerwy była jeszcze ok). Zbudowaliśmy swoją własną, bardzo prostą maszynę stanową, klasyczny przykład – światła uliczne (pojawił się też na innym wykładzie). Niestety później wydarzyło się coś czego się nie spodziewałem. W drugiej części mieliśmy zrobić to samo tylko, że korzystając z narzędzi istniejących w Symfony (bez uprzedniego wprowadzenia w te narzędzia). Oczywistym jest, że dla kogoś, kto zna Symfony w stopniu wysokim i pracował już z maszynami stanowymi to nie byłby żadne wyzwanie. No właśnie. I tu tkwi sedno problemu. Osoby z doświadczeniem, które wiedzą jak tworzyć i zarządzać maszynami stanowymi nie pojawiłby się na tym warsztacie. Może gdyby w pierwszej części pokazałby klasy jak Transition, DefinitionBuilder, czy Workflow jak działają i jak się nimi posługiwać, druga część miałaby więcej sensu. A tak skończyło się na nieco frustrującym kombinowaniu i pospiesznym czytaniu dokumentacji, a ogarnięcie tego w godzinę, to dla mnie trochę za mało.

Należy oczywiście dostrzegać pozytywy w każdym doświadczeniu życiowym, także i tutaj znalazło się ich kilka. Na pewno była to dla mnie lekcja pokory – zawsze istnieje coś czego jeszcze możesz się nauczyć. Poza tym sama idea maszyn stanowych przedstawiona w bardzo ogólnej i krótkiej części teoretyczniej pokazała mi, że jest to narzędzie z którego powinniśmy korzystać znacznie śmielej, ponieważ wiele rzeczy które modelujemy, możemy modelować właśnie jako maszyny stanowe, a takie podejście i wbudowane w Symfony narzędzia mogą nam wiele ułatwić. Dowiedziałem się również, że Tobias jest współautorem maszyn stanowych w Symfony co w pewnym stopniu tłumaczy te jego niekończące się tourne z maszynami stanowymi. Koniec końców poznałem swoje słabe punkty, a to zawsze jest wartościowe. Na następne zajęcia z Tobiasem na pewno przyjdę lepiej przygotowany.

Wzorce projektowe FTW!

Lubię wzorce projektowe. Podoba mi się ich elegancja, prostota i niezaprzeczalna efektywność. Nie znajdziesz programisty, który powie – „Wzorce projektowe? Meh.”, no chyba, że będzie to potomek kolesia, który pierwszy powiedział „I nazywasz to kołem? Meh.”. Wzorce projektowe to efekt lat doświadczeń, a przede wszystkim rezultat imponująco przemyślanego i wnikliwego intelektualnego procesu twórczego. Powstały, jak większość najbardziej wartościowych rzeczy w programowaniu, pod koniec ubiegłego stulecia i do dziś, co potwierdza ich uniwersalność i poprawność mogą być, i są wykorzystywane z powodzeniem w każdym języku programowania. Oczywiście teoretyczna znajomość wzorców nie wystarczy, trzeba umieć wykorzystać je w praktyce. Oczywiście każdy z nas, programistów, z pewnością stara się to robić, ale osobiście jestem daleki od uznanaia się za eksperta. Dlatego w ogóle nie zastanawiałem się przed wyborem „Practical design patterns in PHP”. Jak zwykłem mawiać wykład z wzorców to zawsze dobry plan na piątkowy wieczór ;).

Okazało się, że ten warsztat to doskonały wybór. Hugo Hamon to początkujący, ale w gruncie rzeczy dobry prowadzący, który z pewnością w kolejnych latach nabierze doświadczenia. Był konkretny, bezpośredni, mówił wyraźnie i nie silił się na żarty, ponieważ, jak sam przyznał wykład po angielsku to dla niego nowość (jest Francuzem). Początkowa część wykładu była powtórzeniem podstaw – czyli zasada SOLID, oraz pokazanie różnych technik i sposobów w jaki utrzymywać kod w dobrym stanie. Dalsza część, czyli właściwe warsztaty miały nietrudną do przewidzenia formę – teoretyczne wprowadzenie nowego wzorca i jego implementacja w PHP, którą wykonywaliśmy sami zgodnie z wymaganiami. Hugo chodził, doradzał i odpowiadał na pytania, a na końcu prezentował własne rozwiązanie. Same wzorce zostały zaprezentowane możliwie prosto (z przykładami i zrozumiałymi definicjami). Oczywiście czasu by nie starczyło gdybyśmy chcieli przećwiczyć każdy z wzorców, dlatego zdążyliśmy popracować tylko na kilku wybranych – Composite, Builder, ValueObject, Abstract Factory i Factory Method, a także Memento (wcześniej nie znałem). Z tego ostatniego zresztą bardzo płynnie przeszliśmy do Event Sourcingu, jako, że jest to jeden ze sposobów implementacji tego wzorca.

Możliwość praktycznego wykorzystania wzorców, garść bardzo przydatnych wskazówek odnośnie programowania i utrzymywania kodu, nowe wzorce, a także bardzo obszerna i bogata prezentacja – te warsztaty to była czysta przyjemność.

Testy, testy, wszędzie testy

Nie do końca wiedziałem, czego spodziewać się po warsztatach o tytule „Code like a pro”, które miał poprowadzić Stefan Priebsch. Dla tych, którzy go nie znają – Stefan to konsultant, autor i doświadczony wykładowca, który miał znaczący udział w tworzeniu PHPUnit (najpopularniejszego rozwiązania do testów jednostkowych w PHP). Pomyślałem, że wszystko co możesz się nauczyć od zawodnika wagi ciężkiej jakim Stefan niewątpliwie jest, musi być wartościowe. Muszę przyznać, że dla tego wykładu zrezygnowałem z wykładu o TDD (Test Driven Developement) na równoległej ścieżce, a zdecydowałem się na to głównie ze względu na Stefana.

Zaczęło się niewinnie od wprowadzenia do tematu warsztatów, czyli jaki problem mamy do rozwiązania. Padło na rezerwację leżaków hotelowych. Potem zaskoczenie – okazało się, że problem został zaprezentowany w taki sposób, że właściwie jego rozwiązywanie zaczęliśmy od pisania testów jednostkowych, które w płynny sposób spowodowały tworzenie obiektów domenowych. Koniec końców sami mieliśmy dostosować funkcjonalność domeny do napisanych wcześniej testów. Super. Byłem pozytywnie zaskoczony, zrezygnowałem z zajęć o TDD aby pójść na zajęcia o TDD. No i wniosek nasuwa się sam – chcesz kodować jak profesjonalista – korzystaj z TDD.

Eksperymenty międzytechnologiczne

Wcześniej wspomniany warsztat z renderowania po stronie serwera (React) to swojego rodzaju eksperyment, który prowadzący Nacho Martín rozwija od kilku lat i sprawdza się w środowisku produkcyjnym. Sprawdza się do tego stopnia, że autor postanowił dołożyć swoją cegiełkę do świata Open Source i udostępnił stworzone biblioteki pozwalające wykorzystać Reacta po stronie serwera w Symfony. Na warsztacie mieliśmy okazję sprawdzić jego narzędzia i wiedzę w praktyce, krok po kroku tworząc działające rozwiązanie.

Jako, że jestem programistą głównie backendu to doświadczenie nabyte na tych zajęciach, nie przyda mi się w żadnym z bieżących projektów, ale kto wie, może w przyszłości. Niemniej warsztaty i tak były interesujące – zarówno sama koncepcja, jak i wykorzystane narzędzia (Symfony, node.js, React) to ciekawy eksperyment. Jeden z tych, które testowało się w młodości, aby po prostu sprawdzić czy coś takiego jest możliwe. Warto wiedzieć, że taka możliwość istnieje i w razie potrzeby móc sięgnąć do notatek z warsztatu.

Dobre praktyki

Poza tymi wszystkimi warsztatami jest jeszcze jedna dobra rzecz, którą można wynieść z tego typu wydarzenia. Możliwość zobaczenia jak tworzą kod inni profesjonaliści, ludzie doświadczeni w branży. Jakich bibliotek używają, jak konstruują obiekty domenowe, jak rozdzielają funkcjonalności – to wszystko samo w sobie ma niezwykłą wartość. Przyznam się, że dopiero po Web Summer Camp zacząłem nagminnie korzystać z biblioteki Assertion, gdy zauważyłem jak niezwykle jest przydatna w kodzie Stefana i Hugo. Single Responsibility i Open-Closed Principle znałem oczywiście wcześniej, ale teraz jakby staram się bardziej do nich stosować. Utrwalanie dobrych praktyk to z pewnością ogromna zaleta tego typu spotkania.

Słowo na zakończenie

Było warto. To nie ulega wątpliwości. Czy wprowadziłem zmiany w projekcie? Na pewno staram się tworzyć lepszy kod. Udało mi się z powodzeniem wykorzystać w nowej gałęzi kilka wzorców projektowych i bardzo przykładam się do stosowania wszystkich poznanych zasad i reguł. Zwracam uwagę na to co robi klasa i czy robi rzeczywiście tylko jedną rzecz, czy spełnia zasadę open-closed itp. Zacząłem pisać testy, tak te testy na które zawsze brakuje czasu, nie jest to oczywiście TDD, ale przynajmniej jak tylko mogę wcisnę kilka testów, aby chociaż częściowo pokryć nową funkcjonalność testami.

Wady, złe doświadczenia? Cóż, jedna rzecz, do dziś się za mną ciągnie. Udostępniona przez organizatora maszyna wirtualna odpalona na służbowym laptopie była bardzo powolna. Czasem jeszcze do niej zerkam i zawsze przed tym muszę pozamykać inne programy. Jest to drobne utrudnienie.

Niezależnie od tego czy w przyszłym roku również będę miał możliwość uczestnictwa w Web Summer Camp, muszę przyznać, że jest to niezwykle wartościowe wydarzenie, do uczestnictwa w którym zawsze będę namawiał każdego, żądnego rozwoju i wiedzy programistę.