This is a story that happened to me recently and I wanted to share how I approach debugging problems and what is my thought process. I found this particular issue worth describing, because as usual the most interesting problems are made of smaller problems combined together that you might have never discover otherwise. Enjoy the journey.

Od rozpoczęcia akcji "Daj się poznać 2017" minęło już sporo czasu i w końcu udaje mi się wykonać cel postawiony przed każdym z uczestników. Udało mi się napisać 20 postów (ten post jest postem nr 20) i rozwijać mały projekt Open Source przez 2,5 miesiąca. Oto parę rzeczy, których się nauczyłem przez ten okres oraz plany na przyszłość.

Jednym z problemów w środowisku Javascript jest formatowanie kodu. Istnieje masę udokumentowanych koncepcji z udokomentowanymi wszystkimi zasadami, według których się powinno formatować kod. Najpopularniejsze wzorce to AirBnB style guide, Standard.js, XO i niedawno stworzony Prettier.

Zagłębiłem się ostatnio bardzo w tematykę Redux. Podczas czytania różnych artykułów natrafiłem na rodzaj architektury Redux nazwany Ducks. Cała idea Ducks wygląda bardzo prosto i pozwala trzymać powiązane elementy razem, zamiast dzielić części Redux zależnie do typu (akcje, reduktory, typy). Postanowiłem ją wytestować w projekcie.

W tym poście chcę coś opowiedzieć o swoim podstawowym edytorze - Visual Studio Code. Jest to nowy edytor stworzony przez Microsoft w 2015 roku i od oficjalnego wypuszczenia edytora w marcu 2016 rozwijany jako projekt Open Source. Ja zacząłem korzystać z VS Code 1,5 roku temu, gdy jeszcze był w wersji Beta i jeszcze nie znalazłem powodu, żeby go zamienić na jakikolwiek inny.

Przy tworzeniu projektów z użyciem React odchodzi się od praktyki tworzenia jednego głównego arkusza styli na rzecz tworzenia styli indywidualnie dla każdego komponentu. Jak już opisałem w poprzednim poście o projekcie, że korzystam w nim z modułów CSS i nie korzystam z SCSS. Dzisiaj opiszę trochę cssnext, który usprawnia pracę z stylami w modułach i daje możliwość wykorzystania przyszłych funkcjonalności języka CSS.

Od początku mojej podróży z React obijał się temat wymaganego środowiska, narzędzi budowania i całej konfiguracji wymaganej do odpalenia projektu korzystającego z nowych funkcjonalności ES6. Na szczęście bardzo szybko trafiłem na projekt Create React App, który pozwolił uniknąć mi mnóstwo problemów związanych z podstawową konfiguracją Webpack, Babel przydatnych przy pracy z React.

Wszystkie moje prace do tej pory skupiały się na pisaniu kodu javascript. Dzisiaj trochę odskoczni - stylowanie komponentów z użyciem modułów CSS.

Chyba każdy, kto ma jakikolwiek kontakt z javascript wie jak dynamiczny jest ekosystem zgromadzony wokół tego języka. Codziennie wychodzi nowy frameworka, mnóstwo bibliotek, dobre praktyki też cały czas ewoluują i bardzo ciężko być z tym wszystkim na bieżąco. Zawsze chcę nauczyć się czegoś nowego, przyjrzeć się innemu frameworkowi i napisać probjekt z użyciem czegoś nowego. Problemem jest ilość nowości, którymi jesteśmy bomboradowani. Jakiś czas temu postanowiłem się zdecydować, w którym kierunku zamierzam iść i ustaliłem sobie swój stos technologiczny, którego chcę dogłebnie poznać.

Przy ostatnich pracach nad aplikacją i pisaniu reduktorów nie podobało mi się zwracanie za każdym razem nowego obiektu i braku mutacji w aktualnym stanie. Dodawanie atrybutów do obiektu z pomocą Object.assign jest całkiem przyjemne, natomiast usuwanie atrybutu z obiektu już nie wygląda w kodzie tak ładnie i wymaga trochę uwagi przy zarządzaniu stanem. Wtedy pojawił się pomysł na użycie Immutable.js. Dzisiaj pokażę, co z tego wyszło i sądzę, że zachowanie stanu aplikacji z niemutowalnymi obiektami jest całkiem proste.

Lighthouse. Co to takiego? Co ma wspólnego latarnia z IT? Okazuje się, że coś wspólnego ma. Lighthouse to projekt o otwrtym kodzie źródłowym pozwalającym sprawdzić różne metryki strony internetowej. Dzięki niej możemy się dowiedzieć, czego brakuje naszej aplikacji do stania się Progresywną Aplikacją Webową.

W ostatnim poście na temat projektu opisywałem strukturę stanu aplikacji. Dzisiaj pora na kodzenie ostatnich ustaleń w projekcie. Pokażę, jak w projekcie wyglądają typy, kreatory akcji i reduktory.

Już od długiego czasu w użyciu jest nowy standard dla javascriptu - ES6 (zwany również ES2015). Może jego użycia jeszcze nie widać w plikach wielu aplikacji, bo w większośći przypadków musi być on jeszcze transpilowany do wspieranego niemal wszędzie poprzedniego standardu ES5. Mimo tego standard ten szybko został zaadoptowany w społeczności programistów JS i ciężko natknąć się jeszcze na nowy kod JS, który nie jest pisany w tym standardzie. ES6 wnosi sporo fajnych usprawnień do języka, ale dzisiaj chcę omówić moją ulubioną część tego standardu - moduły.

Zaczyna się prawdziwy etap tworzenia aplikacji. Podstawowy szkielet aplikacji już istnieje, narzędzia działają, podstawowe zadania można dodawać. Teraz pora implementować główne funkcjonalności. Ale zanim przejdę do pisania funkcjonalności, chcę zaplanować bardzo ważną część aplikacji - jej stan.

W październiku zeszłego roku został udostępniony światu nowy menedżer pakietów dla javascriptu - Yarn. Od tamtego czasu nowy klient zdobywa coraz większą popularność. Przy wielu bibliotekach, modułach w instrukcjach instalacyjnych zaczyna się pojawiać oprócz komenda . Ja też już jakiś czas temu przerzuciłem się z klienta npm na Yarna. Opowiem trochę o moich doświadczeniach z nowym menedżerem i przedstawię trochę różnic między tymi klientami.

Od ostatniego postu o projekcie dodałem do aplikacji możliwość ustawienia projektu do każdego zadania oraz usuwanie zadań. Podczas prac bardzo irytowało mnie to, że przy każdym odświeżeniu strony cały stan aplikacji był tracony. Aktualnie planuję rozwijać tylko część frontendową aplikacji, więc implementacja backendu nie wchodziła w grę. Z pomocą przychodzi lokalna pamięć przeglądarki.

W Internecie pojawia się coraz więcej artykułów o nowym interfejsie, który ma zrewolucjonizować nasz sposób komunikacji z maszynami. Mowa tutaj o botach w komunikatorach. Kolejny rodzaj interfejsu, który ma upodobnić naszą komunikację z urządzeniami i usługami do komunikacji międzyludzkiej.

Po skonfigurowaniu wszystkiego zaczynam dzisiaj właściwe prace nad projektem. Na początku zaczynam od prostego formularza do dodawania zadania i wyświetlania listy zadań. Następnym krokiem będzie możliwość edycji, usuwania zadań i filtrowania listy. Po skończeniu tego zajmę się trochę częścią serwerową, żeby nasze zadania były zapamiętywane na dłużej niż jedno wyświetlenie strony. Ale przejdźmy do dzisiejszego tematu - testowania.

Dzisiaj zamiast postu o projekcie opowiem trochę o czymś takim, co określa się jako "serverless". Od jakiegoś czasu natrafiam na to pojęcie w Internecie, a ostatnio miałem również okazję usłyszeć prezentację Michała Kurzeji na konferencji "Boiling Frogs". Opiszę dzisiaj moje spostrzeżenia na ten temat i jak wyglądało moje pierwsze starcie z "serverless".

W pierwszym poście opisywałem trochę narzędzia z których będę korzystał przy robieniu tego projektu. Postaram się teraz trochę bardziej opisać cały stos technologiczny projektu.

Rozpoczyna się miesiąc marzec i zaczynam wyzwanie "Daj się poznać 2017". Całe to wyzwanie polega na rozwijaniu projektu open source przez 10 tygodni i jednoczesne pisanie na blogu 2 postów tygodniowo. Przynajmniej jeden post w tygodniu musi być poświęcony rozwijanemu oprogramowaniu. Drugi post może dotyczyć dowolnych zagadnieć związanych z branżą IT.