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 gdzieś pod spodem, prawdopodobnie pod spodem lub na Patoarchitekci.io albo w opisie. Dobra Szymonie, startujemy. Jakie linki na dzisiaj?

Szymon Warda: Dzisiaj trochę dramatów się działo. Dzisiaj… Ostatni czas się trochę dramatów działo. Takie małe przypomnienie co się działo z XZ, mianowicie backdoorem, exploitem, jakkolwiek by to nazwać tak naprawdę. To co się działo? 2021, T75 tworzy kod na GitHubie, taki timeline sobie powiemy. Kwiecień 2022, wysyła propozycję patcha na listę mailingową. Potem jest Jigar Kumar zaczyna naciskać na Lasse Collina, żeby dodać nowego kontrybutora do XZ. 2023, 7 styczeń, T75 marge’uje pierwszego commita do XZ. Marzec, główny email kontaktowy dla XZ zmienia się na email. Czerwiec, Hans Jensen przygotowuje commita, który będzie podstawą do podatności tak naprawdę. 2024, zmienia się URL do strony projektu na stronę GitHubową. Wcześniej był utrzymywany przez serwer hostingowy chyba w Finlandii, jakoś tak. Potem wchodzą kolejne zmiany do backdoora. A 25 albo 24 marca Andres Freund publikuje swoje odkrycie, że podczas mikro benchmarków zauważył, że jest podatność. Podatność jest o tyle ważna, że biblioteka już weszła m.in. do Debiana i umożliwia otwarcie sesji zdalnej SSH. Czyli wystawienie się dupą do świata, jak to niektórzy mawiają tak naprawdę. Sytuacja jest poważna, nazwijmy to delikatnie.

Łukasz Kałużny: Ja widzę z tym 2 problemy, Szymon. Bo 1, to co powiedziałeś, ktoś pięknie skompromitował opensource.

Szymon Warda: Tak, ja w kontekście tego widziałem taki komentarz, który przewijał się z 10 lat temu, 15, jak opensource wchodził, że cytuję: open source jest bezpieczniejszy, bo więcej ludzi na niego patrzy. Ja powiem, kiedy ostatnio przeglądaliście kod waszych bibliotek? Kiedy wiecie kto to w ogóle utrzymuje? To jest tak absurdalna bzdura i nieudolne stwierdzenie, że to nie ma żadnego sensu. I to nam pokazuje absolutnie idealnie, bo to nie jest pierwsza sytuacja, kiedy mieliśmy takie właśnie ataki, bo to jest atak.

Łukasz Kałużny: Raczej ten jest piękny, rozłożony na tyle lat, bo jest, zobacz jak jest precyzyjnie zrobiony.

Szymon Warda: Tak, w ogóle i to pokazuje po prostu jaka jest dokładność tego typu i pokazuje, ile takich rzeczy jeszcze gdzieś siedzi, które nie zostało wykrytych.

Łukasz Kałużny: I wiesz co? I teraz dla mnie jest druga ciekawa rzecz. Zobacz ile projektów ciągnie po prostu tarballe bez sprawdzania, zamiast skompilować paczkę u siebie.

Szymon Warda: Ale nawet skompilowanie też nic by Ci nie dało.

Łukasz Kałużny: Nie, ja wiem, tylko zobacz, że w ogóle wiesz całość, chyba RedHaty tylko i Oracle Linuxy ze swoją opieszałością w używaniu były niepodatne.

Szymon Warda: W ogóle sytuacja jest trochę przerąbana generalnie, bo tak naprawdę takich mikro bibliotek jest od groma i one mają strasznie szeroki zakres użycia. XZ pokazało to, Log4j pokazało jak małe biblioteki, na które z reguły ludzie nie patrzą, jaką mają niesamowitą podatność właśnie do otwarcia systemów całkowicie na świat. Żeby nie być całkowitą marudą, bo marudzimy dużo odnośnie tego, że open source trochę nie może znaleźć swojego miejsca. Dla mnie to nie oznacza to, że powinniśmy wrócić do paczek utrzymywanych przez korporacje, bo to też nie jest wyjście. Ale ewidentnie, nie wiem czy pamiętasz, była też publikacja w zeszłym roku cała rządu amerykańskiego odnośnie właśnie podatności, określenia użycia i zrobienia czegoś z open sourcem, bo faktycznie biznes nie korzysta. Więc wydaje mi się, że to jest jedno z rozwiązań. Ale dramat, o którym też Ty będziesz mówił tak naprawdę, w ogóle dramaty wokoło finansowania open source’u. Z całym szacunkiem, ale hipsterzy dorośli po prostu, mają dzieci i rodziny, albo po prostu mają inne zajęcia. Są ludzie, którzy utrzymują niektóre projekty, na których opierają się miliardowe korporacje przez dziesiątki lat.

Łukasz Kałużny: Raczej świetny jest ten stary mem z xkcd, który jest też już przeróbką. Jest tak: Old Model Digital Infrastructure, jest po prostu taka cała wieża z różnych paczek i pod spodem: a project sam random person in Nebraska has been thanklessly maintaining since 2003 i tak to wygląda jak popatrzymy niekiedy na zależności.

Szymon Warda: Nabijamy się z Node’a, bo tam to bardzo widać, ale na Unixach, Linuksach nie jest wcale dużo inaczej. Ta idea małych tooli powoduje to, że po prostu jest tego dużo i to jest na tyle dużo, że będzie ciężko to sprawdzić. Fajnymi rzeczami są właśnie CNCF Linux Foundation, że to wchodzi w jakąś opiekę, nadawana jest temu jakaś struktura i to będzie konieczne.

Łukasz Kałużny: Tylko wiesz, też trzeba pamiętać, że oni korzystają z innego… Inaczej mówi się, że niby są audyty i inne rzeczy z całości, ale nadal tak będzie to występowało, bo oni nie piszą żadnych bibliotek pod spodem od zera, tylko biorą jakieś gotowe.

Szymon Warda: Zgadza się. Ja w ogóle patrzyłem na te zmiany w kodzie, to też trzeba ten kod znać, żeby to wyłapać. Nie oszukujmy się.

Łukasz Kałużny: Raczej focusacja, ja też dorzuciłem linka do Coldwinda, do jego blogu, bo zrobił bash stage o focusation explained i zrobił fajny taki przykład, który tłumaczy już, jak ktoś jest ciekawy jak bardzo została zrobiona fokusacja tego i zrobił całą taką analizę tego w jaki sposób było to zrobione. Więc to też jest ciekawą rzeczą tutaj w całości.

Szymon Warda: Ja mam taką nadzieję tylko, że ta cała gównoburza nie przeminie i będą z tego jakieś wnioski wyciągnięte. Bo tutaj jest gównoburza, to jest poważny temat i że nie przyklepiemy tego na zasadzie generalnie, że jest to problem kogoś innego.

Łukasz Kałużny: Dobra, lecimy dalej. Jak jesteśmy już przy gównoburzach, to OpenTofu zaliczyło kolejną dramę. Dostali pozew od prawników HashiCorpu i cała zabawa polega na tym, że jak sobie tam popatrzymy w skrócie patrząc się, to będzie teraz tak zwane kłamstwo dla dzieci, czyli pominiemy, ale o co chodzi? Poszły takie 3 rzeczy. Fajnie to napisał koleś, który był w Microsofcie odpowiedzialny za open source policy w czasach walk Sun - Microsoft.

Szymon Warda: Dawno, dawno temu, za górami, za lasami…

Łukasz Kałużny: Dawno temu, ale to były… Inaczej, to nie jest to, co było Oracle vs. Google. Wtedy trochę inaczej wyglądały, były większe problemy. I patrząc się, powiedział 3 grzechy główne OpenTofu: skopiowany kod bezpośrednio, czytanie kodu, żeby się nim…

Szymon Warda: Inspirować.

Łukasz Kałużny: Inspirować, dokładnie i kopiowanie funkcjonalności, żeby mieć jeden do jednego. I zaczyna się zabawa, że pytanie czy firmy, które się podpisały, którym nie zależy na zarabianiu kasy na terraformie… To jest ważne, bo fork OpenTofu został zainicjowany przez ludzi, którzy byli w dupie ze swoimi biznesami przez ruch HashiCorpo.

Szymon Warda: Czyli wykorzystywali terraforma do budowania swoich platform i świadczenia usług SaaS-owych.

Łukasz Kałużny: Raczej świadczenia usługi SaaS-owej, żeby robić coś z terraformem i zastąpić funkcjonalności płatnych produktów, żeby zabrać tą kasę od HashiCorpu za ich pracę. I teraz jest, patrząc się na te wszystkie rzeczy, które się tam pojawiają, to jestem ciekaw czy te firmy, które popierały, które nie były komercyjne i nie zależało im na tym, które się przypadkiem nie zaczną tutaj odwracać od całości tej układanki.

