Łukasz Kałużny: Cześć, słuchacie Patoarchitektów. Prowadzą Łukasz Kałużny.

Szymon Warda: I Szymon Warda. Wszystkie linki do tego odcinka oczywiście na Patoarchitekci.io, gdzieś tam w opisie. Namierzycie generalnie, dacie sobie radę. No i oczywiście ponawiamy call’a o to wysyłanie cioci, babci, koledze, koledze najlepiej, linków do patopodcastu, bo chcemy go trochę wyskalować, żeby więcej ludzi słuchało. O taki mamy cel roczny.

Łukasz Kałużny: I jeszcze jedno ogłoszenie parafialne. Słuchajcie, z Szymonem występujemy na Infosharze. Infoshare DEV, 24 października - Katowice, 26 - Gdynia, więc będzie można nas spotkać tu i tam. Ja jestem w Katowicach i w Gdyni i będę mówił na temat reliability, a Ty, Szymon, w Gdyni tylko nad morzem. I Szymon będzie mówił o Internal Developer Platform w kontekście procesów, technologii i znaku zapytania, jak to jego tytuł brzmi oraz prowadził warsztaty z…

Szymon Warda: OpenTelemetry, Loki, API i Grafana, Tempo, takie rzeczy. Porównamy sobie, zobaczymy jak te dwa podejścia takiego jak trzymanie rzeczy samemu versus korzystanie z czegoś gotowego.

Łukasz Kałużny: Czyli observability.

Szymon Warda: Dokładnie.

Łukasz Kałużny: O którym Szymon tak marudzi tutaj czasami, że powinniśmy je robić. Więc zobaczycie jak można spróbować.

Szymon Warda: Jak marudzę to znaczy, że trzeba wziąć ręce do roboty i tyle.

Łukasz Kałużny: Dobra i z tej okazji mamy dwa bilety do rozdania, które będzie można wybrać na dowolny event. I gdzieś 10 albo 11 października roześlemy na naszym newsletterze do każdej zapisanej osoby maila, w którym będą informacje jak to zdobyć. Jakieś szybkie zadanko, kto pierwszy ten lepszy. Dwie najszybsze osoby zgarniają, które prawidłowo rozwiążą zadanie, zgarniają bilety i tyle. W ten sposób to ogarniemy. I chyba tyle z takich informacji. Zapraszamy, bo impreza może być ciekawa i też można wpaść i przybić piątkę, jeżeli macie ochotę. Dobra Szymonie, to co masz dzisiaj z linków?

Szymon Warda: Ja zacznę linkiem, który, nie będę ukrywał, pożyczyłem od Oskara, bo faktycznie link jest dobry. Artykuł, który całkiem ciekawie opisuje cashowanie, ale na poziomie bardziej systemowym. Czyli podchodzi do tego opisu strategii cashowania, typu cashowania, sposobów ewikcji, czyli usunięcia starych wpisów z casha, podstawowych systemów do cashowania. Wpis długawy, fajnie napisany i co więcej jeszcze powiem tak, że lepiej napisany niż ostatnio Redis opublikował White Paper swój odnośnie cashowania. No i ten wpis na blogu bije na łeb na szyję właśnie wpis z Redisa. Dużo lepszy, fajnie przemyślany i w jednym miejscu zbiera praktycznie wszystkie tematy wokoło cashowania jakie powinno się znać, także taki, na jakieś tam 10 minut czytania i wiedza już powinny być na dobrym poziomie.

Łukasz Kałużny: Ja to tak 20 ze zrozumieniem, 10 to żeby przelecieć.

Szymon Warda: Trochę tak, ale są dobre rysunki. W ogóle dobrze nawet na wysłanie komuś zabookmarkowanie sobie tego, że w kontekście cashowania to po prostu jeden wpis i po sprawie. No, dobry artykuł, więc Oskar - dzięki.

Łukasz Kałużny: Tak, Architecture Weekly się przydaje. Dobra, lecimy sobie z ogłoszeniami AI-owymi, bo takich będzie pewnie jeszcze przez najbliższy rok dużo.

Łukasz Kałużny: Tym razem, AWS odleciał na poważnie de facto z AI-em, że tak powiem, żeby pokonkurować sobie z Microsoftem i władował 4 biliony dolców ichniejszych, że tak powiem, przecinkach i separatorach w Anthropic. 4 biliony, gdzież nasze miliardy dolców. I z całością, dlaczego jest to ciekawe? Ponieważ ta firma produkuje, jeżeli komuś z was się nie obiło o uszy, swoje modele. Ma taki model Claude i Claude Instant, którymi są LLM-y. I to jest taka pierwsza z nich właśnie, najważniejsza de facto usługa, którą robią, czyli Amazon de facto zainwestował w dobrego LLM-a. Microsoft ma Open AI-a. Google ma swojego Barda i inne zabawki. I Amazon pod tym względem troszeczkę leżał, że tak powiem, z tym, co może zaoferować klientowi. Plus też całość, mają jakieś swoje researchowe usługi wokół tego.

Szymon Warda: Ja bym powiedział bardziej, że Google ma przerażenie w oczach, z całym szacunkiem.

Łukasz Kałużny: Raczej to też omawialiśmy, że gdzieś opensource może prześcignąć wszystkich, jak znajdzie się kasa na trenowanie.

Szymon Warda: To jest kwestia dużej kasy na trenowanie i to ogromnej kasy na trenowanie. Chociaż to też pójdzie w kierunku optymalizacji tego wszystkiego. Odnośnie tego linku, który podrzuciłeś, to ja tak rzucę ekonomicznie na to. Amazon musiał coś ogłosić. Musiał ogłosić jakąś dużą inwestycję i to musiało być dużo zer. Więc ja na zasadzie generalnie, czy ta inwestycja jest warta 4 miliardy? Może. Ale im zależało na tym, żeby wydać dużo kasy po prostu, bo musieli to zrobić, żeby utrzymać akcje na odpowiednim poziomie, tak naprawdę. Jestem ciekawy gdzie to się rozwinie tak naprawdę, ale jakoś do tego takiej wielkiej uwagi nie przykładam, powiem tak trochę. Według mnie to jest bardziej ogłoszenie dla inwestorów niż dla nas.

Łukasz Kałużny: Nie, wiesz, bo tutaj nic za tym, akcje jeszcze żadne nie poszły, że jakoś to zintegrują, cokolwiek. Na razie jest to ogłoszenie inwestycji. Zobaczymy co tam się zadzieje, bo to jest zawsze efekt, może być potem ciekawe w całości.

Szymon Warda: Dobra, to teraz ja trochę wrócę do tematu właściwie takiego trochę menedżerskiego, który raz na jakiś czas poruszam. Ciekawy i to jest dobre określenie, ciekawy artykuł odnośnie wydajności developerów - developer productivity. Nie w kontekście McKinsey’a, ale w kontekście tego, co powoduje, że my jako deweloperzy uznajemy, że jesteśmy wydajni. I czemu mówię, że ten artykuł jest ciekawy? Artykuł jest ciekawy, ponieważ po pierwsze, próbka była na 622 developerach z Google’a i jeszcze dwóch innych firm, więc to jest bardzo mała próbka. Co więcej próbka z dość wąskiego grona firm, itd. Kolejne, czemu to jest ciekawe, ponieważ wynikało to… Badanie jest oparte na tym, że ludzie samoraportowali pewne tematy, w sumie większość z nich, produktywność i co wpływa. I jeżeli chodzi o samoraportowanie w badaniach psychologicznych,ekonomicznych, itd., to one uznawane są za bardzo mało wiarygodne, co w ogóle nawet, nie wiem czy pamiętacie, od pierwszego odcinka właśnie mówiliśmy o tym, jak developerzy raportowali przerwania i co przeszkadza i jak wpływa. I okazało się, że było odwrotnie niż sami mówimy. Ale

Szymon Warda: czemu ten wpis mimo wszystko wrzucam? Dlatego, że to są tematy, które warto zadecydować w zespołach, żeby po prostu ludzie nie marudzili i żeby faktycznie otworzyć inne rzeczy.

Łukasz Kałużny: 48 pytań.

Szymon Warda: To właściwie jest wymiarów, które wpływa na wydajność. I co jest takie ciekawe? Ciekawe jest to, że najwyższe pozycje, TOP10, są rzeczy nietechniczne w ogóle. Ja bym się z tym zgodził. Idziemy po kolei. Co jest od najwyższych? Entuzjazm o tym, czym się ludzie zajmują, wsparcie od ludzi w projekcie, decyzyjność względem problemów de facto.

Łukasz Kałużny: Wiesz co, nie skracając, na temat nowych idei.

Szymon Warda: Tak.

Łukasz Kałużny: Wsparcie na temat nowych idei, bo to jest nie wsparcie, tylko wsparcie na temat nowych idei. Więc to jest ciekawe.

Szymon Warda: Dalej idziemy ciekawe. Profesjonalizm menadżerów zarządzających. Bagi, taski są czytelne i czy tam co jest do zrobienia i tym się to obniża frustrację developerów, że lubią kolegów z zespołu, decyzyjność względem rozwiązania tasków, w sensie czasu. I ostatnie to jest to, że ludzie są inteligentni, czyli że pracują w ciekawym środowisku. Wiadomo, że nie wszystko zaadresujemy kulturą organizacji, itd. Ale sporo z tych rzeczy jest do ogarnięcia tak naprawdę. I wydaje mi się, że też eliminowało narzekania, po pierwsze, bo nie oszukujmy się, produktywność jest często pomylona z tym po prostu, czy ludzie są zmotywowani. I te tematy powodują, że oni są mniej sfrustrowani, więc warto je zaadresować. Tak. Co więcej, jeszcze jedna rzecz generalnie jest to, bo tam jeszcze pytanie między różnymi firmami, jaka jest różnica de facto. I temat, który może nie jest w TOP10, jeśli chodzi o wydajność wydajność, ale zdecydowanie jest dość wysoko oceniany i jest najmniejszy rozrzut, to jest możliwość pracy zdalnej, żeby się skupić po prostu. I też wyszło w podsumowaniu to, że developerzy niezależnie od tego czy pracują zdalnie, czy pracują w biurze, generalnie otrzymują pewną ilość feedback’u do siebie.

Szymon Warda: Także to jest kwestia bardziej kultury niż tego, kto gdzie siedzi i jak siedzi tak naprawdę, damy sobie radę.

Łukasz Kałużny: Też ostatnio przy tym trafiłem, przy remote’cie na ciekawe stwierdzenie, że jeżeli firma techowa ma problem z remote workiem, to że w niektórych obszarach poszło coś bardzo nie tak.

Szymon Warda: Wydaje mi się, że tak, to jest w kontekście mikrozarządzania de facto, bo te 10 punktów, one też chodzą wokoło tego, że nie chcemy być mikrozarządzani.

Łukasz Kałużny: Tak, patrząc się z tego co można szybko poprawić, to jest 1 - zrobienie podejścia, żeby te nowe idee nie były odrzucane. To jest jedno kulturowe. Drugie jest czysto managerskie. To jest ten feedback na temat job performance. Po prostu trzeba dobrze do tego podejść. Dla managera będzie to trudne, ale patrząc z perspektywy wszystkich, to nie jest nic strasznego.

Szymon Warda: Ja zawsze powtarzam jedną rzecz, w IT często zatrudniamy inteligentnych ludzi i płacimy im dobrze, nie oszukujmy się. Więc zarządzanie inteligentnymi ludźmi, którym jeszcze dużo płacimy, przez mikrozarządzanie, jest jakąś wielką, wielką porażką. Naprawdę trzeba jednak pewne rzeczy poluzować, żeby ci ludzie mogli się ułożyć i żeby iść zadaniowo, po prostu. Rozmawiajmy celami, które chcemy osiągnąć, a nie kto co w której minucie robi. Ale tak, to wymaga zaufania po każdej stronie, od developera do managera i z managera do developera. I nie jest wcale praca do zbudowania.

Szymon Warda: Ale wpis jest całkiem niezły. To jest w ogóle skrót badania, które było przeprowadzone, więc jest też link do takiego konkretnego opisu jakby ktoś chciał, więc warto.

Łukasz Kałużny: Dobra, przejdźmy sobie do rzeczy technicznych. Jest sobie bardzo fajny tweet. Całość jest tak, że trafiliśmy teraz, że ta Datadog i głównie z Datadoga głównie sobie leci saga, że firmy się migrują, bo za wysokie koszty. Jest saga. Gdzieś tam też wspominaliśmy w jakiś odcinkach o tym, że trafiają się artykuły i jest najlepszy tekst. Patrząc się na całość tych rachunków i pytanie - do jakiej cholery procesowanie logów może być tańsze niż składowanie intiger’ów z metryk?

Szymon Warda: Mi się przypomina taki stary żart, który też był na Twitterze generalnie, że Cisco tylko nie jest teraz pewne czy chcieli zapłacić za rachunek, czy kupić Splunka. Ale ogólnie systemy APM, czyli application performance monitoring, one są drogie i one są też drogie w utrzymaniu.

Łukasz Kałużny: Tak, to jest całość. Tylko zauważ, że ludzie, to jest… Wiesz, jedno to jest, tylko ludzie bardzo często potem lecą, że ładują tam pierdyliard logów, jak popatrzymy zamiast w ogóle zająć się metrykami.

Szymon Warda: No ja widziałem systemy, które pracują na poziomie debug produkcyjnie, więc…

Łukasz Kałużny: Raczej ja, a propos Splunka widziałem, że u pewnego klienta bardzo się chwalił, że on ma metryki biznesowe zrobione z logów. Bo zrobili sobie framework do logowania, żeby w Splunku łatwo wyliczać metryki z logów i po prostu…

Szymon Warda: Ale to jest dość popularny element, bo to jest proste do outputowania i ja w prawie każdej organizacji widziałem jakieś metryki, czyli jakiegoś time stampa czy cokolwiek innego wpisywane do logów. To jest bardzo popularne, bo kiedyś tego nie było.

Łukasz Kałużny: I to się ciągnie przez lata. Ja też wrócę, bo kiedyś zrobiliśmy sobie taką chyba z 3 albo 4 odcinki, potem zalinkujemy tutaj, były sobie stare 3 odcinki gdzieś w okolicach dwudziestego na temat właśnie observability, na temat też metryk, więc polecamy tam zerknąć. I też z tego, co pamiętam, klęliśmy na logi jako takie w całości.

Szymon Warda: Ale też powiem, że to nie do końca jest wina developerów, to jest też często wina organizacji tak naprawdę, bo logi zawsze mamy, do pliku zawsze zapiszemy. A ci developerzy, którzy generalnie nie wiedzą czy będą mieli jakikolwiek dostęp do metryk, czy do traceability, itd., to po prostu co robią? To wpiszmy to logów. Plusem jest to, że teraz OpenTelemetry ma punkty, które umożliwiają zapisanie do innych źródeł. Czyli wysyłamy metryki, a potem kierujemy to do pliku. Więc to można zrobić. Swoją drogą OpenTelemetry jest w standardzie 1.0, więc hurra. Tak, ale tych rzeczy można robić. Także nawet gdybyście nie mieli czegokolwiek na start projektu, Prometeusza czy czegokolwiek innego, to OpenTelemetry i tam macie eksportery do plików ewentualnie i to jest kierunek, w którym można by iść ewolucyjnie, że tak powiem.

Łukasz Kałużny: Dobra, co jeszcze z Twojej strony?

Szymon Warda: Z mojej strony ciekawy artykuł, właściwie początek serii artykułów o ewolucji testera w Microsoft. Dawno, dawno temu MS, jak jeszcze wydawali głównie Windowsa tak naprawdę, mieli proporcje dwa do jednego. Czyli na dwóch developerów przypadał jeden tester. Żeby było ciekawiej teraz, to proporcja managerów była sześć do jednego. Czyli na sześciu developerów jeden manager. A proporcja engineering managerów, czyli takich technicznych bardziej po prostu ludzi, to jest dwanaście do jednego. Proporcja trochę mnie dziwi, że to w tym kierunku poszło, ale jest.

Szymon Warda: I fajnie Pragmatic Engineer opisuje, to już było kiedyś w innych artykułach i to jest ważne jak kontekst, czyli jeżeli MS wydało wcześniej Windowsa, którego nie przetestowali, nie było internetu albo było go bardzo mało, to poprawa takiego pudełka z Windowsem jest kłopotliwa, dlatego mieli relatywnie bardzo, bardzo dużo testerów. Natomiast potem zaczęło się to zmieniać, bo jak kiedyś robili Skype for web, rzeczy, które wydaje się często, co 2 tygodnie albo i częściej, to stwierdzili, że nie ma sensu posiadania takiej ilości testerów, bo to nie ten proces, trzeba zupełnie inaczej do tego podejść. I potem jeszcze fajnie, tylko dorzucę, jak zmieniło się podejście do testowania…

Szymon Warda: Dorzucę jeszcze link do blogu Microsoftu, jak zmieniło się podejście do testowania w Visual Studio Team Services, czyli obecny Azure DevOps. Jak przesunęli w ogóle tą piramidę testów z bardziej end-to-end, który wydaje się naturalny dla DevOps’a, właśnie bardziej w kierunku unit testów. Tu mam takie trochę wątpliwości jak, co…

Łukasz Kałużny: Tylko dużo z tego L0 powinno się nazwać end-to-end testingiem opakowanym w unit testy, bo to jest też taka rzecz, o której tu się nie mówi.

Szymon Warda: Tak, już o tym rozmawialiśmy wcześniej generalnie, że to nie są unit testy jak my to rozumiemy, że testujemy, czy dodała się pozycja do listy, bo sporo pisząc takie testy, wywalili. Testy sprzed ośmiu lat, mega dużo testów zostało wyrzuconych, jeden tester. Duża wartość tego artykułu.

Łukasz Kałużny: Jest piękny graf, pokazano jak wyglądało przechodzenie i że testy wyrzucamy.

Szymon Warda: I to jest bardzo ważne, bo naprawdę o ile ludzie jeszcze kod jako tako może wyrzucają, to stwierdzają, że testy: a może się jeszcze przyda i zakomentowanie, jakbyśmy Gita nie mieli. Ale ogólnie fajna droga pokazująca to, że wszystko zależy od kontekstu. Nie ma, że musimy mieć taką piramidę testową, albo że musimy mieć takie zachowanie. Dostosowujemy metodologię, dostosowujemy zachowania do kontekstu, w którym jesteśmy. Context is the king. Tak że wpis jest niezły. Mają być też wpisy odnośnie Google’a, Mety i jeszcze innych, więc zobaczymy jak to będzie wyglądało. No całkiem ciekawy artykuł. Co tam masz dalej Łukaszu?

Łukasz Kałużny: Dalej lecimy, może weźmy coś technicznego. Twit, który złapałem od Piotrka Stappa. Signal, w sumie to jest taka bardzo shortowa rzecz, ale ciekawa, która pokaże co się dzieje. Protokół Signala zaczął być odpornym przeciwko obliczeniom kwantowym, czyli całego łamania kryptografii za pomocą podejścia kwantowego, quantum computingu.

Szymon Warda: Pamiętasz, mówiliśmy o algorytmach, które są odporne i przyłączalne. Mniej więcej rok temu było coś takiego

Łukasz Kałużny: Od Cloudflare’a.

Szymon Warda: Bardzo możliwe, że tak.

Łukasz Kałużny: Tak że Cloudflare, to tutaj mamy właśnie taką kontynuację, że ta przyszłość dzieje się teraz. Jeżeli popatrzymy sobie na tą układankę, tu jest taka ciekawa rzecz, z którą będziemy się tak gdzieś po boku spotykać, bo pewnie obstawiam, że za jakiś czas po prostu stanie się to standardem w protokołach i tyle. I będą nowe algorytmy szyfrowania, które wymienimy po prostu sobie w stosie komunikacji i tyle z tego było.

Szymon Warda: Ale wydaje mi się, że to mimo wszystko kwantowe komputery pod strzechy nie trafią. Tak ja obstawiam w najbliższym czasie. Dobrze, to jak Ty masz coś krótkiego, to też jedną rzecz krótką dorzucę. Ponieważ regularnie nabijamy się z artykułów, że ktoś określa, że X technologia jest do dupy, dlatego nie należy stosować i z reguły dotyczą one serverless . To jest takie, że ktoś mówi: o Jezu, strasznie złe,; o Jezu, strasznie dobre. Więc ostatnio chyba był artykuł o tym jak chyba AWS Video stwierdzili, że tyle zaoszczędzili pieniędzy, bo wynieśli się z serverlessa .

Łukasz Kałużny: Tak, to było o indekserze którejś usługi z Prime’a, że zeszli na Prime’ie. Zeszli - zrobili joina kodu i zaczęli go hostować jako monolity.

Szymon Warda: Inna bajka. To teraz, żeby była równowaga, to jest kolejny artykuł, też od AWS-a swoją drogą, o tym właśnie, że Pfizer wyskalował swoją architekturę biomarkerów właśnie w lambdzie. Wpis bardziej do przekartkowania, taki raczej krótki. Ale to pokazuje, że znowu context is the king. Dopasowanie architektury do problemu, który mamy, a nie wszystko w jedno podejście. Oni akurat mają bardzo fajny usecase, z którego wykorzystali, lambdy, slash funkcje i to po prostu działa. Tak że usuńmy absoluty z architektury i z rozwiązań, bo to nigdy nie działa.

Łukasz Kałużny: Tak, dobre jest, można powiedzieć, że zrobili sobie map reviewsa na lambdzie, co swego czasu było bardzo popularnym rozwiązaniem.

Szymon Warda: W ogóle popularną i sensowną strategią do bardzo rozproszonego korowania de facto.

Łukasz Kałużny: Dobra i link ode mnie na koniec, kończący, że tak powiem, dzisiejsze wydanie. To jest coś, z czym mam problem, bo kiedyś trochę hejtowałem, czyli te podejście, że pojawił się Notify i listen na Postgres SQL, żeby można było budować własne kolejki. Teraz patrząc po całości, też po pewnych prezentacjach, pozdrawiamy tu Wojtka Ptaka i dyskusję na temat tego jak Revolut jest zbudowany pod spodem i że Revolut, ten biznesowy, lata sobie na Postgresie całkowicie.

Szymon Warda: Obecnie w ogóle wszystko lata na Postgresie, mam wrażenie.

Łukasz Kałużny: Tak, wiesz co i jak sobie zobaczymy, to jeżeli coś to ładnie nam opakowuje na całości, to ciekawą rzeczą ten Pub/Sub wbudowany, że tak powiem. Jeżeli mamy wystawione odpowiednie API, a nie rzeźbimy tam SQL-em, to jest to zupełnie ciekawą rzeczą, że baza danych załatwia ci de facto i kolejki, których nie implementujesz na tabelach w swojej aplikacji, jak i bazę danych. To jest taka, jak robisz jakiś, powiedzmy sobie, że modularny monolit, to może być to bardzo ciekawa alternatywa zamiast pchania się w dodatkowe Rabbity i inne elementy.

Szymon Warda: A ja bym powiedział tak, jeżeli jakakolwiek biblioteka, np. Mass Transit czy cokolwiek innego, przykryła by tego Pub/Suba Postgresowego, czyli byśmy mogli wymienić generalnie naszą warstwę transportu, czy to będzie Rabbit, czy będzie to Postgres, czy będzie to ServiceBase czy cokolwiek innego, to dla mnie to jest mega sensowne rozwiązanie. Bo zgodzę się, że na starcie w tym momencie stawiamy sobie np. jakiegoś Postgresa i mamy mniejszy narzut. Ja się boję tego, że co będzie jeżeli oprzemy a potem w liście z tego odpłynie warstwa abstrakcji, a to się rozleje po wielu miejscach i te wszystkie obudówki i co tam dalej będzie, potem wyjście z tego będzie kłopotliwe. Ja się tego boję w takich rozwiązaniach, bo jednak sorry, ale komunikowanie się bezpośrednio z brokerem wiadomości, tam coś musi być po drodze, bo tych problemów jest dużo.

Łukasz Kałużny: Raczej nie. Dlatego powiedziałem Ci o nakładce.

Szymon Warda: Tak.

Łukasz Kałużny: To też jest ważne i dlatego od tej strony jest to dla mnie interesujące, bo patrząc się Feature już zaczyna naprawdę być dojrzały pod tym względem.

Szymon Warda: Dla mnie jedna rzecz się w tym momencie uśmiecha, że w tym momencie jak robimy backup bazy danych, to backup danych i kolejki…

Łukasz Kałużny: Spójny!

Szymon Warda: Spójny. Nie mamy opcji, że mamy innego Redisa albo Rabbita i Kafki i potem musimy dowiedzieć się kto z którego momentu. Więc to jest dla mnie duży taki selling point tego podejścia. Jakby się udało? Spoko, Postgres, zresztą Cosmos też siedzi na Postgresie, tak że generalnie systemy rozproszone da się na nim robić.

Łukasz Kałużny: Tak, jest ten i chyba Hangfire wspiera wogóle Postgresa teraz… Nie, nie wspiera, nadal nie wspiera chyba.

Szymon Warda: Wspiera, tylko pytanie jest czy wspiera oficjalnie. Czy wspiera te notify’e, które Postgres teraz robi? Om wspierał już od dawna, bo był jakiś tam community plugin.

Łukasz Kałużny: A właśnie, patrzę się czy było, aż teraz sobie wpisuję Postgres, żeby zobaczyć czy się pojawił. Nic nie widzę tutaj, ale tak, jest to. Ogólnie wiesz, jak popatrzymy sobie w zależności w jakim świecie pracujesz, to jest to ciekawa alternatywa, żeby nie używać u siebie kolejek.

Szymon Warda: Nie używać brokera osobnego, bo z kolejek korzystać.

Łukasz Kałużny: Osobnego, tak, przejęzyczenie, wybaczcie, osobnego brokera, bo w wielu przypadkach… Inaczej, modularny monolit, kurde, może się okazać, że świetnie wtedy można wpakować sobie kolejki.

Szymon Warda: Tak, dobra, przypomnienie. Oczywiście w newsletterze jest cała sekcja short and sweet, czyli sekcja, gdzie nie ma o czym gadać, ale linki są fajne, więc…

Łukasz Kałużny: Tak, zostawiliśmy je.

Szymon Warda: Do przeczytania.

Łukasz Kałużny: Dobra.

Szymon Warda: I tyle chyba.

Łukasz Kałużny: No to trzymajcie się. Na razie.

Szymon Warda: Hej.