Better Software Design
- Épisodes
- 106
- Parution
- mensuelle
- Dernier épisode
- 20 Oct 2026
À propos du podcast
Better Software Design podcast. Rozmowy o projektowaniu oprogramowania, architekturze i wyzwaniach z tym związanych.
Épisodes 106
105. Case Study: Agentic SDLC w Open Mercato
Czy da się zbudować produkcyjny system o skali prawie dwóch milionów linijek kodu, korzystając wyłącznie z agentów AI i nie pisząc kodu ręcznie? Przykład Open Mercato pokazuje, że taki kierunek jest jak …
Notes de l’épisode
Czy da się zbudować produkcyjny system o skali prawie dwóch milionów linijek kodu, korzystając wyłącznie z agentów AI i nie pisząc kodu ręcznie? Przykład Open Mercato pokazuje, że taki kierunek jest jak najbardziej możliwy i działa w praktyce, ale wymaga fundamentalnej zmiany w podejściu do procesów SDLC.
W tym odcinku zapraszam na case study projektu Open Mercato, open-source'owego narzędzia do tworzenia rozwiązań klasy CRM/ERP, rozwijanego w duchu AI-First. Piotr Karwatka, founder i CTO Open Mercato, oraz Patryk Lewczuk, Core Developer / Forward Deployed Engineer, opowiedzą jak wygląda proces SLDC w tym projekcie oraz jakie techniki i narzędzia są do tego wykorzystywane.
104. Clickbait Events - EDA /Anti/Patterns
Kontynuujemy mini-serię o antywzorcach Event-Driven Architecture - ponownie z Oskarem Dudyczem. Tym razem jednak bierzemy na początek na warsztat puchnące zdarzenia: jedno “uniwersalne” zdarzenie, które próbuje …
Notes de l’épisode
Kontynuujemy mini-serię o antywzorcach Event-Driven Architecture - ponownie z Oskarem Dudyczem. Tym razem jednak bierzemy na początek na warsztat puchnące zdarzenia: jedno “uniwersalne” zdarzenie, które próbuje zadowolić wszystkich naraz. Kolejne pole, kolejne ID “na wszelki wypadek”, aż w końcu wysyłamy w świat pół swojej bazy danych.
Zupełnie jak w wierszyku o sznurku Jurka - ktoś dorzuci papierek, aż robi się góra śmieci. Jednak to tylko pretekst do tego, aby dotknąć właściwego tematu, czyli podziału między to, co publiczne, a to, co prywatne.
103. Od smutnego do modularnego monolitu - historia pewnej refaktoryzacji
Zanim pójdziecie w mikroserwisy, upewnijcie się, że wasze granice są poprawne. W modularnym monolicie pomyłkę naprawicie jednym refaktorem w IDE. W rozproszonym systemie zapłacicie za to zmianami w …
Notes de l’épisode
Zanim pójdziecie w mikroserwisy, upewnijcie się, że wasze granice są poprawne. W modularnym monolicie pomyłkę naprawicie jednym refaktorem w IDE. W rozproszonym systemie zapłacicie za to zmianami w infrastrukturze i bazach danych... Między innymi właśnie to warto zapamiętać z rozmowy z Damianem Dziaduchem, który podzielił się historią refaktoryzacji pewnego smutnego monolitu.
102. State Obsession - EDA /Anti/Patterns
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" …
Notes de l’épisode
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.
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.
Zapraszam na stronę https://bettersoftwaredesign.pl, gdzie znajdziesz jeszcze więcej materiałów.
101. Property Sourcing - EDA /Anti/Patterns
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ę …
Notes de l’épisode
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.
W tym odcinku rozmawiamy z Oskarem m.in. o tym:
- dlaczego interfejsy w stylu Jiry i edycja każdego pola z osobna potrafią zepsuć architekturę
- jak Property Sourcing prowadzi do Event Bombardment i dlaczego twoje read modele mogą tego nie udźwignąć
- czym różni się zdarzenie małe od zdarzenia "mniejszego niż powinno być"
- jak wyjść z tej sytuacji obronną ręką, stosując translatory kontraktów i odpowiednie grupowanie danych
100. O AI w strategicznym Domain-Driven Design z Kubą Pilimonem
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 …
Notes de l’épisode
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ę.
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.
99. O architekturze oprogramowania w erze AI-Assisted development z Łukaszem Szydło i Marcinem Markowskim
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 …
Notes de l’épisode
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.
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.
Ogłoszenie!
Już niedługo, bo 17 lutego, będziemy mogli się spotkać na otwartym warsztacie DevHours: Fullstack x EventStorming, który mam przyjemność współorganizować z Capgemini. Jeśli interesujesz się oprogramowaniem i chcesz podnieść swoje umiejętności w projektowaniu software'u, zapraszam do rejestracji.
98. O agregatach, eventach i Dynamic Consistency Boundary z Pawłem Pacaną
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 …
Notes de l’épisode
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?
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?
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.
W tym odcinku usłyszysz między innymi o:
- trudnościach w projektowaniu i długoterminowym utrzymaniu agregatów w systemie
- Dynamic Consistency Boundary i czym ten wzorzec różni się od klasycznego podejścia z agregatem
- tagowaniu i linkowaniu zdarzeń pomiędzy strumieniami
- wymaganiach dla event-store, aby stosowanie Dynamic Consistency Boundary było w ogóle możliwe
- pułapkach, na które należy zwrócić szczególną uwagę, by wykorzystanie DCB nie stało się problem
Materiały dodatkowe do tego odcinka znajdują się na stronie tego odcinka na bettersoftwaredesign.pl.
YouTube Alert! Odcinki podcastu są także dostępne na moim kanale na YouTube. Warto zasubskrybować, aby być na bieżąco z kolejnymi odcinkami.
97. O architekturze mikrofrontendów i mikroserwisach Allegro z Bartoszem Gałkiem prowadzi Tomasz Ducin - część 2
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 …
Notes de l’épisode
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?
W drugiej części rozmowy o mikrforontendach, Bartosz Gałek, Principal Engineer w Allegro, uchyli rąbka tajemnicy i przedstawi trochę technikaliów.
W tym odcinku usłyszysz między innymi o:
- skali systemu, z jaką mierzą się zespoły developerskie Allegro
- wybranych metrykach zapewniających observability systemu od strony frontendowej
- projektowaniu optymalizacji i zapewnianiu dużej wydajności systemu
- projektowaniu stron portalu z użyciem komponentów i wprowadzaniu nowych funkcjonalności na produkcję
- streamingu HTML-a
- stopniowej migracji monolitu do architektury mikroserwisowej
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...
Materiały dodatkowe do tego odcinka znajdują się na stronie tego odcinka na bettersoftwaredesign.pl.
YouTube Alert! Odcinki podcastu są także dostępne na moim kanale na YouTube. Warto zasubskrybować, aby być na bieżąco z kolejnymi odcinkami.
96. O dostarczaniu eventów w systemach rozproszonych z Michałem Ostruszką
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 …
Notes de l’épisode
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.
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"...
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.
Materiały dodatkowe do tego odcinka znajdują się na stronie tego odcinka na bettersoftwaredesign.pl.
YouTube Alert! Odcinki podcastu są także dostępne na moim kanale na YouTube. Warto zasubskrybować, aby być na bieżąco z kolejnymi odcinkami.
95. O architekturze mikrofrontendów i mikroserwisach Allegro z Bartoszem Gałkiem prowadzi Tomasz Ducin
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 …
Notes de l’épisode
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...
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.
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.
Materiały dodatkowe do tego odcinka znajdują się na stronie tego odcinka na bettersoftwaredesign.pl.
94. O integracji serwisów z użyciem kontraktów z Jackiem Milewskim
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 …
Notes de l’épisode
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.
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.
Materiały dodatkowe do tego odcinka znajdują się na stronie tego odcinka na bettersoftwaredesign.pl.
93. Backend vs Frontend: skuteczne testowanie zachowań, unity i integracja
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 …
Notes de l’épisode
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?
Ale “hold your horses”… testy to tylko przyczynek do tego, aby porozmawiać w luźnej atmosferze o wielu ważnych rzeczach dookoła.
92. O wykorzystaniu AI w software developmencie z Jarkiem Pałką i Wojtkiem Ptakiem
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 …
Notes de l’épisode
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.
91. O modułach w aplikacjach JavaScript z Tomaszem 'Comandeer' Jakutem prowadzi Tomasz Ducin
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 …
Notes de l’épisode
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.
W dzisiejszym odcinku gościem Tomka Ducina, specjalisty z zakresu architektury frontendu jest Tomasz Jakut, szerzej znany w społeczności JavaScriptowej jako Comandeer.
Więcej na stronie tego odcinka na stronie bettersoftwaredesign.pl.
90. O projektowaniu architektury multi-tenant z Michałem Giergielewiczem
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 …
Notes de l’épisode
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...
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.
W tym odcinku wspólnie z Michałem rozmawiamy między innymi o:
- trudnościach w tworzeniu systemów multi-tenant, w tym bazach danych czy kolejkach
- możliwych sposobach zaprojektowania infrastruktury przechowującej dane
- problemach związanych z bezpieczeństwem danych i SQL Jailingu
- aspektach, które warto wziąć pod uwagę projektując system pod równoczesną obsługę wielu klientów
- pytaniach, które mogą pomóc w doborze odpowiedniej architektury
- rozwiązywaniu problemów technicznych za pomocą narzędzi biznesowych
Więcej na stronie tego odcinka na stronie bettersoftwaredesign.pl.
89. O ciemnej stronie implementacji API z GraphQL z Sebastianem Rabiejem
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 …
Notes de l’épisode
W 2015 roku Meta, a właściwie ówczesny Facebook wydaje pierwszą wersję specyfikacji GraphQL, języka opisu zapytań do API, którego celem jest wydajne i mocno elastyczne pobieranie danych. A ten właśnie problem mocno doskwierał Facebookowi przy implementacji natywnych aplikacji mobilnych. Nadszedł rok 2024 i wiele organizacji przekonało się, że wdrożenie rozbudowanego i wydajnego GraphQL API nie jest zadaniem prostym...
O GraphQL powiedziano już wiele, warto przybliżyć trochę ciemniejszych stron używania tego rozwiązania w projekcie. Dziś zapraszam na rozmowę o cieniach GraphQL-a, a moim gościem jest Sebastian Rabiej, który z tą technologią ma sporo doświadczenia produkcyjnego.
W tym odcinku wspólnie z Sebastianem rozmawiamy między innymi o:
- raporcie Postmana i trendach w stosowaniu poszczególnych styli budowy API
- czym jest GraphQL i jakie problemy rozwiązuje
- zasadach, popularnych narzędziach i frameworkach do budowy GraphQL API
- sposobach atakowania serwera GraphQL
- potencjalnych problemach z wydajnością, bezpieczeństwem i wersjonowaniem takich API
- best practices i sposobach rozwiązania typowych problemów w GraphQL
Materiały dodatkowe:
- Dokumentacja i strona domowa GraphQL
- Dostępne wydania specyfikacji GraphQL
- Artykuł na blogu Meta opisujący jak to się wszystko zaczęło
- Zestaw zaleceń Principled GraphQL
- Praca Migrating to GraphQL: A Practical Assessment
- Wspomniany w odcinku blog post The rise and fall of GraphQL at sennder
- Artykuł Public versus Published Interfaces Martina Fowlera
- [Dokumentacja limitów GraphQL[(https://docs.github.com/en/graphql/overview/rate-limits-and-node-limits-for-the-graphql-api) w API GitHub
- Netflix DGS Framework do implementacji i uruchamiania usług opartych o GraphQL
- GraphQL Voyager, narzędzie wizualizacji schematu API w formie interkatywnego grafu
- GraphQL Cop, narzędzie audytu security API opartych o GraphQL
88. O rewolucji w Angularze i frontendzie na sygnałach z Maciejem Wójcikiem prowadzi Tomasz Ducin
Frontend i jego technologie rozwijają się szybko. Tym razem na horyzoncie w świecie Angulara są Signals, które mogą dość mocno zmienić podejście do projektowania systemu.Po mocnym otwarciu serii o architekturze …
Notes de l’épisode
Frontend i jego technologie rozwijają się szybko. Tym razem na horyzoncie w świecie Angulara są Signals, które mogą dość mocno zmienić podejście do projektowania systemu.
Po mocnym otwarciu serii o architekturze frontendu rozmową z Bartkiem Cytrowskim o makro-frontendzie Atlassiana, pora na temat typowo techniczny, związany jak to często w tym światku bywa, z konkretnym frameworkiem. Gościem Tomka Ducina dziś jest Maciej Wójckik, Software Engineer i Technical Leader w Cisco, a tematem rozmowy są wspomiane już sygnały.
W dzisiejszej rozmowie:
- czym są sygnały i jaki problem rozwiązują
- w czym są podobne, a czym różnią się od istniejących narzędzi reaktywnych typu RxJs
- komponentach, zależnościach, zmianach, template'ach i wydajności systemu
- jak sygnały wpływają na projektowanie i testowanie aplikacji
- z czym wiąże się migracja aplikacji na Signals i jakie problemy mogą się pojawić
Materiały dodatkowe:
- Oficjalna dokumentacja Angular Signals
- Darmowy kurs Angular Signals autorstwa Macieja
87. O roli CTO, budowaniu zespołu, kultury i umiejętności z Danielem Owsiańskim
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 …
Notes de l’épisode
Zostać CTO i móc samodzielnie podejmować wszystkie decyzje techniczne w projekcie i mieć ostateczne zdanie na każdy temat... Taka wizja przyszłości w nawet średniej wielkości organizacji często nie ma jednak zbyt wiele wspólnego z rzeczywistością. Na czym więc polega rola Chief Technology Officera i ile jest w niej realnie technologii?
W wiadomościach od was, na równi z tematami o architekturę, EventStorming czy Domain-Driven Design przewijają się bardo często pytania o dalszą karierę. W jakim kierunku się rozwijać, czy wiązać dalsze plany w IT ze ścieżką stricte techniczną i zostać np. architektem, czy może całkowicie skręcić w stronę managementu i kierowania zespołem czy projektem... W tym wszystkim pytania związane z funkcją i rolą CTO padały chyba najczęściej. Tak więc temat w końcu zagościł na antenie.
Dziś zapraszam Cię na rozmowę z Danielem Owsiańskim, na tematy związane właśnie z funkcją Chief Technology Officera i zarządzania technologią w firmie. Wybór gościa był jak zwykle nieprzypadkowy — Daniel pełni rolę CTO w Volt.io, gdzie mamy okazję na codzień współpracować.
Jeśli chciałbyś/-abyś dołączyć do jednego z naszych projektów w Java, Go lub PHP, tutaj znajdziesz aktualne oferty pracy.
Zapraszam Cię także do odwiedzenia bloga Daniela, owsianski.com, który ostatnio pojawił się w sieci.
86. O DDD w legacy z wykorzystaniem Bubble i Autonomous Contexts z Marcinem Markowskim
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 …
Notes de l’épisode
Wiele osób chciałoby przy każdym projekcie pracować w green-fieldzie i móc wszystkie decyzje podejmować samodzielnie. Rzeczywistość jest jednak zwykle całkowicie inna, musimy żyć z odziedziczonym kodem i zaprojektowanym modelem. Taki green-field, w którym można zacząć projektować i wdrażać nowy model i techniki DDD, można jednak sobie wykroić.
Wspólnie z Marcinem Markowskim rozmawiamy dziś o technikach Bubble Context, Autonomous Context i Legacy As Exposed Service Erica Evansa, dzięki którym można zacząć refaktoryzację legacy. Z mniejszym lub większym związaniem z legacy, w zależności od potrzeb i możliwości w projekcie.
W dzisiejszej rozmowie:
- na czym polegają techniki Bubble i Autonomous Context,
- kiedy warto, a kiedy nie, korzystać z ich możliwości,
- wykorzystaniu istniejących danych w nowym modelu domenowych,
- ACL-backed repository, Ports & Adapters i innych przydatkach tu technikach,
- jakie synchronizować dane między kontekstami i jakie inne wyzwania staną prawdopodobnie na drodze ku lepszemu,
- współpracy w zespole przy wdrażaniu takich technik.
Materiały dodatkowe:
- Artykuł Getting Started with DDD when surrounded by legacy systems Erica Evans, 2013
85. O Architectural Kata i procesie tworzenia architektury z Piotrem Filipowiczem
"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 …
Notes de l’épisode
"Jak mamy pozyskać świetnych architektów, jeśli w swojej karierze będą mieli okazję ją tworzyć mniej niż pół tuzina razy?". Dokładnie takie pytania postawił Ted Neward, szukając sposobu na doskonalenie umiejętności tworzenia architektury. I trudno się tu nie zgodzić, patrząc jak często w zespołach duże projekty powstają od samego początku. Istnieje jednak prosty sposób na rozwiązanie tego problemu.
Sesje Architectural Kata pozwala jednak zdobywać potrzebne doświadczenie znacznie szybciej. Tym bardziej, jeśli feedbacku na temat twojego designu udzielają Mark Richards i Jacqui Read, autorzy książek poświęconych architekturze oprogramowania. W tym roku, kolejną edycję O'Reilly Software Architecture Katas wygrywa po razy pierwszy zespół z Polski, w którego skład wchodzą Artur Kruszewski, Wojciech Kasa, Sebastian Dąbkowski i Piotr Filipowicz, mój dzisiejszy gość.
Razem z Piotrem rozmawiamy dziś między innymi o:
- czym jest Architectural Kata i jak może wspomóc Cię w procesie projektowania architektury
- sześciu perspektywach, które można wziąć pod uwagę szukając właściwej dla projektu architektury
- charakterystykach architektonicznych, ograniczeniach, macierzy styli Marka Richardsa
- komunikowaniu architektury różnym jej odbiorcom, nie tylko zespołowi developerskiemu
- konkretnych przykładach Fitness Function z architektury ewolucyjnej
Zapraszam!
Materiały dodatkowe:
- Fundamentals of Software Architecture: An Engineering Approach, książka Marka Richardsa i Neala Forda
- Software Architecture: The Hard Parts: Modern Trade-Off Analyses for Distributed Architectures, kolejna pozycja, której współautorami są Mark Richards i Neal Ford
- The Architecture Kata Log, repozytorium Jacqui Read z listą zwycięzców poszczególnych edycji konkursu O'Reilly Software Architecture Katas
- StayHealthy.MonitorMe, repozytorium z wspominanym w rozmowie opisem architektury
- Architectural Katas, katalog różnych kat Teda Newarda
Zapraszam także do obserwowania profilu Piotra na LinkedIn.
84. O implementacji testów backendu i architekturze otwartej na testowanie
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 …
Notes de l’épisode
Jeśli wycena projektu podawana jest w dwóch wersjach, z uwzględnieniem testów i bez, to z software craftsmanshipem ma to niewiele wspólnego. To tak, jakby pytać chirurga, czy może przyspieszyć operację nie dezynfekując skalpela. Jakość nie powinna być elementem przetargowym. Chyba, że pracujemy nad proof-of-concept, ale tego rodzaju projekty często lubią płynnie przejść w fazę protoduction...
Jeśli szukasz sprawdzonych w boju receptur na implementację jakościowych testów, które nie będą wymagały co chwilę refaktoryzacji i modyfikacji przy zmianie kodu projektu, zapraszam Cię na dzisiejszą rozmowę z Piotrem Stawirejem. Napisać test w projekcie to w zasadzie żadna sztuka. Ale napisać test, który dostarczy realną wartość biznesową, będzie łatwy do utrzymania, a przy okazji może zostać wykorzystany na różnych poziomach piramidy testów, to trochę bardziej skomplikowane zadanie.
I pewnie niektóre strategie mogą być trochę kontrowersyjne, jak na przykład rezygnacja z typowego mockowania zależności, czy silnego podziału na wiele różnych testów w projekcie. Ale skoro działa to w praktyce, to w czym rzecz?
W tym odcinku rozmawiamy wraz z Piotrem między innymi o:
- organizacyjnych i technicznych problemach z implementacją jakościowych testów w backendzie
- metryce code-coverage i jej różnym stopniu przydatności w projekcie
- profesjonalnym podejściu do problemu "z testami, czy bez?"
- dobrych praktykach doboru strategii testowania
- szarej strefie testów Kevlina Henney'a
- legacy, testach charakterystyki, szwach i odcinaniu fragmentów systemu dla testów
- unitach, czyli fragmentach kodu o pojedynczej odpowiedzialności, mierzonego kohezją
- implementacji architektury otwartej na testowanie
- eliminacji problemów z nadużywaniem mocków w projekcie
Zapraszam!
Materiały dodatkowe:
- Sub-second acceptance tests, prezentacja Aslaka Hellesøy z konferencji SeleniumConf Chicago
- Growing Object-Oriented Software, Guided by Tests, wspomniana w rozmowie książka Steve'a Freemana i Nata Pryce'a
- Style Guide for Object Design, książka Matthiasa Nobacka
- Financial System, repozytorium z przykładowym kodem Piotra
83. O testowaniu systemu end-to-end i Quality Assurance z Arkadiuszem Jelonkiem
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 …
Notes de l’épisode
Odpowiedzialność za zapewnienie jakości w projekcie nie spoczywa na pojedynczej osobie, tylko na całym zespole. A rola QA nie sprowadza się tylko i wyłącznie do projektowania i implementacji przypadków testowych w procesie inspekcji systemu, ale także na byciu adwokatem jakości w projekcie, i czasem zadawaniu trudnych pytań o to, dlaczego pewne funkcjonalności są zrobione w ten, a nie inny sposób.
Do tej pory temat jakości oprogramowania przewijał się głównie z perspektywy developerskiej w rozmowach o testach jednostkowych, Test Driven Development czy różnych odmianach piramidy testów. Na strukturę testów w projekcie warto też spojrzeć z jej drugiej strony, black-boxowych testów end-to-end całego systemu.
Gościem w podkaście jest dziś Arkadiusz Jelonek, pracujący na co dzień jako Senior Quality Assurance Engineer w eSky Group. A rozmawiać będziemy nie tylko i testach E2E systemu, ale także o tym, jaką rolę QA pełni w projekcie i dlaczego QA warto czasem przetłumaczyć jako Questions Asker.
W dzisiejszym odcinku wspólnie z Arkiem rozmawiamy między innymi o:
- roli Quality Assurance w projekcie
- zdobywaniu doświadczenia pracując w Software House, dojrzałej firmie produktowej i startupie
- pytaniach, jakie warto zadać w zespole wchodząc w rolę Questions Asker
- roli testów end-to-end w projekcie
- klasyfikacji, różnicach i doborze właściwych narzędzi wspierających automatyzację testów
- powstaniu Playwrighta i problemach, które to narzędzie rozwiązuje
- testach regresji wizualnej
- sposobach unikania kruchości w testach E2E
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…
Materiały dodatkowe:
- The Evolution of Browser Automation, artykuł i prezentacja Christiana Bromanna z Sauce Labs
- Zawód tester - Od decyzji do zdobycia doświadczenia, książka Radosława Smilgina, dla osób początkujących
- Pasja testowania (wydanie 2, rozszerzone), książka Krzysztofa Jadczyka, także dla początkujących
82. O architekturze makro front-endu Atlassiana z Bartoszem Cytrowskim prowadzi Tomasz Ducin
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ż …
Notes de l’épisode
Tworzenie oprogramowania nie sprowadza się jedynie do backendu, natomiast tematyka architektury front-endu do tej pory była w zasadzie zupełnie nieobecna w Better Software Design. Do tej pory, ponieważ dzisiejszy odcinek otwiera nowy rozdział w podkaście i tego rodzaju zagadnienia będą się co jakiś czas pojawiać. A rozmowy na takie właśnie tematy prowadzić będzie najlepszy znami mi architekt front-endu, Tomasz Ducin.
Tak, tak, nie jest to przejęzyczenie. Przy dzisiejszym poziomie złożoności technik i narzędzi, po prostu nie można znać się na wszystkim. Dlatego mam dużą satysfakcję z tego, że Tomek będzie gościł w Better Software Design w nowej roli, dostarczając wiedzę z najwyższej front-endowej półki. Pozostaje zacząć nowy etap z przysłowioego "wysokiego C" i bardzo interesującym tematem.
Gościem specjalnym dzisiejszego odcinka jest Bartosz Cytrowski, Senior Software Engineer w Atlassianie. Jeśli chcesz się dowiedzieć, jak wygląda architektura makro front-endu w Atlassianie i Jira Cloud, czy jak pracuje się w tak ogromnym i popularnym ekosystemie, to ten odcinek jest właśnie dla Ciebie!
W tym odcinku usłyszysz między innymi o:
- czym jest monorepo, jego zaletach i wadach, a także o tym jak pracuje się z nim w Atlassianie,
- narzędziach wykorzystywanych do rozwoju systemu o takiej skali jak Jira Cloud,
- sposobie pracy w systemie, w którym pojawia się ponad 1000 pull-requestów dziennie,
- kontrolowaniu zależności pomiędzy modułami,
- stosowaniu feature flags i bezpiecznym wprowadzaniu zmian dotykających wielu zespołów,
- testowaniu zmian, dog-foodingu i bezpiecznym wdrażaniu nowych wersji.
Zapraszam!
81. O procesie discovery i wprowadzaniu DDD do organizacji z Darkiem Pawlukiewiczem i Michałem Wilczyńskim
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 …
Notes de l’épisode
Błędów nie popełnia tylko ten, co nic nie robi, a szramy Wietnamu biorą się z nie z czytania książek, tylko z osadzania zawartych w nich idei w złożonej rzeczywistości konkretnych projektów. Dziś zapraszam na rozmowę o często trudnych realiach wprowadzania Domain-Driven Design do organizacji i procesach Domain Discovery.
Moimi gośćmi są Dariusz Pawlukiewicz i Michał Wilczyński, programiści i architekci, zaangażowani w inicjatywę DevMentors. A rozmawiamy przede wszystkim o doświadczeniach związanych z wprowadzaniem DDD do zespołów i organizacji, oraz o częstych problemach występujących w procesach poznawania domeny.
Materiały dodatkowe:
- Domain model purity vs. domain model completeness (DDD Trilemma), wspomniany w rozmowie artykuł Vladimira Khorikova
- The failed promise of Domain-Driven Design - part 1, artykuł Sebastiana Gębskiego
- The failed promise of Domain-Driven Design - part 2, kontynuacja powyższego artykułu
80. O ostrej zasadzie Pareto, DDDozie i innych chorobach projektowych z Piotrem Przybyłem
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 …
Notes de l’épisode
Czy kilka twoich projektów dla różnych klientów ma dokładnie taką samą strukturę wewnętrzną, stosowane są dokładnie te same wzorce organizacji kodu i architektury? Albo wszędzie widzisz możliwość zastosowania CQRS, rozdziału na komendy i query, czy możliwość zaimplementowania taktycznych wzorców z DDD? W wielu przypadkach będzie to zapewne całkowicie uzasadnione, poza tymi, w których nie ma to większego sensu...
Abraham Maslow kiedyś opisał to zjawisko mówiąc: dla człowieka, który dysponuje tylko młotkiem, wszystko, co spotyka zaczyna wyglądać jak gwóźdź. Idąc tym torem, posługiwanie się tylko jednym młotkiem nie jest ani wygodne, ani zdrowe.
Po ostatnich odcinkach podcastu poświęconych architekturze, zapraszam na luźniejszą rozmowę z Piotrem Przybyłem o chorobach, które czasami można zauważyć w naszych projektach i zespołach. A rozmawiamy m.in. o ostrej zasadzie Pareto, projektowym "good enough" i kilku chorobach, które warto mieć na swojej developerskiej uwadze.
Materiały dodatkowe:
- Cztery choroby, prezentacja Piotra z konferencji Boiling Frogs 2019
- Architecture antipatterns and how to beat them, część 1, prezentacja Łukasza Szydło z konferencji 4Developers 2017
- Architecture antipatterns and how to beat them, część 2, kontynuacja powyższej prezentacji
79. O modularyzacji bez użycia subdomen i heurystyk DDD z Łukaszem Szydło
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 …
Notes de l’épisode
Domain-Driven Design jest skuteczną metodą analizy i modelowania złożonych, nierozpoznanych jeszcze problemów biznesowych. Jednak niektóre wzorce strategiczne są bardzo mgliste i mogą nie dostarczać konkretnych sposobów do działania w projekcie. Krytyka DDD w tym obszarze wydaje się mieć sporo podstaw...
Bo czym właściwie jest subdomena? W myśl definicji, subdomena jest zazwyczaj wyodrębnionym obszarem, który może być zarządzany i rozwijany niezależnie od innych, posiadając swoje specyficzne reguły biznesowe, modele i zasoby. Ale czym się subdomena różni od domeny, jak skutecznie wyznaczyć ten "wyodrębiony" obszar i właściwie czemu to ma służyć? Jeśli dodamy to tego lingwistyczne granice kontekstów, to robi się z tego trudna do strawienia mieszanka.
Dziś zapraszam na rozmowę z Łukaszem Szydło, w której dotykamy tematyki modularyzacji systemu w oparciu o inne, prostsze narzędzia. Na koniec dnia zajmujemy się wprowadzaniem zmian, więc zmodularyzujmy system tak, aby było nam je łatwo wprowadzać.
W tym odcinku rozmawiamy z Łukaszem o:
- hype na Domain-Driven Design i trudnościach w jego stosowaniu
- intuicjach, heurystykach vs. praktyki inżynieryjne
- analizie domeny na mniejsze części, poprzez odkrywanie niezależnie zmieniających się w niej rzeczy
- sumulacji zmian i wykorzystaniu atrybutów jakościowych w procesie dekompozycji
- stabilnych granicach aplikowalności modelu, wynikających z wprowadzanych zmian
- weryfikacji wytwarzanych w ten sposób podziałów w projekcie
- dobrych momentach na refaktoryzację systemu
Materiały dodatkowe:
- Wspomniana w odcinku prezentacja Real Software Engineering Glenna Vanderburga, VP of Engineering w First
- SDLab, inicjatywa projektów badawczych w zakresie projektowania oprogramowania
78. O Outbox Pattern i skutecznej komunikacji z Jackiem Milewskim
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 …
Notes de l’épisode
W informatyce są tylko dwie trudne rzeczy: unieważnianie pamięci podręcznej i nazywanie rzeczy... A jeśli mówimy co systemach rozproszonych, to do tej krótkiej listy Phila Karltona należy dopisać jeszcze skuteczną komunikację sieciową. Projektując systemy często zapominamy o tym, jak zawodny może być to komponent. A złośliwie zawiedzie pewnie w bardzo ważnym momencie... Na szczęście możemy temu zapobiec korzystając z wzorca Transactional Outbox.
Do rozmów w podkaście zapraszam osoby, które nie raz czy dwa zderzyły się z danym problemem w życiu i posiadają konkretne doświadczenie. Nie inaczej jest tym razem, a moim gościem jest dziś Jacek Milewski, który na co dzień pracuje jako modelarz i architekt oprogramowania.
W tym odcinku wraz z Jackiem rozmawiamy między innymi o:
- problemach związanych z komunikacją w systemach,
- idei wzorca Transactional Outbox / Store&Forward,
- możliwych sposobach obsługi outboxa w systemie,
- zastosowaniu tego wzorca zarówno w systemach rozproszonych jak i monolitycznych,
- kolejności przetwarzania wiadomości,
- deduplikacji czy message-poisoning.
Materiały dodatkowe:
- Microservices: Transactional outbox oraz AWS Prescriptive Guidance: Transactional Outbox Pattern, opis omawianego w odcinku rozwiązania wraz z przykładowymi diagramami
- Outbox Pattern: kiedy ten strzał do API to jednak za mało, prezentacja Jacka z konferencji Confitura PL 2023
- Push-based Outbox Pattern with Postgres Logical Replication, artykuł Oskara Dudycza przedstawiający rozwiązanie oparte o bazę danych
Zapraszam także do śledzenia profili Jacka na Twitter/X oraz LinkedIn oraz do zapoznania się z listą szkoleń Jacka w Bottega IT Minds.
77. O couplingu i decouplingu w systemie z Grzegorzem Piwowarkiem
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 …
Notes de l’épisode
Gdy coś się dobrze zaczyna, często kończy się źle... A jednym z tego powodów w projekcie jest niekontrolowane wprowadzenie couplingu, czyli sprzęganie różnych jego elementów ze sobą. Różne komponenty nagle stają się od siebie zależne, logika biznesowa połączona z frameworkiem czy bazą danych, a w efekcie całość jest coraz trudniejsza do utrzymania i rozwoju. Zwiększając sprzężenie zmniejszamy kohezję rozwiązania, a w myśl zasad GRASP Low Coupling i High Cohesion warto postępować dokładnie na odwrót.
Na szczęście decoupling może zostać zrealizowany w projekcie na wiele różnych sposobów. A czasem wręcz świadomie pominięty, ponieważ nie przyniesie on oczekiwanych efektów.
Dziś zapraszam na odcinek z Grzegorzem Piwowarkiem na tematy poświęcone couplingowi, decoplingowi i trzymania rzeczy w projekcie niektórych rzeczy (jak frameworki) na dystans, w którym rozmawiamy między innymi o:
- odcinaniu frameworka webowego czy ORM,
- efektach i zyskach płynących z decouplingu,
- przydatnych heurystykach pomagających odpowiedzieć na pytanie, czy warto odcinać daną zależność,
- architekturze heksagonalnej,
- historiach z życia...
Materiały dodatkowe:
- Trzymaj Springa na dystans , wspomniana w rozmowie prezentacja Grzegorza z konferencji Confitura 2022
- Recipes for Decoupling, książka Matthiasa Nobacka opisująca implementację konceptów dla ekosystemu PHP
- 4comprehension.com, strona Grzegorza, na której można zapoznać się zarówno z ofertą szkoleń programistycznych jak i wpisami związanymi z Javą
- pivovarit@x, profil Grzegorza na Twitter/X
Voici les 40 derniers épisodes sur 106. Les épisodes plus anciens se trouvent dans le flux du podcast.
Podcasts similaires
Plus de podcasts : Technologies
C’est votre podcast ?
Confirmez-le avec une entrée dans votre flux : vous recevez ici un code, vous l’ajoutez comme podcast:txt dans le canal de votre flux, et nous le vérifions. Votre podcast apparaît ensuite comme « vérifié » sur SoundNode.