Ustawienia VS Code dla React

 Kilka małych tipów dla Visual Studio Code przy programowaniu FE:

- install ESLint

- install Prettier - Code formatter

- go to: File -> Preferences -> Settings -> Format On Save on (in Edditor)

- install ES7+ React/Redux/React-Native snippets

In Google Chrom install "React Developer Tools".

Włączenie obsługi wszystkich wyjątków w JetBrains Rider

 Po wielu, wielu latach pracy na Visual Studio nadszedł ten moment, w którym zdecydowałem się na komercyjną pracę z innym IDE. Wybór padł na JetBrains Rider. Z jednej strony chciałem spróbować coś nowego, a z drugiej jednak sam Rider jest tańszy niż Visual Studio + Resharper. 

Ogólnie pracuje się spoko, aczkolwiek pracując na domyślnych ustawieniach zauważyłem, że czasami nie widzę pewnego błędu z user code w runtime. Całe szczęście da się to łatwo włączyć w opcjach. tj. Breakpoints -> CLR Exceptions Breakpoints -> Exception Handler -> User Code.

Obrazek z oficjalnej dokumentacji:

https://www.jetbrains.com/help/rider/Debugging_Exceptions.html#exception-breakpoints

Visual Studio Inmediate Window

 Visual Studio posiada fajny bajer do debuggowania, który nazywa się "Inmediate window" który włączamy przy pomocy opcji Debug -> Windows -> inmediate lub skrótowo Ctrl + Alt + I.

Inmediate windows to dodatkowe okienko, które pozwala nam zmieniać zmienne lub też je podglądać w trakcie zatrzymanego debuga w visual studio. Całkiem przypadny bajer. 

Jaeger tracing czyli śledzenie flow aplikacji

 Oglądając kurs "Messaging Pragmatycznie" od DevMentors moją uwagę zwróciło narzędzie Jeager czyli myśliwy. Jeager jest narzędziem służącym do polowania na błędy w aplikacji ze szczególnym nastawieniem na aplikacje rozproszone. Jeager niemal z pudełka (wraz z Open Telemetry) działa w przypadku aplikacji synchronicznych jednak swoje prawdziwe możliwości pokazuje w przypadku aplikacji rozproszonych.

Fragment kodu od DevMentors jak to włączyć "z pudełka" dla aplikacji synchronicznych opartych o HttpContext czyli M18L4 -> https://github.com/devmentors/Messaging-Pragmatycznie/blob/M18L4/src/Shared/TicketFlow.Shared/Observability/Extensions.cs 

Wytyczne w3.org na których opiera się zastosowany tracing: https://www.w3.org/TR/trace-context/#traceparent-header 

Więcej info w dokumentacji lub rozdziale 18 kursu "Messaging Pragmatycznie". Tutaj umieściłem tylko taką krótką notkę dla samego siebie gdybym tego potrzebował na przyszłość.

Rancher czyli darmowy Docker Desktop

 Chyba każdy zna Dockera oraz jego graficzne UI czyli Docker Desktop. Projekt Docker początkowo był zarządzany przez jeden projekt OpenSource jednak z uwagi na prozę życia, tj. potrzebę samofinansowania pewnego dnia postanowiono rozdzielić silnik Dockerowy czyli Docker CLI oraz nakładkę graficzną czyli Docker Desktop i to UI sprzedać firmie zewnętrznej, która to komercjalizuje. Ten model biznesowy działa. Ostatnimi dniami jednak Docker Destkop postanowił podnieść ceny za swoje usługi, więc w firmie dla której obecnie pracuję postanowiono poszukać darmowych alternatyw. Taką darmową alternatywą wykorzystującą pod spodem darmowe Docker CLI jest Rancher.

Z moich obserwacji działa wolniej i nie aż tak intuicyjnie jak DD (Docker Desktop), ale robi robotę. I tak większość rzeczy robi się z konsoli, a nakładka graficzna jest raczej jako miły dodatek niż coś co jest niezbędne do korzystania z konteneryzacji dostarczanej przez DockerCLI.

Z takich uwag, to nie można mieć równocześnie uruchomionego DD oraz Ranchera. Albo jedno, albo drugie.

Linki:

https://www.rancher.com/ -> oficjalna strona projektu.

https://github.com/rancher/rancher - repozytorium kodu źródłowego na github

Bruno czyli lepszy i darmowy Postman

Ostatnio w firmie w której pracowaliśmy dział bezpieczeństwa na spółkę z działem zakupowym zabronili nam korzystać z Postmana. Było z nim kilka problemów:

• dla używania w firmach jest płatny (trzeba kupić licencję per pracownik) w nowszych wersjach 
• łączy się z chmurą, czemu przeciwny był dział bezpieczeństwa
• przy dużej ilości requestów jakie wysyłaliśmy (ponad 1000) na słabszych komputerach potrafił losowo nie wykonać jakiś requestów nie rzucając przy tym błędem.

