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 klasycznie na Patoarchitekci.io tym razem / 78. Albo gdzieś w tym playerze, w którym słuchacie na dole w opisie. No dobra, Szymonie, to co w tym tygodniu znalazłeś ciekawego? O czym chcesz podyskutować, się podzielić?

Szymon Warda: Parę rzeczy wygrzebanych, jeden ciekawy artykuł, mam co do niego mieszane uczucia, ale o co chodzi? Stworzyli na podstawie badań platformę, wzór do mierzenia DevEx, czyli Developer Experience. Możemy powiedzieć sobie, że tu chodzi o biblioteki, nie. Tu chodzi właśnie o wydajność. Mierzenie wydajności nie przez właśnie wydajność w sensie linii kodu. Mierzenie wydajności na poziomie różnych metryk z reguły się nie sprawdza, no bo to raczej jest twórcze zadanie, ale właśnie na bazie kilku rzeczy stworzono bardziej framework do tego, jak podchodzić do wydajności pracy developerów, poziomie, jak oni odczuwają to i jak te procesy ułatwiać. No bo zakładając, że ludzie się nie opierniczają, to im łatwiej się im pracuje, tym powinno być lepiej, wydajnie. Trochę mieszane uczucia, bo jest tu dużo dobrych rzeczy. Chciałbym to zobaczyć w praktyce, no ale właśnie, o co chodzi…

Łukasz Kałużny: No właśnie, powiedz o tych… Bo są te, trzy filary tego do mierzenia rzekomo.

Szymon Warda: Tak, są trzy filary. Jedno to jest oczywiście flow, czyli przykłady, context switching, czytelność zadań. Ile mamy nieprzerwanego czasu? De facto. Kolejny to jest cognitive load, czyli wielkość rep, ilość zadań, rzeczy stare, które mamy w projekcie itd. Kolejny to jest feedback loop. Czyli generalnie jak często cenimy informacje o jakości naszej pracy? Niekoniecznie przez menadżera czy cokolwiek? Tylko testy, czas buildów itepe, itede. No nie? I to teraz zostało podzielone też na dwie takie… Mówimy o takich kolumnach niejako. I teraz dzielimy to jeszcze horyzontalnie na poziomy - perception, czyli to, jak to jest odbierane przez ludzi I kolejno jest workflows, czyli tak naprawdę jak to wygląda w całym procesie. Wiadomo, że odczucie może się różnić od tych workflowów. I na koniec możemy fajnie sobie ustawić KPI. Generalnie jak to powinno wyglądać. I powiem tak, punkty mierzenia i jak do tego podchodzą są dla mnie osobiście bardzo sensowne. Problem jest taki jaki tu widzę to jest to, że perception jest mierzone przez ankiety.

Łukasz Kałużny: To jest właśnie rzecz, którą chciałem powiedzieć, że to są jego mać ankiety i one sprawdzą się w skali.

Szymon Warda: Tak, dokładnie o to właśnie mi chodzi. To musi być naprawdę niezła skala i tu mówimy niezła na poziomie więcej niż 50 osób dla mnie, żeby te dane nie miały takich fluktuacji bardzo źle, bardzo dobrze itd. Kolejny jeszcze element jest taki, jeżeli chodzi o ankiety, to dla mnie mierzenie takich rzeczy bez mierzenia. Generalnie jak się ludzie czują ogólnie bez kontekstu firm. Nie wiem, na przykład firma miała jakieś tam powiedzmy, że wyniki, cokolwiek… Generalnie co ludzi wkurzyło, albo nie ma owocowych śród czy cokolwiek innego, w tym stylu, to automatycznie percepcja pójdzie nam znacząco w dół. Nawet czas dnia pójdzie nam znacząco w dół, więc to może fluktuować bardzo mocno.

Łukasz Kałużny: Wiesz co, ankieta będzie. Przepraszam, że to tak określę, ale od poziomu wkurwu w danym dniu, kiedy ją ktoś wypełniał albo jak bardzo został zmuszony do wypełnienia.

Szymon Warda: Zgadza się, w dodatku jeszcze u nas kultura jest taka z reguły polska, że nie lubimy takich pierdół HRowych i tak dalej, i tak dalej.

Łukasz Kałużny: Raczej… Ankiety techniczne za to są. Jakie te workflow, które są właśnie, te techniczne metryki? One de facto w większości przypadków, można powiedzieć tak jak są, przekładają się na tym, co jest w Dora Metrics na przykład.

Szymon Warda: Mhm, w ogóle metryki jak oni patrzą, to coś w artykule wyszczegóławiają jako generalnie TS, typu mierzenie bloków, nieprzerwane bez spotkań, mierzenie długości TS, i tak dalej. To są bardzo sensowne metryki. Całości frameworka jako takiego nie do końca kupuję, ale artykuł jest warty, żeby na niego rzucić okiem, żeby po prostu parę właśnie takich smaczków wyłapać. Właśnie. Jak spojrzeć? Do przemyślenia wewnętrznego. Co jest istotne.

Łukasz Kałużny: Właśnie to ja bym jeszcze dodał, że właśnie te rzeczy na temat perception w tych feedback loopach, cognitive loadzie, flow state, to są… Jako robienie z tego metryk… Jak nie masz skali to nie. Ale świetne do przemyśleń, w szczególności jeżeli robisz jakiś większy produkt. Czyli masz tam nie wiem, minimum 50-60 osób. Jesteś software housem czy cokolwiek tego typu? To zobaczenie sobie tego jak bardzo wkurzamy ludzi albo ich spowalniamy tymi punktami.

Szymon Warda: Dla mnie ta cała grupa perception… Ona jest bardzo fajna na omówienie tego na retro. Nie wrzucanie tego w ankiety, ale omówienie tego na poziomie retro i jako takie właśnie zbieranie co faktycznie ludzie mówią i jak to wygląda.

Łukasz Kałużny: Takie na bieżąco, taki cały na bieżąco na zasadzie - zadaj jedno z każdego pytania z każdego typu, nie zawsze to samo, żeby łapać feedback.

Szymon Warda: Tak i potem eskalujemy to w górę i potem patrzymy gdzie, załóżmy, putuje naszą roadmapę na 3, 6 miesięcy. De facto. Więc ma to sens. Niekoniecznie w tej wersji, w jakiej zostało to ubrane w artykule, ale dobry zdecydowanie. A co tam Łukaszu Ty wygrzebałeś?

Łukasz Kałużny: Dobra, to jest ciekawostka jak bardzo open source dla dostawców cloudowych jest poważnym biznesem. Zresztą jest.

Szymon Warda: Jest.

Łukasz Kałużny: Ale jakie są zachowania strategiczne? Przeleciało mi gdzieś to z boku. Microsoft w 2020 roku, na bazie tej specyfikacji Service Mesh Interface zbudował coś, co nazywało się Open Service Mesh, czyli miał być to prosty Service Mesh wykorzystujący envoya, oddany bardzo szybko do CNCF’u. I teraz co się zadziało? Bo ja jakoś to w ogóle przeoczyłem totalnie. W maju projekt został zarchiwizowany, zamknięty. No i niby jest CNCF’ie i w ogóle. Open Service Mesh. Jeżeli tam popatrzymy na pewną strukturę to de facto Microsoft nie miał wpływu wcześniej na inne Service Meshe poza jakimś częściowym Linkerd, który w wersji Managed nigdzie nie występuje. I powiedzmy, że popularność cloudowa jest… Różnie, patrząc się na to Linkerd. A z drugiej strony nad Istio bardzo mocno trzymał pieczę Google i trochę IBM. Tam zaszłości historyczne jak popatrzymy sobie na całość. I teraz co jest najciekawsze, w zeszłym roku Istio pod koniec września zostało przekazane do CNCF’u.

Szymon Warda: Co było ciekawym ruchem.

Łukasz Kałużny: Tak.

Szymon Warda: Długo się opierali, żeby tego nie robić.

Łukasz Kałużny: Tak, bardzo długo, ale poszło. I słuchaj - i teraz co się dzieje? Dlaczego mówię, że to jest rzecz czysto biznesowa? Od kiedy Istio znalazło się w CNCF’ie, dla ludzi z Microsoftu to wiele łatwiej będzie kontrybuować do projektu.

Szymon Warda: Teoretycznie w CNCF’ie byłoby zbyt dużo Service Meshy de facto, no nie oszukujmy się.

Łukasz Kałużny: No tak - ale i z drugiej strony co Microsoft zrobił, bo to jest taka rzecz gdzieś na buildzie zostało ogłoszone, zrobił, addona do Kubernetesa, żeby był managed Istio.

Szymon Warda: To jest ciekawe - znaczy właśnie, powiedzenie managed Istio to jest bardzo szerokie stwierdzenie. Bo w Istio można wiele rzeczy włączyć i wyłączyć, które tak drażniąco komplikują operations.

Łukasz Kałużny: Tak, chodzi o to, że masz instalowany addon, instaluje Ci się Istio i masz do niego support vendora.

Szymon Warda: To jest dużo tego. Który poziom Istio, bo w Istio można wiele rzeczy włączyć, wyłączyć.

