Ostatnie Patoszkolenie w tym roku👇
➡️ 04.06.2024 Architektura 101
Tym razem o Postgresie, rynku IT, a także kilka ciekawostek!
Słuchasz Patoarchitektów dzięki Protopii. Sprawdź, jak Patoarchitekci i Protopia mogą Ci pomóc ➡️ protopia.tech
Linki i ciekawe znaleziska:
Łukasz Kałużny: Cześć! Słuchacie Patoarchitektów. Prowadzą Łukasz Kałużny…
Szymon Warda: …I Szymon Warda. Wszystkie linki do tego odcinka oczywiście na patoarchitekci.io/71. Dobrze, to Łukasz, zaczynamy. Co tam ciekawego wygrzebałeś?
Łukasz Kałużny: Dobra, na start. Dzisiaj moce Postgresa, jego Super Powers od Oskara Dudycza, który ostatnio był u nas gościem i pokazał we wpisie kilka różnych możliwości Postgresa, które przychodzą… Można stosować, budować różne elementy. Tutaj pokazał to na poziomie partycjonowania, Time Series, danych GISowych, więc wymieszane tak naprawdę bardzo dużo możliwości, które normalnie na bazie relacyjnej trudno bezpośrednio zaimplementować. I z tym jedno takie przemyślenie, że Postgres jest najlepszą drugą bazą danych do wyboru. Jak mamy to z Pythonem, że Python zawsze jest najlepszym drugim językiem.
Szymon Warda: To żeby nie było, bo ja mam znowu wpis też właśnie o Postgresie, a mianowicie o tym, że Postgress ma możliwość, praktycznie każda baza ma coś takiego, co nazywa się Print Data Capture. Czyli generalnie mamy taki strumień zmian. Jakie zmiany doszły. To w wielu sytuacjach to jest taki pattern dla mnie. No ale jest ten ficzer, powiedzmy sobie. Teraz Postgres dorzucił opcję, żeby w tym strumieniu eventów, to są eventy de facto, można było wrzucać zdarzenia, których źródłem nie jest to, że zmieniło się coś w tabeli i cały wpis jest wokół tego, że de facto możemy teraz na bazie Postgressa robić też de facto właśnie cały taki strumień eventów a’la Kafka i zrobić też komunikację między mikroserwisami.
Szymon Warda: I moja myśl, bo Ty mówisz o super mocach wszystko fajnie i… OK i Postgres jest fajną bazą danych. Tylko moje pytanie jest teraz takie, czy Postgres nie zmierza do takiego kierunku, że jak będziemy za parę lat widzieć Postgresa to będzie: o Boże, co za pierdolnik tam może być? Tam po prostu może być absolutnie wszystko.
Łukasz Kałużny: Oracle 2.0.
Szymon Warda: Tak, no właśnie albo Oracle Forms i tego typu pomysły tak naprawdę.
Łukasz Kałużny: Wiesz co. Ale pomysły to jest rzecz, którą bardzo często rozmawiamy. Jak to, jak ja rozmawiam z klientami, ugryźć i przetłumaczyć niekiedy, że baza danych w dzisiejszych czasach powinna mieć możliwości szybkiego składowania, szybkiego zapisu, odczytu, dobrego elastycznego wyszukiwania, partycjonowania. A logika biznesowa i inne takie ficzery. Zostawmy to do kodu i dedykowanych usług.
Szymon Warda: Ale też nawet nie mówimy o logice.
Łukasz Kałużny: Wiesz co, tylko dla mnie, widzisz, znowu zaczyna się Integration, takie te Enterprise Integration Pattern, i integracja przez bazę danych, co normalnie śmierdzi tym na kilometr.
Szymon Warda: Nie wydaje mi się, żeby to było źródłem. Zobacz na sytuację, którą mieliśmy parę odcinków temu, kiedy mówiliśmy o opcji zarządzania AWSem przez Postgresa. No nie?
Łukasz Kałużny: Tak.
Szymon Warda: Wydaje mi się, że po prostu znowu wracamy do tego pomysłu, że zamiast mieć odpowiednie toole na odpowiednie sytuacje, to mamy grupę ludzi, którzy po prostu chcą, znają jedno narzędzie i chcą zacząć je wykorzystywać wszędzie.
Szymon Warda: Po prostu. I to parcie do tego, że znowu skupiamy się w takich małych swoich, bąbelkach i tam będziemy hackowali, oby tylko działało. I wydaje się, że Postgres chce być takim prowodyrem z tego takiego nurtu, że tam już wszystko na nim mamy.
Łukasz Kałużny: Tak i wiesz co, i tutaj nawet zgoda z tym, że jest tego za dużo, pomysłów na implementację, bo tak jak te extensiony. Używałem gdzieś produkcyjnie, na przykład tego timescale’a pod bazy raportowe czy partycjonowanie i tam te rzeczy naprawdę ładujesz. To jest extension, który ładujesz. Jest genialnie przygotowany, bo no timescale - automatyczne repartycjonowanie, partycjonowanie z metryk. No sorry, jakbym miał to napisać w kodzie albo dostawać pod to specjalnie… Influxa, męczyć się, to jest problematyczne.
Szymon Warda: Bez dwóch zdań. Takie funkcje jak najbardziej mają sens. Tak samo jak GISy. Jak najbardziej mają sens na bazie danych, to jest nawet konieczność, ale Postgres zaczyna mieć po prostu mieć tego dużo. Moje pytanie po prostu - czy Postgres nie będzie za jakieś parę lat takim sygnałem, że w tym projekcie może być absolutny pierdolnik.
Łukasz Kałużny: To jest ciekawe, może.
Szymon Warda: No właśnie, bo tak… Tempo nowych ficzerów, tempo nowych pomysłów, co tam oprzeć na nim jest takie już dla mnie trochę martwiące.
Szymon Warda: Wpis Oskara jest super, bo on pokazuje to bardziej takie prawidłowe, ale tego jest coraz więcej i też pokazuje swoją drogą jak Postgres bardzo mocno zyskuje na użyciu.
Łukasz Kałużny: No więc to tak. Też ostatnio widziałem parę projektów, które mówią, że ucieczki z DB2 Oracle ze względu na cenę licencji też możliwości. Jak przepisujemy te stare aplikacje przenosimy logikę na warstwę aplikacyjną, wreszcie wydobywamy się z tego kodu o tak to określę kulturalnie. Z kodu SQL owego przenosimy się na rzecz aplikacji. Wtedy Postgres jest genialny.
Szymon Warda: Jedna jeszcze taka refleksja, w ogóle w tej całej rozmowie o bazach danych de facto totalnie, wydaje mi się, że przycichło MySQL. Nie słychać go w ogóle prawie.
Łukasz Kałużny: No ale wiesz co? Ludzie go chyba nadal wybierają, bo patrząc się tam na raporty popularności. Razem z Marią powiedzmy, zapakujmy do jednej, gdzieś leci, ale to jest też pokłosie tego, co zrobił Oracle z tym produktem.
Szymon Warda: No dobrze, lecimy dalej. Co tam wygrzebałeś jeszcze?
Łukasz Kałużny: Dobra, następna rzecz to Self Promotion.
Szymon Warda: Stąd było takie długie “eee, yyy”.
Łukasz Kałużny: Dokładnie, self promotion. W weekend rozgrzebałem na nowo swojego domowego Kubernetesa, więc mam sobie w miarę estetycznie wyglądający klasterek na 5 Raspberry Pi’ach.
Łukasz Kałużny: Więc przez to, że mi się tam coś rozwaliło, co można zobaczyć we wpisie, stwierdziłem, że już go muszę przeinstalować, sobie przekonfigurować. Ja siadłem i dopisałem do tego krótki techniczny wpis wrzucając troszeczkę detali jak programowo uzyskać wysoką dostępność nawet na takim małym ustrojstwie.
Szymon Warda: Czyli jesteś w stanie zapalić diodę korzystając z Kubernetesa.
Szymon Warda: Znaczy, nabijam się ale wpis faktycznie jest niezły. To tak obiektywnie generalnie. Bo konkretnie bym jakąś szyderę zrobił, ale jest ok.
Łukasz Kałużny: Technicznie jest parę fajnych tricków takich jak na przykład jak zrobić chamski client load balancing i fail over nie mając fizycznych load balancerów. To są takie rzeczy jak ktoś grzebie w onpremie. To są takie ciekawostki jak bardzo można w dzisiejszym czasie programowo pewne rzeczy zrobić.
Szymon Warda: Spoko, to ja się dorzucę, bo trochę tak mi się to włącza, znaczy pomysł w ogóle jest super i nie stawiałbym tego na Raspberry po prostu, bo mi się… Nie do końca widzę potrzebę de facto i co tam dalej z tym zrobić. Więc tak kontrując, czy dodając bardziej serię wpisów - jestem na to trochę za stary, to mam jeden ciekawy wpis odnośnie takiego przehajpowania pewnych podejść. Wpis jest prosty - screen test mining.
Szymon Warda: O co w tym chodzi? Promocja czegoś, co kiedyś bym mógł “o, fajny pomysł”, znaczy nic wybitnego. Mianowicie jak ustalić kto jest ownerem maszyn wirtualnych tudzież systemów poprzez wyłączenie ich. Jak test? Bo myślę tak w ramach korporacji. Wyobraź sobie, że np. Wyłączasz serię VMek czy jakąś tam jedną VMkę i czekasz na to, że ktoś się zgłosi bo coś mu nie działa. Ile jest systemów, które robią raporty załóżmy miesięcznie, a nie muszą chodzić? To jest tak absurdalnie zły pomysł jak to tylko możliwe. W ogóle.
Łukasz Kałużny: No cmdb governance i auto kasowanie po prostu, o, nieuchronność auto kasowania.
Szymon Warda: Tak, ale niektóre pomysły. Ja mam wrażenie, że to tak trochę z serii tiktokowych pomysłów co naprawić. I tak dalej, ale na pierwszy moment brzmi okej, sensownie, pomyślisz chwilę mówisz nie, nie, nie, to w ogóle to to można wylecieć z pracy w ogóle.
Łukasz Kałużny: Raczej cmdb by nie działał. Aczkolwiek przypominam sobie takie rzeczy, wypnijmy kabel, zobaczę kto się zgłosi.
Szymon Warda: Też zrobiłem tak kiedyś, bez dwóch zdań.
Łukasz Kałużny: Z drugiej strony jak mówimy o korpo przypomina mi się mój kolega Paszczak. Stare czasy jak robił jakąś migrację w Telekomunikacji Polskiej i zgubili mu 50 fizycznych serwerów czy migracji na pół roku.
Łukasz Kałużny: Więc kur… Zdarza się.
Szymon Warda: Zdarza się, ale nie wydaje mi się, żeby to był dobry i odpowiedzialny sposób na realizowanie rzeczy. Czasami ma to sens, ale nie każdą maszynę można tak wyłączyć.
Łukasz Kałużny: Nie, dlatego w dzisiejszych czasach ta nutka procesu cmdb auto ubijania jest dobrą rzeczą, że taka nieuchronność auto ubijania. Tylko wiesz co z drugiej strony patrząc się na to tak jak poleciały teraz zwolnienia w Microsofcie to było widać po stronie właśnie całego systemu partnerskiego. Było widać, że chyba przekazanie obowiązków było w stylu amerykańskim, więc martwiliśmy się dopiero jak sytuacja ustabilizowała się na nowo, bo tam pewne raporty się nie przetwarzały przez półtorej miesiąca.
Szymon Warda: Dobrze, że ruszyłeś temat odnośnie zwolnień, bo mam link odnośnie tego. O tak więc przejście nie było zamierzone, żeby nie było. Fajny wpis, który robi analizę, bo dużo słyszymy teraz o zwolnieniach. Robi analizę właśnie rynku liczby ofert na wielu rynkach i teraz jak to ciekawie wygląda jak ten wpis przeglądamy to widzimy, że faktycznie najwięcej ofert pracy było w 2021 roku, co by w miarę się zgadzało de facto jak to wyglądało i widzimy super korelację między rynkiem amerykańskim, kanadyjskim, w Australii.
Szymon Warda: To są te wykresy niemalże podobnie. Natomiast jak popatrzymy, poscrollujemy dalej, to rynek japoński zachowa się zupełnie inaczej i de facto rynki europejskie już zachowują się inaczej. Nie ma aż takich spadków i ta charakterystyka zatrudnień jest zupełnie inna, załóżmy we Francji. Liczba ogłoszeń o pracę między ‘21 a teraz. To jest wykres cały czas rosnący tak naprawdę. Czyli coś… Zupełnie inne zachowania tak naprawdę. I czemu o tym wpisie mówię? Bo dużo słyszymy o fakcie, że Amazon, MS, dużo, dużo firm amerykańskich zwalnia. Niestety w tym wpisie nie ma podanego rynku polskiego. Szkoda, wydaje mi się, że jakieś zwolnienie było ale jednak wydaje mi się, że też nie możemy ekstrapolować tego co widzimy na InfoQ, w dużych mediach zagranicznych na to co się dzieje na polskim rynku. Takie spostrzeżenia.
Łukasz Kałużny: Wiesz co, na naszym rynku jesteśmy takim outsourcingiem też dla Stanów, więc…
Szymon Warda: Łukasz, jesteśmy Indiami Europy.
Łukasz Kałużny: Różnie bym to określił, ale bardziej Rumunia, ale w zależności jak na to patrzeć, ale tak jest, to jestem ciekaw jak to wygląda, wiesz co, nie tylko ten big tech, ale to co się dzieje też w branży całej powiązanej z wizkami i innymi rzeczami z kasą do wydania od inwestorów, a nie od klientów.
Łukasz Kałużny: To też jest, byłoby ciekawe ujęcie.
Szymon Warda: Tak, ważne co do tego wpisu jest to, żeby nie ekstrapolować tego, co się dzieje za oceanem koniecznie na lokalny rynek, bo on jest trochę inny mimo wszystko. Takie słowo uspokojenia, jak już mówimy o pracy, zatrudnieniu.
Łukasz Kałużny: Dobra, teraz podejdźmy do rzeczy, którą InfoQ co jakiś czas aktualizuje, czyli InfoQ Trend Report i tutaj architektoniczne. Patrząc się na sam opis i inne rzeczy, to co się pojawiło w tej części innovators. Są rzeczy, o których wspominaliśmy. Oczywiście Large Language Models są na pierwszym miejscu.
Szymon Warda: Kto by się spodziewał?
Łukasz Kałużny: Tak, kto by się spodziewał i rzeczy, które są tutaj… Jest dużo rzeczy, o których mówiliśmy, że są istotne, więc jest supply chain security jest design force accesibility i policy as a code jako właśnie takie rzeczy dla innowatorów. Lecąc… Tutaj chyba nie ma co dyskutować. To są rzeczy, które się po prostu pojawiają.
Szymon Warda: I chociaż dziwi mnie, że GraphQL Federation jest dopiero dla innowatorów.
Łukasz Kałużny: Wiesz co, zastanawiałem się nad tym, czy w ogóle to poruszać. Dla mnie z GraphQLem jest nie do końca dojrzałe.
Szymon Warda: Możliwe? Tak.
Łukasz Kałużny: Nie ma takiego jasnego przekazu jak wokół resta. Jak z tego korzystać? I też wiesz. I to jest dla specyficznych zastosowań. Coraz bardziej patrzę na GraphQL’a, to jest dla pewnego rodzaju projektów. Jak większość tak jest z naszego poletka Enterprisowych to tam GraphQL jakoś specjalnie…
Szymon Warda: Limitowany.
Łukasz Kałużny: Tak. Jak budujesz produkt. To jest już ciekawsze. Jak budujesz taki zewnętrzny produkt dedykowany to jest trochę ciekawsza rzecz.
Szymon Warda: A ja bym powiedział inaczej, graphql sprawdza się świetnie. Jeżeli OK, produkt budujesz to jedna rzecz, ale masz faktycznie realnie duże zespoły frontendowe i duże zespoły back endowe, które są od siebie mocno oddzielone, bo graph QL… Wartość jest taka, kiedy faktycznie nie masz pojęcia gdzie frontend za chwilę pójdzie, masz zbyt dużą inercję tego całego zespołu. Generalnie one po prostu będą szły. Więc tu jest wartość, dziwi mnie że samo Federation jest dopiero dla innowatorów. No ale ok, niech będzie.
Łukasz Kałużny: Dobra. Early adopters. I to jest dla mnie śmiech, bo to już powinniśmy przepraszam, ale kurwa, powinniśmy robić to od dawna. To są wszystkie design for security. Resiliance. Observability.
Szymon Warda: Jeszcze Micro frontends.
Łukasz Kałużny: Wiesz co, tak mikro frontendy to przepraszam, to już w ogóle dla mnie to jest raczej majority w takim rozumieniu. Z fajnych rzeczy, które się pojawiło, o którym się mało mówi, to jest async API. Kolejne podejście do standaryzacji schematów i komunikacji. Tym razem asynchronicznej, bo wokół asynchronicznej były eventy, które są teraz w CNCF’ie. Gdzieś Kafka Registry, ale async API patrząc się od strony dokumentacyjnej i porządku wprowadza to, co zrobiło… Swagger swego czasu.
Szymon Warda: Tak, ale async API ma już z 2, 3 lata lekką ręką. Nie pamiętam jak się na to natknąłem.
Łukasz Kałużny: To się dopiero przebija.
Szymon Warda: Znaczy tak, ale… W ogóle jako pomysł i standaryzacja to jest bardzo dobre. De facto ma to sens mówię właśnie odnośnie Swaggera, to jest wcale nie dużo dalsze od Swaggera de facto tak naprawdę ideowo.
Łukasz Kałużny: Ideowo to tak. To jest Swagger dla komunikatów plus ta rzecz z całością… Jak sobie przypomnę nazwę, to załączę linka do tego. Są też już produkty gdzie możesz sobie zrobić katalog właśnie, czyli katalog na bazie tego eventu i innych rzeczy i to jest naprawdę mocna, dobra rzecz pod tym względem.
Szymon Warda: Też cieszę się, że to wychodzi i że jest potrzeba standaryzacji, dokumentacji tego to będzie faktycznie niezłe.
Łukasz Kałużny: Tak. I kolejna rzecz, trochę dziwiąca ten lowcode, nocode i workflow and decision Automation Platforms. Inaczej, bo nie patrzyłbym jako to, na to… Mocny trend. Tylko to są narzędzia wspomagające, które z nową nazwą przechodzą kolejną ewolucję.
Szymon Warda: Czy to jest coś, co istnieje cały czas? Zgodziłbym z tym, że to nie jest coś, co nagle będzie miało większą adopcję albo cokolwiek w tym stylu? Nie, To po prostu będzie istniało i nie będzie za bardzo miało większego wpływu.
Łukasz Kałużny: Miało funkcję wspierającą, ale ciągłą.
Szymon Warda: Tak.
Łukasz Kałużny: Dobra. No i kolejna rzecz, która, czyli early majority. To co… I ostatnia pozycja z tej listy - Programowanie Funkcyjne.
Szymon Warda: Nie, w ogóle nie. Raczej… Dla bardzo wąskich case’ów. O ile bardzo lubię programować funkcyjnie, to to jest bezsensowne totalnie. Tak samo jak Linux na desktopach. Generalnie Linux dla mas. O tym się mówi od nie wiem ilu lat i to się nie przebije De facto do ogólnego trendu, po prostu nie.
Łukasz Kałużny: Najlepiej pisać proceduralnie i mieć święty spokój.
Szymon Warda: Łukasz… Nie dawaj swoich rad developerskich, bo… nie.
Łukasz Kałużny: Nie. Dobra.
Szymon Warda: Ale popatrzmy, ale tak w ogóle ten early majority. Tam jest w ogóle dużo rzeczy, które dla mnie są dziwne.
Szymon Warda: Jest Service Mesh, który ma adopcję. Nie powiedziałbym, że wcale jest aż tak późno. Ja bym to dał na early adopters bardziej.
Łukasz Kałużny: I to się stamtąd nie rusza. Długo, długo, bo…
Szymon Warda: Dokładnie, to jest tak, powinno być wcześniej dużo.
Łukasz Kałużny: Znaczy, wiesz co, tylko patrząc się znowu, że Service Mesh uzyskał, wiesz, już taki stopień wygrzania. Jako…
Szymon Warda: Że to nie jest nowinka, ludzie już tego się nie boją.
Łukasz Kałużny: Tak, to jest dobre miejsce i on już więcej rynku za dużo nie zyska.
Szymon Warda: Zobaczymy co się stanie jeżeli będzie przeniesiony na poziom kernela i będzie bez… Sucker less.
Łukasz Kałużny: Tak. Jak to się… Zobaczymy. Jak sobie PFAmi pójdzie to tak to tam może być. Wtedy może nie będę tak na to narzekał w trybach auto. Dobra, no i jeszcze actor, actor model, który już znamy od lat, po prostu od lat.
Szymon Warda: Tak. Całe Akowe modele itd. Projekt Orleans od Microsoftu to po prostu jest, ale wydaje mi się, tu będę bronił mimo wszystko, że faktycznie ma coraz większe. Znaczy to to jest trochę jak Postgres. Od lat, ale ma coraz większą adopcję. Powoli bo powoli, ale coraz więcej jest wykorzystane.
Łukasz Kałużny: Wiesz co. To jest dla mnie tak jak z programowaniem funkcyjnym. System…
Łukasz Kałużny: Powiedzmy, że dla mnie actor model jak i programowanie funkcyjne to jest ułożenie pewnego bardzo konkretnego sposobu myślenia i modelowania problemów.
Szymon Warda: Zgodziłbym się. Ale ta adopcja, która jest coraz wyższa… I wydaje mi się, to nie do końca funkcyjne, chociaż model aktorów nadaje się świetnie do programowania funkcyjnego to jest bardziej to, że ludzie zaczynają rozumieć jak włożyć problem w model aktorów i model aktorów… się spina super w kontekście skali tak dużej i w kontekście serverlessa. On się spina.
Łukasz Kałużny: Tak tam można coś zrobić. Dobra, tu się jeszcze pojawiły ADRy, więc faktycznie chcielibyśmy, żeby były szerzej, ale tak po prostu jest.
Szymon Warda: Mnie bardziej bawi tutaj Correctly Built Distributed Systems.
Łukasz Kałużny: To jest Early Adopters. Zdecydowanie early adopters.
Szymon Warda: To sformułowanie tego stwierdzenia jest przezabawne.
Łukasz Kałużny: Tak, określenie jest genialne. Dobra, ja jedną rzecz bym tutaj dorzucił jeszcze jeden wpis. Jest taki blog luźniejszy informatyk zakładowy i tutaj, bo powiedzieliśmy sobie właśnie ten design for sustainability i gadaliśmy o tych carbon footprintach, więc bardzo fajne porównanie. Takie na podstawie ile produkuje CO2 zapakowana domena na jakimś hostingu po prostu z tą stroną hostingu i jak bardzo kalkulatory?
Łukasz Kałużny: Jaki bardzo jest duży rozstrzał żeby to policzyć. Więc tutaj takie dość dobre podejście, nawet wskazujące na badania, metabadania. Ile kosztuje przesłanie? Co jest najciekawsze? Jak policzyć ile kosztuje przesłanie GB, ile przez internet, ile kosztuje energii.
Szymon Warda: Dla mnie to pokazuje jedną rzecz, po pierwsze, że ten rynek jest super niedojrzały. Druga rzecz, że będzie się wokół niego więcej działo, bo jest ciśnienie na to, nawet już nie licząc na fakt tego, że będziemy offsetować ten carbon i tak dalej i tak dalej. To jest bardziej fakt tego, że jak mamy liczby, to zaczniemy je optymalizować, obniżać. Nieważne co jest źródłem tych liczb, co je obliczyło, ale jeżeli możemy to zamienić na liczby, to możemy to optymalizować i trend rynku będzie taki, że jednak będziemy patrzyli jak obniżyć te wartości. I to jest bardziej dla mnie klucz tego wpisu. Tak naprawdę to, że rozstrzał jest pełny, jak najbardziej od tego nie uciekniemy. Dobra, to ja zamknę jednym wpisem. Wpis od bloga engineeringowego od Slacka. Całkiem ciekawy wpis. Wpis jest o technology life cycle, nie jest niczym super nowością i tak dalej.
Szymon Warda: Jest fajnym ułożeniem tematu jak podchodzić do dojrzałości software’u, które my dostarczamy i czemu to jest sensowne. Po pierwsze. Układa poziomy dojrzałości software’u np. jesteśmy Alfa, Beta, active i maintenance. Na końcu jest jeszcze depreciated. Układa w kilka wymiarów, tak naprawdę, czyli zwraca uwagę na to, żeby komunikować na każdym z tych etapów de facto software’u, komunikować kilka, kilka wymiarów, jak zachowuje się dany projekt. Jak załóżmy acceptance of new customers. Czyli mówimy czy to jest projekt do używania, czy jest nie do używania, czy jest tylko dla odważnych, czy jak to będzie wyglądało, czyli jasna komunikacja do third party, czy może raczej do zespołów w ramach organizacji. Jakie jest tego użycie i czy powinno się tego używać? Potem mamy - Jak podchodzimy do feature requestów, no nie? Czy to jest tylko dla nas i po prostu nie? Czy przyjmujemy Requesty czy nie? I to jest fajny sposób na komunikację generalnie, szczególnie w większych organizacjach i zespołów. Gdzie jesteśmy? Idziemy dalej. Bug reports. Czyli jakie mamy procedury, Jak to wygląda, jak przyjmujemy bugi? Czy te bugi poprawiamy? Co się z tym dzieje? Security and compliance reports, czyli de facto czy je dostarczamy - powinniśmy mimo wszystko, czy to jest totalnie do wewnętrznego użytku i właściwie nie powinno być pisane na zewnątrz.
Szymon Warda: I tak dalej, i tak dalej. Potem mówimy documentation quality, czyli mówimy nasza dokumentacja jest okej, to jej używajcie, czy jest dopiero rozwijana, czy dopiero na roadmapie, jak to wygląda, jak i potem? Generalnie co jest jeszcze super ważne, jaki kolejny krok dla tego wewnętrznego software’u czy też tam zewnętrznego software’u widzimy. Tu mówię to nie jest wpis, który robi jakąś rewolucję, ale jest wpis, który jeżeli myślimy właśnie o komunikacji, o produktach w ramach organizacji, fajny wpis, który układa de facto na co zwrócić uwagę i co w tym readme takim informacyjnym zawrzeć. Nie jest długi, sensowny, jest fajny.
Łukasz Kałużny: Ja powiem Ci tak, niektórzy powinni… Najważniejsze są te stage’e, które są dla mnie pokazane, czyli przejścia pomiędzy nimi. Co oznacza active, a co oznacza maintenance? Bo to jest taka rzecz, która się bardzo mocno w komunikacji zaciera, więc te przejście się zaciera. I drugie przejście, które jest w ogóle strasznie rozmyte, to jest przejście od wskazanego na przekreślenie do wygaszania.
Szymon Warda: Tak, znaczy odnośnie active wydaje mi się, że tutaj akurat język polski się broni, mamy aktywny rozwój i utrzymanie i to już daje jasny komunikat generalnie.
Łukasz Kałużny: Utrzymanie tak, ale wiesz co, tylko to jest w definicji oczekiwań.
Szymon Warda: Tak.
Łukasz Kałużny: Bardziej mówię tutaj o definicji oczekiwań właśnie pomiędzy właścicielem, że tak powiem biznesowym oprogramowania użytkownikiem, a tym, kto to dostarcza.
Szymon Warda: Wpis… Wbrew pozorom tego, że temat jest nudny, to właśnie ponieważ temat jest trudny i często nie myślimy to jest fajnie uporządkowany i to jest naprawdę siła tego wpisu. Dla mnie. Miły, konkretny. Zdecydowanie jak ktoś ma problem polecam. Dobrze, to kończymy.
Łukasz Kałużny: Kończymy.
Szymon Warda: Trzymajcie się, na razie, hej.
Łukasz Kałużny: Hej.