Dzień dobry! Ostatnio miałam okazję uczestniczyć w CityJS London 2022 i chciałabym podzielić się z Wami wrażeniami oraz wiedzą. Wpis jest lekko kontrowersyjny i nie ma na celu nikogo urazić, zawiera moje odczucia.

TL;DR: To była przeciętna konferencja, która miała wiele problemów zarówno z treścią jak i organizacyjnych.

Musimy zacząć od tego, że lubię konferencje. Jest to magiczny czas, kiedy mam okazję na programistyczne wybudzenie się z zimowego snu i nadrobienie nowości. W tamtym roku część wykładowa CityJS trwała trzy dni a w tym tylko jeden. Nie miałam nic przeciwko, wprost przeciwnie: wydawało mi się, że poprawi to jakość.

Niestety całość była dla mnie bardzo męcząca:

• ogromna ilość powtarzających się reklam

Rozumiem, że konferencje nie są organizowane za darmo a sponsorzy wymagają sporej ekspozycji, ale połowa konferencji wydawała się jednym wielkim blokiem reklamowym.

• dużo wykładów nietechnicznych

Liczyłam, że na CityJS będzie więcej o programowaniu. Tak po prostu.

• krótkie wykłady, które były i tak za długie

Czas który mieli prelegenci był za krótki na dokładne wyjaśnienie technicznych detali, więc część zdecydowała się na prezentacje nietechniczne a druga przyśpieszała i pomijała slajdy. Często czułam spory niedostatek pomiędzy postawionymi problemami a przedstawionymi rozwiązaniami.

Najciekawsze prezentacje i wykłady

Niemniej jednak kilka prezentacji mnie zainteresowało i chciałabym skrócić części, które uznałam za wartościowe :)

Pomysł Maggie Appleton - komunikacja przez wizualizacje

Maggie zawodowo zajmuje się designem i wyjaśniła, że skomplikowane pojęcia oraz koncepcje najłatwiej zrozumieć przez wizualizacje, obrazy oraz diagramy.

Najciekawszą częścią było wyjaśnienie metafor kognitywnych. Metafora często kojarzy nam się z literaturą i nie zauważamy jak podświadomie używamy jej w programowaniu. Czym innym jest 'kontener' jak nie metaforą zamknięcia i izolacji? Co mówią nam pojęcia 'zmienna' i 'stała'? Z czym kojarzy się nam 'front' (czyli pierwsze co widzimy) a z czym 'backend'?

Zupełnie pominę część o programowaniu wizualnym, bo mam mieszane uczucia wobec konceptu. Istnieją wizualizacje skryptów w Game Devie (na przykład w Unity), które pozwalają na programowanie poprzez interakcje z interfejsem graficznym i jest to sprawdzone rozwiązanie, jednak - jak zauważyła prelegentka - kod w formie wizualnej fatalnie się skaluje do dużych rozmiarów.

Web Monetization API

Jak można zarabiać na swojej twórczości? Jakie opcje mają twórcy internetowi? Alex Lakatos opowiadał o pracach nad Web Monetization API.

Koncepcja Web Monetization API jest prosta: bezpośredni, bezpieczny przepływ pieniędzy pomiędzy twórcą a odbiorcą.

Wydaje się to proste, ale po drodze istnieje wiele problemów.

Portale pośredniczące takie jak Patronite czy inne odpowiedniki pobierają procent od zarobków, banki pobierają prowizje za transakcje a paypal nie jest dostępny wszędzie. Obecny układ sił na rynku finansów sprawia, że drobne datki (na przykład jednodolarowe) są zupełnie nieopłacalne, gdyż koszt takiej transakcji to 30% darowizny.

Koncepcja w której każdy może wpłacić drobną kwotę bez opłat wydaje się idealna.

A teraz zobaczcie interfejs w... HTMLu!

Obecnie jest wspierany przez Chrome, Firefoxa, Edge oraz w przyszłości Safari.

<meta
  name="monetization"
  content="zewnetrznylinkdoportfela.com/kontokamili">

Podejrzanie proste? Tak, płatności będą obsługiwały zewnętrzne firmy korzystające z protokołu stworzonego przez Alexa.

Trzymajcie kciuki!

WebXR - rozszerzona rzeczywistość dla każdego

Rozszerzona rzeczywistość (ang. augmented reality) to gorący temat, szczególnie jeśli podejrzewamy ile zainwestuje w to Facebook z powodu Metaverse. W prezentacji został przedstawiony bardzo przyjazny interfejs webowy, który pozwala tworzyć wirtualne światy mieszające się z naszym przy użyciu np. kamerki z telefonu komórkowego. Pomimo problemów technicznych prelegentce udało się pokazać część możliwości API.

Najbardziej zaskoczyły mnie dwie rzeczy:

• mnogość interfejsów - można tworzyć wirtualną rzeczywistość zarówno przez Javascript jak i... "HTML": AFrame niewiarygodnie łączy znaczniki i VR.
• bardzo dobrze uproszczone koncepcje oświetlenia czy cieni: props tu, props tam i mamy światłocień :)

Z resztą słowa tutaj nie wiele zdziałają, zobaczcie przykłady na oficjalnej stronie WebXR oraz tutaj.

Jak wybierać biblioteki w npm?

Jeden z wykładów opowiadał o tym jak wybiera się biblioteki open source do użycia w większych firmach i do większych projektów. Dlaczego express.js a nie nest.js?

W wielkim skrócie jest to suma poniższych aspektów:

• wsparcie społeczności (dokumentacja, odpowiadanie na pytania)
• ilość użytkowników (gwiazdki, pobrania)
• rozwiązywalność bugów oraz aktualizacje (jak szybko, jak często)
• ilość kontrybutorów (paczki posiadające jednego głównego kontrybutora są ryzykowane)
• możliwość kontrybucji do biblioteki z zewnątrz

GraphQL schema-stiching

Było kilka wykładów o GraphQL. W pracy korzystam z federacji (Apollo Federation), która łączy serwisy różnych zespołów i jest powszechnie preferowanym rozwiązaniem. Niemniej jednak z ciekawością słuchałam o schema-stichingu. Jest to opcja dla zespołu zajmującego się wieloma serwisami z małym budżetem, chcącego uniknąć zarządzania federacją.

Mateo Collina - GraphQL caching demystified

Bezsprzecznie najlepsza prezentacja, którą widziałam na CityJS 2022 London. Wciąż jestem zafascynowana opowieścią Mateo Collina, który rozwija bibliotekę GraphQL do Fastify. Liczby świadczące o wydajności Fastify i Mercuriusa względem konkurencji i natywnych rozwiązań powalają. Mercurius Cache wyraźnie podnosi wydajność zapytań out-of-the-box, nie mówiąc o tym gdy jest dobrze połączony z Redisem. A to jak go dobrze połączyć z Redisem to najlepsza część wykładu, której nie chcę wam opowiadać: zobaczcie to w Internecie koniecznie.

Mateo polecił kilka tooli i bibliotek, którymi warto się zainteresować:

• AutoCannon - benchmark dla zapytań API
• Flame (ClinicJS) - ułatwia analizę zapytań w twoim kodzie
• undici - super szybka konkurencja dla axiosa

Wybitny wykład i szkoda, że tak szybko się skończył.

PWAs: the new frontier by Diego Gonzalez

PWA to genialna koncepcja - aplikacja webowa która działa również jako desktopowa czy mobilna. Jest to dosłownie marzenie web developera. Chociaż Google - moim zdaniem - przestało stawiać na to rozwiązanie, Microsoft wciąż inwestuje w rozwój PWA. I to nie bez przyczyny: duże korporacje takie jak Spotify z powodzeniem go stosują.

Jednak moja ekscytacja nie jest szczera, od dawna mam problem z prezentacjami Microsoftu. Prowadzą je świetni, inteligentni i zbyt spokojni ludzie, którzy zabijają mój entuzjazm. To jest pomysł, którego nie trzeba nawet sprzedawać - potrzebujemy PWA i absolutnie nie wiem skąd moje mieszane uczucia.

Zanim zaczniemy się rzucać na PWA patrząc tylko na pozytywny: szybkość developmentu, możliwość aktualizacji, działanie offline to musimy zdać sobie sprawę, że jest jeszcze wiele do zrobienia.

Głównie dotyczy to integracji z innymi platformami niż Microsoft. Chciałabym zakupić apkę PWA w Google Play tak jak w Microsoft Store, użyć funkcji mojego telefonu takich jak NFC czy czujniki, których PWA obecnie nie obsługuje. Rynek iOSa jest bardzo silnie chroniony przez producenta urządzeń, więc nie zapowiada się na jakąkolwiek integrację z ekosystemem Apple. Warto dodać, że PWA może wysyłać notyfikacje tylko desktopowo na windowsie oraz mobilnie na androidzie.

Musimy zadać sobie pytanie co jest potrzebne, spisać wymagania i sprawdzić na https://aka.ms/pwa.

Inne ciekawostki

Powstał nowy, bardzo ciekawy logger Pino. Jest kilkukrotnie szybszy niż konkurencja, twórcy mają na to dowody i radzą się mu przyjrzeć uważnie.

Podsumowanie

Konferencja to też dzieło, może trafić na bardziej lub mniej dopasowanego odbiorcę. Tym razem byłam tym mniej dopasowanym. Nie oglądałam również wszystkich wykładów, więc najlepsze mogło mnie ominąć :) Sądzę, że moje i CityJS drogi na jakiś czas się rozstaną, ale nie zamykam się na konferencje i nie taki ma być wydźwięk tego wpisu.

Fakt, że mi coś nie odpowiadało nic nie znaczy.

Jeśli byliście na CityJS London 2022 i chcecie się podzielić wrażeniami to zapraszam. Kilku innych uczestników bardzo sobie ją chwaliło, szczególnie offline. Jeśli byliście na jakiś fajnych konferencjach to podzielcie się proszę, szukam wydarzenia które dobije do jakości SphereIT.

Pozdrawiam serdecznie i dziękuję za uwagę. Mam nadzieje, że dowiedzieliście się fajnych rzeczy :)

Dzień dobry! Dawno nie było nowego wpisu i miło mi tu wrócić :) Zakup nieruchomości zajął mi mnóstwo czasu, ale biuro już się urządza i przygotowałam dla was powitalny wpis. Będzie lekko i prosto, bo zaczniemy od podstaw SQL. Miło mi też widzieć, że czasami tu wracacie, a starsze wpisy są nadal czytane! Dziękuję!

Tak więc, początkujący programiści, ruszajcie do czytania!

Co to jest ten SQL?

SQL to język zapytań w którym porozumiewamy się z relacyjnymi bazami danych. Istnieją różne metody pośrednie takie jak przyjazne użytkownikowi programy z graficznym UI (gdzie wyklikujemy zapytanie SQL) czy ORMy, gdzie zapytania są generowane w czasie działania aplikacji. Niestety nie zawsze są optymalne. Dlatego warto poświęcić czas na naukę SQL :)

Baza danych

Żeby wykonać zapytanie musimy mieć bazę danych. Dzisiaj będzie wirtualna, nie potrzebujemy znać typów.

Definicja bazy: posiada trzy tabele: user, address i łączącą je tabelę relacją wiele do wielu: user_adress.

Tabela user ma pola: uuid, username, email, created_at, updated_at.

Tableta address ma pola: uuid, nip, street.

Tabela user_address ma pola user_uuid oraz address_uuid.

Zadania

Osobiście najlepiej uczę się przez zadania oraz wyzwania, więc prezentuję Wam zadania (dziękuję Aniołowi za pomoc w ich tworzeniu) na rozgrzewkę. Dzisiaj będziemy pobierać dane, użyjemy do tego operatora SELECT, który do tego służy.

Zadanie 1: sortowanie i wybieranie kolumn

Zacznijmy powoli :) Z naszej tabeli chcemy pobrać username i email wszystkich użytkowników i posortować od najdłużej istniejącego. Przejdziemy przez pierwsze zapytanie krokami :)

Najpierw pobierzmy wszystkich użytkowników:

SELECT * FROM user;

Jednak tabela user może mieć bardzo dużo kolumn i części tych danych nie potrzebujemy, więc wybierzmy konkretne:

SELECT username, email FROM user;

Na koniec możemy posortować użytkowników po dacie ich utworzenia, żeby w pierwszej kolejności mieć najdłużej istniejących użytkowników.

SELECT username, email FROM user ORDER BY created_at;

Proste, prawda?

Zadanie 2:  Filtrowanie danych poprzez WHERE

Teraz pobierzemy tylko tych użytkowników, którzy posiadają numer telefonu.

Do stawiania warunków w zapytaniu służy operator WHERE , wykorzystamy również IS NOT oraz NULL (zwykle nieobowiązkowe wartości są NULLami, jeśli ich nie wypełnimy).

SELECT username, phone FROM user WHERE phone IS NOT NULL;

W ramach ćwiczenia można również spróbować wylistować użytkowników, którzy nie podali swojego numeru telefonu żeby wysłać im przypomnienie:

SELECT username, phone FROM user WHERE phone IS NULL;

Zadanie 3: LIKE

Bardzo przydatny jest operator LIKE które w przeciwieństwie do porównania pozwala szukać wyrażeń na początku, w środku i na końcu stringa, w różnych kombinacjach. Najczęściej używa do tego znaków _ oraz %, gdzie _ odpowiada za jeden znak a % za dowolny ciąg znaków (włączając pusty).

Teraz wybierzmy sobie użytkowników z mailami w domenie gmail.com:

SELECT username, email FROM user WHERE email like '%@gmail.com';

Można je dowolnie mieszać. Na przykład możemy szukać maili z dowolną końcówką. Google akurat nie oferuje takiej opcji, ale żeby kontynuować przykład:

SELECT username, email FROM user WHERE email like '%@gmail.%';

To wyrażenie niestety złapie także imie.nazwisko@gmail.kotek oraz imie.nazwisko@gmail. i w teorii możemy coś na to poradzić.

Jeśli mówimy o rozwiązaniach produkcyjnych to nie szłabym w tę stronę, ale istnieje w SQL narzędzie do budowania czegoś w stylu wyrażeń regularnych i wygląda to mniej więcej tak:

1. [] wyszukuje znaki znajdujące się w kwadratowych nawiasach np.: przez wyrażenie k[o]t przejdzie 'kot', ale już nie 'kat'. Przez wyrażenie k[ao]t przejdzie zarówno 'kot' jak i 'kat', ale nie 'kit'
2. [^] wyszukuje znaki nie znajdujące się w kwadratowych nawiasach. Na przykład przez wyrażenie k[^i]t przejdzie 'kot', 'kat', ale ponownie nie 'kit'.
3. [a-c] wyszukuje przedział znaków, np.: tutaj znaki od a do c włącznie. Przykładowo przez wyrażenie k[a-i]t przejdzie zarówno 'kat' jak i 'kit', ale już nie 'kot', bo literka 'o' jest poza przedziałem od 'a' do 'i'.

