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".
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
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
Dodatkowe komendy, które mogą być przydatne:
- Ustawienie kontekstu "default" dla Ranchera (Docker Desktop nadpisuje to ustawienie):
docker context ls
docker context use default
- Otwieranie w PowerShell ustawień konfiguracyjnych:
notepad.exe "\\wsl$\rancher-desktop\etc\docker\deamon.json"
A następnie dodać odpowiednie adresy IP do pliku konfiguracyjnego.
Przykładowy wpis:
{
"registry-mirrors": ["http://1.2.3.4:9090", "http:/1.2.3.4:9095"],
"insecure-registries": ["1.2.3.4:9090", "1.2.3.4:9095"],
"debug": true,
"experimental": false
}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:
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.
Ost. w pracy miałem do zrobienia fajne zadanie, tj. dodać narzędzie monitorujące Prometeus wraz z narzędziem wyświetlającym te dane czyli Grafaną. Wszystko w kontenerach Dockerowych, czyli bardzo przyjemne zadanie. Na wstępnie chciałbym pozdrowić Marcina Budnego, którego prezentacja na Śląskiej Grupie .NET dostępna na youtube bardzo mi w tym pomogła: link do nagrania
Gdyby ktoś jednak nie miał czasu, to opiszę w dużym skrócie. System monitorujący składa się z 3 elementów:
1. klient Prometeusa, który wystawia endpoint /metrics z ustandaryzowanym tekstem (format monitu)
2. serwer Prometeusa, który jest de fakto bazą danych nasłuchującą entpointy klientów, agregujace je oraz wystawiający własny endpoint z danymi
3. interfejs UI w postaci Grafany
Klienci mogą być różni. Wiele technologii posiada własnych klientów, a jak w jakiejś brakuje to dosyć łatwo można napisać własnego klienta. Do .net istnieje kilka klientów. Do tego obrazy Dockerowe mają swojego klienta. Serwer może mieć swojego klienta (np. monitorowanie zajętości dysku twardego), kolejki typu Kafka mogą mieć klienta itp.itd.
Serwer w sposób dynamiczny agreguje te dane, dzięki czemu klienci mogą się "rozszerzać" np. w oparciu o kontenery Dockerowe i np. Kubernetesa. Jak mamy większe obciążenie to zwiększamy ilość aplikacji klienta, a serwer Prometeusa automatycznie to wykrywa i ogarnia.
Grafana, która nasłuchuje zagregowanych danych z Prometeusa to część UI która do wyświetlania danych w przystępny sposób. Obok wyświetlania może też wysyłać powiadomienia, np. na email, slacka, teamsy itp.
Klienci Prometeusa zazwyczaj posiadają pewien zbiór gotowych metryk, ale zawsze można dodawać swoje (Marcin to fajnie wyjaśnił w swoim filmie). Do tego, można się podpiąć pod inne toole, np. Open Telemetry i wystawić dane dla Prometeusa przepuszczając dane z OpenTelemetry przez mapper (dane wystawiane przez OpenTelemetry są w innym formacie niż ten, którego oczekuje Prometeus).
Wszystko działa całkiem miło i przyjemnie. Wiele rzeczy jest zautomatyzowanych. Bawiąc się grafaną opartą o obraz dockerowy w miarę szybko ogarnąłem jak zapisać i przechowywać dane tablic (dashboardów) w taki sposób, aby wszystko było "na gotowe" po uruchomieniu kontenera. Trzeba w tym celu zmapować Volumes na swój własny katalog, ale fajnie to działa. Widać, że technologia jest dopracowana (np. dashboard jest w formacie .json więc fajnie się archiwizuje zmiany w raportach w Git-cie).
W międzyczasie zrobiłem też w firmie małą, wewnętrzną prezentację z tego tematu, jednak obawiam się że mogę nie dostać zgody na jej upublicznienie.
Linki:
https://www.youtube.com/watch?v=jYbqGB3Vhbo - prezentacja Marcina Budnego na Ślaskiej grupie .NET
https://github.com/docker/awesome-compose/blob/master/prometheus-grafana/README.md - przykładowy plik Docker-Compose.yml
W poprzednim poście opisałem narzędzie do skanowania obrazów dockera Trivy link. W tym wpisie wspomnę o narzędziu, które służy do skanowania kwestii bezpieczeństwa już zbudowanych narzędzi, które w dodatku posiada dosyć dobrą możliwość wpięcia w proces CI/CD czyli Dockle.
Szerzej opisane co to narzędzie robi jest na blogpoście a na portalu Medium - link
Linki:
https://github.com/goodwithtech/dockle - kod źródłowy na github
https://containers.goodwith.tech/ - strona projektu
https://shrihariharidas73.medium.com/dockle-container-image-linter-for-security-helping-build-the-best-practice-docker-image-easy-b4853fb3675e - blogpost z opisem czym jest dockle
Budując lub wykorzystując obraz Dockerowy warto mieć świadomość że ten obraz często i gęsto posiada własne zależności, np. różnego rodzaju oprogramowanie zainstalowane przez Twórców obrazu dockerowego. Każde z tych narzędzi czy bibliotek może posiadać swoje podatności bezpieczeństwa. Jeżeli zbudujemy obraz, np. bazując na Node.js, który z kolei bazuje m.in. "buildpack-deps:stretch" to musimy mieć świadomość, że jeśli paczka "buildpack-deps:stretch" będzie posiadała jakąś podatność bezpieczeństwa to nasz obraz również będzie ją posiadał. W tym celu warto skanować obrazy dockerowe pod kątem podatności bezpieczeństwa. Przykładowe narzędzie: Trivy.
Linki:
https://trivy.dev/latest/ - strona projektu
https://github.com/aquasecurity/trivy - kod źródłowy na githubie
https://wkontenerach.pl/zarobili-36000-usd-z-kopania-kryptowalut-przez-podatne-obrazy-dockerowe-na-docker-hub/ - blogpost z uzasadnieniem dlaczego warto skanować swoje kontenery pod kątem podatności bezpieczeństwa.
Mojego bloga często traktuje jako swojego rodzaju notatnik na przyszłość. Tak jest i tym razem, tj. chciałbym sobie gdzieś przechować referencje do projektu https://www.vaultproject.io/ czyli projektu, który możemy użyć jako swego rodzaju KeyValueStore dla różnego rodzaju haseł w aplikacji w przypadku podejścia rozproszonej architektury aplikacji, tj. aplikacji opartej o mikroserwisy. Zamiast więc powtarzać wszystkie sekrety dla każdego projektu na każdym osobnym serwisie w builderze to możemy je trzymać w schronie (ang. Vault), a sami pilnujemy tylko hasła do vaulta (łatwiej się wtedy to wszystko zmienia gdy zachodzi potrzeba zmiany).
Integracje z aplikacją .net możemy zrobić przez VaultSharp
Nowy .net 8 daje nam bardzo fajną możliwość wykonywania testów integracyjnych naszych aplikacji webowych przy pomocy klasy WebApplicationFactory. Tego typu testy mogą się odbywać zarówno na faktycznej aplikacji jak i częściowo podmienionej, np. możemy sami podmienić niektóre serwisy, a inne zostawić takie jak były. Możemy zmienić bazę danych, na której mają się wykonywać testy itp. Bardzo fajne narzędzie choćby po to, aby mieć pewność co finalnie wychodzi z naszej aplikacji.
Czasami jednak potrzebujemy mieć aplikację z uwierzytelnieniem, tj. autoryzacją. Przykładowo przy pomocy JWT token. Oczywiście możemy pisać pełny kod od początku tak, aby łatwo się to podmieniało lub aby serwis tworzący tokena poprawnie zwracał go zarówno dla projektu z API jak i dla projektu z testami, ale czasami może się zdarzyć, że trafimy do istniejącego projektu, w którym następuje uwierzytelnienie w zewnętrznym serwisie do którego nie mamy dostępu, a przy okazji nie chcemy od samego początku przebudowywać całej aplikacji (refaktor powinien się odbywać ewolucyjnie, a nie rewolucyjnie). W takich sytuacjach z pomocą przychodzi nam paczka nugetowa: WebMotions.Fake.Authentication.JwtBearer
Dzięki tej paczce w naszym BaseTestController możemy stworzyć metodę autoryzacji:
dynamic data = new ExpandoObject();
data.sub = Guid.NewGuid();
data.role = new [] {"sub_role","admin"};
Client.SetFakeBearerToken((object)data);
gdzie Client to jest obiekt klienta tworzony przez WebApplicationFactory w metodzie "WithWebHostBuilder(builder => {}).CreateClient();
Później możemysię to tych Claimsów odwołać w dowolnym miejscu aplikacji poprzez implementację interfejsu IHttpContextAccessor ,który możemy wstrzyknąć np. do naszej testowej implementacji ISecurityService (czy jaki tam będziemy mieli dowolny inny interfejs w naszej aplikacji odpowiedzialny za obsługę uwierzytelnienia).
Kod źródłowy dostępny na https://github.com/webmotions/fake-authentication-jwtbearer z licejcją MIT więc możemy to komercyjnie zastosować. Dzięki tej paczce, możemy sobie "zasymulować" autoryzację i podmienić jedynie serwis odpowiedzialny za autoryzację. Cała reszta aplikacji może pozostać tak jak była (sami decydujemy, którą część aplikacji chcemy testować tak jak jest, a którą chcemy symulować).
Linki
https://www.nuget.org/packages/WebMotions.Fake.Authentication.JwtBearer - nuget
https://github.com/webmotions/fake-authentication-jwtbearer - github
https://licenses.nuget.org/MIT - licencja MIT
Jak już wspomniałem w moim poprzednim poście oglądam sobie kurs "SOLID WebApi" od DevMentors i co jakiś czas wyłuskuję sobie z niego coś nowego. Tym razem wyłuskałem od nich paczkę NuGetową Humanizer czyli gotowe rozszerzenie to zamiany stringów z jednej wersji na inną, np. z CamelCase na SnakeCase, albo ze SnakeCase na wyrazy rozdzielone spacją. Więcej przykładów jest na stronie projektu. To co warto wspomnieć, to kod źródłowy dostępny jest na githubie (open source), a sama paczka jest na licencji MIT, czyli można ją bez problemu używać również w komercyjnym oprogramowaniu.
Linki:
https://github.com/Humanizr/Humanizer - link do kodu źródłowego na GitHub z plikiem README oraz przykładami użycia.
https://www.nuget.org/packages/Humanizer/ - link do paczki na serwisie nuget
Oglądając kurs od DevMentors zauważyłem że używają oni pakietu Nugetowego Shoudly. Shouldy jest to kolejny pakiet który pozwala wykonywać testy jednostkowe w sposób bardziej płynny, czyli innymi słowy robi dokładnie to samo, co opisana przezemnie wcześniej paczka FluentAssertions.
Co warto wspomnieć, zarówno Shouldy jak i FluentAsserions mają w miarę przyjazne (z komercyjnego punktu widzenia) licencje. Shouldy ma licencję BSD-2, natomiast FluentAsserions posiada licencję Apache.
Linki:
https://docs.shouldly.org/ - strona projektu
https://www.nuget.org/packages/Shouldly - link do Shoudly na Nuget.
Bawiąc się moim testowym projektem WinFormsCrud w pewnym momencie postanowiłem sprawdzić sobie jakie mam pokrycie kodu testami jednostkowymi. O ile wiedziałem, że dla samego projektu WinForms będzie zero (bo do tego projektu jeszcze nie dołożyłem testów) o tyle dla pozostałych projektów byłem zainteresowany ile % wyjdzie.
Samo visual studio 2022 nie ma tego feature w standardzie, o tyle z pomocą przyszedł mi stackoverflow.com który poinformował mi, że dla Visual Studio 2022 Community istnieje darmowy tool pozwalający to sprawdzić, czyli FineCodeCoverage2022
Sprawdzilem sobie ten tool i on faktycznie działa.
Wiadomo, zawsze mogło być lepiej, natomiast w tym momencie najważniejsze że tool jest darmowy i działa.
Do napisania tego postu zainspirowały mnie dwie rzeczy. Pierwszą był post Cezarego Walenciuka na jego blogu odnośnie problemów z klasą HttpClent https://cezarywalenciuk.pl/blog/programing/ihttpclientfactory-na-problem-z-httpclient
Cezary omawia tam problem braku zwalniania socketów przez klasę HttpClient. Jako pierwsze rozwiązanie pada "użyj Flur", który opakowuje HttpClienta i dzięki temu działa to dużo bezpieczniej. Później Cezary omawia problem czystego HttpClienta i na koniec podaje rozwiązanie docelowe dla aplikacji .NET CORE MVC czyli HttpClientFactrory wpiętego w pipeliy (sorry, middleware) ASP MVC CORE. Wszystko pięknie, tyle że ja aktualnie pisałem sobie apkę na zadanie rekrutacyjne i tam było w wymaganiach podane aby to była aplikacja Windows Forms. Chwilę popatrzyłem, nie bardzo wiedziałem jak się wpiąć w pipeliny (middleware) WinFormsów więc użyłem Flur.Http i jestem szczęśliwy.
Dziękuje Cezary.
Edycja:
Problem HttpClient oraz propozycje na jego rozwiązanie jest znacznie szerzej opisany w czasopiśmie Programista nr. 5/2023 (110). Autorem art. jest Igor Trafalski.
Igor przedstawia rozwiązania w postaci HttpClientFactory oraz TypedHttpClient czyli wykorzystanie wbudowanej w net core HttpClientFactory, która to poprzez specjalny handler reużywa połączeń HttpClienta.
Linki:
https://www.nuget.org/packages/Flurl.Http
https://programistamag.pl/programista-5-2023-110/ - link do wspomnianego numeru czasopisma "Programista"
https://programistamag.pl/jak-bezpiecznie-korzystac-z-httpclient-w-net/ -> więcej o tym konkretnym art. Igora.
https://learn.microsoft.com/en-us/aspnet/core/fundamentals/http-requests?view=aspnetcore-9.0 -> link do dokumetacji
Czasami pisząc różne zapytania http, np. zapytania REST potrzebujemy wprowadzić politykę ponowienia zapytania. Serwer mógł dostać czkawkę, mógł się pojawić jakiś problem sieciowy lub deadlock na bazie danych po stronie aplikacji serwerowej. Dlatego dobrze jest mieć jakiś sprawdzony sposób na wykonanie powtórnych zapytań. Jest to szczególnie ważne w kodzie współbierznym..
W tym momencie, zgodnie z teorią "not invented here" (nie wynaleziono tutaj) wchodzi paczka nuget o nazwie Polly która jest odpowiedzialna za ogarnięcie polityki ponownego wysyłania zapytania. Można napisać ile razy chcemy wysłać zapytanie (ile porażek akceptujemy), z jaką częstotliwością robić ponowienie, które wyjątki oraz w jaki sposób chcemy je przechwycić.
https://www.nuget.org/packages/polly/
For several years I have been working remotely in a fully distributed team. Working in a distributed team means that sometimes we need tools that we would not normally need. An example of such a situation is the simultaneous work of several people at the blackboard.
Everyone who has worked in a programming team knows how useful a blackboard can be, where two or more developers can come and start writing and explaining various problems at the same time.
One of the tools that is trying to replace the table for distributed teams is the Figma application. We used it yesterday in our Scrum retrospective and it generally worked. The team decided that the tool is ok and it lived up to its opinion, so I leave a note on the blog here if I ever look for a name for this solution in the future.
Links:
Yesterday I was at a local .net group meeting. One of the presentations was about automatic tools for improving code quality. The first of the presented tools was the SonarQube that is a tool for static code analize that I know and use. The second presented tool for dynamic UI testing in terms of security was OWASP ZAP. It is a "proxy" tool, i.e. it is used to place it between the browser and the visited page, which can view or modify information sent from / to the browser. If anyone has used Fiddler, know what a "browser proxy" is (same type of tool but improved).
OWASP ZAP in the default mode is used to make the user use the page in "normal" mode, and the tool underneath checks for any security vulnerabilities. If someone uses Selenium for automatic tests, then by connecting OWASP ZAP gets additional safety tests.
It is also possible to run OWASP ZAP from the script level, which makes it possible to insert it into the CI / CD tool or to generate a weekly report. It is recommended to test on a different instance than production / test because full tests can take a long time and generate server load.
Tool is Open Source and supported by Community.
Summary:
We have 3 main modes: