Robert Skarżycki - blog - RSS Feed

30 dni z... Pythonem - dzień #2

Tue, 16 Jul 2024 00:00:00 GMT

ainspirowany znalezionym niedawno wystąpieniem Matta Cuttsa pt. “Try something new for 30 days” na konferencji TED, postanowiłem dać sobie następujące “wyzwanie”: przez 30 dni codziennie spędzać pewną porcję czasu na uczenie się Pythona.

Do poznawania Pythona zbierałem się już kilka razy, jakieś podstawowe skrypty tworzyłem, ale brakuje mi elementarnej biegłości w tym języku. Idea 30-dniowego wyzwania wydała mi się ciekawa: brzmi jak coś, co będzie i angażujące, i motywujące, a jednocześnie jakoś określone, przynajmniej w czasie. Na koniec chciałbym mieć poczucie, że coś udało się stworzyć - nie jedynie przejść tutorial X, ale coś zbudować.

Mająć powyższe na uwadze Wymyśliłem więc, że spróbuję sportować jakąś bibliotkę, najpewniej JavaScriptową/TypeScriptową do Pythona. Zamierzam przejść - przynajmniej na początku - poniższe kroki:

Znaleźć odpowiednią bibliotekę. Niech będzie wystarczająco mała, żebym był w stanie ją ogarnąć i żeby miała małe/proste API. Nie ma znaczenia, czy analogiczna biblioteka w Pythonie jest (na pewno jest). Zadanie ma być w celach edukacyjnych, nie dla sławy.
Biblioteka musi mieć jakieś testy, dzięki temu będę mógł zacząć od przepisania testów jednostkowych do Pythona i trochę pójść w podejściu TDD.
Wszystko wrzucę na Githuba, niech sobie leży w formie pamiętniczka i kopii zapasowej.
Tutaj na blogu będę prowadził developer’s diary, czyli dzienniczek, w którym będę starał się opisywać, co udało się danego dnia, na jakie trudności natrafiłem i co mnie zdziwiło, jak Pythonowego nowicjusza.

Chyba na te 30 dni więcej ambicji nie mam. Jeśli okazałoby się, że idzie szybko (albo że wybrałem zbyt małą bibliotekę), to mogę pójść albo w kierunku publikacji paczki w ekosystemie Pythonowym, albo wybrania jakiegoś tematu i np. poznania konkrentnych bibliotek, które na rynku są dla niego stosowane. Zobaczymy, co wyjdzie.

30 dni z... Pythonem - dzień #0

Thu, 11 Jul 2024 00:00:00 GMT

…

Zmigrowany do Gatsby v5!

Wed, 31 Jan 2024 00:00:00 GMT

Udało się zmigrować bloga z Gatsby’ego w wersji 4 do wersji 5 - polecam iść krok po kroku według przewodnika z oficjalnej dokumentacji.

Obyło się bez większych problemów, dodatkowym krokiem była migracja z pakietu typeface na @fontface - okazało się, że typeface jest już deprecated. Przy okazji udało się rozwiązać problem z niewłaściwym wyświetlaniem literki “ż” - zwłaszcza w moim nazwisku. :-)

Azure DevOps pipelines - tips & tricks (4)

Tue, 04 Oct 2022 00:00:00 GMT

cache

Azure DevOps pipelines - tips & tricks (3)

Sat, 01 Oct 2022 00:00:00 GMT

Kolejnym ciekawym “ficzerem” w pipeline’ach Azure DevOps jest możliwość uruchomienia całego joba lub pojedynczego stepu na kontenerze z określonego obrazu, innego niż te podstawowe, jakie Microsoft oferuje jako build maszyny. Uzyskujemy to w ten sposób:

resources:
  containers:
  - container: u14
    image: ubuntu:14.04

jobs:
- job: RunInContainer
  container: u14  
  steps:    
  - script: cat /etc/os-release
    displayName: Print OS version

Lub dla pojedynczego stepu:

resources:
  containers:
  - container: u14
    image: ubuntu:14.04

jobs:
- job: RunInContainer
  steps:    
  - script: cat /etc/os-release
    displayName: Print OS version
	target: u14

Co więcej, możemy skorzystać nie tylko z obrazów dostępnych publicznie w Docker Hub, ale także naszych własnych, które zbudowaliśmy i wgraliśmy do naszego ACR-a.

Po co w ogóle jednak mielibyśmy używać innego obrazu? Do głowy przychodzą mi trzy przypadki:

Potrzebujemy jakichś konkretnych narzędzi do wykonania zadania - zamiast tworzyć kroki, w których te narzędzia ściągamy i doinstalowujemy, możemy skorzystać z obrazu, który już je zawiera. Dzięki temu nie tylko scentralizujemy miejsce, w którym np. określamy jakiej wersji danego narzędzia używamy (wiele pipeline’ów skorzysta z jednego obrazu, zamiast wielu pipeline’ów “babrających” się w samodzielnego dociąganie zależności), a wręcz może i “outsource’ujemy” ten problem (jeśli taki obraz już jest na rynku), ale nawet przyspieszymy build: obraz już ma narzędzie gotowe do pracy, nie trzeba tracić czasu na jego ściąganie i instalowanie.
Weryfikacja na różnych środowiskach: w połączeniu z użyciem matrix jako strategy dla danego joba możemy uruchomić ten sam zestaw kroków na różnych obrazach. Może na przykład weryfikacja jakiegoś narzędzia, czy działa na Windowsie i Linuksie?
W świecie kontenerowym istnieje taki wzorzec, aby skonteneryzowaną aplikację budować też w kontenerze: dzięki temu nie tylko same środowisko uruchomieniowe aplkacji jest stabilne (explicite wyrażone w Dockerfile), ale tak samo środowisko, w którym budujemy aplikację. Zamiast wieloetapowego Dockerfile‘a, który może być trudniejszy do zrozumienia - możemy tę informację o stabilnym środowisku uruchomieniowym przenieść do pipeline’u, uruchamiając build joba w kontenerze. To pewnie jest dyskusyjne, bo na pewno zaletą oryginalnego podejścia jest to, że tuż obok aplikacji (w jej Dockerfile) jest informacja o wszystkich zależnościach - compile-time i run-time.

Disaster recovery w Azure (1) - teoria

Wed, 17 Aug 2022 00:00:00 GMT

Chciałbym niniejszym zainicjować cykl wpisów o disaster recovery w Azure, czyli tych wszystkich rozwiązaniach, które oferuje nam chmura od Microsoftu, a które mogą nas uchronić przed pewnymi poważnymi problemami. Pomysł jest taki, że najpierw opiszę ogólnie, co kryje się pod tym terminem i jakie są możliwe rodzaje owych katastrof, a w kolejnych odcinkach będę się przyglądał konkrentym rodzajom zasobów na Azure i sprawdzał, jakie są oferowane “siatki bezpieczeństwa”.

Co może pójść nie tak?

Zaczynając od początku, podstawowym pojęciem jest business continuity, czyli zapewnienie ciągłości “biznesu” (systemu, aplikacji etc.), na wypadek nieprzewidzianego zdarzenia, zaburzającego tę ciągłość. Pamiętajmy więc, że tutaj chodzi o to, żeby “przetrwać” po katastrofie, niż żeby do niej nie dopuścić (inna sprawa, że np. pewnym katastrofom zapobiec nie możemy, bo są od nas niezależne). Można więc powiedzieć, że procedury disaster recovery i wszystkie zabiegi z tym związane są swoistym ubezpieczeniem na życie - nie zapobiegają wprost katastrofie bądź awarii, ale ułatwiają dalsze funkcjonowanie; tak samo jak ubezpieczenie na życie zdrowia (ani tym bardziej życia) ubezpieczonemu nie przywróci, ale wypłacone środki mogą pomóc w życiu po katastrofie.

Jeśli mówimy o systemach IT, a zwłaszcza zasobach w chmurze, to w zasadzie możemy mieć dwa rodzaje “katastrof”:

niedostępność serwisów chmurowych, czyli nieprzewidziana awaria po stronie Azure’a spowodowana dowolnym czynnikiem: katastrofą naturalną, błędem ludzkim itp.,
“czynnik ludzki” - błąd ludzki “naszego” pracownika bądź wroga działalność włamywacza, powodująca np. usunięcie bazy danych.

“Czynnik ludzki” może spowodować:

utratę i/lub uszkodzenie danych,
niedostępność naszej aplikacji (serwisu) na skutek błędnej konfiguracji.

Natomiast jeśli chodzi o niedostępność serwisów chmurowych, to sam Microsoft wyróżnia trzy poziomy awarii:

Lokalna - dotyczy danego serwera bądź serwerów.
Strefowa - dotyczy całego data center.
Regionalna - dotyczy całego regionu.

Te poziomy wynikają z architektury infrastruktury chmurowej, dokładniej zanurkujemy w temat trochę niżej.

RPO vs RTO

Gdy mowa o business continuity bądź disaster recovery, często pojawiają się dwa terminy: RPO i RTO. Wyjaśnijmy je pokrótce.

RPO - recovery point objective - to jest najdłuższy odcinek czasu (liczony wstecz od momentu awarii), dla którego utrata danych jest możliwa. Łopatologicznie: jeśli w Wordzie mamy auto-save co 5 minut, to maksymalnie 5 minut pracy możemy stracić. RTO - recovery time objective - to jest czas, liczony od momentu awarii, w którym aplikacja/serwis wraca do normalnego funkcjonowania. W przykładzie z Wordem: jeśli awaria skończyła się bluescreenem, to RTO będzie równy czasowi potrzebnemu na restart komputera, włączenie Worda i wybranie opcji odzyskiwania plików.

Gdy będziemy rozważać różne mechanizmy disaster recovery, te dwa terminy będą się przewijać - i one pozwalają ocenić, ile daje nam konkretny mechanizm, zwłaszcza w porównaniu z pozostałymi opcjami.

Architektura infrastruktury Azure

Aby nie powtarzać tego przy omawianiu kolejnych zasobów, warto rzucić okiem, jak wysokopoziomowo zorganizowana jest infrastruktura chmury Azure. Pomijając najniższy poziom konkrentych serwerów lub ich grup - podstawową jednostką jest centrum danych. Jedno lub kilka centrów danych tworzą strefę (availability zone). Z kolei 3 availability zones razem tworzą region. Regiony zaś mają swoje “siostrzane” regiony (powiedzmy najbliższego sąsiada), z którego mogą korzystać np. do tworzenia backupów odpornych na awarię oryginalnego regionu. Oczywiście geografia i szczegóły rozmieszczenia centrów danych i stref mają znaczenie: z jednej strony muszą być położone na tyle blisko, aby zapewniać najmniejsze opóźnienia sieciowe (np. availability zones muszą mieć opóźnienie poniżej 2ms w obie strony), a z drugiej - być jednak niezależne np. jeśli chodzi o źródło energii bądź narażenie na katastrofy naturalne. (Ciekawe, jak to będzie rozwiązane podczas budowy regionu Poland Central - która przecież właśnie trwa - czy można tak na oko przyjąć, że np. jedna zone’a będzie zasilana z Ostrołęki, a druga - z Kozienic? :D)

Azure DevOps pipelines - tips & tricks (2)

Mon, 11 Jul 2022 00:00:00 GMT

W dzisiejszym odcinku pochylimy się nad zmiennymi i parametrami. Poniższa tabelka przedstawia podstawowe różnice:

	parametry	zmienne
różne typy danych	✔️	❌ tylko string
zmiana w runtime	❌	✔️
kierunek przekazywania	top-down	⬆️⬇️➡️

Warto o tych różnicach pamiętać, bo w wielu przypadkach może się wydawać, że w zasadzie możemy zmienne i parametery stosować zamiennie. Tymczasem rządzi nimi inna logika, a do tego - każda grupa ma swoje… dziwne pułapki.

Największe pułapki ze zmiennymi

Po pierwsze, zmienne są by default przekazywane do skryptów Bash/CMD. Wydaje się na to pierwszy rzut oka sensowne, tym bardziej, że “gratis” dostajemy w skryptach dostęp do zmiennych, które są dostarczone przez platformę, np. Build.BuildId. Ale to ma też swoje konsekwencje

Nie ma nadpisywania zmiennych przy użyciu taska `script`

Weźmy taki kawałek YAMLa:

variables:
  MY_VARIABLE: "original value"

steps:
  - bash: echo "$MY_VARIABLE"
    env:
      MY_VARIABLE: "overriden?"

W 5. linii wołamy kawałek skryptu Bash, który ma wydrukować na ekran wartość zmiennej środowiskowej MY_VARIABLE. Dla mnie logiczne było to, że skoro zmienna pipeline’owa MY_VARIABLE automatycznie jest wstrzykiwana do skryptu jako zmienna środowiskowa o tej samej nazwie, to jednak przekazanie jakiejś wartości w liście env spowoduje “wygraną” tej właśnie lokalnej wartości. Tak jednak nie jest. Powyższy kawałek kodu wydrukuje: original value. Przyznacie, że to mindfuck?

Zmienne typu sekret nie są przekazywane do skryptów

W variable groups możemy zdefiniować niektóre zmienne jako sekrety (chyba też wartości zaimportowane z key vaulta nimi są domyślnie), dzięki czemu uzyskujemy większe bezpieczeństwo w samym portalu: wartości sekretu nie można podejrzeć, ani skopiować, ani też zobaczyć jego użycia w logach konkrentego builda (wartość jest “wygwiazdkowana”). Niestety, trzeba pamiętać, że taka zmienna typu sekret nie zostanie automatycznie przekazana do skryptu Bash/CMD, co powoduje, że musimy je przekazać przez argument env.

Service connection nie może być w zmiennej

Jeśli mamy taką sytuację, że np. środowiska testowe i produkcyjne są na innych subskrypcjach Azure, to wówczas potrzebujemy dwóch oddzielnych service connections, aby móc np. wdrażać jakieś zasoby do chmury. Dobrze by było mieć takie rozgałęzienie w pipeline’ie, że w zależności od środowiska używamy konkretnego service connection. Czyli można by chcieć mieć coś takiego:

# dev-vars.yaml
variables:
  SERVICE_CONNECTION: "dev-service-connection"

# prod-vars.yaml
variables:
  SERVICE_CONNECTION: "PROD-service-connection"

# main.yaml
parameter:
  - name: environment
    type: string
    values:
      - dev
      - prod

stages:
  - stage:
    variables:
      - template: ${{ parameters.environment }}-vars.yaml
    steps:
    # -- omitted, but with same step using $(SERVICE_CONNECTION)

(Przy okazji - tutaj jeszcze jeden ciekawy przypadek użycia szablonów: jako “worków” ze zmiennymi, które możemy “importować” w stage’ach i jobach.) Niestety, tak się nie da: przy próbie użycia zmiennej SERVICE_CONNECTION np. w tasku AzureResourceGroupDeployment@2 - dostaniemy na twarz błąd, mówiący mniej więcej, iż “ten pipeline nie jest autoryzowany do service connection o nazwie ’$(SERVICE_CONNECTION)`“. A zatem widzimy od razu, że problem jest z rozwiązywaniem tej zmiennej. Niestety, jedyny workaround to wprowadzenie sztucznego parametru, który będzie służył za słownik:

# main.yaml
parameters:
  - name: environment
    type: string
    values:
      - dev
      - prod
  - name: serviceConnections
    type: object
    default:
      dev: "dev-service-connection"
      prod: "PROD-service-connection"

stages:
  - stage:
    variables:
      - SERCICE_CONNECTION: ${{ parameters.serviceConnections[parameters.environment] }}
    steps:
    # -- omitted, but with same step using $(SERVICE_CONNECTION)

To jest niestety hak, który w głowie miesza pomiędzy parametrami, które przychodzą z zewnątrz a parametrami, które są “internal use”. A żeby było jeszcze gorzej, to na portalu supportu Microsoftu jest na to zgłoszony błąd, który od… 3 lat czeka na rozwiązanie.

Runtime parameter nie może być opcjonalny

Siłą parametrów “najwyższego rzędu” - czyli parametrów, które definiujemy w tym YAML-u, który potem jest użyty do konkretnej build definition - jest to, że gratis dostajemy ładny UI do specyfikowania tychże dla konkretnego uruchomienia. W ten sposób przykładowo scenariusz z poprzedniego podrodziału mógłby być użyty tak, że wybór środowiska - dev bądź prod - dokonuje się z eleganckiego dropdowna. Wszystko jest fajnie dopóty, dopóki nie zechcemy wprowadzić parametru opcjonalnego. Chciałoby się użyć konsekwentnie tej samej składni, której używamy, czyniąc “zwykły” parametr opcjonalnym - a więc określając jego wartość w polu default; a w szczególnym przypadku tą wartością możę być pusty string.

# it does not work :(
parameters:
  - name: firstName
    type: string
  - name: optionalSecondName
    type: string
    default: "" # it does not work :(

steps:
  - ${{ if eq(parameters.optionalSecondName, '') }}:
      - script: echo "Hello, ${{ parameters.firstName }}"
  - ${{ else }}:
      - script: echo "Hello, ${{ parameters.firstName }} ${{ parameters.optionalSecondName }}"

Niestety, zamiast takiej oczywistej składni, musimy kombinować z wpisaniem jakiegoś słowa kluczowego w polu-które-ma-być-opcjonalne:

# it does work, but :(/
parameters:
  - name: firstName
    type: string
  - name: optionalSecondName
    type: string
    default: "I DO NOT HAVE ONE"

steps:
  - ${{ if eq(parameters.optionalSecondName, 'I DO NOT HAVE ONE') }}:
      - script: echo "Hello, ${{ parameters.firstName }}"
  - ${{ else }}:
      - script: echo "Hello, ${{ parameters.firstName }} ${{ parameters.optionalSecondName }}"

Azure DevOps pipelines - tips & tricks (1)

Thu, 19 May 2022 00:00:00 GMT

Podstawową zasadą, którą wpaja się wszystkim młodym programistom, jest reguła reużywania kodu. Wiadomo - zamiast robić przeklęte ctrl+C i ctrl+V, lepiej jest zbudować reużywaną funkcję/moduł, dzięki czemu później zmianę wystarczy zrobić w jednym miejscu. Tę regułę można też zastosować do pipeline’ów YAML-owych w AzureDevops. W tym odcinku devopsowych tips & tricks, przyjrzymy się, jakie są opcje.

Template nesting

Pierwsza opcja to “zagnieżdżanie” szablonów, czyli “referencjonowanie” za pomocą template:

steps:
  - script: echo "Hello world"
  - template: ./nested-template.yml

Jest to podstawowa opcja, oczywiście możemy przekazać do takiego zagnieżdżonego szablonu parametry. Co ciekawe, szablon może znajdować się w innym repozytorium - wówczas musimy zdefiniować owo repozytorium jako zasób w sekcji resources i potem po nazwie zasobu odwołać się do szablonu, np. nested-template.yml@yaml-repo. Takie rozwiązanie nie wydaje się naturalne (raczej chcemy trzymać YAMLe pipeline’ów obok aplikacji), ale przy większych projektach i/lub organizacjach możemy mieć np. bazowe szablony dla wielu projektów/zespołów w oddzielnym repozytorium, którym opiekuje się dedykowany zespół.

Oficjlanie istnieją pewne ograniczenia ilości zagnieżdżeń oraz łącznego rozmiaru wszystkich YAMLów biorących udział w buildzie (zainteresowanych odsyłam do dokumentacji)- ale mnie się nie udało zderzyć ze ścianą. (Próbowałem dojść do limitu zagnieżdżeń.)

Pętle

Kolejną konstrukcją, którą adept programowania poznaje na wczesnym etapie, a którą też da się zastosować w pipeline’ach są pętle. Tutaj nie ma specjalnej filozofii: możemy iterować po listach. (Aczkolwiek de facto nie ma typu danych “lista” w Azure DevOps, no ale typy danych to może temat na oddzielny odcinek.) Przykładowo:

parameters:
  - name: characters
    type: object
    default:
      - Tytus de Zoo
      - Romek
      - A'Tomek

  - steps:
      - ${{ each character in parameters.characters }}:
          - script: echo "Hi, ${{ character }}"

Przy pisaniu trzeba tylko uważać na wcięcia i ważny dwukropek na końcu linijki, w której stosujemy słówko kluczowe each.

Matrix strategy

Bardziej wymyślną pętlą, zastosowaną na całym jobie i bardziej explicite wyrażoną jest owo matrix strategy. Zasada jest tu taka, że na poziomie joba określamy scenariusze jego uruchomienia, tzn. dla każdego scenariusza definiujemy wartość zmiennych, uzyskująć w ten sposób efekt podmiany ich wartości dla każdego scenariusza. Spójrzmy:

jobs:
  - job: MatrixSample
    strategy:
      matrix:
        v1:
          url: https://somwhere.com/old/api
        v2:
          url: https://somwhere.com/new/api

    steps:
      - bash: curl ${{ url }}

W powyższym przykładzie job wykona się dwa razy, dla scenarisuzy v1 i v2, które wykonają request dla starej i nowej wersji api. Oczywiście tutaj przykład wydumany, API powinno być wersjonowane explicite w URL czy w nagłówku, ale tak chyba lepiej widać, o co chodzi. Sam Microsoft w dokumentacji podaje przykład, że matrix strategy może być używane np. do uruchamiania testów na różnych platformach. O tym będzie, ale w innym odcinku. :)

Extend template

Ostatnia opcja to roszerzanie szablonów za pomocą słówka kluczowego extend. Jest do de facto dziedziczenie po innym szablonie. Może być przydatne w scenariuszu opisanym wyżej, czyli: bazowe szablony, wspólne dla wielu projektów, umieszczamy w innym repozytorium, a lokalnie dziedziczymy po nich i konstruujemy własne pipeline’y.

Jak działa to dziedziczenie? W podstawowej opcji, jest to po prostu odwołanie się do szablonu bazowego i przekazanie parametrów. Czyli prawie to samo, co zagnieżdżanie, tyle że robione na poziomie całego szablonu.

# base.yml
parameters:
  - name: yourName
    type: string

steps:
  - script: echo "Hello, ${{ parameters.yourName }}, I am base template".

# extending.yaml
extend: base.yml
  parameters:
  - yourName: Robert

Sam Microsoft w dokumentacji sugeruje, że ten mechanizm można wykorzystać jak prawdziwe “dziedziczenie”: skoro typem parametru może być lista stepów, to dlaczego nie zaprojektować bazowego szablonu tak, aby przyjmował taki opcjonalny parametr. W ten sposób możemy zaimplementować odpowiednik funkcji wirtualnej lub abstrakcyjnej - konstruktów z programowania obiektowego.

# base.yml
parameters:
  - name: yourName
    type: string
  - name: preSteps
    type: stepList
    default: [] # thanks to default value this is 'virtual'
  - name: postSteps
    type: stepList

steps:
  - ${{ each step in parameters.preSteps}}:
      - ${{ step }}
  - script: echo "Hello, ${{ parameters.yourName }}, I am base template".
  - ${{ each step in parameters.postSteps}}:
      - ${{ step }}

# extending.yaml
extend: base.yml
  parameters:
  - yourName: Robert
  - postSteps:
    - script: echo "Goodbye!"

Podsumowanie

Jak widać, przy głębszym poznaniu, AzureDevops oferują całkiem niezłe konstrukty do budowania zaawansowanych szablonów. Co więcej, dokumentacja jest całkiem nieźle napisana i zawiera przykłady. Z własnej praktyki mogę przyznać, że dotychczas “produkcyjnie” użyłem wszystkich wyżej wymienionych opcji, prócz matrix strategy - czyli nie są to tylko zabawki, ale realne pomoce, które warto mieć w swojej skrzynce narzędziowej.

Migracja danych do Comos DB

Mon, 09 Aug 2021 00:00:00 GMT

Całkiem niedawno temu zmagałem się z zadaniem polegającym na migracji pewnej ilości danych (przyjmijmy, że setki tysięcy dokumentów) do Cosmos DB, czyli Azure’owej bazy dokumentowej. Okazuje się, że strategia na “hurrra!” nie zadziała - jeśli będziemy wrzucać dokumenty jeden po drugim, po prostu przy którymś obrocie pętli, kod się nam wykrzaczy wyjątkiem. Co w takiej sytuacji należy zrobić?

Bulk SDK

W najprostszym podejściu, mając kolekcję danych (dokumentów) do wrzucenia do Cosmosa, możemy po prostu przeiterować po nich, dla każdego wywołując operację upsert. Łatwo się domyślić, że będzie to jednak niewydajne, zwłaszcza, że każda operacja będzie oddzielnym requestem. Na początku z pomocą przychodzi “bulk support”, wprowadzony w wersji 3.4.0 SDK. Gdy ustawimy AllowBulkExecution = true w CosmosClientOptions klient (stworzony z użyciem takiego obiektu opcji) będzie miał nową właściwość: będzie kolejkować ileś-tam pojedynczych upsertów w jeden request po sieci do Azure’a. A w kodzie - wystarczy, że odpalimy wszystkie upserty jako taski i poczekamy na wszystkie, jak w poniższym przykładzie:

List<Task> tasks = new List<Task>();
foreach (var itemToInsert in itemsToInsert)
{
    tasks.Add(container.UpsertItemAsync(itemToInsert, partitionKey));
}

await Task.WhenAll(tasks);

To robi dużą różnicę - cały proces przyspiesza, bo robimy po prostu mniej requestów sieciowych. Jak dokładnie to jest rozdzielane przez SDK i jaka jest pojemność “bufora”, tego autorzy nie SDK nie zdradzają. Jednakże taka zamiana z “dużo mały kroczków” na “mało wielkich kroków” (upraszczam, rzecz jasna) może być niewystarczająca. Niby o tym piszą w dokumentacji, ale nie zwrócłem na to uwagi na początku…

Zwiększ throughput

Bulk API generuje jednak dodatkowy problem - skoro szybciej pakujemy dane do chmury, to innymi słowy przystawiamy do Azure’a grubszą rurę. Tyle, że Cosmos DB to nie papier i wszystkiego nie przyjmie. Komunikacja z Cosmos DB jest bowiem ograniczona przez ustawiony na instancji throughput. Troughput (przepustowość) to ta magiczna wartość, liczona w jeszcze bardziej magicznej jednostce RU, za którą płacimy - a dokładniej: płacimy za rezerwację danej przepustowości. Troughput może być ustawiony na sztywno albo autoskalować się w pewnym przedziale. W drugiej opcji polega to na tym, że określamy maksymalną przepustowość, a chmura sama skaluje ją pomiędzy 10% a 100& maksymalnego limitu (dzięki temu w czasie mniejszego obciążenia można sporo zaoszczędzić). W skrócie zatem - jeśli odpalimy bulk API bez zmiany przepustowości, to jest bardzo prawdopodobne, że ona się wyczerpie (no chyba, że mamy ustawiony bardzo duży ten górny limit, no ale to ma sens tylko wtedy gdy mamy naprawdę ogromną amplitudę ruchu). Rozwiązaniem jest po prostu czasowe podniesienie tego limitu - ja się nie patyczkowałem i dałem x10. To oczywiście podbije nam koszty, bo w czasie migrowania danych, bulk API będzie starał się pakować, ile się da - a więc przy autoskalowaniu przepustowości na pewno zostanie ona podniesiona w stronę 100%, ale dzięki temu z jednej strony przyspieszymy cały proces, a z drugiej - unikniemy odrzuconych upsertów. Trzeba tylko wiedzieć, że sam proces podnoszenia górnego limitu przepustowości może trwać nawet godzinę (sic!) oraz pamiętać, żeby po całej operacji przywrócić wartość przepustowości - w przeciwnym wypadku będzie ona “wisieć” na za dużej wartości (przykładowo: jeśli mieliśmy dotychzas górny limit na 4000 RU, to przepustowość skalowała się między 400 a 4000 RU; jeśli zostawimy throughput na tymczasowej wartości np. x10, to zostaniemy na 4000-40000 RU, a więc najniższa wartość będzie taka, jak górny limit normalnego trybu…).

C# - historia (C# 8.0)

Tue, 20 Jul 2021 00:00:00 GMT

To jest kontynuacja przeglądu historii wersji C# (tu znajdziesz poprzedni artykuł).

Readonly members

Metoda w strukturze może być oznaczona jako readonly - w ten sposób oznaczamy ją jako “instance-agnostic”, czyli po pierwsze nie może ona zmieniać stanu struktury, a po drugie - każde odwołanie do elementów struktury (tylko odczyt), będzie skutkować ostrzeżeniem.

public struct WeatherMeasurement {
    public double Temperature {get; init;}

    public override readonly string ToString() => $"Temperature was {Temperature}."; // <-- TU BĘDZIE WARNING

    public readonly void ChangeTemperature(double newTemperature) => Temperature = newTemperature; // <-- TU BĘDZIE BŁĄD KOMPILACJI
}

Trzeba zapamiętać, że w przypadku “ostrzeżeniowym” kompilator pod spodem robi taki “myk”: tworzy kopię struktury i na tej kopii wywołuje tę metodę/właściwość. W ten sposób oryginalna instancja nie jest dotykana, ale to dodaje ukryty narzut.

P.S. Tego readonly nie można użyć dla metod klasy - tam działa tylko na polach.

Domyślne implementacje w interfejsach

Dotychczas interfejsy mogły mieć tylko same sygnatury metod/właściwości. Jeśli mieliśmy wiele implementacji interfejsu, ale jakiś wspólny kod, to trzeba było wprowadzać pomiędzy te implementacje a interfejs abstrakcyjną klasę “superbazową” i tam umieszczać tę wspólną logikę. Natomiast od C# 8.0 można to zrobić od razu w interfejsie, bez sztucznej pośredniej klasy bazowej. Na przykład:

public interface IOrder {
    decimal NetTotal {get;}
    decimal VatPercentage {get;}
    decimal GrossTotal => NetTotal * (1 + VatPercentage/100);
}

public class Order : IOrder {
    public decimal NetTotal {get;init;}
    public decimal VatPercentage {get;init;}
}

W tej sytuacji możemy korzystać z właściwości IOrder.GrossTotal, mimo że w klasie Order nie została ona zainicjalizowana. Ważne jest jednak to, że dostęp do niej mamy tylko, kiedy instancja klasy Order jest użyta w kontekście IOrder - inaczej nie będziemy mieli do niej dostępu. Porównaj:

IOrder order1 = new Order(){ NetTotal = 100, VatPercentage = 22};
Console.WriteLine(order1.GrossTotal); // <-- TU DZIAŁA

var order2 = new Order(){ NetTotal = 100, VatPercentage = 22};
Console.WriteLine(order2.GrossTotal); // <-- TO SIĘ NIE SKOMPILUJE

W drugim użyciu var jes tylko syntactic sugar - zmienna order2 jest typu Order.

Pattern matching w switchach

Pattern matching w połączeniu ze switch umożliwia bardzo zgrabny zapis:

public string GetFuelString(EngineType engineType) => engineType switch {
    EngineType.Diesel => "ON",
    EngineType.Petroleum => "95",
    EngineType.LPG => "LPG",
    _ => throw new ArgumentOutOfRangeException(message: "Unrecognized engine type", paramName: nameof(engineType))
};

Co więcej, można też “matchować” za pomocą warunków określonych na właściwościach, np.:

public bool HasDiscount(Customer customer) => customer switch {
    {IsVIP: true} => true,
    {Age: <18} => true,
    {Age: >65} => true,
    {FirstName: "Adam", LastName: "Małysz"} => true
    _ => false
};

W mocy pozostaje jednak ograniczenie switcha: porównywana wartość musi być stałą.

IAsyncEnumerable

O tym isałem w oddzielnym wpisie, więc odsyłam po szczegóły do niego.

Using bez klamerek

Mniej wcięć dzięki temu, że using może być “inline’owy” - kompilator sam “ogarnie”, że “scope” sięga do końca “aktualnego scope’u”.

public bool WriteToFile(){
    using var stream = new StreamWriter("file.txt");

    // <-- TU JESTEŚMY "WEWNĄTRZ" USINGA

    return true;
}

Operacje na indeksach

C# 8.0 zapewnia nam zgrabniejszy dostęp do fragmentów tablic i konkretnych pozycji, np.:

var weekdays = new[]{"Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday", "Sunday"};

var sunday = weekdays[^1];

var weekend1 = weekdays[5..7]; // <-- TO SAMO CO weekend2
var weekend2 = weekdays[^2..^0]; // <-- TO SAMO CO weekend1

Fajne, tylko czasem może być kłopotliwe - jak tutaj przy zmiennej weekend1: nie dość, że na dzień dobry jest mindfuck, bo piątek to 4, to jeszcze drugi koniec takiego przedziału nie wchodzi do niego (dlatego jest indeks 7, którego nie ma w tablicy), czyli przedział jest jednostronnie domknięty; ale z drugiej strony jak odliczamy indeksy od końca (przykład z weekend2), to zasada jest odwrotna.

C# - historia (C# 9.0)

Sat, 10 Jul 2021 00:00:00 GMT

Prześledźmy, jakie nowinki były wprowadzane w kolejnych wersjach C# (wybór) - w odwrotnie chronologicznej kolejności, najpierw wersja 9.0.

Rekordy

Skrótowa składnia dla klas, które jedynie przechowują dane. Innymi słowy - zamiast rozwlekłego:

public class Student {
    public string FirstName {get; private set;}
    public string LastName {get; private set;}

    public Student(string firstName, string lastName){
        FirstName = firstName;
        LastName = lastName;
    }
}

Możemy to zapisać tak:

public record Student(string FirstName, string LastName);

P.S. Zwróć uwagę na to, że zmienne w rekordzie są PascalCase - w ten sposób uzyskamy właściwości o “klasycznym” case’ingu. P.P.S. Rekordy mogą dziedziczyć tylko po rekordach - i na odwrót (tylko przez rekordy mogą być dziedziczone).

Init-only setters

W powyższym, pierwotnym, przykładzie ze studentem cały “myk” polegał na tym, żeby uniemożliwić modyfikację właściwości, tj. żeby nadać wartość tylko raz, podczas inicjalizacji obiektu. W tej chwili możemy jednak napisać w klasie Student metodę, która, już po zainicjalizowaniu obiektu, będzie modyfikować wartość którejś z właściwości. Oczywiście, można temu zapobiec - po prostu mieć pole oznaczone jako readonly, a właściwość tylko jako getter odczytujący z tegoż pola. To by było jednak już zupełnie rozwlekłe. Stąd w C# 9.0 wprowadzono nowe słowo kluczowe: init. Zobaczmy je w akcji:

public class Student {
    public string FirstName {get; init;}
    public string LastName {get; init;}

    public void ChangeFirstName(string firstName){
        FirstName = firstName; // <-- TO SIĘ NIE SKOMPILUJE!!!
    }
}

W ten sposób otrzymujemy klasę, która też jest podobna do rekordu - ale inicjalizujemy ją inaczej:

var student = new Student {
    FirstName = "John",
    LastName = "Smith"
};

student.FirstName = "Johnny"; // <-- TO SIĘ NIE SKOMPILUJE!!!

Po zainicjalizowaniu obiektu nie ma opcji, żeby zmienić wartość właściwości: czy to z zewnątrz, czy z wewnątrz klasy.

P.S. Oczywiście przykład z blokowaniem zmiany personaliów studenta może być mylący. W normalnym życiu przecież możliwa jest taka zmiana: od zwykłej omyłki na zmianie stanu cywilnego studenta kończąc. :)

Pomijanie typu przy słowie kluczowym `new`

W sytuacji, gdy kompilator potrafi domyślić się typu, wystarczy, że zawołamy samo new(), bez podawania typu, np. przy deklaracji pola:

private List<string> list = new();

Albo gdy przekazujemy parametr do metody:

public class Car{
public Car(Engine engine){}
}

public class Engine{
public bool IsDiesel {get; init;}
}

var dieselCar = new Car(new(){IsDiesel=true});

To może ułatwić życie przy późniejszych refaktoryzacjach - zwłaszcza wtedy, gdy dokonujemy nie zmiany nazwy klasy (to nam załatwią narzędzia dziś dostępne), ale gdy np. rozbijamy jakąś klasę na dwie: nie musimy ręcznie poprawiać wszystkich wywołań konstruktorów (o ile oczywiście nie zmienią się parametry…).

Podstawy architektury oprogramowania dla inżynierów #1 - parametry architektury

Mon, 14 Jun 2021 00:00:00 GMT

Parametry architektury

Parametry architektury spełniają trzy kryteria:

określają pozadziedzinowe względy projektowe,

wpływają na niektóre strukturalne aspekty projektu,

mają decydujące lub duże znaczenie dla działania aplikacji.

To cytat z M. Richardsa i N. Forda, autorów ksiązki Podstawy architektury oprogramowania dla inżynierów. Co rozumieją przez te mądrze brzmiące frazy? Rozbijmy to na części.

“Określają pozadziedzinowe względy projektowe”

W skrócie chodzi o to, że “zwykłe” wymagania określają, co aplikacja ma robić (np. wysyłać mejle). Natomiast są też takie wymogi, zwane czasami “wymaganiami niefunkcjonalnymi”, które nie określają wprost działania aplikacji, ale mówią o jej cechach, np. jaka jest spodziewana wydajność aplikacji.

“Wpływają na niektóre strukturalne aspekty projektu”

Wybór konkretnej zewnętrznej usługi, która będzie wysyłać mejle (np. SendGrid) nie rzutuje na projekt tak, że zmiana dostawcy wywraca całą architekturę do góry nogami. Jeśli jednak warunkiem jest audytowalność (np. ze względów prawnych), wówczas może to wpływać na cały projekt.

“Mają decydujące lub duże znaczenie dla działania aplikacji”

Innymi słowy - nie każde “wymaganie niefunkcjonalne” jest tak samo ważne w danej aplikacji. W systemie do streamowania rozgrywek piłkarskich wydajność można być szczególnie ważna, gdy tymczasem w systemie bankowym jedną z głównych cech będzie bezpieczeństwo. Parametrami architektury będą dla danej aplikacji te cechy, które są szczególnie istotne - niby każdy projekt powinien być bezpieczny, ale np. w bankowości będzie to szczególnie istotne.

Typologia parametrów architektury

Istnieją dwa rodzaje parametrów architektury - sprecyzowane i dorozumiane. To ważne wyszczególnienie, bo nie wszystkie parametry architektury muszą być spisane na papierze explicite jako “wymagania niefunkcjonalne_.

Lista parametrów architektury

Niepełna lista parametrów architektury (moje własne “tłumaczenia” na angielski, gdyż w książce są stosowane polskie terminy, które sieją zamęt):

availability - czyli dostępność w czasie (jaką część czasu system może być wyłączony z użycia),
continuity - zdolność do przywrócenia do działania po awarii (tego trochę nie rozumiem…),
performance - wydajność, czyli jakie obciążenie ma system przyjmować,
recoverability - jak szybko system ma wracać do działania po awarii oraz czy możemy sobie pozwolić na utratę danych,
reliability - czy w przypadku nieprawdiłowego działania firma będzie narażona na duże koszty?
durability ? - odporność na błędy, np. brak połączenia sieciowego,
scalability - skalowalność,
configurability - konfigurowalność,
extendability - czy to się nie zawiera w poprzednim?
setupability - instalowalność na różnych platformach,
reusability
localizability - wsparcie dla wielu języków i regionalnych formatów danych,
supportability - łatwość w utrzymaniu (czy to nie jest za ogólne? i czy chodzi o wsparcie oferowane użytkownikom/klientom?),
portability - możliwość działania na różnych platformach (np. zmiana bazy danych - ?),
updateability - łatwość aktualizowania wersji aplikacji
accessibility - a11y
archivability - inaczej retencja danych
authenticaton - uwierzytelnianie
authorization
legal requirements - czy są jakieś sepcjalne wymagania prawne (np. RODO)?
privacy - możliwość ukrywania danych przed wewnętrznymi pracownikami firmy (np. dział IT w banku nie może zajrzeć Ci wprost na konto),
safety - bezpieczeństwo rozumiane jako zapobieganie przed nieautoryzowanym dostępem np. przez szyfrowanie danych,
usability - użyteczność

Lista jest długa, mnie dziwi obecność niektórych cech, które bardziej bym przypisał już do poziomu konkrentego rozwiązania technicznego, a nie do poziomu architektury (trudno mi wyobrazić sobie jak dostępność dla osób z niepełnosprawnościami miałaby wpływać znacząco na architekturą) - ale trzeba przyznać, że jest w miarę wyczerpująca.

P.S. Wpis jest częścią cyklu, będącego serią notatek z lektury książki pt. Podstawy architektury oprogramowania dla inżynierów, autorstwa Marka Richardsa i Neala Forda.

Mikroserwisy: rodzaje zdarzeń

Tue, 01 Jun 2021 00:00:00 GMT

Termin zdarzenie ma w programowaniu wiele znaczeń. Kiedyś mógł być kojarzony głównie z UI - wydarzenia (eventy ;) ) dotyczyły interakcji użytkownikiem, np. kliknięcia przeń w dany przycisk. W świecie mikroserwisów, DDD itp. - to znaczenie jednak się zmieniło (a może rozszerzyło). Dziś tych zakresów znaczeniowych jest więcej, mogą się one mieszać i nie zawsze wiadomo, o jaki rodzaj eventu chodzi. Na przykładzie projektu, w którym pracowałem, a który był oparty o “referencyjną” architekturę eShopOnConatiners (czyli Microsoftowego przykładu rozwiązania mikroserwisowo-kontenerowego) - będę chciał pokazać typologię różnych znaczeń terminu zdarzenie.

Zdarzenie w ramach encji

Gdy stosujemy event sourcing, to w zasadzie wszelkie zmiany stanu domeny dzieją się za pomocą zdarzeń. Gdy zamówienie zostało złożone (OrderWasCreated), gdy zamówienie zostało opłacone (OrderWasPaid), gdy zamówienie zostało anulowane (OrderWasCancelled) i tak dalej. Te wydarzenia w zasadzie mapują się na wydarzenia, które możemy rozpoznać podczas sesji event stormingu. One też są zapisywane w event store. O ile dobrze przejrzałem projekt eShopOnContainers, nie ma tam takich zdarzeń, jednak spotkałem się z takim rozwiązaniem właśnie w przypadku serwisu implementującego event sourcing.

Zdarzenia domenowe

Jeśli stosujemy event sourcing, być może to rozróżnienia na zdarzenia “wewnątrz encji” i “domenowe” wydaje się bez sensu, ale w przypadku modelowania DDD, ale bez event sourcingu, nie będziemy mieć tych pierwszych, ale te drugie - już tak. Otóż, gdy zachodzi potrzeba reakcji jednego agregatu na zmianę w drugim agregacie - wówczas możemy posłużyć się takim zdarzeniem domenowym. W tym przykładowym repozytorium eShopOnConatiners reprezentowane są one przez klasy z sufiksem -DomainEvent. Ich rolą jest “komunikacja” pomiędzy agregatami. Być może słowo “komunikacja” nie jest precyzyjne, gdyż mamy tu do czynienia raczej ze schematem producent oraz potencjalnie wielu konsumentów. Kiedy takie zdarzenie może być potrzebne? Jak wiadomo, agregaty nie mają możliwości wprost wywoływania swoich metod - byłyby wówczas ze sobą powiązane. Jeśli mamy np. skompilkowaną strukturę zarządzania magazynu, gdzie dostawa wymaga obsługi zarówno przez agregat Warehouse (np. ulokowanie paczki w odpowiednim miejscu fizycznego magazynu), ale też poinformowania agregatu StockProduct o zwiększeniu ilości stanu magazynowego - wówczas z agregatu Warehouse możemy wywołać wydarzenie ProductReceived, który będzie obsłużony przez inny agregat. W praktyce przykładu eShopOnContainers wygląda to tak, że każdy agregar zawiera kolekcję “wydarzeń do opublikowania”, które jest “opróżniana” podczas zapisywania encji. Opróżnianie polega zaś na wysłaniu tych wydarzeń do mediatora, co z kolei wymaga napisania handlera dla takiego wydarzenia, w którym możemy zawołać metodę z innego agregatu. W efekcie uzyskujemy też to, że cała operacja jest wykonywana w transakcji (a przynajmniej może być) - ma to swój plus, gdyż nie ma możliwości, żeby takie wydarzenie gdzieś utknęło (dostawa dotarła do magazynu, ale nie został zwiększony stan magazynowy), ale z drugiej strony - błędy w handlerach powodują, że nie można wykonać “pierwotnej” operacji (z powodu wyjątku).

Zdarzenia integracyjne

eShopOnContainers operuje też trzecim typem wydarzeń - patrz klasy z sufiksem -IntegrationEvents. To są zdarzenia, które służą do poinformowania innych mikroserwisów o - nomen omen - wydarzeniach w ramach pojedynczego serwisu. Przykładowo, gdy użytkownik został oznaczony jako “oszust”, serwis Users powinien poinformować o tym inne serwisy: na przykład serwis Orders może anulować wszystkie jego zamówienia i wstrzymać wysyłkę produktów. W tym przykładowy repo jest to realizowane za pomocą Service Bus: serwisy “wrzucają” wydarzenia integracyjne na odpowiednie “tematy” na szynie, natomiast inne serwisy, zainteresowane danymi wydarzeniami, zawczasu subskrybują się na nie i zapewniają swój kod do obsługi takiego wydarzenia.

AzureDevops pipeline + semantic versioning = da się?

Sat, 20 Mar 2021 00:00:00 GMT

Jak ustawić zmienną środowiskową w Azure DevOps pipeline?

Tue, 12 Jan 2021 00:00:00 GMT

Problem

Mam pipline w Azure DevOps, a w nim - jakś zmienną. Chcę wartość tej zmiennej “wepchnąć” do zmiennej środowiskowej - tak aby jakieś kolejne kroki mogły z niej skorzystać. (Przyjmijmy, że tę wartość mogę przekazać tylko przez environment variable - a nie przez bezpośrednie odwołanie do “pajplajnowej” zmiennej w danym kroku.)

Rozwiązanie nr 1 (nie działa :( )

Szybki risercz internetów i sklecam takie coś:

- variables:
  myVariable: abc

- steps:
    - script: echo "##vso[task.setvariable variable=sauce.userName;issecret=true]$(myVariable)"
# other steps

Efekt? Do zmiennej trafiła wartość następująca: abc" (tak, z cudzysłowem na końcu…). Facepalm. Nie szło to nijak ominąć - usunięcie w ogóle cudzysłowów, powodowało, że ##vso... było traktowane jak komentarz w YAML-u (a więc odpalane było samo echo…), jakieś podmianki cudzysłowów na pojdyncze/podwójne - to samo.

Rozwiązanie nr 2 - działające!

Rozwiązaniem była przesiadka na PowerShella. Co ważne - reszta kroków może pozostać bez zmian (nie musimy innych kroków zmieniać na PowerShella). Takie krok wygląda wówczas następująco:

- task: PowerShell@2
  inputs:
    targetType: 'inline'
    script: |
      Write-Host "##vso[task.setvariable variable=SAUCE_USERNAME;]$(sauceUserName)"

Upierdliwe, nieprawdaż?

Print to file w C# na Windows 10

Thu, 07 Jan 2021 00:00:00 GMT

Jeśli zdarzy Ci się konieczność drukowania czegoś z C# za pomocą bibliotecznej klasy System.Drawing.Printing.PrintDocument - i będziesz chciał wydrukować coś do pliku (do PDFa), to wiedz, że musisz dodać jedną ważną linijkę. A mianowicie - podać PrinterName w PrinterSettings:

printDocument.PrinterSettings.PrinterName = "Microsoft Print to PDF";

Jeśli tego nie zrobisz, a będziesz drukował do pliku (czyli ustawisz PrintToFile na true), to plik co prawda się stworzy, ale będzie jakiś taki corrupted i przeglądarka PDFów nie będzie chciała go otworzyć. Taki przynajmniej miałem efekt na Windowsie 10.

Finalnie całość konfiguracji wyglądałaby tak:

var printDocument = new PrintDocument();

printDocument.PrinterSettings.PrinterName = "Microsoft Print to PDF";
printDocument.PrinterSettings.PrintToFile = true;
printDocument.PrinterSettings.PrintFileName = @"some\path\to\file.pdf";

SignalR + Azure + mikroserwisy = ? (cz.1)

Sun, 03 Jan 2021 00:00:00 GMT

Mamy następuje dramatis personae: mikroserwisowe środowisko w chmurze Azure, n aplikacji klienckich. Mamy nowy feature: chcemy, aby chmura sama informowała klienty o jakiejś zmianie - pojedynczego klienta lub całą ich grupę. Załóżmy, że klientami nie są aplikacje mobilne, więc push notifications odpadają. Chcemy to ograć za pomocą SignalR. Ale jak to zrobić na Azure?

SignalR na Azure

Azure udostępnia usługę pod nazwą Azure SignalR Service. Co ona nam oferuje, skoro SignalR zawsze mogliśmy sobie “postawić” na zwykłej aplikacji ASP.NET? W największym skrócie - umożliwia spięcie SignalR także z “nietypowymi” bytami takimi jak Azure Functions oraz załatwia za nas problemy ze skalowaniem. W zależności od tego, jaką konfigurację chcemy mieć (o tym niżej), możemy uruchomić tę usługę w trybie Default lub Serverless.

Tryb Default

To jest “klasyczne” SignalR, gdzie Azure SignalR Service (dalej ASS) pełni rolę proxy pomiędzy klientami a “hub serverem”, czyli aplikacją webową, na której “stawiamy” SignalR (analogicznie, jakbyśmy stawiali je w zwykłej aplikacji ASP.NET, z tym, że potrzebujemy innych nugetów). Wówczas komunikacja wygląda tak, że klienty połączone są z ASS websocketem (oczywiście, o ile dany klient wspiera websockety, no ale to wiadomo z samej natury SignalR), a także nasz “hub server” jest jest połączony kilkoma websocketami z ASS.

Do zaimplementowania mamy wówczas jedynie klasę “huba” (czyli właściwą “logikę” komunikacji) oraz kilka linijek konfiguracji w Startup.cs. To dołączone nugety zajmują się tym, żeby wystawić endpoint /negotiate, do którego uderzają klienty. Ten endpoint zwraca im już url (i token) bezpośrednio do ASS, z którym następuje połączenie websocketowe. To ważna uwaga, ponieważ Azure API Management nie wspiera socketów - więc to właściwie jedyne rozwiązanie: nasz “schowany” za gatewayem serwis wystawia tylko /negotiate, a reszta komunikacji idzie niejako z pominięciem gatewaya.

Jeśli chodzi o pricing - to w tym układzie płacimy za każdą wiadomość, która wychodzi z ASS. A zatem - jeśli to “hub serwer” sam z siebie coś wysyła, to płacimy tylko za ilość wiadomości do klientów; gdy jednak do klient coś śle do “hub serwera”, to musimy zapłacić też za wiadomość wysłaną z ASS do tegoż “hub serwera”. Zatem takie “echo” od klienta to w zasadzie dwie płatne wiadomości - z ASS do huba i potem (już odpowiedź) z ASS do klienta. Tak przynajmniej zrozumiałem to, co opisane jest w dokumentacji.

Tryb Serverless

A co z sytuacją, gdy naszym “hubem” ma być Azure Function? I to już nieważne, w którą stronę idzie komunikacja: od klientów czy do klientów. Problemem jest to, że funkcja nie będzie miec stałego połączenia z ASS. W tej sytuacji setup jest taki, że potrzebujemy w zasadzie dwóch funkcji:

tej, która wystawia endpoint /negotiate
oraz co najmniej drugiej do obsługi wiadomości.

Chodzi o to, że analogicznie, jak w scenariuszu Default, musimy wystawić dla klientów endpoint HTTP /negotiate, który będzie działać tak samo, jak wyżej: zwróci url do ASS oraz token. Możemy to ograć zwykłą funkcją triggerowaną przez żądanie HTTP.

Druga funkcja potrzebna jest natomiast do samej obsługi komunikatów. W zależności, w którą stronę ma ona działać, możemy mieć albo trigger HTTP (coś w stylu callbacku dla ASS, pod który ów będzie pukał, gdy klient wysyła wiadomość do huba), albo jakiś tam dowolny trigger typu kolejka lub cokolwiek, jeśli chcemy sami pchać wiadomości do klientów.

Jedną i drugą funckję “ogrywamy” odpowiednim nugetem + atrybutami, które wstrzykują do funkcji klasy, które umożliwiają albo dostęp do konfiguracji, albo komunikację z klientami.

To be continued…

Jak to wszystko się ma do mikroserwisów - o tym w części drugiej. :)

7 porad dla każdego, kto robi coś po godzinach

Tue, 22 Dec 2020 00:00:00 GMT

Zapiski do tego aryktułu z bloga Stack Overflow.

1. Wybierz proste zdanie

Nie celuj zbyt wysoko - niech Twoim celem będzie proste zadanie. Dlaczego? Bo i tak natrafisz na różnorodne problemy, które skomplikują to proste zadanie.

2. Nie wynajduj koła na nowo

Jeśli natrafisz na jakiś problem - znajdź gotowe rozwiązanie: Google, StackOverflow itd. Jakaś trudna konfiguracja środowiska/biblioteki? Na pewno ktoś to opisał i możesz skorzystać z gotowca. (Nie próbuj konfigurować Webpacka samemu. ;))

3. Postaraj się mieć coś działającego jak najszybciej

To po prostu będzie Cię motywować. Wyobraź sobie, że tworzysz grę: nie skupiaj się na dopieszczonej grafice czy wielu rozgałęzieniach rozgrywki na starcie; lepiej, jak uda Ci się stworzyć całą rozgrywkę (user journey ;) ), nawet w najprostszej szacie graficznej. Poczucie, że “to działa” doda Ci motywacji.

4. Będą trudności i problemy - to przyjmij za pewnik

Na pewno będą jakieś trudności i problemy. W końcu często w takim hobby project na warsztat bierzesz coś, z czym nie masz do czynienia na co dzień. Ale gdy w końcu przebrniesz przez te trudności, będziesz miał poczucie zwycięstwa. No i bezcenne doświadczenie.

5. Opublikuj swoją working beta

Gdy uda Ci się dojść do momentu “działającej wersji beta” - upublicznij to. Wyślij znajomym, wrzuć na swojego bloga, Twittera, cokolwiek. Dzięki temu masz szansę otrzymać jakąś informację zwrotną (że coś nie działa, że to jest fajne itp.) oraz zdobędziesz motywację do dalszej pracy.

6. Nie rób przerwy

Chodzi o to, że większość side projects umiera dlatego, że w pewnym momencie odkładamy je naprawdę na bok - niby tylko na chwilę: bo tydzień wakacji, bo akurat-coś-ważnego - ale w rezultacie do tego nie wracamy. I zostajemy z takim rozgrzebanym czymś, do czego potem trudno wrócić: bo nie pamiętamy, na czym skończyliśmy, bo już ten pomysł nie wydaje się taki nęcący i wspaniały itp. Rada jest taka, żeby w jednym batchu (oczywiście to nie znaczy: za jednym “posiedzeniem”) zrobić wersję działającą (no, powiedzmy, przynajmniej działającą betę).

7. Enjoy the process

Jeśli side project robisz z przyjemnością i okoliczności są sprzyjające: bo puściłeś sobie do tego ulubioną muzę, bo na jego potrzeby kupiłeś jakiś szalony gadżet, bo robisz go z przyjaciółmi - to wówczas możesz liczyć na prawdziwy fun.

IAsyncEnumerable - to jest dobre!

Mon, 14 Dec 2020 00:00:00 GMT

C# 8 wprowadził pewną nowinkę - IAsyncEnumerable. Co prawda na horyzoncie jest już C# 9, ale jakoś ta nowinka z poprzedniej wersji jakoś nie trafiła pod strzechy - a może być w pewnych sytuacjach bardzo przydatna.

W największym skrócie IAsyncEnumerable umożliwia korzystanie z yield return w metodach oznaczonych słowem kluczowym async - wcześniej nie było to możliwe. Ktoś powie: “zaraz, zaraz - przecież dotychczas mogłem napisać sygnaturę metody w stylu async Task<IEnumerable<SomeType>>, co nie?“. To prawda - ale taka sygnatura oznaczała, że asynchronicznie zwracamy enumerację, jednak już samo enumerowanie asynchroniczne nie jest. Tymczasem IAsyncEnumerable to coś więcej - to asynchroniczne enumerowanie, to znaczy: każdy “krok” enumeracji jest asynchroniczny. Co to oznacza? Na poniższym przykładzie można zobaczyć różnicę. Mamy dwa podejścia do wybrania pierwszego elementu z “asynchronicznej enumeracji” - z Task<IEnumerable<int>> oraz IAsyncEnumerable<int>. Jaki jest wynik na konsoli?


public static class TestRun
{
    static async Task Run()
    {
        var test = new Test();
        Console.WriteLine("Task<IEnumerable<int>>:");
        (await test.DoWithIEnumerable()).FirstOrDefault();

        Console.WriteLine("\nIAsyncEnumerable<int>:");
        await test.DoWithIAsyncEnumerable().FirstOrDefaultAsync();
    }

    public class Test
    {
        private int[] numbers = new[] { 2, 4, 8, 16, 32 };
        public async Task<IEnumerable<int>> DoWithIEnumerable()
        {
            var result = new List<int>();
            foreach(var number in numbers)
            {
                var item = await ReturnWithDelay(number);
                result.Add(item);
            }
            return result;
        }
        public async IAsyncEnumerable<int> DoWithIAsyncEnumerable()
        {
            foreach (var number in numbers)
            {
                var item = await ReturnWithDelay(number);
                yield return item;
            }
        }
        private Task<int> ReturnWithDelay(int x)
        {
            return Task.Run(() =>
            {
                Console.WriteLine($"Waiting 2 seconds before returning... {x}");
                Task.Delay(2000);
                return x;
            });
        }
    }
}

Wyjście:

Task<IEnumerable<int>>:
Waiting 2 seconds before returning... 2
Waiting 2 seconds before returning... 4
Waiting 2 seconds before returning... 8
Waiting 2 seconds before returning... 16
Waiting 2 seconds before returning... 32

IAsyncEnumerable<int>:
Waiting 2 seconds before returning... 2

Widzicie różnicę? W przypadku Task<IEnumerable<int>> musimy de facto najpierw asynchronicznie zbudować całą naszą kolekcję, aby ją zwrócić klientowi. Co z tego, że klient chce tylko pierwszy element, my i tak musimy zbudować całość. Tymczasem w IAsyncEnumerable enumerujemy tak, jak w “klasycznym” IEnumerable: jeśli caller chce tylko jeden element, to “napracujemy” się tylko nad wybraniem tego jednego elementu.

Przykład jest dosyć sztuczny, nasuwa się zatem pytanie, kiedy takie coś możne nam się przydać. Otóż, dobrym przykładem (sam ostatnio używałem w takiej sytuacji IAsyncEnumerable) jest wyciąganie listy dokumentów z Cosmos DB: ze względu na charakterystykę komunikacji z Cosmosem, de facto takiej listy nie dostaniemy jednym zapytaniem do bazy. Cosmos niejako “paginuje” (“porcjuje”) wyniki - czasem potrzeba kilku strzałów do Cosmosa, aby wybrać wyszystkie dokumenty z listy. A każdy taki strzał jest asynchroniczny. Widzimy więc od razu, że w przypadku, gdy caller potrzebuje tylko podzbioru wyników (w skrajnym przypadku - chce woła tylko FirstOrDefault), nie musimy robić wszystkich zapytań do Cosmosa, by wpierw zbudować całą listę wynikową.

Zatem wszędzie tam, gdzie budowanie enumeracji jest asynchroniczne - możemy zyskać stosując IAsyncEnumerable. Dzięki temu unikamy “ukrytego kosztu”: gdy metoda przedstawia się jako Task<IEnumerable<T>>, to nie wiemy (bez zaglądania do jej implementacji), co jest tak naprawdę asynchroniczne w budowaniu takiej enumeracji: czy każdy krok wymaga asynchronicznej operacji, czy może tylko jakiś krok wstępny/przygotowawczy. Natomiast przy IAsyncEnumerable jest to przejrzyste dla konsumenta naszej metody.

Na koniec - dwie sprawy, na które należy zwrócić uwagę:

po pierwsze - IAsyncEnumerable jest “awaitowalne”, czyli - jak w przykładzie powyżej - nie trzeba już go “opakowywać” w Task<...>,
jeśli chcemy coś wyciągnąć z IAsyncEnumerable za pomocą LINQ-owych metod, to musimy doinstalować NuGeta System.Linq.Async i korzystać z asyncowych odpowiedników - np. FirstOrDefaultAsync.

Learn in public

Sat, 12 Dec 2020 00:00:00 GMT

Gdy następnym razem będziesz się czegoś uczyć, zrób tak: upublicznij swój proces uczenia. Niech to będą wpisy na blogu, jakieś nagrywane filmiki albo nawet upublicznione notatki. Spróbuję Cię przekonać, że warto!

bo najlepiej nauczysz się, jeśli zaczniesz uczyć kogoś

bo to nic nie kosztuje i po co zazdrośnie chronić np. swoje notatki

bo świadomość publicznego “raportowania” postępów motywuje

bo “oddajesz” społeczności to, co wziąłeś od innych

Identtyfikacja przeglądarki, czyli jak działają paywalle

Mon, 23 Nov 2020 00:00:00 GMT

…

Śmierć Moment.js

Mon, 09 Nov 2020 00:00:00 GMT

We wrześniu autorzy biblioteki Moment.js ogłosili, że kończą prace nad tym projektem. Od teraz będą jedynie poprawiać oczywiste błędy, natomiast nie będą dodawane nowe funkcje. Dlaczego i co to oznacza, jeśli w jakimś swoim projekcie używam Moment.js?

Po pierwsze - dlaczego. Głównym zarzutem wobec biblioteki jest jej rozmiar. Nie za bardzo poddaje się ona procesowi tree shakingu, który jest używany podczas budowania aplikacji frontendowych np. za pomocą Webpacka, polegający na odrzucaniu tego kodu, który nie jest używany w aplikacji. W efekcie na dzień dobry, dodając zależność do Moment.js, finalny bundle powiększa się o ca 250 kB. Sporo. Problem został już zauważony dawno, powstały alternatywne biblioteki, które są kilku- lub wręcz kilkudziesięciokrotnie “lżejsze” (tutaj znajdziesz dobrą rozpiskę alternatywnych bibliotek).

Po drugie - co robić, jak żyć, jeśli używam Moment.js? Sami autorzy biblioteki przyznają, że jest kilka powodów, dla których nie trzeba od razu rzucać się na wymianę Moment.js na coś innego, m.in. gdy:

jeśli znasz tylko/głównie API Moment.js, to gwałtowna zmiana na inną bibliotekę może być trudna (a i projekt z dużą ilością odwołań do Moment.js może być trudny do szybkiego przepisania),
jeśli musisz wspierać stare przeglądarki (Moment.js wspiera IE8, czego nie można powiedzieć np. o Luxonie),
jeśli inne biblioteki w Twoim projekcie mają zależność od Moment.js - co z tego, że sam przesiądziesz się na co innego, skoro i tak ta inna biblioteka dociągnie Ci całego Momenta? Jeśli chcesz rozważyć alternatywy, to na horyzoncie są m.in.:
Luxon,
Day.js,
date-fns.

Jeśli chodzi o przyszłość, to być może kiedyś w ogóle nie będą potrzebne te biblioteki - jest otwarta propozycja dodania do standardu ECMA globalnej klasy, na wzór Math, która nazywałaby się Temporal i obsługiwałaby całą problematykę dat, czasu i stref czasowych. Pewnie przyjdzie nam na to jeszcze poczekać, ale warto śledzić ten wątek. Moim zdaniem można sparafrazować znane powiedzenie, że najtrudniejsze w programowaniu jest nazywanie zmiennych i unieważnianie cache’a; ja bym dodał: obsługa dat/czasu.

Code Coverage w .NET Core

Mon, 02 Nov 2020 00:00:00 GMT

Code coverage to miara pokrycia kodu testami. Innymi słowy: procentowy wskaźnik, jaka część naszego kodu jest “otestowana”. To narzędzie może nam posłużyć w rozpoznaniu na niższym poziomie projektów lub modułów, które obszary są zabezpieczone testami, a w których ich brakuje. Czasami też - niestety - jakieś wymogi formalne przetargu lub zamówienia mogą wymuszać określony poziom pokrycia testami. Napisałem niestety, bo pojedyncza liczba lub liczba per moduł/projekt, komuś z zewnątrz projektu niewiele powie. Chyba lepiej mieć pokryty testami kod biznesowy, kluczowy, a nie np. jakąś pomocniczą bibliotekę; tymczasem “gołe” liczby mogą sprawić, że jest to równoważne. Co więcej, można też oszukać narzędzie do code coverage pisząc testy… bez asercji: testy się nie wysypią, a na pewno uruchomią kod…

Wracając jednak do korzyści dla zespołu programistów, można skorzystać z code coverage zarówno w nowym, jak i istniejącym projekcie. Ta miara powinna być traktowana raczej “relatywnie”, trochę tak, jak “dług techniczny”, obliczany przez takie narzędzia jak Sonar. Chodzi o to, że pewnie trudno albo w ogóle bez niepotrzebnie byłoby po prostu dążyć do 100% pokrycia testami. Jednakże, jeśli w kolejnych iteracjach ten wskaźnik spada, to może oznaczać, że po prostu piszemy za mało testów (lub nie piszemy ich wcale) dla nowego kodu. A to byłoby bardzo złe. Podobnie z sytuacją istniejącego projektu - nawet jednorazowe uruchomienie code coverage na początku pozwala ocenić, jak dużo jest testów i jakiej są one “jakości”.

…

Ciekawostki Typescript #4 - typowanie strukturalne

Wed, 28 Oct 2020 00:00:00 GMT

Jesteśmy przyzwyczajeni, że JS jest liberalny, dzięki stosowanemu przezeń typowaniu kaczemu (“jeśli coś chodzi jak kaczka i kwacze jak kaczka…”). Innymi słowy - póki nazwy pól się zgadzają, możemy obiekty stosować wymiennie:

const dog = {
  name: "Rex",
  age: 3,
  breed: "German shepherd",
}

const cat = {
  name: "Filemon",
  age: 1,
}

const sayLoveTo = ({ name }) => {
  console.log(`I love you, ${name}!`)
}

sayLoveTo(dog)
sayLoveTo(cat)

Gdy jednak do tego wszystkiego dodamy typy, sprawy się komplikują - wydawać by się mogło, że obikety dog i cat (jeśli są różnych typów, np. Dog i Cat) muszą mieć wspólny typ bazowy, żeby można było je przekazać do metody. Okazuje się jednak - że nie:

interface Dog {
  name: string
  age: number
  breed: string
}

interface Cat {
  name: string
  age: number
}

interface SomeoneToLove {
  name: string
}

const sayLoveTo = (someone: SomeoneToLove): string => {
  console.log(`I love you, ${someone.name}!`)
}

Jak widać, nie ma żadnej relacji pomiędzy typami Dog, Cat i SomeoneToLove - i właśnie nie musi być! Wszak TS idzie to w ślad (i musi iść) JS, de facto stosując typowanie kacze.

Taka cecha języka może być niespodzianką i czasami prowadzić do pułapek, ale z drugiej strony w wielu miejscach ułatawia pisanie, na przykład w testach jednostkowych.

Ten wpis jest częścią serii o TypeScripcie, inspirowaną lekturą książki D. Vanderkama pt. “TypeScript. Skuteczne programowanie”.

Ciekawostki Typescript #3 - z API może przyjść wszystko

Wed, 14 Oct 2020 00:00:00 GMT

Gdy piszemy w C# kod, który operuje na zdeserializowanym JSON-ie czujemy się pewnie: jeśli coś uda się zdeserializować do zdefiniowanego przez nas typu, to znaczy, że obiket jest poprawny i możemy normalnie na nim pracować. Początkującego programistę TyepScript może jednak zaskoczyć fakt - mimo że w zasadzie oczywisty, jeśli chwilę pomyśleć - iż jeśli “deserializujemy” (cudzysłowy intencjonalnie) coś w JSON-a do obiektu w TS, to możemy dostać “pod spodem” niepoprawne dane. Spójrzmy na przykład.

const json = '{ "firstName": 12 }';
interface Person {
  firstName: string;
}

const person: Person = JSON.parse(json);

console.log(`Hello, ${person.firstName.toUpperCase()}`;

Ten kod będzie poprawny w TS, ale w runtime wywali nam się z błędem: person.firstName.toUpperCase(). “Jak to?”, pomyślicie - “Przecież TypeScript miał sprawdzać typy!“. No, sprawdza, ale to już jest nasza odpowiedzialność, że to, co przychodzi z JSON.parse, chcemy traktować jako typ Person. Oczywiście ten przykład jest naciągany, ale łatwo w to “wdepnąć”, np. gdy korzystamy z biblioteki do wykonywania requestów, np. axios - wówczas ta linijka JSON.parse jest ukryta przed naszymi oczyma, ale ona tam w środku jest. Jeśli więc oczekujemy, że w odpowiedzi na request dostaniemy obiekt typu Person, to API może - wskutek błędu - spłatać figla i wstawić number zamiast stringa. Dowiemy się o tym niestety dopiero w runtime i nie mamy możliwości “deserializacji ze sprawdzeniem typu” - bo przecież informacji o typie już w runtime nie mamy.

Oczywiście wniosek z tego nie jest taki, żeby teraz wszystko sprawdzać: czy string jest stringiem itp. Wyczulam raczej na sytuacje w czasie developmentu, kiedy mogą nam się zdarzać rozjazdy pomiędzy deklaracjami typów, a tym, co zwraca nam np. API - zamiast wyrywać sobie włosy, zastanawiając się, dlaczego zamiast stringa mamy liczbę, sprawdźmy, czy nie jesteśmy ofiarami takiego błędnego założenia, że TS nam będzie typów strzegł także w czasie wykonywania.

Ten wpis jest częścią serii o TypeScripcie, inspirowaną lekturą książki D. Vanderkama pt. “TypeScript. Skuteczne programowanie”.

Koniec darmowego open source, czyli IdentityServer będzie płatny

Thu, 08 Oct 2020 00:00:00 GMT

Kilka dni temu twórcy popularnej biblioteki (frameworka?) IdentitySever ogłosili, że “komercjalizują” projekt, tzn. zakładają własną firmę - Duende Software - i że będą IdentityServer sprzedawać jako produkt. Za pieniądze.

W zasadzie nie powinno to nikogo dziwić: skoro ktoś stworzył bardzo popularny produkt, który rozdawał ludziom za darmo, a więc przy jego rozwijaniu pracował pro bono, to racjonalną decyzją staje się w pewnym momencie monetyzacja projektu; innymi słowy: odcięcie kuponów od istniejącej bazy użytkowników/klientów. Ta sprawa jednak po raz kolejny pokazuje, że jest problem z pieniędzmi w open source: zresztą Dominick Baier, współtwórca IdentityServer, sam opisuje jak razem z drugim autorem bibioteki, Brockiem Allenem, próbowali znaleźć finansowanie dla projektu, który stawał się ich pełnoetatową pracą. Najpierw finansowali pracę przy IdentityServerze z przychodów, które uzyskiwali jako trenerzy/konsultanci, pomagający przy jego wdrożeniu. Model bardzo przejrzysty: z biblioteki mogą korzystać wszyscy za darmo, ale jeśli chcesz mieć “autograf” autora, zapłać ekstra. Potem, próbowali oprzeć się na sponsorach: organizacjach lub indywidualnych darczyńcach, ale to okazało się niewypałem: przychody na tym polu wynosiły średnio kilka tysięcy dolarów rocznie. Żadna wielka firma nie była chętna wprost przyjąć ich pod swe skrzydła - co by mogło zapewnić stabilne finansowanie i rozwój projektu - ostatecznie podjęli decyzję o tym, żeby otworzyć firmę i po prostu sprzedawać IdentityServer - przy okazji przemianowany na Duende IdentityServer - jako zwykłe oprogramowanie za pieniądze.

Dla mnie ta historia pokazuje, że open source będzie jeszcze bardziej dryfował w kierunku podzielenia się na drobne projekciki tworzone przez entuzjastów oraz wielkie projekty, za którym stoją firmy (i pieniądze). Być może tak było już wcześniej, ale chyba to będzie się nasilać. Zagadkowy pozostaje jedynie sam moment przejścia od projektu hobbystycznego do stadium komercyjnego. Co z osobami, które nie są głównymi autorami biblioteki, a też pomagały współtworzyć projekt, cały czas pracując pro bono? W przypadku IdentityServera jest kilka takich osób (wystarczy zajrzeć tutaj: [https://github.com/IdentityServer/IdentityServer4/graphs/contributors]) - czy one nie poczują się wykorzystane, bo z jednej strony pomagały tworzyć darmowy projekt, który służył milionom, ale jednak przy okazji ktoś zacznie wprost zarabiać na ich pracy? I właściwie kto powinien mieć głos decydujący, co się dzieje z daną biblioteką - oryginalny autor, aktualny maintainer, osoba, która najwięcej wcommitowała? (To nie jest problem w przypadku IdentityServera, przytłaczająca część pracy została wykonana przez Baiera i Allena, ale w innych projektach już nie musi tak to wyglądać.)

Wracając z tych górnolotnych dywagacji na ziemię, pozostaje pytanie: jak żyć, jeśli w projekcie używam IdentityServera? Autorzy dają jeszcze 2 lata na wspieranie obecnej opensource’owej wersji, więc nie potrzeba gwałtownych ruchów. Na pewno jednak należy zastanowić się, jeśli Twój projekt jest albo na wczesnym stadium (może jeszcze można zrezygnować z IdentityServer?), albo jest to już produkt na produkcji (czy będzie nas stać na płacenie za licencję?). Dwa lata miną szybko, a w przypadku tak wrażliwej części systemu, jaką jest “zarządzanie tożsamością”, na pewno nie można sobie pozwolić na dłuższą metę na korzystanie z biblioteki, która nie jest już wspierana. Pewnie pocieszający powienien być fakt, że IdentityServer implementuje standard OpenID Connect / OAuth, więc ewentualnie przepięcie się na jakieś inne rozwiązanie nie powinno oznaczać przeorywania całego systemu. Oby. ;)

Ciekawostki Typescript #2 - TS - typy = JS

Thu, 01 Oct 2020 00:00:00 GMT

TypeScript nadzbiorem JavaScriptu

Mówi się, że “TypeScript jest nadzbiorem JavaScriptu”. Ale co to oznacza? W praktyce - wiadomo - każdy kod JavaScriptu jest poprawnym kodem JavaScriptowym. Zatem, co jest tym “nad” w stosunku do JavaScriptu? Otóż - system typów. I - przynajmniej koncepcyjnie, z pewnymi drobnym zastrzeżeniami, o których niżej - tylko system typów. To znaczy, że - “kanonicznie” (zastrzeżnia niżej) - konwersja TS do JS polega tylko na usunięciu informacji o typach. A zatem właściwie taką “konwersję” można by wykonać ręcznie usuwając wszystkie typy czy informacje, że dana klasa implementuje jakiś interfejs.

To, co napisałem powyżej, można dobrze zaobserwować na przykładzie typescriptowych modyfikatorów dostępu w klasie. Wyobraźmy sobie, że mamy taką klasę, napisaną w TS:

class Person {
  private firstName: string
  private lastName: string

  constructor(firstName: string, lastName: string) {
    this.firstName = firstName
    this.lastName = lastName
  }

  public sayHello(): string {
    return `Hi, I'm ${this.firstName} ${this.lastName}!`
  }
}

Pola firstName i lastName zadeklarowaliśmy jako prywatne. Zatem w TS próby dostania się do nich zakończą się błędem:

const john = new Person("John", "Smith")
console.log(john.firstName) // <- tu będzie błąd

Jak ta klasa zostanie jednak przekonwertowana do JavaScriptu? Mniej więcej tak:

class Person {
  constructor(firstName, lastName) {
    this.firstName = firstName
    this.lastName = lastName
  }

  sayHello() {
    return `Hi, I'm ${this.firstName} ${this.lastName}!`
  }
}

A gdybyśmy w JavaScripcie chcieli się dostać do firstName? Proszę bardzo - błędu nie ma:

const john = new Person("John", "Smith")
console.log(john.firstName) // <- błędu nie ma!

Gdy pierwszy raz się o tym dowiedziałem, to pomyślałem: “Ale jak to? Prywatne pole jest publiczne?… TypeScript, oszukałeś mnie…” Ale w zasadzie to jest konsekwencja tego równania:

TypeScript - (system typów) = JavaScript

Jeśli zatem chcielibyśmy na 100% traktować te pola jako prywatne - bo np. piszemy bibliotekę i naprawdę chcemy ukryć jakiś szczegół implementacyjny - to mamy dwa wyjścia:

skorzystanie z eksperymentalnej notacji pól prywatnych w JS - # (tutaj opis tej notacji),
skorzystanie z domknięć (patrz niżej).

W przypadku domknięć, należałoby napisać w TS naszą klasę mniej więcej tak:

class Person {
  public sayHello: () => string

  constructor(firstName: string, lastName: string) {
    this.sayHello() = () => {
      return `Hi, I'm ${firstName} ${lastName}!`
    }
  }
}

To rozwiązanie też ma niestety swoje wady:

jeśli chcemy skorzystać z ukrtych danych w metodzie klasy, to musimy ją zdefiniować w konstruktorze,
każda instacja klasy ma kopię tych metod zdefiniowanych w konstruktorze, co zwiększa zużycie pamięci.

Wyjątki od reguły

Na koniec muszę zwrócić uwagę na dwa wyjątki od tej zasady, że transpilator jedynie usuwa informacje o typach i modyfikatory dostępu. Tymi wyjątkami są enumy oraz pewien syntactic sugar w postaci definiowania parametrów konstruktora od razu jako pól klasy.

Enumy

Dla programisty C#, który zaczyna przygodę z TypeScriptem - użycie enumów to coś naturalnego: przecież nie będziemy używać jakichś magic numberów! Jednakże enumy w TS zachowują się nietypowo. Po pierwsze, enum z wartościami liczbowymi pozwala na przypisanie do niego dowolnej liczby… (Co to za enum?!)

enum WeekDay {
  Monday = 1,
  Tuesday = 2,
  Wednesday = 3,
  Thursday = 4,
  Friday = 5,
  Saturday = 6,
  Sunday = 6,
}

const wtf: WeekDay = 11 // <-- nie ma błędu!

Po drugie, jeśli do deklaracji enuma dodamy const (a więc const enum), to wszystkie jego użycia zostaną potraktowane jak const w C# - w czasie transpilacji zostaną podmienione na wartości liczbowe.

Po trzecie, enumy z wartościami stringowymi mają pewne pułapki: jeśli przypiszemy enuma do zmiennej, to zmiast typu string, otrzyma on typ literałowy, więc nie będziemy mogli go nadpisać, np.:

enum Status {
  Pending = "pending",
  Done = "done",
}

let statusText = Status.pending
statusText = `Status is: ${statusText}` // <-- tu będzie błąd: "Type 'string' is not assignable to type 'Status'."

Zamiast enuma lepiej użyć tutaj “unię typów literałowych”, czyli:

type Status = "pending" | "done"

Parametry konstruktora jako pola

TypeScript umożliwia zrobienie takie skrótowego zapisu:

class Person {
  constructor(public firstName: string, public lastName: string) {}
}

zamiast rozwlekłego:

class Person {
  public firstName: stirng
  public lastName: string
  constructor(firstName: string, lastName: string) {
    this.firstName = firstName
    this.lastName = lastName
  }
}

Ten syntactic sugar jest dla TS wyjątkowy, bo właśnie też skutkuje generowanie kodu JS - czyli znów wyłamujemy się z reguły “TS minus typy to JS”. Autor książki, o której wspominam poniżej, krytykuje używanie tego “myku” w TS (właśnie z takich powodów, nazwijmy to, kanonicznych), jednak dla mnie jest to bardzo wygodne. Ponadto, podobną propozycję widziałem w którejś z przyszłych/eksperymentalnych wersji C#, więc być może to jest też jakiś trend wspólny dla różnych języków. :)

Ten wpis jest częścią serii o TypeScripcie, inspirowaną lekturą książki D. Vanderkama pt. “TypeScript. Skuteczne programowanie”.

Ciekawostki Typescript #1 - typ vs. interfejs

Tue, 01 Sep 2020 00:00:00 GMT

W TypeScripcie mamy do dyspozycji dwa podobne byty, które przy deklarowaniu typów wydają się być zamienne - type oraz interface. Czy te dwa typy czymś się różnią?

type Person1 = {
  name: string
}

interface Person2 {
  name: string
}

W ogólności, poza subtelną różnicą w składni - do type “przypisujemy” deklarację, a interface deklarujemy wprost, bez znaku = - te dwie konstrukcje można stosować zamiennie. Obie będą weryfikować typ, np.:

const alice: Person1 = {
  name: "Alice",
  age: 20,
  // -> tu będzie błąd
}

const bob: Person1 = {
  name: "Bob",
  age: 25,
  // -> tu będzie błąd
}

Obie konstrukcje możemy też używać zamiennie w bardziej złożonych przykładach, jak sygnatury indeksu czy typy funkcji, np.:

type Dictionary1 = { [key: string]: string }
interface Dictionary2 {
  [key: string]: string
}

Zarówno typ, jak i interfejs możemy “podziedziczyć” (właściwe określenie w świecie TS to raczej - rozszerzyć):

class Employee1 implements Person1 {
  name: string
}

class Employee2 implements Person2 {
  name: string
}

Jakie zatem mamy różnice?

Jeśli definiujemy unię, to możemy zastosować tylko tylko type: type State = 'on' | 'off'
Tylko type może rozszerzać unię: type StateExtended = State & 'paused'
Teoretycznie interfejsem można wyrazić krotkę, ale za pomocą typu jest to dużo bardziej czytelne i naturalne:

type Pair = [number, number]

// zamiast jakiegoś dziwadła

interface Tuple {
  0: number
  1: number
  length: 2
}

Z drugiej strony interface umożliwia scalanie deklaracji, czyli coś w stylu partial class z C#. Chodzi o to, że możemy w jednym pliku zadeklarować interfejs, a w innym - “dalszą jego część”, finalnie uzyskując interfejs, który będzie połączeniem obydwu deklaracji, np.:

// plik Person.ts
interface Person {
  name: string
}

// plik PersonAddress.ts
interface Person {
  address: string
}

Ten myk nie jest potrzebny raczej w naszym kodzie (możemy przecież scalić deklaracje do jednego pliku), ale przydaje się, gdy chcemy zmodyfikować typ, który dostajemy z jakiejś zewnętrznej biblioteki. Ten mechanizm wykorzystuje też podstawowa biblioteka TS - nowości i zmiany w kolejnych standardach ES to kolejne pliki, które rozszerzają wcześniejsze deklaracje: zatem wybierając odpowiedni standard ES, de facto wybieramy zestaw plików z deklaracjami, które są scalane.

Ten wpis jest częścią serii o TypeScripcie, inspirowaną lekturą książki D. Vanderkama pt. “TypeScript. Skuteczne programowanie”.

AutoMapper to zło - czy na pewno?

Wed, 01 Jul 2020 00:00:00 GMT

Jakiś czas temu przeczytałem artykuł pn. “AutoMapper to zło”. Autor w skrócie odradza używanie AutoMappera, z co najmniej dwóch powodów:

fakt, że mapowanie między różnymi typami mamy “gratis”, zachęca do nadmiernego tworzenia kolejnych “warstw” modeli, co często nie jest potrzebne
niestandardowa logika mapowania jest potencjalnym źródłem poważnych i trudnych do wychwycenia błędów.

O ile daruję autorowi clickbaitowy tytuł wpisu, to jednak pozwolę sobie nie zgodzić się z tak postawioną tezą: że AutoMapper to biblioteka, która więcej szkodzi, niż daje pożytku.

Zacznijmy od początku - co sami autorzy AutoMappera o nim mówią:

AutoMapper is a simple little library built to solve a deceptively complex problem - getting rid of code that mapped one object to another. This type of code is rather dreary and boring to write, so why not invent a tool to do it for us?

W skrócie chodzi więc o to, by nie musieć pisać ręcznie kodu, który przekopiowuje dane z obiektu typu A do obiektu typu B. Kropka. Nie ma tu mowy o żadnych warstwach, DTOsach itp. - po prostu mamy obiekt typu A i chcemy go “przekonwertować” na typ B. Powinniśmy więc najpierw zadać sobie pytanie, kiedy z takimi sytuacjami możemy się spotkać, a dopiero potem - czy AutoMapper jest właściwym do tego narzędziem.

Gdy myślę o użyciu AutoMappera - a więc o sytuacjach konwersji danych z typu A na typ B - to przychodzą mi do głowy następujące przykłady:

chcemy odseparować / odróżnić model API od modelu, którego używamy w aplikacji,
chcemy przenieść dane pomiędzy typami, które o sobie nic nie wiedzą
checemy uprościć model zwracany do klienta, bo ten bazodanowy - ze względu na użycie ORMa - jest trochę niewygodny.

Poniżej opiszę te przypadki.

Jak odseparować model API od modelu aplikacji?

Wyobraźmy sobie, że mamy prostą REST-owo-CRUD-ową nakładkę na bazę danych. Mamy tam encję Product. Dopóki jest ona prosta, to po prostu w endpointach przyjmujemy i zwracamy dokładnie tę samą klasę Student, której używamy w modelu bazdanowym (np. używając EF Core).

Co jeśli chcemy jednak zapisywać też informacje “audytowe”, tj. kto i kiedy zmodyfikował encję. Dodajemy pola LastModifiedDate i LastModifiedBy. Jeśli chcemy, by np. na stronie te dane były wyświetlane, to świetnie, od razu dostajemy je gratis, bo przecież używamy tej samej klasy Student. Ale co z endpointami od aktualizacji? Czy checmy, aby klient mógł “zapostować” na endpoint /students JSONa z dowolnie wypełnionymi polami LastModifiedDate i LastModifiedDate? Raczej nie, to by mogło pozowlić komuś podszyć się pod innego użytkownika albo antydatować zmianę. Możemy to oczywiście obsłużyć/zabezpieczyć na poziomie np. kontrolera, tj. zawsze odpowiednio nadpisywać te pola, jeśli robimy aktualizację. No ale wówczas po co te pola w modelu API? Jeśli opisujemy nasze API za pomocą np. Swaggera, to w wygenerowanej dokumentacji będą one uwzględnione - jak powiedzieć klientowi, że “nie, te pola są nieistotne, możesz je zignorować”. Trochę słabo. :/ W końcu, skoro używamy języka typowanego (C#), to typy powinny opisywać dokładnie to, co się dzieje. W takiej sytuacji AutoMapper może być pomocą - wprowadzamy typy StudentViewApiModel, StudentUpsertApiModel i możemy z nich / do nich mapować naszą klasę Student.

Jak przenieść dane pomiędzy typami, które o sobie nic nie wiedzą?

Weźmy teraz na tapetę inną sytuację - mamy trzy projekty:

Students.Domain - logika biznesowa
Students.WebApi - Web API dla tej logiki
Students.FunctionApp - cloudowa funkcja, która też operuje na tej logice (nie wiem, czyta z kolejki, uruchamia się w jakichś odstępach czasowych itp.) Oczywiście dwa ostatnie projekty zależą od pierwszego. Jeślibyśmy chcieli korzystać wszędzie z klasy Student pochodzącej z projektu Students.Domain, to możemy natrafić na schody: jakiś problem typu opisany w poprzedniej części. Załóżmy zatem, że zdecydowaliśmy się wprowadzić oddzielny typ - powiedzmy StudentQueueModel - np. w projekcie Students.FunctionApp i chcemy jakoś przekonwertować dane z tego typu na ten domenowy. Klasa Student nic nie wie o klasie StudentQueueModel, nie możemy zrobić więc metody Student FromQueueModel(StudentQueueModel model). Możemy w drugą stronę - w klasie StudentQueueModel zrobić metodę Student ToDomainModel() i pisać mapowanie ręcznie. Albo - możemy też użyć AutoMappera.

Jak uprościć model, który mamy “w środku”, zanim wyślemy go do klienta, “na zewnątrz”?

Może być tak, że biblioteka ORM wymaga od nas pewnych dodatkowych pól lub konstrukcji, których nie chcielibyśmy wystawiać klientowi. (Ja natrafiłem na taki problem z podkolekcją elementu typu prostego dla EF Core: zamiast ICollection<string> musiałem stworzyć typ SubItem, z unikalnym kluczem i wartością typu string - i jego użyć w kolekcji ICollection<SubItem>.) Może być tak, że jakieś dane ściągamy z zewnętrznego serwisu - albo w ogóle nasze API jest tylko nakładką na jakiś stary system - i ten oryginalny format jest niestrawny lub niewygodny dla klienta. Ot, choćby wartości logiczne są zapisane jako string (np. "true"). Mapowanie możemy napisać ręcznie - ale możemy też użyć AutoMappera.

Podsumowanie

Moim zdaniem istnieją sytuacje, w których albo chcemy mieć dodatkową warstwę modelu, albo wręcz taką wprost mamy narzuconą z zewnątrz (ciągniemy dane ze starego systemu). Wówczas - AutoMapper może być pomocny, bo nie tylko przyspiesza development, ale zabezpiecza przed błędami (nie trzeba pisać mapowania dla nowego pola - o ile występuje w obu typach mapowania, źródłowym i docelowym). Oczywiście, jak każde narzędzie, także i AutoMapper, może być źle użyty lub nadużyty: ale to już jest opowiedziane znanym powiedzeniem, mówiącym, że dla trzymającego tylko młotek wszystko wydaje się gwoździem. Wydaje mi się więc, że autor rzeczonego artykułu wylewa dziecko z kąpielą. Jeśli czasami zdarza się, że dodajemy niepotrzebne warstwy modeli i mapowania między nimi, to nie znaczy, że narzędzie do mapowania jest złe - to znaczy, że podjęliśmy złą decyzję i niepotrzebnie doprowadziliśmy do sytuacji, kiedy mapowanie jest w ogóle użyte.

Meeting Web Accessibility Guidelines - kurs Pluralsight

Sun, 10 May 2020 00:00:00 GMT

Notatki do kursu Pluralsight o dostępności stron internetowych pn. “Meeting Web Accessibility Guidelines (Section 508/ WCAG 2.1)”

Wybór “kodeksu”

Istnieją w branży pewne “kodeksy” (conformance guidelines), określające zasady dostosowania stron internetowych dla osób z niepełnosprawnościami.

Jakie są korzyści z ich zastosowania?

dostępność dla OzN
zabezpiecza przed pozwami sądowymi (tak, w Stanach firma może być pozwana np. za to, że jej strona nie jest dostępna dla osób niewidomych)
poprawa SEO
ogólnie lepsze usability
kiedy się zestarzejesz, łatwiej Ci będzie z tej aplikacji korzystać - bo z wiekiem i Ty będziesz mieć problemy np. ze wzrokiem

Najbardziej znane “kodeksy” (z perspektywy amerykańskiej):

Section 508
WCAG 2.1

Section 508

uchwalona w 1986 r. poprawka do Rehabilitation Act z 1973 r., zaktualizowana też w 2017 r.
dotyczy stron rządowych albo takich, które za rządowe środki powstały
w przeciwieństwie do ogólnoświatowego WCAG, Section 508 jest używana głównie w USA

WCAG (Web Conformance Accessiblity Guideline)

tworzone przez grupę, która jest częścią W3C (industry standard)
oparte na czterech zasadach (POUR):
- perceivable - każdy użytkownik jest w stanie “odebrać” informację
- operable - każdy użytkownik jest w stanie operować na stronie, bez względu na to, czy używa myszki, czy klawiatury
- understandable - informacja na stronie jest zrozumiała, a interakcje przewidywalne (logiczne)
- robust - strona musi działać z różnymi technologiami asystującymi
poziomy: A, AA, AAA (im więcej A, tym bardziej “restrykcyjne” reguły)
strona WCAG zawiera dokładnie rozpisanie kilkudziesięciu wskazówek
podstawowa rekomendacja - osiągnąć WCAG 2.1 AA (co przy okazji wypełnia w 100% Section 508)

HTML

Struktura strony

ściśle poprawny HTML:
- <!doctype html> - wymagane przez WCAG!
- brak zduplikowanych albo niedomkniętych tagów
określić język strony (WCAG A 3.1.1) - atrybut lang na elemencie <html>; jeśli jakieś fragmenty są w innym języku - nawet kawałki span - tam też należy użyć atrybutu lang, żeby zmienić “lokalnie” język (WCAG AA 3.1.2)
tytuł strony (WCAG A 2.4.2), inny dla każdej strony (żeby ułatwić orientację)
poprawne skalowanie (WCAG AA 1.4.4):
- <meta name="viewport"> - nie stosować user-scalable=no ani maximum-scale=1 (bo to wyłącza powiększenie)
- używaj w CSS relative units, tzn. rem lub em do określania rozmiarów (bo WCAG AA 1.4.1 wymaga, żeby dało się korzystać ze strony powiększonej o 200%)
- strona musi działać i wyglądać, nawet jeśli użytkownik powiększy interlinię (do 1.5), odstęp po akapicie (do 2-krotności czcionki), kerning (do 1/8 rozmiaru czcionki) lub odstęp między wyrazami (do 1/6 rozmariu czcionki) - WCAG AA 1.4.12
używaj tagów z HTML5, tj. header, nav, main, footer, aside (WCAG A 1.3.1, WCAG A 2.4.1) - bo ujawniają strukturę treści oraz ułatwiają nawigację
- jeśli jest kilka elementów nav na stronie - np. na górze, powtórka w stopce oraz oddzielny na bocznym pasku, to mozna je odróżnić nazwami, podanymi w atrybucie aria-label
- main może być tylko jeden na stronie
używaj nagłówków (WCAG A 2.4.6)
- h1 może być tylko jeden na stronie
- nagłówki powinny iść po kolei, bez przeskakiwania, np. z h1 od razu do h5
stosuj listy (li, ul) zamiast grupy div-ów - screen reader dzięki temu może rozpoznać, jaki to jest typ listy, ile ona zawiera elementów oraz poinformować, który element z listy jest aktywny (WCAG A 1.3.1)

Nawigacja

użyj tekstu zamiast obrazka z tekstem, np. w linkach (WCAG AA 1.4.5)
linki nawigacyjne na różnych stronach poiwnny być w tej samej kolejności na wszystkich stronach (WCAG AA 3.2.3)
spójna identyfikacja - jeśli na stronie jest np. wyszukiwarka na pasku, to przycisk “submit” powinien być wszędzie opisany tak samo (WCAG AA 3.2.4)
linki powinny opisywać to, dokąd prowadzą - nie używaj czegoś w stylu: <p>Kliknij <a>tutaj</a>, żeby złożyć zamówienie</p> (WCAG A 2.4.4)
- unikaj samego “czytaj więcej” w opisie linku - jeśli użytkownik będzie iterował po samych linkach, to będzie miał tylko listę wielu “czytaj więcej” (np. na stronie głównej bloga) i nie będzie wiedział, dokąd one prowadzą; pewnym kompromisem jest mieć coś takiego:
```
<a href="/strona">
  Czytaj więcej <span class="hidden">o nowościach w .NET</span>
</a>
```
wówczas wystarczy dopowiednio ostylować CSS-ową klasę hidden tak, aby była niewiodczna - czytnik ekranu jednak ten tekst odczyta
bypass blocks (WCAG A 2.4.1) - czyli mechanizm do omijania np. nagłówka z linkami; taki skip link powinien:
- być pierwszym elementem na stronie
- ostylowany tak, aby występował poza ekranem, chyba, że jest na nim fokus, np. tak:
```
.skip-link {
  left: -100%;
  position: absolute;
}

.skip-link:focus {
  left: 50%;
}
```
- jeśli robimy “skok” robimy za pomocą fokusa, to:
  - docelowy element (ten, do którego skip link ma nawigować) powienien mieć atrybut tabindex ustawiony na -1
  - na onclick tego skip linka, powinniśmy sfokusować docelowy element

Tabele

Table should not be used for layout! It is not 1999.

tytuł tabeli, poprzedzający ją, powienien być w tagu caption (pierwszy “child” elementu table)
nagłówek: użyj th zamiast td i użyj atrybutu scope="col" (bo tam jest “tytuł” dla kolumny)
wiersz: jeśli w tabeli są grupy (wiersza z colspan, będące nagłówkami grupy), to to tam użyj th, ale scope="colgroup"
jeśli nadasz nagłówkom th (dla kolumn i grup) unikalne identyfikatory, możesz ich użyć w komórkach td atrybutu headers z wartością będącą listą id-ków nagłówków (coś w stylu współrzędnych)
za pomocą ukrywania CSS-em (tak jak było to z “read more”) możesz w tagu caption dać szerszy opis, jak dane są ustrykturyzowane, zwłaszcza jeśli tabela jest bardziej złożona, ma podgrupy itp.
dzięki strukturze tabeli (zamiast div-ów) VoiceOver będzie poprawnie opisywał komórki oraz umożliwi nawigację pomiędzy wierszami/kolumnami za pomocą skrótów klawiszowych
ogólnie lepiej złożone tabele rozbijać na kilka mniejszych, bo to ułatwi zadanie czytnikowi ekranu
tag tfoot powinen być przed tagiem tbody

Formularze

odpowiednie opisy i etykiety do pól (WCAG A 1.3.1, WCAG A 3.3.2, WCAG AA 2.4.6)
na inputach label musi się zgadzać z widocznym opisem pola (WCAG A 2.5.3)
zgrupuj pola, które dotyczą logicznej całości (np. kilka inputów dla adresu: miasto, ulica etc.) - używaj fieldset, legend
walidacja, stan pola itp. nie mogą być wyróżnione tylko w sposób wizualny (WCAG 1.3.3)
jeśli input jest niestandardowy, zadbaj o to, by się poprawnie fokusował, inaczej osoba korzystająca tylko z klawiatury, nie będzie w stanie “doscrollować się” do niego i go zobaczyć (WCAG A 2.1.1)
no keyboard traps (WCAG A 2.1.2)
jeśli obiekt jest fokusowalny, to stan focus i zwykły muszą być wizualnie rozróżnialne (AA 2.4.7)
błędy muszą być opisane tekstem (a nie tylko np. obrazkiem wykrzyknika) - WCAG A 3.3.; jeśli jest możliwe zasugerować, jak poprawić błąd (np. data podróży “tam” nie może być późniejsza niż podróż powrotna), to powinno być to przedstawione użytkownikowi (WCAG AA 3.3.3)
element form powinien mieć atrybut novalidate, bo przeglądarkowe “tooltipy” takiej walidacji nie są dostępne
label: albo za pomocą atrybutu for (wtedy label jest rodzeństwem opisywanego inputu), albo poprzez opakowanie (wówczas label jest rodzicem)
tabindex - dwie dozwolone wartości: -1 (wyłączamy z naturalnej kolejności focusowania, ale możemy sfocusować za pomocą JS) oraz 0 (po prostu zmienia element niefokusowalny w fokusowalny)
jeśli formularz ma konsekwencje w “realnym życiu” (np. zakup) albo w bazie danych (np. zapis edytowanego rekordu), końcowa akcja musi być zatwierdzana (WCAG AA 3.3.4)
jeśli istnieje jakiś limit czasowy (np. automatyczne zakończenie sesji), użytkownik musi mieć co najmniej 20 sekund na podjęcie decyzji, czy chce przesunąć ten limit czasowy (WCAG A 2.2.1); oczywiście to nie dotyczy tych ograniczeń czasowych, które wynikają z “reguł biznesowych”, np. ograniczonej w czasie rezerwacji miejsca podczas zakupu biletu
kontrast dla tekstu powinien być co najmniej 4,5:1 (WCAG AA 1.4.3)
elementy interfejsu i grafiki powinny mieć kontrast co najmniej 3:1 (WCAG 1.4.11)

Obrazy, dźwięki i filmy

Obrazy

nie wolno używać obrazków z tekstem zamiast zwykłego tekstu (WCAG AA 1.4.5)
podstawowa zasada - WCAG A 1.1.1 - nietekstowe treści powinny być zaprezentowane w jakiejś alternatywnej, tekstowej formie
wszystkie obrazki powinny mieć atrybut alt; jeśli dany obrazek jest tylko dekoracją, to powinny mieć pusty atrybut alt (inaczej czytnik ekranu będzie czytał nazwę pliku…)
- opis w atrybucie alt wcale nie musi być literalnym opisem tego, co jest na obrazku
- nie używaj fraz typu “obrazek przedstawia…”, bo czytnik ekranu już sam informuje, że dany element jest obrazem
- opisz znaczenie lub cel obrazu, a jeśli zawiera tekst, który ma znaczenie, to powinien on być też w atrybucie alt
jeśli obraz jest ustawiony jako tło w CSS (częsty przykład z ikonami, robiony po to, by poprawić wydajność strony), należy po prostu dodać ukryty tekst, który opisuje ikonę (skoro nie ma tagu img, nie możemy użyć alt)
obrazek wektorowy (SVG) - należy dodać:
- role="img", żeby czytnik ekranu wiedział, że to jest obrazek
- wewnątrz tagu svg - tag title; opcjonalnie, jeśli chcemy szerzej opisać obrazek, można dodać też tag desc
- żeby zapewnić kompatybilność z różnymi przeglądarkami, należy za pomocą aria-labelledby zrobić odnośnik do tagu title (i analogicznie atrybutem aria-describedby, jeśli używamy tagu desc)

Dźwięk

każde nagranie audio, które nie jest “na żywo” (i.e. zostało nagrane wcześniej) powinno mieć reprezentację tekstową, która prezentuje tę samą treść (transkrypcję) - WCAG A 1.2.1
- Google Docs Voice Typing albo Windows Speech Recognition - narzędzia, które mogą zapewnić półautomatyczną transkrypcję (pewnie tylko lub głównie po angielsku…)
- w transkrypcji podaj imiona (nazwiska) rozmawiających oraz opisz też “pozawerbalne” dźwięki (śmiech, inny ton)
jeśli na stronie automatycznie włącza się jakiś dźwięk na dłużej niż 3 sekundy, musi być mechanizm, żeby ten dźwięk wyłączyć lub zapauzować lub dostosować jego głośność niezależnie od poziomu głośności urządzenia (WCAG A 1.4.2) - (na marginesie: ja bym tu też dodał: Żadna strona nie powinna na dzień dobry atakować użytkownika dźwiękami. Nie jesteśmy w roku 1999. ;) )
analogicznie, jeśli jakaś treść, która się automatycznie przesuwa, zmienia lub pulsuje (czyli nie tylko filmy, ale np. “karuzele”) - musi być mechanizm, żeby taką treść zatrzymać lub ukryć (WCAG A 2.2.2)
jeśli cokolwiek błyska/pulsuje, minimalna częstotliwość to 3 Hz - chodzi o uniknięcie napadów epilepsji (inna sprawa, że migające strony to znowu wygląda jak rok 1999…)