SELECT username, email from user where email like '%@gmail.__%';

Nie wiem czy chcę dalej brnąć w koty, katów i kit, więc przejdźmy dalej :)

Zadanie 4: LEFT JOIN

Teraz pobierzmy dane z dwóch tabel na raz, wyszukując użytkownika wraz z nipem jeśli istnieje w bazie.

Tego typu operacje robi się poprzez JOIN. Istnieje kilka rodzajów, troszkę się od siebie różnią, ale zaczniemy powolutku.

LEFT JOIN wraca wszystkie wyniki z lewego zapytania i dopasowuje istniejące z prawego. Dlatego gdy wywołamy poniższe zapytanie dostaniemy wszystkich użytkowników i nipy ich firm jeśli istnieją. Jeśli nie istnieją to zapytanie zamiast nipu zwróci pustą wartość.

SELECT user.username, address.nip FROM user LEFT JOIN user_address on user.uuid = user_address.user_uuid LEFT JOIN address ON user_address.address_uuid = address.uuid;

Zadanie 5: (INNER) JOIN

Teraz pobierzmy użytkownika o NIPie 3398554396.

Tutaj potrzebujemy tylko użytkowników, którzy mają zdefiniowane adresy, więc zastosujemy JOIN oraz dodamy operator WHERE który pozwoli wyfiltrować wartości.

SELECT username, address.nip FROM user JOIN user_address ON user.uuid = user_address.user_uuid JOIN address ON user_address.address_uuid = address.uuid WHERE address.nip = '3398554396'

Zadanie 6: LIMIT

Rzadko chcemy zwracać wszystkie rekordy z bazy, czasem potrzebujemy tylko kilku najważniejszych. Przykładowy przypadek: trzech najdłużej istniejących użytkowników dostanie rabat. Oto jak ich znaleźć:

SELECT username, email FROM user ORDER BY created_at LIMIT 3;

Podsumowanie

Cieszę się, że wytrwaliście do końca :) Potrzebowałam czegoś na rozruszanie, mam nadzieje, że wpis się przyda. Jak zwykle zapraszam do komentowania i poprawiania jeśli zauważycie błąd.

Trzymajcie się i nie przestawajcie uczyć!

Dzień dobry, mam nadzieje, że macie się dobrze i nie przestajecie się uczyć :)

Dzisiaj zapraszam Was na naukę terraforma, który pozwala tworzyć zasoby w chmurze. Jeśli początek Was przestraszył, nie martwcie się, zaczniemy od banałów.

Co to jest ta chmura?

Chmura

Ta mistyczna chmura to po prostu zasoby (serwery, dyski twarde, wirtualne sieci itd.) które możesz dynamicznie wypożyczać/tworzyć w zależności od potrzeb. W większości przypadków płacisz dokładnie za tyle, ile używasz. Jeśli twoja aplikacja ma ruch zwiększony od 16:00 do 19:00 to na ten czas możesz zarezerwować więcej RAMU czy silniejsze CPU dla twojego serwera (co jest trudne w przypadku zwykłego hostingu).

Najpopularniejszymi rozwiązaniami tego typu są Amazon Web Services (AWS), Microsoft Azure oraz Google Cloud. Dzisiaj będziemy korzystać z AWSa, chociaż HCL - jako język - jest uniwersalnym medium.

Infrastructure as a code

Skoro można tak dynamicznie zmieniać zasoby i stawiać środowiska to pojawia się pytanie jak to zrobić. Kiedyś "goście od serwerów" instalowali systemy operacyjne/narzędzia/interpretery, obecnie przesuwa się tę pracę w stronę zespołu programistycznego. Dzięki temu jest w stanie stworzyć i udostępnić aplikację samodzielnie.

Infrastructure as a code to nazwa podejścia w którym piszemy kod, który po wywołaniu tworzy zasoby w chmurze.

A jeśli kod to w jakim języku? Większość dostawców udostępnia swoje narzędzia (API/CLI/etc.) w Javie, C#, JavaScriptcie, ale nie ma wsparcia dla każdego więc powstał unikalny język do tworzenia zasobów w chmurze, czyli HCL.

HCL

Przedmiotem dzisiejszego wpisu jest HCL, czyli HashiCorp Configuration Language na przykładzie użycia w chmurze AWS. Zapoznamy się z jego strukturą.

HCL

HCL posiada dwie podstawowe struktury danych: argumenty oraz bloki.

Argumenty

Argumenty służą do przypisywania wartości do zmiennej.  Nazwa zmiennej może zawierać liczby, litery oraz znaki specjalne: - oraz _.

name = "solutionchaser"
author_name = "kamila"

Bloki

Bloki tworzą struktury danych za pomocą zagnieżdżonych klamer {}:

resource "typStruktury" "nazwaWłasnaStruktury" {
  zmienna = "Hello World"

  struktura wewnętrzna {
    # ...
  }
  tablica = ["kot", "pies"]
}

Komentarze

Z pewnością zauważyliście komentarz w powyższym przykładzie, więc udokumentujmy to jeszcze raz:

# komentarz jednolinijkowy, ten jedyny słuszny
// komentarz jednolinijkowy, nierekomendowany, stworzony żeby trudniej było utrzymać porządek w kodzie
/* komentarz
wielolinikowy */

Terraform

Najpierw polecam zainstalowanie terraforma na naszym komputerze. Jeśli korzystasz Linuxa to będzie to:

snap install terraform

Komendy na inne systemy operacyjne możesz znaleźć pod tym linkiem. Ogólnie polecam zainstalować również tfenv, jeśli zamierzacie używać terraforma pracując w zespole. Pozwala on zmieniać obecnie używaną wersję terraforma.

Dobrze, już powinna zakończyć się instalacja. Poleceniem terraform --help zweryfikujesz czy działa poprawnie.

Terraform to akurat jedna z najprostszych technologii jakie znam. Musisz znać 4 komendy, żeby zacząć:

• terraform init - inicjalizuje stan (zaraz powrócimy do tego ważnego słowa)
• terraform plan - porównuje obecny stan oraz ten który napisaliśmy przez nasz kod i generuje plan zmian
• terraform apply - tworzyć/usuwa/edytuje zasoby w chmurze i zmienia stan
• terraform destroy - niszczy wszystkie zasoby w chmurze zapisanie w stanie
• terraform fmt - formatuje pliki z rozszerzeniem tf

Zmienne

Są tworzone za pomocą bloku variable w którym pierwszy argument to nazwa zmiennej. Mogą mieć typ, opis oraz wartość (zadeklarowaną lub domyślną).

Standardowa deklaracja:

variable "blog" {
  default = "solutionchaser"
}

Zarówno wartość domyślną jak i brak wartości można nadpisać przy wywołaniu kodu, najczęściej przez plik .tfvars.

variable "blog" {}

variable "blog" {
  type    = string
  default = "solutionchaser"
  description = "This variable describes blog's name"
}

Powyższa deklaracja jest typowa: definiuje typ oraz dodaje opis przydatny przy czytaniu kodu oraz generowaniu dokumentacji. Poniżej mamy przykład zmiennej typu lista:

variable "favourite_food_list" {
  type    = list(string)
  default = ["kefir", "borówki"]
}

HCL korzysta z typów prostych: string, boolean, numer oraz typów złożonych: list, map, set, turple oraz object, których nie będziemy dzisiaj szczegółowo omawiać.

Zmienne lokalne (ang. locals)

Zmienne lokalne również mogą deklarować statyczne wartości, ale najczęściej używa się ich do tworzenia zmiennych z innych zmiennych. Spójrzmy na poniższy przykład:

variable "blog" {
  default = "solutionchaser"
}

locals {
  blog   = var.blog #w starszych wersjach terraforma to będzie "${var.blog}"
  domain = "${var.blog}.com"
  author = "Kamila Brylewska"
}

Dostawcy (ang. Providers)

Jak mówiłam wcześniej istnieje wielu dostawców chmury (Amazon, Microsoft etc.) i każdy ma swoje zasoby, strukturę i możliwości dlatego zwykle terraformowanie zaczynamy od zadeklarowania dostawcy.

Musimy także określić wersję sterownika, który zostanie pobrany na nasz komputer i będzie służył do komunikacji z chmurą.

Poniżej mamy przykład deklaracji Amazon Web Services jako dostawcy.

terraform {
  required_providers {
    aws = "~> 1.0"
  }
}

Zasoby (ang. Resources)

Zasoby to ładna nazwa na poszczególne usługi oferowane w chmurze takie jak - jeśli wybaczycie powtórzenia - wirtualna prywatna sieć, wirtualny dysk czy wirtualny serwer.

resource "aws_instance" "NazwaZasobuNpMojSerwerInternetowy" {
  ami           = "ciągZnaków"
  instance_type = "t2.micro" # wartości które możesz tutaj wpisać są       zdefiniowane w dokumentacji AWS
}

Dane wyjściowe (ang. output)

Terraform po stworzeniu zasobu w chmurze zwróci nam szczegóły utworzonego komponentu np.: identyfikator. Możemy go wypisać w konsoli lub użyć do stworzenia innego zasobu.

Dane (ang. Data)

Jeśli potrzebujemy informacji z chmury, na przykład identyfikatora czy nazwy jakiegoś zasobu, możemy je pobrać przy pomocy data i wykorzystać pobrane dane do stworzenia nowego elementu naszej infrastruktury.

Inne

Terraform oferuje także wbudowane funkcje oraz możliwość tworzenia/korzystania z gotowych modułów, ale opisanie tego nie jest sednem dzisiejszego wpisu.

Stwórzmy coś!

Skoro już mniej więcej wiesz co jest co, to na sucho wytłumaczę jak tworzy się zasoby w chmurze.

1. Napiszmy kod

Code as infrastructure zakłada obecność kodu, więc napiszemy kod, który utworzy wirtualny dysk dla nas. Ten dysk jest o tym fajny, że płacimy tylko za GB które zajęliśmy i za transfer danych. W Amazonie ten zasób nazywa się wiaderkiem s3 i - z pełną świadomościa jak zabawnie to brzmi - zamierzam go tak nazywać.

Mamy projekt, tworzymy folder terraform i plik s3.tf.

// plik s3.tf
terraform {
  required_providers {
    aws = "~> 1.0"
  }
}

resource "aws_s3_bucket" "MojeWiadro" {
  bucket = "moje-wiadro-solution-chaser" #unikalny identyfikator w chmurze. Jeśli go nie podasz to AWS wygeneruje nieczytelny ciąg znaków

  tags = { #tagi pomagają kategoryzować i grupować zasoby w chmurze
    Author      = "Kamila"
    Environment = "prod"
  }
}

Teraz zainicjujemy lokalny stan wykonując w folderze terraform komendę:

terraform init

Po skończeniu inicjalizacji zauważycie, że powstał folder .terraform w którym znajduje się plik z sterownikami oraz plik terraform.tfstate.

Plik tfstate jest jedynym źródłem prawdy o zbudowanej przez nas infrastrukturze. W chwili obecnej mamy go w lokalnie, ale najczęściej korzystamy z pliku w chmurze, co nazywa się backendem.

Jeśli chcemy zobaczyć jakie zmiany zostaną wprowadzone to możemy wpisać:

terraform plan

Wykonanie tej komendy pokaże nam ile zasobów zostanie stworzonych, zmienionych i usuniętych oraz dokładne zmiany.

Dobrze, to utwórzmy wirtualny dysk:

terraform apply

To jest moment w którym zostają utworzone zasoby w chmurze, aktualizuje się stan i zaczynamy ponosić koszta.

Dlatego, szczególnie w przypadku droższych zasobów, powinniście teraz wykonać:

terraform destroy

Komenda ta usunie zasoby z chmury, zaktualizuje stan oraz zakończy naukę na dzień dzisiejszy. Samą historię jak skorzystać z tego wirtualnego dysku zostawiam na inny dzień :)

Podsumowanie

Ostatnio spędzam w chmurach... znaczy w chmurze mnóstwo czasu i świetnie się bawię. To magia, że jako developer mogę utworzyć sobie środowisko swoich marzeń w kilkanaście sekund i równie szybko je usunąć.

Bardzo przepraszam za uogólnienia i zapraszam do komentowania. To niestety ułamek wiedzy z terraforma, który jest potrzebny do stworzenia infrastruktury aplikacji internetowej, nie mówiąc o doświadczeniu serwerowo-sieciowym czy projektowaniu. Niemniej jednak to dobry początek!

Mam nadzieje, że się podobało i bardzo dziękuję za uwagę. Ostatnio dostaję od Was sporo fajnego feedbacku i chciałam bardzo podziękować. Prowadzenie bloga to sama przyjemność, ale posiadanie czytelników dodaje temu uroku.

Powodzenia!

Dzień dobry! Mam nadzieje, że wszystko u was w porządku, 2020 był ciężki, trzymajcie się!

Dzisiaj zabiorę Was na przygodę z Nest.js - biblioteką która wprowadza poważne wzorce i architekturę do aplikacjach opartych na Express.js. Uczciwie przyznam, że od dawna spoglądam tam w poszukiwaniu inspiracji i rozwiązań, więc ten tutorial musiał powstać :)

Z powodu dużej popularności poprzednich wpisów o Node.js zadecydowałam, że będzie to tutorial dla kompletnie zielonych. Nie było to łatwe, gdyż Nest.js wykorzystuje kilka popularnych wzorców, których wytłumaczenie uczyniłoby ten wpis trudniejszym.

Dzisiaj będziemy dodawali, usuwali, edytowali i odczytywali opowiadania za pomocą REST API.

Aby ukończyć ten tutorial powinieneś:

• umieć otworzyć konsolę
• znać podstawy TypeScripta

Instalacja

Zakładam, że macie Node.js w wersji minimum 12. Można to sprawdzić wpisując node -v.

Zainstalujmy Nest.js CLI, która pozwoli na automatyzację niektórych czynności takich jak wygenerowanie podstaw projektu. Linuksiarze, pamiętajcie o uprawieniach przy instalacji globalnej paczki :)

npm i -g @nestjs/cli
// nest new <nazwa_projektu>
nest new tutek

Powyżej mamy wygenerowany projekt o nazwie tutek.  Sprawdźmy czy aplikacja wygenerowała się poprawnie wpisując w folderze tutek komendę:

npm run start

Poczekajmy chwilę aż transpilator skończy pracę, skrypt uruchomi aplikację i wejdźmy na http://localhost:3000/.

Powinniśmy zobaczyć napis Hello World! będący naszym pierwszym sukcesem! Gratulacje!

Teoria Nest.js dla początkujących programistów

Jeśli znasz Nest.js lub przeczytałeś dokumentację to ten podpunkt możesz pominąć. Może być tymczasowym zamiennikiem dla dokumentacji, szczególnie że wybiera kluczowe dla tutoriala kwestie i upraszcza/trywializuje je. Są to uogólnienia skierowane do początkującego programisty i nie powinny być odnośnikiem do żadnych rozważań.

