DEV Community: Poznaj dev

Jak zacząć mówić w języku obcym

Marcin Wosinek — Wed, 17 Aug 2022 04:22:00 +0000

Oto opowieść o nauce języka, która urzeczywistnia się nader często: uczysz się języka jakiś czas (mówimy tu o miesiącach lub nawet latach), ale nie umiesz wydusić z siebie najprostszego zdania. Jeśli jednak spojrzeć na to, jak wygląda przeciętna lekcja języka obcego, nie ma tu powodów do zdziwienia.

Na większości moich zajęć językowych w szkole nauczyciel skupiał się bardzo mocno na:

czytaniu artykułów na różne tematy – rzadko na takie, którymi byłbym choć trochę zainteresowany,
uczeniu się teorii gramatyki,
robieniu ćwiczeń, żeby „ćwiczyć” w tak sztucznym środowisku, że bardziej sztucznie się nie dało.

Jeśli już dochodziło do konwersacji, to głównie z innymi uczniami – którzy byli na podobnym (zbyt niskim) poziomie znajomości języka obcego.

Większość korepetycji polegała na tym samym – znowu była to strata czasu, ale uczęszczanie na nie wystawiało przynajmniej na kontakt z językiem.

Moja droga w nauce języka

Języka zacząłem się uczyć w typowy sposób – język angielski w szkole państwowej ze szczyptą pomocy w domu, a potem ze wsparciem w postaci dodatkowych zajęć w szkole językowej. Miałem dobre oceny, ale praktycznie nie potrafiłem mówić.

Wszystko się zmieniło, kiedy zmieniłem szkołę językową na taką, gdzie uczono metodą bezpośrednią – skupioną na zachęcaniu uczniów do rozmawiania w czasie zajęć. Odblokowało to moją zdolność mówienia i po raz pierwszy miałem możliwość uczenia się, w jaki sposób używać elementów słownictwa i gramatyki w konwersacji.

Mniej więcej w tym samym czasie odkryłem program do powtarzania słówek – skuteczny sposób wkuwania słownictwa. Byłem tak zachwycony skutecznością nauki języka „po mojemu”, że zrobiłem z tego hobby, które trwało kilka dobrych lat. W tym czasie odstawiłem język angielski na bok i zacząłem się uczyć od zera francuskiego. Potem przeszedłem do niemieckiego – tym razem uzbrojony w szczerą chęć nauki. W okresie mojej „świetności” całkiem nieźle mówiłem po niemiecku i francusku, a stosowanie tych języków było istotnym elementem mojego życia towarzyskiego – mimo że mieszkałem w Krakowie.

Ostatnim językiem, do którego się przyłożyłem, był język hiszpański, po tym, jak wyjechałem do Hiszpanii. Mimo że nie byłem już wtedy zafascynowany nauką języków, zanurzenie w naturalnym środowisku języka i ludzie zachęcający do jego nauki bardzo mnie motywowały.

W jaki sposób uczyłbym się kolejnego języka teraz?

Tak więc nauczyłem się, jak uczyć się języków, na przykładzie angielskiego, a potem dopracowałem swoje metody, ucząc się francuskiego, niemieckiego i hiszpańskiego. Jak działałbym teraz, gdybym wrócił do uczenia się języków?

Kilka e-lekcji w tygodniu

Mamy obecnie dostęp do ogromnej liczby platform e-learningowych – na przykład italki – i możemy w rezultacie kontaktować się z rodzimymi użytkownikami języka, którego się uczymy, niezależnie od naszego miejsca zamieszkania. Chodziłbym na kilka zajęć w tygodniu. Gdybym musiał liczyć się z wydatkami, ograniczyłbym je do 30- lub 45-minutowych sesji, ale poumieszczałbym je w różne dni tygodnia, aby mieć regularny kontakt z językiem.

Wiem, że nie potrzebuję dużo wyjaśnień opartych na teorii, więc zdecydowałbym się na tańszych nauczycieli, którzy nie zajmują się nauczaniem zawodowo. Opcja ta byłaby nie tylko tańsza – dzięki niej uniknąłbym sytuacji, w których nauczyciel wnosiłby w moje lekcje nawyki nabyte w szkole, czego chciałbym uniknąć: na przykład tracenia czasu w ilościach sporych na omawianie subtelności gramatycznych. Chciałbym mieć opanowaną gramatykę – ale na poziomie intuicyjnym, a nie analitycznym.

Skup się na mówieniu

Moje lekcje skupiałyby się tylko na rozmawianiu. Pierwszymi frazami, których bym się nauczył, byłyby:

„jak powiedzieć...?”
„co to znaczy...?”

Dzięki temu mógłbym zacząć używać języka docelowego już od pierwszych zajęć.

O czym bym mówił? Przy odrobinie szczęścia miałbym z nauczycielem na tyle dużo wspólnego, że rozmowa sama by się kleiła. Jeśli nie, zawsze znalazłyby się tematy, na które mógłbym się wypowiedzieć:

kim jestem,
co robię,
jakie mam plany na następny weekend,
czym się ostatnio zajmowałem,
aktualności, które dominują ostatnio wszystkie rozmowy – nie jakiekolwiek, ale te, o których nie da się nie mówić.

Są to dokładnie te rzeczy, o których się mówi, kiedy spotyka się obcokrajowca, z którym chce się porozmawiać lub z którym trzeba coś załatwić: ludzie, z którymi spędzasz czas na wakacjach, teściowie, ludzie, z którymi rozmawiasz na spotkaniach za granicą itd.

Notuj

Za każdym razem, gdy nauczyciel zwróciłby mi uwagę na nowe słówka czy wyrażenia, zapisywałbym je, żeby potem móc je powtarzać po godzinach. Kiedy intensywnie uczyłem się języka hiszpańskiego, miałem przyczepiony do ściany łańcuszek notatek, które starałem się czytać kilka razy dziennie. Same notatki przydawały się też podczas lekcji – jeśli ciągle zapominałem jakiegoś słowa, mogłem je po prostu znaleźć w swoich zapiskach.

Powtarzaj z innym nauczycielem

W idealnym świecie każda moja lekcja w tygodniu byłaby z innym nauczycielem. W ten sposób mógłbym nauczyć się nowych słówek dotyczących tematów poruszanych u jednego nauczyciela, a potem mógłbym je wykorzystać, opowiadając o tym samym drugiemu nauczycielowi. Oprócz tego istniałoby dużo mniejsze prawdopodobieństwo, że skończyłyby mi się tematy do rozmowy z kimś, kogo widzę tylko raz, a nie kilka razy w tygodniu.

Korzystaj z programów do nauki słownictwa

Powtarzanie w określonych odstępach czasu to świetny sposób na optymalizację nauki. Chodzi o powtarzanie słówek dokładnie w momencie, kiedy zaczynają zamazywać się w pamięci: z jednej strony dojdzie do ich zapamiętania, a z drugiej – nie będziesz spędzał nad nimi zbyt dużo czasu. Występują też papierowe wersje takich systemów, ale najskuteczniejszym sposobem jest zaprzęgnięcie do współpracy aplikacji, która zrobi wszystko za Ciebie. Przykłady programów:

SuperMemo – płatny program, z którego często korzystałem podczas nauki języka angielskiego, francuskiego i niemieckiego,
Anki – darmowy program na licencji open source, szczególnie przydatny, jeśli chcesz tworzyć własne listy słówek.

Obie aplikacje pytają o słówka, które powinieneś już znać, co pozwala na sprawdzenie swojej wiedzy, którą następnie oceniasz. Na podstawie tej oceny program umieszcza słówko w kalendarzu powtórek wcześniej, jeśli go nie pamiętałeś, albo później, jeśli je zapamiętałeś.

Co najbardziej spodobało mi się w SuperMemo:

pliki audio dla wszystkich słówek i przykładowe zdania – mogłem je powtarzać ze słuchu, nie tracąc czasu na rozszyfrowywanie alfabetu fonetycznego,
rozmiar baz danych – na wszystkich poziomach nauki aplikacja oferowała dziesiątki tysięcy słówek,
powtarzanie w określonych odstępach czasu.

Niestety dla rzadszych języków dostępnych było mniej materiałów – na przykład do nauki języka angielskiego i francuskiego można wybierać z nieprzebranej bazy zasobów, ale nie ma już takiego luksusu w przypadku języka polskiego czy baskijskiego.

Jakie są Twoje wskazówki do nauki języków obcych?

Jak do tej pory szło Ci uczenie się języków? Masz jakieś wskazówki, którymi warto podzielić się z innymi czytelnikami? Czekam na nie w komentarzach!

Jak czytać dokumentację

Marcin Wosinek — Wed, 18 May 2022 04:36:46 +0000

Jeśli zadajesz pytania, na które odpowiedzi można łatwo znaleźć w dokumentacji, reakcje będą zależeć od atmosfery miejsca pracy, nastawienia Twojego zespołu lub od forum, na którym piszesz. Osoby przyjaźnie nastawione odeślą Cię do źródeł. Natomiast osoby nastawione „mniej” przyjaźnie potraktują Cię skrótowcem RTFM – „przeczytaj tę ekhem przyjazną instrukcję” (ang. Read The Friendly Manual) – albo prześlą Ci link do Let Me Google That For You.

