2020 - Co było...Co jest...Co będzie...
Nowy Rok. Nowa energia do działania. Nowe plany. Nie wiem jak u Ciebie, ale u mnie styczeń to czas, kiedy znikają wszystkie wątpliwości oraz ograniczenia. To czas, kiedy ponownie wszystko staje się możliwe. To czas dawania sobie kolejnych szans na realizację tego, czego nie udało się zrealizować w latach poprzednich. To czas postanowień - otwarcia na rzeczy nowe.
Rok 2020 jest dobrym momentem na podsumowanie dłuższego okresu, np. ostatnich 5, 10, 15 lat, a także czasem rozważań na temat tego, co chciałoby się osiągnąć w kolejnych latach. W tym artykule podzielę się z Tobą moją technologiczną drogą, którą przebyłem, dochodząc do miejsca, w którym jestem teraz. Podzielę się również moimi planami na najbliższą oraz dalszą przyszłość.
Co było…
“Jeden obraz wart więcej niż tysiąc słów” (chińskie przysłowie):
Moja technologiczna droga podzielona jest na trzy okresy.
Pierwszym okresem była nauka języków programowania i ogólnie, czym jest informatyka. W tamtym czasie ważyły się losy tego, czy zostanę programistą. Mimo że nie zawsze było łatwo i przyjemnie, udało mi się wytrwać. W pewnym momencie coś zaskoczyło i zacząłem rozumieć, na czym to wszystko polega.
Drugi okres to czas używania zdobytej wiedzy w praktyce poprzez realizowanie różnego rodzaju funkcjonalności w systemach biznesowych. Jakież było moje zdziwienie, rozczarowanie, rozgoryczenie, kiedy zobaczyłem, jak niewiele jeszcze potrafię, że sama znajomość języków programowania to za mało, aby wytwarzać oprogramowanie. Będąc bardziej świadomym, wiedziałem, ile pracy (ponownie) będę musiał włożyć, aby osiągnąć poziom dostarczania akceptowalnej jakości rozwiązań w sensownym czasie. Po raz drugi determinacja pomogła mi przetrwać momenty zwątpienia. Był to czas poznawania i używania różnych technik programistycznych oraz projektowych takich, jak układanie kodu w warstwy, testowanie jednostkowe, wdrażanie zrealizowanych funkcjonalności, ich monitoring, utrzymanie oraz rozwój tego, co już działa. Wszystkie te elementy ogólnie można nazwać inżynierią oprogramowania. Z dzisiejszego punktu widzenia nazywam ten okresem czasem RPC - stylu architektonicznego Remote Procedure Call.
Po osiągnięciu akceptowalnego poziomu potwierdzonego udziałem w udanych projektach, co ostatecznie umocniło mnie w przekonaniu, że programowanie oraz projektowanie systemów IT to jest to, co mogę, a także lubię robić, wszedłem w swój trzeci okres rozwoju technologicznego. O ile pierwsze dwa okresy można nazwać planowanymi, o tyle trzeci jest wynikiem szczęścia. Może nie takiego klasycznego szczęścia, że nie robiąc nic, przytrafiło mi się coś fajnego, ale szczęścia natrafienia na odpowiednie materiały, poszukując odpowiedzi na pytanie, w jaki sposób można podnieść jakość wytwarzanego oprogramowania. Wtedy to natrafiłem na materiały autorstwa Udi Dahan. Po przeczytaniu artykułu Clarified CQRS oraz oglądnięciu webcastu Reliability Availability Scalability (lub odwrotnie), wsiąknąłem w blog, a potem w kolejne i kolejne materiały. Intuicja podpowiadała mi, że jest to słuszna droga rozwoju. Dopełnieniem było użycie zdobytej wiedzy w praktyce. Nie był to relaksujący spacer po parku. Czasami trzeba było podejmować trudne i ryzykujące decyzje. Doświadczyłem tego, na czym polega wprowadzanie nowych technologii na poziomie architektury. Zobaczyłem, że to zupełnie coś innego niż np. decyzja o użyciu jednej biblioteki dostępu do bazy danych zamiast innej. Ostatecznie nowe podejście sprawdziło się, czego potwierdzeniem był udział w udanych projektach. Okres ten nazywam czasem MQ - stylu architektonicznego Message Queueing.
Co jest…
“Jeden obraz wart więcej niż tysiąc słów” (chińskie przysłowie):
W ostatnich pięciu latach moją główną aktywnością był udział w realizacji produktów integrujących ze sobą różne systemy. Do tego typu funkcjonalności idealnie nadaje się styl architektoniczny MQ. Jednak sama znajomość podejścia to za mało, aby móc coś stworzyć. Trzeba mieć do tego odpowiednie narzędzia. Tutaj ponownie wspomnę postać Udi Dahan, ponieważ jest on twórcą frameworka NServiceBus, który obecnie jest częścią większej platformy zwanej Particular Service Platform. Konstrukcja platformy jest zgodna z ideą pozwalającą na zastosowanie MQ w odpowiedni, skuteczny sposób. Jakby ktoś mnie zapytał, jaką dziedziną IT się zajmuję, to odpowiedziałbym, że integracją systemów z wykorzystaniem platformy Particular.
Jeśli popatrzysz na pierwszy screen z tego artykułu, to zauważysz, że wraz z nabieraniem doświadczenia byłem w stanie przyswoić większą ilość wiedzy w tym samym okresie czasowym. W ostatnich trzech latach bardzo pomocnym narzędziem motywacyjnym do zapoznawania się z nowymi materiałami był niniejszy blog, na którym z roku na rok pojawiało się co raz więcej wpisów. Jeśli śledzisz mnie od początku lub od któregoś momentu to, po pierwsze bardzo Ci dziękuję za Twój poświęcony czas, a po drugie zaważysz, że piszę właśnie o tematach dookoła podejścia MQ, frameworka NServiceBus oraz platformy Particular. Jeśli jest to twój pierwszy artykuł, to również bardzo Ci dziękuję, że poświęcasz czas na jego czytanie i zachęcam, do zapoznania się z tym, co już powstało. Ja sam wracam do poprzednich wpisów z ciekawością :) Dzielenie się, wiedzą jest czymś, co bardzo pomaga w rozwoju.
Co będzie…
“Jeden obraz wart więcej niż tysiąc słów” (chińskie przysłowie):
Na dzień, w którym publikuję ten artykuł, nie umiemy przewidywać przyszłości. Możemy jednak zaplanować, co byśmy chcieli osiągnąć przez najbliższe 5, 10, 15 lat i próbować robić wszystko, co się da, aby te plany zrealizować. W moich planach rozwoju technologicznego jest zrobienie kroku do przodu, jeśli chodzi o projektowanie i realizację systemów rozproszonych. Obecnie wiem, na czym polega integracja systemów. Zdarza się, że sama integracja jest tylko jednym z wielu elementów składających się na całość rozwiązania. Pojawiają się wymagania odnośnie stworzenia interfejsów użytkownika lub całych systemów wspomagających zainteresowane osoby w podejmowaniu decyzji, które mają wpływ na integrowane dane. Dane te mogą pochodzić z różnych źródeł. Sposób wyświetlania, wprowadzania, modyfikacji danych, a także poziom uprawnień do przeprowadzania tego typu operacji może być różny. Mój długofalowy cel to nauczenie się realizować systemy posiadające Frontend, Backend oraz integrację z systemami zewnętrznymi.
Design
Centralnym punktem wokół, którego będę budował wiedzę, są idee zawarte w kursie Advanced Distributed System Design (ADSD), którego autorem jest twórca frameworka NServiceBus. Dzięki temu będę mógł wykorzystać to, czego nauczyłem się do tej pory, przynajmniej jeśli chodzi o Backend oraz integrację systemów.
A co z Frontendem? Tutaj mam całą lekcję do odrobienia. Z programowaniem webowym miałem te same doświadczenia co z programowaniem funkcyjnym. Próbowałem, ale nie zaskakiwało. Szukałem dalej, próbowałem ponownie, ale nic z tego nie wychodziło. Jest to dobry długofalowy cel, aby coś z tym zrobić. Tym razem zawężę poszukiwania sposobów realizacji tak, aby pasowały do podejścia ADSD.
Jeśli chodzi o bliższe plany, to celem jest biegłe posługiwanie się rożnymi stylami architektonicznymi:
- SOA - Service Oriented Architecture
- CQRS - Command Query Responsibility Segregation
- Domain Model
- MQ - Message Queueing
- RPC - Remote Procedure Call
Niektóre znam dość dobrze, niektóre trochę mniej. Funkcjonalności oparte na każdym z tych stylów można zrealizować na różne sposoby. Poszerzenie wiedzy na temat stosowania danego stylu w konkretnym kontekście oraz ich łączenia ze sobą pozwoli mi dokonywać trafniejszych wyborów, co przełoży się na wytworzony końcowy rezultat.
Develop
Plan długofalowy to wyrównanie umiejętności programowania w języku F# do takiego samego poziomu, na jakim teraz jestem, używając języka C#.
Plany bliższe to wykorzystanie konstrukcji językowych do realizacji powyższych stylów architektonicznych oraz ciągły rozwój tego, co już znam: C#, NServiceBus, ServiceInsight, … Zapewne dojdą elementy programowania webowego, natomiast aktualnie nie wiem, co to będzie. Dopełnieniem będzie lepsza znajomość systemu kontroli wersji Git oraz platformy GitHub.
Test
Na radarze mam trzy długofalowe tematy:
- Property-Based Testing
- Automatyczne testy integracyjne
- Automatyczne testy wydajnościowe
Property-Based Testing jest ideą testowania, na którą natrafiłem, zapoznając się z językiem F#. Temat mnie zaciekawił. Będzie okazja, aby zobaczyć, o co w tym chodzi. Testowanie integracyjne przeprowadzam ręcznie. Mając dobrze podzielony kod na Message Handlery, jestem w stanie przetestować konkretny kawałek, który ma dobrze zdefiniowany Message wejściowy oraz jasno określony Message wyjściowy. Logikę biznesową testuję za pomocą automatycznych testów jednostkowych. Taką samą taktykę stosuję w przypadku testów wydajnościowych, gdzie wynikiem jest szybkość przetworzenia większej ilości wiadomości. Fajnie byłoby umieć automatyzować cały proces.
Deploy
Na celowniku mam trzy tematy:
- Microsoft Azure
- Zastąpienie PowerShella
- ServiceControl, ServicePulse, ServiceInsight
Pierwszy z elementów to temat rzeka, czyli chmura. Wypadałoby umieć zgrabnie się po niej poruszać. Wybór Microsoft Azure jest naturalnym wyborem z racji tego, że na co dzień programuję na platformie .NET. Na pierwszy ogień pójdzie Azure Service Bus lub Azure Storage Queue oraz ich współpraca z frameworkiem NServiceBus.
PowerShell jest ciekawym i potężnym narzędziem, ale przechadzając się ścieżkami programowania funkcyjnego, natrafiłem na narzędzie o nazwie FAKE. Dzięki niemu można realizować procesy CI/CD za pomocą kodu napisanego w języku F#. Decyzja o wzięciu tego narzędzia na warsztat była prosta i szybka.
Trzecim elementem jest dalsze poszerzanie wiedzy na temat Platformy Particular niezbędnej w monitorowaniu oraz analizowaniu wytworzonych funkcjonalności, które bazują na podejściu MQ.
DDTD
To tyle odnośnie moich planów rozwoju technologicznego na bliższą oraz dalszą przyszłość. Wierzę, że praktyczna znajomość powyższych elementów umożliwia wytwarzanie systemów rozproszonych cechującego się dobrą, a może nawet i bardzo dobrą jakością. Dobra jakość pozwala zaś na relatywnie łatwe oraz szybkie realizowanie nowych funkcjonalności, zmiany funkcjonalności istniejących, a także sprawne wdrożenia. Całość pozwala dostarczać produkty końcowemu użytkownikowi, bo przecież o to w tym wszystkim chodzi (chyba…).
Blog
Ostatnim elementem, który uwzględniam w planach, jest ten blog. Po przejściu przez zagadnienia Frontendu być może zmienię układ, kolory, dodam nowe funkcjonalności itp. Jednak najważniejszym elementem pozostanie zawartość. Przede mną długa i kręta ścieżka. Będę dzielił się z Tobą tym, co uda mi się osiągnąć oraz przemyśleniami na temat poznanego zagadnienia.
Kończąc, powrócę do pierwszego zdania z tej sekcji. Na dzień, w którym publikuję ten artykuł, nie umiemy przewidywać przyszłości. Z tego względu zostawiam sobie możliwość niezrealizowania tego, co dla siebie zaplanowałem. Kto wie, może natrafię na ideę, która zmieni mój punkt postrzegania na wytwarzanie oprogramowania, podobnie jak wtedy, kiedy przechodziłem z podejścia RPC na podejście MQ. Być może nie wytrwam w pisaniu na tym blogu, a być może będę pisał częściej. Być może zacznę nagrywać Audio. Być może zacznę nagrywać Video. Być może…
Co by się nie działo, mam nadzieję, że to, co uda mi się stworzyć, w jakiś sposób pomoże również Tobie, zarówno w kwestiach wytwarzanego oprogramowania, jak i ścieżce rozwoju technologicznego.
=
Paweł S
Fajnie, fajnie, podsumowanie jak i plany zacne. Tak sobie myślę, a może by Ci pomóc ogarnąc frontend? Bo mnie to w tę stronę trochę znosi, choć bardziej podchodzę do tego jak fullstack. Taka luźna propo. :)
2020-01-22 12:59 UTC
Paweł dzięki za komentarz. Dzięki, że wpis Ci się podoba :)
Co do pomocy w ogarnięciu frontendu to bardzo chętnie. Tak mi chodzi po głowie, żeby zacząć od rozwiązania, gdzie można wpinać UI w backend, czyli pobierać różne template’y i kodować na nich zachowanie. Coś takiego ma Jekyll.
Jak znasz takie rozwiązanie dla .NET, będę wdzięczny za podzielnie się informacją.
2020-01-23 10:57 UTC
Anonim
Powodzenia!
2021-05-06 00:30 UTC
Dzięki wielkie!
2021-05-06 04:08 UTC