Dzisiaj będziemy używać trzech podstawowych koncepcji z Nest.js: modułów, kontrolerów oraz providerów:

• moduł to klasa grupująca kontrolery i providery. Nie jest jednak obiektem abstrakcyjnym, nastawionym jednie na wrapowanie. Pozwala definiować zależności z innymi modułami (przez importy i eksporty) oraz nakładać globalne właściwości na obiekty które zawiera.
• kontrolery to klasy odpowiedzialne za zapytania i odpowiedzi naszego API. Najprościej mówiąc to dzięki nim mamy dostęp do danych pod adresem URL.
• providery to ogólna nazwa dla pomocniczych klas. Logika/dostęp do danych/generowanie obiektów itd. nie powinna być kodowana w kontrolerze, a w osobnych klasach, gdyż może być tak, że będziemy chcieli z niej korzystać w innym kontrolerze, a kod powinien być reużywalny (w granicach rozsądku).

Moduł Story

Zanim zaczniemy kodowanie wyłączmy poprzedni serwer Node.js zamykając konsolę i otwórzmy nową aby wywołać: npm run start:dev. Ta komenda nie tylko transpiluje aplikację z TypeScripta na JavaScript i uruchamia ją, ale restartuje serwer po każdej zmianie w kodzie.

Po wygenerowaniu projektu powinniśmy mieć wygenerowany folder src:

• usuńmy wszystkie pliki ts poza plikami: app.module.ts i main.ts.
• stwórzmy folder story

W folderze story utwórzmy plik story.module.ts. Prosta aplikacja Nest.js będzie składała się z połączonych ze sobą modułów których struktura znajdzie odzwierciedlenie w logice.

// /src/story/story.module.ts
import { Module } from '@nestjs/common';
import { StoryController } from './story.controller';
import { StoryService } from './story.service';

@Module({
  controllers: [StoryController],
  providers: [StoryService],
})
export class StoryModule {}

Moduł jest miejscem w którym importujemy (czyli czynimy nasz moduł Story zależnym od tego zasobu) oraz eksportujemy (czyli pozwalamy innym modułom korzystać z naszego moduł Story). Moduł może zawierać dużo więcej, nasz będzie jednak pustą definicją klasy, w której - za pomocą dekoratora - importujemy kontroler StoryController w który będzie zdefiniowane nasze API oraz serwis StoryService z którego będziemy pobierać dane.

Struktura danych

W naszej aplikacji będziemy wykorzystywać dwa typy (zalecane przez developerów Nest.js):

• interfejs Story
• klasę createStoryDTO
• powinny jeszcze istnieć analogiczne klasy DTO, na razie popełnijmy świadomy błąd żeby wszystko uprosić

Mam nadzieje, że wiecie co to jest interfejs, z DTO sprawa wymaga wytłumaczenia. DTO to typ obiektów które będziemy przesyłać po HTTP. Na przykład - jak zobaczcie w przykładzie - tworząc Story nie potrzebne jest przesyłanie całego obiektu. Ba! Jest to niemożliwe, bo nie znamy jego id PRZED utworzeniem.

export interface Story {
    id: string;
    name: string
}

src/story/dto/createStory.dto.ts
import { Story } from "../interfaces/story.interface";

export class createStoryDto {
    public name: string
}

Nie zaszalałam, prawda? Prosto i klarowanie :)

Serwis StoryService

StoryService jest punktem z którego w całej aplikacji będziemy pobierać dane o Story. Zwykle serwis odwołuje się do jakiegoś źródła, na przykład bazy danych. Dzisiaj jednak - na potrzeby tutoriala - będziemy trzymać dane w pamięci co oznacza, że będą istnieć tak długo jak instancja serwera: od uruchomienia node.js do jego zamknięcia/przeładowania.

// src/story/story.service.ts

import { Injectable } from '@nestjs/common';
import { Story } from './interfaces/story.interface';

@Injectable()
export class StoryService {
  private stories: Story[] = [];

  constructor() {
    // możecie to odkomentować jeśli chcecie mieć jakieś dane na początku
    // this.stories.push({ id: '2', name: 'ExampleStoryName'});
  }

  getStories(): Story[] {
    return this.stories;
  }

  getStory(id: string): Story {
    return this.stories.find((story: Story) => story.id === id);
  }

  create(newStory: Story): void {
    this.stories.push(newStory);
  }

  remove(id: string): void {
    const index = this.stories.findIndex((story: Story) => story.id === id);
    if (index > -1) {
      this.stories.splice(index, 1);
    }
  }

  update(newStory: Story): void {
    this.stories = this.stories.map((story: Story) => story.id === newStory.id ? newStory : story);
  }
}

Klasa StoryService posiada dekorator o nazwie @Injectable. Jeśli chcecie się w to zagłębić to warto poczytać o wzorcu Dependency Injection, dzisiaj wystarczy Wam informacja, że jest konieczny aby przekazać w module StoryModule klasę do  providers.

Następnie inicjalizujemy prywatną właściwość (property) stories, które będzie naszym źródłem danych :).

Mam nadzieje, że metody są jasne, ale podsumujmy:

• metoda getStories zwraca wszystkie story w pamięci
• metoda getStory(id) zwraca story o id równym parametrowi.
• metoda create(story) tworzy nowe story
• metoda remove(id) usuwa story o danym id
• metoda update(story) uaktulnia story o danym id

Kontroler StoryController

Kontroler - jeśli chodzi o back-end w Nest.js - jest klasą odpowiadającą za endpointy (czyli dostępne w API ścieżki takie jak http://mojastrona.pl/story). Kontrolery w Nest.js są ograne za pomocą biblioteki routing-controllers o których możecie przeczytać w moim poprzednim wpisie: tutaj.

// src/story/story.controller.

import { Controller, Get, Put, Delete, Param, Body, Post } from '@nestjs/common';
import { createStoryDto } from './dto/createStory.dto';
import { Story } from './interfaces/story.interface';
import { StoryService } from './story.service';

@Controller('/story')
export class StoryController {
  constructor(private readonly storyService: StoryService) {}

  @Get()
  getStories(): Story[] {
    return this.storyService.getStories();
  }

  @Get(':id')
  getStory(@Param('id') id: string): Story {
    return this.storyService.getStory(id);
  }

  @Post()
  createStory(@Body() updateCatDto: createStoryDto) {
    // proszę tak nie robić, to powinno zostać utworzone inaczej
    // przez generowanie UUID;
    // często id tworzy za nas baza danych przez autoinkrementację
    const id = `${Math.floor(Math.random() * 1000)}`;
    this.storyService.create({...updateCatDto, id });
  }

  @Put(':id')
  updateStory(@Param('id') id: string, @Body() updateCatDto: createStoryDto) {
    this.storyService.update({ ...updateCatDto, id });
  }

  @Delete(':id')
  removeStory(@Param('id') id: string) {
    this.storyService.remove(id);
  }
}

Klasa StoryController jest oznaczona dekoratorem @Controller. Przyjmuje on jako parametr string, który jest ścieżką bazową dla całego kontrolera. Warto wspomnieć, że ten dekorator zmienia odpowiedź (jak to dekorator) i domyślnie wszystkie obiekty zostaną zwrócone jako JSON. Nie trzeba nic robić, wszystko dzieje się pod spodem dzięki mocy Nest.js.

W powyższym kontrolerze stworzone są metody udostępniające poniższe ścieżki:

• GET http://localhost:3000/story/ zwracająca tablicę obiektów Story
• GET http://localhost:3000/story/{id} zwracająca pojedynczy obiekt Story
• PUT http://localhost:3000/story/{id} zmieniająca obiekt o id 2 na podstawie przesyłanych danych
• DELETE http://localhost:3000/story/{id} usuwający obiekt o id równym 2
• POST http://localhost:3000/story/ tworzący nowy obiekt na podstawie przesłanych danych

Podłączenie modułu Story do App

Jeśli usunęliście niepotrzebne pliki z modułu App jak napisałam wcześniej to powinniście mieć app.module.ts i main.ts. Ten pierwszy musimy lekko zmodyfikować.

// src/app.module.ts
import { Module } from '@nestjs/common';
import { StoryModule } from './story/story.module';

@Module({
  imports: [StoryModule],
})
export class AppModule {}

Uruchomienie i testowanie

Jeśli uruchomiliście aplikację za pomocą npm run start:dev i odkomentowaliście linijkę w contructorze StoryService to przy tworzeniu tego obiektu powinno dodać się jedno Story i możemy je zobaczyć wpisując w przeglądarkę http://localhost:3000/story.

Gratulacje! Twoje API zwraca dane.

Teraz pewnie zastanawiasz się jak przetestować resztę. Masz wiele wyjść, ale ja proponuję dwa narzędzia:

• biblioteka curl korzysta z terminala/konsoli żeby wysłać zapytanie i zwraca odpowiedź
• Postman to program w którym można wyklikać, pobierać, zapisywać, katalogować zapytania, ustawiać zmienne itd. Można też wyklikać tylko proste zapytanie i wysłać.

Osobiście używam Postmana w którym wybieram typ zapytania z dropdowna, wpisuję ścieżkę i potem Body -> Raw i wybieram Content-Type jako JSON z dropdowna.

Używając curl w ten sposób będziecie dodawać nowe story: curl -v -X POST -H "Content-Type: application/json" -d '{"name":"Testowa nazwa"}' http://localhost:3000/story.

Teraz po odświeżeniu strony powinniście zobaczyć nowe story pod adresem http://localhost:3000/story.

Podsumowanie

Mam nadzieje, że dzisiaj w godzinę albo dwie napisaliście ze mną swoje pierwsze API przy użyciu Nest.js. Czeka nas jeszcze dużo pracy związanej z walidacją danych, podłączeniem bazy, autoryzacją i obsługą błędów, jednak mam nadzieje, że widzicie jak prosto można stworzyć szkielet.

Pozdrawiam Was serdecznie i dziękuję za poświęcony czas. Jeśli się spodobało, skorzystaliście lub znaleźliście błędy to zapraszam do komentowania i dyskusji.

Materiały do uzupełnienia wiedzy

Ten wpis miał być krótki i treściwy, a wręcz dowodzić jak można pozwolić komuś na naukę, której mi jest najbliżej: modyfikację gotowych rozwiązań i naukę poprzez czytanie kodu. Mam jednak wielkie parcie na szerzenie wiedzy, więc dla ciekawskich zostawiłam kilka linków:

• co to jest ten dekorator (oznaczony @)? FSGeek dobrze to tłumaczy w tym artykule.
• co to jest Dependency Injection? O tym opowie Wam Michał z TypeOfWeb w tutaj.
• Trochę teorii o tworzeniu API oraz HTTP opowiedzą dwaj Grzegorze: Grzesiek z DevMobile.pl w tym wpisie i Grzesiek z gregkaqa.pl tutaj przy okazji pokazując Wam Postmana (bardzo polecam).

Dzień dobry!
Mam nadzieje, że jesteście zdrowi i chętni do nauki, bowiem ruszamy z kolejną częścią serii o konteneryzacji. Pierwszą możecie przeczytać tutaj gdzie wyjaśniam podstawy dockera :)

Oczywiście polecam mojego instagrama oraz staram się wrócić na Twittera ze śmieszną poezją developerską. Serio.

Segment reklamowy zakończony, więc kodujmy:
Zastanawiałam się jak ugryźć temat, żeby nie zasypać Was setką informacji i nie zrobić z tego wpisu książki. Szczególnie że ostatni wpis się udał. Inspiracja przyszła z pracy tak więc zaczynamy!

Dzisiejszy przypadek

Dzisiejszy use case będzie polegał na skomunikowaniu dwóch kontenerów. W jednym odpalimy aplikację nodejsową, a w drugim pobierzemy zwróconą informację z homepage'a :)

Jeden (yml) by rządzić wszystkimi

Skoro mamy dockera to możemy tworzyć dowolną ilość obrazów i kontenerów, więc po co nam dodatkowe narzędzie? Odpowiedź jest prosta: żeby było łatwiej.

Docker-compose to narzędzie, które pozwala nam na zarządzenie wieloma kontenerami włączając dzielenie zasobów. Wszystko dzieje się poprzez plik yml oraz proste komendy.

Dzisiejszy przykład w którym mamy dwa kontenery z pewnością nie byłoby dużym problemem, ale pomyślmy jaki chaos wprowadziłoby pięć czy siedem. Dlatego powstała usługa docker-compose.

Zacznijmy od instalacji dockera oraz docker-compose. Osobiście korzystam z snapów na Ubuntu:

sudo snap install docker

Można się też posiłkować dokumentacją dla apt-get tutaj, ale wymaga to trochę więcej pracy. Polecam snapy, więcej możecie przeczytać o nich w moim artykule na devenv.pl.

Zacznijmy od napisania pliku yml. Tradycyjnie nazywa się docker-compose.yml, ale nie musimy mieć tylko jednego, więc pewnie spotkacie docker-compose.tests.yml czy docker-compose.local.yml.

Konstrukcja pliku docker-compose.yml

Pierwsza linijka jest wersją formatu pliku konfiguracyjnego docker-compose.yml, która powinna się zgadzać z zainstalowaną wersją dockera (nie docker-compose).

Można to sprawdzić za pomocą poniższych komend:

docker-compose -v 
// docker-compose version 1.25.5 <- nie chodzi o tę wersję
docker -v
// Docker version 19.03.11, build dd360c7 <- tak

Jak widzicie powyżej w chwili pisania tego posta mam wersję 19 i mogę korzystać z wersji pliku 3.8 lub mniejszej wg tabelki w dokumentacji.

Prawdę mówiąc zwykle to nie ma znaczenia, szczególnie w tak prostym tutorialu, ale powinniście mieć tego świadomość.

Następnie wylistujemy dwa serwisy, które - wyjątkowo - nazwiemy po polsku: aplikacja i szperacz, odpowiadające za dwa kontenery. Aplikacja będzie typowym serwisem webowym, a szperacz może być dosłownie wszystkim co powinno mieć dostęp do aplikacji (jakiś crawler, skrypt wykonujący testy e2e, czy jakiś health check).

Przykładowy plik YML:

version: "3.8"
services:
  aplikacja:
    tty: true
    build:
      context: .
      dockerfile: ./Dockerfile.aplikacja
    volumes:
      - .:/usr/app/
      - /usr/app/node_modules
  szperacz:
    tty: true
    build:
      context: .
      dockerfile: ./Dockerfile.szperacz
    depends_on:
      - aplikacja

build

Sekcja odpowiedzialna za budowanie kontenera. Można ją opisać skrótowo umieszczając w niej sam kontekst (ścieżkę, której kontekst będzie dostępny w kontenerze) albo jako obiekt z ścieżką do kontekstu oraz ścieżkę do dockerfile'a.

ports

