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)
In Google Chrom install "React Developer Tools".
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)
In Google Chrom install "React Developer Tools".
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 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.
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ść.
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
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:
Zostaliśmy zmuszeni poszukać alternatywy i ją znaleźliśmy. Tą alternatywą jest Bruno:
Bruno: