Cześć!

Dzisiaj zacznę od cytatu z Łony:

“Z dnia na dzień żeby wzrok im przywykł Uczę moje dni zmiany perspektywy Bo wciąż wąsko widzą mimo tylu przynęt A tak trudno zwiększyć im horyzont choćby o centymetr Z dnia na dzień żeby wzrok im przywykł Uczę moje dni zmiany perspektywy I każdemu z nich co tak pilnie oka strzeże Mówię patrz trochę szerzej patrz trochę szerzej”

Żyjemy w czasach zalewu informacji. Jesteśmy atakowani ze wszystkich stron bodźcami. Nasz poziom skupienia jest podobny jak złotej rybki. Pozornie nasze życie jest łatwiejsze niż kiedyś. Podobnie jest w programowaniu. Nasze narzędzia są coraz łatwiejsze, procesy coraz bardziej zautomatyzowane. Wiedza też jest na wyciągnięcie ręki, kursy online, blogi, książki. W zasadzie ciężko jest wybrać czego i skąd się uczyć. Niektóre firmy zatrudniają DevAdvocate aby pokazywały jak najlepiej używać narzędzia i dlaczego warto. Wiedza jest na wyciągnięcie ręki.

Rozwój technologii jednak nie chce się zatrzymać. Coraz więcej, coraz szybciej. Frameworki Javascriptowe robią się tak szybko zeszłotygodniowe.

Dynamiczny rozwój technologii, pozornie dobra jakość materiałów szkoleniowych, oraz co tu dużo mówić lenistwo sprawiają, że nasza wiedza jest coraz bardziej powierzchowna.

Tydzień temu pisałem o TypeScript i o tym jak pozornie jest podobny do C# i Java, a jednak bardzo inny. Z mojego doświadczenia najgorszy kod wg mnie piszą w nim backendowcy. Mają oni tendencje do lekceważenia różnic i robienia kalki ze swoich przyzwyczajeń. Generyk, generyka pogania, klasa bazowa klasę bazową.

W jednym z moich projektów chłopak twierdził, że Postgres nie wyrabia dla jego problemu. Stwierdził, że użyje Redisa, bo jest szybki dostęp w pamięci. Tak się w tym zapędził, że okazało się, że jak nagle się cache cały wyczyści to dane trzeba zmaterializować. Dodatkowo trzeba je też zapisać, bo jak minie TTL to dane znikną. Zaczął więc się dopytywać DevOps czy mogliby mu robić backupy z cache w pamięci Redisa. Nie widział w tym nic zdrożnego. Z ciekawości zerknąłem jak to jest, że jego Postgres nie wyrabia. Okazało się oczywiście, że w bazie (poza kluczami głównymi) nie było ani jednego indeksu.

Jedną z rzeczy, które lubię podrążyć jak prowadzę rekrutację jest problem N+1 oraz sposoby optymalizacji ORM. Nie, żeby to był jakiś wielce interesujący temat, ale wiele można się dowiedzieć o kandydatach i branży. Jak już przedstawiłem powyżej, wiedza z podstaw baz danych jest rzadko spotykana - taki mamy klimat. Każdy używa ORM, ale czy używa je świadomie? Niestety okazuje się, że takie rzeczy jak rozwiązanie problemu N+1 czy też wyłączenie trackowania zmian to też wiedza tajemna.

W piątek brałem udział na Clubhouse w dyskusji na temat Event Sourcing. Sporo tam ciekawych rzeczy usłyszałem. A to, że nie ma problemu, żeby w strumieniu danych trzymać pół miliona rekordów. Przypominam, że w Event Sourcing write model odbudowujemy za każdym razem ze zdarzeń. Na ludzki rozum - w żadnym wzorcu pobieranie pół miliona rekodów nigdy nie będzie miało sensu. W Event Sourcing jest kluczowe, żeby strumienie były jak najkrócej żyjące, a przez to najkrótsze. Pisałem o tym w swoim wpisie “How to (not) do the events versioning?”. A i jeszcze ponownie argument o cache w Redis, znowu Postgres nie wyrabiał.

Do części dokumentowej Martena najczęstszym pytaniem jest “Jak zrobić joiny między dokumentami”.

Przykłady możnaby mnożyć, ale nie w tym sens, żeby narzekać. Kiedyś usłyszałem, że chcąc być chociaż przyzwoitym programistą powinniśmy patrzeć jeden poziom niżej niż ten, w którym na co dzień pracujemy. Czyli jeśli używamy ORMa, to poza zrozumieniem go, zrozummy też podstawy baz relacyjnych. Jeśli robimy frontend, to zrozummy jakie są zasady budowania dobrego WebApi i jak z grubsza działa backend.

Jeśli używamy bazy dokumentowej czy robimy event sourcing to poszukajmy jakie są specyficzne dla nich zasady modelowania. Jeśli używamy nowego języka to spróbujmy zrozumieć jego konwencje.

Zrozummy nasze narzędzie. Przebijmy się przez marketing sprzedawany przez autorów rozwiązania. Nie pracujmy na “tak mi się wydaje”. Nie dajmy się nakręcić hype i temu co mówią znajomi czy też ktoś napisał na blogu.

Nie bądźmy leniwi, nie bądźmy powierzchowni. Nie musimy wiedzieć wszystkiego, ale zejdźmy chociaż jeden poziom niżej.

Patrzmy trochę szerzej.

Pozdrawiam Oskar

P.S. Właśnie trochę szerzej spojrzałem na CQRS - jest mnóstwo mitów i legend, które warto było odkłamać - zobacz tutaj: https://event-driven.io/en/cqrs_facts_and_myths_explained/. Z posta zrobił się Viral na Twitter, więc chyba warto przeczytać.

Polecam też w temacie podstaw wpis Łukasza Kałużnego “This is the basic stuff”

P.S.2 Napisałem też nowy wpis na blogu EventStore o wersji V1 klienta gRPC Javy. Cieszę się, bo sporo pracy włożyłem też programistycznej w ujednolicenie API z klientami w innych językach: https://www.eventstore.com/blog/getting-started-with-v1-java-grpc-client

A oprócz tego jak co tydzień nowe Architecture Weekly: https://github.com/oskardudycz/ArchitectureWeekly#8th-march-2021