PWA

WarsawJS Meetup #32: Moje wrażenia

• 7 minut

32-edycja comiesięcznych spotkań dla programistów była owocna w świetne tematy. Na scenie pojawili się wspaniali prelegenci Monika i Damian. Zapraszam do zapoznania się jakie były moje odczucia z prelekcji.

Wydarzenie było jak zwykle dostępne na fejsbuku oraz na meetupie.

WarsawJS

Invitation

Dzięki znajomościom Piotra mogliśmy nagrywać zapowiedź nie - jak ma to zwykle miejsce - sprzed obiektu ale z wewnątrz. Ekipa WarsawJS wylądowała w klubie tenisowym WTS Orzeł na warszawskiej Pradze.

Chcesz zobaczyć jak jeden z organizatorów WarsawJS skacze w dal?
Zerknij na poniższe wideo.

Talk #1: SOLID i DRY w JavaScript- praktyczne przykłady [PL] Damian Wielgosik

40 minutowa prelekcja założyciela meet.js oraz Functionate - Damiana - nie była standardowym wyjściem na scenę i opowieścią o frameworku.

Prelegent zamienił się w programistę i na oczach ponad 100 osób programował koszyk dla aplikacji typu sklep internetowy.

Targetem live coding byli programiści na poziomie początkującym i średnio zaawansowanych.

Damian podczas kodowania przedstawiał po kolei wszystkie 5 zasad (a tak naprawdę cztery, bo jednej zabrakło), które składają się na jedną o nazwie SOLID. Wymieńmy sobie po kolei te zasady:

D - DIP

Jako pierwsza została pokazana zasada rozdzielenia zależności, czyli D. Obiekt koszyka - Cart - znał definicję budowania obiektu Product. Nie jest to dobre podejście, ponieważ gdy zmieni się API klasy Product, to trzeba aktualizować zupełnie inną encję - Cart.

Zasada Hollywoodzka

“Jest takie powiedzenie: Nie wołaj nas, my zawołamy Ciebie.”
— Hollywood Principle: Don’t call us, we’ll call you”

Rozwiązanie? Odwrócić zależność! Przenieść tworzenie produktu linijkę przed wykorzystaniem funkcji dodającej produkt.

Damian w okolicach 12 minuty użył słowa “zdikaplowaliśmy”. Coś mi mówi, że prelegent miał na myśli - wykorzystanie wzorca Decoupling Pattern. Już spieszę z wyjaśnieniem.

Wzorzec polega na rozdzieleniu obiektów ze sobą jak najbardziej to możliwe, po to aby zmiana jednego nie powodowała modyfikację drugiego. W świecie gier, sprawa wygląda tak, że jak dodajesz jakiś feature do gry, to w im mniejszej liczbie klas musisz coś zmienić tym lepiej.

✨ Nie wiedziałem, że te podejście posiada taką nazwę. Pierwsze słowa uznania dla prelegenta.

“Jeśli z wielu miejscach musisz nanieść poprawki to wiedz, że coś się dzieje.”
— Damian “Ferrante” Wielgosik

S - SRP

Kolejna zasada jaka została przedstawiona to zasada minimalnej odpowiedzialności. W przykładowej aplikacji Product wiedział, że znajduje się w Cart - trzymał o tym informację w swojej logice. Po co produkt ma wiedzieć, że jest coś takiego jak koszyk?

Rozwiązanie? To koszyk musi wiedzieć, czy produkt w nim jest.

✨ W okolicach 15 minuty zostało wypowiedziane przez prelegenta DDD. Nie znam tego terminu.

Poczytałem trochę o tym i nie będę się starał w krótkich słowach pisać co to jest. Za jakiś czas napiszę artykuł na temat tego podejścia do programowania.

Kupiłem już nawet kiedyś książki na temat DDD aby pogłębić temat. Gdy je przeczytam na pewno pojawi się o tym artykuł.

I - ISP

Po kilku minutach Damian rzucił przykładem, że koszyk chciałby wiedzieć jak się zapisuje. Ten proces może się odbywać za pomocą HTTP, LocalStorage albo cokolwiek innego. Funkcja zapisująca będzie posiadała wszystkie możliwe rozwiązania do zapisu, tym samym będzie to strasznie długa funkcja.

Rozwiązanie? Podział na mniejsze interfejsy, które będą realizowały jak najmniej rzeczy. Jeśli chcielibyśmy zapisywać koszyk do LocalStorage, to trzeba zrobić nową klasę, która będzie realizowała tylko tą rzecz. Rozwiązanie zaczerpnięte z DDD: stworzenie modułu typu “repozytorium”.

✨ Nie znałem takiego typu modułów. Kolejna rzecz, która mnie czegoś nauczyła.

Damian porównał koszyk do listu. List nie wie jak jest przenoszony, czy to InPostem, czy listonoszem itd. Koszyk też nie wie jak jest zapisywany. Bardzo ciekawa analogia.

Koszyk nie może mieć funkcji typu: save, load. Utarło się, że jest to domena repozytoriów, które mogą dane załadować, dostarczyć i zapisują.

“Nie wolno używać generalnego interfejsu. Należy rozbijać funkcje na jak najmniejsze, tak aby realizowały jeden (określony w nazwie) task.”
— Damian “Ferrante” Wielgosik

L - LSP

Zasada ta została stworzona po to, aby tworzyć podklasy danego problemu. Jeśli chcielibyśmy dodać do koszyka grę, która miałaby dodatkowe parametry, takie jak np. ograniczenie wiekowe, to trzeba by rozszerzyć klasę Product. Jednak nie jest to dobra droga, ponieważ wtedy wszystkie produkty, nie ważne jakiego typu by były, dostały informację o ograniczeniu wiekowym.

Rozwiązanie? Bardzo proste. Stworzenie klasy pochodnej GameProduct, która dziedziczy po klasie Product i rozszerza obiekt o parametr limitAge.

O - OCP

Niestety, ale zabrakło czasu na pokazanie tej zasady. No chyba że była omawiana, ale to musiało mnie wtedy zabraknąć.

Damian, jeśli to czytasz, to daj proszę znać, jak w omawiamy przez Ciebie przykładzie omówiłbyś tą zasadę.

Podsumowując 30 minutową prelekcję.

Jestem zadowolony, że na scenie gościliśmy pioniera spotkań programistów JavaScript w Polsce. Przygotowanie prelegenta było na wysokim poziomie. Dobrze mi się go słuchało. Uwielbiam rozmawiać o wzorcach projektowych, dlatego też taka prelekcja jak najbardziej przypadła mi do gustu.

•

Talk #2: Handling Asynchronous Actions in React-Redux Apps [EN] Monika Glier

Monika jako druga prelegentka w historii WarsawJS opowiadała o obsłudze akcji asynchronicznych w aplikacjach Reactowych opartych na Reduxie.

Prelegentka zmieniła swoją ścieżkę kariery 2-3 lata temu. Wcześniej była prawnikiem.

Prelekcja zaczęła się od wprowadzenia w świat asynchroniczności. Jak definicja asynchroniczności została potraktowane powiedzenie:

Asynchroniczne akcje to akcje, które zostaną kiedyś wywołane.
— Monika Glier

Śmieszne wytłumaczenie, ale prawdziwe. Nie ma żadnej kontroli, kiedy funkcje asynchroniczne zostaną wykonane.

Kolejnym krokiem było wytłumaczenie przez Monikę w krótkich słowach czym jest Redux. W dzisiejszych czasach już chyba wszyscy wiedzą co to za biblioteka.

Prosta architektura Reduxa:

  • użytkownik wykonuje akcje (dispatch action),
  • ona uruchamia reducer, który zmienia store
  • a następnie przerenderowany jest component

Tyle. Prosta architektura, ale jakże pomocna. Prawdę mówiąc korzystałem z takiej architektury kilka lat temu, kiedy pracowałem przy projekcie opartym na frameworku Backbone. W dzisiejszych czasach ten framework to już trochę przeżytek, ale ja mocno go chwalę. Można powiedzieć, że “programistycznie” się na nim wychowałem.

Do aplikacji opartych na Reduxie, Monika poleca kilka bibliotek:

  • redux-thunk - popularność biblioteki spowodowana jest występowaniem woficjalnej dokumentacji Reduxa
  • redux-saga

Pod koniec prezentacji dowiedzieliśmy się co nieco o testach z użyciem sagi. A na zakończenie Monika porównała wyżej wymienione biblioteki.

Świetna prelekcja, która “zajawiała” tematykę asynchroniczności w Redux-owym świecie tworzenia aplikacji. Thanks Monia!

•

Panel dyskusyjny

Podczas tego wydarzenia miał miejsce pierwszy w historii WarsawJS panel dyskusyjny podczas którego zadawaliśmy pytania ekspertom, aby wygenerować dyskusję na popularne tematy ze świata JavaScript-u.

Zrezygnowaliśmy z trzeciej prelekcji, aby zobaczyć jak wydarzenie będzie wyglądało razem z panelem. Rozwialiśmy wszelkie wątpliwości, m.in że wydarzenie przerodzi się w kilkugodzinny maraton.

Świetny odbiór ludzi dał mi potwierdzenie, że warto robić takie panele.

Nagranie z panelu jest dostępne w naszych archiwach, jednak z powodu słabej perspektywy (publiczność przysłania ekspertów), materiał nie zostanie opublikowany.

Zastanawiamy się, czy aby nie opublikować samej ścieżki audio.
Jak myślisz, będzie to dobry pomysł?

•

Sponsorzy spotkania

Podziękowania dla firm sponsorskich, które szukają pracowników z obszaru Front-end. Jeśli szukasz pracy napisz do nich, albo do mnie - a ja skieruję Cię do odpowiedniej osoby.