Szymon Warda: Kwestie prawne na pewno ich mocno wystraszą. Ale tak z drugiej strony, to jakie mają inne wyjścia? Powrót do terraforma?

Łukasz Kałużny: Nie mają. Mogą zapłacić za licencję.

Szymon Warda: Ale zdaję sobie sprawę, że to są często jakieś tam mniejsze firmy albo często jakieś startupy, gdzie to im tak mocno wgryzie się w koszty, że ich biznes stanie się trochę mniej opłacalny tak naprawdę. Znaczy wiesz, to też może być taka opcja, że pokazali swoją jakąś tam możliwości, narobili trochę szumu i w tym momencie będą mieli lepszą pozycję negocjacyjną z HashiCorpem. Tak też się może skończyć.

Łukasz Kałużny: Więc zobaczymy. Dla mnie OpenTofu będzie czymś, tak jak powiedziałeś, nie ma pomysłu na open source i OpenTofu zajmują się dzieci wylane z wodą z wanny po prostu, ktoś im sprzątnął piaskownicę sprzed nosa.

Szymon Warda: Tak, ale to co powiedzieliśmy, nie mają do końca innego wyjścia, jak to zaadresować. Więc ciekawe.

Łukasz Kałużny: Zobaczymy. Zobaczymy, jak się rozwinie. Pewnie jak odcinek będzie szedł online, to będą kolejne etapy tej dramy, więc zobaczymy. Dobra.

Szymon Warda: Ja mam taki artykuł, który nie jest może jakoś porywający, ale jest tam jedno zdanie. Może wychodzi moja wewnętrzna maruda, może gorszy humor, może alergia, nie wiem, ale tam jest takie zdanie, jak jest postrzegana kreatywność przez developerów. Jest takie piękne zdanie: clever reuse and recombination of existing code are the primary attributes of creativity. Czyli tłumacząc na polski, że sprytne reużycie różnych kawałków kodu, jest to postrzegane jako kreatywność. Mój problem jest teraz, jak ja mam z tym zdaniem, to jest coś, co się nazywa po angielsku ‘coupling’, czyli zależność oprogramowania. Jak sprytnie te kawałki kodu łączymy, to łączymy je na bazie czego? Na bazie danych. Jak wejdziemy na wikipediowy artykuł odnośnie couplingu, czyli zależności programowania, to na najniższym i najgorszym poziomie couplingu jest data coupling. Bo w tym momencie tworzymy zależności między modułami, które są nieoczywiste i nagle dostajemy właśnie taki kawałek spaghetti tak naprawdę, że są połączone totalnie losowo i nie wiemy jak to dalej wyglądać ma.

Łukasz Kałużny: Raczej dobrą rzeczą jest prawdziwy dobry copy paste z refaktorem kodu i zrobieniem czegoś, a nie sprytne łączenie, bo to jest…

Szymon Warda: Mój problem jest taki z tym, że właśnie ten element sprytny jest tutaj strasznie niebezpieczny tak naprawdę.

Łukasz Kałużny: Ale to słuchaj, to jest to, co też w sumie zawsze nabijamy się z Drya.

Szymon Warda: Jeden kod nie musi być na tyle elastyczny, żeby być wykorzystywany w 10 różnych przypadkach, w różnych sytuacjach, bo to pachnie jak biblioteka utilus, tylko nazwana odrobinkę inaczej, robiąca odrobinę co innego. Tak że tutaj takie moje odcinkowe marudzenie na to, że nie bądźmy aż tak bardzo kreatywni tak naprawdę, będzie w porządku. Jedna funkcja nie musi robić dziesięciu rzeczy. Dobrze, tyle, już nie marudzę więcej. Łukasz?

Łukasz Kałużny: Dobra. Kolejną rzeczą, która się pokazała, TeamCity, pojawiło się TeamCity Pipelines. I ciekawostka, jak patrzę na JetBrainsy, to tak umknął mi cały ekosystem poza IDE, który mają i on ciągle się rozwija. I tutaj przebudowali CI/CD, bo ich CI/CD…

Szymon Warda: Musieli przebudować, bo ono było świetne interfejsowo. Jak weszła epoka CI/CD jako kod, to było absurdalnie nie do utrzymania.

Łukasz Kałużny: No właśnie, więc tutaj odrobili pracę i też jest fajne wskazanie, że to jest for small, mid size dev teams. Do tego stopnia jest wskazanie, co jest prawdopodobnie dobrą rzeczą.

