Jesteśmy społecznością, która kocha książki

In this book author describes the process of creating ambitious software application Chandler. This application was supposed to help people manage their emails, todo lists, calendars, meetings, etc. Chandler team wanted to develop best software which functionalities excel any existing PIM (Personal Information Manager). It would be open source and free (source code will be available for anyone, so users could make own changes in Chandler code too). Author accompanied software company for 3 years and finally published this book, when they still did not had first stable version of their product and there was still a lot of things to finish before there will have initial stable version. They finally released the software in 2008, after publication of this book and quickly abandoned it.

The story of Chandler development shows how not to design and create software. Chandler team got enormous resources and time to develop their dream software. They planned to create very big application from the start instead of creating MVP (Minimum viable product). They spend a lot of time on design and meetings before any coding work was done. They where ultra optimistic in terms of estimates for work to be done. They made many bad decisions, created own solutions for things which they could take of shelf, they spent a lot of time not working on Chandler, but on tools and placeholders for future features.

Most of the book content does not describe strictly Chandler development issues and progress. It looks that 2/3 of the book is about general issues which are common when developing software. There is some content about software development history and description of different concepts for the future of software development. A lot of space is used to describe the issues which programmers and managers face during such projects. The main point of this book is that making software is hard and often fails to meet expectations and software is rarely delivered on time and on budget. There are multiple reasons for it, both technical and human.

Many years has passed and many of the issues described here are still relevant. But there was small progress made in the following decade (author cites report from 2004). More software teams now use iterative approach to develop initial version of the software quickly and later improve it using user feedback, which gives better results than “waterfall” approach with no or very long iterations. Chaos report measures rate of success in IT projects and shows, that the rate of success slightly improved, but there are still a lot of challenged and failed projects. And I suspect that due to nature of software development and increased demand for software and human weaknesses, it will take long time to improve these statistics further (if it is still possible). As commonly mentioned in this book, Brook once wrote that there is no silver bullet for these issues. Data shows that despite measurable improvements when using Agile methodology, there are still a lot of failed and challenged projects which are Agile. Many things in software development are not easily to compare or measure, so a lot of different advocates (and sometimes cultist) still argue what is the best methodology/tool/framework etc. to do the job and I suspect that there will be probably no end to these arguments.

I work in software industry for many years and read The Mythical Man-Month before. If you read this book before and you know some stuff about software development history and software development issues, I suspect that you do not find a lot of interesting things here. This book also describes a lot of terms and processes during software developments. This was probably written in such way to make whole book more understandable for non programmers. I personally was a little bored when reading some parts of this book, probably because I was familiar with many of the concepts described here.

In this book author describes the process of creating ambitious software application Chandler. This application was supposed to help people manage their emails, todo lists, calendars, meetings, etc. Chandler team wanted to develop best software which functionalities excel any existing PIM (Personal Information Manager). It would be open source and free (source code will be...

Książka miała na celu opisanie różnych zagadnień związanych z projektowaniem i tworzeniem platform integracyjnych. Książka składa się z dwunastu rozdziałów poświęconych różnym zagadnieniom związanych z integracją wielu aplikacji w przedsiębiorstwach oraz instytucjach publicznych.

Według mnie z tą pozycją jest kilka poważnych problemów. Głównym z nich jest brak ukierunkowania treści tej książki do konkretnej grupy odbiorców. Bo co tutaj znajdziemy? Przykłady kodu do integrowania aplikacji z wykorzystaniem jakiegoś niszowego rozwiązania od Microsoftu, opisy sieci semantycznych, opisy strategii wdrażania oraz projektowania platform integracyjnych, opisy znaczeń elementów graficznych na diagramach dla różnych rodzajów opisy architektury, opis dostosowywania organizacji oraz kontrolowania projektów integracyjnych dla managementu, opisy narzędzi dla analityków, itd. Wygląda to jak luźno powiązany zbiór artykułów, które w jakiś sposób dotykają tematyki tytułowej. Dodatkowo rozdziały są pisane przez różne osoby (Tomasz Górski ze strony tytułowej odpowiada tylko za połowę książki) i przez to też opisują wybrane zagadnienia na różnym poziomie szczegółowości. Np. popularny BPMN jest opisany bardzo pobieżnie i gdybym nie miał z nim styczności wcześniej to pewnie nie wiele bym z jego opisu zrozumiał. Za to mamy przykłady kodu dla definiowania procesów ETL w SQL Server oraz SQL Azure. Podejrzewam, że te przykłady pojawiły się to tutaj tylko dlatego, że osoba pisząca rozdział jest konsultantem Microsoftu i opisała to z czym ma do czynienia w swojej pracy. Już lepiej byłoby podejść do tematyki ETL bardziej ogólnie lub też porównać ze sobą kilka rozwiązań od różnych dostawców. Wiele treści z tej książki nie jest dla deweloperów, wiele z tej treści nie jest też dla analityków, managerów, architektów itd. Brak jest tutaj konkretnej grupy odbiorców.

Drugim poważnym problem jest przestarzałość tej książki. Książka została wydana w 2012 roku co w świecie IT jest odległą przeszłością, szczególnie, gdy książka stara się opisywać w szczegółowy sposób aspekty techniczne. Ale zdaje mi się, że ta pozycja była już przestarzała nawet na rok 2012. Niektóre z opisanych narzędzi miały podane w wymaganiach np. Windows XP, chociaż Windows Vista był wydany w 2007 roku a Windows 7 w 2009 roku. Była wymieniana też Java 5 (wydana w 2004), kiedy w czasie publikacji tej książki była już dostępna Java 7 (2011). W 2001 roku opublikowano także manifest zwinny, który obecnie jest standardowym modelem pracy zespołowej w IT. Natomiast autorzy nie wspominają nigdzie o zwinnym podejściu do platform integracyjnych i opisują jedynie o podejście kaskadowe.

Nie polecam tej książki.

Książka miała na celu opisanie różnych zagadnień związanych z projektowaniem i tworzeniem platform integracyjnych. Książka składa się z dwunastu rozdziałów poświęconych różnym zagadnieniom związanych z integracją wielu aplikacji w przedsiębiorstwach oraz instytucjach publicznych.

Według mnie z tą pozycją jest kilka poważnych problemów. Głównym z nich jest brak...

Innowatorzy Waltera Isaacsona opowiadają o rozwoju branży informatycznej, od maszyn różnicowych Charlesa Babbage i uwag Ady Lovelace do rozprzestrzenienia się internetu na skalę globalną.

Książka jest podzielona na tematyczne rozdziały, z których każdy omawia dość kompleksowo dane zagadnienie, jak np. komputer, programowanie, komputery osobiste, internet, www itp. W każdym rozdziale znajdziemy sylwetki ludzi i organizacji, które były zaangażowane w dane zagadnienia.

W początkowych okresach na powstanie i rozwój branży IT duży wpływ miały projekty dla wojska realizowane w ramach trójkąta współpracy wojska – uczelni – prywatnego przemysłu. Z czasem coraz większą rolę zaczęły odgrywać prywatne przedsiębiorstwa oraz grupy entuzjastów nowych technologii, z których to powstały ruchy wolnego oprogramowania i Open Source. Wielu innowatorów było geniuszami i przejawiali niezwykłe zdolności już najmłodszych latach, ale nie osiągnęli by wiele bez współpracy między sobą oraz bez wspierających ich zespołów. Zmiany w IT były olbrzymie, ale zachodziły one ewolucyjnie, ponieważ każdy kolejny innowator dodawał coś nowego do olbrzymiego gmachu wiedzy zbudowanej przez poprzedników.

Książkę polecam każdemu zainteresowanemu historią rozwoju technologi oraz branżą IT. Niektóre fragmenty trudno się czyta ze względu na olbrzymią ilość osób przewijających się w opisach tej książki.

Innowatorzy Waltera Isaacsona opowiadają o rozwoju branży informatycznej, od maszyn różnicowych Charlesa Babbage i uwag Ady Lovelace do rozprzestrzenienia się internetu na skalę globalną.

Książka jest podzielona na tematyczne rozdziały, z których każdy omawia dość kompleksowo dane zagadnienie, jak np. komputer, programowanie, komputery osobiste, internet, www itp. W każdym...

Jest to moja pierwsza książka/kurs na temat Domain Driven Design (DDD). Czytałem wersję angielską. Autor postawił sobie jako cel skrócone przedstawienie DDD, aby można było zacząć pracować z tą techniką w swoim projekcie od zaraz.

Autor omawia różne pojęcia DDD w krótkich rozdziałach. Posługuje się przykładem implementowania aplikacji do zarządzania projektem Scrum oraz przykładem polis w firmie ubezpieczeniowej. Przechodzi przez Bounded Context, Unbiqious Language, Subdomeny, sposoby integracji między Bounded Context, projektowanie agregatów oraz udziela kilku uwag odnośnie pracy z DDD w projekcie. Autor też mocno promuje architekturę opartą na zdarzeniach (Event Sourcing).

Pisząc delikatnie, książka nie zrobiła na mnie dobrego wrażenia zarówno na temat DDD jak i samego autora. Pierwszym poważnym problemem jest niejasność i wysoka abstrakcja wielu stosowanych terminów. Np. Co to jest Bounded Context według autora:
First, a Bounded Context is a semantic contextual boundary. This means that within the boundary each component of the software model has a specific meaning and does specific things. The components inside a Bounded Context are context specific and semantically motivated. That’s simple enough.

Czyli Bounded Context to jakiś kontekst z granicami, który zawiera w sobie jakieś rzeczy. Nie mówi to dla mnie zbyt wiele. Podobnie jest z wieloma innymi terminami powiązanymi z DDD. Ja rozumiem, że książka miała to przedstawić w skondensowany sposób, ale to poszło o wiele za daleko. Tym bardziej, że drugim poważnym problemem jest masa szumu wokół treści DDD. Zazwyczaj autor zaczyna od DDD, a później potrafi dodawać uwagi/rozpisywać się o takich rzeczach jak SOAP/REST, Event Sourcing, estymowanie zadań, pisanie testów jednostkowych itd. Wiele z tego szumu nie jest tutaj potrzebne oraz według mnie jest przedstawiane w niezbyt przemyślany sposób. Innymi ciekawymi kwiatkami były na przykład takie akapity:
RESTful HTTP will tend to fail for many of the same reasons that RPC does—network and service provider failures, or unanticipated latency. However, RESTful HTTP is based on the premise of the Internet, and who can find fault with the track record of the Web when it comes to reliability, scalability, and overall success?
Albo nie rozumiem tego akapitu, albo autor sugeruje, że nie ma co się zbytnio przejmować problemami infrastrukturalnymi w przypadku korzystania z REST, bo internet jest niezawodny a jak korzystamy z REST to przecież działami przez Internet. A co z serwerami, na których hostowane są nasze aplikacje oraz łączami między serwerami?

Często są też fragmenty typu rób X, a nie rób Y bez żadnego podania powodu dlaczego podejście X jest lepsze od Y. Po prostu rób tak bo autor tak pisze. Innym przykładem dużych niejasności jest jego opis modelowania agregatów. Autor w tej książce nie zaleca stosowania „anemicznego modelu danych”, w którym to encje reprezentują dane, a serwisy operują na danych tych encji. Ale opisał to w ten sposób, że czytelnik ma wrażenie, że autor zaleca umieszczenie wszelkich operacji w encjach z danymi (co np. z zapisem do bazy, wysyłaniem wiadomości do innych usług itp.?). Jak to zobaczyłem to aż spojrzałem do jego drugiej, dłuższej książki i tam jest to zrobione w tradycyjnej formie (serwis, repozytoria). Autorowi chodziło jedynie o to, aby zamiast stosować settery, użyć np. metod biznesowych jak np. sprint.schedule(…) które ustawiają odpowiednie dane wewnątrz kodu encji.

Z pozytywnych rzeczy podobał mi się opis Event Storming do grupowego projektowania funkcjonalności oraz dzielenia się wiedzą za pomocą samoprzylepnych karteczek (ale opisy np. jakiego koloru użyć do jakiego typu karteczki są trochę przesadzone). Podobało mi się też stwierdzenie, że aby odnieść sukces z DDD, trzeba mieć dobrych deweloperów :).

Podsumowując, książka zraziła mnie do DDD i raczej nie sięgnę po inne prace na ten temat przez najbliższy czas. Według mnie najważniejszym przesłaniem tej książki (które przynajmniej dla mnie było i jest bliskie sercu) jest potrzeba bliskiej współpracy deweloperów z ludźmi znającymi wymagania biznesowe oraz pisanie kodu w ten sposób, aby te wymagania były odzwierciedlone w kodzie aplikacji (łącze z sensownymi nazwami operacji i danych). Książki nie polecam.

Jest to moja pierwsza książka/kurs na temat Domain Driven Design (DDD). Czytałem wersję angielską. Autor postawił sobie jako cel skrócone przedstawienie DDD, aby można było zacząć pracować z tą techniką w swoim projekcie od zaraz.

Autor omawia różne pojęcia DDD w krótkich rozdziałach. Posługuje się przykładem implementowania aplikacji do zarządzania projektem Scrum oraz...

Opinia na temat wydania III. Książka Blocha zawiera wiele ciekawych informacji i porad dotyczących programowania w Java(dla trochę bardziej zaawansowanych). Opisane są w niej często spotykane problemy oraz rozwiązania dla nich. Łącznie 90 tematów. Trochę miejsca jest poświęcone dobrym praktykom programowania. Cześć z nich dotyczy głównie twórców bibliotek, którzy udostępniają swoje klasy użytkownikom a część z nich powinna być stosowana przez wszystkich programistów. Porady ze wskazanej pozycji pozwalają na unikanie części problemów w programowaniu w Java oraz pozwalają na tworzenie kodu, który jest łatwiejszy w utrzymaniu.

Książka była czytana w wersji polskiej. Jeśli chodzi o tłumaczenie Helionu, to jest to standardowy czyli kiepski poziom. Wiele użytych zwrotów jest niezrozumiałych lub poprzekręcanych. Tłumacz starał się przetłumaczyć na polski wszystko i to chyba bez żadnych konsultacji technicznych z programistami. Jeśli komuś nie przeszkadza czytanie w języku angielskim, to odradzam polską wersję. Książka zawiera wiele ciekawych i pożytecznych porad. Polecam wszystkim programistom Java.

Opinia na temat wydania III. Książka Blocha zawiera wiele ciekawych informacji i porad dotyczących programowania w Java(dla trochę bardziej zaawansowanych). Opisane są w niej często spotykane problemy oraz rozwiązania dla nich. Łącznie 90 tematów. Trochę miejsca jest poświęcone dobrym praktykom programowania. Cześć z nich dotyczy głównie twórców bibliotek, którzy...

Legendarny osobomiesiąc jest drugim wydaniem książki Mitologiczny osobomiesiąc. Jest to jedna z najsłynniejszych prac poświęconych inżynierii oprogramowania.

Tematem przewodnim tej książki jest opis problemów związanych z produkcją oprogramowania. Obok opisu tych problemów znajdziemy tutaj także pewnie propozycje rozwiązań/łagodzenia tych problemów.
Według autora głównymi problemami tworzenia oprogramowania jest olbrzymia złożoność wynikająca z samej natury tego procesu, która się zwiększa w miarę rozwoju projektu. Dodam od siebie, że kiedyś John Carmack stwierdził, że tworzenie współczesnych gier jest bardziej skomplikowane niż loty kosmiczne. Do tego dochodzą problemy organizacyjne oraz związane z komunikacją. Programiści w małych zespołach są wstanie pracować znacznie efektywniej niż programiści w dużych projektach (znacznie mniejszy narzut na komunikację), ale jednocześnie małe zespoły nie są wstanie stworzyć wielkich systemów ze względu na ograniczenia czasowe. W ramach rozwoju systemu bardzo ważne jest zachowanie spójności koncepcyjnej projektu, ponieważ pozwala to ograniczać przyrost złożoności w projekcie. Spójności projektu powinien pilnować architekt/architekci. Ważne są także nieustanne testy, ale dla większości to jest raczej oczywiste.

Z ciekawych myśli autora mogę dodać, że dodawanie nowych pracowników do projektu może wydłużyć czas jego realizacji. Wynika to z tego, że tacy pracownicy muszą być wdrożeni w projekt przez innych. Nowi pracownicy też będą potrzebowali trochę czasu na rozkręcenie się w projekcie, więc na początku będą pracować mniej wydajnie. W takiej sytuacji zwiększa się także nakłady na komunikację w projekcie. Z tych powodów, gdy dodajemy nowych pracowników do opóźnionego projektu, bardzo często jedynie zwiększamy opóźnienie oraz koszty realizacji projektu. Dlatego należy być ostrożnym.

Innym ciekawym spostrzeżeniem jest to, że małe opóźnienia nie powinny być ignorowane. Takie opóźnienia będą pojawiać się często i ignorowane mogą stworzyć duże opóźnienie i katastrofę dla całego projektu.

Główną wadą tego dzieła jest jego aktualność. Oryginał został napisany w latach 70 a drugie wydanie w 90. Drugie wydanie różni się od pierwszego dodaniem kilku dodatkowych rozdziałów. Z tego powodu wiele opisanych problemów jest albo nieaktualnych albo zawiera przestarzałe propozycje rozwiązań. Przykładami takich tematów mogą być choćby opisy, jak zarządzać dostępem do komputera (dawno temu jeden komputer przypadał na rzesze programistów), jak zarządzać wymaganiami, aby aplikacja zmieściła się w kilkuset KB pamięci, jak zarządzać wielotomowymi papierowymi podręcznikami użytkownika i dokumentacją, która musi być regularnie aktualizowana itp. Przez to wiele rozdziałów nie ma obecnie żadnej wartości poza historyczną (aby dowiedzieć się z jakimi problemami spotykali się programiści w latach 70).
Inną wadą tej pozycji jest to, że niektóre z opisanych problemów dotyczą tworzenia systemów operacyjnych. W obecnych czasach prawie nikt nie tworzy nowych systemów operacyjnych.

Drugie polskie wydanie czytało się przyjemnie. Książka jest też opracowana w ładny sposób. Niestety zdarzają się literówki. Książkę mogę polecieć wszystkim, którzy są związani z produkcją oprogramowania. W tej pozycji znajduje się wiele ciekawych myśli, których nie wypisałem w recenzji. Ale należy pamiętać o tym, że duża część tej książki jest nieaktualna i ma jedynie wartość historyczną.

Legendarny osobomiesiąc jest drugim wydaniem książki Mitologiczny osobomiesiąc. Jest to jedna z najsłynniejszych prac poświęconych inżynierii oprogramowania.

Tematem przewodnim tej książki jest opis problemów związanych z produkcją oprogramowania. Obok opisu tych problemów znajdziemy tutaj także pewnie propozycje rozwiązań/łagodzenia tych problemów.
Według autora głównymi...

Książka pełni raczej rolę leksykonu kieszonkowego dotyczącego bazy PostgreSQL. Jako leksykon sprawdza się dobrze (są tutaj opisane operatory, typy danych, słowa kluczowe, najważniejsze funkcje, tablice systemowe itd).

Według mnie cały rozdział dotyczący interfejsów dostępowych do bazy danych jest zbędny. Pokazane jest tam kilka przestarzałych technologii z setek możliwych obecnie bibliotek i języków programowania.

Książkę mogę polecić, ale z uwzględnieniem, że nadaje się ona głównie jako leksykon kieszonkowy zamiast wprowadzenia do PostgreSQL. Warto mieć jakąś wiedzę na temat SQL i innej bazy danych przed przeczytaniem tej książki.

Książka pełni raczej rolę leksykonu kieszonkowego dotyczącego bazy PostgreSQL. Jako leksykon sprawdza się dobrze (są tutaj opisane operatory, typy danych, słowa kluczowe, najważniejsze funkcje, tablice systemowe itd).

Według mnie cały rozdział dotyczący interfejsów dostępowych do bazy danych jest zbędny. Pokazane jest tam kilka przestarzałych technologii z setek możliwych...

Książka Blocha zawiera wiele ciekawych informacji i porad dotyczących programowania w Java(dla trochę bardziej zaawansowanych). Opisane są w niej często spotykane problemy oraz rozwiązania dla nich. Trochę czasu jest także poświęcone dobrym praktykom programowania.

Książki jednak nie polecam, ponieważ wydana została 10 lat temu pod wersję JDK 6. Przez to pewne problemy lub rozwiązania wydają się mocno przestarzałe.

Ale sam sięgnę po III wydanie tej książki, które zostało odświeżone pod JDK 9(wydana rok temu po angielsku), niedługo wydana będzie po polsku. Biorąc pod uwagę wysoki poziom tej książki, dla zainteresowanych polecam sięgnąć od razu po III wydanie.

Książka Blocha zawiera wiele ciekawych informacji i porad dotyczących programowania w Java(dla trochę bardziej zaawansowanych). Opisane są w niej często spotykane problemy oraz rozwiązania dla nich. Trochę czasu jest także poświęcone dobrym praktykom programowania.

Książki jednak nie polecam, ponieważ wydana została 10 lat temu pod wersję JDK 6. Przez to pewne problemy lub...

W tej książce autor opisuje krok po kroku, jak stworzyć własny system mikrousług w Java.

Autor przechodzi w niej przez opis koncepcji mikrousług, konfiguracji Spring Boot, projektowaniu z wykorzystaniem DDD, implementacji usług REST, konfiguracji Dockera, OAuth2 oraz dodatkowych serwerów związanych z systemem mikrousług(równoważnik obciążenia, wyłącznik, serwer monitorujący i przesyłający komunikaty). Pod koniec książki pisze także o dobrych praktykach tworzenia mikrousług. Twórca książki poświęcił także rozdział tworzeniu aplikacji w technologii Angular.

W mojej ocenie książka służy bardziej jako prezentacja technologii stworzonych przez Netflixa niż jako poradnik dotyczący tworzenia systemu mikrousług. W wielu miejscach autor nie wyjaśnia dlaczego coś jest robione w podany sposób tylko idzie dalej. Książka nie zawiera prawie żadnej teorii. Jeśli chodzi o praktykę, to bez podstawowej znajomości Spring Boot czytelnik raczej sobie nie poradzi. Natomiast osoby bardziej doświadczone nie znajdą w tej książce wiele ciekawych rzeczy, ponieważ jest to tylko prezentacja technologii Netflixa.

W tej książce autor opisuje krok po kroku, jak stworzyć własny system mikrousług w Java.

Autor przechodzi w niej przez opis koncepcji mikrousług, konfiguracji Spring Boot, projektowaniu z wykorzystaniem DDD, implementacji usług REST, konfiguracji Dockera, OAuth2 oraz dodatkowych serwerów związanych z systemem mikrousług(równoważnik obciążenia, wyłącznik, serwer...

Książka poświęcona jest budowie systemów mikrousługowych. Autorka nie skupia się na żadnej konkretnej technologii - zamiast tego omawia zagadnienia w sposób bardzo ogólny i mało techniczny.

Na początku książki autorka opisuje ogólnie czym są mikrousługi. Następnie w kolejnych rozdziałach opisuje co według niej świadczy o tym, że usługa jest gotowa do niezawodnego działania i w jaki sposób można to zapewnić. Przechodzi przez takie zagadnienia jak stabilność, niezawodność, skalowalność, odporność na awarie, monitorowanie oraz dokumentowanie.

Nie czytało mi się tej pozycji zbyt przyjemnie ze względu na dużą ilość powtórzeń. Polskie tłumaczenie zawiera też trochę dziwnych wyrażeń(jak fronton(front end)). Dziwi mnie też to, że tłumacz nie był pewien płci autorki, ponieważ część tekstu brzmi jakby wypowiadała się kobieta, a w część jak mężczyzna(np. zaczęłam a zaraz później stworzyłem).

Gdzieniegdzie w tekście są też dziwne i czasami niespójne sformułowania, z którymi jako programista nie mogę się zgodzić. Np. twierdzenia o tym, że mikrousługa może być wdrożona dopiero wtedy, kiedy nie zawiera żadnych błędów. Każdy kto ma przynajmniej podstawową wiedzę o oprogramowaniu wie, że nie jest to możliwe ze względu na złożoność aplikacji. Przetestowanie aplikacji pod każdym względem w każdych warunkach, jakie mogą tylko wystąpić jest zbyt kosztowne. Nawet po najlepszych testach nie wie się, gdzie są jeszcze jakieś błędy(bo na pewno jakieś są). Co nie szkodzi autorce później pisać o tym, że w mikrousługi cały czas się zmieniają i przez to normalnym jest, że jest w nich pełno błędów(co mocno przeczy stawianym przez nią wymaganiom przy wdrażaniu nowych wersji). Według mnie jest to niefortunne sformułowanie, bo gdyby napisała o tym, że nie powinno się wdrażać usługi gdy wiemy że zawiera poważne błędy, to nie miałbym z takim stwierdzeniem problemu. Niestety w książce jest wiele tego typu kategorycznych sformułowań, które według mnie nie były dobrze przemyślane, co kuło mnie co jakiś czas w oczy.

Wydaje mi się, że książka została napisana jako krótki przewodnik dla kadr zarządzających, które miałyby tworzyć własny system mikrousług i chciałyby wdrożyć odpowiednie procedury oraz przebudować w tym celu swoją organizację. Książka może zaciekawić też osoby, które chciałby poznać większy obraz pracy nad tego typu systemem.

Książka poświęcona jest budowie systemów mikrousługowych. Autorka nie skupia się na żadnej konkretnej technologii - zamiast tego omawia zagadnienia w sposób bardzo ogólny i mało techniczny.

Na początku książki autorka opisuje ogólnie czym są mikrousługi. Następnie w kolejnych rozdziałach opisuje co według niej świadczy o tym, że usługa jest gotowa do niezawodnego działania...