Better Software Design

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

CQRS, czyli Command Query Responsibility Segregation, jest wzorcem wyjątkowo popularnym i powszechnie stosowanym w wielu systemach. Mało kto jednak sięgnął po oryginalny dokument autorstwa Grega Younga, który opisuje założenia tego konceptu architektonicznego i z czasem obrósł on kilkoma mitami.Dziś w podkaście ponownie gości Oskar Dudycz, z którym na tapet weźmiemy zarówno mity jak i fakty dotyczące wzorca CQRS. A gdy przy drugim mikrofonie pojawia się Oskar, to wiadomo, że będzie do bólu pragmatycznie...W tym odcinku rozmawiamy m.in. na temat:czym jest wzorzec CQRS i jaki ma związek z językiem Eiffel i ideą CQS Bertranda Meyera,związku z wzorcem Command & Command Handler,xszeregu mitów, którymi CQRS obrósł na przestrzeni lat, np. koniecznością stosowania asynchroniczności,różnych możliwych sposobach, w jaki CQRS może zostać zaimplementowany w systemie.Materiały dodatkowe:CQRS, oryginalny dokument Grega Younga, opisujący koncept CQRSCQRS Bliki, artykuł na bliki Martina Fowlera o omawianym wzorcuCQRS facts and myths explained, artykuł na blogu Oskara na poruszony w rozmowie tematOd CRUD do CQRS w praktyce, prezentacja Oskara z konferencji bITconf 2022Zapraszam Cię także do odwiedzenia moich innych miejsc w internecie:https://twitter.com/mariuszgilhttps://instagram.com/mariuszgil_dev/https://youtube.com/c/MariuszGil

Mylić się to rzecz ludzka, propagować automatycznie te błędy to DevOps... Tym razem na tapet bierzemy historie o tym, jak to produkcja płonęła i jakie wnioski zostały z tego wyciągnięte.Dziś moimi gośćmi w podkaście są Jarek Pałka i Wojtek Ptak, a w takim gronie nie wypada zamiatać spraw pod dywan. A że warto uczyć się na błędach, a najlepiej tych popełnianych przez innych, wyciągniemy parę naszych błędów z przeszłości. Oprócz tragikomicznych aspektów niektórych z przytoczonych tu sytuacji, będzie to bardzo dobry wstęp do znacznie ważniejszych wątków.W tym odcinku rozmawiamy m.in. o:naszych błędach i wyciągniętych wnioskach,różnych źródłach problemów i ich typach, od błędów ludzkich po limity infrastrukturalne,mierzeniu rzeczy, by określić wpływ fuckupu na otaczający nas świat,przygotowywaniu się na incydenty, bo to nie kwestia czy wystąpią, tylko kiedy,jakie działania podejmować w trakcie problemu,kulturze postmortems, lessons-learned i upewnianiu się, że wnioski,jak i kiedy komunikować o problemach,co zrobić, gdy fala sztormu odpłynie w dal...Będę bardzo zobowiązany za wypełnienie krótkiej ankiety na temat tego odcinka.Materiały dodatkowe:Death March - Edward YourdonThe Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win - Gene Kim, Kevin Behr, George SpaffordNormal Accidents: Living with High-Risk Technologies - Charles PerrowThe Idealcast with Gene Kim by IT Revolution - rozmowa z dr. Ronem Westrumem m.in. na tematy związane z problemami w złożonych systemach (od 34:45)The Facebook Outage - postmortem problemu FacebookaRoot Cause Analysis: A Quick Guide - opracowanie na temat wspomnianego w odcinku RCASoftware Testing Lessons Learned From Knight Capital Fiasco - analiza przypadku Knight Capital i utraty ponad 400M USD

Gościem jest Piotr Gawrysiak, Chief Data Scientist w mBanku i profesor Politechniki Warszawskiej, znawca AI i ML. Rozmawia o praktycznych zastosowaniach uczenia maszynowego w bankowości oraz o wyzwaniach związanych z danymi. Piotr zdradza, jak zespół analizuje dane i tworzy rozwiązania data-driven. Porusza również rolę technologii, znaczenie edukacji w analityce oraz wpływ narzędzi AI, jak ChatGPT-3, na pracę programistów. Jego doświadczenia z dziedziny proces mining są inspirujące!

Wiele tematów potrafi podnieść temperaturę rozmowy, zaczynając choćby od osławionego pytania "taby czy spacje". Ale kiedy skręcamy w rejony związane z Agile i pada słowo SCRUM, konwersacja często przechodzi na zupełnie nowy poziom. Do rozmowy na temat realiów SCRUM-a i sposobu jego stosowania zaprosiłem Kubę Szczepanika i Jacka Wieczorka, których wiele osób zna np. ze świetnego podcastu Porządny Agile.W tym odcinku rozmawiamy m.in. na temat:SCRUM Guide i jego stosowania w praktyce,codziennych porannych teatrzykach,wybierania ze SCRUM-a tylko jego elementów, czyli o tzw. SCRUM-Butachzastępowania go znacznie lepszymi i bardziej dopasowanymi technikami,kulturze organizacji i SCRUM Masterach,przypadkach, gdzie te metoda ma sens i gdzie go zupełnie nie ma...Zapraszam!Materiały dodatkowe:PorządnyAgile.pl, podcast Kuby i Jacka na tematy związane z podejściami zwinnymiKiedy SCRUM nie jest odpowiedzią, #68 odcinek podcastu Porządny Agile rozwijający wątek o niedopasowaniu SCRUM-a do danej sytuacjiLabirynty SCRUM-a, książka autorstwa Jacka WieczorkaAgile247.pl, sporo właściwej wiedzy o Agile'u, można tu znaleźć wiele artykułów obu gościZapraszam Cię także do odwiedzenia moich innych miejsc w internecie:https://twitter.com/mariuszgilhttps://instagram.com/mariuszgil_dev/https://youtube.com/c/MariuszGil

Niezależność od frameworka, interfejsu użytkownika, bazy danych i innych systemów zewnętrznych, a także wsparcie testowalności - to podstawowe filary takich konceptów architektonicznych jak Clean / Hexagonal / Onion / Sreaming Architecture, DCI, BCE. Poszczególne podejścia różnią się w szczegółach, jednak w zbliżony sposób podchodzą do rozdzielania systemu na mniejsze, dedykowane warstwy. Z moim dzisiejszym gościem, Oskarem Dudyczem przyglądamy się dziś pierwszej pozycji tej listy i analizujemy mocne i słabe strony Clean Architecture, zaproponowanej przez Roberta C. Martina.W tym odcinku rozmawiamy m.in. o:czym jest Clean Architecture i skąd wywodzi się ta idea?stosowaniu zasad SOLID na poziomie architektury całego systemu,proponowanych w Clean Architecture zasadach i warstwach,zaletach i wadach tego rozwiązania,pewnych podobieństwach i różnicach w odniesieniu do np. Hexagonal Architecture,stosowaniu tego rodzaju architektury w kontekście projektu i zespołu.Zapraszam!Materiały dodatkowe:The Clean Architecture - wpis na blogu Roberta C. Martina (Uncle Boba), który można także znaleźć w jednym z rozdziałów książki Clean ArchitectureClean Architecture - książka autorstwa Roberta C. Martina, 2017, wydawnictwo PearsonPutting SOLID into Perspective - artykuł Jeremiego Millera o stosowaniu zasad SOLID w kontekście projektowania i rozwoju architekturyPowiązane z tematem artykuły na blogu Oskara:What onion has to do with Clean Code?Generic does not mean SimpleHow to slice the codebase effectively?

W trakcie implementacji systemu często stajemy przed problemem kontroli uprawnień i decydowaniu, czy pozwalamy użytkownikowi wykonać określoną operację. Ten jeden, pozornie prosty IF w kodzie jest pretekstem do dzisiejszej rozmowy z Bartkiem Słotą, na temat kontroli uprawnień w projekcie opartym o techniki Domain-Driven Design.Na konkretnym przykładzie przejdziemy proces analityczno-modelarski i rozważymy możliwe opcje, ich zalety i wady. Materiały dodatkowe:Fragment EventStormingu, a także mapa kontekstów z przedstawionymi relacjami znajdują się na boardzie Miro: https://miro.com/app/board/uXjVPq0-LUM=/W odcinku pojawiają się narzędzia i herystyki modelowania, o których szerzej posłuchać można we wcześniejszych odcinkach podcastu:BSD #43 O subdomenach biznesowych ze Sławkiem SobótkąBSD #37 O Context Mappingu z Bartkiem SłotąBSD #26 O perspektywach Being, Behaving, BecomingBSD #8 O Bounded Contextach ze Sławkiem Sobótka