<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:googleplay="http://www.google.com/schemas/play-podcasts/1.0" xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd" xmlns:media="http://search.yahoo.com/mrss/" xmlns:podcast="https://podcastindex.org/namespace/1.0">
  <channel>
    <atom:link href="https://feeds.simplecast.com/KIo9ot3b" rel="self" title="MP3 Audio" type="application/atom+xml"/>
    <atom:link href="https://simplecast.superfeedr.com" rel="hub" xmlns="http://www.w3.org/2005/Atom"/>
    <generator>https://simplecast.com</generator>
    <title>Better Software Design</title>
    <description>Better Software Design podcast. Rozmowy o projektowaniu oprogramowania, architekturze i wyzwaniach z tym związanych.</description>
    <copyright>2020-2025 Better Software Design</copyright>
    <language>pl</language>
    <pubDate>Wed, 8 Apr 2026 23:00:00 +0000</pubDate>
    <lastBuildDate>Wed, 8 Apr 2026 23:00:12 +0000</lastBuildDate>
    <image>
      <link>https://bettersoftwaredesign.simplecast.com</link>
      <title>Better Software Design</title>
      <url>https://image.simplecastcdn.com/images/e37e236c-1fa8-459a-81e9-cd3548888657/98559e66-04c8-4cf7-9e2b-1647875b208f/3000x3000/2-2500px.jpg?aid=rss_feed</url>
    </image>
    <link>https://bettersoftwaredesign.simplecast.com</link>
    <itunes:type>episodic</itunes:type>
    <itunes:summary>Better Software Design podcast. Rozmowy o projektowaniu oprogramowania, architekturze i wyzwaniach z tym związanych.</itunes:summary>
    <itunes:author>Mariusz Gil</itunes:author>
    <itunes:explicit>false</itunes:explicit>
    <itunes:image href="https://image.simplecastcdn.com/images/e37e236c-1fa8-459a-81e9-cd3548888657/98559e66-04c8-4cf7-9e2b-1647875b208f/3000x3000/2-2500px.jpg?aid=rss_feed"/>
    <itunes:new-feed-url>https://feeds.simplecast.com/KIo9ot3b</itunes:new-feed-url>
    <itunes:keywords>domain driven design, ddd, programming, software, software architecture</itunes:keywords>
    <itunes:owner>
      <itunes:name>Mariusz Gil</itunes:name>
    </itunes:owner>
    <itunes:category text="Technology"/>
    <item>
      <guid isPermaLink="false">73aadeeb-6228-44d4-8a3b-43e15b12d530</guid>
      <title>102. State Obsession - EDA /Anti/Patterns</title>
      <description><![CDATA[<p>W poprzednim odcinku mówiliśmy o przesadnej szczegółowości eventów. Tym razem uderzamy w drugą stronę — w stronę zdarzeń-worków, które zamiast o biznesie, mówią nam tylko o tym, że "coś się w bazie zmieniło". Razem z Oskarem bierzemy na tapet CRUD-sourcing, często nazywany też obsesją stanu.</p>
<p>State Obsession to sytuacja, w której zamiast faktów takich jak EmailConfirmed czy PersonalDocumentVerified, Twój system wypluwa generyczne UserUpdated. Na pierwszy rzut oka wygląda to na ułatwienie, ale w praktyce to prosty przepis na wyciek szczegółów implementacyjnych i utratę intencji użytkownika.</p>
<p>Zapraszam na stronę <a href="https://bettersoftwaredesign.pl" rel="noopener noreferrer">https://bettersoftwaredesign.pl</a>, gdzie znajdziesz jeszcze więcej materiałów.</p>
]]></description>
      <pubDate>Wed, 8 Apr 2026 23:00:00 +0000</pubDate>
      <author>Oskar Dudycz</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/102-Zu6j28HM</link>
      <content:encoded><![CDATA[<p>W poprzednim odcinku mówiliśmy o przesadnej szczegółowości eventów. Tym razem uderzamy w drugą stronę — w stronę zdarzeń-worków, które zamiast o biznesie, mówią nam tylko o tym, że "coś się w bazie zmieniło". Razem z Oskarem bierzemy na tapet CRUD-sourcing, często nazywany też obsesją stanu.</p>
<p>State Obsession to sytuacja, w której zamiast faktów takich jak EmailConfirmed czy PersonalDocumentVerified, Twój system wypluwa generyczne UserUpdated. Na pierwszy rzut oka wygląda to na ułatwienie, ale w praktyce to prosty przepis na wyciek szczegółów implementacyjnych i utratę intencji użytkownika.</p>
<p>Zapraszam na stronę <a href="https://bettersoftwaredesign.pl" rel="noopener noreferrer">https://bettersoftwaredesign.pl</a>, gdzie znajdziesz jeszcze więcej materiałów.</p>
]]></content:encoded>
      <enclosure length="29090476" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/cd8f58a2-6704-4118-b9b8-dba592515b68/audio/7abdcf63-4e30-43fa-9a5f-56c3e97ac307/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>102. State Obsession - EDA /Anti/Patterns</itunes:title>
      <itunes:author>Oskar Dudycz</itunes:author>
      <itunes:duration>00:30:16</itunes:duration>
      <itunes:summary>W poprzednim odcinku mówiliśmy o przesadnej szczegółowości eventów. Tym razem uderzamy w drugą stronę — w stronę zdarzeń-worków, które zamiast o biznesie, mówią nam tylko o tym, że &quot;coś się w bazie zmieniło&quot;. Razem z Oskarem bierzemy na tapet CRUD-sourcing, często nazywany też obsesją stanu.</itunes:summary>
      <itunes:subtitle>W poprzednim odcinku mówiliśmy o przesadnej szczegółowości eventów. Tym razem uderzamy w drugą stronę — w stronę zdarzeń-worków, które zamiast o biznesie, mówią nam tylko o tym, że &quot;coś się w bazie zmieniło&quot;. Razem z Oskarem bierzemy na tapet CRUD-sourcing, często nazywany też obsesją stanu.</itunes:subtitle>
      <itunes:keywords>crud sourcing, anti-patterns, event driven architecture, event, crud, best practices</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>103</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">7f398759-6669-46e1-820c-1091ae089ab0</guid>
      <title>101. Property Sourcing - EDA /Anti/Patterns</title>
      <description><![CDATA[<p>Rozpoczynamy nową mini-serię, w której bierzemy na warsztat konkretne problemy ze świata Event-Driven Architecture. Razem z Oskarem Dudyczem, autorem bloga eventdriven.io postanowiliśmy przejść przez listę "antywzorców", które sprawiają, że zamiast elastycznych systemów, fundujemy sobie architektoniczną drogę przez mękę. Na pierwszy ogień idzie temat Property Sourcing.</p>
<p>W tym odcinku rozmawiamy z Oskarem m.in. o tym:</p>
<ul>
 <li>dlaczego interfejsy w stylu Jiry i edycja każdego pola z osobna potrafią zepsuć architekturę</li>
 <li>jak Property Sourcing prowadzi do Event Bombardment i dlaczego twoje read modele mogą tego nie udźwignąć</li>
 <li>czym różni się zdarzenie małe od zdarzenia "mniejszego niż powinno być"</li>
 <li>jak wyjść z tej sytuacji obronną ręką, stosując translatory kontraktów i odpowiednie grupowanie danych</li>
</ul>
]]></description>
      <pubDate>Thu, 19 Mar 2026 00:00:00 +0000</pubDate>
      <author>Oskar Dudycz</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/101-U1sp5S6C</link>
      <content:encoded><![CDATA[<p>Rozpoczynamy nową mini-serię, w której bierzemy na warsztat konkretne problemy ze świata Event-Driven Architecture. Razem z Oskarem Dudyczem, autorem bloga eventdriven.io postanowiliśmy przejść przez listę "antywzorców", które sprawiają, że zamiast elastycznych systemów, fundujemy sobie architektoniczną drogę przez mękę. Na pierwszy ogień idzie temat Property Sourcing.</p>
<p>W tym odcinku rozmawiamy z Oskarem m.in. o tym:</p>
<ul>
 <li>dlaczego interfejsy w stylu Jiry i edycja każdego pola z osobna potrafią zepsuć architekturę</li>
 <li>jak Property Sourcing prowadzi do Event Bombardment i dlaczego twoje read modele mogą tego nie udźwignąć</li>
 <li>czym różni się zdarzenie małe od zdarzenia "mniejszego niż powinno być"</li>
 <li>jak wyjść z tej sytuacji obronną ręką, stosując translatory kontraktów i odpowiednie grupowanie danych</li>
</ul>
]]></content:encoded>
      <enclosure length="31907361" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/0c448be6-51c3-4073-8701-a487855abd7f/audio/4035a4c2-0bcd-46ec-846e-31da9f8a1ece/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>101. Property Sourcing - EDA /Anti/Patterns</itunes:title>
      <itunes:author>Oskar Dudycz</itunes:author>
      <itunes:duration>00:33:12</itunes:duration>
      <itunes:summary>Rozpoczynamy nową mini-serię, w której bierzemy na warsztat konkretne problemy ze świata Event-Driven Architecture. Razem z Oskarem Dudyczem,  autorem bloga eventdriven.io postanowiliśmy przejść przez listę &quot;antywzorców&quot;, które sprawiają, że zamiast elastycznych systemów, fundujemy sobie architektoniczną drogę przez mękę. Na pierwszy ogień idzie temat Property Sourcing.</itunes:summary>
      <itunes:subtitle>Rozpoczynamy nową mini-serię, w której bierzemy na warsztat konkretne problemy ze świata Event-Driven Architecture. Razem z Oskarem Dudyczem,  autorem bloga eventdriven.io postanowiliśmy przejść przez listę &quot;antywzorców&quot;, które sprawiają, że zamiast elastycznych systemów, fundujemy sobie architektoniczną drogę przez mękę. Na pierwszy ogień idzie temat Property Sourcing.</itunes:subtitle>
      <itunes:keywords>property sourcing, software, patterns, event sourcing, event-driven architecture</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>101</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">049331a6-96eb-4b6e-be37-27916c5937bb</guid>
      <title>100. O AI w strategicznym Domain-Driven Design z Kubą Pilimonem</title>
      <description><![CDATA[<p>Better Software Design zaczęło się w 2020 roku od tematów związanych z Domain-Driven Design, gdzie często z Kubą Pilimonem zagłębialiśmy się w kolejne wzorce i przykłady. Po kilku latach wspólnie z Kubą wracamy do tej tematyki, aby sprawdzić, jak zmieniło się nasze postrzeganie Domain-Driven Design i pracy architekta w świecie, który przyspieszył do prędkości mierzonych w tokenach na sekundę.</p>
<p>A rozmowę zaczynamy od pytania Kuby, jednego ze słuchaczy podcastu, które pojawiło się przy okazji zbliżającego się odcinka specjalnego z okazji 100 odcinków Better Software Design.</p>
]]></description>
      <pubDate>Thu, 26 Feb 2026 00:00:00 +0000</pubDate>
      <author>Jakub Pilimon</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/100-5aDWCwI5</link>
      <content:encoded><![CDATA[<p>Better Software Design zaczęło się w 2020 roku od tematów związanych z Domain-Driven Design, gdzie często z Kubą Pilimonem zagłębialiśmy się w kolejne wzorce i przykłady. Po kilku latach wspólnie z Kubą wracamy do tej tematyki, aby sprawdzić, jak zmieniło się nasze postrzeganie Domain-Driven Design i pracy architekta w świecie, który przyspieszył do prędkości mierzonych w tokenach na sekundę.</p>
<p>A rozmowę zaczynamy od pytania Kuby, jednego ze słuchaczy podcastu, które pojawiło się przy okazji zbliżającego się odcinka specjalnego z okazji 100 odcinków Better Software Design.</p>
]]></content:encoded>
      <enclosure length="69324262" type="audio/mpeg" url="https://cdn.simplecast.com/media/audio/transcoded/10d98846-68e9-41ec-bdf6-bba1b029b3a4/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/audio/group/b70a8e04-8606-4d4a-89a6-de8d6db302c2/group-item/e5ff725f-2035-4f5f-8fb8-aa25557ad3c4/128_default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>100. O AI w strategicznym Domain-Driven Design z Kubą Pilimonem</itunes:title>
      <itunes:author>Jakub Pilimon</itunes:author>
      <itunes:duration>01:12:09</itunes:duration>
      <itunes:summary>Better Software Design zaczęło się w 2020 roku od tematów związanych z Domain-Driven Design, gdzie często z Kubą Pilimonem zagłębialiśmy się w kolejne wzorce i przykłady. Po kilku latach wspólnie z Kubą wracamy do tej tematyki, aby sprawdzić, jak zmieniło się nasze postrzeganie Domain-Driven Design i pracy architekta w świecie, który przyspieszył do prędkości mierzonych w tokenach na sekundę.</itunes:summary>
      <itunes:subtitle>Better Software Design zaczęło się w 2020 roku od tematów związanych z Domain-Driven Design, gdzie często z Kubą Pilimonem zagłębialiśmy się w kolejne wzorce i przykłady. Po kilku latach wspólnie z Kubą wracamy do tej tematyki, aby sprawdzić, jak zmieniło się nasze postrzeganie Domain-Driven Design i pracy architekta w świecie, który przyspieszył do prędkości mierzonych w tokenach na sekundę.</itunes:subtitle>
      <itunes:keywords>domain-driven design, claude code, software development, ai, ddd, llm</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>100</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">9db108c5-02a7-4d48-ad94-df4fa44eeaa7</guid>
      <title>99. O architekturze oprogramowania w erze AI-Assisted development z Łukaszem Szydło i Marcinem Markowskim</title>
      <description><![CDATA[<p>Od ostatnich odcinków minęło trochę czasu, ale świat IT nie stał w miejscu – wręcz przeciwnie, przyspieszył tak, że momentami trudno nadążyć. Dlatego w tym odcinku, wspólnie z Łukaszem Szydło i Marcinem Markowskim, próbujemy po prostu głośno zastanowić się, co tak naprawdę dzieje się z pracą architekta oprogramowania i ogólnie architekturą software'u w dobie wszechobecnego Generative AI.</p><p>Gdy kolejne modele wychodzą w coraz szybszym tempie, w zasadzie trochę trudno rozmawiać o tym, jakie 10 narzędzi zmieni Twoje życie architekta, z których warto korzystać już teraz. Zamiast tego usiedliśmy, żeby porozmawiać o naszych spostrzeżeniach i obserwacjach z placu boju. AI wpędza nas po trochu w pułapkę: kod powstaje błyskawicznie, ale nasze ludzkie moce przerobowe do jego czytania i weryfikacji pozostają w zasadzie bez zmian. Czy przez to nie zmieniamy się powoli w redaktorów kodu i czy Code Review nie stanie się zaraz największym wąskim gardłem w naszych projektach? Ale Code Review jest tylko jednym z etapów procesu Software Development Lifecycle, na którym widać wpływ narzędzi AI.</p><p>Ogłoszenie!</p><p>Już niedługo, bo 17 lutego, będziemy mogli się spotkać na otwartym warsztacie <strong>DevHours: Fullstack x EventStorming</strong>, który mam przyjemność współorganizować z <strong>Capgemini</strong>. Jeśli interesujesz się oprogramowaniem i chcesz podnieść swoje umiejętności w projektowaniu software'u, zapraszam do <a href="https://www.capgemini.com/pl-pl/aktualnosci/wydarzenia/devhours-fullstack-x-event-storming/">rejestracji</a>.</p>
]]></description>
      <pubDate>Thu, 5 Feb 2026 00:00:00 +0000</pubDate>
      <author>Marcin Markowski, Łukasz Szydło</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/99-SenCcuyo</link>
      <content:encoded><![CDATA[<p>Od ostatnich odcinków minęło trochę czasu, ale świat IT nie stał w miejscu – wręcz przeciwnie, przyspieszył tak, że momentami trudno nadążyć. Dlatego w tym odcinku, wspólnie z Łukaszem Szydło i Marcinem Markowskim, próbujemy po prostu głośno zastanowić się, co tak naprawdę dzieje się z pracą architekta oprogramowania i ogólnie architekturą software'u w dobie wszechobecnego Generative AI.</p><p>Gdy kolejne modele wychodzą w coraz szybszym tempie, w zasadzie trochę trudno rozmawiać o tym, jakie 10 narzędzi zmieni Twoje życie architekta, z których warto korzystać już teraz. Zamiast tego usiedliśmy, żeby porozmawiać o naszych spostrzeżeniach i obserwacjach z placu boju. AI wpędza nas po trochu w pułapkę: kod powstaje błyskawicznie, ale nasze ludzkie moce przerobowe do jego czytania i weryfikacji pozostają w zasadzie bez zmian. Czy przez to nie zmieniamy się powoli w redaktorów kodu i czy Code Review nie stanie się zaraz największym wąskim gardłem w naszych projektach? Ale Code Review jest tylko jednym z etapów procesu Software Development Lifecycle, na którym widać wpływ narzędzi AI.</p><p>Ogłoszenie!</p><p>Już niedługo, bo 17 lutego, będziemy mogli się spotkać na otwartym warsztacie <strong>DevHours: Fullstack x EventStorming</strong>, który mam przyjemność współorganizować z <strong>Capgemini</strong>. Jeśli interesujesz się oprogramowaniem i chcesz podnieść swoje umiejętności w projektowaniu software'u, zapraszam do <a href="https://www.capgemini.com/pl-pl/aktualnosci/wydarzenia/devhours-fullstack-x-event-storming/">rejestracji</a>.</p>
]]></content:encoded>
      <enclosure length="97548959" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/c1c53b0b-254c-43e3-a587-127a2a69f3bb/audio/03b6f376-c3fd-4563-bb39-5cee74c7e1f1/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>99. O architekturze oprogramowania w erze AI-Assisted development z Łukaszem Szydło i Marcinem Markowskim</itunes:title>
      <itunes:author>Marcin Markowski, Łukasz Szydło</itunes:author>
      <itunes:duration>01:41:34</itunes:duration>
      <itunes:summary>Od ostatnich odcinków minęło trochę czasu, ale świat IT nie stał w miejscu – wręcz przeciwnie, przyspieszył tak, że momentami trudno nadążyć. Dlatego w tym odcinku, wspólnie z Łukaszem Szydło i Marcinem Markowskim, próbujemy po prostu głośno zastanowić się, co tak naprawdę dzieje się z pracą architekta oprogramowania i ogólnie architekturą software&apos;u w dobie wszechobecnego Generative AI.</itunes:summary>
      <itunes:subtitle>Od ostatnich odcinków minęło trochę czasu, ale świat IT nie stał w miejscu – wręcz przeciwnie, przyspieszył tak, że momentami trudno nadążyć. Dlatego w tym odcinku, wspólnie z Łukaszem Szydło i Marcinem Markowskim, próbujemy po prostu głośno zastanowić się, co tak naprawdę dzieje się z pracą architekta oprogramowania i ogólnie architekturą software&apos;u w dobie wszechobecnego Generative AI.</itunes:subtitle>
      <itunes:keywords>sdlc, software development lifecycle, sztuczna inteligencja, software architecture, ai, claud code, ddd, gen ai</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>99</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">9e6f7aca-54d7-4625-b59c-b587bfaa35ce</guid>
      <title>98. O agregatach, eventach i Dynamic Consistency Boundary z Pawłem Pacaną</title>
      <description><![CDATA[<p>W świecie Domain-Driven Design, Agregat jest powszechnie uznawany za jeden z fundamentalnych wzorców odpowiedzialnych za spójność danych. To on wyznacza granicę transakcyjną, wewnątrz której pilnujemy niezmienników biznesowych, gwarantując integralność naszego modelu. Ale co w sytuacji, gdy ta z góry zdefiniowana, statyczna granica staje się pewnym ograniczeniem? </p><p>Czy w każdym procesie biznesowym potrzebujemy dokładnie tego samego, silnego poziomu spójności i czy sztywny podział na agregaty zawsze idealnie odzwierciedla dynamiczną naturę problemu, który modelujemy?</p><p>Okazuje się, że możemy podejść do tego zagadnienia w bardziej elastyczny sposób. W tym odcinku, wraz z moim gościem, Pawłem Pacaną z firmy Arkency, dokładnie przyjrzymy się koncepcji Dynamic Consistency Boundary. Porozmawiamy o tym, jak można myśleć o spójności nie jako o statycznej, raz ustalonej granicy, ale jako o koncepcji, która dopasowuje się do kontekstu konkretnej operacji biznesowej.</p><p>W tym odcinku usłyszysz między innymi o:</p><ul><li>trudnościach w projektowaniu i długoterminowym utrzymaniu agregatów w systemie</li><li>Dynamic Consistency Boundary i czym ten wzorzec różni się od klasycznego podejścia z agregatem</li><li>tagowaniu i linkowaniu zdarzeń pomiędzy strumieniami</li><li>wymaganiach dla event-store, aby stosowanie Dynamic Consistency Boundary było w ogóle możliwe </li><li>pułapkach, na które należy zwrócić szczególną uwagę, by wykorzystanie DCB nie stało się problem</li></ul><p>Materiały dodatkowe do tego odcinka znajdują się na stronie tego odcinka na <a href="https://bettersoftwaredesign.pl/podcast/o-agregatach-eventach-i-dynamic-consistency-boundary-z-pawlem-pacana/">bettersoftwaredesign.pl</a>.</p><p>YouTube Alert! Odcinki podcastu są także dostępne na <a href="https://www.youtube.com/c/MariuszGil">moim kanale na YouTube</a>. Warto zasubskrybować, aby być na bieżąco z kolejnymi odcinkami.</p>
]]></description>
      <pubDate>Tue, 9 Sep 2025 23:00:00 +0000</pubDate>
      <author>Paweł Pacana</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/98-nM1hSWrB</link>
      <content:encoded><![CDATA[<p>W świecie Domain-Driven Design, Agregat jest powszechnie uznawany za jeden z fundamentalnych wzorców odpowiedzialnych za spójność danych. To on wyznacza granicę transakcyjną, wewnątrz której pilnujemy niezmienników biznesowych, gwarantując integralność naszego modelu. Ale co w sytuacji, gdy ta z góry zdefiniowana, statyczna granica staje się pewnym ograniczeniem? </p><p>Czy w każdym procesie biznesowym potrzebujemy dokładnie tego samego, silnego poziomu spójności i czy sztywny podział na agregaty zawsze idealnie odzwierciedla dynamiczną naturę problemu, który modelujemy?</p><p>Okazuje się, że możemy podejść do tego zagadnienia w bardziej elastyczny sposób. W tym odcinku, wraz z moim gościem, Pawłem Pacaną z firmy Arkency, dokładnie przyjrzymy się koncepcji Dynamic Consistency Boundary. Porozmawiamy o tym, jak można myśleć o spójności nie jako o statycznej, raz ustalonej granicy, ale jako o koncepcji, która dopasowuje się do kontekstu konkretnej operacji biznesowej.</p><p>W tym odcinku usłyszysz między innymi o:</p><ul><li>trudnościach w projektowaniu i długoterminowym utrzymaniu agregatów w systemie</li><li>Dynamic Consistency Boundary i czym ten wzorzec różni się od klasycznego podejścia z agregatem</li><li>tagowaniu i linkowaniu zdarzeń pomiędzy strumieniami</li><li>wymaganiach dla event-store, aby stosowanie Dynamic Consistency Boundary było w ogóle możliwe </li><li>pułapkach, na które należy zwrócić szczególną uwagę, by wykorzystanie DCB nie stało się problem</li></ul><p>Materiały dodatkowe do tego odcinka znajdują się na stronie tego odcinka na <a href="https://bettersoftwaredesign.pl/podcast/o-agregatach-eventach-i-dynamic-consistency-boundary-z-pawlem-pacana/">bettersoftwaredesign.pl</a>.</p><p>YouTube Alert! Odcinki podcastu są także dostępne na <a href="https://www.youtube.com/c/MariuszGil">moim kanale na YouTube</a>. Warto zasubskrybować, aby być na bieżąco z kolejnymi odcinkami.</p>
]]></content:encoded>
      <enclosure length="42227856" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/19841e6e-edb0-4346-9f45-5c1616bc6286/audio/b286edba-fa5a-4a49-ba5a-2b943c63f786/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>98. O agregatach, eventach i Dynamic Consistency Boundary z Pawłem Pacaną</itunes:title>
      <itunes:author>Paweł Pacana</itunes:author>
      <itunes:duration>00:43:58</itunes:duration>
      <itunes:summary>W świecie Domain-Driven Design, Agregat jest powszechnie uznawany za jeden z fundamentalnych wzorców odpowiedzialnych za spójność danych. To on wyznacza granicę transakcyjną, wewnątrz której pilnujemy niezmienników biznesowych, gwarantując integralność naszego modelu. Ale co w sytuacji, gdy ta z góry zdefiniowana, statyczna granica staje się pewnym ograniczeniem?</itunes:summary>
      <itunes:subtitle>W świecie Domain-Driven Design, Agregat jest powszechnie uznawany za jeden z fundamentalnych wzorców odpowiedzialnych za spójność danych. To on wyznacza granicę transakcyjną, wewnątrz której pilnujemy niezmienników biznesowych, gwarantując integralność naszego modelu. Ale co w sytuacji, gdy ta z góry zdefiniowana, statyczna granica staje się pewnym ograniczeniem?</itunes:subtitle>
      <itunes:keywords>dynamic consistency boundary, aggregate, data consistency, dcb, event driven architecture, sara pellegrini</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>98</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">4fd5560c-1edb-4a61-841f-48f2cb495c81</guid>
      <title>97. O architekturze mikrofrontendów i mikroserwisach Allegro z Bartoszem Gałkiem prowadzi Tomasz Ducin - część 2</title>
      <description><![CDATA[<p>Ponad 2000 osób w 500 zespołach, 3000 różnych mikroserwisów i kilkaset tysięcy eventów na sekundę - skala Allegro zawsze robi wrażenie. Jak w tym wszystkim wdrożono architekturę mikrofrontendów, która pozwala sprawnie łączyć różne mikroserwisy i tworzyć podstrony największego w Polsce e-commerce'u prosto z panelu?</p><p>W drugiej części rozmowy o mikrforontendach, Bartosz Gałek, Principal Engineer w Allegro, uchyli rąbka tajemnicy i przedstawi trochę technikaliów. </p><p>W tym odcinku usłyszysz między innymi o:</p><ul><li>skali systemu, z jaką mierzą się zespoły developerskie Allegro</li><li>wybranych metrykach zapewniających observability systemu od strony frontendowej</li><li>projektowaniu optymalizacji i zapewnianiu dużej wydajności systemu</li><li>projektowaniu stron portalu z użyciem komponentów i wprowadzaniu nowych funkcjonalności na produkcję</li><li>streamingu HTML-a</li><li>stopniowej migracji monolitu do architektury mikroserwisowej</li></ul><p>Dzięki Bartkowi mamy możliwość zajrzeć za kulisy i zobaczyć co się dzieje "pod maską" Allegro, gdy odwiedzasz przykładowo podstronę interesującego Cię produktu. I dlaczego, dzięki stosowanym rozwiązaniom i optymalizacjom, jest to tak wydajne...</p><p>Materiały dodatkowe do tego odcinka znajdują się na stronie tego odcinka na <a href="https://bettersoftwaredesign.pl/podcast/o-architekturze-mikrofrontendow-i-mikroserwisach-allegro-z-bartoszem-galkiem-prowadzi-tomasz-ducin-czesc-2/">bettersoftwaredesign.pl</a>.</p><p>YouTube Alert! Odcinki podcastu są także dostępne na <a href="https://www.youtube.com/c/MariuszGil">moim kanale na YouTube</a>. Warto zasubskrybować, aby być na bieżąco z kolejnymi odcinkami.</p>
]]></description>
      <pubDate>Mon, 7 Apr 2025 23:00:00 +0000</pubDate>
      <author>bartosz gałek</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/97-x54wmZo9</link>
      <content:encoded><![CDATA[<p>Ponad 2000 osób w 500 zespołach, 3000 różnych mikroserwisów i kilkaset tysięcy eventów na sekundę - skala Allegro zawsze robi wrażenie. Jak w tym wszystkim wdrożono architekturę mikrofrontendów, która pozwala sprawnie łączyć różne mikroserwisy i tworzyć podstrony największego w Polsce e-commerce'u prosto z panelu?</p><p>W drugiej części rozmowy o mikrforontendach, Bartosz Gałek, Principal Engineer w Allegro, uchyli rąbka tajemnicy i przedstawi trochę technikaliów. </p><p>W tym odcinku usłyszysz między innymi o:</p><ul><li>skali systemu, z jaką mierzą się zespoły developerskie Allegro</li><li>wybranych metrykach zapewniających observability systemu od strony frontendowej</li><li>projektowaniu optymalizacji i zapewnianiu dużej wydajności systemu</li><li>projektowaniu stron portalu z użyciem komponentów i wprowadzaniu nowych funkcjonalności na produkcję</li><li>streamingu HTML-a</li><li>stopniowej migracji monolitu do architektury mikroserwisowej</li></ul><p>Dzięki Bartkowi mamy możliwość zajrzeć za kulisy i zobaczyć co się dzieje "pod maską" Allegro, gdy odwiedzasz przykładowo podstronę interesującego Cię produktu. I dlaczego, dzięki stosowanym rozwiązaniom i optymalizacjom, jest to tak wydajne...</p><p>Materiały dodatkowe do tego odcinka znajdują się na stronie tego odcinka na <a href="https://bettersoftwaredesign.pl/podcast/o-architekturze-mikrofrontendow-i-mikroserwisach-allegro-z-bartoszem-galkiem-prowadzi-tomasz-ducin-czesc-2/">bettersoftwaredesign.pl</a>.</p><p>YouTube Alert! Odcinki podcastu są także dostępne na <a href="https://www.youtube.com/c/MariuszGil">moim kanale na YouTube</a>. Warto zasubskrybować, aby być na bieżąco z kolejnymi odcinkami.</p>
]]></content:encoded>
      <enclosure length="61597915" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/99968062-3e61-4406-b226-ccfd51260853/audio/d1ae814f-a3f6-42fc-8aa0-a3d8220d90eb/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>97. O architekturze mikrofrontendów i mikroserwisach Allegro z Bartoszem Gałkiem prowadzi Tomasz Ducin - część 2</itunes:title>
      <itunes:author>bartosz gałek</itunes:author>
      <itunes:duration>01:04:08</itunes:duration>
      <itunes:summary>Ponad 2000 osób w 500 zespołach, 3000 różnych mikroserwisów i kilkaset tysięcy eventów na sekundę - skala Allegro zawsze robi wrażenie. Jak w tym wszystkim wdrożono architekturę mikrofrontendów, która pozwala sprawnie łączyć różne mikroserwisy i tworzyć podstrony największego w Polsce e-commerce&apos;u prosto z panelu?</itunes:summary>
      <itunes:subtitle>Ponad 2000 osób w 500 zespołach, 3000 różnych mikroserwisów i kilkaset tysięcy eventów na sekundę - skala Allegro zawsze robi wrażenie. Jak w tym wszystkim wdrożono architekturę mikrofrontendów, która pozwala sprawnie łączyć różne mikroserwisy i tworzyć podstrony największego w Polsce e-commerce&apos;u prosto z panelu?</itunes:subtitle>
      <itunes:keywords>allegro, microservices architecture, microfrontends, software architecture, architektura mikroserwisowa, refactoring, frontend architecture, monolith</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>97</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">36cffcd7-83e1-4534-9ad7-8fc4391c1281</guid>
      <title>96. O dostarczaniu eventów w systemach rozproszonych z Michałem Ostruszką</title>
      <description><![CDATA[<p>Rozpraszanie systemu na szereg działających niezależnie od siebie usług, przy wszystkich oczywistych korzyściach dla ogólnej architektury i współpracy pomiędzy zespołami, niesie za sobą kilka istotnych konsekwencji. Przykładowo, dostarczenie zdarzenia czy innego komunikatu pomiędzy serwisami przestaje być już tak oczywiste i bezproblemowe, jak to jest w przypadku monolitycznych aplikacji komunikujących się wewnątrz in-memory.</p><p>Sieć ze swojej natury bywa zawodna, przerwa w dostarczaniu wiadomości, czy też dostarczanie ich do konsumentów w losowej kolejności nie są sytuacjami czysto hipotetycznymi. Wcześniej czy później taka sytuacja przydarzy się w systemie, pytanie brzmi tylko "kiedy"...</p><p>Michał Ostruszka w dzisiejszej rozmowie zarysowuje kilka wzorców w kwestii gwarancji dostarczania wiadomości, które obok Outbox Pattern warto mieć w swojej architektonicznej skrzynce z narzędziami. </p><p>Materiały dodatkowe do tego odcinka znajdują się na stronie tego odcinka na <a href="https://bettersoftwaredesign.pl/podcast/o-dostarczaniu-eventow-w-systemach-rozproszonych-z-michalem-ostruszka/">bettersoftwaredesign.pl</a>.</p><p>YouTube Alert! Odcinki podcastu są także dostępne na <a href="https://www.youtube.com/c/MariuszGil">moim kanale na YouTube</a>. Warto zasubskrybować, aby być na bieżąco z kolejnymi odcinkami.</p>
]]></description>
      <pubDate>Tue, 25 Mar 2025 00:00:00 +0000</pubDate>
      <author>Michał Ostruszka</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/96-0_uQUKCA</link>
      <content:encoded><![CDATA[<p>Rozpraszanie systemu na szereg działających niezależnie od siebie usług, przy wszystkich oczywistych korzyściach dla ogólnej architektury i współpracy pomiędzy zespołami, niesie za sobą kilka istotnych konsekwencji. Przykładowo, dostarczenie zdarzenia czy innego komunikatu pomiędzy serwisami przestaje być już tak oczywiste i bezproblemowe, jak to jest w przypadku monolitycznych aplikacji komunikujących się wewnątrz in-memory.</p><p>Sieć ze swojej natury bywa zawodna, przerwa w dostarczaniu wiadomości, czy też dostarczanie ich do konsumentów w losowej kolejności nie są sytuacjami czysto hipotetycznymi. Wcześniej czy później taka sytuacja przydarzy się w systemie, pytanie brzmi tylko "kiedy"...</p><p>Michał Ostruszka w dzisiejszej rozmowie zarysowuje kilka wzorców w kwestii gwarancji dostarczania wiadomości, które obok Outbox Pattern warto mieć w swojej architektonicznej skrzynce z narzędziami. </p><p>Materiały dodatkowe do tego odcinka znajdują się na stronie tego odcinka na <a href="https://bettersoftwaredesign.pl/podcast/o-dostarczaniu-eventow-w-systemach-rozproszonych-z-michalem-ostruszka/">bettersoftwaredesign.pl</a>.</p><p>YouTube Alert! Odcinki podcastu są także dostępne na <a href="https://www.youtube.com/c/MariuszGil">moim kanale na YouTube</a>. Warto zasubskrybować, aby być na bieżąco z kolejnymi odcinkami.</p>
]]></content:encoded>
      <enclosure length="40992253" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/e18a2145-1c61-4b47-b311-589af2da73b1/audio/3029f9b1-b561-42bb-8cc7-f37d6d94bd3e/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>96. O dostarczaniu eventów w systemach rozproszonych z Michałem Ostruszką</itunes:title>
      <itunes:author>Michał Ostruszka</itunes:author>
      <itunes:duration>00:42:40</itunes:duration>
      <itunes:summary>Rozpraszanie systemu na szereg działających niezależnie od siebie usług, przy wszystkich oczywistych korzyściach dla ogólnej architektury i współpracy pomiędzy zespołami, niesie za sobą kilka istotnych konsekwencji. Przykładowo, dostarczenie zdarzenia czy innego komunikatu pomiędzy serwisami przestaje być już tak oczywiste i bezproblemowe, jak to jest w przypadku monolitycznych aplikacji komunikujących się wewnątrz in-memory.</itunes:summary>
      <itunes:subtitle>Rozpraszanie systemu na szereg działających niezależnie od siebie usług, przy wszystkich oczywistych korzyściach dla ogólnej architektury i współpracy pomiędzy zespołami, niesie za sobą kilka istotnych konsekwencji. Przykładowo, dostarczenie zdarzenia czy innego komunikatu pomiędzy serwisami przestaje być już tak oczywiste i bezproblemowe, jak to jest w przypadku monolitycznych aplikacji komunikujących się wewnątrz in-memory.</itunes:subtitle>
      <itunes:keywords>wzorce integracyjne, change data capture, finger printing, komunikacja sieciowa, event-driven architecture, outbox pattern, listen to yourself</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>96</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">a1e3ae02-1ea4-4c5f-bbc6-f56ec82ff783</guid>
      <title>95. O architekturze mikrofrontendów i mikroserwisach Allegro z Bartoszem Gałkiem prowadzi Tomasz Ducin</title>
      <description><![CDATA[<p>Termin "microservices architecture" w ostatnich latach był odmieniany przez wszystkie możliwe przypadki. Przeważnie jednak ten styl architektoniczny przewijał się w kontekście rozwiązań backendowych i wyciągania z monolitów fragmentów jego funkcjonalności. Rzadko jednak mówiło się o projektowaniu rozwiązań frontendowych w tego rodzaju systemach...</p><p>Netlifx, Amazon, Spotify czy Uber - te firmy przychodzą z pewnością na myśl jako przykłady popularnych wdrożeń mikroserwisów. W Polsce zdecydowanie jest to Allegro, które dokonało migracji z monolitycznego systemu PHP do właśnie takiej architektury i innych technologii.</p><p>Tomasz Ducin i Bartosz Gałek, Principal Engineer w Allegro, zaglądają "pod maskę" największego portalu ecommerce w Polsce, aby porozmawiać na temat architektury microfrontendów.</p><p>Materiały dodatkowe do tego odcinka znajdują się na stronie tego odcinka na <a href="https://bettersoftwaredesign.pl/podcast/o-architekturze-mikrofrontendow-i-mikroserwisach-allegro-z-bartoszem-galkiem-prowadzi-tomasz-ducin-czesc-1/">bettersoftwaredesign.pl</a>.</p>
]]></description>
      <pubDate>Wed, 5 Mar 2025 00:00:00 +0000</pubDate>
      <author>Bartosz Gałek, Tomasz Ducin</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/95-SFvytOU9</link>
      <content:encoded><![CDATA[<p>Termin "microservices architecture" w ostatnich latach był odmieniany przez wszystkie możliwe przypadki. Przeważnie jednak ten styl architektoniczny przewijał się w kontekście rozwiązań backendowych i wyciągania z monolitów fragmentów jego funkcjonalności. Rzadko jednak mówiło się o projektowaniu rozwiązań frontendowych w tego rodzaju systemach...</p><p>Netlifx, Amazon, Spotify czy Uber - te firmy przychodzą z pewnością na myśl jako przykłady popularnych wdrożeń mikroserwisów. W Polsce zdecydowanie jest to Allegro, które dokonało migracji z monolitycznego systemu PHP do właśnie takiej architektury i innych technologii.</p><p>Tomasz Ducin i Bartosz Gałek, Principal Engineer w Allegro, zaglądają "pod maskę" największego portalu ecommerce w Polsce, aby porozmawiać na temat architektury microfrontendów.</p><p>Materiały dodatkowe do tego odcinka znajdują się na stronie tego odcinka na <a href="https://bettersoftwaredesign.pl/podcast/o-architekturze-mikrofrontendow-i-mikroserwisach-allegro-z-bartoszem-galkiem-prowadzi-tomasz-ducin-czesc-1/">bettersoftwaredesign.pl</a>.</p>
]]></content:encoded>
      <enclosure length="62574585" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/96c63159-4c96-425e-a79a-17a12e721ff4/audio/45989d83-ce11-407b-8e64-1fa144fa266f/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>95. O architekturze mikrofrontendów i mikroserwisach Allegro z Bartoszem Gałkiem prowadzi Tomasz Ducin</itunes:title>
      <itunes:author>Bartosz Gałek, Tomasz Ducin</itunes:author>
      <itunes:duration>01:05:07</itunes:duration>
      <itunes:summary>Termin &quot;microservices architecture&quot; w ostatnich latach był odmieniany przez wszystkie możliwe przypadki. Przeważnie jednak ten styl architektoniczny przewijał się w kontekście rozwiązań backendowych i wyciągania z monolitów fragmentów jego funkcjonalności. Rzadko jednak mówiło się o projektowaniu rozwiązań frontendowych w tego rodzaju systemach... </itunes:summary>
      <itunes:subtitle>Termin &quot;microservices architecture&quot; w ostatnich latach był odmieniany przez wszystkie możliwe przypadki. Przeważnie jednak ten styl architektoniczny przewijał się w kontekście rozwiązań backendowych i wyciągania z monolitów fragmentów jego funkcjonalności. Rzadko jednak mówiło się o projektowaniu rozwiązań frontendowych w tego rodzaju systemach... </itunes:subtitle>
      <itunes:keywords>architecture, frontend, allegro, microservices, microfrontend, op-box</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>95</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">93c8ecd1-f719-4bf5-9b58-89a43fc9a9c6</guid>
      <title>94. O integracji serwisów z użyciem kontraktów z Jackiem Milewskim</title>
      <description><![CDATA[<p>Tworzenie integracyjnych środowisk testowych w całym przedsiębiorstwie jest powszechną, marnotrawną praktyką, która spowalnia wszystko i wszystkich. Brzmi ostro lub może także nawet znajomo? Ale właśnie w taki sposób duże środowiska integracyjne są określane w kolejnych wydaniach Technology Radaru Thoughtworks i to od 2017 roku! O rok dłużej, bo od 2016 raport ten sugeruje także wdrażanie testów kontraktowych jako jedno z możliwych rozwiązań tego problemu.</p><p>Temat samych testów kontraktowych pojawił się już w podkaście, w odcinku "O testowaniu kontraktowym z Rafałem Maciakiem". W dzisiejszej rozmowie, wraz z Jackiem Milewskim, uzupełniamy to podejście o aspekty praktyczne, aby zabezpieczanie komunikacji pomiędzy serwisami nie stało się szybko długiem technicznym, którego utrzymanie będzie kosztować wszystkie zespoły czas i niepotrzebne nerwy.</p><p>Materiały dodatkowe do tego odcinka znajdują się na stronie tego odcinka na <a href="https://bettersoftwaredesign.pl/podcast/o-integracji-serwisow-z-uzyciem-kontraktow-z-jackiem-milewskim/">bettersoftwaredesign.pl</a>.</p>
]]></description>
      <pubDate>Tue, 4 Feb 2025 00:00:00 +0000</pubDate>
      <author>Jacek Milewski</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/94-fTg2JSEN</link>
      <content:encoded><![CDATA[<p>Tworzenie integracyjnych środowisk testowych w całym przedsiębiorstwie jest powszechną, marnotrawną praktyką, która spowalnia wszystko i wszystkich. Brzmi ostro lub może także nawet znajomo? Ale właśnie w taki sposób duże środowiska integracyjne są określane w kolejnych wydaniach Technology Radaru Thoughtworks i to od 2017 roku! O rok dłużej, bo od 2016 raport ten sugeruje także wdrażanie testów kontraktowych jako jedno z możliwych rozwiązań tego problemu.</p><p>Temat samych testów kontraktowych pojawił się już w podkaście, w odcinku "O testowaniu kontraktowym z Rafałem Maciakiem". W dzisiejszej rozmowie, wraz z Jackiem Milewskim, uzupełniamy to podejście o aspekty praktyczne, aby zabezpieczanie komunikacji pomiędzy serwisami nie stało się szybko długiem technicznym, którego utrzymanie będzie kosztować wszystkie zespoły czas i niepotrzebne nerwy.</p><p>Materiały dodatkowe do tego odcinka znajdują się na stronie tego odcinka na <a href="https://bettersoftwaredesign.pl/podcast/o-integracji-serwisow-z-uzyciem-kontraktow-z-jackiem-milewskim/">bettersoftwaredesign.pl</a>.</p>
]]></content:encoded>
      <enclosure length="63038358" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/55e6ce1c-95dc-4ee1-98e3-47f1fc163cb5/audio/2002d80a-8829-4b02-9c87-eade181e81ff/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>94. O integracji serwisów z użyciem kontraktów z Jackiem Milewskim</itunes:title>
      <itunes:author>Jacek Milewski</itunes:author>
      <itunes:duration>01:05:34</itunes:duration>
      <itunes:summary>Tworzenie integracyjnych środowisk testowych w całym przedsiębiorstwie jest powszechną, marnotrawną praktyką, która spowalnia wszystko i wszystkich. Brzmi ostro lub może także nawet znajomo? Ale właśnie w taki sposób duże środowiska integracyjne są określane w kolejnych wydaniach Technology Radaru Thoughtworks i to od 2017 roku! O rok dłużej, bo od 2016 raport ten sugeruje także wdrażanie testów kontraktowych jako jedno z możliwych rozwiązań tego problemu.</itunes:summary>
      <itunes:subtitle>Tworzenie integracyjnych środowisk testowych w całym przedsiębiorstwie jest powszechną, marnotrawną praktyką, która spowalnia wszystko i wszystkich. Brzmi ostro lub może także nawet znajomo? Ale właśnie w taki sposób duże środowiska integracyjne są określane w kolejnych wydaniach Technology Radaru Thoughtworks i to od 2017 roku! O rok dłużej, bo od 2016 raport ten sugeruje także wdrażanie testów kontraktowych jako jedno z możliwych rozwiązań tego problemu.</itunes:subtitle>
      <itunes:keywords>api, cdc, contract testing, microservices, architektura mikroserwisowa, testowanie oprogramowania, software testing, pact, pact broker</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>94</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">b4184c48-1fc3-437a-b492-d30616bace74</guid>
      <title>93. Backend vs Frontend: skuteczne testowanie zachowań, unity i integracja</title>
      <description><![CDATA[<p>W pierwszym odcinku w 2025 roku zapraszam na pierwszą odsłonę Backend vs Frontend, gdzie wspólnie z Tomkiem Ducinem bedziemy pochylać się nad różnymi problemami związanymi z software developmentem. Na początek temat testowania i testów integracyjnych, bo jeśli nie testujesz swojego kodu, to jak możesz mieć pewność, że wszystko działa poprawnie?</p><p>Ale “hold your horses”… testy to tylko przyczynek do tego, aby porozmawiać w luźnej atmosferze o wielu ważnych rzeczach dookoła.</p>
]]></description>
      <pubDate>Wed, 15 Jan 2025 00:00:00 +0000</pubDate>
      <author>Tomasz Ducin</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/93-2l1zU2Vu</link>
      <content:encoded><![CDATA[<p>W pierwszym odcinku w 2025 roku zapraszam na pierwszą odsłonę Backend vs Frontend, gdzie wspólnie z Tomkiem Ducinem bedziemy pochylać się nad różnymi problemami związanymi z software developmentem. Na początek temat testowania i testów integracyjnych, bo jeśli nie testujesz swojego kodu, to jak możesz mieć pewność, że wszystko działa poprawnie?</p><p>Ale “hold your horses”… testy to tylko przyczynek do tego, aby porozmawiać w luźnej atmosferze o wielu ważnych rzeczach dookoła.</p>
]]></content:encoded>
      <enclosure length="73044674" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/9343bc91-5530-4d30-bf34-06e770c84b02/audio/6c0656cd-5f43-45cd-bb6d-232babb5e154/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>93. Backend vs Frontend: skuteczne testowanie zachowań, unity i integracja</itunes:title>
      <itunes:author>Tomasz Ducin</itunes:author>
      <itunes:duration>01:16:00</itunes:duration>
      <itunes:summary>W pierwszym odcinku w 2025 roku zapraszam na pierwszą odsłonę Backend vs Frontend, gdzie wspólnie z Tomkiem Ducinem bedziemy pochylać się nad różnymi problemami związanymi z software developmentem. Na początek temat testowania i testów integracyjnych, bo jeśli nie testujesz swojego kodu, to jak możesz mieć pewność, że wszystko działa poprawnie?</itunes:summary>
      <itunes:subtitle>W pierwszym odcinku w 2025 roku zapraszam na pierwszą odsłonę Backend vs Frontend, gdzie wspólnie z Tomkiem Ducinem bedziemy pochylać się nad różnymi problemami związanymi z software developmentem. Na początek temat testowania i testów integracyjnych, bo jeśli nie testujesz swojego kodu, to jak możesz mieć pewność, że wszystko działa poprawnie?</itunes:subtitle>
      <itunes:keywords>backend, frontend, unit testing, software development, integration testing, best practices</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>93</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">a978f9ed-8d33-4230-aa82-db570007d12b</guid>
      <title>92. O wykorzystaniu AI w software developmencie z Jarkiem Pałką i Wojtkiem Ptakiem</title>
      <description><![CDATA[<p>Dziś już chyba nie ma sposobu, by uciec od tematu sztucznej inteligencji i jej wykorzystania w codziennej pracy. I właśnie często pojawiające się pytanie o wpływ sztucznej inteligencji na wytwarzanie oprogramowania i zawód programisty jest przyczyną dzisiejszego odcinka. A że taką małą tradycją w tym podkaście powoli staje się doroczne spotkanie z Jarkiem Pałką i Wojtkiem Ptakiem, temat rozmowy narzucił nam się niemal od razu. I choć wiele z tego zdezaktualizuje się zapewne bardzo szybko, to tak właśnie widzimy zastosowanie AI w IT, anno domini 2024.</p>
]]></description>
      <pubDate>Mon, 23 Dec 2024 00:00:00 +0000</pubDate>
      <author>Wojtek Ptak, Jarek Pałka</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/92-wwf3VWhb</link>
      <content:encoded><![CDATA[<p>Dziś już chyba nie ma sposobu, by uciec od tematu sztucznej inteligencji i jej wykorzystania w codziennej pracy. I właśnie często pojawiające się pytanie o wpływ sztucznej inteligencji na wytwarzanie oprogramowania i zawód programisty jest przyczyną dzisiejszego odcinka. A że taką małą tradycją w tym podkaście powoli staje się doroczne spotkanie z Jarkiem Pałką i Wojtkiem Ptakiem, temat rozmowy narzucił nam się niemal od razu. I choć wiele z tego zdezaktualizuje się zapewne bardzo szybko, to tak właśnie widzimy zastosowanie AI w IT, anno domini 2024.</p>
]]></content:encoded>
      <enclosure length="84967983" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/a72def05-0e48-4dd8-8a54-985645b690d1/audio/00c17dcc-e466-4e75-a4b5-ea4bf883f685/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>92. O wykorzystaniu AI w software developmencie z Jarkiem Pałką i Wojtkiem Ptakiem</itunes:title>
      <itunes:author>Wojtek Ptak, Jarek Pałka</itunes:author>
      <itunes:duration>01:28:26</itunes:duration>
      <itunes:summary>Dziś już chyba nie ma sposobu, by uciec od tematu sztucznej inteligencji i jej wykorzystania w codziennej pracy. I właśnie często pojawiające się pytanie o wpływ sztucznej inteligencji na wytwarzanie oprogramowania i zawód programisty jest przyczyną dzisiejszego odcinka. A że taką małą tradycją w tym podkaście powoli staje się doroczne spotkanie z Jarkiem Pałką i Wojtkiem Ptakiem, temat rozmowy narzucił nam się niemal od razu. I choć wiele z tego zdezaktualizuje się zapewne bardzo szybko, to tak właśnie widzimy zastosowanie AI w IT, anno domini 2024.</itunes:summary>
      <itunes:subtitle>Dziś już chyba nie ma sposobu, by uciec od tematu sztucznej inteligencji i jej wykorzystania w codziennej pracy. I właśnie często pojawiające się pytanie o wpływ sztucznej inteligencji na wytwarzanie oprogramowania i zawód programisty jest przyczyną dzisiejszego odcinka. A że taką małą tradycją w tym podkaście powoli staje się doroczne spotkanie z Jarkiem Pałką i Wojtkiem Ptakiem, temat rozmowy narzucił nam się niemal od razu. I choć wiele z tego zdezaktualizuje się zapewne bardzo szybko, to tak właśnie widzimy zastosowanie AI w IT, anno domini 2024.</itunes:subtitle>
      <itunes:keywords>chat gpt, sztuczna inteligencja, software development, ai, startup</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>92</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">134a5535-a628-4a85-b6dd-9b1b9782df08</guid>
      <title>91. O modułach w aplikacjach JavaScript z Tomaszem &apos;Comandeer&apos; Jakutem prowadzi Tomasz Ducin</title>
      <description><![CDATA[<p>W świecie technologii frontendowych, w najprostszym rozumieniu moduł może być najmniejszą cząstką aplikacji, zajmującą się jedną podstawową rzeczą, dodatkowo wydzieloną do osobnego miejsca. Ale aby nie było zbyt prosto, to tylko jedna z często stosowanych definicji modułu.</p><p>W dzisiejszym odcinku gościem Tomka Ducina, specjalisty z zakresu architektury frontendu jest Tomasz Jakut, szerzej znany w społeczności JavaScriptowej jako Comandeer.</p><p>Więcej na stronie <a href="https://bettersoftwaredesign.pl/podcast/o-modulach-w-aplikacjach-javascript-z-tomaszem-comandeer-jakutem-prowadzi-tomasz-ducin/">tego odcinka</a> na stronie <a href="https://bettersoftwaredesign.pl">bettersoftwaredesign.pl</a>.</p>
]]></description>
      <pubDate>Wed, 11 Dec 2024 00:00:00 +0000</pubDate>
      <author>Tomasz Jakut, Tomasz Ducin</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/91-_MZIUAYJ</link>
      <content:encoded><![CDATA[<p>W świecie technologii frontendowych, w najprostszym rozumieniu moduł może być najmniejszą cząstką aplikacji, zajmującą się jedną podstawową rzeczą, dodatkowo wydzieloną do osobnego miejsca. Ale aby nie było zbyt prosto, to tylko jedna z często stosowanych definicji modułu.</p><p>W dzisiejszym odcinku gościem Tomka Ducina, specjalisty z zakresu architektury frontendu jest Tomasz Jakut, szerzej znany w społeczności JavaScriptowej jako Comandeer.</p><p>Więcej na stronie <a href="https://bettersoftwaredesign.pl/podcast/o-modulach-w-aplikacjach-javascript-z-tomaszem-comandeer-jakutem-prowadzi-tomasz-ducin/">tego odcinka</a> na stronie <a href="https://bettersoftwaredesign.pl">bettersoftwaredesign.pl</a>.</p>
]]></content:encoded>
      <enclosure length="63413857" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/4b4218c3-4bd0-4ec3-b23e-ea910c1ac341/audio/55d9de6c-9c88-43a0-9eb7-30d4eb244635/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>91. O modułach w aplikacjach JavaScript z Tomaszem &apos;Comandeer&apos; Jakutem prowadzi Tomasz Ducin</itunes:title>
      <itunes:author>Tomasz Jakut, Tomasz Ducin</itunes:author>
      <itunes:duration>01:06:00</itunes:duration>
      <itunes:summary>W świecie technologii frontendowych, w najprostszym rozumieniu moduł może być najmniejszą cząstką aplikacji, zajmującą się jedną podstawową rzeczą, dodatkowo wydzieloną do osobnego miejsca. Ale aby nie było zbyt prosto, to tylko jedna z często stosowanych definicji modułu.</itunes:summary>
      <itunes:subtitle>W świecie technologii frontendowych, w najprostszym rozumieniu moduł może być najmniejszą cząstką aplikacji, zajmującą się jedną podstawową rzeczą, dodatkowo wydzieloną do osobnego miejsca. Ale aby nie było zbyt prosto, to tylko jedna z często stosowanych definicji modułu.</itunes:subtitle>
      <itunes:keywords>deno, ecmascript, moduły, frontend architecture, javascript, node.js, bun</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>91</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">ca0454bb-9b99-44eb-91e0-e125b38a8704</guid>
      <title>90. O projektowaniu architektury multi-tenant z Michałem Giergielewiczem</title>
      <description><![CDATA[<p>Architektura systemu nie jest jedynie pochodną wymagań funkcjonalnych. Istotny wpływ ma tu także fakt, czy z system powstaje do obsługi jednej organizacji, czy też będzie z niego korzystać wiele całkowicie osobnych firm, a także w jakim stopniu poszczególni użytkownicy będą wykorzystywać dostępne zasoby. Ale to nie jedyne wyzwania, jakie pojawiają się w architekturach multi-tenant...</p><p>Tematy zahaczające o infrastrukturę nie pojawiają się w Better Software Design zbyt często, jednak w przypadku tego rodzaju architektur nie sposób od tego tematu uciec. A moim gościem w tej rozmowie jest dziś Michał Giergielewicz, który na co dzień pracuje przy systemie email-marketingowym, z którego korzysta kilkaset tysięcy klientów na całym świecie.</p><p>W tym odcinku wspólnie z Michałem rozmawiamy między innymi o:</p><ul><li>trudnościach w tworzeniu systemów multi-tenant, w tym bazach danych czy kolejkach</li><li>możliwych sposobach zaprojektowania infrastruktury przechowującej dane</li><li>problemach związanych z bezpieczeństwem danych i SQL Jailingu</li><li>aspektach, które warto wziąć pod uwagę projektując system pod równoczesną obsługę wielu klientów</li><li>pytaniach, które mogą pomóc w doborze odpowiedniej architektury</li><li>rozwiązywaniu problemów technicznych za pomocą narzędzi biznesowych</li></ul><p>Więcej na stronie <a href="https://bettersoftwaredesign.pl/podcast/o-projektowaniu-architektury-multi-tenant-z-michalem-giergielewiczem/">tego odcinka</a> na stronie <a href="https://bettersoftwaredesign.pl">bettersoftwaredesign.pl</a>.</p>
]]></description>
      <pubDate>Tue, 19 Nov 2024 00:00:00 +0000</pubDate>
      <author>Michał Giergielewicz</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/90-eJsW_fSE</link>
      <content:encoded><![CDATA[<p>Architektura systemu nie jest jedynie pochodną wymagań funkcjonalnych. Istotny wpływ ma tu także fakt, czy z system powstaje do obsługi jednej organizacji, czy też będzie z niego korzystać wiele całkowicie osobnych firm, a także w jakim stopniu poszczególni użytkownicy będą wykorzystywać dostępne zasoby. Ale to nie jedyne wyzwania, jakie pojawiają się w architekturach multi-tenant...</p><p>Tematy zahaczające o infrastrukturę nie pojawiają się w Better Software Design zbyt często, jednak w przypadku tego rodzaju architektur nie sposób od tego tematu uciec. A moim gościem w tej rozmowie jest dziś Michał Giergielewicz, który na co dzień pracuje przy systemie email-marketingowym, z którego korzysta kilkaset tysięcy klientów na całym świecie.</p><p>W tym odcinku wspólnie z Michałem rozmawiamy między innymi o:</p><ul><li>trudnościach w tworzeniu systemów multi-tenant, w tym bazach danych czy kolejkach</li><li>możliwych sposobach zaprojektowania infrastruktury przechowującej dane</li><li>problemach związanych z bezpieczeństwem danych i SQL Jailingu</li><li>aspektach, które warto wziąć pod uwagę projektując system pod równoczesną obsługę wielu klientów</li><li>pytaniach, które mogą pomóc w doborze odpowiedniej architektury</li><li>rozwiązywaniu problemów technicznych za pomocą narzędzi biznesowych</li></ul><p>Więcej na stronie <a href="https://bettersoftwaredesign.pl/podcast/o-projektowaniu-architektury-multi-tenant-z-michalem-giergielewiczem/">tego odcinka</a> na stronie <a href="https://bettersoftwaredesign.pl">bettersoftwaredesign.pl</a>.</p>
]]></content:encoded>
      <enclosure length="73483543" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/9a498c3d-379d-4399-acf9-c7e03028bb6b/audio/785040c9-7719-44fd-9a4c-f5da460afb70/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>90. O projektowaniu architektury multi-tenant z Michałem Giergielewiczem</itunes:title>
      <itunes:author>Michał Giergielewicz</itunes:author>
      <itunes:duration>01:16:30</itunes:duration>
      <itunes:summary>Architektura systemu nie jest jedynie pochodną wymagań funkcjonalnych. Istotny wpływ ma tu także fakt, czy z system powstaje do obsługi jednej organizacji, czy też będzie z niego korzystać wiele całkowicie osobnych firm, a także w jakim stopniu poszczególni użytkownicy będą wykorzystywać dostępne zasoby. Ale to nie jedyne wyzwania, jakie pojawiają się w architekturach multi-tenant...</itunes:summary>
      <itunes:subtitle>Architektura systemu nie jest jedynie pochodną wymagań funkcjonalnych. Istotny wpływ ma tu także fakt, czy z system powstaje do obsługi jednej organizacji, czy też będzie z niego korzystać wiele całkowicie osobnych firm, a także w jakim stopniu poszczególni użytkownicy będą wykorzystywać dostępne zasoby. Ale to nie jedyne wyzwania, jakie pojawiają się w architekturach multi-tenant...</itunes:subtitle>
      <itunes:keywords>architecture, scaling, saas, database, multi-tenancy, sql jailing</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>90</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">c9706cf4-ff48-4a57-b427-166053a9d63a</guid>
      <title>89. O ciemnej stronie implementacji API z GraphQL z Sebastianem Rabiejem</title>
      <description><![CDATA[<p>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...</p><p>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.</p><p>W tym odcinku wspólnie z Sebastianem rozmawiamy między innymi o:</p><ul><li>raporcie Postmana i trendach w stosowaniu poszczególnych styli budowy API</li><li>czym jest GraphQL i jakie problemy rozwiązuje</li><li>zasadach, popularnych narzędziach i frameworkach do budowy GraphQL API</li><li>sposobach atakowania serwera GraphQL</li><li>potencjalnych problemach z wydajnością, bezpieczeństwem i wersjonowaniem takich API</li><li>best practices i sposobach rozwiązania typowych problemów w GraphQL</li></ul><p>Materiały dodatkowe:</p><ul><li>Dokumentacja i strona domowa <a href="https://graphql.org">GraphQL</a></li><li>Dostępne wydania <a href="https://spec.graphql.org">specyfikacji GraphQL</a></li><li>Artykuł na blogu Meta opisujący <a href="https://engineering.fb.com/2015/09/14/core-infra/graphql-a-data-query-language/">jak to się wszystko zaczęło</a></li><li>Zestaw zaleceń <a href="https://principledgraphql.com">Principled GraphQL</a></li><li>Praca <a href="https://arxiv.org/pdf/1906.07535">Migrating to GraphQL: A Practical Assessment</a></li><li>Wspomniany w odcinku blog post <a href="https://www.sennder.com/blog/the-rise-and-fall-of-graphql-at-sennder">The rise and fall of GraphQL at sennder</a></li><li>Artykuł <a href="https://martinfowler.com/ieeeSoftware/published.pdf">Public versus Published Interfaces</a> Martina Fowlera</li><li>[Dokumentacja limitów GraphQL[(<a href="https://docs.github.com/en/graphql/overview/rate-limits-and-node-limits-for-the-graphql-api">https://docs.github.com/en/graphql/overview/rate-limits-and-node-limits-for-the-graphql-api</a>) w API GitHub</li><li><a href="https://netflix.github.io/dgs/">Netflix DGS Framework</a> do implementacji i uruchamiania usług opartych o GraphQL</li><li><a href="https://github.com/graphql-kit/graphql-voyager">GraphQL Voyager</a>, narzędzie wizualizacji schematu API w formie interkatywnego grafu</li><li><a href="https://github.com/dolevf/graphql-cop">GraphQL Cop</a>, narzędzie audytu security API opartych o GraphQL</li></ul>
]]></description>
      <pubDate>Mon, 24 Jun 2024 23:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/89-nCUbaHoj</link>
      <content:encoded><![CDATA[<p>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...</p><p>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.</p><p>W tym odcinku wspólnie z Sebastianem rozmawiamy między innymi o:</p><ul><li>raporcie Postmana i trendach w stosowaniu poszczególnych styli budowy API</li><li>czym jest GraphQL i jakie problemy rozwiązuje</li><li>zasadach, popularnych narzędziach i frameworkach do budowy GraphQL API</li><li>sposobach atakowania serwera GraphQL</li><li>potencjalnych problemach z wydajnością, bezpieczeństwem i wersjonowaniem takich API</li><li>best practices i sposobach rozwiązania typowych problemów w GraphQL</li></ul><p>Materiały dodatkowe:</p><ul><li>Dokumentacja i strona domowa <a href="https://graphql.org">GraphQL</a></li><li>Dostępne wydania <a href="https://spec.graphql.org">specyfikacji GraphQL</a></li><li>Artykuł na blogu Meta opisujący <a href="https://engineering.fb.com/2015/09/14/core-infra/graphql-a-data-query-language/">jak to się wszystko zaczęło</a></li><li>Zestaw zaleceń <a href="https://principledgraphql.com">Principled GraphQL</a></li><li>Praca <a href="https://arxiv.org/pdf/1906.07535">Migrating to GraphQL: A Practical Assessment</a></li><li>Wspomniany w odcinku blog post <a href="https://www.sennder.com/blog/the-rise-and-fall-of-graphql-at-sennder">The rise and fall of GraphQL at sennder</a></li><li>Artykuł <a href="https://martinfowler.com/ieeeSoftware/published.pdf">Public versus Published Interfaces</a> Martina Fowlera</li><li>[Dokumentacja limitów GraphQL[(<a href="https://docs.github.com/en/graphql/overview/rate-limits-and-node-limits-for-the-graphql-api">https://docs.github.com/en/graphql/overview/rate-limits-and-node-limits-for-the-graphql-api</a>) w API GitHub</li><li><a href="https://netflix.github.io/dgs/">Netflix DGS Framework</a> do implementacji i uruchamiania usług opartych o GraphQL</li><li><a href="https://github.com/graphql-kit/graphql-voyager">GraphQL Voyager</a>, narzędzie wizualizacji schematu API w formie interkatywnego grafu</li><li><a href="https://github.com/dolevf/graphql-cop">GraphQL Cop</a>, narzędzie audytu security API opartych o GraphQL</li></ul>
]]></content:encoded>
      <enclosure length="65010688" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/e41c7d90-5abb-41cb-b90a-63eeb8effb37/audio/37b04570-723c-4acf-946b-5266d41c2728/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>89. O ciemnej stronie implementacji API z GraphQL z Sebastianem Rabiejem</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>01:07:40</itunes:duration>
      <itunes:summary>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...</itunes:summary>
      <itunes:subtitle>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...</itunes:subtitle>
      <itunes:keywords>performance, api, security, design, graphql, rest</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>89</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">d946176f-c0fd-4627-b17b-ea2e4429d54e</guid>
      <title>88. O rewolucji w Angularze i frontendzie na sygnałach z Maciejem Wójcikiem prowadzi Tomasz Ducin</title>
      <description><![CDATA[<p>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.</p><p>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.</p><p>W dzisiejszej rozmowie:</p><ul><li>czym są sygnały i jaki problem rozwiązują</li><li>w czym są podobne, a czym różnią się od istniejących narzędzi reaktywnych typu RxJs</li><li>komponentach, zależnościach, zmianach, template'ach i wydajności systemu</li><li>jak sygnały wpływają na projektowanie i testowanie aplikacji</li><li>z czym wiąże się migracja aplikacji na Signals i jakie problemy mogą się pojawić</li></ul><p>Materiały dodatkowe:</p><ul><li>Oficjalna dokumentacja <a href="https://angular.dev/guide/signals">Angular Signals</a></li><li>Darmowy kurs <a href="https://angular-signals.dev">Angular Signals</a> autorstwa Macieja</li></ul>
]]></description>
      <pubDate>Mon, 3 Jun 2024 23:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/88-fMPWMWEa</link>
      <content:encoded><![CDATA[<p>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.</p><p>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.</p><p>W dzisiejszej rozmowie:</p><ul><li>czym są sygnały i jaki problem rozwiązują</li><li>w czym są podobne, a czym różnią się od istniejących narzędzi reaktywnych typu RxJs</li><li>komponentach, zależnościach, zmianach, template'ach i wydajności systemu</li><li>jak sygnały wpływają na projektowanie i testowanie aplikacji</li><li>z czym wiąże się migracja aplikacji na Signals i jakie problemy mogą się pojawić</li></ul><p>Materiały dodatkowe:</p><ul><li>Oficjalna dokumentacja <a href="https://angular.dev/guide/signals">Angular Signals</a></li><li>Darmowy kurs <a href="https://angular-signals.dev">Angular Signals</a> autorstwa Macieja</li></ul>
]]></content:encoded>
      <enclosure length="66481828" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/7be5e9ec-31f7-4c2d-a162-3d8daf916f12/audio/3d71cc37-ca55-4448-971b-6d81a04a686e/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>88. O rewolucji w Angularze i frontendzie na sygnałach z Maciejem Wójcikiem prowadzi Tomasz Ducin</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>01:09:12</itunes:duration>
      <itunes:summary>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. </itunes:summary>
      <itunes:subtitle>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. </itunes:subtitle>
      <itunes:keywords>architecture, performance, frontend, signals, angular, javascript</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>88</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">ba89b83a-fee6-4eef-92fe-b442e377608a</guid>
      <title>87. O roli CTO, budowaniu zespołu, kultury i umiejętności z Danielem Owsiańskim</title>
      <description><![CDATA[<p>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?</p><p>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.</p><p>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 <a href="https://www.volt.io">Volt.io</a>, gdzie mamy okazję na codzień współpracować.</p><p>Jeśli chciałbyś/-abyś dołączyć do jednego z naszych projektów w Java, Go lub PHP, tutaj znajdziesz <a href="https://apply.workable.com/volt-dot-i-o/?lng=en">aktualne oferty pracy</a>.</p><p>Zapraszam Cię także do odwiedzenia bloga Daniela, <a href="https://owsianski.com">owsianski.com</a>, który ostatnio pojawił się w sieci.</p>
]]></description>
      <pubDate>Mon, 27 May 2024 23:00:00 +0000</pubDate>
      <author>Daniel Owsiański</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/87-y7iMfoLD</link>
      <content:encoded><![CDATA[<p>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?</p><p>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.</p><p>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 <a href="https://www.volt.io">Volt.io</a>, gdzie mamy okazję na codzień współpracować.</p><p>Jeśli chciałbyś/-abyś dołączyć do jednego z naszych projektów w Java, Go lub PHP, tutaj znajdziesz <a href="https://apply.workable.com/volt-dot-i-o/?lng=en">aktualne oferty pracy</a>.</p><p>Zapraszam Cię także do odwiedzenia bloga Daniela, <a href="https://owsianski.com">owsianski.com</a>, który ostatnio pojawił się w sieci.</p>
]]></content:encoded>
      <enclosure length="53170577" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/5af86d75-5d8a-4c8a-bf76-0b575534df41/audio/8de9a946-a760-49c7-8ce6-1ac5a8d258bb/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>87. O roli CTO, budowaniu zespołu, kultury i umiejętności z Danielem Owsiańskim</itunes:title>
      <itunes:author>Daniel Owsiański</itunes:author>
      <itunes:duration>00:55:20</itunes:duration>
      <itunes:summary>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?</itunes:summary>
      <itunes:subtitle>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?</itunes:subtitle>
      <itunes:keywords>kariera, management, chief technology officer, cto, zespół</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>87</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">bd57198c-3059-4d69-97f7-b28bfdbac984</guid>
      <title>86. O DDD w legacy z wykorzystaniem Bubble i Autonomous Contexts z Marcinem Markowskim</title>
      <description><![CDATA[<p>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ć.</p><p>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.</p><p>W dzisiejszej rozmowie:</p><ul><li>na czym polegają techniki Bubble i Autonomous Context,</li><li>kiedy warto, a kiedy nie, korzystać z ich możliwości,</li><li>wykorzystaniu istniejących danych w nowym modelu domenowych,</li><li>ACL-backed repository, Ports & Adapters i innych przydatkach tu technikach,</li><li>jakie synchronizować dane między kontekstami i jakie inne wyzwania staną prawdopodobnie na drodze ku lepszemu,</li><li>współpracy w zespole przy wdrażaniu takich technik.</li></ul><p>Materiały dodatkowe:</p><ul><li>Artykuł <a href="https://www.domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf">Getting Started with DDD when surrounded by legacy systems</a> Erica Evans, 2013</li></ul>
]]></description>
      <pubDate>Tue, 7 May 2024 23:00:00 +0000</pubDate>
      <author>Marcin Markowski</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/86-HRP4quZ7</link>
      <content:encoded><![CDATA[<p>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ć.</p><p>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.</p><p>W dzisiejszej rozmowie:</p><ul><li>na czym polegają techniki Bubble i Autonomous Context,</li><li>kiedy warto, a kiedy nie, korzystać z ich możliwości,</li><li>wykorzystaniu istniejących danych w nowym modelu domenowych,</li><li>ACL-backed repository, Ports & Adapters i innych przydatkach tu technikach,</li><li>jakie synchronizować dane między kontekstami i jakie inne wyzwania staną prawdopodobnie na drodze ku lepszemu,</li><li>współpracy w zespole przy wdrażaniu takich technik.</li></ul><p>Materiały dodatkowe:</p><ul><li>Artykuł <a href="https://www.domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf">Getting Started with DDD when surrounded by legacy systems</a> Erica Evans, 2013</li></ul>
]]></content:encoded>
      <enclosure length="66197447" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/2caa12e3-249e-46b0-a507-481a6ff9e1b1/audio/4ae05982-4537-481f-854e-f5efeb1dcd62/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>86. O DDD w legacy z wykorzystaniem Bubble i Autonomous Contexts z Marcinem Markowskim</itunes:title>
      <itunes:author>Marcin Markowski</itunes:author>
      <itunes:duration>01:08:55</itunes:duration>
      <itunes:summary>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ć.</itunes:summary>
      <itunes:subtitle>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ć.</itunes:subtitle>
      <itunes:keywords>bubble context, autonomous context, legacy, domain driven design, domain model, ddd, eric evans</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>86</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">cf7ce3af-8e38-422b-ba19-2c69c6dd8f4b</guid>
      <title>85. O Architectural Kata i procesie tworzenia architektury z Piotrem Filipowiczem</title>
      <description><![CDATA[<p>"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.</p><p>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ść.</p><p>Razem z Piotrem rozmawiamy dziś między innymi o:</p><ul><li>czym jest Architectural Kata i jak może wspomóc Cię w procesie projektowania architektury</li><li>sześciu perspektywach, które można wziąć pod uwagę szukając właściwej dla projektu architektury</li><li>charakterystykach architektonicznych, ograniczeniach, macierzy styli Marka Richardsa</li><li>komunikowaniu architektury różnym jej odbiorcom, nie tylko zespołowi developerskiemu</li><li>konkretnych przykładach Fitness Function z architektury ewolucyjnej</li></ul><p>Zapraszam!</p><p>Materiały dodatkowe:</p><ul><li><a href="https://www.goodreads.com/pl/book/show/44144493">Fundamentals of Software Architecture: An Engineering Approach</a>, książka Marka Richardsa i Neala Forda</li><li><a href="https://www.goodreads.com/book/show/58153482-software-architecture">Software Architecture: The Hard Parts: Modern Trade-Off Analyses for Distributed Architectures</a>, kolejna pozycja, której współautorami są Mark Richards i Neal Ford</li><li><a href="https://github.com/TheKataLog">The Architecture Kata Log</a>, repozytorium Jacqui Read z listą zwycięzców poszczególnych edycji konkursu O'Reilly Software Architecture Katas</li><li><a href="https://github.com/TheKataLog/BluzBrothers">StayHealthy.MonitorMe</a>, repozytorium z wspominanym w rozmowie opisem architektury</li><li><a href="https://www.architecturalkatas.com">Architectural Katas</a>, katalog różnych kat Teda Newarda</li></ul><p>Zapraszam także do obserwowania profilu <a href="https://www.linkedin.com/in/piotr-filipowicz-402b062a/">Piotra</a> na LinkedIn. </p>
]]></description>
      <pubDate>Mon, 22 Apr 2024 23:00:00 +0000</pubDate>
      <author>Piotr Filipowicz</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/85-hDzoAooE</link>
      <content:encoded><![CDATA[<p>"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.</p><p>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ść.</p><p>Razem z Piotrem rozmawiamy dziś między innymi o:</p><ul><li>czym jest Architectural Kata i jak może wspomóc Cię w procesie projektowania architektury</li><li>sześciu perspektywach, które można wziąć pod uwagę szukając właściwej dla projektu architektury</li><li>charakterystykach architektonicznych, ograniczeniach, macierzy styli Marka Richardsa</li><li>komunikowaniu architektury różnym jej odbiorcom, nie tylko zespołowi developerskiemu</li><li>konkretnych przykładach Fitness Function z architektury ewolucyjnej</li></ul><p>Zapraszam!</p><p>Materiały dodatkowe:</p><ul><li><a href="https://www.goodreads.com/pl/book/show/44144493">Fundamentals of Software Architecture: An Engineering Approach</a>, książka Marka Richardsa i Neala Forda</li><li><a href="https://www.goodreads.com/book/show/58153482-software-architecture">Software Architecture: The Hard Parts: Modern Trade-Off Analyses for Distributed Architectures</a>, kolejna pozycja, której współautorami są Mark Richards i Neal Ford</li><li><a href="https://github.com/TheKataLog">The Architecture Kata Log</a>, repozytorium Jacqui Read z listą zwycięzców poszczególnych edycji konkursu O'Reilly Software Architecture Katas</li><li><a href="https://github.com/TheKataLog/BluzBrothers">StayHealthy.MonitorMe</a>, repozytorium z wspominanym w rozmowie opisem architektury</li><li><a href="https://www.architecturalkatas.com">Architectural Katas</a>, katalog różnych kat Teda Newarda</li></ul><p>Zapraszam także do obserwowania profilu <a href="https://www.linkedin.com/in/piotr-filipowicz-402b062a/">Piotra</a> na LinkedIn. </p>
]]></content:encoded>
      <enclosure length="55097756" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/256c779e-aca3-4a57-8a61-74ce5b72543f/audio/a0138c5e-a73d-4114-b0be-7ab56a222422/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>85. O Architectural Kata i procesie tworzenia architektury z Piotrem Filipowiczem</itunes:title>
      <itunes:author>Piotr Filipowicz</itunes:author>
      <itunes:duration>00:57:20</itunes:duration>
      <itunes:summary>&quot;Jak mamy pozyskać świetnych architektów, jeśli w swojej karierze będą mieli okazję ją tworzyć mniej niż pół tuzina razy?&quot;. 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.</itunes:summary>
      <itunes:subtitle>&quot;Jak mamy pozyskać świetnych architektów, jeśli w swojej karierze będą mieli okazję ją tworzyć mniej niż pół tuzina razy?&quot;. 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.</itunes:subtitle>
      <itunes:keywords>mark richards, neal ford, software architecture, drivery architektoniczne, o&apos;reilly, architectural kata</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>85</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">a17d6176-b0bc-443f-b536-ec30cf94184b</guid>
      <title>84. O implementacji testów backendu i architekturze otwartej na testowanie</title>
      <description><![CDATA[<p>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...</p><p>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.</p><p>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?</p><p>W tym odcinku rozmawiamy wraz z Piotrem między innymi o:</p><ul><li>organizacyjnych i technicznych problemach z implementacją jakościowych testów w backendzie</li><li>metryce code-coverage i jej różnym stopniu przydatności w projekcie</li><li>profesjonalnym podejściu do problemu "z testami, czy bez?"</li><li>dobrych praktykach doboru strategii testowania</li><li>szarej strefie testów Kevlina Henney'a</li><li>legacy, testach charakterystyki, szwach i odcinaniu fragmentów systemu dla testów</li><li>unitach, czyli fragmentach kodu o pojedynczej odpowiedzialności, mierzonego kohezją</li><li>implementacji architektury otwartej na testowanie</li><li>eliminacji problemów z nadużywaniem mocków w projekcie</li></ul><p>Zapraszam!</p><p>Materiały dodatkowe:</p><ul><li><a href="https://www.youtube.com/watch?v=AJ7u_Z-TS-A">Sub-second acceptance tests</a>, prezentacja Aslaka Hellesøy z konferencji SeleniumConf Chicago</li><li><a href="https://www.goodreads.com/book/show/4268826-growing-object-oriented-software-guided-by-tests">Growing Object-Oriented Software, Guided by Tests</a>, wspomniana w rozmowie książka Steve'a Freemana i Nata Pryce'a</li><li><a href="https://www.goodreads.com/book/show/49649345-style-guide-for-object-design">Style Guide for Object Design</a>, książka Matthiasa Nobacka</li><li><a href="https://github.com/stawirej/financial-system">Financial System</a>, repozytorium z przykładowym kodem Piotra</li></ul>
]]></description>
      <pubDate>Tue, 2 Apr 2024 23:00:00 +0000</pubDate>
      <author>piotr stawirej</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/84-ys43eKDs</link>
      <content:encoded><![CDATA[<p>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...</p><p>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.</p><p>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?</p><p>W tym odcinku rozmawiamy wraz z Piotrem między innymi o:</p><ul><li>organizacyjnych i technicznych problemach z implementacją jakościowych testów w backendzie</li><li>metryce code-coverage i jej różnym stopniu przydatności w projekcie</li><li>profesjonalnym podejściu do problemu "z testami, czy bez?"</li><li>dobrych praktykach doboru strategii testowania</li><li>szarej strefie testów Kevlina Henney'a</li><li>legacy, testach charakterystyki, szwach i odcinaniu fragmentów systemu dla testów</li><li>unitach, czyli fragmentach kodu o pojedynczej odpowiedzialności, mierzonego kohezją</li><li>implementacji architektury otwartej na testowanie</li><li>eliminacji problemów z nadużywaniem mocków w projekcie</li></ul><p>Zapraszam!</p><p>Materiały dodatkowe:</p><ul><li><a href="https://www.youtube.com/watch?v=AJ7u_Z-TS-A">Sub-second acceptance tests</a>, prezentacja Aslaka Hellesøy z konferencji SeleniumConf Chicago</li><li><a href="https://www.goodreads.com/book/show/4268826-growing-object-oriented-software-guided-by-tests">Growing Object-Oriented Software, Guided by Tests</a>, wspomniana w rozmowie książka Steve'a Freemana i Nata Pryce'a</li><li><a href="https://www.goodreads.com/book/show/49649345-style-guide-for-object-design">Style Guide for Object Design</a>, książka Matthiasa Nobacka</li><li><a href="https://github.com/stawirej/financial-system">Financial System</a>, repozytorium z przykładowym kodem Piotra</li></ul>
]]></content:encoded>
      <enclosure length="77312668" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/b8b44e56-8ba4-42bc-b2f9-75429cc2fa89/audio/bee1eae3-8f4f-4f2f-bd74-e062a65cf2b3/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>84. O implementacji testów backendu i architekturze otwartej na testowanie</itunes:title>
      <itunes:author>piotr stawirej</itunes:author>
      <itunes:duration>01:20:27</itunes:duration>
      <itunes:summary>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...</itunes:summary>
      <itunes:subtitle>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...</itunes:subtitle>
      <itunes:keywords>unit testing, anti-patterns, integration testing, test pyramid, software testing, best practices, code design</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>84</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">bf5b5825-612c-45d8-93c2-2ea7965e324f</guid>
      <title>83. O testowaniu systemu end-to-end i Quality Assurance z Arkadiuszem Jelonkiem</title>
      <description><![CDATA[<p>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.</p><p>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.</p><p>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.</p><p>W dzisiejszym odcinku wspólnie z Arkiem rozmawiamy między innymi o:</p><ul><li>roli Quality Assurance w projekcie</li><li>zdobywaniu doświadczenia pracując w Software House, dojrzałej firmie produktowej i startupie</li><li>pytaniach, jakie warto zadać w zespole wchodząc w rolę Questions Asker</li><li>roli testów end-to-end w projekcie</li><li>klasyfikacji, różnicach i doborze właściwych narzędzi wspierających automatyzację testów</li><li>powstaniu Playwrighta i problemach, które to narzędzie rozwiązuje</li><li>testach regresji wizualnej</li><li>sposobach unikania kruchości w testach E2E</li></ul><p>Ten 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…</p><p>Materiały dodatkowe:</p><ul><li><a href="https://portal.gitnation.org/contents/the-evolution-of-browser-automation">The Evolution of Browser Automation</a>, artykuł i prezentacja Christiana Bromanna z Sauce Labs</li><li><a href="https://www.goodreads.com/book/show/48642919-zaw-d-tester---od-decyzji-do-zdobycia-do-wiadczenia">Zawód tester - Od decyzji do zdobycia doświadczenia</a>, książka Radosława Smilgina, dla osób początkujących</li><li><a href="https://www.goodreads.com/book/show/99475153-pasja-testowania-wydanie-2-rozszerzone">Pasja testowania (wydanie 2, rozszerzone)</a>, książka Krzysztofa Jadczyka, także dla początkujących</li></ul>
]]></description>
      <pubDate>Tue, 19 Mar 2024 00:00:00 +0000</pubDate>
      <author>Arkadiusz Jelonek</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/83-nB_6ynCJ</link>
      <content:encoded><![CDATA[<p>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.</p><p>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.</p><p>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.</p><p>W dzisiejszym odcinku wspólnie z Arkiem rozmawiamy między innymi o:</p><ul><li>roli Quality Assurance w projekcie</li><li>zdobywaniu doświadczenia pracując w Software House, dojrzałej firmie produktowej i startupie</li><li>pytaniach, jakie warto zadać w zespole wchodząc w rolę Questions Asker</li><li>roli testów end-to-end w projekcie</li><li>klasyfikacji, różnicach i doborze właściwych narzędzi wspierających automatyzację testów</li><li>powstaniu Playwrighta i problemach, które to narzędzie rozwiązuje</li><li>testach regresji wizualnej</li><li>sposobach unikania kruchości w testach E2E</li></ul><p>Ten 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…</p><p>Materiały dodatkowe:</p><ul><li><a href="https://portal.gitnation.org/contents/the-evolution-of-browser-automation">The Evolution of Browser Automation</a>, artykuł i prezentacja Christiana Bromanna z Sauce Labs</li><li><a href="https://www.goodreads.com/book/show/48642919-zaw-d-tester---od-decyzji-do-zdobycia-do-wiadczenia">Zawód tester - Od decyzji do zdobycia doświadczenia</a>, książka Radosława Smilgina, dla osób początkujących</li><li><a href="https://www.goodreads.com/book/show/99475153-pasja-testowania-wydanie-2-rozszerzone">Pasja testowania (wydanie 2, rozszerzone)</a>, książka Krzysztofa Jadczyka, także dla początkujących</li></ul>
]]></content:encoded>
      <enclosure length="62182481" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/4b24535f-c9ff-40e0-9d52-c6e3c46de2cc/audio/eabd8a12-a361-44a5-ad56-bf0afa5a3f8e/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>83. O testowaniu systemu end-to-end i Quality Assurance z Arkadiuszem Jelonkiem</itunes:title>
      <itunes:author>Arkadiusz Jelonek</itunes:author>
      <itunes:duration>01:04:43</itunes:duration>
      <itunes:summary>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.</itunes:summary>
      <itunes:subtitle>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.</itunes:subtitle>
      <itunes:keywords>qa, testowanie end-to-end, selenium, software testing, quality assurance, playwright, e2e</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>83</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">84a59d17-2127-4e7f-a24c-cf53e82a86b9</guid>
      <title>82. O architekturze makro front-endu Atlassiana z Bartoszem Cytrowskim prowadzi Tomasz Ducin</title>
      <description><![CDATA[<p>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.</p><p>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.</p><p>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!</p><p>W tym odcinku usłyszysz między innymi o:</p><ul><li>czym jest monorepo, jego zaletach i wadach, a także o tym jak pracuje się z nim w Atlassianie,</li><li>narzędziach wykorzystywanych do rozwoju systemu o takiej skali jak Jira Cloud,</li><li>sposobie pracy w systemie, w którym pojawia się ponad 1000 pull-requestów dziennie,</li><li>kontrolowaniu zależności pomiędzy modułami,</li><li>stosowaniu feature flags i bezpiecznym wprowadzaniu zmian dotykających wielu zespołów,</li><li>testowaniu zmian, dog-foodingu i bezpiecznym wdrażaniu nowych wersji.</li></ul><p>Zapraszam!</p>
]]></description>
      <pubDate>Tue, 5 Mar 2024 00:00:00 +0000</pubDate>
      <author>Tomasz Ducin, Bartosz Cytrowski</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/82-ZTbJV0jY</link>
      <content:encoded><![CDATA[<p>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.</p><p>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.</p><p>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!</p><p>W tym odcinku usłyszysz między innymi o:</p><ul><li>czym jest monorepo, jego zaletach i wadach, a także o tym jak pracuje się z nim w Atlassianie,</li><li>narzędziach wykorzystywanych do rozwoju systemu o takiej skali jak Jira Cloud,</li><li>sposobie pracy w systemie, w którym pojawia się ponad 1000 pull-requestów dziennie,</li><li>kontrolowaniu zależności pomiędzy modułami,</li><li>stosowaniu feature flags i bezpiecznym wprowadzaniu zmian dotykających wielu zespołów,</li><li>testowaniu zmian, dog-foodingu i bezpiecznym wdrażaniu nowych wersji.</li></ul><p>Zapraszam!</p>
]]></content:encoded>
      <enclosure length="66115039" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/1b050c68-a389-4710-bd42-40f8b73d3616/audio/dec78ddb-c0c7-47ae-8d20-338513cfdcaa/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>82. O architekturze makro front-endu Atlassiana z Bartoszem Cytrowskim prowadzi Tomasz Ducin</itunes:title>
      <itunes:author>Tomasz Ducin, Bartosz Cytrowski</itunes:author>
      <itunes:duration>01:08:49</itunes:duration>
      <itunes:summary>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.</itunes:summary>
      <itunes:subtitle>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.</itunes:subtitle>
      <itunes:keywords>architecture, frontend, jira cloud, ecosystem, monorepo, atlasssian</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>82</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">bdd0028f-1cf0-4abb-9348-52ad3c1a3da2</guid>
      <title>81. O procesie discovery i wprowadzaniu DDD do organizacji z Darkiem Pawlukiewiczem i Michałem Wilczyńskim</title>
      <description><![CDATA[<p>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.</p><p>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.</p><p>Materiały dodatkowe:</p><ul><li><a href="https://enterprisecraftsmanship.com/posts/domain-model-purity-completeness/">Domain model purity vs. domain model completeness (DDD Trilemma)</a>, wspomniany w rozmowie artykuł Vladimira Khorikova</li><li><a href="https://no-kill-switch.ghost.io/the-failed-promise-of-domain-driven-design-part-1/">The failed promise of Domain-Driven Design - part 1</a>, artykuł Sebastiana Gębskiego</li><li><a href="https://no-kill-switch.ghost.io/the-failed-promise-of-domain-driven-design-part-2/">The failed promise of Domain-Driven Design - part 2</a>, kontynuacja powyższego artykułu</li></ul>
]]></description>
      <pubDate>Tue, 27 Feb 2024 00:00:00 +0000</pubDate>
      <author>Dariusz Pawlukiewicz, Michał Wilczyński</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/81-aVReUjhK</link>
      <content:encoded><![CDATA[<p>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.</p><p>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.</p><p>Materiały dodatkowe:</p><ul><li><a href="https://enterprisecraftsmanship.com/posts/domain-model-purity-completeness/">Domain model purity vs. domain model completeness (DDD Trilemma)</a>, wspomniany w rozmowie artykuł Vladimira Khorikova</li><li><a href="https://no-kill-switch.ghost.io/the-failed-promise-of-domain-driven-design-part-1/">The failed promise of Domain-Driven Design - part 1</a>, artykuł Sebastiana Gębskiego</li><li><a href="https://no-kill-switch.ghost.io/the-failed-promise-of-domain-driven-design-part-2/">The failed promise of Domain-Driven Design - part 2</a>, kontynuacja powyższego artykułu</li></ul>
]]></content:encoded>
      <enclosure length="69687331" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/d2b0b5ac-5748-46ae-913b-75a0d8a132b2/audio/6112e4f1-5094-48a7-92f6-acf9ea24e96b/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>81. O procesie discovery i wprowadzaniu DDD do organizacji z Darkiem Pawlukiewiczem i Michałem Wilczyńskim</itunes:title>
      <itunes:author>Dariusz Pawlukiewicz, Michał Wilczyński</itunes:author>
      <itunes:duration>01:12:33</itunes:duration>
      <itunes:summary>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.</itunes:summary>
      <itunes:subtitle>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.</itunes:subtitle>
      <itunes:keywords>domain-driven design, proces discovery, ddd trilemma, ddd</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>81</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">680b3abb-9e00-46f1-8a1d-b6887fcf0edf</guid>
      <title>80. O ostrej zasadzie Pareto, DDDozie i innych chorobach projektowych z Piotrem Przybyłem</title>
      <description><![CDATA[<p>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...</p><p>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.</p><p>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.</p><p>Materiały dodatkowe:</p><ul><li><a href="https://www.youtube.com/watch?v=DELWr2Cw30g">Cztery choroby</a>, prezentacja Piotra z konferencji Boiling Frogs 2019</li><li><a href="https://www.youtube.com/watch?v=cJDDsSj2vJA">Architecture antipatterns and how to beat them, część 1</a>, prezentacja Łukasza Szydło z konferencji 4Developers 2017</li><li><a href="https://www.youtube.com/watch?v=aq3Jwti9K14">Architecture antipatterns and how to beat them, część 2</a>, kontynuacja powyższej prezentacji</li></ul>
]]></description>
      <pubDate>Tue, 20 Feb 2024 00:00:00 +0000</pubDate>
      <author>Piotr Przybył</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/80-sS_ueW1R</link>
      <content:encoded><![CDATA[<p>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...</p><p>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.</p><p>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.</p><p>Materiały dodatkowe:</p><ul><li><a href="https://www.youtube.com/watch?v=DELWr2Cw30g">Cztery choroby</a>, prezentacja Piotra z konferencji Boiling Frogs 2019</li><li><a href="https://www.youtube.com/watch?v=cJDDsSj2vJA">Architecture antipatterns and how to beat them, część 1</a>, prezentacja Łukasza Szydło z konferencji 4Developers 2017</li><li><a href="https://www.youtube.com/watch?v=aq3Jwti9K14">Architecture antipatterns and how to beat them, część 2</a>, kontynuacja powyższej prezentacji</li></ul>
]]></content:encoded>
      <enclosure length="56379018" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/bdb2e6e0-a6b5-40ef-9eda-5037136da1ef/audio/23e2b526-dd20-4eaf-8f5c-c81ac91677f0/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>80. O ostrej zasadzie Pareto, DDDozie i innych chorobach projektowych z Piotrem Przybyłem</itunes:title>
      <itunes:author>Piotr Przybył</itunes:author>
      <itunes:duration>00:58:40</itunes:duration>
      <itunes:summary>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...</itunes:summary>
      <itunes:subtitle>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...</itunes:subtitle>
      <itunes:keywords>software craftsmanship</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>80</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">c7798bfa-6b14-44fb-9104-45883a5e7093</guid>
      <title>79. O modularyzacji bez użycia subdomen i heurystyk DDD z Łukaszem Szydło</title>
      <description><![CDATA[<p>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...</p><p>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.</p><p>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ć.</p><p>W tym odcinku rozmawiamy z Łukaszem o:</p><ul><li>hype na Domain-Driven Design i trudnościach w jego stosowaniu</li><li>intuicjach, heurystykach vs. praktyki inżynieryjne</li><li>analizie domeny na mniejsze części, poprzez odkrywanie niezależnie zmieniających się w niej rzeczy</li><li>sumulacji zmian i wykorzystaniu atrybutów jakościowych w procesie dekompozycji</li><li>stabilnych granicach aplikowalności modelu, wynikających z wprowadzanych zmian</li><li>weryfikacji wytwarzanych w ten sposób podziałów w projekcie</li><li>dobrych momentach na refaktoryzację systemu</li></ul><p>Materiały dodatkowe:</p><ul><li>Wspomniana w odcinku prezentacja <a href="https://www.youtube.com/watch?v=RhdlBHHimeM">Real Software Engineering</a> Glenna Vanderburga, VP of Engineering w First</li><li><a href="https://sd-lab.dev/">SDLab</a>, inicjatywa projektów badawczych w zakresie projektowania oprogramowania</li></ul>
]]></description>
      <pubDate>Tue, 30 Jan 2024 00:00:00 +0000</pubDate>
      <author>Łukasz Szydło</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/79-jBiptKK3</link>
      <content:encoded><![CDATA[<p>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...</p><p>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.</p><p>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ć.</p><p>W tym odcinku rozmawiamy z Łukaszem o:</p><ul><li>hype na Domain-Driven Design i trudnościach w jego stosowaniu</li><li>intuicjach, heurystykach vs. praktyki inżynieryjne</li><li>analizie domeny na mniejsze części, poprzez odkrywanie niezależnie zmieniających się w niej rzeczy</li><li>sumulacji zmian i wykorzystaniu atrybutów jakościowych w procesie dekompozycji</li><li>stabilnych granicach aplikowalności modelu, wynikających z wprowadzanych zmian</li><li>weryfikacji wytwarzanych w ten sposób podziałów w projekcie</li><li>dobrych momentach na refaktoryzację systemu</li></ul><p>Materiały dodatkowe:</p><ul><li>Wspomniana w odcinku prezentacja <a href="https://www.youtube.com/watch?v=RhdlBHHimeM">Real Software Engineering</a> Glenna Vanderburga, VP of Engineering w First</li><li><a href="https://sd-lab.dev/">SDLab</a>, inicjatywa projektów badawczych w zakresie projektowania oprogramowania</li></ul>
]]></content:encoded>
      <enclosure length="70270645" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/1a198f31-2be0-4cd9-b59c-3896f65196b4/audio/09dfacde-f047-48e9-aaed-c79c3f066449/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>79. O modularyzacji bez użycia subdomen i heurystyk DDD z Łukaszem Szydło</itunes:title>
      <itunes:author>Łukasz Szydło</itunes:author>
      <itunes:duration>01:13:08</itunes:duration>
      <itunes:summary>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...</itunes:summary>
      <itunes:subtitle>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...</itunes:subtitle>
      <itunes:keywords>modularyzacja, domain driven design, ddd, software engineering</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>79</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">41d73785-c4ef-4f45-9049-3dbbc0f1ce65</guid>
      <title>78. O Outbox Pattern i skutecznej komunikacji z Jackiem Milewskim</title>
      <description><![CDATA[<p>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.</p><p>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.</p><p>W tym odcinku wraz z Jackiem rozmawiamy między innymi o:</p><ul><li>problemach związanych z komunikacją w systemach,</li><li>idei wzorca Transactional Outbox / Store&Forward,</li><li>możliwych sposobach obsługi outboxa w systemie,</li><li>zastosowaniu tego wzorca zarówno w systemach rozproszonych jak i monolitycznych,</li><li>kolejności przetwarzania wiadomości,</li><li>deduplikacji czy message-poisoning.</li></ul><p>Materiały dodatkowe:</p><ul><li><a href="https://microservices.io/patterns/data/transactional-outbox.html">Microservices: Transactional outbox</a> oraz <a href="https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/transactional-outbox.html">AWS Prescriptive Guidance: Transactional Outbox Pattern</a>, opis omawianego w odcinku rozwiązania wraz z przykładowymi diagramami</li><li><a href="https://www.youtube.com/watch?v=NWyiP1EGKcQ">Outbox Pattern: kiedy ten strzał do API to jednak za mało</a>, prezentacja Jacka z konferencji Confitura PL 2023</li><li><a href="https://event-driven.io/en/push_based_outbox_pattern_with_postgres_logical_replication/">Push-based Outbox Pattern with Postgres Logical Replication</a>, artykuł Oskara Dudycza przedstawiający rozwiązanie oparte o bazę danych</li></ul><p>Zapraszam także do śledzenia profili Jacka na <a href="https://twitter.com/jacek_mil">Twitter/X</a> oraz <a href="https://www.linkedin.com/in/jacekmilewski/">LinkedIn</a> oraz do zapoznania się z <a href="http://www.bottega.com.pl/trener-jacek-milewski">listą szkoleń</a> Jacka w Bottega IT Minds.</p>
]]></description>
      <pubDate>Tue, 16 Jan 2024 00:00:00 +0000</pubDate>
      <author>Jacek Milewski</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/78-4CERmJ3T</link>
      <content:encoded><![CDATA[<p>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.</p><p>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.</p><p>W tym odcinku wraz z Jackiem rozmawiamy między innymi o:</p><ul><li>problemach związanych z komunikacją w systemach,</li><li>idei wzorca Transactional Outbox / Store&Forward,</li><li>możliwych sposobach obsługi outboxa w systemie,</li><li>zastosowaniu tego wzorca zarówno w systemach rozproszonych jak i monolitycznych,</li><li>kolejności przetwarzania wiadomości,</li><li>deduplikacji czy message-poisoning.</li></ul><p>Materiały dodatkowe:</p><ul><li><a href="https://microservices.io/patterns/data/transactional-outbox.html">Microservices: Transactional outbox</a> oraz <a href="https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/transactional-outbox.html">AWS Prescriptive Guidance: Transactional Outbox Pattern</a>, opis omawianego w odcinku rozwiązania wraz z przykładowymi diagramami</li><li><a href="https://www.youtube.com/watch?v=NWyiP1EGKcQ">Outbox Pattern: kiedy ten strzał do API to jednak za mało</a>, prezentacja Jacka z konferencji Confitura PL 2023</li><li><a href="https://event-driven.io/en/push_based_outbox_pattern_with_postgres_logical_replication/">Push-based Outbox Pattern with Postgres Logical Replication</a>, artykuł Oskara Dudycza przedstawiający rozwiązanie oparte o bazę danych</li></ul><p>Zapraszam także do śledzenia profili Jacka na <a href="https://twitter.com/jacek_mil">Twitter/X</a> oraz <a href="https://www.linkedin.com/in/jacekmilewski/">LinkedIn</a> oraz do zapoznania się z <a href="http://www.bottega.com.pl/trener-jacek-milewski">listą szkoleń</a> Jacka w Bottega IT Minds.</p>
]]></content:encoded>
      <enclosure length="73355666" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/8ea04927-68a9-41f1-a41f-8c1205d78eb7/audio/165dc9d1-de00-4535-b284-1a5fedc5ce0e/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>78. O Outbox Pattern i skutecznej komunikacji z Jackiem Milewskim</itunes:title>
      <itunes:author>Jacek Milewski</itunes:author>
      <itunes:duration>01:16:18</itunes:duration>
      <itunes:summary>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.</itunes:summary>
      <itunes:subtitle>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.</itunes:subtitle>
      <itunes:keywords>software architecture, outbox pattern, network communication</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>78</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">9e81149e-5ef9-48a2-ae4b-bb43f6517176</guid>
      <title>77. O couplingu i decouplingu w systemie z Grzegorzem Piwowarkiem</title>
      <description><![CDATA[<p>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.</p><p>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.</p><p>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:</p><ul><li>odcinaniu frameworka webowego czy ORM,</li><li>efektach i zyskach płynących z decouplingu,</li><li>przydatnych heurystykach pomagających odpowiedzieć na pytanie, czy warto odcinać daną zależność,</li><li>architekturze heksagonalnej,</li><li>historiach z życia...</li></ul><p>Materiały dodatkowe:</p><ul><li><a href="https://www.youtube.com/watch?v=I0ZLVzAU7Ic">Trzymaj Springa na dystans</a> , wspomniana w rozmowie prezentacja Grzegorza z konferencji Confitura 2022</li><li><a href="https://www.goodreads.com/book/show/62703680-recipes-for-decoupling">Recipes for Decoupling</a>, książka Matthiasa Nobacka opisująca implementację konceptów dla ekosystemu PHP</li><li><a href="http://4comprehension.com/">4comprehension.com</a>, strona Grzegorza, na której można zapoznać się zarówno z ofertą szkoleń programistycznych jak i wpisami związanymi z Javą</li><li><a href="https://twitter.com/pivovarit">pivovarit@x</a>, profil Grzegorza na Twitter/X</li></ul>
]]></description>
      <pubDate>Tue, 2 Jan 2024 00:00:00 +0000</pubDate>
      <author>Grzegorz Piwowarek</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/77-EqZ_aZUa</link>
      <content:encoded><![CDATA[<p>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.</p><p>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.</p><p>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:</p><ul><li>odcinaniu frameworka webowego czy ORM,</li><li>efektach i zyskach płynących z decouplingu,</li><li>przydatnych heurystykach pomagających odpowiedzieć na pytanie, czy warto odcinać daną zależność,</li><li>architekturze heksagonalnej,</li><li>historiach z życia...</li></ul><p>Materiały dodatkowe:</p><ul><li><a href="https://www.youtube.com/watch?v=I0ZLVzAU7Ic">Trzymaj Springa na dystans</a> , wspomniana w rozmowie prezentacja Grzegorza z konferencji Confitura 2022</li><li><a href="https://www.goodreads.com/book/show/62703680-recipes-for-decoupling">Recipes for Decoupling</a>, książka Matthiasa Nobacka opisująca implementację konceptów dla ekosystemu PHP</li><li><a href="http://4comprehension.com/">4comprehension.com</a>, strona Grzegorza, na której można zapoznać się zarówno z ofertą szkoleń programistycznych jak i wpisami związanymi z Javą</li><li><a href="https://twitter.com/pivovarit">pivovarit@x</a>, profil Grzegorza na Twitter/X</li></ul>
]]></content:encoded>
      <enclosure length="59605325" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/2bab2b64-55dd-4b34-8928-a571e539dba0/audio/8c5b56df-61a9-4168-9515-7d66a88b3961/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>77. O couplingu i decouplingu w systemie z Grzegorzem Piwowarkiem</itunes:title>
      <itunes:author>Grzegorz Piwowarek</itunes:author>
      <itunes:duration>01:02:01</itunes:duration>
      <itunes:summary>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.</itunes:summary>
      <itunes:subtitle>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.</itunes:subtitle>
      <itunes:keywords>coupling, grzegorz piwowarek, software architecture, framework, decoupling, software design</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>77</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">a647b535-aace-413b-9ec0-823c1184ff99</guid>
      <title>76. O 77 latach doświadczeń w branży IT z Wojtkiem Ptakiem i Jarkiem Pałką</title>
      <description><![CDATA[<p>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.</p><p>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...</p><p>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?</p><p>Zapraszam!</p>
]]></description>
      <pubDate>Tue, 26 Dec 2023 00:00:00 +0000</pubDate>
      <author>Wojtek Ptak, Jarek Pałka</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/76-F58PxrYG</link>
      <content:encoded><![CDATA[<p>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.</p><p>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...</p><p>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?</p><p>Zapraszam!</p>
]]></content:encoded>
      <enclosure length="124474118" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/09727843-2042-461a-b562-a42aa4b93927/audio/2f128c75-f7f5-4f1d-95dc-4ab453cb992a/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>76. O 77 latach doświadczeń w branży IT z Wojtkiem Ptakiem i Jarkiem Pałką</itunes:title>
      <itunes:author>Wojtek Ptak, Jarek Pałka</itunes:author>
      <itunes:duration>02:09:32</itunes:duration>
      <itunes:summary>Mijający właśnie rok dla Better Software Design był szczególny i &quot;naj&quot; 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.</itunes:summary>
      <itunes:subtitle>Mijający właśnie rok dla Better Software Design był szczególny i &quot;naj&quot; 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.</itunes:subtitle>
      <itunes:keywords>kariera, doświadczenia, praca, lessons learned, it</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>76</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">b11b6595-b4a5-4594-af12-6ddf344aeeec</guid>
      <title>75. O User Story Mapping i analizie warsztatowej z Michałem Bartyzelem</title>
      <description><![CDATA[<p>"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.</p><p>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. </p><p>W tym odcinku rozmawiamy z Michałem między innymi o:</p><ul><li>bezużyteczności wielu historyjek typu "Jako klient chcę się zalogować, aby zrobić zakup w sklepie",</li><li>odkrywaniu właściwych aktorów, ich celi biznesowych i funkcjonalności, które służą ich osiągnięciu,</li><li>sposobach budowania mapy historyjek, zgodnie z założeniami User Story Mappingu,</li><li>wykorzystaniu USM w projekcie,</li><li>różnicach i podobieństwam pomiędzy EventStormingiem i User Story Mappingiem,</li><li>sposobach prowadzenia warsztatu analitycznego.</li></ul><p>Materiały dodatkowe:</p><ul><li><a href="https://jpattonassociates.com/wp-content/uploads/2015/01/how_you_slice_it.pdf">It's All in How You Slice</a>, artykuł Jeffa Pattona opisujący pierwotne założenia techniki, rozwiniętej następnie do User Story Mappingu</li><li><a href="https://jpattonassociates.com/the-new-backlog/">The New User Story Backlog is a Map</a>, drugi po artykule istotny wpis Pattona na temat problemów z historyjkami</li><li><a href="https://www.goodreads.com/pl/book/show/22221112">User Story Mapping: Discover the Whole Story, Build the Right Product</a>, książka Jeffa z 2012 roku, przedstawiająca technikę User Story Mappingu</li><li><a href="https://jpattonassociates.com/wp-content/uploads/2015/03/story_mapping.pdf">Story Map Concepts</a> oraz <a href="http://jeffpatton.wpengine.com/wp-content/uploads/2015/03/story_essentials_quickref.pdf">Agile Story Essentials</a>, krótkie i rzeczowe podsumowania pokazujące zasadę działania USM</li></ul><p>Polecam także zajrzeć na <a href="https://www.michalbartyzel.pl/">stronę Michała</a>, a w szczególności na prowadzonego przez niego <a href="https://www.michalbartyzel.pl/blog/">bloga</a>.</p><p>Zapraszam!</p>
]]></description>
      <pubDate>Tue, 19 Dec 2023 00:00:00 +0000</pubDate>
      <author>Michał Bartyzel</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/75-zbkKkDo9</link>
      <content:encoded><![CDATA[<p>"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.</p><p>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. </p><p>W tym odcinku rozmawiamy z Michałem między innymi o:</p><ul><li>bezużyteczności wielu historyjek typu "Jako klient chcę się zalogować, aby zrobić zakup w sklepie",</li><li>odkrywaniu właściwych aktorów, ich celi biznesowych i funkcjonalności, które służą ich osiągnięciu,</li><li>sposobach budowania mapy historyjek, zgodnie z założeniami User Story Mappingu,</li><li>wykorzystaniu USM w projekcie,</li><li>różnicach i podobieństwam pomiędzy EventStormingiem i User Story Mappingiem,</li><li>sposobach prowadzenia warsztatu analitycznego.</li></ul><p>Materiały dodatkowe:</p><ul><li><a href="https://jpattonassociates.com/wp-content/uploads/2015/01/how_you_slice_it.pdf">It's All in How You Slice</a>, artykuł Jeffa Pattona opisujący pierwotne założenia techniki, rozwiniętej następnie do User Story Mappingu</li><li><a href="https://jpattonassociates.com/the-new-backlog/">The New User Story Backlog is a Map</a>, drugi po artykule istotny wpis Pattona na temat problemów z historyjkami</li><li><a href="https://www.goodreads.com/pl/book/show/22221112">User Story Mapping: Discover the Whole Story, Build the Right Product</a>, książka Jeffa z 2012 roku, przedstawiająca technikę User Story Mappingu</li><li><a href="https://jpattonassociates.com/wp-content/uploads/2015/03/story_mapping.pdf">Story Map Concepts</a> oraz <a href="http://jeffpatton.wpengine.com/wp-content/uploads/2015/03/story_essentials_quickref.pdf">Agile Story Essentials</a>, krótkie i rzeczowe podsumowania pokazujące zasadę działania USM</li></ul><p>Polecam także zajrzeć na <a href="https://www.michalbartyzel.pl/">stronę Michała</a>, a w szczególności na prowadzonego przez niego <a href="https://www.michalbartyzel.pl/blog/">bloga</a>.</p><p>Zapraszam!</p>
]]></content:encoded>
      <enclosure length="51882820" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/a84850d9-d7d8-4cef-b858-ba35aece9055/audio/8cc157f0-3f2f-43d0-b559-c687a521f22d/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>75. O User Story Mapping i analizie warsztatowej z Michałem Bartyzelem</itunes:title>
      <itunes:author>Michał Bartyzel</itunes:author>
      <itunes:duration>00:54:00</itunes:duration>
      <itunes:summary>&quot;Jako użytkownik chcę przeszukać bazę książek, aby znaleźć kilka książek&quot; - 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.</itunes:summary>
      <itunes:subtitle>&quot;Jako użytkownik chcę przeszukać bazę książek, aby znaleźć kilka książek&quot; - 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.</itunes:subtitle>
      <itunes:keywords>jeff patton, event storming, analiza it, user story mapping, slice</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>75</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">d4b1dbc4-087c-4b1c-9fa4-96f4ef71cad8</guid>
      <title>74. O syndromie wypalenia zawodowego z Olą Kunysz</title>
      <description><![CDATA[<p>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.</p><p>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. </p><p>Materiały dodatkowe:</p><ul><li><a href="https://burnoutindex.yerbo.co">The Burnout Index</a>, darmowy test Yerbo wspomagający określenie poziomu ryzyka zagrożenia wypaleniem,</li><li><a href="https://wellbee.pl/psychoedukacja/testy/wypalenie-zawodowe">Test BAT12</a>, prostszy test w języku polskim,</li><li><a href="https://youtu.be/XyKDaysFuSo?si=_CglnGFyPmrdminL">Nie wypalaj się! Jak żonglerka może uratować pracowników IT?</a>, prezentacja Oli na TedX Koszalin</li><li><a href="https://instagram.com/olaqnysz">Ola@Instagram</a>, profil Oli na Instagramie, gdzie dzieli się m.in. informacjami na tematy związane z wypaleniem zawodowym</li></ul>
]]></description>
      <pubDate>Tue, 5 Dec 2023 00:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/74-j4ay_krD</link>
      <content:encoded><![CDATA[<p>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.</p><p>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. </p><p>Materiały dodatkowe:</p><ul><li><a href="https://burnoutindex.yerbo.co">The Burnout Index</a>, darmowy test Yerbo wspomagający określenie poziomu ryzyka zagrożenia wypaleniem,</li><li><a href="https://wellbee.pl/psychoedukacja/testy/wypalenie-zawodowe">Test BAT12</a>, prostszy test w języku polskim,</li><li><a href="https://youtu.be/XyKDaysFuSo?si=_CglnGFyPmrdminL">Nie wypalaj się! Jak żonglerka może uratować pracowników IT?</a>, prezentacja Oli na TedX Koszalin</li><li><a href="https://instagram.com/olaqnysz">Ola@Instagram</a>, profil Oli na Instagramie, gdzie dzieli się m.in. informacjami na tematy związane z wypaleniem zawodowym</li></ul>
]]></content:encoded>
      <enclosure length="57954085" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/5a458524-aaac-47a1-96cb-31d4c71db77b/audio/ecdf584d-7c7e-49f6-bc55-a5f86534fff6/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>74. O syndromie wypalenia zawodowego z Olą Kunysz</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>01:00:20</itunes:duration>
      <itunes:summary>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.</itunes:summary>
      <itunes:subtitle>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.</itunes:subtitle>
      <itunes:keywords>mental health, wypalenie zawodowe, praca, stres, ola kunysz</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>74</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">8bd821d9-9e49-4394-8974-2e21e9c2082d</guid>
      <title>73. O streamingu eventów w systemie z Piotrem Gankiewiczem</title>
      <description><![CDATA[<p>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ń.</p><p>Dziś zapraszam na rozmowę o message brokerach i event-streamingu. Wraz z dzisiejszym gościem, Piotrem Gankiewiczem, rozmawiamy między innymi o:</p><ul><li>różnicach pomiędzy message-brokerami a platformami do event-streamingu,</li><li>wykorzystywanej w obu przypadkach terminologii,</li><li>zrównoleglaniu procesów i zapewnianiu odpowiedniego porządku przetwarzania pochodzących ze strumieni zdarzeń.</li></ul><p>Zapraszam!</p><p>Materiały dodatkowe:</p><ul><li><a href="https://www.goodreads.com/book/show/23463279-designing-data-intensive-applications">Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems</a>, Martin Kleppmann, 2015</li><li><a href="https://www.youtube.com/playlist?list=PLeKd45zvjcDFUEv_ohr_HdUFe97RItdiB">Distributed Systems lecture series</a>, playlista materiałów na temat projektowania systemów rozproszonych</li><li><a href="https://bravenewgeek.com/building-a-distributed-log-from-scratch-part-1-storage-mechanics/">Building a Distributed Log from Scratch</a>, seria artykułów na temat tworzenia systemów rozproszonych</li><li><a href="https://www.cloudamqp.com/blog/the-consistent-hash-exchange-making-rabbitmq-a-better-broker.html">The Consistent Hash Exchange</a>, artykuł na temat opisywanego w odcinku algorytmu przypisywania konsumerów w RabbitMQ</li><li><a href="https://medium.com/baseds/ordering-distributed-events-29c1dd9d1eff">Ordering Distributed Events</a>, artykuł Vaidehi Joshi na temat porządkowania zdarzeń</li><li><a href="https://book.mixu.net/distsys/time.html">Distributed Systems: Time and order</a>, teoria porządkowania w systemach rozproszonych</li><li><a href="https://bravenewgeek.com/you-cannot-have-exactly-once-delivery/">You Cannot Have Exactly-Once Delivery</a></li></ul><p>Zapraszam także do odwiedzenia:</p><ul><li><a href="https://iggy.rs">Iggy.rs</a>, strona domowa projektu Iggy</li><li><a href="https://github.com/spetz">Piotr@Github</a></li><li><a href="https://twitter.com/spetzu">Piotr@X / Twitter</a></li></ul>
]]></description>
      <pubDate>Tue, 21 Nov 2023 00:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/73-Kq_XS1T_</link>
      <content:encoded><![CDATA[<p>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ń.</p><p>Dziś zapraszam na rozmowę o message brokerach i event-streamingu. Wraz z dzisiejszym gościem, Piotrem Gankiewiczem, rozmawiamy między innymi o:</p><ul><li>różnicach pomiędzy message-brokerami a platformami do event-streamingu,</li><li>wykorzystywanej w obu przypadkach terminologii,</li><li>zrównoleglaniu procesów i zapewnianiu odpowiedniego porządku przetwarzania pochodzących ze strumieni zdarzeń.</li></ul><p>Zapraszam!</p><p>Materiały dodatkowe:</p><ul><li><a href="https://www.goodreads.com/book/show/23463279-designing-data-intensive-applications">Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems</a>, Martin Kleppmann, 2015</li><li><a href="https://www.youtube.com/playlist?list=PLeKd45zvjcDFUEv_ohr_HdUFe97RItdiB">Distributed Systems lecture series</a>, playlista materiałów na temat projektowania systemów rozproszonych</li><li><a href="https://bravenewgeek.com/building-a-distributed-log-from-scratch-part-1-storage-mechanics/">Building a Distributed Log from Scratch</a>, seria artykułów na temat tworzenia systemów rozproszonych</li><li><a href="https://www.cloudamqp.com/blog/the-consistent-hash-exchange-making-rabbitmq-a-better-broker.html">The Consistent Hash Exchange</a>, artykuł na temat opisywanego w odcinku algorytmu przypisywania konsumerów w RabbitMQ</li><li><a href="https://medium.com/baseds/ordering-distributed-events-29c1dd9d1eff">Ordering Distributed Events</a>, artykuł Vaidehi Joshi na temat porządkowania zdarzeń</li><li><a href="https://book.mixu.net/distsys/time.html">Distributed Systems: Time and order</a>, teoria porządkowania w systemach rozproszonych</li><li><a href="https://bravenewgeek.com/you-cannot-have-exactly-once-delivery/">You Cannot Have Exactly-Once Delivery</a></li></ul><p>Zapraszam także do odwiedzenia:</p><ul><li><a href="https://iggy.rs">Iggy.rs</a>, strona domowa projektu Iggy</li><li><a href="https://github.com/spetz">Piotr@Github</a></li><li><a href="https://twitter.com/spetzu">Piotr@X / Twitter</a></li></ul>
]]></content:encoded>
      <enclosure length="59470766" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/867aa0f7-0daf-4178-b4ef-3568d556cd65/audio/78b22e31-7ca0-4a73-986d-36e975ac5843/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>73. O streamingu eventów w systemie z Piotrem Gankiewiczem</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>01:01:54</itunes:duration>
      <itunes:summary>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ń.</itunes:summary>
      <itunes:subtitle>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ń.</itunes:subtitle>
      <itunes:keywords>iggy, apache kafka, event driven architecture, event streaming, message broker</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>73</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">cc1b4330-13dc-46a8-b63c-fff1ecdc8661</guid>
      <title>72. O encjach w Domain-Driven Design z Kamilem Grzybkiem</title>
      <description><![CDATA[<p>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?</p><p>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.</p><p>W tym odcinku rozmawiamy między innymi o:</p><ul><li>przeznaczeniu wzorca Entity,</li><li>różnych metodach nadawania tożsamości obiektom,</li><li>podziałach encji względem cykli życia w domenie,</li><li>różnicach pomiędzy encjami a agregatami czy Value Objectami,</li><li>mapowaniu encji domenowych na encje bazodanowe.</li></ul><p>Zapraszam!</p><p>Materiały dodatkowe:</p><ul><li><a href="https://www.goodreads.com/book/show/15756865-implementing-domain-driven-design">Implementing Domain-Driven Design</a>, rozdział 5 poświęcony encjom domenowym</li><li><a href="https://www.baeldung.com/hi-lo-algorithm-hibernate">What Is the Hi/Lo Algorithm?</a>, artykuł na temat algorytmu Hi/Lo do generacji identyfikatorów</li><li><a href="https://enterprisecraftsmanship.com/posts/entity-identity-vs-database-primary-key/">Entity Identity vs Database Primary Key</a></li><li><a href="https://github.com/kgrzybek/modular-monolith-with-ddd">Modular Monolith with DDD</a>, repozytorium Kamila, w którym moduły korzystają ze wszystkich wzorców omawianych w odcinku wzorców taktycznych</li></ul>
]]></description>
      <pubDate>Mon, 23 Oct 2023 23:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/72-eo5CnkKs</link>
      <content:encoded><![CDATA[<p>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?</p><p>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.</p><p>W tym odcinku rozmawiamy między innymi o:</p><ul><li>przeznaczeniu wzorca Entity,</li><li>różnych metodach nadawania tożsamości obiektom,</li><li>podziałach encji względem cykli życia w domenie,</li><li>różnicach pomiędzy encjami a agregatami czy Value Objectami,</li><li>mapowaniu encji domenowych na encje bazodanowe.</li></ul><p>Zapraszam!</p><p>Materiały dodatkowe:</p><ul><li><a href="https://www.goodreads.com/book/show/15756865-implementing-domain-driven-design">Implementing Domain-Driven Design</a>, rozdział 5 poświęcony encjom domenowym</li><li><a href="https://www.baeldung.com/hi-lo-algorithm-hibernate">What Is the Hi/Lo Algorithm?</a>, artykuł na temat algorytmu Hi/Lo do generacji identyfikatorów</li><li><a href="https://enterprisecraftsmanship.com/posts/entity-identity-vs-database-primary-key/">Entity Identity vs Database Primary Key</a></li><li><a href="https://github.com/kgrzybek/modular-monolith-with-ddd">Modular Monolith with DDD</a>, repozytorium Kamila, w którym moduły korzystają ze wszystkich wzorców omawianych w odcinku wzorców taktycznych</li></ul>
]]></content:encoded>
      <enclosure length="60541642" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/615ece6e-b732-4129-9d91-7b274f4a99f2/audio/4f70178c-785c-4476-9dab-6c8de76e83e8/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>72. O encjach w Domain-Driven Design z Kamilem Grzybkiem</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>01:03:00</itunes:duration>
      <itunes:summary>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?</itunes:summary>
      <itunes:subtitle>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?</itunes:subtitle>
      <itunes:keywords>domain-driven design, entity, domain objects, software development, software patterns, patterns</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>72</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">3e514914-f512-4059-9ef9-eeef0a965415</guid>
      <title>71. O doświadczeniach z EventSourcingiem w projekcie z Łukaszem Reszke</title>
      <description><![CDATA[<p>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.</p><p>Moim gościem jest Łukasz Reszke, pracujący na co dzień właśnie przy projektach opartych o event-store i EventSourcing.</p><p>W tym odcinku rozmawiamy z Łukaszem między innymi o:</p><ul><li>praktycznym zastosowaniu EventSourcingu w projekcie z problemami u klienta,</li><li>wdrażaniu EventSourcingowego modułu do aplikacji z istniejącą relacyjną bazą i danymi,</li><li>publikacji eventów do pozostałej części systemu i rodzajach eventów,</li><li>odczytywaniu danych ze zdarzeń, strumieniach i linkowaniu do nich zdarzeń.</li></ul><p>Materiały dodatkowe:</p><ul><li><a href="https://www.youtube.com/watch?v=c0T9137Cb-8">Working with RailsEventStore in Cashflow Management System</a>, prezentacja Łukasza z konferencji wroc_love.rb 2023</li><li><a href="https://verraes.net/2019/06/eventsourcing-patterns-migration-events-ghost-context/">Eventsourcing Patterns: Migration Events in a Ghost Context</a>, artykuł Mathiasa Verraesa o imporcie danych z systemów legacy do modelu opartego o zdarzenia</li><li><a href="https://verraes.net/2019/05/patterns-for-decoupling-distsys-summary-event/">Patterns for Decoupling in Distributed Systems: Summary Event</a>, kolejny artykuł Mathiasa Verraesa, tym razem o emitowaniu zdarzeń zbiorczych</li><li><a href="https://twitter.com/lreszke">Łukasz@X</a>, profil Łukasza na X/Twitter</li></ul><p>Wspomniany w intro odcinek nr 10 z Andrzejem Krzywdą o refaktoryzacji The Arkency Way można znaleźć <a href="https://bettersoftwaredesign.pl/episodes/10">tutaj</a>.</p>
]]></description>
      <pubDate>Mon, 9 Oct 2023 23:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/71-VQQ8bCOp</link>
      <content:encoded><![CDATA[<p>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.</p><p>Moim gościem jest Łukasz Reszke, pracujący na co dzień właśnie przy projektach opartych o event-store i EventSourcing.</p><p>W tym odcinku rozmawiamy z Łukaszem między innymi o:</p><ul><li>praktycznym zastosowaniu EventSourcingu w projekcie z problemami u klienta,</li><li>wdrażaniu EventSourcingowego modułu do aplikacji z istniejącą relacyjną bazą i danymi,</li><li>publikacji eventów do pozostałej części systemu i rodzajach eventów,</li><li>odczytywaniu danych ze zdarzeń, strumieniach i linkowaniu do nich zdarzeń.</li></ul><p>Materiały dodatkowe:</p><ul><li><a href="https://www.youtube.com/watch?v=c0T9137Cb-8">Working with RailsEventStore in Cashflow Management System</a>, prezentacja Łukasza z konferencji wroc_love.rb 2023</li><li><a href="https://verraes.net/2019/06/eventsourcing-patterns-migration-events-ghost-context/">Eventsourcing Patterns: Migration Events in a Ghost Context</a>, artykuł Mathiasa Verraesa o imporcie danych z systemów legacy do modelu opartego o zdarzenia</li><li><a href="https://verraes.net/2019/05/patterns-for-decoupling-distsys-summary-event/">Patterns for Decoupling in Distributed Systems: Summary Event</a>, kolejny artykuł Mathiasa Verraesa, tym razem o emitowaniu zdarzeń zbiorczych</li><li><a href="https://twitter.com/lreszke">Łukasz@X</a>, profil Łukasza na X/Twitter</li></ul><p>Wspomniany w intro odcinek nr 10 z Andrzejem Krzywdą o refaktoryzacji The Arkency Way można znaleźć <a href="https://bettersoftwaredesign.pl/episodes/10">tutaj</a>.</p>
]]></content:encoded>
      <enclosure length="62025711" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/41965365-c85e-429a-8e0c-89e144723038/audio/b20a18a5-e51e-42ff-b3a4-763390bb5fa7/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>71. O doświadczeniach z EventSourcingiem w projekcie z Łukaszem Reszke</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>01:04:35</itunes:duration>
      <itunes:summary>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.</itunes:summary>
      <itunes:subtitle>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.</itunes:subtitle>
      <itunes:keywords>events, legacy refactoring, event driven architecture, event sourcing, software design</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>71</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">6015064c-ac24-43a4-902a-fe456ae24d38</guid>
      <title>70. O Testcontainers, piramidzie testów i jakości życia z Piotrem Przybyłem</title>
      <description><![CDATA[<p>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.</p><p>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.</p><p>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.</p><p>W tym odcinku rozmawiamy z Piotrem między innymi o:</p><ul><li>częstych problemach z testowaniem kodu i jego jednostkach,</li><li>możliwych podejściach do organizacji testów w piramidy, odwrócone piramidy, plastry miodu...</li><li>zasadzie działania biblioteki Testcontainers i jej kluczowych konceptach,</li><li>różnicach pomiędzy Testcontainers a innymi sposobami uruchamiania usług podczas testów,</li><li>synchronizacji kodu testów opartych o Testcontainers z infrastrukturą produkcyjną.</li></ul><p>Zapraszam!</p><p>Materiały dodatkowe:</p><ul><li><a href="https://testcontainers.com/getting-started/">Testcontainers Getting Started</a>, dokumentacja omawianej w odcinku biblioteki</li><li><a href="https://testcontainers.com/modules/">Katalog modułów</a>, dostępne gotowe kontenery z prekonfigurowanymi usługami</li><li><a href="https://github.com/testcontainers/workshop">Testcontainers Workshop</a>, repozytorium na Githubie z przykładowym kodem krok-po-kroku</li><li><a href="https://www.youtube.com/watch?v=6hHoZN9xRdY">Integration tests are needed and simple</a>, prezentacja Piotra o testach integracyjnych z użyciem TC z konferencji Devoxx UK 2023</li><li><a href="https://www.youtube.com/watch?v=bali16KUnOI">Testcontainers: needed, simple, powerful</a>, dłuższa, niemal 3 godzinna prezentacja z Devoxx z Belgii</li><li><a href="https://softwaregarden.dev/pl/tags/testcontainers/">Wpisy o Testcontainers</a>, blog Piotra o oprogramowaniu, nie tylko o testowaniu</li></ul>
]]></description>
      <pubDate>Mon, 25 Sep 2023 23:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/70-HaQ0R48F</link>
      <content:encoded><![CDATA[<p>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.</p><p>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.</p><p>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.</p><p>W tym odcinku rozmawiamy z Piotrem między innymi o:</p><ul><li>częstych problemach z testowaniem kodu i jego jednostkach,</li><li>możliwych podejściach do organizacji testów w piramidy, odwrócone piramidy, plastry miodu...</li><li>zasadzie działania biblioteki Testcontainers i jej kluczowych konceptach,</li><li>różnicach pomiędzy Testcontainers a innymi sposobami uruchamiania usług podczas testów,</li><li>synchronizacji kodu testów opartych o Testcontainers z infrastrukturą produkcyjną.</li></ul><p>Zapraszam!</p><p>Materiały dodatkowe:</p><ul><li><a href="https://testcontainers.com/getting-started/">Testcontainers Getting Started</a>, dokumentacja omawianej w odcinku biblioteki</li><li><a href="https://testcontainers.com/modules/">Katalog modułów</a>, dostępne gotowe kontenery z prekonfigurowanymi usługami</li><li><a href="https://github.com/testcontainers/workshop">Testcontainers Workshop</a>, repozytorium na Githubie z przykładowym kodem krok-po-kroku</li><li><a href="https://www.youtube.com/watch?v=6hHoZN9xRdY">Integration tests are needed and simple</a>, prezentacja Piotra o testach integracyjnych z użyciem TC z konferencji Devoxx UK 2023</li><li><a href="https://www.youtube.com/watch?v=bali16KUnOI">Testcontainers: needed, simple, powerful</a>, dłuższa, niemal 3 godzinna prezentacja z Devoxx z Belgii</li><li><a href="https://softwaregarden.dev/pl/tags/testcontainers/">Wpisy o Testcontainers</a>, blog Piotra o oprogramowaniu, nie tylko o testowaniu</li></ul>
]]></content:encoded>
      <enclosure length="68969072" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/9764bf80-0533-4f0c-8538-d5f9c35a4b7c/audio/44e59bf3-c7c4-43d3-b376-bb80d17c53fb/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>70. O Testcontainers, piramidzie testów i jakości życia z Piotrem Przybyłem</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>01:11:48</itunes:duration>
      <itunes:summary>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.</itunes:summary>
      <itunes:subtitle>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.</itunes:subtitle>
      <itunes:keywords>docker, software development, software testing, testcontainers, integration tests</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>70</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">bd34a840-0f22-4719-b4de-73b89df27f08</guid>
      <title>69. O wydajności systemu, optymalizacjach i trade-offach z Tomaszem Lelkiem</title>
      <description><![CDATA[<p>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.</p><p>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...</p><p>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.</p><p>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 <a href="https://forms.gle/o2rVAQHmwZuyP7y66">https://forms.gle/o2rVAQHmwZuyP7y66</a></p>
]]></description>
      <pubDate>Mon, 11 Sep 2023 23:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/69-9pVwrdqX</link>
      <content:encoded><![CDATA[<p>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.</p><p>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...</p><p>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.</p><p>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 <a href="https://forms.gle/o2rVAQHmwZuyP7y66">https://forms.gle/o2rVAQHmwZuyP7y66</a></p>
]]></content:encoded>
      <enclosure length="55906605" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/df608a66-fea8-45a2-883e-268e7e49a4f6/audio/0750ab59-c367-4f8f-8bbd-9cb295146569/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>69. O wydajności systemu, optymalizacjach i trade-offach z Tomaszem Lelkiem</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>00:58:12</itunes:duration>
      <itunes:summary>Czy nieczytelny, trudno nierozszerzalny i na dodatek zduplikowany kod może być dobry? 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.</itunes:summary>
      <itunes:subtitle>Czy nieczytelny, trudno nierozszerzalny i na dodatek zduplikowany kod może być dobry? 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.</itunes:subtitle>
      <itunes:keywords>premature optimization, tomasz lelek, tradeoffs, software engineering, performance optimization</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>69</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">c0e06bbe-b3ac-4aa4-aabd-042776a62cac</guid>
      <title>68. O rozwoju domeny generycznej w modelu open-source z Łukaszem Chruścielem</title>
      <description><![CDATA[<p>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?</p><p>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ą.</p><p>Zapraszam!</p><p>Materiały dodatkowe:</p><ul><li><a href="https://github.com/Sylius/Sylius">Sylius Github</a>, repozytorium projektu</li><li><a href="https://twitter.com/lukaszchrusciel">Profil Łukasza na Twitterze</a></li><li><a href="https://www.slideshare.net/ukaszChruciel1/boilingfrogs-rozterki-i-decyzje-czego-si-nauczylimy-projektujc-api-syliusa">Rozterki i decyzje. Czego się nauczyliśmy projektując API Syliusa</a>, prezentacja Łukasza z konferencji Boiling Frogs 2023, przy okazji której mogliśmy się spotkać i porozmawiać</li></ul>
]]></description>
      <pubDate>Mon, 28 Aug 2023 23:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/68-ARlQxOW0</link>
      <content:encoded><![CDATA[<p>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?</p><p>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ą.</p><p>Zapraszam!</p><p>Materiały dodatkowe:</p><ul><li><a href="https://github.com/Sylius/Sylius">Sylius Github</a>, repozytorium projektu</li><li><a href="https://twitter.com/lukaszchrusciel">Profil Łukasza na Twitterze</a></li><li><a href="https://www.slideshare.net/ukaszChruciel1/boilingfrogs-rozterki-i-decyzje-czego-si-nauczylimy-projektujc-api-syliusa">Rozterki i decyzje. Czego się nauczyliśmy projektując API Syliusa</a>, prezentacja Łukasza z konferencji Boiling Frogs 2023, przy okazji której mogliśmy się spotkać i porozmawiać</li></ul>
]]></content:encoded>
      <enclosure length="50028813" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/a626232b-952b-4f75-8456-2863d6da3b9f/audio/68a9ea82-8b68-48ab-8dd4-6ecaf1dbf041/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>68. O rozwoju domeny generycznej w modelu open-source z Łukaszem Chruścielem</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>00:52:03</itunes:duration>
      <itunes:summary>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?

</itunes:summary>
      <itunes:subtitle>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?

</itunes:subtitle>
      <itunes:keywords>sylius, open source, łukasz chruściel, generic subdomain</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>68</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">f0cbcbc2-107c-4bbc-ab05-ff22aff22ea1</guid>
      <title>67. O danych prywatnych w architekturach zdarzeniowych z Oskarem Dudyczem</title>
      <description><![CDATA[<p>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...</p><p>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.</p><p>W tym odcinku razem z Oskarem rozmawiamy m.in. o:</p><ul><li>prywatności niektórych danych,</li><li>usuwaniu danych vs utracie możliwości ich dalszego przetwarzania,</li><li>strategiach "zapominania" o danych prywatnych w architekturach eventowych,</li><li>czym jest i jak działa crypto-shredding, tombstoning czy scavenging,</li><li>GDPR i o tym, o czym zwykle mało pamięta się w projekcie...</li></ul><p>Materiały dodatkowe:</p><ul><li><a href="https://event-driven.io/pl/gdpr/">How to deal with privacy and GDPR in Event-Sourced systems</a>, prezentacja Oskara na omawiany w odcinku temat z konferencji Devoxx Greece</li><li><a href="https://www.youtube.com/watch?v=l6ueOeoW7XM">Scalable User Privacy: Crypto Shredding at Spotify</a>, prezentacja Brama Leendersa na temat przetwarzania danych prywatnych w Spotify</li><li><a href="https://gdpr.eu/tag/gdpr/">GDPR - General Data Protection Regulation</a>, zestaw regulacji na temat prywatności i ochrony danych prywatnych</li><li><a href="https://developers.eventstore.com/server/v5/streams.html#deleting-streams-and-events">Tombstoning i scavening w EventStoreDB</a>, fragment dokumentacji na temat sposobów usuwania zdarzeń</li></ul>
]]></description>
      <pubDate>Mon, 14 Aug 2023 23:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/67-6IXqQmHo</link>
      <content:encoded><![CDATA[<p>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...</p><p>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.</p><p>W tym odcinku razem z Oskarem rozmawiamy m.in. o:</p><ul><li>prywatności niektórych danych,</li><li>usuwaniu danych vs utracie możliwości ich dalszego przetwarzania,</li><li>strategiach "zapominania" o danych prywatnych w architekturach eventowych,</li><li>czym jest i jak działa crypto-shredding, tombstoning czy scavenging,</li><li>GDPR i o tym, o czym zwykle mało pamięta się w projekcie...</li></ul><p>Materiały dodatkowe:</p><ul><li><a href="https://event-driven.io/pl/gdpr/">How to deal with privacy and GDPR in Event-Sourced systems</a>, prezentacja Oskara na omawiany w odcinku temat z konferencji Devoxx Greece</li><li><a href="https://www.youtube.com/watch?v=l6ueOeoW7XM">Scalable User Privacy: Crypto Shredding at Spotify</a>, prezentacja Brama Leendersa na temat przetwarzania danych prywatnych w Spotify</li><li><a href="https://gdpr.eu/tag/gdpr/">GDPR - General Data Protection Regulation</a>, zestaw regulacji na temat prywatności i ochrony danych prywatnych</li><li><a href="https://developers.eventstore.com/server/v5/streams.html#deleting-streams-and-events">Tombstoning i scavening w EventStoreDB</a>, fragment dokumentacji na temat sposobów usuwania zdarzeń</li></ul>
]]></content:encoded>
      <enclosure length="51791654" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/0bcd1467-4438-4a7e-a402-7185e26b1d47/audio/2906e8ad-4749-45a2-a79b-c7a5c3fc50ab/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>67. O danych prywatnych w architekturach zdarzeniowych z Oskarem Dudyczem</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>00:53:55</itunes:duration>
      <itunes:summary>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...</itunes:summary>
      <itunes:subtitle>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...</itunes:subtitle>
      <itunes:keywords>data governance, private data, gdpr, event-sourcing, event-driven architecture</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>67</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">77c63266-aca1-4b32-a914-8abcdbcfeb93</guid>
      <title>66. O Fitness Functions w architekturze ewolucyjnej z Sebastianem Buczyńskim</title>
      <description><![CDATA[<p>"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.</p><p>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.</p><p>Zapraszam!</p><p>Materiały dodatkowe:</p><ul><li><a href="https://www.goodreads.com/book/show/35755822-building-evolutionary-architectures">Building Evolutionary Architectures: Support Constant Change</a>, Neal Ford, Rebecca Parsons, Patrick Kua, 2017</li><li><a href="https://www.youtube.com/watch?v=m2ZlX1je3as&pp=ygUaZXZvbHV0aW9uYXJ5IGFyY2hpdGVjdHVyZSA%3D">Building Evolutionary Architectures</a>, prezentacja Rebeki Parsons, Neala Forda i Jamesa Lewisa z konferencji GOTO 2023</li><li><a href="https://www.youtube.com/watch?v=CglSFhwbI3s">Evolutionary Software Architectures</a>, prezentacja Neala Forda z Voxxed Days</li><li><a href="https://www.infoq.com/articles/evolutionary-architecture-organizational/">Evolutionary Architecture from an Organizational Perspective</a>, artykuł jednego z gości Better Software Design, Radka Maziarki na temat dopasowania architektury do przedsiębiorstwa</li></ul>
]]></description>
      <pubDate>Mon, 31 Jul 2023 23:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/66-oO4IVwgW</link>
      <content:encoded><![CDATA[<p>"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.</p><p>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.</p><p>Zapraszam!</p><p>Materiały dodatkowe:</p><ul><li><a href="https://www.goodreads.com/book/show/35755822-building-evolutionary-architectures">Building Evolutionary Architectures: Support Constant Change</a>, Neal Ford, Rebecca Parsons, Patrick Kua, 2017</li><li><a href="https://www.youtube.com/watch?v=m2ZlX1je3as&pp=ygUaZXZvbHV0aW9uYXJ5IGFyY2hpdGVjdHVyZSA%3D">Building Evolutionary Architectures</a>, prezentacja Rebeki Parsons, Neala Forda i Jamesa Lewisa z konferencji GOTO 2023</li><li><a href="https://www.youtube.com/watch?v=CglSFhwbI3s">Evolutionary Software Architectures</a>, prezentacja Neala Forda z Voxxed Days</li><li><a href="https://www.infoq.com/articles/evolutionary-architecture-organizational/">Evolutionary Architecture from an Organizational Perspective</a>, artykuł jednego z gości Better Software Design, Radka Maziarki na temat dopasowania architektury do przedsiębiorstwa</li></ul>
]]></content:encoded>
      <enclosure length="54321794" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/062474f4-a12c-42e2-b034-4e599e86dc82/audio/ef284543-cba8-40ee-9cc2-23a0a95d70b1/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>66. O Fitness Functions w architekturze ewolucyjnej z Sebastianem Buczyńskim</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>00:56:33</itunes:duration>
      <itunes:summary>&quot;Architekci muszę bez przerwy oceniać cechy architektury, aby upewnić się, że ciągle zapewniają one jakość i nie stają się antywzorcami...&quot; Ten cytat z książki &quot;Evolutionary Architecture&quot; autorstwa Neala Forda, Rebeki Parsons i Patricka Kua dotyczy jednego z fundamentów architektury ewolucyjnej, czyli tzw. funkcji dopasowania - Fitness Functions.</itunes:summary>
      <itunes:subtitle>&quot;Architekci muszę bez przerwy oceniać cechy architektury, aby upewnić się, że ciągle zapewniają one jakość i nie stają się antywzorcami...&quot; Ten cytat z książki &quot;Evolutionary Architecture&quot; autorstwa Neala Forda, Rebeki Parsons i Patricka Kua dotyczy jednego z fundamentów architektury ewolucyjnej, czyli tzw. funkcji dopasowania - Fitness Functions.</itunes:subtitle>
      <itunes:keywords>architektura ewolucyjna, software architecture, evolutionary architecture, fitness functions, system design</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>66</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">55f1b455-9b4e-46dc-802f-69ac3d0604f3</guid>
      <title>65. LIVE PHPers Summit 2023</title>
      <description><![CDATA[<p>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.</p><p>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ę!</p><p>Zapraszam!</p>
]]></description>
      <pubDate>Mon, 17 Jul 2023 23:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/65-iXpcCteL</link>
      <content:encoded><![CDATA[<p>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.</p><p>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ę!</p><p>Zapraszam!</p>
]]></content:encoded>
      <enclosure length="78840573" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/036c2cd2-a6b5-47c6-a7d2-ba6f3509cc0b/audio/c6be9dea-4f8f-4989-ba1f-ad7574fdc8d2/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>65. LIVE PHPers Summit 2023</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>01:22:05</itunes:duration>
      <itunes:summary>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.</itunes:summary>
      <itunes:subtitle>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.</itunes:subtitle>
      <itunes:keywords>software quality, live, software craftsmanship, michał giergielewicz, mariusz gil, phpers summit, conference, grzegorz korba</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>65</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">84b8ea2a-1425-4c5b-82b3-77aecaf09492</guid>
      <title>64. O architekturze hexagonalnej, portach i adapterach z Kubą Nabrdalikiem</title>
      <description><![CDATA[<p>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?</p><p>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...</p><p>W dzisiejszym odcinku:</p><ul><li>czym jest architektura heksagonalna,</li><li>czym są porty i adaptery,</li><li>skąd w ogóle wywodzi się ten koncept i jak ma się do dzisiejszych czasów,</li><li>jakie typowe błędy można popełnić stosując ten wzorzec w kodzie,</li><li>nie zabrakło oczywiście przykładów z życia i produkcji...</li></ul><p>Materiały dodatkowe:</p><ul><li><a href="https://hexagonalarchitecture.org">hexagonalarchitecture.org</a>, homepage na temat Ports & Adapters</li><li><a href="https://alistair.cockburn.us/hexagonal-architecture/">Hexagonal architecture</a>, nowsza wersja oryginalnego wpisu Alistaira Cockburna na temat architektury heksagonalnej z 2005 roku</li><li><a href="http://wiki.c2.com/?HexagonalArchitecture">Hexagonal architecture @ wiki c2</a>, wpis na blogu Warda Cunninghama</li><li><a href="https://github.com/totheralistair/SmallerWebHexagon">SmallerWebHexagon</a>, wspominane w odcinku repo pokazujące bazową ideę</li><li><a href="https://github.com/jakubnabrdalik/hentai">Hentai</a>, repozytorium Kuby Nabrdalika pokazujące użycie hexagona z modularyzacją i innymi technikami</li></ul>
]]></description>
      <pubDate>Mon, 3 Jul 2023 23:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/64-1sjNsQvS</link>
      <content:encoded><![CDATA[<p>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?</p><p>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...</p><p>W dzisiejszym odcinku:</p><ul><li>czym jest architektura heksagonalna,</li><li>czym są porty i adaptery,</li><li>skąd w ogóle wywodzi się ten koncept i jak ma się do dzisiejszych czasów,</li><li>jakie typowe błędy można popełnić stosując ten wzorzec w kodzie,</li><li>nie zabrakło oczywiście przykładów z życia i produkcji...</li></ul><p>Materiały dodatkowe:</p><ul><li><a href="https://hexagonalarchitecture.org">hexagonalarchitecture.org</a>, homepage na temat Ports & Adapters</li><li><a href="https://alistair.cockburn.us/hexagonal-architecture/">Hexagonal architecture</a>, nowsza wersja oryginalnego wpisu Alistaira Cockburna na temat architektury heksagonalnej z 2005 roku</li><li><a href="http://wiki.c2.com/?HexagonalArchitecture">Hexagonal architecture @ wiki c2</a>, wpis na blogu Warda Cunninghama</li><li><a href="https://github.com/totheralistair/SmallerWebHexagon">SmallerWebHexagon</a>, wspominane w odcinku repo pokazujące bazową ideę</li><li><a href="https://github.com/jakubnabrdalik/hentai">Hentai</a>, repozytorium Kuby Nabrdalika pokazujące użycie hexagona z modularyzacją i innymi technikami</li></ul>
]]></content:encoded>
      <enclosure length="51539136" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/4235436d-0896-4794-b3a1-d72bfd14b305/audio/fc326290-8d8b-4729-9720-3c3dbd051fcc/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>64. O architekturze hexagonalnej, portach i adapterach z Kubą Nabrdalikiem</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>00:53:40</itunes:duration>
      <itunes:summary>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 &amp; Adapters? I jak to przekłada się na kod systemu?</itunes:summary>
      <itunes:subtitle>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 &amp; Adapters? I jak to przekłada się na kod systemu?</itunes:subtitle>
      <itunes:keywords>kuba nabrdalik, ports and adapters, alistair cockburn, software architecture, hexagonal architecture</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>64</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">934e5952-c871-41a4-a6e6-a511636cb9bb</guid>
      <title>63. O modułach w DDD i organizacji kodu aplikacji biznesowej z Marcinem Markowskim</title>
      <description><![CDATA[<p>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.</p><p>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.</p><p>W dzisiejszym odcinku rozmawiamy z Marcinem m.in. o:</p><ul><li>decyzjach wpływających na kształt subdomen biznesowych i bounded contextów,</li><li>modułach i ich roli w projekcie,</li><li>organizacji kodu i struktury aplikacji w pakiety.</li></ul><p>Materiały dodatkowe:</p><ul><li><a href="https://www.goodreads.com/book/show/179133.Domain_Driven_Design">Tacking Complexity in the Heart of Software</a>, Eric Evans, rozdział poświęcony modułom,</li><li><a href="https://dev.to/ielgohary/modules-in-ddd-9b7">Modules in DDD</a>, artykuł podsumowujący wspomniany powyżej rozdział,</li><li><a href="https://github.com/itlibrium/DDD-starter-dotnet">DDD Starter DotNet</a>, przykład organizacji kodu w repozytorium Marcina,</li><li><a href="https://github.com/kgrzybek/modular-monolith-with-ddd#31-high-level-view">Modular Monolith with DDD</a>, przykład organizacji kodu w repozytorium Kamila Grzybka,</li><li><a href="https://livebook.manning.com/book/functional-and-reactive-domain-modeling/chapter-5/">Modularization of domain models</a>, darmowy rozdział książki Functional and Reactive Domain Modeling,</li></ul>
]]></description>
      <pubDate>Mon, 19 Jun 2023 23:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/63-zs1MsQ07</link>
      <content:encoded><![CDATA[<p>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.</p><p>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.</p><p>W dzisiejszym odcinku rozmawiamy z Marcinem m.in. o:</p><ul><li>decyzjach wpływających na kształt subdomen biznesowych i bounded contextów,</li><li>modułach i ich roli w projekcie,</li><li>organizacji kodu i struktury aplikacji w pakiety.</li></ul><p>Materiały dodatkowe:</p><ul><li><a href="https://www.goodreads.com/book/show/179133.Domain_Driven_Design">Tacking Complexity in the Heart of Software</a>, Eric Evans, rozdział poświęcony modułom,</li><li><a href="https://dev.to/ielgohary/modules-in-ddd-9b7">Modules in DDD</a>, artykuł podsumowujący wspomniany powyżej rozdział,</li><li><a href="https://github.com/itlibrium/DDD-starter-dotnet">DDD Starter DotNet</a>, przykład organizacji kodu w repozytorium Marcina,</li><li><a href="https://github.com/kgrzybek/modular-monolith-with-ddd#31-high-level-view">Modular Monolith with DDD</a>, przykład organizacji kodu w repozytorium Kamila Grzybka,</li><li><a href="https://livebook.manning.com/book/functional-and-reactive-domain-modeling/chapter-5/">Modularization of domain models</a>, darmowy rozdział książki Functional and Reactive Domain Modeling,</li></ul>
]]></content:encoded>
      <enclosure length="69565585" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/fd7c431e-0066-4f16-8f9c-cf01a594c811/audio/a7f2fcde-8f83-4533-87bf-496880a3cc3a/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>63. O modułach w DDD i organizacji kodu aplikacji biznesowej z Marcinem Markowskim</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>01:12:25</itunes:duration>
      <itunes:summary>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.







</itunes:summary>
      <itunes:subtitle>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.







</itunes:subtitle>
      <itunes:keywords>bounded context, modules, subdomain, domain driven design, project structure, ddd, code design</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>63</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">3e9badc7-e638-45e3-9e0e-eb478c125370</guid>
      <title>62. O siedmiu dev-grzechach głównych kariery w IT z Wojtkiem Ptakiem</title>
      <description><![CDATA[<p>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...</p><p>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.</p><p>Materiały dodatkowe:</p><ul><li><a href="https://www.youtube.com/watch?v=FeDks5BJCQQ">Developer Community Keynote: The thing about burnout</a>,</li><li><a href="https://www.goodreads.com/book/show/52163477-zasady">Principles</a>, Ray Dalio, 2017</li><li><a href="https://www.goodreads.com/book/show/13593553-to-sell-is-human">To Sell is Human: The Surprising Truth About Moving Others</a>, Daniel H. Pink, 2012</li><li><a href="https://www.goodreads.com/book/show/566213.The_Secrets_of_Consulting">The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully</a>, Gerald M. Weinberg, Virginia Satir, 1985 - klasyka gatunku, wielokrotnie wspominana w poprzednich odcinkach</li></ul><p>Odcinek ukazuje się przy okazji 3 edycji szkolenia <a href="https://legacyfighter.pl">Legacy Fighter</a>. 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!</p><p>Cały kod jest dostępny w kilku technologiach jest dostępny na <a href="https://github.com/legacyfighter">GitHubie</a>.</p>
]]></description>
      <pubDate>Mon, 5 Jun 2023 23:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/62-FOR_1tX3</link>
      <content:encoded><![CDATA[<p>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...</p><p>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.</p><p>Materiały dodatkowe:</p><ul><li><a href="https://www.youtube.com/watch?v=FeDks5BJCQQ">Developer Community Keynote: The thing about burnout</a>,</li><li><a href="https://www.goodreads.com/book/show/52163477-zasady">Principles</a>, Ray Dalio, 2017</li><li><a href="https://www.goodreads.com/book/show/13593553-to-sell-is-human">To Sell is Human: The Surprising Truth About Moving Others</a>, Daniel H. Pink, 2012</li><li><a href="https://www.goodreads.com/book/show/566213.The_Secrets_of_Consulting">The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully</a>, Gerald M. Weinberg, Virginia Satir, 1985 - klasyka gatunku, wielokrotnie wspominana w poprzednich odcinkach</li></ul><p>Odcinek ukazuje się przy okazji 3 edycji szkolenia <a href="https://legacyfighter.pl">Legacy Fighter</a>. 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!</p><p>Cały kod jest dostępny w kilku technologiach jest dostępny na <a href="https://github.com/legacyfighter">GitHubie</a>.</p>
]]></content:encoded>
      <enclosure length="68141103" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/b82220e7-31e6-4c5a-988e-aa07268e4522/audio/8892402e-92b0-4ad5-9bf0-09c367bc9bc4/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>62. O siedmiu dev-grzechach głównych kariery w IT z Wojtkiem Ptakiem</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>01:10:56</itunes:duration>
      <itunes:summary>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 &quot;dev-grzeszków&quot;, które z perspektywy osób odpowiedzialnych za pion IT mogą przeszkadzać w karierze. Ponieważ technologia to niestety nie wszystko...</itunes:summary>
      <itunes:subtitle>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 &quot;dev-grzeszków&quot;, które z perspektywy osób odpowiedzialnych za pion IT mogą przeszkadzać w karierze. Ponieważ technologia to niestety nie wszystko...</itunes:subtitle>
      <itunes:keywords>kariera, rozwój umiejętności, software engineering</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>62</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">5c62fa74-addf-43c7-8795-fde3404e1721</guid>
      <title>61. O dostarczaniu kodu na produkcję z użyciem Feature Toggles z Mateuszem Kwaśniewskim</title>
      <description><![CDATA[<p>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.</p><p>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.</p><p>W tym odcinku rozmawiamy z Mateuszem m.in. o:</p><ul><li>rozdzielaniu wdrożeń od wydań projektu,</li><li>różnego rodzajach Feature Toggle'ach i ich przeznaczeniu,</li><li>sposobach i miejscach osadzania toggli w kodzie,</li><li>dobrych i złych praktykach stosowania tej techniki w projekcie,</li><li>testowaniu kodu wyposażonego we flagi.</li></ul><p>Zapraszam!</p><p>Materiały dodatkowe:</p><ul><li><a href="https://martinfowler.com/articles/feature-toggles.html">Feature Toggles a.k.a Feature Flags</a>, świetny artykuł Pete Hodgsona na temat różnego rodzaju toggli, ich przeznaczenia i cykli życia</li><li><a href="https://www.honeybadger.io/newsletter/knight-capital/">The most expensive bug in history...</a>, poruszona już w podkaście historia firmy Knights Capital, zakończona m.in. błędnym wykorzystaniem feature flagi</li><li><a href="https://www.youtube.com/watch?v=-yHZ9uLVSp4">Feature Toggles - Why and How to Add to Your Software</a>, 2-godzinny tutorial na temat stosowania toggli z użyciem Unleasha</li><li><a href="https://docs.getunleash.io/tutorials/quickstart">Unleash Quickstart</a>, skrócona wersja tutoriala</li><li><a href="https://featureflags.pl">FeatureFlags.pl</a>, małe kompendium wiedzy na temat Feature Flags i podejścia Trunk Based Development</li></ul>
]]></description>
      <pubDate>Mon, 29 May 2023 23:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/61-zpPLWxS1</link>
      <content:encoded><![CDATA[<p>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.</p><p>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.</p><p>W tym odcinku rozmawiamy z Mateuszem m.in. o:</p><ul><li>rozdzielaniu wdrożeń od wydań projektu,</li><li>różnego rodzajach Feature Toggle'ach i ich przeznaczeniu,</li><li>sposobach i miejscach osadzania toggli w kodzie,</li><li>dobrych i złych praktykach stosowania tej techniki w projekcie,</li><li>testowaniu kodu wyposażonego we flagi.</li></ul><p>Zapraszam!</p><p>Materiały dodatkowe:</p><ul><li><a href="https://martinfowler.com/articles/feature-toggles.html">Feature Toggles a.k.a Feature Flags</a>, świetny artykuł Pete Hodgsona na temat różnego rodzaju toggli, ich przeznaczenia i cykli życia</li><li><a href="https://www.honeybadger.io/newsletter/knight-capital/">The most expensive bug in history...</a>, poruszona już w podkaście historia firmy Knights Capital, zakończona m.in. błędnym wykorzystaniem feature flagi</li><li><a href="https://www.youtube.com/watch?v=-yHZ9uLVSp4">Feature Toggles - Why and How to Add to Your Software</a>, 2-godzinny tutorial na temat stosowania toggli z użyciem Unleasha</li><li><a href="https://docs.getunleash.io/tutorials/quickstart">Unleash Quickstart</a>, skrócona wersja tutoriala</li><li><a href="https://featureflags.pl">FeatureFlags.pl</a>, małe kompendium wiedzy na temat Feature Flags i podejścia Trunk Based Development</li></ul>
]]></content:encoded>
      <enclosure length="68717617" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/0ea07bac-86c7-417b-9f87-e1dbc43b7e84/audio/7dd286f6-b040-42f8-ac44-99384df1d651/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>61. O dostarczaniu kodu na produkcję z użyciem Feature Toggles z Mateuszem Kwaśniewskim</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>01:11:32</itunes:duration>
      <itunes:summary>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.</itunes:summary>
      <itunes:subtitle>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.</itunes:subtitle>
      <itunes:keywords>software releases, software development, ops toggles, release toggles, trunk based development, feature toggles, experiment toggles, feature flags</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>61</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">170124ec-8636-4dd2-b746-57516ba27f5f</guid>
      <title>60. O technikach Living Documentation i modelu P3 z Marcinem Markowskim</title>
      <description><![CDATA[<p>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.</p><p>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ć.</p><p>W tym odcinku rozmawiamy z Marcinem m.in. o:</p><ul><li>co i dlaczego warto dokumentować podczas prac nad projektem,</li><li>typowych problemach z dokumentacją, w tym</li><li>koncepcie Living Documentation autorstwa Cyrille Martraire,</li><li>strategiach i konwencjach pozwalających utrzymać aktualność dokumentacji wbudowanej w projekt,</li><li>założeniach modelu P3 i różnych perspektywach dokumentacji.</li></ul><p>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.</p><p>Materiały dodatkowe:</p><ul><li><a href="https://www.goodreads.com/book/show/34927405-living-documentation">Living Documentation: Continuous Knowledge Sharing by Design</a>, 2015, wspomniana w odcinku książka Cyrille Martraire</li><li><a href="https://www.youtube.com/watch?v=icGhEOWPqB4">Leaving Documentation, or Living Documentation?</a>, prezentacja na wspomniany temat autorstwa Cyrille'a z konferencji SoCraTes</li><li><a href="https://www.goodreads.com/book/show/223911.Documenting_Software_Architectures">Documenting Software Architectures: Views and Beyond</a>, Felix Bachmann, Len Bass, David Garlan, 2002</li><li><a href="https://github.com/P3-model/P3-model/">P3 Model</a>, strona projektu Marcina i Łukasza Szydło na GitHubie, na ten moment informacyjnie o projekcie</li><li><a href="https://slides.com/technites_pl/living-documentation">Dokumentacja, która sama się pisze</a>, prezentacja Marcina z Boiling Frogs i 4Developers 2023</li><li><a href="https://twitter.com/technites_pl">marcin@twitter</a>, profil Marcina na Twitterze</li></ul><p>Zapraszam!</p>
]]></description>
      <pubDate>Mon, 15 May 2023 23:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/60-_yRsQ5fC</link>
      <content:encoded><![CDATA[<p>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.</p><p>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ć.</p><p>W tym odcinku rozmawiamy z Marcinem m.in. o:</p><ul><li>co i dlaczego warto dokumentować podczas prac nad projektem,</li><li>typowych problemach z dokumentacją, w tym</li><li>koncepcie Living Documentation autorstwa Cyrille Martraire,</li><li>strategiach i konwencjach pozwalających utrzymać aktualność dokumentacji wbudowanej w projekt,</li><li>założeniach modelu P3 i różnych perspektywach dokumentacji.</li></ul><p>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.</p><p>Materiały dodatkowe:</p><ul><li><a href="https://www.goodreads.com/book/show/34927405-living-documentation">Living Documentation: Continuous Knowledge Sharing by Design</a>, 2015, wspomniana w odcinku książka Cyrille Martraire</li><li><a href="https://www.youtube.com/watch?v=icGhEOWPqB4">Leaving Documentation, or Living Documentation?</a>, prezentacja na wspomniany temat autorstwa Cyrille'a z konferencji SoCraTes</li><li><a href="https://www.goodreads.com/book/show/223911.Documenting_Software_Architectures">Documenting Software Architectures: Views and Beyond</a>, Felix Bachmann, Len Bass, David Garlan, 2002</li><li><a href="https://github.com/P3-model/P3-model/">P3 Model</a>, strona projektu Marcina i Łukasza Szydło na GitHubie, na ten moment informacyjnie o projekcie</li><li><a href="https://slides.com/technites_pl/living-documentation">Dokumentacja, która sama się pisze</a>, prezentacja Marcina z Boiling Frogs i 4Developers 2023</li><li><a href="https://twitter.com/technites_pl">marcin@twitter</a>, profil Marcina na Twitterze</li></ul><p>Zapraszam!</p>
]]></content:encoded>
      <enclosure length="67566264" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/478679db-1439-4127-8954-632685f708a8/audio/9c5fc252-9169-4aed-8f3b-5c9e97fda557/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>60. O technikach Living Documentation i modelu P3 z Marcinem Markowskim</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>01:10:20</itunes:duration>
      <itunes:summary>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.</itunes:summary>
      <itunes:subtitle>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.</itunes:subtitle>
      <itunes:keywords>model p3, domain-driven design, bounded context, dokumentacja, living documentation</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>60</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">291a7b82-e4cf-40be-8dab-f889e543a3d7</guid>
      <title>59. O optymalizacji współpracy zespołów i Team Topologies z Piotrem Kacałą</title>
      <description><![CDATA[<p>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.</p><p>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...</p><p>W tym odcinku rozmawiamy m.in. o:</p><ul><li>o tym, co tworzy dobry zespół,</li><li>idei Team Topologies,</li><li>modelach współpracy pomiędzy zespołami i rolami samych zespołów,</li><li>realiach zespołowych przy rozwoju projektu Displate.</li></ul><p>Materiały dodatkowe:</p><ul><li><a href="https://www.goodreads.com/book/show/44135420-team-topologies">Team Topologies</a>, książka autorstwa Manuela Paisa i Matthew Skeltona, 2019</li><li><a href="https://www.goodreads.com/book/show/53481975-empowered?ac=1&from_search=true&qid=zPIWu0k54w&rank=1">Empowered: Ordinary People, Extraordinary Products</a>, Marty Cagan, Chris Jones, 2020</li><li><a href="https://www.product-blocks.com">Product Blocks</a>, rozwijany przez Piotra katalog "klocków", narzędzi i technich pomocnych przy zarządzaniu zespołami, który mocno polecam</li></ul>
]]></description>
      <pubDate>Mon, 1 May 2023 23:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/59-hmuErLnZ</link>
      <content:encoded><![CDATA[<p>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.</p><p>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...</p><p>W tym odcinku rozmawiamy m.in. o:</p><ul><li>o tym, co tworzy dobry zespół,</li><li>idei Team Topologies,</li><li>modelach współpracy pomiędzy zespołami i rolami samych zespołów,</li><li>realiach zespołowych przy rozwoju projektu Displate.</li></ul><p>Materiały dodatkowe:</p><ul><li><a href="https://www.goodreads.com/book/show/44135420-team-topologies">Team Topologies</a>, książka autorstwa Manuela Paisa i Matthew Skeltona, 2019</li><li><a href="https://www.goodreads.com/book/show/53481975-empowered?ac=1&from_search=true&qid=zPIWu0k54w&rank=1">Empowered: Ordinary People, Extraordinary Products</a>, Marty Cagan, Chris Jones, 2020</li><li><a href="https://www.product-blocks.com">Product Blocks</a>, rozwijany przez Piotra katalog "klocków", narzędzi i technich pomocnych przy zarządzaniu zespołami, który mocno polecam</li></ul>
]]></content:encoded>
      <enclosure length="60066971" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/19921e71-efdf-4dd9-92e4-10138d49c8f2/audio/69e39d68-afd4-43a3-9a4b-a3f1eee0a125/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>59. O optymalizacji współpracy zespołów i Team Topologies z Piotrem Kacałą</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>01:02:30</itunes:duration>
      <itunes:summary>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.</itunes:summary>
      <itunes:subtitle>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.</itunes:subtitle>
      <itunes:keywords>manuel pais, team topologies, współpraca, software development, matthew skelton, zespoły produktowe</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>59</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">4ec89037-b484-4513-a7c8-e2f19f147e42</guid>
      <title>58. O testowaniu kontraktowym z Rafałem Maciakiem</title>
      <description><![CDATA[<p>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... </p><p>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.</p><p>W tym odcinku rozmawiamy m.in. o:</p><ul><li>idei testowania kontraktowego,</li><li>przykładowej budowie kontraktów,</li><li>lokalizacji tego rodzaju weryfikacji w piramidzie testów,</li><li>narzędziach wspierających testowanie kontraktowe,</li><li>różnicach pomiędzy Consumer Driven Contract i Producer Driven Contract,</li></ul><p>Materiały dodatkowe:</p><ul><li><a href="https://softwaremill.com/contract-testing-spring-cloud-contract/">Contract Testing - Spring Cloud Contract</a>, artykuł Rafała na blogu SoftwareMill przedstawiający praktyczną stronę testowania kontraktowego z użyciem Springa,</li><li><a href="https://www.youtube.com/watch?v=vUAk3FoFPTQ">Save your friday's evening with Contract Testing</a>, prezentacja Rafała z Allegro Tech Meetings</li><li><a href="https://spring.io/blog/2018/02/13/spring-cloud-contract-in-a-polyglot-world">Spring Cloud Contract in a polyglot world</a>, artykuł Marcina Grzejszczaka na blogu Spring, pokazujący praktyczne użycie SCC,</li><li><a href="https://docs.pact.io/getting_started/how_pact_works">How Pact Works</a>, krótkie wprowadzenie do zasady działania jednego ze wspomnianych w odcinku narzędzi</li><li><a href="https://docs.pact.io/pact_broker/can_i_deploy">Can I Deploy</a>, jedno z narzędzi wchodzących w skład Pacta, wspomagające proces wdrożenia systemu</li><li><a href="https://www.youtube.com/playlist?list=PLwy9Bnco-IpfZ72VQ7hce8GicVZs7nm0i">Introducing Contact Testing with PactFlow</a>, playlista kilku ciekawych filmów przedstawiających użycie Pacta w omawianym w odcinku kontekście</li></ul><p>Zapraszam Cię także do odwiedzenia moich innych miejsc w internecie:</p><ul><li><a href="https://twitter.com/mariuszgil">https://twitter.com/mariuszgil</a></li><li><a href="https://www.instagram.com/mariuszgil_dev/">https://instagram.com/mariuszgil_dev/</a></li><li><a href="https://youtube.com/c/MariuszGil">https://youtube.com/c/MariuszGil</a></li></ul>
]]></description>
      <pubDate>Mon, 17 Apr 2023 23:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/58-PSUiuWO4</link>
      <content:encoded><![CDATA[<p>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... </p><p>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.</p><p>W tym odcinku rozmawiamy m.in. o:</p><ul><li>idei testowania kontraktowego,</li><li>przykładowej budowie kontraktów,</li><li>lokalizacji tego rodzaju weryfikacji w piramidzie testów,</li><li>narzędziach wspierających testowanie kontraktowe,</li><li>różnicach pomiędzy Consumer Driven Contract i Producer Driven Contract,</li></ul><p>Materiały dodatkowe:</p><ul><li><a href="https://softwaremill.com/contract-testing-spring-cloud-contract/">Contract Testing - Spring Cloud Contract</a>, artykuł Rafała na blogu SoftwareMill przedstawiający praktyczną stronę testowania kontraktowego z użyciem Springa,</li><li><a href="https://www.youtube.com/watch?v=vUAk3FoFPTQ">Save your friday's evening with Contract Testing</a>, prezentacja Rafała z Allegro Tech Meetings</li><li><a href="https://spring.io/blog/2018/02/13/spring-cloud-contract-in-a-polyglot-world">Spring Cloud Contract in a polyglot world</a>, artykuł Marcina Grzejszczaka na blogu Spring, pokazujący praktyczne użycie SCC,</li><li><a href="https://docs.pact.io/getting_started/how_pact_works">How Pact Works</a>, krótkie wprowadzenie do zasady działania jednego ze wspomnianych w odcinku narzędzi</li><li><a href="https://docs.pact.io/pact_broker/can_i_deploy">Can I Deploy</a>, jedno z narzędzi wchodzących w skład Pacta, wspomagające proces wdrożenia systemu</li><li><a href="https://www.youtube.com/playlist?list=PLwy9Bnco-IpfZ72VQ7hce8GicVZs7nm0i">Introducing Contact Testing with PactFlow</a>, playlista kilku ciekawych filmów przedstawiających użycie Pacta w omawianym w odcinku kontekście</li></ul><p>Zapraszam Cię także do odwiedzenia moich innych miejsc w internecie:</p><ul><li><a href="https://twitter.com/mariuszgil">https://twitter.com/mariuszgil</a></li><li><a href="https://www.instagram.com/mariuszgil_dev/">https://instagram.com/mariuszgil_dev/</a></li><li><a href="https://youtube.com/c/MariuszGil">https://youtube.com/c/MariuszGil</a></li></ul>
]]></content:encoded>
      <enclosure length="55721833" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/e37864e4-ba88-4f93-8867-a47227e66be8/audio/8212b6b0-a1ca-4186-b0ed-9b1b9461ad26/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>58. O testowaniu kontraktowym z Rafałem Maciakiem</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>00:58:00</itunes:duration>
      <itunes:summary>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...</itunes:summary>
      <itunes:subtitle>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...</itunes:subtitle>
      <itunes:keywords>consumer driven contract, contract testing, testowanie kontraktowe, producer driven contract, pact, spring cloud contract</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>58</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">c234d56b-d4f7-4889-b5e9-0ff62f320d93</guid>
      <title>57. O faktach i mitach wzorca CQRS z Oskarem Dudyczem</title>
      <description><![CDATA[<p>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.</p><p>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...</p><p>W tym odcinku rozmawiamy m.in. na temat:</p><ul><li>czym jest wzorzec CQRS i jaki ma związek z językiem Eiffel i ideą CQS Bertranda Meyera,</li><li>związku z wzorcem Command & Command Handler,x</li><li>szeregu mitów, którymi CQRS obrósł na przestrzeni lat, np. koniecznością stosowania asynchroniczności,</li><li>różnych możliwych sposobach, w jaki CQRS może zostać zaimplementowany w systemie.</li></ul><p>Materiały dodatkowe:</p><ul><li><a href="https://cqrs.files.wordpress.com/2010/11/cqrs_documents.pdf">CQRS</a>, oryginalny dokument Grega Younga, opisujący koncept CQRS</li><li><a href="https://martinfowler.com/bliki/CQRS.html">CQRS Bliki</a>, artykuł na bliki Martina Fowlera o omawianym wzorcu</li><li><a href="https://event-driven.io/en/cqrs_facts_and_myths_explained/">CQRS facts and myths explained</a>, artykuł na blogu Oskara na poruszony w rozmowie temat</li><li><a href="https://www.youtube.com/watch?v=jU5aKVQmBeM">Od CRUD do CQRS w praktyce</a>, prezentacja Oskara z konferencji bITconf 2022</li></ul><p>Zapraszam Cię także do odwiedzenia moich innych miejsc w internecie:</p><ul><li><a href="https://twitter.com/mariuszgil">https://twitter.com/mariuszgil</a></li><li><a href="https://www.instagram.com/mariuszgil_dev/">https://instagram.com/mariuszgil_dev/</a></li><li><a href="https://youtube.com/c/MariuszGil">https://youtube.com/c/MariuszGil</a></li></ul>
]]></description>
      <pubDate>Mon, 10 Apr 2023 23:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/57-E6_fsXtM</link>
      <content:encoded><![CDATA[<p>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.</p><p>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...</p><p>W tym odcinku rozmawiamy m.in. na temat:</p><ul><li>czym jest wzorzec CQRS i jaki ma związek z językiem Eiffel i ideą CQS Bertranda Meyera,</li><li>związku z wzorcem Command & Command Handler,x</li><li>szeregu mitów, którymi CQRS obrósł na przestrzeni lat, np. koniecznością stosowania asynchroniczności,</li><li>różnych możliwych sposobach, w jaki CQRS może zostać zaimplementowany w systemie.</li></ul><p>Materiały dodatkowe:</p><ul><li><a href="https://cqrs.files.wordpress.com/2010/11/cqrs_documents.pdf">CQRS</a>, oryginalny dokument Grega Younga, opisujący koncept CQRS</li><li><a href="https://martinfowler.com/bliki/CQRS.html">CQRS Bliki</a>, artykuł na bliki Martina Fowlera o omawianym wzorcu</li><li><a href="https://event-driven.io/en/cqrs_facts_and_myths_explained/">CQRS facts and myths explained</a>, artykuł na blogu Oskara na poruszony w rozmowie temat</li><li><a href="https://www.youtube.com/watch?v=jU5aKVQmBeM">Od CRUD do CQRS w praktyce</a>, prezentacja Oskara z konferencji bITconf 2022</li></ul><p>Zapraszam Cię także do odwiedzenia moich innych miejsc w internecie:</p><ul><li><a href="https://twitter.com/mariuszgil">https://twitter.com/mariuszgil</a></li><li><a href="https://www.instagram.com/mariuszgil_dev/">https://instagram.com/mariuszgil_dev/</a></li><li><a href="https://youtube.com/c/MariuszGil">https://youtube.com/c/MariuszGil</a></li></ul>
]]></content:encoded>
      <enclosure length="54724926" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/a7662336-bc7b-4301-a64c-6b382f8ece3a/audio/b0bf419a-eeb6-4f70-8d8c-d0aa98411894/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>57. O faktach i mitach wzorca CQRS z Oskarem Dudyczem</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>00:56:57</itunes:duration>
      <itunes:summary>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 CQRS obrósł kilkoma mitami.</itunes:summary>
      <itunes:subtitle>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 CQRS obrósł kilkoma mitami.</itunes:subtitle>
      <itunes:keywords>architecture, command query responsibilities segregation, cqs, command query separation, cqrs, greg young</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>57</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">1c85cf36-7ceb-4d3c-8908-dcda29f5d6f8</guid>
      <title>56. O fuckupach w projektach IT z Jarkiem Pałką i Wojtkiem Ptakiem</title>
      <description><![CDATA[<p>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.</p><p>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.</p><p>W tym odcinku rozmawiamy m.in. o:</p><ul><li>naszych błędach i wyciągniętych wnioskach,</li><li>różnych źródłach problemów i ich typach, od błędów ludzkich po limity infrastrukturalne,</li><li>mierzeniu rzeczy, by określić wpływ fuckupu na otaczający nas świat,</li><li>przygotowywaniu się na incydenty, bo to nie kwestia czy wystąpią, tylko kiedy,</li><li>jakie działania podejmować w trakcie problemu,</li><li>kulturze postmortems, lessons-learned i upewnianiu się, że wnioski,</li><li>jak i kiedy komunikować o problemach,</li><li>co zrobić, gdy fala sztormu odpłynie w dal...</li></ul><p>Będę bardzo zobowiązany za wypełnienie <a href="https://forms.gle/HxCSFD66v2QZCmC96">krótkiej ankiety</a> na temat tego odcinka.</p><p>Materiały dodatkowe:</p><ul><li><a href="https://www.goodreads.com/book/show/54259.Death_March">Death March</a> - Edward Yourdon</li><li><a href="https://www.goodreads.com/book/show/17255186-the-phoenix-project">The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win</a> - Gene Kim, Kevin Behr, George Spafford</li><li><a href="https://www.goodreads.com/book/show/192408.Normal_Accidents">Normal Accidents: Living with High-Risk Technologies</a> - Charles Perrow</li><li><a href="https://podcasts.apple.com/pl/podcast/the-sociology-and-typologies-of/id1511804968?i=1000520429617&l=pl">The Idealcast with Gene Kim by IT Revolution</a> - rozmowa z dr. Ronem Westrumem m.in. na tematy związane z problemami w złożonych systemach (od 34:45)</li><li><a href="https://medium.com/@sonnydewfall/the-facebook-outage-a-postmortem-ac60428a16cb">The Facebook Outage</a> - postmortem problemu Facebooka</li><li><a href="https://www.projectmanager.com/blog/root-cause-analysis-guide">Root Cause Analysis: A Quick Guide</a> - opracowanie na temat wspomnianego w odcinku RCA</li><li><a href="https://www.cio.com/article/286790/software-testing-lessons-learned-from-knight-capital-fiasco.html">Software Testing Lessons Learned From Knight Capital Fiasco</a> - analiza przypadku Knight Capital i utraty ponad 400M USD</li></ul>
]]></description>
      <pubDate>Mon, 3 Apr 2023 23:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/56-U82nROeJ</link>
      <content:encoded><![CDATA[<p>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.</p><p>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.</p><p>W tym odcinku rozmawiamy m.in. o:</p><ul><li>naszych błędach i wyciągniętych wnioskach,</li><li>różnych źródłach problemów i ich typach, od błędów ludzkich po limity infrastrukturalne,</li><li>mierzeniu rzeczy, by określić wpływ fuckupu na otaczający nas świat,</li><li>przygotowywaniu się na incydenty, bo to nie kwestia czy wystąpią, tylko kiedy,</li><li>jakie działania podejmować w trakcie problemu,</li><li>kulturze postmortems, lessons-learned i upewnianiu się, że wnioski,</li><li>jak i kiedy komunikować o problemach,</li><li>co zrobić, gdy fala sztormu odpłynie w dal...</li></ul><p>Będę bardzo zobowiązany za wypełnienie <a href="https://forms.gle/HxCSFD66v2QZCmC96">krótkiej ankiety</a> na temat tego odcinka.</p><p>Materiały dodatkowe:</p><ul><li><a href="https://www.goodreads.com/book/show/54259.Death_March">Death March</a> - Edward Yourdon</li><li><a href="https://www.goodreads.com/book/show/17255186-the-phoenix-project">The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win</a> - Gene Kim, Kevin Behr, George Spafford</li><li><a href="https://www.goodreads.com/book/show/192408.Normal_Accidents">Normal Accidents: Living with High-Risk Technologies</a> - Charles Perrow</li><li><a href="https://podcasts.apple.com/pl/podcast/the-sociology-and-typologies-of/id1511804968?i=1000520429617&l=pl">The Idealcast with Gene Kim by IT Revolution</a> - rozmowa z dr. Ronem Westrumem m.in. na tematy związane z problemami w złożonych systemach (od 34:45)</li><li><a href="https://medium.com/@sonnydewfall/the-facebook-outage-a-postmortem-ac60428a16cb">The Facebook Outage</a> - postmortem problemu Facebooka</li><li><a href="https://www.projectmanager.com/blog/root-cause-analysis-guide">Root Cause Analysis: A Quick Guide</a> - opracowanie na temat wspomnianego w odcinku RCA</li><li><a href="https://www.cio.com/article/286790/software-testing-lessons-learned-from-knight-capital-fiasco.html">Software Testing Lessons Learned From Knight Capital Fiasco</a> - analiza przypadku Knight Capital i utraty ponad 400M USD</li></ul>
]]></content:encoded>
      <enclosure length="156466154" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/6aba72cc-ec2f-4cdb-af22-db7285b84701/audio/b909544d-417c-4e83-af81-604d30379aca/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>56. O fuckupach w projektach IT z Jarkiem Pałką i Wojtkiem Ptakiem</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>02:42:50</itunes:duration>
      <itunes:summary>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.</itunes:summary>
      <itunes:subtitle>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.</itunes:subtitle>
      <itunes:keywords>devops, failure, problem, root cause analysis, fuck-up, postmortem, design for failure</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>56</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">b34557bc-8de3-45a3-91b3-41f3ad67cfa4</guid>
      <title>55. O Machine-Learningu i rozwiązaniach Data-Driven dla bankowości z Piotrem Gawrysiakiem</title>
      <description><![CDATA[<p>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.</p><p>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.</p><p>W tym odcinku rozmawiamy m.in. o:</p><ul><li>projektach opartych w ML/AI w banku,</li><li>rodzajach problemów możliwych do rozwiązania z użyciem Machine Learningu,</li><li>procesie tworzenia rozwiązań data-driven,</li><li>wykorzystywanych technologiach i potrzebnych umiejętnościach w kwestii data-science,</li><li>późniejszym wdrażaniu przygotowanych modeli i podejścia do dzielenia się danymi,</li><li>process miningu i automatycznej analizy procesów,</li><li>wpływie modeli typu ChatGPT-3 na pracę developerów.</li></ul><p>Zapraszam na odcinek!</p><p>Materiały dodatkowe</p><ul><li><a href="https://www.itwmbanku.pl/experts/">IT w mBanku</a>, więcej rozmów z ekspertami i tematy dookoła software-house'u IT</li><li><a href="https://www.andrewng.org/courses/">Kursy Andrew NG</a>, kilka kursów od Andrew NG w specjalizacjach Machine Learning, MLOps i Deep Learning</li><li><a href="https://www.meetup.com/process-mining-warsaw/">Process Mining Warsaw</a>, grupa meetupowa poświęcona tematyce optymalizacji procesów z użyciem Proces Miningu</li><li><a href="https://pm4py.fit.fraunhofer.de">Biblioteka pm4py</a>, implementacja algorytmów Process Mining w Pythonie</li></ul><p>Odcinek powstał we współpracy z mBankiem.</p>
]]></description>
      <pubDate>Tue, 21 Mar 2023 00:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/55-pH6_vQd_</link>
      <content:encoded><![CDATA[<p>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.</p><p>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.</p><p>W tym odcinku rozmawiamy m.in. o:</p><ul><li>projektach opartych w ML/AI w banku,</li><li>rodzajach problemów możliwych do rozwiązania z użyciem Machine Learningu,</li><li>procesie tworzenia rozwiązań data-driven,</li><li>wykorzystywanych technologiach i potrzebnych umiejętnościach w kwestii data-science,</li><li>późniejszym wdrażaniu przygotowanych modeli i podejścia do dzielenia się danymi,</li><li>process miningu i automatycznej analizy procesów,</li><li>wpływie modeli typu ChatGPT-3 na pracę developerów.</li></ul><p>Zapraszam na odcinek!</p><p>Materiały dodatkowe</p><ul><li><a href="https://www.itwmbanku.pl/experts/">IT w mBanku</a>, więcej rozmów z ekspertami i tematy dookoła software-house'u IT</li><li><a href="https://www.andrewng.org/courses/">Kursy Andrew NG</a>, kilka kursów od Andrew NG w specjalizacjach Machine Learning, MLOps i Deep Learning</li><li><a href="https://www.meetup.com/process-mining-warsaw/">Process Mining Warsaw</a>, grupa meetupowa poświęcona tematyce optymalizacji procesów z użyciem Proces Miningu</li><li><a href="https://pm4py.fit.fraunhofer.de">Biblioteka pm4py</a>, implementacja algorytmów Process Mining w Pythonie</li></ul><p>Odcinek powstał we współpracy z mBankiem.</p>
]]></content:encoded>
      <enclosure length="68270260" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/3a510de2-a55e-4518-8f9e-2f9baeb5c41d/audio/19beab1e-2fde-47b9-9dd1-b966aeda9ab8/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>55. O Machine-Learningu i rozwiązaniach Data-Driven dla bankowości z Piotrem Gawrysiakiem</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>01:11:04</itunes:duration>
      <itunes:summary>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.</itunes:summary>
      <itunes:subtitle>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.</itunes:subtitle>
      <itunes:keywords>sztuczna inteligencja, process mining, data-sience, machine-learning, artificial intelligence, ml, data-driven, uczenie maszynowe</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>55</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">4225437f-3cf0-474b-94d4-a10fadee8a1d</guid>
      <title>54. O stosowaniu SCRUMa z Kubą Szczepanikiem i Jackiem Wieczorkiem</title>
      <description><![CDATA[<p>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.</p><p>W tym odcinku rozmawiamy m.in. na temat:</p><ul><li>SCRUM Guide i jego stosowania w praktyce,</li><li>codziennych porannych teatrzykach,</li><li>wybierania ze SCRUM-a tylko jego elementów, czyli o tzw. SCRUM-Butach</li><li>zastępowania go znacznie lepszymi i bardziej dopasowanymi technikami,</li><li>kulturze organizacji i SCRUM Masterach,</li><li>przypadkach, gdzie te metoda ma sens i gdzie go zupełnie nie ma...</li></ul><p>Zapraszam!</p><p>Materiały dodatkowe:</p><ul><li><a href="https://porzadnyagile.pl">PorządnyAgile.pl</a>, podcast Kuby i Jacka na tematy związane z podejściami zwinnymi</li><li><a href="https://porzadnyagile.pl/068-kiedy-scrum-nie-jest-odpowiedzia/">Kiedy SCRUM nie jest odpowiedzią</a>, #68 odcinek podcastu Porządny Agile rozwijający wątek o niedopasowaniu SCRUM-a do danej sytuacji</li><li><a href="https://labiryntyscruma.pl">Labirynty SCRUM-a</a>, książka autorstwa Jacka Wieczorka</li><li><a href="https://agile247.pl">Agile247.pl</a>, sporo właściwej wiedzy o Agile'u, można tu znaleźć wiele artykułów obu gości</li></ul><p>Zapraszam Cię także do odwiedzenia moich innych miejsc w internecie:</p><ul><li><a href="https://twitter.com/mariuszgil">https://twitter.com/mariuszgil</a></li><li><a href="https://www.instagram.com/mariuszgil_dev/">https://instagram.com/mariuszgil_dev/</a></li><li><a href="https://youtube.com/c/MariuszGil">https://youtube.com/c/MariuszGil</a></li></ul>
]]></description>
      <pubDate>Tue, 7 Mar 2023 00:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/54-SwmJq0ce</link>
      <content:encoded><![CDATA[<p>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.</p><p>W tym odcinku rozmawiamy m.in. na temat:</p><ul><li>SCRUM Guide i jego stosowania w praktyce,</li><li>codziennych porannych teatrzykach,</li><li>wybierania ze SCRUM-a tylko jego elementów, czyli o tzw. SCRUM-Butach</li><li>zastępowania go znacznie lepszymi i bardziej dopasowanymi technikami,</li><li>kulturze organizacji i SCRUM Masterach,</li><li>przypadkach, gdzie te metoda ma sens i gdzie go zupełnie nie ma...</li></ul><p>Zapraszam!</p><p>Materiały dodatkowe:</p><ul><li><a href="https://porzadnyagile.pl">PorządnyAgile.pl</a>, podcast Kuby i Jacka na tematy związane z podejściami zwinnymi</li><li><a href="https://porzadnyagile.pl/068-kiedy-scrum-nie-jest-odpowiedzia/">Kiedy SCRUM nie jest odpowiedzią</a>, #68 odcinek podcastu Porządny Agile rozwijający wątek o niedopasowaniu SCRUM-a do danej sytuacji</li><li><a href="https://labiryntyscruma.pl">Labirynty SCRUM-a</a>, książka autorstwa Jacka Wieczorka</li><li><a href="https://agile247.pl">Agile247.pl</a>, sporo właściwej wiedzy o Agile'u, można tu znaleźć wiele artykułów obu gości</li></ul><p>Zapraszam Cię także do odwiedzenia moich innych miejsc w internecie:</p><ul><li><a href="https://twitter.com/mariuszgil">https://twitter.com/mariuszgil</a></li><li><a href="https://www.instagram.com/mariuszgil_dev/">https://instagram.com/mariuszgil_dev/</a></li><li><a href="https://youtube.com/c/MariuszGil">https://youtube.com/c/MariuszGil</a></li></ul>
]]></content:encoded>
      <enclosure length="61763136" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/73aa6566-be03-464c-884b-e81ed6621b01/audio/7aea92f2-7afc-4138-86df-97101b8ed754/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>54. O stosowaniu SCRUMa z Kubą Szczepanikiem i Jackiem Wieczorkiem</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>01:04:17</itunes:duration>
      <itunes:summary>Wiele tematów potrafi podnieść temperaturę rozmowy, zaczynając choćby od osławionego pytania &quot;taby czy spacje&quot;. Ale kiedy skręcamy w rejony związane z Agile i pada słowo SCRUM, konwersacja często przechodzi na zupełnie nowy wymiar. </itunes:summary>
      <itunes:subtitle>Wiele tematów potrafi podnieść temperaturę rozmowy, zaczynając choćby od osławionego pytania &quot;taby czy spacje&quot;. Ale kiedy skręcamy w rejony związane z Agile i pada słowo SCRUM, konwersacja często przechodzi na zupełnie nowy wymiar. </itunes:subtitle>
      <itunes:keywords>scrum master, scrum, agile, zwinność, zespół, kanban, lean, scrum guide</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>54</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">7c1889b2-3ab0-42b9-8eed-328208748ec4</guid>
      <title>53. O zaletach i wadach Clean Architecture z Oskarem Dudyczem</title>
      <description><![CDATA[<p>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.</p><p>W tym odcinku rozmawiamy m.in. o:</p><ul><li>czym jest Clean Architecture i skąd wywodzi się ta idea?</li><li>stosowaniu zasad SOLID na poziomie architektury całego systemu,</li><li>proponowanych w Clean Architecture zasadach i warstwach,</li><li>zaletach i wadach tego rozwiązania,</li><li>pewnych podobieństwach i różnicach w odniesieniu do np. Hexagonal Architecture,</li><li>stosowaniu tego rodzaju architektury w kontekście projektu i zespołu.</li></ul><p>Zapraszam!</p><p>Materiały dodatkowe:</p><ul><li><a href="https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html">The Clean Architecture</a> - wpis na blogu Roberta C. Martina (Uncle Boba), który można także znaleźć w jednym z rozdziałów książki Clean Architecture</li><li><a href="https://www.goodreads.com/book/show/18043011-clean-architecture">Clean Architecture</a> - książka autorstwa Roberta C. Martina, 2017, wydawnictwo Pearson</li><li><a href="https://jeremydmiller.com/2022/08/10/putting-solid-into-perspective/">Putting SOLID into Perspective</a> - artykuł Jeremiego Millera o stosowaniu zasad SOLID w kontekście projektowania i rozwoju architektury</li></ul><p>Powiązane z tematem artykuły na blogu Oskara:</p><ul><li><a href="https://event-driven.io/en/onion_clean_code/">What onion has to do with Clean Code?</a></li><li><a href="https://event-driven.io/en/generic_does_not_mean_simple/">Generic does not mean Simple</a></li><li><a href="https://event-driven.io/en/how_to_slice_the_codebase_effectively/">How to slice the codebase effectively?</a></li></ul>
]]></description>
      <pubDate>Tue, 21 Feb 2023 00:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/53-1u7JxEmc</link>
      <content:encoded><![CDATA[<p>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.</p><p>W tym odcinku rozmawiamy m.in. o:</p><ul><li>czym jest Clean Architecture i skąd wywodzi się ta idea?</li><li>stosowaniu zasad SOLID na poziomie architektury całego systemu,</li><li>proponowanych w Clean Architecture zasadach i warstwach,</li><li>zaletach i wadach tego rozwiązania,</li><li>pewnych podobieństwach i różnicach w odniesieniu do np. Hexagonal Architecture,</li><li>stosowaniu tego rodzaju architektury w kontekście projektu i zespołu.</li></ul><p>Zapraszam!</p><p>Materiały dodatkowe:</p><ul><li><a href="https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html">The Clean Architecture</a> - wpis na blogu Roberta C. Martina (Uncle Boba), który można także znaleźć w jednym z rozdziałów książki Clean Architecture</li><li><a href="https://www.goodreads.com/book/show/18043011-clean-architecture">Clean Architecture</a> - książka autorstwa Roberta C. Martina, 2017, wydawnictwo Pearson</li><li><a href="https://jeremydmiller.com/2022/08/10/putting-solid-into-perspective/">Putting SOLID into Perspective</a> - artykuł Jeremiego Millera o stosowaniu zasad SOLID w kontekście projektowania i rozwoju architektury</li></ul><p>Powiązane z tematem artykuły na blogu Oskara:</p><ul><li><a href="https://event-driven.io/en/onion_clean_code/">What onion has to do with Clean Code?</a></li><li><a href="https://event-driven.io/en/generic_does_not_mean_simple/">Generic does not mean Simple</a></li><li><a href="https://event-driven.io/en/how_to_slice_the_codebase_effectively/">How to slice the codebase effectively?</a></li></ul>
]]></content:encoded>
      <enclosure length="54646175" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/d7332986-d4a0-4f4d-9f1e-b33b24219a91/audio/36924e44-1313-4138-934c-46207d4bdab4/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>53. O zaletach i wadach Clean Architecture z Oskarem Dudyczem</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>00:56:51</itunes:duration>
      <itunes:summary>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.</itunes:summary>
      <itunes:subtitle>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.</itunes:subtitle>
      <itunes:keywords>architektura oprogramowania, software architecture, uncle bob, clean architecture</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>53</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">4e79fb30-34ea-4ac3-95a0-02d3ad50ada4</guid>
      <title>52. O uprawnieniach i domenie z Bartkiem Słotą</title>
      <description><![CDATA[<p>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.</p><p>Na konkretnym przykładzie przejdziemy proces analityczno-modelarski i rozważymy możliwe opcje, ich zalety i wady.</p><p> </p><p>Materiały dodatkowe:</p><p>Fragment EventStormingu, a także mapa kontekstów z przedstawionymi relacjami znajdują się na boardzie Miro: <a href="https://miro.com/app/board/uXjVPq0-LUM=/">https://miro.com/app/board/uXjVPq0-LUM=/</a></p><p>W odcinku pojawiają się narzędzia i herystyki modelowania, o których szerzej posłuchać można we wcześniejszych odcinkach podcastu:</p><ul><li><a href="https://bettersoftwaredesign.pl/episodes/43">BSD #43 O subdomenach biznesowych ze Sławkiem Sobótką</a></li><li><a href="https://bettersoftwaredesign.pl/episodes/37">BSD #37 O Context Mappingu z Bartkiem Słotą</a></li><li><a href="https://bettersoftwaredesign.pl/episodes/26">BSD #26 O perspektywach Being, Behaving, Becoming</a></li><li><a href="https://bettersoftwaredesign.pl/episodes/8">BSD #8 O Bounded Contextach ze Sławkiem Sobótka</a></li></ul>
]]></description>
      <pubDate>Tue, 7 Feb 2023 00:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/52-JN6OlBpc</link>
      <content:encoded><![CDATA[<p>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.</p><p>Na konkretnym przykładzie przejdziemy proces analityczno-modelarski i rozważymy możliwe opcje, ich zalety i wady.</p><p> </p><p>Materiały dodatkowe:</p><p>Fragment EventStormingu, a także mapa kontekstów z przedstawionymi relacjami znajdują się na boardzie Miro: <a href="https://miro.com/app/board/uXjVPq0-LUM=/">https://miro.com/app/board/uXjVPq0-LUM=/</a></p><p>W odcinku pojawiają się narzędzia i herystyki modelowania, o których szerzej posłuchać można we wcześniejszych odcinkach podcastu:</p><ul><li><a href="https://bettersoftwaredesign.pl/episodes/43">BSD #43 O subdomenach biznesowych ze Sławkiem Sobótką</a></li><li><a href="https://bettersoftwaredesign.pl/episodes/37">BSD #37 O Context Mappingu z Bartkiem Słotą</a></li><li><a href="https://bettersoftwaredesign.pl/episodes/26">BSD #26 O perspektywach Being, Behaving, Becoming</a></li><li><a href="https://bettersoftwaredesign.pl/episodes/8">BSD #8 O Bounded Contextach ze Sławkiem Sobótka</a></li></ul>
]]></content:encoded>
      <enclosure length="71183994" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/a93684e9-3d6e-4943-8313-e38730f32d18/audio/74aa0132-39e0-4798-99a2-cce7d4c42bac/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>52. O uprawnieniach i domenie z Bartkiem Słotą</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>01:14:06</itunes:duration>
      <itunes:summary>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.</itunes:summary>
      <itunes:subtitle>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.</itunes:subtitle>
      <itunes:keywords>domain-driven design, context mapping, autoryzacja, uwierzytelnianie, uprawnienia, kontrola uprawnień</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>52</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">adebf5ce-93e9-48e9-b76e-11e79a99a4b8</guid>
      <title>51. O semantyce i roli reguł biznesowych z Aleksandrem Bartnikiewiczem</title>
      <description><![CDATA[<p>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.</p><p>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.</p><p>W tym odcinku rozmawiamy z Aleksandrem m.in. o:</p><p>- czym są, a także czym nie są reguły biznesowe i jak się mają do procesów w domenie,<br />- odpowiednim wyrażaniu i semantyce reguł, aby poprawnie opisywały zasady działania biznesu,<br />- podejściu Evansa vs podejście Rossa do języka biznesowego,<br />- budowanie słowników i dokumentowaniu wiedzy na tem reguł biznesowych,<br />- stosowaniu rulebooka w większym projekcie i zespole.</p><p>Zapraszam!</p><p> </p><p>Na <a href="https://bartnikiewi.cz/">blogu Aleksandara</a> znaleźć można artykuł <a href="https://bartnikiewi.cz/2023/01/13/model-pojeciowy-diagram/">Model pojęciowy - Diagram</a>, który przedstawia wizualną stronę wspomnianego w odcinku przykładu.</p><p>Materiały dodatkowe:</p><ul><li><a href="https://www.businessrulesgroup.org/brmanifesto/BRManifestoPL.pdf">Manifest Reguł Biznesowych</a>, polska wersja manifestu Business Rules Group</li><li><a href="https://www.businessrulesgroup.org/brmanifesto.htm">The Business Rules Manifesto*</a>, angielska wersja 2.0 manifestu, listopad 2003</li><li><a href="https://www.goodreads.com/book/show/6803688-business-rule-concepts">Business Rule Concepts : Getting to the Point of Knowledge</a>, wspomniana książka Ronalda Rossa</li><li><a href="https://www.goodreads.com/book/show/51061094-business-knowledge-blueprints">Business Knowledge Blueprints: Enabling Your Data to Speak the Language of the Business</a>, kolejna warta uwagi pozycja Rossa</li></ul><p>Dla wytrwałych odnośnik do specyfikacji SBVR, <a href="https://www.omg.org/spec/SBVR/">Semantics Of Business Vocabulary And Business Rules</a>.</p>
]]></description>
      <pubDate>Tue, 24 Jan 2023 00:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/51-uZf8X0_h</link>
      <content:encoded><![CDATA[<p>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.</p><p>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.</p><p>W tym odcinku rozmawiamy z Aleksandrem m.in. o:</p><p>- czym są, a także czym nie są reguły biznesowe i jak się mają do procesów w domenie,<br />- odpowiednim wyrażaniu i semantyce reguł, aby poprawnie opisywały zasady działania biznesu,<br />- podejściu Evansa vs podejście Rossa do języka biznesowego,<br />- budowanie słowników i dokumentowaniu wiedzy na tem reguł biznesowych,<br />- stosowaniu rulebooka w większym projekcie i zespole.</p><p>Zapraszam!</p><p> </p><p>Na <a href="https://bartnikiewi.cz/">blogu Aleksandara</a> znaleźć można artykuł <a href="https://bartnikiewi.cz/2023/01/13/model-pojeciowy-diagram/">Model pojęciowy - Diagram</a>, który przedstawia wizualną stronę wspomnianego w odcinku przykładu.</p><p>Materiały dodatkowe:</p><ul><li><a href="https://www.businessrulesgroup.org/brmanifesto/BRManifestoPL.pdf">Manifest Reguł Biznesowych</a>, polska wersja manifestu Business Rules Group</li><li><a href="https://www.businessrulesgroup.org/brmanifesto.htm">The Business Rules Manifesto*</a>, angielska wersja 2.0 manifestu, listopad 2003</li><li><a href="https://www.goodreads.com/book/show/6803688-business-rule-concepts">Business Rule Concepts : Getting to the Point of Knowledge</a>, wspomniana książka Ronalda Rossa</li><li><a href="https://www.goodreads.com/book/show/51061094-business-knowledge-blueprints">Business Knowledge Blueprints: Enabling Your Data to Speak the Language of the Business</a>, kolejna warta uwagi pozycja Rossa</li></ul><p>Dla wytrwałych odnośnik do specyfikacji SBVR, <a href="https://www.omg.org/spec/SBVR/">Semantics Of Business Vocabulary And Business Rules</a>.</p>
]]></content:encoded>
      <enclosure length="79800769" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/e9f29f96-4769-42bc-b44b-6df7d155d3f9/audio/1c71d116-20a2-4426-8988-77d90f10c718/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>51. O semantyce i roli reguł biznesowych z Aleksandrem Bartnikiewiczem</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>01:23:02</itunes:duration>
      <itunes:summary>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 &quot;no jakieś tam reguły są w biznesie&quot;. Są traktowane trochę jak czarna magia, jak jakiś mityczny stwór. Trochę jak synonim &quot;logiki biznesowej&quot;. 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.</itunes:summary>
      <itunes:subtitle>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 &quot;no jakieś tam reguły są w biznesie&quot;. Są traktowane trochę jak czarna magia, jak jakiś mityczny stwór. Trochę jak synonim &quot;logiki biznesowej&quot;. 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.</itunes:subtitle>
      <itunes:keywords>ronald ross, business rules, business rules manifesto, reguły biznesowe, production rules</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>51</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">b5ade971-6566-4825-992c-2a4d600570e0</guid>
      <title>50. O implementacji logiki biznesowej z Decider Pattern z Oskarem Dudyczem</title>
      <description><![CDATA[<p>Materiały dodatkowe:</p><ul><li><a href="https://thinkbeforecoding.com/post/2021/12/17/functional-event-sourcing-decider">Functional Event Sourcing Decider</a>, źródłowy artykuł na blogu Jérémiego Chassaing na temat implementacji wzorca Decider</li><li><a href="https://www.youtube.com/watch?v=whFfzQfdJZg">Functional Event Sourcing</a>, nagranie prezentacji Jérémiego z DDD Europę 2020, niestety bez obrazu z laptopa</li><li><a href="https://event-driven.io/en/how_to_effectively_compose_your_business_logic/">How to effectively compose your business logic</a>, artykuł Oskara na temat kompozycji logiki z wzorcem Decider</li><li><a href="https://event-driven.io/en/how_events_can_help_on_making_state_based_approach_efficient/">How events can help in making the state-based approach efficient</a>, eventowe podejście do zmiany stanu systemu</li><li><a href="https://event-driven.io/en/writing_and_testing_business_logic_in_fsharp/">Writing and testing business logic in F#</a>, kolejny artykuł z bloga Oskara na temat użycia Decidera, tym razem w F#</li></ul>
]]></description>
      <pubDate>Tue, 10 Jan 2023 00:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/50-Zw2WiviC</link>
      <content:encoded><![CDATA[<p>Materiały dodatkowe:</p><ul><li><a href="https://thinkbeforecoding.com/post/2021/12/17/functional-event-sourcing-decider">Functional Event Sourcing Decider</a>, źródłowy artykuł na blogu Jérémiego Chassaing na temat implementacji wzorca Decider</li><li><a href="https://www.youtube.com/watch?v=whFfzQfdJZg">Functional Event Sourcing</a>, nagranie prezentacji Jérémiego z DDD Europę 2020, niestety bez obrazu z laptopa</li><li><a href="https://event-driven.io/en/how_to_effectively_compose_your_business_logic/">How to effectively compose your business logic</a>, artykuł Oskara na temat kompozycji logiki z wzorcem Decider</li><li><a href="https://event-driven.io/en/how_events_can_help_on_making_state_based_approach_efficient/">How events can help in making the state-based approach efficient</a>, eventowe podejście do zmiany stanu systemu</li><li><a href="https://event-driven.io/en/writing_and_testing_business_logic_in_fsharp/">Writing and testing business logic in F#</a>, kolejny artykuł z bloga Oskara na temat użycia Decidera, tym razem w F#</li></ul>
]]></content:encoded>
      <enclosure length="60160216" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/5750f28d-4e81-45fe-9d39-d7ff4d3d759d/audio/b0b4bf93-66c1-4a12-aac9-925e7adf4e4f/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>50. O implementacji logiki biznesowej z Decider Pattern z Oskarem Dudyczem</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>01:02:37</itunes:duration>
      <itunes:summary>&quot;Asking a question should not change the answer&quot; - w myśl tej idei Bertranda Meyera warto separować zapytania o zmianę stanu systemu od akcji ten stan zmieniających. A gdyby tę ideę zastosować przy implementacji np. agregatów i zacząć mocniej separować logikę biznesową od modyfikacji stanu? Z moim dzisiejszym gościem, Oskarem Dudyczem, przyglądamy się zaproponowanej przez Jérémiego Chassaing koncepcji tego rozdziału z użyciem wzorca Decider.

W tym odcinku rozmawiamy z Oskarem m.in. o:
- funkcyjnej genezie i idei Decider Pattern,
- rozdzielaniu decyzji o zmianie stanu od jego faktycznej zmiany,
- kompozycji logiki,
- aspektach implementacyjnych,
- potencjalnych problemach i korzyściach związanych ze stosowaniem Decider Pattern.</itunes:summary>
      <itunes:subtitle>&quot;Asking a question should not change the answer&quot; - w myśl tej idei Bertranda Meyera warto separować zapytania o zmianę stanu systemu od akcji ten stan zmieniających. A gdyby tę ideę zastosować przy implementacji np. agregatów i zacząć mocniej separować logikę biznesową od modyfikacji stanu? Z moim dzisiejszym gościem, Oskarem Dudyczem, przyglądamy się zaproponowanej przez Jérémiego Chassaing koncepcji tego rozdziału z użyciem wzorca Decider.

W tym odcinku rozmawiamy z Oskarem m.in. o:
- funkcyjnej genezie i idei Decider Pattern,
- rozdzielaniu decyzji o zmianie stanu od jego faktycznej zmiany,
- kompozycji logiki,
- aspektach implementacyjnych,
- potencjalnych problemach i korzyściach związanych ze stosowaniem Decider Pattern.</itunes:subtitle>
      <itunes:keywords>domain-driven design, aggregate, decider pattern, logika biznesowa, ddd, wzorce implementacyjne</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>50</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">fd216382-0d55-4805-abe6-c4741d354f5c</guid>
      <title>49. O przeprowadzeniu zmiany z Krzysztofem Rakowskim i Pawłem Rekowskim</title>
      <description><![CDATA[<p>Materiały dodatkowe:</p><ul><li><a href="https://www.kotterinc.com/methodology/8-steps/">8-krokowy process przeprowadzenia zmiany</a>, podsumowanie wspomnianego przez Krzysztofa frameworka Johna Kottera</li><li><a href="https://www.amazon.com/Technology-Strategy-Patterns-Architecture/dp/1492040878">Technology Strategy Patterns: Architecture as Strategy</a>, książka Ebena Hewitta</li><li><a href="https://nerd.management">Nerd Management</a>, video podcast Krzysztofa i Pawła na tematy związane z zarządzaniem zespołami IT</li></ul>
]]></description>
      <pubDate>Sun, 1 Jan 2023 05:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/49-j1E_VaLd</link>
      <content:encoded><![CDATA[<p>Materiały dodatkowe:</p><ul><li><a href="https://www.kotterinc.com/methodology/8-steps/">8-krokowy process przeprowadzenia zmiany</a>, podsumowanie wspomnianego przez Krzysztofa frameworka Johna Kottera</li><li><a href="https://www.amazon.com/Technology-Strategy-Patterns-Architecture/dp/1492040878">Technology Strategy Patterns: Architecture as Strategy</a>, książka Ebena Hewitta</li><li><a href="https://nerd.management">Nerd Management</a>, video podcast Krzysztofa i Pawła na tematy związane z zarządzaniem zespołami IT</li></ul>
]]></content:encoded>
      <enclosure length="52940106" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/037edbcb-605a-4bc5-8227-c6a6dc3307a2/audio/9e7983c8-2f51-4f74-9a1d-543903f5f4d8/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>49. O przeprowadzeniu zmiany z Krzysztofem Rakowskim i Pawłem Rekowskim</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>00:55:07</itunes:duration>
      <itunes:summary>Nowy Rok to idealny moment na to, aby na chwilę odejść od technologii i porozmawiać o zmianie. A właściwie o jej przeprowadzeniu w organizacji, bo chyba zbyt często się o to rozbijamy w projektach i zespołach... Krzysztof Rakowski i Paweł Rekowski, których być może znacie z podcastu Nerd Management, w dzisiejszej rozmowie dzielą się swoim doświadczeniem i sprawdzonym procesem dr Kottera. Jeśli w minionym roku nie udało Ci się zmienić czegoś w twoim projektowym otoczeniu, może znajdziesz tu inspirację... 

Zapraszam!</itunes:summary>
      <itunes:subtitle>Nowy Rok to idealny moment na to, aby na chwilę odejść od technologii i porozmawiać o zmianie. A właściwie o jej przeprowadzeniu w organizacji, bo chyba zbyt często się o to rozbijamy w projektach i zespołach... Krzysztof Rakowski i Paweł Rekowski, których być może znacie z podcastu Nerd Management, w dzisiejszej rozmowie dzielą się swoim doświadczeniem i sprawdzonym procesem dr Kottera. Jeśli w minionym roku nie udało Ci się zmienić czegoś w twoim projektowym otoczeniu, może znajdziesz tu inspirację... 

Zapraszam!</itunes:subtitle>
      <itunes:keywords>team</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>49</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">d2a4a932-ac7d-4711-876c-dd600abe68cf</guid>
      <title>48. O CUPID, alternatywie dla zasad SOLID z Piotrem Stawirejem</title>
      <description><![CDATA[<p>Materiały dodatkowe:</p><ul><li><a href="https://dannorth.net/2021/03/16/cupid-the-back-story/">CUPID - the back story</a>, pierwszy artykuł Dana Northa o kwestionowaniu zasad SOLID</li><li><a href="https://dannorth.net/2022/02/10/cupid-for-joyful-coding/">CUPID - for joyful coding</a>, kontynuacja tematu na blogu Dana Northa</li><li><a href="https://www.youtube.com/watch?v=KRLOCFDw5x4">CUPID - for joyful coding</a>, nagranie prezentacji z konferencji NDC London 2022</li><li><a href="https://www.goodreads.com/book/show/685486.Patterns_of_Software">Patterns of Software: Tales from the Software Community</a>, Richard P. Gabriel</li></ul>
]]></description>
      <pubDate>Tue, 27 Dec 2022 00:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/48-pByh21pG</link>
      <content:encoded><![CDATA[<p>Materiały dodatkowe:</p><ul><li><a href="https://dannorth.net/2021/03/16/cupid-the-back-story/">CUPID - the back story</a>, pierwszy artykuł Dana Northa o kwestionowaniu zasad SOLID</li><li><a href="https://dannorth.net/2022/02/10/cupid-for-joyful-coding/">CUPID - for joyful coding</a>, kontynuacja tematu na blogu Dana Northa</li><li><a href="https://www.youtube.com/watch?v=KRLOCFDw5x4">CUPID - for joyful coding</a>, nagranie prezentacji z konferencji NDC London 2022</li><li><a href="https://www.goodreads.com/book/show/685486.Patterns_of_Software">Patterns of Software: Tales from the Software Community</a>, Richard P. Gabriel</li></ul>
]]></content:encoded>
      <enclosure length="60670905" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/a18c560f-8b0b-4075-bbe8-325d78c2fc2e/audio/b176fd98-f75a-4bd8-964d-cf5d9a88820e/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>48. O CUPID, alternatywie dla zasad SOLID z Piotrem Stawirejem</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>01:03:09</itunes:duration>
      <itunes:summary>Zestaw zasad SOLID, wspomagający tworzenie łatwo rozwijalnego i utrzymywanego oprogramowania, jest znany w branży IT od lat. I także od lat mówi się o jego niedopasowaniu do obecnej rzeczywistości. Mój dzisiejszy gość i jednocześnie wielki zwolennik podejścia Clean Code i Software Craftsmanship, Piotr Stawirej, przedstawia propozycję zestawu zasad CUPID autorstwa Dana Northa, mający rozwiązującać bolączki SOLID-a.

W odcinku:
- jakie zasady/właściwości proponuje CUPID,
- jak można interpretować założenia Composable, Unix Philosophy, Predictable, Idiomatic i Domain-based,
- jak może wyglądać wdrażanie tych zasad w praktyce,
- jakie problemy rozwiązuje, a jakie wprowadza CUPID...

Zapraszam!</itunes:summary>
      <itunes:subtitle>Zestaw zasad SOLID, wspomagający tworzenie łatwo rozwijalnego i utrzymywanego oprogramowania, jest znany w branży IT od lat. I także od lat mówi się o jego niedopasowaniu do obecnej rzeczywistości. Mój dzisiejszy gość i jednocześnie wielki zwolennik podejścia Clean Code i Software Craftsmanship, Piotr Stawirej, przedstawia propozycję zestawu zasad CUPID autorstwa Dana Northa, mający rozwiązującać bolączki SOLID-a.

W odcinku:
- jakie zasady/właściwości proponuje CUPID,
- jak można interpretować założenia Composable, Unix Philosophy, Predictable, Idiomatic i Domain-based,
- jak może wyglądać wdrażanie tych zasad w praktyce,
- jakie problemy rozwiązuje, a jakie wprowadza CUPID...

Zapraszam!</itunes:subtitle>
      <itunes:keywords>software craftsmanship, cupid principles, software properties, solid principles, dan north</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>48</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">b3f07db7-cee9-40d6-91de-13af1f698f5f</guid>
      <title>47. O nauce DDD i bi-temporalnych eventach domenowych z Andrzejem Krzywdą</title>
      <description><![CDATA[<p>Materiały dodatkowe:</p><ul><li><a href="https://martinfowler.com/articles/bitemporal-history.html">Bitemporal History</a>, wpis na blogu Martina Fowlera na temat problemu modelowania bitemporalnego</li><li><a href="https://www.youtube.com/watch?v=xzekp1RuZbM">As Time Goes By…, a Bi-temporal Event Sourcing story</a>, prezentacja - Thomas Pierrain z konferencji DDD Europe 2018</li><li><a href="https://www.eventstore.com/blog/4-strategies-for-future-events-with-event-sourcing">4 Strategies for future events with Event Sourcing</a>, strategie rozwiązywania problemu "zdarzeń z przyszłości"</li><li><a href="https://verraes.net/2022/03/multi-temporal-events/">Eventsourcing Patterns: Multi-temporal Events</a>, wpis na blogu Mathiasa Verraesa na temat rozróżniania momentu rejestracji zdarzenia i zmiany przez niego opisywanej</li><li><a href="https://verraes.net/2019/05/patterns-for-decoupling-distsys-summary-event/">Patterns for Decoupling in Distributed Systems: Summary Event</a>, kolejny wpis Matthiasa na temat emisji pojedynczego eventu summary zamiast całego streamu zdarzeń</li></ul><p>Materiały od zespołu Arkency:</p><ul><li><a href="https://blog.arkency.com/fixing-the-past-and-dealing-with-the-future-using-bi-temporal-eventsourcing/">Fixing the past and dealing with the future using bi-temporal EventSourcing</a>, wpis Łukasza Reszke na blogu Arkency</li><li><a href="https://blog.arkency.com/take-advantage-of-turbo-streams-in-event-handlers/">Take advantage of Turbo Streams in event handlers</a>, wpis Piotra Jurewicza na temat aktualizacji read-modeli i UI aplikacji</li><li><a href="https://blog.arkency.com/speed-up-aggregate-roots-loading-with-snapshot-events/">Speed up aggregate roots loading with snapshot events</a>, wpis Piotra Jurewicza na temat odtwarzania stanu agregatu z użyciem snapshottingu</li><li><a href="https://github.com/RailsEventStore/ecommerce">RailsEventStore/ecommerce</a>, repozytorium z kodem poligonu doświadczalnego aplikacji ecommerce z użyciem RailsEventStore</li><li><a href="https://ecommerce.arkademy.dev">Demo ecommerce</a>, prosty interfejs www powyższej aplikacji</li></ul>
]]></description>
      <pubDate>Tue, 20 Dec 2022 00:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/47-JNddcMCM</link>
      <content:encoded><![CDATA[<p>Materiały dodatkowe:</p><ul><li><a href="https://martinfowler.com/articles/bitemporal-history.html">Bitemporal History</a>, wpis na blogu Martina Fowlera na temat problemu modelowania bitemporalnego</li><li><a href="https://www.youtube.com/watch?v=xzekp1RuZbM">As Time Goes By…, a Bi-temporal Event Sourcing story</a>, prezentacja - Thomas Pierrain z konferencji DDD Europe 2018</li><li><a href="https://www.eventstore.com/blog/4-strategies-for-future-events-with-event-sourcing">4 Strategies for future events with Event Sourcing</a>, strategie rozwiązywania problemu "zdarzeń z przyszłości"</li><li><a href="https://verraes.net/2022/03/multi-temporal-events/">Eventsourcing Patterns: Multi-temporal Events</a>, wpis na blogu Mathiasa Verraesa na temat rozróżniania momentu rejestracji zdarzenia i zmiany przez niego opisywanej</li><li><a href="https://verraes.net/2019/05/patterns-for-decoupling-distsys-summary-event/">Patterns for Decoupling in Distributed Systems: Summary Event</a>, kolejny wpis Matthiasa na temat emisji pojedynczego eventu summary zamiast całego streamu zdarzeń</li></ul><p>Materiały od zespołu Arkency:</p><ul><li><a href="https://blog.arkency.com/fixing-the-past-and-dealing-with-the-future-using-bi-temporal-eventsourcing/">Fixing the past and dealing with the future using bi-temporal EventSourcing</a>, wpis Łukasza Reszke na blogu Arkency</li><li><a href="https://blog.arkency.com/take-advantage-of-turbo-streams-in-event-handlers/">Take advantage of Turbo Streams in event handlers</a>, wpis Piotra Jurewicza na temat aktualizacji read-modeli i UI aplikacji</li><li><a href="https://blog.arkency.com/speed-up-aggregate-roots-loading-with-snapshot-events/">Speed up aggregate roots loading with snapshot events</a>, wpis Piotra Jurewicza na temat odtwarzania stanu agregatu z użyciem snapshottingu</li><li><a href="https://github.com/RailsEventStore/ecommerce">RailsEventStore/ecommerce</a>, repozytorium z kodem poligonu doświadczalnego aplikacji ecommerce z użyciem RailsEventStore</li><li><a href="https://ecommerce.arkademy.dev">Demo ecommerce</a>, prosty interfejs www powyższej aplikacji</li></ul>
]]></content:encoded>
      <enclosure length="58550617" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/45a923ac-7017-4786-82fc-19677f7842e4/audio/3b8075d8-c538-4139-b984-9d52518635a0/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>47. O nauce DDD i bi-temporalnych eventach domenowych z Andrzejem Krzywdą</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>01:00:57</itunes:duration>
      <itunes:summary>Po ponad 2 latach mam przyjemność ponownie gościć Andrzeja Krzywdę, jednak tym razem rozmawiamy na temat nauki Domain-Driven Design i sposobu testowania różnych nowych koncepcji programistycznych w Arkency. Jednym z implementowanych niedawno pomysłów były, wprowadzające dodatkowy wymiar czasowy, bi-temporalne eventy domenowe. 

W odcinku rozmawiamy z Andrzejem m.in. o:
- sposobie nauki DDD i nowych podejść w praktyce, 
- modelowaniu zdarzeń bi-temporalnych i możliwych innych podejściach,
- Hotwire, read-modelach i protokołach rozbieżności w zespole,
- stosowaniu snapshottingu przy odtwarzaniu stanu obiektu,
- wzorcu Event Summary.

Zapraszam! </itunes:summary>
      <itunes:subtitle>Po ponad 2 latach mam przyjemność ponownie gościć Andrzeja Krzywdę, jednak tym razem rozmawiamy na temat nauki Domain-Driven Design i sposobu testowania różnych nowych koncepcji programistycznych w Arkency. Jednym z implementowanych niedawno pomysłów były, wprowadzające dodatkowy wymiar czasowy, bi-temporalne eventy domenowe. 

W odcinku rozmawiamy z Andrzejem m.in. o:
- sposobie nauki DDD i nowych podejść w praktyce, 
- modelowaniu zdarzeń bi-temporalnych i możliwych innych podejściach,
- Hotwire, read-modelach i protokołach rozbieżności w zespole,
- stosowaniu snapshottingu przy odtwarzaniu stanu obiektu,
- wzorcu Event Summary.

Zapraszam! </itunes:subtitle>
      <itunes:keywords>events, domain-driven design, event-driven, snapshotting, aggregate, bitemporal event sourcing, temporal modeling, event sourcing, read models</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>47</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">2b378e4d-5f44-4906-aa13-413f6030e913</guid>
      <title>46. O testowaniu mutacyjnym z Marcinem Zajączkowskim</title>
      <description><![CDATA[<p>Materiały dodatkowe:</p><ul><li><a href="https://www.youtube.com/watch?v=lhvDp0_2MI4">Testowanie mutacyjne</a>, prezentacja Marcina na temat testowania mutacyjnego z konferencji Boiling Frogs 2016</li><li><a href="https://speakerdeck.com/szpak/mutation-testing-how-good-your-tests-really-are">Slajdy prezentacji</a></li><li><a href="https://solidsoft.wordpress.com/2017/09/19/how-fast-or-slow-mutation-testing-really-is/">Jak szybkie (lub wolne) jest testowanie mutacyjne?</a>, artykuł Marcina na temat szybkości testowania z mutantami, na przykładzie PIT i projektów FOSS</li><li><a href="https://blog.solidsoft.pl/">Blog Marcina</a></li><li><a href="https://twitter.com/SolidSoftBlog">Twitter Marcina</a></li></ul><p>Przykładowe narzędzia testowania mutacyjnego:</p><ul><li>Java, PIT - <a href="https://pitest.org/">https://pitest.org/</a></li><li>Java, Arcmutate - <a href="https://www.arcmutate.com/">https://www.arcmutate.com/</a></li><li>.NET, Stryker.NET - <a href="https://stryker-mutator.io/">https://stryker-mutator.io/</a></li><li>JavaScript, Stryker.JS - <a href="https://stryker-mutator.io/">https://stryker-mutator.io/</a></li><li>PHP, Infection - <a href="https://infection.github.io/guide/">https://infection.github.io/guide/</a></li><li>PHP 5.x (historycznie), Humbug - <a href="https://github.com/humbug/humbug">https://github.com/humbug/humbug</a></li><li>Ruby, Mutant - <a href="https://github.com/mbj/mutant">https://github.com/mbj/mutant</a></li><li>Python, Mutmut - <a href="https://mutmut.readthedocs.io/en/latest/">https://mutmut.readthedocs.io/en/latest/</a></li><li>Python, Mutatest - <a href="https://mutatest.readthedocs.io/en/latest/">https://mutatest.readthedocs.io/en/latest/</a></li><li>Python, Cosmic Ray - <a href="https://cosmic-ray.readthedocs.io/en/latest/">https://cosmic-ray.readthedocs.io/en/latest/</a></li></ul>
]]></description>
      <pubDate>Tue, 13 Dec 2022 00:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/46-poDhxNWL</link>
      <content:encoded><![CDATA[<p>Materiały dodatkowe:</p><ul><li><a href="https://www.youtube.com/watch?v=lhvDp0_2MI4">Testowanie mutacyjne</a>, prezentacja Marcina na temat testowania mutacyjnego z konferencji Boiling Frogs 2016</li><li><a href="https://speakerdeck.com/szpak/mutation-testing-how-good-your-tests-really-are">Slajdy prezentacji</a></li><li><a href="https://solidsoft.wordpress.com/2017/09/19/how-fast-or-slow-mutation-testing-really-is/">Jak szybkie (lub wolne) jest testowanie mutacyjne?</a>, artykuł Marcina na temat szybkości testowania z mutantami, na przykładzie PIT i projektów FOSS</li><li><a href="https://blog.solidsoft.pl/">Blog Marcina</a></li><li><a href="https://twitter.com/SolidSoftBlog">Twitter Marcina</a></li></ul><p>Przykładowe narzędzia testowania mutacyjnego:</p><ul><li>Java, PIT - <a href="https://pitest.org/">https://pitest.org/</a></li><li>Java, Arcmutate - <a href="https://www.arcmutate.com/">https://www.arcmutate.com/</a></li><li>.NET, Stryker.NET - <a href="https://stryker-mutator.io/">https://stryker-mutator.io/</a></li><li>JavaScript, Stryker.JS - <a href="https://stryker-mutator.io/">https://stryker-mutator.io/</a></li><li>PHP, Infection - <a href="https://infection.github.io/guide/">https://infection.github.io/guide/</a></li><li>PHP 5.x (historycznie), Humbug - <a href="https://github.com/humbug/humbug">https://github.com/humbug/humbug</a></li><li>Ruby, Mutant - <a href="https://github.com/mbj/mutant">https://github.com/mbj/mutant</a></li><li>Python, Mutmut - <a href="https://mutmut.readthedocs.io/en/latest/">https://mutmut.readthedocs.io/en/latest/</a></li><li>Python, Mutatest - <a href="https://mutatest.readthedocs.io/en/latest/">https://mutatest.readthedocs.io/en/latest/</a></li><li>Python, Cosmic Ray - <a href="https://cosmic-ray.readthedocs.io/en/latest/">https://cosmic-ray.readthedocs.io/en/latest/</a></li></ul>
]]></content:encoded>
      <enclosure length="58145910" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/9c174c9f-e88a-49ca-9321-08ccba12b067/audio/1a52d1b9-e2e5-4497-8384-06f2e7ac948d/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>46. O testowaniu mutacyjnym z Marcinem Zajączkowskim</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>01:00:32</itunes:duration>
      <itunes:summary>Testy zawsze powinny być obywatelami pierwszej kategorii w projekcie, a ich jakości powinniśmy poświęcać sporo uwagi. Z moim dzisiejszym gościem, Marcinem Zajączkowskim, rozmawiamy na temat automatycznego &quot;testowania&quot; testów i oceny ich jakości, czyli technice testowania mutacyjnego.

W tym odcinku m.in.:
- na czym polega testowanie mutacyjne,
- ogromnych korzyściach oferowanych przez to podejście,
- powodach, dla których tego rodzaju testowanie może być czasem trudne w praktyce,
- przykładowych sposobach mutacji kodu i odkrywanych przez nie problemach.

Zapraszam!</itunes:summary>
      <itunes:subtitle>Testy zawsze powinny być obywatelami pierwszej kategorii w projekcie, a ich jakości powinniśmy poświęcać sporo uwagi. Z moim dzisiejszym gościem, Marcinem Zajączkowskim, rozmawiamy na temat automatycznego &quot;testowania&quot; testów i oceny ich jakości, czyli technice testowania mutacyjnego.

W tym odcinku m.in.:
- na czym polega testowanie mutacyjne,
- ogromnych korzyściach oferowanych przez to podejście,
- powodach, dla których tego rodzaju testowanie może być czasem trudne w praktyce,
- przykładowych sposobach mutacji kodu i odkrywanych przez nie problemach.

Zapraszam!</itunes:subtitle>
      <itunes:keywords>software development, jakość testów, testowanie mutacyjne</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>46</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">2eb739a4-d23a-4b5a-a2d4-f9955fc77bdd</guid>
      <title>45. O testowalności oprogramowania z Kamilem Grzybkiem</title>
      <description><![CDATA[<p>Materiały dodatkowe:</p><ul><li><a href="https://www.goodreads.com/book/show/583766.An_Introduction_to_General_Systems_Thinking">An Introduction to General Systems Thinking </a>, książka Geralda M. Weinberga</li></ul>
]]></description>
      <pubDate>Tue, 29 Nov 2022 00:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/45-jENpl2mX</link>
      <content:encoded><![CDATA[<p>Materiały dodatkowe:</p><ul><li><a href="https://www.goodreads.com/book/show/583766.An_Introduction_to_General_Systems_Thinking">An Introduction to General Systems Thinking </a>, książka Geralda M. Weinberga</li></ul>
]]></content:encoded>
      <enclosure length="72209785" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/087f1818-3000-4ef3-9409-064b7fcd808e/audio/f48a2754-4177-45cf-a2df-eb0fe6172afa/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>45. O testowalności oprogramowania z Kamilem Grzybkiem</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>01:15:10</itunes:duration>
      <itunes:summary>Złożony system informatyczny może być postrzegany jako zbiór stanów ze zdefiniowanymi sposobami przejść pomiędzy nimi, gdzie testy weryfikują poprawność poszczególnych przejść stanowych. Taką definicję w dzisiejszym odcinku wprowadza Kamil Grzybek, z którym rozmawiamy o testowalności oprogramowania i związanych z nią zagadnieniach.

W tym odcinku wraz z Kamilem poruszamy m.in. tematy:
- kategoryzacji testów,
- testowalności systemu i czynnikach na nią wpływających,
- piramidzie testów i jej dopasowaniu w poszczególnych fragmentach projektu,
- pokrycia kodu testami na poszczególnych poziomach piramidy,
- trade-offach,
- betonowaniu systemu niewłaściwymi testami.

Zapraszam!</itunes:summary>
      <itunes:subtitle>Złożony system informatyczny może być postrzegany jako zbiór stanów ze zdefiniowanymi sposobami przejść pomiędzy nimi, gdzie testy weryfikują poprawność poszczególnych przejść stanowych. Taką definicję w dzisiejszym odcinku wprowadza Kamil Grzybek, z którym rozmawiamy o testowalności oprogramowania i związanych z nią zagadnieniach.

W tym odcinku wraz z Kamilem poruszamy m.in. tematy:
- kategoryzacji testów,
- testowalności systemu i czynnikach na nią wpływających,
- piramidzie testów i jej dopasowaniu w poszczególnych fragmentach projektu,
- pokrycia kodu testami na poszczególnych poziomach piramidy,
- trade-offach,
- betonowaniu systemu niewłaściwymi testami.

Zapraszam!</itunes:subtitle>
      <itunes:keywords>testy, software testability, testowalność oprogramowanie, testowanie jednostkowe</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>45</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">bf08287c-62ba-4727-884c-b7f94c11e1aa</guid>
      <title>44. O programowaniu reaktywnym z Tomkiem Nurkiewiczem</title>
      <description><![CDATA[<p>Materiały dodatkowe:</p><ul><li><a href="https://www.youtube.com/watch?v=5TJiTSWktLU">Reactive programming: lessons learned</a>, prezentacja Tomka z konferencji JDD 2018</li><li><a href="https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/">What Color is Your Function?</a></li><li><a href="https://rxmarbles.com">RxMarbles</a>, interaktywne diagramy Rx</li><li><a href="https://nurkiewicz.com">nurkiewicz.com</a>, strona Tomka i jego podcastu Around IT in 256 Seconds</li><li><a href="https://www.goodreads.com/book/show/28321006-reactive-programming-with-rxjava">Reactive Programming with RxJava: Creating Asynchronous, Event-Based Applications</a></li></ul><p>Narzędzia:</p><ul><li><a href="https://reactivex.io">ReactiveX</a>, pełna lista wspieranych języków jest <a href="https://reactivex.io/languages.html">na tej stronie</a></li><li><a href="https://spring.io/reactive">Spring Reactive</a></li><li><a href="https://projectreactor.io">Project Reactor</a></li><li><a href="https://rxjs.dev">RxJS</a></li></ul>
]]></description>
      <pubDate>Tue, 15 Nov 2022 00:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/44-Zdwdr6cM</link>
      <content:encoded><![CDATA[<p>Materiały dodatkowe:</p><ul><li><a href="https://www.youtube.com/watch?v=5TJiTSWktLU">Reactive programming: lessons learned</a>, prezentacja Tomka z konferencji JDD 2018</li><li><a href="https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/">What Color is Your Function?</a></li><li><a href="https://rxmarbles.com">RxMarbles</a>, interaktywne diagramy Rx</li><li><a href="https://nurkiewicz.com">nurkiewicz.com</a>, strona Tomka i jego podcastu Around IT in 256 Seconds</li><li><a href="https://www.goodreads.com/book/show/28321006-reactive-programming-with-rxjava">Reactive Programming with RxJava: Creating Asynchronous, Event-Based Applications</a></li></ul><p>Narzędzia:</p><ul><li><a href="https://reactivex.io">ReactiveX</a>, pełna lista wspieranych języków jest <a href="https://reactivex.io/languages.html">na tej stronie</a></li><li><a href="https://spring.io/reactive">Spring Reactive</a></li><li><a href="https://projectreactor.io">Project Reactor</a></li><li><a href="https://rxjs.dev">RxJS</a></li></ul>
]]></content:encoded>
      <enclosure length="63208621" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/1b6a4212-ad0a-4b6a-8780-05c71b62985f/audio/7b0efc9b-68de-4459-a2e0-fb8c9b708cee/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>44. O programowaniu reaktywnym z Tomkiem Nurkiewiczem</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>01:05:46</itunes:duration>
      <itunes:summary>Każdy paradygmat programowania świetnie funkcjonuje w przestrzeni, do której został zaprojektowany. I jednocześnie sprawia dużo problemów, gdy jest stosowany w miejscach dla niego nie przeznaczonych. Nie inaczej jest z programowaniem reaktywnym, o którym rozmawiamy dziś razem z Tomkiem Nurkiewiczem, autorem m.in. książki Reactive Programming with RxJava czy podcastu Around IT in 256 Seconds.

W tym odcinku:
- czym właściwie jest programowanie reaktywne?
- jakie są zalety i wady tego paradygmatu, zarówno na warstwie frontendowej jak i backendowej systemu,
- o zarażaniu systemu reaktywnością,
- narzędzia implementujących ten koncept programistyczny.</itunes:summary>
      <itunes:subtitle>Każdy paradygmat programowania świetnie funkcjonuje w przestrzeni, do której został zaprojektowany. I jednocześnie sprawia dużo problemów, gdy jest stosowany w miejscach dla niego nie przeznaczonych. Nie inaczej jest z programowaniem reaktywnym, o którym rozmawiamy dziś razem z Tomkiem Nurkiewiczem, autorem m.in. książki Reactive Programming with RxJava czy podcastu Around IT in 256 Seconds.

W tym odcinku:
- czym właściwie jest programowanie reaktywne?
- jakie są zalety i wady tego paradygmatu, zarówno na warstwie frontendowej jak i backendowej systemu,
- o zarażaniu systemu reaktywnością,
- narzędzia implementujących ten koncept programistyczny.</itunes:subtitle>
      <itunes:keywords>reactive programming, rx, programowanie reaktywne, paradygmaty programowania</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>44</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">c4506347-f057-4f22-855d-be381dec8d87</guid>
      <title>43. O subdomenach biznesowych ze Sławkiem Sobótką</title>
      <description><![CDATA[<p>Aktualizacja... Podczas publikacji odcinka niestety nie zapisały się linki do książek. </p><ul><li><a href="https://www.goodreads.com/book/show/434826.Enterprise_Patterns_and_MDA">Enterprise Patterns and MDA: Building Better Software with Archetype Patterns and UML</a>, Jim Arlow, Ila Neustadt</li><li><a href="https://www.goodreads.com/book/show/85002.Analysis_Patterns">Analysis Patterns: Reusable Object Models</a>, Martin Fowler, z przedmową Ralpha Johnsona i Warda Cunninghama</li><li><a href="https://www.goodreads.com/book/show/981057.Data_Model_Patterns">Data Model Patterns: Conventions of Thought</a>, David C. Hay</li><li><a href="https://www.goodreads.com/book/show/19219878-the-data-model-resource-book">The Data Model Resource Book: A Library of Universal Data Models for All Enterprises</a>, Len Silverston - książek z tej serii jest kilka, kolejne dotykają różnych domen biznesowych lub są rozwinięciem poprzedniego wydania</li></ul><p>Mał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.</p>
]]></description>
      <pubDate>Tue, 1 Nov 2022 00:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/43-B4mS_BHf</link>
      <content:encoded><![CDATA[<p>Aktualizacja... Podczas publikacji odcinka niestety nie zapisały się linki do książek. </p><ul><li><a href="https://www.goodreads.com/book/show/434826.Enterprise_Patterns_and_MDA">Enterprise Patterns and MDA: Building Better Software with Archetype Patterns and UML</a>, Jim Arlow, Ila Neustadt</li><li><a href="https://www.goodreads.com/book/show/85002.Analysis_Patterns">Analysis Patterns: Reusable Object Models</a>, Martin Fowler, z przedmową Ralpha Johnsona i Warda Cunninghama</li><li><a href="https://www.goodreads.com/book/show/981057.Data_Model_Patterns">Data Model Patterns: Conventions of Thought</a>, David C. Hay</li><li><a href="https://www.goodreads.com/book/show/19219878-the-data-model-resource-book">The Data Model Resource Book: A Library of Universal Data Models for All Enterprises</a>, Len Silverston - książek z tej serii jest kilka, kolejne dotykają różnych domen biznesowych lub są rozwinięciem poprzedniego wydania</li></ul><p>Mał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.</p>
]]></content:encoded>
      <enclosure length="58925712" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/f8234eef-c4a9-47dd-b3e8-af067e17e762/audio/c3a08c1d-dbf1-42be-a804-d8bd36efc019/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>43. O subdomenach biznesowych ze Sławkiem Sobótką</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>01:01:20</itunes:duration>
      <itunes:summary>Jednym z fundamentów Domain-Driven Design jest zrozumienie i dekompozycja działalności organizacji w odrębne subdomeny. A do dyskusji o subdomenach, nazywanych także czasem poddziedzinami czy też przestrzenią problemu, zaprosiłem dziś Sławka Sobótkę.

W tym odcinku ze Sławkiem rozmawiamy m.in. o tym:
- czym właściwie są subdomeny,
- jak można je kategoryzować,
- przykładowych heurystykach pomocnych w identyfikacji subdomen,
- jak wykorzystać tę wiedzę w projekcie i wiązać z innymi podejściami.

Nie zabrakło też kilku przykładów, aby zobrazować ten czasem niezbyt oczywisty koncept.

Zapraszam Cię także na spotkanie online Legacy Fighter LIVE: &quot;DDD w Legacy: jak uratować Twój system&quot;, które odbędzie się już 7 listopada o 20:00. Więcej szczegółów na https://legacyfighter.pl/live.html</itunes:summary>
      <itunes:subtitle>Jednym z fundamentów Domain-Driven Design jest zrozumienie i dekompozycja działalności organizacji w odrębne subdomeny. A do dyskusji o subdomenach, nazywanych także czasem poddziedzinami czy też przestrzenią problemu, zaprosiłem dziś Sławka Sobótkę.

W tym odcinku ze Sławkiem rozmawiamy m.in. o tym:
- czym właściwie są subdomeny,
- jak można je kategoryzować,
- przykładowych heurystykach pomocnych w identyfikacji subdomen,
- jak wykorzystać tę wiedzę w projekcie i wiązać z innymi podejściami.

Nie zabrakło też kilku przykładów, aby zobrazować ten czasem niezbyt oczywisty koncept.

Zapraszam Cię także na spotkanie online Legacy Fighter LIVE: &quot;DDD w Legacy: jak uratować Twój system&quot;, które odbędzie się już 7 listopada o 20:00. Więcej szczegółów na https://legacyfighter.pl/live.html</itunes:subtitle>
      <itunes:keywords>domain-driven design, core subdomain, supportive subdomain, strategic ddd, subdomeny biznesowe, generic subdomain</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>43</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">88d282b3-3f68-43e6-b2a2-875525ba55cc</guid>
      <title>42. O analizie biznesowej i systemowej z Moniką Perendyk</title>
      <description><![CDATA[<p>Materiały dodatkowe:</p><ul><li><a href="https://www.goodreads.com/book/show/17346953-software-requirements-3">Software Requirements</a>, Karl Wiegers, Joy Beatty, wydanie III</li><li><a href="https://www.goodreads.com/book/show/12900800-requirements-engineering-fundamentals">Requirements Engineering Fundamentals: A Study Guide for the Certified Professional for Requirements Engineering Exam - Foundation Level</a>, Klaus Pohl, Chris Rupp</li><li><a href="https://www.goodreads.com/book/show/10288718-specification-by-example">Specification by Example: How Successful Teams Deliver the Right Software</a>, Gojko Adzic</li><li>Facylitacja-wiedza, umiejętności, sztuka czy magia</li></ul><p>Na stronie Moniki można też przeczytać kilka artykułów na tematy, które zostały poruszone w rozmowie:</p><ul><li><a href="https://analizawymagan.pl/wymaganie-biznesowe-a-regula-biznesowa/">Wymaganie biznesowe a reguła biznesowa</a></li><li><a href="https://analizawymagan.pl/atrybuty-wymagania-bo-opis-wymagania-to-za-malo/">Atrybuty wymagania</a></li><li><a href="https://analizawymagan.pl/definicja-wymagania-rodzaje-wymagan-czyli-o-czym-powinien-pamietac-kazdy-analityk/">Kategoryzacja wymagań</a></li><li><a href="https://analizawymagan.pl/dlug-techniczny-czym-jest-i-dlaczego-analityk-ma-na-niego-wplyw/">Dług techniczny</a></li><li><a href="https://analizawymagan.pl/adaptowanie-produktu-w-czasach-kryzysu-czyli-czym-jest-pivot/">Adaptowanie produktu w czasach kryzysu, czyli czym jest PIVOT</a></li></ul><p>Monikę można obserwować m.in. na <a href="https://www.instagram.com/monikaperendyk/">Instagramie</a> lub <a href="https://www.linkedin.com/in/monikaperendyk/">LinkedIn</a>.</p>
]]></description>
      <pubDate>Mon, 17 Oct 2022 23:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/42-URgrRPoB</link>
      <content:encoded><![CDATA[<p>Materiały dodatkowe:</p><ul><li><a href="https://www.goodreads.com/book/show/17346953-software-requirements-3">Software Requirements</a>, Karl Wiegers, Joy Beatty, wydanie III</li><li><a href="https://www.goodreads.com/book/show/12900800-requirements-engineering-fundamentals">Requirements Engineering Fundamentals: A Study Guide for the Certified Professional for Requirements Engineering Exam - Foundation Level</a>, Klaus Pohl, Chris Rupp</li><li><a href="https://www.goodreads.com/book/show/10288718-specification-by-example">Specification by Example: How Successful Teams Deliver the Right Software</a>, Gojko Adzic</li><li>Facylitacja-wiedza, umiejętności, sztuka czy magia</li></ul><p>Na stronie Moniki można też przeczytać kilka artykułów na tematy, które zostały poruszone w rozmowie:</p><ul><li><a href="https://analizawymagan.pl/wymaganie-biznesowe-a-regula-biznesowa/">Wymaganie biznesowe a reguła biznesowa</a></li><li><a href="https://analizawymagan.pl/atrybuty-wymagania-bo-opis-wymagania-to-za-malo/">Atrybuty wymagania</a></li><li><a href="https://analizawymagan.pl/definicja-wymagania-rodzaje-wymagan-czyli-o-czym-powinien-pamietac-kazdy-analityk/">Kategoryzacja wymagań</a></li><li><a href="https://analizawymagan.pl/dlug-techniczny-czym-jest-i-dlaczego-analityk-ma-na-niego-wplyw/">Dług techniczny</a></li><li><a href="https://analizawymagan.pl/adaptowanie-produktu-w-czasach-kryzysu-czyli-czym-jest-pivot/">Adaptowanie produktu w czasach kryzysu, czyli czym jest PIVOT</a></li></ul><p>Monikę można obserwować m.in. na <a href="https://www.instagram.com/monikaperendyk/">Instagramie</a> lub <a href="https://www.linkedin.com/in/monikaperendyk/">LinkedIn</a>.</p>
]]></content:encoded>
      <enclosure length="84359323" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/ec9f6913-8fb4-4c5b-9bfd-bd760180c8fc/audio/ae2328bf-63df-481d-be36-db9d8c9c9c19/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>42. O analizie biznesowej i systemowej z Moniką Perendyk</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>01:27:49</itunes:duration>
      <itunes:summary>Mało który temat budzi tak wiele skrajnych emocji jak współpraca analityków i developerów. A na pewno nie było takiego do tej pory w podkaście. Czas więc przyjrzeć się bliżej zagadnieniom analizy biznesowej i systemowej oraz roli analityków w procesie tworzenia oprogramowania. W tej rozmowie padną konkretne i mocne słowa, ponieważ dookoła tych tematów urosło wiele mitów i nieporozumień. Dlatego bardzo się cieszę, że zaproszenie do tej właśnie rozmowy przyjęła osoba, która ma ogromne doświadczenie w zakresie analizy IT.

A gościem odcinka jest Monika Perendyk, analityk biznesowy z ponad 15-letnim doświadczeniem, organizator Konferencji Inżynierii Wymagań i Analizy Biznesowej, wykładowca Politechniki Warszawskiej prowadzący zajęcia z tematyki inżynierii wymagań, v-ce prezes Stowarzyszenia Inżynierii Wymagań. Słowem, właściwa osoba na właściwym miejscu...

W tym odcinku rozmawiamy z Moniką m.in. o:
- roli analityka biznesowego i systemowego,
- inżynierii wymagań,
- skutecznych narzędziach eksploracji domeny biznesowej,
- współpracy analityków z zespołem developerskim, także tym wykorzystującym techniki DDD,
- często popełnianych (po obu stronach) błędach i ich przyczynach.

Zapraszam także na Legacy Fighter LIVE!, więcej informacji znajduje się na stronie https://legacyfighter.pl/live.html.</itunes:summary>
      <itunes:subtitle>Mało który temat budzi tak wiele skrajnych emocji jak współpraca analityków i developerów. A na pewno nie było takiego do tej pory w podkaście. Czas więc przyjrzeć się bliżej zagadnieniom analizy biznesowej i systemowej oraz roli analityków w procesie tworzenia oprogramowania. W tej rozmowie padną konkretne i mocne słowa, ponieważ dookoła tych tematów urosło wiele mitów i nieporozumień. Dlatego bardzo się cieszę, że zaproszenie do tej właśnie rozmowy przyjęła osoba, która ma ogromne doświadczenie w zakresie analizy IT.

A gościem odcinka jest Monika Perendyk, analityk biznesowy z ponad 15-letnim doświadczeniem, organizator Konferencji Inżynierii Wymagań i Analizy Biznesowej, wykładowca Politechniki Warszawskiej prowadzący zajęcia z tematyki inżynierii wymagań, v-ce prezes Stowarzyszenia Inżynierii Wymagań. Słowem, właściwa osoba na właściwym miejscu...

W tym odcinku rozmawiamy z Moniką m.in. o:
- roli analityka biznesowego i systemowego,
- inżynierii wymagań,
- skutecznych narzędziach eksploracji domeny biznesowej,
- współpracy analityków z zespołem developerskim, także tym wykorzystującym techniki DDD,
- często popełnianych (po obu stronach) błędach i ich przyczynach.

Zapraszam także na Legacy Fighter LIVE!, więcej informacji znajduje się na stronie https://legacyfighter.pl/live.html.</itunes:subtitle>
      <itunes:keywords>analiza it, analiza systemowa, analiza wymagań, techniki analityczne, analiza biznesowa</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>42</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">196ee423-0125-4329-8249-16ce1e47f64a</guid>
      <title>41. O Domain Storytelling z Maciejem Jędrzejewskim</title>
      <description><![CDATA[<p>Materiały dodatkowe:</p><ul><li><a href="https://domainstorytelling.org/quick-start-guide">Domain Storytelling Quick Start Guide</a>, szybkie wprowadzenie do techniki</li><li><a href="https://www.goodreads.com/book/show/58385794-domain-storytelling">Domain Storytelling: A Collaborative, Visual, and Agile Way to Build Domain-Driven Software</a>, Henning Schwentner oraz Stefan Hofer</li><li><a href="https://www.youtube.com/watch?v=Y1ykXnl6r7s">Find Context Boundaries with Domain Storytelling</a>, prezentacja Henninga Schwentner oraz Stefana Hoferz konferencji DDD EU 2018</li><li><a href="https://leasingninja.io">LeasingNinja</a>, przykład z użyciem Domain Storytellingu</li><li><a href="https://egon.io">Egon.io</a>, proste narzędzie do wizualizacji historyjek</li><li><a href="https://github.com/WPS/egon.io-examples">Egion.io - examples</a>, repozytorium z kilkoma przykładami do Egon</li></ul>
]]></description>
      <pubDate>Mon, 3 Oct 2022 23:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/41-VG_0uIYz</link>
      <content:encoded><![CDATA[<p>Materiały dodatkowe:</p><ul><li><a href="https://domainstorytelling.org/quick-start-guide">Domain Storytelling Quick Start Guide</a>, szybkie wprowadzenie do techniki</li><li><a href="https://www.goodreads.com/book/show/58385794-domain-storytelling">Domain Storytelling: A Collaborative, Visual, and Agile Way to Build Domain-Driven Software</a>, Henning Schwentner oraz Stefan Hofer</li><li><a href="https://www.youtube.com/watch?v=Y1ykXnl6r7s">Find Context Boundaries with Domain Storytelling</a>, prezentacja Henninga Schwentner oraz Stefana Hoferz konferencji DDD EU 2018</li><li><a href="https://leasingninja.io">LeasingNinja</a>, przykład z użyciem Domain Storytellingu</li><li><a href="https://egon.io">Egon.io</a>, proste narzędzie do wizualizacji historyjek</li><li><a href="https://github.com/WPS/egon.io-examples">Egion.io - examples</a>, repozytorium z kilkoma przykładami do Egon</li></ul>
]]></content:encoded>
      <enclosure length="64313569" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/0d47848d-ac81-4756-9aed-90b0ebbe77b2/audio/8bf2ff28-507f-41a9-ba0b-5f76b0b20b52/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>41. O Domain Storytelling z Maciejem Jędrzejewskim</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>01:06:55</itunes:duration>
      <itunes:summary>Zrozumienie domeny biznesowej może być budowane na wiele sposobów i różnymi technikami. Mój dzisiejszy rozmówca, Maciej Jędrzejewski, przedstawia kolejne narzędzie analitycznego toolboxa, które z powodzeniem stosuje w pracy ze swoim zespołem. Domain Storytelling, autorstwa  Henninga Schwentnera oraz Stefana Hofera, to prosta technika notowania i wizualizacji historyjek domenowych, które mogą przełożyć się na więcej niż to się pozornie wydaje.

W tym odcinku rozmawiamy z Maćkiem m.in. o:
- tym, czym jest technika Domain Storytellingu,
- często wykorzystywanych poziomach tego narzędzia,
- łączeniu go z innymi technikami analitycznymi i modelarskimi,
- pomocnych narzędziach,
- przykładowym zastosowaniu Storytellingu.

Zapraszam!</itunes:summary>
      <itunes:subtitle>Zrozumienie domeny biznesowej może być budowane na wiele sposobów i różnymi technikami. Mój dzisiejszy rozmówca, Maciej Jędrzejewski, przedstawia kolejne narzędzie analitycznego toolboxa, które z powodzeniem stosuje w pracy ze swoim zespołem. Domain Storytelling, autorstwa  Henninga Schwentnera oraz Stefana Hofera, to prosta technika notowania i wizualizacji historyjek domenowych, które mogą przełożyć się na więcej niż to się pozornie wydaje.

W tym odcinku rozmawiamy z Maćkiem m.in. o:
- tym, czym jest technika Domain Storytellingu,
- często wykorzystywanych poziomach tego narzędzia,
- łączeniu go z innymi technikami analitycznymi i modelarskimi,
- pomocnych narzędziach,
- przykładowym zastosowaniu Storytellingu.

Zapraszam!</itunes:subtitle>
      <itunes:keywords>domain-driven design, domain storytelling, domain stories, analiza</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>41</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">63a26e87-820b-4a35-bb27-05fc870fac91</guid>
      <title>40. O architekturze frontendu z Tomaszem Ducinem</title>
      <description><![CDATA[<p>Materiały dodatkowe:</p><ul><li><a href="https://kentcdodds.com/blog/the-testing-trophy-and-testing-classifications">The Testing Trophy And Testing Classification</a>, artykuł Kenta C. Doddsa dotyczący zmiany struktury testów w projekcie</li><li><a href="https://www.youtube.com/c/GotoConferences/videos">GOTO Conferences</a>, nagrania z różnych edycji konferencji GOTO</li></ul><p>Pozwoliłem też sobie wybrać kilka konkretnych prezentacji z GOTO:</p><ul><li><a href="https://www.youtube.com/watch?v=MWsk1h8pv2Q">Structure and Interpretation of Test Cases</a>, Kevlin Henney, GOTO 2022</li><li><a href="https://www.youtube.com/watch?v=GBTdnfD6s5Q">When To Use Microservices (And When Not To!)</a>, Sam Newman & Martin Fowler, GOTO 2020</li><li><a href="https://www.youtube.com/watch?v=STKCRSUsyP0">The Many Meanings of Event-Driven Architecture</a>, Martin Fowler, GOTO 2017</li></ul>
]]></description>
      <pubDate>Mon, 26 Sep 2022 23:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/40-Iw8xPtP_</link>
      <content:encoded><![CDATA[<p>Materiały dodatkowe:</p><ul><li><a href="https://kentcdodds.com/blog/the-testing-trophy-and-testing-classifications">The Testing Trophy And Testing Classification</a>, artykuł Kenta C. Doddsa dotyczący zmiany struktury testów w projekcie</li><li><a href="https://www.youtube.com/c/GotoConferences/videos">GOTO Conferences</a>, nagrania z różnych edycji konferencji GOTO</li></ul><p>Pozwoliłem też sobie wybrać kilka konkretnych prezentacji z GOTO:</p><ul><li><a href="https://www.youtube.com/watch?v=MWsk1h8pv2Q">Structure and Interpretation of Test Cases</a>, Kevlin Henney, GOTO 2022</li><li><a href="https://www.youtube.com/watch?v=GBTdnfD6s5Q">When To Use Microservices (And When Not To!)</a>, Sam Newman & Martin Fowler, GOTO 2020</li><li><a href="https://www.youtube.com/watch?v=STKCRSUsyP0">The Many Meanings of Event-Driven Architecture</a>, Martin Fowler, GOTO 2017</li></ul>
]]></content:encoded>
      <enclosure length="81696819" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/6dfb90e3-bbd9-4d8a-8244-dd03c52f1bbb/audio/4d0291fa-00c2-4a6d-bf1b-78a83ec39895/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>40. O architekturze frontendu z Tomaszem Ducinem</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>01:25:01</itunes:duration>
      <itunes:summary>Poprzedni odcinek o driverach architektonicznych pokazał, że nie samą &quot;domeną&quot; żyje projekt. Podobnie jest z frontendem, który dawno temu przestał już być tylko prostą warstwą prezentacyjną, a stał się często (i to mocno złożoną!) osobną aplikacją. 

Z moim dzisiejszym gościem, Tomaszem Ducinem, wkraczamy w świat architektury frontendu i w tym odcinku rozmawiamy m.in.  o:
- wyzwaniach architektonicznych związanych z frontendem,
- porównaniach wzorców i technik stosowanych na backendzie,
- typowych klasach problemów, w tym Eventualny-Connected,
- innej piramidzie testów i testowaniu aplikacji frontowych.

Nie zabrakło często zadawanego pytania &quot;ile wiedzy o domenie i podejściu Domain-Driven Design jest faktycznie potrzebne na froncie&quot;.

Zapraszam!</itunes:summary>
      <itunes:subtitle>Poprzedni odcinek o driverach architektonicznych pokazał, że nie samą &quot;domeną&quot; żyje projekt. Podobnie jest z frontendem, który dawno temu przestał już być tylko prostą warstwą prezentacyjną, a stał się często (i to mocno złożoną!) osobną aplikacją. 

Z moim dzisiejszym gościem, Tomaszem Ducinem, wkraczamy w świat architektury frontendu i w tym odcinku rozmawiamy m.in.  o:
- wyzwaniach architektonicznych związanych z frontendem,
- porównaniach wzorców i technik stosowanych na backendzie,
- typowych klasach problemów, w tym Eventualny-Connected,
- innej piramidzie testów i testowaniu aplikacji frontowych.

Nie zabrakło często zadawanego pytania &quot;ile wiedzy o domenie i podejściu Domain-Driven Design jest faktycznie potrzebne na froncie&quot;.

Zapraszam!</itunes:subtitle>
      <itunes:keywords>architecture, frontend</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>40</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">bdcba422-07e7-49f3-888f-bf8062a5ec2e</guid>
      <title>39. O driverach architektonicznych z Kubą Pilimonem</title>
      <description><![CDATA[<p>Materiały dodatkowe:</p><ul><li><a href="https://leanpub.com/software-architecture-for-developers">Software Architecture for Developers</a>, książka Simona Browna</li><li><a href="https://www.goodreads.com/book/show/31670678-design-it">Design It! : Pragmatic Programmers: From Programmer to Software Architect</a>, książka Michaela Keelinga</li><li><a href="https://www.goodreads.com/book/show/40223985-thinking-architecturally">Thinking Architecturally</a>, książka Nathaniela Schutty</li><li><a href="https://www.youtube.com/watch?v=IGOV3-um0CQ">Thinking Architecturally</a>, prezentacja Nathaniela związana z powyższą książką</li></ul>
]]></description>
      <pubDate>Mon, 19 Sep 2022 23:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/39-t9Ec157n</link>
      <content:encoded><![CDATA[<p>Materiały dodatkowe:</p><ul><li><a href="https://leanpub.com/software-architecture-for-developers">Software Architecture for Developers</a>, książka Simona Browna</li><li><a href="https://www.goodreads.com/book/show/31670678-design-it">Design It! : Pragmatic Programmers: From Programmer to Software Architect</a>, książka Michaela Keelinga</li><li><a href="https://www.goodreads.com/book/show/40223985-thinking-architecturally">Thinking Architecturally</a>, książka Nathaniela Schutty</li><li><a href="https://www.youtube.com/watch?v=IGOV3-um0CQ">Thinking Architecturally</a>, prezentacja Nathaniela związana z powyższą książką</li></ul>
]]></content:encoded>
      <enclosure length="62208505" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/94e9d407-3d85-4a7d-b187-d74aacf380bb/audio/a640a3b7-848b-429d-af53-ee0df0fdc79f/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>39. O driverach architektonicznych z Kubą Pilimonem</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>01:04:44</itunes:duration>
      <itunes:summary>Projektując złożony system wymagania funkcjonalne stanowią najbardziej oczywisty aspekt, jaki powinniśmy wziąć pod uwagę. To one w dużym stopniu kształtują podejmowane decyzje architektoniczne. Ale uwaga! Istnieją także inne siły, które w równie dużym stopniu mogą rozpychać design systemu i które powinny zostać przez nas uwzględnione. Innymi słowy, dziś temat driverów architektonicznych i ich roli w projekcie.

W tym odcinku wraz z Kubą Pilimonem rozmawiamy m.in. o:
- koncepcie driverów architektonicznych,
- czym są i w jaki sposób wpływają na projekt,
- jakie rodzaje driverów powinniśmy wziąć pod uwagę projektując złożony system,
- możliwych pomiarach i metrykach.

Zapraszam!</itunes:summary>
      <itunes:subtitle>Projektując złożony system wymagania funkcjonalne stanowią najbardziej oczywisty aspekt, jaki powinniśmy wziąć pod uwagę. To one w dużym stopniu kształtują podejmowane decyzje architektoniczne. Ale uwaga! Istnieją także inne siły, które w równie dużym stopniu mogą rozpychać design systemu i które powinny zostać przez nas uwzględnione. Innymi słowy, dziś temat driverów architektonicznych i ich roli w projekcie.

W tym odcinku wraz z Kubą Pilimonem rozmawiamy m.in. o:
- koncepcie driverów architektonicznych,
- czym są i w jaki sposób wpływają na projekt,
- jakie rodzaje driverów powinniśmy wziąć pod uwagę projektując złożony system,
- możliwych pomiarach i metrykach.

Zapraszam!</itunes:subtitle>
      <itunes:keywords>architektura oprogramowania, software architecture, drivery architektoniczne, software design, metryki</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>39</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">ceb7f5b4-2a3a-44be-9ea1-ab65ec3c0f97</guid>
      <title>38. O budowaniu fundamentów z Michałem Giergielewiczem</title>
      <description><![CDATA[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. 
]]></description>
      <pubDate>Mon, 12 Sep 2022 23:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/38-YSgooqYA</link>
      <enclosure length="88214798" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/b120b690-07db-4656-a4d1-e6cd3ca6c3c8/audio/6d859e1f-10bb-4f10-b8cd-341bd2731135/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>38. O budowaniu fundamentów z Michałem Giergielewiczem</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>01:31:49</itunes:duration>
      <itunes:summary>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.</itunes:summary>
      <itunes:subtitle>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.</itunes:subtitle>
      <itunes:keywords>domain-driven design, solid principles, grasp patterns, ddd</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>38</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">fb11f26c-7e4b-4117-adf8-4a6c472fc7ca</guid>
      <title>37. O Context Mappingu z Bartkiem Słotą</title>
      <description><![CDATA[<p>Materiały dodatkowe:</p><ul><li><a href="https://www.youtube.com/watch?v=VjtMt689ql8">Context Maps - a deep dive</a>, prezentacja Michaela Plöda z konferencji KanDDDinsky 2019</li><li><a href="https://contextmapper.org">Context Mapper</a>, narzędzia do dokumentowania i wizualizowania map kontekstów</li></ul>
]]></description>
      <pubDate>Mon, 5 Sep 2022 23:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/37-k_X8eitR</link>
      <content:encoded><![CDATA[<p>Materiały dodatkowe:</p><ul><li><a href="https://www.youtube.com/watch?v=VjtMt689ql8">Context Maps - a deep dive</a>, prezentacja Michaela Plöda z konferencji KanDDDinsky 2019</li><li><a href="https://contextmapper.org">Context Mapper</a>, narzędzia do dokumentowania i wizualizowania map kontekstów</li></ul>
]]></content:encoded>
      <enclosure length="73049320" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/5e4ca4ed-11c6-4a93-9e31-af333be259a3/audio/861ba666-0ba6-483d-a7bd-99fd4ce35988/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>37. O Context Mappingu z Bartkiem Słotą</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>01:16:03</itunes:duration>
      <itunes:summary>Temat mapowania kontekstów kilkukrotnie pojawił się we wcześniejszych rozmowach, zarówno na poziomie technicznej integracji serwisów jak i struktury całej organizacji. 

Czym jest Context Mapping, wzorce takie jak Open Host Service, Conformist, Customer/ Supplier, Partnership (i jeszcze kilka innych!) , a także w czym te narzędzia pomagają w projekcie - to tematy, które poruszamy dziś w rozmowie z Bartkiem Słotą. Nie zabrakło również wątków związanych z praktycznym stosowaniem Context Mappingu i uzupełnianiu nim swojego analitycznego toolboxa.

Zapraszam!</itunes:summary>
      <itunes:subtitle>Temat mapowania kontekstów kilkukrotnie pojawił się we wcześniejszych rozmowach, zarówno na poziomie technicznej integracji serwisów jak i struktury całej organizacji. 

Czym jest Context Mapping, wzorce takie jak Open Host Service, Conformist, Customer/ Supplier, Partnership (i jeszcze kilka innych!) , a także w czym te narzędzia pomagają w projekcie - to tematy, które poruszamy dziś w rozmowie z Bartkiem Słotą. Nie zabrakło również wątków związanych z praktycznym stosowaniem Context Mappingu i uzupełnianiu nim swojego analitycznego toolboxa.

Zapraszam!</itunes:subtitle>
      <itunes:keywords>mapowanie kontekstów, domain-driven design, bounded context, open-host, customer-supplier, context mapping, strategic ddd, anti-corruption layer</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>37</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">d1949648-d652-4e1a-bd31-231bcd9076e4</guid>
      <title>36. O modularyzacji monolitu z Kamilem Grzybkiem</title>
      <description><![CDATA[<p>Materiały dodatkowe:</p><ul><li><a href="https://www.kamilgrzybek.com/design/modular-monolith-primer/">Modular monolith: Primer</a>, część 1 serii</li><li><a href="https://www.kamilgrzybek.com/design/modular-monolith-architectural-drivers/">Modular Monolith: Architectural Drivers</a>, część 2 serii</li><li><a href="https://www.kamilgrzybek.com/design/modular-monolith-architecture-enforcement/">Modular Monolith: Architecture Enforcement</a>, część 3 serii</li><li><a href="https://www.kamilgrzybek.com/design/modular-monolith-integration-styles/">Modular Monolith: Integration Styles</a>, część 4 serii</li><li><a href="http://www.kamilgrzybek.com/design/modular-monolith-domain-centric-design/">Modular Monolith: Domain-Centric Design</a>, część 5 serii</li><li><a href="https://github.com/kgrzybek/modular-monolith-with-ddd/">Modular Monolith with DDD</a>, przykład modularnego monolitu w repozytorium Kamila na Githubie</li><li><a href="https://www.goodreads.com/book/show/85012.Enterprise_Integration_Patterns">Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions</a>, Gregor Hohpe</li></ul>
]]></description>
      <pubDate>Mon, 30 May 2022 23:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/36-p8ZZFMMv</link>
      <content:encoded><![CDATA[<p>Materiały dodatkowe:</p><ul><li><a href="https://www.kamilgrzybek.com/design/modular-monolith-primer/">Modular monolith: Primer</a>, część 1 serii</li><li><a href="https://www.kamilgrzybek.com/design/modular-monolith-architectural-drivers/">Modular Monolith: Architectural Drivers</a>, część 2 serii</li><li><a href="https://www.kamilgrzybek.com/design/modular-monolith-architecture-enforcement/">Modular Monolith: Architecture Enforcement</a>, część 3 serii</li><li><a href="https://www.kamilgrzybek.com/design/modular-monolith-integration-styles/">Modular Monolith: Integration Styles</a>, część 4 serii</li><li><a href="http://www.kamilgrzybek.com/design/modular-monolith-domain-centric-design/">Modular Monolith: Domain-Centric Design</a>, część 5 serii</li><li><a href="https://github.com/kgrzybek/modular-monolith-with-ddd/">Modular Monolith with DDD</a>, przykład modularnego monolitu w repozytorium Kamila na Githubie</li><li><a href="https://www.goodreads.com/book/show/85012.Enterprise_Integration_Patterns">Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions</a>, Gregor Hohpe</li></ul>
]]></content:encoded>
      <enclosure length="114392930" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/d8fac84d-f7bc-427e-968c-30d0111c19ab/audio/0bd9ef67-578f-4c3f-a710-0452b1687167/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>36. O modularyzacji monolitu z Kamilem Grzybkiem</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>01:19:25</itunes:duration>
      <itunes:summary>Wcześniej czy później, chyba każdy programista czy programistka zetknie się w swojej karierze z systemem monolitycznym. Monolity na przestrzeni lat obrosły złą sławą, automatycznie kojarzą się z kodem o niskiej jakości, sprzężenia wszystkiego ze wszystkim i chęcią ucieczki do innego projektu. Z moim dzisiejszym gościem, Kamilem Grzybkiem, chcielibyśmy odczarować trochę hasło &quot;monolit&quot;, bo nie zawsze powinno ono się wiązać ze słabym kodem i zaczynamy poruszać tematykę modularyzacji takich systemów. 

W tym odcinku rozmawiamy z Kamilem m.in. o:
- heurystykach modularyzacji monolitu,
- kluczowych wzorcach Domain-Driven Design pomocnych w tym procesie,
- sposobach komunikacji w modularnym monolicie i integracji rozciętych modułów,
- driverach architektonicznych pomocnych przy ocenie architektury.

Zapraszam!</itunes:summary>
      <itunes:subtitle>Wcześniej czy później, chyba każdy programista czy programistka zetknie się w swojej karierze z systemem monolitycznym. Monolity na przestrzeni lat obrosły złą sławą, automatycznie kojarzą się z kodem o niskiej jakości, sprzężenia wszystkiego ze wszystkim i chęcią ucieczki do innego projektu. Z moim dzisiejszym gościem, Kamilem Grzybkiem, chcielibyśmy odczarować trochę hasło &quot;monolit&quot;, bo nie zawsze powinno ono się wiązać ze słabym kodem i zaczynamy poruszać tematykę modularyzacji takich systemów. 

W tym odcinku rozmawiamy z Kamilem m.in. o:
- heurystykach modularyzacji monolitu,
- kluczowych wzorcach Domain-Driven Design pomocnych w tym procesie,
- sposobach komunikacji w modularnym monolicie i integracji rozciętych modułów,
- driverach architektonicznych pomocnych przy ocenie architektury.

Zapraszam!</itunes:subtitle>
      <itunes:keywords>domain-driven design, monolit, modularyzacja, mariusz gil, legacy, monolith, kamil grzybek, ddd, refaktoryzacja</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>36</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">5a485e50-ef57-4bb7-81b1-22b09ebb3c30</guid>
      <title>35. O Wardley Mappingu z Radkiem Maziarką</title>
      <description><![CDATA[<p>Dodatkowe materiały</p><ul><li><a href="https://miro.com/app/board/uXjVON2EAwI=/?invite_link_id=490103773100">Wardley Mapping - notatki ze spotkania na Miro</a></li><li><a href="https://twitter.com/swardley">Konto Simona Wardley’a na Twitterze</a></li><li><a href="https://learnwardleymapping.com/">Nauka map Wardley’a w 90 sek</a></li><li><a href="https://radekmaziarka.pl/2020/06/21/narzedzia-pracy-konsultanta-wardley-map/">Narzędzia konsultanta</a>, artykuł wprowadzający na blogu Radka</li><li><a href="https://joapen.com/blog/2021/09/16/zalando-a-wardley-map-about-how-they-play-the-game/">Analiza przypadku Zalando</a>, przykład praktycznego użycia map</li><li><a href="https://www.youtube.com/watch?v=NnFeIt-uaEc">Introduction to Value Chain Mapping"</a>, keynote Simona Wardley'a z konferencji OSCON 2014</li><li><a href="https://www.youtube.com/watch?v=oZZKjxeg5W0">Crossing the River by Feeling the Stones</a> , prezentacja Simona Wardley'a z konferencji DDD Europe 2018</li><li><a href="https://medium.com/wardleymaps/on-being-lost-2ef5f05eb1ec">On being lost</a>, artykuł autorstwa Simona Wardley'a</li></ul>
]]></description>
      <pubDate>Mon, 16 May 2022 23:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/35-bNhxrVtE</link>
      <content:encoded><![CDATA[<p>Dodatkowe materiały</p><ul><li><a href="https://miro.com/app/board/uXjVON2EAwI=/?invite_link_id=490103773100">Wardley Mapping - notatki ze spotkania na Miro</a></li><li><a href="https://twitter.com/swardley">Konto Simona Wardley’a na Twitterze</a></li><li><a href="https://learnwardleymapping.com/">Nauka map Wardley’a w 90 sek</a></li><li><a href="https://radekmaziarka.pl/2020/06/21/narzedzia-pracy-konsultanta-wardley-map/">Narzędzia konsultanta</a>, artykuł wprowadzający na blogu Radka</li><li><a href="https://joapen.com/blog/2021/09/16/zalando-a-wardley-map-about-how-they-play-the-game/">Analiza przypadku Zalando</a>, przykład praktycznego użycia map</li><li><a href="https://www.youtube.com/watch?v=NnFeIt-uaEc">Introduction to Value Chain Mapping"</a>, keynote Simona Wardley'a z konferencji OSCON 2014</li><li><a href="https://www.youtube.com/watch?v=oZZKjxeg5W0">Crossing the River by Feeling the Stones</a> , prezentacja Simona Wardley'a z konferencji DDD Europe 2018</li><li><a href="https://medium.com/wardleymaps/on-being-lost-2ef5f05eb1ec">On being lost</a>, artykuł autorstwa Simona Wardley'a</li></ul>
]]></content:encoded>
      <enclosure length="74291181" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/48e88b2c-e30f-4064-9eb6-a3c17ffddcf8/audio/294a6652-42e2-49cf-86c0-d87146e07dea/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>35. O Wardley Mappingu z Radkiem Maziarką</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>00:51:34</itunes:duration>
      <itunes:summary>Kierowanie strategicznym rozwojem projektu może przysparzać wielu wyzwań. Dzisiejszy gość, Radek Maziarka, przedstawia narzędzie Wardley Mappingu, które może być ciekawym wsparciem przy strategicznym wyznaczaniu kierunku rozwoju organizacji i produktu.

W tym odcinku Radek przedstawia m.in.
- czym są mapy Wardley&apos;a,
- komu mogą okazać się przydatne w rozwoju produktu,
- jak Wardley Mapping może łączyć się ze strategicznym Domain-Driven Design,
- w jaki sposób można wykorzystać je do planowania prac rozwojowych (i nie tylko).</itunes:summary>
      <itunes:subtitle>Kierowanie strategicznym rozwojem projektu może przysparzać wielu wyzwań. Dzisiejszy gość, Radek Maziarka, przedstawia narzędzie Wardley Mappingu, które może być ciekawym wsparciem przy strategicznym wyznaczaniu kierunku rozwoju organizacji i produktu.

W tym odcinku Radek przedstawia m.in.
- czym są mapy Wardley&apos;a,
- komu mogą okazać się przydatne w rozwoju produktu,
- jak Wardley Mapping może łączyć się ze strategicznym Domain-Driven Design,
- w jaki sposób można wykorzystać je do planowania prac rozwojowych (i nie tylko).</itunes:subtitle>
      <itunes:keywords>domain-driven design, wardley mapping, strategic ddd</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>35</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">df5675cb-c4aa-480f-82ca-fc019cbbcc75</guid>
      <title>34. O autonomii zmiany w architekturze mikroserwisowej z Łukaszem Szydło</title>
      <description><![CDATA[<p>Materiały dodatkowe</p><ul><li><a href="https://www.youtube.com/watch?v=VjtMt689ql8">Context Maps - a deep dive, Michael Plöd</a>, prezentacja z konferencji KanDDDinsky 2019</li></ul>
]]></description>
      <pubDate>Tue, 3 May 2022 23:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/34-nsyubXbk</link>
      <content:encoded><![CDATA[<p>Materiały dodatkowe</p><ul><li><a href="https://www.youtube.com/watch?v=VjtMt689ql8">Context Maps - a deep dive, Michael Plöd</a>, prezentacja z konferencji KanDDDinsky 2019</li></ul>
]]></content:encoded>
      <enclosure length="78224697" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/5921a1cc-2d81-4de2-a2a0-f63a68dd0271/audio/1ef64971-81d4-45e6-810f-d49b1e53baff/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>34. O autonomii zmiany w architekturze mikroserwisowej z Łukaszem Szydło</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>00:54:17</itunes:duration>
      <itunes:summary>W architekturze mikroserwisowej często wykorzystuje się zdarzenia do wprowadzania asynchroniczności i zmniejszania couplingu pomiędzy poszczególnymi częściami systemu. Ale opieranie komunikacji w każdym możliwym przypadku o koncept eventu często doprowadza do powstania zupełnie nowych problemów, związanych np. z koniecznością wprowadzania jednoczesnych zmian w wielu różnych częściach systemu. Łukasz Szydło, gość dzisiejszego odcinka wprowadzi nas w temat autonomii zmian w takiej architekturze i wykorzystania różnych narzędzi do jej projektowania.

W dzisiejszym odcinku będzie można posłuchać m.in. o:
- autonomii wprowadzania zmian w architekturze mikroserwisowej,
- couplingu i decydowaniu, kiedy chcemy się go pozbywać z kodu systemu,
- Context Mappingu,
- wykorzystania map kontekstów do ustalania zależności pomiędzy zespołami,
- zmianach zdarzeń na komendy.</itunes:summary>
      <itunes:subtitle>W architekturze mikroserwisowej często wykorzystuje się zdarzenia do wprowadzania asynchroniczności i zmniejszania couplingu pomiędzy poszczególnymi częściami systemu. Ale opieranie komunikacji w każdym możliwym przypadku o koncept eventu często doprowadza do powstania zupełnie nowych problemów, związanych np. z koniecznością wprowadzania jednoczesnych zmian w wielu różnych częściach systemu. Łukasz Szydło, gość dzisiejszego odcinka wprowadzi nas w temat autonomii zmian w takiej architekturze i wykorzystania różnych narzędzi do jej projektowania.

W dzisiejszym odcinku będzie można posłuchać m.in. o:
- autonomii wprowadzania zmian w architekturze mikroserwisowej,
- couplingu i decydowaniu, kiedy chcemy się go pozbywać z kodu systemu,
- Context Mappingu,
- wykorzystania map kontekstów do ustalania zależności pomiędzy zespołami,
- zmianach zdarzeń na komendy.</itunes:subtitle>
      <itunes:keywords>domain-driven design, mikroserwisy, event-driven, mariusz gil, microservices, architektura mikroserwisowa, łukasz szydło, ddd, event-driven architecture, boiling frogs</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>34</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">72de8731-32fa-4930-b640-ef529b37b2ea</guid>
      <title>33. O temporal modelingu i Event Sourcingu z Oskarem Dudyczem</title>
      <description><![CDATA[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. 
]]></description>
      <pubDate>Mon, 18 Apr 2022 23:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/33-fmywHIvy</link>
      <enclosure length="58751017" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/c4aa6036-7efc-45d7-97d4-59b5b81f59be/audio/afea19e9-59d6-4971-8ad5-678c55033dad/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>33. O temporal modelingu i Event Sourcingu z Oskarem Dudyczem</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>01:01:11</itunes:duration>
      <itunes:summary>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.</itunes:summary>
      <itunes:subtitle>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.</itunes:subtitle>
      <itunes:keywords>modeling by example, mariusz gil, aggregates, aggregate, oskar dudycz, temporal modeling, event sourcing, event store, event stream</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>33</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">e9c1e21b-f9f6-4ffb-a0bf-1e8d23396c7c</guid>
      <title>32. O Behaviour-Driven Development z Michałem Michalukiem</title>
      <description><![CDATA[<p>Materiały dodatkowe:</p><ul><li><a href="https://cucumber.io/docs/gherkin/reference/">Składnia języka Gherkin</a></li><li><a href="https://cucumber.io">Cucumber</a></li><li><a href="https://jbehave.org">JBehave</a></li><li><a href="https://specflow.org">SpecFlow</a></li><li><a href="https://behat.org/en/latest/">Behat</a></li><li><a href="https://gauge.org">Thoughtworks Gauge</a></li><li><a href="https://taiko.dev">Thoughtworks Taiko</a></li></ul><p>Dodatkowo, sporo ciekawych odnośników do materiałów związanych z Behaviour-Driven Development znajduje się z repozytorium Mateusza, <a href="https://github.com/msz13/Awesome-BDD/blob/main/README.md">Awesome-BDD</a></p>
]]></description>
      <pubDate>Tue, 1 Feb 2022 00:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/32-fthbxyH4</link>
      <content:encoded><![CDATA[<p>Materiały dodatkowe:</p><ul><li><a href="https://cucumber.io/docs/gherkin/reference/">Składnia języka Gherkin</a></li><li><a href="https://cucumber.io">Cucumber</a></li><li><a href="https://jbehave.org">JBehave</a></li><li><a href="https://specflow.org">SpecFlow</a></li><li><a href="https://behat.org/en/latest/">Behat</a></li><li><a href="https://gauge.org">Thoughtworks Gauge</a></li><li><a href="https://taiko.dev">Thoughtworks Taiko</a></li></ul><p>Dodatkowo, sporo ciekawych odnośników do materiałów związanych z Behaviour-Driven Development znajduje się z repozytorium Mateusza, <a href="https://github.com/msz13/Awesome-BDD/blob/main/README.md">Awesome-BDD</a></p>
]]></content:encoded>
      <enclosure length="72336071" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/22cf7c74-82d6-4779-ab60-53bb0ac22bd0/audio/e75b4d6b-08e5-4827-ac04-ff2851f21b0a/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>32. O Behaviour-Driven Development z Michałem Michalukiem</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>01:15:19</itunes:duration>
      <itunes:summary>Do tej pory w rozmowach przewijał się temat EventStormingu, jako narzędzia do rozpoznawania domeny. Dzisiejszy gość, Michał Michaluk, pokazuje jak używa podejścia Behaviour-Driven Development, przy którego pomocy pozyskuje i systematyzuje wiedzę domenową.

W dzisiejszym odcinku będzie można posłuchać m.in. o:
- krótkiej historii BDD,
- stosowaniu tej techniki w praktyce,
- narzędziach wykorzystujących to podejście,
- praktycznych wskazówkach od Michała, aby taki warsztat był dla wszystkich uczestników wartościowy.</itunes:summary>
      <itunes:subtitle>Do tej pory w rozmowach przewijał się temat EventStormingu, jako narzędzia do rozpoznawania domeny. Dzisiejszy gość, Michał Michaluk, pokazuje jak używa podejścia Behaviour-Driven Development, przy którego pomocy pozyskuje i systematyzuje wiedzę domenową.

W dzisiejszym odcinku będzie można posłuchać m.in. o:
- krótkiej historii BDD,
- stosowaniu tej techniki w praktyce,
- narzędziach wykorzystujących to podejście,
- praktycznych wskazówkach od Michała, aby taki warsztat był dla wszystkich uczestników wartościowy.</itunes:subtitle>
      <itunes:keywords>michał michaluk, behavior driven development, dan north, bdd</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>32</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">a440a640-05df-4378-93ac-98bcbe1ac838</guid>
      <title>31. O refaktoryzacji organizacji z Wojtkiem Ptakiem</title>
      <description><![CDATA[<p>Materiały dodatkowe..</p><p>Prezentacje:</p><ul><li><a href="https://www.youtube.com/watch?v=zkRfDw0N4W8">Dissecting Bounded Contexts</a>, prezentacja Nicka Tune z konferencji DDD Europe 2020</li><li><a href="https://www.youtube.com/watch?v=VjtMt689ql8">Context Maps - a deep dive</a>, prezentacja Michaela Plöd z konferencji KanDDDinsky 2019</li></ul><p>Książki:</p><ul><li><a href="https://www.goodreads.com/book/show/35747076-accelerate">Accelerate: Building and Scaling High-Performing Technology Organizations</a>, Nicole Forsgren,Jez Humble, Gene Kim</li><li><a href="https://www.goodreads.com/book/show/26083308-the-devops-handbook">The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations</a>, Gene Kim, Jez Humble, Patrick Debois, John Willis</li><li><a href="https://www.goodreads.com/book/show/42611483-escaping-the-build-trap">Escaping the Build Trap: How Effective Product Management Creates Real Value</a>, Melissa Perri</li><li><a href="https://www.goodreads.com/book/show/35249663-inspired">Inspired: How to Create Tech Products Customers Love</a>, Marty Cagan</li><li><a href="https://www.goodreads.com/book/show/53481975-empowered">Empowered: Ordinary People, Extraordinary Products</a>, Marty Cagan, Chris Jones</li><li><a href="https://www.goodreads.com/book/show/17255186-the-phoenix-project">The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win</a>, Gene Kim, Kevin Behr, George Spafford</li><li><a href="https://www.goodreads.com/book/show/55782292-strategic-microservices-and-monoliths">Strategic Microservices and Monoliths</a>, Vaughn Vernon, Tomasz Jaskuła</li><li><a href="https://www.goodreads.com/book/show/57573212-learning-domain-driven-design">Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy</a>, Vladik Khononov</li></ul>
]]></description>
      <pubDate>Tue, 25 Jan 2022 00:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/31-w8Ni_Yqy</link>
      <content:encoded><![CDATA[<p>Materiały dodatkowe..</p><p>Prezentacje:</p><ul><li><a href="https://www.youtube.com/watch?v=zkRfDw0N4W8">Dissecting Bounded Contexts</a>, prezentacja Nicka Tune z konferencji DDD Europe 2020</li><li><a href="https://www.youtube.com/watch?v=VjtMt689ql8">Context Maps - a deep dive</a>, prezentacja Michaela Plöd z konferencji KanDDDinsky 2019</li></ul><p>Książki:</p><ul><li><a href="https://www.goodreads.com/book/show/35747076-accelerate">Accelerate: Building and Scaling High-Performing Technology Organizations</a>, Nicole Forsgren,Jez Humble, Gene Kim</li><li><a href="https://www.goodreads.com/book/show/26083308-the-devops-handbook">The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations</a>, Gene Kim, Jez Humble, Patrick Debois, John Willis</li><li><a href="https://www.goodreads.com/book/show/42611483-escaping-the-build-trap">Escaping the Build Trap: How Effective Product Management Creates Real Value</a>, Melissa Perri</li><li><a href="https://www.goodreads.com/book/show/35249663-inspired">Inspired: How to Create Tech Products Customers Love</a>, Marty Cagan</li><li><a href="https://www.goodreads.com/book/show/53481975-empowered">Empowered: Ordinary People, Extraordinary Products</a>, Marty Cagan, Chris Jones</li><li><a href="https://www.goodreads.com/book/show/17255186-the-phoenix-project">The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win</a>, Gene Kim, Kevin Behr, George Spafford</li><li><a href="https://www.goodreads.com/book/show/55782292-strategic-microservices-and-monoliths">Strategic Microservices and Monoliths</a>, Vaughn Vernon, Tomasz Jaskuła</li><li><a href="https://www.goodreads.com/book/show/57573212-learning-domain-driven-design">Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy</a>, Vladik Khononov</li></ul>
]]></content:encoded>
      <enclosure length="93547122" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/1f1e1f1a-9c76-41c4-87f3-e8648ee8e0aa/audio/20cced4f-0e44-4cce-9f86-4b48857873c6/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>31. O refaktoryzacji organizacji z Wojtkiem Ptakiem</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>01:37:24</itunes:duration>
      <itunes:summary>Tym razem odrywamy się na chwilę od kodu i zaczynamy patrzyć wyżej, na poziom całej organizacji. Często to tam kryją się problemy i wyzwania, które później dają o sobie znać zespołowi developerskiemu - wystarczy przypomnieć sobie choćby słynne prawo Melvina Conwaya o odwzorowywaniu w strukturze oprogramowania szlaków komunikacyjnych organizacji. Od 1967 roku dało o sobie znać w niejednym projekcie...

A jest ku temu specjalna okazja, bo gościem 31 odcinka Better Software Design jest Wojtek Ptak, obecnie Chief Technology Office w Talent Alpha, który posiada wieloletnie doświadczenie w pracy z zespołami IT, a w swojej karierze zawodowej pomógł przeprowadzić niejedną organizację przez proces transformacji. Przy jednej z takich zmian miałem przyjemność pracować z Wojtkiem i jego zespołem.

W tym odcinku będzie można posłuchać m.in. o:
- stosowaniu strategicznego Domain-Driven Design do nadawania kierunku rozwoju organizacji,
- prawie Conwaya i jego wpływie na wytwarzane oprogramowanie,
- narzędziach typu Lean Business Canvas, Business Model Canvas, Context Map i innych,
- nie zabraknie oczywiście wskazówek i porad Wojtka, a także odniesień do różnego rodzaju prezentacji i książek.</itunes:summary>
      <itunes:subtitle>Tym razem odrywamy się na chwilę od kodu i zaczynamy patrzyć wyżej, na poziom całej organizacji. Często to tam kryją się problemy i wyzwania, które później dają o sobie znać zespołowi developerskiemu - wystarczy przypomnieć sobie choćby słynne prawo Melvina Conwaya o odwzorowywaniu w strukturze oprogramowania szlaków komunikacyjnych organizacji. Od 1967 roku dało o sobie znać w niejednym projekcie...

A jest ku temu specjalna okazja, bo gościem 31 odcinka Better Software Design jest Wojtek Ptak, obecnie Chief Technology Office w Talent Alpha, który posiada wieloletnie doświadczenie w pracy z zespołami IT, a w swojej karierze zawodowej pomógł przeprowadzić niejedną organizację przez proces transformacji. Przy jednej z takich zmian miałem przyjemność pracować z Wojtkiem i jego zespołem.

W tym odcinku będzie można posłuchać m.in. o:
- stosowaniu strategicznego Domain-Driven Design do nadawania kierunku rozwoju organizacji,
- prawie Conwaya i jego wpływie na wytwarzane oprogramowanie,
- narzędziach typu Lean Business Canvas, Business Model Canvas, Context Map i innych,
- nie zabraknie oczywiście wskazówek i porad Wojtka, a także odniesień do różnego rodzaju prezentacji i książek.</itunes:subtitle>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>31</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">70a9a5de-e43f-42e6-b24c-16cda54cd4e6</guid>
      <title>30. O rozwoju i utrzymaniu oprogramowania w Displate z Wojtkiem Wiktorowiczem</title>
      <description><![CDATA[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ć.  
]]></description>
      <pubDate>Tue, 18 Jan 2022 00:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/30-disO_h22</link>
      <enclosure length="62420266" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/afd0c263-3fed-4877-badc-1bf796b26083/audio/265cb02b-3cb0-449b-8646-772f4cf7688b/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>30. O rozwoju i utrzymaniu oprogramowania w Displate z Wojtkiem Wiktorowiczem</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>01:04:59</itunes:duration>
      <itunes:summary>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ć. </itunes:summary>
      <itunes:subtitle>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ć. </itunes:subtitle>
      <itunes:keywords>displate, software engineering</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>30</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">a34f2f46-ba7c-41e2-afd2-28a06a409e56</guid>
      <title>29. Domain Driven Design Essentials: Domain Service</title>
      <description><![CDATA[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. 
]]></description>
      <pubDate>Tue, 11 Jan 2022 00:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/29-H82_vMF5</link>
      <enclosure length="20189743" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/03601f84-34e7-4adf-9238-74db4e18cd63/audio/c6180eb1-4e4b-43c1-8111-10ae3659e79e/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>29. Domain Driven Design Essentials: Domain Service</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>00:21:01</itunes:duration>
      <itunes:summary>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.</itunes:summary>
      <itunes:subtitle>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.</itunes:subtitle>
      <itunes:keywords>domain service, logika domenowa, domain driven design, serwis domenowy, ddd</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>29</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">bfbc7ed3-a4c7-4b46-9676-f7ca1cb850ac</guid>
      <title>28. O Event Sourcingu z Oskarem Dudyczem</title>
      <description><![CDATA[<p>Materiały dodatkowe:</p><ul><li><a href="https://event-driven.io/pl/">https://event-driven.io/pl/</a>, blog Oskara - pragmatycznie o programowaniu, można tutaj znaleźć serie artykułów o Event Sourcingu, CQRS, architekturze i innych ciekawych tematach</li><li><a href="https://martendb.io">https://martendb.io</a>, implementacja EventStore i bazy dokumentowej dla .NET z wykorzystanie PostgreSQL</li><li><a href="https://www.eventstore.com">https://www.eventstore.com</a>, dedykowana baza danych pod Event Sourcing</li><li><a href="https://github.com/oskardudycz/EventSourcing.NetCore">https://github.com/oskardudycz/EventSourcing.NetCore</a>, praktyczne przykłady, ćwiczenia oraz tutoriale o tym jak budować aplikacje z użyciem Event Sourcing w .NET.</li><li><a href="https://www.architecture-weekly.com">https://www.architecture-weekly.com</a>, cotygodniowy zestaw materiałów i linków na temat szeroko pojętej Architektury Oprogramowania</li><li><a href="https://www.eventstore.com/blog/keep-your-streams-short-temporal-modelling-for-fast-reads-and-optimal-data-retention">https://www.eventstore.com/blog/keep-your-streams-short-temporal-modelling-for-fast-reads-and-optimal-data-retention</a>, artykuł Oskara o temporal modelingu i krótkich strumieniach zdarzeń</li></ul>
]]></description>
      <pubDate>Tue, 4 Jan 2022 00:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/28-fZewlAaO</link>
      <content:encoded><![CDATA[<p>Materiały dodatkowe:</p><ul><li><a href="https://event-driven.io/pl/">https://event-driven.io/pl/</a>, blog Oskara - pragmatycznie o programowaniu, można tutaj znaleźć serie artykułów o Event Sourcingu, CQRS, architekturze i innych ciekawych tematach</li><li><a href="https://martendb.io">https://martendb.io</a>, implementacja EventStore i bazy dokumentowej dla .NET z wykorzystanie PostgreSQL</li><li><a href="https://www.eventstore.com">https://www.eventstore.com</a>, dedykowana baza danych pod Event Sourcing</li><li><a href="https://github.com/oskardudycz/EventSourcing.NetCore">https://github.com/oskardudycz/EventSourcing.NetCore</a>, praktyczne przykłady, ćwiczenia oraz tutoriale o tym jak budować aplikacje z użyciem Event Sourcing w .NET.</li><li><a href="https://www.architecture-weekly.com">https://www.architecture-weekly.com</a>, cotygodniowy zestaw materiałów i linków na temat szeroko pojętej Architektury Oprogramowania</li><li><a href="https://www.eventstore.com/blog/keep-your-streams-short-temporal-modelling-for-fast-reads-and-optimal-data-retention">https://www.eventstore.com/blog/keep-your-streams-short-temporal-modelling-for-fast-reads-and-optimal-data-retention</a>, artykuł Oskara o temporal modelingu i krótkich strumieniach zdarzeń</li></ul>
]]></content:encoded>
      <enclosure length="89757664" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/35b168b9-56e2-43d0-a86a-92a9d4382d99/audio/3e3cdec2-6218-4a41-9d77-bc354588eabd/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>28. O Event Sourcingu z Oskarem Dudyczem</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>01:33:30</itunes:duration>
      <itunes:summary>Event Sourcing nie jest nową i zaskakującą techniką, a jednak wciąż budzi wiele różnych emocji. Wspólnie z dzisiejszym gościem, Oskarem Dudyczem, pracującym na co dzień jako Developer Advocate w EventStore, staramy się rozłożyć ten koncept na czynniki pierwsze.

W tym odcinku razem z Oskarem rozmawiamy m.in. o:
- czym właściwie jest Event Sourcing?
- możliwych do osiągnięcia korzyściach,
- powiązanej terminologii i innych technikach,
- wzorcu CQRS,
- pułapkach i wyzwaniach modelowania zdarzeniowego, w tym oczywiście o nieśmiertelnym wersjonowaniu zdarzeń
- wartych uwagi best-practices.

Nie zabrakło oczywiście kilku anegdot i ciekawostek z pola walki...</itunes:summary>
      <itunes:subtitle>Event Sourcing nie jest nową i zaskakującą techniką, a jednak wciąż budzi wiele różnych emocji. Wspólnie z dzisiejszym gościem, Oskarem Dudyczem, pracującym na co dzień jako Developer Advocate w EventStore, staramy się rozłożyć ten koncept na czynniki pierwsze.

W tym odcinku razem z Oskarem rozmawiamy m.in. o:
- czym właściwie jest Event Sourcing?
- możliwych do osiągnięcia korzyściach,
- powiązanej terminologii i innych technikach,
- wzorcu CQRS,
- pułapkach i wyzwaniach modelowania zdarzeniowego, w tym oczywiście o nieśmiertelnym wersjonowaniu zdarzeń
- wartych uwagi best-practices.

Nie zabrakło oczywiście kilku anegdot i ciekawostek z pola walki...</itunes:subtitle>
      <itunes:keywords>events, persystencja, oskar dudycz, zdarzenie, es, marten, event sourcing, event, event-driven architecture, event store, cqrs</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>28</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">335eb4a2-5909-40fe-9875-b275d985e01f</guid>
      <title>27. O wszystkim i o niczym z Kubą Pilimonem</title>
      <description><![CDATA[<p>Materiały dodatkowe:</p><ul><li> <a href="https://www.youtube.com/watch?v=eEUVA0lnKQ0&list=PLlpgO2wWvQHZn-jWzKN1ISw6EdiooBMXO&index=13">DevKuchnia #11 z Mariuszem Gilem o żywocie konsultanta</a></li><li><a href="https://www.youtube.com/watch?v=D39bjCrzZm4&list=PLlpgO2wWvQHZn-jWzKN1ISw6EdiooBMXO&index=14">DevKuchnia #12 z Bartkiem Słotą o żywocie konsultanta</a></li><li><a href="https://www.goodreads.com/book/show/566213.The_Secrets_of_Consulting">The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully, Gerald M. Weinberg</a>, ciekawa pozycja o byciu konsultantem, jest w niej sporo wartych uwagi wskazówek przydatnych nie tylko konsultantom,</li><li><a href="https://www.goodreads.com/book/show/714345.More_Secrets_of_Consulting">More Secrets of Consulting: The Consultant's Tool Kit, Gerald M. Weinberg</a>, kontynuacja poprzedniej pozycji</li></ul>
]]></description>
      <pubDate>Tue, 21 Dec 2021 00:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/27-o0Ez4re_</link>
      <content:encoded><![CDATA[<p>Materiały dodatkowe:</p><ul><li> <a href="https://www.youtube.com/watch?v=eEUVA0lnKQ0&list=PLlpgO2wWvQHZn-jWzKN1ISw6EdiooBMXO&index=13">DevKuchnia #11 z Mariuszem Gilem o żywocie konsultanta</a></li><li><a href="https://www.youtube.com/watch?v=D39bjCrzZm4&list=PLlpgO2wWvQHZn-jWzKN1ISw6EdiooBMXO&index=14">DevKuchnia #12 z Bartkiem Słotą o żywocie konsultanta</a></li><li><a href="https://www.goodreads.com/book/show/566213.The_Secrets_of_Consulting">The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully, Gerald M. Weinberg</a>, ciekawa pozycja o byciu konsultantem, jest w niej sporo wartych uwagi wskazówek przydatnych nie tylko konsultantom,</li><li><a href="https://www.goodreads.com/book/show/714345.More_Secrets_of_Consulting">More Secrets of Consulting: The Consultant's Tool Kit, Gerald M. Weinberg</a>, kontynuacja poprzedniej pozycji</li></ul>
]]></content:encoded>
      <enclosure length="96758898" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/0428226e-268b-491e-bae0-0251ff4104f4/audio/2b8515c2-461f-4dde-a63f-8cc4ccf7498b/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>27. O wszystkim i o niczym z Kubą Pilimonem</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>01:40:47</itunes:duration>
      <itunes:summary>Po długiej przerwie czas wrócić do bardziej cyklicznych publikacji kolejnych odcinków. Na koniec roku pewnie mało kto myśli o niuansach modelowania, zapraszam więc na dłuższą rozmowę w bardzo luźnej atmosferze z cyklu &quot;5 pytań do...&quot;. Dzisiejszym gościem jest, już po raz kolejny, Kuba Pilimon, z którym rozmawiamy m.in. o wygenerowanych stratach w projektach, hashtagu #PodróżujZMariuszem i o tym, jak to się stało, że oglądał własne wystąpienie stojąc z tyłu sali, wygenerowanych stratach w projektach.</itunes:summary>
      <itunes:subtitle>Po długiej przerwie czas wrócić do bardziej cyklicznych publikacji kolejnych odcinków. Na koniec roku pewnie mało kto myśli o niuansach modelowania, zapraszam więc na dłuższą rozmowę w bardzo luźnej atmosferze z cyklu &quot;5 pytań do...&quot;. Dzisiejszym gościem jest, już po raz kolejny, Kuba Pilimon, z którym rozmawiamy m.in. o wygenerowanych stratach w projektach, hashtagu #PodróżujZMariuszem i o tym, jak to się stało, że oglądał własne wystąpienie stojąc z tyłu sali, wygenerowanych stratach w projektach.</itunes:subtitle>
      <itunes:keywords>better software design, mariusz gil, kuba pilimon</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>27</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">6bab9059-527c-4bd1-88dc-35540d4cd6a3</guid>
      <title>26. O perspektywach Being, Behaving, Becoming</title>
      <description><![CDATA["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. 
]]></description>
      <pubDate>Mon, 28 Jun 2021 23:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/26-Rc7zqkMZ</link>
      <enclosure length="11474303" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/29456d14-3a2a-4cd8-aa93-a12ac63d4853/audio/93a6bdf0-f867-4f74-b93a-667d721b24cd/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>26. O perspektywach Being, Behaving, Becoming</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>00:11:55</itunes:duration>
      <itunes:summary>&quot;There are only two hard things in Computer Science: cache invalidation and naming things&quot; - 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.</itunes:summary>
      <itunes:subtitle>&quot;There are only two hard things in Computer Science: cache invalidation and naming things&quot; - 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.</itunes:subtitle>
      <itunes:keywords>nazewnictwo obiektów, software development, perspectives, modelowanie, domain driven design, being behaving becoming, perspektywy, naming things</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>26</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">2b136a7a-562d-463f-9bf7-87425b3bd5e1</guid>
      <title>25. O modelu i modelowaniu ze Sławkiem Sobótką</title>
      <description><![CDATA[<p>Materiały dodatkowe:</p><ul><li><a href="https://www.youtube.com/watch?v=iaLeKHbspLg">Model jest wszystkim czego potrzebujesz</a>, prezentacja z konferencji Confitura 2013</li><li> <a href="https://www.youtube.com/channel/UCNeyWe1dv6dRl9iypnFqHdA/featured">DevKuchnia</a>, czyli piątkowe spotkania w symulatorze kuchni</li></ul>
]]></description>
      <pubDate>Mon, 14 Jun 2021 23:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/25-k_XAj1wr</link>
      <content:encoded><![CDATA[<p>Materiały dodatkowe:</p><ul><li><a href="https://www.youtube.com/watch?v=iaLeKHbspLg">Model jest wszystkim czego potrzebujesz</a>, prezentacja z konferencji Confitura 2013</li><li> <a href="https://www.youtube.com/channel/UCNeyWe1dv6dRl9iypnFqHdA/featured">DevKuchnia</a>, czyli piątkowe spotkania w symulatorze kuchni</li></ul>
]]></content:encoded>
      <enclosure length="65598695" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/b574deed-4705-471f-b44d-1f0e96a02c5b/audio/cb5b4ed2-9591-4650-8790-603b2709d1ef/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>25. O modelu i modelowaniu ze Sławkiem Sobótką</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>01:08:18</itunes:duration>
      <itunes:summary>Architektura i model - dwa proste słowa, które bez kontekstu w zasadzie nie wiadomo co oznaczają. Dziś, wspólnie z moim gościem, Sławkiem Sobótką postaramy się porozmawiać właśnie o modelu i sposobach modelowania. W końcu cytując Sławka &quot;model jest wszystkim czego potrzebujesz&quot;... Ale tym razem postaramy się cofnąć trochę czas i wrócić myślami aż do 2013 roku, gdy hasło EventStorming nie było jeszcze znane.

W tym odcinku wspólnie ze Sławkiem rozmawiamy o:
- technikach modelowania domenowego
- kontekście modelu i powiązanym z nim językiem
- prostych sposobach na utrwalanie pozyskanej wiedzy</itunes:summary>
      <itunes:subtitle>Architektura i model - dwa proste słowa, które bez kontekstu w zasadzie nie wiadomo co oznaczają. Dziś, wspólnie z moim gościem, Sławkiem Sobótką postaramy się porozmawiać właśnie o modelu i sposobach modelowania. W końcu cytując Sławka &quot;model jest wszystkim czego potrzebujesz&quot;... Ale tym razem postaramy się cofnąć trochę czas i wrócić myślami aż do 2013 roku, gdy hasło EventStorming nie było jeszcze znane.

W tym odcinku wspólnie ze Sławkiem rozmawiamy o:
- technikach modelowania domenowego
- kontekście modelu i powiązanym z nim językiem
- prostych sposobach na utrwalanie pozyskanej wiedzy</itunes:subtitle>
      <itunes:keywords>sławomir sobótka, domain driven design, software, software modeling, ddd, bottega it minds, domain experts</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>25</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">d99b10a6-c97b-4d29-b0c3-e8c8f1d5435f</guid>
      <title>24. O Aggregates By Example, analiza procesu wypożyczenia ze Sławkiem Sobótką</title>
      <description><![CDATA[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 
]]></description>
      <pubDate>Tue, 12 Jan 2021 00:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/24-kgi2SI8s</link>
      <enclosure length="75831368" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/96b24057-fc4d-4613-b323-2843b01dbdad/audio/b7ce0b6a-fa21-4ec8-bc83-cc75cd6250ed/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>24. O Aggregates By Example, analiza procesu wypożyczenia ze Sławkiem Sobótką</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>01:18:57</itunes:duration>
      <itunes:summary>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</itunes:summary>
      <itunes:subtitle>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</itunes:subtitle>
      <itunes:keywords>sławomir sobótka, tactical ddd, sławek sobótka, aggregates, domain driven design, ddd, bottega it minds</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>24</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">1711f2db-975d-499c-970b-7213457773a9</guid>
      <title>23. O 4 poziomach zdarzeń</title>
      <description><![CDATA[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.  
]]></description>
      <pubDate>Tue, 22 Dec 2020 00:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/23-B_vB3U3L</link>
      <enclosure length="18873977" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/c4ee054c-8c85-4788-a2f6-9cd2308afa1b/audio/4738edbe-4a59-47ef-87b1-0b9cb9df9f6e/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>23. O 4 poziomach zdarzeń</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>00:19:38</itunes:duration>
      <itunes:summary>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. </itunes:summary>
      <itunes:subtitle>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. </itunes:subtitle>
      <itunes:keywords>process level eventstorming, big picture eventstorming, event, eventstorming</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>23</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">af291c93-50e4-41c7-8f38-e1d5dc057232</guid>
      <title>22. O Aggregates By Example, kontynuacja analizy agregatu</title>
      <description><![CDATA[<p>Materiały dodatkowe:</p><ul><li><a href="https://bettersoftwaredesign.pl/episodes/2">BSD #2, O Aggregates By Example, analiza procesu rezerwacji z Kubą Pilimonem</a>, odcinek podcastu, w którym razem z Kubą analizujemy kilka propozycji agregatów</li><li><a href="https://github.com/mariuszgil/aggregates-by-example">Repozytorium Aggregates By Example</a>, repozytorium z przykładami implementacji różnych agregatów</li><li><a href="https://youtu.be/uDrAYXo7spA?t=2743">O odkrywaniu granic - heurystyki ważnych decyzji, Kuba Pilimon</a>, prezentacja z naszego wspólnego eventu z Piątkami na Produkcji, w której Kuba przedstawia heurystyki znajdowania granic w systemach</li></ul>
]]></description>
      <pubDate>Tue, 24 Nov 2020 00:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/22-4dbmTuO8</link>
      <content:encoded><![CDATA[<p>Materiały dodatkowe:</p><ul><li><a href="https://bettersoftwaredesign.pl/episodes/2">BSD #2, O Aggregates By Example, analiza procesu rezerwacji z Kubą Pilimonem</a>, odcinek podcastu, w którym razem z Kubą analizujemy kilka propozycji agregatów</li><li><a href="https://github.com/mariuszgil/aggregates-by-example">Repozytorium Aggregates By Example</a>, repozytorium z przykładami implementacji różnych agregatów</li><li><a href="https://youtu.be/uDrAYXo7spA?t=2743">O odkrywaniu granic - heurystyki ważnych decyzji, Kuba Pilimon</a>, prezentacja z naszego wspólnego eventu z Piątkami na Produkcji, w której Kuba przedstawia heurystyki znajdowania granic w systemach</li></ul>
]]></content:encoded>
      <enclosure length="36137085" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/9781db5c-ca3c-4fcb-a048-741e2ae802db/audio/f13c201d-d261-40f2-ba07-cfa2acfa67c5/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>22. O Aggregates By Example, kontynuacja analizy agregatu</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>00:37:37</itunes:duration>
      <itunes:summary>W 2 odcinku Better Software Design analizowaliśmy z Kubą Pilimonem proces rezerwacji w kinie i przedstawiliśmy kilka propozycji agregatów. Dziś kontynuujemy ten temat wchodząc głębiej w strukturę naszej finalnej propozycji, czyli Rezerwacji jako kolekcji miejsc.
</itunes:summary>
      <itunes:subtitle>W 2 odcinku Better Software Design analizowaliśmy z Kubą Pilimonem proces rezerwacji w kinie i przedstawiliśmy kilka propozycji agregatów. Dziś kontynuujemy ten temat wchodząc głębiej w strukturę naszej finalnej propozycji, czyli Rezerwacji jako kolekcji miejsc.
</itunes:subtitle>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>22</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">d4a76015-1d2f-412a-93af-631506fb9ef1</guid>
      <title>21. O refaktoryzacji legacy z Andrzejem Krzywdą i Robertem Pankowieckim</title>
      <description><![CDATA[<p>Materiały dodatkowe:</p><ul><li><a href="https://www.amazon.com/exec/obidos/ASIN/0887307280/clientsource-20">The E-Myth Revisited: Why Most Small Businesses Don't Work and What to Do About It</a>, Michael E. Gerber </li><li><a href="https://kariera.future-processing.pl/blog/object-oriented-metrics-by-robert-martin/">Object-oriented metrics by Robert Martin</a>, ciekawe przedstawienie 5 metryk OO Uncle Boba odnośnie couplingu i pochodnych wartości</li></ul>
]]></description>
      <pubDate>Tue, 10 Nov 2020 00:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/21-DSdCD0rt</link>
      <content:encoded><![CDATA[<p>Materiały dodatkowe:</p><ul><li><a href="https://www.amazon.com/exec/obidos/ASIN/0887307280/clientsource-20">The E-Myth Revisited: Why Most Small Businesses Don't Work and What to Do About It</a>, Michael E. Gerber </li><li><a href="https://kariera.future-processing.pl/blog/object-oriented-metrics-by-robert-martin/">Object-oriented metrics by Robert Martin</a>, ciekawe przedstawienie 5 metryk OO Uncle Boba odnośnie couplingu i pochodnych wartości</li></ul>
]]></content:encoded>
      <enclosure length="59402891" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/2d038c27-97ca-442f-975a-bcd76c77cc19/audio/2b9f5606-5eab-4183-bd33-890b61037b9d/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>21. O refaktoryzacji legacy z Andrzejem Krzywdą i Robertem Pankowieckim</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>01:01:51</itunes:duration>
      <itunes:summary>Temat refaktoryzacji pojawił się już w podkaście, w odcinku BSD #10 i spotkał się z ogromnym wręcz zainteresowaniem. Wówczas wraz z Andrzejem Krzywdą skupiliśmy się na styku technologii i biznesu rozmawiając m.in. sposobach sprzedania całego procesu klientowi. W dzisiejszym odcinku  będziemy kontynuować te zagadnienia, ale zanurzymy się także trochę w świat technologii. A do grona rozmówców dołączył oprócz Andrzeja Krzywdy także Robert Pankowiecki z Arkency.

Nasza rozmowa została nagrana w styczniu 2018, ale niewiele (jeśli w ogóle) tematów się zdezaktualizowało. Na pewno zmianie uległ sposób w jaki nagrywam podcast, ale da się bardzo szybko zauważyć... </itunes:summary>
      <itunes:subtitle>Temat refaktoryzacji pojawił się już w podkaście, w odcinku BSD #10 i spotkał się z ogromnym wręcz zainteresowaniem. Wówczas wraz z Andrzejem Krzywdą skupiliśmy się na styku technologii i biznesu rozmawiając m.in. sposobach sprzedania całego procesu klientowi. W dzisiejszym odcinku  będziemy kontynuować te zagadnienia, ale zanurzymy się także trochę w świat technologii. A do grona rozmówców dołączył oprócz Andrzeja Krzywdy także Robert Pankowiecki z Arkency.

Nasza rozmowa została nagrana w styczniu 2018, ale niewiele (jeśli w ogóle) tematów się zdezaktualizowało. Na pewno zmianie uległ sposób w jaki nagrywam podcast, ale da się bardzo szybko zauważyć... </itunes:subtitle>
      <itunes:keywords>bounded context, legacy, domain driven design, arkency, refactoring, refaktoryzacja</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>21</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">f1dad7ff-f24b-4522-8723-912186224efb</guid>
      <title>20. O grafach i Neo4j z Jarkiem Pałką</title>
      <description><![CDATA[<p>Materiały dodatkowe:</p><ul><li><a href="https://neo4j.com">Neo4j.com</a></li><li><a href="https://console.neo4j.org">Neo4j console</a>, konsola online, gdzie można się pobawić przykładowym grafem bezpośrednio z przeglądarki</li><li><a href="https://neo4j.com/graphgists/">Neo4j GraphGists</a>, zestaw świetnych przykładów użycia grafów</li><li><a href="https://portal.graphgist.org/graph_gists">GraphGist portal</a>, jeszcze więcej przykładów użycia</li><li><a href="https://neo4j.com/docs/cypher-refcard/current/">Neo4j Cypher Refcard</a>, refcard języka Cypher</li><li><a href="https://www.icij.org/investigations/panama-papers/">Panama Papers</a>, strona główna International Consortium of Investigative Journalists z artykułami odnośnie całej afery</li><li><a href="https://offshoreleaks.icij.org/pages/database">Offshore Leaks Database</a>, datasety ICIJ nie tylko dla Panama Papers, ale także Paradise Papers, Bahama i Offshore Leaks</li><li><a href="https://hub.docker.com/r/ryguyrg/neo4j-panama-papers">ryguyrg/neo4j-panama-papers</a>, przykładowy docker z importem danych Panama Papers do bazy </li></ul><p>Wpisy na blogu teamu Neo4j odnośnie afery Panama Papers:</p><ul><li><a href="https://neo4j.com/blog/panama-papers-graph-database-download/">The Panama Papers Graph Database Is Now Available for Download</a></li><li><a href="https://neo4j.com/blog/icij-neo4j-unravel-panama-papers/">How the ICIJ Used Neo4j to Unravel the Panama Paper</a></li><li><a href="https://neo4j.com/blog/analyzing-panama-papers-neo4j/">Analyzing the Panama Papers with Neo4j: Data Models, Queries & More</a></li><li><a href="https://neo4j.com/blog/panama-papers/">The Panama Papers: Why It Couldn’t Have Happened Ten Years Ago</a></li></ul><p>Na koniec polecę jeszcze darmową książeczkę od O'Reilly Media, Graph Databases. Można ją pobrać ze strony <a href="https://graphdatabases.com">https://graphdatabases.com</a>.</p>
]]></description>
      <pubDate>Tue, 27 Oct 2020 00:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/20-kY08dPAy</link>
      <content:encoded><![CDATA[<p>Materiały dodatkowe:</p><ul><li><a href="https://neo4j.com">Neo4j.com</a></li><li><a href="https://console.neo4j.org">Neo4j console</a>, konsola online, gdzie można się pobawić przykładowym grafem bezpośrednio z przeglądarki</li><li><a href="https://neo4j.com/graphgists/">Neo4j GraphGists</a>, zestaw świetnych przykładów użycia grafów</li><li><a href="https://portal.graphgist.org/graph_gists">GraphGist portal</a>, jeszcze więcej przykładów użycia</li><li><a href="https://neo4j.com/docs/cypher-refcard/current/">Neo4j Cypher Refcard</a>, refcard języka Cypher</li><li><a href="https://www.icij.org/investigations/panama-papers/">Panama Papers</a>, strona główna International Consortium of Investigative Journalists z artykułami odnośnie całej afery</li><li><a href="https://offshoreleaks.icij.org/pages/database">Offshore Leaks Database</a>, datasety ICIJ nie tylko dla Panama Papers, ale także Paradise Papers, Bahama i Offshore Leaks</li><li><a href="https://hub.docker.com/r/ryguyrg/neo4j-panama-papers">ryguyrg/neo4j-panama-papers</a>, przykładowy docker z importem danych Panama Papers do bazy </li></ul><p>Wpisy na blogu teamu Neo4j odnośnie afery Panama Papers:</p><ul><li><a href="https://neo4j.com/blog/panama-papers-graph-database-download/">The Panama Papers Graph Database Is Now Available for Download</a></li><li><a href="https://neo4j.com/blog/icij-neo4j-unravel-panama-papers/">How the ICIJ Used Neo4j to Unravel the Panama Paper</a></li><li><a href="https://neo4j.com/blog/analyzing-panama-papers-neo4j/">Analyzing the Panama Papers with Neo4j: Data Models, Queries & More</a></li><li><a href="https://neo4j.com/blog/panama-papers/">The Panama Papers: Why It Couldn’t Have Happened Ten Years Ago</a></li></ul><p>Na koniec polecę jeszcze darmową książeczkę od O'Reilly Media, Graph Databases. Można ją pobrać ze strony <a href="https://graphdatabases.com">https://graphdatabases.com</a>.</p>
]]></content:encoded>
      <enclosure length="64058385" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/6479bfac-adc1-48e3-b1a0-d7327bf0cf41/audio/069fc025-7992-4f04-bbc0-48df0dd1eb57/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>20. O grafach i Neo4j z Jarkiem Pałką</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>01:06:42</itunes:duration>
      <itunes:summary>Tworzenie software&apos;u to nie tylko modelowanie domeny, ale także późniejsze jej połączenie z warstwą infrastruktury. Wraz z Jarkiem Pałką zapraszam więc do odsłuchania odcinka, w którym rozmawiamy o grafowej bazie danych Neo4j, a także o różnicach pomiędzy modelem relacyjnym i grafowym. </itunes:summary>
      <itunes:subtitle>Tworzenie software&apos;u to nie tylko modelowanie domeny, ale także późniejsze jej połączenie z warstwą infrastruktury. Wraz z Jarkiem Pałką zapraszam więc do odsłuchania odcinka, w którym rozmawiamy o grafowej bazie danych Neo4j, a także o różnicach pomiędzy modelem relacyjnym i grafowym. </itunes:subtitle>
      <itunes:keywords>algorytmy grafowe, nosql, graphs, nosql databases, grafy, neo4j</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>20</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">7cbb3fc3-2fb5-44a4-9dbd-d0ae2c7cbd20</guid>
      <title>19. O nazewnictwie eventów</title>
      <description><![CDATA[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.

 
]]></description>
      <pubDate>Mon, 19 Oct 2020 23:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/19-9mYsC3oa</link>
      <enclosure length="17157804" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/b0a3f5e8-2184-46ce-9514-d2967fc01353/audio/88b6bcd3-858a-489d-bde2-a0f9d3923f37/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>19. O nazewnictwie eventów</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>00:17:51</itunes:duration>
      <itunes:summary>Phil Karlton dawno temu powiedział swoje słynne zdanie: &quot;There are only two hard things in Computer Science: cache invalidation and naming things&quot;. 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.

</itunes:summary>
      <itunes:subtitle>Phil Karlton dawno temu powiedział swoje słynne zdanie: &quot;There are only two hard things in Computer Science: cache invalidation and naming things&quot;. 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.

</itunes:subtitle>
      <itunes:keywords>events, domain driven design, heuristics, event, programming</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>19</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">1f6d7df1-f01d-4fa9-9196-18f93c92ace5</guid>
      <title>18. About the past, present and future of IT with Uncle Bob</title>
      <description><![CDATA[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. 
]]></description>
      <pubDate>Mon, 12 Oct 2020 23:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/18-e8W5EyJh</link>
      <enclosure length="44923411" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/e7052cd0-c158-4a6c-a461-233f536e4ab9/audio/a127ee15-651c-4f3c-bbed-699a0e28d962/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>18. About the past, present and future of IT with Uncle Bob</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>00:46:45</itunes:duration>
      <itunes:summary>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.</itunes:summary>
      <itunes:subtitle>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.</itunes:subtitle>
      <itunes:keywords>developers, development, agile manifesto, agile, it industry, uncle bob, programming</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>18</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">0897eb76-cc04-446a-91aa-6690e2c99020</guid>
      <title>17. O prawie Demeter, Clean Code i zasadach SOLID z Piotrem Stawirejem</title>
      <description><![CDATA[<p>Materiały dodatkowe:</p><ul><li><a href="https://en.wikipedia.org/wiki/Law_of_Demeter">Definicja Law of Demeter, Wikipedia</a></li><li><a href="https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882">Clean Code: A Handbook of Agile Software Craftsmanship, Robert C. Martin</a>, klasyczna książka Uncle Boba na temat czystego kodu</li><li><a href="https://www.amazon.com/Agile-Principles-Patterns-Practices-PRACTS-ebook/dp/B0051TM4GI/ref=sr_1_5">Agile Principles, Patterns, and Practices in C#, Robert C. Martin, Mikah Martin</a></li><li><a href="https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530/ref=sr_1_1?dchild=1&keywords=tdd+by+example&qid=1599161437&s=books&sr=1-1">Test Driven Development: By Example, Kent Beck</a>, książka, która pojawiła się już przy okazji poprzedniego odcinka o Test Driven Development</li><li><a href="https://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215/ref=sr_1_1">Domain-Driven Design: Tackling Complexity in the Heart of Software, Eric Evans</a>, z rekomendacją od Piotra, aby szczególną uwagę zwrócić na rozdział 2 tej książki, czyli "Communication and the Use of Language"</li></ul><p>Wspomniane przez nas repozytorium z ciekawie zaimplementowaną piramidą testów i nawiązujące do tematyki odcinka można znaleźć na BitBuckecie Piotra, <a href="https://bitbucket.org/piotrstawirej/financial-system/src/master/">https://bitbucket.org/piotrstawirej/financial-system/src/master/</a>.</p>
]]></description>
      <pubDate>Mon, 5 Oct 2020 23:00:00 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/17-syHJ1Ala</link>
      <content:encoded><![CDATA[<p>Materiały dodatkowe:</p><ul><li><a href="https://en.wikipedia.org/wiki/Law_of_Demeter">Definicja Law of Demeter, Wikipedia</a></li><li><a href="https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882">Clean Code: A Handbook of Agile Software Craftsmanship, Robert C. Martin</a>, klasyczna książka Uncle Boba na temat czystego kodu</li><li><a href="https://www.amazon.com/Agile-Principles-Patterns-Practices-PRACTS-ebook/dp/B0051TM4GI/ref=sr_1_5">Agile Principles, Patterns, and Practices in C#, Robert C. Martin, Mikah Martin</a></li><li><a href="https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530/ref=sr_1_1?dchild=1&keywords=tdd+by+example&qid=1599161437&s=books&sr=1-1">Test Driven Development: By Example, Kent Beck</a>, książka, która pojawiła się już przy okazji poprzedniego odcinka o Test Driven Development</li><li><a href="https://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215/ref=sr_1_1">Domain-Driven Design: Tackling Complexity in the Heart of Software, Eric Evans</a>, z rekomendacją od Piotra, aby szczególną uwagę zwrócić na rozdział 2 tej książki, czyli "Communication and the Use of Language"</li></ul><p>Wspomniane przez nas repozytorium z ciekawie zaimplementowaną piramidą testów i nawiązujące do tematyki odcinka można znaleźć na BitBuckecie Piotra, <a href="https://bitbucket.org/piotrstawirej/financial-system/src/master/">https://bitbucket.org/piotrstawirej/financial-system/src/master/</a>.</p>
]]></content:encoded>
      <enclosure length="62158207" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/6e05cdd0-1644-44eb-848f-e8630e465306/audio/779a1852-6ce5-475a-8cee-ed315e49cd91/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>17. O prawie Demeter, Clean Code i zasadach SOLID z Piotrem Stawirejem</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>01:04:43</itunes:duration>
      <itunes:summary>Czysty, prosty i łatwy do utrzymania kod można tworzyć na wiele sposobów. Dziś odsuniemy Domain Driven Design troszeczkę na bok i wspólnie z Piotrem Stawirejem skupimy się na innych wzorcach, prawach i zasadach pozwalających na tworzenie takiego właśnie designu kodu. 

W tym odcinku będzie można więc posłuchać o:
- prawie Demeter,
- zasadach SOLID, a przy okazji i anty-zasadach STUPID, których należy się wystrzegać,
- Clean Code Uncle Boba.

Pojawi się także wiele tematów pobocznych, takich jak np. wzorce General Responsibilities Assignment Software Patterns czy metryki LCOM, których dotknęliśmy w trakcie rozmowy. </itunes:summary>
      <itunes:subtitle>Czysty, prosty i łatwy do utrzymania kod można tworzyć na wiele sposobów. Dziś odsuniemy Domain Driven Design troszeczkę na bok i wspólnie z Piotrem Stawirejem skupimy się na innych wzorcach, prawach i zasadach pozwalających na tworzenie takiego właśnie designu kodu. 

W tym odcinku będzie można więc posłuchać o:
- prawie Demeter,
- zasadach SOLID, a przy okazji i anty-zasadach STUPID, których należy się wystrzegać,
- Clean Code Uncle Boba.

Pojawi się także wiele tematów pobocznych, takich jak np. wzorce General Responsibilities Assignment Software Patterns czy metryki LCOM, których dotknęliśmy w trakcie rozmowy. </itunes:subtitle>
      <itunes:keywords>clean code, demeter law, general responsibility assignment software patterns, prawo demeter, uncle bob, grasp, solid</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>17</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">69c6930f-96fd-42ce-a392-ece62534e745</guid>
      <title>16. O Test Driven Development z Kubą Pilimonem</title>
      <description><![CDATA[<p>Materiały dodatkowe:</p><ul><li><a href="http://www.growing-object-oriented-software.com">Growing Object-Oriented Software Guided by Tests, Steve Freeman, Pryce</a>, klasyka gatunku na temat implementacji systemów w podejściu Object-Oriented i Test Driven Development</li><li><a href="https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530">Test Driven Development: By Example, Kent Beck</a>, druga z klasycznych książek na temat TDD</li><li><a href="http://xunitpatterns.com/Mocks,%20Fakes,%20Stubs%20and%20Dummies.html">Mocks, Fakes, Stubs and Dummies, xUnitPatterns.com</a>, zestawienie terminologii Test Doubles w literaturze </li></ul>
]]></description>
      <pubDate>Mon, 28 Sep 2020 23:00:12 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/16-glgb6YSL</link>
      <content:encoded><![CDATA[<p>Materiały dodatkowe:</p><ul><li><a href="http://www.growing-object-oriented-software.com">Growing Object-Oriented Software Guided by Tests, Steve Freeman, Pryce</a>, klasyka gatunku na temat implementacji systemów w podejściu Object-Oriented i Test Driven Development</li><li><a href="https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530">Test Driven Development: By Example, Kent Beck</a>, druga z klasycznych książek na temat TDD</li><li><a href="http://xunitpatterns.com/Mocks,%20Fakes,%20Stubs%20and%20Dummies.html">Mocks, Fakes, Stubs and Dummies, xUnitPatterns.com</a>, zestawienie terminologii Test Doubles w literaturze </li></ul>
]]></content:encoded>
      <enclosure length="62898663" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/d2c75390-05a2-4872-b48e-b9b58e26cd2d/audio/6b0403d4-654a-48f1-b79e-63b07d21a2e7/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>16. O Test Driven Development z Kubą Pilimonem</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>01:05:30</itunes:duration>
      <itunes:summary>Kontynuując temat testów jednostkowych i Test Driven Development wraz z Kubą Pilimonem wzięliśmy na warsztat kilka często pojawiających się pytań dookoła tych metod. 

W tym odcinku będzie więc można posłuchać m.in. o:
- szkole londyńskiej i szkole Chicago w Test Driven Development,
- sytuacjach, kiedy nie warto stosować TDD i dlaczego ma to sens,
- sposobach testowania zmiany stan agregatu,
- dobieraniu piramidy testów do projektu,
- technikach testowania z uwzględnieniem bazy danych.</itunes:summary>
      <itunes:subtitle>Kontynuując temat testów jednostkowych i Test Driven Development wraz z Kubą Pilimonem wzięliśmy na warsztat kilka często pojawiających się pytań dookoła tych metod. 

W tym odcinku będzie więc można posłuchać m.in. o:
- szkole londyńskiej i szkole Chicago w Test Driven Development,
- sytuacjach, kiedy nie warto stosować TDD i dlaczego ma to sens,
- sposobach testowania zmiany stan agregatu,
- dobieraniu piramidy testów do projektu,
- technikach testowania z uwzględnieniem bazy danych.</itunes:subtitle>
      <itunes:keywords>test driven development, test doubles, tdd</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>16</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">9e55120d-17dd-415c-86a9-bde55913c9b7</guid>
      <title>15. O Test Smells z Olą Kunysz</title>
      <description><![CDATA[<p>Materiały dodatkowe:</p><ul><li><a href="http://xunitpatterns.com/Test%20Smells.html">xUnitPatterns Test Smells</a>, lista Test Smells według Gerarda Meszarosa</li><li><a href="https://testsmells.github.io/pages/testsmells.html">Software Unit Tests Smells</a>, uzupełnienie listy o inne smelle i jedocześnie tool do ich wykrywania</li><li><a href="http://pitest.org">PIT Mutation Testing</a>, testowanie mutacyjne w Java</li><li><a href="https://infection.github.io">Infectionn PHP</a>, testowanie mutacyjne w PHP</li><li><a href="https://github.com/stryker-mutator/stryker-net">Stryket.NET</a>, testowanie mutacyjne w .NET</li><li><a href="https://github.com/mbj/mutant">Mutant</a>, testowanie mutacyjne w Ruby</li><li><a href="https://www.youtube.com/watch?v=ZRoEVJlxPlo">Data i czas dla programistów, Michał Pipa, Boiling Frogs 2017</a>, ciekawa prezentacja na temat "jak bardzo skomplikowany może być czas"</li></ul>
]]></description>
      <pubDate>Mon, 21 Sep 2020 23:00:01 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/15-CYAfnYKK</link>
      <content:encoded><![CDATA[<p>Materiały dodatkowe:</p><ul><li><a href="http://xunitpatterns.com/Test%20Smells.html">xUnitPatterns Test Smells</a>, lista Test Smells według Gerarda Meszarosa</li><li><a href="https://testsmells.github.io/pages/testsmells.html">Software Unit Tests Smells</a>, uzupełnienie listy o inne smelle i jedocześnie tool do ich wykrywania</li><li><a href="http://pitest.org">PIT Mutation Testing</a>, testowanie mutacyjne w Java</li><li><a href="https://infection.github.io">Infectionn PHP</a>, testowanie mutacyjne w PHP</li><li><a href="https://github.com/stryker-mutator/stryker-net">Stryket.NET</a>, testowanie mutacyjne w .NET</li><li><a href="https://github.com/mbj/mutant">Mutant</a>, testowanie mutacyjne w Ruby</li><li><a href="https://www.youtube.com/watch?v=ZRoEVJlxPlo">Data i czas dla programistów, Michał Pipa, Boiling Frogs 2017</a>, ciekawa prezentacja na temat "jak bardzo skomplikowany może być czas"</li></ul>
]]></content:encoded>
      <enclosure length="74312780" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f4c-c92d-41f1-a1f8-89d291f62b34/episodes/dc8472e6-f4cc-4f4b-ab06-6b7fdfa94dd2/audio/9fad0501-7550-41c4-8bbc-5f2ca6f19a76/default_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>15. O Test Smells z Olą Kunysz</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>01:17:23</itunes:duration>
      <itunes:summary>Test to obywatel pierwszej kategorii w projekcie, jego kod należy więc postawić na tym samym poziomie co kod produkcyjny, jeśli chodzi o zagadnienia związane z np. jakością. Więc skoro poświęcamy sporo czasu podczas code review na wykrywanie różnego rodzaju Code Smells, podobnie powinniśmy postępować z testami.

Razem z moim dzisiejszym gościem, Olą Kunysz, na tapet bierzemy Test Smells, czyli powody, dla których kod testów staje się trudny do utrzymania i rozwoju. Punktem wyjścia jest oczywiście lista złych zapachów Gerarda Meszarosa, ale niejednokrotnie pozwoliliśmy sobie pójść z rozmową dalej...

</itunes:summary>
      <itunes:subtitle>Test to obywatel pierwszej kategorii w projekcie, jego kod należy więc postawić na tym samym poziomie co kod produkcyjny, jeśli chodzi o zagadnienia związane z np. jakością. Więc skoro poświęcamy sporo czasu podczas code review na wykrywanie różnego rodzaju Code Smells, podobnie powinniśmy postępować z testami.

Razem z moim dzisiejszym gościem, Olą Kunysz, na tapet bierzemy Test Smells, czyli powody, dla których kod testów staje się trudny do utrzymania i rozwoju. Punktem wyjścia jest oczywiście lista złych zapachów Gerarda Meszarosa, ale niejednokrotnie pozwoliliśmy sobie pójść z rozmową dalej...

</itunes:subtitle>
      <itunes:keywords>test driven development, unit testing, tdd, test smells</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>15</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">64188bc5-1b11-4f19-9eec-3fa7a9337444</guid>
      <title>14. Domain Driven Design Essentials: Value Object</title>
      <description><![CDATA[<p>Materiały dodatkowe:</p><ul><li><a href="https://martinfowler.com/bliki/ValueObject.html">Value Object, bliki Martina Fowlera</a>, strona, której przedstawiać raczej nie trzeba...</li><li><a href="http://wiki.c2.com/?ValueObject">Value Object, c2 wiki</a></li><li><a href="http://wiki.c2.com/?ValueObjectsShouldBeImmutable">Value Object Should Be Immutable, c2 wiki</a></li><li><a href="http://c2.com/ppr/checks.html">The CHECKS Pattern Language of Information Integrity, Ward Cunningham</a>, zestawienie 11 wzorców zarządzania spójnością informacji, gdzie opisany jest wzorzec Whole Value</li></ul>
]]></description>
      <pubDate>Mon, 14 Sep 2020 23:00:16 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/14-_hQGeflH</link>
      <content:encoded><![CDATA[<p>Materiały dodatkowe:</p><ul><li><a href="https://martinfowler.com/bliki/ValueObject.html">Value Object, bliki Martina Fowlera</a>, strona, której przedstawiać raczej nie trzeba...</li><li><a href="http://wiki.c2.com/?ValueObject">Value Object, c2 wiki</a></li><li><a href="http://wiki.c2.com/?ValueObjectsShouldBeImmutable">Value Object Should Be Immutable, c2 wiki</a></li><li><a href="http://c2.com/ppr/checks.html">The CHECKS Pattern Language of Information Integrity, Ward Cunningham</a>, zestawienie 11 wzorców zarządzania spójnością informacji, gdzie opisany jest wzorzec Whole Value</li></ul>
]]></content:encoded>
      <enclosure length="13471451" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f/32114f4c-c92d-41f1-a1f8-89d291f62b34/d4a57d05-b7d2-414d-8be1-25c717e56d2b/s014_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>14. Domain Driven Design Essentials: Value Object</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>00:14:01</itunes:duration>
      <itunes:summary>Domain Driven Design oferuje wiele wzorców taktycznych oraz strategicznych, pozwalających na kompleksowe podejście do analizy i implementacji domeny biznesowej. Jednym z wzorców taktycznego DDD jest Value Object i to właśnie on będzie bohaterem pierwszego odcinka mini-serii Domain Driven Design Essentials.

Każdy odcinek będzie poświęcony tu pojedynczemu zagadnieniu i wzorzec po wzorcu, będę budować katalog wszystkich istotnych tematów, o których warto po prostu coś wiedzieć. 

A w temacie wzorca Value Object porozmawiamy o:
- powodach, dla których pewne obiekty nie potrzebują tożsamości i identyfikatorów
- niezmienności obiektów i zaletach takiego podejścia
- sposobach sprawdzania, czy mamy do czynienia właśnie z Value Objectem 

Zapraszam na odcinek!</itunes:summary>
      <itunes:subtitle>Domain Driven Design oferuje wiele wzorców taktycznych oraz strategicznych, pozwalających na kompleksowe podejście do analizy i implementacji domeny biznesowej. Jednym z wzorców taktycznego DDD jest Value Object i to właśnie on będzie bohaterem pierwszego odcinka mini-serii Domain Driven Design Essentials.

Każdy odcinek będzie poświęcony tu pojedynczemu zagadnieniu i wzorzec po wzorcu, będę budować katalog wszystkich istotnych tematów, o których warto po prostu coś wiedzieć. 

A w temacie wzorca Value Object porozmawiamy o:
- powodach, dla których pewne obiekty nie potrzebują tożsamości i identyfikatorów
- niezmienności obiektów i zaletach takiego podejścia
- sposobach sprawdzania, czy mamy do czynienia właśnie z Value Objectem 

Zapraszam na odcinek!</itunes:subtitle>
      <itunes:keywords>domain driven design, value object</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>14</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">a7b89416-4c91-46c7-a9c7-eef0f0c1bf99</guid>
      <title>13. O architekturze mikroserwisowej z Kubą Nabrdalikiem</title>
      <description><![CDATA[<p>Materiały dodatkowe:</p><ul><li><a href="https://www.youtube.com/watch?v=jo46-CP6ywU">Common mistakes when moving to microservices & cloud</a>, prezentacja Kuby z Confitury 2019, same slajdy można pobrać <a href="https://jakubn.gitlab.io/mistake2microservices/#1">tutaj</a></li><li><a href="https://www.confluent.io/designing-event-driven-systems/">Designing Event-Driven Systems: Concepts and Patterns for Streaming Services with Apache Kafka, Ben Stopford</a>, wspomniana w rozmowie książka o projektowaniu systemów w architekturze Event-Driven</li><li><a href="https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-2008-11.pdf">The Influence of Organizational Structure on Software Quality: An Empirical Case Study</a>, opracowanie case study Microsoftu od Nachiappan Nagappan, Brendan Murphy, Victor R. Basili</li><li><a href="http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/cathedral-bazaar.ps">The Cathedral and the Bazaar, Eric Steven Raymond</a>, wersja Postscript eseju Erica Raymonda o projektach Open-Source z obserwacji na przykładzie m.in. jądra Linuksa</li></ul><p>Polecam także śledzić profil <a href="https://twitter.com/jnabrdalik">Kuby na Twitterze</a>, pojawia się tam sporo ciekawych materiałów i treści.</p>
]]></description>
      <pubDate>Mon, 7 Sep 2020 23:00:04 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/13-zex2GEV2</link>
      <content:encoded><![CDATA[<p>Materiały dodatkowe:</p><ul><li><a href="https://www.youtube.com/watch?v=jo46-CP6ywU">Common mistakes when moving to microservices & cloud</a>, prezentacja Kuby z Confitury 2019, same slajdy można pobrać <a href="https://jakubn.gitlab.io/mistake2microservices/#1">tutaj</a></li><li><a href="https://www.confluent.io/designing-event-driven-systems/">Designing Event-Driven Systems: Concepts and Patterns for Streaming Services with Apache Kafka, Ben Stopford</a>, wspomniana w rozmowie książka o projektowaniu systemów w architekturze Event-Driven</li><li><a href="https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-2008-11.pdf">The Influence of Organizational Structure on Software Quality: An Empirical Case Study</a>, opracowanie case study Microsoftu od Nachiappan Nagappan, Brendan Murphy, Victor R. Basili</li><li><a href="http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/cathedral-bazaar.ps">The Cathedral and the Bazaar, Eric Steven Raymond</a>, wersja Postscript eseju Erica Raymonda o projektach Open-Source z obserwacji na przykładzie m.in. jądra Linuksa</li></ul><p>Polecam także śledzić profil <a href="https://twitter.com/jnabrdalik">Kuby na Twitterze</a>, pojawia się tam sporo ciekawych materiałów i treści.</p>
]]></content:encoded>
      <enclosure length="69756327" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f/32114f4c-c92d-41f1-a1f8-89d291f62b34/489eeb08-bc4e-4cae-b6f6-2ae2faa87b2c/s013-o-wyzwaniach-architektury-mikroserwisowej-z-kuba-nabrdalikiem_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>13. O architekturze mikroserwisowej z Kubą Nabrdalikiem</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>01:12:39</itunes:duration>
      <itunes:summary>Bez dwóch zdań architektura mikroserwisowa jest złożona i trudna w implementacji, a jednocześnie bardzo często wybierana przez zespoły trochę niepotrzebnie lub na wyrost. Z moim dzisiejszym gościem, Kubą Nabrdalikiem z Bottega IT Minds, rozmawiamy dziś właśnie m.in. o tych problemach, stojących za nimi decyzjami i konsekwencjami.

Udało nam się dotknąć zarówno aspektów technicznych, takich jak wybór właściwego stylu architektonicznego, ale także problemów zupełnie innego gatunku, wpływających mocno na organizację i jej strukturę. Nie każda firma wybierająca tą właśnie architekturę jest gotowa na zmianę swojego modelu security w projektach IT, rozpraszania decyzyjności czy w kontrolowania struktury całego systemu.

Doświadczenie Kuby z mikroserwisowych projektów, a także rozmawianie wprost o popełnianych przez siebie błędach, każde mi w tym momencie napisać: ten odcinek to pozycja obowiązkowa dla każdego Software Architecta i osób zajmujących się mikroserwisami.

W kolejnych odcinkach na pewno wrócimy do tego tematu, także z mocno technicznej strony, a tymczasem zapraszam do odsłuchania!</itunes:summary>
      <itunes:subtitle>Bez dwóch zdań architektura mikroserwisowa jest złożona i trudna w implementacji, a jednocześnie bardzo często wybierana przez zespoły trochę niepotrzebnie lub na wyrost. Z moim dzisiejszym gościem, Kubą Nabrdalikiem z Bottega IT Minds, rozmawiamy dziś właśnie m.in. o tych problemach, stojących za nimi decyzjami i konsekwencjami.

Udało nam się dotknąć zarówno aspektów technicznych, takich jak wybór właściwego stylu architektonicznego, ale także problemów zupełnie innego gatunku, wpływających mocno na organizację i jej strukturę. Nie każda firma wybierająca tą właśnie architekturę jest gotowa na zmianę swojego modelu security w projektach IT, rozpraszania decyzyjności czy w kontrolowania struktury całego systemu.

Doświadczenie Kuby z mikroserwisowych projektów, a także rozmawianie wprost o popełnianych przez siebie błędach, każde mi w tym momencie napisać: ten odcinek to pozycja obowiązkowa dla każdego Software Architecta i osób zajmujących się mikroserwisami.

W kolejnych odcinkach na pewno wrócimy do tego tematu, także z mocno technicznej strony, a tymczasem zapraszam do odsłuchania!</itunes:subtitle>
      <itunes:keywords>mikroserwisy, microservices architecture, microservices, architektura mikroserwisowa, jakub nabrdalik, architektura</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>13</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">a6407968-1c29-4bdf-9a1d-270337f130c0</guid>
      <title>12. O zbieraniu i analizie wymagań z Michałem Bartyzelem</title>
      <description><![CDATA[<p>Materiały dodatkowe:</p><ul><li><a href="https://www.michalbartyzel.pl/blog/">Blog Michała Bartyzela</a>, 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 lat</li><li><a href="https://www.thriftbooks.com/w/writing-effective-use-cases_alistair-cockburn/250340/#isbn=0201702258&idiq=4483215">Writing Effective Use-Cases, Alistair Cockburn</a></li><li><a href="https://www.thriftbooks.com/w/patterns-for-effective-use-cases_alistair-cockburn_steve-adolph/847828/#isbn=0201721848&idiq=7082940">Patterns for Effective Use Cases, Alistair Cockburn</a></li></ul><p>Zainteresowanych tą tematyką polecam także grupę Michała na Facebooku <a href="https://www.facebook.com/groups/it.spotyka.klienta/">IT spotyka klienta</a>, gdzie można o inch podyskutować albo poczytać.</p>
]]></description>
      <pubDate>Mon, 31 Aug 2020 23:00:11 +0000</pubDate>
      <author>Michał Bartyzel</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/12-BgCPjcJQ</link>
      <content:encoded><![CDATA[<p>Materiały dodatkowe:</p><ul><li><a href="https://www.michalbartyzel.pl/blog/">Blog Michała Bartyzela</a>, 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 lat</li><li><a href="https://www.thriftbooks.com/w/writing-effective-use-cases_alistair-cockburn/250340/#isbn=0201702258&idiq=4483215">Writing Effective Use-Cases, Alistair Cockburn</a></li><li><a href="https://www.thriftbooks.com/w/patterns-for-effective-use-cases_alistair-cockburn_steve-adolph/847828/#isbn=0201721848&idiq=7082940">Patterns for Effective Use Cases, Alistair Cockburn</a></li></ul><p>Zainteresowanych tą tematyką polecam także grupę Michała na Facebooku <a href="https://www.facebook.com/groups/it.spotyka.klienta/">IT spotyka klienta</a>, gdzie można o inch podyskutować albo poczytać.</p>
]]></content:encoded>
      <enclosure length="61097486" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f/32114f4c-c92d-41f1-a1f8-89d291f62b34/e6446c99-97a5-4f69-905d-13e8afa4cd15/s011_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>12. O zbieraniu i analizie wymagań z Michałem Bartyzelem</itunes:title>
      <itunes:author>Michał Bartyzel</itunes:author>
      <itunes:duration>01:03:37</itunes:duration>
      <itunes:summary>Do tej pory rozmawialiśmy głównie o tym JAK implementować pewne problemy, dziś skupimy się więc na aspektach CO i DLACZEGO powinno powstać. Moim rozmówcą będzie Michał Bartyzel, analityk, programista, autor kilku książek poświęconych relacjom pomiędzy IT oraz biznesem.

W tym odcinku będzie można posłuchać m.in. o:
- rozumieniu potrzeb klienta i metodach ich odkrywania
- dlaczego User Stories często nie działają i jak powinny być stosowane właściwe,
- niedziałających dokumentacjach projektowych,
- naszych nieudanych projektach i doświadczeniach, co pokazuje, jak dużo doświadczenia można zdobyć na błędach i wyciąganiu z nich wniosków,
- zdobywaniu umiejętności miękkich.

Przygotowując te odcinek do publikacji przesłałem go Michałowi do weryfikacji. W końcu od naszej rozmowy minęły prawie 2 lata i może Michał chciałby jakoś ją skomentować, z perspektywy czasu niektóre rzeczy mogą wyglądać inaczej. W odpowiedzi usłyszałem jedynie &quot;Przesłuchałem i gdybyśmy nagrywali to wczoraj to powiedziałbym to samo&quot; i niech to będzie najlepszą rekomendacją dla was.

Zapraszam na odcinek!</itunes:summary>
      <itunes:subtitle>Do tej pory rozmawialiśmy głównie o tym JAK implementować pewne problemy, dziś skupimy się więc na aspektach CO i DLACZEGO powinno powstać. Moim rozmówcą będzie Michał Bartyzel, analityk, programista, autor kilku książek poświęconych relacjom pomiędzy IT oraz biznesem.

W tym odcinku będzie można posłuchać m.in. o:
- rozumieniu potrzeb klienta i metodach ich odkrywania
- dlaczego User Stories często nie działają i jak powinny być stosowane właściwe,
- niedziałających dokumentacjach projektowych,
- naszych nieudanych projektach i doświadczeniach, co pokazuje, jak dużo doświadczenia można zdobyć na błędach i wyciąganiu z nich wniosków,
- zdobywaniu umiejętności miękkich.

Przygotowując te odcinek do publikacji przesłałem go Michałowi do weryfikacji. W końcu od naszej rozmowy minęły prawie 2 lata i może Michał chciałby jakoś ją skomentować, z perspektywy czasu niektóre rzeczy mogą wyglądać inaczej. W odpowiedzi usłyszałem jedynie &quot;Przesłuchałem i gdybyśmy nagrywali to wczoraj to powiedziałbym to samo&quot; i niech to będzie najlepszą rekomendacją dla was.

Zapraszam na odcinek!</itunes:subtitle>
      <itunes:keywords>requirements, it project analysis, michał bartyzel, analiza wymagań</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>12</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">b90ea079-f0fe-45b6-9847-563ea17cc26f</guid>
      <title>11. Fast Update #1</title>
      <description><![CDATA[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! 
]]></description>
      <pubDate>Sun, 30 Aug 2020 23:00:24 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/11-3xYKtKyT</link>
      <enclosure length="7652267" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f/32114f4c-c92d-41f1-a1f8-89d291f62b34/f513aa8b-ca5a-490c-ae24-5ec7694c1c92/s011-studio-update-1_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>11. Fast Update #1</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>00:07:58</itunes:duration>
      <itunes:summary>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!</itunes:summary>
      <itunes:subtitle>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!</itunes:subtitle>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>11</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">a63ff5cd-0adf-4736-a9f6-f43a7c2b6f30</guid>
      <title>10. O refaktoryzacji The Arkency Way z Andrzejem Krzywdą</title>
      <description><![CDATA[<p>Materiały dodatkowe:</p><ul><li><a href="https://martinfowler.com/books/refactoring.html">Refactoring: Improving the Design of Existing Code,Martin Fowler, with Kent Beck</a> , klasyka gatunku</li><li><a href="https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052">Working Effectively with Legacy Code, Michael Feathers</a>, druga klasyka warta przeczytania i posiadania w swojej biblioteczce</li><li><a href="https://rails-refactoring.com/?_ga=2.182259751.1438334614.1597065851-1546638955.1597065851">Fearless Refactoring: Rails Controllers, Andrzej Krzywda</a>, wspomniana przez Andrzeja jego książka o refaktoryzacji Railsowych kontrolerów</li><li><a href="https://refactoring.com/catalog/">Katalog przekształceń refaktoryzacyjnych Martina Fowlera</a></li><li><a href="https://trunkbaseddevelopment.com">TrunkBasedDevelopment.com</a>, 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 problemy</li></ul><p>Nasze profile na Instagramie:</p><ul><li><a href="https://www.instagram.com/andrzejkrzywda_po_polsku/">Profil Andrzeja Krzywdy</a></li><li><a href="https://www.instagram.com/mariuszgil_dev/">Profil Mariusza Gila</a></li></ul><p>Przy okazji wizyty Andrzeja w studio nagraliśmy coś jeszcze! Zapraszam do śledzenia <a href="https://www.youtube.com/c/MariuszGil">mojego kanału na YouTube</a>.</p>
]]></description>
      <pubDate>Mon, 10 Aug 2020 23:00:39 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/10-yXA9xHcw</link>
      <content:encoded><![CDATA[<p>Materiały dodatkowe:</p><ul><li><a href="https://martinfowler.com/books/refactoring.html">Refactoring: Improving the Design of Existing Code,Martin Fowler, with Kent Beck</a> , klasyka gatunku</li><li><a href="https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052">Working Effectively with Legacy Code, Michael Feathers</a>, druga klasyka warta przeczytania i posiadania w swojej biblioteczce</li><li><a href="https://rails-refactoring.com/?_ga=2.182259751.1438334614.1597065851-1546638955.1597065851">Fearless Refactoring: Rails Controllers, Andrzej Krzywda</a>, wspomniana przez Andrzeja jego książka o refaktoryzacji Railsowych kontrolerów</li><li><a href="https://refactoring.com/catalog/">Katalog przekształceń refaktoryzacyjnych Martina Fowlera</a></li><li><a href="https://trunkbaseddevelopment.com">TrunkBasedDevelopment.com</a>, 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 problemy</li></ul><p>Nasze profile na Instagramie:</p><ul><li><a href="https://www.instagram.com/andrzejkrzywda_po_polsku/">Profil Andrzeja Krzywdy</a></li><li><a href="https://www.instagram.com/mariuszgil_dev/">Profil Mariusza Gila</a></li></ul><p>Przy okazji wizyty Andrzeja w studio nagraliśmy coś jeszcze! Zapraszam do śledzenia <a href="https://www.youtube.com/c/MariuszGil">mojego kanału na YouTube</a>.</p>
]]></content:encoded>
      <enclosure length="69140992" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f/32114f4c-c92d-41f1-a1f8-89d291f62b34/a1fcf123-330c-42ae-8fcf-dbbf1f584bf5/s010_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>10. O refaktoryzacji The Arkency Way z Andrzejem Krzywdą</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>01:12:02</itunes:duration>
      <itunes:summary>Jedyną stałą rzeczą w organizacji jest zmiana - to hasło Petera Druckera odczuła chyba każda osoba związana z IT. Zmienia się struktura zespołu, umiejętności, technologie, ale przede wszystkim wymagania biznesowe, co pociąga za sobą konieczność modyfikacji implementowanych aplikacji. Podejmowane decyzje techniczne są zawsze osadzone w pewnym kontekście i czasem jego zmiana może mieć duży wpływ na architekturę systemu czy wydajność samego zespołu. 

Właśnie o tych rzeczach, a także o sposobach rozmowy z biznesem rozmawiam dziś z Andrzejek Krzywdą, developerem i CEO Arkency. Andrzej od lat jest związany z językiem Ruby i frameworkiem Ruby on Rails, ale niech was to nie zwiedzie. Technologia stanowi tu jedynie tło do rozmowy o tym, kiedy warto coś refaktoryzować, jak umiejętnie &quot;sprzedać&quot; konieczność refaktoryzacji biznesowi i jak może wyglądać przykładowa ścieżka zmian w projekcie. 

Zapraszam na odcinek!</itunes:summary>
      <itunes:subtitle>Jedyną stałą rzeczą w organizacji jest zmiana - to hasło Petera Druckera odczuła chyba każda osoba związana z IT. Zmienia się struktura zespołu, umiejętności, technologie, ale przede wszystkim wymagania biznesowe, co pociąga za sobą konieczność modyfikacji implementowanych aplikacji. Podejmowane decyzje techniczne są zawsze osadzone w pewnym kontekście i czasem jego zmiana może mieć duży wpływ na architekturę systemu czy wydajność samego zespołu. 

Właśnie o tych rzeczach, a także o sposobach rozmowy z biznesem rozmawiam dziś z Andrzejek Krzywdą, developerem i CEO Arkency. Andrzej od lat jest związany z językiem Ruby i frameworkiem Ruby on Rails, ale niech was to nie zwiedzie. Technologia stanowi tu jedynie tło do rozmowy o tym, kiedy warto coś refaktoryzować, jak umiejętnie &quot;sprzedać&quot; konieczność refaktoryzacji biznesowi i jak może wyglądać przykładowa ścieżka zmian w projekcie. 

Zapraszam na odcinek!</itunes:subtitle>
      <itunes:keywords>ruby on rails, domain driven design, arkency, refactoring, ddd, refaktoryzacja</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>10</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">f00f85c5-dbff-4d5e-aeb7-f47c1d0b5c03</guid>
      <title>9. O modelu i strukturach wielkiej skali z Kubą Pilimonem</title>
      <description><![CDATA[<p>Materiały dodatkowe:</p><ul><li>Eric Evans, Domain Driven Design: Tackling Complexity In The Hearth Of Software, rozdział 16</li><li><a href="https://bottega.com.pl/pdf/materialy/ddd/ddd2.pdf">Zaawansowane modelowanie DDD, techniki strategiczne: konteksty i architektura zdarzeniowa, Sławek Sobótka</a>, część 2 cyklu artykułów "Domain Driven Design krok po kroku" Sławka</li></ul><p>Wspominaliśmy także kanały YouTube:</p><ul><li><a href="https://www.youtube.com/watch?v=31PNdWaUrTY">kanał Mariusza z otwierającym projekt "EventStorming i 4 poziomy zdarzeń</a></li><li><a href="https://www.youtube.com/channel/UCvNne80z8XObPYIhDwnKDrg">kanał DevUpgrade.online Kuby Pilimona i Sławka Sobótki</a></li></ul>
]]></description>
      <pubDate>Mon, 13 Jul 2020 23:00:05 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/9-TrbDkMBv</link>
      <content:encoded><![CDATA[<p>Materiały dodatkowe:</p><ul><li>Eric Evans, Domain Driven Design: Tackling Complexity In The Hearth Of Software, rozdział 16</li><li><a href="https://bottega.com.pl/pdf/materialy/ddd/ddd2.pdf">Zaawansowane modelowanie DDD, techniki strategiczne: konteksty i architektura zdarzeniowa, Sławek Sobótka</a>, część 2 cyklu artykułów "Domain Driven Design krok po kroku" Sławka</li></ul><p>Wspominaliśmy także kanały YouTube:</p><ul><li><a href="https://www.youtube.com/watch?v=31PNdWaUrTY">kanał Mariusza z otwierającym projekt "EventStorming i 4 poziomy zdarzeń</a></li><li><a href="https://www.youtube.com/channel/UCvNne80z8XObPYIhDwnKDrg">kanał DevUpgrade.online Kuby Pilimona i Sławka Sobótki</a></li></ul>
]]></content:encoded>
      <enclosure length="66852891" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f/32114f4c-c92d-41f1-a1f8-89d291f62b34/d91c3f79-a6de-4b8a-a998-4863e0cd524f/s009_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>9. O modelu i strukturach wielkiej skali z Kubą Pilimonem</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>01:09:37</itunes:duration>
      <itunes:summary>W kilku dotychczasowych odcinkach pojawił się temat struktur wielkiej skali w modelu domenowym. Nadszedł więc czas, aby przyjrzeć się temu zagadnieniu z bliska i sprawdzić, o jakich strukturach pisze Eric Evans w rozdziale 16 swojej słynnej książki &quot;Domain Driven Design: Tackling Complexity In The Hearth Of Software&quot;. Wspólnie z Kubą Pilimonem analizujemy poszczególne struktury, skupiając się przede wszystkim na wzorcu Responsibility Layers.

W tym odcinku będzie można zatem posłuchać m.in. o warstwach modelu:
- Capabilities, opisującej spektrum możliwości 
- Operations, opisującej faktyczne operacje biznesowe na warstwie Capabilities
- Policies, dedykowanej np. optymalizacji wykonywanych procesów
- Decision Support, opisującej mechanizmy automatycznego wspierania i podejmowania decyzji w systemie</itunes:summary>
      <itunes:subtitle>W kilku dotychczasowych odcinkach pojawił się temat struktur wielkiej skali w modelu domenowym. Nadszedł więc czas, aby przyjrzeć się temu zagadnieniu z bliska i sprawdzić, o jakich strukturach pisze Eric Evans w rozdziale 16 swojej słynnej książki &quot;Domain Driven Design: Tackling Complexity In The Hearth Of Software&quot;. Wspólnie z Kubą Pilimonem analizujemy poszczególne struktury, skupiając się przede wszystkim na wzorcu Responsibility Layers.

W tym odcinku będzie można zatem posłuchać m.in. o warstwach modelu:
- Capabilities, opisującej spektrum możliwości 
- Operations, opisującej faktyczne operacje biznesowe na warstwie Capabilities
- Policies, dedykowanej np. optymalizacji wykonywanych procesów
- Decision Support, opisującej mechanizmy automatycznego wspierania i podejmowania decyzji w systemie</itunes:subtitle>
      <itunes:keywords>domain driven design, strategic patterns, responsibility layers, ddd, eric evans</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>9</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">98fc50f3-5850-4aae-96b0-56c819b24484</guid>
      <title>8. O Bounded Contextach ze Sławkiem Sobótką</title>
      <description><![CDATA[<p>Materiały:</p><ul><li><a href="https://martinfowler.com/bliki/BoundedContext.html">Bounded Context</a>, krótkie wprowadzenie do wzorca na Bliki Martina Fowlera</li><li><a href="https://www.youtube.com/watch?v=u4aFjePJJTM">Event Storming - od analizy do architektury</a>, prezentacja Sławka Sobótki o wykorzystaniu EventStormingu w procesie analizy, ponad 2.5 godziny konkretnej wiedzy</li><li><a href="https://www.youtube.com/watch?v=ez9GWESKG4I">The Art of Discovering Bounded Contexts</a>, prezentacja Nicka Tune</li><li><a href="https://www.amazon.com/Secrets-Consulting-Giving-Getting-Successfully/dp/0932633013">The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully, Gerald M. Weinberg</a></li><li><a href="https://www.amazon.com/More-Secrets-Consulting-Consultants-Tool/dp/0932633528">More Secrets of Consulting: The Consultant's Tool Kit, Gerald M. Weinberg</a></li><li><a href="https://www.charlesleon.uk/blog/3-thinking-modes-of-creative-thinking-divergent-emergent-and-convergent-thinking24112019">Divergent, Emergent, Convergent Thinking - 3 Thinking Modes</a>, procesy kreatywne i mechanika ich działania</li></ul>
]]></description>
      <pubDate>Mon, 22 Jun 2020 23:00:07 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/8-9skqlYsI</link>
      <content:encoded><![CDATA[<p>Materiały:</p><ul><li><a href="https://martinfowler.com/bliki/BoundedContext.html">Bounded Context</a>, krótkie wprowadzenie do wzorca na Bliki Martina Fowlera</li><li><a href="https://www.youtube.com/watch?v=u4aFjePJJTM">Event Storming - od analizy do architektury</a>, prezentacja Sławka Sobótki o wykorzystaniu EventStormingu w procesie analizy, ponad 2.5 godziny konkretnej wiedzy</li><li><a href="https://www.youtube.com/watch?v=ez9GWESKG4I">The Art of Discovering Bounded Contexts</a>, prezentacja Nicka Tune</li><li><a href="https://www.amazon.com/Secrets-Consulting-Giving-Getting-Successfully/dp/0932633013">The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully, Gerald M. Weinberg</a></li><li><a href="https://www.amazon.com/More-Secrets-Consulting-Consultants-Tool/dp/0932633528">More Secrets of Consulting: The Consultant's Tool Kit, Gerald M. Weinberg</a></li><li><a href="https://www.charlesleon.uk/blog/3-thinking-modes-of-creative-thinking-divergent-emergent-and-convergent-thinking24112019">Divergent, Emergent, Convergent Thinking - 3 Thinking Modes</a>, procesy kreatywne i mechanika ich działania</li></ul>
]]></content:encoded>
      <enclosure length="95597008" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f/32114f4c-c92d-41f1-a1f8-89d291f62b34/115fcd26-5dbe-4cec-bb54-5d319e8bc0a7/s008-o-bounded-contextach_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>8. O Bounded Contextach ze Sławkiem Sobótką</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>01:39:34</itunes:duration>
      <itunes:summary>Sporo uwagi we wcześniejszych odcinkach poświęciliśmy wzorcowi Aggregate, pozwalającemu zapewnić spójność reguł biznesowych podczas wykonywania zmian w systemie. Dziś wraz ze Sławkiem Sobótką, założycielem i właścicielem Bottega IT Minds, przyjrzymy się jednemu z najważniejszych elementów strategicznego Domain Driven Design. Zapraszam na ponad 90 minut rozmowy o idei Bounded Context, subdomenach biznesowych i heurystykach pomocnych przy ich identyfikacji. </itunes:summary>
      <itunes:subtitle>Sporo uwagi we wcześniejszych odcinkach poświęciliśmy wzorcowi Aggregate, pozwalającemu zapewnić spójność reguł biznesowych podczas wykonywania zmian w systemie. Dziś wraz ze Sławkiem Sobótką, założycielem i właścicielem Bottega IT Minds, przyjrzymy się jednemu z najważniejszych elementów strategicznego Domain Driven Design. Zapraszam na ponad 90 minut rozmowy o idei Bounded Context, subdomenach biznesowych i heurystykach pomocnych przy ich identyfikacji. </itunes:subtitle>
      <itunes:keywords>bounded context, domain driven design, strategic patterns, ddd</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>8</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">3069c373-b137-451b-8ec0-d0e552f6ed34</guid>
      <title>7. O programowaniu aspektowym z Andrzejem Krzywdą</title>
      <description><![CDATA[<p>Materiały:</p><ul><li><a href="https://www.cs.ubc.ca/~gregor/papers/kiczales-ECOOP1997-AOP.pdf">Aspect-Oriented Programming, Gregor Kiczales, John Lamping, Anurag Mendhekar, Chris Maeda, Cristina Lopes, Jean-Marc Loingtier and John Irwin</a>, pochodzący z 1997 roku i Xerox Palo Alto Research Center whitepaper opisujący podejście AOP</li><li><a href="https://blog.arkency.com/2013/07/ruby-and-aop-decouple-your-code-even-more/">Ruby and AOP: Decouple your code even more</a>, post Marcina Grzywaczewskiego na blogu Arkency</li><li><a href="http://stochmialek.pl/papers/aop-thesis.pdf">Programowanie aspektowe: studium empiryczne, Michał Stochmiałek</a>, praca magisterska z 2005 z Politechniki Wrocławskiej, jak ktoś ma więcej wolnego czasu...</li></ul><p>Biblioteki i narzędzia:</p><ul><li><a href="https://github.com/eclipse/org.aspectj">AspectJ</a>, implementacja AOP dla Javy</li><li><a href="https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html#aop">Aspect Oriented Programming with Spring</a>, dokumentacja opisująca możliwości wykorzystania AOP we frameworku Spring</li><li><a href="https://github.com/goaop/framework">Go! AOP PHP</a>, implementacja AOP dla PHP</li><li><a href="https://flowframework.readthedocs.io/en/stable/TheDefinitiveGuide/PartIII/AspectOrientedProgramming.html">Flow Framework</a>, inna implementacja dla PHP we frameworku Flow</li><li><a href="https://github.com/deanwampler/Aquarium">Aquarium</a>, implementacja AOP dla Ruby</li><li><a href="https://www.postsharp.net/aop.net">Aspect-Oriented Programming on .NET Framework</a>, implementacja na platformę .NET</li></ul><p>Jeśli korzystacie z jakiejś innej implementacji, chętnie zaktualizuję listę o nowe pozycje.</p>
]]></description>
      <pubDate>Sun, 31 May 2020 23:00:08 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/7-24yQ9ZMo</link>
      <content:encoded><![CDATA[<p>Materiały:</p><ul><li><a href="https://www.cs.ubc.ca/~gregor/papers/kiczales-ECOOP1997-AOP.pdf">Aspect-Oriented Programming, Gregor Kiczales, John Lamping, Anurag Mendhekar, Chris Maeda, Cristina Lopes, Jean-Marc Loingtier and John Irwin</a>, pochodzący z 1997 roku i Xerox Palo Alto Research Center whitepaper opisujący podejście AOP</li><li><a href="https://blog.arkency.com/2013/07/ruby-and-aop-decouple-your-code-even-more/">Ruby and AOP: Decouple your code even more</a>, post Marcina Grzywaczewskiego na blogu Arkency</li><li><a href="http://stochmialek.pl/papers/aop-thesis.pdf">Programowanie aspektowe: studium empiryczne, Michał Stochmiałek</a>, praca magisterska z 2005 z Politechniki Wrocławskiej, jak ktoś ma więcej wolnego czasu...</li></ul><p>Biblioteki i narzędzia:</p><ul><li><a href="https://github.com/eclipse/org.aspectj">AspectJ</a>, implementacja AOP dla Javy</li><li><a href="https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html#aop">Aspect Oriented Programming with Spring</a>, dokumentacja opisująca możliwości wykorzystania AOP we frameworku Spring</li><li><a href="https://github.com/goaop/framework">Go! AOP PHP</a>, implementacja AOP dla PHP</li><li><a href="https://flowframework.readthedocs.io/en/stable/TheDefinitiveGuide/PartIII/AspectOrientedProgramming.html">Flow Framework</a>, inna implementacja dla PHP we frameworku Flow</li><li><a href="https://github.com/deanwampler/Aquarium">Aquarium</a>, implementacja AOP dla Ruby</li><li><a href="https://www.postsharp.net/aop.net">Aspect-Oriented Programming on .NET Framework</a>, implementacja na platformę .NET</li></ul><p>Jeśli korzystacie z jakiejś innej implementacji, chętnie zaktualizuję listę o nowe pozycje.</p>
]]></content:encoded>
      <enclosure length="46425829" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f/32114f4c-c92d-41f1-a1f8-89d291f62b34/7ccf2b08-9cd8-4b0c-8a08-7230cad133b6/s007-o-programowaniu-aspektowym_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>7. O programowaniu aspektowym z Andrzejem Krzywdą</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>00:48:21</itunes:duration>
      <itunes:summary>Czym są cross-cutting concerns, point-cuts, join-points, advices oraz aspects? Jak wspomniane zagadnienia przecinające, punkty przecięć, punkty złączeń, porady i aspekty możemy odnieść do implementacji i na co zwrócić uwagę podczas wdrażania Aspect Oriented Programming? Odpowiedzi na te pytania szukamy wspólnie z Andrzejem Krzywdą, założycielem Arkency i wybitnym znawcą tej właśnie tematyki.

Tym odcinkiem rozpoczyna się nowa seria w ramach Better Software Design. Poświęcona będzie rozmowom o paradygmatach, strategiach i technikach programowania, o których warto co nieco wiedzieć.

Zapraszam do odsłuchania!</itunes:summary>
      <itunes:subtitle>Czym są cross-cutting concerns, point-cuts, join-points, advices oraz aspects? Jak wspomniane zagadnienia przecinające, punkty przecięć, punkty złączeń, porady i aspekty możemy odnieść do implementacji i na co zwrócić uwagę podczas wdrażania Aspect Oriented Programming? Odpowiedzi na te pytania szukamy wspólnie z Andrzejem Krzywdą, założycielem Arkency i wybitnym znawcą tej właśnie tematyki.

Tym odcinkiem rozpoczyna się nowa seria w ramach Better Software Design. Poświęcona będzie rozmowom o paradygmatach, strategiach i technikach programowania, o których warto co nieco wiedzieć.

Zapraszam do odsłuchania!</itunes:subtitle>
      <itunes:keywords>events, aspect oriented programming, domain driven design, programming paradigm, aop</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>7</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">d3a941d9-f8a2-4c0b-bd02-1327eefb0c61</guid>
      <title>6. O persystencji agregatów z Kubą Pilimonem</title>
      <description><![CDATA[<p>Materiały do odcinka:</p><ul><li><a href="https://leanpub.com/esversioning">Versioning in an Event Sourced System, Greg Young</a></li><li>Prezentacja Łukasza Szydło z Boiling Frogs 2020 <a href="https://speakerdeck.com/lszydlo/ddd-o-jeden-krok-za-dalego">DDD - o jeden krok za daleko</a>. 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...</li><li><a href="https://www.oreilly.com/library/view/patterns-principles-and/9781118714706/">Patterns, Principles, and Practices of Domain-Driven Design, Scott Millett, Nick Tune</a>, rozdział 21  "Aggregates Persistence Strategies"</li></ul>
]]></description>
      <pubDate>Thu, 21 May 2020 06:40:51 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/6-ht2M94Br</link>
      <content:encoded><![CDATA[<p>Materiały do odcinka:</p><ul><li><a href="https://leanpub.com/esversioning">Versioning in an Event Sourced System, Greg Young</a></li><li>Prezentacja Łukasza Szydło z Boiling Frogs 2020 <a href="https://speakerdeck.com/lszydlo/ddd-o-jeden-krok-za-dalego">DDD - o jeden krok za daleko</a>. 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...</li><li><a href="https://www.oreilly.com/library/view/patterns-principles-and/9781118714706/">Patterns, Principles, and Practices of Domain-Driven Design, Scott Millett, Nick Tune</a>, rozdział 21  "Aggregates Persistence Strategies"</li></ul>
]]></content:encoded>
      <enclosure length="62918229" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f/32114f4c-c92d-41f1-a1f8-89d291f62b34/7c12f5fd-0bdb-457c-932a-67b181dc8a77/s006-o-persystencji-agregatow-mixdown-01_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>6. O persystencji agregatów z Kubą Pilimonem</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>01:05:31</itunes:duration>
      <itunes:summary>W jaki sposób możemy utrwalać agregaty w bazie danych, jakie są możliwe podejścia i czym powinniśmy się kierować podejmując tę kluczową dla projektu decyzję? W kolejnej rozmowie z Kubą Pilimonem analizujemy te właśnie problemy. </itunes:summary>
      <itunes:subtitle>W jaki sposób możemy utrwalać agregaty w bazie danych, jakie są możliwe podejścia i czym powinniśmy się kierować podejmując tę kluczową dla projektu decyzję? W kolejnej rozmowie z Kubą Pilimonem analizujemy te właśnie problemy. </itunes:subtitle>
      <itunes:keywords>aggregates, domain driven design, event sourcing, ddd, orm, database</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>6</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">a639349e-f394-4f36-bf0a-5fbf06499573</guid>
      <title>5. O wzorcach Saga i Process Manager z Kubą Pilimonem</title>
      <description><![CDATA[<p>Materiały:</p><ul><li><a>Saga, opracowanie naukowe, Hectora Molina-Garcia oraz Kennetha Salem, 1987</a></li><li><a href="https://microservices.io/patterns/data/saga.html">Wzorzec Saga w katalogu Microservices.io</a></li><li><a href="https://www.youtube.com/watch?v=xDuwrtwYHu8">Applying the Saga Pattern, prezentacja Caitie McCaffrey GOTO Conference 2015</a></li><li><a href="https://www.youtube.com/watch?v=0UTOLRTwOX0">Distributed Sagas: A Protocol for Coordinating Microservices, prezentacja Caitie McCaffrey z JOTB17</a></li><li><a href="https://blog.bernd-ruecker.com/saga-how-to-implement-complex-business-transactions-without-two-phase-commit-e00aa41a1b1b">Saga: How to implement complex business transactions without two phase commit, Bernd Rucker</a></li><li><a href="https://docs.microsoft.com/en-us/previous-versions/msp-n-p/jj591569(v=pandp.10)">Microsoft CQRS Journey, Saga on Sagas</a></li><li><a href="https://www.enterpriseintegrationpatterns.com/patterns/messaging/ProcessManager.html">Wzorzec Process Manager w Enterprise Integration Patterns, Martin Fowler</a>, tutaj odsyłamy do internetowego podsumowania, więcej o wzorcu można znaleźć w samej książce</li></ul>
]]></description>
      <pubDate>Mon, 27 Apr 2020 19:34:58 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/5-ozxtTWCX</link>
      <content:encoded><![CDATA[<p>Materiały:</p><ul><li><a>Saga, opracowanie naukowe, Hectora Molina-Garcia oraz Kennetha Salem, 1987</a></li><li><a href="https://microservices.io/patterns/data/saga.html">Wzorzec Saga w katalogu Microservices.io</a></li><li><a href="https://www.youtube.com/watch?v=xDuwrtwYHu8">Applying the Saga Pattern, prezentacja Caitie McCaffrey GOTO Conference 2015</a></li><li><a href="https://www.youtube.com/watch?v=0UTOLRTwOX0">Distributed Sagas: A Protocol for Coordinating Microservices, prezentacja Caitie McCaffrey z JOTB17</a></li><li><a href="https://blog.bernd-ruecker.com/saga-how-to-implement-complex-business-transactions-without-two-phase-commit-e00aa41a1b1b">Saga: How to implement complex business transactions without two phase commit, Bernd Rucker</a></li><li><a href="https://docs.microsoft.com/en-us/previous-versions/msp-n-p/jj591569(v=pandp.10)">Microsoft CQRS Journey, Saga on Sagas</a></li><li><a href="https://www.enterpriseintegrationpatterns.com/patterns/messaging/ProcessManager.html">Wzorzec Process Manager w Enterprise Integration Patterns, Martin Fowler</a>, tutaj odsyłamy do internetowego podsumowania, więcej o wzorcu można znaleźć w samej książce</li></ul>
]]></content:encoded>
      <enclosure length="48065181" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f/32114f4c-c92d-41f1-a1f8-89d291f62b34/9322ade2-adf4-441d-a9b7-cbfff0f53aad/s005_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>5. O wzorcach Saga i Process Manager z Kubą Pilimonem</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>00:50:03</itunes:duration>
      <itunes:summary>Jak zapewniać spójność ostateczną i radzić sobie z przeprowadzaniem zmian w środowisku rozproszonym? Czym właściwie jest Saga, co odróżnia ją od Process Managera i jak możemy wykorzystać te wzorce w projektach? Wspólnie z Kubą Pilimonem staramy się odpowiedzieć na te właśnie pytania...</itunes:summary>
      <itunes:subtitle>Jak zapewniać spójność ostateczną i radzić sobie z przeprowadzaniem zmian w środowisku rozproszonym? Czym właściwie jest Saga, co odróżnia ją od Process Managera i jak możemy wykorzystać te wzorce w projektach? Wspólnie z Kubą Pilimonem staramy się odpowiedzieć na te właśnie pytania...</itunes:subtitle>
      <itunes:keywords>eventual consistency, saga, ddd, process manager</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>5</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">5f819bba-9ed3-4f76-967c-1e9337edd755</guid>
      <title>4. O Remote EventStorming z Alberto Brandolinim i Jacopo Romei</title>
      <description><![CDATA[<p>Materiały:</p><ul><li><a href="https://github.com/mariuszgil/awesome-eventstorming#remote-eventstorming">Repozytorium Awesome EventStorming na Githubie, sekcja Remote EventStorming</a></li></ul>
]]></description>
      <pubDate>Sat, 18 Apr 2020 21:48:48 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/4-n8oaK0Tr</link>
      <content:encoded><![CDATA[<p>Materiały:</p><ul><li><a href="https://github.com/mariuszgil/awesome-eventstorming#remote-eventstorming">Repozytorium Awesome EventStorming na Githubie, sekcja Remote EventStorming</a></li></ul>
]]></content:encoded>
      <enclosure length="38165314" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f/32114f4c-c92d-41f1-a1f8-89d291f62b34/c7055efe-d3fe-45f5-9a5e-ca97e5301a0e/s004_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>4. O Remote EventStorming z Alberto Brandolinim i Jacopo Romei</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>00:39:44</itunes:duration>
      <itunes:summary>Jak współpracować i modelować zdalnie z zespołem, gdzie są istotne różnice pomiędzy sesją online i offline, wreszcie na co zwrócić szczególną uwagę podczas sesji zdalnego EventStormingu - te właśnie kwestie pojawią się w rozmowie z dzisiejszymi gośćmi, Alberto Brandolinim i Jacopo Romei. Na koniec nie mogło oczywiście zabraknąć pytania o książkę...</itunes:summary>
      <itunes:subtitle>Jak współpracować i modelować zdalnie z zespołem, gdzie są istotne różnice pomiędzy sesją online i offline, wreszcie na co zwrócić szczególną uwagę podczas sesji zdalnego EventStormingu - te właśnie kwestie pojawią się w rozmowie z dzisiejszymi gośćmi, Alberto Brandolinim i Jacopo Romei. Na koniec nie mogło oczywiście zabraknąć pytania o książkę...</itunes:subtitle>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>4</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">89794909-1df0-4838-9123-22267b581afa</guid>
      <title>3. O różnych odmianach Ubiquitous Language z Łukaszem Szydło</title>
      <description><![CDATA[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. 
]]></description>
      <pubDate>Thu, 16 Apr 2020 09:57:33 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/3-O6d3PVQO</link>
      <enclosure length="57710517" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f/32114f4c-c92d-41f1-a1f8-89d291f62b34/c7b62218-c6cf-4bb4-b829-4b27819c66aa/s003_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>3. O różnych odmianach Ubiquitous Language z Łukaszem Szydło</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>01:00:06</itunes:duration>
      <itunes:summary>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.</itunes:summary>
      <itunes:subtitle>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.</itunes:subtitle>
      <itunes:keywords>ubiquitous language, domain driven design</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>3</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">814b158b-728e-4d48-aaba-8d3091ef7518</guid>
      <title>2. O Aggregates By Example, analiza procesu rezerwacji z Kubą Pilimonem</title>
      <description><![CDATA[<p>Materiały:</p><ul><li><a href="https://time.com/7332/chinese-singles-sabotage-valentines-day-by-buying-up-movie-tickets/">Chinese Singles Buy Movie Tickets So Couples Can't Sit Together on Valentine's Day, Time.com</a></li><li><a href="https://github.com/mariuszgil/aggregates-by-example">Repozytorium Aggregates By Example, przykłady różnych implementacji agregatów</a></li><li><a href="https://github.com/ddd-by-examples/library">Repozytorium DDD By Example, projekt Library</a></li></ul>
]]></description>
      <pubDate>Thu, 16 Apr 2020 09:57:01 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/2-fb_LSv3X</link>
      <content:encoded><![CDATA[<p>Materiały:</p><ul><li><a href="https://time.com/7332/chinese-singles-sabotage-valentines-day-by-buying-up-movie-tickets/">Chinese Singles Buy Movie Tickets So Couples Can't Sit Together on Valentine's Day, Time.com</a></li><li><a href="https://github.com/mariuszgil/aggregates-by-example">Repozytorium Aggregates By Example, przykłady różnych implementacji agregatów</a></li><li><a href="https://github.com/ddd-by-examples/library">Repozytorium DDD By Example, projekt Library</a></li></ul>
]]></content:encoded>
      <enclosure length="46947431" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f/32114f4c-c92d-41f1-a1f8-89d291f62b34/9f83db48-25cb-4952-81dc-f8e588f5459c/s002_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>2. O Aggregates By Example, analiza procesu rezerwacji z Kubą Pilimonem</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>00:48:53</itunes:duration>
      <itunes:summary>Kontynuujemy rozmowy o agregatach, jednak tym razem na warsztat bierzemy konkretny przykład z życia. Razem z Kubą przeprowadzamy analizę różnych konceptów agregatów w procesie rezerwacji biletu na seans w kinie. </itunes:summary>
      <itunes:subtitle>Kontynuujemy rozmowy o agregatach, jednak tym razem na warsztat bierzemy konkretny przykład z życia. Razem z Kubą przeprowadzamy analizę różnych konceptów agregatów w procesie rezerwacji biletu na seans w kinie. </itunes:subtitle>
      <itunes:keywords>aggregates, domain driven design, ddd</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>2</itunes:episode>
    </item>
    <item>
      <guid isPermaLink="false">0d6dd6a7-320b-426e-8423-cf8a6d5e89ee</guid>
      <title>1. O modelowaniu agregatów z Kubą Pilimonem</title>
      <description><![CDATA[<p>Materiały:</p><ul><li><a href="https://github.com/mariuszgil/aggregates-by-example">Repozytorium Aggregates by Example</a>, kod przykładu z dokumentem i załącznikami znajduje się <a href="https://github.com/mariuszgil/aggregates-by-example/tree/master/examples/php/src/Loan">tutaj</a></li></ul>
]]></description>
      <pubDate>Thu, 16 Apr 2020 09:56:43 +0000</pubDate>
      <author>Mariusz Gil</author>
      <link>https://bettersoftwaredesign.simplecast.com/episodes/1-eXrqPw5i</link>
      <content:encoded><![CDATA[<p>Materiały:</p><ul><li><a href="https://github.com/mariuszgil/aggregates-by-example">Repozytorium Aggregates by Example</a>, kod przykładu z dokumentem i załącznikami znajduje się <a href="https://github.com/mariuszgil/aggregates-by-example/tree/master/examples/php/src/Loan">tutaj</a></li></ul>
]]></content:encoded>
      <enclosure length="75027085" type="audio/mpeg" url="https://cdn.simplecast.com/audio/32114f/32114f4c-c92d-41f1-a1f8-89d291f62b34/0cda7c89-8496-4878-8e47-ec8e5ed4519b/s001_tc.mp3?aid=rss_feed&amp;feed=KIo9ot3b"/>
      <itunes:title>1. O modelowaniu agregatów z Kubą Pilimonem</itunes:title>
      <itunes:author>Mariusz Gil</itunes:author>
      <itunes:duration>01:18:07</itunes:duration>
      <itunes:summary>Wspólnie z Kubą siadamy przy pierwszym Domain Driven Design Roundtable i rozkładamy koncept agregatu na czynniki pierwsze. W premierowym odcinku podcastu skupiamy się na zasadach i heurystykach modelowania agregatów.</itunes:summary>
      <itunes:subtitle>Wspólnie z Kubą siadamy przy pierwszym Domain Driven Design Roundtable i rozkładamy koncept agregatu na czynniki pierwsze. W premierowym odcinku podcastu skupiamy się na zasadach i heurystykach modelowania agregatów.</itunes:subtitle>
      <itunes:keywords>aggregates, domain driven design, ddd</itunes:keywords>
      <itunes:explicit>false</itunes:explicit>
      <itunes:episodeType>full</itunes:episodeType>
      <itunes:episode>1</itunes:episode>
    </item>
  </channel>
</rss>