Afleveringen
-
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 kolejkachmożliwych sposobach zaprojektowania infrastruktury przechowującej daneproblemach związanych z bezpieczeństwem danych i SQL Jailinguaspektach, które warto wziąć pod uwagę projektując system pod równoczesną obsługę wielu klientówpytaniach, które mogą pomóc w doborze odpowiedniej architekturyrozwiązywaniu problemów technicznych za pomocą narzędzi biznesowychWięcej na stronie tego odcinka na stronie bettersoftwaredesign.pl.
-
W 2015 roku Meta, a właściwie ówczesny Facebook wydaje pierwszą wersję specyfikacji GraphQL, języka opisu zapytań do API, którego celem jest wydajne i mocno elastyczne pobieranie danych. A ten właśnie problem mocno doskwierał Facebookowi przy implementacji natywnych aplikacji mobilnych. Nadszedł rok 2024 i wiele organizacji przekonało się, że wdrożenie rozbudowanego i wydajnego GraphQL API nie jest zadaniem prostym...
O GraphQL powiedziano już wiele, warto przybliżyć trochę ciemniejszych stron używania tego rozwiązania w projekcie. Dziś zapraszam na rozmowę o cieniach GraphQL-a, a moim gościem jest Sebastian Rabiej, który z tą technologią ma sporo doświadczenia produkcyjnego.
W tym odcinku wspólnie z Sebastianem rozmawiamy między innymi o:
raporcie Postmana i trendach w stosowaniu poszczególnych styli budowy APIczym jest GraphQL i jakie problemy rozwiązujezasadach, popularnych narzędziach i frameworkach do budowy GraphQL APIsposobach atakowania serwera GraphQLpotencjalnych problemach z wydajnością, bezpieczeństwem i wersjonowaniem takich APIbest practices i sposobach rozwiązania typowych problemów w GraphQLMateriały dodatkowe:
Dokumentacja i strona domowa GraphQLDostępne wydania specyfikacji GraphQLArtykuł na blogu Meta opisujący jak to się wszystko zaczęłoZestaw zaleceń Principled GraphQLPraca Migrating to GraphQL: A Practical AssessmentWspomniany w odcinku blog post The rise and fall of GraphQL at sennderArtykuł Public versus Published Interfaces Martina Fowlera[Dokumentacja limitów GraphQL[(https://docs.github.com/en/graphql/overview/rate-limits-and-node-limits-for-the-graphql-api) w API GitHubNetflix DGS Framework do implementacji i uruchamiania usług opartych o GraphQLGraphQL Voyager, narzędzie wizualizacji schematu API w formie interkatywnego grafuGraphQL Cop, narzędzie audytu security API opartych o GraphQL -
Zijn er afleveringen die ontbreken?
-
Frontend i jego technologie rozwijają się szybko. Tym razem na horyzoncie w świecie Angulara są Signals, które mogą dość mocno zmienić podejście do projektowania systemu.
Po mocnym otwarciu serii o architekturze frontendu rozmową z Bartkiem Cytrowskim o makro-frontendzie Atlassiana, pora na temat typowo techniczny, związany jak to często w tym światku bywa, z konkretnym frameworkiem. Gościem Tomka Ducina dziś jest Maciej Wójckik, Software Engineer i Technical Leader w Cisco, a tematem rozmowy są wspomiane już sygnały.
W dzisiejszej rozmowie:
czym są sygnały i jaki problem rozwiązująw czym są podobne, a czym różnią się od istniejących narzędzi reaktywnych typu RxJskomponentach, zależnościach, zmianach, template'ach i wydajności systemujak sygnały wpływają na projektowanie i testowanie aplikacjiz czym wiąże się migracja aplikacji na Signals i jakie problemy mogą się pojawićMateriały dodatkowe:
Oficjalna dokumentacja Angular SignalsDarmowy kurs Angular Signals autorstwa Macieja -
Zostać CTO i móc samodzielnie podejmować wszystkie decyzje techniczne w projekcie i mieć ostateczne zdanie na każdy temat... Taka wizja przyszłości w nawet średniej wielkości organizacji często nie ma jednak zbyt wiele wspólnego z rzeczywistością. Na czym więc polega rola Chief Technology Officera i ile jest w niej realnie technologii?
W wiadomościach od was, na równi z tematami o architekturę, EventStorming czy Domain-Driven Design przewijają się bardo często pytania o dalszą karierę. W jakim kierunku się rozwijać, czy wiązać dalsze plany w IT ze ścieżką stricte techniczną i zostać np. architektem, czy może całkowicie skręcić w stronę managementu i kierowania zespołem czy projektem... W tym wszystkim pytania związane z funkcją i rolą CTO padały chyba najczęściej. Tak więc temat w końcu zagościł na antenie.
Dziś zapraszam Cię na rozmowę z Danielem Owsiańskim, na tematy związane właśnie z funkcją Chief Technology Officera i zarządzania technologią w firmie. Wybór gościa był jak zwykle nieprzypadkowy — Daniel pełni rolę CTO w Volt.io, gdzie mamy okazję na codzień współpracować.
Jeśli chciałbyś/-abyś dołączyć do jednego z naszych projektów w Java, Go lub PHP, tutaj znajdziesz aktualne oferty pracy.
Zapraszam Cię także do odwiedzenia bloga Daniela, owsianski.com, który ostatnio pojawił się w sieci.
-
Wiele osób chciałoby przy każdym projekcie pracować w green-fieldzie i móc wszystkie decyzje podejmować samodzielnie. Rzeczywistość jest jednak zwykle całkowicie inna, musimy żyć z odziedziczonym kodem i zaprojektowanym modelem. Taki green-field, w którym można zacząć projektować i wdrażać nowy model i techniki DDD, można jednak sobie wykroić.
Wspólnie z Marcinem Markowskim rozmawiamy dziś o technikach Bubble Context, Autonomous Context i Legacy As Exposed Service Erica Evansa, dzięki którym można zacząć refaktoryzację legacy. Z mniejszym lub większym związaniem z legacy, w zależności od potrzeb i możliwości w projekcie.
W dzisiejszej rozmowie:
na czym polegają techniki Bubble i Autonomous Context,kiedy warto, a kiedy nie, korzystać z ich możliwości,wykorzystaniu istniejących danych w nowym modelu domenowych,ACL-backed repository, Ports & Adapters i innych przydatkach tu technikach,jakie synchronizować dane między kontekstami i jakie inne wyzwania staną prawdopodobnie na drodze ku lepszemu,współpracy w zespole przy wdrażaniu takich technik.Materiały dodatkowe:
Artykuł Getting Started with DDD when surrounded by legacy systems Erica Evans, 2013 -
"Jak mamy pozyskać świetnych architektów, jeśli w swojej karierze będą mieli okazję ją tworzyć mniej niż pół tuzina razy?". Dokładnie takie pytania postawił Ted Neward, szukając sposobu na doskonalenie umiejętności tworzenia architektury. I trudno się tu nie zgodzić, patrząc jak często w zespołach duże projekty powstają od samego początku. Istnieje jednak prosty sposób na rozwiązanie tego problemu.
Sesje Architectural Kata pozwala jednak zdobywać potrzebne doświadczenie znacznie szybciej. Tym bardziej, jeśli feedbacku na temat twojego designu udzielają Mark Richards i Jacqui Read, autorzy książek poświęconych architekturze oprogramowania. W tym roku, kolejną edycję O'Reilly Software Architecture Katas wygrywa po razy pierwszy zespół z Polski, w którego skład wchodzą Artur Kruszewski, Wojciech Kasa, Sebastian Dąbkowski i Piotr Filipowicz, mój dzisiejszy gość.
Razem z Piotrem rozmawiamy dziś między innymi o:
czym jest Architectural Kata i jak może wspomóc Cię w procesie projektowania architekturysześciu perspektywach, które można wziąć pod uwagę szukając właściwej dla projektu architekturycharakterystykach architektonicznych, ograniczeniach, macierzy styli Marka Richardsakomunikowaniu architektury różnym jej odbiorcom, nie tylko zespołowi developerskiemukonkretnych przykładach Fitness Function z architektury ewolucyjnejZapraszam!
Materiały dodatkowe:
Fundamentals of Software Architecture: An Engineering Approach, książka Marka Richardsa i Neala FordaSoftware Architecture: The Hard Parts: Modern Trade-Off Analyses for Distributed Architectures, kolejna pozycja, której współautorami są Mark Richards i Neal FordThe Architecture Kata Log, repozytorium Jacqui Read z listą zwycięzców poszczególnych edycji konkursu O'Reilly Software Architecture KatasStayHealthy.MonitorMe, repozytorium z wspominanym w rozmowie opisem architekturyArchitectural Katas, katalog różnych kat Teda NewardaZapraszam także do obserwowania profilu Piotra na LinkedIn.
-
Jeśli wycena projektu podawana jest w dwóch wersjach, z uwzględnieniem testów i bez, to z software craftsmanshipem ma to niewiele wspólnego. To tak, jakby pytać chirurga, czy może przyspieszyć operację nie dezynfekując skalpela. Jakość nie powinna być elementem przetargowym. Chyba, że pracujemy nad proof-of-concept, ale tego rodzaju projekty często lubią płynnie przejść w fazę protoduction...
Jeśli szukasz sprawdzonych w boju receptur na implementację jakościowych testów, które nie będą wymagały co chwilę refaktoryzacji i modyfikacji przy zmianie kodu projektu, zapraszam Cię na dzisiejszą rozmowę z Piotrem Stawirejem. Napisać test w projekcie to w zasadzie żadna sztuka. Ale napisać test, który dostarczy realną wartość biznesową, będzie łatwy do utrzymania, a przy okazji może zostać wykorzystany na różnych poziomach piramidy testów, to trochę bardziej skomplikowane zadanie.
I pewnie niektóre strategie mogą być trochę kontrowersyjne, jak na przykład rezygnacja z typowego mockowania zależności, czy silnego podziału na wiele różnych testów w projekcie. Ale skoro działa to w praktyce, to w czym rzecz?
W tym odcinku rozmawiamy wraz z Piotrem między innymi o:
organizacyjnych i technicznych problemach z implementacją jakościowych testów w backendziemetryce code-coverage i jej różnym stopniu przydatności w projekcieprofesjonalnym podejściu do problemu "z testami, czy bez?"dobrych praktykach doboru strategii testowaniaszarej strefie testów Kevlina Henney'alegacy, testach charakterystyki, szwach i odcinaniu fragmentów systemu dla testówunitach, czyli fragmentach kodu o pojedynczej odpowiedzialności, mierzonego kohezjąimplementacji architektury otwartej na testowanieeliminacji problemów z nadużywaniem mocków w projekcieZapraszam!
Materiały dodatkowe:
Sub-second acceptance tests, prezentacja Aslaka Hellesøy z konferencji SeleniumConf ChicagoGrowing Object-Oriented Software, Guided by Tests, wspomniana w rozmowie książka Steve'a Freemana i Nata Pryce'aStyle Guide for Object Design, książka Matthiasa NobackaFinancial System, repozytorium z przykładowym kodem Piotra -
Odpowiedzialność za zapewnienie jakości w projekcie nie spoczywa na pojedynczej osobie, tylko na całym zespole. A rola QA nie sprowadza się tylko i wyłącznie do projektowania i implementacji przypadków testowych w procesie inspekcji systemu, ale także na byciu adwokatem jakości w projekcie, i czasem zadawaniu trudnych pytań o to, dlaczego pewne funkcjonalności są zrobione w ten, a nie inny sposób.
Do tej pory temat jakości oprogramowania przewijał się głównie z perspektywy developerskiej w rozmowach o testach jednostkowych, Test Driven Development czy różnych odmianach piramidy testów. Na strukturę testów w projekcie warto też spojrzeć z jej drugiej strony, black-boxowych testów end-to-end całego systemu.
Gościem w podkaście jest dziś Arkadiusz Jelonek, pracujący na co dzień jako Senior Quality Assurance Engineer w eSky Group. A rozmawiać będziemy nie tylko i testach E2E systemu, ale także o tym, jaką rolę QA pełni w projekcie i dlaczego QA warto czasem przetłumaczyć jako Questions Asker.
W dzisiejszym odcinku wspólnie z Arkiem rozmawiamy między innymi o:
roli Quality Assurance w projekciezdobywaniu doświadczenia pracując w Software House, dojrzałej firmie produktowej i startupiepytaniach, jakie warto zadać w zespole wchodząc w rolę Questions Askerroli testów end-to-end w projekcieklasyfikacji, różnicach i doborze właściwych narzędzi wspierających automatyzację testówpowstaniu Playwrighta i problemach, które to narzędzie rozwiązujetestach regresji wizualnejsposobach unikania kruchości w testach E2ETen odcinek jest także pierwszym z mini-serii rozmów poświęconych rozwojowi własnej kariery w IT, nie tylko na stanowisku developera. Myślisz o tym, aby pracować w tej branży np. jako Solution Architect, Engineering Manager, Chief Technology Officer czy zostać konsultantem? To tylko niektóre role i stanowiska, które pojawią się w przyszłych odcinkach Better Software Design…
Materiały dodatkowe:
The Evolution of Browser Automation, artykuł i prezentacja Christiana Bromanna z Sauce LabsZawód tester - Od decyzji do zdobycia doświadczenia, książka Radosława Smilgina, dla osób początkującychPasja testowania (wydanie 2, rozszerzone), książka Krzysztofa Jadczyka, także dla początkujących -
Tworzenie oprogramowania nie sprowadza się jedynie do backendu, natomiast tematyka architektury front-endu do tej pory była w zasadzie zupełnie nieobecna w Better Software Design. Do tej pory, ponieważ dzisiejszy odcinek otwiera nowy rozdział w podkaście i tego rodzaju zagadnienia będą się co jakiś czas pojawiać. A rozmowy na takie właśnie tematy prowadzić będzie najlepszy znami mi architekt front-endu, Tomasz Ducin.
Tak, tak, nie jest to przejęzyczenie. Przy dzisiejszym poziomie złożoności technik i narzędzi, po prostu nie można znać się na wszystkim. Dlatego mam dużą satysfakcję z tego, że Tomek będzie gościł w Better Software Design w nowej roli, dostarczając wiedzę z najwyższej front-endowej półki. Pozostaje zacząć nowy etap z przysłowioego "wysokiego C" i bardzo interesującym tematem.
Gościem specjalnym dzisiejszego odcinka jest Bartosz Cytrowski, Senior Software Engineer w Atlassianie. Jeśli chcesz się dowiedzieć, jak wygląda architektura makro front-endu w Atlassianie i Jira Cloud, czy jak pracuje się w tak ogromnym i popularnym ekosystemie, to ten odcinek jest właśnie dla Ciebie!
W tym odcinku usłyszysz między innymi o:
czym jest monorepo, jego zaletach i wadach, a także o tym jak pracuje się z nim w Atlassianie,narzędziach wykorzystywanych do rozwoju systemu o takiej skali jak Jira Cloud,sposobie pracy w systemie, w którym pojawia się ponad 1000 pull-requestów dziennie,kontrolowaniu zależności pomiędzy modułami,stosowaniu feature flags i bezpiecznym wprowadzaniu zmian dotykających wielu zespołów,testowaniu zmian, dog-foodingu i bezpiecznym wdrażaniu nowych wersji.Zapraszam!
-
Błędów nie popełnia tylko ten, co nic nie robi, a szramy Wietnamu biorą się z nie z czytania książek, tylko z osadzania zawartych w nich idei w złożonej rzeczywistości konkretnych projektów. Dziś zapraszam na rozmowę o często trudnych realiach wprowadzania Domain-Driven Design do organizacji i procesach Domain Discovery.
Moimi gośćmi są Dariusz Pawlukiewicz i Michał Wilczyński, programiści i architekci, zaangażowani w inicjatywę DevMentors. A rozmawiamy przede wszystkim o doświadczeniach związanych z wprowadzaniem DDD do zespołów i organizacji, oraz o częstych problemach występujących w procesach poznawania domeny.
Materiały dodatkowe:
Domain model purity vs. domain model completeness (DDD Trilemma), wspomniany w rozmowie artykuł Vladimira KhorikovaThe failed promise of Domain-Driven Design - part 1, artykuł Sebastiana GębskiegoThe failed promise of Domain-Driven Design - part 2, kontynuacja powyższego artykułu -
Czy kilka twoich projektów dla różnych klientów ma dokładnie taką samą strukturę wewnętrzną, stosowane są dokładnie te same wzorce organizacji kodu i architektury? Albo wszędzie widzisz możliwość zastosowania CQRS, rozdziału na komendy i query, czy możliwość zaimplementowania taktycznych wzorców z DDD? W wielu przypadkach będzie to zapewne całkowicie uzasadnione, poza tymi, w których nie ma to większego sensu...
Abraham Maslow kiedyś opisał to zjawisko mówiąc: dla człowieka, który dysponuje tylko młotkiem, wszystko, co spotyka zaczyna wyglądać jak gwóźdź. Idąc tym torem, posługiwanie się tylko jednym młotkiem nie jest ani wygodne, ani zdrowe.
Po ostatnich odcinkach podcastu poświęconych architekturze, zapraszam na luźniejszą rozmowę z Piotrem Przybyłem o chorobach, które czasami można zauważyć w naszych projektach i zespołach. A rozmawiamy m.in. o ostrej zasadzie Pareto, projektowym "good enough" i kilku chorobach, które warto mieć na swojej developerskiej uwadze.
Materiały dodatkowe:
Cztery choroby, prezentacja Piotra z konferencji Boiling Frogs 2019Architecture antipatterns and how to beat them, część 1, prezentacja Łukasza Szydło z konferencji 4Developers 2017Architecture antipatterns and how to beat them, część 2, kontynuacja powyższej prezentacji -
Domain-Driven Design jest skuteczną metodą analizy i modelowania złożonych, nierozpoznanych jeszcze problemów biznesowych. Jednak niektóre wzorce strategiczne są bardzo mgliste i mogą nie dostarczać konkretnych sposobów do działania w projekcie. Krytyka DDD w tym obszarze wydaje się mieć sporo podstaw...
Bo czym właściwie jest subdomena? W myśl definicji, subdomena jest zazwyczaj wyodrębnionym obszarem, który może być zarządzany i rozwijany niezależnie od innych, posiadając swoje specyficzne reguły biznesowe, modele i zasoby. Ale czym się subdomena różni od domeny, jak skutecznie wyznaczyć ten "wyodrębiony" obszar i właściwie czemu to ma służyć? Jeśli dodamy to tego lingwistyczne granice kontekstów, to robi się z tego trudna do strawienia mieszanka.
Dziś zapraszam na rozmowę z Łukaszem Szydło, w której dotykamy tematyki modularyzacji systemu w oparciu o inne, prostsze narzędzia. Na koniec dnia zajmujemy się wprowadzaniem zmian, więc zmodularyzujmy system tak, aby było nam je łatwo wprowadzać.
W tym odcinku rozmawiamy z Łukaszem o:
hype na Domain-Driven Design i trudnościach w jego stosowaniuintuicjach, heurystykach vs. praktyki inżynieryjneanalizie domeny na mniejsze części, poprzez odkrywanie niezależnie zmieniających się w niej rzeczysumulacji zmian i wykorzystaniu atrybutów jakościowych w procesie dekompozycjistabilnych granicach aplikowalności modelu, wynikających z wprowadzanych zmianweryfikacji wytwarzanych w ten sposób podziałów w projekciedobrych momentach na refaktoryzację systemuMateriały dodatkowe:
Wspomniana w odcinku prezentacja Real Software Engineering Glenna Vanderburga, VP of Engineering w FirstSDLab, inicjatywa projektów badawczych w zakresie projektowania oprogramowania -
W informatyce są tylko dwie trudne rzeczy: unieważnianie pamięci podręcznej i nazywanie rzeczy... A jeśli mówimy co systemach rozproszonych, to do tej krótkiej listy Phila Karltona należy dopisać jeszcze skuteczną komunikację sieciową. Projektując systemy często zapominamy o tym, jak zawodny może być to komponent. A złośliwie zawiedzie pewnie w bardzo ważnym momencie... Na szczęście możemy temu zapobiec korzystając z wzorca Transactional Outbox.
Do rozmów w podkaście zapraszam osoby, które nie raz czy dwa zderzyły się z danym problemem w życiu i posiadają konkretne doświadczenie. Nie inaczej jest tym razem, a moim gościem jest dziś Jacek Milewski, który na co dzień pracuje jako modelarz i architekt oprogramowania.
W tym odcinku wraz z Jackiem rozmawiamy między innymi o:
problemach związanych z komunikacją w systemach,idei wzorca Transactional Outbox / Store&Forward,możliwych sposobach obsługi outboxa w systemie,zastosowaniu tego wzorca zarówno w systemach rozproszonych jak i monolitycznych,kolejności przetwarzania wiadomości,deduplikacji czy message-poisoning.Materiały dodatkowe:
Microservices: Transactional outbox oraz AWS Prescriptive Guidance: Transactional Outbox Pattern, opis omawianego w odcinku rozwiązania wraz z przykładowymi diagramamiOutbox Pattern: kiedy ten strzał do API to jednak za mało, prezentacja Jacka z konferencji Confitura PL 2023Push-based Outbox Pattern with Postgres Logical Replication, artykuł Oskara Dudycza przedstawiający rozwiązanie oparte o bazę danychZapraszam także do śledzenia profili Jacka na Twitter/X oraz LinkedIn oraz do zapoznania się z listą szkoleń Jacka w Bottega IT Minds.
-
Gdy coś się dobrze zaczyna, często kończy się źle... A jednym z tego powodów w projekcie jest niekontrolowane wprowadzenie couplingu, czyli sprzęganie różnych jego elementów ze sobą. Różne komponenty nagle stają się od siebie zależne, logika biznesowa połączona z frameworkiem czy bazą danych, a w efekcie całość jest coraz trudniejsza do utrzymania i rozwoju. Zwiększając sprzężenie zmniejszamy kohezję rozwiązania, a w myśl zasad GRASP Low Coupling i High Cohesion warto postępować dokładnie na odwrót.
Na szczęście decoupling może zostać zrealizowany w projekcie na wiele różnych sposobów. A czasem wręcz świadomie pominięty, ponieważ nie przyniesie on oczekiwanych efektów.
Dziś zapraszam na odcinek z Grzegorzem Piwowarkiem na tematy poświęcone couplingowi, decoplingowi i trzymania rzeczy w projekcie niektórych rzeczy (jak frameworki) na dystans, w którym rozmawiamy między innymi o:
odcinaniu frameworka webowego czy ORM,efektach i zyskach płynących z decouplingu,przydatnych heurystykach pomagających odpowiedzieć na pytanie, czy warto odcinać daną zależność,architekturze heksagonalnej,historiach z życia...Materiały dodatkowe:
Trzymaj Springa na dystans , wspomniana w rozmowie prezentacja Grzegorza z konferencji Confitura 2022Recipes for Decoupling, książka Matthiasa Nobacka opisująca implementację konceptów dla ekosystemu PHP4comprehension.com, strona Grzegorza, na której można zapoznać się zarówno z ofertą szkoleń programistycznych jak i wpisami związanymi z Javąpivovarit@x, profil Grzegorza na Twitter/X -
Mijający właśnie rok dla Better Software Design był szczególny i "naj" z wielu powodów - liczby nowych odcinków, odsłuchanych rozmów, nowych słuchaczy... Nie byłoby tego podcastu bez was, także w tym roku w formie podcastowego prezentu i podziękowania za wspólnie spędzony rok, zapraszam na odcinek specjalny.
Wraz z Wojtkiem Ptakiem i Jarkiem Pałką, znanych doskonale z kilku poprzednich odcinków podcastu, rozmawiamy o karierze w IT z perspektywy naszych wspólnych... ponad 77 lat spędzonych w branży IT. W tym odcinku zaczynamy od łączenia kropek, które każdy z nas postawił na swojej developerskiej (i nie tylko) drodze...
Jedną z takich moich kropek (choć niestety nie wspomnianą podczas rozmowy) było dołączenie do niektórych prac kierowanego przez Wojtka zespołu. Gdy na 2 godziny przed rozpoczęciem właściwej pracy analizuje się wspólnie wykorzystywane w projekcie techniki, wypracowuje na ich podstawie własne podejście do software developmentu, którym można się dzielić z innymi - czego chcieć więcej?
Zapraszam!
-
"Jako użytkownik chcę przeszukać bazę książek, aby znaleźć kilka książek" - takiego rodzaju User Story są niestety dość typowe i w zasadzie niewiele dobrego wnoszą do projektu. A trudności, jakie często pojawiały się przy formułowaniu wartościowych User Story, skutkowały się pojawianiem różnych technik wspomagających ich rozpoznanie. Kuźnią wielu pomysłów były prace zespołów stosujących Extreme Programming w projektach Chrysler C3 i Connextra... Kompleksowe podejście zarówno do identyfikacji User Stories jak i ich dalszego wykorzystania z projekcie zaproponował w końcu w 2014 roku Jeff Patton, proponując warsztatową technikę User Story Mapping.
W tym odcinku Better Software Design dodajemy więc User Story Mapping do naszego analitycznego toolboksa. A moim gościem w tej rozmowie jest Michał Bartyzel, który bardzo mocno wykorzystuje tę technikę w swojej codziennej pracy z zespołami.
W tym odcinku rozmawiamy z Michałem między innymi o:
bezużyteczności wielu historyjek typu "Jako klient chcę się zalogować, aby zrobić zakup w sklepie",odkrywaniu właściwych aktorów, ich celi biznesowych i funkcjonalności, które służą ich osiągnięciu,sposobach budowania mapy historyjek, zgodnie z założeniami User Story Mappingu,wykorzystaniu USM w projekcie,różnicach i podobieństwam pomiędzy EventStormingiem i User Story Mappingiem,sposobach prowadzenia warsztatu analitycznego.Materiały dodatkowe:
It's All in How You Slice, artykuł Jeffa Pattona opisujący pierwotne założenia techniki, rozwiniętej następnie do User Story MappinguThe New User Story Backlog is a Map, drugi po artykule istotny wpis Pattona na temat problemów z historyjkamiUser Story Mapping: Discover the Whole Story, Build the Right Product, książka Jeffa z 2012 roku, przedstawiająca technikę User Story MappinguStory Map Concepts oraz Agile Story Essentials, krótkie i rzeczowe podsumowania pokazujące zasadę działania USMPolecam także zajrzeć na stronę Michała, a w szczególności na prowadzonego przez niego bloga.
Zapraszam!
-
Stres w pracy nie jest rzadkim zjawiskiem. Pozostawiony sam sobie przez dłuższy czas, może zacząć wyrządzać nam więcej szkód, w tym doprowadzić do syndromu wypalenia zawodowego.
O tym jak może się objawiać wypalenie w naszym codziennym życiu, jak można sobie z nim radzić i jak reagować, gdy problem zaczyna dotykać osoby w naszym otoczeniu - o tym wszystkim rozmawiamy dziś z Olą Kunysz. Bez technologii i architektury, ale o własnych doświadczeniach z wypaleniem w kontekście branży IT.
Materiały dodatkowe:
The Burnout Index, darmowy test Yerbo wspomagający określenie poziomu ryzyka zagrożenia wypaleniem,Test BAT12, prostszy test w języku polskim,Nie wypalaj się! Jak żonglerka może uratować pracowników IT?, prezentacja Oli na TedX KoszalinOla@Instagram, profil Oli na Instagramie, gdzie dzieli się m.in. informacjami na tematy związane z wypaleniem zawodowym -
Eventy stanowią naturalny sposób komunikacji w systemach rozproszonych. Jednak przesyłanie i dalsze przetwarzanie zdarzeń z jednego systemu do drugiego zazwyczaj wymaga określonej infrastruktury i wprowadza do systemu nowy rodzaj złożoności. Zawodność przesyłania danych, unikanie wielokrotnego przetwarzania tych samych wiadomości, zapewnianie kolejności ich przetwarzania czy odpowiedniej wydajności całej aplikacji - to tylko niektóre z czekających tu wyzwań.
Dziś zapraszam na rozmowę o message brokerach i event-streamingu. Wraz z dzisiejszym gościem, Piotrem Gankiewiczem, rozmawiamy między innymi o:
różnicach pomiędzy message-brokerami a platformami do event-streamingu,wykorzystywanej w obu przypadkach terminologii,zrównoleglaniu procesów i zapewnianiu odpowiedniego porządku przetwarzania pochodzących ze strumieni zdarzeń.Zapraszam!
Materiały dodatkowe:
Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems, Martin Kleppmann, 2015Distributed Systems lecture series, playlista materiałów na temat projektowania systemów rozproszonychBuilding a Distributed Log from Scratch, seria artykułów na temat tworzenia systemów rozproszonychThe Consistent Hash Exchange, artykuł na temat opisywanego w odcinku algorytmu przypisywania konsumerów w RabbitMQOrdering Distributed Events, artykuł Vaidehi Joshi na temat porządkowania zdarzeńDistributed Systems: Time and order, teoria porządkowania w systemach rozproszonychYou Cannot Have Exactly-Once DeliveryZapraszam także do odwiedzenia:
Iggy.rs, strona domowa projektu IggyPiotr@GithubPiotr@X / Twitter -
Encje domenowe to obok Value Objectów jeden z podstawowych wzorców implementacyjnych Domain-Driven Design. Mogą działać zarówno samodzielnie, jak i być częścią innych struktur, np. agregatów. Ale czym właściwie są encje i co odróżnia je od pozostałych wzorców taktycznego DDD?
W telegraficznym skrócie encje to obiekty domenowe posiadające ściśle określoną tożsamość, które z jakiegoś powodu muszą być śledzone na przestrzeni czasu. Gościem dzisiejszej rozmowy jest Kamil Grzybek, który pojawił się już w Better Software Design przy okazji rozmów o modularyzacji monolitu czy testowalności oprogramowania.
W tym odcinku rozmawiamy między innymi o:
przeznaczeniu wzorca Entity,różnych metodach nadawania tożsamości obiektom,podziałach encji względem cykli życia w domenie,różnicach pomiędzy encjami a agregatami czy Value Objectami,mapowaniu encji domenowych na encje bazodanowe.Zapraszam!
Materiały dodatkowe:
Implementing Domain-Driven Design, rozdział 5 poświęcony encjom domenowymWhat Is the Hi/Lo Algorithm?, artykuł na temat algorytmu Hi/Lo do generacji identyfikatorówEntity Identity vs Database Primary KeyModular Monolith with DDD, repozytorium Kamila, w którym moduły korzystają ze wszystkich wzorców omawianych w odcinku wzorców taktycznych -
W greenfieldzie, który jeszcze nie dotarł do środowiska produkcyjnego zazwyczaj wszystko jest dość proste. Nawet przy zupełnej zmianie koncepcji w najgorszym razie można postawić bazę danych czy środowisko od zera. Jednak gdy system działa na produkcji, trzeba wprowadzać w nim głębsze zmiany, a do tabel w bazie przywiązana jest nie tylko aplikacja, sytuacja trochę się komplikuje. Dziś zapraszam na rozmowę o wprowadzaniu EventSourcingu do projektu, na przykładzie prawdziwego systemu obsługi cashflow.
Moim gościem jest Łukasz Reszke, pracujący na co dzień właśnie przy projektach opartych o event-store i EventSourcing.
W tym odcinku rozmawiamy z Łukaszem między innymi o:
praktycznym zastosowaniu EventSourcingu w projekcie z problemami u klienta,wdrażaniu EventSourcingowego modułu do aplikacji z istniejącą relacyjną bazą i danymi,publikacji eventów do pozostałej części systemu i rodzajach eventów,odczytywaniu danych ze zdarzeń, strumieniach i linkowaniu do nich zdarzeń.Materiały dodatkowe:
Working with RailsEventStore in Cashflow Management System, prezentacja Łukasza z konferencji wroc_love.rb 2023Eventsourcing Patterns: Migration Events in a Ghost Context, artykuł Mathiasa Verraesa o imporcie danych z systemów legacy do modelu opartego o zdarzeniaPatterns for Decoupling in Distributed Systems: Summary Event, kolejny artykuł Mathiasa Verraesa, tym razem o emitowaniu zdarzeń zbiorczychŁukasz@X, profil Łukasza na X/TwitterWspomniany w intro odcinek nr 10 z Andrzejem Krzywdą o refaktoryzacji The Arkency Way można znaleźć tutaj.
- Laat meer zien
