W najnowszym odcinku podcastu gościmy Michała Wilczyńskiego – Architekt i Tech Lead (Pragmatic i EcoVadis), a także współtwórca inicjatywy DevMentors. Michał, z bogatym doświadczeniem od service desku po tworzenie oprogramowania do cyberbezpieczeństwa, dzieli się swoimi spostrzeżeniami na temat poziomu świadomości bezpieczeństwa w IT wśród programistów. Porusza temat DevSecOps i podejścia shift-left, podkreślając, że choć wielu deweloperów ma podstawową wiedzę o uwierzytelnianiu i autoryzacji, to brakuje głębszego zrozumienia ryzyka i holistycznego podejścia do bezpieczeństwa aplikacji. Dyskusja skupia się na potrzebie zmiany mentalności z „młotka, który wbija gwoździe” na inżyniera, który kwestionuje i rozumie proces biznesowy.

Odcinek podkreśla, że bezpieczeństwo to wspólna odpowiedzialność, a nie tylko domena wyspecjalizowanych zespołów.

Poruszane wątki:

• Wspólna odpowiedzialność i empatia w zespołach IT: Podkreślono, że każdy członek zespołu, w tym programiści, powinien czuć się odpowiedzialny za bezpieczeństwo, a empatia w relacjach między deweloperami a specjalistami ds. bezpieczeństwa (tzw. „bezpiecznikami”) jest kluczowa dla efektywnej współpracy i zrozumienia ryzyk.
• Konieczność holistycznego podejścia do bezpieczeństwa aplikacji: Zamiast polegać wyłącznie na automatycznych narzędziach i checklistach, deweloperzy powinni rozumieć przepływ danych, identyfikować potencjalne zagrożenia i kwestionować, czy dane są przechowywane w sposób bezpieczny i zgodny z regulacjami, takimi jak GDPR.
• Znaczenie ciągłego rozwoju i elastyczności w obliczu zmian w IT: Wskazano, że w dobie sztucznej inteligencji i dynamicznie zmieniającego się krajobrazu technologicznego, programiści muszą być elastyczni, poszerzać swoje kompetencje poza samo kodowanie i aktywnie dążyć do zrozumienia szerszego kontekstu biznesowego i niefunkcjonalnych wymagań oprogramowania.

Odcinek dostępny na YouTube, Spotify, Apple Podcasts i innych platformach.

Transkrypcja

Andrzej: To co panowie, jesteśmy. Jesteśmy.

Krzysiek: Dobry wieczór.

Andrzej: Właśnie, już wieczór, dziewiętnasta, Jezus Maria.

Michał: U mnie jak w piwnicy, to w sumie.

Andrzej: Jesteś z IT, nie? To przyzwyczajony. Dzień, noc nie oznaczają nic.

Michał: Tak.

Andrzej: Dobra, panowie, zebraliśmy się. Zebraliśmy się i będziemy startować. Mamy dziewiętnastą. Michał, na sam początek, powiedz kim jesteś, skąd się tu wziąłeś, co robisz, przedstaw się.

Michał: Dokąd zmierzam.

Andrzej: Do tego dojdziemy.

Michał: No dobrze, jestem po pierwsze współautorem i współtwórcą w ramach DevMentors, czyli inicjatywy, w której… uczymy, dzielimy się różnymi doświadczeniami, różnymi praktykami, wydajemy też kursy związane z ogólnie szeroko pojętą architekturą i wytwarzaniem oprogramowania. Poza tym jestem tech leadem i architektem w ramach Pragmile i w ramach Ego Vadis, gdzie zajmuję się, co samo w sobie może być ciekawe z punktu widzenia w ogóle tych naszych dzisiejszych dywagacji, wytwarzaniem między innymi również softu, który zajmuje się bezpieczeństwem na jednej z platform. Więc wydaje mi się, że będę miał taką perspektywę w ramach naszej dyskusji, która pokaże z jednej strony trochę taką perspektywę dewelopera, z drugiej perspektywę architekta, ale też trochę twórcy narzędzi związanych z bezpieczeństwem dla innych programistów. A żeby nie było też za prosto, to historycznie pracowałem też w service desku, więc widziałem też tą stronę taką… śmieszniejszą z punktu widzenia, co użytkownicy robią, bo wiecie, jako deweloper często się nie widzi tego, zwłaszcza aplikacji takich enterprise’owych, tego, co tam się do końca dzieje w stu procentach po stronie użytkownika, a jak pracujesz jako service desk, przychodzisz, patrzysz i przecierasz oczami, co właśnie zobaczyłeś przed sobą, co tam użytkownicy robią, więc no, to myślę, że tyle.

Andrzej: No właśnie, Michał, bo ty w samym IT to już jesteś spory kawałek czasu. Powiedz mi, bo w zasadzie nigdy o tym nie rozmawialiśmy, a teraz zahaczyłeś o tego service deska, jak się w ogóle znalazłeś w IT. W sensie, jaka była twoja droga? Taka w, wiesz, TLDR.

Michał: Na sam początek, jeśli chodzi ogólnie o IT, to ja na przykład poza tym, że wiadomo, jakiś tam kompa sobie składałem, potrafiłem coś tam zrobić, coś tam sobie skonfigurować, na przykład jeśli chodzi o programowanie, no to często się słyszy, że programiści to tacy, co tam czytali, wertowali jeszcze Bajtka albo generalnie uczyli, tam w wieku czterech lat usiedli przed jakimś Commodorem, umieli programować. Ja się nauczyłem programować w wieku… 18 czy 19 lat dopiero, więc myślę, że dość późno, jeśli chodzi ogólnie o karierę programistów, tak nawet statystycznie patrząc. A w IT się wziąłem, no właśnie dlatego, że głównie lubiłem sobie siedzieć na kompie, więc w ogóle śmieszna sprawa, bo zacząłem od pracy w Saturnie. Nie wiem, czy kojarzycie się takie sklepy, już nie ma Saturnu, teraz wszędzie są MediaMarkty.

Krzysiek: To był chyba konkurent MediaMarktu kiedyś, a potem jedna spółka, nie?

Michał: Nie, to zawsze była jedna spółka. To trochę działa jak, wiesz, kupujesz różne proszki, różne proszki do prania i to jest wszystko ta sama firma, tam chyba Procter & Gamble, tylko po prostu ten produkt jest targetowany na inną półkę i do innego klienta, więc pracowałem sobie na początku mojej kariery przez, poza tym, że oczywiście byłem zainteresowany gierkami i tak dalej, to pracowałem przez dwa lata takim po prostu na sklepie, sprzedawałem komputery, no i potem uznałem, że w sumie kurczę tam jakieś tam dostałem też zadania takie pomocnicze, żeby utrzymywać jakąś infrastrukturę taką komputerową na sklepie. Więc tak pomyślałem sobie, w sumie to jest fajna, jakaś tam administratorka, to pójdę gdzieś dalej, poszedłem do service desku. W service desku się okazało, że jestem leniwy, żeby niektóre rzeczy robić, więc zacząłem oprogramowywać te rzeczy jakimiś skryptami i tak dalej. No to potem wyszło, że w sumie mi się podoba jakieś tam oprogramowanie różne. Po co sobie poszukałem jakiejś pracy w takim razie jako programista. To były takie w sumie czasy w polskiej branży IT, gdzie faktycznie można było dobrymi chęciami i chęcią jakby wskakiwania na głęboką wodę w różne tematy, no wskoczyć praktycznie chyba w każdą rolę, bo pamiętam też osobę, która ze mną wtedy w service desku pracowała, która została, chcąc chyba zostać sieciowcem, potem została opsem, potem się jeszcze czymś innym zajmowała, więc no… W tamtych czasach faktycznie można było zostać praktycznie wejść w każdą rolę tak naprawdę od poziomu juniora, co dzisiaj jest w sumie nie do pomyślenia, wydaje mi się, względem jakby tych tego 10 czy ponad 10, no paręnaście lat temu. No i co, no i potem sobie w różnych firmach pracowałem, od startupów po takie… może nie hardkorowe, ale takie cięższe korpo, takie typowe korpo. No i obecnie mówię, że to jest moje obecne miejsce współpracy. To jest coś takim pomiędzy późnym startupem a wczesnym korpo. Tak myślę, że można nazwać mniej więcej to.

Andrzej: Okej, to z całym tym doświadczeniem, to moje pierwsze pytanie, które zahacza o temat dzisiejszej rozmowy. Skoro widziałeś różne aspekty w kilku różnych kawałkach IT, a w dużym wycinku programowania, tworzenia oprogramowania, też właśnie z kilku perspektyw. Powiedz mi, jak postrzegasz, nazwijmy to, poziom świadomości bezpieczeństwa tego, co widziałeś. Czy ludzie w ogóle o tym myślą, nie myślą, czy biorą to pod uwagę, czy raczej jest takie, a wiecie, no potem sobie to dodamy, a może nie.

Michał: Wydaje mi się, że to jest dość złożone pytanie, bo taka najprostsza odpowiedź, myślę, że brzmiałaby, że większość programistów coś tam wie, ale traktuje to jako taki dodatek, ale wydaje mi się, że to byłoby zbyt duże spłycenie tematu, bo wydaje mi się, że od co najmniej paru lat widać taki shift, jeśli chodzi o to, jak programiści ogólnie pracują w projektach. Zazwyczaj było tak, że… mieliśmy różne role, które zajmowały się różnymi elementami tego procesu wytwarzania oprogramowania. Byli analitycy, był biznes, był analityk, analityk tłumaczył to, co powiedział, biznes, potem analityk, jakoś to przelewał na jakieś artefakty, UML-ów, czymkolwiek, przekazywał to programiście, jak programista zrozumiał, tak zaimplementował i tak dalej. Jak dodamy jeszcze do tego, że są ops, że są bezpiecznicy i tak dalej, i tak dalej, no to się zaczyna z tego robić niezła taka komedia, bo zaczynamy się zastanawiać, co my właściwie robimy tam w głuchym telefonie już tam na końcu. To tam w ogóle jakaś poczwarka wyszła, więc no i to się od paru lat na szczęście zmienia i wydaje mi się, że ta grupa programistów czy inżynierów programowania, inżynierów programowania, która chce wiedzieć, co się dzieje w procesie biznesowym, to jest często też dokładnie ta sama grupa, która jest zainteresowana zadawaniem trochę bardziej dogłębnych pytań, to znaczy wiesz co, jak to tak robimy, to ja mam pewną wątpliwość, bo już nawet na poziomie takiej logiki biznesowej, jak myślę sobie, jak proces przechodzi, gdzieś się już zapalają lampki. W sensie nie do końca mi pasuje, że na przykład to użytkownik mógłby zrobić, albo co się stanie w przypadku alternatywnego przejścia tego przypadku użycia. Generalnie parę lat temu powiedział, że raczej większość ma jakieś takie świadomość technicznych aspektów, czyli uwierzytelnienia, jakaś tam autoryzacja, że coś tam powinno być. Raczej na poziomie capability, czyli musimy jakiegoś endpointa bronić, ale filtrowanie danych też różnie tam, niektórzy pamiętają, niektórzy nie, więc jak tam ktoś sobie zacznie coś tam po API latać, to powyciąga różne rzeczy, ale to się zmienia, obecnie się zmienia, wydaje mi się, że security jest trochę… dalej na tej osi czasu za samym próbą lepszego zrozumienia tego, co właściwie biznes chce, ale wydaje mi się, że to coraz bardziej się będzie zmieniało, no bo to podejście shift-left z wszystkimi aspektami tak naprawdę się będzie tylko intensyfikować, też biorąc pod uwagę ten nieszczęsny AI, którego jest coraz więcej. Ja akurat się trochę cieszę, bo ja mam akurat tyle tematów, którymi się na co dzień zajmuję, że mi się przyda trochę automatyzacji. Ale niektórzy myślę, że będą trochę czuli powoli ten oddech za plecami, że może warto się zainteresować różnymi innymi aspektami czy wymaganiami niefunkcjonalnymi chociażby oprogramowania, żeby zachować to job security w jakimś stopniu. Jednym z nich na pewno będzie moim zdaniem bezpieczeństwo, ale czy tam jesteśmy teraz. Patrząc po tym, jak jeszcze spora część programistów po prostu bierze jakieś wymagania, nawet w formie jakiegoś, nie wiem, jakbyś dostał kartkę papieru i tam, słuchaj, musimy zrobić XYZ. Dobra, nie zadaję pytań, jakby ja jestem młotkiem, to jest buś, więc wbijam i nara. Więc z bezpieczeństwem jeszcze nawet nie jesteśmy w tym miejscu, w którym zaczynamy kwestionować, wydaje mi się, wiele rzeczy, ale jest już sporo zespołów, z których na przykład też widzę, że my pracujemy w ramach na przykład warsztatów związanych z Domain Driven Design, gdzie widzę, że zaczynają się bardzo podobne dywagacje inżynierów i inżynierów oprogramowania nad tym nie tylko jak to działa, dlaczego tak działa, ale też czy… na pewno robimy to w sposób, który spełnia i też takie techniczne aspekty bezpieczeństwa, a też regulacyjne na przykład, ile rzeczy w ogóle udostępniamy, ile rzeczy przechowujemy na przykład w systemie i tak dalej, więc myślę, że tak to z mojej perspektywy teraz wygląda. Jestem ciekawy w ogóle, jak to się będzie zmieniało, czy to się będzie pogłębiało, czy jednak jest jakiś taki poziom, do którego programiści dojdą, którym jest jakimś takim jakimś takim uśrednionym poziomem zrozumienia, jak to powinno wyglądać i to będzie koniec. Czy jednak będą trochę bardziej to zgłębiać i będą bardziej holistycznie do tego podchodzić. Szczerze na razie nie wiem, bo jesteśmy w bardzo dziwnym miejscu w ogóle jako branża IT teraz i… i myślę, że wszyscy mogą śmiało to potwierdzić, więc ciężko w ogóle cokolwiek teraz przewidywać.

