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 gdzieś tu na dole strony lub playera, czy w czym to słuchacie. Dobra Szymonie, co od Ciebie na początek?

Szymon Warda: Na początek ciekawy wpis. I wpis jest bardziej takim trochę jako zagadka do podejścia, jako ćwiczenie bym powiedział architektoniczne, tudzież algorytmiczne tak naprawdę. Wpis opisujący jak Uber wykorzystał algorytm i tu jest ciekawe, ponieważ algorytm został nazwany jako młody, ale w cudzysłowiu, z 1994 roku. Więc wiesz Łukasz, algorytm, który był elementem jest elementem stacku TCP/IP, który precyzuje rozrzucanie pakietów między różnymi ścieżkami nie względem zgubionych pakietów, względem latencji odbierania tych pakietów. I oni ten algorytm przerzucili jako swój algorytm load balancingowy w kontekście rozrzucania wiadomości między wielu subskrybentów, między wielu konsumentów tak naprawdę. Oczywiście to nie jest problem, który 99,9, dużo dziewiątek, z nas będzie miało, ale jest to bardzo fajny wpis jako taka zagadka jak ja bym to zaimplementował i jako takie przejście architektoniczne, algorytmiczne. Na pewno jest dobrze zrobione, fajnie napisane i pokazuje wiele obszarów jak użyli i czemu użyli odpowiednich elementów w pewnym miejscu. Tak że dobry.

Łukasz Kałużny: W ogóle to, co będziemy powtarzać, te bazowe algorytmy, stare algorytmy, one ciągle będą wracały.

Szymon Warda: Tak nie od parady książka o algorytmach jest z siedemdziesiątego któregoś tam roku, jakoś tak. To są stare rzeczy.

Łukasz Kałużny: Raczej chyba tylko sortowanie się polepszyły, bo sorty chyba były w latach 80-tych trochę poprawione i teraz ktoś, jak coś poprawcie mnie w komentarzach.

Szymon Warda: Była zmiana wybierania punktu środkowego w quicksorcie swego czasu tam, właśnie koło lat 80.

Łukasz Kałużny: Właśnie nie pamiętam. Tak, bo w siedemdziesiątce wiem, że searchów nie zamknięto, najgorszych algorytmów nie zamknięto w latach 70-tych. Dobra.

Szymon Warda: A Ty co tam masz?

Łukasz Kałużny: Wiesz co, fajna rzecz. Ultimate Guide to Quality Requirements for Software Architects: Meeting Stakeholder Expectations. I są fajne te wymagania klasyczne. Ma być szybko, ma być łatwe do utrzymania, ma się skalować, ma mieć dobry good user experience, czyli wrzody, z którymi spotkał każdy się z nas budując jakiś system, bo nie wiemy co ma być, tylko są wrzucone rzeczy. I taką część popatrzymy, jak sobie listę tych słów wszystkich, jeżeli popatrzymy, to słuchajcie, jest na to standard ISO, który jest nudny. Ale wszystkie te elementy, dla znudzonych polecam zjechać do diagramu po prostu, bo fajnie to wizualizuje, pokazuje właśnie w przypadku normy ISO 25010, edycji z zeszłego roku, pokazuje tak naprawdę rozbicie tego według takiej wystandaryzowanej, w którym miejscu takiego drzewka te wymagania się znajdują.

Szymon Warda: Grafu takiego.

Łukasz Kałużny: Tak, grafu, diagram może złe, graf jest lepszym określeniem. I są dobre definicje. I na taki wstęp, jeżeli sobie zaczynamy projektować, jeszcze nie czujemy się dobrze z określaniem tych charakterystyk, to jest to taki fajny punkt wyjścia.

Szymon Warda: Wpis jest absurdalnie wręcz długi.

Łukasz Kałużny: Tak, ale jak sobie popatrzysz, większość to jest wypunktowanie tych charakterystyk, które możemy sobie znaleźć.

Szymon Warda: Tak, muszę zapoznać się więcej z nim, to będę miał większą opinię. Na razie trochę mieszane uczucia, ale faktycznie jest niezły ten standard ISO, który dużo upraszcza i ten diagram faktycznie, pogrupowanie tego właściwie.

Łukasz Kałużny: Wartością jest pogrupowanie, żeby nazwać te niefunkcjonalne, bo większość, jak sobie zobaczymy… Słuchaj, większość, np. ile będzie? Z 5, 6 metryk będzie Cię całościowo, bo zobacz, z reliability, to co jest po reliability mamy pięknie, a w ability fold teraz recoverability.