Filmy

po pierwsze - transkrypcja wypowiedzi (tak, jakby to było samo audio)
po drugie: napisy do filmu; WCAG A 1.2.1 wymaga tylko dla filmów uprzednio nagranych, natomiast WCAG AA 1.2.4 - także dla nagrań na żywo
- dwa rodzaje:
  - “open” - zawsze widoczne, “wgrane” do filmu
  - “closed” - pokazywane tylko na życzenie użytkownika, jako nakładka na film
po trzecie: audiodeskrypcja (słowny opis tego, co widać i co się dzieje na filmie oraz odłgosów lub muzyki, budującej nastrój) - WCAG AA 1.2.5

Responsive Web Design

Visual order must match DOM order

Czyli kolejność fokusów musi być sensowna i taka, jak to jest widoczne, bez przeskakiwania np. do stopki, żeby potem wrócić do głównej treści (WCAG A 1.3.2, WCAG A 2.4.3).

strona musi działać niezależnie, jak obrócony jest telefon (portret/krajobraz) - WCAG AA 1.3.4
jeśli operacja jest dostępna za pomocą gestów (np. zoom dwoma palcami), to musi być też ścieżka za pomocą pojdenyczego wskazania (np. przyciski +/-) (WCAG A 2.5.1)
akcje powinny być podpięte pod eventy typu click/touch, a nie pod keydown/touchdown - tak aby można było wycofać się z akcji poprzez przesunięcie się (myszką, palcem) poza element (WCAG A 2.5.2)
jeśli operacja jest wyzwalana poruszaniem urządzenia, powinna być też opcja, żeby wykonać ją za pomocą “zwykłego” UI (WCAG A 2.5.4)
jak ukryć element?
- display: none lub visibility:hidden w CSS-ie - niewidoczy dla wzorku, ale i czytnika ekranu
- aria-hidden="true" - ukrywa tylko przed czytnikiem ekranu
- wypozycjonowanie poza ekran - niewidoczny dla wzroku, ale widoczny dla czytnika - np. takim CSS-em:
```
.hidden {
  position: absolute;
  left: -10000px;
  top: auto;
  width: 1px;
  height: 1px;
  overflow: hidden;
}
```

QuaggaJS + React, czyli skaner kodów kreskowych

Sun, 03 May 2020 00:00:00 GMT

QuaggaJS to bardzo poręczna biblioteka do odczytywania kodów kreskowych za pomocą samego JavaScriptu. Daje radę z kilkoma formatami kodów i odczytuje je bardzo sprawnie. Ostatnio chciałem zobaczyć, jak można to zintegrować z Reaktem, a że dostępny w internecie przykład jest baaaaardzo stary (React w wersji 0.x…), postanowiłem przygotować na szybko coś z najnowszym Reaktem (i TypeScriptem): https://github.com/robert-skarzycki/quagga-react-example

Podlinkowane repozytorium to w zasadzie kod strony, która prezentuje bibliotekę w działaniu. Jak widać, wystarczy kilka linijek kodu, a od razu dostajemy i samo odczytywanie kodów kreskowych, jak i okienko podglądu z kamerki. Wow!

Zapraszam do forkowania i eksperymentowania - na stronie z dokumentacją do biblioteki można przeczytać, jak pozmieniać konfigurację, na przykład:

zmienić rozpoznawany format kodów,
przełączyć na kamerkę en face lub tylną,
włączać i wyłączać dekodowanie (żeby nie obciążać urządzenia)
itd.

Marten - dole i niedole

Thu, 30 Apr 2020 00:00:00 GMT

Jest sobie taka biblioteka o nazwie Marten, która umożliwia korzystanie z bazy PostgreSQL jako bazy dokumentowej albo bazy do event sourcingu - w aplikacji .NET. (Co ciekawe, jest współautorem - a przynajmniej jednym z tych, którzy obecnie ją utrzymują - jest nasz krajan, Oskar Dudycz). Jeśli Ty lub ktoś w Twoim zespole rozważa jej użycie - przeczytajcie kilka przestróg.

Dlaczego ludzie wpadają na taki pomysł? Wiadomo, event sourcing, NoSQL - to wszystko brzmi fajnie i modnie. Kolejny argument - jeśli działasz na Azure, to fakt, że baza PostgreSQL jest tańsza od MS (sic!) oraz, że nie ma “z pudełka” innych baz NoSQL (typu MongoDB - co nie jest do końca prawdą): to wszystko może być kuszące. No i jeszcze do tego pokusa - robimy mikroserwisy, więc czemu nie zrobić w każdym serwisie innej bazy danych? ;)

A teraz na serio - jeśli chcesz robić event sourcing, to ta biblioteka brzmi ciekawie i może pozwolić łatwo zrobić event store. Ja tego nie sprawdzałem, więc się nie wypowiem. W ogóle mam jednak takie wrażenie, że autorzy oryginalnie chcieli zrobić po prostu event store na PostgreSQL, więc potrzebowali do tego document store - żeby trzymać eventy jako dokumenty. Tak więc niejako przy okazji możemy sobie za pomocą Martena zrobić po prostu bazę dokumentową. I tu zaczynają się schody.

Technicznie rzecz biorąc od kilku wersji PostgreSQL posiada typ danych JSON (w także JSONB - czyli JSON z informacją o typach). Marten przykrywa to dla nas w ten sposób, że po prostu dla każdego obiektu (dokumentu) tworzy wiersz w odpowiedniej tabelce, gdzie oprócz kolumny z właściwymi JSON-owymi danymi, jest kilka kolumn z metadami (choćby identyfikator). To brzmi na pierwszą myśl dziwnie, ale gdybyśmy mieli to implementować sami, to szybko przyznamy: dobrze, że tę pracę ktoś wykonał za nas.

Gdy wczytamy się w dokumentację, dowiemy się, że z tej roboty wykonanej za nas - to nawet ktoś zaimplementował Linq. Tak więc - wydawałoby się - bomba! Po prostu Entity Framework dla bazy dokumentowej. Tak więc podpinamy NuGeta, tworzymy projekt i… zaczynają się schody. Niestety, dokumentacja przedstawia najprostsze przykłady, o ograniczeniach milczy albo wspomina zdawkowo. Tymczasem rzeczywistość brutalnie rewiduje pierwotne założenia. Pierwsze schody zaczynają się, gdy chcemy zrobić trochę bardziej skomplikowane zapytanie - ot, choćby coś tam odfiltrować na bazie tego, co jest w podkolekcji. Dla prostych przykładów, np. listy stringów, możemy użyć Contains, ale gdy chcemy użyć czegoś bardziej skomplikowanego w predykacie Where, to niestety Marten się wysypuje wyjątkiem w runtime’ie. Co gorsze, to jest jakiś randomowy wyjątek z nullem lub o collection has no elements. Kolejne schody zaczynają się, gdy chcemy zrobić sobie jakąś agregację lub wyciąć tylko fragment dokumentu (inna sprawa, jak dużo powinniśmy wrzucać do dokumentu…). Próby użycia Linqu i extension methods kończą się wyjątkami, zostaje więc goły SQL zapisany w C#. Co gorsza, jest to stricte “postgresowy” SQL (dzień dobry standard, który jednak w detalach się różni), a do tego - operujemy na JSON-ie w PostgreSQL, czyli musimy nauczyć się całej nowej składni (te wszystkie ->, json_array_elements itp.). Dla człowieka, który - na studiach czy to w pracy - raczej głównie bazował na bazach typu MySQL bądź SQL Server, to jest bardzo przykre doświadczenie. Marten ma też opcję “projekcji”, czyli kodu javascriptowego, który jest za pomocą C# ładowany do bazy SQL-owej i tam trzymany jako bazodanowa funkcja. Słyszeliście? JS ładowany w C# do SQL-a! Mindfuck gotowy!

Dodatkowym problemem z Martenem jest też to, że niestety nie jest zbyt aktywnie rozwijany - niby ostatnie wersje są wydawne co miesiąc, ale sporo issues na Githubie wisi ponad rok. (Tu oczywiście nie mam pretensji do autorów, jedynie stweirdzam fakt.) To też dodaje frustracji, bo na ficzery, których nam brakuje, możemy się nie doczekać.

To, co napisałem wyżej, jest oczywiście zabarwione pewnym uprzedzeniem do PostgreSQL (wychowałem się jednak na MySQL i SQL Serwerze od Microsoftu) oraz lenistwem (nie zawsze chce mi się czytać dokładnie dokumentację). Przyznaję jednak, że moje doświadczenia z Elasticsearchem lub MongoDB były o niebo lepsze (a przecież, gdy pierwszy raz z nimi się stykałem, też pewne koncepcje i składnia dla kwerend była novum). Wydaje mi się zatem, że pomysł pt. Marten jako baza dokumentowa w C# - to nie jest najlepsze rozwiązanie. Prawdopodbnie popełniłem sporo błędów i częściowo używałem biblioteki w niewłaściwy sposób - ale DX (developer experience) nie jest zadowalające: tych wszystkich frustracji, co miałem, to już nikt ich nie wymaże z pamięci. ;)

R.I.P. John Conway

Tue, 28 Apr 2020 00:00:00 GMT

Kilka dni temu dotarła do mnie wiadomość, że John Conway zmarł w wieku 82 lat. Był on twórcą słynnej “gry w życie” (Game of Life) - wspaniałego automatu komórkowego, opartego na arcyprostych regułach, a mimo to pozwalającego na niemal nieograniczone analizy, symulacje i dociekania. Kto nigdy nie słyszał o tej “grze” (to przecież nie jest gra sensu stricto), koniecznie niech coś sobie o niej przeczyta i zobaczy animacje różnych ponadkomorkówych struktur, takich jak działa, statki itp.

Dla mnie jednak Game of Life nie ma charakteru naukowego, ale przede wszystkim - sentymentalny. Pamiętam, że dowiedziałem się o tej “grze” w podstawówce, z archiwalnych numerów “Młodego Technika” z lat 80., gdzie zamieszczona była też implementacja w QBasiku. Przepisywałem to z bratem najpierw do QBasika, eksperymentując z różnymi regułami i zestawem startowym. Ze dwa lata później, reimplementowaliśmy to w C++. Ech, niesamowity czar końcówki lat 90. …

Tak więc, requiescat in pacem, Johnie Conwayu!

Programista COBOL-a poszukiwany...

Wed, 15 Apr 2020 00:00:00 GMT

Kilka tygodni temu gubernator stanu New Jersey poinformował, że stanowa administracja natychmiast potrzebuje programistów… COBOL-a. (Sic!) Okazało się bowiem, że system do obsługi zasiłków dla bezrobotnych nie wytrzymał natłoku chętnych, spowodowanego koronawirusem. Potrzebne są zatem natychmiastowe usprawnienia, ale system napisany jest w COBOL-u.

Można się śmiać (o ile nie jest się bezrobotnym w New Jersey, bo ja nie wiem, czy zakorkowany system oznacza brak wypłaty zasiłków…), ale wydaje mi się, że to najlepsza lekcja w zakresie długu technologicznego i konieczności unowocześniania starych systemów. Nawet jeśli coś działa i wydawać by się mogło, że nie trzeba tego ruszać, to - okazuje się - zawsze może pojawić się czynnik zewnętrzny, spoza świata technologii, który wszystko zmienia i “pogrzebie stary świat”.

Enumerable.Range w JavaScripcie

Fri, 10 Apr 2020 00:00:00 GMT

W C# zdarza się czasami napisać taki kod:

var collection = Enumerable.Range(0, 10).Select(i=> $"Item number {i}" );

Ale jak to zrobić w JS? Oto sprytny myk:

const collection = [...Array(5).keys()].map(i => `Item number ${i}`)

Źródło: https://stackoverflow.com/a/10050831/2017882

Dobre, nie? :)

Jak zmusić Chrome, żeby zapomniał o redirekcie z http do https

Thu, 02 Apr 2020 00:00:00 GMT

Jeśli w dewelopmencie żonglujemy pomiędzy różnymi apkami, uruchamianymi lokalnie, może zdarzyć się taka sytuacja:

odpalamy projekt A, na porcie 3000, który jest skonfigurowany na redirect z HTTP do HTTPS także lokalnie,
potem odpalamy projekt B, na tym samym porcie, ale bez HTTPSa.

Wtedy Chrome możne nam zrobić pułapkę. Przy odpalaniu projektu B, czyli wpisując http://localhost:3000, Chrome będzie nas przekierowywał na HTTPS. Ale projekt B działa lokalnie tylko na HTTP, więc na twarz dostaniemy na twarz SSL_CERTIFICATE_ERROR. Odświeżanie strony, jakieś hard refreshe, restart przeglądarki - nic nie pomoże. Jak rozwiązać problem?

Musimy Chrome’owi powiedzieć wprost: “weź zapomnij o tym redirekcie”. Oto recepta:

Wejdź na chrome://net-internals/#hsts.
Przejdź do “Delete domain security policies”.
Wpisz nazwę domeny (w naszym wypadku np. “localhost” - bez portu) i kliknij “Delete”.

Voilà!

Migracja .NET Core 2.2 do 3.1

Fri, 20 Mar 2020 00:00:00 GMT

W wersjach .NET Core można się nie łapać - co jakiś wychodzą nowe, nie zawsze wiadomo, czy i kiedy przenosić się na nowsze wersje oraz jakie będą tego skutki. (Osoby ze świata “starego” .NETa pamiętają, że to nigdy nie była prosta decyzja.) Z pomocą przychodzi jednak sam Microsoft, mówiąc wprost, jakie wersje wspiera, a jakie już skazuje na zapomnienie. Stan na dzisiaj:

Gdy ze zdziwieniem spostrzegłem, że wersja 2.2, na której oparty był ostatni projekt, w którym pracowałem - nie jest już wspierana od Bożego Narodzenia 2019, zaordynowałem przenosiny na 3.1. To jest wersja rekomendowana i będzie wspierana przez najbliższe 2 lata. Jak dla mnie spoko.

No to myślę sobie, że zmieniam w csprojach tylko jedną linijkę:

 <TargetFramework>netcoreapp3.1</TargetFramework>

…i fajrant. 😎

To jednak nie jest takie proste. Poniżej przedstawiam listę kolejnych kroków, które trzeba zrobić.

Podbij wersję w csprojach jak wyżej.
Po skompilowaniu dostaniesz na pewno błędy z informacją o konieczności usunięcia referencji do niektórych nugetów lub podbcia wersji. Ja musiałem m.in.:

usunąć referencję do Microsoft.AspNetCore.App z projektu WebAPI,
podbić wersję Microsoft.Extensions.DependencyInjection do 3.1.x

Zrób parę modyfikacji w Startup.cs (to jest przykład dla projektu WebAPI, bez żadnych widoków czy Razor pages):

dodaj services.AddControllers(); na początku ConfigureServices,
zmień CompatibilityVersion na Version_3_0 w services.AddMvc(...).SetCompatibilityVersion(...),
zamień użycie IHostingEnvironment na IWebHostEnvironment w argumentach metod,
w metodzie Configure:
- dodaj app.UseRouting(); (raczej na początku),
- dodaj app.UseAuthorization(); (o ile jest uwierzytelnianie w projekcie),
- dodaj na końcu:

app.UseEndpoints(endpoints =>
{
    endpoints.MapControllers();
});

Potem podbij EF Core do 3.1 (oczywiście, jeśli jest używane w Twoim projekcie). Nie zapomnij też o podbiciu Microsoft.EntityFrameworkDesign, jeśli Twój kontekst jest w innym projekcie niż apka webowa.
Jeśli masz testy Twoich repozytoriów (lub innego kodu czytającego coś bazy) - na pewno testy się wywalą. Chodzi tu o to, że w EF Core 3 została wprowadzona zasadnicza zmiana: w poprzedniej wersji EF Core tam, gdzie nie potrafił zbudować poprawnego, bardziej złożonego query - na chama wykonywał operację po stronie klienta (co skutkowało miejscami niespodziewanie niską wydajnością zapytań); w wersji 3 inżynierowie Microsoftu postanowili zrobić odwrotnie: tam, gdzie query byłoby w wersji 2 wykonane po stronie klienta, teraz framework rzuca wyjątek - i sugeruje, żeby zrobić tę kwerendę explicite po stronie klienta. Umownie można powiedzieć, że w tych miejscach trzeba dodać to przysłowiowe ToList, żeby najpierw dane ściągnąć do klienta.
Jeśli sam utrzymujesz build maszynę, to czeka Cię jeszcze jedna niespodzianka - odpowiednie sparowanie wersji .NET Core SDK i EF Core CLI Tool. Tutaj też nastąpiła zmiana - otóż, dotychczas EF Core CLI Tool (czyli coś, co umożliwia pisanie dotnet ef ...) było częścią całego SDK. Teraz już tak nie jest i należy tego toola zainstalować oddzielnie. Żeby było jeszcze trudniej, wersja tego narzędzia musi być “sparowana” z wersją .NET Core SDK. U mnie zadziałał zestaw:

dev@build-machine:~$ dotnet --version
3.1.102
dev@build-machine:~$ dotnet-ef --version
Entity Framework Core .NET Core Command-line Tools
3.1.1

To ważne, bo na ten moment najnowszą wersję EF Core CLI Tools jest 3.1.2, które nijak nie chce współgrać z .NET Core 3.1.102. Tak więc EF Core CLI Tool musi być zainstalowany z podaniem konkretnej wersji, a nie domyślnie.

Po drodze jeszcze podbiłem wersję xUnit, ale już nie pamiętam, czy to było konieczne. :) (Ale wówczas trzeba też podbić xunit.runner.visualstudio i - chyba? - Microsoft.NET.Test.Sdk - żeby można było odpalać unit testy w Resharperze.)

Boiling Frogs 2020 - relacja

Sat, 14 Mar 2020 00:00:00 GMT

Na chwilę przed wprowadzeniem zakazów organizowania imprez masowych odbyła się we Wrocławiu konferencja Boiling Frogs. Byłem, widziałem, kawę tam piłem - a com widział: opisuję.

N-warstwowe modele domenowe

Mariusz Gil

Prelegent zwrócił uwagę na możliwość wyróżnienia innej typologii “klocków”, jakich używamy w DDD - w dużych projektach. Używając metafory systemu sygnalizacji świetlnej w mieście, wyróżnił następujące byty (idąc za Erikiem Evansem):

Nazwa	Metaforyczny odpowiednik
capabilities	sygnalizator na skrzyżowaniu
operations	cykle sygnalizacji na skrzyżowaniu
policies	“zielona fala”
decision support	automatyczna regulacja cyklami świateł na podstawie bieżącego ruchu samochodów
commitments	?

To są przecież podstawowe rzeczy

Piotr Stapp

Warte przemyślenia rozróżnienie pomiędzy rzemieślnikiem a architektem (inżynierem). (Trochę na przekór ruchowi “software craftsmanship”. ;) ) W skrócie: rzemieślnik po prostu umie powtarzać jakieś wzorce, a architekt (inżynier) rozumie te wzorce i potrafi tworzyć nowe. Tak jak w budowlance, zwykły majster ma po prostu wiedzieć, jak dobrze wylać beton na strop, a inżynier - wie, dlaczego ten strop się nie zawala. :) Jeśli chcemy być inżynierami, musimy rozumieć, dlaczego coś działa w dany sposób.
12 factor app - https://12factor.net/pl/
Logi w rozproszonym systemie:
- nie można opierać się na kolejności w czasie, bo serwery mają zawsze rozjazd pomiaru czasu pomiędzy sobą,
- można stosować correlation id, ale warto przy kolejnym wywołaniu kolejnego serwisu w łańcuszku, dodawać numerek z oznaczeniem zagłębienia - tak aby móc zbudować nie tyle łańcuch, ale drzewko “wywołań” pomiędzy serwisami.

Prezentacja była bardzo luźno opowiedziana, ale merytorycznie - zdecydowanie polecam Piotra Stappa na każdą konferencję. :)

Microfrontends - czyli jak wdrożyć idee microservices na frontendzie

Marcin Milewicz

Minusy monolitycznego frontendu:

duże repozytorium (dużo plików),
zależności między zespołami,
długi czas budowania.

Jak zrobić microfrontends na froncie?