Andrzej: Tak, ogólnie sama branża IT faktycznie znalazła się w nietypowym miejscu, a może nie tyle nietypowym, co po prostu my tego nie pamiętamy, bo ja tam mam jakichś znajomych, którzy jeszcze przeżywali kryzys. Wielki kryzys finansowy z 2008 roku i oni pamiętają czasy IT, gdzie było po prostu trudniej dostać pracę, gdzie tego nie było i gdzie trzeba było się tak mocno trzymać tego, co się po prostu miało. No i krajobraz z mojej perspektywy trochę zaczyna przypominać coś takiego, te opisy. Nie wiem, ja wtedy jeszcze nie miałem okazji pracować, ale to dobrze, bo to bym jako nastolatek pracował. Natomiast to, co powiedziałeś, to mi się od razu przywołało na myśl taką prezentację, wydaje mi się, Wojciecha Seligi z Konfitury 2017 o plantacjach programistów, gdzie on właśnie mówił, że… jeśli chcemy iść dalej jako inżynierowie oprogramowania, programiści, jeżeli chcemy iść dalej, to musimy patrzeć szerzej, musimy patrzeć na to, co robimy, na naszą pracę jako tworzenie produktu, a nie tylko na ten bardzo wąski kawałek wytwarzania kodu, że samo wytwarzanie kodu jest tak naprawdę małym kawałkiem pracy programisty.

Michał: A przynajmniej.

Andrzej: Powinno być, jeśli chcemy mieć w tym karierę, a nie tylko pracę. I oczywiście tam wtedy te aspekty bezpieczeństwa, ale też wszystkie inne takie, jak no właśnie, czego chce ode mnie biznes, też są brane pod uwagę. Ciekawe. Wojciech Seliga, polecam.

Krzysiek: Tak, a wiesz co Michał, mnie zaciekawiło w tym, co powiedziałeś, że ta świadomość jakaś tam jest i powiedziałeś, że nie wiesz, jak bardzo głęboko programiści, deweloperzy powinni wchodzić. A ja troszeczkę to odwrócę. Powiedz, czy może myślisz, że nie powinno być tak, że programisty totalnie nie powinno obchodzić bezpieczeństwo, tylko te zespoły platformowe i to, z czego programiści korzystają, powinno już być bezpieczne by default i ta domyślna ścieżka powinna być zawsze tak ułożona, że programista nie ma prawie szansy popełnić błędu, który skutkowałby jakąś podatnością. No bo dużo się teraz mówi o platform engineeringu, budowaniu platformy i potem oddawaniu jej w ręce deweloperów, którzy po prostu tylko z tych dużych klocków składają to w feature.

Michał: No trudne się wylosowało, trudne. Znaczy to zależy jak definiujemy bezpieczeństwo i na jakich płaszczyznach o bezpieczeństwie rozmawiamy, tak. No bo okej, ja się zgadzam, że z punktu widzenia tego, że im większa organizacja, tym bardziej staramy się budować też jakieś, w ramach jakiegoś zespołu opsowego, jakieś takie szyny, czy jakieś takie właśnie jakieś granice, w jakich poruszać się będą zespoły programistyczne, na przykład jakieś uproszczenie też, jeśli chodzi o tworzenie infrastruktury i tak dalej, gotowe obrazy i tak dalej, jakieś gotowe polityki, jeśli chodzi o ruch sieciowy, reguły bezpieczeństwa i tak dalej, i tak dalej. Okej, tylko to jest jakiś… no nie chcę powiedzieć marginalny wycinek, ale ja bym rzekł, że to jest jedna z prostszych rzeczy, na przykład jak pracujesz w chmurze, no w chmurze jest multum jakiś, może trywializuję, ale jest dużo świstków na przykład w chmurze, które wykrywają ci automatycznie jakieś może złe reguły, może jakieś anomalie i tak dalej. To są rzeczy, które wydaje mi się, że są out of the box, może nie out of the box, ale są dużo prostsze do ogarnięcia, jeśli chodzi o jeśli chodzi o przypilnowanie. Ale z drugiej strony, bo tutaj musielibyśmy trochę jeszcze rozszerzyć to, wydaje mi się, to pytanie, bo dokładnie to samo pytanie można by zadać ogólnie o architekturę oprogramowania, czy o architekturę rozwiązania, prawda. No bo kto jest odpowiedzialny za architekturę rozwiązania? Architekt. Architekt. Architekt. Tak, bo nazwa wskazuje, że architekt. Easy, easy. Tester jest odpowiedzialny za testowania. Tak, o testowania, nie.

Krzysiek: Zaczynam rozumieć, do czego pijesz, że chcesz powiedzieć o wspólnej odpowiedzialności, tak.

Michał: Wiesz co, odpowiedzialność, bo odpowiedzialność to jest w ogóle kolejny krok, tylko mnie bardziej chodzi trochę o to, kto jest kontrybutorem do danego aspektu inżynierii oprogramowania, no bo ja na przykład prowadząc zespoły i tworząc architekturę systemową, nie tworzę jej sam, nie jestem osobą, która rysuje boksy i strzałki między tymi boksami na diagramie. I teraz mówię, słuchajcie, to są boksy i strzałki, jedziemy, nie. Jakby, jak czegoś nie rozumiecie, to pytajcie. Mówię, stary, ale tu są tylko jakieś kwadraty i strzałki, jakby co mam zrobić. Więc… i no śmiejecie się, ale jeszcze tam z pięć czy dziesięć lat temu to bardzo często tak było, że oczywiście trywializuję, tak jakby ten UML jest bogatą na przykład notacją, z której często się korzysta, jest tam pierdyliard różnych, różnych diagramów, typów diagramów, które można zareprezentować.

Andrzej: Pozdrawiamy, pozdrawiamy pana Jarka. Pozdrawiamy dla kumatych.

Michał: To jest dziwne, że ja odgadłem, o kogo chodzi. To jest dziwne, czy nie?

Andrzej: No jesteś, jesteś po prostu kumaty.

Krzysiek: Po prostu jesteś kumatym architektem.

Michał: No i teraz pytanie, bo jeżeli ja jestem jedyną osobą, która jest odpowiedzialna za architekturę rozwiązania i potem sobie, no bo to jest ten sam problem co z analitykiem i z tym głuchym telefonem, nie. Jeżeli ja narysuję te strzałki, te strzałki i kwadraty i dam to do zespołu, no to zespół pewnie, jeżeli to jest zgodnie z jakąś sztuką, z jakąś notacją zorganizowane, no to weźmie i to przeleje na kod z jakimś szczątkowym zrozumieniem domeny dziedziny problemowej, którą się zajmujemy. No tylko chyba nie o to chodzi, no bo jeżeli, znaczy inaczej, jeżeli zamkniemy się w takim podejściu, to faktycznie, jeżeli byśmy przenieśli to z powrotem na kanwę bezpieczeństwa, to ci ludzie nie za bardzo poza jakimiś aspektami takim stricte w kodziku, gdzie są z większości rozwiązane problemy przez jakieś frameworki i tak dalej, oni powiedzą, że ja jestem kryty, tak. Czy ja jestem kryty, tak. No bo tutaj framework wszystko ogarnia, a wszystko inny dostęp od architekta, tak. On tak narysował strzałki pomiędzy różnymi tymi, zdefiniował, jak endpointy mają wyglądać, jak komunikacja ma wyglądać, więc ja tylko jestem jakby tą osobą, która przelewa to, co jest na papierze, na kod i tyle. Więc w takim podejściu faktycznie programista nie powinien się tym zajmować, no bo nie ma jakby dostępu w ogóle do dyskusji, którą toczymy na temat tego, jak to oprogramowanie wygląda. Z drugiej strony, jeżeli podejdziemy do tego tak, jak moim zdaniem to powinno wyglądać, czy nie mamy Ivory Tower, w którym są święci architekci i tam tylko, wiecie, tam te kamienne, te tablice spadają do programistów, które implementują, tylko rozmawiamy sobie o tym, okej, czyli dostaliśmy takie i takie wymaganie, daj Boże jeszcze z tym biznesem, który tego chce, albo przedstawicielem biznesu. Czyli to tak naprawdę, co próbujemy przekazać ludziom, szkoląc ich z Domain Driven Design. To jest jakiś rocket science tak naprawdę, no bo to jest, my to nazywamy myślenie przed robieniem. Nie jest to jakieś odkrywcze, nie. Fajnie by było pomyśleć, zanim coś zrobimy, nie. I okazuje się to bardzo często czymś, nad czym może nie tyle ludzie nie myślą, do czego nie mają często dostępu. A przez to, że też nie mają trochę jakichś bazowych umiejętności, jak zdobywać tą wiedzę, nie mają też trochę wprawy na przykład w warsztatowaniu różnych tematów, trochę przejściu i zrozumieniu, jak proces działa, no to nie mają szansy trochę oddolnie zmieniać tego podejścia i kontrybuować do tego, żebyśmy coraz bardziej ten shift-left robili. No i tak samo moim zdaniem jest z bezpieczeństwem. Jeżeli ktoś przyjdzie i na koniec ci puści skan na gotowym oprogramowaniu i powie, że no, jest zjebane. Okej. Ale co? No tutaj nie robicie tego, tego. Aha, ale my to robimy od pół roku, to już za tydzień jest wdrożenie, to już nie ma czasu na to. No tak, ale nie możecie tego. Ale ja muszę, bo to jest, wiesz, to jest sprint goal albo coś tam jeszcze innego. Ale nie możecie. No i zaczyna się, wiecie, to też jak pracowaliście w korpo, to wiecie jak to wygląda, że jak tu się ludziki nie dogadają, to trzeba iść wyżej. Jak tu się nie dogadają, to jeszcze wyżej. I tak idziemy w górę, w górę, jakaś w końcu jest eskalacja, która… dobieramy sobie tak naprawdę w skali ryzyka, czy możemy zaryzykować, czy nie, jak możemy, to deployujemy i releaseujemy, jak nie możemy, no to się cofamy i ktoś tam musi jakąś tam w cudzysłowie burę zebrać, no ale do czego. Jakby konkludując, moim zdaniem to trochę zależy od tego, od poziomu dojrzałości, nawet nie organizacji, bo bardzo często, jeżeli zespoły są bardzo dojrzałe, to są w stanie wypracować sobie taką autonomię, ale i odpowiedzialność, tak, no bo tak jak w sumie odbiłem trochę tą piłeczkę Krzyśka, teraz wracam do niej, że no to jest jakby z jednej strony mamy, jeżeli zespół dostaje autonomię i wypracuje, albo sobie wypracuje tę autonomię, no to z drugiej strony będzie mi też odpowiedzialność, tak. I dopiero wtedy moim zdaniem zespół jest w stanie dużo szerzej odpowiadać za bezpieczeństwo tego, co buduje, versus kiedy jest po prostu podwykonawcą tak naprawdę, no innej części swojej organizacji, ale jest podwykonawcą, tak. Trochę to, o czym też powiedziałeś, Andrzej, to się chyba nazywa… nie feature factory, w ogóle jest taka skala chyba dojrzałości zespołów, gdzie są na samym końcu chyba są zespoły produktowe, wcześniej jest feature factory i wcześniej jest chyba coś podobnego, gdzie tak naprawdę właśnie z gotowych klocków my jesteśmy tylko tymi, tylko fabryka się zmieniła, ale deweloper to biorą tam tylko i tam obraca tą żarówkę, dobra, zła, nie wkręca, tam coś tam przywija i tak dalej. I to jest gdzieś tam na środku dojrzałości zespołu deweloperskich, a na samym końcu jest zespół produktowy, który jest właścicielem wewnętrznego lub customer facing jakiegoś produktu i stara się być odpowiedzialny jak za najszerszy wachlarz różnych cech tego produktu. Jedną z nich jest bezpieczeństwo, dbałość o dane, odporność na błędy itd. To mega zależy od zespołu, też trochę od organizacji, bo to trochę zależy czy organizacja pozwala, żeby te zespoły mogły w takim… w trybie funkcjonować lub nie. Niektóre nie pozwalają, niektóre zakładają kajdany i robimy tylko tak i tylko tak.

Krzysiek: Tak, no i też czy organizacja promuje takie podejście, w którym deweloperzy i zespoły działają w takim trybie rzemieślniczym, tak? Czy jesteś tylko tym po prostu budowlańcem z łopatą, który przerzuca z jednej kupki na drugą, nie? No bo jednak dbanie o różne aspekty jakości, zarówno te funkcjonalne, jak i w szczególności niefunkcjonalne, jeżeli mówimy o bezpieczeństwie, no to jednak jest jakiś przejaw, jakby nie patrzeć, rzemieślnictwa, tego craftmanshipu.

Andrzej: Ja chcę jeszcze dodać, mi się bardzo spodobało, że wspomniałeś o tej odpowiedzialności i o tym, że można zacząć działać tak naprawdę nawet na poziomie lokalnym, oddolnie i nie trzeba czekać, aż organizacja się zmieni. Oczywiście nie w każdej organizacji są takie, które są bardziej sztywne, ale wtedy zawsze my możemy zmienić nasze warunki i przejść do innej organizacji. Natomiast ja czasami spotykam się z taką, nazwijmy to… frustracją wśród osób, które są jeszcze na poziomie gdzieś tam operacyjnym. I ta frustracja idzie w kierunku takim, no fajnie, że coś tam chciałbym na przykład testować, bo się czegoś tam nauczyłem, albo chciałbym modelować zagrożenia, ale u mnie się nie da. U mnie się nie da, bo to, bo tamto, bo pięć innych rzeczy. Zawsze się da, bo w naj… w gorszym wydaniu można robić to po prostu samemu. W kolejnych krokach można rozszerzać to przede wszystkim na swój zespół, działać lokalnie, zmieniać oddolnie. A jeśli się faktycznie nie da, jeśli próbujemy i to nie idzie, no to trzeba pomyśleć gdzieś tam o zmianach. Natomiast przestrzegam i… przestrzegam, żeby się tutaj nie poddawać, tylko po prostu podchodzić do tego z optymizmem. Każda zmiana zawsze będzie wymagała trochę pracy, no bo… no bo zmiana wymaga po prostu pracy, która jest niemiła.

Michał: To jest bardzo ciekawe, co mówisz, bo dokładnie ten sam problem mamy rozmawiając z ludźmi, kiedy mówimy, zacznijcie zadawać pytania, czemu tak robimy, tak biznesowo, w sensie widzicie, że to nie ma sensu, w sensie to nie jest tak, że wy jesteście ludźmi, którzy rozumieją tylko aspekt technikaliów tego procesu. Jak sobie w głowie układacie te klocki, to nie ma bata, żeby ten człowiek wchodząc w tym miejscu dotarł do punktu wyjścia tutaj w tym procesie, jakby to się nie spina w ogóle, no widzicie, że jakby te klocki nie pasują do siebie, nie. No i musicie, macie dwie opcje, no robicie tak i widzicie, że na pewno to się nie uda, więc zaraz trzeba będzie to poprawiać, więc jakby jak lubicie marnować swój czas, to spoko, ale spróbujcie zadawać te pytania, no ale nikt z nami warsztatów nie zrobi, no bo zakładam na przykład… nie robiłem nigdy sesji modelowania zagrożeń, od razu mówię, ale zakładam, że to jest, robimy sobie, warsztatujemy sobie jakiś, jak wygląda ogólnie z punktu strategicznego cały proces i szukamy na przykład różnych pewnie jakichś tam aspektów.

Andrzej: Co może pójść źle. Tak. Co może pójść źle.

Michał: Dokładnie. No i teraz, jak można podejść przy takim typowym modelowaniu biznesowym, jeżeli ktoś nam powie, że no nie zrobimy z wami warsztatów, bo wasz stakeholder to jest bardzo drogi, żeby z tym człowiekiem zrobić, jego czas jest cenny i tak dalej. Okej, no to nasza propozycja zazwyczaj jest taka, że dobra, ale na przykład dostajesz jakieś zadanie do zrobienia, albo to zadanie jest w ramach jakiejś większej takiej, może nie historyjki, ale jakiegoś feature’a do zbudowania, no to nic nie stoi na przeszkodzie, żebyście nawet z zespołem, czy ty nawet sam czy sama usiadł i zaczął sobie to rozpisywać w dowolnej notacji, na jakieś tam karteczki w Miro, zrozum co tam się dzieje. Jeżeli zrozumiesz co tam się dzieje, to wtedy po pierwsze, masz wsad merytoryczny, żeby rozmawiać w ogóle z tymi ludźmi i zadawać pytania. Bo jeżeli ty nie masz szansy nawet… zadać samemu sobie pytań, jak ten proces się spina, czy on się w ogóle spina. Potem z zespołem możesz to przegadać i potem się nagle okazuje, że ty jesteś w ogóle partnerem do rozmowy, bo wykonałeś tą pracę, tak. A potem się w ogóle coś śmiesznie się okazuje, że inne zespoły patrzą i pytają, słuchajcie, a jak u was ten proces działa. Wiesz co, tutaj mamy link do Miro, to sobie zobacz. Jak to macie link do Miro. No tu jest wszystko rozpisane i mam też pozaznaczane. Tu nie wiedzieliśmy, co jest. To znaczy, że nie wiemy. To znaczyliśmy, że jest jakieś ryzyko. Nie potrafimy go teraz zaadresować. Zobaczcie sobie, jak to wygląda, więc to jest nasza wiedza na teraz. No i to działa, tu się zaczyna taki trochę, nie wiem, czy mogę nazwać efekt motyla, ale zaczyna to się rozchodzić po organizacji. Od dosłownie jednej osoby da radę. Naprawdę, nie chcę powiedzieć szybko, bo ja nie chcę dawać złudnych też nadziei widzom, że w ciągu tygodnia nagle się okaże, że jak pracujecie praca w podstawach, to nagle wszyscy się dostosowują. Nie, no to jest, nie wiem, rok, jak widać efekty, niestety. Ale naprawdę, to da radę zmienić organizację do takiego stopnia, że organizacja w ogóle zmienia sposób, w jaki zaczyna nowe inicjatywy. Od jednej osoby, czy od dwóch osób. Naprawdę się da. I tu mówię o firmach, które wyceniane są na miliardy euro. Więc naprawdę się da. Tylko trzeba spróbować po prostu.

Andrzej: Dokładnie. Ja tutaj jeszcze dodam, że nie jest tak, że tylko firma na tym skorzysta, ale my sami na tym korzystamy. Przechodząc te procesy, ucząc się, my sami się czegoś nauczymy, my staniemy się lepszymi inżynierami. Więc tak naprawdę to gros wartości jest zbierane przez nas, którą potem będziemy wykorzystywać w dalszej części naszej kariery. Więc tutaj polecam. Polecam, zachęcam i motywuję do działania, i nie zniechęcam się po prostu nastawienie się, że początki zawsze bywają trudne, no bo zmiana bywa trudna. No nikt nie chce się zmieniać. Gdyby zmiana była łatwa, to każdy będzie zmieniał.

Michał: Musi boleć, musi. To znaczy, że jest dobrze.

Andrzej: When it burns, it grows.

Michał: Tak jak mówił Arnold. Chyba, że ręka ci odpadła, to wtedy wiesz. To jest dobry sygnał.

Andrzej: Zerwał się mięsień.

Krzysiek: Tak, mi się przypomina taka mini historia, jako jeszcze QA zainteresowałem się tematem modelowania zagrożeń. I wiecie, wprowadzenie tematu modelowania zagrożeń, czy wprowadzenie tematu event stormingu, który Michał pewnie jest Ci bliższy w małych firmach, to jest katorga, ale… taka praca ze sprintu na sprint z miesiąca na miesiąc faktycznie zaowocowała tym, że tak jak Andrzej mówisz i tutaj też Michał, po roku zaiskrzyło. Ludzie zaczęli widzieć w tym wartość i ilość tych rzeczy, która została zebrana przez ten rok, potem owocowała przez następne kilka lat.

Andrzej: Więc trzeba być tutaj agentem zmiany, tak to się ładnie nazywa. Ostatnio gdzieś to usłyszałem, nie pamiętam gdzie, ale bardzo mi się spodobało. Bądź agentem zmiany. To nawet na plakat się nadaje.

Michał: Kurczę, ale tak jak powiedziałeś o testowaniu, to kurczę, to jest tak szeroki temat, w sensie, bo są dwie grupy, trochę zaczęliśmy o tym rozmawiać, ale są dwie grupy, wydaje mi się, programistów. Właśnie jest ten taki bym to nazwał partyjny beton. Z partią nie ma nic wspólnego, ale charakterystyką bardzo jest zbliżony. To znaczy, co osoby, które… Mamy cały ruch DevOps, który ma ile? Już, nie wiem, 10, 15 lat.

Andrzej: Więcej, więcej, więcej. Od 2009. Nawet wcześniej można.

Michał: O Jezu, bo jest 2025. Jak już takie lata potem tam lecą, to wiecie. Ale jeśli chodzi o taką popularność, to powiedzmy, że tam… Dobra, powiedzmy, że 15 lat, tak. I… znam multum ludzi, którzy się nie chcą w ogóle aspektami infrastruktury zajmować, która jest… Jak nie ma tej bazy, w której te dane zapiszesz… Dobrze byłoby wiedzieć, chociaż jak ona jest skonstruowana. Nie musisz wiedzieć, jak ona jest zdeployowana, jak ona jest utrzymywana, jak są backupy pewnie robione, ale fajnie byłoby wiedzieć, co w tych backupach się zawiera, czy to pełne backupy, czy to są na przody, czy to jest backup logów transakcyjnych, jako przykład. Żebyś wiedział, jak ten mechanizm działa. Trochę takie mechanical sympathy. Ja z testowania mam też bardzo podobną historię, bo w jednym z zespołów pamiętam, że mieliśmy w pewnym momencie nie wiem, czy można powiedzieć, że problem, ale wyzwanie, tak się mówi wyzwanie, bardziej jest korporacyjnie, że przez pewien moment albo nie mieliśmy testera w zespole, albo mieliśmy tylko testera, bo testerkę, która się nie zajmowała testami automatycznymi, a mieliśmy założenie, że mamy też jakimś tam Selenium, czy czymś tam mamy pokrycie też testami end-to-end naszej aplikacji. No i co się okazało? To jest problem nie do rozwiązania. W sensie nie ma testera, który… potrafi pisać testy. Są programiści, którzy potrafią pisać, ale oni nigdy nie pisali testów automatycznych, więc oni nie będą pisać testów, no bo oni są kodzik aplikacyjny, a nie kod testów. No ja tak sobie siedzę i słucham jednej z takich rozmów i mówię, ja nie wierzę, w co słyszę. Po prostu, po prostu nie wierzę, w sensie ja jako osoba, która przechodziła przez pracę w sklepie, tam serwis, desk, tam różne też, różne projekty po drodze, dla mnie to jest jak… Jak słyszę, nowa technologia, no mimo, że Selenium nie jest sexy technologią, mówmy się. Myślę, że Krzysiek przyzna, że tam nie jest to najwspanialsze rozwiązanie do pracy. Jeszcze w jakimś tam SDK, w każdym języku są jakieś smaczki pewnie. W C#owym SDK do Selenium, do WebDrivera.

Krzysiek: Tam praktycznie trzeba było pisać w Javie. Było dla mnie pewnym koszmarem.

Michał: Coś w tym jest. Ja akurat w .NET-cie mieliśmy tam te SDK do WebDrivera Selenium. Dla mnie to było coś takiego, że ja mam inne zadania też w sprincie jako lead i jako też programista, więc mam trochę mniej tego czasu, ale jak widzę, że jest nowa technologia i ona rozwiązuje nam jakiś też problem, bo jeżeli ten test mi opędzi jakiś case, to jest niezerowa szansa, że jeżeli dałem ciała w testach po sobie lokalnie i dałem ciała pisać testy jednostkowe czy integracyjne, no to myślę, że spora szansa, że chociaż pokryją to te testy end-to-end, więc ja sam sobie tak naprawdę robię, brzydko mówiąc dobrze, umiejąc napisać taki test. Nie dlatego, że jestem w stanie testera zastąpić, po prostu nie mam czasu, żeby zastępować tego testera i tak i tak, ale wiem po pierwsze mniej więcej, co się dzieje, po drugie jestem w stanie budować soft w taki sposób, na przykład częsty case z tego, co wiem u programistów testów automatycznych, nie ma żadnych ID-ków i klas, na które się można zaczepić jakimś XPathem w HTML, więc nie da się tego przetestować, trzeba modyfikować aplikację. No to ja już po napisaniu jednego czy dwóch testów jestem w stanie stwierdzić, jak powinien budować aplikację. Z drugiej strony, ja mam też, jako osoba, która ma dużo większe doświadczenie programistyczne, jestem w stanie zobaczyć, jak my te testy w ogóle piszemy. No bo bardzo często było też tak, historycznie przynajmniej z mojego punktu widzenia, że testerzy manualnie wchodzili w testy automatyczne i zaczynali pisać testy w taki sposób, trochę jak teraz byśmy do Chatu GPT wrzucili. W sensie weź mi tam wypluj, wypluj jakiś taki proceduralny kod, tam go wklejamy i w pewnym momencie się da radę go doklejać, nie. Dalej, dalej, ale potem się okazuje, że no, te podejście się skończyło i teraz mamy problem, nie. Ja mogę na przykład przyjść i z drugiej strony trochę pomóc w tym obszarze i powiedzieć, słuchajcie, no ale jakbyście to tak ubrali, jakby to tak wyciągnąć to tutaj i to potem sobie tak jakoś przemyśleć, że możecie tego użyć w różnych miejscach i jakoś to tak uprościć też z tej strony i pokazać na przykład jak, to ja też jestem w stanie wnosić jakość w innych obszarach. Z mojego doświadczenia też w bezpieczeństwie, jeśli chodzi o to, jak procesy na przykład związane z bezpieczeństwem, przynajmniej analizą bezpieczeństwa poszczególnych procesów, czy bardziej projektów, które dostarczamy. Jest też szansa, żeby jako na przykład programista wnieść jakąś, nazwę to jakość do tego procesu. Przez po prostu próbę zrozumienia co się dzieje i powiedzenia na przykład, że słuchajcie, to z punktu widzenia naszego procesu nie ma sensu, po prostu my tak nie robimy, nie. W sensie dokleiliśmy proces tutaj z drugiej strony, nie ma to sensu, więc spróbujmy może zrobić to tak, bo my tak pracujemy i nagle się okazuje, że o, nagle się da, tak. Bo nagle się okazuje, jak gadamy ze sobą, to się okazuje o, czyli wy tak to robicie. To ciekawe, no to spróbujmy może inaczej, może się uda i zazwyczaj się udaje.

