Przed Wami odcinek numer 87, a w nim… No cóż, robimy coś, czego dawno nie było. Bierzemy pod lupę Technology Radar od Thought Works. Będzie o tym, co nas zaskoczyło, co jest dla nas nowością i jakie WTF-y po drodze nas spotkały. Nie zostawiliśmy na tym dokumencie suchej nitki. Ale żeby było uczciwie, doceniliśmy to, co zasługiwało na docenienie :) Zatem, zapnijcie pasy i zanurzcie się w technologiczne rewelacje razem z nami
Słuchasz Patoarchitektów dzięki Protopii. Sprawdź, jak Patoarchitekci i Protopia mogą Ci pomóc ➡️ protopia.tech
Linki i ciekawe znaleziska:
Szymon Warda: Cześć, słuchacie Patoarchitektów. Prowadzą - Szymon Warda.
Łukasz Kałużny: I Łukasz Kałużny. Wszystkie linki do tego odcinka znajdziecie na Patoarchitekci.io lub klasycznie gdzieś tu na dole, w zależności w czym słuchacie.
Szymon Warda: No i oczywiście zwykły call o to, żeby wysyłać linki, chwalić się itd. babci, cioci, koledze, bo chcemy Pato wyskalować na trochę większą skalę.
Łukasz Kałużny: Tak. Ewentualnie jest tu jakiś przycisk lajku, suba czy whatever gdzie słuchasz. Dobra Szymonie, co dzisiaj dotykamy?
Szymon Warda: Dziś powracamy do trochę starej tradycji, mianowicie przeglądania Technology Radara od Thought Worksa. I będzie ciekawie, bo faktycznie był okres, że przerwaliśmy przeglądanie go dość regularne, bo po prostu tam się nic nie działo. A dziś to się zmieniło trochę tak naprawdę.
Łukasz Kałużny: No jest ciekawie, ale oczywiście Thought Works zapewnia tam też trochę różnych ciekawych WTF-ów, więc z nimi też się poznęcamy dzisiaj. Dobra, to co? Przypomnijmy czym jest Technology Radar.
Szymon Warda: Tak, Technology Radar jest takim podejściem Thoughtworksowym, gdzie Thought Works dzieli obszar technologiczny na takie sobie 4 obszary - technics, tools, platforms languages and frameworks. Każdy z tych obszarów podzielony został na takie cztery strefy. Adopt to jest taka strefa, gdzie Thought Works mówi: tak, używaj, możesz, nie ma problemu, nie musisz dużo myśleć, bierz i używaj. Trial na zasadzie, że spróbuj czy Ci pasuje, ale wygląda na to, że to jest w porządku. Assess bardziej na zasadzie przez dokumentację zapoznaj się, zobacz, niekoniecznie z próbowaniem czy to Ci pasuje. I hold to jest, że raczej nie, my nie rekomendujemy. I taki Radar publikowany jest tam mniej więcej raz na kwartał, raz na pół roku. Przy okazji też można własny Radar budować. Co udało Tobie się wygrzebać?
Łukasz Kałużny: Dzisiaj tak mnie zaskoczyło, jest na GitHubie, zostawiam linka do odcinka, na GitHubie jest - build your own Radar w wersji on-linowej. U nich na stronie jak i u siebie jakoś mi się rzuciło przy przeglądaniu u nich wspomnieli na stronie, że takie coś dodali po prostu.
Szymon Warda: Tak, więc co, przechodzimy de facto przez Radar.
Łukasz Kałużny: To co, techniki na pierwszy rzut, Szymonie i lecimy z tym co wybrałeś w niektórych punktach. Wybraliśmy.
Szymon Warda: I dla mnie też trochę omówiliśmy przed odcinkiem, to jest dziwny Radar, bo na przykład jedną rzecz, która z pierwszych rzeczy, która jest w adopt, jest design systems. Bardzo mocno poruszają co to jest. To jest guide book. Jak się spotkaliście generalnie, to jest po prostu zbiór jak powinny wyglądać przyciski, itd., cały zestaw cech powinien wyglądać. I to jest w adopt. Pierwszy raz pojawiło się w 2021 roku i znowu teraz, więc taki zombi właściwie powrót. Ja trochę nie rozumiem czemu to się pojawiło. To jest coś oczywistego, co właściwie działy marketingu, w ogóle UI-a używają od dawna i totalnie nie rozumiem, czemu to powróciło. Dobra rzecz.
Łukasz Kałużny: Wiesz co? Jest to dobre. Wrażenie z tymi design systems, jak jesteśmy, bo widzieliśmy, parę razy już mignęło, że w większości przypadków to firmy produktowe gdzieś próbują w to albo duże korpo zainwestować. I w większości przypadków to jest bardziej wpis dla UX-owca, że zrobiliśmy własny design system, wpis. To jest odpowiednik naszych zabawek technologicznych w świecie UX-owym.
Szymon Warda: Tak, bo to jest realizacja co jak powinno wyglądać. Dokładnie tak.
Łukasz Kałużny: A spotkałem się gdzieś z taką ciekawą opinią, która jest dobra, że w większości przypadków walić design systemy, tylko UX-owiec razem z front-endowcem powinni siąść i wyklepać wspólnie po prostu bibliotekę komponentów. Nie, że ja mam się zastanawiać jak to przenieść, tylko po prostu dostać gotowca do użycia.
Szymon Warda: Wydaje mi się, że to takie, że wpierw design system, czyli guide book, a potem de facto musimy to przekuć w bibliotekę komponentów. Bo zgodzę się, że sam guide book to niewiele. Komponenty jak najbardziej, ale podejrzewam, żeto dla dużych organizacji, bo one często to robią, to jest kwestia tego, że mają dużo frameworków i dużo komponentów i po prostu wpierw muszą to jakoś uwspólnić. Ale tak, dziwny dla mnie wpis. Ciekawe. Kolejny mamy wspólny, bo mamy lightweight approach to RFC’s. Jakie jest Twoje podejście?
Łukasz Kałużny: Ono jest w adopcie. To jest ważne, że całość jest też w adopcie, bo zapomnieliśmy, design system również jest w całości. Wiesz co, dla mnie to jest troszeczkę rozszerzenie tego podejścia do ADR-ów, czyli twórzmy de facto lightweight ADR-y i z RFC jest de facto… Wiesz, różnie organizacje nazywają HLD, bo RFC jest w większości przypadków gdzieś przeskokiem pomiędzy HLD, high level design i low level design, w zależności od jakichś elementów, jeżeli w firmie mamy jakieś ustrukturyzowane podejście do robienia nowych rzeczy. Jeżeli jest coś za małe na ADR-a, to taki lekki RFC albo RFC dla nowego komponentu jest bardzo dobrą rzeczą, bo daje Ci Request for Comments. Sama nazwa mówi właśnie, żeby wziąć i poddać coś w sformalizowany sposób pod review.
Szymon Warda: Zgodzę się z tym.Trochę jak czytając uzasadnienie Thought Worksa, trochę nie czaję tego, bo oni uzasadniają właśnie lightweight approach to RFC na to, że jest to trochę alternatywa dla ADR-ów, a dlatego, że one się gubią. Tam takie zdania powtarzają się dość mocno.
Łukasz Kałużny: Jestem w stanie w to uwierzyć, że się gubią.
Szymon Warda: Tak, ale dla mnie to jest kwestia organizacji odpowiedniej i złożenia gdzie dokumenty trzymamy, jakie trzymamy niż… Powód dla mnie jest trochę błędny tak naprawdę.
Łukasz Kałużny: Raczej wiesz, w świecie jedna rzecz, jeżeli ADR-y trzymałbyś w kontekście firmy, to trudniej się to w teorii przeszukuje. Podkreślam słowo ‘w teorii’, bo wystarczy dobre tagowanie do którego systemu. A ADR-y mogą się gubić jak mamy strukturę multirepo i trzymamy je blisko kodu.
Szymon Warda: Mogą w teorii się gubić, ale generalnie ja trzymam blisko kodu, bo jestem tego zwolennikiem, to w tym momencie też, jeżeli wiemy o jakim systemie mówimy to łatwo jest je znaleźć. Zresztą search po multirepo też nie jest trudny.
Łukasz Kałużny: Więc dobra, zostawmy. Dla mnie to nie jest zastępstwo, tak jak piszą, ADR-ów.
Szymon Warda: Tak, zdecydowanie.
Łukasz Kałużny: To jest inny level. Dla mnie to jest, jeżeli ADR byłby za duży, to jest to RFC.
Szymon Warda: Dobra. To ja teraz - Automatic Merging of Dependency Update PRs. O co chodzi? Chodzi o to, że jest podejście z automatycznym tworzeniem PR-ów do zależności, czyli automatyczne podbijanie zależności de facto. I będziemy też dalej mówili w kontekście Snyka, bo tutaj mam dość ciekawe.
Łukasz Kałużny: I to jest w trialu?
Szymon Warda: To jest w trialu.
Szymon Warda: I ogólnie rzecz biorąc - zdecydowanie tak. Tylko problem, jeszcze na przykładzie Snyka, jest taki, że to jest trochę niedojrzałe. I teraz o czym mówię? Np. weźmy sobie niektóre toole, niektóre języki pracują na poziomie solucji, czyli mamy solucja, czyli zbiór projektów de facto. A sporo z tych narzędzi podbija poszczególne zależności w poszczególnych projektach. I wtedy otrzymujemy np. 15 PR-ów do jednego brancha, bo każdy projekt ma osobne podbicie zależności.
Łukasz Kałużny: Tak, jak mówisz, w Dependabocie da się lepiej to skonfigurować, GitHubowym. Ale wiesz co, inaczej, patrząc się dlaczego dopiero teraz to się pokazuje?
Szymon Warda: Wiesz co? Akurat to wiem czemu dopiero teraz. Bo jest to trochę niedojrzałe.
Łukasz Kałużny: Raczej wiesz co? Może niedojrzałość w zależności na jakich poziomach, bo to jest bardzo… Mówiąc toolingowo, jeżeli popatrzysz się, zresztą wiesz jak wygląda podbijanie w projektach w pewnym momencie bibliotek, że jest to piekło, bo ludzie robią to raz na rok i potem nie wiadomo jak się zupgrade’ować, albo trzymają się i zapierają nogami, rękami, żeby tego nie zrobić.
Szymon Warda: To jest dziwne, bo tak, Snyk, który właśnie takie funkcje robi, jest w adopt’cie, a technika jako taka jest w trialu, więc to powinno być zupełnie na odwrót.
Łukasz Kałużny: Dobra, do Snyka wrócimy jeszcze, ale ogólnie tak, zacznijcie to robić.
Szymon Warda: Z dobrym toolingiem. Dokładnie tak. Bo ze złym toolingiem, źle wybranym do odpowiedniej technologii w której piszecie, to totalnie nie ma sensu. Więc sprawdźcie dokładnie co będziecie wykorzystywali. Zgadza się?
Łukasz Kałużny: Dobra, co dalej mamy?
Szymon Warda: Ja widzę, że Ty wybrałeś OIDC dla GitHuba, o którym też mówiliśmy, czyli OpenID Connect.
Łukasz Kałużny: Tak. Wiesz co? I to jest z OIDC dla GitHuba i w ogóle cały trend Workload Identity, on jest w trialu, cały trend Workload Identity, czyli że usługi pomiędzy sobą, czyli przykładowo GitHub Actions wystawia swój token OIDC, jesteś w stanie go czy w Azurze czy w AWS-sie czy Google wymienić na token z tamtego Clouda, żeby zrobić jakieś operacje. I dobrze, że to się pojawiło. To jest niby pierdoła…
Szymon Warda: To nie jest pierdoła, bo to umożliwia usunięcie haseł de facto z…
Łukasz Kałużny: Dokładnie, właśnie chciałem powiedzieć, że pozwala Ci wyrzucić hasła i inne rzeczy z konfiguracji. Całość, jak popatrzymy, bo to jest takie jedno przemyślenie, od strony security i ufania temu jest to tricky. Przy czym tak jak powiedziałeś, zazwyczaj składujemy tam też hasła wtedy. Tak więc różnie do tego można podejść.
Szymon Warda: Dla mnie jest to, bardziej to powinno być bliżej adopta tak naprawdę, bo trzymanie haseł, jeżeli chodzi o SIST, gdzie, nie oszukujmy się, jeżeli ktokolwiek przechwyciłby nasze SIST albo dorwał się do tych haseł, to ma prawo pewnie do wszystkiego w ogóle, naszej subskrypcji potencjalnie.
Łukasz Kałużny: Dokładnie, dlatego wiesz, na to patrzę trochę. Hmm.. Jeżeli gdzieś poleci bridge to i tak będzie słabo i tak będzie słabo w tej całej układance.
Szymon Warda: Będzie beznadziejnie, można powiedzieć. Dobrze. Ja jeszcze wygrzebałem dwie rzeczy, o których trochę mówiliśmy i które dla mnie są usystematyzowaniem tego, jakie mam podejście. Jedno to jest Risk Base Feature Modeling, czyli modelowanie ryzyk i skutków de facto. To jest ciekawe podejście, które w ogóle pierwszy raz się pojawiło w trialu. Podejście, które jest używane od 1940 roku, czyli znowu wyciągamy coś z lat czterdziestych, używane w przemyśle lotniczym już od jakiegoś czasu i w ogóle w takich przemysłach raczej, które mają jakieś ryzyka. Chodzi o to, że modelowanie bezpieczeństwa na poziomie generalnie… Upraszczając, jeżeli tu będziemy mieli włamanie, to jakie będą efekty? Czyli myślimy: zdarzenie - skutek tak naprawdę. Fajne usystematyzowanie, szczególnie z racji tego, że jest to proces, który jest dobrze udokumentowany jeżeli chodzi nawet na Wikipedii, w sieci, itd. Więc warto go sobie przejrzeć pod kątem właśnie ułożenia wiedzy i korzystania z osiemdziesięciu lat i więcej innych przemysłów, które radzą sobie dość dobrze. Więc dla mnie fajne, jak najbardziej. I drugie wygrzebane - tracking health over debt, czyli siedzenie z drzewa systemu, a nie mówienie tylko o długu technologicznym,. O czym mówiliśmy nie raz, że dług technologiczny to nie jest coś absolutnie tragicznego i zdecydowanie śledźmy też inne rzeczy.
Szymon Warda: A sam dług to jest kwestia tego, że system jest używany i żyje. Tyle.
Łukasz Kałużny: Dobra i rzecz, którą mamy wspólną, ostatnią z tego, to jest… Powiem tak, nie wiedziałem, że był taki trend, ale brzmi, dobrze, że jest na holdzie, pojawiło się na holdzie, czyli ignoring OWASP Top 10 lists. Kurde, trafiłeś na taki trend?
Szymon Warda: Komentarz w tym, odnośnie, bo to się też pojawiło po raz pierwszy w ogóle.
Łukasz Kałużny: No właśnie tak.
Szymon Warda: To jest, wydaje mi się, że ktoś z Thought Works chciał być zabawny, miał poczucie humoru, bo to jest jedyny sensowny wpis…
Łukasz Kałużny: Wiesz co, bardziej ignoring, nie pasuje mi, to jest bardziej, to powinno być - nieświadomość.
Szymon Warda: Tak, dokładnie, bo według mnie tytuł wpadł tylko po to właśnie, żeby zauważyć… Bo nie oszukujmy się i adopt i on hold są tymi strefami, gdzie ludzie najbardziej na to patrzą, tak naprawdę. Chyba Hold jest nawet mocniejszy. Więc jeżeli nagle wchodzisz, patrzysz, na holdzie jest OWASP Top 10, to jest takie: w ogóle o co chodzi? Chodzi o to, że na holdzie jest ignorowanie de facto. Więc moje podejście jest takie, że ktoś chciał być zabawny i trochę wyszło.
Łukasz Kałużny: Udało się. Dobra, dalej mam tutaj Buzzworda, bo zawsze też patrzę się jakie nowe Buzzwordy się pojawiają. I poleciało tutaj podejście Platform Orchestration, czyli że pasy to za mało, innego typu rzeczy. I całość sprowadza się do tego, że wskazane, że potrzebujemy frameworków do budowy platform.
Szymon Warda: Ja mam też to wpisane sobie i pisałem to na zasadzie generalnie, że temat przy którym mamy takie mikro dyskusje, powiedzmy sobie, dość regularnie i to jest cały temat na to, że już mówimy, będzie cała seria odnośnie platform i w ogóle podejścia, jakie uważamy.
Łukasz Kałużny: Tak, całość inaczej, czy ten buzzword jest OK jako ten sam element. To jest większa część składowa platformy.
Szymon Warda: Tak.
Łukasz Kałużny: I problem rozwiązujemy w zależności od dostępnych kompetencji. Tu nie ma co patrzeć na magiczne narzędzia, dlatego czy jest to faktyczny problem? Tak, jest to problem, ale jeżeli budujesz samodzielnie IDP i tylko wtedy.
Szymon Warda: Zgadza się.
Szymon Warda: Te toole, które wyszczególnili, a wyszło ich dość sporo, mnie do końca nie przekonują. No ale tak jak mówiliśmy, to jest dłuższy temat na dyskusję i osobny odcinek de facto i jak podchodzić do IDP naszym zdaniem.
Łukasz Kałużny: Dobra, lećmy sobie dalej. Co jeszcze tutaj mam? Bardzo fajna rzecz, która się teraz pojawia, to jest Dependency Health Check przeciwko halucynacjom. Czyli tu jest taki trend, który w ogóle w tym Radarze jest bardzo szeroki, czyli jak my wszyscy, Thought Works wskoczył na wagonik z Generative AI Large Language Modules. I to jest fajne, bo zastanawiając się to jest bardzo fajne pokazanie ile problemów ta automatyzacja nam przyniesie.
Szymon Warda: Oj będzie, będzie się działo, zdecydowanie.
Łukasz Kałużny: Tak, więc to jest bardzo fajny przykład. Druga rzecz, która jest dość ciekawa, to są samodzielnie hostowane właśnie LLM-y. Czyli że bierzemy jakiś gotowy przetrenowany open source i samodzielnie go hostujemy, ewentualnie fine-tune’ujemy pod nasze potrzeby. To jest dość ciekawa rzecz.
Szymon Warda: A czy to jest rzecz, którą niektóre organizacje będą musiały przejść, bo nie będą mogły danych do uczenia, bo LLM sięga do jakiś danych, wyrzucić gdzieś to providera chmurowego po prostu.
Łukasz Kałużny: Więc dlatego mówię, że albo gdzieś z przykładów kosztowych i innych. Więc w sensie tak, dobrze, że to się tu pojawiło, to nie jest wymysł. I przypominając ten dokument Googla, że open source jest największym wrogiem w tym kontekście, ich finansów, a nie Open AI.
Szymon Warda: Tak i w ogóle to podejście do LLM-ów, które mają w tym Radarze, naprawdę jest sensowne. Jest pozbyte hype’u i takie no okej, przynajmniej w większości zakresów.
Łukasz Kałużny: Dobra, to lecimy sobie z toolsami.
Szymon Warda: Toolsy, pierwsza rzecz, która jest w adopt, która mnie trochę tak zdziwiła, że jest dopiero teraz, to jest Mermaid czyli diagramy z kodu, diagramy UML-owe. Nie jest to pełen UML, powiedzmy sobie, ale za to są to diagramy, które można rysować.
Łukasz Kałużny: Diagramy z kodu, bo UML-a tam możesz zamodelować i parę innych rzeczy.
Szymon Warda: Dokładnie, to jest o tyle fajne, że po prostu piszemy i potem dodajemy bibliotekę JS-ową, która nam na front-endzie ładnie to generuje. Więc to jest całkiem fajne. Ja dodam tylko tyle, że alternatywą do tego wszystkiego jest to, że jest jeszcze PlantUML, który jest m.in. dodatkiem do Visual Studio Code’a z trochę większymi możliwościami i plus generuje PNG, więc nie mamy problemów z generowaniem JS-a.
Łukasz Kałużny: Tak, Mermaid, przy czym jest w Azure Dev-opsie, w GitHubie jest wbudowany.
Szymon Warda: Tak, więc w pewnych obszarach on jest bardzo, bardzo fajny. I to generowanie, rysowanie czasami potrafi się wykrzaczyć tak naprawdę, więc uważnie z tym, ale stosujcie, zdecydowanie, jedno albo drugie.
Łukasz Kałużny: Dobra, to ja sobie wezmę wspólny punkt, czyli Sirium. Jest to driver sieciowy do Kubernetesa, który działa też na L7, bo korzysta z eBPF-ów, czyli że tak powiem eBPF-y pod strzechy. W tym miejscu można się z tym spotkać i też można powiedzieć, że serwis ma szybę bez sidecarów. Przy czym Istio teraz też dokonało w tym trochę roboty.
Szymon Warda: Projekt ciekawy, bo po pierwsze jest w inkubacji w CNCF-ie, co jest dość ważne, ma wsparcie od Adobe, AWS-a, Google’a, tak że wygląda nieźle.
Łukasz Kałużny: W Azure też jest jako usługa, jest wersja komercyjna, więc jest to duża ciekawostka. W Google’u jest nawet jako natywny driver sieciowy. Więc całość jest ciekawa, czy taka tutaj, w sensie czy ten kawałek powinien się pojawić w Technology Radarze? Mam takie przemyślenie, że te klocki Kubernetesowe, nie wiem czy wszystkie tutaj powinny być, które się pojawiają. To jest dzisiejsze takie, jeszcze jak robiłem sobie przed odcinkiem taki ponowny przegląd tego, to mam problem czy klocki Kubernetesowe jeszcze powinny się tu pojawiać.
Szymon Warda: Ale się dzieje, wydaje mi się. Może nie jest na hype’ie, ale ten Radar nie jest taki hype’owany, on bardzo praktyczny, więc ja nie mam z tym problemu. To teraz lecę do mojego nieszczęsnego Snyka. Dla mnie, moja ogólna uwaga, że cały wpis o Snyku brzmi jak taki product placement. Mi bardzo mocno tak zapachniało okej reklamą po prostu. Żeby nie było, Snyk jest dobrym narzędziem pod wieloma względami.
Łukasz Kałużny: Wiesz co, chociaż słyszałem, że jak się używa go więcej, to ludzie, w szczególności od strony developera, trafiają na 500-ki, time outy. Pozdrowienia dla Gutka w tym miejscu.
Szymon Warda: Faktycznie, Snyk jest… To narzędzie wyewoluowało dość dawno. Pojawił się oficjalnie, nawet jak się odpala obrazy Dockerowe i informacja, że możesz korzystać, więc ktoś nieźle się zadomowił, ma dużo feature’ów. Żeby patrzeć na feature’y, to wszystko potrzebne tam jest. Ja mam problem z tym jak to działa. Bo są mówiłem odnośnie podbijania akurat migracji GitHubem, że podbija automatycznie referencje całkowicie nieużywalne, bo leci dopiero projekt. Więc to jest w ogóle do wyłączenia można powiedzieć. Skanowanie obrazu w plastrze działa jako tako, skanowanie obrazu w rejestrze jest ok, szału nie ma. Fajne narzędzie, które jest drogie jak nie wiem co.
Łukasz Kałużny: No właśnie wiesz, do skanowania całość, wiesz…. Rzecz, która mi się… Statyczna analiza kodu, pytanie, czy starsze? Właśnie chciałem powiedzieć, czy starsze narzędzia nie wypadają lepiej, developerskie.
Szymon Warda: Snyk, jeżeli chodzi o statyczną analizę kodu, wypada słabo, naprawdę słabo. Jeżeli chodzi o skanowanie zależności, które w dependency są aktualne, to ok, to umie, ale kodu nie. Więc jakbyście robili ewaluację go, zróbcie wpierw demo, zróbcie wpierw triale, jak to realnie działa, bo na papierze jest super, szczegóły trochę gorsze.
Łukasz Kałużny: Tak, raczej tak. Do analizy chyba zostańmy przy starym znienawidzonym Sonarze.
Szymon Warda: Tak, pod wieloma względami wydaje mi się, że Snyk jest o tyle fajnym narzędziem, że on w jednym narzędziu zbiera wszystko. Ale jednak chyba osobne narzędzia do osobnych obszarów mogą działać po prostu lepiej. Dobre doświadczenia.
Łukasz Kałużny: Lecimy. Następny punkt wspólny o nazwie Cloud Carbon Footprint, czyli open source’owy tool do mierzenia footprintu cloudowego. Inaczej, czy jest to nam potrzebne?
Szymon Warda: To jest potrzebne. Będzie potrzebne.
Łukasz Kałużny: Będzie potrzebne. Dodajmy jedną rzecz, sponsored by Thought Works. To jest istotny element, który… Nie zrobili product placementu, tutaj powinni dać pełną nazwę, że to ich tool.
Szymon Warda: Oni wierzą, że są dużym kontrybutorem, że tak powiem.
Łukasz Kałużny: A na ich stronie jest takie wielkie ‘sponsored by’.
Szymon Warda: Możliwe, też to wyłapałem, co więcej w opisie jest to w ostatniej linii, że jest.
Łukasz Kałużny: A w stopce jest “made for the world by Thought Works”, to jest w stopce jak wejdziesz na stronę. Dobra, skończmy jeździć. Wiesz co? I tak, czy ta przydatność, będę musiał tu przekląć, to są dane instytutu z dupy, które tutaj będą wyrzucane w tym momencie.
Szymon Warda: Dla mnie problem jest taki, rynek, jeżeli chodzi o Carbon Footprint of Setting się zatrzymał, bo tam zbyt dużo ściemy weszło, żeby to było użyteczne. Pomysł nie jest zły, totalnie nie wiemy w którym kierunku to powinno iść. I to co powiedziałeś też, że cały Cloud Carbon Footprint, umieszczenie go, on jest ponownie, bo wcześniej był w trial w marcu, według mnie to jest taka zachęta: korzystajcie, korzystajcie, bo to jest nasz produkt.
Łukasz Kałużny: Tak, dokładnie, całą rzecz, bo zastanawiałem się, od strony open source’u, dopóki provider nie będzie wystawiał tego w swoich bilingach, to Ty de facto możesz sobie tylko liczyć coś…ekhm, ekhm, bo mają tutaj swoje estymaty. Przy czym nie jesteś w stanie tego w ogóle wyliczyć realnie.
Szymon Warda: Sami piszą, że są jeszcze inne toole, dają różne inne wyniki i czas czasy się od siebie bardzo mocno różnią. Tak, bo to jest szacowanie i bardzo zgrubne szacowanie. Więc co powiedziałeś, to musi być wystawione przez providera de facto.
Łukasz Kałużny: No, więc tutaj na razie to zostawmy sobie. Jedna ciekawa rzecz z tego, słuchaj Szymon, która mi tylko przyszła do głowy, kiedy providerzy to wystawią, to będzie piękne narzędzie wspomagające optymalizację kosztów.
Szymon Warda: To w tym kierunku na pewno pójdzie, bo to optymalizacja .
Łukasz Kałużny: De facto to będzie optymalizacja kosztów, bo ten Footprint równa się jak zrobić coś szybciej i de facto krócej obliczeniowo.
Szymon Warda: Tak, dokładnie i będzie więcej energii. Gdzie ta energia jest tańsza po prostu.
Łukasz Kałużny: Boję się ile będzie kosztował token w Promt’cie w Open AI-u? CO2.
Szymon Warda: Będzie kosztował dużo.
Łukasz Kałużny: Tak, dobra, u Ciebie co jeszcze?
Szymon Warda: Git Merge Queue, mały feature, który dużo poprawia. O co chodzi? Chodzi o to, że możemy, jak mamy brancha do którego mamy kilka PR-ów, możemy je ułożyć w odpowiedniej kolejności i w tym momencie nie tylko weryfikujemy czy nie mamy konfliktów z branchem, ale też jak jesteśmy ustawieni w kolejce. Czyli generalnie nasz może drugi PR będzie zgodny z naszym branchem po zaaplikowaniu pierwszego PR-a, itd. Więc nie jest to nic rewolucyjnego. To jest coś, co jeżeli mamy branch, który faktycznie jest dynamiczny i mamy dużo dużych PR-ów np. albo wiele zespołów kontrybuuje, to nagle możemy to sobie ułożyć i nie mieć tego ryzyka, że właściwie mamy takie długo żyjące branche, bo one i tak czekają na wcześniejsze branche i potem finalnie mają tylko feature, że nie da rady.
Łukasz Kałużny: Ważne, GitHub to takie do podkreślenia.
Szymon Warda: Tak, w GitHubie to jest feature githubowy. Dla mnie ciekawe, bo myślałem, że GitHub już tam dużo nie wykombinuje. Oni dalej w kontekście nawet samego Gita dość sporo nowych rzeczy wymyślają.
Łukasz Kałużny: To ja sobie polecę z WTF-em wokółkubernetesowym.
Szymon Warda: Tak, też to mam wynotowane.
Łukasz Kałużny: Dobra, co tu robi w ogóle KEDA w 2023 roku.
Szymon Warda: Łukasz, ja to uzupełnię. Ona jest po raz pierwszy na Radarze.
Łukasz Kałużny: Pierwszy? Wydawało mi się, że kiedyś była, bo tego nie sprawdzałem. Ale co ona tutaj w ogóle robi? Dla przypomnienia, KEDA to jest Kubernetes Event-driven Autoscaler open source zrobiony przez Microsoft i Red Hata, żeby skalować się w Kubernetesie od zera poprzez eventy i różne sygnały, czego Kubernetes sam nie pozwala. I projekt, który poszedł szeroko, został oddany do CNCF-u, jest teraz wersja druga, jest stabilny, służy w wielu miejscach pod spodem jako element dostarczenia usługi cloudowej czy budowy swoich rozwiązań do autoskalowań. W sensie poszedł w świat kubernetesowy już jako taka rzecz normalna.
Szymon Warda: Jedną rzecz uzupełnię, bo tego nie podałeś. On jest w trialu obecnie nie w adopcie. Po raz pierwszy w trialu. Nie rozumiem tego. Dla mnie to powinno być w adopcie 2 lata temu.
Łukasz Kałużny: Rok temu to na pewno i nie trzeba się nad tym w ogóle zastanawiać. Więc to są te WTF-y, o których wspomniałem. Co Ty masz teraz?
Szymon Warda: Ja mam Pixi.
Szymon Warda: Ciekawy w ogóle projekt, znowu oparty na eBPF-ach i funkcjach, które to ma, czyli nie wymaga zmian w aplikacji. Pokazuje serwis Graph, czyli mapę zależności, który serwis z którym gada, proste, zbiera metryki CPU, pamięci, itd. Normalka. To nic wybitnego. Teraz serwis performance, czyli HTTP, czas odpowiedzi, kolejki, to ok, już wygląda nieźle. Dalej, kwerendy do baz danych zbiera, włącznie z tekstem i umie to normalizować. To jest nieźle. Ale lecimy dalej.
Łukasz Kałużny: Tylko wiesz co? Powiem Ci tak od razu, żeby się nie napalać, compliance’owo jest to duży problem.
Szymon Warda: Wiem, wiem. Ale lecimy feature’ami, bo to bardziej pokazuje, co mogą eBPF-y zrobić. Zbieranie requestu z pełnym body, to akurat jest bardzo śliskie. Ciągły, w sensie ciągle włączony Flame Graph, czyli graf zależności callstacków de facto, które funkcje wywołają.
Łukasz Kałużny: Jest piękny, to tak, robi wrażenie. Ciekawe jak w praktyce.
Szymon Warda: Tak. Żeby nie było, tu się opieram na liście co oni potrafią zrobić, na ich demach i faktycznie w filmach i dokumentacji, bo nie używałem jeszcze, ale robi wrażenie. Dalej. Profiling Kafki, to jest w ogóle jako osobny feature, więc żeby było ciekawie. A i teraz czym się chwalą? Że Pixi zużywa do 5% procesora, najczęściej widzą koło 2%, co jest absurdalnie małą wartością, bo serwis Graph, Flame Graph, zbieranie SQL-i to są generalnie Application Performance Monitoring Toole, które z reguły właśnie koło tych wartości zbierają i często, szczególnie SQL-e, a Flame Graph to już na pewno, wymagają integracji w aplikacje. Dlatego jeżeli to działa tak dobrze, jak piszą, że działa, a zamierzam pobawić się tym, zrobić jakieś demo, to jest fenomenalne narzędzie open source’owe.
Łukasz Kałużny: Ogólnie układanka z eBPF-ami jest przyszłością, tam gdzie będą te trace’y wystawiane.
Szymon Warda: Tak i faktycznie eBPF-y umieją to zrobić, one mają miejsce wpięcia się i mają miejsce, żeby to faktycznie było nie tak bardzo kosztowne.
Łukasz Kałużny: Pytanie, dla mnie całość jest z zabawy, żeby dostawcy cloudowi wyrzucali te informacje w postaci OpenTelemetry. To byłoby idealne, żeby można było wypchnąć to gdzieś do siebie. Dobra, idziemy dalej. Taka ciekawostka, bo Postman w tym roku dał ciała z wyłączeniem swoich trybów off-linowych, w pewnych częściach bez logowania nie zadziałał, więc jako alternatywa pojawiła się Insomnia. To jest coś, już dawno temu z tego korzystałem z tego open source’u raczej teraz to już jest produkt, jak ze wszystkimi takimi rzeczami, ale bardzo spoko i fajnie, że się pojawiło jako całość tej układanki, która jest.
Łukasz Kałużny: Jest niezła. Faktycznie.
Łukasz Kałużny: Dobra. Co u Ciebie jeszcze?
Szymon Warda: Jeszcze wydaje mi się, że Thought Works też McKinsey’a czyta, bo wrzucili toola DX DevEx 360, więc w ogóle dwa “x” i jeszcze 360 na koniec dorzucili, więc spoko. O co w tym chodzi? Jak sami w opisie podają, to jest tool do zbierania feedbacku odnośnie platformy, który mierzy takie rzeczy jak metryki DORA i SPACE. Dokładnie te, które omówiliśmy 3, 4 odcinki temu odnośnie McKinseya. Po raz pierwszy w trialu. Tool wygląda ciekawie. Faktycznie do zbierania feedbacku, oni chwalą się tym, że mają największy zwrot odpowiedzi, największy procent. Ok, mój jedyny problem z tym - tool kosztuje 26 dolarów za developera miesięcznie.
Łukasz Kałużny: Nie opłaca się.
Szymon Warda: Jeżeli ma się ogromną skalę to może tak, ale…
Łukasz Kałużny: No nie.
Szymon Warda: Nie, za dużo, powiedzmy sobie tak.
Łukasz Kałużny: To jest formularz i prosta tabela w Google Sheet’cie czy Excelu.
Szymon Warda: Albo Microsoft Formsach. Tak, dokładnie tak. Ciekawe podejście. Fajnie, że coś się pojawiło. Wydaje mi się, że tutaj też zahaczyli o ten cały obszar. Za dużo.
Łukasz Kałużny: Ciekawe, founderzy DORA i SPACE to założyli. To jest też, że to są właśnie te ankiety założone. Nie będę… Ale ciekawe, że się pojawiło. Dobra. I dwie rzeczy znowu z General AI-a. Pierwsze, to pojawiła się właśnie self-hosted model w postaci Llamy 2 od Facebooka albo przepraszam, Mety. Open source, oczywiście tam jest jeszcze problem z definicją open source’u, niektórzy nazywają to semi-open, ale już zostawmy te kwestie licencyjne. Więc tak, warto to zobaczyć. W szczególności, że też pojawił się na cloudach jako gotowy w różnych usługach cloudowych, jako gotowy do skorzystania, zdiplayowania po prostu jako semi-delf-hosted. To jest jedna rzecz. Druga, która jest ciekawa, to jest w kontekście, bo tu też się przejawia w tym Copilot, którego żaden z nas nie wziął do tooli, GitHub Copilot, ale pojawiło się jako open source LLM-y do kodowania, żeby wykorzystać do kodowania.
Szymon Warda: O których też mówiliśmy parę odcinków temu, swoją drogą.
Łukasz Kałużny: Tak, wspominaliśmy i to jest ciekawa rzecz, którą można zrobić, w szczególności w dużej części, jeżeli chcemy zrobić fine tuning pod siebie pewnych rzeczy. Jeżeli mamy schematy baz danych, innych rzeczy, można wykombinować. Tam mamy takie modele jak StarCoder np., więc tak, jest to ciekawy trend i może się okazać, że w niektórych miejscach gdzieś wyprze Copilota. W szczególności tam, gdzie są różnego rodzaju obawy. Compliance zrobił swoją wersję świata i są obawy na temat copyrightów i innych rzeczy.
Szymon Warda: I kwestie tego, czy możemy te modele doszkolić, też bardzo ważne, bo nie wszystkie modele, które są zamknięte, można doszkolić na naszym…
Łukasz Kałużny: Dlatego mówię właśnie, czy można doszkolić, czy zrobić fine tuning, bo to są różne podejścia do tego. Dobra, to przechodzimy do platform.
Szymon Warda: Tak, to ja zacznę, w adopcie. Zabezpieczenie dostępu do danych na poziomie…. A możliwe,w takim razie źle sobie zanotowałem. Tak, masz rację, była w assess w 2023, teraz faktycznie jest w trialu. To jest, wydaje mi się też o tym wspominaliśmy jakiś czas temu, bo jeżeli mówimy o dużych zbiorach danych, zarządzaniem danych i uprawnień do danych na poziomie organizacji, to będziemy potrzebowali ABAC-a, czyli Attribute-based access control, czyli dostępy na poziomie bardziej dokładnym. Fajnie, że ten trend się pojawił. Czekam trochę na to jak to będzie wdrożone dokładniej i w trochę łatwiejszy sposób, bo tam jest akurat integracja dużo mocniejsza ze Snowflake’iem.
Łukasz Kałużny: Ale jest parę tych… Tylko wiesz, też masz natywne cloudowe, u dostawców cloudowych masz, AWS ma coś swojego, Microsoft ma coś swojego, więc to też jest takie… Żyją w swoich ekosystemach i jak widać te oznaczają takie technologie, jak sobie popatrzysz, to one tutaj ładnie mówią że modern data stack, ale de facto lecą takie podziały gdzieś tam w okół Snowflake’a i technologii data warehouse’owych.
Szymon Warda: To co mówisz, idealnie przebija się do tego, co miałem w drugim assessie, Azure Container Appsy, które są w assessie w ogóle chwalone dość mocno w tym wpisie, z jednym ‘ale’ - czemu mówią, żeby to sprawdzić w assessie a nie wyżej? Ponieważ provider teraz terraformowy laguje trochę i jest późniejszy niż zestaw feature setów.
Łukasz Kałużny: Mam dwie odpowiedzi. Pierwsza, bardzo low levelowa, powinni dowiedzieć się, że jest provider o nazwie AzAPI. To jest pierwsza rzecz. Druga rzecz, czy oni zaczęli pracować w ciągu ostatnich 3 lat w Terraformie? Przecież Terraform zawsze jest do tyłu z tym co provider cloudowy udostępnia.
Szymon Warda: Ale zobacz po nawet ich toolach, itd., platformach, językach siedzą bardzo, bardzo, bardzo mocno w Terraformie. Więc wydaje mi się, że dla nich to jest opcja taka, że jeżeli Terraform działa tam słabo, no to będzie dla nas to minus. OK, no bo to jest zaopiniowane, Thought Works popatrzy do swojej strony, więc rozumiem, mają do tego prawo w pełni. OK, ale się z tym nie zgadzam po prostu, powiem sobie tak. A co tam masz?
Łukasz Kałużny: Dobra, po pierwsze WTF, czyli cloud eventy. Cloud event też zrobione przez Microsoft, oddane do CNCF-u, czyli forma standaryzacji eventów cloudowych. I WTF, nie wiem czy jest sens, bo teraz jest tutaj w trialu, 4 lata temu była w assessie. Całość jest taka, że gdzieś powoli te cloud eventy się u cloudowych providerów pojawiają. Tutaj dużo w tym projekcie zmian de facto gdzieś nie ma. W tym roku doszły - obsługa protobufów. Po prostu sobie to żyje. I jak popatrzymy jest to good enough rozwiązanie, event grid Microsoftowy w tym działa, Google’owe eventy w tym działają. Więc właśnie mam taki WTF - co tutaj to robi?
Szymon Warda: Wygrzebane, wykopane, jest po prostu. Mam wrażenie, że w ogóle ten obszar platformowy i języków tak kuleje dużo bardziej. O ile wcześniejsze 2, czyli wcześniejsze dwa były bardzo fajne, to te dwa tak trochę gorzej.
Łukasz Kałużny: Więc to był mój WTF-ik. Kolejne dwie rzeczy, które się pojawiły, tu mnie akurat nie dziwią, czyli Azure OpenAI Service. Tutaj nie dziwię się, że trafili na to na projektach. A całość de facto, tam minusa dali za ograniczoną dostępność, tak, chociaż teraz to się zmieniło ostatnio troszeczkę, to całość, jakby to dobrze określić, musiała się tu pojawić. Było pytanie tylko, w którym miejscu się pojawi. Więc myślałem bardziej, że pojawi się gdzieś przy toolach. To tak zupełnie szczerze.
Szymon Warda: Co mnie zdziwiło, jedna rzecz, bo to jest w assessie, nie w trialu.
Łukasz Kałużny: Ale klienci chcą z tym na produkcję.
Szymon Warda: Dlatego właśnie… Według mnie powinno być w trialu w tym momencie tak naprawdę.
Łukasz Kałużny: Tak, ale klienci chcą z tym na produkcję. Wiemy. I kolejna rzecz, akurat że w assessie to dobrze, to Pinecone, czyli baza wektorowa dla właśnie long term memory dla AI-a. Ciekawe, nie open source tylko komercyjne rozwiązanie hostowane. I to jest właśnie fully-managed, więc zawsze jak to problem z takimi rozwiązaniami, baza danych czy cokolwiek assess serwis gdzieś na zewnątrz. Zobaczymy co się będzie z tym działo. Ale jest to taki trend narzędzi, które potrzebujemy. Jestem ciekaw kiedy Microsoft z Oraclem dorobią wektory w tych swoich silnikach SQL-owych. Postgres już ma swojego vector searcha.
Szymon Warda: Postgres ma wszystko tam generalnie.
Łukasz Kałużny: Więc lecimy. Dobra. To co, języki?
Szymon Warda: Języki. Dla mnie mało tam się dzieje. Dwie rzeczy, które wygrzebałem. Jeden, to jest pojawienie się OpenTelemetry, który jest w trialu, dalej jest w trialu, od 2020 jest w tym trialu.
Łukasz Kałużny: Tylko, że wiesz co? Tylko zobacz, że w tym roku to uzyskało realnego GA.
Szymon Warda: Tak, bo wyszła wersja 1.0. Ale trochę nie rozumiem czemu jest w trialu. Według mnie powinno być dużo dalej, bo nie ma alternatywnego, dobrego opisu jak zbierać metryki standardów. To już stało się już de facto standardem rok temu tak naprawdę. Jeżeli chodzi o implementację, jeżeli chodzi o podejście, więc ok. Argumentują to, że to jest w trialu, bo oni jeszcze badają temat, że się przydaje, że jest fajnie. Sorry, to powinno być w adopcie tak naprawdę dla mnie. Nie rozumiem tego wstrzymania się.
Łukasz Kałużny: Wiesz co, tylko tooling jeszcze dorasta wokół, więc to też może być gdzieś całość układanki.
Szymon Warda: Zgadza się, ale to w tym momencie jeżeli budujemy aplikację, bo to jest element typowo do budowania aplikacji, to powinniśmy już zacząć używać OpenTelemetry, bo tooling będzie dorastał. Ta aplikacja wbrew temu, co pokazują prezentacje i dema, z reguły nie powstaje w ciągu jednego dnia.
Łukasz Kałużny: No dobra, to teraz lećmy z punktem wspólnym ze względu na nasze całe hate-love relationship z Microsoftem, czyli .NET minimal API.
Szymon Warda: No i właśnie, mam do tego ciekawy komentarz. A jak Ty na to patrzysz? Bo patrzymy z innej perspektywy, bo Ty bardziej tło administracyjne, a ja bardziej developerskie.
Łukasz Kałużny: Wiesz co, ja patrzę na całość. Dobrze, że pojawiła się, nawet oni to robią, że jest to nowe podejście, które się gdzieś pojawiło w świecie Javy, takie jak tam ten Micronaut, Quarkus. Patrząc się na ten kod jest naprawdę spoko podejście. Pytanie jest jak ludzie, którzy piszą korzystając z Web API, czyli de facto z tego okrojonego MVC, będą się czuli kiedy ten cały overkill boilerplate jest wyrzucony.
Szymon Warda: A ja mam do tego zupełnie odwrotny komentarz.
Łukasz Kałużny: Jaki?
Szymon Warda: Nawet na dokumentacji API jest napisane, że jest dla zaawansowanych developerów. To jest ważna uwaga. I mi to całe podejście bardzo mocno przypomina., Nie wiem czy pamiętasz, pewnie pamiętasz, to dawno, dawno temu był taki pomysł jak API Apsy. Dzięki temu powstały generalnie w…API. Czyli super fajny pomysł na - okrójmy, wytnijmy pewne rzeczy, żeby generalnie pokryć pewien bardzo wąski kontekst. I to Minimal API wygląda fajnie, ale mnie zastanawia jedna rzecz, bo to jest taki dla właśnie małych apek, w którym momencie, wiesz, która apka będzie mała a która będzie duża.
Łukasz Kałużny: To jest podejście jak mówimy, że mikro serwis jest dobry dla wszystkiego, Szymon i zaczynamy w ten sposób klepać. Wiesz co, kurde Oskar, będziesz musiał nam tantiemy płacić. Fajnie jest tak, jak tam Oskar promuje u siebie na przykład podejścia z CQRS-em, czyli jak masz sobie funkcjonalność z CQRS-em i właśnie te vertical slice’y. I to gdzieś się spina np. w tych przykładach.
Szymon Warda: Ja się zgodzę, że się spina, tylko problem jest taki, że [niesłyszalne 00:38:49] Minimal API dla mnie osobiście wygląda świetnie na demo, bo świetnie na prezentacji, świetnie na małych serwisach, ale jak te serwisy trochę bardziej urosną, to nagle tracimy to uporządkowanie, które jest.
Łukasz Kałużny: Właśnie chciałem powiedzieć, że brakuje Ci… Dlatego dla zaawansowanych, bo ten opinionated structure musisz wypracować sam.
Szymon Warda: Właśnie, a bez tej opinionated structure’y, jak się wpuści tych ludzi… Będzie jeden wielki pierdolnik. To jest sposób na to, żeby mieć cały serwis w jednym pliku. Dosłownie.
Łukasz Kałużny: Tak, ale ja się śmieję, zrobisz .NET new: boże, tam jest tylko program CS? Co ja z tym mam zrobić?
Szymon Warda: Więc rozumiem, że się pojawiło.
Łukasz Kałużny: Wiesz co, jestem ciekaw, ja to akurat kupuję, tylko bardziej jestem ciekaw tych zmian, które idą w ósemce. Trzeba kogoś zaprosić w ogóle wreszcie od .NET-a. Może macie przykłady osób, które moglibyśmy zaprosić i pogadać o .NET-cie. Dobra, to Twoje skończone. Zostały mi jeszcze dwie rzeczy. I tu mnie nie dziwi, że są w tym. Czyli po pierwsze, Langchain, czyli biblioteka pozwalająca pracować właśnie na LLM-ach, żeby budować sobie z większych kawałków odpowiedzi. I to rozwiązanie jest teraz w assessie, czyli w dobrym miejscu jak wszystkie te rzeczy wokół. Większość chciałaby już triala i wspomaga to budowę rozwiązań, no ale jest to początek drogi, więc fajnie, że to się to znalazło jako właśnie framework do wykorzystania w aplikacjach. Tam po drodze też, co ciekawe, przypominają Microsoftowy Semantic Kernel, który też się swoją drogą pojawia w assessie.
Szymon Warda: W ogóle te toole do LLM-ów z reguły siedzą właśnie w assessach i nie… To jest plus tego Radaru, nie polecieli pełnym hypem i nie wrzucili wszystkiego generalnie na adopt, tylko podchodzą dość w miarę rozsądnie.
Łukasz Kałużny: Ani w trialach w niektórych tych. I ostatnią rzeczą, która się z tym pojawia to GPT Cash, to też jest ciekawe. Zdziwiłem się, że to się pojawiło, ale właśnie Cash, żeby wspomóc sobie oszczędność na odpowiedziach i innych rzeczach. Bardziej już specyficzne do całej układanki.
Szymon Warda: Czyli teraz nie będziemy wiedzieli czy model ma halucynacje, czy po prostu ma zły wpis w Cashu.
Łukasz Kałużny: Tak, dokładnie i integruje się z Langchainem jak i Llamą Index, która gdzieś w tym jest, ale już jej nie wygrzebywałem.
Szymon Warda: Tak, dość sporo mimo wszystko rzeczy właśnie odnośnie LLM-ów jest. Ja wiedziałem, że Ty je będzie wygrzebywał, więc oddałem je.
Łukasz Kałużny: Dobra.
Szymon Warda: Podsumowanie tego Radaru.
Łukasz Kałużny: Zrobimy następny, jeżeli utrzymają taki poziom.
Szymon Warda: Dużo, bardzo dużo rzeczy nowych jest, bardzo dużo rzeczy w trialu się pojawiło. Jak przeglądałem historię gdzieś, gdzie to się pojawiło, to bardzo dużo rzeczy pojawiło się nowe.
Łukasz Kałużny: Ale były też rzeczy znikająco-pojawiające się, więc…
Szymon Warda: Były też zombi, były takie potwory, które wróciły niejako. Może nie potwory a rzeczy, które wróciły. Ale dużo lepszy niż ten okres takiego, suchości, że tak powiem, który mieli przez jakiś czas. I tak wygląda na to, że do kolejnego zdecydowanie siądziemy i rzucimy okiem, co tam się dzieje.
Łukasz Kałużny: Aczkolwiek pierwsze odczucie, które miałem pierwsze meh, to było takie pierwsze, ale tak po zagłębieniu się jest już spoko.
Szymon Warda: Dobra, no to co, kończymy.
Łukasz Kałużny: Trzymajcie się, na razie.
Szymon Warda: Na razie, hej.