build-time integration - czyli po prostu jedno repozytorium, ale moduły w sub-packages; to ma jednak nadal minusy jednego, dużego repo,
iframes - minusem trudność w ostylowaniu, i niewygodne dla SEO,
moduły w odrębnych bundlach w JS, czyli “dociągnij bundla i renderuj”
WebComponents

O pracy zdalnej dla firmy z zagranicy

Maciej Sławik

Bardzo dobra, krótka (15 min) prezentacja o tym, jak szukać i jak znaleźć pracę zdalną dla firmy z zagranicy.

Portale strcite z oferatmi pracy zdalnej są słabe - te firmy są zalewane ofertami, mogą nawet nie odpowiedzieć na Twoją ofertę.
Lepiej znaleźć potencjalnego pracodawcę samemu i do niej zaaplikować (oczywiście trzeba sprawdzić, czy firma jest remote-friednly).
Warto być specjalistą w czymś konkretnym - pracując zdalnie sam, musisz być ekspertem, żeby być w stanie rozwiązywać problemy samemu.
Postaraj się o profesjonalny profil na Linkedin - zdjęcie od fotografa, można poprosić o rekomendacje.
Wysyłając CV do różnych krajów, sprawdź, jakie tam są zwyczaje i dostosuj do nich swoje CV - np. w Wielkiej Brytanii nie daje się zdjęcia do CV.
Lepsza jest firma mała lub średnia, bo łatwiej się dogadać, że chce się być 100% zdalnie.

Czy wydajność to jakość?

Jarek Pałka

Jarek to standupowiec polskich konferencji IT, więc wiadomo, że jest wesoło (i często nie na temat). Najciekawszy był jednak ten link - do artykułu o tym, że, mówiąc w skrócie, obecny przemysł IT jest do dupy, bo w ogóle nie dbamy podstawowe rzeczy związane z wydajnością. No bo jak to możliwe, że np. aplikacja Messenger na telefon z wersji na wersję zajmuje coraz więcej, a funkcjonalności nie jest więcej.

#ąęszcz Rzecz o języku informatyków

Piotr Przybył

Świetna, lekka prezentacja o tym, jak bardzo nasz język branżowy jest odległy od normalnej polszczyzny. Te wszystkie “merdżuję”, “fokusuję się na taskach”, “mitingi”, “tajmlajny” itp. to jest nowomowa. To jest oczywiście w porządku, gdy tego używamy między sobą (każda branża na swoje terminy zawodowe), ale naprawdę warto używać normalnych, polskich odpowiedników, gdy komunikujemy się na zewnątrz. Dzięki temu będziemy lepiej rozumiani.

Tutaj znajdziesz link do prezentacji.

Na Githubie istnieje repozytorium, gdzie wspólnymi siłami próbuje się znaleźć polskie odpowiedniki.

Czy pracując w software housie zmarnuję sobie życie?

Marcin Zabawa

Ciekawa typologia potencjalnych miejsc pracy dla programisty. W skrócie mamy do wyboru takie opcje:

startup: będzie przygoda, ale i zapierdziel, no i raczej nie ma szans na “craftsmanship”, bo gonimy deadline’y
firma produktowe: nadgodzin nie ma, można się z produktem identyfikować i trochę wykazać się w “craftsmanshipie”, ale na pewno nie będzie przygód
software house: w porównaniu do firmy produktowej na pewno poczucie misji jest słabsze (jednak od projektu do projektu), ale więcej przygód i więcej możliwości na wykazanie się jako inżynier
korpo (czyli “centra usług wspólnych”) - tego wątku prelegent nie poruszył, bo stwierdził, że nie ma osobistego doświadczenia w tym zakresie.

GovTech 2019 - walidator zdjęć

Thu, 27 Feb 2020 00:00:00 GMT

W listopadzie 2019 roku zgłosiłem się do konkursu GovTech. Wybrałem zadanie konkursowe polegajce na przygotowaniu aplikacji mobilnej, która miała pomóc osobom wgrywającym zdjęcia do dowodu osobistego. Chodziło to, żeby aplikacja - podczas robienia sobie zdjęcia selfie - od razu wskazywała, dlaczego dane ustawienie do zdjęcia jest nieprawidłowe: a to za ciemne tło,a to niedozwolone okulary.

Mój pomysł polegał na tym, że zabrać się za zadanie w 3 krokach:

Przygotować aplikację webową, za pomocą której mógbłym zebrać dane testowe od znajomych i rodziny.
Wytrenować model machine learning za pomocą tych danych.
Przygotować aplikację mobilną wykorzystującą ten wytrenowany model - apka była właściwym elementem konkursu.

Niestety, nie udało mi się dobrnąć do kroków numer 2 i 3, bo przygotowanie apki z kroku pierwszego zajęło mi sporo czasu, no i też nie zebrałem wystarczającej ilości zdjęć, żeby móc to jakoś wrzucić do machine learning. Jednakże to i tak było ciekawe doświadczenie, dlatego dzielę się tym, co udało mi się zrobić.

Wszystko, co zrobiłem, można znaleźć na moim Githubie: https://github.com/robert-skarzycki/govtech-2019-collect-id-photos

To repozytorium zawiera dwie aplikacje:

apkę webową do zbierania zdjęć,
funkcję Azure do przepychania tych zdjęć do Blob storage.

Apkę webową stworzyłem za pomocą Gatsby CLI oraz startera Julia - tego samego, na którym działa mój blog. Sama strona to po prostu zwykły “wizard”, który prowadzi użytkownika krok po kroku, prosząc o wykonanie kolejnych zdjęć - prawidłowych i nieprawidłowych. Natomiast funkcja Azure działa na .NET Core i wykorzystuje Azure Blob SDK (to było moje pierwsze spotkanie z tym SDK).

AutoMapper - flatten

Tue, 18 Feb 2020 00:00:00 GMT

Od dawna wiedziałem, że AutoMapper ma bardzo wygodną - domyślną - funkcję, automatycznego rozpoznawania poprawnego mapowania między zagnieżdżonymi obiektami a ich spłaszczonymi wersjami. Przykładowo:

class Car
{
    public string Vin {get;set;}
    public string Model {get;set;}
    public Person Owner {get;set;}
}

class Person
{
    public string Id {get;set;}
    public string FirstName {get;set;}
    public string LastName {get;set;}
}

Możemy bez problemu zmapować na spłaszczoną wersję:

class CarDto
{
    public string Vin {get;set;}
    public string Model {get;set;}
    public string OwnerId {get;set;}
    public string OwnerFirstName {get;set;}
    public string OwnerLastName {get;set;}
}

Wystarczy zdefiniować zwykłe mapowanie między typami Car i CarDto - AutoMapper sam rozpozna, że “podobiekt” Owner należy “spłaszyczyć” do właściwości z prefiksem Owner*:

configuration.CreateMap<Car, CarDto>();

Co zrobić, gdy potrzebujemy wykonywać mapowanie w drugą stronę? To znaczy - mamy spłaszczony obiekt, a chcemy mapować do zagnieżdżonego obiektu (każdy przyzna, że lepsza jest taka struktura niż litania właściwości z takim samym prefiksem). Okazuje się, że to jest banalnie proste - wysatrczy przy definiowaniu mapowania dodać ReverseMap, tj.:

configuration.CreateMap<Car, CarDto>()
    .ReverseMap();

Co więcej, dodając specjalne metody typu ForMember czy ForPath możemy “customizować” tę odwrotną mapę - tak jakbyśmy konfigurowali zwykłe mapowanie.

Całkiem zgrabne, prawda?

Organizacja folderów w projekcie frontendowym

Sat, 01 Feb 2020 00:00:00 GMT

Rozbudowane narzędzia IDE typu Visual Studio mają tę zaletę (albo wadę - o tym potem :)), że udostępniają szablony projektów, wprowadzając pewną standaryzację do tego, jak zorganizowane są pliki projektu. Sztandarowy przykład to szablon ASP.NET MVC z Visual Studio, który domyślnie tworzy foldery typu Controllers czy Views, będące domyślnym miejscem do umieszczenia - odpowiednio - kontrolerów i widoków.

W świecie frontendowym sytuacja jest dużo bardziej “rozmyta”. Tworząc aplikacje Reactowe w zasadzie narzędziami pracy są konsola oraz edytor (Visual Studio Code :heart:). Ale nawet skorzystanie z CLI, które “scaffolduje” projekt (np. create-react-app) nie wprowadza (narzuca?) struktury folderów, która by była umożliwiała “ustandaryzowany” układ folderów nawet, gdy aplikacja się rozrośnie. create-react-app w zasadzie “standaryzuje” tylko istnienie folderu src. Przyznacie, że to trochę mało. Gdzie umieszczać testy? Gdzie umieścić komponenty, a gdzie moduły “niewizualne” (np. serwisy kontaktujące się z zewnętrznym API)? Każdy deweloper jakoś odpowiada na te pytania, ale to skutkuje tym, że w ramach zespołu trudniej utrzymać spójność, a szerzej - jeśli każdy projekt przyjmuje inną filozofię organizacji plików, to trudniej się w tym połapać. Jeśli ktoś korzysta z Reacta wraz z Reduxem, to mógł spotkać się z propozycją, aby zgrupować komponenty w dwóch folderach: containers i components. W tym pierwszym powinny znaleźć się komponenty “wyższego rzędu”, tj. te, które są “podpięte” pod Reduxa, w drugim folderze - pozostałe. Takie rozwiązanie wydaje mi się jednak niepraktyczne - zmiana komponentu z Redux-agnostic na Redux-wise nie powinna oznaczać konieczności przenosin pliku do innego folderu. Inna sprawa, że to nie jest szablon/standard, tylko rekomendacja.

Wobec braku standaryzacji organizacji plików i folderów w świecie frontendowym, mogę i ja zaproponować własne rozwiązanie. :) Stosuję je ostatnio w projektach, które - chyba można tak powiedzieć - osiągnęły już rozmiar midi. Zasada jest następująca:

Grupuj pliki według funkcjonalności, a nie według technicznego podobieństwa.

Oznacza to tyle - na przekór np. struktury szablonu projektu ASP.NET MVC - że nie mamy folderu typu views, zbierającego widoki, albo reducers, do którego, jak do worka, wrzucamy wszystkie reducery. Moim zdaniem lepiej grupować pliki według fragmentów aplikacji. Przykładowo, jeśli mamy “podstronę” do administracji (użytkownicy, role itp.), to niech wszystko, co jest potrzebne do tej części systemu niech będzie w folderze administration. Oczywiście dalej można to pokroić na dalsze podfoldery, czy to dalej według kolejnych “podsystemów” (users, roles), czy już bardziej technicznie. Co nam daje takie rozwiązanie? Otóż, moim zdaniem, aplikacja przestaje być jedną wielką kulą błota, gdzie mieszamy style CSS, komponenty Reactowe, testy itp., ale raczej wprowadzamy hierarchię: aplikacja składa się z modułów (np. ów moduł administracyjny, reprezentowany przez folder administration), a te moduły składają się z technicznych “cegieł” - np. plików z komponentami Reactowymi. Dodatkowo, niejako gratis, dostajemy jeszcze możliwość stosowania krótszych nazw plików (nie trzeba powtarzać wszędzie prefiksu, bo nadrzędny folder może mówić, jaki tu jest obszar zaimplementowany) oraz potencjalne łatwiejsze wydzielenie podprojektów i skorzystanie z narzędzi typu Lerna. Innymi słowy - niech struktura plików w projekcie będzie sugerowała, że mamy do czyniania z “modularnym monolitem”. ;)

W praktyce pewnie nie warto wydzielać takie foldery-moduły jako pierwszy krok po stworzeniu projektu za pomocą create-react-app: jesli aplikacja jest na wczesnej fazie rozwoju, to nie musimy się wiązać konkretnym podziałem. Chyba lepiej najpierw zacząć szybko, kosztem lekkiego bałaganu, a w odpowiednim momencie, gdy już wyklaruje się, z jakimi obszarami mamy do czynienia, wprowadzić taki podział na foldery-moduły.

Potęga podzapytań w Cosmos DB

Thu, 30 Jan 2020 00:00:00 GMT

Cosmos DB Query Playground to interaktywne środowisko do eksperymentowania z kwerendami do Cosmos DB. Jako dane testowe zawiera ono bazę produktów spożywczych wraz z informacjami o ich wartościach odżywczych. Przykładowy dokument wygląda mniej-więcej tak:

{
  "food": {
    "id": "14203",
    "description": "Coffee, instant, regular, powder, half the caffeine",
    "tags": [
      {
        "name": "coffee"
      },
      {
        "name": "instant"
      },
      ...
      // pomijam resztę
    ],
    "foodGroup": "Beverages",
    "nutrients": [
      {
        "id": "204",
        "description": "Total lipid (fat)",
        "nutritionValue": 0.5,
        "units": "g"
      },
      {
        "id": "205",
        "description": "Carbohydrate, by difference",
        "nutritionValue": 73.18,
        "units": "g"
      },
      ...
      // pomijam resztę
    ]
    ...
    // pomijam resztę
  }
}

Posłużmy się tym “typem” danych jako przykładem dla zobrazowania, jak bardzo mogą się różnić koszty zapytania.

Załóżmy, że chcemy wybrać wszystkie produkty, które zawierają 1g lub więcej kofeiny. A zatem musimy dla każdego produkty wyszukać w liście nutrients elementu o description równym "Caffeine" oraz nutritionValue >= 1000.

Podejście “łopatologiczno-proceduralne” może nas zaprowadzić do pomysłu, żeby dodać sobie user-defined-function, która “opakuje” te warunki, powiedzmy coś takiego:

function hasHighLevelOfCaffeine(food) {
  return food.nutrients.some(
    n => n.description == "Caffeine" && n.nutritionValue >= 1000
  )
}

Wówczas główne zaptanie się “upraszcza”:

SELECT food FROM food WHERE udf.hasHighLevelOfCaffeine(food)

Problem z tym zapytaniem jest jednak taki, że zżera ono sporo RU. Na potrzeby obliczeń zrobiłem sobie przykładową bazę, gdzie miałem niecałe 2000 produktów i tylko jeden z “wysokim poziomem kofeiny”. Dla takich dancyh zwykły select zeżarł ponad 600 RUs. Co gorsza - im więcej dokumentów w kolekcji, tym koszt będzie jeszcze większy. Wynika to prawdopodobnie z tego, że Cosmos nie potrafi sobie “zoptymalizować” zapytania z użyciem UDF, operującej na podkolekcji.

Spróbujmy zatem do problemu podejść inaczej. Korzystając z dokumentacji możemy spróbować użyć podzapytania - tak byśmy przecież postąpili w “zwykłym SQL-u”. (Mamy tu relację jeden-do-wielu, więc za pomocą EXISTS i podzapytania moglibyśmy to ograć.) W Cosmosie spraw wygląda podobnie, z tą różnicą, że używamy JOIN i podzapytania. Finalnie query wygląda tak:

SELECT
food
FROM food
JOIN (SELECT VALUE n FROM n IN food.nutrients
WHERE
	n.description = 'Caffeine' and n.nutritionValue >= 1000)

Dla wspomnianej wyżej “benchmarkowej” bazy z 2000 produktów - to zapytanie “kosztowało” tylko 2 RU. I to w zasadzie niezależnie od ilości dokumentów.

Ciekawe, prawda? :)

ITCorner Tech Meetup #1 Skalowanie

Sun, 19 Jan 2020 00:00:00 GMT

Kilka dni temu wziąłem udział w spotkaniu ITCorner Tech Meetup, którego tematem przewodnim było skalowanie. Poniżej garść notatek.

Temat

W zasadzie tylko 50% spotkania było o skalowaniu - reszta była o refaktorze legacy. Temat ciekawy jeden i drugi, ale tytuł spotkania jednak mylący.

Skalowanie