Krzysiek: No tak, to prawda. I w ogóle wchodzenie przez programistów w inne role często zaczyna ich trochę uczyć empatii, nie. Tak jak wspomniałeś o pisaniu testów automatycznych i nagle się okazuje, ej, może dodajmy te lokatory, po których potem można łapać się w tych testach. Dlaczego ich nie dodawaliśmy wcześniej? Oni przecież pisali te testy. No i podobnie jest, tak jak mówisz, z bezpieczeństwem, kiedy zaczynają wchodzić w te buty.

Michał: Ja w ogóle uważam, że empatia to jest top, top skill programisty, tak swoją drogą. W sensie to jest robota, która polega na tym, że rozwiążesz problemy innych ludzi, więc jakby myślę, że umiejętność jakby empatyzowania z potrzebami i problemami innych jest całkiem spoko skillem, bo może uda ci się rozwiązać problem, za którego rozwiązanie ci płacą.

Andrzej: Dokładnie i ja chciałbym tutaj zrobić ten nacisk, że to jest skill. To da się wyskillować, upskillować. Nawet jeżeli ktoś ma niski poziom empatii, to da się to upskillować, da się być w tym lepszym, tylko znowu trzeba najpierw to zauważyć, a potem chcieć to polepszyć, a końcowy efekt jest super, bo stajemy się bardziej efektywni w naszej pracy. Więc na koniec dnia, znowu, większość wartości zbieramy my sami, więc to się opłaca każdemu.

Michał: No to prawda, to prawda. No z mojego punktu widzenia to, kurczę, no ja mam nadzieję, naprawdę, nie wiem, czy ja powinienem życzyć tego branży, ale naprawdę życzę, żeby trochę części ludzi się trochę w głowie jednak poukładało z nadejściem różnych narzędzi sztucznej inteligencji, bo tą sztuczną inteligencją można nazywać, to jest temat na inną dyskusję, ale no naprawdę, na razie jesteśmy w takim miejscu, w którym duże organizacje… nie generują kodu na potęgę takimi narzędziami, albo on jest zbyt, albo ma za małe okno, jeśli chodzi o kontekst, albo nie jest już na tyle skuteczny, żeby korzystały z niego duże organizacje, przez też naleciałość różną, jakieś tam legacy, itd. itd., ale jakieś tam startupy, czy mniejsze organizacje już korzystają z tego na potęgę, więc powoli zaczynamy się, branża zaczyna się trochę zmierzać w kierunku, w którym zderzy się z tym, że to, że ja potrafię pisać kodzik, to nie wystarczy, nie. I teraz pytanie, co teraz. No i są dwie opcje. Zaczynam się rozglądać i staram się być osobą, która po prostu w organizacji czy w projekcie jest trochę bardziej elastyczna, potrafię wejść w różne buty i potrafię się rozejrzeć trochę bardziej i pomóc w różnych aspektach. Albo jestem osobą, która jak się zmieni framework javascriptowy albo zmieni się framework backendowy, z którego korzystamy, to ja jestem jakby bez rąk, nie. Nie jestem w stanie nic zrobić. Ale to chyba w sumie, tak jak Andrzej powiedziałeś, jakbyśmy pamiętali jeszcze tamten kryzys finansowy, to myślę, że też ci ludzie, którzy byli elastyczni i potrafili się dostosować do różnych klas problemów, które są do rozwiązania, byli dużo bardziej pożądani niż ludzie, którzy po prostu ja umiem tylko to, ja się zamykam w swojej ramce i w swoich ramach i tylko tym się będę zajmował.

Andrzej: Pełna zgoda. Ja mam pytanie, bo w zasadzie już z całej tej rozmowy nawet na ten moment można wywnioskować, że trochę faktycznie doświadczenia masz, tam nie ściemniałeś, coś chyba faktycznie robiłeś i pracujesz w tym IT od chwilę i nawet potrafisz się rozejrzeć, przeanalizować, przemyśleć temat. Powiedz mi, w takim wypadku od jeden do trzech, od jeden do trzech rzeczy, czego cię nauczyła praca w dużych organizacjach, w większych organizacjach, z większymi zespołami, z mniejszymi zespołami, w kontekście już nawet nie tylko cyberbezpieczeństwa, ale ogólnie takiej jakości, takiej szerszej jakości. To, co po latach, jakbyś wiedział wcześniej, no, to byś był zadowolony. Sam sobie byś powiedział dekady temu, zwróć uwagę na to, na to, na to. No wiadomo, na empatię, ale poza empatią.

Michał: Wiesz co, na przykład w pracy w dużych organizacjach, jeśli chodzi o współpracę pomiędzy zespołami, zakładanie, że zespoły mają, pomimo podobnych stanowisk, mają podobny poziom. Na przestrzeni różnych obszarów. Testowania, bezpieczeństwa, modelowania obszarów, modelowania procesów biznesowych i tak dalej. I to jest w ogóle taka, wydaje mi się, że całkiem niezła rada też dla osób, które wchodzą trochę w buty, na przykład, nie wiem, engineering managera, z którym będziecie rozmawiać już tu za tydzień, gdzie ludzie zakładają, że ten poziom jest bardzo równy pomiędzy zespołami i też ich doświadczenia się przekładają na nowe zespoły, z którymi pracują, co nie jest zupełnie prawdą, więc jeśli chodzi o układanie takich trochę ram współpracy, bo wydaje mi się, że organizacje próbują próbują urównać do jakiejś powiedzmy do najsłabszego zespołu, który jest w tej organizacji i na przykład zakładają różne zabezpieczenia, żeby się nie dało różnych rzeczy zrobić. Zarówno bezpieczeństwa, ale żeby nie dało się na przykład nabić, nie wiem, miliona euro na karcie kredytowej podpiętej do Azure’a i tak dalej, i tak dalej. I teraz ja z jednej strony to rozumiem, z drugiej strony patrząc przez pryzmat innych zespołów, które sobie świetnie radzą i są dojrzałe i którym warto dać autonomię, budujemy trochę takie środowisko pracy, w którym każemy wszystkich za to, że mamy jakąś część ludzi, którzy ja nawet nie chcę powiedzieć, że są niekompetentni, bo to nie o to chodzi. Też często jest tak, że to są ludzie, którzy ciągnęli tą firmę przez 10 lat na przykład jako programiści. Zaczynają od początku i teraz ty patrzysz, wchodzisz w ten kod i mówisz Boże, co za gówno. Taka jest prawda. To jest też super rada ogólnie dla programistów. Jak widzicie jakieś legacy sprzed x lat i patrzycie i mówicie, boże, co za syf, co za głąb to pisał. Poza tym, że to może być sprzed dwóch lat i to ty pisałeś akurat, ale co za syf. A potem się okazuje, że jak zaczynacie sobie zadawać trochę szerzej pytania na temat ogólnie całego tego oprogramowania, po co w ogóle je budowano, w jakich warunkach je budowano i tak dalej. I też dokładnie to samo może dotyczyć, nie wiem, bezpieczeństwa. Ktoś to zrobił tak, że jakbyśmy teraz chcieli rozszerzyć jakieś polityki bezpieczeństwa albo dodać coś tutaj więcej, to się nie da. No okej, no jakby ty teraz to wiesz, tak. Ale 10 lat temu to nie było takie oczywiste, że ta firma zamiast zarabiać 5 milionów euro czy 5 milionów złotych będzie zarabiać teraz 100 milionów, tak. I warto sobie zdać z tego sprawę, że to, co dzisiaj się wydaje głupie albo niepraktyczne, kiedyś było świetnym pomysłem i się sprawdziło. I nadal zarabia pieniądze. Może nie jest rozwijalne, może nie jest rozszerzalne, może trudno się to utrzymuje, może ciężko się to analizuje, ale zazwyczaj te takie najgorsze projekty, które ci się wydaje, to są projekty, które dają pieniądze organizacji. I ludzie o tym zapominają. I to wydaje mi się, że to jest chyba najważniejsza rzecz, którą mnie nauczyła praca z dużymi organizacjami. Może jeszcze jedną, bo to jest coś, co też wychodzi nam często czy na pracy w projektach, ale też na przykład na szkoleniach, również z ludźmi. Jak wygląda więc taki scenariusz naszego szkolenia z Domain Driven Design, gdzie staramy się ludzi uczyć, jak trochę podchodzi do rozwiązywania problemów. Dajemy ludziom sześć czy siedem karteczek z wymaganiami biznesowymi do jakiegoś systemu, który mają zbudować. No i uczymy ich trochę, jak zbierać tę wiedzę, jak budować zrozumienie, jak budować strategię, potem jak mają dalej sobie to zrozumienie całości zbudować, serializować itd. I bardzo często zaskoczeniem ludzi jest, że są jakieś aspekty, których nie było w tych wymaganiach, więc to nie jest coś, o co warto pytać. I w drugą stronę, może nie w drugą stronę, ale rozszerzając trochę to, ludzie zakładają, że biznes zawsze wie, co robi. Że biznes przyjdzie i powie, że to ma być tak. Ja podam przykład, tylko muszę go dobrze zafunkcjonować, żeby… Czekaj, muszę się zastanowić. Dobra. Robiłem jeden projekt w jednej firmie, w której polegał on na… Jak to dobrze ubrać. Polegało to na tym, że czasami gdzieś tam się albo pomyliliśmy na fakturze, albo coś trzeba było zwrócić, albo ktoś coś zwrócił i trzeba było wyrównać coś tam finansowo, no i były jakieś rozliczenia. Jak to bywa w organizacjach, które się z biegiem czasu rozwijają. Do pewnego momentu co wystarczy do takich rozliczeń? No Excel. Jakby klasyka. Excel jakby opędzi wszystko do pewnego momentu. No ale się okazało w pewnym momencie, że trzeba tego Excela przepisać na jakąś aplikację, żeby to było jakby w miarę trochę lepiej dostępne dla ludzi i może bezpieczniejsze niż to, że ktoś tam sobie zmieni formułę i nagle się okaże, że coś nie tak jednak liczymy. No i słuchajcie, okazało się, że jak zaczęliśmy budować tą aplikację, to nie dość, że poza chyba jedną osobą nikt z tego departamentu do końca nie wiedział, jak my to wszystko liczymy w tym Excelu, no to potem się okazało, że jak tą aplikację dowieźliśmy i ona dobrze liczyła, to się okazało, że to jest źle. Bo to nie tak, bo tutaj wyliczycie, a ja tutaj czasami jak trzeba, to jednak tego nie liczę. Mówię, no chwileczkę, jakby to jest reguła, czy to jest widzimisię. Nie, no bo to nie każdy tam, no wiecie, bo to zależy, mówię, no od czego zależy, no bo jest jakaś reguła, która tym steruje, albo nie. No i się potem okazuje, że ta reguła to w sumie nie istnieje, tylko czasami tak było wygodnie, albo coś w tym stylu. No i konkluzja jest taka, że bardzo często biznes albo nie do końca wie, nawet jak ten proces, który mamy cyfryzować albo przerabiać, funkcjonuje. I to jest tak, że my nie możemy zadawać… pytań, dopytywać się, albo nawet challenge’ować, czy to ma sens, czy nie, bo bardzo często, no, tak jak my jesteśmy często zagubieni, jak coś działa, tak samo często ludzie też nie kwestionują też tego statusu quo, o którym przed chwilą sobie rozmawialiśmy. No, tak to działało zawsze, no to tak to robimy, tak. A czy to jest dobrze? To jest inne pytanie, tak. Działa tak, jak działało, a czy działa dobrze? To już trochę co innego. I to jest, myślę, że… tyle się chodzi, nauczyła mnie taka praca z, znaczy, no da, może dużo więcej, ale takich rzeczy, takich, które są aplikowalne do, myślę, że do każdego projektu, czy większego, czy mniejszego, to są takie rzeczy, które myślę, że będą uniwersalne i myślę, że każdy dochodzi do nich, mam nadzieję, z biegiem czasu, jeżeli nie, to myślę, że warto sobie przemyśleć, zwłaszcza to część z legacy, bo tam może być wiele takich aspektów. Ciekawych do odkrycia, również historycznie, taki można sobie trochę wywiad nawet zrobić, nie chcę nazwać tego OSINT-em, ale można sobie pochodzić trochę i zobaczyć, jaka była trochę jak, do czego by to przyrównać, do słoju w drzewie, albo jakieś tam skały się znajduje, nie jakieś tam warstwy. No można sobie też przejść po kodzie i zobaczyć, czyli w tym punkcie w czasie coś się wydarzyło, w którym nalepiliśmy straszny syf, który został. No ale jesteśmy tutaj, czyli znaczy, że jednak było bardziej in plus niż in minus. W ogóle ciekawe, że to tak można mówić sobie o programowaniu, jak trochę o archeologii. Podniesiesz kamień, jest ten dinozaur, a czasami jest… kolejny śmieć po prostu.

