PHPers Day 2019
Konferencja, której nie było
Zeszłej jesieni świat PHP zaskoczyła wiadomość, że z początkiem bieżącego roku rusza w Ostródzie nowa konferencja ExpoPHP. Było to o tyle zaskakujące, że organizować to wydarzenie miała ta sama firma, która kilka lat temu organizowała PHPCon Poland. PHPCon Poland, jak niektórzy może pamiętają to były wydarzenia naprawdę wyjątkowe. Nieco dzikie, nieco chaotyczne, ale przesiąknięte duchem programowania, pasją i chęcią zdobywania wiedzy. Przy tym wszystkim cena była przystępna, a i zaplecze na solidnym poziomie. Nagle, w 2016 organizator podjął decyzję, aby zakończyć organizację tej konferencji w Polsce i wypłynął na szerokie, Europejskie morza pod szyldem PHP CE.
Społeczność PHP ma się w Polsce całkiem nieźle, a w ostatnich latach, dzięki dziarskiemu rozwojowi samego języka, PHP zaczęło zyskiwać uznanie jako język dojrzały i obiecujący. Lukę po PHPCon Poland zaczyna wypełniać PHPers Summit, 4Developers i inne konferencje ogólno-programistyczne. Organizator stwierdził najwyraźniej, że znajdzie się miejsce dla jeszcze jednego wydarzenia i bardzo sprawnie zaczął tę nową konferencję organizować. Dość szybko zaczęła się pojawiać agenda, a na niej Derick Rethans, Michał Kurzeja, czy Chris Holland i sporo innych międzynarodowych nazwisk. Zaczęło to wyglądać naprawdę obiecująco. W pewnym momencie ruszyła wreszcie przedsprzedaż biletów, ale wtedy wszystko jakby zamarło.
Petarda wybuchła z początkiem lutego, półtora miesiąca temu – ExpoPHP odwołane. Szok i niedowierzanie, zaskoczenie i wszechobecna konfuzja w społeczności. Okazję postanowił wykorzystać znany trójmiejski piwosz, programista, prelegent, promotor i przedsiębiorca (kolejność przypadkowa) – Leszek Prabucki. Już kilka dni później było wiadomo, w GPNT (Gdański Park Naukowo-Technologiczny) organizowane będzie PHPers Day 2019 – jednodniowe wydarzenie na którym pojawią się niektórzy mówcy, którzy mieli wystąpić na ExpoPHP, a nie są w stanie zmienić już swoich planów – wykupione bilety lotnicze, zaplanowane urlopy itp. Wydarzenie zostało zaplanowane na drugiego marca.
Koszt udziału w konferencji: 25 zł. W cenie obiadu w restauracji można było spędzić cały dzień słuchając wykładów wielu naprawdę dobrych specjalistów z branży, przy okazji zjeść pizzę, pić kawę, jeść ciastka, a nawet wypić piwko z naszego pomorskiego browaru Amber (wszystko w cenie). Co więcej, zawsze na takim wydarzeniu można spotkać starych dobrych znajomych z branży, co zawsze jest pozytywnym doświadczeniem.
Oczywiście nie mogło tam zabraknąć i nas. Jako firma postanowiliśmy z radością wspomóc to wydarzenie i zaprezentować się morzu programistów.
Takiej okazji nie mogłem przegapić i ja. Dlatego z grupą kilku znajomych ze Speednetu wybraliśmy się w chłodny, sobotni poranek, drugiego marca do Gdańska.
Understanding OAuth For Real by Johannes Pichler
Pierwszy wykład był poświęcony OAuth. Prowadził go Johannes Pichler, główny programista w austriackim portalu kerriere.at.
OAuth to de facto obowiązujący standard uwierzytelniający, powszechnie wykorzystywany przez praktycznie wszystkich w celu udostępniania swoich treści w bezpieczny sposób stronom trzecim. Większość z was na pewno słyszało tę nazwę, a i pewnie wykorzystywało w swoich projektach, choć najpewniej przy użyciu bibliotek dostarczonych bądź przez dostawców treści, bądź przez społeczność.
Johannes, dla odmiany, zaprezentował na wykładzie jak działają wnętrzności procesu autentykacji. Dowiedzieliśmy się, jak zbudowane są pakiety przesyłanych danych, jakie rodzaje tokenów mogą pojawić się trakcie całego procesu, jakie role zostały zdefiniowane w standardzie. Całość została zaprezentowana na czytelnej prezentacji, którą Johannes udostępnił w sieci. W trakcie wykładu, moje notatki nieznacznie korygował kolega po fachu, którego miałem przyjemność zobaczyć po długim czasie, a który ma spore doświadczenie w OAuth. To on podsunął mi stronę https://jwt.io na której znajdziecie bardzo jasne i czytelne wprowadzenie do JSON Web Token, które są używane w trakcie uwierzytelniania przy pomocy OAuth.
XDEBUG by Derick Rethans
Wykład Dericka Rethansa był bardzo ciekawy i mógł zaskoczyć nawet tych z nas, którzy używają XDEBUG na co dzień. Twórca tego narzędzia omówił zarówno kilka nowości dodanych w zeszłym roku, wspomniał o kilku przydatnych parametrach konfiguracyjnych, opowiedział co nieco o swojej pracy i problemach z jakimi się styka.
Zaczęło się jednakże od żartu. W poprzednim wykładzie, Johannes wspomniał o funkcji pad (print and die), od której zaczyna kodowanie. Derick oczywiście skomentował to odpowiednio z pewną dozą uszczypliwości wywołując wśród publiczności salwy śmiechu. Swoją drogą – a czy Ty korzystasz już z XDEBUG?
Jedną z nowości, która była omawiana, to między innymi aktywacja step debuggera, z którego przypuszczam większość programistów już korzysta na co dzień.
Do ciekawych rzeczy o których się dowiedziałem należy np. parametr konfiguracyjny xdebug.halt_level, który określa po jakim rodzaju błędu skrypt ma się wysypać. Przykład:
<?php
ini_set(‘xdebug.halt_level’, E_USER_NOTICE | E_NOTICE);
trigger_error("Testing");
echo "Hi!";
W powyższej sytuacji komunikat “Hi” się nie pojawi, a skrypt zatrzyma się po wystąpieniu błędu. Jak wiecie większość parametrów XDEBUG, można modyfikować w trakcie działania programu przy pomocy ini_set.
Inny parametr, o którym warto pamiętać to xdebug.remote_log. Aktywuje on logowanie błędów z połączeniem ze zdalną maszyną, co niezwykle się przydaje przy rozwiązywaniu problemów podczas pracy XDEBUG z maszyną wirtualną.
Twórcy IDE dostarczają interfejs do konfiguracji różnych funkcjonalności XDEBUG. Świetnie poradził sobie z tym PhpStorm. Jest on w miarę na bieżąco z możliwościami tego narzędzia, dzięki czemu, w bardzo prosty sposób można skorzystać z jego niezwykłych możliwości. Można np. skonfigurować xdebuga w taki sposób, że dany break point aktywuje się dopiero po spełnieniu konkretnego warunku, występującego wcześniej w kodzie, co więcej te „punkty przerwań” można łączyć w łańcuchy i aktywować kolejne w oparciu o aktywację wcześniejszych. Wydaje się, że daje to całkiem spore możliwości, zwłaszcza przy dużych projektach.
Prowadzący opowiedział także o różnych problemach, które pojawiają się w jego pracy, zwłaszcza po ostatnich zmianach w PHP. Przykładem takiej sytuacji jest optymalizacja instrukcji switch, któraj obsługa została całkowicie zmieniona – po nowych zmianach PHP od razu skacze do poprawnego warunku, nie odwiedzając pośrednich. To jest oczywiście problem, bo programista chce wiedzieć co się dzieje po drodze. Dlatego właśnie XDEBUG musi odkręcać optymalizację zrobioną przez PHP. Co ma oczywiście wpływ na wydajność całego środowiska.
Wykład zdecydowanie udany. Warto dodać, że Derick postanowił całkowicie poświęcić się pracy nad xdebugiem, czego efektem będą częstsze wydania i nowe funkcjonalności. Jeżeli chcecie mu podziękować za dobrą robotę to w serwisie Patreon możecie wesprzeć jego starania.
Taming Change by Chris Holland
Największe zaskoczenie dla mnie, a jednocześnie chyba największa perełka całego wydarzenia. Chris Holland to pochodzący z Teksasu doświadczony programista i lider niewielkiej grupy programistycznej w firmie HR. Doświadczony mówca, który regularnie pojawia się na różnych międzynarodowych konferencjach PHP. Zobaczyć go podczas PHPers Day, niemalże przypadkowo, za 25 złotych to była wyjątkowa okazja (jak widać jeżdżenie na konferencje nie musi być drogie).
Tematem przewodnim wykładu była szeroko pojęta zmiana. Chris postawił bardzo ciekawą tezę, że ludzie boją się zmian i w projektach wytwarzają dużo proceduralnego tarcia dokoła zmian, aby je zahamować, zablokować, a w ostateczności rozmyć odpowiedzialność w razie porażki (robiliśmy wszystko zgodnie z dokumentacją).
W trakcie wykładu podał bardzo ciekawy przykład historyczny, czyli zapoczątkowany w latach 50., w Stanach Zjednoczonych półautomatyczny system obrony naziemnej zwany SAGE. Założenia były bardzo ambitne – kilkadziesiąt tysięcy linii kodu, miliony dolarów. Projekt wytwarzano w modelu kaskadowym.
Gdy w końcu został ukończony, okazało się, że przekroczył wielokrotnie wszystkie ograniczenia co do czasu, środków i linii kodu, a koniec końców okazał się zawodny (przejęto ¼ wszystkich jednostek bojowych objętych systemem). W latach 80. system finalnie wyłączono.
Niby już nikt nie korzysta z kaskadowego systemu wytwarzania oprogramowania, ponoć wszyscy jesteśmy teraz tak bardzo Agile, ale jednak, jak w dalszej części wykładu dowodził Chris, cały czas podświadomie, bądź nie, toniemy w dokumentacjach, zwiększamy dług technologiczny, a w konsekwencji chcąc nie chcąc wydłużamy sprinty. Czy tak naprawdę jesteśmy „zwinni”? Co robimy źle? Takich pytań było znacznie więcej. Ale przytaczanie całej, tak dobrze poprowadzonej prezentacji tutaj jest pozbawione sensu. Dość wspomnieć, że Chris przypomniał manifest Agile i pokazał, co w nim przegapiliśmy.
Całe wystąpienie, miało to coś, co bardzo sobie cenię w tego typu prezentacjach – było inspirujące, a koniec końców, to takie rzeczy najbardziej zapadają nam w pamięć.
Na zakończenie podsumowania jego wykładu, dodam tylko, że usłyszałem na jego wystąpieniu najprostszą, a jednocześnie bardzo obrazową definicję długu technologicznego.
Strangler pattern by Michał Kurzeja
Strangler pattern Michała to jego klasyczny, popisowy wykład, który słyszałem już bodajże w zeszłym roku na 4Developers (dostępny na YouTube). Strangler pattern to sposób na radzenie sobie z kodem odziedziczonym (tak, chyba, można poprawnie przetłumaczyć „legacy”) w taki sposób, aby nie zaburzyć działania całości systemu, a jednocześnie, krok po kroku przenosić go na nową wersję. Strangler pattern to de facto wzorzec wprowadzony przez Martin Fowlera, który zaproponował przeszło 15 lat temu. Wykład poprowadzony był sprawnie, a Michał właściwie opisywał swoją przygodę z wdrażaniem tego rozwiązania u klienta. Opisał problemy jakie napotkał, co zrobiłby z perspektywy czasu inaczej, a także jako to się wszystko skończyło. Całość była zaprezentowana kompleksowo, wykraczając mocno, poza „suche” zasady wzorca. Poruszona została kwestia konfiguracji serwera, bazy danych, a także ewentualnej konieczności wystawienia API.
Strangler pattern to niewątpliwie narzędzie / wzorzec, o którym warto pamiętać i mieć je na podorędziu. Nigdy nie wiadomo, kiedy trafi się do projektu, gdzie takiego kodu „odziedziczonego” będzie tak dużo, że jedynym rozwiązaniem będzie po prostu, stare, dobre duszenie.
Designing Applications Without Framework by Dariusz Drobisz
To był ostatni wykład, w którym miałem przyjemność uczestniczyć. Ostatni, ale nie ostatni, jak to mawiają Anglicy. Tworzenie aplikacji bez frameworka to taki trochę święty gral programistów. Niby wszyscy chcą to robić, niby mamy potrzebne narzędzia (DDD, CQRS, TDD) niby każdy z nas ciągle myśli o ścisłym określeniu domeny, zdefiniowaniu komend, czy precyzyjnych zapytań do API, ale w praktyce, jak przychodzi co do czego trzymanie się DDD bywa niezwykle trudne. Często łatwiej jest w pewnym momencie, pójść na kompromis, czy to dla wygody, czy w celu uniknięcia tworzenia zbyt dużej ilości klas, zwłaszcza, że – w końcu jak często zmieniamy framework w projekcie?
Trochę przypadkowo (choć może i był to celowy zabieg) sam wykład też zaczął się bardziej jak opowieść – o tym czym jest BDD, czym nie jest i jakie narzędzia wykorzystuje. Jednak w pewnym momencie płynnie przeszliśmy do projektowania przykładowej aplikacji, z wykorzystaniem tych technik. Od opowieści, do specyfikacji.
Ze wszystkich prezentacji, ta była chyba najbardziej techniczna. Zawierała przykłady kodu, na bieżąco pokazywała zmiany w strukturze katalogu projekt, zobaczyliśmy jak styktura tych katalogów odzwierciedla poszczególne warstwy systemu. Co więcej i to, może jest najważniejsze, prelegent pokazał nam pewien kluczowy sposób myślenia, podejścia do tworzenia aplikacji zgodnie z podejściem BDD.
Podsumowanie
Długo się zastanawiałem, który z tych wykładów był tym najlepszym. Trudno jednoznacznie stwierdzić, gdyż każdy z opisanych, był na wyjątkowo wysokim poziomie. Wszystkie bez wątpienia były wartościowe, każdy miał inne mocne strony i w gruncie temat, który prezentowały omawiały szczegółowo.
Z pewnością najbardziej zapadły mi w pamięć wystąpienia Chrisa i Dariusza. Wystąpienie Chrisa – niezwykle inspirujące, a prezentacja Dariusza – bardzo klarowna i przyjemna technicznie. Były jeszcze inne wykłady, ale na jeden z nich się spóźniłem (Feature Toggling), a na drugi wolałbym spuścić zasłonę milczenia…
Każdy kto miał przyjemność uczestniczyć w tym wydarzeniu, na pewno tego nie żałuje. Wiadomo, że taka szansa, na takie tuzy sceny PHP się raczej nie powtórzy, a przynajmniej nieprędko. Na każdej, nawet lokalnej konferencji może trafić się fantastyczny prelegent z ciekawym tematem. Dlatego warto obserwować lokalne grupy, zapisać się do kilku list i po prostu trzymać rękę na pulsie.
Na koniec ogromne gratulacje dla organizatorów, przede wszystkim za inicjatywę i sprytne wykorzystanie okazji. Oby więcej takich inicjatyw. Ze swojej strony mogę obiecać ze ze wszystkich sił będę zachęcał decydentów u nas w firmie do sponsorowania takich wydarzeń ;). Do zobaczenia na kolejnej konferencji!
