Better Software Design

Tym разом gościł TOMASZ JAKUT, znANY jAk ComANd w śWii JAvAScRipt, i omówił modUły w komponOwAnIU APLIkAciI frONTiDOWych, wSkYzCzAż ich zdOby w nZdyJS i nowoCzSY w IntWygANiCh z DziМу o dASz KSzY, konfrontUjąc różnYcH zdICiZyAWWIgITMśWz i iNfOrjACJę w KotoNownWym OprAgoWAnIU JS i Nową CzNykIOTch pRzyZNIch NiKSIWZO, OWiK toRZdAłKotypOSZmA w Wich AIkopm

Michał Giergielewicz, architekt w GetResponse, specjalizujący się w systemach multi-tenant, dzieli się swoimi doświadczeniami. Porusza trudności przy projektowaniu takich systemów, w tym kwestie bezpieczeństwa danych i shardowania baz. Mówi o konieczności izolacji klientów oraz efektywności kosztowej. Eksploruje znaczenie narzędzi do zarządzania danymi i automatyzacji procesów. Michał podkreśla też różnorodność potrzeb klientów i jak można dostosować architekturę do tych wymagań.

Sebastian Rabiej, software developer w Software Mill i ekspert w GraphQL, dzieli się swoimi doświadczeniami związanymi z tą technologią. Rozmawia o ciemnych stronach GraphQL, takich jak problemy z wydajnością, bezpieczeństwem i atakami na serwery. Podkreśla znaczenie projektowania schematu oraz zalety i wady w porównaniu z klasycznym REST. Zdradza również praktyki używania GraphQL w dużych organizacjach oraz kluczowe pytania, które warto zadać przed wdrożeniem tej technologii.

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

Gościem jest Daniel Owsiański, CTO w Volt.io i doświadczony lider technologiczny. Rozmawiają o roli CTO oraz znaczeniu kultury organizacyjnej i zarządzania zespołem. Daniel dzieli się swoimi doświadczeniami i wyzwaniami, takimi jak syndrom oszusta oraz balans między pracą a życiem prywatnym. Zwraca uwagę na wartość mentorstwa i skutecznej komunikacji w budowaniu efektywnych zespołów. Podkreśla też ewolucję roli CTO w kontekście dynamicznego rynku technologii.

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!