Krzysiek: No właśnie Michał, a jak taki dobry archeolog wchodząc do takiego legacy projektu, to powiedz, masz może jakąś checklistę, która gdzieś zahacza w jakimś rozdziale o bezpieczeństwo. Czy w ogóle posługujesz się takimi narzędziami jak checklisty, wchodząc do projektu.

Michał: Wiesz co, w poprzedniej organizacji jak pracowałem, to w ogóle mieliśmy, jeśli chodzi o projekt, mieliśmy cały taki handoff, w którym był opis i architektury, mieliśmy też wszystkie wymagania jakieś takie niefunkcjonalne, storage, compute i checklistę całą, związaną z bezpieczeństwem. Nie będę wchodził w szczegóły, bo też nie powinienem się, wiadomo, za bardzo tym dzielić, ale generalnie były pytania od tego, czy coś jest zgodne z OWASP-em, po to, czy jak przechowujemy dane i tak dalej, i tak dalej, tam nie wiem, nie pamiętam, ile było stron. Jak strzelasz z 10 A4, to myślę, że nie będzie, mogę trochę przesadzić, a mogę trochę niedoszacować. No i to moim zdaniem jest coś, co… jest kompletnie bezskuteczne, w sensie nic nie daje, w sensie po pierwsze wypełnia to jedna osoba w zespole, jakiś lead albo architekt, po drugie za pierwszym razem pewnie zrobi to, pewnie to zrobi w miarę tak dogłębnie, potem to już będzie takie, no dobra, to ja sobie wezmę z tego Excela, przekopiuję do tego Excela i będzie git, jakby jak przyjdzie audyt, co oni tam wiedzą, przecież nie zajrzą do tego, audyt ma tam dwa tygodnie, to co tam każdej aplikacji nie sprawdzi, nie. Oczywiście żartuję, no ale wiecie jak to jest, nie. Jakby jak się wysyła komuś stertę papierów do wypełnienia, no to jest jakiś punkt odcięcia, w którym ktoś mówi stop, chwila, jakby ja mam skończoną ilość czasu, którą mogę poświęcić na to i to musi być też trochę dostosowane do tego, jak ja funkcjonuję. No z drugiej strony, no są takie rzeczy, które może nie są częścią takiej checklisty gdzieś spisane, ale są częścią rzeczy, na które ja w ogóle zwracam uwagę, jeśli chodzi o myślenie o procesie biznesowym, no bo checklista trochę brzmi jak skończyłem robić, to sobie przejdę. Ja tak patrzę na checklistę, tak. Czy o wszystkim pomyślałem, nie. A ja na to bardziej patrzę, na na przykład takie aspekty bezpieczeństwa, bardziej właśnie z punktu widzenia, jak przychodzę sobie przez proces i zastanawiam się, okej, kim jest ten człowiek. Kim jest w ogóle, jaki to jest archetyp, jakaś persona, która uczestniczy w tym procesie. To po pierwsze. Po drugie, jaki jest przepływ tych informacji, które, w ogóle. Jak zacząłem sobie o tym myśleć, to dopiero dzisiaj sobie przeczytałem, na czym polega to modelowanie zagrożeń. I wyszło, że robię w jakimś stopniu modelowanie zagrożeń przy okazji. Dokładnie tak. I może sobie to wymyśliłem, jak to ma funkcjonować. Może to cała jest, cała ta idea jest, na tym polega, żeby to też nie było jakiś niewiadomo jaki rocket science. Więc myślę sobie o procesie, my też myślę, jakie informacje tam przepływają. Jakie informacje musimy przechowywać. Czy my na pewno potrzebujemy tej informacji. No bo oczywiście jest aspekt bezpieczeństwa, to znaczy co jeżeli coś tam szambo wybije i te informacje będą dostępne na zewnątrz, ale z drugiej strony jest też aspekt taki typowo inżynierski, architektoniczny, jeżeli to są dane, które nie do końca pochodzą, źródłem prawdy jest mój obszar, tylko inny obszar na przykład w organizacji, albo w ogóle jakieś third party. To w jaki sposób ja te dane będę też synchronizował, albo nie wiem, mamy GDPR, dane osobowe, jakie będę anonimizował, jak ktoś powie, że ja już nie chcę, żebyście przechowywali moje dane w systemie. I programiści w ogóle mają tendencję do przechowywania nadmiarowo danych, bo się przydadzą i ja to rozumiem, bo bardzo często też są jako taki reference point, co się wydarzyło i bardzo często nie ma innych narzędzi, które mogłyby im pomóc, więc korzystają sobie z tego, co sami nalepili. No ale z drugiej strony, no to wiadomo, wiąże się z różnymi aspektami bezpieczeństwa, które mogą gdzieś tam nas w tyłek ugryźć. No ale też takie rzeczy typu, no takie podstawy od tego, kto będzie mógł w ogóle dostać się do tej funkcjonalności, jak te w ogóle, czy te informacje, zazwyczaj w większych organizacjach raczej mówimy o podejściu multi-tenant, tak, czyli mamy albo to pokrojone na różne grupy tenantów, albo pojedynczych tenantów, ale zazwyczaj jest tak, że mamy po prostu w jednej bazie mamy dane wszystkich klientów, tak. W jaki sposób musimy te dane też, w jaki sposób te dane odfiltrować tak, żeby funkcjonować tylko na jakimś podzbiorze, który dotyczy tego konkretnego klienta. Wydaje się być oczywiste, ale bardzo często z punktu widzenia technicznego nie jest. W sensie, nie wiem, kurczę, dyskusje, które w ostatnich tygodniach miałem też z różnymi programistami, zadając takie podstawowe pytania, no tak, sprawdzamy, czy ktoś tam, wiecie, ma jakiś tam, ale jest jakiś atrybut na jakimś kontrolerze i tyle, nie. A co z danymi wewnątrz, no to jakoś tam są filtrowane, ale to tyle. No już powiem jakieś tam aspekty, też często, gdy programiści przychodzą i pytają, czy mogą wykorzystać jakąś bibliotekę. W ogóle teraz temat doszletowy z ostatnich IT news, które nagrywaliśmy. Nagle się okazuje, że połowa stosu, którego ludzie korzystają, jest może nie do śmietnika, no bo ktoś może za niego zapłaci, a nagle się okazuje, że nie potrafię rozwiązać problemu typu, nie wiem, mapowanie obiektu A na obiekt B, albo nie umiem w jakiś… brakuje mi słowa po polsku. Indirekt way nie potrafię wysłać jakiegoś obiektu z punktu A do punktu B w mojej aplikacji, żeby sobie poluzować trochę zależności pomiędzy różnymi funkcjonalnościami. Dużo jest takich rzeczy przez myślenie trochę… To też pytanie, o której warstwie mówimy, bo zazwyczaj na początku projektu to jest bardziej ta warstwa procesowa, czyli z kim mamy do czynienia, jakie informacje potrzebujemy, jaki jest przepływ tej informacji. W architekturze takiej rozproszonej bardzo często też te informacje latają wszędzie, no bo na przykład mamy aplikację, żeby w jakimś stopniu informować inne, znaczy usługi, żeby informować inne usługi o tym, co się zadziało, ewentualnie pozwolić im na to, żeby stworzyły sobie jakąś projekcję informacji, czy jakąś kopię informacji, które te źródło prawdy, czyli moja usługa ma, no nasłuchują na jakieś zdarzenia, które są opublikowane, jakieś RabbitMQ, Service Bus-a, nie wiem, Kafka, whatever. No i teraz zaczyna się zastanawianie, okej, to teraz jeszcze jakie dane tam latają. I w sumie tak sobie teraz myślę, to bardzo rzadko się, często się rozmawia trochę o tej warstwie takiej, która wydaje się być tym publicznym API, czyli o jakimś tam endpointach HTTP, no ale rzadko się rozmawia na przykład o tym, jakie tam sobie eventy latają pomiędzy różnymi usługami, co jest trochę zrozumiałe, bo zazwyczaj to jest ruch wewnętrzny, ale z drugiej strony to rodzi pytania pod tytułem, ja zadałem sobie pytanie, czy dane, które przechowuję są okej. Ale czy ci, którzy nasłuchują i sobie robią też kopię tych danych u siebie, czy oni sobie to pytanie zadali. Nie wiem, ale się domyślam. I szczerze, jeśli ma być szczery, to takie checklisty typowo związane z technicznymi aspektami. Mamy już sporo narzędzi, które zwracają uwagę na różne takie typowe podatności. W ogóle. Notabene moje pierwsze pytanie na Stack Overflow, który już chyba niedługo umrze, to było jakieś pytanie właśnie o… SQL Injection w PHP w ogóle i da się znaleźć, bo go nie usunąłem. I tam pamiętam, że się kłóciłem z jakimś gościem, że można użyć ORM-a, który od razu escape’uje, wszystkie jakieś tam różne dziwne kombinacje, a ja mówiłem, no tak, ale ja sobie jak tam skastuję wszystko do stringa i tak dalej, czy tam używam typów, których się nie da, no to wiadomo, mam początek gdzieś tam kariery, to tam byłem najmądrzejszy z wszystkich, potem wiadomość zaczyna tam. Wiem, że nic nie wiem.

Krzysiek: Ale to było, Michał, twoje pytanie, a pierwszy komentarz to było użyj Doctrine.

Michał: Wiesz co, wtedy to były czasy, w których ja w PHP pisałem, gdzie w HTML po prostu się otwierało tag PHP i coś tam jechałem, więc już nawet nie pamiętam, musiałem teraz wygooglować, akurat zmieniłem kompa, więc nie jestem zalogowany na Stack Overflow, ale da radę znaleźć na moim profilu tą przepychankę, którą tam gdzieś toczyłem. W ogóle też wątek zgubiłem, poszliśmy tak daleko w ten…

Andrzej: To ja mam pytanie. Michał, skoro zgubiłeś wątek, to ja… Właśnie. Tak, właśnie. Tutaj będziemy mieć memory leak. Więc… Michał, wcześniej wspominałeś o empatii. Ja się zgadzam, że empatia jest bardzo ważna. Natomiast… Przy tym temacie ja nie zadałem bardzo ważnego pytania, bo empatia jest ważna, wiadomo, w kierunku wszystkich ludzi, ale ty już w swojej roli na pewno nieraz miałeś przebieżki z bezpiecznikami. Takimi, wiesz, takimi bezpiecznikami, bezpiecznikami, co są w osobnym dziale i tam dbają o bezpieczeństwo. Powiedz mi, jak wygląda wtedy taka twoja relacja, swoich doświadczeń. Czy wspominasz je dobrze? Czy faktycznie wykazujesz się wtedy empatią? Czy może jednak…

