Ostatnio czyli - 05.03.2020 odbyło się 33 spotkanie grupy ng-wroclaw. Meetup odbył się oczywiście w potężnej kuchni w biurze firmy PGS Software. Spotkanie odbyło się po dłuższej przerwie, która była spowodowana między innymi tym, że organizatorzy chcieli zmienić trochę formułę dotychczasowych spotkań oraz w ogóle chcieli się zastanowić i przemyśleć co zmienić i w jaki sposób po to, by spotkania cały czas były dla wszystkich atrakcyjne.

Meetup planowo rozpoczął się o godzinie 18:00. Kilka minut przed 18 w samym holu dolnym gdzie są wejścia do biur, była już niemała kolejka ludzi oczekujących na wejście. Każda osoba musi być sprawdzona czy występuje na utworzonej wcześniej liście, dlatego chwilę trwało samo wejście oraz wjazd wind na kilka razy. Na samej górze już było sporo ludzi. Na stronie z ogłoszeniem o tym meetupie zapisanych było końcowo 119 uczestników ! :O. I naprawdę było baaardzo dużo osób, na tyle dużo, że znaczna część kuchni była wypełniona kiedy nawet wszystkie miejsca siedzące były zajęte. Byłem już na kilku meetupach z tego cyklu ale osobiście nigdy chyba nie widziałem, żeby aż tyle osób przyszło :D. Tym razem meetup rozpoczynał się od poczęstunku w postaci pizzy :pizza: a nie jak zazwyczaj było do tej pory - na końcu.

Tak jak napisałem wcześniej, samo spotkanie przybrało trochę inną formę. Do tej pory były to prezentacje o różnej długości poszczególnych prelegentów na dany temat. Tym razem całość była poprowadzona jako panel dyskusyjny, w którym brali udział trzej rozmówcy.

Wszystkie szczegóły wraz z agendą dostępne są jak zawsze na platformie meetup.com - ng-wroclaw #33

Kilka słów o prowadzących :

Szymon Pawlak

"Pasjonat rozwiązań webowych zwracający uwagę, na jkość i czytelność kodu. Karierę zaczynał, jako full-stack, po czym wybrał ścieżkę rozwoju, jako frontendowiec. Organizator warsztatów Angular. Gdy nie programuje - ćwiczy trójbój, dwubój i crosffit."

Adam Mortka

"Z webdevem związany od czasów layoutów opartych na tabelkach, pierwsze szlify zdobywał przy kursie Pawła Wimmera. Fan React-a, ES6 i wizualizacji danych. W codzinnej pracy lubi wdrażać mikro-optymalizacje. Prywatnie: mąż, tata, amator fotografii. Uwielbia słuchać Pink Floydów podczas jazdy samochodem."

Michał Jawulski

"Na początku swojej kariery był związany z technologiami Microsoftu (Windows Phone wróć...) ale jakiś czas temu przesiadł się na Angulara i JavaScript. Od ponad 6 lat tworzy i projektuje systemy dla firm finansowych z całego świata. Lubi poznawać nowe technologie, pasjonuje go inżynieria oprogramowania. Wieczorami rozwija własne projekty , bawiąc się nowinkami technologicznymi. Cały czas jest związany z Wrocławiem. Najpierw skończył studia na PWr a obecnie pracuje we wrocławskim oddziale firmy Capgemini. Poza tym jest kibicem Premier League i relaksuje się grając w Fifę."

Miejsce na panel dyskusyjny. Wyglądało co najmniej jak studio do nagrań wywiadów :D. Oświetlenie :bulb:, kamery :video_camera:, rejestrator dźwięku :iphone:, mikrofon :microphone:, widownia, listy z pytaniami i tematami, po prostu wszystko. Uruchomiona była również specjalna aplikacja, za pomocą której można było na bieżąco pisać pytania do mówców, które następnie były widoczne dla nich na laptopie.

Meetup ng-wroclaw #33 - PGS Software

To jaki w ogóle był temat tego spotkania ?

Temat główny to - organizacja kodu w aplikacjach typu enterprise. Na początku zostało omówione czym są aplikacje typu enterprise, jakie są definicje, ponieważ też się trochę różnią w zależności od źródła. Przede wszystkim swoją interpetację podali uczestnicy panelu dyskusyjnego. Dla mnie osobiście takie pojęcie do czasu tego meetupu powodowało zazwyczaj skojarzenie z pooootężną aplikacją z sektora finansowego, po prostu jakiś system bankowy. Oczywiście to nie jest tak powiązane i było to w ciekawy sposób wytłumaczone. Mówcy wymienili następujące cechy aplikacji typu enterpise takie jak m.in. :

  • duża wielomodułowa aplikacja
  • mocna integracja z wieloma innymi systemami
  • aplikacja o dużym znaczeniu biznesowym

