Szymon Warda: 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 gdzieś tu klasycznie na dole.

Szymon Warda: No i ponieważ chcemy zrobić bit-shift liczby subskrybentów i odsłuchań tak mniej więcej o 3 w lewo, to oczywiście lajki, suby, polećcie i w ogóle. Wiadomo, o co chodzi. Co tam Łukaszu wygrzebałeś?

Łukasz Kałużny: Dobra. Zaległe jeszcze dramy OpenSource’owe bieżące i nie tylko. Zacznijmy od takiej ciekawości. Jest sobie taka libka, była dość popularna Javascriptowa Lodash i jak to ładnie na Twitterze zostało określone, ogłosiła bankructwo i wszystkie issue i PR-y zostały zamknięte.

Szymon Warda: To fajnie pokazuje jedno, że ludzie, którzy utrzymują te biblioteki po prostu już w pewien sposób myślą. Słowo bankructwo jest takim dojrzałym słowem i tak do tego podchodzą, że sorry, nie ma z tego kasy, bo to właśnie to pokazuje. Nie ma kasy więc ogłaszają bankructwo. I takich bibliotek będzie dużo, które będą będzie dużo bibliotek, które taki właśnie los czeka. I jestem ciekawy jak ten cały stos zależności node’a się w tej sytuacji utrzyma. Bo to nie będzie takie łatwe.

Łukasz Kałużny: Jestem ciekaw jak to w ogóle wszystko będzie wyglądało i składało się. No ale jest tak, że trochę ten freeride się trochę skończył.

Szymon Warda: Problem jest taki w ogóle z pomysłem na finansowanie. To samo co drama, o której chyba każdy słyszał to jest dramat z Unity co ogłosili kwestie licencyjne. I żeby dać kontekst - Unity od dwóch kwartałów jest na minusie i na poważnym minusie tak naprawdę, więc oni też szukają sposobu na finansowanie. Open source też szuka sposobów na finansowanie tylko open source częściej mówi, że sorry, po prostu nie, albo porzucamy, albo jest to w ogóle utrzymywane w sposób taki, że realnie nie jest utrzymywane. Tak że wydaje mi się, że czeka nas przemyślenie, jak w ogóle płacimy za coś, co jest darmowe i jak na to zbieramy kasę.

Łukasz Kałużny: Nie, w całości, wiesz, z tym Lodashem też jest bankruptcy, to jest dobre określenie, zabawne, bo koleś po prostu zamknął wszystkie PR-y, issuesy, bo stwierdził, że ma tego dość i trzeba zrobić nową wersję. Ale to też pokazuje jak bardzo właśnie, tak jak mówisz, finansowanie i inne rzeczy sprawiają, że no fucking way czasami, żeby coś szło w tym kierunku co trzeba.

Szymon Warda: To pokazuje też pewne rzeczy, bo jeżeli koleś ma finansowanie, powiedzmy sobie, to w tym momencie robienie wersji, która byłaby jakoś zgodna, przejścia, ścieżki migracyjne, to są rzeczy, które są mniej sexy niż kodowanie po prostu. Więc jak ma na to finansowanie, to z reguły takie rzeczy się robi. Jak na to finansowania nie ma, to może powiedzieć: walę to, lecę z nową wersją, będzie nowe, będzie fajnie i nie muszę martwić się o całą zgodność wsteczną de facto. Dobrze, to jeszcze ja się wtrącę z fajną rzeczą.12 lat w przygotowaniu. Ruszyło niedawno. Mianowicie amerykański justice department wytoczył Google’owi sprawę o monopol, jeżeli chodzi o reklamę. I teraz co tu jest ważne? Po pierwsze, 12 lat w przygotowaniu, to jest absurdalnie długi czas. To są rzeczy, o których Google już dawno wiedział, więc czy teraz myślimy o tym właśnie: a czy Google będzie w chmurze czy nie będzie w chmurze. Google będzie w chmurze tak naprawdę i będzie utrzymywał i to będzie się rozwijało. I czemu Google tyle zainwestował? Ponieważ ich rynek, jeżeli chodzi o właśnie reklamy, powoli, powoli się wykrusza tak naprawdę i chmura staje się bezpiecznym obszarem, gdzie giganci mogą wejść, no bo tam płaci kto inny de facto.