Michał: Znaczy, oni się wykazują empatią. Wiecie co, bo to jest tak, trzeba sobie zadać bardzo ważne pytanie, czy jesteśmy w trakcie audytu, czy nie. Jeżeli jesteśmy w trakcie audytu, to raczej nie da się za bardzo podyskutować, pośmieszkować i tak dalej, bo sytuacja jest bardzo poważna, ale co do zasady, kurczę, no z mojego doświadczenia pracując z… z różnymi ludźmi, również z różnymi bezpiecznikami, od osób, które powierzchownie, można by było powiedzieć, że są bucami, bo mówią, to nie, tutaj tego nie możesz, tam to musi być zablokowane i tak dalej. Jak zaczynasz się zastanawiać, zaczynasz obserwować też rzeczywistość, która ich otacza i odpowiedzialność, która na nich ciąży, no to dochodzisz do wniosku, że… kurczę, jakbym tak patrzył na ogół naszej organizacji, to by zrobił to samo, co oni, a zablokował tutaj dostęp do wszystkiego, jak coś trzeba tam przekopiować, to musi być serwer siatkowy w ogóle, żeby się nie dało czegoś zrobić. Tutaj bym w ogóle wyciął ruch części ludzi, bo wysycają sieć oglądając YouTube’a, a tutaj bym zrobił jeszcze coś innego, bo tak naprawdę im nie ufam, więc kurczę, no wracamy cały czas do tej empatii, ale ja mam wrażenie, że jak ludzie trochę wychylą nos poza swój ogródek i zaczną się zastanawiać, jak to wygląda z tej drugiej strony. No bo to też nie jest tak, że gość przychodzi mi wręcza Excela z listą rzeczy do oczekiwania. No przecież to jest ostatnia rzecz, o której taki bezpiecznik myśli, że ja sobie przygotuję teraz Excela, przejdę sobie do Michałka i Michałek mi teraz wypełni 40 pytań, których pewnie nie przeczytam, tylko podam dalej po prostu, bo nie mam też czasu zapoznać, czy on napisał prawdę, czy nie. No taka jest prawda, nie. No panowie, no to będzie z prawdą teraz. Czy na pewno Angular w wersji 7 jest odporny na XSS? Chłopie, nie wiem, no jak w dokumentacji jest, to jest, ja tego nie sprawdzam, ty też tego nie sprawdzisz, nie. Więc, no były jakieś tam sytuacje, że na przykład, nie wiem, pamiętam, że, o Jezu, taka dość śmieszna historia, znaczy śmieszna, nie wiem, czy śmieszna, dla kogo śmieszna, dla tego śmieszna. Okazuje się, że jedyna chyba certyfikowana wtedy biblioteka do OIDC, czyli OpenID Connect, napisana w JavaScript, czyli dla tej strony… czyli dla tej strony ogólnie client-side, nie server-side, czyli nie dla Node.js-a, tylko dla jakichś tam Reactów, Angularów i tak dalej, jako funkcję kryptograficzną używała jakiejś biblioteki do kopania kryptowalut. No tam mieli najlepiej napisane, bo była jakby najefektywniejsza, żeby jakby, no tam najlepiej zoptymalizowali, no bo jakby kosztowo opłacało się śrubować do jakichś tam milisekund, no bo oni na tym zarabiają, więc no… autor wpadł na genialny pomysł, żeby w tej bibliotece jako zależności mieć bibliotekę, która po prostu w nazwie miała na haśle, bitcoin, coś tam, nie. No i teraz, no panowie, jakby, co się dzieje, jak się analizuje, jak się analizuje skrypty javascriptowe w aplikacji, które wypuszczacie na świat do klientów. Jak pada słowo bitcoin, to od razu wiadomo, tam wszystkie tam, wszystkie tam sygnały odpalamy, bagiety jadą i jadą po nas deweloperów. I o co chodzi, czemu kopiemy bitcoiny, nie? To ty kopiujesz bitcoiny, czy ktoś nas zaatakował, nie? No ale jak tam potem zaczynasz analizować, no to w sumie kurczę, no jakbyś tak analizował sam jako deweloper, tak sobie myślisz, no kurde, widzę, że mam zależność na bitcoina w tych binarkach, czy tam w skryptach, które udostępniamy na świat. Też pewnie bym sobie zadał to pytanie raz, czy dwa, czy ja na pewno potrzebuję bitcoina w tej aplikacji, no ale potem jak się przeanalizujemy, no to faktycznie jest okej. I ja miałem dużo takich, nie chcę powiedzieć przecierek, raczej dyskusji z bezpieczeństwa, bo jak się okazuje, że trochę wiesz o czym mówisz, bo to też jest ważne, to znaczy jeżeli ja zauważyłem, że jeżeli przychodzi, kurczę, to działa, znowuż ta analogia mi przychodzi do głowy, to znaczy przychodzi bezpiecznik do dewelopera i pyta jak to jest zabezpieczone, a deweloper, no przecież framework to ogarnia, o mordo, czego nie rozumiesz, nie. Ale z drugiej strony przychodzi deweloper do, przychodzi deweloper do biznesu i też zadaje w podobnej relacji, tak, zadaje pytania jakieś takie szczegółowe, a biznes mówi, chłopie, jakby, a tak po polsku, bo tak mówisz o jakichś tam tabelkach, o jakichś tam feature’ach i tak dalej, nie rozumiem, co w ogóle do mnie mówisz, nie. To jest ten sam trochę problem, nie. I teraz oczywiście gdybyśmy oczekiwali, że biznes się teraz będzie doszkalał z IT, jest to trochę patologią, bo jakby dewelopera głównym zadaniem jest to szkolenie, tak ubieranie tej dyskusji, żeby ten stakeholder był w stanie zrozumieć o co faktycznie pytamy i był w stanie przekazać mi te informacje, które potrzebuję, żeby ten problem rozwiązać. Z drugiej strony, jeżeli deweloper jest tą osobą centralną trochę z punktu widzenia dostarczania programowania, to trochę kurczę nie ma wyjścia, no musi być osobą, która jest w stanie nawiązać tą dyskusję z bezpiecznikiem. W drugą stronę, wydaje mi się, że mamy też, z mojego doświadczenia też wynikało, że jak zacząłem się z tymi ludźmi dogadywać i pokazałem, że faktycznie nie wiem o czym mówię, no to ci ludzie też zaczynali trochę po pierwsze schodzić z tonu, po drugie zaczynali też, co jest w ogóle ciekawe, zaczynali mówić w trochę bardziej lakoniczny sposób. Zakładając, że ja rozumiem o co chodzi, więc oni nie muszą mówić wszystkiego wprost, tak. Nie muszą jakby, bo jak ktoś powie, a bo mi bezpieczniki nie powiedziały, że powiem na to i na to zwrócić uwagę, to ja tego nie zrobiłem, nie. To jest trochę jak w przedszkolu, nie. To jest jeszcze jedna rzecz, którą mnie nauczyły duże organizacje. Wbrew pozorom, bardzo często jest tak, że im więcej ludzi, im bardziej rozmyta odpowiedzialność, tym bardziej zaczynamy się bawić w jakiś… No może nie przedszkole, bo przedszkole to jest akurat krzywdzące dla przedszkola, bardziej gimnazjum. Gimnazjum już nie ma, ale kojarzycie jak to wygląda. Ja nie wiem, ja nie wiem, to jest nie moje. Jakby ja się nie interesuję, bo to jest już ten, ja tego nie dotykam, to jest tamtych odpowiedzialność. Mi nikt tego nie powiedział, więc ja tego nie zrobiłem, skąd miałem wiedzieć. Kurczę, to jest śmieszne, ale to tak wygląda, nie. I wydaje mi się, że jeśli chodzi o… prace wewnątrz IT, różnych departamentów, tak sobie to nazwijmy, chociaż to też jest coś, co będzie się pewnie zacierało z czasem, to kurczę, no to wydaje mi się, że to jest po obu stronach jednak coś, nad czym trzeba popracować. To znaczy znalezienie trochę tego języka pośrodku, w którym nie strywializujemy problemu z punktu widzenia bezpieczeństwa, a z drugiej strony nie będzie tak, że trzeba nam tłumaczyć, no chłopie, jakby aplikacja czy ten ludzik. Może tutaj, może nie może. Rozumie, nie rozumie. Więc ja wiem, że ja trochę tak podkoloryzowuję, ale wiecie o co chodzi. W sensie, że gdzieś tam się musimy po środku spotkać. Z biznesem jest troszeczkę inaczej, ale trochę dlatego, że ten biznes płaci nam, żebyśmy rozwiązywali te problemy. A bezpieczniki nie płacą mi, żebym zabezpieczył aplikację, ale bagiety przyjadą, jak się okaże, że nie jestem zabezpieczona.

Andrzej: Dokładnie tak i jeszcze często się czepiają, ale ja mam bardzo podobne doświadczenia z dużych organizacji, gdzie im większa, tym bardziej jest rozmyta odpowiedzialność, a im bardziej rozmyta jest odpowiedzialność. No tym bardziej zaczyna się po prostu spychologia, to nie moje, to tam nie, to ja nie wiem, ja nie, to nie, to w ogóle. Co ty tu robisz? No ja robię tylko ten mały kawałek i tyle.

Krzysiek: I zobaczcie, że wszyscy mówią, ej, ale my wszyscy robimy DevOps, a tak naprawdę nikt nie robi DevOps, bo te silosy jeszcze bardziej się od siebie oddalają, nie. To jest nie moje, to jest twoje, to jest tamtych.

Michał: Exactly.

Andrzej: I zamiast wszyscy właśnie grać do tej jednej bramki i też przez co po prostu się lepiej żyje, lepiej pracuje, przyjemniej się wtedy chodzi do pracy i wykonuje swoją pracę, bo się widzi większy sens tego wszystkiego, no to jest właśnie takie okopywanie się. I nie, nie, to nie, nie, ja nie chcę tej odpowiedzialności, proszę, proszę, weź ją ode mnie. Michał, będziemy dobijać powoli do brzegu, bo minęła 20, nie chcę zabierać za bardzo twojego czasu, ale mamy pewne pytania, które padły na czacie, więc zaczniemy je zadawać i na nie odpowiadać. Ja pierwsze pytanie, jakie tutaj widzę akurat, to pytanie Kamila, więc je przeczytam. I proszę się ustosunkować, proszę Państwa. Jeśli aplikacja jest on-premowa i jest wystawiona w sieci lokalnej, to nie rola devów, aby dbać o bezpieczeństwo w kodzie aplikacji. I często się Kamil spotyka właśnie z takim tłumaczeniem. Co o tym sądzisz, Michale? A potem ja się.

Michał: Pierwsze pytanie, o jakim aspekcie bezpieczeństwa mówimy, no bo jeśli chodzi o jakieś, nie wiem, takie już ciężkie rozwiązania typu WAF-y i tak dalej, które jakieś tam ogólnie na poziomie infrastrukturalnym, no to w pewnym stopniu się zgadzam, ale gdyby to był cloud albo cokolwiek innego, też by tak było, że raczej jest osoba, która ok, no w mniejszych może zespołach są, można powiedzieć, że to jest wirtualny ops, którym jest, po prostu są gotowe rozwiązania w Azure, w AWSie i tak dalej, więc moim zdaniem rola jest ta sama. No ale jak się zastanowimy, no to aplikacje, ktoś z tej aplikacji korzysta, tak. Jeżeli to są wewnętrzni użytkownicy, no to nadal jest ryzyko, że po pierwsze, nie ten użytkownik, czy nie ten aktor, co trzeba, będzie miał dostęp do tej aplikacji. W ogóle najbardziej trywialny aspekt, o którym możemy rozmawiać. Potem dochodzi aspekt tego, że ten gość, czy ta pani, która ma dostęp do tej aplikacji, z jakiegoś powodu kliknęła w jakiś obrazek z śmiesznymi pieskami w mailu, jakiś najprostszy przykład, w którym się okazuje, że dało się coś wykonać na rzecz aplikacji, która miała odpalona w innej zakładce. No i teraz pytanie, co teraz. No bo oczywiście… są organizacje, w których jest pozamykane wszystko na cztery spusty i komputer, który masz podłączony, ma dostęp tylko do czterech aplikacji, które są w intranecie i koniec. Ale ja myślę, że też pandemia to pokazała, że to rozwiązanie się przestało bardzo szybko skalować, bo ludzie byli sparaliżowani, jeśli chodzi o proces jakby po pierwsze decyzyjny, po drugie możliwość działania, więc zaczęło się to poluzowywać. Więc odpowiadając, nie ma bezpośredniego zagrożenia tego, że ktoś uderzył tej aplikacji i będzie próbował coś w niej złamać, ale jest multum sposobów, które można wykorzystać, które ja zresztą kiedyś tam pamiętam, że testowałem, ktoś tak pokazywał, że na przykład wy się lepiej na tym znacie, więc możecie powiedzieć, ale tam był chyba taki case, że gościu jakiś zrobił stronę, w którą można było wejść, który pokazywał, że widzę twój lokalny devserver, który masz na odpalania aplikacji, którą masz na localhostie, bo dało się tak przekierować ruch, że z jakiegoś tam portu 8000 dało się odpytać lokalnie tą aplikację, a dało się dlatego, że na developmencie się wyłącza na przykład jakieś podstawowe rzeczy typu CORS-y i tak dalej, i tak dalej, no bo tak jest wygodniej testować. Moim zdaniem absolutnie jest to aspekt, o którym trzeba myśleć, od tego, kto co może robić, kto ma dostęp do jakichś informacji, po to, że fakt, że aplikacja jest w sieci wewnętrznej, a użytkownicy mają dostęp też do świata zewnętrznego, moim zdaniem oznacza, że trudniej, ale nie jest to niemożliwe, żeby się dostać w jakiś sposób do tej aplikacji, coś w niej zrobić.

Krzysiek: A ja tak.