Jest kilka definicji takich systemów. Oczywiście nie każda duża aplikacja będzie typowo enterprisowa. Jednak następną kwestią jaka została rozważona to czy wielkość zespołu może definiować to, że mamy styczność z aplikacją enterprise. Opinie były różne, jednak pojawiło się stwierdzenie, że wielkość zespołu niekoniecznie definiuje aplikację entersprise. Następnie rozważano czy w takim razie liczba użytkowników może to jasno określić. W tej części dyskusji były rozważane jeszcze inne metryki oraz takie kwestie jak zarządzenie i współdzielenie kodu, które przy tej klasie systemów również jest nietrywialnym zadaniem. Mogą czasami pojawiać się różne dziwne i zaskakujące decyzje co do zmian w kodzie czy nawet technologii. Tutaj była podana ciekawa anegdota, kiedy to w jednym z projektów, niespodziewanie w nocy inna część zepsołu po drugiej stronie Ziemi zmieniła cały stos technologiczny ...

Następny temat - czy da się przewidzieć, że aplikacja będzie klasy enterprise ?

To oczywiście jest zależne od wielu czynników. Aplikacja klasy enterprise musi również spełniać pewne wymagania korporacyjne. Mogą być to zasady dotyczące standardów związanych z kodem po inne bardziej zaawansowane wytyczne. Mogą być również w danej firmie/korporacji założenia, że aplikacje są tworzone tylko w jednej konkretnej technologii. Oczywiście do tego mogą dochodzić kwestie związane z security oraz wymogiem konteneryzowania. Dla osoby tworzącej takie oprogramowanie czyli programisty, to również może być szereg wyzwań do spełnienia. Do tego w obrębie jednej firmy/korporacji mogą występować różne style pisania kodu w zależności od projektu oraz zaawansowania programistów tworzących dany projekt. Wszystkie składowe przekładają się na jakość projektu.

Zostało również poruszone takie zagadnienie jak prawo Conway'a.

Czy kod powinien się sam dokumentować ?

To oczywiście również zależy od zastosowanego podejścia. Mogą być takie założenia by tworzyć dokumentację, może być również tak, że dany kawałek nowo stworzonego kodu musi bezwzględnie przejść code review.

Czy Angular out of the box wspiera enterprise ?

I na tak postawione pytanie jedna z opinii brzmiała następująco - Angular jest tylko narzędziem, a wytworzony produkt końcowy można określić jako aplikację klasy enterprise. Akurat w przypadku omawianego Angulara częsty cykl wydawniczy został uznany jako problem w pewnym sensie, ponieważ może to tworzyć problemy podczas podbijana wersji danej aplikacji oraz przede wszystkim uzgadnianie czegoś takiego ze wszelkimi osobami odpowiedzialnymi za projekt może być kłopotliwe. Ogólnie łatwiej wytłumaczyć klientowi zasadność danej technologii tym, że jest popularna przez co dopracowana i stabilna oraz ma np. duże community.

Sam Angular ma dużo wbudowanych mechanizmów ale również wyższy próg wejścia, ma również wiele styleguide'ów. Natomiast React jako biblioteka nie ma chociażby jasno określonej struktury i w każdym projekcie ten aspekt również może się różnić. Często w ogóle pojawia się takie pytanie - jaka właściwie powinna być dobra struktura projektu w React.

W kontekście Reacta również została powiedziana ciekawostka - mianowicie udało się podbić wersje jakiejś aplikacji opartej o Reacta z wersji sprzed około dwóch lat do najabardziej aktualnej na dany czas i aplikacja zadziałała o tak po prostu bez większych problemów.

Porówniania do samego Vue za dużo nie było, jedynie co zostało powiedziane to, że technicznie zmierza w kierunku React tzn. zaczyna działać w oparciu o podobne mechanizmy, aczkolwiek jak dotychczas każda kolejna wersja nie miała potężnych zmian załamujących całe funkcjonowanie.

I następny temat jaki był poruszony to monorepo vs multirepo.