Łukasz Kałużny: Tylko co z tymi reklamami? Ja też bym popatrzył na to w ten sposób, że teraz to nadal jest core biznesu zdrowy. Przecież u nich chmura jakoś niedawno dopiero realnie zyski wykazała.

Szymon Warda: Zgodzę się jak najbardziej. Więc Google w ogóle trochę, zgódźmy się na tym, że właściwie przespali to. Ale oni wiedzą, że zaczyna im się palić pod tyłkiem tak naprawdę i muszą zacząć dywersyfikować to w dużo inny sposób. Też inny case jest taki - zobaczmy jak jest ogromny lag między tym, co się dzieje, a tym, kiedy to właściwie się dzieje, kiedy powinno. Więc teraz mówimy, że powinniśmy zacząć patrzeć i będą jakieś regulacje w kontekście np. bezpieczeństwa, open source’u, w kontekście AI i tak dalej. 12 lat zajęło reklamy, więc teraz to nadgonimy w kontekście innych regulacji.

Łukasz Kałużny: Tylko zobacz, że Unia Europejska się aż tak nie bawi w takie rzeczy z szybkością. Zaś ta głupia standaryzacja USB-C czy tego, że… Czyli iPhone dostał… Unia Europejska zmusiła Apple’a wreszcie do włożenia USB-C do telefonu.

Szymon Warda: Ale to też widzę już zajęło im chyba z 6 lat.

Łukasz Kałużny: Wiesz co, 6, ale to nie 12 zauważ. I nie było… I to odbyło się bez procesu.

Szymon Warda: Tak, Unia zrobiła to dekretem tak naprawdę, więc to jest plus wielki.

Łukasz Kałużny: Zobacz, że masz ten AI Act, jest jaki jest, ale się pojawił. Zobacz, że bez procesu Microsoft zrobił teraz licencję. Możesz kupić licencję na opisach bez Teamsów. To jest w ogóle nowość. Od pierwszego października Teamsy wyleciały z subskrypcji M365. I w przypadku tych najniższych, to jest ciekawostka, bo wczoraj to dojrzałem, wcześniej tego nie widziałem, suma Office 365 + Teamsy wychodzi tyle co obecna licencja.

Szymon Warda: Totalnie ominąłem to. Nieźle.

Łukasz Kałużny: Zrobili to po prostu, bo ktoś się do nich przywalał, chyba Slack czy… Slack chyba się przywalał o to w Uni Europejskiej, że wykorzystuje swoje monopolistyczne podejście.

Szymon Warda: MS ma doświadczenie w tym, żeby nie podskakiwać za bardzo i generalnie nie chcą żeby ich rozbito. Cały proces był ciekawy, bo jestem ciekawy jak się zmieni podejście do dużych firm technologicznych w kontekście właśnie procesowania ich i jakie będzie podejście sądownictwa. Bo to, pamiętajmy, że Google ma kilka procesów, tak samo Facebook ma kilka, jest dużo, dużo firm, dużo polityków chce się temu przyjrzeć de facto. Więc to będzie ciekawe, co się będzie dalej działo, z mojego punktu widzenia tak naprawdę.

Łukasz Kałużny: Tak ten proces jest ciekawy. Jestem w ogóle ciekaw skutków tego.

Szymon Warda: Tak, bo skutki będą… Wyrok nie jest tak bardzo interesujący, jak też to, co się będzie działo dookoła tak naprawdę.

Szymon Warda: Dobra, to się jeszcze wtrącę z jedną rzeczą, dużą rzeczą. I to miało być na później, ale zebrało się parę fajnych rzeczy. Container Appsy Azure’owe. I teraz lecąc po kolei, to co dorzucili ostatnio? Jobsy, czyli są joby w qlts-ie, jest mTLS, UDR-y, NAT Gateway, mniejsze wymagają. Dodatkowe porty na TCP, jest Dedicated plan, a nie tylko plan konsumpcyjny, integracja z Key Vaultem korzystająca z managed identity, gdzie, co jest super ważne i super fajne, to jest to, że w tym momencie każdy Container App, czyli każda aplikacja de facto, chodzi na swojej tożsamości i z nią się łączy do Key Vaulta. Czyli tak samo jak Kubectl Identity w Kubernetesie w AKS-ie.

Łukasz Kałużny: Wiesz co, słuchaj, to jest Workload Identity w AKS-ie tak naprawdę na koniec dnia. To wiesz, trzeba sobie to też nazwać, że to jest dokładnie ten sam mechanizm.

Szymon Warda: Tak, dalej jedziemy . Init Containery CORSa, Cross Origin Resource Sharing session affinity, to nie jest nic nowego patrząc na, porównując z AKS-em. Ale ja mam tutaj dwa pytania. Po pierwsze, czy MS przebije się z Container Appsami? Bo te Appsy są fajne, zbudowane na bazie Dapra, zbudowane na bazie KEDA-y, na bazie Kubernetesa.

Łukasz Kałużny: App jest tylko dodatkiem. To jest zbudowane na bazie AKS-a, bo to trzeba sobie tak powiedzieć, to jest zarządzany AKS.

Szymon Warda: Więc pytanie pierwsze - czy się przebije?Pytanie jest drugie, które wydaje mi się ciekawsze - czy świat chce i potrzebuje takiego zarządzanego, uproszczonego Kubernetesa?

Łukasz Kałużny: Odpowiadając, czy się przebije, to jest to samo pytanie do Cloud Runa, ECS-ów na Fargate’cie i innych tego typu rzeczy. Robiłem jakiś czas temu u jednego klienta eksperyment właśnie z Container Appsami, czyli gościa, który ogarniał jako tako Azure’a, rozumiał Kubernetesa, nie było sensu stawiać dla aplikacji Kubernetesa, dedykowanego AKS-a. W sensie musiał być w oddzielnej strefie sieciowej i inne takie rzeczy. Kolejny cluster. No sorry, nie było sensu. A było tam trochę producerów, consumerów, czyli nie było to czyste API, żeby wykorzystać po prostu App Service’y. Nie było i część kodu już istniała. I słuchaj, zrobiłem eksperyment i kolesia wrzuciłem, żeby sam spróbował odpalić tą aplikację w Container Appsach. I tam w ciągu kilku dni zrobił to praktycznie poprawnie z dokumentacji i z tego co jest.

Szymon Warda: Ja się z tobą zgadzam tylko w trochę innym kontekście myślę. Bo czy Container Appsy mają sens? Mają straszny sens. Wchodzenie w Kubernetesa dla organizacji, która nie jest na to przygotowana i w ogóle wchodzenie w Kubernetesa zawsze nie ma sensu w bardzo wielu przypadkach. Ale moje teraz pytanie jest takie bardziej właśnie czy świat chce de facto, czy realnie developerzy, architekci będą wybierali właśnie Container Appsa, czy będziemy lecieli na prosto Kubernetes zawsze, bo tak jest, bo tak jest fajnie tak naprawdę? Czy w ogóle ten ruch jest potrzebny?

Łukasz Kałużny: Inaczej, jeżeli będzie to zespół: chcę się jak najmniej zajmować Infrą i nie ma problemów, pobawię się technologiami, to tam się takie rzeczy sprzedają.

Szymon Warda: Ja się boję ludzi., którzy mówią: a co będzie jeżeli? I jak to zrobić? I znajdzie się zawsze jakiś taki, który chce się pobawić albo mówi, że nie, musi być Kubernetes, bo co będzie, jeżeli za 3 lata będziemy potrzebowali coś wdrożyć albo co będzie jeżeli.

Łukasz Kałużny: Nie będziesz potrzebował.

Szymon Warda: I ja sobie z tego zdaję sprawę, bo nie oszukujmy się, jak będziesz to świat za 3 lata będzie zupełnie innym światem tak naprawdę. I ja Container Appsy bardzo, bardzo lubię i to co się dzieje wokół nich, świetna sprawa.

Łukasz Kałużny: Raczej osiągnęły już teraz tymi readsami, o których mówisz, przez wakacje, to co teraz na wrześniu wypuścili jako General Ability, jest już taka zupełnie pełna dla wszystkich statelessów, Jest już zupełnie pełna produkcyjność.

Szymon Warda: Nie brakuje niczego, co by było super istotne. Dokładnie tak.

Łukasz Kałużny: Może wiesz co, jakbym miał ponarzekać, czego mi brakuje, to logi są nadal trochę drogie, bo mamy tylko Log Analytics, więc przy większych aplikacjach to jest nie fajną rzeczą. I to jest taki element, który jest gdzieś dla mnie trochę problematyczny. Druga rzecz, tak jak mówisz o subnetach, to nadal ten każdy kontener tam ma, swoją aplikacją ma dedykowanego IP. Więc jeżeli pracujesz w organizacji, która ma problemy z adresacją, bo porobiła burdel, bo tak zazwyczaj jest, to jest to problematyczne do użycia w takich elementach. A tak poza tym to się składa.

Szymon Warda: To się składa bardzo. Ja się bardzo obawiam, że to będzie kolejny super fajny pomysł, bo pomysł mi się bardzo podoba, który do końca nie trafi w rynek, a szkoda, bo bardzo wiele problemów by rozwiązał.

Łukasz Kałużny: Wiesz co, ale trochę Ci powiem, że ten usage, który idzie w tym, inwestują w to, bo usage ogólnie na świecie nie jest taki mały. Korpo to na te Container Appsy, tam gdzie rzyga się już Kubernetesem a używa Azure’a, jest to bardzo miła odmiana. Bo można wreszcie dostać coś takiego jak App Service i nie martwić się infrastrukturą.

Szymon Warda: App Service z lepszą utylizacją i lepszym zagęszczeniem aplikacji, a przy okazji jeszcze takie, że Consumption Plany też są bardzo tam przyjemne. Ja nie będę ukrywał, że trzymam kciuki, bo rozwiązywanie kolejnych problemów z Kuberentesem, gdzie agencja ma trzy osoby i nie umie go kompletnie obsługiwać, fajnie byłoby sobie uprościć życie.

Łukasz Kałużny: Dobra, słuchajcie, podejdźmy teraz z moim linkiem. To jest taka rzecz, gdzieś przy przeglądzie wakacyjnych dram, w pierwszym odcinku sezonu pominąłem tego linka. Mianowicie RedHat pod skrzydłami IBM-a, bo tak to trzeba nazwać, dba o to żeby rozwalać open source jak należy. I wcześniej RedHat zabił CentOS-a, czyli swojego open source’owego forka, który był bardzo otwarty i był też takim poligonem, a teraz zamknął dostęp w ogóle do publicznych źródeł samego Red Hat Linux Enterprise Servera, którego z pewnych przyczyn Oracle i SUSE forkowały i sobie budowały z tego swoje distra. No i tak wyszło, że Oracle właśnie i SUSE i CQ odpaliły właśnie Open Enterprise Linux Association, żeby stworzyć otwarte Enterprise’owe distro Open ELA, czyli Open Enterprise, właśnie Open Enterprise Linux. I zobaczymy co z tego wyjdzie.

Łukasz Kałużny: Z ciekawych rzeczy, np. to się akurat pojawiło na Azure, pewnie u innych dostawców podobnie, SUSE, jak szukasz Enterprise’owego Linuksa, że tak powiem, z supportem i innymi rzeczami i nie chcesz Ubuntu tylko jakieś distro z RPM-ami, to na Azure pojawiły się komercyjne distra SUSE, że możesz wziąć je bez licencji zupełnie, korzystać za darmo i masz dostęp do poprawek, bezpieczeństwa i innych takich rzeczy, czego wcześniej nie było.

Łukasz Kałużny: Czyli możesz sobie po prostu odpalić. Jak potrzebujesz to dokupujesz support dopiero. Więc to takie dość ciekawe ruchy. Jestem ciekaw co będzie w ogóle z tym całym stackiem Red Hata przy tym zachowaniu IBM-a.

Szymon Warda: Jestem ciekawy jak wygląda całe finansowanie wokół tego, bo to są takie dziwnie nerwowe ruchy, bym powiedział.

Łukasz Kałużny: Finansowanie tej fundacji… Słuchaj, mają, nie oszukujmy się, mają dziurę, ponieważ oni, jak wychodził nowy RHL, to tamci brali, forkowali, robili rename’ing i tylko wypuszczali łatki. Musieli tylko łatki pisać. Więc to było. A teraz trzeba utrzymywać swoje distro. Więc poszła po prostu ściepa na ograniczenie kosztów.

Szymon Warda: Czyli dramat utrzymywania open source’u i kto ma za to płacić - ciąg dalszy, powiedzmy sobie tak.

Łukasz Kałużny: Tak, dokładnie, tylko tutaj podeszli do tego w lepszy sposób i gdzieś tam z plusem po tych ruchach RedHata, po tym jak na przykład ten CentOS został zabity. Dobra, to co jeszcze u Ciebie?

Szymon Warda: U mnie jeden, ponieważ mieliśmy ostatnio odcinek o tym, jak nie warto pewnych rzeczy uczyć się i że większość ludzi pewnych rzeczy nie potrzebuje, czyli schodzenie na bardzo duży detal.

Szymon Warda: To ja dzisiaj mięso. Fajna prezentacja o twórcy baz danych i o tym, jak będą wyglądały kolejne etapy baz danych i jak w ogóle do nich podchodzić. Ale powiedz mi, trochę jest sprzedażowa, ale jest mega mięso jeżeli chodzi o taką serię, którą też swego czasu Oren robił, Oren od Ravena. Mianowicie o tym jak w ogóle wygląda to z zapisu, od tego, że robimy file save’a, przez efsink, itd., jak to trafia na faktyczny talerz czy też na pamięć NVML-a. I fajnie, bo omawia mmapa, omawia całego Odirect, omawia efsinka, bo mamy problemy z efsinkiem i co się dzieje jak się nie uda. Omawia problemy cashowania w ogóle, buforowania i omawia cały problem, czyli co się dzieje jak na poziomie dysku, czyli mediów na które zapisujemy. Ten bit, ta jedynka nam się po prostu zdegraduje powoli do zera, bo takie rzeczy też się dzieją i jak to do tego w ogóle bazy podchodzą?

Szymon Warda: Strasznie długa prezentacja, bardzo mięsista, jakby ktoś faktycznie czuł się na potrzebie albo wewnętrznej potrzebie, żeby faktycznie zejść na taki detal, dobra godzina słuchania o tym jak to działa wewnętrznie.

Łukasz Kałużny: To ja dorzucę do tego linka linka do książki. Jest sobie pan Petrov, jeżeli dobrze wymawiam, nie widzę stąd dokładnie na półce, napisał taką książkę Database Internals.

Szymon Warda: Którą omawialiśmy na jednym z pierwszych w ogóle patoodcinków.

Łukasz Kałużny: I że warto, że warto do niej sięgnąć. I on tam pokazuje wszystko, czego wykorzystuje się w nowoczesnych bazach danych. Czyli też wspomina o storage, ale też wspomina o replikacji innych rzeczy. Czyli wszystkie algorytmiczne klocki potrzebne do zbudowania dobrze działającej bazy danych. I też zrobił ostatnio fajną prezentację na ten temat. Takie na zasadzie właśnie chyba 45 minut albo godzina i chyba też w ramach InfoQ. Właśnie, muszę potem zerknąć, ale zrobił takiego właśnie, można powiedzieć, że trochę streścił książkę w 45 minutach.

Szymon Warda: Dobre. Co masz jeszcze Łukaszu?

