Better Software Design

Gościem odcinka jest Grzegorz Piwowarek, niezależny specjalista i trener programowania Java, ekspert w separacji komponentów. Rozmawia o problemach związanych ze sprzeżeniem w systemach i dylematach technologicznych. Porusza znaczenie decouplingu oraz technikach utrzymania frameworków na dystans. Dzieli się doświadczeniami związanymi z architekturą heksagonalną i wyzwaniami przy wdrażaniu narzędzi takich jak RabbitMQ i Kafka. Oferuje praktyczne wskazówki dotyczące efektywności w programowaniu oraz testowania kodu.

Mijający właśnie rok dla Better Software Design był szczególny i "naj" z wielu powodów - liczby nowych odcinków, odsłuchanych rozmów, nowych słuchaczy... Nie byłoby tego podcastu bez was, także w tym roku w formie podcastowego prezentu i podziękowania za wspólnie spędzony rok, zapraszam na odcinek specjalny.Wraz z Wojtkiem Ptakiem i Jarkiem Pałką, znanych doskonale z kilku poprzednich odcinków podcastu, rozmawiamy o karierze w IT z perspektywy naszych wspólnych... ponad 77 lat spędzonych w branży IT. W tym odcinku zaczynamy od łączenia kropek, które każdy z nas postawił na swojej developerskiej (i nie tylko) drodze...Jedną z takich moich kropek (choć niestety nie wspomnianą podczas rozmowy) było dołączenie do niektórych prac kierowanego przez Wojtka zespołu. Gdy na 2 godziny przed rozpoczęciem właściwej pracy analizuje się wspólnie wykorzystywane w projekcie techniki, wypracowuje na ich podstawie własne podejście do software developmentu, którym można się dzielić z innymi - czego chcieć więcej?Zapraszam!

"Jako użytkownik chcę przeszukać bazę książek, aby znaleźć kilka książek" - takiego rodzaju User Story są niestety dość typowe i w zasadzie niewiele dobrego wnoszą do projektu. A trudności, jakie często pojawiały się przy formułowaniu wartościowych User Story, skutkowały się pojawianiem różnych technik wspomagających ich rozpoznanie. Kuźnią wielu pomysłów były prace zespołów stosujących Extreme Programming w projektach Chrysler C3 i Connextra... Kompleksowe podejście zarówno do identyfikacji User Stories jak i ich dalszego wykorzystania z projekcie zaproponował w końcu w 2014 roku Jeff Patton, proponując warsztatową technikę User Story Mapping.W tym odcinku Better Software Design dodajemy więc User Story Mapping do naszego analitycznego toolboksa. A moim gościem w tej rozmowie jest Michał Bartyzel, który bardzo mocno wykorzystuje tę technikę w swojej codziennej pracy z zespołami. W tym odcinku rozmawiamy z Michałem między innymi o:bezużyteczności wielu historyjek typu "Jako klient chcę się zalogować, aby zrobić zakup w sklepie",odkrywaniu właściwych aktorów, ich celi biznesowych i funkcjonalności, które służą ich osiągnięciu,sposobach budowania mapy historyjek, zgodnie z założeniami User Story Mappingu,wykorzystaniu USM w projekcie,różnicach i podobieństwam pomiędzy EventStormingiem i User Story Mappingiem,sposobach prowadzenia warsztatu analitycznego.Materiały dodatkowe:It's All in How You Slice, artykuł Jeffa Pattona opisujący pierwotne założenia techniki, rozwiniętej następnie do User Story MappinguThe New User Story Backlog is a Map, drugi po artykule istotny wpis Pattona na temat problemów z historyjkamiUser Story Mapping: Discover the Whole Story, Build the Right Product, książka Jeffa z 2012 roku, przedstawiająca technikę User Story MappinguStory Map Concepts oraz Agile Story Essentials, krótkie i rzeczowe podsumowania pokazujące zasadę działania USMPolecam także zajrzeć na stronę Michała, a w szczególności na prowadzonego przez niego bloga.Zapraszam!

Stres w pracy nie jest rzadkim zjawiskiem. Pozostawiony sam sobie przez dłuższy czas, może zacząć wyrządzać nam więcej szkód, w tym doprowadzić do syndromu wypalenia zawodowego.O tym jak może się objawiać wypalenie w naszym codziennym życiu, jak można sobie z nim radzić i jak reagować, gdy problem zaczyna dotykać osoby w naszym otoczeniu - o tym wszystkim rozmawiamy dziś z Olą Kunysz. Bez technologii i architektury, ale o własnych doświadczeniach z wypaleniem w kontekście branży IT. Materiały dodatkowe:The Burnout Index, darmowy test Yerbo wspomagający określenie poziomu ryzyka zagrożenia wypaleniem,Test BAT12, prostszy test w języku polskim,Nie wypalaj się! Jak żonglerka może uratować pracowników IT?, prezentacja Oli na TedX KoszalinOla@Instagram, profil Oli na Instagramie, gdzie dzieli się m.in. informacjami na tematy związane z wypaleniem zawodowym

Eventy stanowią naturalny sposób komunikacji w systemach rozproszonych. Jednak przesyłanie i dalsze przetwarzanie zdarzeń z jednego systemu do drugiego zazwyczaj wymaga określonej infrastruktury i wprowadza do systemu nowy rodzaj złożoności. Zawodność przesyłania danych, unikanie wielokrotnego przetwarzania tych samych wiadomości, zapewnianie kolejności ich przetwarzania czy odpowiedniej wydajności całej aplikacji - to tylko niektóre z czekających tu wyzwań.Dziś zapraszam na rozmowę o message brokerach i event-streamingu. Wraz z dzisiejszym gościem, Piotrem Gankiewiczem, rozmawiamy między innymi o:różnicach pomiędzy message-brokerami a platformami do event-streamingu,wykorzystywanej w obu przypadkach terminologii,zrównoleglaniu procesów i zapewnianiu odpowiedniego porządku przetwarzania pochodzących ze strumieni zdarzeń.Zapraszam!Materiały dodatkowe:Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems, Martin Kleppmann, 2015Distributed Systems lecture series, playlista materiałów na temat projektowania systemów rozproszonychBuilding a Distributed Log from Scratch, seria artykułów na temat tworzenia systemów rozproszonychThe Consistent Hash Exchange, artykuł na temat opisywanego w odcinku algorytmu przypisywania konsumerów w RabbitMQOrdering Distributed Events, artykuł Vaidehi Joshi na temat porządkowania zdarzeńDistributed Systems: Time and order, teoria porządkowania w systemach rozproszonychYou Cannot Have Exactly-Once DeliveryZapraszam także do odwiedzenia:Iggy.rs, strona domowa projektu IggyPiotr@GithubPiotr@X / Twitter

Encje domenowe to obok Value Objectów jeden z podstawowych wzorców implementacyjnych Domain-Driven Design. Mogą działać zarówno samodzielnie, jak i być częścią innych struktur, np. agregatów. Ale czym właściwie są encje i co odróżnia je od pozostałych wzorców taktycznego DDD?W telegraficznym skrócie encje to obiekty domenowe posiadające ściśle określoną tożsamość, które z jakiegoś powodu muszą być śledzone na przestrzeni czasu. Gościem dzisiejszej rozmowy jest Kamil Grzybek, który pojawił się już w Better Software Design przy okazji rozmów o modularyzacji monolitu czy testowalności oprogramowania.W tym odcinku rozmawiamy między innymi o:przeznaczeniu wzorca Entity,różnych metodach nadawania tożsamości obiektom,podziałach encji względem cykli życia w domenie,różnicach pomiędzy encjami a agregatami czy Value Objectami,mapowaniu encji domenowych na encje bazodanowe.Zapraszam!Materiały dodatkowe:Implementing Domain-Driven Design, rozdział 5 poświęcony encjom domenowymWhat Is the Hi/Lo Algorithm?, artykuł na temat algorytmu Hi/Lo do generacji identyfikatorówEntity Identity vs Database Primary KeyModular Monolith with DDD, repozytorium Kamila, w którym moduły korzystają ze wszystkich wzorców omawianych w odcinku wzorców taktycznych

W greenfieldzie, który jeszcze nie dotarł do środowiska produkcyjnego zazwyczaj wszystko jest dość proste. Nawet przy zupełnej zmianie koncepcji w najgorszym razie można postawić bazę danych czy środowisko od zera. Jednak gdy system działa na produkcji, trzeba wprowadzać w nim głębsze zmiany, a do tabel w bazie przywiązana jest nie tylko aplikacja, sytuacja trochę się komplikuje. Dziś zapraszam na rozmowę o wprowadzaniu EventSourcingu do projektu, na przykładzie prawdziwego systemu obsługi cashflow.Moim gościem jest Łukasz Reszke, pracujący na co dzień właśnie przy projektach opartych o event-store i EventSourcing.W tym odcinku rozmawiamy z Łukaszem między innymi o:praktycznym zastosowaniu EventSourcingu w projekcie z problemami u klienta,wdrażaniu EventSourcingowego modułu do aplikacji z istniejącą relacyjną bazą i danymi,publikacji eventów do pozostałej części systemu i rodzajach eventów,odczytywaniu danych ze zdarzeń, strumieniach i linkowaniu do nich zdarzeń.Materiały dodatkowe:Working with RailsEventStore in Cashflow Management System, prezentacja Łukasza z konferencji wroc_love.rb 2023Eventsourcing Patterns: Migration Events in a Ghost Context, artykuł Mathiasa Verraesa o imporcie danych z systemów legacy do modelu opartego o zdarzeniaPatterns for Decoupling in Distributed Systems: Summary Event, kolejny artykuł Mathiasa Verraesa, tym razem o emitowaniu zdarzeń zbiorczychŁukasz@X, profil Łukasza na X/TwitterWspomniany w intro odcinek nr 10 z Andrzejem Krzywdą o refaktoryzacji The Arkency Way można znaleźć tutaj.

Każdy kod zostanie przetestowany, wcześniej bądź później. Pozostają jedynie pytania na jakim etapie i przez kogo zostanie to wykonane i jaki będzie tego ostateczny koszt. Gdy aplikacja staje się złożona i tworzy ją wiele różnych komponentów, proces testowania może zacząć przysparzać pewnych trudności, choćby z odwzorowaniem odpowiedniego środowiska uruchomienia testów. I tu przychodzi z pomocą biblioteka Testcontainers.Testcontainers to framework pozwalający testować aplikację w oparciu o kontenery Dockera z prawdziwymi zależnościami systemu. I choć pozornie brzmi to banalnie, narzędzie to oferuje szereg bardzo praktycznych i przydatnych rozwiązań, znacznie upraszczających cały proces testowania integracyjnego.Moim gościem jest dziś Piotr Przybył, Software Gardener z wieloletnim doświadczeniem programistycznym, który o praktycznym wykorzystaniu Testcontainers w projektach wie naprawdę sporo.W tym odcinku rozmawiamy z Piotrem między innymi o:częstych problemach z testowaniem kodu i jego jednostkach,możliwych podejściach do organizacji testów w piramidy, odwrócone piramidy, plastry miodu...zasadzie działania biblioteki Testcontainers i jej kluczowych konceptach,różnicach pomiędzy Testcontainers a innymi sposobami uruchamiania usług podczas testów,synchronizacji kodu testów opartych o Testcontainers z infrastrukturą produkcyjną.Zapraszam!Materiały dodatkowe:Testcontainers Getting Started, dokumentacja omawianej w odcinku bibliotekiKatalog modułów, dostępne gotowe kontenery z prekonfigurowanymi usługamiTestcontainers Workshop, repozytorium na Githubie z przykładowym kodem krok-po-krokuIntegration tests are needed and simple, prezentacja Piotra o testach integracyjnych z użyciem TC z konferencji Devoxx UK 2023Testcontainers: needed, simple, powerful, dłuższa, niemal 3 godzinna prezentacja z Devoxx z BelgiiWpisy o Testcontainers, blog Piotra o oprogramowaniu, nie tylko o testowaniu

Czy nieczytelny, trudno nierozszerzalny i na dodatek zduplikowany kod może być dobry? Co więcej, nawet pożądany? Tak, jeśli w projekcie istotne są zupełnie inne drivery, np. w postaci oczekiwanej dużej wydajności systemu. Wówczas poświęcenie pewnych cech kodu na cześć innych wydaje się mieć dużo sensu.Dziś zapraszam na rozmowę z Tomaszem Lelkiem, współautorem wydanej w ubiegłym roku w wydawnictwiem Manning książki "Software Mistakes and Tradeoffs: How to make good programming decisions". A rozmawiać będziemy właśnie o świadomym podejmowaniu decyzji, zwłaszcza w kontekście wydajności i optymalizacji systemu. Nie od dziś przecież wiadomo, że zbyt wczesna optymalizacja jest źródłem całego zła. Niestety wykonana zbyt późno też źródłem wszystkich kosztów...Dzięki uprzejmości wydawnictwa Manning mam 2 kody uprawniające do darmowego pobrania książki Tomka "Software Mistakes and Tradeoffs: How to make good programming decisions" w formie ebooka. Zapraszam więc do podzielenia się historiami o optymalizacjach waszych systemów. Kody te trafią do dwóch osób, których zgłoszenia zostały wybrane przeze mnie jako najciekawsze i najbardziej pouczające dla Ciebie i/lub zespołu.Termin przesyłania zgłoszeń mija z końcem 30 września 2023 roku, nadsyłać je można z użyciem formularza dostępnego na stronie https://forms.gle/o2rVAQHmwZuyP7y66

Temat tworzenia oprogramowania pod konkretne potrzeby biznesowe, we współpracy z ekspertami domenowymi pojawiał się wielokrotnie w podkaście. Ale jak tworzyć oprogramowanie w modelu open-source, które będzie wykorzystywane przez innych developerów i gdzie pojedynczy ekspert domenowy nie istnieje, bo trzeba dbać o wielu różnych klientów?Jak tworzyć oprogramowanie rozszerzane następnie przez innych developerów, jakie techniki stosować, dlaczego to co w innym projekcie byłoby bad-practice tu może być dobrym rozwiązaniem - m.in. o tym będziemy rozmawiać dziś z Łukaszem Chruścielem. Łukasz od wielu lat pracuje w core-teamie open-source'owego frameworka e-commerce Sylius, a dodatkowo miliony pobrań poszczególnych pakietów tego kodu i wiele dużych wdrożeń w projektach będzie tu ciekawą perspektywą.Zapraszam!Materiały dodatkowe:Sylius Github, repozytorium projektuProfil Łukasza na TwitterzeRozterki i decyzje. Czego się nauczyliśmy projektując API Syliusa, prezentacja Łukasza z konferencji Boiling Frogs 2023, przy okazji której mogliśmy się spotkać i porozmawiać