Szymon Warda: Tak, ten graf robi robotę. Nawet dla samego tego diagramu warto zobaczyć.

Łukasz Kałużny: Zobaczyć czy fajnie też jest w utrzymaniu, że mamy modularację, reużywanie, możliwość analizy, testowania, możliwość łatwej modyfikacji, że są dobrze całościowo rozpisane i można sobie powiedzieć i potem też profesjonalnie zabrzmieć, jak umiesz odnieść się do normy ISO, w niektórych kręgach.

Szymon Warda: Tak, ale też takie ustandaryzowanie. Zawsze jakieś tam podparcie się czymś, co już inni wymyślili jest dobre. Zresztą też koła, nie warto na nowo zawsze wymyślać.

Łukasz Kałużny: Dobra, co u Ciebie?

Szymon Warda: To tym razem tranzycję świetną odnośnie wymyślania koła na nowo. Wrócę do tematu, który omawialiśmy już chyba przez dwa odcinki ostatnie, odnośnie tego dokumentu z Białego Domu, odnośnie używania języków wysoko poziomowych i memory save, czyli bezpieczne pamięciowo. Wpis z Pragmatic Engineer odnośnie tego i ilości problemów jakie wystąpiły 29 lutego. I to jest cała seria. Tego po prostu jest dużo. I teraz to jest ta wartość, właśnie odnosząc się, wykorzystanie języków tych takich bezpiecznych pojęciowo, czyli powiedzmy sobie szczerze, języków trochę wyższej kategorii w kontekście tego, że z reguły są bardziej obudowane, nie są takie niskopoziomowe, mają więcej bibliotek, z reguły są… Tego po prostu jest więcej tak naprawdę. Daje te plusy, że właśnie między innymi dodanie dnia +1 to będzie obsłużone. Więc naprawdę mało jest sytuacji, gdzie ten system musi chodzić i musi wykorzystać taki niskopoziomowy język i musi chodzić tak super szybko, gdzie użycie języka niskopoziomowego naprawdę ma sens i takie błędy nie wyjdą.

Łukasz Kałużny: Słuchajcie, najlepszy z tych, który można podkreślić, że EA Sports WRC nie działało 29 lutego i polecano zmienić datę na pierwszego marca w systemie operacyjnym, żeby zagrać.

Szymon Warda: Realnie brak działania takich rzeczy to jest naprawdę poważny problem. W kontekście EA Sports to może to nie jest krytyczne, ale jest masę systemów, Które się w takiej sytuacji wywali naprawdę.

Łukasz Kałużny: Za ile jest, w momencie, jak nagrywamy, chciałem zapytać się, bo jest kolejny event w najbliższym czasie, z którym jest masa problemów, to jest zmiana czasu.

Szymon Warda: Java nie jest sexy. Dotąd nie jest sexy, ale one działają i nie mamy tego typu problemów w takich wysokopoziomowych językach, więc naprawdę może niekoniecznie zawsze najnowsze zabawki, jeżeli chodzi o języki i wykorzystanie bibliotek, które już istnieją, przydaje się. Dobra, lećmy z tego tematu dalej, bo o tym wiemy tylko taki apel bardziej.

Łukasz Kałużny: Dobra, kolejny news. Microsoft zazdrościł Cloudflare’owi.

Szymon Warda: I bardzo dobrze, niech ktoś ich tam popędza.

Łukasz Kałużny: I słuchajcie, jest ogłoszone Distributed Function dla Azure Static Web Apps. Microsoftowe Static Web Apps to jest do hostowania wszystkich tych statycznych frameworków do stron, czyli aplikacji SPA i przydaje zawsze się jakiś backend API do tego. I tutaj Microsoft zrobił na swojej infrastrukturze to co CloudFlare ma już z 3 lata, jak nie 4, czyli Cloudflare Workers w opakowaniu od Microsoftu, czyli Distributed Functions. I zostało zapowiedziane preview. Więc taka ciekawostka, że da się już teraz, co jest fajne Szymon, jednym przyciskiem włączyć te Distributed Functions i nagle stamtąd, skąd idzie request, to nasza… Gdzie jest najbliższe datacenter z tego regionu zaczyna odpowiadać.

Szymon Warda: Czyli rozrzucenie danych statycznych w regionach tam, gdzie są najbardziej potrzebne.

Łukasz Kałużny: Tak, przy czym i teraz gwiazdka, bliżej jest temu podejściu do tego, co ma AWS a nie Cloudflare, bo Cloudflare odpala to totalnie na Edge’u. Tu jest najbliższe datacenter, więc to nie jest takie on the edge, takie mocne on the edge.

Szymon Warda: To i tak będzie też tam cashowane jakiś tam, z tych datacenter wyjściowych, ale tak, to nie jest taki typowy Edge jak ma Cloudflare, ale oni tego mają po prostu od groma i ciut ciut. Dobra, jeden wpis, jest taka historia, w internecie krąży, ona chyba jest prawdziwa, o tym jak NASA zatrudniając pracowników, głównie menadżerów, puszcza im film Armagedon. Kojarzysz oczywiście generalnie.

Łukasz Kałużny: Tak.

Szymon Warda: Doskonale. I puszczają ten film w kontekście znajdź problemy i znajdź błędy. Chyba rekordem jest 96 błędów, jakoś tak, dość pokaźna ilość, takich absurdów, takich oczywistych, jak łatwiej byłoby nauczyć astronautów wiercić dziurę niż wziąć wiertników, zrobić z nich astronautów, bo takie rzeczy organizacyjne, w sensie co NASA by w ogóle nie zrobiło. Ja mam taki ciekawy wpis, nazywa się to Hidden Cost of Using Managed Databases, który pokazuje…

Łukasz Kałużny: Przepraszam, jedną rzecz, bo musiałem sprawdzić, 168 błędów, jest rekord.

Szymon Warda: A, już teraz więcej jest. No to widzisz. I wpis, który pokazuje jedną rzecz, koleś, autor właściwie, pisze o tym, jak on mówi, że pokazuje trade offy tak naprawdę, rzeczy, które trzeba się pogodzić wykorzystując bazę danych, ale on pokazuje coś zupełnie innego tak naprawdę. Pokazuje jak taki totalny brak zrozumienia używania zasobów zarządzanych przez developera z perspektywy obsuw. Bo on tłumaczy to takimi rzeczami, jak np. że łatwo jest hostować własne serwisy, własne bazy danych, to jest w ogóle super proste. Np. że bazy zarządzane nie dają mu wejścia w niskopoziomowe metryki, że jak provider chmurowy może zgubić backupy tak naprawdę, a przecież organizacje takie zwykłe mają, trzymają osobny datacenter, itd. i trzymają te, chyba są na taśmach, itd. To jest taki brak zrozumienia w tym kontekście, że zgodzę się, trzymanie jednej bazy danych jest super proste. Trzymanie stu baz danych w różnych wersjach, zarządzanie i utrzymanie, to nie skaluje się zupełnie liniowo, to jest masę więcej roboty. Backupy, można mieć osobny datacenter, tylko ile to kosztuje organizacyjnie, kasowo, itd. To jest taki totalny brak zrozumienia w sensie skali. Koleś jest CEO startupu i jego tak, to nie ma sensu, znaczy mogą nie mieć sensu bazy zarządzane. W sensie korporacji, która tych baz ma generalnie setki, to jest wybawienie.

Łukasz Kałużny: Właśnie chciałem powiedzieć, że koleś przeszedł z Cloudflare’a, zajmował się tam, był Database Practitioner, jak to jest określone, czyli gdzieś tam ekspercko się zajmował i otworzył swój startup na bazie Postgressa. Raczej nie, fajnie jest pokazane, że są takie rzeczy jak secondary backups, backup restoration, to jest rzecz, którą zobacz, że na co dzień Szymon ja nawet biorę, bo dwa tygodnie temu omawiałem, czy tydzień temu omawiałem to właśnie w kontekście takiej standaryzacji z klientem. Jest tam dużo dziwolągów, które z tych trade offów trzeba mieć zrozumienie, że one występują, bo one występują.

Szymon Warda: One występują. Ale załóżmy w kontekście backupów, jak łatwo jest Ci zrobić backupy, załóżmy, że padnie region, albo coś się stanie, jak łatwo jest Ci zrobić backup w innym regionie w chmurze, a ile Ci to zajmie na on-premie? Onprem to jest projekt.

Łukasz Kałużny: Raczej na on-premie… Musisz inaczej, tu sobie klikniesz, w on-premie musisz przygotować sobie cały setup pod takie coś. Fakt, że to jest często jednorazowa operacja, jak już to zrobisz to potem…

Szymon Warda: Tak, ale to jest projekt, który Ci zajmie miesiące, bo musisz wybrać miejsce, musi to być zrobione bezpiecznie, itd.