Łukasz Kałużny: Dobra. Następnie ulubiony Dage, nasz ulubiony kolega David Himmer Hanson i jego kolejny shit post w teorii, kontynuacja sagi Our Loud Exit. I wiesz co? I powiem Ci tak, pokazał tutaj troszeczkę jak wyglądały te spadki po tym jak cały HeiKom i ten biznes wokół BaseCampu i innych tych rzeczy, jak wygląda ich wyjście z AWS-a. I to co powiedzieli, że już są o milion do przodu. Czyli de facto, tak jak podsumował we wpisie, potrzebowali kilku miesięcy po zakupie Blah, potrzebowali kilku miesięcy, żeby inwestycja się zwróciła. I teraz z takich ciekawych rzeczy. Jeżeli to jest prawda, to zespół, który OPS-ował AWS-a, zajął się obserwowaniem Hardware’ów Data Center w kolokacji. Jeżeli tak jest, to te koszty operacyjne się nie zmieniły. Od tej strony.

Szymon Warda: Nie wierzę, żeby tyle samo ludzi ogarnęło chmury i tyle samo ludzi ogarnęło fizyczne maszyny.

Łukasz Kałużny: Wiesz co i to jest taka ciekawa rzecz. Jestem w stanie w to uwierzyć. O tak. Wiesz, patrząc się na pewnych rzeczach, jestem w stanie, przy tej ich skali jestem w stanie w to uwierzyć, że nabijali ten rachunek niektórymi tylko usługami.

Szymon Warda: Ale na pewno nabijali. Takie posty jest łatwo stworzyć, bo to jest księgowość. Zależy jak co policzymy, to nam wyjdzie wynik, który chcemy, żeby wyszedł tak naprawdę. To nigdy nie jest porównanie jabłek do jabłek i pomarańczy do pomarańczy, ponieważ będą inne mieli polityki disaster recovery, zachowania, możliwości, ryzyka, które mają na On-premie względem tego, co mieli na chmurze. Nie mówię, że któraś jest lepsza, któraś jest gorsza generalnie, ale to nie jest porównanie jabłek do jabłek.

Łukasz Kałużny: Wiesz co, zobaczyłem np. jak wygląda, bo mają też takie rozbicie z zeszłego roku jeszcze, jak sobie byli na AWS-ie, mają rozbicie tego, słuchaj, na usługi per miesiąc, ile kosztowały. I w ich przypadku np. najwięcej kasy wyciągały RDS-y, czyli któraś baza danych i OpenSearch Service, czyli de facto zarządzany Elastic.

Szymon Warda: Czyli dwie najdroższe praktycznie usługi.

Łukasz Kałużny: Tak EC2, które tam były i reszta takich zabawek. S3, to już było. Cała reszta mieściła się, czyli połowę kasy spalał Elastic, czyli OpenSearch i bazy danych.

Szymon Warda: To są usługi które Elastic będzie i jest drogi w utrzymaniu i od tego nie uciekniemy tak naprawdę. Więc tylko znowu RDS-y, wszystko fajnie, też bardzo droga usługa, którą się słabo też skaluje de facto, bo trzeba skalować w górę.

Łukasz Kałużny: Raczej jest to mowa relacyjna, baza danych.

Szymon Warda: Tak, dokładnie od tego jest skrót. Więc super, oni używali chmury jako takie IaC+. Typowy, nic więcej. Czy to jest sensowne podejście? Pewnie jest, ale jest też drogie generalnie. Czym bardziej pójdziemy w te rzeczy zarządzane, tym będzie lepiej.

Łukasz Kałużny: Jak sobie popatrzysz w ich modelu chmura jest fajna do wystartowania i powrót do datacenter jest spoko, a w przypadku Enterprise’ów jest to często dobre rozwiązanie i początkowe i docelowe, patrząc się w zupełnie inny profil. Zauważ, że to bezpośrednio wpływa na ich marże.

Szymon Warda: Tak, ale przede wszystkim u nich, oni wiedzą jaki mają biznes. Ten biznes jest dość wąski. Nie będą eksperymentowali z milionem innych usług i po prostu dla nich to opcja, że mamy to co mamy i potrzebujemy tego samego przez kolejne 5 lat, ma sens. Dla większości firm nie ma to sensu po prostu. OK, fajny wpis. Dla mnie trochę kreatywna księgowość.

Łukasz Kałużny: Co masz na koniec u siebie?