Łukasz Kałużny: Tak, to wiesz, nie wchodźmy już teraz w detale, tylko… Tylko całość, że zrobili to w ten sposób, żeby… Właśnie zobacz, że ubijają projekt, ogłaszają wsparcie dla nowej rzeczy i jazda. I nie muszą inwestować teraz tej kasy, bo jednak opiekowali się tym projektem w ramach CNCF’u jakim jest Service Mesh, więc mogli developerów wykorzystać do czego innego.

Szymon Warda: Znaczy nie oszukujmy się, dla MSu głównym źródłem dochodów to jest obecnie Azure, więc to utrzymywanie open Service Mesha było kosztem dodatkowym, w dodatku kosztem jeszcze takim, gdzie spora część rynku kręciła nosem. Mówią nie, nie, nie, tego to byśmy nie chcieli. My byśmy chcieli coś, co jest jednak lepiej znane itd. Więc tak, biznes, dokładnie.

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

Szymon Warda: Ciekawy artykuł odnośnie Data Patterns na Edge’u.

Łukasz Kałużny: Mhm.

Szymon Warda: Tak naprawdę. W miarę długawy. Omawia trzy wzorce zachowań. Synchronous Data Retrieval, Subsequent data retrieval, i prefetched data retrieval. Nie są to wzorce, które są jakieś skomplikowane, wiadomo synchronous, czyli generalnie z naszego edge’a. Raczej tej takiej na rynku komputerów bliżej nas generalnie. Pobieramy te dane z chmury albo z jakiegoś innego data center, żeby były bliżej. Subsequent to jest to, że pobieramy pierw a potem synchronicznie pobieramy kolejne części i prefetch, czyli pobieramy wcześniej. Więc nie są to wzorce, które brzmią jakoś skomplikowanie, ale poziom głębokości i omówienia ich. Tam jest dużo rysunków i tak dalej i tak dalej… I zachowań, plusów i minusów. Bardzo dobry opis. To mnie skłoniło żeby ten link polecić, bo sensownie, fajnie opisane Patterny. Rzadko widuję tak dobrze napisane patterny, z reguły są paroma zdaniami bez rysunków itd. A tu to zrobione jest naprawdę nieźle. Więc tak. Naprawdę dobry, dobry artykuł.

Łukasz Kałużny: Inaczej. Co ciekawe, rzadko kiedy użyjemy tych wzorców. To jest bardziej chyba wrzucenie sobie do świadomości.

Szymon Warda: Tak, bez dwóch zdań. Jak najbardziej tak.

Łukasz Kałużny: Jak nie walczymy o każdą milisekundę z klientem, nie robimy projektu, znowu ja się zaśmieję, w tej skali. Warto sobie przeczytać, żeby uświadomić sobie o możliwościach jak można pewne rzeczy robić, a implementować na siłę edge’a nie polecam.

Szymon Warda: Tak, znaczy to będą wzorce, które będą implementowane przez dostawców chmury de facto. Przełożenie jak to może wyglądać? To jest o dziwo dla ludzi na UIu, z grubymi klientami. Jak się to ma zachowywać i tak dalej. Więc to jest tak. To jest zdecydowanie artykuł po to, żeby pomyśleć, niekoniecznie żeby generalnie od razu wykorzystywać. Bo też nie polecam.

Łukasz Kałużny: Dobra, co jeszcze u Ciebie, Szymonie, bo Ty masz w tym tygodniu więcej?

Szymon Warda: I ja… Tak. Ciekawy artykuł - już ruszymy temat AI’a itd.

Łukasz Kałużny: Ajaj…

Szymon Warda: Ale na pewno pamiętasz, jak wchodziły głębokie modele nauczania. To była próba regulacji na poziomie całej Unii Europejskiej i chyba w Stanach też do tego, żeby jeżeli te modele są wykorzystywane w krytycznych zastosowaniach, to żeby mogły one być tłumaczone. I w tym momencie było wielkie, nazwijmy to, obsranie, bo generalnie tłumaczenie tych modeli jest piekielnie trudne. I teraz temat wraca, de facto i będzie wracał, to się nie oszukujmy, szczególnie, że mamy interfejs tekstowy, więc to będzie dużo ważniejsze i openAI zrobił ciekawą rzecz. Wytrenowali Chat GPT-4 i wykorzystali. Żeby umiał wytłumaczyć zachowania, interpretacje. Chat GPT 2. I to jest ciekawe, bo jest to super ważne dla całego governance - a wydaje mi się, że te modele jak będą szerzej wykorzystywane, jednak regulacje rządowe jakieś będą powstawały, niekoniecznie same modele, ale kiedy, które modele, gdzie wykorzystywać?