Jarosław Jedliński w swojej prezentacji opowiedział, jak jego zespół dba o to, żeby strona popularnego sklepu Euro RTV AGD nie wysypywała się w czasie czarnego piątku. Według zamieszczony statystyk - ruch na stornie w ten dzień jest kilka razy większy, dając kilka tysięcy requestów na sekundę. Ten zespół rozwija portal [https://www.euro.com.pl/] już od kilkunastu lat, co pozwoliło w fajny sposób pokazać ewolucję architektury i używanych rozwiązań. Kroki mniej więcej były takie:

Odseparować aplikacje “analityczne” od tej głównej, sklepowej.
Zduplikować bazę, żeby aplikacje “analityczne” nie zamulały dostępu do bazy dla sklepu.
Dać więcej instancji aplikacji sklepowych i jakiś load balancer.
Dodać cache w aplikacjach sklepowych - żeby zredukować round-tripy do bazy.
Wprowadzić centralny cache, żeby oszczędzić pamięć i nie trzymać powtórek w kilku cache’ach.
Wprowadzić cache dla całych requestów (Varnish) - umożliwia chwilowy offline sklepu (np. podczas wdrożenia w ciągu dnia).
Dodać drugą serwerownię ze zdkuplikowaną infrastrukturą, na wypadek awarii tej pierwszej.

Co ciekawe, cały rozwiązanie jest trzymane we własnych serwerowniach. Wydawało mi się, że to śmiga w chmurze, a jednak. Inna ciekawostka: nad rozwojem i utrzymaniem sklepu pracuje ponad 20-osobowy zespół programistów, testerów i administratorów.

Piotr Gołofit z Accesto opowiadał bardziej o mądrym przepisywaniu legacy (o tym niżej), ale w działce skalowania zwrócił uwagę na ciekawy aspekt. Bardziej mówił o skalowaniu biznesowy niż technicznym, tzn. o skalowaniu produktu (aplikacji) na większy rynek (międzynarodowy). W takich wypadkach trzeba pomyśleć m.in. o:

i18n = czyli obsłudze wielu języków: zarówno o przetłumaczonym interfejsie, jak i potencjalnym multi-języczną obsługą danych,
różnych strefach czasowych: wyświetlanie wg strefy czasowej użytkownika plus odpowiednie “tłumaczenie” dat i godzin wprowadzanych,
obsługa różnych walut - przede wszystkim jeśli chodzi o płatności. Co ciekawe, w przypadku tego projektu, o którym opowiadał Piotr, były to bliskie geograficznie rynki - wyjście z Irlandii na całe Wyspy Brytyjskie - to poza ww. sprawami dochodziły różnice kulturowe (wpływające de facto na sposób prezentowania danych) i polityczne (potencjalny brexit).

Przepisywanie legacy

Piotr Gołofit i Łukasz Urbański w swoich prezentacjach poruszali podobny temat: dostajemy do utrzymania (i rozwijania) starą aplikację, co robimy?

Ciągniemy to tak, jak jest - babrzemy się w legacy, conieco refaktorując.
Nowe rzeczy idą po nowemu, stare powoli próbujemy przepisywać na nowo.
Wywalamy wszystko i startujemy z carte blanche.

Żadna z opcji nie jest idealna, obaj prelegenci udowadniali, że opcja druga - nazwana strangler pattern (termin wprowadził Martin Fowler) - jest sensownym rozwiązaniem. Jeżeli jesteśmy w stanie na poziomie routingu rozdzilić ruch do starej i nowej aplikacji, to możemy sobie stworzyć takie poletko z nową aplikacją w nowej technologii. Nowe moduły trafiają do nowej aplikacji, stare są po kolei przepisywane na nowo. Ale cały czas mamy jedno i drugie aktywne - na produkcji. Co więcej, analizując użycie poszczególnych funkcji, możemy wybierać do przepisana te części, które są najczęściej używane przez użytkowników. Finalnie - w świecie idealnym - na koniec w starej aplikacji nie zostaje nic, można więc w całości przepiąć się na nową wersję. Oczywiście to nie jest takie hop-siup: przykład projektu, o którym opowiadał Piotr Gołofit, to były 3 lata stopniowego naprawiania sytuacji. To wymaga metodycznego podejścia, tym bardziej, im bardziej bagniste jest legacy, do którego siadamy. Trzeba najpierw zadbać o elementarne sprawy, jak kontrola wersji, CI/CD, podstawowe testy, załatanie najważniejszych luk bezpieczeństwa - żeby móc iść do przodu. W pewnym sensie podziwiam konsekwencję, bo wiele osób widząc bagniste legacy, do którego nikt nie chce się dotykać, szybko by uciekło, byleby nie babarać się w jakichś technologiach sprzed 10 lat i byleby nie sprzątać bajzlu po kimś innym.

Team tourism

Fri, 10 Jan 2020 00:00:00 GMT

Kilka lat temu zaproponowałem przełożonym, żebyśmy spróbowali zrobić trochę wymian personalnych pomiędzy zespołami. Celem, jaki mi przyświecał, było usprawnienie wymiany wiedzy - pracowaliśmy wszyscy nad jednym dużym projektem, ale każdy zespół siedział w swojej “działce”. Co więcej, duża część pracowników to były osoby z mniejszym doświadczeniem, chciałem więc pomóc młodszym kolegom w jego zdobywaniu, a “starszakom” - dać okazję do dzielenia się wiedzą i “mentorowania”. Niestety, pomysł upadł. Już nawet nie pamiętam dokładnych przyczyn - czy to było po prostu “nie da się”, czy zła organizacja pracy powodująca konieczność gaszenia pożarów, a może za słaba argumentacja z mojej strony. Ucieszyłem się jednak po jakimś czasie, gdy zobaczyłem ten wpis z blogu allegro.tech, w którym autor dokładnie wypunktowuje zalety “team tourism” (m.in. możliwość “odskoczni” od obecnego projektu/zespołu, wymiana wiedzy o częściach dużego systemu, zdobycie nowych umiejętności) oraz przekazuje parę praktycznych wskazówek, jak taki proces w firmie zorganizować i jakie mogą pojawić się problemy. Jeśli taką inicjatywę chciałbyś zorganizować w swoim miejscu pracy i potrzebujesz przekonać “górę” - koniecznie przeczytaj!

..

Tue, 07 Jan 2020 00:00:00 GMT

Po co API Gateway w mikroserwisach?

Accessible states in design systems #id24

Sun, 24 Nov 2019 00:00:00 GMT

Polecam poniższe nagranie z konferencji Inclusive Design 24, w którym autor, Russ Weakley, opisuje podstawowe stany elementów HTML (np. visited/unvisited link) i to, jak łatwo zadbać o ich dostępność:

https://www.youtube.com/watch?v=k_7yqLyHc3U

TypeScript 3.7!

Tue, 12 Nov 2019 00:00:00 GMT

Oto jest - TypeScript 3.7. Hurra!

A co tym razem dostajemy?

Optional chaining - czyli ficzer znany choćby z C#. Dotychczas - aby uniknąć błędu z komunikatem Cannot read property 'x' of undefined - trzeba było explicite sprawdzać, czy dana zmienna jest undefined lub null. Teraz - wystarczy użyć operatora ?., który zrobi to sprawdzenie za nas. Innymi słowy - zamiast

let x = foo === null || foo === undefined ? undefined : foo.bar.baz()

można napisać po prostu

let x = foo?.bar.baz()

Niezłe, co nie?

Nullish Coalescing - znowu rzecz znana z C#. Jak łatwo przypisać do zmiennej wartość domyślną, na wypadek, gdyby podstawowa ścieżka skutkowała undefined? Dotychczas stosować musiałem sztuczkę z JavaScriptu, tj.:

let model = options.volume || 0.5

Jeśli w obiekcie options nie ma właściwości volume lub jest ona ustawiona na undefined - mogę mieć “fallback” do jakiejś tam wartości domyślnej (np. 0.5). Problem jest jednak taki, że ten operator || “wybiera” prawą stronę, gdy lewa strona jest “falsy”,czyli gdy np. ktoś ustawi options.volume = 0, to i tak zostanie wybrana prawa strona, czyli wartość domyślna. Ten problem rozwiązuje właśnie “nullish coalescing” - czyli operator ??. Dzięki temu powyższy przykład można opisać jako:

let model = options.volume ?? 0.5

I w ten sposób problem “falsy” wartości po lewej stronie mamy rozwiązany.

Uncalled Function Checks - ile to już razy zdarzało się, że zamiast wywołania funkcji - użyłem samego odwołania się do niej, zwłaszcza w warunku w ifie. Mam na myśli:

if(user.isAdministrator) {
    ...
}

zamiast tego

if(user.isAdministrator()) {
    ...
}

Co gorsza, kod w pierwszej opcji będzie się transpilował bez błędu, zawsze zwracając true, no bo właściwość, która jest funkcją zawsze jest “truthy”. Tak było do teraz. Od wersji 3.7 w powyższej sytuacji dosteniemy błąd.

""Flatter Error Reporting** - tworząc coś z użyciem React i TS, często zdarza się, że zmieniamy coś w propsach komponentu. W miejscu, w którym z niego korzystamy, po takiej zmianie “interfejsu” komponentu, oczywiście pokazać się może błąd. Często jednak ten błąd jest tak bardzo nieczytelny - zwłaszcza, gdy zmiana w interfejsie jest głęboko - jakiś atrybut, do którego przyisujemy obiekt przyjmuje teraz obiekt o lekko innej strukturze. TypeScript 3.7 dostarcza teraz komunikatów bardziej “spłaszczonych”, tj. konkretnie informujących, że w tym miejscu strutktury zagnieżdżonych obiektów jest “rozjazd”.

Ja się przesiadam na 3.7 jak najszybciej, a Ty?

PS. Pełną listę zmian można znaleźć tu: https://devblogs.microsoft.com/typescript/announcing-typescript-3-7/

WinForms is dead

Thu, 07 Nov 2019 00:00:00 GMT

Polemika z tym tekstem: https://blog.submain.com/death-winforms-greatly-exaggerated/

Tekst stary (sprzed ponad roku), ale gdzieś mi wpadł w ręce - no i jak przeczytałem, to postanowiłem wysmarowąć polemikę.

Tak, WinForms jest wciąż żywy - ale to dlatego, że ciągle istnieją stare aplikacje, z których ktoś korzysta i których - z różnych powodów - nie wymienia się na rozwiązania oparte na nowszych technologiach. Ale to nie jest argument - znam przypadki produkcyjnego wykorzystywania aplikacji “dosowych” z UI w stylu Norton Commander. Ale czy to znaczy, że te technologie są żywe?
Tak, WinForms jest martwy - nikt chyba dzisiaj nie tworzy od nowa projektów w oparciu o WinForms: po pierwsze mamy dzisiaj inne standardy i oczekiwania (np. dotyczące wyglądu GUI); po drugie ciężko przekonać programistów do pracy w technologii, która jeśli nie jest już martwa, to na pewno zmierza do tego; po trzecie - nie jestem pewien, czy .NET Core 3 coś tu zmienia, ale bazowo WinForms jest tylko na Windowsa, więc odpadają inne platformy; po czwarte - inne technologie mają lepsze wsparcie narzędziowe (ot choćby to, że - jak pisze sam autor - w Visual Studio 2019 nie ma designera do WinFormsów…).
Szybkość prototypowania? Nie sądzę. Jeśli naprawdę chcemy zrobić szybki proof of concept aplikacji desktopowej, a nie za bardzo znamy się na WPF-ie, to chyba dzisiaj najlepiej wybrać któreś z rozwiązań typu Electron: czyli osadzenia aplikacji webowej w desktopowym okienku. Ja bym szedł dzisiaj w tym kierunku, tym bardziej, że napisanie aplikacji Elektronowej np. w Reakcie daje od razu potencjał na pójście w innych kierunkach - czy to czystej webówki, czy urządzeń mobilnych za pomocą React Native. To po co robić coś prototypować w WinFormsach?

Generic type inference in C#

Thu, 31 Oct 2019 00:00:00 GMT

Próbowałem ostatnio zrobić takie coś:

interface IWrapper<TItem> {
    ICollection<TItem> Items {get;set;}
}

class MyWrapper : IWrapper<sting>{
    public ICollection<string> Items{get;set;}
}

class Operator {
    public TWrapper DoSomething<TWrapper, TItem>()
    where TWrapper : IWrapper<TItem>
    {
        // ...
    }
}

Następnie chciałem, żeby kompilator sam domyślił się drugiego argumentu generycznego, gdy wołam DoSomething:

operator.DoSomething<Wrapper>();

zamiast

operator.DoSomething<Wrapper, string>();

Niestety, pierwsze opcja wywalała kompilację z komunikatem, że kompilator nie potrafi domyślić się typu tego drugiego argumentu generycznego. No ale - jak to? Skoro określam w where, że TRequest ma implementować interfejs IWrapper<TItem>, a TItem jest drugim argumentem, to chyba wiadomo, że np. dla TRequest = IWapper<int> - TItem = int?

A jednak - nie! Jak zwykle odpowiedź przychodzi ze Stack Overflow - tym razem sam Eric Lippert, który pracował onegdaj przy kompilatorze C# wyjaśnia, że:

A bunch of people have pointed out that C# does not make inferences based on constraints. That is correct, and relevant to the question. Inferences are made by examining arguments and their corresponding formal parameter types and that is the only source of inference information.

Azure Pipelines - uważaj na stages i jobs

Tue, 22 Oct 2019 00:00:00 GMT

Odkąd Azure Pipelines (lub szerzej - Azure Devops) umożliwił deklarowanie pipeline’ów w plikach YAML zamiast klikania po stronie - bardzo spodobał mi się ten sposób organizacji CI/CD. Mimo że struktura YAML-a jest przejrzysta, umożliwia składanie procesu budowania/wdrazania z klocków i w zasadzie koncepcyjnie odzwierciedla to, co dało się zrobić w wersji UI-owej - to jednak o pomyłkę łatwo.

Ostatnio dużo czasu spędziłem na tym, że wysypywał mi się bardzo prosty pipeline: w zasadzie tam było tylko w pierwszym kroku zbudowanie projektu przez npm install; w drugim zaś kroku: uruchomienie testów UI, napisanych z pomocą biblioteki Cypress. Mimo że wszystkie skrypty były poprawnie zdefiniowane, build agent też miał wszystko, co było potrzebne i wszystko działało na maszynie deweloperskiej, to Azure Devops potykał się na drugim kroku, stwierdzając, że cypress not found. Sprawdzałem pathy, kombinowałem z różnymi opcjami, ale nic nie chciało działać. Okazało się finalnie, że - krok pierwszy (npm install) i drugi zdefiniowałem jako oddzielne joby w ramach jednego stage’a. (Czyli miałem jeden stage, z dwoma jobami, a w każdym jobie po jednym stepie.) No i nie uwzględniłem tego, że joby są od siebie niezależne, a zatem stworzony w pierwszym kroku folder node_modules nie był dostępny w drugim jobie. Czyli de facto próbowałem uruchomić skrypt npm (do uruchomineia Cypressa) bez wcześniejszego odpalnia npm install. Na świeżo sklonowanym repo to nie może się udać.

Na przyszłość warto więc pamiętać, jaka jest struktura pipeline’a:

STAGE 1
   - JOB 1
     - STEP 1
     - STEP 2
     ...
   - JOB 2
     - STEP 1
     ...

Przykładowo można to sobie wytłumaczyć tak:

stages służą do oddzielenia głównych operacji, np. budowania od wdrażnia
joby są poiom niżej i “enkapsulują” jakiś konkretny kawałek takiego dużego procesu, czyli np. jeśli budujemy oddzielnie frontend i backend, to możemy mieć w dwa joby na to; joby możemy puszczać równolegle albo określać, że dany job ma czekać wynik innego joba
stepy to już kolejne kroki w ramach danego joba, np. npm install, potem npm run build.

Wyniki z jednego joba można dzielić z innymi, ale trzeba to zrobić poprzez pipeline artefacts.

CSS in JS

Tue, 15 Oct 2019 00:00:00 GMT

Gdy widzę kogoś, kto używa Reacta, a stosuje globalne pliki CSS, to bolą mnie zęby (choć nie tak bardzo, gdy widzę, jak ktoś tworzy większą aplikację w Reakcie-Reduksie, a nie korzysta z TypeScripta - żal mi takiego biedaka; ale to opowieść na inną okazję). Od kiedy zacząłem korzystać z biblioteki (Material UI)[https://material-ui.com/] (Reaktowe komponent implementujące Material Design), bardzo mi się spodobało to, że mogę stylować komponenty lokalnie za pomocą CSS-in-JS (czyli reguły CSSa pisane w JS/TS). To po prostu jest wygodne, a do tego ma kilka innych plusów, o których można sobie poczytać przeglądając poniższą prezentację: https://speakerdeck.com/vjeux/react-css-in-js

Jeśli jeszcze nie czujesz się przekonany, zajrzyj też tu: https://medium.com/seek-blog/a-unified-styling-language-d0c208de2660

P.S. Istnieje wiele rozwiązań typu CSS-in-JS, nie tylko to, które jest “zaszyte” w Material UI, np.:

Styled Components,
Galmorous,
Emotion.

Blog - jaką platformę wybrać?

Tue, 01 Oct 2019 00:00:00 GMT

Na dziś odpowiedź brzmi: Gatsby.

Próbowałem wcześniej z WordPressem, potem eksperymentowałem ze statycznym generatorem (Hexo), potem wróciłem do WordPressa, by na końcu wylądować tutaj, czyli statycznym generatorem, jakim jest Gatsby.

WordPress wydawał mi się dotychczas domyślnym rozwiązaniem dla strony typu blog. Ma on kilka plusów:

znana platforma - wiele lat temu z niego korzystałem (kiedy byłem programistą PHP :P),
bardzo dużo gotowych - darmowych lub płatnych - szablonów, co pozwala szybko osiągnąć atrakcyjny efekt wizualny,
trylion wtyczek, a więc: “jeśli masz jakiś problem, to na pewno został on rozwiązany”
rozbudowany CMS - mamy posty, grafikę, tagi, kategorie itp.
na wielu hostingach można go zainstalować “1 kliknięciem”

W zderzeniu z rzeczywistością Anno Domini 2019 okazało się, że są jednak minusy:

instalacja, aktualizacja i konfiguracja WordPressa, MySQL to na dzisiejsze za dużo pracy; hostowanie z własną domeną na wordpress.com nie opłaca się finansowo
tam jest jednak pod spodem PHP! ;)

Dlaczego statyczny generator?

Statyczny generator stron to narzędzie oparte np. o Node.js, dzięki któremu przetwarzamy jedną postać strony/bloga (np. pliki markdown) - w statyczną stronę, opartą tylko o HTML, JS i CSS. Na rynku jest całkiem sporo, można sobie przebierać, zależnie od silnika, możliwości, “dojrzałości” społeczności - polecam stronę https://www.staticgen.com/, z listą generatorów.

Jakie możliwości daje statyczny generator?

możliwość hostowania “wszędzie” - finalna strona to są same pliki HTML, CSS i JS, więc można nawet wrzucić ten content na Azure Blob Storage i już
interfejs command-line (nie wiem, czy we wszystkich, ale na pewno w wielu, zwłaszcza tych opartych o Node.js), bliski programistycznemu sercu
bezpieczeństwo - to nie jest PHP z dziurami, które trzeba pilnować, aktualizować itp.
prostsze zarządzanie - nie muszę logować się do jakiegoś CMSa, podawać hasła itp.; mogę całą stronę/bloga trzymać na GitHubie i po porstu git commit/git push i mam zaktualizowaną treść
większa elastyczność i łatwiejsze rozszerzanie funkcjonalości - to nie jest PHP, tylko np. JavaScript/TypeSciprt

Czemu więc niw udało się z Hexo? Pewnie było kilka powodów:

może jeszcze nie byłem gotowy na zmianę w myśleniu o “silniku do bloga”
próg wejścia był spory (konfiguracja, szablony), a w zasadzie silnik działał jedynie w oparciu o pliki markdown
nie znalazłem satysfakcjonującego gotowego szablonu

A teraz cały na biało - Gatsby

Gatsby zainteresował mnie dwoma “ficzerami”:

wykorzystanie Reacta - czyli przyjazne środowisko: nie muszę samemu pisać szablonu w gołym HTML-u/CSS-ie
możliwość podpięcia jako wejścia dowolnego źródła z contentem - via GraphQL.

Okazało się, że uruchomienie jest bardzo proste, zwłaszcza przy wykorzystaniu gotowych (starterów)[https://www.gatsbyjs.org/starters/]. Dodatkowo, za rękę prowadzi (tutorial)[https://www.gatsbyjs.org/tutorial/], więc próg wejścia jest bezbolesny. Dzięki temu, że renderowanie “contentu” jest oddzielone od źródła danych (“separation of concerns” ;)), możemy w zasadzie tworzyć treść strony/bloga w dowolny sposób - albo po prostu jako treść pomiędzy komponentami Reactowymi, albo z wykorzystaniem wtyczki, która będzie źródłem danych dla kwerend GraphQL, np. w plikach Markdown, ale też wykorzystaniem zewnętrznego CMSa, w tym - WordPressa. A do tego z Gatsby’ego łatwo zdiplojujemy na (Surge)[https://surge.sh/] czy (Netlify)[https://www.gatsbyjs.org/docs/deploying-to-netlify/], tak więc byłskawicznie możemy stworzyć jakiś proof-of-concept i podzielić się nim z kimś, przesyłając linka.

I ten właśnie miks - z jednej strony pełna elastyczność, a z drugiej łatwość osiągnięcia zadowalającego efektu, startując z poziomu 0 - jest wielką siłą Gatsby’ego. A do tego cały sztafaż znajomych narzędzi - Node’owe CLI, git, VS Code, React - czyni pracę bardzo przyjazną. Wydaje mi się zatem, że Gatsby stanie się moim podstawowym narzędziem do budowy blogów i prostych stron - ten Gatsby to naprawdę “Wielki Gatsby”. ;)

P.S. Dla ciekawych - tę stronę zbudowałem w oparciu o starter gatsby-starter-julia ((link)[https://www.gatsbyjs.org/starters/niklasmtj/gatsby-starter-julia/]).

Robert Skarżycki - blog - RSS Feed

30 dni z... Pythonem - dzień #2

30 dni z... Pythonem - dzień #0

Zmigrowany do Gatsby v5!

Azure DevOps pipelines - tips & tricks (4)

Azure DevOps pipelines - tips & tricks (3)

Disaster recovery w Azure (1) - teoria

Co może pójść nie tak?

RPO vs RTO

Architektura infrastruktury Azure

Azure DevOps pipelines - tips & tricks (2)

Największe pułapki ze zmiennymi

Nie ma nadpisywania zmiennych przy użyciu taska script

Zmienne typu sekret nie są przekazywane do skryptów

Service connection nie może być w zmiennej

Runtime parameter nie może być opcjonalny

Azure DevOps pipelines - tips & tricks (1)

Template nesting

Pętle

Matrix strategy

Extend template

Podsumowanie

Migracja danych do Comos DB

Bulk SDK

Zwiększ throughput

C# - historia (C# 8.0)

Readonly members

Domyślne implementacje w interfejsach

Pattern matching w switchach

IAsyncEnumerable

Using bez klamerek

Operacje na indeksach

C# - historia (C# 9.0)

Rekordy

Init-only setters

Pomijanie typu przy słowie kluczowym new

Podstawy architektury oprogramowania dla inżynierów #1 - parametry architektury

Parametry architektury

“Określają pozadziedzinowe względy projektowe”

“Wpływają na niektóre strukturalne aspekty projektu”

“Mają decydujące lub duże znaczenie dla działania aplikacji”

Typologia parametrów architektury

Lista parametrów architektury

Mikroserwisy: rodzaje zdarzeń

Zdarzenie w ramach encji

Zdarzenia domenowe

Zdarzenia integracyjne

AzureDevops pipeline + semantic versioning = da się?

Jak ustawić zmienną środowiskową w Azure DevOps pipeline?

Problem

Rozwiązanie nr 1 (nie działa :( )

Rozwiązanie nr 2 - działające!

Print to file w C# na Windows 10

SignalR + Azure + mikroserwisy = ? (cz.1)

SignalR na Azure

Tryb Default

Tryb Serverless

To be continued…

7 porad dla każdego, kto robi coś po godzinach

1. Wybierz proste zdanie

2. Nie wynajduj koła na nowo

3. Postaraj się mieć coś działającego jak najszybciej

4. Będą trudności i problemy - to przyjmij za pewnik

5. Opublikuj swoją working beta

6. Nie rób przerwy

7. Enjoy the process

IAsyncEnumerable - to jest dobre!

Learn in public

bo najlepiej nauczysz się, jeśli zaczniesz uczyć kogoś

bo to nic nie kosztuje i po co zazdrośnie chronić np. swoje notatki

bo świadomość publicznego “raportowania” postępów motywuje

bo “oddajesz” społeczności to, co wziąłeś od innych

Identtyfikacja przeglądarki, czyli jak działają paywalle

Śmierć Moment.js

Code Coverage w .NET Core

Ciekawostki Typescript #4 - typowanie strukturalne

Ciekawostki Typescript #3 - z API może przyjść wszystko

Koniec darmowego open source, czyli IdentityServer będzie płatny

Ciekawostki Typescript #2 - TS - typy = JS

TypeScript nadzbiorem JavaScriptu

Nie ma nadpisywania zmiennych przy użyciu taska `script`

Pomijanie typu przy słowie kluczowym `new`