Łukasz Kałużny: To jest tak, wybrać software, appliance i inne zabawki, jak robimy to sobie. Nie, więc w kontekście takim wiesz, to co jest powiedziane fajnie odnosi się do firm SAS-owych, albo które wchodzą w naprawdę dużą skalę na jednym produkcie. To jest bardzo fajny wpis, ma on rację. Jeżeli tworzymy Enterprise Soft to zwykle te trade’y… Inaczej, koszt organizacji jest o wiele większy niż trade offy, które będą z tego poziomu, jeżeli popatrzymy sobie na całość układanki.

Szymon Warda: To jest dobre podsumowanie faktycznie. Jeżeli mamy generalnie jeden system albo bardzo mało tych systemów, tylko mają duże one użycie, to ok. I faktycznie, posiadanie specjalistów od poszczególnych baz, żebyśmy wiedzieli, jak najbardziej to ma sens. Natomiast jeżeli od groma i ciut ciut, to sorry, te bazy zarządzane są po prostu wybawieniem tak naprawdę. Wiadomo, wejście w bardziej SaaS-owe systemy, to jak najbardziej, jeszcze Azure, SQL Database, itd., to jeszcze lepiej. Ale nie, to jest dla mnie fajny wpis do przejścia z perspektywy generalnie jak to wygląda w organizacjach dużych, korporacjach tak naprawdę, gdzie tego po prostu będzie dużo i tyle. Dobra, co tam u Ciebie?

Łukasz Kałużny: Wiesz co, przerwa reklamowa. Jeżeli potrzebujecie pomocy w układaniu takich tematów i następnego linka, to nie wszyscy kojarzą po rozmowach z Wami, że na co dzień z Szymonem zajmujemy się doradztwem technologicznym w Protopii, więc jeżeli potrzebujecie…

Szymon Warda: Nie tylko doradztwem.

Łukasz Kałużny: Pomocy, nie tylko właśnie, jeżeli potrzebujecie zrobić jakiś projekt, albo go skonsultować, albo się przeszkolić, to możecie do nas uderzać. Link, z którym chciałem właśnie podejść, to jest Szymona konik ostatnimi czasami, czyli Open Telemetry. Honeycomb wrzucił, zaczął serię wpisów na temat best practice. I pierwszy jest to, co Szymon ględzisz, w szczególności przy części platformowej IDP na temat telemetrii, to jest właśnie weź gotowy standard z rynku. I tu jest takie wskazanie jak to wygląda z namingiem.

Szymon Warda: To jest bardzo niespójne, ponieważ naming open telemetry jest inny niż nazewnictwo Prometeusza.

Łukasz Kałużny: To jest inna rzecz. I słuchajcie, to jest po prostu, jak zawsze w zależności którą wersję tam wpisu sobie weźmiemy, słynnego cytatu, ale na koniec dnia naming things is hard całościowo. I tu jest wprowadzenie na temat Symantec Convention domeny, namespace’ów, sposobu organizacji tego, czyli takie pierwsze wjechanie w jaki sposób powinniśmy podejść do jednej chyba z najgorszych rzeczy na początku, czyli jak to nazywać.

Szymon Warda: Najgorszej, ale też bardzo ważne do ustalenia, bo jak już coś ustalimy, to to zostanie w tej wersji. Dodam, że artykuł jest krótki i faktycznie skupia się na nazewnictwie. Niewiele więcej, ale jest zapowiedzią całej serii, więc faktycznie warty do rzucenia okiem.

Łukasz Kałużny: Tak, jest tam od razu zalinkowany kolejny wpis, ja go też może podlinkuję, jest na przykład właśnie na temat samych Symantec Convention. Pokazanie właśnie na podstawie już bardziej sygnałów, jest następny wpisik, więc warto to, jeżeli podchodzi się do open telemetry czy ogólnie autoinstrumentacji, warto się zapoznać z tym, albo wziąć Szymona do pomocy.

Szymon Warda: Dobra, to teraz ja polecę z kolejnym wpisem od RevenueCat. Wpis, który opisuje ich przejścia i rzeczy, które trzeba zastanowić się w kontekście wykorzystania casha, casha rozproszonego w ogromnej skali. I dla mnie to jest taki wpis, który pokazuje jak często ludzie tak mówią, że skale Googla, chcemy robić jak Google, itd. A ten wpis doskonale pokazuje to jak w większości sytuacji absolutnie nie chcemy mieć skali Google albo nawet takiej skali właśnie RevenueCat. Bo z takiego casha, weźmy sobie po kolei co jest do ogarnięcia. Zarządzanie połączeniami TCP/IP, bo generalnie nie będziemy przecież tego połączenia za każdym razem otwierali, bo to jest dość kosztowne otwarcie i musimy odpowiednio to poolować.

Łukasz Kałużny: Witamy connection pooling.

Szymon Warda: Dokładnie tak. Co znowu języki wyższych, frameworki wyższych poziomów mają to z reguły wsparcie. Niektóre nie mają tego w ogóle i trzeba to dorabiać. Wykrywanie serwerów, które za chwilę padną albo są w trakcie padania, to jest ważne. Rozgrzewanie serwerów bez wpływu na działanie reszty systemu, to nie jest takie coś, że w dużej skali SAS-owej możemy powiedzieć: a bo cash się dopiero rozgrzewa. No nie. Dalej, planowanie na awarię i projektowanie fallbacków, w sensie co się stanie i gdzie to ma się przełączyć jeżeli coś nawali. Dalej, będziemy mieli cashe do specjalnych zastosowań, do bardzo wąskich systemów, które muszą być superszybkie, więc trzeba te poole wydzielać. Problemy z nierównomiernym rozkładem gorących kluczy. Co się stanie jak klucz wygaśnie i wiele serwerów o niego zapyta, czy mamy takie, że nagle 20 maszyn po prostu leci do tej bazy i baza ubije. Resharding cashe’y.

Łukasz Kałużny: To jest w ogóle kurde, to jest przewalone. Dodajesz cash i powinieneś zrobić resharding.

Szymon Warda: Ja powiem tak więcej, a dopiero zrób resharding na bazach danych, to jest dopiero też przerąbane. Bo w ogóle jak mówimy resharding jest super, bo jest super, to trzeba się nauczyć.

Łukasz Kałużny: Ale utrzymanie jest masakrą.

Szymon Warda: Tak, ale dojdziemy do takiego momentu, że będziemy musieli jakoś ten resharding zrobić. Dalej, wymiana serwerów i migracje z wyłączeniem serwerów. To nie jest takie oczywiste, że sobie wyłączymy serwery, itd. Będziemy musieli je włączać, wyłączać, utrzymywać dalej.

Łukasz Kałużny: Przepraszam Szymon, chyba, że jesteś bankiem i masz wyłączenie co 3 miesiące.

Szymon Warda: Tak też może być. Spójność, bo te cashe też muszą być spójne. Dalej lecimy, problemy przy zapisie, bo jak będziemy mieli… Znowu, wracamy do tego, że cashe są rozproszone, czyli zapisujemy z reguły do kilku cashe’y, żeby mieć duplikację po prostu. Więc jak mamy do dwóch różnych, albo większej ilości maszyn to mamy problem, że gdzieś się może nie udać. Czyli mamy nagle problem braku spójności. I znowu, potem tych problemów jest naprawdę bardzo, bardzo dużo. I to jest taka opcja, czy naprawdę chcę mieć taką wielką skalę? Co do sytuacji, to jest takie dobre balansowanie odnośnie tego, jakie z tym budujemy i jakie wyzwania dobieramy. I jeżeli pójdziemy w kierunku takim - duże systemy, bo projektujemy pod duże systemy, itd., to nie wystarczy dać sobie 3, 4 cashe, to trzeba zaprojektować co się będzie działo i spojrzeć na te przypadki użycia, bo czasami może jeden większy cashe nam wystarczy i mówię, to nie jest idealne rozwiązanie, niż wejście w wiele i nagle otwieramy taką skrzynkę Pandory i nagle te wszystkie rzeczy musimy obsłużyć, bo inaczej to nie będzie działało poprawnie. Będziemy mieli błędy danych zwracanych.

Łukasz Kałużny: Jak to było? Dodając cashe do aplikacji zamiast jednego problemu z wydajnością masz już dwa.

Szymon Warda: To jest w ogóle ciekawy system, bo czasami bierzemy przykłady wzorując się, zresztą Ty o tym też mówisz na swoim szkoleniu, Architektura 101, tak, właśnie, że kontekst jednak jest najważniejszy. To, że robi tak Netflix, Twitter, itd., spokojnie dobierzmy do tego, co realnie mamy. A jak już chcemy w ten kontekst pójść, to bądźmy świadomi tego, co musimy zrobić, żeby to w ogóle działało poprawnie, niekoniecznie tylko szybko. Tak że taki wpis. W ogóle wpis długi, bardzo dobry, fajnie opisujący…

Łukasz Kałużny: Raczej pokazujący. To jest z tych smutnych wpisów, pokazujący ile trzeba się narobić, żeby utrzymać to up and running.

Szymon Warda: To jest fajny wpis w kontekście tego, jak się ma jakiegoś młodziaka, który mówi: dodajmy, zróbmy tak. Ok, możemy, możesz zrobić. Przeczytaj ten wpis i pokaż mi rozwiązania na problemy, które tam występują. Jak Ty je zaadresujesz. I nagle jest takie: czy naprawdę chcę? Co u Ciebie?

Łukasz Kałużny: To będzie ostatni link na dzisiaj ode mnie. W sumie dwa, bo jeden do tweeta, drugi do krótkiego artykułu na podstawie tweeta. Tutaj też pudelkowatość dotarła. Kelsey Hightower, czyli z Googla, developer advocate, który gdzieś tam bardzo mocno w światku CNC-owego działa. Rzucił sobie takim tekstem, że: wierzę, że składnia terraforma stanie się przez to, że OpenTofu teraz w ten sposób zaczyna działać, interpretować, że ta składnia, terraforma staje się http off configuration management.

Szymon Warda: Ale overhyping, Jezu.

Łukasz Kałużny: Cieszę się, bo prawdopodobnie masz teraz taką minę jak ja miałem jak to przeczytałem i stwierdziłem, że dobra, muszę to.

Szymon Warda: Ja Ci powiem tak, składnia terraforma jako taka wygrała, bo to Bicep pokazuje chociażby generalnie…

Łukasz Kałużny: Raczej HCL. Czy wiesz, wygrał… Zauważ, patrząc się na całą układankę, zresztą omawialiśmy to kilka odcinków temu, nie pamiętam dokładnie w którym, ale rozmawialiśmy na temat IaC-ów, że mamy też ten trend, pisz IaC-a w swoim języku programowania.

Szymon Warda: Zły pomysł.

Łukasz Kałużny: Proszę, żeby tylko zostawili logikę taką samą wszystkich narzędzi.

Łukasz Kałużny: Wiadomo, że on robi hyping. Mi przypomniała się taka sytuacja, jak ktoś wytknął Ballmerowi, że nabijał się z iPhone’a. Ballmer powiedział: ale pamiętasz jaką wtedy rolę pełniłem? Więc co ja mogłem innego zrobić? To jest prawdziwe. On hype’uje. Dla mnie całe ostatnie dwa lata porażek open source’u w kontekście skąd brać pieniądze, pokazuje bardzo jawnie, musi ktoś stać za projektem, to się po prostu samo nie zadzieje, samo się nie utrzyma. Sorry, czy hashicorpowe utrzymanie terraforma jest dobre? Nie, trochę zapomnieli o tym. Pod wieloma względami jest to taki projekt, który tam trochę żyje, trochę nie żyje, nie jest utrzymany super. Ewidentnie HashiCorp też ma, nawet jak my rozmawialiśmy, mało kto za terraforma płaci, więc mało też inwestują w utrzymanie go. Ale OpenTofu? Nie, nie wydaje mi się. To ja mam jeszcze jeden wpis. Tak mi się przypomniało. Architektura heksagonalna, prezentacja odnośnie twórcy architektury heksagonalnej, jest jedna rzecz, bo o niej się wiele mówi na prezentacjach, na prelekcjach, itd. Czy ktoś realnie, bo ja znam chyba jedną sytuację gdzie ona realnie była wykorzystywana, jest ciekawe pytanie do Was, czy wykorzystujecie architecture, hexagonal architecture, layered architecture? Można to różnie nazywać. Taka gdzie mamy porty i adaptery, itd. Czy ktoś z Was z niej realnie korzysta w systemie produkcyjnym tak naprawdę? Bo jestem ciekawy jak to wygląda. Czemu? Bo to jest generowanie ogromnej ilości kodu, łatwo się boarduje ludzi, absurdalna ilość kodu tam jest potrzebna. To tak z ciekawostek, dajcie znać. Więc to jest test: Oskar daj znać czy nas słuchasz, bo zawsze mówisz, że do końca. Więc jak coś zapraszamy do następnego shorta. Podyskutujemy wspólnie.

Szymon Warda: Dobra, to tyle chyba.

Łukasz Kałużny: Tyle, kończymy. Trzymajcie się.

Szymon Warda: Na razie. Hej!