Lepiej nie dopuszczać do takich sytuacji.

Zobaczmy zatem, jak rozwinąć umiejętność czytania dokumentacji.

Otwórz ją

Najważniejsza sprawa – jeśli masz jakiekolwiek trudności w pracy, zacznij od próby znalezienia odpowiedzi w dokumentacji. Największą zaletą takiego podejścia jest skuteczność: w wielu przypadkach w ten sposób znajdziesz potrzebne informacje. Musisz oddać się lekturze i nieco poszperać. Im dalej będziesz na swojej ścieżce zawodowej, tym więcej problemów będzie stawać Ci na drodze – nie ma gotowego przewodnika po wszystkich niuansach programowania.

Masz jakiś problem? I bardzo dobrze!

Większość dokumentacji jest zwykle rzeczowa do bólu, a ich zadaniem jest udzielenie odpowiedzi na ewentualne pytania – nie jest to porywająca lektura. Dużo łatwiej skupić się na niej, kiedy szukasz rozwiązania problemu.

Nie cierpię czytać dokumentacji tylko po to, żeby rozeznać się w projekcie. Nie ma znaczenia, czy chodzi o nowy projekt, czy o nieznaną mi bibliotekę. Mam wrażenie, że to strata czasu, bo nie mam kontekstu, na którym mógłbym się oprzeć, i trudno jest zrozumieć powiązania między rzeczami, o których czytam.

Wolę zrobić coś po swojemu, potknąć się i wrócić do dokumentacji z konkretnym pytaniem. W takim wypadku przynajmniej wiem, czego nie wiem, i jestem zmotywowany do uzupełnienia braków w wiedzy.

Skorzystaj z funkcji wyszukiwania

Aby szybko uzyskać informacje na temat tego, jak rozwiązać problem, na który się natknąłeś, skorzystaj z narzędzi do wyszukiwania.

W przypadku bibliotek zewnętrznych możesz wykorzystać wyszukiwarki, dzięki czemu ograniczysz wyszukiwanie do strony internetowej projektu: po prostu dodaj do wyszukiwanej frazy site:<domain>:

Funkcja ta działa w Google, Bing i DuckDuckGo.

W dokumentacji znajdującej się w kodzie możesz zastosować te same narzędzia, z których korzystasz do przeszukiwania bazy kodu:

wyszukiwanie w edytorze,
ripgrep,
git grep.

Przykład na podstawie git grep:

$ git grep 'http\.post'
src/auto/injector.js: *         $http.post(trackingUrl, trackedEvents);
src/ng/http.js:     *   $http.post('/someUrl', data, config).then(successCallback, errorCallback);
src/ng/http.js:     * - {@link ng.$http#post $http.post}

Ręczne przeszukiwanie dokumentacji ma kilka zalet:

możesz zapoznać się z jej strukturą,
znajdziesz wszystkie fragmenty dokumentacji dotyczące Twojego problemu.

Dokumentacja API – suchy opis metod

Samouczek lub przewodnik dają większy kontekst.

Nie rozumiesz? Nic nie szkodzi!

Dokumentacja dokumentacji nierówna. Często nie są one łatwe w odbiorze. Ich twórcy mogą zakładać, że czytelnik posiada już pewną wiedzę o systemie, i nie wszystko będzie wprost opisane. Przez takie sytuacje nowi członkowie zespołu mogą czuć się zbici z tropu.

Najbardziej problematyczne okazują się projekty komercyjne closed source. Jeśli za utrzymywanie bazy kodu i jej dokumentacji odpowiada niewielki zespół, mogą minąć miesiące, zanim przeczyta go nowa para oczu, próbując rozeznać się w tym wszystkim.

Projekty open source są zwykle „łatwiejsze w obsłudze”. Te bez dobrej dokumentacji mają mniejsze szanse na sukces.

Dobry przewodnik nie jest zły

Jeśli w projekcie dostępny jest samouczek albo przewodnik, dobrze jest z niego skorzystać. Jeśli często borykasz się z podobnym problemem, znajdź dotyczący go fragment i po prostu go przeczytaj. Dobrze zrobiony przewodnik da Ci kontekst potrzebny do pełnego zrozumienia wykorzystywanego mechanizmu.

Zanurz się w odpowiedniej części API

Opis API to najbardziej techniczna z dokumentacji. Jest zwykle rzeczowa i brakuje jej opisów kontekstów, w których możesz zastosować konkretną metodę. Przedstawia wszystkie klasy, metody, argumenty i dane wyjściowe będące na Twoim podorędziu.

Jeżeli opis ten jest dostępny, zapoznaj się z różnymi fragmentami dotyczącymi tych samych lub podobnych rzeczy. Często jest tak, że rozwiązanie polega na odesłaniu do innej metody – więc jeśli nadal nic nie wiesz po przeczytaniu jakiegoś fragmentu, sprawdź, czy opis innych metod nie będzie bardziej przydatny.

Wyniki

W przypadku metod będziesz spotykał się albo ze zmianą stanu wewnętrznego obiektu, albo z danymi wyjściowymi. Przewodnik po API powinien dobrze opisywać oba te przypadki.

Zmiana danych wejściowych

Często zdarza się, że metody akceptują dane wejściowe w wielu kombinacjach argumentów. Dokumentacja opisze Ci pełen wachlarz możliwości wprowadzenia wszystkiego, czego potrzebujesz.

Podsumowanie

Czytanie dokumentacji jest istotną umiejętnością, której można się nauczyć tylko przez praktykę. Nie zniechęcaj się, jeśli na początku będzie Ci szło opornie; z czasem będziesz sobie radził coraz lepiej.

Chcesz wiedzieć więcej?

Przeczytaj o tym, jak zajść daleko, stawiając małe kroki.

Jak pisać testy jednostkowe

Marcin Wosinek — Wed, 27 Apr 2022 04:59:09 +0000

Początkującym programistom starsi koledzy po fachu często radzą, aby testowali swój kod. To dobra rada – zobaczmy, jak wprowadzić ją w życie!

Czym są testy jednostkowe

Testy pozwalają na ustalenie wyraźnych oczekiwań w stosunku do kodu. Dają Ci możliwość maszynowego sprawdzenia, czy Twój kod spełnia te oczekiwania.

Jest to program, który weryfikuje Twój program.

W przypadku projektów opartych na JavaScript będziesz zwykle korzystał z biblioteki testującej takiej jak:

Jest,
Jasmine,
Chai.

Są to jednak tylko narzędzia. Najważniejsze, żebyś miał na podorędziu coś, co w sposób automatyczny zweryfikuje Twoją aplikację.

Jak testy jednostkowe mogą Ci pomóc

Pisanie testów ułatwi Ci życie na cztery sposoby:

Jest to szybki i sprawdzony sposób na sprawdzenie, czy kod działa, jak należy. Nie musisz myśleć o przypadkach brzegowych, zajmą się nimi testy jednostkowe.
Dobre pokrycie kodu to zawór bezpieczeństwa, który pozwala na nieco śmielszą refaktoryzację kodu. Zwiększysz w ten sposób prawdopodobieństwo tego, że Twoja baza kodu będzie znajdować się w niezmiennie dobrym stanie.
Pisanie testów jednostkowych zmusza Cię do myślenia o jednostkach i o tym, jak rozdzielić między nie odpowiedzialność: w rezultacie Twój kod stanie się modułowy i łatwiej będzie go utrzymać.
Testy jednostkowe zrobią z Ciebie szybszego programistę. Najpierw będziesz musiał zainwestować czas na stworzenie przypadku testowego – pozwoli Ci to jednak potem na bezwysiłkowe uruchamianie go raz za razem. Inwestycja przyniesie Ci dywidendy już we wstępnej fazie programowania.

Zbuduj strukturę

Zanim zabierzesz się za testowanie funkcjonalności, upewnij się, że możesz przetestować cokolwiek. Zainstaluj bibliotekę testującą i skonfiguruj testujący skrypt. Kiedy będziesz już coś miał, zacznij tworzyć rusztowanie pod niektóre z Twoich testów. Musisz przyjąć konwencję nazewnictwa. Jeśli na przykład Twój kod znajduje się w: my-project/plane-ticket.js, nazwą Twojego kodu testującego może być: my-project/plane-ticket.spec.js.

Zbuduj wszystko, co potrzebne do przetestowania danej klasy, a potem posprawdzaj podstawowe elementy:

czy obiekt jest obiektem;
czy funkcja jest funkcją.

Dzięki temu dowiedziesz swoich umiejętności testowania.

Stwórz atrapy

Atrapa (mock) to obiekt tworzony w celu zastąpienia zależności jednostki, którą testujesz. Jeżeli na przykład testujesz funkcję saveBlogPost, będzie Ci zależeć na przejęciu żądania HTTP, zanim zostanie ono wysłane przez funkcję. Będziesz chciał się dowiedzieć, przy pomocy czego Twoja funkcja wysyła żądanie, i zastąpić to atrapą. Korzystanie z atrap powinno być proste, jeżeli budujesz kod, korzystając ze wstrzykiwania zależności.

Utrzymuj porządek

Jak widzisz, w każdym teście dużo się dzieje. Możemy wyodrębnić trzy fazy całego procesu:

tworzenie atrap;
uruchamianie kodu do sprawdzenia;
sprawdzanie oczekiwań.

Zachowanie tego podziału w kodzie ma sens: dzięki temu łatwiej będzie go czytać. Prostym sposobem na jego organizację jest zebranie wszystkich linii razem i dodanie komentarza określającego, jaka to część kodu.

Programuj w oparciu o testy – test-driven development

Programowanie oparte na testach to często spotykane podejście pozwalające na tworzenie schludnie wyglądającego kodu z dobrym pokryciem testami. Zaczynasz od dodania testu do funkcji, zanim zostanie ona wprowadzona. Uruchamiasz testy, które powinny dać wynik negatywny – jeśli tak się nie stanie, będzie to oznaczać, że coś jest bardzo nie tak: Twoim zadaniem będzie zbadać co. Natomiast po uzyskaniu w teście wyniku negatywnego dodaj do kodu brakującą implementację. Zgodnie z założeniami problem zostanie naprawiony. Jeśli wszystko pójdzie zgodnie z planem, będzie to inwestycja w ulepszenie Twojego rozwiązania – zarówno po stronie kodu, jak i testu – bez zmieniania logiki. Pozwoli Ci to na szybką iterację procesu budowania kodu i tworzenia do niego testów.

Praktykowanie takiego podejścia powinno zagwarantować regularne pisanie testów do logiki. W tej sytuacji nie odczuwacz pokusy, żeby ominąć krok obejmujący pisanie testów – a dzieje się tak często, kiedy przesuwasz ich tworzenie na koniec sprintu.

Wyjątki od reguły

Aby gdzieś dotrzeć, musisz wiedzieć, dokąd idziesz. Jeżeli chcesz rozeznać się w tym, jakie rozwiązania są wykonalne, daj sobie na chwilę spokój z testami. Po rekonesansie albo je dodaj, albo podejdź do problemu jeszcze raz, tym razem opierając się na testach.

Brakujące testy

Możesz mieć pecha i pracować na przestarzałym kodzie bez testów i innych środków kontroli jakości – czyli na przykład na czymś takim. W takim wypadku lepiej zastosować się do powiedzenia „lepiej późno niż wcale”: pracując nad bazą kodu, pisz jednocześnie testy. Idąc tą drogą, poprawisz sytuację na przyszłość, a może nawet znajdziesz podstępny bug ukryty gdzieś na rubieżach przypadków brzegowych.

A co z Tobą?

Jak trudna jest dla Ciebie nauka testowania? W Internecie można spotkać się ze skargami ludzi, którzy mają problemy ze znalezieniem dobrych materiałów dydaktycznych. Daj mi znać, jak to dotychczas wyglądało u Ciebie.

Jak zachwycić zadaniem rekrutacyjnym

Marcin Wosinek — Wed, 20 Apr 2022 05:26:46 +0000

Zobaczmy, jak sprawić, aby Twoje frontendowe zadanie rekrutacyjne wyszło jak najlepiej.

Trzymaj się tego, co umiesz najlepiej

Perspektywa upieczenia dwóch pieczeni na jednym ogniu poprzez naukę lub ćwiczenie nowej technologii podczas starania się o pracę jest kusząca. Na pewno swego czasu dla mnie taka była. Ale to nie w taki sposób dojdziesz do kodu najlepszej jakości. Lepiej wyjdziesz na trzymaniu się tego, co znasz najlepiej, i uczeniu się nowych rzeczy przy okazji pracy nad odrębnymi projektami.

Dobrze wiesz, która opcja dostanie lepszą ofertę.

Łatwość weryfikacji

Zrób tak, żeby Twoja praca była łatwa do sprawdzenia. Z punktu widzenia rekrutera idealny proces weryfikacji wygląda następująco:

otrzymanie działającego linku;
zobaczenie na własne oczy, że aplikacja działa, jak trzeba;
zagłębienie się w kod, aby zobaczyć, jak udało Ci się to uzyskać.

Weryfikacja kodu bez wiedzy o tym, czy działa, wydaje się pozbawiona sensu. Jeżeli kod nie będzie działał prawidłowo, to, jak on wygląda, nie będzie miało większego znaczenia. Jeśli natomiast sprawdzenie, czy kod działa, będzie problematyczne, może to zniechęcić do zagłębienia się w Twoją pracę.

Podaj im wszystko na tacy

Zrób coś interaktywnego

Gdy mamy do czynienia z frontendową aplikacją, najprostszym rozwiązaniem będzie wdrożenie jej na darmowy serwer:

strony GitHub,
strony GitLab,
lub Netlify.

Zapomnij o wysyłaniu plików ZIP

Przesyłanie plików ZIP jest obarczone dwiema wadami, przez które możesz odpaść już w przedbiegach:

niewygodne rozwiązanie,
otwieranie pliku ZIP stanowi zagrożenie dla bezpieczeństwa.

Ciekawe, co jest w środku!

Upewnij się, że wszystko działa

I że działa na różnych przeglądarkach i urządzeniach. Nie musi być piękne, ale musi działać – niezależnie od tego, czy weryfikator siedzi przed komputerem, czy trzyma w ręku smartfon.

Dodaj README.md

Każdy typowy projekt potrzebuje pliku README, a zadanie rekrutacyjne potrzebuje go tym bardziej. Powinieneś pokrótce przedstawić zadanie, które wykonujesz, i dodać link do działającej aplikacji. Potem możesz dodać dokumentację podsumowującą – opis frameworka, z którego skorzystałeś, oraz przedstawienie, w jaki sposób zbudować czy przetestować Twój kod.

Przedstaw swój sposób myślenia

Przedstaw weryfikatorowi swój sposób rozumowania. Jeżeli korzystasz z pewnych wzorców czy dobrych praktyk, wyraźnie się do nich odnieś w dokumentacji. Jeśli w pewnym miejscu pójdziesz na kompromis, opisz go i wyjaśnij, dlaczego postąpiłeś tak, a nie inaczej.

Niech się błyszczy

Aby się czymś wyróżnić, możesz dodać do swojego zadania któryś z elementów przedstawionych poniżej. Będzie to nieco wykraczać poza to, co miałeś wykonać, ale pokaże, że dobrze poruszasz się po zadaniach, które będziesz wykonywał w pracy każdego dnia.

Niech będzie ciekawie

Dodaj do swojego projektu kilka ścieżek. Uwagę weryfikatora na swoim zadaniu utrzymasz dłużej poprzez dodanie kilku dodatkowych stron. Może krótkie /about, żeby łatwiej mu było powiązać aplikację demonstracyjną z Twoim CV?

Test jednostkowy

Konfiguracja testów jednostkowych może być świetnym elementem, na którego przykładzie pochwalisz się swoim skupieniem na jakości. Nie musisz objąć testem całego kodu: kilka testów pokazujących, że wiesz, o co chodzi, powinno wystarczyć.

Skonfiguruj Lint i Prettier

Wiele profesjonalnych zespołów ujednolica swój styl programowania za pomocą automatycznych narzędzi. W przypadku front-endu będą to najpewniej ESLint & Prettier. Zrobienie tego samego w zadaniu rekrutacyjnym będzie miłym akcentem – jeśli w zespole znajdują się programiści, którym zależy na spójności, z pewnością to docenią.

Wprowadzaj rewizje, które coś wnoszą

Git (albo, ogólniej rzecz biorąc, kontrola wersji) jest w branży IT narzędziem kluczowym do pracy zespołowej. Zespół wykorzystuje we współpracy repozytorium Git, więc dobre komunikaty o rewizjach są nieodzowne. Jeśli stworzysz historię rewizji sensowną dla zadania rekrutacyjnego, bardzo ładnie pokaże to, jak będzie wyglądać Twój wkład w projekt firmy.

A co z Tobą?

Jakim najlepszym projektem demo możesz się pochwalić? Prześlij link w komentarzach!

Jak współpracować z mentorem programowania

Marcin Wosinek — Wed, 13 Apr 2022 05:37:18 +0000

Kontakt z bardziej doświadczonym programistą, który chce Ci pomóc w rozwoju zawodowym, może znacznie przyspieszyć Twoje postępy w branży IT. Kimś takim może być:

przyjaźnie nastawiony kolega z pracy z większym doświadczeniem,
uczynny znajomy,
mentor z zewnątrz – za którego usługi trzeba płacić (albo i nie).

Co zrobić, żeby wycisnąć z takiej pomocy jak najwięcej?

Senior JS developer

Dziel się problemami z życia wziętymi

Twój mentor ma dużo większe doświadczenie „w terenie” niż Ty. Może się nim z Tobą podzielić – o ile powiesz mu o swoich trudnościach. Na przykład:

jeśli masz przed sobą wyzwanie techniczne, może Ci polecić alternatywne rozwiązania;
jeśli nie zgadzasz się ze współpracownikiem, może ocenić sytuację i nakierować Cię na lepsze rozwiązanie podobnego sporu w przyszłości;
jeśli jesteś przytłoczony liczbą dostępnych bibliotek, może Ci pomóc w wyborze i skupieniu się na jednej z nich;
jeśli Twoja sytuacja zawodowa ma się nie najlepiej, może pomóc Ci w przygotowaniu się do rozmowy o podwyżce lub w szukaniu nowej pracy. W tym wypadku lepiej by było, gdyby mentor nie pracował w firmie, w której aktualnie pracujesz.

Bądź dobrym uczniem

Mentoring jest przyjemny, o ile Ty – uczeń – jesteś otwarty na naukę. Zwracaj uwagę na zalecenia swojego mentora. Jeśli poleci Ci artykuł, przeczytaj go; jeśli zarekomenduje książkę, zdobądź ją i przeczytaj; jeżeli będzie wychwalał kurs, kup go i ukończ. Jeśli dostaniesz informacje zwrotne z weryfikacji kodu, przynajmniej zareaguj na jego propozycje: omów ich zalety i wady, nawet jeśli nie wykorzystasz ich akurat w tej konkretnej sytuacji.

Traktuj mentora tak, jak traktowałbyś sowę.

Ucz się... podczas nauki

Jeżeli Twoja praca nie stanowi źródła problemów programistycznych, stwórz je sobie sam. Możesz poprosić mentora o weryfikację Twojego kodu w ramach pracy nad własnym projektem. Najlepiej byłoby, gdyby taki projekt był ogólnodostępny. Workflow mógłby wyglądać tak:

Robisz pierwszą wersję sam.
Mentor daje Ci wskazówki.
Wprowadzasz zmiany na ich podstawie.

Jawna praca nad własnym projektem pokazuje potencjalnemu pracodawcy trzy ważne rzeczy:

jesteś wystarczająco zmobilizowany do dostarczenia projektu;
masz pomoc z zewnątrz i Twój rozwój nie będzie opierał się wyłącznie na zasobach pracodawcy;
pokazujesz, jak dobrze znosisz krytykę i jak wykorzystujesz informacje zwrotne.

A Ty?

Jakie są Twoje doświadczenia z mentoringiem? Daj znać w komentarzach!

Po co nam wiersz poleceń (CLI)

Marcin Wosinek — Wed, 16 Mar 2022 05:56:57 +0000

Graficzny interfejs użytkownika (GUI) stał się standardem w latach 90. XX wieku. Zastąpił on wcześniej stosowany interfejs tekstowy. Dzięki temu komputery stały się ogólnodostępne. Dlaczego więc niektórzy nadal pracują na terminalach tekstowych?

Pracuje się szybko

Klawiatura to najszybsze i najdokładniejsze urządzenie do wprowadzania danych do komputera. Każdy palec ma w zasięgu kilka klawiszy i nawet przeciętny użytkownik potrafi wystukać od dwóch do trzech liter na sekundę. W porównaniu z tym mysz wypada słabo – ma tylko kilka klawiszy, rolkę i osie x i y. Nadaje się wyłącznie do wyboru opcji widocznych na ekranie, które zostały określone wcześniej. A między kliknięciami zawsze będzie kilkusekundowa przerwa.

Ze względu na te wady większość aplikacji graficznych zawiera skróty klawiszowe. Wydajne korzystanie z komputera wymaga nauczenia się wielu z nich na pamięć; patrzenie, jak ktoś kopiuje i przekleja pliki ręcznie, bez korzystania ze skrótów systemowych, zakrawa w dzisiejszych czasach o torturę. Większość GUI nie jest jednak dobra w uczeniu użytkownika skrótów klawiszowych – to często na jego barkach spoczywa ciężar szukania skrótów klawiaturowych dla opcji, z których korzysta najczęściej.

W przypadku CLI wszystko natomiast opiera się na tekście. Niektóre aplikacje uruchamia się w jednym długim wierszu poleceń, np. Git, grep, sed itd. Inne z kolei otwiera się w interfejsie tekstowym, gdzie obsługiwane są przy pomocy skrótów klawiszowych – na przykład Vim czy Emacs.

Zarządzanie złożonością

Program tekstowy obsługuje dowolną liczbę parametrów, ale wystarczy, że znasz te, które są Ci potrzebne. Zastanawiałeś się kiedyś nad tym, jak dużo takich parametrów posiada przeglądarka internetowa Chromium? Ponad 1000 (źródło). Siedzą sobie tam i czekają, aż ich użyjesz. Są one jednak zazwyczaj niewidoczne – chyba że zaczniesz wczytywać się w dokumentację.

Takie bogactwo możliwości jest nieosiągalne dla aplikacji opartych na GUI. Rzadziej stosowane opcje albo zaśmiecają ekran, albo kryją się w ogromnych, wielowarstwowych menu. W rezultacie dostajemy:

proste programy dla prostych przypadków użycia z przystępnym interfejsem albo
profesjonalne programy z przytłaczającymi interfejsami, gdzie trudno o doszukanie się nawet najprostszych z opcji.

Skrypty

Programy tekstowe przyjmują tekst jako dane wejściowe i dane wyjściowe oddają również w postaci tekstu. Na poziomie dane wejściowe/wyjściowe wszystkie programy CLI są kompatybilne: przy pomocy git ls-files możesz wyświetlić wszystkie pliki w swoim repozytorium, a następnie zastosować grep, aby je przefiltrować – wystarczy Ci do tego operator potoku:

$ git ls-files | grep index
home-page/index.html
registration/index.html
index.js

Operator potoku daje Ci dostęp do supermocy obliczeniowych, do których świat graficzny dostępu nie ma i nigdy mieć nie będzie. Działania takie jak:

tworzenie tysięcy folderów czy
wyszukiwanie wszystkich plików pasujących do wzoru lub zawierających taki wzór i wykonywanie na nich wszystkich operacji

są całkiem proste i wymagają nieco pobuszowania w sieci, przeczytania dokumentacji i zastosowania metody prób i błędów.

Interfejs użytkownika

Z tych powodów wiersz poleceń stanowi w wielu programach główny interfejs. Jako użytkownik jesteś więc niemalże zmuszony do jego stosowania. Najlepszym przykładem będzie tu Git: można dostać do niego jakieś GUI, ale korzystanie z nich tworzy jeszcze jeden poziom abstrakcji nad danymi, którymi zarządzasz. Jeśli z Gita korzystasz codziennie, nauka jego CLI da Ci bardzo dużo. Moim zdaniem GUI pozwala Ci na osiągnięcie 80% swoich celów, ale możesz też natknąć się na jeden z tych dziwniejszych przypadków, którym będziesz mógł się zająć wyłącznie przy pomocy wiersza poleceń.

A co z Tobą?

Jakie masz doświadczenia z CLI? Jakich rzeczy chciałbyś się w ich zakresie nauczyć? Daj mi znać w komentarzach!

Jak zajść daleko, stawiając małe kroki

Marcin Wosinek — Thu, 10 Mar 2022 11:21:02 +0000

Wszyscy czasem bierzemy na siebie zadania, które przekraczają nasze możliwości – wynika to z naszej niezdolności do prawidłowej oceny złożonych zadań. Zastanówmy się, co z tym zrobić w odniesieniu do Twojej przygody programistycznej.

Iteracja

Niewielkie posunięcia, które nie wymykają się spod kontroli, są podstawą wielu metodologii popularnych w naszej branży, na przykład:

Agile – opiera się całkowicie na nieustannym wprowadzaniu zmian w produkcie w celu odkrycia potrzeb klienta,
produkt o kluczowej funkcjonalności (ang. minimum viable product – MVP) – zakłada wydanie pierwszej funkcjonalnej wersji produktu, aby umożliwić sprawdzenie jej przez rynek, a następnie wprowadzanie kolejnych zmian.

Zobaczmy, jak wykorzystać podobne podejście w życiu codziennym.

W nauce

Najlepszym pomysłem byłoby:

nauczenie się części materiału, a następnie
zastosowanie go w praktyce.

W dobrym kursie lub w dobrej książce będziesz regularnie dostawał wyzwania, które pozwolą Ci sprawdzić Twoje postępy. Jeśli uczysz się bez takich luksusów, tego rodzaju zadania będziesz musiał tworzyć sobie sam. W obu przypadkach najlepszą informacją zwrotną będzie to, czy Twój kod działa, jak należy – więc powinieneś albo wykorzystać to, czego uczysz się przy swoim dodatkowym projekcie, albo zacząć nowy.

W pracy nad ticketem

Czy często zdarza Ci się utknąć nad ticketem? Możliwe, że próbujesz robić zbyt wiele rzeczy naraz. Poszczególne zadania można zwykle podzielić na kilka części:

refaktoryzacja kodu, nad którym masz zacząć pracować,
dodanie infrastruktury kodu – helperów, różnych rodzajów aktualizacji itd.,
wprowadzanie zmian w logice aplikacji,
dodanie testów integracyjnych do nowej funkcji.

W większości przypadków warto zrobić osobną rewizję z każdą z tych zmian: nie ma sensu weryfikować lub cofać refaktoryzacji razem z implementacją zmian w logice. Podział na osobne rewizje, a nawet propozycje zmian pozwalają na szybszą weryfikację kodu, co przyspieszy Twoje postępy.

A co jeśli nie jesteś zaznajomiony z kodem wystarczająco dobrze, aby zaplanować działania z wyprzedzeniem, albo po prostu zapomniałeś i wprowadziłeś wszystkie zmiany jednocześnie? Nie martw się: wiedza, którą zdobyłeś przy pierwszej próbie, nie pójdzie na marne – daj sobie chwilę oddechu, zacznij nową gałąź i zastosuj lub przerób część tej dużej rewizji, nad którą zacząłeś pracować.

W pracy nad projektami

Niezależnie od tego, czy pracujesz w projektach komercyjnych, czy open source – wszędzie usłyszysz to samo:

„wydawaj szybko, wydawaj często”,
„działaj szybko i popełniaj błędy”.

Możesz to zastosować nawet w pracy nad swoim osobistym projektem do nauki. Zamiast planować dużą, końcową wersję produktu, spróbuj jak najbardziej uprościć to, co budujesz. Kilka rad w tej kwestii znajdziesz w moim artykule na temat tego, jak uczyć się podczas pracy nad własnymi projektami.

Unikaj utykania nad problemem

Twoim głównym celem w pracy na podstawie iteracji jest unikanie utknięcia z problemem. Dobrze jest przeznaczyć czas na zbadanie nowego tematu; jako programista musisz być odporny na frustrację wynikającą z niewiedzy na temat tego, jak coś działa albo jak naprawić bug. Odporność ta jednak jest jak miecz obosieczny i może zwrócić się przeciwko Tobie. Korzyści ze zgłębiania tematu będą coraz mniejsze, aż w końcu takie dokształcanie się stanie się zwyczajnym marnotrawstwem czasu. A kiedy do tego dojdzie, będziesz już dobrze obeznany w temacie i na dobrej drodze do naprawienia problemu, a co za tym idzie – niełatwo będzie Ci odpuścić. Zobaczmy, jak uniknąć takich pułapek!

Nie jesteś sam

Najczęściej nie pracujesz sam: w Twoim środowisku znajdują się ludzie, którzy mogą Ci pomóc. Jako początkujący programista możesz tu popełnić błąd w dwojaki sposób:

poprosić o pomoc zbyt szybko,
poprosić o pomoc zbyt późno.

Co to znaczy „zbyt szybko”, a co „zbyt późno”? To zależy od sytuacji Twojego zespołu. Na myśl od razu przychodzą mi dwie sytuacje:

zespół pracuje pod dużą presją – trzeba zażegnać kryzys, więc żaden bardziej doświadczony programista nie ma czasu, żeby Ci pomóc;
przejmujesz projekt po programiście, który kończy pracę za dwa tygodnie, więc Twoim głównym zadaniem jest uzyskanie od niego jak najwięcej informacji.

Radzę określić w zespole konkretne zasady, a potem się ich trzymać. Jeżeli ustalicie, że cztery godziny walki z ticketem bez żadnych rezultatów to za dużo, to po bezskutecznym upływie tych czterech godzin poproś o pomoc.

Czasem lepiej odpuścić

Pomysł nie stanie się nagle lepszy tylko dlatego, że przeznaczyłeś na jego wprowadzenie bardzo dużo czasu. Wręcz przeciwnie: takim działaniem tylko pokażesz, że nie jest wykonalny albo że nie jest tak prosty, jak zakładałeś. Miej świadomość efektu utopionych kosztów – najlepiej będzie z wyprzedzeniem określić czas, jaki chcesz przeznaczyć na zadanie, zanim odpuścisz jego realizację, a następnie porzucić zadanie, jeśli zajmie Ci ono więcej czasu, niż chciałeś na nie przeznaczyć. Odpuszczenie ticketu w zależności od jego rodzaju może znaczyć pozostawienie go innemu programiście lub całkowite zaniechanie pracy nad nim, przynajmniej w danym momencie.

Wypatruj informacji zwrotnej w każdej sytuacji

Każdy etap interakcji jest momentem, w którym możemy – i powinniśmy – uzyskać feedback. Dzięki niemu wprowadzimy potrzebne korekty i upewnimy się, że zmierzamy w dobrą stronę. Istnieje bardzo dużo rodzajów informacji zwrotnej, na które można zwrócić uwagę:

testy automatyczne wykonywane lokalnie lub w ramach CI,
weryfikacja kodu przez bardziej doświadczonego kolegę po fachu lub mentora,
zebranie informacji zwrotnej po prezentacji produktu na zewnątrz.

Chcesz dowiedzieć się więcej? Przeczytaj artykuł o pętlach informacji zwrotnej.

Jak przyspieszyć pracę dzięki informacji zwrotnej

Marcin Wosinek — Wed, 02 Mar 2022 06:25:14 +0000

Pętla informacji zwrotnej to kluczowy element wszystkich systemów kontroli, z wyjątkiem tych trywialnych. A jeżeli zależy Ci na innych celach, takich jak:

uczenie się,
zbudowanie działającej aplikacji,
zarabianie pieniędzy,

to masz do czynienia z systemem kontroli, który trywialny nie jest. Spójrzmy wobec tego na najważniejsze cechy skutecznej pętli informacji zwrotnej i zastanówmy się, jak mógłbyś ją wykorzystać w swojej karierze programistycznej.

Im szybciej, tym lepiej

Im szybciej dowiesz się, czy wszystko idzie zgodnie z planem, tym lepiej. Posuwanie się do przodu po omacku nic Ci nie da. Jeśli jesteś na dobrej drodze, informacja zwrotna zmotywuje Cię do dalszego działania. Jeśli natomiast robisz coś źle, uzyskany feedback pozwoli Ci to zmienić. Wyobraź sobie, jak skomplikowana byłaby jazda na rowerze, gdyby sygnał z Twoich oczu dochodził do mózgu z choćby milisekundowym opóźnieniem: prowadziłbyś rower, jakbyś był pijany.

W zależności od złożoności systemu podejmowanie działań na podstawie uzyskanej wiedzy wymaga czasu. Jeśli dowiesz się, że Twoja aktualna ścieżka zawodowa nie jest dla Ciebie, nadal będziesz musiał przeznaczyć kilka lat na nauczenie się nowego fachu. Ale zdecydowanie wolałbyś zdobyć tę informację na pierwszym semestrze studiów, a nie po ich ukończeniu.

Codzienne pętle informacji zwrotnej

Spróbujmy zebrać w jednym miejscu wszystkie pętle informacji zwrotnej, z którymi stykasz się codziennie jako programista.

Zmiany w kodzie

Praca nad kodem wymaga sprawdzania wpływu wprowadzanych zmian na jego zachowanie. Testy automatyczne są szybkim i dobrym sposobem na pozyskiwanie informacji zwrotnej. Pisanie ich wymaga na początku nakładu czasu, ale jednocześnie zwiększa Twoją produktywność, nie mówiąc już o ich długofalowym wpływie na jakość, jeśli stosowane są regularnie.

Gdy mam przed sobą logikę, która jest skomplikowana, lubię zaczynać pracę od napisania testów. Zrozumienie wszystkich szczegółów projektu jest trudne i wolę zrobić to podczas tworzenia testów, a nie za każdym razem, kiedy wprowadzam w kodzie zmiany.

Codzienna praca nad ticketem

Jeśli działasz w dobrze zorganizowanym zespole, ktoś będzie weryfikować Twoją pracę. Jest to świetny sposób na to, żeby się dowiedzieć, w jaki sposób zespół wykonuje swoje zadania, a także dokształcić się z programowania. Praca nad ticketem przez dzień czy dwa tylko po to, aby dostać ponad 40 propozycji zmian naraz, może być frustrująca.

Aby temu zapobiec, możesz podzielić swoją pracę na kilka mniejszych etapów i prosić o informacje zwrotne po zakończeniu każdego z nich:

Po przeczytaniu ticketu przekaż jego treść swoimi słowami osobie, która rozumie, czego on dotyczy. Jeśli czegoś nie zrozumiałeś, będzie ona mogła skorygować Twój sposób myślenia.
Napisz plan rozwiązania problemu – i daj go innemu programiście do weryfikacji, zanim przeznaczysz czas na jego wdrożenie. Możliwe, że zwróci Ci uwagę na coś, co Ci umknęło.
Najważniejsza jest jednak informacja zwrotna dotycząca logiki programu. Poproś o weryfikację kodu, kiedy jeszcze aktualizujesz testy.

Wersja aplikacji

W miarę jak sprint posuwa się do przodu, rośnie zbiór zmian czekających na dostarczenie. Czekanie w takiej sytuacji miałoby sens tylko wtedy, gdybyś w tym czasie robił coś konstruktywnego, na przykład realizował złożony protokół testowania aplikacji. Jeśli jednak nie są wykonywane żadne sensowne testy, to tylko opóźniasz moment, w którym zaczniesz dostawać feedback od użytkowników. Zamiast tego proces wdrażania staraj się przeprowadzać jak najczęściej. Dzięki temu unikniesz wydania jednego dużego release’u zawierającego wszystkie zmiany (i bugi) wprowadzone przez Twój zespół przez całe kilka tygodni sprintu – zamiast tego będziesz wydawał zmiany po trochu, co kilka dni.

Dopasowanie produktu do rynku

Aspekt ten znajduje zastosowanie nawet na szerszą skalę. Metody takie jak Agile czy Lean Startup wskazują, że najlepiej jest wydać produkt jak najszybciej, co pozwoli na zebranie feedbacku od klientów.

Co z jakością informacji zwrotnej?

Nie każda informacja zwrotna ma taką samą wartość. Wszystko dzieje się na pewnym kontinuum – od dokładnych wyników testów do subiektywnej opinii osoby udzielającej informacji zwrotnej. W przypadku informacji obiektywnych, takich jak:

negatywny wynik testu lub nieprawidłowe działanie funkcji,
zbyt wolne działanie aplikacji,
przyjmowanie nieoczekiwanych wartości przez inne wskaźniki wydajności,

dobrze jest natychmiast rozpocząć proces naprawy.

Natomiast w przypadku opinii subiektywnych, które mogą dotyczyć:

podejścia do kodowania,
nazewnictwa zmiennych lub metod,
innych spraw, które różni programiści zrealizowaliby na różne sposoby,

sytuacja wymaga wyważonego podejścia. Możliwe, że pracujesz wbrew konwencji przyjętej w projekcie albo Twoje nazewnictwo wprowadza zamęt – takimi problemami najlepiej zająć się od razu. Zdarza się jednak, że niektóre osoby dzielą się sposobem, w jaki poradziliby sobie z konkretnym problemem, tak po prostu, wiedzione chęcią omówienia metodologii pracy nad projektem.

A co z Tobą?

Czy kiedykolwiek dostałeś informację zwrotną, która zmieniła bieg Twojej kariery? Daj mi znać w komentarzach – przeczytam na pewno!

Jak wykorzystać Netlify do procesu ciągłej integracji

Marcin Wosinek — Thu, 24 Feb 2022 06:03:03 +0000

Netlify to dostawca hostingu, z którego usług możesz korzystać na potrzeby swoich statycznych stron internetowych czy aplikacji webowych. Opcja darmowa daje 300 minut czasu na proces budowania, co powinno wystarczyć do skonfigurowania ciągłego wdrażania (CD) w projekcie, w którym nie wprowadza się dużo rewizji. Pokażę Ci, jak – korzystając z tych zasobów – dodać prosty proces ciągłej integracji do swojego buildu.

Przykładowa aplikacja

Żeby za bardzo nie komplikować sprawy, oprę się na przykładzie aplikacji wygenerowanej w Create React App (CRA). Dzięki temu będziemy mieć do dyspozycji aplikację, która:

przypomina proste, rzeczywiste przypadki,
posiada kilka zależności npm,
zapewnia już większość tego, co potrzebujemy.

Powstała aplikacja wygląda następująco:

Etapy weryfikacji

Niedawno pisałem o działaniach, które możesz podjąć dzięki CI. Pokażę Ci teraz, jak skonfigurować ten proces pod naszą przykładową aplikację.

Budowanie

Kod wygenerowany przez CRA robi wszystko, co będzie Ci potrzebne do procesu budowania:

$ npm run build

> netlify-ci@0.1.0 build
> react-scripts build

Creating an optimized production build...
Compiled successfully.

File sizes after gzip:

  43.71 kB  build/static/js/main.1fb16459.js
  1.78 kB   build/static/js/787.c84d5573.chunk.js
  541 B     build/static/css/main.073c9b0a.css
…

Netlify wybiera skrypt build z repozytorium wygenerowanego przez CRA automatycznie jako polecenie budowania i wszystko działa bez żadnych problemów:

Testy

Kod wygenerowany przez CRA obejmuje konfigurację pozwalającą na uruchamianie testów jednostkowych i jeden test przykładowy. Skrypt npm test został stworzony do programowania: uruchamia się w trybie interaktywnym, a jego domyślna konfiguracja zakłada obserwowanie plików. Uruchomienie w kontekście CI wymaga jednej iteracji:

$ npm test -- --watchAll=false

> netlify-ci@0.1.0 test
> react-scripts test "--watchAll=false"

 PASS  src/App.test.js
  ✓ renders learn react link (16 ms)

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

Zdefiniujmy teraz nowy skrypt w package.json, aby mieć go na podorędziu:

{
  …
  "scripts": {
    …
    "test": "react-scripts test",
    "test:ci": "react-scripts test --watchAll=false",
    …
  },

Analiza statyczna

Kod warto wzbogacić o analizę statyczną. Podstawowa konfiguracja powinna być dość prosta, ale nie będę jej omawiał w tym artykule. Jeśli chcesz rozwinąć się w tym temacie, polecam zacząć od:

ESLint – ze względu na to, że ostrzega Cię przed potencjalnymi problemami występującymi w kodzie,
Prettier – bo pozwala Ci w sposób automatyczny zachować jednorodny styl programowania.

Nowy skrypt CI

Aby pomyślnie uruchomić CI/CD, wykonaj następujące działania na stworzonym kodzie:

npm install – zapewnia zależności, realizowane domyślnie przez Netlify,
npm run test:ci – zmodyfikowane polecenie testowania,
npm run build – oryginalne polecenie budowania,
wdrożenie – realizowane przez Netlify.

Build powinien być zależny od testów: jeśli one zawiodą, proces wykonywania powinien się zatrzymać – dlatego zastosuję '&&'. W ramach konfiguracji Netlify polecenie to może jednak uruchomić tylko jeden input. Stworzenie nowego skryptu przeznaczonego do tego przypadku użycia pozwala zająć się obiema kwestiami:

{
  …
  "scripts": {
    …
    "test:ci": "react-scripts test --watchAll=false",
    "ci": "npm run test:ci && npm run build",
    …
  },
  …
}

Przykładowe uruchomienie

Po całej konfiguracji skrypty będą zachowywać się tak:

jeżeli testy buildów dadzą wynik negatywny, pulpit Netlify pokaże uruchomienie zakończone niepowodzeniem;
jeżeli wszystko działa jak należy, aplikacja zostanie wdrożona.

Wykorzystanie zasobów

W ramach przeprowadzonych przeze mnie uruchomień testy nie miały praktycznie żadnego wpływu na czas budowania, czyli zasób, który Netlify sprawdza, aby kontrolować stopień wykorzystywania systemu. Będzie się to oczywiście zmieniać, w miarę jak Twój projekt będzie się rozrastał i będziesz do niego dodawał kolejne testy. W pewnym momencie dobrze będzie zainwestować w konfigurację dedykowanego rozwiązania CI, a z Netlify korzystać tylko na potrzeby hostingu.

Linki

Co zrobiłbyś dalej?

Uruchamianie CI na Netlify to tylko tymczasowe rozwiązanie. Z jakiego narzędzia skorzystałbyś w następnej kolejności? Chciałbym wiedzieć, co ciekawi czytelników mojego bloga. Daj mi znać w ankiecie.

Czym jest ciągła integracja (CI) i jak może Ci pomóc

Marcin Wosinek — Wed, 16 Feb 2022 05:44:16 +0000

Ciągła integracja (CI) to proces weryfikacji projektu po każdorazowym wprowadzeniu zmiany w bazie kodu. Czym dokładnie jest integracja? To zależy od tego, jak skonfigurujesz ten proces: może być to coś tak prostego jak instalacja zależności i kompilacja projektu albo skomplikowana operacja polegająca na uruchamianiu wielu różnych skryptów celem stwierdzenia, czy Twój kod znajduje się w odpowiednim stanie.

Pilny współpracownik

Proces CI możesz traktować, jak pilnego współpracownika, który zawsze jest gotowy do pracy, tylko czekając na Twoje zmiany, aby móc je sprawdzić przed scaleniem ich do gałęzi głównej. W przypadku korzystania z CI warto mieć w workflow pull request, nawet jeśli pracujesz nad projektem sam. Twoje zmiany zostaną zweryfikowane przez maszynę, a umieszczenie ich na osobnej gałęzi pozwoli Ci na naprawę wszelkich wykrytych błędów, zanim zostaną scalone do gałęzi głównej.

Bez CI każdy programista odpowiada za weryfikację wszystkich wprowadzanych przez siebie zmian. Prędzej czy później któryś z członków zespołu zapomni o takiej weryfikacji – może oryginalne zmiany są w porządku, ale co będzie, jeśli po przeprowadzeniu rebase’a lub scalenia pojawi się problem? Jeśli nie korzystasz z procesu CI, pozwalasz mniej uważnym kolegom z zespołu na wrzucanie zmian z błędami i zapominanie o nich, a cały bałagan będą musieli po nich sprzątać inni.

Jak jest zorganizowane CI

Ciągła integracja sprawdza Twoje rewizje. Każda zmiana kodu pociąga za sobą wykonanie kilku różnych zadań w określonym porządku. Możesz wykorzystać dane wyjściowe z jednego zadania jako dane wejściowe w drugim zadaniu; możesz na przykład zbudować aplikację, a potem wykorzystać powstały dzięki temu pakiet do przeprowadzenia testów aplikacji. CI zarządza się zwykle z poziomu pliku konfiguracyjnego, który znajduje się w repozytorium – dzięki temu CI ewoluuje razem z Twoją bazą kodu.

Jeśli wszystkie zadania zostaną wykonane prawidłowo, commit przejdzie weryfikację pomyślnie; jeśli któreś z nich nie zostanie wykonane, commit nie przejdzie weryfikacji. W idealnej sytuacji sama zawartość commitu decyduje o wyniku CI: nie będą miały znaczenia usługi zewnętrzne ani nie będzie żadnego losowego elementu, który mógłby namieszać.

CI pokazuje wynik dla najnowszej rewizji. Gałąź główna powinna dawać wynik pozytywny w zdecydowanej większości przypadków; jakiekolwiek problemy wykryte w tym miejscu będą wpływać na cały zespół, jeśli więc dojdzie do regresji, naprawianie ich powinno być priorytetem. Gałęzie funkcjonalności należy scalać dopiero, gdy przejdą przez CI z wynikiem pozytywnym.

Zadania, którymi może zająć się CI

W procesie CI możesz umieścić wszelkie skrypty, które wykonujesz w swoim środowisku lokalnym. W przypadku większych projektów takich skryptów może być bardzo dużo. Przyjrzyjmy się jednak zadaniom tego procesu, które pojawią się najpewniej w każdym projekcie, niezależnie od jego wielkości.

Budowanie

Najprostszym testem, który możesz przeprowadzić na swoim kodzie, jest sprawdzenie, czy się kompiluje. Dzięki temu wyłapiesz wszystkie zależności, które zostały zainstalowane, ale nie zapisane, wszelkie rozbieżności typu TypeScript, które przedostały się do rewizji. Błędy te można łatwo usunąć, kiedy programista pracuje nad zadaniem, ale kiedy zostaną one udostępnione pozostałym członkom zespołu, mogą dezorientować i denerwować.

Analiza statyczna

Analiza statyczna zakłada sprawdzenie kodu bez jego uruchamiania. W projektach frontendowych często można spotkać się z narzędziami takimi jak:

ESLint,
HTMLHint,
Stylelint.

Programy te dają najlepsze rezultaty, jeśli integruje się je z edytorem kodu. Sprawdzenie ich wyniku w ramach procesu CI stanowi dodatkową weryfikację, która może Ci pomóc w dwojaki sposób:

zidentyfikuje każdego programistę, który zapomniał o wykonaniu tych programów u siebie – dzięki czemu możemy go poprosić, aby naprawił swoje zmiany, zanim zepsuje większy fragment kodu,
zidentyfikuje wszelkie rozbieżności w wersjach i konfiguracjach, które mogą występować w różnych środowiskach programistycznych

Wykonywanie testów

Korzystanie z procesu CI i wykonywanie w jego ramach testów jest kluczowe, jeśli poważnie podchodzisz do zautomatyzowanych testów w swojej aplikacji. Testy te mają sens, jeśli wykonuje się je bardzo często – a nie ma na to chyba lepszego momentu niż zaraz przed wprowadzeniem zmian do głównej gałęzi. Zaniechanie tego prędzej czy później sprawi, że:

jeden z programistów doprowadzi do regresji bazy kodu,
pozostali członkowie zespołu naniosą na tę regresję zmiany,
ktoś w końcu wykona testy, które wykryją początkową regresję,
ten ktoś traci cenny czas na rozwiązywanie problemów, których nie spowodował, związanych ze zmianami, o których może nie mieć pojęcia.

Głównym wyzwaniem w takiej sytuacji jest to, że kiedy w końcu zaczniesz diagnozować problemy, nie będziesz nawet wiedział, kiedy one powstały: w poprzednim commicie, a może tydzień temu? Sprawę można załatwić poprzez git blame lub git bisect, ale dużo prościej jest, kiedy wiesz, w którym momencie testy przestały działać.

Podkreślę tu coś jeszcze: pisanie testów jest inwestycją w jakość. Jest to praca, którą trzeba wykonać każdego dnia. Jeśli to robisz, warto, żebyś skonfigurował CI – dzięki temu opracowywane przez Ciebie testy dadzą najlepsze rezultaty.

Wdrażanie

CI często idzie w parze z ciągłym wdrażaniem (CD), a połączenie to często skraca się do CI/CD. Jest tak dlatego, że kompilacja i weryfikacja kodu prowadzi do powstania gotowego do wdrożenia produktu – przynajmniej na serwer testowy. Proces CD z prawdziwego zdarzenia wezwałby Cię do wprowadzenia tego produktu do środowiska produkcyjnego, ale mogłoby to być jeszcze większym wyzwaniem, bo wystawiałoby użytkowników projektu na potencjalne regresje.

Minusy

Jakie są minusy CI?

Skomplikowana konfiguracja

Konfiguracja ciągłej integracji może Ci zabrać sporo czasu, zwłaszcza jeśli zajmujesz się nią po raz pierwszy. Weryfikacja nawet najprostszych zmian w konfiguracji może być czasochłonna, bo musisz ją przeprowadzić na zewnętrznym serwerze, do którego nie masz bezpośredniego dostępu.

Zależność od zewnętrznego dostawcy

Jeśli zintegrujesz CI ze swoim workflow, będziesz zależny od dostawcy tego procesu. Jeśli usługa będzie niedostępna, nie będziesz mógł scalać albo zostaniesz pozbawiony zaworu bezpieczeństwa, do którego już zdążyłeś się przyzwyczaić. Może to być frustrujące, szczególnie jeśli zdarza się dość często.

Koszt

Wielu dostawców CI oferuje opcję darmową, która powinna wystarczyć do prostych ćwiczeń lub projektów demo. Do projektów, nad którymi pracuje się na okrągło, prawie na pewno potrzebna będzie opcja płatna oraz dodatkowy czas, w którym CI będą mogły wykonać Twoje skrypty. Będzie to jednak najprawdopodobniej warte swojej ceny, nawet przy założeniu, że CI zaoszczędzi każdemu z programistów w Twoim zespole jedynie kilka minut pracy dziennie.

A co z Tobą?

Jesteś zainteresowany pogłębianiem wiedzy na temat konfiguracji CI? Myślę o napisaniu bardziej szczegółowych artykułów na temat konfigurowania narzędzi CI. Jeśli będę wiedział, jakie narzędzie interesuje Cię najbardziej, będę mógł tworzyć treści pod tym kątem.
Tak więc daj mi znać w ankiecie! Twoje zdanie jest dla mnie bardzo cenne. Dzięki!

Co dalej?

Aby wycisnąć z CI jeszcze więcej, warto przeprowadzać w ramach tego procesu testy end-to-end (E2E). Konfiguracja E2E na CI to nie lada wyzwanie. Będę o tym pisał w kolejnym artykule. Tymczasem zachęcam do lektury poradnika, w którym tłumaczę, jak zacząć pracę z testami E2E.

Po co nam bundlery JavaScript

Marcin Wosinek — Wed, 09 Feb 2022 06:04:01 +0000

JavaScript jest językiem interpretowanym, nie potrzebuje kompilacji. Twoja przeglądarka wykonuje ten sam kod, który piszesz. Po co więc stosować bundlery JavaScript?

Mniej plików JS

Swego czasu liczba plików JS wykorzystywanych przez witrynę internetową była kluczową sprawą, ponieważ duża liczba takich plików o niewielkim rozmiarze powodowała spadki wydajności. Przeglądarki ładowały każdy plik na podstawie odrębnego żądania HTTP. Każde żądanie wymagało połączenia między przeglądarką a serwerem, a to za każdym razem zajmowało nieco czasu. Aktualnie, dzięki protokołowi HTTP/2, liczba plików nie tworzy już takich problemów. Nadal jednak pakowanie plików razem ma sens. Każde żądanie jest zapisywane osobno w pamięci podręcznej, więc duża liczba plików sprawia, iż trudniej jest zapewnić, że przeglądarka nie załaduje z tej pamięci nieodświeżonego kodu.

Poza tym do 2018 roku wiele przeglądarek nie obsługiwało modułów ES. Ładowało się wiele plików z HTML i wszystkie dzieliły zakres globalny. Bundlery JS rozwiązują oba problemy, ponieważ:

pozwalają na przechowywanie bazy kodu podzielonej na wiele dobrze zorganizowanych plików,
pakują kod w duże pliki do wrzucenia na serwer.

Prosty import z `node_modules`

Bundlery dają Ci możliwość importowania zależności, co jest dużo wygodniejsze niż ładowanie ich jako modułów ES. Aby wykorzystać pakiety węzłów otrzymane z przeglądarki, musiałbyś:

opublikować node_modules na serwerze produkcyjnym,
zastosować ścieżkę względną od Twojego pliku do pliku, który chcesz importować.

Stosowanie ścieżki względnej jest problematyczne, bo zmusza Cię to do pisania importu na nieco różne sposoby, w zależności od tego, jak głęboko w strukturze folderowej akurat się znajdujesz. W przypadku Lodash będziesz mieć coś takiego:

// in ./src/core.js 
var _ = require('../node_modules/lodash/lodash.js');

// in ./src/app/main.js
var _ = require('../../node_modules/lodash/lodash.js');

Bundlery pozwolą Ci na uzyskanie tego samego prościej:

// anywhere
var _ = require('lodash');

Import innych rodzajów plików

Twoja baza kodu składa się nie tylko z JavaScript. Jeżeli porządkujesz swój kod według komponentów lub ścieżek, każdy taki element będzie mieć swój własny szablon i swoją własną stylizację. Natywne moduły ES nie pozwalają na importowanie typów zasobów innych niż JS. Przez to ograniczenie byłbyś zmuszony zaimportować CSS z HTML, ale reszta byłaby importowana w JavaScript – co sprawiłoby, że musiałbyś zsynchronizować dwa niezwiązane ze sobą pliki. Bundlery JS obchodzą ten problem, pozwalając Ci zarządzać wszystkimi zależnościami bezpośrednio z Twoich plików JS:

import ‘./core.js’;
import ‘./style.css’;

const template = require(‘./view.html’);

Transpilacja kodu

Duża część JavaScript to tak naprawdę nie tylko JavaScript: jest on pisany w językach takich jak TypeScript, a następnie kompiluje się go do JavaScript. Taka kompilacja z jednego kodu do drugiego nazywa się transpilacją. Poddawana jest jej większość kodu pisanego w JavaScript. Poniżej tłumaczę, dlaczego tak jest.

Minifikacja kodu

Jeśli piszesz swój kod tak, jak trzeba, to:

nadajesz zmiennym sensowne nazwy,
stosujesz wcięcia,
zostawiasz komentarze dla pozostałych programistów.

To wszystko to tylko szum, który dla interpretera nie znaczy zupełnie nic. Minifikacja jest pierwszym krokiem na drodze redukcji rozmiaru payload. Usuwa wszystko, co nie ma wpływu na działanie aplikacji.

Downgrade do starszych wersji przeglądarek

Kiedy kod poszerza wachlarz swoich funkcji, w pewnym momencie dochodzi do sytuacji, w której:

developerzy chcą zacząć już z niego korzystać,
nie jest on obsługiwany przez wszystkie przeglądarki.

Na szczęście sytuacja taka utrzymuje się już znacznie krócej dzięki przeglądarkom typu evergreen, ale nadal istnieje zapotrzebowanie na projekty pokroju Babel. Kompilator ten pozwala Ci na korzystanie z najnowszej wersji języka podczas kodowania i na transpilowanie kodu do wersji obsługiwanej przez starszą wersję przeglądarki.

Odmiany JavaScript

Obok standardowego JavaScript możesz korzystać z wielu jego odmian:

TypeScript,
PureScript,
Elm,
CoffeeScript.

Bundlery JavaScript radzą sobie z jednolitym mieszaniem różnych odmian w jednym projekcie – co wydaje się kiepskim pomysłem dopóty, dopóki nie zaczniesz pracować z przestarzałym kodem i dopóki nie będziesz potrzebować dużej dozy elastyczności, żeby wybrać odpowiednie priorytety.

Osobne buildy dla różnych przypadków użycia

Kiedy zaczniesz już kompilować swój kod bundlerem, otworzą się przed Tobą nowe możliwości. Najpewniej od samego początku kompilujesz kod w jeden sposób na potrzeby środowiska produkcyjnego, a inny na potrzeby programowania lokalnego. Jeśli piszesz testy jednostkowe, możesz być ciekaw, jak dobrze weryfikują one Twój kod. Istnieją narzędzia, które dadzą Ci dokładną odpowiedź na to pytanie – są to tzw. narzędzia mierzące pokrycie kodu. Wymagają one dedykowanego buildu obejmującego narzędzia zliczające, ile razy test podczas wykonywania „odwiedza” daną linię kodu.

A co z Tobą?

Z jakiego bundlera JS chcesz skorzystać w ramach swojego kolejnego projektu? Daj mi znać w ankiecie, żebym wiedział, na czym skupić się tutaj w przyszłości.

Co dalej?

Możesz przeczytać mój artykuł o tym, jak korzystać z natywnych modułów ES, lub obejrzeć jeden z moich wideokursów:

Jak dodawać testy end-to-end do projektu

Marcin Wosinek — Wed, 02 Feb 2022 09:03:55 +0000

Gratulacje! Tworzenie testów end-to-end (E2E) to dość zaawansowany temat, który może okazać się wartościowy dla Twojego projektu. Testy te potrafią wyłapywać potencjalne problemy przed scaleniem zmian w gałęzi głównej – kiedy jeszcze daleko do wdrożenia do środowiska produkcyjnego. Im wcześniej wykryjesz bug, tym łatwiej będzie Ci go naprawić. Testy E2E pozwalają na szeroko zakrojoną weryfikację wszelkich zmian zaraz po ich udostępnieniu.

Czym są testy end-to-end

Testy E2E to skrypty, które „używają” aplikacji tak, jak zrobiłby to użytkownik. Otwierają przeglądarkę, ładują adres URL, klikają w elementy interfejsu użytkownika (UI), na przykład przyciski, i oczekują pewnych rezultatów. Testy przeprowadza komputer i są one dużo szybsze i mniej zawodne od ludzi. Poza tym nigdy się nie nudzą.

Ich jedynym słabym punktem jest to, że potrzebują precyzyjnych poleceń i zdarza się, że ich zaprogramowanie jest bardziej skomplikowane niż funkcja, którą mają testować. Pisanie testów stanowi element programowania i jest powiązane z aplikacją, która ma być testowana. Mimo to jest to zadanie, do którego wielu programistów nie podchodzi z entuzjazmem. Jeżeli rozwiniesz się w tej dziedzinie, może stać się to Twoją wyjątkową kompetencją, która pozwoli Ci błyszczeć w zawodzie.

Dobierz odpowiednie narzędzia!

Pakiet E2E można zbudować na wiele różnych sposobów:

Cypress
Playwright
~~Protractor~~
Selenium
TestCafe

Sytuacja wygląda tu tak samo jak w przypadku innych decyzji dotyczących stosów technologii: dobrze jest gruntownie zapoznać się z wszystkimi możliwościami. Każdy pisany przez Ciebie test będzie ściśle związany z wybraną przez Ciebie platformą. Istnieje możliwość migracji z jednego narzędzia do testowania do drugiego, ale jest to przedsięwzięcie przypominające wymianę frameworka na frontendzie.

Moje doświadczenia ograniczają się głównie do Protractora, niedocenianego rozwiązania opartego na Angular. Aktualnie przeprowadzam migrację testów do Cypress i jestem pod wrażeniem postępu w dziedzinie narzędzi do testowania, do jakiego doszło na przestrzeni minionych lat. A Ty z jakiego narzędzia E2E chcesz korzystać w swoim kolejnym projekcie? Daj mi znać, biorąc udział w ankiecie.

Proste testy na lokalnym sprzęcie

Niech Twoje pierwsze testy będą wręcz banalne. Weź dowolny lokalny testowy URL, jaki masz pod ręką, i uruchom na nim swoje skrypty. Nie musisz nawet sprawdzać workflow aplikacji. Po prostu napisz kilka testów, po jednym dla każdej trasy, i sprawdź, czy na danej stronie pojawiają się elementy interfejsu UI. Możesz na przykład sprawdzić:

on /login– czy pojawiają się pola wprowadzania hasła i nazwy użytkownika,
on /product/12 – czy wyświetlana jest nazwa produktu,
itd.

Nawet przy pomocy tak prostych testów możesz udowodnić, że:

aplikacja się uruchamia, a wszystkie trasy wyświetlają się razem z kluczowymi elementami interfejsu UI;
potrafisz tworzyć testy E2E.

I tym sposobem temat E2E zacznie się rozkręcać – zespół będzie mieć kilka testów do wyboru, a jeden z jego członków (czyli Ty) będzie chętny i zdolny do pisania kolejnych!

Podziel się dobrą nowiną z zespołem

Nie będziesz musiał być tu zbyt nachalny, przynajmniej na początku. Upewnij się tylko, że wszyscy wiedzą, że testy E2E są dostępne, i doprowadź do sytuacji, w której od każdego programisty oczekiwać się będzie, że przeprowadzi je przed scaleniem jakichkolwiek zmian w gałęzi głównej. Na tym etapie zauważysz wszelkie różnice między lokalnymi konfiguracjami używanymi przez Twoich kolegów po fachu – inne domeny lub porty, z których korzystają lokalnie. Możesz opanować sytuację przez dopilnowanie, żeby wszyscy używali tego samego adresu URL, albo przez sprawienie, że URL testowy będzie łatwy w konfiguracji, a nie zakodowany „na twardo”. Oba podejścia są w porządku. Ja zdecydowałem się na dopilnowanie, aby wszyscy korzystali z tego samego adresu URL localhosta; w moim przypadku zespół nie miał nic przeciwko.

Kolejnym krokiem jest przetestowanie ścieżki happy path w odniesieniu do workflow – czyli jak powinna działać aplikacja, kiedy wszystko funkcjonuje, jak należy. Innymi słowy – piszesz testy, które sprawdzają, czy przycisk „Dodaj do koszyka” rzeczywiście dodaje wybrane produkty do koszyka i czy przycisk „Kupuję i płacę” kieruje użytkownika na stronę dostawcy usług płatniczych. Testy takie trudniej się pisze, ale sprawdzają najważniejsze elementy aplikacji. Skrypty te powinny pomóc Ci w przekonaniu kolegów o przydatności E2E. A Twoje testy będą stawać się coraz bardziej zaawansowane.

Co dalej

Jeśli masz jakiekolwiek pytania lub wątpliwości w temacie testów E2E, podziel się nimi w komentarzach! Przeczytam je i postaram się odpowiedzieć na nie jak najlepiej. A jeśli jeszcze mało Ci czytania, zapraszam do zapoznania się z moim artykułem o zarządzaniu delikatnym przestarzałym kodem.