WarsawJS Meetup #34

• 6 minut

Już 34. spotkanie warszawskich programistów JavaScript. Cieszę się, że takie wydarzenia cieszą się dużą popularnością. Sala zawsze jest pełna. To cieszy i napawa optymizmem.

Całe wydarzenie jest darmowe. Pozbawione jest wcześniejszej rejestracji. Po prostu przychodzisz i słuchasz, a po prelekcjach “networkingujesz”.

WarsawJS

Invitation

Kolejna zapowiedź “na sportowo”. Zwykle w poniedziałki gramy w nogę na pobliskim (blisko szklanego wieżowca - Blue Point - w którym pracuję) boisku. Nie jest to poziom profesjonalny… hmm amatorski to chyba też nie jest. Po prostu kopiemy pomalutku w piłę.

Na filmie wystąpił jeden z moich kolegów z pracy - Marek, z którym bardzo często rozgrywamy mecze. Zwykle to jest tak jak w pierwszych minutach filmu - kopiemy na pustą bramkę a i tak często nie wpada!

Chciałbyś popykać w piłę. Napisz do mnie. Ustawimy się na jakiś sparing na Pradze.

Talk #1: Need for Speed - optimizing React [PL] Kamil Grabek

Kamil - doświadczony developer, fanatyk performance-u. Wygłosił prelekcję na temat optymalizacja aplikacji React-owej.

Siła Reacta nie leży po stronie budowania UI. Leży po stronie jego aktualizacji.

Kilka wskazówek optymalizacyjnych

  • 1. Komponenty

    Tworzenie komponentów, które renderują treść w pętli. Przy każdej iteracji zostanie wykonane sprawdzenie, czy faktycznie powinien się przerenderować. Jeśli jego właściwości nie uległy zmianie, to nie zostanie on przerenderowany, oszczędzając tym samym zasoby.

  • 2. Immutability

    Dane w trybie read-only pozwalają na szybsze porównywanie. Pożyteczna paczka (w npm): immutable-helper

  • 3. Memoizacja

    Oszczędność wykonywania tych samych operacji. Zapamiętywany jest wynik operacji. Pożyteczna paczka (w npm): moize

  • 4. Produkcja

    Wersja produkcyjna pozbawiona jest kilku sprawdzeń, oszczędzając zasoby.

  • 5. Pure functions

    Funkcje, które nie modyfikują stanu, tylko zwracają nowy.

  • 6. Alternatywy

    Przykładowa alternatywa: preact. Podczas budowania aplikacji produkcyjnej można podmienić główną bibliotekę (React.js) na lżejszą.

🏆 Złota myśl

Pamiętaj, że nie wykonuj optymalizacji za wcześniej.
Na początku budowania aplikacji nie ma co optymalizować.

•

Talk #2: Trening na redukcję: jak spalić kilobajty? [PL] Paweł Kondraciuk

Druga prelekcja o wydajności. Cóż za performance-owy meetup! Lubię takie. Sam jestem fanem optymalizacji.

Wiecie, że Google nie lubi wolnych aplikacji? Na potwierdzenie artykuł.

  • 1. Pozbycie się Dead Code

    Wykorzystanie narzędzia: closure-compiler

  • 2. Wielkości plików

    Weryfikacja, które pliki są wykorzystywane w projekcie:

    Wydzielenie vendorów do osobnego pliku, aby go móc skeszować.
    Wykorzystana narzędzie: CommonsChunkPlugin.

  • 3. Tree Shaking + Minifikacja

    Tree shaking usuwana z eksportowania nieużywane funkcje. Minifikacja usuwa kod, który nie jest używany.

  • 4. JIT vs AOT

    JIT - Just In Time compilation

    • kompilacja szablonów w locie
    • wolne bootstrap aplikacji, jednak szybsze budowanie, jakże pomocne w devloperce

    AOT - Ahead Of Time compilation

    • wycięty @angular/compiler - duża redukcja wielkości pliku vendors.js
    • szablony są już skompilowane
    • błędy w szablonie są wykryte na tym poziomie
    • większe bezpieczeństwo - brak ewaluacji kodu
    • włączenie tree shaking pozwala wyciąć nieużywane dyrektywy np. ngIf

  • 5. Lazy loading

    Dołączanie wykorzystywanych modułów w sposób leniwy. Bardzo szybki czas prezentacji pierwszej strony Istnieją 2 strategie:

    • pobieranie chunków dopiero wtedy kiedy faktycznie powinny być używane
    • pobieranie wszystkich chunków od razu, ale po wyświetleniu pierwszej strony

  • 6. Kompresja GZIP

    Optymalizacja plików CSS np. bootstrap.css na poziomie 84%.

Pierwotnie aplikacja ważyła 4 MB. Po realizacji wyżej wymienionych zabiegów wielkość plików ściąganych przez przeglądarkę zmalała do 140 KB.

•

Talk #3: Dlaczego Twój administrator Cię nienawidzi? [PL] Maciej Maciejewski

Miękka prezentacja. Czasami i takie są potrzebne, bo przecież sami developerzy nie wystarczą, aby zbudować projekt. Równie ważni są także devopsi / admini.

Administrator też chce dobrze dla projektu. Tylko patrzy na niego z innej strony.

Jeśli jesteś programistą, to jesteś użytkownikiem zaawansowanym.

Kilka wskazówek podczas współpracy

  • trzeba być konkretny w komunikacji z administratorami, nie można powiedzieć “strona nie działa”
  • nie można być gamoniem 😄 bo zostanie się zaszufladkowanym
  • nie prosić o deploy w piątek, generuje to duży kłopot jeśli deploy się nie powiedzie
  • trzeba znać podstawy działania internetu oraz protokół HTTP
  • podstawowe kody odpowiedzi HTTP powinny być w głowach programistów, albo chociaż odróżniać 400-setki od 500-setek
  • developerzy powinni znać stack projektu w którym biorą udział
  • nie hardkodować w kodzie adresów IP, co jeśli takie adres się zmieni w tzw. międzyczasie?
  • napisać prostą dokumentację w README.md zawierającą wymagania projektu
  • nie testuj sam swojego kodu!
  • pisz testy jednostkowe oraz integracyjne, podniosą one komfort pracy z aplikacją
  • nazywaj commit message-e dokładnie, np. "poprawa nawigacji" niewiele mówi

Zakazy dla developera

  • nie dostaniesz root-a na produkcji
  • nie będzie wdrożeń małych zmian - wszystko musi przejść odpowiednią procedurę na wypadek gdyby mała zmiana rozwaliła system
  • nie będziesz zmieniał konfiguracji serwerów - administratorzy potrafią to zwykle zrobić lepiej

Najważniejsza zasada

Nie używaj zwrotu: “u mnie działa”. Wypowiedzenie tego przy adminach spowoduje tylko niepotrzebne przypływ adrenaliny.

Wszelkie problemy z wydajnością można rozwiązać wspólnie.

Hint odnośnie skalowania aplikacji

Łatwiej jest postawić 500 kopii tego samego kodu, niż sprawić, aby jedna kopia działała 500 razy szybciej.

Ale dlaczego się nie da?

Nie zawsze administrator może coś zrobić. Stoi za nim kilka argumentów:

  • stack technologicznych zdefiniowany w umowach
  • istnieją problemy licencyjne
  • wymogi bezpieczeństwa

Administratorzy i developerzy mają ten sam cel. Widzą go natomiast z innych perspektyw. Jeśli admini ufają programistom to dużo łatwiej i szybciej uda się zrealizować cele.

Dla przypomnienia

Pracujemy w eksperckich zawodach, nie musimy więc się na siebie obrażać.

•

Panel dyskusyjny

Podczas panelu dyskusyjnego poruszone zostały 3 pytania:

  • Nowa składnia: Czy jest warta uwagi? Jaki jest najlepszy feature?
  • Asynchronous JavaScript: Jak sobie z nim poradzić?
  • Node.js: Dla kogo? Po co? Jak?

A na pytania odpowiadali:

•

Sponsorzy spotkania

•

Podsumowanie

Świetny meetup. Lubię wykłady o optymalizacji, a tym bardziej jeśli dotyczą one stacka którego używamy na co dzień (Angular 4). Prelekcja Maćka również świetna. Przypomniała mi trochę stare czasy, kiedy to ja byłem tym raczkującym developerem i czułem się jak dziecko we mgle.

Do zobaczenia w kolejnej relacji ze spotkania!
Tym razem z dzisiejszego wydarzenia - WarsawJS Meetup #35