Jeżeli miałbym wskazać największe problemy, z jakimi boryka się branża IT, to oprócz oczywistych oczywistości takich jak źle zarządzane projekty, czy hype driven development itp., to moim osobistym “bólem” jest fakt, że jak na dziedzinę, która lubi przypisywać sobie inżynierskość, mamy potężny problem z weryfikowalności naszych decyzji. Powiedzmy sobie szczerze, w tworzonych przez nas projektach bardzo często potrzebujemy wybrać jedną z wachlarza dostępnych opcji, mając często dość mgliste pojęcie, która z alternatyw będzie lepsza długoterminowo. Nie bez kozery mówi się, że w IT wszystko jest “tradeoffem“, ale pal licho, jeśli bylibyśmy jeszcze w stanie po czasie cokolwiek ocenić i nauczyć się na błędach. Bardzo często tak niestety nie jest – nawet jeśli będziemy w stanie spojrzeć po czasie na powstałe rozwiązanie i zrozumieć jego dobre i złe strony, to tak naprawdę dalej daje nam tylko to mgliste pojęcie, czy alternatywa byłaby lepsza.
Nie da się długoterminowo i równolegle rozwijać np. dwóch różnych architektur, żeby po roku zaobserwować, która daje lepsze rezultaty. Dodatkowo, tak naprawdę każdy z nas ma szansę w swojej karierze “zaliczyć” kilka większych projektów, rzadko kiedy mając okazję pracować przy dwóch równocześnie i mieć możliwość porównywania różnych podejść. Bardzo wiele reperkusji przychodzi po czasie, co nieraz przy dużej rotacji, jaka jednak panuje w branży sprawi, że nigdy nie dowiemy się, czy nie popełniliśmy błędu, trudno się nam więc na takowych nauczyć. Dlatego też tak cenny jest fakt, że pojawiają się opracowania pokroju Technology Radaru – publikacje pomagające ocenić przydatność poszczególnych technik i narzędzi.
Spis Treści
Czym jest Technology Radar?
Dobra, wydaje się jednak że niektórym z Was czytających ten tekst należy się małe wyjaśnienie, czym tak naprawdę Technology Radar jest. Otóż jest to wydawana semi-regularnie (zwykle ok. dwa razy do roku) analiza i ocena trendów wyróżniających się w technologicznym świecie, dokonywana przez firmę ThoughtWorks. W firmie pracują takie uznane osobistości naszej branży jak choćby Martin Fowler czy Rebecca Parson, a sama firma jest agencją konsultingową, pracującą z wieloma dużymi klientami na całym świecie przy często kluczowych dla tych firm projektach. Daje im to dość unikalną perspektywę – są w stanie zarówno przetestować różne rozwiązania konkretnych problemów np. porównując, jak sprawdziły się poszczególne podejścia u poszczególnych klientów, jak i mają widoczność na szerokie spektrum problemów, z jakimi duże firmy muszą się mierzyć.
Są osoby, które mają do Radaru nieco krytyczne podejście, traktując go jako nieco skrzywiony pod kątem wyłącznie większych organizacji – co jest pokłosiem tego, że z takimi podmiotami zwykle pracuje ThoughtWorks – ale z mojej perspektywy każdorazowo jest on zbiorem trafnych obserwacji, pozwalających na mocne poszerzenie horyzontów i “wyłuskanie” dla siebie technik i narzędzi, które może w innym wypadku przeszłyby pod naszym (nomen omen) radarem.
Dlatego też mam dla Was przegląd tego, co w Radarze można znaleźć, pogrupowany w specjalne sekcje tematyczne (pewnego rodzaju hmmm… podział funkcjonalny zamiast domenowego jest najtrudniejszą rzeczą przy konsumpcji Radaru). Mam nadzieje, że dzięki temu opracowaniu docenicie kapitalną robotę, jaką wykonują inżynierowie z ThoughtWorks.
Jeżeli jesteś programistą mobilnym….
Czytając Technology Radar od dłuższego czasu, bardzo ciekawym jest obserwowanie tego, jak coraz mniej miejsca z każdą edycją poświęcone jest wszelakim technologiom mobilnym. Z pewnością powód jest taki, a nie inny charakter klientów ThoughtWorks (duże podmioty, raczej z bardziej “tradycyjnych” branż – nowoczesne startupy czy FAANG nie korzystają z tego typu konsultingu), pokazuje to jednak, że o ile spokojnie możemy się zgodzić, że przeciętny konsument dawno wszedł w erę Post-PC, to równocześnie aplikacje mobilne przestały być przestrzenią, o którą szczególnie się walczy, a rynek dokonał już swoistego “podziału łupów”. Coraz trudniej się wypromować, coraz trudniej zachęcić ludzi do używania dedykowanej aplikacji, jest to również dość droga fanaberia ponieważ klienci oczekują również istnienia równoległego dobrego “webowego” doświadczenia. Tym razem jednak sytuacja wygląda trochę inaczej – Radar dostarczył nam kilka ciekawych projektów i technik związanych z tym segmentem rynku.
Jako że nawiązałem przed momentem do faktu, że na dzisiejszym rynku niezbędne jest posiadanie zarówno mobilnej, jak i webowej aplikacji, pozwolę sobie zacząć od tego tematu. Otóż w nowym Radarze znaleźć możemy dwa hmmm… ekosystemy, które mają nam w tym pomóc. Zarówno Flutter, jak i Kotlin Multiplatform od dawna starają się spełnić obietnice “Write Once, Deploy Everywhere”, poszerzając zakres dostępnych środowisk docelowych. Nowy Radar zauważa to i sugeruje, że każdy z ekosystemów warty jest choćby rozważenia. Ja od siebie dodałbym, że zarówno Flutter, jak i Kotlin celują jeszcze dalej, w ostatnich miesiącach chcąc stać się całkowicie “uniwersalnymi”, celując również w aplikacje desktopowe. Spełnia się więc powoli nasze marzenie o pisaniu “uniwersalnych aplikacji” – co ciekawe, powoli zaczyna wydawać się, że to pomysł przepakowywania stron internetowych był ślepą uliczką. Pożyjemy zobaczymy, ale na pewno jesteśmy na etapie agresywnego poszukiwania alternatyw.
Z tym też pewnie wiąże się mały radarowy “renesans” bibliotek i rozwiązań powiązanych z dwoma największymi graczami rynku – Androidem i IOSem. Radar poświęca bowiem zaskakująco dużo miejsca np. narzędziom do wygodniejszego utrzymania mobilkowych appek. Trafiły do niego uniwersalne TrustKit (umożliwiający zarządzanie kluczami SSL), Flipper (uniwersalny debugger, potrafiący pracować z Androidem, iOSem, ale też np. React Native), czy też bardziej nakierowany na konkretną platformę LeakCanary – narzędzie umożliwiające wykrycie przyczyny wycieków pamięci w aplikacjach androidowych. Pod uwagę wzięty został też fakt, że w dzisiejszych czasach coś, co kiedyś było małą aplikacją mogło przerodzić się w złożony projekt – swoje miejsce w bieżącej edycji znalazła technika modularyzacji dla androidowych aplikacji (on-demand modules), a także narzędzia do utrzymywaniu w ryzach plików XCode, które nieraz potrafią wymknąć się spod kontroli programisty. Całość zamyka też oficjalne applowskie rozwiązanie hmmm… reaktywne – Combine, będące Swiftowym API do zarządzania strumieniami zdarzeń.
Ciekawe, czy taka nadreprezentacja rozwiązań do tworzenia aplikacji natywnych, to jednorazowy wybryk czy odwrócenie długoletniego trendu. Będziemy obserwować
Jeżeli nie wiesz co się dzieje w Twoich systemach…
Mając w swojej karierze trochę do czynienia z systemami Legacy, mam wrażenie że to, co w największym stopniu odróżnia tworzone dzisiaj oprogramowania, to (dość optymistycznie, wiem) lekcje, jakie odrobiliśmy w oparciu o błędy przeszłości. Dzisiaj dobrze zdajemy sobie sprawę z faktu, że napisanie systemu to jedno, ale tak naprawdę trudną częścią całości jest jego utrzymanie i późniejsza ewolucja wraz ze zmieniającymi się wymaganiami rynku. W systemach odziedziczonych po wcześniejszych pokoleniach niejednokrotnie bardzo trudno jest zmapować powiązania pomiędzy poszczególnymi komponentami czy zależności czasowe. Niejednokrotnie znalezienie głupich logów nastręcza problemów. Pewnie stąd też tak duży nacisk położony na tak zwane “observability” – odzwierciedlone jest to również w Radarze, w którym możemy znaleźć kilka narzędzi tego typu.
O ile po stronie serwerowej stosunkowo łatwo agreguje się zdarzenia do wspólnego systemu, o tyle w czasach, gdy coraz więcej logiki znajduje się po stronie klienta, krytycznym staje się możliwość zebrania informacji o potencjalnych błędach, którymi niejednokrotnie zalewane są DevToolsy przeglądarek. Nie możemy łudzić się, że użytkownik zgłosi nam problem – zwykle po prostu już do nas nie wróci, a w bardziej pesymistycznym scenariuszu stanie się naszym publicznym krytykiem. Sami przez lata szukaliśmy dobrego narzędzia do szybkiego wykrywania takich potencjalnych usterek, i z przyjemnością możemy stwierdzić, że wybór, którego dokonaliśmy nie był chyba najgorszy. Sentry, który zbiera dla nas błędy użytkowników Vived, jest również polecany przez edytorów nowego Radaru.
Co ciekawy, Sentry jest jednym z klientów drugiego z rozwiązań pomagających nam odnaleźć się w nawale danych. Nie sztuka bowiem zebrać mnogość logów i zdarzeń z systemu – trzeba umieć się w nich odnaleźć. W takim wypadku przydatnym może okazać się ReDash. Pozwala on przeglądać eventy z naszego systemu w adhocowy sposób, przy pomocy SQLa. Po latach pracy z wszelkiej maści wariacjami własnościowych, jsonowych API do wszelkiej maści systemów, zobaczenie starego dobrego SQLa jest dosyć odświeżające.
Z systemami do observability wiąże się też smutny fakt – przy odpowiednio złożonym systemie zawsze pojawi się coś wymagającego naszej uwagi. Stąd też, jeżeli chcemy zadbać o zdrowie psychiczne nasze i naszych zespołów, niezbędny jest system pozwalający na zarządzanie zdarzeniami w sposób kontrolowany i uporządkowany. Takie narzędzie też znajdziemy w Radarze – będzie nim Opstrace. Jest to rozwiązanie typu Low-Code (w dodatku OpenSource), pozwalające nam pospinać różnego rodzaju usługi w jeden, łatwo zarządzalny interfejs, dzięki któremu możemy szybko zareagować w wypadku jakiegokolwiek problemu. Pozwala on na zarządzanie alarmami, heltcheckami i ogólnie pełnym “devopsowym” procesem. Wygląda bardzo interesująco i takim też został uznany przez inżynierów z Thoughtworks.
Kończąc tą sekcje, należy pamiętać, że nie wszystko należy “obserwować”. W czasach coraz większego nacisku na prywatność ze strony użytkowników niezbędne jest, aby pamiętać o tym aspekcie projektując nasze systemy “obserwowalnościowe”. ThoughtWorks podkreśla w nowej edycji, że szczególnie istotne jest to zwłaszcza w przypadku serwisów działających bezpośrednio z klientem – czy to mowa o przywołanym już Sentrym, czy też np. Web Analyticsach pokroju rozwiązania google’owskiego. Ja od siebie dodałbym tylko, że nawet zachowując pełnię anonimowości nie trudno o kontrowersję – ostatnie rozwiązania pokroju FLOC od Google pokazują, że jeżeli chodzi o prywatność użytkowników, przed nami jeszcze długa droga. Ethical Explorer, również pojawiające się w obecnym Radarze rozwinięcie przywoływanego już EthicalOS, wydaje się być wartościowym przewodnikiem po tym dość grząskim gruncie, nie raz wymagającym od nas eksperymentów myślowych z etyki.
Zainstaluj teraz i czytaj tylko dobre teksty!
Przeczytaj tą sekcje jeśli musisz się zmodernizować… szybko i skutecznie
Jako że przywołałem już Legacy, jak pewnie domyślacie się, temat modernizacji systemów jest mi dosyć bliski. Dlatego też nie mogę sobie odmówić w naszym małym podsumowaniu przypatrzeniu się również temu, co Radar ma do powiedzenia w tym kontekście.
I moje serduszko cieplej zabiło, gdy tylko zobaczyłem, że przywołana została technika modernizacji oparta na hipotezach. Jest to moja ulubiona, której sam poświęciłem sporo miejsca w napisanym przeze mnie niedawno ebooku. Otóż faktem jest, że tak naprawdę pracę ze starymi systemami naprawdę trudno jest dobrze zaplanować. Kto miał okazję pobawić się w tego typu archeologie wie, że cały czas rzucają nam kłody pod nogi, a rzeczy, które pozornie wydawały się być proste okazują się kryć tajemnice, których rozwikłanie nieraz wykracza poza ramy zwykłego, dwutygodniowego sprintu. Dlatego też inżynierowie od Technology Radaru zalecają iteracyjność, eksperymentowanie i niejako odkrywanie na nowo tego, jak system działa, kierując się nie z góry zaplanowanym backlogiem, a na bieżąco potwierdzonymi lub obalanymi hipotezami. Taki prawdziwy “agile” użyty w dość nieortodoksyjny sposób. Jest to w oparciu o moje doświadczenie tak naprawdę jedyna skuteczna metoda i cieszę się, że technika ta została teraz ubrana w tak elegancki termin. Nazywanie rzeczy pomaga budować wspólny, zrozumiały dla wszystkich słownik.
Mam też trochę ubaw z faktu, że Single Page Application też już podchodzą pod bycie “legacy”. Po początkowym zachłyśnięciu się nowymi możliwościami, relatywnie szybko odkryliśmy jako branża, że skomplikowany kod kliencki posiada jednak sporo wad i jest bardzo trudny w utrzymaniu. Jeżeli nasza strona stała się nieutrzymywalną kulą błocka, ThoughtWorks sugeruje “zaduszanie” – technikę znaną m.in. właśnie z zastępowania przestarzałych już systemów. Ostrzegają oni co prawda, że niektóre z podejść mogą wiązać się z zepsuciem wydajności dla użytkownika końcowego, ale niejednokrotnie jest to jedyne wyjście z sytuacji, gdy nasz kod stał się na tyle nieutrzymywalny, że każda zmiana staje się katorgą – sam miałem okazję pracować z (i pewnie też pisać…) tego typu narzędziami tortur, gdzie każda zmiana CSSa powodowała palpitacje serca. Dobrze, że Frontend też uczy się zalet modularyzacji.
Co ciekawego znajdzie dla siebie Frontendowiec?
Jest to ta część ekosystemu, która zwykle rozwija się dosyć dynamicznie, co oczywiście nie umyka twórcom Radaru. Sprawia to, że jak zwykle mamy całkiem sporą nadreprezentację tematyczną.
Tak jak już mieliśmy okazję wspomnieć, przy tematach związanych z modernizacją, współczesne aplikacje klienckie posiadają masę logiki, zbliżoną do systemów działających “pod maską”. Dlatego też coraz więcej energii poświęca się frontendowej architekturze. Śmiem twierdzić, że w świecie, w którym ustabilizowała się nam wielka trójca frameworków (Angular, React, Vue), to właśnie do świata Microfrontendów przeniosły się największe bo
je o rynkową pozycję. Poza już wspomnianym SPA Injection (które do tematu bardzo pasuje) Radar przynosi rozpychające się łokciami Webpackowe rozwiązanie – Federacje Modułów, ale także nieco zbliżone w koncepcji, a rozwijane jako standard przez Web Incubator Community Group mapy importów, opierającej się na “klejeniu” aplikacji z mniejszych kawałków za pomocą standardowego systemu modułów EcmaScript.
Przyznam jednak, że o ile tamte dwa rozwiązania z pewnością znajdą szerszą rzeszę fanów, to mnie najbardziej ujął hotwire – aronim HTML over the Wire. Podejście to zostało rozpropagowane przez Basecamp, znany ze swojej miłości do statycznie renderowanych stron (czegoś innego spodziewać się zresztą od twórców Ruby on Rails), przenoszące je w świat asynchronicznego doładowywania kontentu. Otóż sugerują oni, że systemy templatingu po stronie klienta, to kod w ślepą uliczkę i tak naprawdę… najlepiej jest przesyłać do frontu HTMLa wyrenderowanego po stronie serwera. Nie da się ich argumentacji (którą znaleźć możecie pod linkiem) odmówić sporej ilości sensu, a dodatkowo dostarczając dość bogaty zestaw narzędzi. Może ktoś z Was się skusi?
TypeScript dzieli i rządzi frontentdowym światem, dlatego też nikogo nie powinna dziwić jego może nie największa, ale z pewnością interesująca reprezentacja w bieżącym Radarze. W świecie, gdzie Deno (alternatywa do NodeJS traktująca TypeScripta jako obywatela pierwszej kategorii) próbuje przebić się do świadomości programistów, a i sam król Node coraz przychylniejszym okiem spogląda na dziecko Microsoftu, technika polegająca na dzieleniu typów między Frontentedem i Backendem (dla Frontendu) wydaje się być dość oczywistym kierunkiem – aczkolwiek zawsze dobrze, jak o tego typu rzeczach się wspomnia.
Nieco mniej oczywistym rozwiązaniem komunikacji Frontend/Backend (zwłaszcza w świecie, gdy rozwiązanie serwerowe nie jest napisane w TypeScripcie). Jest to zestaw narzędzi (Encoderów/Decoderów), których zadaniem jest sprawdzać poprawność otrzymanych danych nie tylko na poziomie kompilacji, ale również w runtimie. Brak wsparcia TypeScripta dla dynamicznego typowania jest zrozumiałą decyzją projektową, biorąc pod uwagę chęć zachowania kompatybliności z JSem, ale dobrze mieć w arsenale narzędzia, które zapewnią spójność aplikacji również poza momentem kompilacji.
Nie mogło w Radarze zabraknąć również podsumowania nowości ze świata frontendowych frameworków. Wyjątkowo nadreprezentowany jest tutaj React, który może pochwalić się naprawdę sporą ilością rozbudowujących go narzędzi. Z rzeczy, które mnie najbardziej zaskoczyły wymienie z pewnością jotai i zustand – dwa różne projekty mające na celu okiełznanie zarządzania stanem w Reactcie, podchodzące do tematu z nieco odmiennej perspektywy. To, co jest dość unikalne, to to, że mimo że stanowią wobec siebie wzajemną konkurencję, wspiera je ta sama grupa – Poimandres.
Narzędzia do zarządzania stanem (to musi być straszliwie złożony problem w Recie, skoro w każdej edycji Radaru mamy wręcz zatrzęsienie jego rozwiązań) reprezentuje też SWR (stale-while-revalidate) – rozwiązanie opierające się w zupełności na Reactowych Hookach, a którego celem jest bycie cache nad requestami HTTP – automatycznego ograniczenia ilości zapytań do serwera, co prowadzi do ładniejszego i czytelniejszego kodu, bez ifów sprawdzających, czy nie posiadamy już danego zestawu informacji. Ograniczyć ono też może ilość “repaintów” aplikacji, czyli niepotrzebnego męczenia przeglądarki ponownym rysowaniem komponentów ze względu na nadmiar zmiany w strukturze danych – w wykryciu takowych zaś pomóc może nam did-you-render – małe narzędzie informujące nas w wypadku wykrycia tego typu nie optymalności. Na hookach także React Hook Form – rozwiązanie stające się powoli standardem w świecie zarządzanie formularzami w Reactcie.
Nie można też nie wspomnieć o Next.js – “brakującym” frameworku dla Reacta. Next.js prezentuje “opinionated” zestaw bibliotek i praktyk, pozwalających na szybkie zasetupowanie, a później również też pisanie aplikacji reactowej. Wprawdzie to środowisko zawsze ceniło sobie tę swobodę własnoręcznego dobierania odpowiednich “baterii”, ale choćby ostatnie dofinansowania do Next.js udowadniają, jaki potencjał mają narzędzia jego pokroju.
Angular jest w nowym Radarze reprezentowany znacznie węziej – mamy bowiem do czynienia tylko z pojedynczą biblioteką – Angular Testing Library. Ta kopia React Testing Library zyskuje na popularności, w czym z pewnością nie przeszkadzają ostatnie zapowiedzi zabicia projektu Protractor, stanowiącego przez lata standard tego, jak testuje się angularowe aplikacje.
Całego frontentdowego obrazku niech dopełni fakt, że coraz więcej miejsca poświęcone jest WebAssembly. Mamy bowiem w nowym Technology Radarze Blazora od Microsoftu oraz służące do jego tesowania bUnit. Niby nie tak wiele, ale w dalszym ciągu należy pamiętać, że angularowi poświęcono o połowę mniej miejsca.
Nowe rzeczy w temacie konteneryzacji
Szeroko pojęta konteneryzacja jest tematem, który zwykle dość licznie reprezentowany jest w ramach Technology Radaru. Tym razem zaskakująco nie mamy nawału różnego rodzaju kubernetesowych tooli, ale też znajdziemy sporo interesujących projektów.
Od lat można zauważyć proces coraz większego odchudzania obrazów dockerowych. Początkowo do obrazów wrzucane tam były najnormalniejsze, pełne dystrybucje Linuxa, następnym krokiem było stopniowe ich odchudzanie, wyrzucanie możliwości logowania się do obrazu itd. Czasem motywacją był rozmiar, a czasem ograniczenie potencjalnych wektorów ataku. Jeżeli motywuje nas to ostatnie, to kolejnym krokiem są tak zwane ‘”Distroless” Docker Images’. Są to docięte do minimum wersje Linuxa rozpropagowane przez Google’a, posiadające wyłącznie aplikacje i sam trzon systemu operacyjnego. Nie znajdziemy w nich powłoki czy menedżerów pakietów. Pewnie do debuggingu lokalnego nie chciałbym musieć tego używać, ale jako artefakt do Kubernetesa, brzmią już one całkiem interesująco.
Jeżeli już jesteśmy w temacie bezpieczeństwa – może szukacie lepszej pod tym względem alternatywy do Dockera? Jeśli tak, może zainteresujecie się podmanem. Jest to w pełni zgodny z API Dockera (do poziomu, gdzie jego twórcy zalecają dla wygody zaliasowanie go w shellu komendą docker) tool, umożliwiający uruchamianie obrazów z kontekstem użytkownika nie będącego rootem. Jak łatwo się domyślić, jest to dobra dodatkowa ochrona. Do tego ma bardzo “cute” ikonkę. Czego chcieć więcej od toola devopsowego? #FokiPonadWielorybami
Jeżeli zaś używamy już Kuberenetesa i chcemy w ramach tej platformy uruchamiać wszystkie niezbędne fragmenty naszej infrastruktury, najlepszą metodą może być użycie tak zwanych “operatorów”. Ten parasolkowy standard umożliwia uruchamianie w ramach klastra popularnych aplikacji. Niech przykładem będzie tutaj Jenkins Operator, używany u nas w firmie. A jeżeli spodoba Wam się takie podejście, to ostatnim narzędzie które możecie znaleźć w Radarze jest Longhorn – kubernetesowy odpowiednik S3. Persystencja w ramach K8s nigdy nie była prosta, Longhorn zaś chyba rozwiązał ten problem całkiem nieźle. Wydaje się, że może być interesującą alternatywą, jeśli nie chcemy rozwiązań “managed” lub naszym celem jest zamknięcie wszystkiego w ramach własnej podsieci.
ThoughtWorks pamięta o designerach
Oni też znajdą dla siebie coś w nowym Radarze.
To, że Design Systemy (zestawy gotowych do użycia komponentów, które programiści mogą łatwo zainkorporować w swoich projektach) są przydatne, jest już niejako truizmem. Są one, co prawda sporą inwestycją, ale z gatunku takich wpływających na długoterminową produktywność zespołów programistycznych – a więc z takich, co dość szybko się spłacają. Co jednak przykuło moją uwagę w nowym Radarze, to fakt pojawienia się Bit.dev – platformy low-code, pozwalającej na połączenie UIowych klocków z różnego rodzaju dostarczycielami danych, w efekcie pozwalając na łatwe spinanie do kupy rzeczonych komponentów w funkcjonalne aplikacje. Co wyróżnia Bit.dev z nawału innych platform to fakt, że pozwala na działanie zarówno w ramach hostowanej przez nich platformy, jak i może być zainstalowana po prostu jako zewnętrzna zależność – bardzo lubię narzędzia dające tego typu elastyczność.
Jak już jesteśmy w temacie low-code, to ciekawym rozwiązaniem jest imgcook. Ta chińska biblioteka mająca swoje korzenie w Alibabie pozwala na automatyczne wygenerowanie strony z plików Sketch / Photoshop, używając do tego Deep Learningu. O ile efekty nie są jeszcze idealne i wymagają od projektantów nieco porzucenia kreatywnej wolności (aczkolwiek w stopniu ponoć akceptowalnym dla większości), to całość zdaje się działać . A przynajmniej świadczy o tym fakt, że Alibaba Group sporo swoich prostych, eventowych stronek właśnie tak wypuściło na produkcję. W ciekawych czasach żyjemy, oj ciekawych.
Jak powinniśmy testować oprogramowanie?
Testowanie to zwykle ta część, która bywa mocno “technologio specyficzna”, ale akurat obecna edycja Radaru daje nam kilka tooli relatywnie agnostycznych do naszego stacku.
Pamiętam czasy, kiedy w zasadzie de facto standardem do testowania wydajności aplikacji był Gatling. Jego panowanie chyba powoli odchodzi w cień, bo coraz częściej to właśnie k6 jest przywoływany jako nowy złoty standard dla tego typu rozwiązań. Wynika to z faktu, że twórcy zauważyli, jak kluczowym dla tego typu toola jest mnogości integracji i łatwość połączenia go z usługami zewnętrznymi. Żyjemy w czasach, gdy rozwiązania technologiczne się ze sobą mocno przeplatają, dlatego też nie dziwi fakt że dla wielu programistów jest to kluczowa funkcjonalność.
Testowanie UI to niekończąca się historia. Właściwie przez całą moją dotychczasową karierę mam okazję obserwować powoli zmieniające się technologie, obiecujące kolejne usprawnienia tego dość niestabilnego (zarówno poprzez potrzebę uruchomienia zewnętrznej aplikacji, jak i fakt, że po prostu nie łatwo jest napisać utrzymywalne testy dla UI). Kolejnym ważnym graczem w tej przestrzeni wydaje się być Playwright – narzędzie stworzone przez twórców Puppetera, którzy nauczeni tym co działało się, a co nie działało w ich poprzednim narzędziu, postanowili stworzyć kolejne. W poprzedniej edycji Radaru, Playwright znajdował się w sekcji Asses, teraz przeszedł to Trial – widać, że zdobywa coraz większe zaufanie ThoughtWorksowych Developerów.
A wiecie, co jeszcze ciężko się testuje? Infrastrukturę. Dlatego też dobrze wiedzieć, że powstają narzędzia pozwalające nam nabrać pewności również do tego fragmentu procesu developerskiego. Terratest, przeznaczony do popularnego Terraforma, przeszedł bardzo podobną drogę jak Playwright -> w poprzedniej edycji był w Asses, teraz trafił do sekcji Trial. Zobaczymy, jak jego losy będą się rysowały w kolejnych miesiącach.
Simplicity Matters
Dla tych którzy o tym zapominają, Radar ma dwie przypominajki.
Po pierwsze, przypomina że jednak skomplikowane Design Doci są już pozostałością epoki, która minęła. Komunikacja pisemna, zwłaszcza w czasach kiedy ciągle jeszcze praca zdalna jest mocno rozpowszechniona, jest niezbędna – nie bez kozery mówi się, że umiejętność szeroko pojętego “technicznego pisania” jest jedną z nieodzownych cech dobrego inżyniera Anno Domini 2021. Dobre edytor to zaś taki, który czas z tyłu głowy odbiorcę komunikatu. Design Doci ze starych epok były świetne jako baza wiedzy (ale naprawdę, zdarzało
się że uratowały mi skórę przy próbie zrozumienia starych systemów), ale jeśli naszym celem jest otrzymanie feedbacku od zespołu z którym musimy współpracować, to prawdopodobnie powinniśmy się skupić na jak najkrótszej formie, mającej na uwadzę zarówno “attention span”, jak i po prostu nawał obowiązków z drugiej strony. Dlatego też Radar zachęca do jak najbardziej zwięzłej formy tak zwanych Request-for-comments, które lepiej znane są pod postacią skrótu RFC.
Podobnie prezentuje się sytuacja w kontekście Machine Learningu. Nietrudno jest bowiem zabrać się za szerokie zbieranie danych, próbę stworzenia datasetu w celu użycia którejś z nowoczesnych technik. Jednak kluczowe jest wzięcie tutaj pod uwagę, na ile pozwoli nam to uzyskać efekt końcowy o tyle lepszy, że rekompensujący odpalenie olbrzymiej, często bardzo drogiej machiny. Nowa edycja Radaru radzi próbować podejść do tematu prostymi metodami, typu bazowe modele naklepane w Pythonie, a dopiero gdy to nie zadziała próbowanie z bardziej skomplikowanymi metodami i algorytmami state-of-the-art.
Od Remote nie uciekniemy, trzeba go wykorzystać
Biorąc pod uwagę, jak przez wszystkie przypadki odmieniana była praca zdalna w ostatnim półroczu, przebitki tej dyskusji możemy też znaleźć w publikacji ThoughtWorks.
Okazuje się, że praca zdalna ma pewne oryginalne zalety. Otóż w momencie, gdy jesteśmy w biurze, wspólna praca nad jednym problemem jest ograniczona przez… fizyczną przestrzeń. Monitory są małe, salki czasem ciężko zarezerwować (za tym aspektem biura na pewno nikt nie tęskni). Na wideokonferencji zaś można udostępnić ekran dladowolnie dużej ilości kolegów z pracy. Dlatego też jedną z technik, którą według twórców Radaru warto choćby mieć w arsenale, jest Remote Mob Programming. Jest to rozwinięcie Mob Programmingu, gdzie tłum ludzi pracuje nad jednym kodem, regularnie zmieniając osobę mającą dostęp do klawiatury. Okazuje się, że nasze narzędzia są już na tyle dojrzałe, że jest to w sytuacji pracy zdalnej po prostu wygodniejsze i łatwiejsze do przeprowadzenia. To co, ktoś z Was kiedykolwiek mob programował lub zamierza to robić?
Apropo wspomnianych coraz lepszych narzędzi – w nowym Radarze pojawia się Tuple. W czasie pandemii inżynierowie z Thoughtworks przetestowali wiele różnych aplikacji i właśnie Tuple według nich najlepiej sprawdza się w sytuacji wspólnej pracy zdalnej nad jednym kodem. Jako jedną ze szczególnych zalet tego rozwiązania wskazują oni unikalną możliwość sterowania jednym kursorem przez dwie osoby.
Kilka interesujących technik, jak dbać o nasze zespoły
Bardzo ciekawym aspektem, już w zasadzie kilku poprzednich Radarów, jest duży nacisk jaki ludzie z ThoughtWorks kładą na produktowe podejście do rozwoju każdego oprogramowania, także wewnętrznego – zarówno przeznaczonego do biznesu, jak i będącego “infrą” dla pozostałych zespołów. W aktualnym Radarze przeciwstawiają oni bardzo mocno to podejście, w którym wszyscy ludzie są bardzo mocno zaangażowani w rozwój usługi dającej konkretną wartość dla klienta, typowym “silosowym” organizacjom i zespołom, określanym tutaj jako layered platform teams. Sugerują oni, że bardzo łatwo ukryć klasyczne klastrowanie, nazywając poszczególne zespoły np. DBAów “platformowymi” i udając, że jesteśmy nowocześni i interoperacyjni. Zauważają za to, żeby podziału organizacji, zwłaszcza zespołów przynoszących “wartość”, dokonywać w sposób szanujący “ładunek kognitywny” ludzi w nich pracujących. Chodzi o to, żeby zespół realnie mógł skupić się nad jednym problemem, w miarę jednolitym stosie technologicznym – inaczej możemy doprowadzić do przemęczenia ludzi i sprawienia, że będą oni nieszczęśliwi oraz mało wydajni.
Ciekawą rzeczą jest fakt, że dość krytycznie Thoughtworks wypowiada się o oprogramowaniu Backstage. Jest to, zbierająca spore ilości pozytywnego buzzu aplikacja do tworzenia tak zwanych wewnętrznych “developer portali”, będących w zasadzie kolejną warstwą abstrakcji np. nad dostawcami chmurowymi. Inżynierowie tworzący Radar ze swojego doświadczenia twierdzą, że wymuszają one często bardzo ograniczającą standaryzacje. Z podobnych powodów mają oni też dość jasną opinię, co do SAFE (Skalowalnego Agile). Jest ona zgodna ze starym powiedzeniem: “Główna zasada skalowania: Nie”. Używanie ustandaryzowanych frameworków z konkretnymi frameworkami może być jakimś startem, ale kurczowe trzymanie się generycznych powoduje, że często trzeba naginać styl pracy pasujący do problemu w celu dopasowania się do frameworka, co jest zarówno frustrujące jak i mało efektywne.
Wszystkie rzeczy które dzieją się „Continuous”
W tej edycji, wszystko kręci się w zasadzie w około Gita.
Dla wszystkich, którzy śledzą rynek systemów CI/CD, nie jest tajemnicą że Thoughtworks posiadają własne rozwiązanie tego typu. GoCD, swego czasu jedne z najciekawszych dostępnych na rynku. Z tej perspektywy interesującym jest fakt, że w nowej edycji Radaru sugerują oni spróbowanie chyba najlżejszego ze wszystkich dostępnych rozwiązań do Continuous Delivery – GitHub Actions. Chwalą oni wygodę, prostotę i (jakże by inaczej) integrację z repozytorium kodu. Używanie GitHub Actions broni nas też przed jednym z antypatternów jakie odnaleźć możemy w nowym Radarze – utrzymanie kodu źródłowego aplikacji i kodu źródłowego pipeline przez dwa niezależne zespoły. Radar bardzo jasno wypowiada się, że jest to bardzo, bardzo zła praktyka.
A skoro o antypatternach, to ogólnie dużo więcej znaleźć możemy wskazówek czego nie robić niż co robić. Przykładowo, raczej odradzane są tak zwane GitOpsy. Jest to opisywane jako rozwinięcie Infrastructure as a Code polegające na automatycznym ściąganiu z repozytorium bieżącego stanu infrastruktury, który to specjalny pooler potem implementuje w ramach produkcyjnego środowiska. Według ludzi z ThoughtWorks, ta dosyć sprytna idea kończy się szybko sytuacjami, że branche dla poszczególnych środowisk rozjeżdżają się. Wynikowo więcej z tego szkody niż pożytku (zresztą, również w wypadku samych deployowanych artefaktów też zwrócono uwagę na ten problem, sugerując automatyczne mierzenie poziomu “rozjazdu” środowisk) . Dodatkowo, pandemia pokazała nam, że model Gitowych PullRequestów przy wszystkich swoich zaletach, potrafi być bardzo blokujący dla zespołów. Dlatego też inżynierowie tworzący Radar sugerują, aby w swoim arsenale posiadać także inne metody utrzymywania jakości (i znajomości) kodu – inaczej tak naprawdę dostajemy długożyjące branże i cała mityczna, ciągła integracja bierze w łeb.
Schodząc trochę z tematu Gita, Technology Radar jest kolejnym miejscem dość jasno wypowiadającym się, że czego jak czego, ale AWSowego CodePipeline lepiej kijem nie ruszać. Jak widać nie wszystko złoto, czego się Amazon dotknie.
Co słychać w świecie Infrastructure-as-a-Code
Pierwsza sugestia przypomina nieco radę, którą znają domorośli eksperymentatorzy, próbujący stworzyć własną bibliotekę do kryptografii – jeśli nie jesteś specjalistą, który buduje tego typu rozwiązanie dla społeczności (a nie na potrzebę kilku zespołów), zdaj się na jedno z istniejących rozwiązań. Rynek Cloud Computingu jest za szybki, zbyt dynamiczny i w dłuższej perspektywie albo rozwijanie własnego rozwiązania będzie za drogie i będziesz musiał się przenieść np. na Terraforma, albo zostaniesz z tyłu za rozwiązaniami chmurowymi, które (jak to już w tym artykule wspomnieliśmy) po prostu rozwijają się zbyt dynamicznie. Mało która firma ma na tyle unikalne potrzeby, żeby nie brać czegoś istniejącego “z półki” – mimo że wielu wydaje się, że tak właśnie jest u nich.
A jakie rozwiązania Radar wskazuje jako interesujące? Jeżeli nie przeszkadza Ci Vendor Lock-In (tutaj masz dobry artykuł dlaczego tak naprawdę nie powinien) i używasz AWSa, ichniejszy Cloud Development Kit zdobywa corazwiększą popularność. Sam pamiętam, jak rozwiązanie to wchodziło na, już wydaje się dość nasycony, rynek i interesujące jest, jak w odróżnieniu od np. CodePipelines, ono akurat zdobyło naprawdę szeroką aprobatę użytkowników. Jeżeli zaś nie używasz AWSa, możesz spróbować Pulumi. Oba rozwiązania przyjęły dość nietypową parę lat temu filozofię – stwierdziły one, że tak naprawdę świat infrastruktury stał się na tyle skomplikowany, że deklaratywne rozwiązania nie w każdym przypadku są najlepszym pomysłem i do opisywania środowiska warto zaprzęgnąć języki Turing Complete – z ich wszystkimi pętlami, ifami i zmiennymi. Mam wrażenie, że to akurat jest ciągły cykl (zaletą deklaratywne rozwiązań miało być właśnie zmniejszenie niepotrzebnej złożoności, którą cechowały oparte na bashu skrypty do deploymentu), ale jak widzimy historia lubi zatoczyć koło.
Dla tych zaś, którzy potrzebują maksymalnego platform-agnostycyzmu, mamy zaś Open Appliaction Model (OAM) – kolejne już podejście do tworzenia abstrakcji nad chmurami, tym razem oparte mocno oparte o Kubernetesa. Pożyjemy, zobaczymy
Kto powinien rządzić chmurą w firmie?
W poprzedniej sekcji opisywaliśmy, że tworzenie własnych narzędzi do zarządzania chmurami to syzyfowa praca, gdyż gonienie wszystkich zmian, które wprowadzają dostawcy chmur po prostu jest mało efektywne. Nieco podobny problem jest z wszystkimi narzędziami do symulacji ich zachowań w środowisku lokalnym. Każdy, kto ich używał wie, że zwykle działają “prawie dobrze”, a nawet jeśli nadążają za tym, co dzieje się w chmurze, to wraz z każdą nową wersją niezbędne są operacje po stronie użytkownika jak np. update jarzm testowych używanych do symulowania zachowania chmury.
Skoro abstrakcje przeciekają, Radar ma interesujące rozwiązanie – olać abstrakcje, i biorąc pod uwagę szybkość internetu i względną taniość zasobów chmurowych w porównaniu do czasu inżynierów, tworzyć indywidualne Cloud Sandboxy na potrzeby każdego z inżynierów. Przy okazji, taki Sandbox rzeczony inżynier powinien móc wyklikać sobie samemu – jedną z odradzanych praktyk jest operowanie chmurą w oparciu o “tickety” do “platform teamu”. Nie pozwala to w realnym świecie oszacować kosztów (to można lepiej ogarnąć poprzez prawidłowe tagowanie maszynek), a powoduje tylko frustracje i wieczne opóźnienia – ogólnie mam wrażenie, że szybkość procesów jest jedną z myśli prz
ewodnich samego Radaru.
Zainstaluj teraz i czytaj tylko dobre teksty!
Co Radar przynosi dla programistów JVM?
No jak to co – Kotlin Aczkolwiek nie w takich ilościach, jak w ostatnich edycjach.
Poza Kotlin Multiplatform Mobile, o którym już wspomnieliśmy w sekcji o aplikacjach mobilnych, w Radarze znalazł się Kotlin Flow – abstrakcje nad bardzo popularnymi korutynami, które niejedną osobę przyciągnęły do tego języka. Dobra passa Kotlina się nie kończy – Flow również bowiem uważany jest za bardzo ciekawe podejście do pisania asynchronicznego kodu.
Co mnie jednak cieszy nawet bardziej niż Kotlin (bo jak już wspomniałem, Kotlina nigdy w Radarze nie brakuje), to fakt zauważenia GraalVM. Osoby, które czytają nasze JVMowe przeglądy na pewno zauważyły, że rozwiązanie to coraz bardziej przebija się może nie do mainstreamu, ale na pewno znajduje sobie wczesnych adopterów. Sam mocno kibicuje tej platformie (miałem ją okazję z niezłym skutkiem użyć w jednym z projektów), dlatego też miło widzieć, że również inżynierowie z ThoughtWorks zauważają jej potencjał.
Czy Ty też lubisz lintery?
Lubi je branża, lubię też je i ja, dlatego udało mi się wyłuskać dwa rozwiązania tego typu. Oba też zajmują się “lintowaniem” bardzo podobnego zakresu – specyfikacji naszego API i jego zgodności ze standardem OpenAPI.
Rozwiązania różnią się trochę swoją filozofią – o ile Spectral jest szalenie generyczny – o tyle wspomniane OpenAPI jest jego najczęstszym przypadkiem użycia. Jest to komercyjny projekt, którego użyć można np. również do walidacji konfiguracji Kubernetesa, a samo narzędzie posiada edytor pozwalający na granularne określenie konkretnych zasad. W odróżnieniu od niego, Zally jest znacznie bardziej “opinionated”, opierając się na standardach wobec API wypracowanych przez firmę Zalando. W zależności od Waszych potrzeb, możecie użyć jednego z dwóch rozwiązań – dla każdego coś miłego.
Dla tworzących API w Pythonie
Również dla Was znajdą się dwa ciekawe narzędzia.
Pierwszym z nich jest Pyright – TypeChecker, który potrafi walidować kod w oparciu o adnotacje zgłoszone jako proposale do języka (Python Enhancement Proposals). Jego twórcy (a stoi za nim firma Microsoft – może kojarzycie?) chwalą się, że ich rozwiązanie pozostaje szybkie nawet w wypadku pracy z olbrzymimi repozytoriami kodu.
Szybkość jest też słowem kluczowym w wypadku drugiego z prezentowanych pythonowych rozwiązań. FastAPI to framework, którego inżynierowie od Radaru wskazują jako najlepsze obecne rozwiązania do tworzenia API w Pythonie – w odróżnieniu od takiego Django jest lekkie, wydajne i elastyczne, a przede wszystkim łatwe do zrozumienia – nie wprowadza kilogramów niepotrzebnej magii.
No cóż, to by było na tyle! Zasubskrybujcie się, aby nie przegapić przyszłych przeglądów tego typu. Dodatkowo, zapraszamy do naszych regularnych edycji „Weekly”, gdzie we wtorki, czwartki i soboty opisujemy na bieżąco to, czym żyje nasza branża .