To sekcja w której możemy mapować i udostępniać porty z wewnątrz kontenera na zewnętrz w formacie: zewnętrzny_port:wewnętrzny_port np.: 5001:5002. Jeśli chcemy zmapować ten sam port to możemy skorzystać z skrótu: 5000 (zamiast 5000:5000).

environment

Lista zmiennych środowiskowych (environment) jest odpowiedzialna za zmienne które z powłoki (np.: będziemy mogli je przekazać przy uruchomieniu) trafią do kontenera. Często wykorzystuje się je do przekazywania sekretów.

depends_on

Pozwala uruchamiać kontener w określonej kolejności. Jeśli serwis A jest zależy od serwisu B, to może kontener serwisu B powinien się uruchomić pierwszy? Zwrócę szczególną uwagę, że dotyczy to uruchamiania kontenerów, a nie aplikacji w kontenerze.

tty

Ten parametr odpowiada za wyświetlanie z którego kontenera pochodzi informacja w konsoli. Przydatne do nauki :)

Uruchamianie

Żeby nie przedobrzyć na początek musicie wiedzieć, że kontenery się tworzy i uruchamia. Tworzy się poprzez komendę docker-compose build a uruchamia poprzez docker-compose up. Nie wykańcza to tematu ale na razie to wystarczy.

Czego potrzebujemy aby zbudować naszą aplikację:

• docker-compose.yml - plik który pozwoli utworzyć i skomunikować dwa kontenery
• Dockerfile.aplikacja - plik odpowiadający za szczegóły kontenera naszej aplikacji
• Dockerfile.szperacz - plik odpowiadający za szczegóły naszego szperacza
• package.json - plik który skopiujemy do kontera, żeby prosto zainstalować zależności naszej aplikacji
• server.js - nasza wielce skomplikowana aplikacja z poprzedniego tutoriala

server.js

To prosty plik, który korzystając z frameworka express zwraca wiadomość Hello guys! Kamila is here i słucha na portcie 8080.

// server.js
const express = require('express');
const app = express();

app.get('/', function (req, res) {
  res.send('Hello guys! Kamila is here');
});

// 8080 to przykładowy port
app.listen(8080, function () {
  console.log('Example app listening on port 8080!');
});

package.json

To prosty plik z jedną dependencją.

{
  "name": "solutionchaser",
  "version": "1.0.0",
  "description": "Blog post",
  "main": "server.js",
  "author": "Kamila",
  "license": "OhPlease",
  "dependencies": {
    "express": "^4.15.3"
  }
}

Dockerfile

Dockerfile służy do zdefiniowania obrazu. Można zainstalować wszystko samemu, ale istnieją również gotowe rozwiązania. Możemy również używać gotowych rozwiązań i rozszerzyć je.

FROM

Komenda FROM służy do rozszerzania obraz z innego. Działa to w prosty sposób: najpierw wykonuje się Dockerfile z polecenia FROM. Obrazy mogą pochodzić z naszego repozytorium, z prywatnych plików lub - najczęściej - dockerhuba (taka biblioteka dockerowych obrazów).

WORKDIR

Zmienia katalog w którym pracuje/wykonujemy komendy/etc. To jest dosłownie work dir - katalog w którym pracujesz.

RUN

Odpala komendy podczas builda, czyli tworzenia się kontenera (nazwanie tego instalacją to przesada, ale w czasie tworzenia kontenera zwykle instalujemy potrzebne rzeczy).

CMD

Odpala komendy podczas up, czyli uruchamiania kontenera.

COPY

Kopiuje podany plik lub folder do katalogu w kontenerze. Składania jest prosta: pomiędzy jednym a drugim argumentem jest spacja. Na poniższym przykładzie mamy: skopiuj plik server.js z dostępnego kontekstu (context w docker-compose.yml) do katalogu w którym obecnie jestem w kontenerze.

COPY ./server.js .

Dockerfile.aplikacja

Podobnie jak w poprzednim tutorialu uruchomimy nasz serwer. Korzystamy z obrazu node:12-apline, który zawiera bardzo mały system alpine i nodejs w wersji 12 :)

FROM node:12-alpine 

WORKDIR /app

COPY ./server.js .
COPY ./package.json .

RUN npm i

CMD [ "node", "server.js"]

Potem zmieniamy katalog, kopiujemy dwa niezbędne pliki do głównego katalogu (wyznaczonego przez WORKDIR), instalujemy zależności, które utworzą node_modules, a potem odpalamy aplikację.

Dockerfile.szperacz

W tym Dockerfilu użyjemy obrazu nodejs z strechem, ponieważ zawiera curla, który potrafi odpytywać serwery HTTP. Nie jest to dobre wyjście, ale myślę, że ten tutorial na tym nie ucierpi.

Ciekawe jest to, że aby połączyć się do innego kontenera możemy użyć nazwy serwisu z docker-compose.yml.

FROM node:12-stretch

WORKDIR /app

CMD curl http://aplikacja:8080

docker-compose.yml

Oto nasz docker-compose.yml, gdzie można zobaczyć wszystkie opisane wcześniej rzeczy.

version: "3.8"
services:
  aplikacja:
    tty: true
    build:
      context: .
      dockerfile: ./Dockerfile.aplikacja
  szperacz:
    tty: true
    build:
      context: .
      dockerfile: ./Dockerfile.szperacz
    depends_on:
      - aplikacja

Wywołanie

Teraz wystarczy tylko:

sudo docker-compose build
sudo docker-compose up

Dlaczego z podwyższeniem uprawień? Na potrzeby tutoriala, taka jest natywna polityka dockera. Poprawnym wyjściem byłoby dodanie naszego użytkownika do grupy docker z odpowiednimi uprawieniami, ale nie chcę komplikować zbyt bardzo.

No i czekamy :)

aplikacja_1  | Example app listening on port 8080!
szperacz_1   | Hello guys! Kamila is here
dockersample_szperacz_1 exited with code 0

Co się stało?
Najpierw poprawnie zbudowały się oba kontenery, uruchomił serwis aplikacja, a potem szperacz. Aplikacja zwróciła informację o tym, że apka nodejs już działa, a potem szperacz zapytał naszą apkę o dane z głównego endpointa.

Na końcu szperacz się wyłączył (bowiem zakończył swoją pracę wykonując wszystkie komendy), a aplikacja wciąż działa (nieskończenie czeka na zapytania, bo komenda node server.js nic nie zwróci).

Pełen sukces!

Warto jednak zauważyć, że przypadkiem jest, że serwer nodejs był gotowy gdy szperacz wywołał curl'a. Parametr depends_on czeka na uruchomienie kontenera, a nie wszystkich wykonywanych w nim poleceń. Pozostaje więc pytanie: jak to bezpiecznie synchronizować? Zagadnienie opisuję kilka akapitów niżej :)

Problemy i ciekawe zagadnienia

Nie starczy mi czasu i miejsca - a Wam cierpliwości - żeby opisać wszystkie potencjalne problemy i rozwiązania. Nawet nie zakończyłam podstaw docker-compose i niestety w tym wpisie nie starczy mi czasu na pozostałe zagadnienia.

Kilka słów o debugowaniu: gdy coś nie działa, a informacja w konsoli nie wyjaśnia zbyt wiele warto dodać --verbose do zapytania. Wtedy zobaczymy więcej szczegółów, na przykład: docker-compose --verbose up.

Za mało miejsca

Prawdopodobnie podczas swojej nauki doświadczysz informacji o skończonym miejscu na dysku, chociaż twój komputer może mieć jeszcze pełnego miejsca. Chodzi tutaj konkretnie o miejsce przeznaczone na obrazy i kontenery

Docker ma ciekawą politykę, ponieważ nie usuwa sam nieużywanych kontenerów. Jeśli często robisz buildy (np.: przy nauce) to miejsce na dysku może się szybko skończyć. Jak temu zaradzić? Usunąć starocie :)

Ten błąd można wykryć komendą: docker system df. Jeśli w wierszu Images będzie bardzo duży rozmiar oraz wysoki procent pamięci do odzyskania (Reclaimable) to w środowisku developerskim  pomoże docker image prune -a.

Zależność pomiędzy serwisami w kontenerach

Jak wspomniałam parametr depends_on czeka na uruchomienie kontenera, a nie serwera nodejs. Szczególnie gdy aplikacja będzie większa to instalacja dependencji może chwilę czekać i curl w drugim kontenerze odpali się przed uruchomieniem aplikacji. Zwróci wtedy błąd.

Jak to zrobić poprawnie? W poprzednich wersji dockera istniała opcja wbudowanego healthchecku podłączonego z depend_on, ale obecnie dokumentacja sugeruje ręczne sprawdzanie dostępności serwisu.

Bardzo popularnym rozwiązaniem jest skrypt wait-for-it.sh. Można go pobrać z repozytorium do projektu i skopiować do kontenera lub ściągnąć w kontenerze.

Potem zmienić uprawnienia i wywołać. W naszej aplikacji będzie to wyglądało tak:

RUN chmod +x ./wait-for-it.sh
CMD ["/bin/sh", "-c", "wait-for-it.sh aplikacja:8080 --timeout=120 --strict -- curl aplikacja:8080"]

W tej chwili wydaje się to absurdalne (bo trochę jest), ale curl jest tutaj tylko placeholderem.

Co się stało? Nadaliśmy plikowi pozwolenia na wykonywania, a potem wykonaliśmy skrypt wait-for-it.sh. Wykorzystaliśmy dwa parametry: timeout który mówi po ilu sekundach skrypt ma przestać czekać i strict, który mówi o tym, że gdy serwis się nie odnajdzie to ma zwrócić błąd.

Podsumowanie

Mam nadzieje, że się podobało i z chęcią wybraliście się ze mną w dockerową podróż. Miałam z tego ogromną przyjemność i z radością wrócę do tematu (szczególnie zasobów; gdzie network i volumes?).

Jak zwykle zapraszam do komentowania, zostawiania reakcji i komentarzy, jeśli gdzieś źle się wyraziłam lub popełniłam błąd!

Dzień dobry! Mam nadzieje, że macie się dobrze, wakacje minęły pogodnie i jesteście głodni wiedzy. Dzisiaj powrócimy do Vue zaliczając kolejny, niezbędny element z stacku Vue: Vue Router. Zaczniemy prosto dlatego zapraszam wszystkich początkujących do nauki!

Krótki blok reklamowy: Facebook, Instagram. Implementacja - jak zawsze - w TypeScriptcie.

Konfiguracja Typescripta jest w tym poście.

Instalacja

Instalacja Vue Routera polega na pobraniu paczki vue-router:

npm install vue-router

Możemy zacząć od przekazania Vue Routera w konstruktorze Vue, za chwilę go stworzymy:

// front.ts
import Vue from 'vue';
import App from 'Front/components/app.vue';
import { router } from 'Front/routing/router';

const v: Vue = new Vue({
    router,
    el: '#app',
    template: '<App/>',
    components: {
        App,
    },
});

To czas na konfigurację VueRoutera, która na początku będzie polegała na zmapowaniu komponentów i ścieżek. Musimy wiedzieć pod którym adresem wyświetli się jaki komponent.

// Front/routing/router/index.ts
import VueRouter, { RouteConfig } from "vue-router";
Vue.use(VueRouter);

const routes: Array<RouteConfig> = [
    { path: 'login', component: Login},
    { path: '/', component: StoryList},
]
    
export const router = new VueRouter({
    routes
});

Musimy także znaleźć miejsce w aplikacji w którym wyświetlimy komponent z wskazanej ścieżki. Może być to w głównym komponencie, gdy będziemy mieli każdą podstronę inną albo pomiędzy nagłówkiem a stopką, gdy zdecydujemy się na proste SPA.

W perfekcyjne miejsce wkleimy komponent, który pełni rolę slota:

// part of front/components/app.vue   
<template>
    <div class="layout">
        <div class="layout_content">
            <HeaderNavigation></HeaderNavigation>
            <router-view></router-view>
        </div>

        <Footer></Footer>
    </div>
</template>

Ok, to jak sprawdzić czy działa? Najlepiej stworzyć linka i nacisnąć w niego.

Kotwice <router-link>

Zapewne za chwilę zaczniecie się zastanawiać dlaczego nie stworzyć zwykłej kotwicy <a>? Po synchronizacji z paskiem adresu wszystko powinno działać.
Tak, będzie działać, lecz stracimy część funkcjonalności.

Skąd to wynika? Z tego, że gdy linki obsługuje Vue Router to stara się maksymalnie zminimalizować przeładowania. Na przykład gdy będąc na podstronie https://twojastrona.com/#/boo klikniesz w link przekierowujący na tę samą podstronę, nie załaduje się żaden nowy komponent.

To jest jeden z wielu powodów dlaczego warto używać komponentu Vue Routera <router-link> do wewnętrznych linków.

<router-link :to="{ name: ROUTINGS.MAIN }">Nazwa linka</router-link>

Jeśli chcemy wykonać przekierowanie w kodzie wystarczy wykonać metodę push z odpowiednio zbudowanym obiektem.

router.push({ path: '/' });

Proste? To dobrze, podstawy mamy już za sobą!

Parametry w URL

Kolejnym częstym przypadkiem jest parametr w URL. Pokażę Wam jak zaimplementować taki URL: https://twojastrona.com/#/story/5 który otwiera opowiadanie o id równym pięć. Będzie on mapowany z stringa https://twojastrona.com/#/story/:id gdzie :id będzie miejscem wstawienia parametru.

Aby to uzyskać najlepiej aby nasze routingi miały zdefiniowaną unikalną nazwę. Osobiście stosuję enumy, chociaż gdy macie potrzebę iterowania po wszystkich routingach - na przykład w celu stworzenia menu - to równie dobre będą obiekty.

// Front/routing/router/routings.ts
export const ROUTING_URLS = {
    MAIN: '/',
    LOGIN: '/login',
    STORIES: '/stories',
    STORY: '/story/:id',
    ERROR404: '/404'
}

Możemy zaimplementować różną logikę:

• parametr może być wymagany, a jego brak skutkuje przeniesieniem do innej podstrony np.: podstrony z błędem. Przykładem jest na przykład podstrona z opowiadaniem, gdzie gdy nie wiemy jakie opowiadanie mamy wyświetlić, to nie wyświetlamy żadnego.
• parametr może być opcjonalny i jego brak skutkuje np.: nie pojawieniem się jakiegoś elementu
• parametr może być opcjonalny i posiadać wartość domyślną np.: jeśli wyświetlając listę opowiadań nie podamy wartości paginacji to zakładamy, że chodzi o pierwszą stronę. Tak więc https://twojastrona.com/#/stories i https://twojastrona.com/#/stories/1/ będą wyświetlały to samo.

Wszystkie obecne parametry są podstępne w globalnym obiekcie this.$route.params, jeśli ustawimy opcję props: true. W innych przypadkach możemy przypisać obiekt, jeśli chcemy podać stałą wartość lub... funkcję, jeśli chcemy stworzyć parametr wyliczanych z innych :)

import Vue from 'vue';
import VueRouter, { RouteConfig } from "vue-router";
import DisplayStory from 'Front/components/story/DisplayStory.vue';
import { ROUTING_URLS } from 'Front/routing/routings';

Vue.use(VueRouter);

const routes: Array<RouteConfig> = [
    { path: ROUTING_URLS.STORY, component: DisplayStory, name: ROUTING_URLS.STORY, props: true },
    { path: ROUTING_URLS.STORY2, component: DisplayStory, name: ROUTING_URLS.STORY, props: { id: 1 },
        { path: ROUTING_URLS.STORY3, component: DisplayStory, name: ROUTING_URLS.STORY, props: props: route => ({ query: route.query.id }),
]
    
export const router = new VueRouter({
    routes
});

Więcej dynamicznych slotów

Przyjrzyjmy się temu co tej pory zrobiliśmy: w naszej testowej aplikacji mamy nagłówek, stopkę i treść. Nagłówek i stopka są stałe, a treść jest zależna od routingu i wyświetlana w komponencie <router-view>.

Tylko co z sytuacja kiedy na różnych podstronach chcemy wyświetlać nie tylko inną treść ale także inny nagłówek?

Jak pewnie się domyślacie, Vue oferuje rozwiązanie tego problemu, bowiem slot z którego korzystaliśmy to jedynie slot domyślny i można ich napisać nieskończenie wiele. Także z:

<Header />
<router-view></router-view>
<Footer />

Można zrobić:

<router-view name="myheader"></router-view>
<router-view></router-view>
<Footer />

i uzyskać możliwość zmiany nagłówka w zależności od podstrony. Jedyną różnicą jest rozróżnienie slota atrybutem name. Musimy tylko jeszcze zadeklarować jaki widok ma się wyświetlać po jakim atrybutem:

const router = new VueRouter({
  routes: [{
    path: '/story/',
    components: {
        default: DisplayStory,
        myheader: StoryHeader
    },
  }]
});

Zagnieżdżone widoki

Skoro już wiemy, że da się spokojnie używać więcej niż jednego slotu router-view to pewnie przyszło Wam do głowy, że dobrze byłoby je zagnieżdżać.

Otóż da się i wcale nie jest to takie trudne! Wystarczy - poza dodaniem komponentu <router-view>  w innym komponencie wyświetlanym za pomocą <router-view> - zdefiniować potomków w konfiguracji Vue Routera za pomocą klucza children.

const router = new VueRouter({
  routes: [
    { path: '/author/:id', component: Author,
      children: [
        {
          // /author/:id/profile
          path: 'profile',
          component: AuthorProfile
        },
        {
          // /author/:id/stories
          path: 'stories',
          component: AuthorPosts
        }
      ]
    }
  ]
})

Podsumowanie

Mam nadzieje, że się podobało i początkujący programiści Vue.js już lecą zaimplementować swój pierwszy Vue Router :) Niestety temat nie dość, że nie został wyczerpany to jeszcze ledwo co zaczęty, gdyż Vue Router - i w ogóle frontowy routing - kryje dużo więcej: middleware, lazy-loading, sprawdzanie ścieżek to tylko przykłady. Na razie nie jest to jeszcze wersja, która mogłaby się pojawić na produkcji w standardowej aplikacji. Będę kontynuować temat w następnych wpisach, więc wyczekujcie cierpliwie :)

Zapraszam do zadawania pytań i komentowania, w szczególności jeśli coś jest niejasne :)

Trzymajcie się!

Polecam też inne wpisy o Vue na moim blogu:

• Implementacja Vuex
• Implementacja frameworka UI (Vue + TypeScript)

Continuous Integration i Continous Delivery to terminy, które powinny być znane każdemu programiście. Continuous Integration to praktyka regularnego mergowania kodu dzięki której powstało mnóstwo świetnych praktyk i narzędzi. Jest związana z pojęciem Continous Delivery, które odnosi się do regularnego wydawania na produkcję małych funkcjonalności. Dzisiaj spróbuję początkującym wyjaśnić z czym to się je :)

Jeszcze blok reklamowy przed wpisem i jedziemy!

Po pierwsze: mój Instagram (można tam znaleźć zapowiedzi wpisów, dodać jakieś sugestie i przywitać się :) Jestem również na devenv.pl, szczególnie zapraszam na mój artykuł o tej trudniejszej części TypeScripta.

Wystartowałam tez w wersji alpha z newsletterem :) Jeśli chcecie dostawać ciekawe linki i zadania z programowania to zapraszam do zapisania się :)

Trochę teorii dla początkujących

Zacznijmy od podstaw. Chociaż CI w każdym projekcie wygląda inaczej, jeśli chodzi o web development można wyodrębnić popularne praktyki takie jak:

• używanie repozytorium kodu z systemem kontroli wersji - najpopularniejszym jest git
• testy (zwykle jednostkowe) których poprawne przejście jest warunkiem koniecznym do pushowania kodu
• automatyzacja budowania aplikacji - push na konkretnego brancha powinien wywołać proces budowania się aplikacji
• zbudowana aplikacja podlega automatycznym testom - push na konkretnego brancha powinien uruchamiać testy na serwerze
• po wykonaniu testów oraz builda, aplikacji powinna zostać zreleasowana na odpowiednie środowisko (albo na staging skąd w przyszłości pójdzie promote - czyli wierna kopia - na produkcję)

Prosty przykład dobrze zaimplementowanego CI/CD:

1. Push uruchamia prepush który puszcza testy jednostkowe. Testy zakończone sukcesem umożliwiają push kodu do repozytorium.
2. Push uruchamia testy jednostkowe na zewnętrznej maszynie (może to być serwer, chmura albo komputer leżący dwa biurka dalej)
3. Po przejściu testów uruchamia się build, który buduje z kodu źródłowego aplikację
4. Często po buildzie na środowisku testowym/stagingowym uruchamiają się testy automatyczne E2E
5. Aplikacja zostaje zreleasowana (udostępniona publicznie)

Dla początkującego programisty, który zna podstawy gita z pewnością pojawi się pytanie: Jak to się stało, że git push uruchomił akcję na serwerze?

Na to pytanie odpowiem dzisiaj :)

Github Actions

Trochę zastanawiałam się nad idealnym przykładem. W pracy używam Drone'a jednak nie jest on open source'owym rozwiązaniem ani nawet - od jakiegoś czas - darmowym. Okazja nadarzyła się sama: Ghost w wersji 3.0 obsługuje customowe integracje!

W końcu się udało i nie będę musiała już budować szablonu lokalnie oraz wysyłać do na serwer. Wspólnie zautomatyzujemy ten proces :)

Po pierwsze potrzebujemy projektu do zbudowania na githubie. Moim będzie szablon bloga o nazwie technozaur.

Maszyną która wykona dla nas builta będzie serwer githuba, a dokładnie usługa Github Action. Istnieją alternatywne CI takie jak Drone, Jenkins, CircleCI, Buddy i wiele innych, jednak ta - ze względu na brak kosztów - będzie idealnym wyjściem. Dodatkowo autentykację mamy załatwioną, bo Github Actions jest częścią Githuba.

We wszystkich popularniejszych rozwiązaniach zadania dla usługi CI tworzy się poprzez plik w formacie yml (lub yaml) który umieszczamy w repozytorium kodu. Będzie on źródłem informacji o tym co i jak powinien zrobić serwer.

Nasz będzie wyglądał następująco:

name: Deploy Theme
on:
  push:	
    branches:	
      - master
jobs:
  deploy:
    runs-on: ubuntu-18.04
    steps:
      - uses: actions/checkout@master
      - uses: TryGhost/action-deploy-theme@v1.0.0
        with:
          api-url: https://solutionchaser.com 
          api-key: ${{ secrets.CHASER_PROD_API_KEY }}

Dokładne formaty znajdziesz w dokumentacji poszczególnych narzędzi, ale zasada działania będzie podobna.

W pierwszej linijce podajemy name czyli nazwę joba (akcji do wykonania), czuj się swobodnie puścić wodze fantazji, to jest nazwa własna i nie ma znaczenia :)

Druga linijka jest bardzo ważna, bowiem triggerem (czyli elementem wywołującym joba) może być mnóstwo rzeczy: zmiana labelki, stworzenie Pull Requesta czy zgłoszenie buga. W tym przypadku będzie to push do brancha master.

Następnie pod kluczem jobs definiujemy akcje będą składowymi joba, w tym przypadku jest to tylko deploy (to też nazwa własna w yml) na produkcję, który wykonamy na obrazie ubuntu-18.04. Github Actions udostępnia kilka typów maszyn z różnymi systemami operacyjnymi. Jeśli zastanawia cię co to obraz (czy kontener) to zapraszam do przeczytania wpisu o Dockerze.

Warto wiedzieć, że jest w pełni wyizolowane, postawione na chwilę (dosłownie na wywołanie tego joba) środowisko, które zostanie usunięte wraz z zakończeniem pracy.

Następnie podajemy kroki, które chcemy wykonać (pod kluczem steps). Tutaj mamy dwa:

• pobierz najnowszą wersję szablonu z mastera
• zbuduj szablon Ghosta i umieść na produkcji

      // fragment yml
      - uses: actions/checkout@master
      - uses: TryGhost/action-deploy-theme@v1.0.0

Pierwsze jest łatwe, bo przecież znamy gita i wystarczy tylko użyć pluginu z Github Actions. Drugie już mniej a to po prostu napisany skrypt w js i wrzucony do repozytorium https://github.com/TryGhost/action-deploy-theme/.

Szczegóły można zobaczyć tutaj: https://github.com/TryGhost/action-deploy-theme/blob/master/index.js.

Pisanie takich skryptów jest monotonne: Normalnie użylibyśmy kontenera z nodejs, potem zrobili npm install, a następnie npm build (pod którym w przypadku szablonu ghosta byłby gulp zip), aż w końcu skopiowali otrzymany plik do katalogu na serwerze poleceniem cp.

Jednak w większości przypadków będziecie używać gotowych rozwiązań, które robią to za nas :)

Zmienne środowiskowe i sekrety

Skoro już wiemy jak wywołać kolejne akcje to teraz objaśnijmy sobie klucz with. Odpowiada on za zmienne środowiskowe, które będą dostępne w czasie przetwarzania kroku. Zwykle są to zewnętrzne dane takie jak środowisko, ścieżki, rodzaj builda albo hasła.

W naszym przykładzie podaliśmy tam URL mojego bloga. Akurat ten plugin wymaga takich danych do poprawnego działania.

Pewnie zastanawia was kolejna zmienna środowiskowa ${{ secrets.GHOST_ADMIN_API_KEY }}. To całkiem proste: klamerki poprzedzone dolarem to oznaczanie zmiennej, a w środku mamy jej nazwę.

Tylko skąd się wzięła zmienna secrets? I co to w ogóle jest?

Co to sekrety?

Sekretami w programowaniu nazywamy informacje, które nie powinny być dostępne publicznie: takie jak hasła i - jak w tym przypadku - klucze dostępu. Lokalnie przechowywane są w powłokach lub plikach, których nie pushuje się do repozytorium a serwery korzystają z narzędzi przechowujących klucze pod postacią klucz-wartość. Rzadko jest to zwykła baza, powstało wiele dedykowanych ku temu narzędzi.

Na szczęście Github ma swoje, dostępne w Settingsach każdego repozytorium. Najprościej go znaleźć przez klienta webowego Githuba czyli github.com. Wejdź do repozytorium swojego szablonu, przyciśnij Settings i z pionowego menu po lewej wybierz Secrets. Ścieżka powinna być mniej więcej taka https://github.com/KamilaBrylewska/technozaur/settings/secrets/.

Umieściłam tam klucz który pobrałam po tworzeniu customowej integracji w panelu ghosta: Ghost Admin -> Settings -> Inegrations -> Add Custom Integration. Klucz który cię interesuje to Admin API Key i to właśnie jego wartość dodałam po kluczem CHASER_PROD_API_KEY na githubie.

Gotowe!

Teraz udostępnijmy yml serwerowi pushując plik do repozytorium:

git add .github/workflows/deploy-theme.yml
git commit -m "Github Actions - Deploy"
git push

Jeśli autoryzujecie się do githuba przez customowe integracje np.: OAuth to możecie napotkać błąd 'refusing to allow an OAuth App to create or update workflow .github/workflows/main.yml without workflow scope'. Jest to celowe działanie, które ma zapobiegać aktualizacji workflow poprzez zewnętrzne aplikacje. Więc przygotujcie klucze do działania!

Teraz musicie wejść na https://github.com/TwojaNazwa/NazwaTwojeRepozytorium/actions i zobaczyć swój pierwszy deploy :)

Po kliknięciu na szczegóły będziecie mogli podejrzeć jakie dokładnie kroki się wykonały.

Fajne linki do dokumentacji

Ten wpis jest coraz dłuższy, a informacji wciąż sporo do przekazania, więc dla dociekliwych przygotowałam kilka ciekawych linków. Jeśli chcecie wiedzieć co można wpisać w runs-on, co oznaczają poszczególne klucze w YAML oraz jakie zmienne środowiskowe są dostępne, zapraszam do odwiedzenia poniższych linków:

Using Node.js with GitHub Actions - GitHub Help

You can create a continuous integration (CI) workflow to build and test your Node.js project.

GitHub Help

Using environment variables - GitHub Help

GitHub sets default environment variables for each GitHub Actions workflow run. You can also set custom environment variables in your workflow file.

GitHub Help

Dodatkowo jeśli nie chcecie korzystać z gotowego plugina, można poczytać dokładną instrukcję jak samemu napisać podobny workflow:

Workflow syntax for GitHub Actions - GitHub Help

A workflow is a configurable automated process made up of one or more jobs. You must create a YAML file to define your workflow configuration.

GitHub Help

Podsumowanie

Mam nadzieje, że się podobało :) Obecnie automatyzacja jest niezbędna do zwinnej produkcji oprogramowania i obecnie nie wyobrażam sobie pracy bez niej. Pomijając wyniosłe idee tak naprawdę to po prostu szereg powtarzalnych zadań, których nie muszę robić. A to tygryski lubią najbardziej :)

A wy z jakich CI korzystacie? Możecie coś polecić w rozsądnej cenie dla developera-hobbysty?

W ramach mentoringu tworzę zadania dla mojego mentee i postanowiłam się z Wami nimi podzielić :) Ten wpis jest dla osób początkujących po kursach. Tych którzy czują się gotowi na podjęcie pierwszej pracy lub chcą sprawdzić się w prawdziwym zadaniu.

Jak wiadomo od słuchania i oglądania nikt programistą nie został, więc do roboty. Dobrze zrobione zadania tego typu to fajny wpis do pierwszego CV front-end developera :)

Słowniczek

Zanim przejdziemy do zadań musimy wyjaśnić sobie kilka słów:

• AC (Acceptance Criteria) - lista biznesowych (czyli nietechnicznych), wymagań, które trzeba spełnić aby zadanie zostało zakończone. Czym dokładniejsze tym lepsze :) A dzisiaj to ja będe je przygotowała.
• standardy kodowania - każdy team ma swoje, uczymy się ich kodując i współpracując z innymi programistami. Jeśli nie masz swoich to polecam te od Google'a. Dla mnie podstawą dla juniora będzie: ES6, modularność i reużywalność kodu (na takim poziomie jak dacie radę), logicznie ponazywane zmienne, czytelny kod.
• CTA - skrót marketingowców od Call To Action; zwykle interaktywny komponent, kluczowy w kontekście danego widoku strony. Powinien się wizualnie wyróżniać.

Formularz kontaktowy

Poziom trudności dla początkującego: wysoki.

Zaczęłam od najtrudniejszego zadania, ale front-end developer powinien umieć stworzyć dobry formularz. Moim zdaniem perfekcyjne zadanie dla kogoś kto opanował podstawy HTML, CSS oraz JavaScript i szuka wyzwania.

AC:

• podstawą formularza jest prosty landing page z białym tłem
• formularz jest wycentrowany zarówno w poziomie jak i w pionie
• formularz posiada tytuł "Skontaktuj się ze mną" oraz podtytuł "Zawsze chętnie się dowiemy się co Ci chodzi po głowie"
• Formularz posiada trzy pola (imię, adres e-mail oraz treść wiadomości) oraz przycisk "Wyślij"
• wszystkie pola w formularzu są walidowane: w polu imię da się wpisać tylko imię a w polu email tylko email. Błędna walidacja pola jest sygnalizowana czerwonym kolorem.
• pole "Treść wiadomości" pozwala na wpisanie maksymalnie 120 znaków
• przycisk "Wyślij" jest CTA (więc jest wystylowany jako taki)
• przycisk "Wyślij" jest nieaktywny gdy formularz jest niepoprawnie wypełniony
• design ma być elegancki, czytelny i klarowny, a obsługa intuicyjna i zgodna z nawykami użytkowników

To wbrew pozorom trudne zadanie, które wymaga zainteresowania jak wyglądają formularze i interakcje z nimi. Dla początkującego front-end developera jest to wiedza wręcz niezbędna, więc zostawiam Was z wyszukiwarką.

Stopka

Poziom trudności dla początkującego: średni.

Kolejnym zadaniem jest klasyczna stopka w której zwykle umieszczane są linki do najważniejszych podstron. Niezbędna część strony.

AC:

• stopka znajduje się na dole strony, jest to rozciągnięta na całą szerokość
• tło stopki jest w kolorze #383B44, tekst (linki oraz tekst) w #EBECF0
• Stopka zawiera trzy kolumny ułożone obok siebie, a w każdej z nich tytuł oraz pięć Twoich ulubionych linków dotyczących web developmentu
• Każda kolumna ma taką samą szerokość
• W wersji mobilnej kolumny zamieniają się w rozwijaną listę składającą się z tytułów.
• Listę rozwijasz klikając na tytuł, dzięki czemu ukazują się linki. Liste zwijasz klikają na tytuł, linki się chowają. Jak w poniższym przykładzie można użyć jakieś ikonki pokazującej stan (plus/minus albo strzałki góra/dół).

Da się to zrobić w samym CSS i jest to wersja preferowana ze względu na wydajność, ale zostawiam to Wam :)

Menu typu hamburger

Poziom trudności dla początkującego: niski.

Jest to typowy komponent stworzony pod mobilne wersje, ale wiele stron - w tym YouTube - korzysta z niego na wszystkich rozdzielczościach. Możecie je kojarzyć jako charakterystyczne trzy poziom kreski po naciśnięciu których pojawia się menu tak jak na zdjęciu poniżej:

AC:

• strona posiada klikalną ikonkę hamburgera w lewym górym rogu strony
• ikona zawsze (niezależnie od skrolowania) jest u góry strony
• po naciśnięciu ikonki pojawia się menu o szerokości 200px którego wysokość jest równa wysokości strony
• w menu są klikalne bloki z linkami
• menu posiada wewnętrzny scroll na wypadek gdyby pozycji menu było więcej niż pozwala na to wysokość strony
• menu chowa się po ponownym naciśnięciu na ikonkę hamburgera
• dodatkowym atutem będzie animacja pojawiania się i chowania menu, ale nie jest konieczna

Hamburger jest obecnie nielubiany przez UXowców, ale to w miarę proste zadanie, idealne na rozgrzewkę lub mniej śmiałego adepta frontu :) Protip: To również można wykonać samym CSS.

Podsumowanie

Udostępniłam 3 zadania o różnym (wg mnie) poziomie trudności, które sprawdzają wiedzę i - przede wszystkim - umiejętność zdobywania informacji. Możecie zauważyć, że zadania nie kolidują ze sobą, więc szaleńcy mogą wykonać je w jednym pliku.

Piszcie jeśli coś jest niejasne i chwalcie się wynikami Waszej pracy :)

Zapraszam do kodowania :)

Docker. Kontenery. Wirtualizacja. Środowisko programistyczne. Jeśli zastanawialiście się jak rozpocząć zabawę z konteneryzacją to jest wpis dla Was :) Krok po kroczku postawicie swojego pierwszego dockera.

Dzisiejszy przykład będzie bardzo prosty, postawimy serwer node.js w kontenerze, który będzie zwracał miłą wiadomość. Proszę nie robić tak na produkcji :)

Stop. Co to są te kontenery?

Jeśli takie pytanie przeszło ci przez głowę to najlepsza odpowiedź brzmi mniej tak: to taki wirtualny komputer na twoim fizycznym: kompletnie odseparowany i niezależny (oczywiście oprócz zasobów fizycznych). Można go postawić na dowolnym, innym komputerze i wszędzie będzie działał tak samo. Dlatego developerzy używają go do stawiania środowisk programistycznych/produkcyjnych.

To jak? Gotowi na pierwszą przygodę z Dockerem?

Rozpoczęcie

Pierwsze co musicie zrobić to zainstalować Dockera, najbezpieczniej pobrać go z oficjalnej strony.

Stwórzmy folder kreda w którym będziemy trzymali nasz projekt, a w środku:

• plik server.js w którym będzie kod aplikacji opartej na express.js
• plik package.json w którym dodamy zależności aplikacji
• plik Dockerfile w którym będą polecenia do zbudowania środowiska i aplikacji
• plik .dockerignore w którym dodamy ścieżki które chcemy w dockerze ignorować

Zacznijmy od serwera:

// server.js
const express = require('express');
const app = express();

app.get('/', function (req, res) {
  res.send('Hello guys! Kamila is here');
});

// 8080 to przykładowy port
app.listen(8080, function () {
  console.log('Example app listening on port 8080!');
});

A teraz package.json:

// package.json
{
    "name": "solutionchaser",
    "version": "1.0.0",
    "description": "Blog post",
    "main": "index.js",
    "scripts": {
      "start": "node server.js"
    },
    "author": "Kamila",
    "license": "OhPlease",
    "dependencies": {
      "express": "^4.15.3"
    }
  }

Testowo odpalmy server.js w konsoli (będąc oczywiście w folderze kreda):

// w konsoli
npm i
node sever.js

Jeśli nie pojawił się żaden błąd, to spróbujmy otworzyć stronę w przeglądarce pod adresem http://127.0.0.1:8080. Jeśli wyświetli się ekran powitalny to odnieśliśmy pierwszy sukces. Niezwiązany z dockerem, ale jednak!

Teraz zabijmy proces i zamknijmy konsolę, jest to szczególnie ważne bowiem czasem system nie zwalnia portu.

Definicje dockerowe

Korzystając z Dockera najczęściej korzysta się z gotowych obrazów zawierających system z zainstalowanymi komponentami. Jako, że chcemy postawić prostą aplikację node.js przydałby się nam node.

Pod tym linkiem DockerHub można zobaczyć listę oficjalnie dostępnych obrazów do uruchomienia w dockerze i chyba jest to najprostszy sposób na start :) Wybrałam node'a w wersji 10.

W pliku Dockerfile wykonujemy kroki służące do zbudowania kontenera. Robimy to za pomocą krótkich (zwykle pisanych wielkimi literami) komend takich jak COPY albo CMD.

// wykorzystanie obrazu zawierającego node w wersji 10
FROM node:10

// skopiowanie wszystkich plików z obecnego katalogu do kontenera
COPY . .

// wykonanie komendy: npm install która pobierze paczkę express.js
CMD npm install

// wystaw na zewnątrz port 8080, żeby można było się z nim połączyć
EXPOSE 8080

// wykonanie komendy node server.js
CMD node server.js

A teraz .dockerignore, bowiem nie chcemy, żeby z naszego lokalnego środowiska kopiowały się niepotrzebne pliki:

node_modules
npm-debug.log

Ty, ja i Docker - let's run it!

Po pierwsze musimy zbudować środowisko:

docker build -t twoja-nazwa-kontenera .

Nie ma żadnych błędów? Mam nadzieję :)

To teraz uruchomimy go, żebyśmy mogli korzystać z aplikacji. W parametrze p podajemy mapowanie portu (tego samego co w EXPOSE do tego który chcemy wpisywać w przeglądarce). Tutaj oczywiście mapowanie jest trochę bez sensu, ale gdy macie port 8080 zajęty na fizycznej maszynie to oto trick :)

docker run -p 8080:8080 -d twoja-nazwa-kontenera

Mam nadzieje, że zwrócił długi ciąg znaków w konsoli, teraz skopiujmy go i wklejmy:

docker logs dhdbahjdbahjdbadjhabdbdahdbahwid

Tutaj powinniśmy dostać informację: Example app listening on port 8080!

Ostatni etap to odpalenie serwera w przeglądarce: http://127.0.0.1:8080.

SUKCES :)

Niestety nie jest to perfekcyjne rozwiązanie ze względu na mnogość środowisk fizycznych, gdzie najbardziej ograniczają nas systemy operacyjne. Prawda jest taka, że większość serwerów na świecie stoi na Linuxach i jest to najlepsze środowisko programistyczne również pod względem wirtualizacji.

Apple nie wspiera natywnie wirtualizacji, więc większe środowiska mogą chodzić dużo wolniej bez paru tricków i hasków. Na Windowsie w wersji Home (brak obsługi wirtualizacji Hyper-V) podobno trudno uruchomić Dockera bez dodatkowego oprogramowania. Są jeszcze rozważania na temat ogólnej wydajności, ale to zdecydowanie nie jest wpis aby się w to zagłębiać.

Podsumowanie

Mam nadzieje, że się podobało i udało się Wam w 30 minut zbudować swój pierwszy kontener. To oczywiście jest tylko zalążek możliwości dockera i jeden serwis wiosny nie czyni, ale mam nadzieje, że przekonałam jak łatwa i przyjemna jest konteneryzacja :)

Dzień dobry! Jak się macie? U mnie wspaniale, chociaż dosyć pracowicie, mam nadzieje, że ten rok będzie pełen sukcesów.

Bardzo mi miło, że ze mną tutaj jesteście! Coraz więcej osób mnie czyta, dziękuję za ten czas, mam nadzieje, że nie jest zmarnowany!

Dzisiaj przychodzę do Was z bardzo ciekawym tematem, który postanowiłam ogarnąć w weekend.

Fetch

// implementacja syntax-sugar
const response = await fetch('https://pokeapi.co/api/v2/pokemon');
const json = await response.json();
console.log(json));

// implementacja sugar-free
fetch('https://pokeapi.co/api/v2/pokemon')
.then((response) => response.json())
    .then((json) =>  {
        console.log(json); 
    }); 

Fetch to natywna funkcja umożliwiająca asynchroniczne pobieranie danych, swojego rodzaju alternatywa dla XMLHttpRequest. Istnieje pomiędzy nimi kilka różnic w które polecam się zagłębić, jednak kluczową informacją jest, że fetch zwraca Promise'a.

Co oznacza, że los fetch'a nie jest przekreślony, tym bardziej jeśli skorzystamy z AbortAPI.

AbortAPI

Sprawa jest prosta: przeglądarka udostępnia narzędzia, które umożliwiają przerwanie dowolnego requestu z DOM, a ja pokażę wam się tego używa.

Przykład będzie bardzo życiowy: chcemy pobrać dane, które są tak dynamiczne że czekanie na nie powyżej sekundy mija się z celem, a nawet szkodzi naszej aplikacji.

To co? Ruszamy do kodowania!

Przykładowe wywołanie poniżej, oszczędziłam Wam catch'a, ale nie powinnam!

const response = SolutionFetch.fetch('https://pokeapi.co/api/v2/pokemon', 6000)
    .then((response) => response.json())
    .then((json) => {
        console.log(json);
        // pokaż tylko wartościowe dane
    })
    .catch(() => {});

A teraz wrapper na natywnego fetcha:

class SolutionFetch {
    static fetch(url, timeout, configObj = {}) {
        const controller = new AbortController();
        const signal = controller.signal;
        let timeoutReference = null;
        
        return new Promise((resolve, reject) => {
        
            // rejestrujemy timeouta
            timeoutReference = setTimeout(() => {
                console.log('ABORT');
                controller.abort();
                return reject();
            }, timeout);

            // fetchujemy prawdziwe dane
            fetch(url, { signal }).then((response) => {
                clearTimeout(timeoutReference);
                console.log('OK');
                return resolve(response);
            }).catch((error) => {
                console.log('NOPE');
                clearTimeout(timeoutReference);
                return reject(error);
            });
        });
    }
}

Jak to działa? Gdy utworzymy controller i podamy jego sygnał do fetcha, możemy go przerwać w dowolnym momencie! Kluczowe jest tutaj controller.abort().

To teraz szybki quiz:

1) Co będzie w konsoli jeśli wywołamy te funkcję z dużym timeoutem (czyli wartością po której chcemy zrezygnować z fetcha, w tym przykładzie 6000ms)?

2) A co jeśli timeout będzie równy 1ms? Spójrzcie do góry na kod i zastanówcie się.

3) Co się zmieni jeśli wykomentujemy 12 linijkę ( controller.abort(); ) i czas będzie równy 1ms ?

4) Co się stanie jeśli nie wyclearujemy SetTimeout'a, gdy czas będzie długi (na przykład 1000ms)?

I jak? Proste pytania czy wymagają nieco zastanowienia?

Jesteście pewni, że chcecie znać odpowiedzi? Jeśli tak to scrollujcie dalej!

A teraz wyniki:

1) Wyświetli się zarówno "OK" jak i odpowiedź z serwera z listą pokemonów.

2) Wyświetli się "ABORT" i "NOPE", a request nie zostanie wysłany. Można to zobaczyć w zakładce "Sieć"/"Network"

3) Wyświetli się "ABORT" i "OK", request zostanie wysłany.

4) Wyświetli się "OK", potem pojawi się odpowiedź z serwera, a po chwili "ABORT". Raz zresolvowanego promise'a nie da się rejectować, więc reject w setTimeoutcie nie będzie miał znaczenia.

Podsumowanie

Mam nadzieje, że się podobało :) Staram się cały czas na nowo odkrywać Javascript, a pisanie #funWithJavascript to najlepsza okazja!

Pochwalcie się wynikami? Udało Wam się rozwiązać mój mini quiz czy gdzieś się pomyliliście?

Pozdrawiam serdecznie i bardzo dziękuję za wszystkie polubienia, udostępnienia oraz miłe słowa!

Dzień dobry!

Niestety wszystko co dobre kiedyś się kończy i przed nami finalne wyniki badań! Jeśli chcecie pozazdrościć specjalistom z Podlasia to zapraszam do czytania!

Warto dodać, że ostatnie wpisy są całkiem popularne (także te techniczne), a dzięki wykopowi (wykop.pl) zaliczyłam ogromny skok popularności właśnie dzięki wstępnym wynikom badań. Dziękuję za wszystkie lajki, reakcje!

Dzisiaj będzie równie interesująco. Jeśli boicie się zapytać kto, gdzie i ile zarabia, ten wpis odpowie na wiele pytań!

TL;DR

• Aż 66% specjalistów pracuje ponad etat miesięcznie i podczas gdy za standardową liczbę godzin (160h w miesiącu) zarabiają średnio 10,5 tys. miesięcznie netto.
• Większość z ankietowanych uważa, że zarobki są nieadekwatne do wykonywanej pracy.
• Statystycznie kobiety w IT zarabiają mniej niż mężczyźni, za to odczuwają większy komfort pracy i rozwoju.
• 2,6% ankietowanych kobiet i 11,8% mężczyzn zarabia ponad 150zł/h netto.
• Zadowolonych z wynagrodzenia jest tylko 47% badanych
• Najniższy komfort finansowy odczuwają respondenci z województwa lubelskiego: 48%, a najwyższy z...

Podziękowania

Bardzo chciałabym podziękować grupie EWork za inicjatywę, która ma na celu poprawę warunków pracy specjalistów w IT. Według badań nie jest tak różowo jak mówią w mediach, ale już dokładanie wiemy co trzeba zmienić :)

Ework Group to niezależna agencja konsultingowa notowana na giełdzie Nasdaq Stockholm, zrzeszająca specjalistów IT, reprezentująca pochodzący ze Skandynawii model biznesowy powstały w 2000 roku w Szwecji. Obecnie funkcjonuje również w Danii, Norwegii, Finlandii i w Polsce. Ework Group działa w Polsce od 2015 r., z biurami w Warszawie, Wrocławiu i Gdyni.

Największe - bo osobiste - podziękowania chciałabym skierować ku agencji reklamowej, która powoli przeprowadziła mnie przez moją pierwszą komercyjną współpracę! Naprawdę cudowne osoby pomogły mi przekazać Wam tę całą wiedzę!

Agencja Biuro Podróży Reklamy to eksperci w kampaniach łączących social, web, mobile, search marketing, video, blog i content marketing z ambientem technologicznym, marketingiem partyzanckim oraz innymi działaniami niestandardowymi i innowacyjnymi technologiami. Twórcy nowatorskich stron i aplikacji mobilnych. Agencja posiada dwa tytuły agencji roku: Agency of the Year 2014 in Poland – Epica Awards, Agencja Marketingu Zintegrowanego Roku – Impactor (2015) oraz w sumie 33 nagrody i wyróżnienia branżowe: Epica Awards, Kreatura, Impactor, Mixx Awards, AME Award, Webstar Creative, Golden Arrow, Innovation Award, Pióro Roku, Złoty i Srebrny Spinacz, Kampania Społeczna Roku.

Wyniki badania

Po długim wstępie nadszedł czas na wyniki badania!

W badaniu oceniliście są takie obszary jak „Komfort finansowy”, „Komfort pracy”, „Komfort czasu pracy”, „Styl pracy”, „Komfort współpracy” czy „Komfort rozwoju”. Okazuje się, że w swojej pracy specjaliści IT najgorzej oceniają „komfort finansowy”, na który wpływają m.in. zarobki i systemy podwyżek – został oceniony średnio na 62% (w skali satysfakcji 0-100%).

I to mimo faktu, iż ponad 60% kobiet i ponad 70% mężczyzn pracujących jako specjaliści IT w oparciu o kontrakt B2B zarabia w Polsce powyżej 65 zł na godzinę (netto), czyli co najmniej 10,5 tys. zł netto miesięcznie (przy przyjęciu puli godzin w miesiącu jak na etacie).

Zarobki do 65 zł (netto) za godzinę deklaruje 36,8% kobiet i 27,8% mężczyzn, od 66 do 95 zł za godzinę – 23,7% kobiet i 24,4% mężczyzn, od 96 zł do 125 zł za godzinę – 19,7% i 25% mężczyzn, od 126 do 150 zł za godzinę – 17,1% kobiet i 11% mężczyzn oraz powyżej 150 zł za godzinę – 2,6% kobiet i 11,8% mężczyzn.

Dla 43% ankietowanych najważniejszym benefitem stażu pracy jest właśnie wyższe wynagrodzenie, 29% ankietowanych uznała, że najważniejsze są ciekawe projekty. Aż 53% badanych uważa, że ich zarobki mogłyby być lub wręcz powinny być lepsze. Ogólne zadowolenie z zarobków wynosi 47% - tyle procent badanych uważa, że ich zarobki są „stabilne” lub „adekwatne do projektu”.

Najbardziej zadowoloną ze swoich zarobków grupą są osoby, które mają mniej niż 2 lata doświadczenia. 55% z nich uznało, że wynagrodzenie jest adekwatne lub stabilne. Jednak im dłuższy staż pracy, tym więcej wskazań „mogłoby być lepiej”.

Wraz z doświadczeniem rosną stawki. Pośród osób biorących udział w badaniu, ponad 70% osób z doświadczeniem poniżej 2 lat zarabia poniżej 65 zł za godzinę, z kolei prawie 20% osób z doświadczeniem ponad 9 lat zarabia powyżej 150 zł za
godzinę.

Z kolei w podziale na specjalności zawodowe kwestie zarobków i satysfakcji kształtują się tak, że spośród badanych, najwyższe zarobki deklarują specjaliści pracujący w obszarze zarządzania IT i systemów ERP, a najmniejsze – specjaliści w
obszarze bezpieczeństwa.

Jednocześnie specjaliści w obszarze bezpieczeństwa deklarują największe zadowolenie z zarobków, a specjaliści z obszaru zarządzania IT - najmniejsze.

Zarobki to jednak nie wszystko. Specjaliści w branży IT (pracujący na kontraktach B2B) najwyżej oceniają „komfort rozwoju” (m.in. możliwości podnoszenia kwalifikacji, szkolenia, premie i nagrody) – kategorię tę oceniono średnio
na 86% (w skali 0-100%).

Wysoko oceniano także „komfort czasu” pracy (m.in. liczba godzin w miesiącu oraz możliwość pracy zdalnej) – 80% oraz komfort współpracy (m.in. pozyskiwanie nowych projektów, ich atrakcyjność czy atmosfera pracy) - 75%.

Gorzej oceniane są kategorie takie jak „styl pracy” (m.in. trudność w prowadzeniu biznesu, elastyczność czasu pracy, wybór projektu) - 65%; oraz komfort pracy (m.in. podróże służbowe czy lokalizacja biura) - 67%.
Kobiety notują wyższy średni komfort pracy, komfort czasu pracy, komfort współpracy oraz komfort rozwoju. Mężczyźni mają wyższy średni komfort finansowy, jak również oceniają wyżej styl pracy.

W skali ogólnopolskiej, średni komfort we wszystkich kategoriach jest wysoki – wynosi 72,5%. Najniższy średni komfort jest notowany w województwie opolskim – wynosi 64%. Najwyżej plasują się specjaliści IT z województwa świętokrzyskiego, których średni komfort wynosi aż 76%. Najniższy komfort finansowy odczuwają respondenci z województwa lubelskiego: 48%, a najwyższy – z podlaskiego – 73%.

Podsumowanie

Ta współpraca to była sama przyjemność, sporo nauczyłam się o branży i mogłam posłuchać Waszych opinii. Statystyka jest zwodniczą nauką, ale bez zadawania pytań i kategoryzowania problemów nigdzie nie zaszlibyśmy jako ludzkość i cieszę się, że mogę w tym uczestniczyć.

A jak tam u Was? Zszkokowani? Czekacie na przelew 10k czy kujecie po nocach, żeby dostac lepszą pracę?

Pozdrawiam i serdecznie dziękuję za wszystkie polecenia, linki oraz reakcje <3

Szczęśliwego Nowego Roku! Mam nadzieje, że przerwa świąteczno-noworoczna była okazją do odpoczynku. Wróciłam z zdwojoną siła i entuzjazmem!

Serdecznie zapraszam do czytania drugiej części tego cyklu. Dzisiaj będziemy kontynuować podstawy i zjemy duży kawałek TypeScriptowego tortu. Największą zaletą TypeScripta jest... typowanie, więc bez tego trudno ruszyć dalej.

Do przeczytania tego artykuły wymagana jest podstawowa znajomość JavaScript. Nie omówiłam wszystkich typów ani niuansów związanych z typowaniem. Żeby nie było zbyt słodko :)

Typy zmiennych

Na początek drobna uwaga: w TypeScripcie typy natywne zapisujemy z małej litery. Trzeba pamiętać, że number to typ, a Number to obiekt.

Tutaj wylistowałam niekompletną liczbę typów. Dlaczego niekompletną? Bowiem trudno mi było jednoznacznie oddzielić wiedzę podstawową od tej bardziej zaawansowanej i zrobiłam to według własnego uznania.

• string to powszechnie znany łańcuch znakowy, przechowuje tekst
• number trzyma w sobie liczby
• array lub [] to  tablica, można również deklarować tablice konkretnego typu np.:  string[] lub Cat[]
• object to powszechnie znany obiekt, wrócimy do niego za kilka akapitów
• unknown - to typ nieznany
• any - to dowolny typ
• [key | string] - typy indexów
• <T> - typy generyczne zostawiam na inny wpis
• never
• void
• enum - zapraszam do czytania specjalnego wpisu o Enumach w TypeScripcie https://solutionchaser.com/typescript-enum/
• inne: typy mieszane i zaawansowane

Any i unknown

Z pewnością ten akapit wzbudzi wiele kontrowersji, bowiem samo istnienie typu - nazwijmy to tymczasowo - nieokreślonego wydaje się kontrowersyjne. TypeScript jest po to, żeby typować, więc o co chodzi? Używać czy nie używać? A jeśli tak to kiedy?

Sama koncepcja pochodzi z języków obiektowych, gdzie istnieje bazowy `Object` z którego dziedziczy wszystko. Jak nie ma na co rzutować to zawsze można na Object.

W JavaScripcie any/ unknown  pełni podobną rolę dodatkowo ułatwiając przetwarzanie danych, szczególnie tych pobranych z zewnętrznych źródeł. Jeśli jednak uważnie przeczytacie ten post możecie znaleźć lepsze alternatywy.

Moim zdaniem powszechnym błędem jest stosowanie any oraz unknown zamiennie lub stosowanie tylko any.

Any ma większy zakres, zmienną tego typu można zawołać, może być także konstruktorem. Wszystko można przypisać do zmiennej typu any i zmienna typu any może być przypisana do wszystkiego (z drobnym wyjątkiem: never).

Unknown został wprowadzony jako poprawka do any. Do tego typu zmiennej można przypisać wszystko, ale zmiennej typu unknown nie można przypisać do innego typu niż any or unknown. Nie można jej wywołać.

To jakby powiedzieć: "Ok, rozumiem, że w tamtej chwili nie było możliwości, żeby znać strukturę danych, ale żeby ich użyć bezpiecznie musisz rzutować na odpowiedni typ."

// data to dane z nieznanego nam API
let jakakolwiek: any = data;
let nieznana: unknown = data;

let numerek: string = jakakolwiek; // OK
let numerek2: string = nieznana; // ERROR

Ok, to jak to zrobić? Trzeba rzutować, a co za tym idzie: dokładnie wiedzieć co się robi.

let numerek2: string = nieznana as string; // OK

Object, typy indexów i index signatures

Podczas gdy w Javascriptcie obiekty są wolnym duchem, TypeScript lubi trzymać je pod kontrolą.

let obj: { kot: string };

obj = {
	kot: 'franek"
}

Dlatego powyższy zapis jest poprawny, ale poniższy wyrzuci błąd:

let obj: { kot: string };

obj = {
	kot: 'franek',
	pies: 'łapka' // ERROR
}

Czy straciliśmy całą elastyczność związaną z obiektami? Niekoniecznie!

Mamy dwa wyjścia:

• właściwość nieobowiązkowa oznaczona znakiem zapytania

W poniższym przykładzie mamy definicję typu, który jest obiektem z obowiązkową właściwością kot i dodatkową pies. Dzięki temu możemy elastyczniej przypisywać obiekty.

let obj: { kot: string, pies?: string };

obj = { // OK
	kot: 'franek',
	pies: 'łapka'
}

obj = { // OK
	kot: 'franek',
}

obj = { // ERROR
	pies: 'łapka'
}

Nie będę dzisiaj tego omawiać, ale tutaj również rozwiązaniem mogą być typy zaawansowane/mieszane.

• zdefiniować klucz obiektu

Tutaj mamy mnóstwo władzy, której łatwo naużyć, ale tak: mamy możliwość zdefiniować typu klucza oraz umieszczonych pod nim danych.

let obj: {
    [key: string] : string
}


obj = {
    piesek: 'łapka',
    kotek: 'mruczek',
    papuzka: 'swiergotka'
    wiek: 3 // ERROR
}

Świetne, ale co z sytuacją gdy chcemy przypisać cokolwiek?

let obj: {
    [key: string] : any
}

obj = {
    piesek: 'łapka',
    kotek: 'mruczek',
    papuzka: 'swiergotka',
    wiek: 3 // OK
}

Jeśli już potrzebujemy sporej elastyczności, powyższe rozwiązanie jest dobre.  Oczywiście klucz może być także number.

Never & Void

Te typy nie są powiązane, ale bardzo łatwo można je zmylić.

Void jest typem, który często zwracamy w metodach, bowiem jest on oznaczeniem, że ta funkcja nic nie zwróci. Podczas wykorzystywania tak oznaczonej funkcji linter przypilnuje, żeby nic nie zwracała oraz żebyśmy nie przypisywali wyniku do jakieś zmiennej.

Never to informacja o tym, że ta funkcja nigdy się nie zakończy. Istnieje kilka takich funkcji np.: niekończący się while.