Szymon Warda: Na koniec mam ciekawy wpis i trochę też shaming nas programistów jako taki generalnie. Mianowicie było zrobione badanie odnośnie przerwań, interruptions, ładnie nazwanych po angielsku, badanie, które skupiało się na tym, które przeszkadzacze de facto nas bardziej wytrącają. Jak to wygląda jakby na czas powrotu? I badanie jest niezłe, bo jest przeprowadzone na całkiem niezłej grupie.

Szymon Warda: Ale co ono pokazuje? Ono pokazuje kilka rzeczy takich trochę, tu właśnie będzie ten shaming wewnętrzny, bo że przerwania popołudniowe są bardziej niszczące. Co rozumiemy przez niszczące? Mianowicie, że dłużej czasu zajmuje nam powrót do oryginalnego zadania. Czyli realnie, jak jesteśmy zmęczeni, to przerwania są gorsze. Można się tego spodziewać. I teraz rzecz najgorsza w tym wszystkim, tak wewnętrznie, to jest że samo przerwania, czyli jeżeli my coś robimy i przerywamy sobie, żeby zmienić taska wewnętrznego bez zewnętrznego sygnału, że tak powiem, są dużo bardziej destrukcyjne, mają dużo gorszy wpływ niż jak ktoś nam przeszkodzi pomimo faktu, że osoby, które brały udział w badaniu raportowały jako bardziej przeszkadzające. Czyli wchodzimy teraz w to, Pomodoro. I to faktycznie ja się z tym zgodzę, jakby już ktoś na to spjrzał.

Szymon Warda: Pomodoro i to, że robimy taski, a nie przełączamy się między wieloma zakładkami. I będę się upierał przy tym, że jednak kiedy monitor jest dobry, bo pomaga się skupić właśnie i nie generować samoprzerwań. Co dalej jeszcze było? Przerwania w innym projekcie są mniej niszczące niż w tym samym. To jest ciekawa sprawa. Czyli jeżeli ktoś się zagada odnośnie innego projektu, to jest to mniejsze przerwanie niż generalnie [niesłyszalne 00:22:21] tego samego projekjtu tylko innych klas, innego kontekstu.

Łukasz Kałużny: To jest ciekawe.

Szymon Warda: To jest ciekawe. Znaczy wydaje mi się, że to jest kwestia tej różnicy tak naprawdę, że nagle byłeś w podobnym kontekście, muszę do czegoś podobnego wrócić i trudniej jest to rozgraniczyć. Ale to jest moja interpretacja. I teraz kolejna rzecz, przerwania przy niektórych czynnościach, bo oni to podzielili na architekturę, debugowanie, kodowanie, pisanie testów, i tak dalej, że programowanie i testowanie są najbardziej wrażliwymi czynnościami, jakie mamy, jeżeli chodzi o przerwania. Architektura i takie bardziej rzeczy, które nie wymagają tak długiego kontekstu de facto zbudowania, dużo mniej są podatne i mają dużo mniej niszczycielskie przerwania. Też ciekawe. To akurat jest dość oczywiste generalnie, bo tu mamy, a nie mamy takiego kontekstu całej linii, klas i gdzie jesteśmy tak naprawdę. Ciekawe podejście, ciekawe badanie. Artykuł, który będziemy linkowali akurat, to jest streszczeniem tego badania, bo to jest badanie naukowe i ono jest trochę długawe. Ale jedna rzecz, bo to nie jest wszystko. Rozmawialiśmy z Łukaszem, że część rzeczy, które są ciekawe, jak artykuły, ale nie ma o nich co pogadać, tak wygląda nasze short and sweet, będziemy wrzucali do newslettera i tam będzie parę linków, które wygrzebaliśmy, dobrych artykułów o open telemetrii, o zmianach w funkcjach Azure i jeszcze kilka innych rzeczy. Dajemy linki, nie ma co dyskutować.

Łukasz Kałużny: Tak, więc szukajcie tego w newsletterze, gdzieś tam na stronie jest na samym dole zapis, żeby się do niego wbić i dostać też powiadomienia o nowych odcinkach. No dobra, to kończymy. Tyle Na razie.

Szymon Warda: Tyle. Hej!