podcast TechChatter odcinek 1

KRZYSZTOF POJASEK: Cześć wszystkim. Nazywam się Krzysztof Pojasek. Jestem senior software inżynierem w Capgemini. Pracuję tu już od 8 lat. Głównie w sektorze finansowym, ale przy okazji trafił mi się też sektor logistyczny. Obecnie zajmuję się technologiami chmurowymi, pisaniem aplikacji na nie i wszystkie poboczne tematy z tym związane. 
MARCEL RZEPKA: Ja jestem Marcel Rzepka. W Capgemini od 5 lat. Tak się trafiło, że w projekcie jestem kolegą Krzyśka. Moje stanowisko to konsultant aplikacji, programista, więc oprócz tego, że razem piszemy aplikacje zdarza mi się też czasami dotknąć tej infrastruktury.  
KRZYSZTOF POJASEK: Dzisiaj chcieliśmy porozmawiać z Marcelem, przybliżyć wam trochę temat, który jest ostatnio popularny. Ogólnie nie tylko w branży IT, ale ogólnie na świecie. Chcieliśmy porozmawiać o realnym problemie, jakim jest efekt cieplarniany. O przyczynach jego i przede wszystkim o tym, jak my, świat IT, my programiści, możemy pomóc środowisku, możemy zwalczyć w pewnym sensie ten efekt. Marcel, czy ty robisz coś dla środowiska? Czy ty jesteś eko?
MARCEL RZEPKA: Tak. No robię to, co mogę. Czyli wyłączam światło, oszczędzam wodę. Staram się nie jeździć samochodem, tylko raczej wybieram pociąg, tramwaj. Takie podstawowe rzeczy.
KRZYSZTOF POJASEK: Okej. A dlaczego w ogóle to robisz? Dlaczego myślisz, że to jest w porządku?
MARCEL RZEPKA: Jestem młodym człowiekiem, tak? Ja mam 25 lat, więc jeszcze planuję na tej planecie trochę pożyć, więc trzeba tworzyć sobie dobre warunki do życia w przyszłości. Trzeba tworzyć dobre warunki dla moich potencjalnych dzieci.
KRZYSZTOF POJASEK: Ale ty uważasz, że ten efekt cieplarniany, to nie jest ściema? Że to nie jest jakiś taki trend tylko po to, żeby, nie wiem, przepchnąć jakieś nowe produkty, czy inne jakieś teorie?
MARCEL RZEPKA: Znaczy wiesz, my jesteśmy ludźmi technicznymi. Wierzymy w naukę, wierzymy w dokumentację. W tej chwili konsensus naukowy jest jasny. Globalne ocieplenie istnieje, więc dla mnie to jest poza wszelką wątpliwością.
KRZYSZTOF POJASEK: Okej. No to ocieplenie istnieje. Patrzymy przez okno i widzimy, że tak jest. Jest coraz cieplej. Zimy są coraz surowsze. Okej, ale to co? To my jesteśmy temu winni, ludzie? Czy to może po prostu proces jest nieunikniony i nieważne, co będziemy robić, to i tak to się będzie działo? 
MARCEL RZEPKA: Szczerze? Dla mnie to nie jest ważne. Wierzę w to, że to ludzie są winni. A nawet, jeśli nie są winni, to możemy offsetować ten stan rzeczy. Możemy wpływać na niego.
KRZYSZTOF POJASEK: Właśnie. Czyli możemy mieć wpływ na niego. To powiem ci, że nie jesteś odosobniony z taką myślą, ponieważ 99,9 procent naukowców ma takie samo zdanie. Po przeszukaniu gdzieś tam większości prac związanych z efektem cieplarnianym zdecydowana większość naukowców potwierdza właśnie tą teorię. Zastanawia mnie tylko, kim jest ta jedna dziesiąta procenta. O czym są te prace. No ale może to pomińmy jako gdzieś błąd druku, czy po prostu chwila…
MARCEL RZEPKA: Błąd pomiaru.
KRZYSZTOF POJASEK: Chwila zaburzenia. No okej, czyli problem jest? Problem istnieje, tak? Wiemy, że my możemy na niego wpłynąć i może powinniśmy coś z tym zrobić.
MARCEL RZEPKA: Wydaje mi się, że najważniejszym elementem tego, oprócz tego, że problem istnieje jest to, że ten problem jest mierzalny. Możemy mierzyć go w różnych wymiarach. Możemy mierzyć to, jak zmienia się średnia temperatur, ale też możemy mierzyć to, jak wpływamy na ten klimat.
KRZYSZTOF POJASEK: Dobra.
MARCEL RZEPKA: Na przykład za pomocą śladu węglowego, nie?
KRZYSZTOF POJASEK: Dokładnie. A co to jest ten ślad węglowy? Możesz wytłumaczyć?
MARCEL RZEPKA: Ten ślad węglowy to jest właśnie taka miara, w jaki sposób wpływamy na klimat, przeliczona na ilość dwutlenku węgla. No bo tak naprawdę wpływamy na klimat freonami, metanem. 
KRZYSZTOF POJASEK: Okej.
MARCEL RZEPKA: Ale to dwutlenek węgla został przyjęty jako ta uniwersalna miara. 
KRZYSZTOF POJASEK: Okej. Mierzyłeś sobie może kiedyś, jaki ty wytwarzasz rocznie ślad węglowy?
MARCEL RZEPKA: Tak. Ale nie pamiętam, co mi wyszło. Wiem, że nie jest tragicznie, ale zawsze może być lepiej.
KRZYSZTOF POJASEK: Prawdopodobnie twój ślad węglowy będzie się mieścił w przedziale pomiędzy 14 a 22 tony dwutlenku węgla rocznie. Ponieważ 14 to jest taka średnia z zeszłego roku dla człowieka, dla mieszkańca ziemi, a 22 to jest już niestety średnia dla przeciętnego Polaka, więc mam nadzieję, że mieścisz się w tych granicach i to bliżej tego człowieka. Ja sobie niedawno zmierzyłem. U mnie wyszło 16, więc jestem bliżej jakby średniego człowieka, ale to i tak wydaje mi się, że jest dużo. I zastanawiające jest to, że 16 ton, to się wydaje, że to jest ogromna ilość, nie? I tak się zacząłem zastanawiać na przykład, co ja robię takiego, czego nie robi przeciętny mieszkaniec ziemi, dlaczego zanieczyszczam to powietrze bardziej, nie? I tak zacząłem się zastanawiać i myślę, nie wiem. Przecież jeżdżę autem tak jak tysiące innych osób, bo widzę przecież w korkach, że wszyscy stoją. Jem te same produkty, co wszyscy inni. Wszystko robię to samo, a jest ten współczynnik większy. I tak zacząłem przeglądać, w jaki sposób wytwarzany jest ten dwutlenek węgla. I okazało się, że nawet podczas codziennej rutynowej czynności, jakim jest research po mediach socjalnych, czyli tam przeglądam sobie, nie wiem, Facebooka, Instagrama, sprawdzę co jest na Twitterze, jakiś krótki film na YouTubie i tak dalej. Przy spędzeniu czasu 5 minut na każdym z tych, dziennie 5 minut na każdym z tych takich portali tych głównych społecznościowych, to czy wiesz, że to jest tyle samo wytworzonego dwutlenku węgla, co przy przejechaniu jednego kilometra samochodem? Mnie tak zszokowało, że jadąc do pracy, rozumiesz?, jadąc o pracy, cztery kilometry mam do pracy, no to jestem w stanie wobec tego po 20 minut na każdym z portali spędzić i to tak jakbym jechał do pracy, nie? 
MARCEL RZEPKA: No.
KRZYSZTOF POJASEK: Szok.
MARCEL RZEPKA: I to dużo łatwiej wytłumaczyć ludziom, żeby jeździli, wiesz, tramwajem, pociągiem, autobusem. Tak jak sam zresztą ci powiedziałem, że ja uważam, że to jest eko, ale nie myślę o tym, ile czasu spędzam w internecie, czy nawet właśnie jadąc tym tramwajem, pociągiem, przeglądam przecież internet, nie?
KRZYSZTOF POJASEK: No właśnie, i teraz pytanie, kwestia do zastanowienia się. Czy ja, jadąc samochodem wytwarzam więcej dwutlenku węgla niż tłum ludzi jadący w autobusie scrollujący tam Facebooka czy inne media społecznościowe, nie? Pytanie, czy jazda tym autobusem jest faktycznie bardziej ekologiczna niż jazda samochodem. Podczas gdy jadąc autem przecież skupiasz się na drodze, nie w telefon, nie?
MARCEL RZEPKA: Myślę, że tak. Wiesz, to jest tak, że jedziesz samochodem, dojeżdżasz do celu szybciej, być może nawet, albo stoisz w korku i nie wiem, słuchasz podcastu. No właśnie, słuchasz podcastu.
KRZYSZTOF POJASEK: Tak jest.
MARCEL RZEPKA: Albo potem, jeśli dojedziesz szybciej do celu, będziesz scrollował te media społecznościowe, więc nie wiem, czy to można tak przeliczać. 
KRZYSZTOF POJASEK: Dlaczego ja w ogóle zahaczyłem się na tym punkcie, jak tak przeglądałem te? Ponieważ pomyślałem sobie, że kurde, to jest to miejsce, w którym my, programiści, czy my, twórcy aplikacji właściwie, bo różnymi rzeczami się zajmujemy, możemy w jakichś sposób zadziałać, nie? Tylko w jaki sposób? Co możemy my zrobić, żeby te aplikacje wytwarzały mniej tego dwutlenku węgla? I pomyślałem sobie, że chyba, dlaczego w ogóle te aplikacje ten dwutlenek węgla generują? No bo pobierają energię. A sprawdziłem, że 30 procent zanieczyszczenia w powietrzu jest generowanych właśnie podczas procesu wytwarzania energii. Czyli przez elektrownie, które te energię produkują. I w związku z tym, tak sobie myślę, że najłatwiejszym dla nas sposobem, żeby poprawić to środowisko byłoby wytwarzać aplikacje, które by ten prąd aż tak nie konsumowały, które by zużywały o wiele mniej prądu. A dlaczego tak? Bo to wiesz, to może się wydawać, no i no? Napiszesz sobie aplikację, która tam w porzo, jedna aplikacje zużyje ci jeden miliwat, czy coś tam mniej prądu rocznie, nie? I co to jest za pomoc, jak ty pisząc ją spalisz więcej tej energii? Ale wyobraź sobie, że na przykład taki Facebook będzie spalał te kilka watów rocznie mniej, nie? I ile jest użytkowników? Ostatnio widziałem, że jest 200 tysięcy czynnych, dziennych czynnych…
MARCEL RZEPKA: Użytkowników.
KRZYSZTOF POJASEK: Użytkowników Facebooka.
MARCEL RZEPKA: I nie mówimy o 5 minutach dziennie prawdopodobnie, tylko raczej o paru godzinach, nie? To jest efekt skali, efekt dużych liczb.
KRZYSZTOF POJASEK: Duża część tych osób właśnie jest też zaangażowanych, jako Facebook to ich praca, nie? Więc oni spędzają, tak jak mówisz, masę czasu nagrywając jakieś czy pisząc jakieś recenzje czy nagrywając jakieś filmy, często wielokrotnie. No i zobacz, i z jednej aplikacji mnożąc to razy 200 tysięcy, jaki to jest impakt, nie? I to wszystko uruchamia tą twoją aplikację, którą ty napisałeś, za której stworzenie ty jesteś odpowiedzialny, nie? Aplikację czy funkcjonalność, nie? Biorąc te dwa aspekty na raz można dojść do tych wniosków, że my, twórcy aplikacji, mamy naprawdę realny i ogromny wpływ, nie?, na to jak środowisko będzie się rozwijać i jak zanieczyszczone to powietrze będzie, nie?
MARCEL RZEPKA: Wiesz co, ja myślę, że ty robisz pewne uproszczenie, nie? Bo widziałem też taką tabelkę z językami i mój ukochany payton jest jednym z najmniej energooszczędnych, najmniej eko języków, nie? Java jest chyba na szóstym miejscu, czy coś takiego. No tylko koniec końców wybór języka nie do końca zawsze zależy od nas, nie? Ode mnie programisty, takiego, wiesz, który jest częścią zespołu. To zazwyczaj jest rzecz pomiędzy klientem a architektem. 
KRZYSZTOF POJASEK: Nie, no to oczywiście to prawda, że często jest tak, że te wybory są narzucane. Ale każdy powinien wybierać te rzeczy, za które jest odpowiedzialny, na które ma wpływ. To znaczy, jeżeli ja wybiorę, tak samo, czasami musisz jechać autem, b spieszysz się gdzieś, czy musisz zawieźć dziecko do lekarza, t musisz jechać autem. Wiadomo, że nie wybierzesz autobusu. Ale jeżeli możesz jechać, pozwala ci na to sytuacja, to wybierasz autobus. I okej, jeżeli przyjdzie klient i ci powie pisz w pythonie, a nie w javie, no to nie możesz powiedzieć, ale ja chciałem w pythonie, tylko musisz zdecydować się na to. Ale w tym miejscu warto wtedy przy analizie projektu, jeżeli to jest oczywiście nowy projekt, zwrócić uwagę klientowi, że może byśmy wybrali na przykład javę, bo java zużywa mniej energii. A przez to wasza aplikacja może pozyskać jakiś status aplikacji ekologicznej. Co też teraz staje się modne, prawda?
MARCEL RZEPKA: Wszystko jest fajnie, tylko wiesz, ja w tym wszystkim widzę jeszcze jeden wymiar, nie? Bo mówimy o ekologii, o tym, ile to zużywa prądu, ale tak naprawdę jest też jeszcze jeden wymiar, łatwość pisania tej aplikacji, nie? Bo ta tabelka, z tego, co ja widzę, to ona jest oparta o osiem jakichś tam podstawowych algorytmów, nie?
KRZYSZTOF POJASEK: Tak, tak, tak.
MARCEL RZEPKA: No i na samym szczycie jest C, czy C plus plus, tak?
KRZYSZTOF POJASEK: Tak.
MARCEL RZEPKA: Te takie języki najniższego poziomu. No to dlaczego nie pisać w nich? Bo wiesz, ja widzę tutaj coś takiego, że jeśli bym zaczął pisać aplikację, backendy webowe w C, to prawdopodobnie dużo większą szkodę bym sobie tym wyrządził, przez jakieś wycieki pamięci i inne nieefektywności, niż pisząc w javie, nie? 
KRZYSZTOF POJASEK: No to prawda. No oczywiście. Jest też ten aspekt zasobów ludzkich, który gdzieś tam trzeba uwzględnić. No ale wybór języka nie jest tym jedynym wyborem, który trzeba podjąć podczas gdzieś tam tworzenia tej aplikacji. To nie jest jedyne miejsce, gdzie możesz zdecydować o tym, jak na końcu będzie wyglądać twoja aplikacja. Poza tym tak naprawdę ta tabelka, której mówisz, może pomóc w decyzji na przykład. Zwróć uwagę, że jest w niej typescript i javascript. I javascript jest kilka pozycji ponad typescriptem. To są języki relatywnie podobne do siebie i składniowo i funkcjonalnie. I już ta tabelka na tym etapie może ci pomóc podjąć decyzję, żebyś wybrał javascript, prawda? Wiadomo, nie jest to główny aspekt, czyli nie jest to główne kryterium dla którego wybierasz język programowania. Ale gdzieś tam jako podpowiedź, jako jedno z dalszych kryteriów zawsze warto byłoby to też już zacząć uwzględniać. 
MARCEL RZEPKA: To jest fajna uwaga. Też wiesz, nawet wiesz, bo my jesteśmy programistami javy, nie?
KRZYSZTOF POJASEK: Tak.
MARCEL RZEPKA: To nawet w naszym świecie masz różne alternatywy dla wirtualnych maszyn. Masz Graala, masz Openjdk. Może to też jest coś, nad czym powinniśmy się pochylić?
KRZYSZTOF POJASEK: Tak. Ale to też jest kolejny wybór, który ty musisz podjąć. Jeżeli wybierzesz już tą javę, to wtedy znowu trzeba wybrać na jakim środowisku właśnie, czy na jakiej wizualnej maszynie masz tą aplikację dostarczyć, tak? Tak samo czy sama infrastruktura, czy powinieneś wybrać on-premise czy może jednak chmurę. To wszystko to są wybory, które my musimy podjąć i mam nadzieję, że dzisiaj poruszymy właśnie te wszystkie w dalszej części aspekty i pomożemy w tych wyborach innym, którzy będą tworzyć te aplikacje, bo tak naprawdę te wybory są nie tylko na tym poziomie ściśle technicznym. Ale też na każdym innym etapie tworzenia aplikacji. Tak jak wspomniałem wcześniej, podczas już tworzenia wymagań, czy zbierania wymagań od klienta możemy jasno postawić jedno z kryteriów, że coraz częściej zdarza się, że aplikacje reklamują się jako przyjazne środowisku. Zauważ, że mamy reklamy banków czy innych instytucji, które reklamują, że nasze karty płatnicze są tworzone poprzez recykling innych plastików. To dlaczego by się nie pochwalić, że właśnie nasza aplikacja zużywa tylko jakąś tam wartość gramów dwutlenku węgla rocznie, tak?
MARCEL RZEPKA: No tak. Poza tym to jest dobry krok w stronę neutralności węglowej, nie? Neutralności węglowej, o której wiele firm walczy.
KRZYSZTOF POJASEK: Poza tym zwróć uwagę, jak się pewnie domyślasz, często ekologiczne programowanie jest, idzie w parze z takim programowaniem dosyć optymalnym. To znaczy gdzie performans jest na wysokim poziomie, gdzie jakość kodu jest na wysokim poziomie. To wszystko zazwyczaj idzie ze sobą w parze.
MARCEL RZEPKA: No bo tak naprawdę to wszystko to nie jest rzeczywiście ten jeden poziom, a można o to walczyć też w paru innych wymiarach. Wydaje mi się, że też można to robić na tym niższym poziomie. Na tym poziomie takiego zwykłego programisty, bo wytknąłeś mi parę razy.
KRZYSZTOF POJASEK: Znaczy wiesz, tak naprawdę, bo rozmawialiśmy o tym etapie, w którym zbieramy te wymagania od klienta i zakładając, że my już je pozbieramy, że klient, już przekonamy tego klienta, żeby okej, chcę być neutralny, czy tam chcę być blisko neutralności, chcę być, chcę mieć reklamy z zielonym listkiem w rogu. Róbcie to. To kolejnym takim etapem, który będzie podczas tworzenia tej aplikacji będzie właśnie wybranie tych kryteriów. I tutaj ten wspomniany język, o którym mówiliśmy. Wspomniane gdzieś tam narzędzia, których będziemy używać. Typu właśnie chmura czy on-premise. Ale też tak naprawdę w tym miejscu jest wybór bazy danych, wybór architektury. Wymyślenie tej architektury całej. To są kolejne etapy, gdzie możemy tak naprawdę dużo zrobić, żeby tą aplikację naszą zrobić oszczędną. I czy masz jakichś pomysł, co moglibyśmy zrobić podczas tworzenia architektury? W jaki sposób zaprojektować aplikację?   
MARCEL RZEPKA: Z tego, co kojarzę, to prawdopodobnie chmura jest bardziej ekologiczna od on-premise. No bo dzielisz się tymi zasobami w ramach potrzeb, tak? Te same zasoby mogę być używane zależnie od zapotrzebowania przez użytkownika po jednej stronie globu, gdzie peak jest o jednym czasie i po drugiej stronie globu, gdzie ten peak użytkowników jest przesunięty, nie? Samo to, że nie masz serwerów, które są produkowane ileś razy daje ci tego boosta do ekologii, nie? 
KRZYSZTOF POJASEK: Zobacz na przykład, że jak masz stworzyć taki on-premise, nie? Sobie taki serwer. To przygotowujesz się, budując tam, kupując kolejne serwery i kolejne pamięci, tak naprawdę przygotowujesz się d tych skrajnych przypadków, nie? Do tego najwyższego obciążenia, nie? I musisz kupić, podłączyć te wszystkie dyski, spiąć ze sobą i one cały czas muszą chodzić. 
MARCEL RZEPKA: Musisz mieć jakiś backup, wiesz?
KRZYSZTOF POJASEK: Tak.
MARCEL RZEPKA: Jeśli coś ci padnie, jakąś redundancję.
KRZYSZTOF POJASEK: Czekają na tą właśnie dwunastą, czy tam czternastą, gdzie jest ten szczyt i wtedy one dopiero hulają wszystkie w pełni mocy. Ale potem w godzinach nocnych na przykład, gdzie nikt nie korzysta z twojego serwera i tak one są zasilane, nie? I teraz zobacz, że to jest jeden z takich przypadków, dlaczego ten on-premise może dawać gorsze rezultaty, dlaczego może żreć więcej energii. Powiem ci, że znalazłem taką statystykę, że gdyby wszystkie obecne aplikacje webowe przeniosły swój backend na chmurę, gdyby wszystkie aplikacje nagle pojawiły się w chmurze, to wtedy emisyjność CO2 w całym sektorze IT, czyli jeżeli wyciągnąć by sektor IT z tych statystyk emisyjności, to emisja CO2 spadłaby o 6 procent. O 6 procent, nie? Ale może się wydawać tylko 6 procent, ale patrząc na całkowicie zużycie, wytworzenie właściwie, emisję tego dwutlenku węgla przez sektor IT, to te 6 procent to jest 60 milionów ton rocznie. 
MARCEL RZEPKA: Ogromna liczba. 
KRZYSZTOF POJASEK: Ogromna liczba, ale żeby to sobie zwizualizować, uplastycznić, jak to mówi jeden ze słynnych komentatorów piłkarskich, uplastycznijmy to sobie i wyobraź sobie, że budzisz się i nie ma żadnego auta w Polsce, nie? Znikają wszystkie auta. To jest taki sam spadek emisyjności CO2 w ciągu roku, co w momencie, gdyby wszystkie aplikacje przenieść do chmur, nie? I to, zobacz, jak tak naprawdę robi skalę. Wydaje się, że 6 procent, ale to jednak dość duży krok do poprawy jakości powietrza, nie?
MARCEL RZEPKA: No.
KRZYSZTOF POJASEK: I to tylko dlatego, między innymi tylko dlatego, że chociażby jest ta skalowalność, która właśnie zapobiega kupowaniu hardware’u nad wyrost, tak? Poza tym te wszystkie chmury, te wszystkie serwery chmurowe coraz częściej robią się neutralne pod względem właśnie emisji, ponieważ korzystają z odnawialnych źródeł energii. Słyszałem nawet o serwerowni Microsoftu, która jest gdzieś pod wodą.
MARCEL RZEPKA: Tej takiej w kontenerze?
KRZYSZTOF POJASEK: Tak, tak, tak. podobno jej nawet awaryjność jest zdecydowanie mniejsza niż zwykłych serwerów. Także wybierając chmurę jako nasz backend powodujemy, że nasza aplikacja zdecydowanie jest bardziej energooszczędna niż takie rozwiązanie on-premise.
MARCEL RZEPKA: To jest jeden z aspektów tego wszystkiego, nie? Bo mamy jeszcze, możemy wybrać bazę no SQL i SQL. 
KRZYSZTOF POJASEK: Też. Na przykład. Nawet sam fakt przy konstruowaniu nie tylko już, okej, mówisz od strony infrastruktury baza danych, no to też jest tutaj ważny wybór, nie? Ale jak myślisz, co więcej prądu zje? Gdy wyślę select from person czy select imię, nazwisko from person, czy select names of some persons? 
MARCEL RZEPKA: To jest oczywiste, nie? Że nawet to wyszukiwanie po stronie bazy danych będzie dużo bardziej zoptymalizowane niż wyszukiwanie po stronie naszej aplikacji. No i są jeszcze koszty przesyłu, tak? Musisz zapłacić za internet, bo dostawcy chmurowi często się tak rozliczają. Ale przede wszystkim musisz zasilić te urządzenia sieciowe. Trzeba o nie zadbać, nie?
KRZYSZTOF POJASEK: Nie, to też prawda, tak, tak, to też prawda, że różne urządzenia, które przesyłają dane też jedzą ten prąd. Dlatego też powinniśmy się skupić na tym, żeby te zapytania były jak najbardziej konkretne, że to, co chcemy się dowiedzieć, o to pytamy, nie? Ale też nawet tworząc tabelę, ja się na przykład złapałem kilka razy, że tworząc tabelę duplikowałem jakąś wiadomość tylko dla tego na przykład, że był lepszy dostęp. Często jest to błąd gdzieś tam architektury samych relacji pomiędzy tymi bazami danych. Przez to nie dość, że gubimy siebie, powodujemy jakieś tam spaghetti w tych relacjach, to jeszcze tak naprawdę powodujemy nad wyrost gromadzenia tych danych, nie? Tych danych jest coraz więcej. Niepotrzebnych danych, nie?
MARCEL RZEPKA: No tak, jeśli masz zduplikowane dane, one w pewnym momencie mogą ci się rozjechać, nie?, co doprowadzi do błędu w tej aplikacji, więc to eko programowanie w pewnym sensie też zapobiega błędom. Zapobiega błędom, pomaga optymalizować. Jest dobrą wskazówką.
KRZYSZTOF POJASEK: Tak. Wracając do tego, co mówiliśmy na początku, że eko programowanie to często jest też lepsza wydajność, czystsza aplikacja, łatwiejsza w przemieszczaniu się po niej, nie? Jeszcze jedna rzecz do tej bazy danych. To też ważny aspekt, bo to jest drobna rzecz którą można dodać, a może znacznie wpłynąć na performans właśnie wyszukiwania, to jest dodanie indeksów po prostu do unikalnych, czy tam do IDI-ku czy do unikalnej kolumny. Dodawanie indeksów, tak by to wyszukiwanie trwało szybciej. Żeby nie zajmowało tyle procesów, ile robiło to bez tych indeksów, nie?
MARCEL RZEPKA: Więc mamy sytuację win win, nie?
KRZYSZTOF POJASEK: Dokładnie.
MARCEL RZEPKA: Tak naprawdę.
KRZYSZTOF POJASEK: I zobacz, że to jest właśnie ten mały krok, o którym tam wspominałem, który tworzy wielki impakt. Ty dodasz tylko jeden indeks, to jest kwestia kilka słów wpisania, przetworzenia kolumny, a zobacz jaki to jest impakt, nie? Ile jest na przykład zapytań, które będzie, nie wiem, wyszukiwania postów rekomendowanych dla danej osoby, nie? Ile tego jest, zapytań, ile leci dziennie, a jaka mała zmiana, nie?
MARCEL RZEPKA: No. Ja teraz nie wiem, czy my możemy o tym mówić, ale wiesz, u nas w projekcie też to jest fajnie wdrożone, bo mamy plug in do sonara, który po prostu wskazuje nam te miejsca w kodzie, gdzie można coś poprawić, nie?
KRZYSZTOF POJASEK: Tak.
MARCEL RZEPKA: Że może tutaj warto się zastanowić nad switchem? Może tutaj zamiast replays alla użyj zwykłego replaysa, bo nie pojawi ci się zbędny regex, który będzie kosztował cię trochę prądu i wydajności.
KRZYSZTOF POJASEK: Ja powiem ci Marcel, że my nawet powinniśmy o tym mówić. Zwróć uwagę, że Capgemini już rok temu wydało raport, który pokazuje, w jaki sposób IT ma wpływ na środowisko i w jaki sposób podpowiada w jaki sposób możemy to środowisko poprawić. I jednym z takich elementów tej poprawy jest trzymanie się pewnych zasad podczas wytwarzania oprogramowania. Te zasady zostały przełożone właśnie na reguły sonarowe. Sonar to taki plug in do dbania o jakość kodu. I przy każdym budowaniu, zautomatyzowanym budowaniu aplikacji dostajemy konkretny spis reguł, w którym miejscu nasz kod nie spełnia tych reguł. Czyli w którym miejscu tak naprawdę możemy zmniejszyć emisję CO2 przez naszą aplikację. Pomocne narzędzie, które, znowu, wystarczy tylko dodać jeden plug in do projektu i przy każdym budowaniu jesteś w stanie dbać krok po kroku o swoją aplikację. Mało tego, i to nie znaczy, że to możesz zastosować tylko do nowych aplikacji, bo mając już aplikację, większość projektów w ogóle to są projekty legacy, czy projekty które dostajemy w spadku, które musimy poprawić, które musimy rozwijać i to rozwiązanie, o którym przed chwilą wspomniałem, możemy właśnie do tych projektów zastosować. Wystarczy wczytać te zasady regułowe. 
MARCEL RZEPKA: Dodać po prostu. 
KRZYSZTOF POJASEK: Dokładnie, dodać.
MARCEL RZEPKA: Plug in do istniejącej instancji sonara, bo nie wierzę, że projekty nie mają sonara, bo to jest narzędzie, które po prostu ułatwia. Ułatwia zapanowanie nad chaosem aplikacji, zapanowanie nad długiem technologicznym, bo tak naprawdę naruszenie tych reguł eko programowania możemy traktować jako dług technologiczny, nie?
KRZYSZTOF POJASEK: Właśnie dostałem kiedyś pytanie, nie”, jak się ma to eko programowanie do właśnie długu technologicznego? I w sensie, czy można eko programowanie robić kosztem długu technologicznego i odpowiedź była prosta, przecież jedno drugiego nie wyklucza. Przecież programując eko tak naprawdę poprawiamy też performans aplikacji, czyli zmniejszamy ten dług technologiczny. Dostajemy właśnie spis reguł, narzędzi. Nawet sam fakt przejścia z infrastruktury lokalnej na infrastrukturę chmurową jest pewnym krokiem do zmniejszenia, dość dużym krokiem, milowym, do zmniejszenia tego długu technologicznego, nie? Więc zwróć uwagę, że kolejną prostą czynnością, zaciągnięciem tych reguł do swojego projektu możemy krok po kroku, eliminując kolejne z błędów, zmniejszyć zużycie energii naszej aplikacji, nie? 
MARCEL RZEPKA: Mhm.
KRZYSZTOF POJASEK: No ale okej, nie tylko programistami, nie tylko analitykami projekt istnieje. Zanim jeszcze zaczniemy programować musimy na przykład zaprojektować na przykład UI, nie? Czy przychodzą ci jakieś do głowy pomysły, co taki projektant, czy UI czy UX może zrobić, żeby właśnie ta aplikacja była bardziej oszczędna?
MARCEL RZEPKA: Teraz mnie zaskoczyłeś, bo nie myślałem o tym.
KRZYSZTOF POJASEK: Pach. Pierwsze, co przychodzi do głowy.
MARCEL RZEPKA: Patrz, a wiesz co? 
KRZYSZTOF POJASEK: No?
MARCEL RZEPKA: Też mi coś przyszło, nie?
KRZYSZTOF POJASEK: No to dawaj pierwszy.
MARCEL RZEPKA: Daj mi się wypowiedzieć troszkę. 
KRZYSZTOF POJASEK: Dawaj proszę.
MARCEL RZEPKA: Bo jak myślę o tych social mediach, ja jestem fanem Redita. Dużo czasu spędzam na Reddicie, ale właśnie używam alternatywnych aplikacji do przeglądania, dlatego, że wykorzystują mniej zasobów w sensie internetu. Nie ładują wszystkiego od razu, całego feeda, tylko ładują sobie posty po kolei. Nawet coś tak prostego, nie? 
KRZYSZTOF POJASEK: Tak.
MARCEL RZEPKA: Ten lazy loading.
KRZYSZTOF POJASEK: Okej. A jaki kolor jest, jak wchodzisz na Reddita?
MARCEL RZEPKA: Wiesz, że ja jestem fanem czarnych teł, ja jestem programistą. 
KRZYSZTOF POJASEK: No właśnie, widzisz, czyli tryb ciemny, nie? Czyli większość aplikacji, o których mówimy mają swoje odpowiedniki bądź same są już zaprojektowane na telefony, które w znacznej większości coraz częściej mają ekrany amoledowe.
MARCEL RZEPKA: Czyli mają ekrany oled.
KRZYSZTOF POJASEK: Amoled, które…
MARCEL RZEPKA: A ekrany oled nie świecą ciemnymi pikselami, nie?
KRZYSZTOF POJASEK: Dokładnie. Czyli projektując aplikację pamiętaj o tym, że albo dodać po prostu tryb ciemny, bo oczywiście może być użytkownik, który preferuje jasny tryb z jakichś powodów, albo po prostu projektuj ją w ciemnych barwach, nie? Jest dużo podstron z podpowiedziami, jakie barwy zużywają jak najmniej prądu przy ekranach amu led. Może tym warto też się zasugerować podczas projektowania takiego interfejsu, nie? Kolejna rzecz, też fajna, ciekawa właśnie taka podpowiedź, którą znalazłem, gość stworzył aplikację dla sklepu i by zmniejszyć ilość zapytań i przesył tak naprawdę tych wielkich zdjęć, które zazwyczaj są ładowane z modelami, z tymi ubraniami. 
MARCEL RZEPKA: Nie mówi mi, że to jest kaszowanie? I to jest tak proste.
KRZYSZTOF POJASEK: Nie, to nie jest cache’owanie. I jeszcze cache’owanie jest jedna rzecz.
MARCEL RZEPKA: Okej.
KRZYSZTOF POJASEK: Ale druga rzecz, że CSN rysuje zarys tego ubrania i dopiero wtedy, gdy jesteś zainteresowany konkretnym produktem, rozumiesz, szukasz spodni, a wyświetlają ci się skarpetki, no to nie chcesz oglądać zdjęcia. Nie chcesz ładować zdjęcia ze skarpetkami, tylko szukasz tych spodni, które na przykład jeansy, ale źle, nie pofiltrowałeś i masz masę różnych spodni. No to szukasz te, które cię zainteresują i dopiero po zainteresowaniu się konkretnym produktem pobierasz zdjęcie, nie? Wcześniej wszystkie obrazki są generowane przez CSS, czyli ty tak naprawdę zmniejszasz zużycie przesyłu tych zdjęć, którymi i tak nie jesteś zainteresowany.
MARCEL RZEPKA: Masz szybszy czas do interaktywności, co jest też fajnym wyznacznikiem, że twoja aplikacja jest lepsza.
KRZYSZTOF POJASEK: Tak. To prawda.
MARCEL RZEPKA: Dla użytkownika, nie? Z punku widzenia użytkownika, bo nie czeka na obrazki, aż się to załaduje. 
KRZYSZTOF POJASEK: Dokładnie. Samo przewijanie właśnie tych obrazków jest o wiele, pseudo obrazków, to są rysunki w sumie, tych rysunków, to jest o wiele bardziej płynne, nie? Że widzisz, to są kolejne jakieś takie drobne triki i to nawet innowacyjne, bym nawet to nazwał, bo jest to coś nieszablonowego, nie?
MARCEL RZEPKA: No pewnie. Tak samo można w SOG wykorzystać, który też jest lekkim formatem do tego, nie? Jeśli nawet CSS komuś nie wystarcza, bo mimo że w CSS-ie można tworzyć małe cuda, to SOG też jest fajnym formatem, który można wykorzystać.
KRZYSZTOF POJASEK: To samo. Przy tworzeniu właśnie różnego typu aplikacji z treściami, gdzie możesz udostępnić treść, albo dodać lubię to, czy jakiś inny przycisk dedykowany dla social mediów, często programiści idą na łatwiznę i używane są te guziki, które są generowane przez właśnie Facebooka czy przez konkretne media społecznościowe. A zwracałeś uwagę kiedyś, jak kliknąłeś w taki przycisk, który był stworzony przez portal społecznościowy, ile tam jest pomiędzy jeszcze przekierowań? 
MARCEL RZEPKA: Tak. Tam jest masa analityki tej takiej, nie?
KRZYSZTOF POJASEK: Dokładnie, więc lepiej jest na przykład stworzyć taki przycisk samemu i przekierować bezpośrednio do swojej strony, czy do docelowego miejsca, niż korzystać w wygenerowanych guzików, bo one generują niepotrzebny ruch sieciowy, który też w jakimś stopniu obciąża tam urządzenia pozwalające komunikować się pomiędzy punktami docelowymi, nie? 
MARCEL RZEPKA: Ja chciałbym jeszcze wrócić do tego tematu cache’owania, nie? Bo to też jest fajne zagadnienie. I to jest coś, co w wielu miejscach może poprawić znacząco i wydajność twojej aplikacji, no bo tak naprawdę nie musisz uderzać z tego backendu za każdym razem, jeśli masz takie same zapytania. To pozwoli ci zdownskalować twój abserwis, czy cokolwiek, na czymkolwiek twoja aplikacja stoi. Twój kontener po prostu. I to doprowadzi do tego, że będziesz miał niższe koszty, ale też będziesz bardziej ekologiczny.
KRZYSZTOF POJASEK: Dobra. A w jaki sposób na przykład?
MARCEL RZEPKA: Sam wiesz, że w samym teamie u nas, u naszego klienta, jeden zespół zaimplementował cache’owanie przed swoją aplikacją. Tam chyba było mówione o 70 procent mniejszych kosztach? Mniejszym zużyciu?
KRZYSZTOF POJASEK: No. To prawda. To prawda. A dałbyś jakiś przykład? W sensie fikcyjny, pseudo fikcyjny przykład.
MARCEL RZEPKA: No wiesz, masz jakieś powiadomienie, nie wiem, pop up, który wyskakuje, tak? Zamiast za każdym razem odpytywać aplikację z tą bazą pop upów, mieć statyczny kesz przed tym. 
KRZYSZTOF POJASEK: Dokładnie.
MARCEL RZEPKA: To jest tak proste.
KRZYSZTOF POJASEK: Dokładnie. Albo jakiś timer też, nie? Zamiast zapytywać się o zmianę hasła i tak dalej, nie wiem czego może dotyczyć ten pop up. Jeżeli miałaby to być jakaś przypominajka, no to zamiast wypytywać się ciągle, to obsłużyć to po stronie…
MARCEL RZEPKA: Przenieść to na frontend, nie?
KRZYSZTOF POJASEK: Dokładnie. Dobra. Masz jakiś pomysł jeszcze, na jakim etapie możemy podpowiedzieć słuchaczom co mogą zmienić, co mogą poprawić, żeby ich aplikacje też były eko?
MARCEL RZEPKA: Wiesz co? Ja się zastanawiam nad frameworkami, nie? Bo teraz wydaje mi się, że duży hype jest na Quercusa. Nie wiem czy liznąłeś, zobaczyłeś?
KRZYSZTOF POJASEK: Kiedyś się interesowałem. No. Kiedyś, w sumie jeszcze wcześniej jak zaczynały dopiero wchodzić, to też starałem się poznać wroga.
MARCEL RZEPKA: I mam wrażenie, że to jest fajny kierunek, bo z tego, co kojarzę, to te kontenery z Quercusem są dużo lżejsze. Całe to oprogramowanie tam jest okrojone. I wydaje mi się, że chyba dzięki Graalowi tam jest transpiracja do natywnego kodu, czy coś takiego. Może kłamię, musiałbym sprawdzić, czy tam po prostu się nie pojawia, fragmenty natywnego kodu, które to wszystko nie dość, że przyspieszają, bo start kontenera jest dużo szybszy. 
KRZYSZTOF POJASEK: Ale w ogóle konteneryzacja, nie? W jakichś sposób. 
MARCEL RZEPKA: No właśnie. Zamiast wirtualizacji. Też o tym teraz pomyślałem, jak użyłem słowa kontener parę razy. Kontener jest dużo lżejszy niż wirtualna maszyna. I tu nie ma co się oszukiwać, bo w wirtualnej maszynie tak naprawdę stawiamy cały pełny system, tak? Pełen hardware emulujemy. A kontener? Tylko staramy się odseparować to, co jest powiązane z naszą aplikacją od systemu, na którym to pracuje, nie ? I to też jest dużo lżejsze.
KRZYSZTOF POJASEK: I zobacz też, że sama konteneryzacja też poprawia czas na przykład przywrócenia, tak?, sprawności aplikacji, że to zmniejsza pobór energii, który mógłby być konieczny do tego typu napraw, nie? To też w pewnym sensie uelastycznia i daje więcej możliwości na to, by nasza aplikacja była bardziej eko. A co za tym też idzie, w ogóle cały deployment aplikacji, nie? Jakby go tak zautomatyzować. Każdy z deploymentów byłby zautomatyzowany. Przeniesiony do chmury, skonteneryzowany. Opatrzony w odpowiednią kontrolę jakości, taką jak wspomniany wcześniej sonar i te konkretne reguły. To mogłoby nam właśnie pomóc nie tylko właśnie zmniejszyć zużycie prądu, bo deploy wykonywał by się wtedy, kiedy jest to konieczne. Tylko wtedy, gdy jest to konieczne. Kontrolowalibyśmy to, czy nie wyłamujemy się z jakichś wcześniej narzuconych reguł. Chmura, tak jak wspomnieliśmy wcześniej, zmniejszy zużycie prądu. 
MARCEL RZEPKA: Wiesz, mówisz jakbyśmy tego nie robili, nie? Przecież mamy ustawione procesy CI, CD. To wszystko jest robione na współdzielonych nod’ach. To też jest fajna uwaga tutaj, że te nody do budowania bardzo często mogą być współdzielone między wieloma projektami. Tak naprawdę nie ma dla ciebie znaczenia, czy projekt buduje się w ciągu 10 minut czy 20. W wielu przypadkach, jeśli tam budujesz go na gotowo, na produkcję do deploymentu, a to też jest jakiś sposób, żeby ograniczyć te koszty, nie? Zwłaszcza, że te nody można skalować w górę, w dół. Tak naprawdę chyba wszerz. 
KRZYSZTOF POJASEK: Wszerz też. Wszerz też.
MARCEL RZEPKA: Dostawiać nody do budowania zależnie od potrzeb, tak? Bo wiesz, że twoi programiści tak naprawdę mają takie ośmio, około ośmiogodzinne okienko, gdzie pracują najintensywniej i tych nodów musi być najwięcej, żeby dostarczyć im tą aplikację jak najszybciej. Ale poza tym okienkiem możesz oddać te nody do czegoś innego, tak?
KRZYSZTOF POJASEK: To jedna rzecz.
MARCEL RZEPKA: Testowanie może odbywać się w nocy.
KRZYSZTOF POJASEK: Właśnie.
MARCEL RZEPKA: Na pozostałych nodach.
KRZYSZTOF POJASEK: A część jobów, które były w nocy możesz też tak naprawdę wyłączyć, jeżeli one są niepotrzebne, nie? Możesz w pełnym zakresie kontrolować tymi jobami, możesz decydować, ustawić im cykle, decydować, które są potrzebne, które nie. Programować je od zależnych warunków, które są. Nie wiem, jeżeli jest na przykład, w sektorze finansowym często są te business days, czy jakieś freezy. Możesz wyłączyć te nody na ten etap, bo po co ci budowanie, cykliczne budowane aplikacji, czy tam cykliczne sprawdzanie bezpieczeństwa aplikacji, która nie została przez freeze ani żadna zmiana zdeployowana, nie?  
MARCEL RZEPKA: Zwłaszcza, jeśli to, wiesz, nie są buildy akceptacyjne, nie? To jest fajne. Ale też uderzyłeś w jeden czuły punkt, z którego sobie nie zdawałem sprawy, bo dla mnie to jest coś oczywistego teraz, ale pamiętam, że jednym z zadań, z którym się kiedyś spotkałem w jednym z bardziej legacy projektów, było przerobienie payplajnów CI CD tak, żeby one nie budowały sobie wszystkich zależności od postaw, tylk żeby zaciągały je z Nexusa. To też jest fajna uwaga, nie?, że jeśli masz zależności rozwijane in house, no to nie musisz ich budować za każdym razem. 
KRZYSZTOF POJASEK: No tak i to wszystko możesz zrobić właśnie przy automatycznym deploy’u, nie? To możesz wszystko zaprojektować. Tak samo jak wspomniałeś o jobach, które testują w nocy, nie? No ale pytanie. Czy nie lepiej by było opatrzyć go w warunek, że testuj tylko wtedy, gdy były jakieś zmiany? 
MARCEL RZEPKA: Znaczy wyobrażam sobie, że mówisz teraz o integracji, która trwa dość długo, nie?, więc to będzie miało spore znaczenie.
KRZYSZTOF POJASEK: Tak. Ty właśnie mówiłeś o tych jobach nocnych, które lecą, tak jak mówisz, dość długo. No ale jeżeli przez sobotę, niedzielę, nikt nie wstawił żadnych zmian, no to nie będziemy w nocy budować kolejnych testów integracyjnych, sprawdzać, ponieważ nic się przecież nie zmieniło od ostatniego testu, nie? Więc opatrzmy ten job odpowiednim warunkiem, który mówi, że jeżeli nie było zmian, bądź też, jeżeli to jest sobota, niedziela…
MARCEL RZEPKA: Tak. Porównaj commit hasha z poprzednim [niezrozumiałe 00:36:25]
KRZYSZTOF POJASEK: Tak. I wtedy puszczaj.
MARCEL RZEPKA: To nie są trudne rzeczy, nie? Tylko sobie trzeba z nich zdać sprawę.
KRZYSZTOF POJASEK: Tak. Dokładnie. No wiadomo, że łatwiej jest stworzyć joba, który po prostu będzie codziennie puszczał, ale może warto trochę usiąść chwilę dłużej, dodać jakiś warunek, sprawić, by to wykonywało się tylko wtedy, gdy jest taka potrzeba, nie? No tak jak z tym światłem, o którym na początku wspominałeś. Wychodzisz z pokoju, gasisz światło. Masz zbudowaną aplikację, masz, przeszły wszystkie testy, nic nie zmieniałeś, to nie puszczaj jeszcze raz tych testów. Przecież nic się nie zmieniło. A używając na przykład chmur to o stabilności dowiesz się poprzez monitoring cały w aplikacji. Nie musisz puszczać co chwilę testów integracyjnych, które ci odpowiedzą, że aplikacja nie działa, bo ta aplikacja jest monitorowana przecież. 
MARCEL RZEPKA: Coś mi się wydaje, że można przycinać trochę zasoby na przykład na środowiskach deweloperskich, nie? Co się często robi. Ale to akurat fajnie skonsultować z programistami, na ile można sobie pozwolić.
KRZYSZTOF POJASEK: Ale co masz na przykład na myśli? Wypiąć pamięć ram z twojego komputera?
MARCEL RZEPKA: Nie, no wiesz, ja żyję w świecie chmury, gdzie po prostu zmniejszenie zasobów to jest dla mnie przesunięcie suwaka.
KRZYSZTOF POJASEK: No to prawda. No, okej. Dobrze. Czy przychodzą ci do głowy jeszcze jakieś pomysły, gdzie moglibyśmy, obszary, gdzie moglibyśmy pomóc naszym słuchaczom?
MARCEL RZEPKA: Wiesz co? Chyba nie. Myślę, że powoli można się zbliżać ku podsumowaniu. A ja ci zadam teraz podkręconą piłkę, rzucę ci teraz podkręconą piłkę i zapytam cię, czy uważasz, że to eko programowanie to nie jest trochę taki rebranding optymalizacji?
KRZYSZTOF POJASEK: Rebranding optymalizacji? To wiesz, ja myślę…
MARCEL RZEPKA: No bo tak naprawdę chodzi o to, żeby twoja aplikacja, wiesz, działała szybko. Jeśli będzie działała szybko, to będzie używała mniej zasobów, nie?
KRZYSZTOF POJASEK: Tak. No to to, co wspomniałem wcześniej, że sprawianie, żeby twoja aplikacja była eko niekoniecznie musi się mijać z tym, że ona będzie szybsza, że będzie miała lepszy performans. Wręcz przeciwnie. To jest często zbieżne ze sobą. Może to ja nie nazwałbym tego rebrandingiem optymalizacji, bo optymalizacja, wydaje mi się, jest tutaj takim efektem ubocznym. Tak naprawdę, zresztą optymalizacji czego? Optymalizacji performansu?
MARCEL RZEPKA: Mhm. 
KRZYSZTOF POJASEK: Sprawianie, że aplikacja będzie eko jest w pewnym sensie optymalizacją, ale zużywania energii. A to jest raczej oczywiste, że mniej zużyjemy energii, jeżeli będzie działać aplikacja szybciej, nie? Zarówno zużyjemy mniej energii na urządzeniu, na którym będzie uruchomiona, jak i także na urządzeniach, które uczestniczą w komunikacji, czy uczestniczą w dostawie tych danych do końcowego użytkownika, nie? Więc to też jest jakaś optymalizacja, ale wydaje mi się, że to jest nowy nurt optymalizacji. W sensie… 
MARCEL RZEPKA: Że tych reguł jest więcej po prostu?
KRZYSZTOF POJASEK: Tak. 
MARCEL RZEPKA: Dookoła.
KRZYSZTOF POJASEK: I wcześniej optymalizacja była traktowana też jako optymalizacja, żeby klient był zadowolony na przykład, albo żeby klient końcowy, który będzie się cieszył, że szybko wszystko płynnie działa. A teraz ta optymalizacja poszła też krok dalej nadając tak naprawdę sens dla ludzi postronnych. Dla osób, które nie używają tej aplikacji, ale które chcą cieszyć się tym środowiskiem, nie? Lepszym środowiskiem.
MARCEL RZEPKA: Okej. To następne pytanie takie już powoli kończące.
KRZYSZTOF POJASEK: Podkręcone?
MARCEL RZEPKA: Nie. To akurat nie.
KRZYSZTOF POJASEK: A dobrze odbiłem?
MARCEL RZEPKA: Dobrze.
KRZYSZTOF POJASEK: Dobrze.
MARCEL RZEPKA: Czy miałeś jakieś złe nawyki, z których zdałeś sobie sprawę ucząc się eko programowania? Bo ja na przykład, ten nasz plug in od sonara wytknął mi czasami, też się głupio do tego przyznać, że używam replace all w javie. A replace all w javie przyjmuje regexa i bardzo często to nie ma w ogóle znaczenia, że przyjmuje regexa, ale właśnie, jeśli chodzi o performans i eko programowanie, to zużywasz trochę więcej zasobów. No bo tego regexa trzeba skompilować i potem prześledzić na tekście, nie? Czy miałeś coś takiego?
KRZYSZTOF POJASEK: Powiem ci szczerze, że pod tym kątem nie analizowałem tego tak naprawdę. Ale na przykład rzeczy, które mnie zaskoczyły, na które ja niestety nie miałem wpływu ze względu na role moje w projekcie, to na przykład sam fakt, jak dobrze wiesz, to chyba możemy zdradzić, że w projekcie, dla którego pracujemy, używamy warstwy BFF, która też w dużym stopniu tak naprawdę ogranicza zużycie energii przez aplikację. Ponieważ agreguje te wszystkie backendy pod spodem, będąc również na backendzie i ogranicza ilość zapytań przez aplikację kliencką do tego pojedynczego zapytania, nie? Czyli to jest ta agregacja wszystkich danych, nie? Zamiast wypytywać serwis, który jest odpowiedzialny za dane osobowe, serwis, który jest odpowiedzialny za bilans klienta, czy serwis, który jest odpowiedzialny za rekomendację produktu dla klienta, tak naprawdę wysyłamy jedno zapytanie, czyli angażujemy wszystkie urządzenia po drodze tylko raz. I przesyłamy odpowiedź też tylko raz. 
MARCEL RZEPKA: I dostajesz tylko to i nic więcej niż jest potrzebne do załadowania danego widoku, nie?
KRZYSZTOF POJASEK: Dokładnie. Nawet nie zdawałem sobie…
MARCEL RZEPKA: To jest fajne.
KRZYSZTOF POJASEK: W ten stronę odpowiem ci na twoje, przewrotnie trochę odpowiem ci na to twoje pytanie, że nie zdawałem sobie sprawy, że robię coś dobrego, nie? Że to, co używam tak naprawdę jest tym czymś dobrym, nie? To jest ciekawe, że jak nawet się rozglądnąć wokół siebie, to nawet nie jesteś świadom jak wiele, poprzez to, żeby zapewnić dobry performans, bezpieczeństwo, czy inne jakieś aspekty, jak wiele robisz przy okazji dobrego dla środowiska. Co nie znaczy oczywiście, że nie możesz zrobić więcej, bo zawsze możesz zrobić więcej. 
MARCEL RZEPKA: I to jest fajna myśl, żeby zakończyć tą rozmowę, myślę. Zawsze można zrobić więcej, ale warto też wiedzieć, co robimy w tej chwili.
KRZYSZTOF POJASEK: Bardzo dziękujemy wam, że spędziliście ten czas z nami. Mam nadzieję, że coś z tego dla siebie wyciągniecie. I zapraszamy was do słuchania kolejnych podcastów. 
MARCEL RZEPKA: Dziękujemy.
KRZYSZTOF POJASEK: Dzięki serdeczne.
MARCEL RZEPKA: Jeżeli chcecie pogłębić swoją wiedzę na tematy poruszane przez nas zapraszamy was do opisu podcastu, w którym znajdziecie linki do raportów wykorzystanych do przygotowania tego materiału. A także stronę ONZ-u, na której możecie zmierzyć swój ślad węglowy. 
KONIEC