const immortality = (): never => {
    while(1) {
        breath();
    }
}

Albo funkcja, która zawsze zwróci wyjątek. Są to często funkcje pomocnicze, gdy aplikacja wymaga bardziej skomplikowanej obsługi błędów:

function error(message: string): never {
    throw new Error(message);
}

Podsumowanie

Podobało się? To tylko zalążek tego co można zrobić z typami w TypeScriptcie! Wrócimy jeszcze do typów generycznych oraz bardziej zaawansowanego typowania, ale na dzisiaj odpocznijcie. Ten rok będzie szalony!

Zapraszam do komentowania, pewnie kilka niuansów przeoczyłam!

Dzień dobry! Dzisiaj mam dla Was szalenie ciekawe wyniki z ankiety na temat jakości pracy na B2B. Jeśli interesuje Was komfort pracy, zarobki oraz motywacje w świecie IT to serdecznie zapraszam do czytania!

Słowem wstępu

Od początku października Grupa Ework organizuje „Wielkie badanie specjalistów IT na B2B” . Badanie ma na celu określenie trendów w pracy na rynku IT z perspektywy specjalistów pracujących na B2B, określenie jakie są ich potrzeby, co wymaga zmian oraz określenie jak obszar biznes-to-biznes będzie rozwijał się w przyszłości. Jest to pierwsze takie badanie na polskim rynku.

Badanie nie jest jeszcze zakończone i nadal można wziąć w nim udział (do końca stycznia) na stronie internetowej: badanieB2B.eworkgroup.com.

TL;DR

Jeśli przeraża cię statystyka (nawet w formie obrazków) to uogólniając: specjaliści na B2B uważają, że zarabiają za mało, kiepsko również oceniają podwyżki (zarówno ilość jak i częstotliwość). Bardzo chwalą się sobie jednak komfort rozwoju oraz ciekawe projekty. Prowadzenie firmy uważają za niepotrzebnie skomplikowane.

Wyniki badania

W badaniu oceniane są m.in. takie obszary jak „Komfort finansowy”, „Komfort pracy”, „Komfort czasu pracy”, „Styl pracy”, „Komfort współpracy” czy „Komfort rozwoju”. Są to określenia uogólniające szereg pytań o zadowolenie z każdego obszaru.

Okazuje się, że najgorzej specjaliści IT w swojej pracy oceniają „komfort finansowy” (na który wpływają m.in. zarobki i podwyżki) – został on oceniony średnio na 61% (w skali satysfakcji 0-100%).

Kobiety notują wyższy średni komfort pracy, komfort czasu pracy, komfort współpracy oraz komfort rozwoju. Mężczyźni mają wyższy średni komfort finansowy, jak również oceniają wyżej styl pracy.

Specjaliści w branży IT (pracujący na kontraktach B2B) najwyżej oceniają natomiast „komfort rozwoju” (m.in. możliwości podnoszenia kwalifikacji, szkolenia, premie i
nagrody) – kategorię tę oceniono średnio na 85% (w skali 0-100%).

Wysoko oceniano także „komfort czasu” pracy (m.in. liczba godzin w miesiącu oraz możliwość pracy zdalnej) - 79% oraz komfort współpracy (m.in. pozyskiwanie nowych projektów, ich atrakcyjność czy atmosfera pracy) - 75%.

Analizując powyższe dane liczbowe o zarobkach trzeba zwrócić uwagę na dwie rzeczy: po pierwsze są to wartości netto, a po drugie B2B jest opłacalne dopiero od pewnego pułapu finansowego. Najczęściej po zdobyciu doświadczenia i przekroczeniu pewnej kwoty wynagrodzenia specjaliści decydują się na założenie firmy.

Dla prawie 40% ankietowanych najważniejszym benefitem stażu pracy jest właśnie wyższe wynagrodzenie, mniej niż 1/3 ankietowanych uznała, że najważniejsze są ciekawe projekty. Aż 56,5% badanych uważa, że ich zarobki mogłyby być lub wręcz powinny być lepsze.

To chyba najciekawszy element ankiety :) Głęboko utożsamiam się z potrzebą dobrych zaróbków, ciekawych projektów oraz partnerstwa. Co o tym myślicie?

Podsumowanie - potencjał badania

Wyniki nie są szokujące, ale zdecydowanie jednoznaczenie nakierowują na konkretne obszary w których można poprawić sytuację:

• wyższe wynagrodzenia
• regularne, adekwatne do umiejętności i zaangażowania podwyżki
• ciekawe projekty
• partnerstwo biznesowe - dobre relacje, szacunek, elastyczność ze strony pracodawcy oraz zaufanie

Pamiętajcie jednak, że badanie nie jest zakończone i każdy z was może wziąć w nim udział :) Zapraszam tutaj: badanieB2B.eworkgroup.com.

A jakie jest Wasze zdanie? Coś was zszokowało, z czymś się nie zgadzacie?

Dzisiaj rozpoczniemy zabawę z testami jednostkowymi. Już trochę doświadczenia z JESTem mam, ale zaczniemy zgodnie z naturalnym biegiem spraw... Od początku!

Test jednostkowe (tzw. unit testy) są to testy sprawdzające malutkie części kodu: najczęściej funkcje lub/i metody. Każdy test jest niezależny od poprzedniego oraz w jak najmniejszym stopniu opiera się na zewnętrznych zależnościach (wręcz nie powinno ich być!). Test może zakończyć się sukcesem lub porażką (ang. fail).

npm i --save-dev jest to dobry początek, potem w package.json można podpiąć npm test do polecenia jest, którym uruchamiamy testy.

Tworzymy folder tests, a potem plik mytest.test.js.

Nazewnictwo jest tutaj kluczowe, bowiem domyślnie JEST szuka testów w wszystkich plikach w projekcie o rozszerzeniu *.test.js. Jest to szalenie wygodne.

Odpalamy!

Teraz sprawdźmy czy wszystko działa :)

W pliku mytest.test.js utwórzmy sobie test, który zawsze będzie przechodził. W JEST testy definiuje się bardzo prosto: funkcją test.

Jej pierwszym argumentem jest opis testu, kolejnym funkcja w której wywołujemy expect sprawdzającą poprawność wartości. W tej chwili pominiemy wszystkie inne aspekty.

test('3 is equal to 3', () => {
    expect(3).toBe(3);
});

Powyższy test sprawcza czy 3 === 3.

Teraz w konsoli puszczamy komendę jest lub `npm test`, jeśli wpisaliśmy polecenie do package.jsona. Wynik?

> storyportal@1.0.0 test /home/kamila/Dokumenty/StoryPortal
> jest

 PASS  tests/first.test.js
  ✓ adds 1 + 2 to equal 3 (6ms)

Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total
Snapshots:   0 total
Time:        2.332s
Ran all test suites.

Pełen sukces!

Chociaż przyznam, że programistyczny instynkt podpowiedział mi, że 3 jest równie 3 :)

Typescript

Niestety dobrze wiecie, że to nie koniec konfiguracji bowiem moja miłość do TypeScripta nie pozwoliłaby mi spać. Musicie wiedzieć, że są dwa sposoby na integrację JESTa z Typescriptem, jeden sprawdza typy, drugi korzysta z wygenerowanych plików js. My oczywiście chcemy sprawdzać typy, więc użyjemy ts-jest!

Najpierw instalacja:

npm i --save-dev jest typescript
npm i --save-dev ts-jest @types/jest
npx ts-jest config:init

Teraz stworzymy plik typetest.test.ts i wklejamy dokładnie to co mieliśmy w poprzednim teście.

I puszczamy npm test. Wynik?

> storyportal@1.0.0 test /home/kamila/Dokumenty/StoryPortal
> jest

 PASS  tests/first.test.js
 PASS  tests/typetest.test.ts

Test Suites: 2 passed, 2 total
Tests:       2 passed, 2 total
Snapshots:   0 total
Time:        1.643s, estimated 5s
Ran all test suites.

Znowu dziki, programistyczny instynkt zadziałał i byłam niemal pewna, że cztery jest równe cztery. Niemal :)

No ale w końcu musimy coś przetestować i dlatego wybrałam pusty controller.

import { JsonController } from "routing-controllers";

@JsonController()
export class StoryController {
  constructor() {
    console.log('Wywołany!');
  }
}

Stwórzmy plik storyController.test.ts i wypełnijmy go szalenie nudnym testem. Sprawdzimy czy zmienna do której przypisaliśmy nową instancję klasy na pewno jest instancji tej klasy. W prostych aplikacjach jest to oczywiście kompletna bzdura.

import { StoryController } from './../src/controllers/StoryController';

test('StoryController constructor allows creating story', () => {
    const storyController = new StoryController();
    expect(storyController).toBeInstanceOf(StoryController);
});

Puszczamy npm test i co? Błąd. Okazuje się, że JEST nie radzi sobie z czytaniem relatywnych ścieżek z aplikacji, które są zdefiniowane w tsconfig.json.

Problem jest powszechnie znany i powstał fix naprawiający go w pewnym stopniu: link, jednak nie wystarczająco dobry jak na moją aplikację, gdzie trochę podmieniam nazwy ścieżek.

Istnieją dwa wyjścia:

• ręczne wpisywanie mapperów do jest.config.js
• zastosowanie jakieś funkcji/biblioteki np.: https://www.npmjs.com/package/jest-module-name-mapper

Ręczne wpisywanie jest prostsze, ale wymaga duplikacji danych co zawsze wiąże się z ryzykiem starty spójności. Dlatego zainstalujemy i użyjemy jest-module-name-mapper :)

npm i --save-dev jest-module-name-mapper

A w jest.config.js:

module.exports = {
  preset: 'ts-jest',
  testEnvironment: 'node',
  moduleNameMapper: require('jest-module-name-mapper')(),
};

Puszczamy... I działa! Ale zaszaleliśmy!

Expect

Czeka nas jeszcze długa droga poprzez mockowanie, fake'owanie, strukturę JESTa i wiele innych przygód.

Na żadną z nich nie wyruszymy bez przybliżenia się funkcji expect.

Zwraca ona obiekt z metodami, które umożliwiają wybranie wygodnego operatora logicznego oraz tego co dokładnie będziemy porównywać.

W poprzednich przykładach poznaliśmy dwie z tych metod: toBe (która jest jednym z kilku odpowiedników równości w JEST) oraz beInstanceOf (która sprawdza klasę zmiennej).

Teraz napiszemy kilka oczywistych testów, żeby poznać bliżej JESTa. Wszystkie testy poniżej przechodzą.

test('if 3 is equal to 3', () => {
    expect(5).not.toBe('5');
});

test('if 3 is equal to 3', () => {
    expect(0).toBeFalsy();
});

test('if 3 is equal to 3', () => {
    expect(5).toBeLessThan(6);
});

test('if 3 is equal to 3', () => {
    expect(5).toBeGreaterThanOrEqual(5);
});

test('if 3 is equal to 3', () => {
    // strict checking 
    expect(['cat', 5]).toContain('cat');
});

test('if 3 is equal to 3', () => {
    expect(4).not.toBe(3);
});

Z powyższych przykładów powinniście zapamiętać:

• funkcję not będącą zaprzeczeniem
• niektóre funkcje sprawdzają typy strictly (z porównaniem typów, podobnie jak ===). Dlatego 5 nie jest równe '5'.
• funkcje takie jak toBeFalsy rzutują na bool'a. Jest to szczególnie przydatne przy sprawdzaniu warunków.

Podsumowanie

I jak podobało się Wam? Gotowi na więcej? Jeśli ktoś chce się podzielić uwagami na temat pisania testów w JEST lub ma inny ulubiony framework to zapraszam do sekcji komentarzy.

W następnej części przygotujcie się na testowanie funkcji oraz klas, w tym także tych asynchronicznych!

Dzisiaj specjalny post na moim blogu! Skontaktowała się ze mną Ework Group, która chce dotrzeć do Was z kwestionariuszem. Interesuje ich współpraca oparta na B2B i bardzo chcą poznać Wasze zdanie na ten temat.

Jeśli bez dodatkowych chcesz się wypowiedzieć to zapraszam do wzięcia udziału w ankiecie od razu: https://badanieb2b.eworkgroup.com/.

Jeśli jednak interesuje Was o co dokładnie chodzi to zapraszam do czytania dalej :)

Co się dzieje?

W okresie od października do grudnia 2019 na stronie internetowej https://badanieb2b.eworkgroup.com/ przeprowadzone zostanie badanie pt. „Wielkie badanie specjalistów IT na B2B”. W ramach badania przeprowadzany jest również konkurs (można wygrać IPHONE XS, szczegóły na stronie). Badanie ma na celu znalezienie odpowiedzi na pytania jakie są trendy na rynku IT, jak ma się ta branża z perspektywy freelancerów, jakie są ich potrzeby i co wymaga zmian, a w konsekwencji ocena jak ten obszar będzie rozwijał się w przyszłości. Będzie to pierwsze takie badanie na polskim rynku.

Badanie zostanie przeprowadzone przy użyciu specjalnie przygotowanej strony internetowej z kwestionariuszem online, w którym znajdą się m.in. pytania dotyczące modelu i komfortu pracy, komfortu finansowego, możliwości rozwoju. Pytania demograficzne z kolei umożliwią scharakteryzowanie grupy zawodowej jaką są specjaliści IT współpracujący na B2B.

Jak wziąć udział w badaniu i konkursie? Wystarczy wejść na stronę internetową https://badanieb2b.eworkgroup.com/ przejść przez cztery proste kroki: odpowiedzieć na pytania, wykonać krótkie zadanie konkursowe, podać swój adres e-mail (jeśli chcecie wziąć udział w konkursie) i dzięki wygenerowanemu wynikowi dowiedzieć się o poziomie komfortu swojej pracy.

Kto to organizuje?

Organizatorem badania i konkursu jest Ework Group - niezależna agencja konsultingowa zrzeszająca specjalistów IT, działająca w pochodzącym ze Skandynawii modelu biznesowym powstałym w Szwecji. Obecnie funkcjonuje również w Danii, Norwegii, Finlandii i Polsce. Główna siedziba Ework Group znajduje się w Sztokholmie, a od 2008 roku akcje firmy notowane są na giełdzie NASDAQ Stockholm. Od 2015 Ework Group działa w Polsce: w Warszawie, Wrocławiu i Gdyni. Wspiera rozwój działalności biznesowej dopasowując kompetencje do standardów projektu. Współpracuje z ponad 170 największymi firmami w większości branż, zapewniając kontrakty B2B ponad 10 000 specjalistom IT.

Chcesz mieć wpływ na komfort swojej pracy? Weź udział w „Wielkim badaniu specjalistów IT na B2B”!

https://badanieb2b.eworkgroup.com

Po zakończeniu badania opublikę i omówię wyniki. Chciałabym zacząć serię artykułów o podobnej tematyce dotykające pracy programisty: od HR, po managmentu, organizację pracy i rozwiązywanie konfliktów.