Czyli co to jest oraz wady i zalety stosowania każdego rozwiązania. Sam się spotkałem już kilkukrotnie z różnymi podejściami, sam również wielokrotnie analizowałem zasadność jednego i drugiego podejścia w kontekście prywatnych projektów, chociaż zawsze stosowałem podejście drugie - czyli multirepo (o ile oczywiście w aplikacji była taka potrzeba by mieć więcej niż jedno repozytorium do czegokolwiek). Jednak domowe projekty to nic w porównaniu do naprawdę dużych projektów, gdzie pracują nad nimi dziesiątki lub setki programistów i takie decyzje mają ogromny wpływ na funkcjonowanie. Jako jedne z zalet monorepo zostały podane - łatwość zarządzania zależnościami oraz ułatwiony cykl wydawniczy. Natomiast przy commitowaniu do takiego repozytorium zazwyczaj uruchamia się cały proces CI/CD. Monorepo wymaga bardzo dobrej komunikacji członków zespołu. Można zaobserwować tendencję wykorzystania monorepo przez duże firmy. Jako przykład został tutaj podany Google, który posiada monorepo dla swoich projektów (poza Chromem i Androidem). Przeprowadzono wśród dwóch tysięcy programistów badania na temat zadowolenia z tego podejścia i znaczna większość sobie ceniła takie rozwiązanie. Jedną z wad, która została jeszcze przedstawiona w przypadku monorepo to dostęp zazwyczaj do całego kodu, wszystkich części aplikacji czy danego systemu. Zaś w multirepo może dochodzić do duplikacji i powielania oraz tworzenia kodu w różnym stylu.

Oczywiście w całej dyskusji było poruszonych znacznie więcej aspektów takich jak :

  • code review w aplikacjach enterprise
  • komunikacja zespołów
  • utrzymanie kodu
  • git flow (wady i zalety i wszelkie następstwa róznych podejść)
  • różne metryki
  • kwestie związane z testowaniem - unit testy, testy e2e, które, kiedy dlaczego są robione
  • różne kwestie przez które 'wkurza' enterprise, czyli długie procedury i w ogóle duża liczba procedur, managerowie, którzy czasami nie mają dobrej lub w ogóle nie posiadają komunikacji z zespołami, narzut na komunikację, mnogość product ownerów

W tej całej dyskusji przewinęło się naprawdę dużo tematów. Różne wątki były omawiane, a przez pytania widowni wiele aspektów zostało jeszcze bardziej poszerzonych lub dopowiedzianych. Oczywiście nie sposób wszysto opisać od a do z co było na takim meetupie. Dlatego zawsze warto przyjść na takie spotkanie jeśli tylko oczywiście można ! Dla mnie był to duży kawałek wiedzy.

Pojawiła się również prośba o propozycje nastepnych tematów, które mogłyby być poruszone na przyszłych spotkaniach. Pomyślałem trochę nad tym i przyszła mi do głowy taka lista potencjalnych tematów czy zagadnień :

  • omówienie dlaczego Angular to kompleksowe rozwiązanie do tworzenia palikacji, jakie dokładnie mechanizmy wpływają na to
  • z jakimi frameworkami wizualnymi można go skonfigurować, jakie są najbardziej popularne rozwiązania w przypadku Angulara (analogicznie tak jak dla Vue jest Vuetify)
  • prezentacja o nowościach w 9 wersji Angulara
  • prezentacja, czy omówienie tego w jaki sposób można samemu zmodyfikować jakieś komponenty Angulara, jak zmodyfikować core czy po prostu komponenty bazowe
  • pokazać w kontekście różnych projektów opensourcowych/javascriptowych jak zostać kontrybutorem w danym projekcie, jak wesprzeć jakiś projekt
  • prezentacja z omówieniem i wyjaśnieniem dlaczego i jak powstały zaawansowane mechanizmy w nowoczesnych frameworkach frontowych, czyli np. treeshaking itp.
  • pokazanie jak zrobić kompletnie najprostszą implementację extremalnie prostego zalążka frameworka javascriptowego na wzór Angular/Vue/React. Czyli jak stworzyć taki micro framework od zera - jaką trzeba mieć wiedzę i jakie znać pojęcia, żeby w ogóle podejść do takiego tematu
  • zrobić takie podsumowanie/zestawienie - po prostu przemyśleć i rozważyć czego jeszcze brakuje w obecnie dostępnych frameworkach ? Co potencjalnie mogłoby do nich trafić, czego chcieliby jeszcze developerzy ? Czy może im w ogóle jeszcze czegoś brakować w dostępnych rozwiązaniach ?

Takie kwestie przychodzą mi do głowy po przemyśleniach. Może któraś z tych propozycji będzie jakąś namiastką do inspiracji :sunglasses:.

Podsumowując. Oczywiście meetup był jak zawsze na bardzo wysokim poziomie organizacyjnym oraz merytorycznym. Forma panelu dyskusyjnego była bardzo ciekawa, już z samego faktu, że pojawiały się trzy różne lub podobne opinie na dane pytanie czy zagadnienie. Po spotkaniu były dostępne ankiety do wypełnienia, gdzie można było określić czy wszystko jest ok albo napisać co można poprawić.