Mentionsy

DevTalk
DevTalk
11.08.2025 13:20

DevTalk #122 – O Residuality z Andrzejem Krzywdą

Rozmowa o tym, jak przygotować system, który przetrwa chaos… zanim chaos Cię zaskoczy. Dowiedz się, czym są stresory i residua, dlaczego warto przewidywać nieprzewidywalne i kiedy architektura staje się naprawdę critical. Z tego odcinka dowiesz się: Czym jest residuality i dlaczego to może być brakujące ogniwo w projektowaniu systemów; Co oznaczają pojęcia stresor, residuum i […]

The post DevTalk #122 – O Residuality z Andrzejem Krzywdą appeared first on DevTalk.

Szukaj w treści odcinka

Znaleziono 24 wyników dla "AI"

Nazywam się Andrzej Krzywda, prowadzę firmę ArkenC, działamy w języku Ruby, pomagamy z aplikacjami Legacy napisanych w Ruby on Rails.

Wymagania funkcjonalne już mamy ogarnięte na milion sposobów, dzięki domain-driven design, dzięki event-driven architecture, to już mamy ogarnięte.

Wszystko wiemy, jak zaimplementować, co nam biznes powie.

No i najczęściej z tego, co niestety obserwuję, to jest tak, że tworzona jest jakaś architektura, tak zwana naiwna architektura, najprostsza możliwa, tak zwany happy path jest zrobiony, no i potem wpada duży ruch, no i coś, za przeproszeniem, dobra, nie będę kloł, ale coś się nam zawali w tym systemie, więc my dziarsko już nauczeni tym doświadczeniem naprawimy to i już będzie system trochę odporniejszy.

I ten taki diff między tą architekturą pierwszą, naiwną, a tą drugą, która już ogarnie ruch 100 tysięcy ludzi, to jest właśnie residuum.

W sumie z tego, co mówisz, to przewidzieć wszystko, co się może wydarzyć, a następnie zaimplementować do tego jakieś rozwiązania.

zastanawiamy się, czyli znowu to jest bardziej na poziomie analizy, myślenia, nic nie implementujemy, zastanawiamy się, czy jak ten drugi stresor może być 100 tysięcy 100 tysięcy właśnie ruchu nagle się pojawia, trzeci stresor może być jakiś tam polityczny typu, nie wiem, nagle musimy wejść, otwierają się wszystkie możliwe bariery i możemy wejść na rynek, nie wiem, ukraiński, czyli w jakiś nowy zupełnie rynek

No AI oczywiście też wchodzi, prawda?

I nawet a propos właśnie AI, to też jest podnoszone teraz to, że wpływ generowanego kodu...

Natomiast efekt jest taki, że dzięki AI-owi więcej kodu powstaje w szybszym tempie w niektórych firmach,

Czyli oni mają stresora nowego, tym stresorem jest właśnie ten AI i ich komponenty, czyli na przykład CI jest komponentem, w tym momencie jest po prostu, nie wyrabia się i trzeba się zastanowić, okej, no to co w takim razie, tak?

Bo tu jest bardzo wiele analogii i wydaje mi się, że właśnie to, co nauczyliśmy się poprzez, nie wiem, domain-driven design, czy właśnie jakąś tam architekturę zdarzeniową, wydaje mi się i właśnie szczególnie coupling, to my to już znamy i to nie jest aż takie zaskakujące.

Ja podam jeden przykład, to już zrobiliśmy tak bardziej na szybko pewną analizę takiego naszego projektu dydaktycznego bardziej, czyli e-commerce, gdzie pokazujemy jak robić dobre domain-driven design, dobre event-driven, dobre event-sourcing.

Jakbyś to porównał do czegoś, co znamy wszyscy, czyli chociażby do Erika Evansa i Domain Driven Design rok 2003, 2004 czy 2005?

A może będzie właśnie Ericiem Evansem i wypromuje to na poziom Domain Driven Design.

Szczególnie właśnie ze świata Domain Driven Design, też bardzo popularnego przez świata w Polsce.

natomiast każdy z nas właśnie już wyciągnął jakieś rzeczy, które można natychmiast aplikować, to jest właśnie fajne, czyli to nie jest, tak samo było z Domain Driven Design, to właśnie to uważam za taką kluczową, kluczowy wyznacznik czegoś, co może osiągnąć sukces, to znaczy ty nie musisz 100% tego wdrożyć, możesz nawet tych tabelek nie robić, ale samo takie myślenie o tych stresorach, takie świadome, albo zrobienie tej tabelki po prostu chociaż raz gdzieś tam, to już jest wartość, to jest pewnego rodzaju świadomość.

Więc tutaj bardziej było takie, jako osoba, która też z domain driven design się utożsamia, tutaj dostaliśmy pewien język,

Że wy w ten sposób myślicie, czy z tego korzystacie, czy w ogóle, że to jest w kręgu waszych zainteresowań, czy raczej...

Tak, nie ukrywam, że to robimy, także myślę, że też w tę stronę idziemy i też pewne rzeczy, które robiliśmy wcześniej, nie mając może języka stresorów, residiusów i tak dalej, to ja widzę, jak nasz model biznesowy właściwie na tym jechał cały czas, znaczy my jesteśmy specjalistami od aplikacji Ruby on Rails, my po prostu totalnie wszyscy u nas są mega doświadczeni w tym temacie, wszyscy przerabiali dziesiątki właściwie takich projektów, widzieliśmy wszystkie wzorce i antywzorce Railsów.

Mieliśmy teraz klienta, to też a propos kolejnego stresora, stresorem dla wielu systemów teraz jest to, ile AI-ów teraz crawluje internet i próbuje zbierać, czytać wszystko, co się da.

I zwiększenie liczby odczytów, bo się AI tam bardzo aktywowały.

totalnie uwalało im system w godzinach roboczych, a to były takie typowe B2B, więc rozwiązaniem właściwie takim pierwszym residiu to było zablokowanie AI-ów, to było rozwiązanie właściwie większości problemów, tylko dojście do tego, że to jest problem, to wcale nie było takie oczywiste, też przez tą pojęczynkę tych mikroserwisów niepotrzebnych, więc... Ale to jest takowe, że chyba klękało niejednokrotnie w ostatnich dwóch latach przez to indeksowanie.

O, tu masz fajny stresor, czyli znowu świat AI i teraz twoja aplikacja tudusowa ma wystawić MCP, modne pojęcie, bo teraz AI będzie z tym gadał bezpośrednio, bo ty chcesz się przez czatem komunikować.