Better Software Design

Better Software Design podcast. Rozmowy o projektowaniu oprogramowania, architekturze i wyzwaniach z tym związanych.

Link RSS Link do katalogu Numer katalogowy: 4611 Wesprzyj dobrym słowem
Udostępnij
Kategorie:
Technologia

Odcinki od najnowszych:

77. O couplingu i decouplingu w systemie z Grzegorzem Piwowarkiem
2024-01-02 01:00:00

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

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

76. O 77 latach doświadczeń w branży IT z Wojtkiem Ptakiem i Jarkiem Pałką
2023-12-26 01:00:00

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!

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!

75. O User Story Mapping i analizie warsztatowej z Michałem Bartyzelem
2023-12-19 01:00:00

"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 Mappingu The New User Story Backlog is a Map , drugi po artykule istotny wpis Pattona na temat problemów z historyjkami User Story Mapping: Discover the Whole Story, Build the Right Product , książka Jeffa z 2012 roku, przedstawiająca technikę User Story Mappingu Story Map Concepts oraz Agile Story Essentials , krótkie i rzeczowe podsumowania pokazujące zasadę działania USM Polecam także zajrzeć na stronę Michała , a w szczególności na prowadzonego przez niego bloga . 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:

Polecam także zajrzeć na stronę Michała, a w szczególności na prowadzonego przez niego bloga.

Zapraszam!

74. O syndromie wypalenia zawodowego z Olą Kunysz
2023-12-05 01:00:00

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 Koszalin Ola@Instagram , profil Oli na Instagramie, gdzie dzieli się m.in. informacjami na tematy związane z wypaleniem zawodowym

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:

73. O streamingu eventów w systemie z Piotrem Gankiewiczem
2023-11-21 01:00:00

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, 2015 Distributed Systems lecture series , playlista materiałów na temat projektowania systemów rozproszonych Building a Distributed Log from Scratch , seria artykułów na temat tworzenia systemów rozproszonych The Consistent Hash Exchange , artykuł na temat opisywanego w odcinku algorytmu przypisywania konsumerów w RabbitMQ Ordering Distributed Events , artykuł Vaidehi Joshi na temat porządkowania zdarzeń Distributed Systems: Time and order , teoria porządkowania w systemach rozproszonych You Cannot Have Exactly-Once Delivery Zapraszam także do odwiedzenia: Iggy.rs , strona domowa projektu Iggy Piotr@Github Piotr@X / Twitter

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:

Zapraszam także do odwiedzenia:

72. O encjach w Domain-Driven Design z Kamilem Grzybkiem
2023-10-24 01:00:00

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 domenowym What Is the Hi/Lo Algorithm? , artykuł na temat algorytmu Hi/Lo do generacji identyfikatorów Entity Identity vs Database Primary Key Modular Monolith with DDD , repozytorium Kamila, w którym moduły korzystają ze wszystkich wzorców omawianych w odcinku wzorców taktycznych

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:

71. O doświadczeniach z EventSourcingiem w projekcie z Łukaszem Reszke
2023-10-10 01:00:00

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 2023 Eventsourcing Patterns: Migration Events in a Ghost Context , artykuł Mathiasa Verraesa o imporcie danych z systemów legacy do modelu opartego o zdarzenia Patterns for Decoupling in Distributed Systems: Summary Event , kolejny artykuł Mathiasa Verraesa, tym razem o emitowaniu zdarzeń zbiorczych Łukasz@X , profil Łukasza na X/Twitter Wspomniany w intro odcinek nr 10 z Andrzejem Krzywdą o refaktoryzacji The Arkency Way można znaleźć tutaj .

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:

Wspomniany w intro odcinek nr 10 z Andrzejem Krzywdą o refaktoryzacji The Arkency Way można znaleźć tutaj.

70. O Testcontainers, piramidzie testów i jakości życia z Piotrem Przybyłem
2023-09-26 01:00:00

Każdy kod zostanie przetestowany, wcześniej bądź później. Pozostają jedynie pytania na jakim etapie i przez kogo zostanie to wykonane i jaki będzie tego ostateczny koszt. Gdy aplikacja staje się złożona i tworzy ją wiele różnych komponentów, proces testowania może zacząć przysparzać pewnych trudności, choćby z odwzorowaniem odpowiedniego środowiska uruchomienia testów. I tu przychodzi z pomocą biblioteka Testcontainers. Testcontainers to framework pozwalający testować aplikację w oparciu o kontenery Dockera z prawdziwymi zależnościami systemu. I choć pozornie brzmi to banalnie, narzędzie to oferuje szereg bardzo praktycznych i przydatnych rozwiązań, znacznie upraszczających cały proces testowania integracyjnego. Moim gościem jest dziś Piotr Przybył, Software Gardener z wieloletnim doświadczeniem programistycznym, który o praktycznym wykorzystaniu Testcontainers w projektach wie naprawdę sporo. W tym odcinku rozmawiamy z Piotrem między innymi o: częstych problemach z testowaniem kodu i jego jednostkach, możliwych podejściach do organizacji testów w piramidy, odwrócone piramidy, plastry miodu... zasadzie działania biblioteki Testcontainers i jej kluczowych konceptach, różnicach pomiędzy Testcontainers a innymi sposobami uruchamiania usług podczas testów, synchronizacji kodu testów opartych o Testcontainers z infrastrukturą produkcyjną. Zapraszam! Materiały dodatkowe: Testcontainers Getting Started , dokumentacja omawianej w odcinku biblioteki Katalog modułów , dostępne gotowe kontenery z prekonfigurowanymi usługami Testcontainers Workshop , repozytorium na Githubie z przykładowym kodem krok-po-kroku Integration tests are needed and simple , prezentacja Piotra o testach integracyjnych z użyciem TC z konferencji Devoxx UK 2023 Testcontainers: needed, simple, powerful , dłuższa, niemal 3 godzinna prezentacja z Devoxx z Belgii Wpisy o Testcontainers , blog Piotra o oprogramowaniu, nie tylko o testowaniu

Każdy kod zostanie przetestowany, wcześniej bądź później. Pozostają jedynie pytania na jakim etapie i przez kogo zostanie to wykonane i jaki będzie tego ostateczny koszt. Gdy aplikacja staje się złożona i tworzy ją wiele różnych komponentów, proces testowania może zacząć przysparzać pewnych trudności, choćby z odwzorowaniem odpowiedniego środowiska uruchomienia testów. I tu przychodzi z pomocą biblioteka Testcontainers.

Testcontainers to framework pozwalający testować aplikację w oparciu o kontenery Dockera z prawdziwymi zależnościami systemu. I choć pozornie brzmi to banalnie, narzędzie to oferuje szereg bardzo praktycznych i przydatnych rozwiązań, znacznie upraszczających cały proces testowania integracyjnego.

Moim gościem jest dziś Piotr Przybył, Software Gardener z wieloletnim doświadczeniem programistycznym, który o praktycznym wykorzystaniu Testcontainers w projektach wie naprawdę sporo.

W tym odcinku rozmawiamy z Piotrem między innymi o:

  • częstych problemach z testowaniem kodu i jego jednostkach,
  • możliwych podejściach do organizacji testów w piramidy, odwrócone piramidy, plastry miodu...
  • zasadzie działania biblioteki Testcontainers i jej kluczowych konceptach,
  • różnicach pomiędzy Testcontainers a innymi sposobami uruchamiania usług podczas testów,
  • synchronizacji kodu testów opartych o Testcontainers z infrastrukturą produkcyjną.

Zapraszam!

Materiały dodatkowe:

69. O wydajności systemu, optymalizacjach i trade-offach z Tomaszem Lelkiem
2023-09-12 01:00:00

Czy nieczytelny, trudno nierozszerzalny i na dodatek zduplikowany kod może być dobry? Co więcej, nawet pożądany? Tak, jeśli w projekcie istotne są zupełnie inne drivery, np. w postaci oczekiwanej dużej wydajności systemu. Wówczas poświęcenie pewnych cech kodu na cześć innych wydaje się mieć dużo sensu. Dziś zapraszam na rozmowę z Tomaszem Lelkiem, współautorem wydanej w ubiegłym roku w wydawnictwiem Manning książki "Software Mistakes and Tradeoffs: How to make good programming decisions". A rozmawiać będziemy właśnie o świadomym podejmowaniu decyzji, zwłaszcza w kontekście wydajności i optymalizacji systemu. Nie od dziś przecież wiadomo, że zbyt wczesna optymalizacja jest źródłem całego zła. Niestety wykonana zbyt późno też źródłem wszystkich kosztów... Dzięki uprzejmości wydawnictwa Manning mam 2 kody uprawniające do darmowego pobrania książki Tomka "Software Mistakes and Tradeoffs: How to make good programming decisions" w formie ebooka. Zapraszam więc do podzielenia się historiami o optymalizacjach waszych systemów. Kody te trafią do dwóch osób, których zgłoszenia zostały wybrane przeze mnie jako najciekawsze i najbardziej pouczające dla Ciebie i/lub zespołu. Termin przesyłania zgłoszeń mija z końcem 30 września 2023 roku, nadsyłać je można z użyciem formularza dostępnego na stronie https://forms.gle/o2rVAQHmwZuyP7y66

Czy nieczytelny, trudno nierozszerzalny i na dodatek zduplikowany kod może być dobry? Co więcej, nawet pożądany? Tak, jeśli w projekcie istotne są zupełnie inne drivery, np. w postaci oczekiwanej dużej wydajności systemu. Wówczas poświęcenie pewnych cech kodu na cześć innych wydaje się mieć dużo sensu.

Dziś zapraszam na rozmowę z Tomaszem Lelkiem, współautorem wydanej w ubiegłym roku w wydawnictwiem Manning książki "Software Mistakes and Tradeoffs: How to make good programming decisions". A rozmawiać będziemy właśnie o świadomym podejmowaniu decyzji, zwłaszcza w kontekście wydajności i optymalizacji systemu. Nie od dziś przecież wiadomo, że zbyt wczesna optymalizacja jest źródłem całego zła. Niestety wykonana zbyt późno też źródłem wszystkich kosztów...

Dzięki uprzejmości wydawnictwa Manning mam 2 kody uprawniające do darmowego pobrania książki Tomka "Software Mistakes and Tradeoffs: How to make good programming decisions" w formie ebooka. Zapraszam więc do podzielenia się historiami o optymalizacjach waszych systemów. Kody te trafią do dwóch osób, których zgłoszenia zostały wybrane przeze mnie jako najciekawsze i najbardziej pouczające dla Ciebie i/lub zespołu.

Termin przesyłania zgłoszeń mija z końcem 30 września 2023 roku, nadsyłać je można z użyciem formularza dostępnego na stronie https://forms.gle/o2rVAQHmwZuyP7y66

68. O rozwoju domeny generycznej w modelu open-source z Łukaszem Chruścielem
2023-08-29 01:00:00

Temat tworzenia oprogramowania pod konkretne potrzeby biznesowe, we współpracy z ekspertami domenowymi pojawiał się wielokrotnie w podkaście. Ale jak tworzyć oprogramowanie w modelu open-source, które będzie wykorzystywane przez innych developerów i gdzie pojedynczy ekspert domenowy nie istnieje, bo trzeba dbać o wielu różnych klientów? Jak tworzyć oprogramowanie rozszerzane następnie przez innych developerów, jakie techniki stosować, dlaczego to co w innym projekcie byłoby bad-practice tu może być dobrym rozwiązaniem - m.in. o tym będziemy rozmawiać dziś z Łukaszem Chruścielem. Łukasz od wielu lat pracuje w core-teamie open-source'owego frameworka e-commerce Sylius, a dodatkowo miliony pobrań poszczególnych pakietów tego kodu i wiele dużych wdrożeń w projektach będzie tu ciekawą perspektywą. Zapraszam! Materiały dodatkowe: Sylius Github , repozytorium projektu Profil Łukasza na Twitterze Rozterki i decyzje. Czego się nauczyliśmy projektując API Syliusa , prezentacja Łukasza z konferencji Boiling Frogs 2023, przy okazji której mogliśmy się spotkać i porozmawiać

Temat tworzenia oprogramowania pod konkretne potrzeby biznesowe, we współpracy z ekspertami domenowymi pojawiał się wielokrotnie w podkaście. Ale jak tworzyć oprogramowanie w modelu open-source, które będzie wykorzystywane przez innych developerów i gdzie pojedynczy ekspert domenowy nie istnieje, bo trzeba dbać o wielu różnych klientów?

Jak tworzyć oprogramowanie rozszerzane następnie przez innych developerów, jakie techniki stosować, dlaczego to co w innym projekcie byłoby bad-practice tu może być dobrym rozwiązaniem - m.in. o tym będziemy rozmawiać dziś z Łukaszem Chruścielem. Łukasz od wielu lat pracuje w core-teamie open-source'owego frameworka e-commerce Sylius, a dodatkowo miliony pobrań poszczególnych pakietów tego kodu i wiele dużych wdrożeń w projektach będzie tu ciekawą perspektywą.

Zapraszam!

Materiały dodatkowe:

Informacja dotycząca prawa autorskich: Wszelka prezentowana tu zawartość podkastu jest własnością jego autora

Wyszukiwanie

Kategorie