Dla mnie obecność na 4Developers to już tradycja. Idealna długość (1 dzień w poniedziałek), miesiąc perfekcyjny (kwiecień, gdzie świat konferencyjny dopiero się budzi), w miarę prosty dojazd z Trójmiasta (pociągiem ~ 3h). I samo miejsce w Warszawie mi odpowiada (dawny Hotel Gromada, ~ 20 minut z centrum).
A jak było w tym roku? Inaczej, co roku jest inaczej. Nigdy nie doświadczymy tego samego. Zmieniają się ludzie, ścieżki, technologie, a my sami mamy nowy bagaż własnych doświadczeń.
Moim zdaniem dało się odczuć coraz większe niedostatki w ilości prelegentach, i nawet takiego organizatora jakim jest PROIDEA dotknął ten problem. Dlatego staram się posiłkować zagranicznymi konferencjami, ale do rzeczy.
Trendy
Zastanawiacie się czemu warto bywać na konferencjach, i dlaczego bywanie jest lepsze od oglądania nagrań? Uczestnicząc możecie wyczuć jakie są obecnie trendy na rynku, co się zmienia, z czego mniej się korzysta, a co stało się już standardem.
I tak jak kiedyś tylko napominano w świecie IT o DDD (Domain-Driven Design) to dzisiaj korzysta z niego wiele firm w wielu projektach. I nie zapominajmy, że jeśli mówimy o DDD, to w parze idzie z CQRS czy Event Sourcingiem, a tuż obok (a wręcz przed) stoi Event Storming.
Jeśli nie słyszeliście o tych pojęciach, możecie szybko przeklikać się przez 233 slajdy Cyryla Martraire, z którego zaczerpnięty jest powyższe obrazek.
Natomiast w świecie bardziej sprzętowym coraz modniejszym podejście staje się Serverless. Coraz więcej i coraz częściej można usłyszeć, że znajduje się kolejny śmiałek, z odpowiednim budżetem, aby wejść w FaaS. W przeciwieństwie do DDD, nie widzę szerokiego miejsca w świecie IT na FaaS, ale jest to ciekawe podejście do wytwarzania oprogramowania i są pewne miejsce gdzie na pewno znajdzie zastosowanie.
Fajne było…
Fajnie, że identyfikator był na smyczy, a nie jak w 2016 roku (korkowa podkładka pod kubek). Fajne jest również to, że 4Developers nadal wpółpracuje z Eventory i cała agenda jest dostępna na telefonie i można układać własny program dnia.
To o czym zapominają niektórzy organizatorzy w Polsce to napoje, kawa, herbata, słodkości w czasie przerw – ułatwia to nie tylko przeżycie całego dnia, ale również w pewien sposób rozmowy kuluarowe. I tego było pod dostatkiem.
Mniej fajne
Niefajnie, że wspomniany badge był z eko-papieru, bez agendy (ale agendę papierową można było dostać).
Podczas tegorocznego 4Developers brakowało mi prelekcji stricte technicznych, takich z mięskiem (jak kiedyś np. GoldenLine, GOG, Allegro). Prelekcje, które były to bardziej forma prezentacji technologii, procesu, a nie podrasowania aplikacji/systemów pod maską.
Wydawało mi się, że w tym roku jest mniej ścieżek, ale mimo wszystko ścieżka PHP dostała salę wielkości 2/3 z poprzedniego roku. Dziwnie. Co było jeszcze dziwnego? Lunch – zimny, z boksu, ze słabymi ziemniakami. Ale…
Na pewno wrócę za rok, trzymając kciuki za CfP i czas prelegentów, aby pomiędzy swoimi obowiązkami zawodowymi i prywatnymi mieli czas na dzielenie się wiedzą. A poniżej możecie przeczytać moje notatki z tegorocznej edycji.
Strangler pattern – czyli jak sprawnie udusić Legacy
Prelegent: Michał Kurzeja
Ścieżka: PHP
Wg definicji Michała „Legacy” to kod, który jet ciężki w utrzymaniu, często otrzymujemy po kimś w firmie do utrzymania. Jest to kod można by rzec – zamrożony. A to dlatego, że kod jest stary, dokumentacja prawie znikoma lub nieaktualna, a projekt ma ślimacze tempo – jak tutaj coś zmienić, usprawnić i mieć pewność, że nie popsuliśmy?
Zdarza się, że nawet Biznes zauważa ten problem, ale nie ma prostej (taniej) recepty na jego rozwiązanie.
Z pomocą może przyjść Strangler pattern, które nazwę wzięło od pnączy, które wczepia się w górną część drzewa i rośnie w dół, w dół aż do ziemi, w trakcie oplatając drzewo, wręcz je „zaduszając”. I w taki sposób chcielibyśmy przepisywać kod Legacy – stopniowo, a docelowo usuwać starą aplikację.
Cała reszta prelekcji było to powtórzenie, tego co kiedyś powiedział Sebastian Grodzicki o migracji GoldenLine do Symfony2 na PHPCon PL 2014 (oraz na 4Developers 2014).
Czyli tworzymy przed aplikacją proxy (fasadę), która na wstępie przekazuje cały ruch do aplikacji Legacy, a w miarę powstania odpowiedników w nowym kodzie (Modern) robimy odpowiednie rewrite w mechanizmie proksującym.
Do zapamiętania:
- Gdy Modern odwołuje się do Legacy powinniśmy w miarę możliwości oddzielić bazy danych, wspólny ruch itp. Można to zrobić np. za pomocą evenetów, wyzwalaczy w bazie danych czy po prostu cyklicznej synchronizacji. Celem powinno być 0 punktów styku.
- W przypadku infrastruktury powinniśmy zrobić „Legacy in a box”, stworzyć odpowiedni kontener/maszynę wirtualną z rozwiązaniem i konfiguracją Legacy (np. PHP 5.2). Dzięki temu łatwo będziemy mogli przenosić Legacy, jak również nowi programiści będą w stanie szybko wdrożyć się w projekt uruchamiając go u siebie lokalnie.
State or Events? Which Shall I Keep?
Prelegent: Jakub Pilimon
Ścieżka: Bottega It Minds
Po dość mało odkrywczej prelekcji na ścieżce PHP udałem się sprawdzić poziom na ścieżce Bottega. Sposób prowadzenia, jak również poziom przygotowania się Kuby był świetny.
W przystępny sposób, w formie programowania na żywo, pokazał jak łatwo zastosować DDD, Event Storming i masę świetnych rzeczy podczas pierwszego kontaktu z Klientem, aż po stworzenie kodu aplikacji.
W dużym skrócie – zbieramy dwa typy ludzi: developerów (bo umieją zadawać pytania), oraz Biznes (umie odpowiadać na pytania). Do tego masa karteczek, aby dobrze opisać zdarzenia domenowa na ścianie.
Na podstawie przykładowych zdarzeń (tj. Spłata kredytu, zmiana limitu, pobierz gotówkę) Kuba pokazał związek tych zdarzeń z przyczynami (powiadomienie od innego systemu, cykle rozliczeniowe, jedno zdarzenie może być przyczyną innego).
Powoli widzieliśmy, że wszystkie te rzeczy są mocno od siebie zależne, czyli opisujemy jedną klasę – KartaKredytowa. Mimo, że takie podejście nazywamy dzisiaj OOP (Object-Oriented Programming), to sam Alan Kay później powiedział, że powinniśmy bardziej mówić o MOP (Message-Oriented Programming).
Bardzo szybko z pomocą OOP/TDD Kuba przeniósł 1:1 wszystkie punkty z karteczek do języka programowania i jak podkreślał nie powinniśmy tutaj używać żadnego mózgowego procesu:
- Niezmienniki (żółte karteczki) – początkowe warunki w metodach
- Powiązanie karteczek – struktury, które ubieramy w zdania i mamy gotowe scenariusze testowe („za darmo” testy dzięki sesji event stormowej)
- Pamiętajmy, aby stosować model dziedziny, a dane zostawić sobie (bazie danych)
Na koniec Jakub bardzo szybko pokazał jak wprowadzić zdarzenia w obiekcie KartaKredytowa (Event Sourcing) i zaznaczył, że w event sourcingu nie zmieniamy kontraktu obiektu.
Kod powstałego zalążka możecie zobaczyć na Github: Sample ES/CQRS application.
Wprowadzenie do Domain-Drived Design na przykładach
Prowadzący: Michał Michaluk, Jakub Pilimon
Ścieżka: Bottega It Minds
Wyjście na przerwę ze ścieżki Bottega było błędem – gdy wróciłem były tylko dalekie miejsca stojące (dokładniej – w drzwiach). Michał i Kuba zamiast prelekcji zrobili małe przedstawienie i bardzo prosto wyjaśnili pokrótce najważniejsze koncepty DDD (Domain-Drived Design). Sesja była nagrywana, jak tylko będzie online dam Wam znać.
DDD Q&A – czyli co gryzie programistów i programistki?
Prelegent: Sławomir Sobótka
Ścieżka: Bottega It Minds
Ogrom wiedzy przedstawiony w przystępny sposób – tak można podsumować każdą prelekcję Sławka, tą również.
Już na samym początku prowadzący podkreślił, że programiści często popełniają błąd posługując się „swoim” językiem zamiast korzystać z języka opisującego świat dookoła nas.
Interesujący był przykład z Zamówieniem i Produktem, gdzie okazało się, że de facto Klient nie składa zamówienia z punktu widzenia procesu, ale jest to rezerwacja danego Produktu. I taką cząstkową rezerwacją mogą być np. wszystkie pozycje, za które jeszcze nie zapłaciliśmy.
Co można modelować ze świata rzeczywitego?
- being (co to jest)
Jaka jest tego struktura? Jakie są pola, a najważniejsze jakiego są typu. “Mając dany produkt z ceną X” (struktura), “Mając dany produkt, robi to” (pseudo-zachowanie) - behaving (co to robi)
Jakie sygnały mogę wysłać, co się zmienia, jak reaguje na sygnały? Kto dokunuje zmiany? Jak często się zmienia? - becoming (w co to się przemienia)
Jak to się zmienia w coś innego? Co gdy w czasie elementy będą usunięte?
12Cena katalogowa -> cena dla klienta -> zakup(Agregat) (Value object)
Sławek podkreślił również, aby nie mylić modelu prezentacyjnego z modelem biznesowym. To, że na wizualizacji zamówienia są nagłówki, sprzedawca etc., to nie znaczy że jest to wymóg biznesowy.
Jak również ważne jest, aby pamiętać o tym, że możemy odczytywać dane z wielu agregatów jednocześnie, ale zapisywać tylko do 1. Dlaczego? Ze względu na potencjalną skalowalność.
Podczas prac powinniśmy również unikać przeładowania naszych klas „nad obowiązkami”. Stosujmy zasadę małych klocków. Dlaczego? Programujemy w języku klasowym, to stosujmy klasy, poza tym mniejsze klocki łatwiej użyć ponownie, a z nich już prosta droga do mikroserwisów.
Jak można projektować API?
- Zasobowo (GET / UPDATE)
Ale tylko teoretycznie, ponieważ nie aktualizuje się już istniejących rekordów. To jest „trochę jak diler – jak weżmiesz pierwszą działkę, to ci się wciągasz”. - RESTful
Składasz wnioski, np. o zmianę nazwy firmy (moduł petenta, a po drugiej stronie moduł urzędnika – domena), ważne są w tym wypadku linki, które wracają w odpowiedzi (mediaType; HATEOS). A najważniejsze jest to, że nie ma przecież możliwości skasowania firmy, ale można za to złożyć wniosek o zawieszenie/zamknięcie firmy.
RESTful można nazwać protokołem aplikacyjnym, w którym nieodzowny jest cache - CRUD
Jest to model jajka sadzonego nadający się tylko dla kolejarzy (RoR) 😉
Jak można się dogadać?
DDD to technika służąca do gromadzenia wiedzy i sposobu uczenia się (np. technika Alberto Brandolini – Event Storming).
Zastosowanie Event Storming: odkrywanie procesu biznesowego, granic bounded context, reguł domenowych i granic Agregatów:
- Event (czas przeszły, tryb dokonany) STORMING [podobne do burzy mózgów; wrzucamy zdarzenia, nie jest ważna kolejność]
- Rygor czasu (sortujemy to co dzieje się po kolei, równolegle, w paczce itd)
- Weryfikacja od końca (co jest celem procesu, co brakuje w procesie, cofam się i cofam).
- Command – użytkownicy lub inne systemy (dla każdego zdarzenia zadaję pytanie o przyczynę – command)
- Reguły (dlaczego ten command powoduje to zdarzenie; albo to zdarzenie powoduje to zdarzenie).
- Agregaty (chronią mi te reguły, które muszą być spójne NATYCHMIAST).
- Widoki (czasami warto stosować, to dodatkowe; bo nieraz biznes myśli widokami).
Na koniec warto zobaczyć wystąpienie Grega Younga o The art of destroying software oraz wersję rozszerzoną DDD Q&A Sławka Sobótki.
Uff, sporo wiedzy dotyczącej DDD i otoczających go wspomagaczy. Pora wybrać się na inną ścieżkę – pomyślałem – pytanie co słychać w Allegro, pomyślałem….
Allegro, vivo, presto
Prelegent: Sergey Bolshov
Ścieżka: Front-end by Allegro
Nie była to niskoprogramowa prelekcja, raczej wprowadzenie dla juniorów, ale spokojnie do wysłuchania. Sergey starał się prosto przedstawić po co nam wydajność (we frontendzie, jak również backendzie) i jak pokazać potrzebę szybkie ładowania serwisów Biznesowi.
Dane zbierane przez różne serwisy (również z grupy Allegro) pokazują, że ZU (Zwykły Użytkownik) chętniej korzysta z aplikacji, gdy czas jej ładowania jest poniżej 1 sekundy. W tym przypadku należy pamiętać, że wydajność to nie jest jedna liczba, ale zbiór szerokich danych, które wpływają ostatecznie na ogólne poczucie szybkości działania aplikacji przez ZU.
Sergey powiedział, że Allegro zbiera metryki w czasie rzeczywistym (m.in. czas ładowania czy czas do pierwszej interakcji po stronie ZU). Dodatkowo zanim podejmą jakieś kroki optymalizacyjne patrzą najpierw jaka to jest przeglądarka, ilu użytkowników Allegro z niej korzysta i czy jest sens coś zmieniać (mało użytkowników), lub w ogóle da się to zrobić (np. IE).
Pamiętajmy, że różne testy syntetyczne (np. webpagetest.org , speedcurve.com , waterfall view) pomijają kwestię interaktywności, a skupiają się tylko na danych statycznych. Allegro ostatnio wprowadziło HTTP/2, ale nie przyniosło to spodziewanych efektów. Wydaje mi się, że wiąże się to już z wcześniejszymi optymalizacjami pod HTTP/1.1 (limity jak 6-8 aktywnych połączeń do 1 domeny). Modyfikacje robione pod HTTP/1.1 nie zawsze sprawdzają się w świecie HTTP/2.
Ciekawą informację, o której powiedział Sergey jest to, że na urządzeniach mobilnych renderowanie odbywa się wolniej, bo wszystko dzieje się na 1 wątku, którego czas często w połowie zajmowany jest przez przetwarzanie samego Javascriptu.
Serverless is not about code. It is how you think
Prelegent: Szymon Warda
Ścieżka: Bottega It Minds
Ta prelekcja to było jakieś nieporozumienie (przepraszam), dwukrotnie sprawdzałem czy to na pewno ścieżka Bottega. Dla mnie chaotyczna prezentacja.
Odniosłem wrażenie, że Szymon nie słyszał o open-source i narzędziach jakie oferuje.
Dla Szymona chmura (w tym wypadku Azure) jest receptą na wszystko – małe, dużo aplikacje. Nie zwracając uwagi chociażby na to co dzieje się na rynku (patrz: Apple usuwa działające aplikacje ze sklepu, bo nie 32-bitowe, bo nieaktualizowane od 2-3 lat, co z naszymi FaaS za 3 lata?).
Jedna z wartościowszych informacji: Uber posiada już 8500 repozytoriów, a dział developerów powiększył się z 300 do 3000 pracowników.
Serverless PHP
Prelegent: Michał Kurzeja
Ścieżka: PHP
To było trochę niebezpieczne iść po poprzednim wykładzie na kolejny teoretycznie o tym samym. Szczególnie, gdy Michał sam na początku powiedział, że nie ma ogromnego doświadczenia w chmurowych sprawach (AWS / Azure). Ale zostałem…
I powiem Wam, że było warto. Michał jest CTO w Accesto.com, nie jest to duża firma, ale Klienci często też nie są duzi. Ze względu, że admin to kolejny etat, kolejna osoba etc. wydawało się im, że wejście w „chmurę” to odpowiednia decyzja (prosta sprawa, łatwa skalowalność, niskie koszty na początku).
Czym w ogóle jest tajemnicze określenie serverless?
Serverless to trend w cloud computing w którym zmieniamy sposób myślenia o tworzeniu oprogramowania (auth0.com)
Serverless to architektura, w której nasz kod jest uruchamiany w krótko żyjących kontenerach (Martin Flower)
Serverless nie jest wynalazkiem dnia dzisiejszego. Jest to następstwo wcześniejszych wyborów. Początkowy firmy dostarczały pełen backend dla firm tworzących oprogramowanie. Ale z czasem okazało się, że np. mailing dobrze jest robić zlecić dedykowanym firmom i w ten sposób powstał BaaS – czyli małe, wydzielone fragmenty kodu, które byłī używane przez inne. I tak dalej, i tak dalej, aż dochodzimy do dnia dzisiejszego, czyli FaaS (Function As a Service, np. AWS Lambda).
W FaaS piszemy tylko funkcję, cała reszta to inne obszary wytwarzania oprogramowania (np. inne usługi „firmy chmurowej”). W tym wypadku płacimy za czas działania funkcji, a nie moc. Po wykonaniu funkcji teoretycznie „kontener” jest niszczony (ze względów optymalizacyjnych żyje jeszcze 10-15 minut, bo może za chwilę znów będziemy potrzebować).
FaaS jest teoretycznie bezstanowy, krótkotrwały (ephemeral) z prostym cennikiem (czas wykonywania X zagwarantowana pamięć).
Moim zdaniem FaaS, czy w ogóle *aaS powoduje dodatkowy narzut prac i z tego powodu nadaje się do większych projektów, które z założenia mają służyć użytkownikom z całego globu, ponieważ w tym wypadku dostajemy wiele rzeczy „od chmury” za darmo.
Dobrym przykładem jest Droplr, który pomaga dzielić się zrzutami ekranów (desktop & mobile). Przejście na koncepcję serverless obniżyło ich koszta infrastruktury 10x krotnie, a czas ładowania strony spadł poniżej 50 ms.
Minusem chmury jest uzależnienie się od jednego, specyficznego dostawcy tworząc np. FaaS, z tego powodu powstał Serverless Framework, który pozwala w pewien sposób zapomnieć czy korzystamy z AWS, Azure a może Google Platform.
I ważną rzeczą na koniec, którą zauważył Michał, jest multitenancy – pamiętajmy, że w chmurze korzystamy ze wspólnych zasobów, dlatego nasze pomiary czasowe wykonywania funkcji mogą być niepowtarzalne.
Tip: Serverless nie oferuje obecnie wsparcia natywnego dla PHP, dlatego Accesto stworzyło projekt Serverless PHP na GitHub, który buduje PHP i uruchamia aplikacja PHP wywołaniem z node.js.
KICK ME
Prelegent: Przemysław Krzywania
Ścieżka: Architektury aplikacji II
Mimo, że sporo osób wyszło z tej prelekcji (naprawdę sporo), uważam ją za jedną z bardziej wartościowych.
Przemek można powiedzieć to kolejny przedstawiciel małej firmy, co ma swoją bardzo dobrą stronę – od początku kładzie nacisk na zrozumienie ludzi z biznesu (Klienta) i wokół tego poruszał się w trakcie prelekcji.
Programista często skupia się na sobie, kodzie, technologiach zapominając o Kliencie, dla którego jest aplikacja, czy innych osobach z zespołu. A w programowaniu jednym z ważniejszym aspektów jest prostota w tworzeniu (prosto czyli łatwo i czytelnie stworzony kod).
Często zdarza się, że programiści stosują pewne skróty myślowe w zapisach, dziwne rozwiązania co nie jest dobre, ponieważ przyjdzie nowy programista, albo projekt trafi do działu utrzymania i kod będzie niezrozumiały, a tym samym trudny w utrzymaniu.
Pamiętajmy, że programowanie to gra zespołowa – kod powinien być prosty dla innych. Ponieważ zespół jest ważniejszy, a kod niezrozumiały jest kodem nieutrzymywalnym.
Przemek wspomniał również o znanych „skrótowcach” (zasadach), o których powinniśmy pamiętać i wykorzystywać codziennie:
- DRY – Don’t Repeat Yourself
- KISS – Keep It Simple, Stupid
- Liskov – substitution principle
- DI – Dependency Injection
- Yagni – You Ain’t Gonna Need It
Dzisiaj wszyscy mówią o mikroserwisach, czy FaaS – dlaczego nie zacząć od tego? Bo prościej zacząć od monolitu, tak jak to robił Google, Facebook czy Netflix. A z czasem refaktorujmy, udoskonalajmy, wydzielajmy kod w postaci klocków.
Na koniec Przemek napomniał jeszcze o długu technicznym. W momencie kiedy tworzymy dług techniczny jest on dobry, a nawet wspierany np. przez Agile (powinniśmy dostarczać wiele opcji do wyboru, najszybciej jak się da). Oczywiście docelowo niwelujemy dług poprzez refaktoryzację, najlepiej zanim trafi na produkcję.
I warto mieć na uwadze, że dług techniczny nie dotyczy technologii, ale ludzi.
Pamiętajmy, że najważniejsze jest ciągłe dostarczanie wartości.
To tyle, do zobaczenia za rok! A poniżej linki do innych podsumowań 4Developers 2018: