W 2015 roku Meta, a właściwie ówczesny Facebook wydaje pierwszą wersję specyfikacji GraphQL, języka opisu zapytań do API, którego celem jest wydajne i mocno elastyczne pobieranie danych. A ten właśnie problem mocno doskwierał Facebookowi przy implementacji natywnych aplikacji mobilnych. Nadszedł rok 2024 i wiele organizacji przekonało się, że wdrożenie rozbudowanego i wydajnego GraphQL API nie jest zadaniem prostym...O GraphQL powiedziano już wiele, warto przybliżyć trochę ciemniejszych stron używania tego rozwiązania w projekcie. Dziś zapraszam na rozmowę o cieniach GraphQL-a, a moim gościem jest Sebastian Rabiej, który z tą technologią ma sporo doświadczenia produkcyjnego.W tym odcinku wspólnie z Sebastianem rozmawiamy między innymi o:raporcie Postmana i trendach w stosowaniu poszczególnych styli budowy APIczym jest GraphQL i jakie problemy rozwiązujezasadach, popularnych narzędziach i frameworkach do budowy GraphQL APIsposobach atakowania serwera GraphQLpotencjalnych problemach z wydajnością, bezpieczeństwem i wersjonowaniem takich APIbest practices i sposobach rozwiązania typowych problemów w GraphQLMateriały dodatkowe:Dokumentacja i strona domowa GraphQLDostępne wydania specyfikacji GraphQLArtykuł na blogu Meta opisujący jak to się wszystko zaczęłoZestaw zaleceń Principled GraphQLPraca Migrating to GraphQL: A Practical AssessmentWspomniany w odcinku blog post The rise and fall of GraphQL at sennderArtykuł Public versus Published Interfaces Martina Fowlera[Dokumentacja limitów GraphQL[(https://docs.github.com/en/graphql/overview/rate-limits-and-node-limits-for-the-graphql-api) w API GitHubNetflix DGS Framework do implementacji i uruchamiania usług opartych o GraphQLGraphQL Voyager, narzędzie wizualizacji schematu API w formie interkatywnego grafuGraphQL Cop, narzędzie audytu security API opartych o GraphQL

Frontend i jego technologie rozwijają się szybko. Tym razem na horyzoncie w świecie Angulara są Signals, które mogą dość mocno zmienić podejście do projektowania systemu.Po mocnym otwarciu serii o architekturze frontendu rozmową z Bartkiem Cytrowskim o makro-frontendzie Atlassiana, pora na temat typowo techniczny, związany jak to często w tym światku bywa, z konkretnym frameworkiem. Gościem Tomka Ducina dziś jest Maciej Wójckik, Software Engineer i Technical Leader w Cisco, a tematem rozmowy są wspomiane już sygnały.W dzisiejszej rozmowie:czym są sygnały i jaki problem rozwiązująw czym są podobne, a czym różnią się od istniejących narzędzi reaktywnych typu RxJskomponentach, zależnościach, zmianach, template'ach i wydajności systemujak sygnały wpływają na projektowanie i testowanie aplikacjiz czym wiąże się migracja aplikacji na Signals i jakie problemy mogą się pojawićMateriały dodatkowe:Oficjalna dokumentacja Angular SignalsDarmowy kurs Angular Signals autorstwa Macieja

Zostać CTO i móc samodzielnie podejmować wszystkie decyzje techniczne w projekcie i mieć ostateczne zdanie na każdy temat... Taka wizja przyszłości w nawet średniej wielkości organizacji często nie ma jednak zbyt wiele wspólnego z rzeczywistością. Na czym więc polega rola Chief Technology Officera i ile jest w niej realnie technologii?W wiadomościach od was, na równi z tematami o architekturę, EventStorming czy Domain-Driven Design przewijają się bardo często pytania o dalszą karierę. W jakim kierunku się rozwijać, czy wiązać dalsze plany w IT ze ścieżką stricte techniczną i zostać np. architektem, czy może całkowicie skręcić w stronę managementu i kierowania zespołem czy projektem... W tym wszystkim pytania związane z funkcją i rolą CTO padały chyba najczęściej. Tak więc temat w końcu zagościł na antenie.Dziś zapraszam Cię na rozmowę z Danielem Owsiańskim, na tematy związane właśnie z funkcją Chief Technology Officera i zarządzania technologią w firmie. Wybór gościa był jak zwykle nieprzypadkowy — Daniel pełni rolę CTO w Volt.io, gdzie mamy okazję na codzień współpracować.Jeśli chciałbyś/-abyś dołączyć do jednego z naszych projektów w Java, Go lub PHP, tutaj znajdziesz aktualne oferty pracy.Zapraszam Cię także do odwiedzenia bloga Daniela, owsianski.com, który ostatnio pojawił się w sieci.

Wiele osób chciałoby przy każdym projekcie pracować w green-fieldzie i móc wszystkie decyzje podejmować samodzielnie. Rzeczywistość jest jednak zwykle całkowicie inna, musimy żyć z odziedziczonym kodem i zaprojektowanym modelem. Taki green-field, w którym można zacząć projektować i wdrażać nowy model i techniki DDD, można jednak sobie wykroić.Wspólnie z Marcinem Markowskim rozmawiamy dziś o technikach Bubble Context, Autonomous Context i Legacy As Exposed Service Erica Evansa, dzięki którym można zacząć refaktoryzację legacy. Z mniejszym lub większym związaniem z legacy, w zależności od potrzeb i możliwości w projekcie.W dzisiejszej rozmowie:na czym polegają techniki Bubble i Autonomous Context,kiedy warto, a kiedy nie, korzystać z ich możliwości,wykorzystaniu istniejących danych w nowym modelu domenowych,ACL-backed repository, Ports & Adapters i innych przydatkach tu technikach,jakie synchronizować dane między kontekstami i jakie inne wyzwania staną prawdopodobnie na drodze ku lepszemu,współpracy w zespole przy wdrażaniu takich technik.Materiały dodatkowe:Artykuł Getting Started with DDD when surrounded by legacy systems Erica Evans, 2013

"Jak mamy pozyskać świetnych architektów, jeśli w swojej karierze będą mieli okazję ją tworzyć mniej niż pół tuzina razy?". Dokładnie takie pytania postawił Ted Neward, szukając sposobu na doskonalenie umiejętności tworzenia architektury. I trudno się tu nie zgodzić, patrząc jak często w zespołach duże projekty powstają od samego początku. Istnieje jednak prosty sposób na rozwiązanie tego problemu.Sesje Architectural Kata pozwala jednak zdobywać potrzebne doświadczenie znacznie szybciej. Tym bardziej, jeśli feedbacku na temat twojego designu udzielają Mark Richards i Jacqui Read, autorzy książek poświęconych architekturze oprogramowania. W tym roku, kolejną edycję O'Reilly Software Architecture Katas wygrywa po razy pierwszy zespół z Polski, w którego skład wchodzą Artur Kruszewski, Wojciech Kasa, Sebastian Dąbkowski i Piotr Filipowicz, mój dzisiejszy gość.Razem z Piotrem rozmawiamy dziś między innymi o:czym jest Architectural Kata i jak może wspomóc Cię w procesie projektowania architekturysześciu perspektywach, które można wziąć pod uwagę szukając właściwej dla projektu architekturycharakterystykach architektonicznych, ograniczeniach, macierzy styli Marka Richardsakomunikowaniu architektury różnym jej odbiorcom, nie tylko zespołowi developerskiemukonkretnych przykładach Fitness Function z architektury ewolucyjnejZapraszam!Materiały dodatkowe:Fundamentals of Software Architecture: An Engineering Approach, książka Marka Richardsa i Neala FordaSoftware Architecture: The Hard Parts: Modern Trade-Off Analyses for Distributed Architectures, kolejna pozycja, której współautorami są Mark Richards i Neal FordThe Architecture Kata Log, repozytorium Jacqui Read z listą zwycięzców poszczególnych edycji konkursu O'Reilly Software Architecture KatasStayHealthy.MonitorMe, repozytorium z wspominanym w rozmowie opisem architekturyArchitectural Katas, katalog różnych kat Teda NewardaZapraszam także do obserwowania profilu Piotra na LinkedIn.

Jeśli wycena projektu podawana jest w dwóch wersjach, z uwzględnieniem testów i bez, to z software craftsmanshipem ma to niewiele wspólnego. To tak, jakby pytać chirurga, czy może przyspieszyć operację nie dezynfekując skalpela. Jakość nie powinna być elementem przetargowym. Chyba, że pracujemy nad proof-of-concept, ale tego rodzaju projekty często lubią płynnie przejść w fazę protoduction...Jeśli szukasz sprawdzonych w boju receptur na implementację jakościowych testów, które nie będą wymagały co chwilę refaktoryzacji i modyfikacji przy zmianie kodu projektu, zapraszam Cię na dzisiejszą rozmowę z Piotrem Stawirejem. Napisać test w projekcie to w zasadzie żadna sztuka. Ale napisać test, który dostarczy realną wartość biznesową, będzie łatwy do utrzymania, a przy okazji może zostać wykorzystany na różnych poziomach piramidy testów, to trochę bardziej skomplikowane zadanie.I pewnie niektóre strategie mogą być trochę kontrowersyjne, jak na przykład rezygnacja z typowego mockowania zależności, czy silnego podziału na wiele różnych testów w projekcie. Ale skoro działa to w praktyce, to w czym rzecz?W tym odcinku rozmawiamy wraz z Piotrem między innymi o:organizacyjnych i technicznych problemach z implementacją jakościowych testów w backendziemetryce code-coverage i jej różnym stopniu przydatności w projekcieprofesjonalnym podejściu do problemu "z testami, czy bez?"dobrych praktykach doboru strategii testowaniaszarej strefie testów Kevlina Henney'alegacy, testach charakterystyki, szwach i odcinaniu fragmentów systemu dla testówunitach, czyli fragmentach kodu o pojedynczej odpowiedzialności, mierzonego kohezjąimplementacji architektury otwartej na testowanieeliminacji problemów z nadużywaniem mocków w projekcieZapraszam!Materiały dodatkowe:Sub-second acceptance tests, prezentacja Aslaka Hellesøy z konferencji SeleniumConf ChicagoGrowing Object-Oriented Software, Guided by Tests, wspomniana w rozmowie książka Steve'a Freemana i Nata Pryce'aStyle Guide for Object Design, książka Matthiasa NobackaFinancial System, repozytorium z przykładowym kodem Piotra

Odpowiedzialność za zapewnienie jakości w projekcie nie spoczywa na pojedynczej osobie, tylko na całym zespole. A rola QA nie sprowadza się tylko i wyłącznie do projektowania i implementacji przypadków testowych w procesie inspekcji systemu, ale także na byciu adwokatem jakości w projekcie, i czasem zadawaniu trudnych pytań o to, dlaczego pewne funkcjonalności są zrobione w ten, a nie inny sposób.Do tej pory temat jakości oprogramowania przewijał się głównie z perspektywy developerskiej w rozmowach o testach jednostkowych, Test Driven Development czy różnych odmianach piramidy testów. Na strukturę testów w projekcie warto też spojrzeć z jej drugiej strony, black-boxowych testów end-to-end całego systemu.Gościem w podkaście jest dziś Arkadiusz Jelonek, pracujący na co dzień jako Senior Quality Assurance Engineer w eSky Group. A rozmawiać będziemy nie tylko i testach E2E systemu, ale także o tym, jaką rolę QA pełni w projekcie i dlaczego QA warto czasem przetłumaczyć jako Questions Asker.W dzisiejszym odcinku wspólnie z Arkiem rozmawiamy między innymi o:roli Quality Assurance w projekciezdobywaniu doświadczenia pracując w Software House, dojrzałej firmie produktowej i startupiepytaniach, jakie warto zadać w zespole wchodząc w rolę Questions Askerroli testów end-to-end w projekcieklasyfikacji, różnicach i doborze właściwych narzędzi wspierających automatyzację testówpowstaniu Playwrighta i problemach, które to narzędzie rozwiązujetestach regresji wizualnejsposobach unikania kruchości w testach E2ETen odcinek jest także pierwszym z mini-serii rozmów poświęconych rozwojowi własnej kariery w IT, nie tylko na stanowisku developera. Myślisz o tym, aby pracować w tej branży np. jako Solution Architect, Engineering Manager, Chief Technology Officer czy zostać konsultantem? To tylko niektóre role i stanowiska, które pojawią się w przyszłych odcinkach Better Software Design…Materiały dodatkowe:The Evolution of Browser Automation, artykuł i prezentacja Christiana Bromanna z Sauce LabsZawód tester - Od decyzji do zdobycia doświadczenia, książka Radosława Smilgina, dla osób początkującychPasja testowania (wydanie 2, rozszerzone), książka Krzysztofa Jadczyka, także dla początkujących

Tworzenie oprogramowania nie sprowadza się jedynie do backendu, natomiast tematyka architektury front-endu do tej pory była w zasadzie zupełnie nieobecna w Better Software Design. Do tej pory, ponieważ dzisiejszy odcinek otwiera nowy rozdział w podkaście i tego rodzaju zagadnienia będą się co jakiś czas pojawiać. A rozmowy na takie właśnie tematy prowadzić będzie najlepszy znami mi architekt front-endu, Tomasz Ducin.Tak, tak, nie jest to przejęzyczenie. Przy dzisiejszym poziomie złożoności technik i narzędzi, po prostu nie można znać się na wszystkim. Dlatego mam dużą satysfakcję z tego, że Tomek będzie gościł w Better Software Design w nowej roli, dostarczając wiedzę z najwyższej front-endowej półki. Pozostaje zacząć nowy etap z przysłowioego "wysokiego C" i bardzo interesującym tematem.Gościem specjalnym dzisiejszego odcinka jest Bartosz Cytrowski, Senior Software Engineer w Atlassianie. Jeśli chcesz się dowiedzieć, jak wygląda architektura makro front-endu w Atlassianie i Jira Cloud, czy jak pracuje się w tak ogromnym i popularnym ekosystemie, to ten odcinek jest właśnie dla Ciebie!W tym odcinku usłyszysz między innymi o:czym jest monorepo, jego zaletach i wadach, a także o tym jak pracuje się z nim w Atlassianie,narzędziach wykorzystywanych do rozwoju systemu o takiej skali jak Jira Cloud,sposobie pracy w systemie, w którym pojawia się ponad 1000 pull-requestów dziennie,kontrolowaniu zależności pomiędzy modułami,stosowaniu feature flags i bezpiecznym wprowadzaniu zmian dotykających wielu zespołów,testowaniu zmian, dog-foodingu i bezpiecznym wdrażaniu nowych wersji.Zapraszam!

Błędów nie popełnia tylko ten, co nic nie robi, a szramy Wietnamu biorą się z nie z czytania książek, tylko z osadzania zawartych w nich idei w złożonej rzeczywistości konkretnych projektów. Dziś zapraszam na rozmowę o często trudnych realiach wprowadzania Domain-Driven Design do organizacji i procesach Domain Discovery.Moimi gośćmi są Dariusz Pawlukiewicz i Michał Wilczyński, programiści i architekci, zaangażowani w inicjatywę DevMentors. A rozmawiamy przede wszystkim o doświadczeniach związanych z wprowadzaniem DDD do zespołów i organizacji, oraz o częstych problemach występujących w procesach poznawania domeny.Materiały dodatkowe:Domain model purity vs. domain model completeness (DDD Trilemma), wspomniany w rozmowie artykuł Vladimira KhorikovaThe failed promise of Domain-Driven Design - part 1, artykuł Sebastiana GębskiegoThe failed promise of Domain-Driven Design - part 2, kontynuacja powyższego artykułu

Czy kilka twoich projektów dla różnych klientów ma dokładnie taką samą strukturę wewnętrzną, stosowane są dokładnie te same wzorce organizacji kodu i architektury? Albo wszędzie widzisz możliwość zastosowania CQRS, rozdziału na komendy i query, czy możliwość zaimplementowania taktycznych wzorców z DDD? W wielu przypadkach będzie to zapewne całkowicie uzasadnione, poza tymi, w których nie ma to większego sensu...Abraham Maslow kiedyś opisał to zjawisko mówiąc: dla człowieka, który dysponuje tylko młotkiem, wszystko, co spotyka zaczyna wyglądać jak gwóźdź. Idąc tym torem, posługiwanie się tylko jednym młotkiem nie jest ani wygodne, ani zdrowe.Po ostatnich odcinkach podcastu poświęconych architekturze, zapraszam na luźniejszą rozmowę z Piotrem Przybyłem o chorobach, które czasami można zauważyć w naszych projektach i zespołach. A rozmawiamy m.in. o ostrej zasadzie Pareto, projektowym "good enough" i kilku chorobach, które warto mieć na swojej developerskiej uwadze.Materiały dodatkowe:Cztery choroby, prezentacja Piotra z konferencji Boiling Frogs 2019Architecture antipatterns and how to beat them, część 1, prezentacja Łukasza Szydło z konferencji 4Developers 2017Architecture antipatterns and how to beat them, część 2, kontynuacja powyższej prezentacji

Domain-Driven Design jest skuteczną metodą analizy i modelowania złożonych, nierozpoznanych jeszcze problemów biznesowych. Jednak niektóre wzorce strategiczne są bardzo mgliste i mogą nie dostarczać konkretnych sposobów do działania w projekcie. Krytyka DDD w tym obszarze wydaje się mieć sporo podstaw...Bo czym właściwie jest subdomena? W myśl definicji, subdomena jest zazwyczaj wyodrębnionym obszarem, który może być zarządzany i rozwijany niezależnie od innych, posiadając swoje specyficzne reguły biznesowe, modele i zasoby. Ale czym się subdomena różni od domeny, jak skutecznie wyznaczyć ten "wyodrębiony" obszar i właściwie czemu to ma służyć? Jeśli dodamy to tego lingwistyczne granice kontekstów, to robi się z tego trudna do strawienia mieszanka.Dziś zapraszam na rozmowę z Łukaszem Szydło, w której dotykamy tematyki modularyzacji systemu w oparciu o inne, prostsze narzędzia. Na koniec dnia zajmujemy się wprowadzaniem zmian, więc zmodularyzujmy system tak, aby było nam je łatwo wprowadzać.W tym odcinku rozmawiamy z Łukaszem o:hype na Domain-Driven Design i trudnościach w jego stosowaniuintuicjach, heurystykach vs. praktyki inżynieryjneanalizie domeny na mniejsze części, poprzez odkrywanie niezależnie zmieniających się w niej rzeczysumulacji zmian i wykorzystaniu atrybutów jakościowych w procesie dekompozycjistabilnych granicach aplikowalności modelu, wynikających z wprowadzanych zmianweryfikacji wytwarzanych w ten sposób podziałów w projekciedobrych momentach na refaktoryzację systemuMateriały dodatkowe:Wspomniana w odcinku prezentacja Real Software Engineering Glenna Vanderburga, VP of Engineering w FirstSDLab, inicjatywa projektów badawczych w zakresie projektowania oprogramowania

W informatyce są tylko dwie trudne rzeczy: unieważnianie pamięci podręcznej i nazywanie rzeczy... A jeśli mówimy co systemach rozproszonych, to do tej krótkiej listy Phila Karltona należy dopisać jeszcze skuteczną komunikację sieciową. Projektując systemy często zapominamy o tym, jak zawodny może być to komponent. A złośliwie zawiedzie pewnie w bardzo ważnym momencie... Na szczęście możemy temu zapobiec korzystając z wzorca Transactional Outbox.Do rozmów w podkaście zapraszam osoby, które nie raz czy dwa zderzyły się z danym problemem w życiu i posiadają konkretne doświadczenie. Nie inaczej jest tym razem, a moim gościem jest dziś Jacek Milewski, który na co dzień pracuje jako modelarz i architekt oprogramowania. W tym odcinku wraz z Jackiem rozmawiamy między innymi o:problemach związanych z komunikacją w systemach,idei wzorca Transactional Outbox / Store&Forward,możliwych sposobach obsługi outboxa w systemie,zastosowaniu tego wzorca zarówno w systemach rozproszonych jak i monolitycznych,kolejności przetwarzania wiadomości,deduplikacji czy message-poisoning.Materiały dodatkowe:Microservices: Transactional outbox oraz AWS Prescriptive Guidance: Transactional Outbox Pattern, opis omawianego w odcinku rozwiązania wraz z przykładowymi diagramamiOutbox Pattern: kiedy ten strzał do API to jednak za mało, prezentacja Jacka z konferencji Confitura PL 2023Push-based Outbox Pattern with Postgres Logical Replication, artykuł Oskara Dudycza przedstawiający rozwiązanie oparte o bazę danychZapraszam także do śledzenia profili Jacka na Twitter/X oraz LinkedIn.

Gdy coś się dobrze zaczyna, często kończy się źle... A jednym z tego powodów w projekcie jest niekontrolowane wprowadzenie couplingu, czyli sprzęganie różnych jego elementów ze sobą. Różne komponenty nagle stają się od siebie zależne, logika biznesowa połączona z frameworkiem czy bazą danych, a w efekcie całość jest coraz trudniejsza do utrzymania i rozwoju. Zwiększając sprzężenie zmniejszamy kohezję rozwiązania, a w myśl zasad GRASP Low Coupling i High Cohesion warto postępować dokładnie na odwrót.Na szczęście decoupling może zostać zrealizowany w projekcie na wiele różnych sposobów. A czasem wręcz świadomie pominięty, ponieważ nie przyniesie on oczekiwanych efektów.Dziś zapraszam na odcinek z Grzegorzem Piwowarkiem na tematy poświęcone couplingowi, decoplingowi i trzymania rzeczy w projekcie niektórych rzeczy (jak frameworki) na dystans, w którym rozmawiamy między innymi o:odcinaniu frameworka webowego czy ORM,efektach i zyskach płynących z decouplingu,przydatnych heurystykach pomagających odpowiedzieć na pytanie, czy warto odcinać daną zależność,architekturze heksagonalnej,historiach z życia...Materiały dodatkowe:Trzymaj Springa na dystans , wspomniana w rozmowie prezentacja Grzegorza z konferencji Confitura 2022Recipes for Decoupling, książka Matthiasa Nobacka opisująca implementację konceptów dla ekosystemu PHP4comprehension.com, strona Grzegorza, na której można zapoznać się zarówno z ofertą szkoleń programistycznych jak i wpisami związanymi z Javąpivovarit@x, profil Grzegorza na Twitter/X

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/Twitter

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 bibliotekiTestcontainers 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 2023Wpisy 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ć

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ń

"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, 2017Building Evolutionary Architectures, prezentacja Rebeki Parsons, Neala Forda i Jamesa Lewisa z konferencji GOTO 2023Evolutionary Software Architectures, prezentacja Neala Forda z Voxxed DaysEvolutionary 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 & 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 tutoriala

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

Często uciekamy od danych i analizujemy zachowania w procesach biznesowych, a równie często to właśnie dane są podstawą do budowy zaawansowanych systemów IT. Zanim dotkniemy gwarantujących spójność agregatów, nasze operacje przechodzą przez systemy oparte o sztuczną inteligencję czy uczenie maszynowe i to właśnie tym zagadnieniom dziś się przyjrzyjmy.Zapraszam dziś na odcinek z wielu powodów dla mnie szczególny, ponieważ moim gościem jest Piotr Gawrysiak, Chief Data Scientist w mBanku i profesor Politechniki Warszawskiej, osoba o ogromnej wiedzy w tematach AI/ML, a także Process Miningu. Po 30 latach życie napisało tu piękną klamrę, bo choć dziś będziemy wspólnie rozmawiać o projektowaniu rozwiązań data-driven czy automatycznej analizie procesów biznesowych, to dawniej chłonąłem treści tworzone przez Piotra pod szyldem magazynów Bajtek i Top Secret... Piotr uchyli rąbka tajemnicy i pokaże jak kierowany przez niego zespół wspiera mBank na polu analizy danych i projektów ML.W tym odcinku rozmawiamy m.in. o:projektach opartych w ML/AI w banku,rodzajach problemów możliwych do rozwiązania z użyciem Machine Learningu,procesie tworzenia rozwiązań data-driven,wykorzystywanych technologiach i potrzebnych umiejętnościach w kwestii data-science,późniejszym wdrażaniu przygotowanych modeli i podejścia do dzielenia się danymi,process miningu i automatycznej analizy procesów,wpływie modeli typu ChatGPT-3 na pracę developerów.Zapraszam na odcinek!Materiały dodatkoweIT w mBanku, więcej rozmów z ekspertami i tematy dookoła software-house'u ITKursy Andrew NG, kilka kursów od Andrew NG w specjalizacjach Machine Learning, MLOps i Deep LearningProcess Mining Warsaw, grupa meetupowa poświęcona tematyce optymalizacji procesów z użyciem Proces MininguBiblioteka pm4py, implementacja algorytmów Process Mining w PythonieOdcinek powstał we współpracy z mBankiem.

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

O tym, że procesy biznesowe istnieją i że są ważne wiedzą wszyscy. Potrafimy o nich ogólnie mówić na poziomie abstrakcyjnym, ale też umiemy schodzić na niższe poziomy i opisywać ich działanie zdarzeniami lub BPMN-em. Natomiast o regułach często mówi się tylko na ogólnym poziomie, jeśli w ogóle, że "no jakieś tam reguły są w biznesie". Są traktowane trochę jak czarna magia, jak jakiś mityczny stwór. Trochę jak synonim "logiki biznesowej". Reguły biznesowe to jest bardzo konkretna rzecz, za którą stoi mocna teoria, własny standard (SBVR by OMG). która ma nie tylko praktyczne przełożenie na naszą pracę ale wręcz może zrewolucjonizować niektóre aspekty.Takie wprowadzenie do dzisiejszego tematu otrzymałem od mojego gościa, Aleksandra Bartnikiewicza, z którym rozmawiamy o regułach biznesowych, analizie domeny w oparciu o tę wiedzę, zapisie, semantyce i dokumentowaniu reguł. Nie będzie to odcinek poświęcony implementacji reguł w kodzie, ale uważny słuchacz znajdzie zapewne od razu odniesienia do Domain-Driven Design, chronionych agregatami niezmienników lub innych implementacjami zakazów i nakazów.W tym odcinku rozmawiamy z Aleksandrem m.in. o:- czym są, a także czym nie są reguły biznesowe i jak się mają do procesów w domenie,- odpowiednim wyrażaniu i semantyce reguł, aby poprawnie opisywały zasady działania biznesu,- podejściu Evansa vs podejście Rossa do języka biznesowego,- budowanie słowników i dokumentowaniu wiedzy na tem reguł biznesowych,- stosowaniu rulebooka w większym projekcie i zespole.Zapraszam! Na blogu Aleksandara znaleźć można artykuł Model pojęciowy - Diagram, który przedstawia wizualną stronę wspomnianego w odcinku przykładu.Materiały dodatkowe:Manifest Reguł Biznesowych, polska wersja manifestu Business Rules GroupThe Business Rules Manifesto*, angielska wersja 2.0 manifestu, listopad 2003Business Rule Concepts : Getting to the Point of Knowledge, wspomniana książka Ronalda RossaBusiness Knowledge Blueprints: Enabling Your Data to Speak the Language of the Business, kolejna warta uwagi pozycja RossaDla wytrwałych odnośnik do specyfikacji SBVR, Semantics Of Business Vocabulary And Business Rules.

Materiały dodatkowe:Functional Event Sourcing Decider, źródłowy artykuł na blogu Jérémiego Chassaing na temat implementacji wzorca DeciderFunctional Event Sourcing, nagranie prezentacji Jérémiego z DDD Europę 2020, niestety bez obrazu z laptopaHow to effectively compose your business logic, artykuł Oskara na temat kompozycji logiki z wzorcem DeciderHow events can help in making the state-based approach efficient, eventowe podejście do zmiany stanu systemuWriting and testing business logic in F#, kolejny artykuł z bloga Oskara na temat użycia Decidera, tym razem w F#

Materiały dodatkowe:8-krokowy process przeprowadzenia zmiany, podsumowanie wspomnianego przez Krzysztofa frameworka Johna KotteraTechnology Strategy Patterns: Architecture as Strategy, książka Ebena HewittaNerd Management, video podcast Krzysztofa i Pawła na tematy związane z zarządzaniem zespołami IT

Materiały dodatkowe:CUPID - the back story, pierwszy artykuł Dana Northa o kwestionowaniu zasad SOLIDCUPID - for joyful coding, kontynuacja tematu na blogu Dana NorthaCUPID - for joyful coding, nagranie prezentacji z konferencji NDC London 2022Patterns of Software: Tales from the Software Community, Richard P. Gabriel

Materiały dodatkowe:Bitemporal History, wpis na blogu Martina Fowlera na temat problemu modelowania bitemporalnegoAs Time Goes By…, a Bi-temporal Event Sourcing story, prezentacja - Thomas Pierrain z konferencji DDD Europe 20184 Strategies for future events with Event Sourcing, strategie rozwiązywania problemu "zdarzeń z przyszłości"Eventsourcing Patterns: Multi-temporal Events, wpis na blogu Mathiasa Verraesa na temat rozróżniania momentu rejestracji zdarzenia i zmiany przez niego opisywanejPatterns for Decoupling in Distributed Systems: Summary Event, kolejny wpis Matthiasa na temat emisji pojedynczego eventu summary zamiast całego streamu zdarzeńMateriały od zespołu Arkency:Fixing the past and dealing with the future using bi-temporal EventSourcing, wpis Łukasza Reszke na blogu ArkencyTake advantage of Turbo Streams in event handlers, wpis Piotra Jurewicza na temat aktualizacji read-modeli i UI aplikacjiSpeed up aggregate roots loading with snapshot events, wpis Piotra Jurewicza na temat odtwarzania stanu agregatu z użyciem snapshottinguRailsEventStore/ecommerce, repozytorium z kodem poligonu doświadczalnego aplikacji ecommerce z użyciem RailsEventStoreDemo ecommerce, prosty interfejs www powyższej aplikacji

Materiały dodatkowe:Testowanie mutacyjne, prezentacja Marcina na temat testowania mutacyjnego z konferencji Boiling Frogs 2016Slajdy prezentacjiJak szybkie (lub wolne) jest testowanie mutacyjne?, artykuł Marcina na temat szybkości testowania z mutantami, na przykładzie PIT i projektów FOSSBlog MarcinaTwitter MarcinaPrzykładowe narzędzia testowania mutacyjnego:Java, PIT - https://pitest.org/Java, Arcmutate - https://www.arcmutate.com/.NET, Stryker.NET - https://stryker-mutator.io/JavaScript, Stryker.JS - https://stryker-mutator.io/PHP, Infection - https://infection.github.io/guide/PHP 5.x (historycznie), Humbug - https://github.com/humbug/humbugRuby, Mutant - https://github.com/mbj/mutantPython, Mutmut - https://mutmut.readthedocs.io/en/latest/Python, Mutatest - https://mutatest.readthedocs.io/en/latest/Python, Cosmic Ray - https://cosmic-ray.readthedocs.io/en/latest/

Materiały dodatkowe:An Introduction to General Systems Thinking , książka Geralda M. Weinberga

Materiały dodatkowe:Reactive programming: lessons learned, prezentacja Tomka z konferencji JDD 2018What Color is Your Function?RxMarbles, interaktywne diagramy Rxnurkiewicz.com, strona Tomka i jego podcastu Around IT in 256 SecondsReactive Programming with RxJava: Creating Asynchronous, Event-Based ApplicationsNarzędzia:ReactiveX, pełna lista wspieranych języków jest na tej stronieSpring ReactiveProject ReactorRxJS

Aktualizacja... Podczas publikacji odcinka niestety nie zapisały się linki do książek. Enterprise Patterns and MDA: Building Better Software with Archetype Patterns and UML, Jim Arlow, Ila NeustadtAnalysis Patterns: Reusable Object Models, Martin Fowler, z przedmową Ralpha Johnsona i Warda CunninghamaData Model Patterns: Conventions of Thought, David C. HayThe Data Model Resource Book: A Library of Universal Data Models for All Enterprises, Len Silverston - książek z tej serii jest kilka, kolejne dotykają różnych domen biznesowych lub są rozwinięciem poprzedniego wydaniaMały komentarz w kwestii powyższych pozycji... Moim zdaniem nie są to książki, które czyta się od przysłowiowej deski do deski. Są to katalogi modeli lub pomysłów, po które się sięga w razie potrzeby, gdy spotyka się dany problem. Oczywiście niektóre problemy są bardziej uniwersalne i powszechne, choć literatura nie klasyfikuje tego w ten sposób. Niezależnie od tego, trzeba te koncepty przefiltrować przez własne doświadczenie.

Materiały dodatkowe:Software Requirements, Karl Wiegers, Joy Beatty, wydanie IIIRequirements Engineering Fundamentals: A Study Guide for the Certified Professional for Requirements Engineering Exam - Foundation Level, Klaus Pohl, Chris RuppSpecification by Example: How Successful Teams Deliver the Right Software, Gojko AdzicFacylitacja-wiedza, umiejętności, sztuka czy magiaNa stronie Moniki można też przeczytać kilka artykułów na tematy, które zostały poruszone w rozmowie:Wymaganie biznesowe a reguła biznesowaAtrybuty wymaganiaKategoryzacja wymagańDług technicznyAdaptowanie produktu w czasach kryzysu, czyli czym jest PIVOTMonikę można obserwować m.in. na Instagramie lub LinkedIn.

Materiały dodatkowe:Domain Storytelling Quick Start Guide, szybkie wprowadzenie do technikiDomain Storytelling: A Collaborative, Visual, and Agile Way to Build Domain-Driven Software, Henning Schwentner oraz Stefan HoferFind Context Boundaries with Domain Storytelling, prezentacja Henninga Schwentner oraz Stefana Hoferz konferencji DDD EU 2018LeasingNinja, przykład z użyciem Domain StorytellinguEgon.io, proste narzędzie do wizualizacji historyjekEgion.io - examples, repozytorium z kilkoma przykładami do Egon

Materiały dodatkowe:The Testing Trophy And Testing Classification, artykuł Kenta C. Doddsa dotyczący zmiany struktury testów w projekcieGOTO Conferences, nagrania z różnych edycji konferencji GOTOPozwoliłem też sobie wybrać kilka konkretnych prezentacji z GOTO:Structure and Interpretation of Test Cases, Kevlin Henney, GOTO 2022When To Use Microservices (And When Not To!), Sam Newman & Martin Fowler, GOTO 2020The Many Meanings of Event-Driven Architecture, Martin Fowler, GOTO 2017

Materiały dodatkowe:Software Architecture for Developers, książka Simona BrownaDesign It! : Pragmatic Programmers: From Programmer to Software Architect, książka Michaela KeelingaThinking Architecturally, książka Nathaniela SchuttyThinking Architecturally, prezentacja Nathaniela związana z powyższą książką

Patrząc na tematy związane z Domain-Driven Design czy książki, można by powiedzieć „DDD - to nie takie proste”. Z Michałem Giergielewiczem rozmawiamy dziś o tym, jak można wejść w ten świat i jak zbudować solidne fundamenty pod przyszłe poznawanie bardziej zaawansowanych wzorców i praktyk.

Materiały dodatkowe:Context Maps - a deep dive, prezentacja Michaela Plöda z konferencji KanDDDinsky 2019Context Mapper, narzędzia do dokumentowania i wizualizowania map kontekstów

Materiały dodatkowe:Modular monolith: Primer, część 1 seriiModular Monolith: Architectural Drivers, część 2 seriiModular Monolith: Architecture Enforcement, część 3 seriiModular Monolith: Integration Styles, część 4 seriiModular Monolith: Domain-Centric Design, część 5 seriiModular Monolith with DDD, przykład modularnego monolitu w repozytorium Kamila na GithubieEnterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions, Gregor Hohpe

Dodatkowe materiałyWardley Mapping - notatki ze spotkania na MiroKonto Simona Wardley’a na TwitterzeNauka map Wardley’a w 90 sekNarzędzia konsultanta, artykuł wprowadzający na blogu RadkaAnaliza przypadku Zalando, przykład praktycznego użycia mapIntroduction to Value Chain Mapping", keynote Simona Wardley'a z konferencji OSCON 2014Crossing the River by Feeling the Stones , prezentacja Simona Wardley'a z konferencji DDD Europe 2018On being lost, artykuł autorstwa Simona Wardley'a

Materiały dodatkoweContext Maps - a deep dive, Michael Plöd, prezentacja z konferencji KanDDDinsky 2019

Modelowanie domeny z użyciem Event Sourcingu wymaga wzięcia pod uwagę kilku czynników. Jednym z nich jest liczba zdarzeń, jaka będzie związana z modelowanym obiektem. Wraz z Oskarem Dudyczem, Developer Advocate w EventStore, rozmawiamy w tym odcinku o temporal modelingu, czyli modelowaniu obiektów w odniesieniu do upływającego czasu, kontroli długości strumieni zdarzeń i powiązanych problemach. Wszystko oczywiście w kontekście Event Sourcingu.

Materiały dodatkowe:Składnia języka GherkinCucumberJBehaveSpecFlowBehatThoughtworks GaugeThoughtworks TaikoDodatkowo, sporo ciekawych odnośników do materiałów związanych z Behaviour-Driven Development znajduje się z repozytorium Mateusza, Awesome-BDD

Materiały dodatkowe..Prezentacje:Dissecting Bounded Contexts, prezentacja Nicka Tune z konferencji DDD Europe 2020Context Maps - a deep dive, prezentacja Michaela Plöd z konferencji KanDDDinsky 2019Książki:Accelerate: Building and Scaling High-Performing Technology Organizations, Nicole Forsgren,Jez Humble, Gene KimThe DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations, Gene Kim, Jez Humble, Patrick Debois, John WillisEscaping the Build Trap: How Effective Product Management Creates Real Value, Melissa PerriInspired: How to Create Tech Products Customers Love, Marty CaganEmpowered: Ordinary People, Extraordinary Products, Marty Cagan, Chris JonesThe Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win, Gene Kim, Kevin Behr, George SpaffordStrategic Microservices and Monoliths, Vaughn Vernon, Tomasz JaskułaLearning Domain-Driven Design: Aligning Software Architecture and Business Strategy, Vladik Khononov

Przykłady przykładami, ale jeśli trafia się tylko okazja, to warto porozmawiać o prawdziwych projektach i ich wyzwaniach. Gościem 30-stego odcinka Better Software Design jest Wojtkiem Wiktorowicz, obecnie zajmujący stanowisko Head of Engineering, który na co dzień pracuje nad rozwojem i utrzymaniem platformy Displate - globalnego marketplace’u dla artystów. Skala projektu to 1.5 miliona unikalnych prac, 40 tysięcy artystów na platformie i 5 milionów plakatów rozsianych na całym świecie i sporo ruchu w aplikacji. Za to wszystko odpowiada 40-osobowy zespół Engineeringu i to właśnie o tym zespole, jego transformacjach, zmianach podejścia do tworzenia oprogramowania będziemy rozmawiać.

W ramach mini-serii Domain-Driven Design Essentials rozmawialiśmy do tej pory o wzorcu Value Object. Dziś z Kubą Pilimonem rozmawiamy o kolejnym wzorcu taktycznego DDD, a konkretnie o serwisie domenowym. A w rozmowie poruszamy dziś następujące tematy: - czym właściwie jest Domain Service? - jaki kod można w nim osadzić i jak to identyfikować? - pojawi się oczywiście kilka różnych przykładów.

Materiały dodatkowe:https://event-driven.io/pl/, blog Oskara - pragmatycznie o programowaniu, można tutaj znaleźć serie artykułów o Event Sourcingu, CQRS, architekturze i innych ciekawych tematachhttps://martendb.io, implementacja EventStore i bazy dokumentowej dla .NET z wykorzystanie PostgreSQLhttps://www.eventstore.com, dedykowana baza danych pod Event Sourcinghttps://github.com/oskardudycz/EventSourcing.NetCore, praktyczne przykłady, ćwiczenia oraz tutoriale o tym jak budować aplikacje z użyciem Event Sourcing w .NET.https://www.architecture-weekly.com, cotygodniowy zestaw materiałów i linków na temat szeroko pojętej Architektury Oprogramowaniahttps://www.eventstore.com/blog/keep-your-streams-short-temporal-modelling-for-fast-reads-and-optimal-data-retention, artykuł Oskara o temporal modelingu i krótkich strumieniach zdarzeń

Materiały dodatkowe: DevKuchnia #11 z Mariuszem Gilem o żywocie konsultantaDevKuchnia #12 z Bartkiem Słotą o żywocie konsultantaThe Secrets of Consulting: A Guide to Giving and Getting Advice Successfully, Gerald M. Weinberg, ciekawa pozycja o byciu konsultantem, jest w niej sporo wartych uwagi wskazówek przydatnych nie tylko konsultantom,More Secrets of Consulting: The Consultant's Tool Kit, Gerald M. Weinberg, kontynuacja poprzedniej pozycji

"There are only two hard things in Computer Science: cache invalidation and naming things" - nie pierwszy raz wracam w podkaście do słów Phila Karltona, a zapewne także i nie ostatni. Gdy coś raz zostanie nazwane, zwłaszcza niefortunnie, często bardzo trudno się od tej nazwy uwolnić. Tym razem chciałbym więc zwrócić uwagę na to, co i jak możemy przeanalizować w naszym projekcie zanim zaczniemy nazywać poszczególne jego elementy i obiekty. Mowa tu oczywiście o perspektywach, dzięki którym możemy poznać jak coś wygląda, jak się zachowuje, a czasem dodatkowo czym innym się staje i kiedy. Technika wyjątkowo prosta w użyciu i jednocześnie zaskakująco skuteczna.

Materiały dodatkowe:Model jest wszystkim czego potrzebujesz, prezentacja z konferencji Confitura 2013 DevKuchnia, czyli piątkowe spotkania w symulatorze kuchni

Powraca temat analizy przykładowego agregatu i Aggregates By Example, tym razem moim gościem jest jednak Sławek Sobótka i wspólnie rozkładamy na czynniki pierwsze proces wypożyczenia książki z biblioteki. Oczywiście jest to tylko pretekst do tego, aby porozmawiać o samym procesie projektowania agregatu, możliwych jego wersjach i związanych z tym konsekwencjach. W tym odcinku rozmawiamy m.in. o: - agregatach zbyt dużych, gdzie granica spójności jest zdecydowanie zbyt obszerna - agregatach zbyt małych, nie potrafiących utrzymać systemu w spójności - możliwych agregatach pozwalających zachować spójność reguł biznesowych - bounded contextach

Podczas sesji Big Picture EventStorming bardzo często generowanych jest wiele zdarzeń, które podczas kolejnych kroków stormingu są kolejno eliminowane. W tym odcinku przyjrzymy się 4 rodzajom zdarzeń, czym różnią się od siebie zdarzenia środowiskowe, interfejsowe, domenowe i infrastrukturalne i do czego ten podział można wykorzystać podczas pierwszych warsztatów rozpoznawania domeny.

Materiały dodatkowe:BSD #2, O Aggregates By Example, analiza procesu rezerwacji z Kubą Pilimonem, odcinek podcastu, w którym razem z Kubą analizujemy kilka propozycji agregatówRepozytorium Aggregates By Example, repozytorium z przykładami implementacji różnych agregatówO odkrywaniu granic - heurystyki ważnych decyzji, Kuba Pilimon, prezentacja z naszego wspólnego eventu z Piątkami na Produkcji, w której Kuba przedstawia heurystyki znajdowania granic w systemach

Materiały dodatkowe:The E-Myth Revisited: Why Most Small Businesses Don't Work and What to Do About It, Michael E. Gerber Object-oriented metrics by Robert Martin, ciekawe przedstawienie 5 metryk OO Uncle Boba odnośnie couplingu i pochodnych wartości

Materiały dodatkowe:Neo4j.comNeo4j console, konsola online, gdzie można się pobawić przykładowym grafem bezpośrednio z przeglądarkiNeo4j GraphGists, zestaw świetnych przykładów użycia grafówGraphGist portal, jeszcze więcej przykładów użyciaNeo4j Cypher Refcard, refcard języka CypherPanama Papers, strona główna International Consortium of Investigative Journalists z artykułami odnośnie całej aferyOffshore Leaks Database, datasety ICIJ nie tylko dla Panama Papers, ale także Paradise Papers, Bahama i Offshore Leaksryguyrg/neo4j-panama-papers, przykładowy docker z importem danych Panama Papers do bazy Wpisy na blogu teamu Neo4j odnośnie afery Panama Papers:The Panama Papers Graph Database Is Now Available for DownloadHow the ICIJ Used Neo4j to Unravel the Panama PaperAnalyzing the Panama Papers with Neo4j: Data Models, Queries & MoreThe Panama Papers: Why It Couldn’t Have Happened Ten Years AgoNa koniec polecę jeszcze darmową książeczkę od O'Reilly Media, Graph Databases. Można ją pobrać ze strony https://graphdatabases.com.

Phil Karlton dawno temu powiedział swoje słynne zdanie: "There are only two hard things in Computer Science: cache invalidation and naming things". Tematem odcinka 19 będzie właśnie nazewnictwo, ale w kontekście zdarzeń domenowych. Odcinek też jest jednocześnie rozwinięciem rozmowy z Miłoszem, jednym ze słuchaczy podcastu. Miłosz kilka dni temu zwrócił się z pytaniem, czy lepiej stosować bardzo konkretne i jednoznaczne nazwy zdarzeń, czy też można sobie pozwolić na uogólnienia typu SomethingChanged.

From time to time we should stop for a moment and take a look around. We will see what is behind us already and what is waiting for us in the future. In this episode my today guest, Robert C. Martin widely known as Uncle Bob, shares his perspectives on Agile, challenges and state of IT industry. This episode of Better Software Design podcast is in English.

Materiały dodatkowe:Definicja Law of Demeter, WikipediaClean Code: A Handbook of Agile Software Craftsmanship, Robert C. Martin, klasyczna książka Uncle Boba na temat czystego koduAgile Principles, Patterns, and Practices in C#, Robert C. Martin, Mikah MartinTest Driven Development: By Example, Kent Beck, książka, która pojawiła się już przy okazji poprzedniego odcinka o Test Driven DevelopmentDomain-Driven Design: Tackling Complexity in the Heart of Software, Eric Evans, z rekomendacją od Piotra, aby szczególną uwagę zwrócić na rozdział 2 tej książki, czyli "Communication and the Use of Language"Wspomniane przez nas repozytorium z ciekawie zaimplementowaną piramidą testów i nawiązujące do tematyki odcinka można znaleźć na BitBuckecie Piotra, https://bitbucket.org/piotrstawirej/financial-system/src/master/.

Materiały dodatkowe:Growing Object-Oriented Software Guided by Tests, Steve Freeman, Pryce, klasyka gatunku na temat implementacji systemów w podejściu Object-Oriented i Test Driven DevelopmentTest Driven Development: By Example, Kent Beck, druga z klasycznych książek na temat TDDMocks, Fakes, Stubs and Dummies, xUnitPatterns.com, zestawienie terminologii Test Doubles w literaturze

Materiały dodatkowe:xUnitPatterns Test Smells, lista Test Smells według Gerarda MeszarosaSoftware Unit Tests Smells, uzupełnienie listy o inne smelle i jedocześnie tool do ich wykrywaniaPIT Mutation Testing, testowanie mutacyjne w JavaInfectionn PHP, testowanie mutacyjne w PHPStryket.NET, testowanie mutacyjne w .NETMutant, testowanie mutacyjne w RubyData i czas dla programistów, Michał Pipa, Boiling Frogs 2017, ciekawa prezentacja na temat "jak bardzo skomplikowany może być czas"

Materiały dodatkowe:Value Object, bliki Martina Fowlera, strona, której przedstawiać raczej nie trzeba...Value Object, c2 wikiValue Object Should Be Immutable, c2 wikiThe CHECKS Pattern Language of Information Integrity, Ward Cunningham, zestawienie 11 wzorców zarządzania spójnością informacji, gdzie opisany jest wzorzec Whole Value

Materiały dodatkowe:Common mistakes when moving to microservices & cloud, prezentacja Kuby z Confitury 2019, same slajdy można pobrać tutajDesigning Event-Driven Systems: Concepts and Patterns for Streaming Services with Apache Kafka, Ben Stopford, wspomniana w rozmowie książka o projektowaniu systemów w architekturze Event-DrivenThe Influence of Organizational Structure on Software Quality: An Empirical Case Study, opracowanie case study Microsoftu od Nachiappan Nagappan, Brendan Murphy, Victor R. BasiliThe Cathedral and the Bazaar, Eric Steven Raymond, wersja Postscript eseju Erica Raymonda o projektach Open-Source z obserwacji na przykładzie m.in. jądra LinuksaPolecam także śledzić profil Kuby na Twitterze, pojawia się tam sporo ciekawych materiałów i treści.

Materiały dodatkowe:Blog Michała Bartyzela, sporo ciekawych tekstów dotyczących także zbierania i analizy wymagań w projektach IT, treści jest tu dużo, Michał pisze tego bloga od 12 latWriting Effective Use-Cases, Alistair CockburnPatterns for Effective Use Cases, Alistair CockburnZainteresowanych tą tematyką polecam także grupę Michała na Facebooku IT spotyka klienta, gdzie można o inch podyskutować albo poczytać.

Jedyną stałą rzeczą w projektach IT jest zmiana, także czas na... zmiany. W tym wyjątkowo krótkim odcinku opowiem Ci więc o moich planach dotyczących Better Software Design w najbliższym czasie. Na najbliższy pełny odcinek podcastu nie trzeba będzie długo czekać. Pojawi się on już jutro, 1 września z samego rana. Zapraszam!

Materiały dodatkowe:Refactoring: Improving the Design of Existing Code,Martin Fowler, with Kent Beck , klasyka gatunkuWorking Effectively with Legacy Code, Michael Feathers, druga klasyka warta przeczytania i posiadania w swojej biblioteczceFearless Refactoring: Rails Controllers, Andrzej Krzywda, wspomniana przez Andrzeja jego książka o refaktoryzacji Railsowych kontrolerówKatalog przekształceń refaktoryzacyjnych Martina FowleraTrunkBasedDevelopment.com, skarbnica wiedzy jeśli chodzi o podejście Trunk Based. Można tu znaleźć zarówno przypadki użycia tej techniki, jak i przydatne wzorce, rozwiązujące typowe problemyNasze profile na Instagramie:Profil Andrzeja KrzywdyProfil Mariusza GilaPrzy okazji wizyty Andrzeja w studio nagraliśmy coś jeszcze! Zapraszam do śledzenia mojego kanału na YouTube.

Materiały dodatkowe:Eric Evans, Domain Driven Design: Tackling Complexity In The Hearth Of Software, rozdział 16Zaawansowane modelowanie DDD, techniki strategiczne: konteksty i architektura zdarzeniowa, Sławek Sobótka, część 2 cyklu artykułów "Domain Driven Design krok po kroku" SławkaWspominaliśmy także kanały YouTube:kanał Mariusza z otwierającym projekt "EventStorming i 4 poziomy zdarzeńkanał DevUpgrade.online Kuby Pilimona i Sławka Sobótki

Materiały:Bounded Context, krótkie wprowadzenie do wzorca na Bliki Martina FowleraEvent Storming - od analizy do architektury, prezentacja Sławka Sobótki o wykorzystaniu EventStormingu w procesie analizy, ponad 2.5 godziny konkretnej wiedzyThe Art of Discovering Bounded Contexts, prezentacja Nicka TuneThe Secrets of Consulting: A Guide to Giving and Getting Advice Successfully, Gerald M. WeinbergMore Secrets of Consulting: The Consultant's Tool Kit, Gerald M. WeinbergDivergent, Emergent, Convergent Thinking - 3 Thinking Modes, procesy kreatywne i mechanika ich działania

Materiały:Aspect-Oriented Programming, Gregor Kiczales, John Lamping, Anurag Mendhekar, Chris Maeda, Cristina Lopes, Jean-Marc Loingtier and John Irwin, pochodzący z 1997 roku i Xerox Palo Alto Research Center whitepaper opisujący podejście AOPRuby and AOP: Decouple your code even more, post Marcina Grzywaczewskiego na blogu ArkencyProgramowanie aspektowe: studium empiryczne, Michał Stochmiałek, praca magisterska z 2005 z Politechniki Wrocławskiej, jak ktoś ma więcej wolnego czasu...Biblioteki i narzędzia:AspectJ, implementacja AOP dla JavyAspect Oriented Programming with Spring, dokumentacja opisująca możliwości wykorzystania AOP we frameworku SpringGo! AOP PHP, implementacja AOP dla PHPFlow Framework, inna implementacja dla PHP we frameworku FlowAquarium, implementacja AOP dla RubyAspect-Oriented Programming on .NET Framework, implementacja na platformę .NETJeśli korzystacie z jakiejś innej implementacji, chętnie zaktualizuję listę o nowe pozycje.

Materiały do odcinka:Versioning in an Event Sourced System, Greg YoungPrezentacja Łukasza Szydło z Boiling Frogs 2020 DDD - o jeden krok za daleko. Nie wspominaliśmy tej prezentacji w odcinku, ale zdecydowanie jest warta polecenia. Łukasz omawia w niej swoje doświadczenia z różnymi podejściami do persystencji. Nagranie z konferencji chyba jeszcze się nie ukazało...Patterns, Principles, and Practices of Domain-Driven Design, Scott Millett, Nick Tune, rozdział 21 "Aggregates Persistence Strategies"

Materiały:Saga, opracowanie naukowe, Hectora Molina-Garcia oraz Kennetha Salem, 1987Wzorzec Saga w katalogu Microservices.ioApplying the Saga Pattern, prezentacja Caitie McCaffrey GOTO Conference 2015Distributed Sagas: A Protocol for Coordinating Microservices, prezentacja Caitie McCaffrey z JOTB17Saga: How to implement complex business transactions without two phase commit, Bernd RuckerMicrosoft CQRS Journey, Saga on SagasWzorzec Process Manager w Enterprise Integration Patterns, Martin Fowler, tutaj odsyłamy do internetowego podsumowania, więcej o wzorcu można znaleźć w samej książce

Materiały:Repozytorium Awesome EventStorming na Githubie, sekcja Remote EventStorming

W tym odcinku razem z Łukaszem Szydło rozmawiamy o różnych odmianach języka wszechobecnego, jaki może pojawić się w rozmowach pomiędzy uczestnikami projektu.

Materiały:Chinese Singles Buy Movie Tickets So Couples Can't Sit Together on Valentine's Day, Time.comRepozytorium Aggregates By Example, przykłady różnych implementacji agregatówRepozytorium DDD By Example, projekt Library

Materiały:Repozytorium Aggregates by Example, kod przykładu z dokumentem i załącznikami znajduje się tutaj