Andrzej: Tak, ja się w pełni zgadzam i ja najpierw jeszcze przejdę do tej swojej myśli, żeby mi nie uciekła, zaraz oddam Ci głos Krzysztofie. Dla mnie, ja pójdę od drugiej strony, oczywiście w pełni się zgadzam z Tobą Michale, ale pójdę od drugiej strony, żeby uzupełnić argument. I dla mnie tutaj głównym argumentem byłoby to, że inżyniera, który buduje most, albo dom, nie muszę przekonywać, że musi go budować zawsze i wszędzie w sposób bezpieczny, żeby się nie zawalił. I nieważne, czy robi garaż dla mnie, czy nie robi garażu, tylko buduje stumetrowy budynek w centrum Warszawy i w jednym i w drugim pewne bazowe bezpieczeństwo musi zostać zapewnione. I tak samo z budowaniem aplikacji. Pewne bazowe bezpieczeństwo powinno zostać zapewnione, a to jak bardzo chcemy w to wchodzić, czy chcemy na przykład z punktu widzenia organizacji wykonywać testy penetracyjne dla tej aplikacji. Być może nie. Ona może będzie miała taką klasyfikację, że nie musimy mieć wszystkich kontroli. Ale z punktu widzenia dewelopera, czyli z punktu widzenia osoby, która będzie taką aplikację wdrażać, będzie implementować funkcjonalności, uważam, że… No, jest co najmniej dziwne dla mnie, jeśli taka osoba uznaje, że a, to jest aplikacja tylko wewnętrzna, to ja nie muszę jej pisać bezpiecznie. Według mnie jest to pewnego rodzaju malpractice, który mogę zaakceptować, jeśli ktoś jest na początku swojej drogi, zrozumiałe, bo jest wiele piłeczek w powietrzu, którymi musi żonglować, ale w momencie, gdy jest już trochę dalej, jest już regularem czy seniorem, to oczekiwałbym, że nie będzie popełniał bardzo prostych błędów bezpieczeństwa i przykładowo w jego aplikacjach nigdy nie znajdę podstawowego XSS-a. Uważam, że dla seniora jest to nawet takie dość dobre założenie, że nie powinienem być w stanie tego zrobić. A jeśli jestem, no to w jakiś sposób powinienem go pokierować, go lub ją, żeby się po prostu podciągnęli w tym aspekcie. Pewien baseline musi zostać zachowany. Nie wymagam dużo, ale pewne wymagania mam.

Michał: Wiesz co, to analogia jest bardzo ciekawa, jeśli tak powiedziałem, że testy penetracyjne nie mają sensu z punktu widzenia takich wewnętrznych aplikacji, no bo inny przykład dla deweloperów, który myślę, że jest też taki bardzo bliski ich sercu, jeśli chodzi o performance. W sensie… Zależnie od tego, o jakiej klasie aplikacji mówimy, aplikacja musi być w stanie udźwignąć, nie wiem, milion użytkowników na raz albo dziesięciu. Czy to znaczy, że mogę połączyć sobie milion rekordów wyciągnąć na raz z bazy? Pewnie nie, więc w sumie tak jak sobie o tym rozmawiamy, to faktycznie jakby to takie jakieś podstawowe zasady obowiązują wszystkich. I dalej tak naprawdę sobie trochę dokładamy, czy muszę jeszcze na to zwrócić uwagę, czy jeszcze muszę na to zwrócić uwagę. No i tutaj pewnie jakaś tam świadomość by się przydała, nie. W ogóle o czym mówimy, tak. No bo bez świadomości ciężko też sobie zadać to pytanie, bo nie wiem w ogóle jakie pytanie zadać.

Andrzej: Tak, tak, oczywiście. No to jest pierwszy punkt, żeby wiedzieć przynajmniej… to, czego nie wiem i gdzie popatrzeć, żeby się z tego douczyć.

Krzysiek: Czyż mikrofon w twoją rękę. Takie aplikacje on-premowe, które żyją gdzieś tam lokalnie za VPN-em schowane, to taka anegdotka, że na przykład przejście całkowicie z on-prema do chmury potrafi stworzyć taką sytuację i widziałem to dwukrotnie, w której te internalowe aplikacje… przez przypadek zaczęły być dostępne publicznie, więc to, że jakaś aplikacja jest teraz schowana, jest postawiona…

Andrzej: Krzyśka wycięło.

Michał: Chyba tak. Lag jest.

Andrzej: Krzysiek wycięło się. Krzysiek wycięło się.

Krzysiek: Tak, nie wiem, chyba że ona wysyca sieć, niestety.

Michał: Może ogląda też, tylko w 4K. No właśnie.

Krzysiek: A druga kwestia, Michał się zgodzi, że te aplikacje nie żyją w próżni i na przykład jakieś internalowe apki, które służą jako CRM bardzo często gdzieś tam korzystają po tych samych bazach, z których korzystają te aplikacje klienckie wystawione na świat, więc to też nie jest tak, że ta apka on-premowa to jest tak totalnie odcięta.

Michał: Mój ulubiony case to jest pole description, które przyjęliśmy ze świata w aplikacji, która jest customer facing. A renderujemy je też gdzieś na jakimś back-office, który jest w sieci zamkniętej. Ale jak sobie kliknę sobie w jakiś link, albo w ogóle to łącze się tam jakiś wesoły skrypcik przy renderowaniu, a mam dostęp do różnych rzeczy w ramach tego, co tam robi, mam też dostęp do internetu, to się nagle okazuje, że można bardzo ciekawe rzeczy zrobić. I takie rzeczy się zdarzają, więc w takim, tak jak powiedziałeś, gdzie mamy taki system naczyń połączonych, ma trochę mniej znaczenie jakieś tam testy penetracyjne i tak dalej, to co wystawiamy na świat, ale myślenie o wielu aspektach, z którymi się spotykamy i w ogóle też to, jak połączone są ze sobą różne obszary organizacji, jakie dane przepływają, jest tak samo ważne i w takich back-office’owych aplikacjach, jak i tych customer facing, więc myślę, że to problem ten sam.

Andrzej: Dobra. Panowie, mam kolejne pytanie. Jeszcze dokończymy pytania Kamila, potem będzie od Bełkocika, chociaż myślę, że to bez znaków, i od Tomiego. Kamil zadał dodatkowe pytanie, kiedy następuje ten moment, że organizacja decyduje się na testy aplikacji i przykłada większą uwagę do tych tematów. Ja od razu powiem od siebie, bo to jest prosta odpowiedź, po pierwszym dużym incydencie bezpieczeństwa. Wtedy zawsze znajdujesz…

Krzysiek: Tak, albo przed tym, jak… po prostu podchodzą do formalnego audytu i muszą mieć ten pentest.

Michał: Ja nie wiem, bo do mnie przychodzą jakieś papierki wypełnić. Z mojej praktyki faktycznie tak, to zazwyczaj jest moment, w którym się coś większego wydarzyło. To zresztą nie dotyczy tylko pentestów, dotyczy też różnych innych rzeczy, które się mogą wydarzyć z bezpieczeństwem informacji, o których zaczynamy myśleć dopiero w momencie, w którym jest pierwszy backup. I to jest, myślę, że taka dość uniwersalna reguła do pentestów.

Krzysiek: Kiedy testujemy backupy, jak potrzebujemy coś przywrócić? Tak.

Michał: Że nie działają.

Andrzej: Czy działają, czy nie. A do pentestów jeszcze dorzucę, że często jest to po prostu albo właśnie wymóg compliance’owy, czyli musimy… przejść jakiś audyt, przykładowo 27001 lub SOC 2, no i robimy to po to znowu najczęściej, bo firma chce pozyskiwać nowych klientów. No i wtedy… znajdują się fundusze na pentesty, więc raz compliance, a dwa właśnie te incydenty. Jak coś się wydarzy i ma to odpowiednią rangę, odpowiedni koszt dla organizacji, no to wtedy też się pieniądze najczęściej znajdują. I to nie jest przypadek, w tym sensie, że tak powinno być, bo celem biznesu jest zarabianie pieniędzy, więc wiadomo, że bezpieczeństwo… pomimo tego, że fajnie sobie jest mówić, że bezpieczeństwo jest super ważne i jest priorytetem numer jeden, jest to absurdalne to, że przykładowo CEO Microsoftu powie, że bezpieczeństwo jest priorytetem numer jeden. No nie może być, bo priorytetem numer jeden dla Microsoftu jest zarabianie pieniędzy.

Michał: To tak samo jak rozmawiamy sobie o tym, to jest też ciekawa dyskusja, która często ma miejsce, jak zadajemy pytanie, po co piszemy aplikacje, które piszemy. Jaki jest nadrzędny cel tej aplikacji czy procesu, który cyfryzujesz? Są tylko dwa powody. Chcemy zarobić więcej pieniędzy, albo chcemy wydać mniej pieniędzy. Czyli albo poszerzamy naszą sprzedaż, albo optymalizujemy kosztowo. Są jedyne dwa powody, dla których budujemy soft. Koniec. Wszystko inne jest jakby wynikową lub składową tego, co próbujemy osiągnąć. Tyle.

Andrzej: I końcem końców i jedno i drugie prowadzi do po prostu większego zysku. Bo albo ten zysk końcowy powiększymy poprzez mniejszą utylizację zasobów, które mamy, no albo będziemy więcej zasobów zbierać. Więc zysk, więc ciasto urośnie. Proste. I na koniec dnia…

Krzysiek: Słuchajcie, moje życie w IT stało się dużo prostsze, kiedy zmieniłem mój mindset właśnie na to podejście z tego utopijnego.

Andrzej: Tak, tak, tak. To są procesy, do których się to są stage’e, jak denial, ale etc. Potem się w końcu to akceptuje, a na końcu żyje się lepiej. Dobrze. Proszę Państwa, mamy pytanie od Bełkocika. Nie będę dodawał „ły”. Jak zabezpieczyć VPS-a, na którym jest uruchomiony web serwer? Otwarcie portów 80, 443 i 22 do SSH. Co jeszcze? Z mojej strony, proszę pana, trzeba dodać jakiegoś firewalla do tego wszystkiego, dobrze by było, co oczywiście w podstawowych dystrybucjach Linuksa da się zrobić bez większego problemu. I ja bym dodał jeszcze Fail2Ban, czyli w momencie przy odpowiedniej ilości przykładowo logowań do SSH błędnych, żeby nakładał bana na… na IP, które próbowało się logować. Jeżeli popatrzymy sobie na logi z takiego Fail2Ban-a, to dość szybko zobaczymy, że tych prób logowań jest bardzo dużo do jakiegokolwiek VPS-a wystawionego do sieci internet, więc opłaca się to zrobić nawet nie tyle z powodów bezpieczeństwa, bo jeśli mamy mocne hasło albo logujemy się poprzez certyfikaty, to nic nam za bardzo nie grozi. Ale będzie nam wysycało ruch sieciowy niepotrzebnie, bo po prostu te próby są podejmowane cały czas. Więc te dwie porady. Fail2Ban plus firewall. Coś jeszcze macie do dodania?

Krzysiek: Ja bym może przeszedł przez jakąś uproszczoną listę z hardeningu takiego web serwera i takiego VPS-a. Na przykład CIS ma takie listy od hardeningu. Można sobie wybrać tak naprawdę te punkty ważniejsze i krok po kroku mówią, w jaki sposób możemy taką instancję zabezpieczyć.

Andrzej: Ale tutaj polecałbym przemielenie tego CIS-a w GPT, żeby nam dał top 5, top 10, bo CIS-y są…

Michał: Obszerne.

Andrzej: Chociaż for fun zawsze można sobie przeczytać i zobaczyć, co oni tam piszą. Dla ćwiczenia i dla nauki.

Michał: Ja bym się zastanowił jeszcze, bo bardzo często, jak obecnie przynajmniej, jak kupujemy sobie VPS-a, to raczej sobie na przykład stawiamy jakąś formę konteneryzacji, więc zastanowiłbym się też na przykład zakładając, że to jest więcej niż jedna aplikacja, która tam jest wystawiana, co faktycznie musi być wystawione na świat. Pozwolę sobie zadać sobie to pytanie, bo bardzo często jest tak, że stawiamy sobie jakieś rozwiązania, nie wiem, do, już pomijam jakąś tam bazę danych, ale jakieś tam, nie wiem, coś do zarządzania jakąś konfiguracją i tak dalej, i tak dalej. Bardzo często potrzebujemy tylko port 80 na jednej aplikacji webowej, która jest tym naszym oknem na świat, tak, z tego VPS-a, więc tak zdroworozsądkowo spojrzę na to, co sobie stawiam tam i faktycznie co jest potrzebne i co nie, bo można się zaskoczyć. To regularnie chyba różne takie rzeczy odkrywamy, odkrywamy, przynajmniej z Darkiem szukając newsów, gdzie tam nie wiem, co tam mieliśmy ostatnio z takich ciekawostek. W Deep Seeku udostępniali tam chyba jakiś tam publiczny jakiś gotowiec do przeglądania chyba bazy z wszystkimi danymi, które tam były wysyłane, więc takie zdroworozsądkowe przemyślenie po prostu, co mam i co powinno być faktycznie, co faktycznie powinno być publiczne, a co nie.

Andrzej: Czyli zrobić sobie taką mini sesję modelowania zagrożeń.

Michał: Skoro tak mówisz.

