Eventy świetnie pozwalają rozdzielać duże systemy na mniejsze części i i przenosić między nimi dane. Każda usługa może wówczas je przetwarzać w oparciu o własną logikę biznesową. Problem w tym, że propagacja danych w systemie jest dość prosta, ale ich usunięcie już niekoniecznie...

O tym, w jaki sposób możemy rozwiązywać problem przetwarzania danych prywatnych rozmawiam dziś z Oskarem Dudyczem. I choć skupiamy się przede wszystkim na architekturach zdarzeniowych, to w zasadzie wszystkie omawiane techniki można bez problemu zastosować również w innych systemach.

W tym odcinku razem z Oskarem rozmawiamy m.in. o:

• prywatności niektórych danych,
• usuwaniu danych vs utracie możliwości ich dalszego przetwarzania,
• strategiach "zapominania" o danych prywatnych w architekturach eventowych,
• czym jest i jak działa crypto-shredding, tombstoning czy scavenging,
• GDPR i o tym, o czym zwykle mało pamięta się w projekcie...

Materiały dodatkowe:

• How to deal with privacy and GDPR in Event-Sourced systems, prezentacja Oskara na omawiany w odcinku temat z konferencji Devoxx Greece
• Scalable User Privacy: Crypto Shredding at Spotify, prezentacja Brama Leendersa na temat przetwarzania danych prywatnych w Spotify
• GDPR - General Data Protection Regulation, zestaw regulacji na temat prywatności i ochrony danych prywatnych
• Tombstoning i scavening w EventStoreDB, fragment dokumentacji na temat sposobów usuwania zdarzeń

"Architekci muszę bez przerwy oceniać cechy architektury, aby upewnić się, że ciągle zapewniają one jakość i nie stają się antywzorcami..." Ten cytat z książki "Building Evolutionary Architectures: Support Constant Change" autorstwa Neala Forda, Rebeki Parsons i Patricka Kua dotyczy jednego z fundamentów architektury ewolucyjnej, czyli tzw. funkcji dopasowania - Fitness Functions.

Funkcje te pozwalają konkretnie ocenić dopasowanie architektury oprogramowania względem postawionych wymagań i podejmować świadome decyzje odnośnie wprowadzania zmian. Czym są wspominane tu funkcje, jak można je definiować i weryfikować, a także czym jest architektura ewolucyjna, o tym rozmawiamy z moim dzisiejszym gościem, Sebastianem Buczyńskim.

Zapraszam!

Materiały dodatkowe:

• Building Evolutionary Architectures: Support Constant Change, Neal Ford, Rebecca Parsons, Patrick Kua, 2017
• Building Evolutionary Architectures, prezentacja Rebeki Parsons, Neala Forda i Jamesa Lewisa z konferencji GOTO 2023
• Evolutionary Software Architectures, prezentacja Neala Forda z Voxxed Days
• Evolutionary Architecture from an Organizational Perspective, artykuł jednego z gości Better Software Design, Radka Maziarki na temat dopasowania architektury do przedsiębiorstwa

Konferencja PHPers Summit 2023 była świetną okazją do tego, aby zrobić coś zupełnie inaczej w podkaście. Mikrofony i reszta sprzętu wylądowała w jednej z hal Międzynarodowych Targów Poznańskich, na scenie zasiedli obok mnie Michał Giergielewicz i Grzegorz Korba z trójmiejskiego GetResponse, a na sali pojawiło się kilkaset zainteresowanych rozmową osób.

Summit i 10-lecie community były świetną okazją do tego, aby to właśnie słuchacze napisali scenariusz tej rozmowy. Pojawiały się pytania z sali i na chacie, a zaplanowane na sam koniec konferencji 45 minut nagrania przeciągnęło się do 1.5 godziny, za co wszystkim tam zebranym jeszcze raz dziękuję!

Zapraszam!

Idea zaproponowanej przez Alistaira Cockburna architektury heksagonalnej ma już prawie 20 lat. Ale jak krótko i rzeczowo opisać założenia Hexagonal Architecture, czy też Ports & Adapters? I jak to przekłada się na kod systemu?

Każdy koncept można bardzo mocno i niepotrzebnie skomplikować. Nawet tak prosty w swojej istocie jak Porty i Adaptery. Dziś z moim gościem, Kubą Nabrdalikiem, wracamy do korzeni z 2005 roku i staramy się wyłuskać esencję tego wzorca architektonicznego. A jeśli przy drugim mikrofonie gości Kuba, to wiadomo, że będzie do bólu pragmatycznie i prosto w z mostu...

W dzisiejszym odcinku:

• czym jest architektura heksagonalna,
• czym są porty i adaptery,
• skąd w ogóle wywodzi się ten koncept i jak ma się do dzisiejszych czasów,
• jakie typowe błędy można popełnić stosując ten wzorzec w kodzie,
• nie zabrakło oczywiście przykładów z życia i produkcji...

Materiały dodatkowe:

• hexagonalarchitecture.org, homepage na temat Ports & Adapters
• Hexagonal architecture, nowsza wersja oryginalnego wpisu Alistaira Cockburna na temat architektury heksagonalnej z 2005 roku
• Hexagonal architecture @ wiki c2, wpis na blogu Warda Cunninghama
• SmallerWebHexagon, wspominane w odcinku repo pokazujące bazową ideę
• Hentai, repozytorium Kuby Nabrdalika pokazujące użycie hexagona z modularyzacją i innymi technikami

Subdomena czy bounded-context może być odkryta lub zamodelowana z użyciem heurystyk, które pojawiły się już kilkukrotnie we wcześniejszych rozmowach. Ale jak te koncepty mapują się na kod naszego systemu? Gdzie i jak zobaczymy w IDE ich istnienie i zakres? Odpowiedzią na te pytania mogą być opisane przez Erica Evansa moduły, zwane także pakietami.

Dziś ponownie moim gościem jest Marcin Markowski, a nasza rozmowa będzie dotyczyć wspomnianych już modułów. Będzie i teoretycznie i praktycznie, z obowiązkowym przykładem.

W dzisiejszym odcinku rozmawiamy z Marcinem m.in. o:

• decyzjach wpływających na kształt subdomen biznesowych i bounded contextów,
• modułach i ich roli w projekcie,
• organizacji kodu i struktury aplikacji w pakiety.

Materiały dodatkowe:

• Tacking Complexity in the Heart of Software, Eric Evans, rozdział poświęcony modułom,
• Modules in DDD, artykuł podsumowujący wspomniany powyżej rozdział,
• DDD Starter DotNet, przykład organizacji kodu w repozytorium Marcina,
• Modular Monolith with DDD, przykład organizacji kodu w repozytorium Kamila Grzybka,
• Modularization of domain models, darmowy rozdział książki Functional and Reactive Domain Modeling,

Kod często można zmienić relatywnie łatwo. Jednak zupełnie inaczej jest z własnymi nawykami czy podejściem. Dziś na czynniki pierwsze rozkładamy kilka typowych "dev-grzeszków", które z perspektywy osób odpowiedzialnych za całe piony IT mogą przeszkadzać w karierze. Ponieważ technologia to niestety nie wszystko...

Moim gościem jest dziś ponownie Wojtek Ptak, Executive Engineering Director oraz Head of Development w Revolut Business. A jakich tematów dotkniemy podczas rozmowy? Choćby tego, że błędem jest nieposiadanie planu. Nasza kariera nie musi się "wydarzać" i podążać od przypadku do przypadku. Ten proces może być znacznie bardziej świadomy, wsparty różnymi ćwiczeniami i działaniami. Jakimi dokładnie? Polecam posłuchać mojego gościa.

Materiały dodatkowe:

• Developer Community Keynote: The thing about burnout,
• Principles, Ray Dalio, 2017
• To Sell is Human: The Surprising Truth About Moving Others, Daniel H. Pink, 2012
• The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully, Gerald M. Weinberg, Virginia Satir, 1985 - klasyka gatunku, wielokrotnie wspominana w poprzednich odcinkach

Odcinek ukazuje się przy okazji 3 edycji szkolenia Legacy Fighter. Jeśli chcesz nauczyć się tworzyć nowy kod ściśle dopasowany do wymagań biznesowych, odporny na erozję, a także skutecznie naprawiać już istniejące legacy tymi samymi technikami, zapraszam!

Cały kod jest dostępny w kilku technologiach jest dostępny na GitHubie.

Do dziś pamiętam pierwsze wydanie pewnego projektu... 30 sekund po zakończeniu procedury rozdzwoniły się telefony i jasne już było, że choć wdrożenie może i się udało, to wydanie już niekoniecznie. Jakiś czas później sterowaliśmy zmianami w zachowaniu kodu na produkcji bez konieczności jego aktualizacji, już całkowicie bezstresowo.

Jedną z zastosowanych tam technik były Feature Toggles i właśnie na ten temat rozmawiamy z moim dzisiejszym gościem, Mateuszem Kwaśniewskim. Ponieważ jeśli na ten temat z kimś rozmawiać, to najlepiej z osobą, która pracuje przy jednym z najbardziej znanych systemów do zarządzania flagami w kodzie.

W tym odcinku rozmawiamy z Mateuszem m.in. o:

• rozdzielaniu wdrożeń od wydań projektu,
• różnego rodzajach Feature Toggle'ach i ich przeznaczeniu,
• sposobach i miejscach osadzania toggli w kodzie,
• dobrych i złych praktykach stosowania tej techniki w projekcie,
• testowaniu kodu wyposażonego we flagi.

Zapraszam!

Materiały dodatkowe:

• Feature Toggles a.k.a Feature Flags, świetny artykuł Pete Hodgsona na temat różnego rodzaju toggli, ich przeznaczenia i cykli życia
• The most expensive bug in history..., poruszona już w podkaście historia firmy Knights Capital, zakończona m.in. błędnym wykorzystaniem feature flagi
• Feature Toggles - Why and How to Add to Your Software, 2-godzinny tutorial na temat stosowania toggli z użyciem Unleasha
• Unleash Quickstart, skrócona wersja tutoriala
• FeatureFlags.pl, małe kompendium wiedzy na temat Feature Flags i podejścia Trunk Based Development

Istnieją trzy rodzaje dokumentacji. Przy czym pierwszy rodzaj to taki, który… nie istnieje. A o dwóch pozostałych dowiesz się z tego odcinka.

Dziś moim gościem jest Marcin Markowski, a rozmawiać będziemy o dokumentacji i sposobach na utrzymanie jej aktualności. Bo niestety, mało co tak przeszkadza podczas pracy jak dokumentacja, na której nie można polegać.

W tym odcinku rozmawiamy z Marcinem m.in. o:

• co i dlaczego warto dokumentować podczas prac nad projektem,
• typowych problemach z dokumentacją, w tym
• koncepcie Living Documentation autorstwa Cyrille Martraire,
• strategiach i konwencjach pozwalających utrzymać aktualność dokumentacji wbudowanej w projekt,
• założeniach modelu P3 i różnych perspektywach dokumentacji.

Nie mogło oczywiście zabraknąć wątku związanego z utrzymywaniem wiedzy projektowej na Confluence… A w kilku miejscach wodze fantazji zostaną delikatnie puszczone.

Materiały dodatkowe:

• Living Documentation: Continuous Knowledge Sharing by Design, 2015, wspomniana w odcinku książka Cyrille Martraire
• Leaving Documentation, or Living Documentation?, prezentacja na wspomniany temat autorstwa Cyrille'a z konferencji SoCraTes
• Documenting Software Architectures: Views and Beyond, Felix Bachmann, Len Bass, David Garlan, 2002
• P3 Model, strona projektu Marcina i Łukasza Szydło na GitHubie, na ten moment informacyjnie o projekcie
• Dokumentacja, która sama się pisze, prezentacja Marcina z Boiling Frogs i 4Developers 2023
• marcin@twitter, profil Marcina na Twitterze

Zapraszam!

Wytwarzanie oprogramowania, zwłaszcza tego złożonego, to gra zespołowa. A gdy w projekcie udział bierze wiele zespołów, musimy zatroszczyć się choćby o komunikację pomiędzy nimi, czy przypisanie właściwych odpowiedzialności w projekcie.

Dziś moim gościem jest Piotr Kacała, CTO i członek zarządu Displate, a rozmawiać będziemy o podejściu zwanym Team Topologies. W myśl Manuela Paisa i Matthew Sheltona, autorów książki Team Topologies, w organizacji produktowej poszczególnym zespołom można przypisać bardzo jasno określone role, co z kolei pozwala określić modele komunikacji pomiędzy nimi. Na koniec dnia, nie każdy rodzaj komunikacji w organizacji jest pomocny i właściwy...

W tym odcinku rozmawiamy m.in. o:

• o tym, co tworzy dobry zespół,
• idei Team Topologies,
• modelach współpracy pomiędzy zespołami i rolami samych zespołów,
• realiach zespołowych przy rozwoju projektu Displate.

Materiały dodatkowe:

• Team Topologies, książka autorstwa Manuela Paisa i Matthew Skeltona, 2019
• Empowered: Ordinary People, Extraordinary Products, Marty Cagan, Chris Jones, 2020
• Product Blocks, rozwijany przez Piotra katalog "klocków", narzędzi i technich pomocnych przy zarządzaniu zespołami, który mocno polecam

Projektowanie systemu rozproszonego, opartego np. o architekturę mikroserwisową, zwykle nie jest trywialne. Pojawia się tu choćby problem komunikacji poszczególnych części systemu i właściwego sposobu jej testowania...

Wspólnie z moim dzisiejszym gościem, Rafałem Maciakiem, przyglądamy się idei testowania kontraktowego, które świetnie rozwiązuje problem testowania poprawności komunikacji pomiędzy konsumentami i producentami. Co istotne, w izolacji, bez konieczności używania kosztowych środowisk i testów integracyjnych.

W tym odcinku rozmawiamy m.in. o:

• idei testowania kontraktowego,
• przykładowej budowie kontraktów,
• lokalizacji tego rodzaju weryfikacji w piramidzie testów,
• narzędziach wspierających testowanie kontraktowe,
• różnicach pomiędzy Consumer Driven Contract i Producer Driven Contract,

Materiały dodatkowe:

• Contract Testing - Spring Cloud Contract, artykuł Rafała na blogu SoftwareMill przedstawiający praktyczną stronę testowania kontraktowego z użyciem Springa,
• Save your friday's evening with Contract Testing, prezentacja Rafała z Allegro Tech Meetings
• Spring Cloud Contract in a polyglot world, artykuł Marcina Grzejszczaka na blogu Spring, pokazujący praktyczne użycie SCC,
• How Pact Works, krótkie wprowadzenie do zasady działania jednego ze wspomnianych w odcinku narzędzi
• Can I Deploy, jedno z narzędzi wchodzących w skład Pacta, wspomagające proces wdrożenia systemu
• Introducing Contact Testing with PactFlow, playlista kilku ciekawych filmów przedstawiających użycie Pacta w omawianym w odcinku kontekście

Zapraszam Cię także do odwiedzenia moich innych miejsc w internecie:

• https://twitter.com/mariuszgil
• https://instagram.com/mariuszgil_dev/
• https://youtube.com/c/MariuszGil