Łukasz Kałużny: Wiesz co, to jest jedno - ale to jest w ogóle też… Ułatwi problem audytowalności, bo jak byłem ostatnio teraz na infoShare to gadałem z prelegentem, już zapomniałem jak się nazywa. Koleś jest z pewnej firmy z Londynu i zajmują się czymś, co można określić jako AI Ethics. Jeżeli bardzo ładnie wchodząc. I tłumaczył mi model w jaki sposób, bo jedną z ich usług jest audytowanie modelu pod względem czy nie ma cognitive biasów, jakichś preferencji i innych takich. Cała ta ciężka rzecz i tego typu rozwiązania uproszczą tą pracę.

Szymon Warda: Raczej to będzie obszar, który jest piekielnie trudny, bo mówimy o ogromnej ilości danych, którymi te modele są karmione.

Łukasz Kałużny: Tak.

Szymon Warda: A co więcej jeszcze jest obszar - i jedna ważna rzecz, debugowanie. Czemu się zachował tak, a nie inaczej w ogóle. Więc obszar jest szalenie ważny i na pewno będzie uregulowany, bo powinien być.

Łukasz Kałużny: To już powoli się staje tam w zależnościach gdzieś tam finansowych i innych, więc.

Szymon Warda: Tak, ale niestety kubeł zimnej wody. Chat GPT-4 tłumaczy Chat-GPT 2. I tu polega problem. De facto. Tu mówimy o… Model obecny tłumaczy model sprzed kilku lat.

Łukasz Kałużny: Wiesz co? Tak, tylko zobaczmy na tempo postępu jak też w open source, jak szybko te modele rozwijają się i inne rzeczy, więc być może teraz rozmawiamy, a po wakacjach będzie to wyglądało, że jest już na to rozwiązanie w tym tempie, jeżeli to idzie.

Szymon Warda: Mam nadzieję, że tak. Wydaje mi się, że do powszechnego użycia ponownie to będzie konieczne. Jestem ciekawy też jak będzie dokładne to tłumaczenie, bo to też wszystko wyjdzie w praniu, daniu, de facto. No i nie ma co się za bardzo napalać, ale już zaczynałeś temat odnośnie rozmowy to jeszcze kolejny wpis. OWASP przygotował draftowy artykuł - Owasp Top Ten dla właśnie dużych modeli językowych, LLMów. I to jest mega ciekawy ruch, bo wcześniej takich rzeczy nie robili. OWASP to oczywiście firma, która słynie z tego OWASP security, czyli najczęstsze problemy, jakie występują w aplikacjach i przed czym się bronić? Oczywiście SQL Injection jest tam zawsze dość wysoko. I tu też właśnie są generalnie błędy odnośnie uczenia, wstrzykiwania. Oczywiście Prompt Injection jest na pierwszym miejscu.

Łukasz Kałużny: Na drugim złe sandboxowanie. Klasyka? Raczej klasyka, którą zrobiliśmy, nie, ale cieszy mnie, że to tak szybko się pojawiło.

Szymon Warda: Ale to tylko pokazuje, jak ważny temat się nagle pojawił i co więcej nie wygląda to na takie zrobione na chybcika i nie wygląda to na rzeczy, które są po prostu robione tak na odwal się. To naprawdę nieźle wygląda.

Łukasz Kałużny: Przy czym to są, widać, patrząc się na wszystko… To są dobrze opisane po prostu problemy, które w ciągu ostatniego roku wyskoczyły. Co możemy spaprać przy integracji takiego modelu?

Szymon Warda: Tak, to jest tak samo jak OWASP Top Ten dla aplikacji. To są takie podstawy, które najczęściej występują. Tak samo to. Nie mówimy o niczym super skomplikowanym. To są najczęstsze problemy, że jak je zaadresujemy to jest OK już tak naprawdę.

Łukasz Kałużny: Wiesz co, ja teraz jestem ciekaw. Powiedzmy, że duża część z nich będzie po stronie integracji kodu musiała się bronić i to jest dla mnie najciekawsze.

Szymon Warda: W ogóle używanie i pisanie modeli… To czekają nas ciekawe lata, bo będziemy uczyli się przeciekawych rzeczy i boję się, że wokół modeli będą rosły całe biblioteki ifów.

Łukasz Kałużny: Niektórzy case’y użyją i switche.

Szymon Warda: Fabrici też będą popularne jak wrócą do łask.

Łukasz Kałużny: Tak, dobra, to zobaczymy, ale tak. Jest to rzecz, która… Jeżeli chcesz patrzeć w integrację jakiegokolwiek modelu w swój flow to popatrz na tego, OWASPa, bo naprawdę warto. Dobra, to co, kończymy.

Szymon Warda: Kończymy.

Łukasz Kałużny: Na razie.

Szymon Warda: Na razie.

Łukasz Kałużny: Hej.