Szymon Warda: Jest świetne, bo faktycznie, TaemCity dla małych i średnich teamów nadaje się fenomenalnie. Dla takich naprawdę dużych zaczyna być już tam bałagan, ale tak, zgodziłbym się. Lata temu korzystałem, dużo nawet.

Łukasz Kałużny: Pamiętam.

Szymon Warda: Super, naprawdę super. Ten model, co prawda licencyjny dla agentów był trochę kulawy na dłuższą metę, ale jeżeli ktoś musi budować nową premier, to działało dużo lepiej niż cokolwiek innego.

Łukasz Kałużny: Raczej wtedy było, w sensie w stosie .Netowym to było dość przyjemne i popularne, tak jak wtedy pamiętam Team City, ale jest spoko, jak popatrzymy na UI-a, ładniej ten wygląda… Inaczej, tak jak zawsze przy tym, patrząc się, te Developer Experience jak zawsze jest u nich na najwyższym poziomie, patrząc się na konfigurację i inne rzeczy, jak zrobiłem sobie taki przegląd dokumentacji i tego co pokazują.

Szymon Warda: To jest trochę jak wejście w ekosystem Appla. Jak już korzystasz z innego produktu, to cała reszta się super integruje. Naprawdę działa świetnie.

Łukasz Kałużny: A, i dodając, to jest tylko online’owa usługa + self-hosted agent is coming soon.

Szymon Warda: To też ciekawe. Rozumiem czemu w tym kierunku idą. Wydaje im się, że ich potęga była w tym kierunku, żeby to jednak było hostowane na onPremie, ale ok.

Łukasz Kałużny: Spoko, wiesz, to jest patrząc się zobacz small and medium, więc to też idealnie oddaje potrzebę.

Szymon Warda: Dobra.

Łukasz Kałużny: To co Ty masz dalej?

Szymon Warda: Chwaląc rzeczy, mnie zawsze rzeczy w kontekście FinOpsa cieszą. I wyszedł nowy Cube Cost 2.0 i trochę tam rzeczy doszło. Chwalą się najbardziej kwestią dodania monitorowania kosztów chmurowych w temacie sieci, całego networkingu. OK, bo to faktycznie było ciężkie do monitorowania, ale doszło też kilka innych rzeczy. Mnie może trochę inne cieszą niż sam networking. Akcje, czyli możliwość reagowania i działania, odpalania różnych akcji, jak nazwa wskazuje, na rzeczy związane z kosztami. I to jest fajne. Pojawił się też ML, ale nie AI, więc oceniam naprawdę. Forecasting, czyli przewidywanie jak będą wyglądały koszty na bazie historii tak naprawdę. Przydatne, bardzo.

Łukasz Kałużny: I druga rzecz, która poszła za forecastingiem, to anomaly detection na tym forecastingu.

Szymon Warda: To był drugi właśnie element, który mnie chyba najbardziej ucieszył, czyli wykrywanie… Bo budowanie alertów na bazie, że coś przekroczy jakąś wartość, nie sprawdza się w żadnej skali, jest nieutrzymywalny. Powiem tylko, mamy PR-y, żeby podbić tą wartość. A wykrywanie anomalii to jest faktycznie realna wartość. Więc to jest ten feature, który mnie najbardziej ucieszył. Tak więc widzę, że też wyłapałeś. Jeszcze chwalą się optymalizacjami wydajnościowymi, że nawet 100 razy przy dużej skali. To mnie martwi, jak 1.0 działało, ale ok. Ogólnie rzecz biorąc fajny temat, dobrze ta usługa wygląda i jeżeli ktoś potrzebuje, to do zerknięcia, jak najbardziej. Co tam masz Łukaszu jeszcze?

Łukasz Kałużny: Dobra, kolejną rzeczą stąd, takie ciekawe zdanie patrząc się, które powtarzamy też na co dzień klientom w pracy na temat governance i posiadania, słuchaj, własnych, tak jak w Protopii pomagamy klientom przy governance i platformizacji usług. To jedna rzecz, która jest fajnie powiedziana, ja zawsze podkreślam, że dużą część kompetencji merytorycznych i też w ogóle powiedzenia sobie strategii, jak chcemy to poukładać, muszą być zbudowane u Ciebie w firmie, bo zewnętrzna firma dostarczy Ci wszystko. Co z tego, jeżeli taka część governance’owa, zarządcza powinna siedzieć u Ciebie i powinieneś mieć jej całkowitą świadomość.

Szymon Warda: Ewentualnie firma powinna Ci to dostarczyć, a Ty przejmujesz to, żeby nie wybrzmiało, że Ty musisz sam to zrobić.

Łukasz Kałużny: Raczej może z Tobą ułożyć to. Bo teraz tak, przeniesienie… Zobacz, że mieliśmy np. klienta, który miał dość specyficzną sytuację i wziął właśnie taki cały package i okazało się, że ten governance w ogóle mu nie pasuje. Jest 3 miesiące po rozpoczęciu robienia governance’u, okazało się, że trzeba to wyrzucić do kosza i zacząć od nowa, bo przyszedł ktoś z “best practice”, to można w cudzysłowie określić.

Szymon Warda: Też to tyczy się odnośnie platformy, odnośnie bardzo wielu tematów, że czasami jednak, że pewne rzeczy trzeba odrobinę dostosować do tego, co firma ma u siebie tak naprawdę, albo co chce mieć.

Łukasz Kałużny: Tak, dostosować to jest jedno. Ale drugie, powinniśmy u siebie w firmie, jeżeli nie jesteś konsultantem, tylko korzystasz z konsultacji, to ten know how też powinieneś zacząć budować u siebie.

Szymon Warda: Zdecydowanie.

Łukasz Kałużny: Dobra. Co u Ciebie?

Szymon Warda: U mnie jeszcze, powiedziałem, że nie będę marudził, ale no dobra, nie powstrzymam się, StreamZ weszło do CNCF-u. Czym jest StreamZ? Operator do utrzymywania Kafki w Kubernetesie. To jest o tyle ciekawe, że sam Confluent jakoś się nie pali w tym obszarze, bardziej buduje własną chmurę i w tym kierunku idzie.

Łukasz Kałużny: Raczej mają działający operator, to jest lepsze określenie, ale jest to nastawione na klientów Enterprisowych z supportem.

Szymon Warda: Ale mnie przemyślenie naszło, mianowicie jestem ciekawy jak duży kac będzie po Kafce, bo będzie jakiś kac. Czy to będzie kac na poziomie taki jak np. jest po Enterprise Service Busach, no nie, że nagle okazało się, że to kompletnie się nie skaluje i trzeba z tego uciekać, itd.

Łukasz Kałużny: Wiesz co, ja określę to jako kacu finansowo-utrzymaniowym po Oraclach.

Szymon Warda: Właśnie, a to jest moja druga właśnie, czy będzie na zasadzie takiej, że to będzie kac na poziomie baz relacyjnych, że będzie moment, że stwierdzimy, że to w ogóle się nie nadaje, a potem wrócimy do tematu już wiedząc, jak z tego nie korzystać, co w sumie wiedzieliśmy od dawna, to wykorzystanie.

Łukasz Kałużny: Ale życie pokazało, że trzeba się sparzyć.

Szymon Warda: Tak, że jednak cudów nie ma. I czy po prostu Kafka będzie kolejnym narzędziem, tak jak jest, nie wiem, jakieś Pub/Suby, tak jak są bazy relacyjne, itd., że po prostu będziemy to jakoś utrzymywali. Mnie trochę martwi to nawet, jak rozmawiamy, patrzymy, co klienci w ogóle robią i nawet dostajemy komentarze gdzieniegdzie odnośnie naszego złego podejścia do Kafki, to jest to ile odpowiedzialności wchodzi na Kafkę i ile ekosystemu wokół niej jest budowane. I to się staje tym wąskim gardłem, jak by na to nie patrzeć.

Łukasz Kałużny: Wiesz co, najgorszą całością tej układanki, tak jak powiedziałeś, że ile razy spotykamy się, że ktoś chciałby, żeby Kafka była jedynym źródłem prawdy i bazą danych jednocześnie.

Szymon Warda: Patrzy się na Kafkę jak na coś, co ma nieskończoną wydajność, nieskończone możliwości i nie ma żadnych ograniczeń. To jest trochę przerażające tak naprawdę, dlatego ten kac.

Łukasz Kałużny: A z drugiej strony wiesz, chcemy mieć brokera, a nie piszemy np.kodu.

Szymon Warda: Tak, bo Kafka ma swoje zastosowania, naprawdę w pewnych obszarach jest świetna, jest fajna wydajnościowo, ale też wymaga trochę więcej utrzymania niż przeciętne systemy. No dobrze, tyle naszego kafkowego marudzenia, limit się wyczerpał. Co tam masz Łukaszu?

Łukasz Kałużny: Dobra, to teraz bardziej miły link na koniec. LangChain wrzucił fajne demo i w sumie rozwiązanie, czyli LangChain Extract. I o co teraz chodzi? Wykorzystywanie LLM-ów do tego, żeby z jednej strony wrzucić nieustrukturyzowane dane i wyrzucić do niej dane do jakichś już schematów JSON-owych, do których ekstraktujemy. Czyli fajny przykład, to co mówię o LLM-ach, że to jest bardzo dobry szwajcarski scyzoryk w pracy developera i w możliwościach budowy, w szczególności jak coś potrzebujemy zrobić na szybko. Szymon docenił demo przed tym, jak zerknął.

Szymon Warda: Tak dla kontekstu, demo jest odnośnie tego wyciągania składników, ich ilości i jednostek z przepisów. Domena mi bardzo bliska, bo sam kiedyś z tym kombinowałem i to jest trudne. Wiadomo, że diabeł tkwi w szczegółach, jak dobrze to robi, jak na słabych opisach, ale to nie jest trywialny proces tak naprawdę, tak.

Łukasz Kałużny: Tak więc całość przy dobrym wykorzystaniu promptów i dotuningowaniu do przypadku pokazuje, że mamy np. gotowca, który przewali Ci dane nieustrukturyzowane i załaduje je w jakiś rozsądny sposób, schematy, które potrzebujesz. I to jest jeden z case’ów integracyjnych LLM-ów, które nagle zaczynają mieć sens, jeżeli wiesz co robisz i spina się to kosztowo.

Szymon Warda: Ja bym też powiedział inaczej. Niekoniecznie przewali, że odpalimy i będzie działało i nie musimy się tym interesować. Ale przewali na tyle inicjalnie dobrze, że oszczędzi nam bardzo dużo pracy. Bo tu jest też duża wartość, nie, że coś, co zrobi z pudełka i będzie dobrze zrobione, po prostu będzie tego dużo. A potem możemy się na takich przypadkach krawędziowych zatrzymać, pochylić i spędzić na nich więcej czasu. To samo co nam zrobiło ORM-y i inne systemy.

Łukasz Kałużny: Chodzi o szybkość zrobienia tego.

Szymon Warda: Dobra, to ja mam jeszcze jeden. Jak już chwalimy, to chwalmy tak naprawdę. Bardzo ciekawy wpis od AWS-u. AWS chwali się jak przyspieszyli tworzenie zasobów całkowitych, wykonanie tworzenia zasobów w Cloud Formation. W dużym skrócie, podzielili tworzenie zasobu, zawsze podzielone było na dwie części, stworzenie zasobu i potem przygotowywanie, stabilizację jego, jak to ładnie jest nazywane. I teraz zrobili taką opcję, że wprowadzili optymistyczne [niesłyszalne 00:19:58] stabilizację, czyli zakładają, że zasób się stworzy i dopiero po stworzeniu tego zasobu od razu plan tworzenia kolejnych zasobów. A wcześniej było tak, że dopiero po stabilizacji zasobu tworzyli zasoby zależne. Wpis jest bardzo dobry, długi, fajnie pokazuje ile się dzieje tworząc zasoby i daje trochę takie wewnętrzne spojrzenie jak ta chmura działa. Naprawdę dobrze napisany, długi, z rysunkami, ilustracjami, dobrze zrobiony.

Łukasz Kałużny: Inaczej, pokazuje wytłumaczenie pracy na dependency graphie.

Szymon Warda: Tak, ale też generalnie co się dzieje, jak ten zasób otrzymujemy. Dla mnie wpis obowiązkowy, jeżeli ktoś będzie chciał korzystać z tego optimistic stabilization. I w ogóle pomysł jest bardzo dobry faktycznie, bo doskonale wiemy, że jak odpalamy większego terraforma, Bicepa, to czasami można naprawdę dużo kawy wypić, zjeść obiad i wrócić do czegoś, co jeszcze nie będzie skończone.

Łukasz Kałużny: I plan się wywalił po drodze, bo czegoś zabrakło.

Szymon Warda: Tak też może właśnie być. Więc wszystkie ruchy w tym kierunku, żeby IaC działał lepiej, zawsze są mile widziane, naprawdę.

Łukasz Kałużny: Dobra, to kończymy na dziś. Na razie.

Szymon Warda: Na razie.