Andrzej: Ja tutaj jeszcze dodam, bo pojawiły się porty 80, 443, czyli po prostu tam będzie jakaś web-apka żyła, pomyślałbym nad postawieniem jej za Cloudflare’em. Więc jeśli będziemy tam serwować jakiś content, to serwować go za Cloudflare’em. Zwłaszcza.

Michał: Że skoro powiedziałeś o wysycaniu naszego łącza, no to obecnie to, co robią duże modele językowe i duże firmy stojące za nimi, no to potrafią nabijać ostro rachunki i potrafią DDoSować tak naprawdę nasze aplikacje, więc Cloudflare, z tego co pamiętam, tylko jeden z jedynych ma gotowca, który w miarę działa.

Andrzej: Tak, Labirynt. Tak, tak, tak, wpuszczaj w labirynt i wydaje mi się, że pisał o tym niedawno Gergely Orosz z Pragmatic Engineer. Nie jestem pewien, czy pisał cały artykuł, ale na pewno opisywał wątek na Twitterze i tam całkiem sporo mu podbijały te modele kosztów za infrastrukturę i potem jak postawił je za Cloudflare’em.

Krzysiek: Ja na co dzień pracuję w SaaS-ie i ilość requestów, podglądam sobie na Cloudflare na brzegu sieci, która idzie z botów, bo Cloudflare umożliwia taką opcję, żeby pokazać tylko ruch, który idzie z botów, które on identyfikuje jako znane boty, to to są setki milionów requestów w skali roku, które trzeba by było obsłużyć, gdybyśmy tego Cloudflare’a nie mieli i pozwalali na ten ruch do naszej aplikacji. Tak w pełni.

Andrzej: No, więc to jest koszt. Panowie, jest jeszcze jedno pytanie, ale tutaj nie jestem pewien, czy Michał nam pomoże. Od Toma. Czołem panowie, planuję wejść w CyberSec, nie mam doświadczenia w IT, pracuję w marketingu. Czy polecacie mi zacząć od certyfikatu Network+ czy od razu od Security+? Jakieś ogólne porady na początek? Network+ i Security+ to są CompTIA certyfikaty. Krzysiek, ty zacznij, a ja…

Krzysiek: Nie chcę powiedzieć, jak rasowy konsultant, to zależy, ale muszę od tego zacząć, bo jeżeli chciałbyś wejść w cyber security, to fajnie by było wiedzieć, w jaką domenę cyber security chciałbyś uderzyć. Czy chodzi ci o bezpieczeństwo aplikacji? Czy chodzi ci bardziej o CorpSec? Czy chcesz się dostać do Security Operation Center na linię? Ale jeżeli chodzi o same certyfikaty, to na przykład w moim przypadku nie grały one żadnej roli, bo nie mam żadnego i całkiem dobrze sobie bez nich radzę. Myślę, że większość wiedzy, jestem pewny, że większość wiedzy, którą potrzebujesz na pozycję juniorską, bez problemu znajdziesz w internecie, przynajmniej korzystając z takich serwisów, które… oferują Ci tę wiedzę za 10 dolarów miesięcznie, takich jak na przykład TryHackMe. Tam jest pełno ścieżek, które pozwolą Ci się rozwijać w różnych kierunkach, albo obrać jedną ścieżkę, którą będziesz sobie po prostu potem wiercił i rozwijał się i nie potrzebujesz do tego żadnych certyfikatów, a z przechodzenia takich ścieżek możesz tworzyć artefakty w internecie w postaci artykułów, czy dzielić się nimi na social mediach i wydaje mi się, że to będzie dużo bardziej efektywne, miarodajne niż jakiś papierek z Network+ czy z Security+.

Andrzej: Dokładnie tak. Ja to rozwinę. Tutaj Krzysztof podał TryHackMe, ja również polecam po prostu TryHackMe. Oni mają te takie ścieżki tam wydzielone, paths. Na sam początek, jeśli nawet nie jesteś jeszcze w IT, a myślisz po prostu o cyber security, to przetestuj, czy w ogóle faktycznie cyber security ci się podoba. I to da się zrobić za darmo, trzeba po prostu poświęcić trochę swojego czasu, a na ten moment płatnego upskillowania, bo trzeba też zauważyć, płatne upskillowanie… ma swoje miejsce i potrafi skrócić drogę od A do B, jeśli chcemy ją przejść, ale to nie powinien być początek. Przynajmniej w mojej opinii to nie powinien być początek. Początkiem powinno być zweryfikowanie jak najtańszym, jak najmniejszym kosztem, czyli najczęściej kosztem naszego czasu, to czy faktycznie ten kierunek w ogóle jest… bo może być tak, że wejdziemy w jakiś bootcamp, wejdziemy w jakiś certyfikat, wejdziemy w jakiś kurs, a potem się okaże, że w zasadzie, no dobra, idziemy, wchodzimy na ten szczyt, ale w zasadzie to mi się nie podoba, ten szlak mi się nie podoba, zawracam. Więc najpierw wejdźmy sobie na jakiś kawałek szczytu, zobaczmy, czy faktycznie nam się szlak podoba, a dopiero podejmiemy decyzję po tych godzinie czy dwóch, czy chcemy faktycznie poświęcać kolejne osiem godzin, żeby wejść na szczyt. Czy nie. A te dwie godziny, godzina, dwie, no będzie łatwiej nam się cofnąć, więc te tańsze alternatywy, takie właśnie jak TryHackMe, są tutaj lepsze, a dopiero jak zweryfikujemy, czyli naprawdę, ja bym sobie założył z 90 dni, czyli kwartał, 3 miesiące, pobawił się po godzinach, poświęcił na to swojego czasu. Jakiś weekend. No właśnie. Wiecie, na górę wchodzimy te parę godzin. Tutaj automatycznie ta góra jest dużo wyższa, więc zajmie nam dłużej czasu. Z 90 dni… i dopiero potem podjąć decyzję. Ja oczywiście polecam swój kurs ofensywne testowanie, ale to tylko w wypadku, jeśli ktoś faktycznie chce testować bezpieczeństwo, bo może być tak, że na przykład Tom spodoba Ci się bardziej analizowanie, Security Analyst, i wtedy ścieżki są jeszcze inne, więc w tym etapie, jeśli nawet nie wiesz jeszcze, co konkretnie Ci się podoba, zainwestuj swój czas, zainwestuj swoją uwagę i pobaw się platformą TryHackMe, są tam ścieżki, możesz je przejść, i nie tylko je przechodź, ale też bądź aktywny, czyli rób sobie notatki, najlepiej dziel się tymi notatkami. To nie jest tak, że ktoś będzie je jakoś aktywnie, chętnie czytał, ale ty będziesz korzystał na tym, że będziesz je robić, będziesz je udostępniać, a potem patrząc wstecz, można też na nie komuś je po prostu pokazać. Taki self-work, a dopiero potem ewentualnie szukanie czegoś komercyjnego, bo wiecie, najgorzej jest tak, że wstaję rano, chcę coś zrobić, kupuję kursik, a potem się okazuje tydzień później, że w zasadzie mi się to nie podoba, nie.

Krzysiek: Ja się nie znam.

Michał: Ale się wypowiem jeszcze, bo wydaje mi się, że jest jedna ważna rzecz, którą ja jestem też osobą, która się stara też o jakichś różnych innych rzeczy uczyć, na przykład teraz się muzyki uczę, w ogóle od początku, nie mam w ogóle nawet, nie wiem, z czym są, nie wiem, jakieś interwały, w ogóle nie wiem, który klawisz na piętnie jest. Jeszcze trzy tygodnie temu nie wiedziałem, jak cokolwiek zagrać, co to znaczy i tak dalej, i tak dalej. I wydaje mi się, że warto, żebyś tylko tą zwrócił uwagę na jedną rzecz. Nie pozwól sobie na tak zwane, ja mówię ogólnie, czy o IT, czy o czymkolwiek, w co chcesz wejść. Nie pozwól sobie na analysis paralysis. To znaczy, bo teraz ty sobie wybrałeś już jakieś certyfikaty, które chciałbyś zrobić, spytałeś, czy warto. Teraz chłopaki ci podrzucą jakiś link. Ty go przeczytasz, potem wejdziesz na Reddita, zobaczysz, tam jest komentarz, nie, TryHackMe, to nie, nie, powinieneś zrobić to i to. I ja tak mam, w sensie, od razu mówię, jestem osobą, która wydaje kursy i ma dokładnie to samo, że wchodzę i czytam, kupiłem sobie klawisze jakieś, teraz czytam w necie, nie, te klawisze to słabo, powinieneś sobie kupić jakieś, to już w pełni ważone, 88 klawiszy, nie wiem, gdzie bym je postawił, ale to takie są najlepsze. Minimum budżet 3 tysiące, nie. Wiecie jak to jest, w sensie zgadzam się. Na pewno warto próbować różnych rzeczy jak najniższym kosztem, tylko nie pozwól, żeby ta decyzja była odwlekana kolejną jakąś analizą, szukaniem czegoś i tak dalej, bo nie zaczniesz nigdy. W sensie najlepiej po prostu się skomitować, założyć, że dobra, wchodzę w to, może to nie jest, nie wiem, najlepsze narzędzie, najlepszy tooling, najlepszy kurs, whatever. W najgorszym przypadku dojdziesz do ściany, gdzie coś jest po prostu, jeżeli to jest słabej jakości materiał edukacyjny, to dojdziesz do ściany i zaczniesz sam szukać. Ale już będziesz w tym trybie, w którym próbujesz zrozumieć, o co chodzi i jeżeli próbujesz dociekać, to znaczy, że w jakimś stopniu ci się to podoba, więc i tak będziesz sam pchał do przodu. Więc z mojej strony ogólnie, jako osoby, która i uczy, i uczy innych, i sama się uczy regularnie, to nie pozwolić sobie na to, żeby wpaść w taką pułapkę wiecznego szukania idealnego kursu, idealnych materiałów do nauki, ich po prostu nie ma. Trzeba poświęcić swój czas i trochę też samemu spróbować, czy to jest… to, co chcę robić, ale też to, czy to jest sposób nauki, który mi odpowiada, bo to też może być tak, że po prostu sposób takiej nauki mi odpowiada i tyle.

Andrzej: Panowie, ja mam jeszcze jedno pytanie, w sumie głównie do ciebie, Michał, bo tam padło na czacie, ale nie weszło na shortlistę, ale ja je zauważyłem. Pytanie było, czy jesteśmy Rzymianinami, bo mamy czapki.

Michał: No ja byłem w czapce, więc Andrzej postanowił, że będzie mi towarzyszył, żeby mi smutno nie było. Nie mogę się dogadać z swoim fryzjerem, żeby jakiś termin znalazł, żebym się ostrzygł. A tak uważam, że nie wiem, jakoś tak lubię. Lubię siebie w czapce.

Andrzej: Michała wycina. Teraz Michała.

Krzysiek: No.

Andrzej: Tak, teraz ciebie. Michał, to powiedz mi, ty jesteś po… Ty mieszkasz w Warszawie, czy po drugiej stronie Wisły?

Michał: Jaka podkręcona. To Warszawa po drugiej stronie Wisły.

Andrzej: No to, czyli już poza Warszawą, okej. Ale to, wiesz co, to ja ci podeślę numery do tego, do Barbera, to tam znajdziesz te, na Booksy można się nawet umówić.

Michał: A ja mam dobrego, tylko właśnie dochodzi, że nie mogę się do niego dostać, bo jest właśnie dobry, to jest ten paradoks.

Andrzej: Dobra, dobra, sprawdzisz mojego, do twojego nie pójdziesz.

Krzysiek: To różni są, mówię ci, na pewno u złego byłeś. Różni są, musisz spróbować. Na pewno u złego byłeś.

Andrzej: Różny. Tak, dokładnie. No ale, dobra, panowie, wybiła 20:29, więc jeszcze mamy minutę. Powoli. Rozmowę za twoje doświadczenia. Na pewno musimy to powtórzyć. Ja czekam na zaproszenie do DevMentors. Możecie mnie nawet wziąć do odcinka newsowego, to pośmiejemy.

Michał: W każdym odcinku jest security, więc myślę, że…

Andrzej: To ja będę gościem specjalnym i pokryję ten aspekt i będzie będzie beka over my house.

Krzysiek: I Michał.

Andrzej: Wezmę czateczka.

Krzysiek: Już mój kursor jest rozgrzany. Mam kilka MCP fajnych, odpalonych. Będę brał udział.

Michał: Dobrze zabezpieczonych, jak się domyślam.

Krzysiek: A jak.

Michał: Krzysiek.

Andrzej: Krzysiek. Ty, wiesz co, ty nie instaluj tego kursora i tych serwerów MCP, tylko dokończ na artykuł. Co na to?

Krzysiek: Też po to właśnie potrzebuję te serwery MCP, żeby napisać artykuł.

Andrzej: I’m doing research.

Krzysiek: Dobra, panowie. Miłego wieczoru. Wiem, wiem, żartujemy wszystkim.

Andrzej: Dobra, panowie, dzięki i widzimy się kiedyś w przyszłości.

---