Zostaliśmy zmuszeni poszukać alternatywy i ją znaleźliśmy. Tą alternatywą jest Bruno: 

Bruno:

• w swojej podstawowej wersji jest darmowy, nawet do zastosowań komercyjnych (płacimy dopiero za jego integrację z usługami firmowymi)
• nie łączy się z chmurą
• dużo lepiej obsługuje wgrywanie plików jako załączniki do requestu (np, jak chcemy wgrać dużego Excela, albo CSV)
• posiada możliwość szybkiego zaczytania plików z Postmana, więc migracja jest łatwa i bezbolesna
• dużo łatwiej robi się code review zmian w plikach (robisz code review pojedyńczego pliku z requestem a nie całej wielkiej kolekcji postmanowej)

 Z wad wykryliśmy że:

• przy równoczesnym uruchomieniu dużej ilości requestów (powyżej 1000) trzeba dać opóźnienie 1ms pomiędzy requstami. Nie wiemy dlaczego, ale to eliminuje pewien losowy błąd.

Na chwilę obecną jesteśmy zadowoleni z alternatywy. Osobiście uważam, że do prostych REST API Call Bruno jest lepszy niż Postman.

Linki:

https://www.usebruno.com/ -> strona projektu.

https://github.com/usebruno/bruno/  -> kod źródłowy dostępny na github

Azure DevOps

W ten weekend miałem okazję być na kursie/warsztatach/prezentacji zorganizowanych przez StacjaIT .

Był to płatny, kilkugodzinny kurs w tematyce narzędzia "Azure DevOps". Poziom warsztatu był oznaczony jako "wprowadzenie" tudzież "dla początkujacych".  Ostatnio zainteresowałem się tematyką DevOps nieco głębiej, a że tematy Chmurowe są mile widziane w wielu ogłoszeniach o pracę postanowiłem się wybrać na ten warsztat. I po wszystkim uczucia mam nieco mieszane. Spodziewałem się czegoś związanego z Chmurą, na co mógłby wskazywać pierwszy człon nazwy, tj. "Azure". Stety bądź niestety coś, co Microsoft nazwał "Azure DevOps" to nie jest typowe "Azure", a jedynie stary "Team Foundation System" po rebrandingu. 

Moja pierwsza styczność z TFS miała miejsce jakieś ~15 lat temu i wtedy w firmie, w której pracowaliśmy zaliczyliśmy jeden poważny fackup związany z błędem merge kodu źródłowego. Autorski, microsoftowy system kontroli wersji zaliczył na naszym projekcie wielkiego faila. Na tyle dużego, że programiści go nienawidzili. Managment natomiast był zbyt zajęty łapaniem "punktów bonusowych" u Microsoftu i nalegał na dalsze kontynuowanie korzystania z tej technologii.

Pierwsza część warsztatów to była cała filozofia "DevOps". Wyjaśnienie czym jest DevOps, a czym nie jest. Nie będę się tutaj nad tym teraz rozpisywał. Polecona była również książka "Projekt Fenix" którą swego czasu rozdawano nam za darmo gdy jeszcze pracowałem w Santanderze. 

Teraz wracamy do części praktycznej i... okazało się że ten cały współczesny "Azure DevOps" to jest nic innego, jak tool w którym pracowałem przez ~2.5 roku w Duńskim Santanderze. I w sumie tyle bym mógł napisać. Że największą wartością dodaną tego szkolenia było to, że została mi usystematyzowana pewna wiedza, którą już wcześniej miałem, ale nie do końca orientowałem się w fachowym nazewnictwie. Całe szczęście, że ticket na to szkolenie dostałem za darmo w mojej obecnej firmie.

To jeszcze tak z kronikarskiego obowiązku wypadało by wspomnieć czym ten Azure Devops jest. 

Azure DevOps to jest zintegrowane narzędzie, a dokładniej kilka narzędzi w jednym które spełnia podstawowe funkcje takie jak: Scrum Board, Pull Request Board, firmowa Wikipedia, Build Pipeline (CI), tool do publikowania deployów (CD)* i parę innych rzeczy. Taki mini kombajn, który dla firm, które siedzą na stack M$ i maja wykupione płatne licencje na Visual Studio dodawany jest niejako do tych licencji w gratisie.

No cóż. Nie do końca było to to, czego się spodziewałem ale przynajmniej teraz wiem jak się nazywa tool, którego znajomość mogę sobie wpisać do CV.

* - tutaj CD oznaczało jedynie inicjalizację builda (kwestia akceptacji), a sam build ogarniany był w Octopus Deploy. Tutaj część procesu była automatyczna, tutaj uzyskiwane były zgody (jeśli np. deploy na proda wymagał jakiejś akceptacji kogoś "powyżej"), ustawiany był czas deployu, ale sam finalny build i deploy na wiele różnych serwerów czy środowisk odbywał się w Octopusie.

https://en.wikipedia.org/wiki/Azure_DevOps_Server - strona Azure Devops na wikipedi.