Better Software Design

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 GreeceScalable User Privacy: Crypto Shredding at Spotify, prezentacja Brama Leendersa na temat przetwarzania danych prywatnych w SpotifyGDPR - General Data Protection Regulation, zestaw regulacji na temat prywatności i ochrony danych prywatnychTombstoning i scavening w EventStoreDB, fragment dokumentacji na temat sposobów usuwania zdarzeń

Sebastian Buczyński, lider techniczny w SOS Labs, jest pasjonatem inżynierii oprogramowania i szkoleń w Pythonie. W rozmowie podejmuje temat funkcji dopasowania w architekturze ewolucyjnej. Uczestnicy omawiają elastyczność decyzji projektowych oraz adaptacyjność architektury w zmieniających się wymaganiach biznesowych. Zwracają uwagę na krytyczne błędy w refaktoryzacji oraz znaczenie kultury eksperymentowania w zespole. Buczyński dzieli się również praktycznymi przykładami, ilustrując wdrażanie nowoczesnych podejść do przetwarzania danych.

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 & AdaptersHexagonal architecture, nowsza wersja oryginalnego wpisu Alistaira Cockburna na temat architektury heksagonalnej z 2005 rokuHexagonal architecture @ wiki c2, wpis na blogu Warda CunninghamaSmallerWebHexagon, 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, 2017To Sell is Human: The Surprising Truth About Moving Others, Daniel H. Pink, 2012The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully, Gerald M. Weinberg, Virginia Satir, 1985 - klasyka gatunku, wielokrotnie wspominana w poprzednich odcinkachOdcinek 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 życiaThe most expensive bug in history..., poruszona już w podkaście historia firmy Knights Capital, zakończona m.in. błędnym wykorzystaniem feature flagiFeature Toggles - Why and How to Add to Your Software, 2-godzinny tutorial na temat stosowania toggli z użyciem UnleashaUnleash Quickstart, skrócona wersja tutorialaFeatureFlags.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 tymkoncepcie 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 MartraireLeaving Documentation, or Living Documentation?, prezentacja na wspomniany temat autorstwa Cyrille'a z konferencji SoCraTesDocumenting Software Architectures: Views and Beyond, Felix Bachmann, Len Bass, David Garlan, 2002P3 Model, strona projektu Marcina i Łukasza Szydło na GitHubie, na ten moment informacyjnie o projekcieDokumentacja, która sama się pisze, prezentacja Marcina z Boiling Frogs i 4Developers 2023marcin@twitter, profil Marcina na TwitterzeZapraszam!

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, 2019Empowered: Ordinary People, Extraordinary Products, Marty Cagan, Chris Jones, 2020Product 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 MeetingsSpring 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ędziCan I Deploy, jedno z narzędzi wchodzących w skład Pacta, wspomagające proces wdrożenia systemuIntroducing Contact Testing with PactFlow, playlista kilku ciekawych filmów przedstawiających użycie Pacta w omawianym w odcinku kontekścieZapraszam Cię także do odwiedzenia moich innych miejsc w internecie:https://twitter.com/mariuszgilhttps://instagram.com/mariuszgil_dev/https://youtube.com/c/MariuszGil