blog.marlas.pl RSS Feed

Debugging Travis issue

Sun, 10 May 2020 00:00:00 GMT

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.

Before I go to the real issue let me shortly describe the project background. More than 20 people regularly commit code to the project. To maintain quality of the code we require that each PR passes all required checks. In our case all unit tests have to pass, critical e2e tests are passing and linter doesn't catch any errors. Additionally we commit to 2 main branches. One branch for stable version maintenance and the other for next version development. Recently we worked on major release, so we have a lot of differences between those branches that will play a role in this story.

The story starts with this image

Suddenly Travis job failed for the change that shouldn't break anything. It was only the library version bump in maintenance branch. Everything should be okay.

Let's see what failed in this job.

✓ Linter passed
✓ Prettier passed
✓ Unit tests for core library passed

Aha. Unit tests for storefront library failed.

Let's look at the details

Ok. Only one unit test failing. I'll just checkout to this branch and run the tests locally.

Few moments later... What! All tests green. Not a single failure! Wtf

Let me just check the changes in the last commit once again. Maybe I messed up the last commit.

Hmmm. It looks alright. Maybe that was random Travis failure. Maybe job restart will solve this.

Few minutes passed by. Travis failed once again. The same test failed. I'm getting closer. Now I know that this is something with the Travis environment. Let me check if that also fails on the development branch.

Weird. It works there. The test and the the function haven't changed between the branches. So definitely it's not the issue with the code.

Why only this one particular test failed? Not the others if that's the issue with environment. What makes it so special? Let's inspect that code.

Let's start with the failing test

describe('when unknown titles are added', () => {
  it('they should be put at the end', () => {
    const mockTitles: Title[] = [
      {
        code: 'dr',
        name: 'Dr.',
      },
      {
        code: 'mrs',
        name: 'Mrs.',
      },
      {
        code: 'rev',
        name: 'Rev.',
      },
      {
        code: 'unknown',
        name: 'Unknown',
      },
      {
        code: 'mr',
        name: 'Mr.',
      },
    ];
    const expectedTitles: Title[] = [
      {
        code: 'mr',
        name: 'Mr.',
      },
      {
        code: 'mrs',
        name: 'Mrs.',
      },
      {
        code: 'dr',
        name: 'Dr.',
      },
      {
        code: 'rev',
        name: 'Rev.',
      },
      {
        code: 'unknown',
        name: 'Unknown',
      },
    ];

    const sortedTitles = mockTitles.sort(sortTitles);

    expect(sortedTitles).toEqual(expectedTitles);
  });
});

Nothing complicated. Only some sorting. Let's look at the sorting function.

import { Title } from '@spartacus/core';

export const titleScores = {
  mr: 1,
  mrs: 2,
  miss: 3,
  ms: 4,
  dr: 5,
  rev: 6,
};

export function sortTitles(title1: Title, title2: Title) {
  if (!titleScores[title1.code] || !titleScores[title2.code]) {
    return 1;
  } else {
    return titleScores[title1.code] - titleScores[title2.code];
  }
}

Okay. It only returns integers in that setup. A lot of 1 in this test case. And the failure stated different expected order that the actual one.

Aha!!! Sort doesn't guarantee order preservation! That must have been the issue in this case! But why it changed the order only in this job? Why is it always passing?

Gotcha! I remember that some time ago they changed the sort function implementation in V8. That must be it.

Let's look at what exactly we use on Travis. We are running Node.js 10 on maintenance branch, but Node.js 12 on develop branch.

Let's check when the V8 update got into the Node.js. Version 11. Bingo. That must be it. Let's confirm it. Change version of Node.js locally to 10 and rerun unit tests. Maybe then I would see the issue locally.

What?! Green again. How is it possible?

I'm stupid! Unit test are run with Chrome not the Node :facepalm:

Weird. I don't see any differences in Chrome setup on Travis between maintenance and development branch. Time to check the Travis logs for the chrome setup.

I'm onto something. Installation of the stable chrome failed in the job. Let's see how it worked previously.

Ok. In the previous job Chrome 81 was successfully installed and replaced default Chrome 62. When the V8 change got into Chrome? Let's google.

Chrome 70 landed the fix for sort function. That explains why the test failed in this particular job.

Why on development branch Chrome is installed successfully and why it fails on maintenance branch?

Oh yeah! We changed the OS distribution from trusty to bionic! Let's check if someone also had this problem with Chrome on trusty distro.

Perfect! https://travis-ci.community/t/travis-is-downloading-older-chrome-versions-in-place-of-chrome-stable/5040/2 Exactly the same issue. But why it happened to us half a year later than for these folks?

I guess maybe Chrome team prolonged trusty distribution support to increase the transition period. I don't have time to dive into what changed in this deb packages over last 2 weeks. I found the issue, fix is easy. Let's just bump the distribution to match the one from development branch and we are green once again. Let's go to the next topic.

Ah. Almost forgot. Let's create a ticket to improve the title util function to work correctly in non deterministic environment as well.

Thanks for reading the story. Hope that's been journey full of surprises for you as well. I've felt great once I figured out the underlying cause of this problem. That's what makes my job satisfying and that's why I love being a programmer.

Post nr 20

Fri, 16 Jun 2017 00:00:00 GMT

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ść.

Blogowanie nie zajmuje jednak tak dużo czasu jak myślałem, ale nie jest to aż takie proste. Pisanie sprawiło mi trochę przyjemnośći, ale skala, której wymagał konkurs "Daj się poznać" była zdecydowanie za duża. Pisanie 2 postów tygodniowo to było ciągłe szukanie wolnego czasu na napisanie kolejnego posta i popracowanie nad projektem. Po tym maratonie blogowania mam zamiar zrobić sobie dłuższą przerwę od tego. Zamiast pisać krótkie lub średniej długości teksty wolałbym badać konkretne zagadnienie przez dłuższy okres i tworzyć obszerny, i bardzo treściwy materiał. O niektórych elementach nie da się pisać dłuższych wypowiedzi, bo są tak proste i łatwe do wytłumaczenia, ale takie materiały do mnie nie przemawiają. Wolę przeczytać "kawał" dobrych badań i wyciągniętych z nich wniosków z pomysłami na ich wykorzystanie, niż dostać bardzo krótki wstęp do jakiegoś zagadanienia, który i tak mogę znaleźć w dokumentacji, czy mnóstwie innych artykułów na jego temat. Myślę, że w przyszłości pójdę raczej w dłuższe formy, które wnoszą coś nowego do środowiska, a nie są jednym z kilkunastu artykułów mówiących o tym samym. Tutaj bardzo doceniam wkład od Addy Osmani, który przy swoich materiałach bardzo dogłębnie bada temat i daje kompletny poradnik wyjaśniający najlepsze praktyki i możliwe rozwiązania badanych problemów.

Projekt, który wybrałem sobie do konkursu jest bardzo ambitny i zakres jego funkcjonalności ma być ogromny, skrojony pod moje potrzeby. Jednak już na samym początku wiedziałem, że nie jest on do wykonania w okresie konkursu. Planowałem pracować nad nim powoli i dokładnie przemyśleć jak wszystko w nim rozwiążę. Z tego powodu, większość mojej pracy z projektem to było szukanie rozwiązań pod tą aplikację i ich integracja w istniejący zalążek. Nadal mam kilka pomysłów na duże zmiany przed przejściem w prawdziwą część projektu - tworzenie funkcjonalności.

Pakiet startowy, który wybrałem na start trochę mnie zawiódł i będzie raczej zmieniony na next.js, ale dużo rzeczy, które poznałem z React Go mam zamiar dalej wykorzystać (np. stylowanie modułami i korzystanie z cssnext). Na pewno dalej będę korzystał z Redux, ale może w ramach nauki nowego rodzaju API zbadam Graph QL, zamiast klasycznego REST API. Jedną rzeczą, którą muszę teraz wykonać, jest stworzenie kompletnego backlogu, żeby potem w czasie prac nie zbaczać z obranego kursu.

W czasie trwania konkursu pracowałem również nad kilkoma innymi aplikacjami korzystającymi z React, Redux i wiele się w tym czasie nauczyłem. Tę wiedzę zdobytą w innych projektach, chcę również wykorzystać przy rozwoju projektu i poprawie niektórych części kodu.

To teraz trochę o mnie. Nie pisałem jeszcze na blogu kim jestem, czym się dokładnie zajmuję, więc pora na parę wyjaśnień. Aktualnie jestem studentem informatyki na Politechnice Wrocławskiej na Wydziale Informatyki i Zarządzania. W czasie akcji "Daj się poznać 2017" jestem na 6 semestrze studiów i zbliżam się dużymi krokami do obrony pracy inżynierskiej. Poza tym pracuję na 1/2 etatu w świetnej firmie Divante, jako Frontend Developer.

Aktualny stan studenta/pracownika jest bardzo wymagający (trochę trzeba się napracować na tym 6 semestrze) i wiedziałem, że udział w "Daj się poznać" zajmie resztki mojego wolnego czasu, ale teraz na finiszu jestem zadowolony z tego, że wziąłem w nim udział. Konkurs zmotywował mnie do startu przygody z blogowaniem, do którego mam nadzieję niedługo wrócić. Dodatkowo udowodniłem sobie, że da się pracować, studiować i blogować w tym samym czasie, ale nie polecam tego nikomu. Taki ogrom kontaktu z programowaniem prowadzi do szybkiego wypalenia i tutaj narazie chcę wypocząć przynajmniej z programowaniem do blogowania. Zachęcam każdego do wypróbowania swoich sił w pisaniu bloga, bo może przypadnie to wam do gustu. Ja z chęcią wrócę do tego, jeśli zmniejszę swoje obłożenie innymi sprawami. Do usłyszenia jak najszybciej. :)

Prettier

Fri, 12 May 2017 00:00:00 GMT

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.

Dotychczas próbowałem korzystać z wzorców AirBnb oraz Standard.js. Jednak dopiero Prettier spełnił wszystkie moje wymagania. Wiele z tych standardów jest odpowiedzialnych nie tylko za styl kodu, ale również za elementy dotyczące dostępności, reguły niezwiązane z stylem kodu, a użyciem nowszych funkcjonalności JS.

Prettier różni się od nich tym, że nie jest to linter. Prettier na wejście dostaje nasz kod i na wyjściu zwraca sformatowany kod. Tutaj właśnie jest zaleta tego formattera. Jeśli wywołujemy funkcję z 4 krótkimi parametrami i będzie ona się mieściła w 80 znakach to nadal będzie ona tak zapisana. Jeśli jednak nie zmieści się ta funkcja w limicie znaków w linii, to każdy argument zostanie zapisany w osobnej linii. Dzięki temu dostajemy kod, który zawsze mieści się w naszym limicie znaków.

Konfiguracja Prettier jest bardzo uboga i to jest właśnie bardzo dobre rozwiązanie, bo nie wprowadza dużego rozłamu. Możemy tylko ustawić rozmiar wcięcia, rodzaj 'trailing comma', rodzaje apostrofów, odstępy w obiektach i użycie średników. Reszta jest poza naszą kontrolą.

Ja korzystam z tego rozszerzenia w edytorze Visual Studio Code - Prettier - Javascript formatter i działa to bardzo sprawnie. Jeśli chcę sformatować plik to tylko korzystam z skrótu Ctrl + Shift + i i dokument jest poprawnie sformatowany. Konfigurację formatera ustawiam w konfiguracji edytora i to wszystko. Już nie muszę patrzeć do konsoli lintera i sprawdzać co muszę poprawić. Teraz formatowanie kodu przypomina korzystanie z takich narzędzi jak formater do Javy w edytorze IntelliJ. Plusem Prettier jest również to, że wspiera JSX oraz funkcjonalności ES2017.

W przypadku, gdy potrzebujemy jeszcze sprawdzania rzeczy poza formatowaniem możemy skorzystać z pluginu do eslint: eslint-config-prettier, który wyłączy wszystkie reguły eslint, które mogą konfliktować z Prettier, a pozwoli na lintowanie zasad, które nie są obsługiwane przez Prettier.

Polecam wszystkim sprawdzenie Prettier i przestanie się martwić o formatowanie kodu i wybieranie miliona reguł do lintowania. Ja już wybrałem Prettier w połączeniu z ESlint i przestałem się martwić.

ReDucks

Mon, 08 May 2017 00:00:00 GMT

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.

Cała idea Ducks opiera się na trzymaniu reduktora razem z jego typami i kreatorami akcji w jednym pliku. Dzięki czemu unikamy wielu eksportów/importów i powiązane funkjonalności edytujemy w jednym miesjcu.

Mamy jednak parę zasad:

reduktor musi być eksportowany domyślnie
każda akcja musi być eksportowana
typy są zdefiniowane w tym samym pliku i mogą być eksportowane, jeśli są potrzebne w innych reduktorach

Z tymi zasadami przerobiłem swoje wszystkie reduktory w projekcie. Całość zajęła kilka minut i zaoszczędziłem kilka eksportów, zmniejszyłem liczbę plików oraz wszystkie funkcjonalności związane z reduktorem mogę szybciej edytować. Poniżej przykład reduktora zadań przerobiony na Ducks.

const ADD_TASK = "ADD_TASK";
const REMOVE_TASK = "REMOVE_TASK";

const taskReducer = (state = [], action) => {
  switch (action.type) {
    case ADD_TASK:
      return [action.payload, ...state];
    case REMOVE_TASK:
      return state.filter(element => element.name !== action.payload);
    default:
      return state;
  }
};

export default taskReducer;

export function addTask(task) {
  return {
    type: ADD_TASK,
    payload: task,
  };
}

export function removeTask(task) {
  return {
    type: REMOVE_TASK,
    payload: task,
  };
}

W przypadku potrzeby zmienienia akcji możemy zmienić reduktor i kreator akcji w jednym miejscu, bez potrzeby wyszukiwania odpowiednich plików. Do tego nie muszę już nigdzie eksportować typów i nie mam jednego folderu, który był tylko od trzymania pliku z listą typów. W przypadku większych reduktorów importowanie po każdym typie było straszne, a import grupowy dodawał dodatkowej składni. Dzięki tej architekturze zarządzanie Redux jest jeszcze prostsze.

Bardzo polecem ją przetestować i zobaczyć jak sprawdzi się w waszych projektach. Jeśli pliki staną się bardzo obszerne będzie to sygnał, że może reduktor ma za dużo odpowiedzialności i należy go odpowiednio rozbić na mniejsze składowe reduktory. Miłej zabawy z kaczuszkami.

Visual Studio Code

Thu, 04 May 2017 00:00:00 GMT

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.

Edytor ten jest bardzo lekki. Jest oparty na silniku Electron, na którym można tworzyć aplikacje desktopowe korzystające z Node.js i silnika Blink. Na tym samym silniku działa również inny popularny edytor - Atom. Od pierwszego publicznego wypuszczenia VS Code jest on regularnie, co miesiąc aktualizowany o masę nowych funkcjonalności i z miesiąca na miesiąc coraz bardziej dojrzeje.

Za co lubię VS Code:

bardzo schludny i prosty interfejs
dobry system rozszerzeń
dobre wsparcie dla Javascript
wbudowany Debugger JS
świetna integracja z GIT

Oprócz wyżej wymienionych zalet bardzo dobrze działa dzielenie edytora na wiele grup zakładek, wbudowany Emmet, łatwość konfiguracji i paletę komend. Te rzeczy są wykorzystywane wielokrotnie każdego dnia i działają bez zarzutu, i bardzo ułatwiają pracę. Przez to, że edytor jest pisany w JS mogę w przyszłości wesprzeć jego rozwój, czy stworzyć potrzebny plugin. A co do pluginów - to naprawdę ciężko wpaść na pomysł pluginu, bo społeczność tworzy je bardzo szybko i większosć z nich jest bardzo dobrej jakości. Jeśli wchodzi jakaś nowa biblioteka czy framework to Visual Studio Code ma wcześnie dostępny plugin jako jeden z niewielu edytorów.

A jeśli mowa o pluginach to mogę wspomnieć kilka, które są warte uwagi i mi się bardzo przydały:

pluginy do wsparcia języków: PostCSS syntax, Docker, Handlebars
Settings Sync - mój plugin no. 1 - to dzięki niemu wszystkie moje urządzenia zawsze mają te same wersje rozszerzeń i ustawienia są przenoszone między edytorami. Dzięki niemu instalacja edytora z wszystkimi ustawieniami i rozszerzeniami zajmuje tylko 5 minut.
markdownlint
vscode-icons - ikony dla różnych plików pozwalają naprawdę sprawnie poruszać się w drzewie katalogów
SVG Viewer
Path Intellisense - importy wszystkich plików są dzięki niemu banalne
Prettier - Javascript formatter

Chcę jeszcze wspomnieć o powodzie, dla którego naprawdę polubiłem ten edytor - integracja z GIT. Dzięki temu byłem w stanie wyrobić w sobie praktykę częstych commitów, pracowania na osobnych branchach dla zadań oraz bardzo prosto synchronizowałem wszystko z centralnymi serwerami. Jedynej rzeczy, której mi tutaj brakuje to dobry mechanizm obsługi konfliktów, ale do ręcznej pracy na konfliktach da się przyzwyczaić. W końcu nie ma ich tak dużo.

Ja z mojej stronę chcę bardzo polecić Visual Studio Code. Jeśli piszecie dużo Javascriptu i frontendowych rzeczy to jest to edytor stworzony pod te potrzeby. Dodatkowo polecem wspominaną integrację z GIT oraz mnóstwo dobrej jakości pluginów do najróżniejszych potrzeb.

CSSnext w projekcie

Sun, 30 Apr 2017 00:00:00 GMT

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 kilku lat korzystam z SCSS i stał się on jednym z moich podstawowych narzędzi do pisania styli, ale zawsze z chęcią poznaję nowości. Już jakiś czas temu usłyszałem o postcss i bardzo szybko w mój workflow wprowadziłem świetne narzędzie - autoprefixer. Nie wgłębiałem się natomiast w resztę możliwości jakie oferuje ekosystem. Teraz mam świetną okazję je poznać pisząc tę aplikację w React i mając już skonfigurowany projekt do obsługi cssnext i importów.

Głównymi funkcjonalnościami jakie używam w SCSS są zmienne, mixiny, importy oraz świetny nesting. Te funkcjonalności najbardziej usprawniają pracę i ciężko będzie mi bez nich pisać style. Po szybkim przejrzeniu dokumentacji cssnext okazuje się, że wszystko to mogę wykonać.

Na początku import. Tutaj składnia jest identyczna jak w przypadku SCSS i obsługiwana jest przez plugin postcss-import

@import "settings.css"

Następnie zmienne. Tutaj następuje spora zmiana, bo użycie zmiennych wymaga zmiany podejścia na nowe, które wprowadzone jest powoli do przeglądarek. Zmiennych w CSS. Zmienne definiujemy w elemencie :root i odwołujemy się do nich poprzez funkcję var().

:root {
    --gray: #ddd;
}

.button {
    border-color: var(--gray);
}

Kolej na mixiny. Tutaj znowu są zauważalne różnice, ale jeśli potrafimy korzystać z zmiennych CSS to mixiny również nie powinny sprawiać problemów.

:root {
    --box: {
        width: 64px;
        height: 64px;
    }
}


.box {
    background-color: goldenrod;
    @apply --box;
}

Na koniec zostaje mój ulubiony nesting. Tutaj znacznie przyjemniej pracowało mi się z SCSS, ale można przywyknąć. Nesting media query zostaje taki sam. Prosty nesting również, jedynie w przypadku nestingu odwrotnego trzeba korzystać z dyrektywy @nest.

.box {
    & span {
        font-size: 1.2em;
    }

    @nest .container & {
        max-width: 34em;
    }

    @media (max-width: 30px) {
        height: 200px;
    }
}

Cssnext oferuje poza przedstawionymi wyżej funkcjonalnościami jeszcze parę innych smaczków: proste tworzenie customowych media queries, mnóstwo funkcji kolorów, wsparcie dla rem, wbudowany autoprefixer, korzystanie z pseudoklas i funkcje do resetu właściwości. Więcej możecie znaleźć w dokumentacji cssnext.

Praca z cssnext w projekcie bardzo ułatwia pisanie styli i raczej zmienię swój sposób pisania z SCSS na rozszerzalnego postcssa i na korzystanie z przyszłych funkcjonalności CSS, zamiast korzystać z specjalnej składni preprocesora.

Create React App

Wed, 26 Apr 2017 00:00:00 GMT

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.

Create React App jest bardzo proste w użyciu, a instalacja wymaga tylko zainstalowania globalnego pakietu.

yarn add create-react-app -g

Do utworzenia nowego projektu wystarczy tylko uruchomić jedną komendę i mamy postawiony nowy projekt z podstawowymi komponentami.

create-react-app my-app

Odpalenie projektu to też jedna linijka, podobnie jak uruchomienie testów opartych na Jest oraz zbudowanie projektu na produkcję. Przy odpaleniu projektu stronę możemy podejrzeć pod podanym adresem przez Create React App.

# Dev
yarn start

# Test
yarn test

# Build
yarn build

Dla mnie ten projekt bardzo ułatwił start z Reactem i gorąco go polecam. Mimo, że zaczynam się rozglądać za nowymi pakietami startowymi, które oferują renderowania po stronie serwera oraz hot module replacement (obiecująco wygląda next.js), to Create React App sprawdza się bardzo dobrze przy prostych projektach, które musimy szybko stworzyć i chcemy uniknąć problemów związanych ze środowiskiem. Jeśli potrzebujemy roszerzać naszą konfigurację, to mamy dostępną dobrą dokumentację, która podpowie jak np. podpiąć style pisane z SASS lub deployować na popularne platformy. Jeśli jeszcze nie poznaliście Reacta i chcecie szybko zacząć z nim pracę to Create React App zdecydowanie wam to ułatwi.

Style w projekcie

Tue, 25 Apr 2017 00:00:00 GMT

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.

Pakiet startowy na którym oparłem projekt ma wbudowane wsparcie dla modułów css i zobaczmy jak w tym się pisze style. Na start zabieram się za pisanie styli dla formularza dodawania zadania. Mamy na nim dwa pola tekstowe z opisami oraz przycisk. Zacznijmy od napisania prostych styli dla tych elementów. Korzystam z zwykłej składni CSS i nie wykorzystuję tutaj żadnych zaawansowanych opcji. Dostępny jest tu postCSS, ale narazie skupmy się na połączeniu styli z komponentem React. Tworzę sobie plik o nazwie komponentu przy pliku komponentu, przez co nie muszę długo szukać plików podczas pracy nad jednym komponentem. Wszystkie pliki z nim związane są w jednym miejscu.

Styluję podstawowe komponenty:

.label {
    font-family: sans-serif;
    margin-bottom: 4px;
    display: inline-block;
}

.input {
    height: 32px;
    line-height: 28px;
    padding: 0 8px;
    border: 1px solid #333;
    font-family: sans-serif;
}

.button {
    height: 32px;
    line-height: 28px;
    padding: 0 20px;
    font-size: 1.2em;
    border: 2px solid #333;
    font-family: sans-serif;
    background-color: white;
    transition: border-color 0.2s ease-in-out;
    cursor: pointer;
}

.button:hover {
    border-color: royalblue;
}

Teraz pora na połączeniu styli z komponentem. Tutaj wykorzystujemy bibliotekę classnames. Zaczynam od importu tej biblioteki i importu styli.

import classNames from 'classnames/bind';
import styles from './new-todo.css';

Potem łączymy nasze klasy z styli z komponentem.

const cx = classNames.bind(styles);

Na końcu użycie styli jest banalnie proste. Przy elemencie dodajemy tylko atrybut className z naszą połączoną klasą.

<label className={cx('label')} htmlFor="name">Zadanie</label><br />

Użycie modułów CSS z biblioteką classnames jest banalnie proste i problem z globalnymi stylami zostaje rozwiązany. Teraz możemy pisać wyizolowane style dla każdego komponentu i nie martwić się ich wpływem na resztę dokumentu.

Plan na mój stos technologiczny

Tue, 11 Apr 2017 00:00:00 GMT

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ć.

Ustalenie swojego stosu wcale nie ogranicza mnie od nowych rzeczy. Nastał taki moment, w którym chcę znać parę podstawowych narzędzi bardzo dobrze i mieć dobrą bazę do pisania nowoczesnych aplikacji webowych. Oczywiście staram się na bieżąco obserwować co nowego wychodzi, czego inni zaczynają używać, ale już nie mam zamiaru zaraz skakać na coś nowego, tylko z powodu tego, że to jest nowe. Jeśli coś przynosi sporą wartość, jest stabilne i sprawdzone, wtedy można zagłebić się bardziej w temat i szukać zastosowania w swojej pracy.

Pierwszą dużą rzeczą na którą się zdecydowałem jest React, o którym już trochę pisałem. Wprowadził on trochę zamieszania w środowisku i upowszechnił nowy sposób tworzenia aplikacji, bardzo modularnych napisanych w prosty sposób z użyciem najnowszych możliwości języka Javascript. Kolejnymi plusami jest upowszechnienie Reacta na innych platformach np. React Native, co może w przyszłości mi bardzo pomóc, jeśli będę musiał stworzyć aplikację mobilną. Widząc aktualny stan tej biblioteki i jaki ekosystem narzędzi został zbudowany wokół niej przyszłość Reacta widzę, bardzo stabilną i nie sądzę, żeby w ciągu 5 latach znikł on z rynku.

Kolejny element układanki to narzędzia budujące. Tu wybrałem i od jakiegoś czasu uczę się Webpacka, wspartego skryptami npm i Gulpem. Webpack ostanio bardzo dojrzał, wydana została wersja druga. Jest aktualnie chyba najpopularniejszym narzędziem do bundlowania JS i podobnie jak w przypadku Reacta ekosystem jest mocno rozwijany wokół tego. Dodatkowo do prostych zadań, czy procesowania plików zostają skrypty i Gulp, którego całkiem dobrze już poznałem do tej pory i jeśli jest z czymś problem w Webpacku, to zawsze mogę wspomóc się sprawdzonym Gulpem.

Kolejnym elementem do układanki jest SASS i preprocessor PostCSS. Te narzędzia już weszły jakiś czas temu do mojego arsenału i udowodniły swoją wartość. Pisanie styli z ich pomocą, zgodnie z dobrą architekturą jest bardzo proste i szybkie. Chodź na horyzoncie jest sporo rozwiązań do styli w komponencie React np. styled-jsx, narazie stare, dobre rozwiązanie prowadzi. Jednak w niektórych projektach może wykorzystm nowe podejście do styli.

Do tych elementów dorzucam parę elementów backendowych z Node.js na czele. Mam zamiar skupić się trochę bardziej na stronie serwerowej i wyrobić trochę praktyki w tworzeniu API, innych zadań do przetwarzania danych i obsługi baz danych. Do tego dochodzi świetny framework do tworzenia API - Express.js. Na takim stosie chcę oprzeć swoje umiejętności w zakresie serwerowym.

Z serwerami od jakiegoś czasu pomaga mi juz Docker i docker-compose, które bardzo ułatwiają mi przenoszenie aplikacji między urządzeniami, serwerami. Mam dalej zamiar szukać najlepszego podejścia do kontenerów i być może wspomoże mnie w tym jeszcze Rancher. Ale z Rancherem nie miałem jeszcze tak dużego kontaktu i wymaga jeszcze sprawdzenia, ale wygląda obiecująco.

W części serwerowej nie można zapomnieć o jeszcze jednym ważnym aspekcie - bazy danych. Tutaj chciałbym wgłebić się w MongoDB, Redis i 2 bazy relacyjne MySQL i PostgreSQL. Taka urozmaicona wiedza może się bardzo przydać dla różnych rodzajów projektów. Dla niektórych lepiej nadaje się baza NoSQL, dla drugich baza relacyjna i tutaj chcę wybierać odpowiednie narzędzia do pracy, a nie tylko to co znam. Z czasem może dojdzie jeszcze ElasticSearch do wyszukiwarek, ale to już bardzo dalekie plany.

Na koniec zostawiam sobie narzędzia do testów. Tutaj jeszcze muszę wybrać, czy lepiej korzystać z popularnego zestawu Mocha+Karma, czy już zająć się nowym dzieckiem na podwórku - Jest. Jako, że zaczynam jeszcze zabawę z testami, muszę trochę popracować i z jednym, i z drugim i sprawdzić, co bardziej pomaga mi w pracy i jest prostsze w użyciu.

A wszystko chcę dalej pisać w Visual Studio Code, którego używam już od ponad roku i spełnia wszystkie moje oczekiwania. Co jakiś czas odkrywam kolejny smaczek, nowy skrót klawiszowy i praca z nim staje się jeszcze szybsza i przyjemniejsza.

Taki oto stos technologiczny wybrałem na swój początek kariery i zobaczę, jak wypadnie mój plan po 3 latach, bo w takim czasie chciałbym poznać te wszystkie narzędzia dogłębnie i zrobić kilka aplikacji z ich wykorzystaniem. 3 lata wydają się bardzo odległe, ale i narzędzi jest trochę do poznania, więc każdego dnia będę miał okazję nauczyć się czegoś nowego i dużo pracy przede mną. Pewnie w czasie tej drogi niektóre narzędzia stracą na znaczeniu, a inne wejdą na ich miejsce, ale liczę, że taki stos nie wyjdzie szybciej z użytku, niż go poznam dogłębnie.

Immutable.js w reduktorach

Fri, 07 Apr 2017 00:00:00 GMT

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.

Zaczynamy od instalacji, wystarczy npm install immutable --save i możemy używać Immutable.js w Redux.

Potem tylko import Immutable from 'immutable' i można podpiąć zamiast pustego obiektu JS do domyślnego stanu reduktora pustą niemodyfikowalną mapę: state = Immutable.Map({}).

Główne metody, które musimy poznać do Map to: set(), get() i delete(). Za pomocą funkcji set() ustawiamy wartość atrybutu lub tworzymy nowy atrybut z wartością. Żeby odczytać z mapy wartość wykorzystujemy funkcję get() do której przekazujemy klucz. Do usuwania atrybutu służy polecenie delete(). Z tymi informacjami możemy zabierać się za przerobienie naszego reduktora.

Na początku wszystkie miejsca, gdzie przypisuję obiekt zamieniam na przypisania do Immutable.Map().

case types.ADD_PROJECT:
      return state.set(action.payload, Immutable.Map({
        id: action.payload,
        name: '',
        description: '',
        categories: Immutable.Map({})
      }))

Następnie przekształcam po kolei reduktory. Usuwanie projektu z obiektu z starej wersji z użyciem biblioteki lodash zamieniam z:

return _.omit(state, [action.payload]);

na:

return state.delete(action.payload);

Przy zmianie wartości wewnętrznych obiektu jest trochę więcej zmian. Poprzedni kod:

return Object.assign({},
        _.set(state,
          `[${action.payload.projectId}].name`,
          action.payload.name))

Kod z Immutable.js:

return state.set(action.payload.projectId,
        state
          .get(action.payload.projectId)
          .set('name',action.payload.name));

Mi bardzo przypadła do gustu biblioteka Immutable.js i korzystanie z niej jest znacznie prostsze niż rokminianie, jak zrobić immutability z dostępnymi w języku metodami. Składnia jest bardzo prosta i dostaję gwarancję, że nie zmodyfikuję przypadkowo obiektu. W przyszłości postaram się zwiększyć użycie Immutable.js w reszcie projektu i zobaczę jakie będą tego efekty.

Lighthouse

Wed, 05 Apr 2017 00:00:00 GMT

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ą.

Korzystać z Lighthouse możemy na kilka sposobów. Dostepne jest rozszerzenie do przeglądarki Google Chrome i jako aplikacja konsolowa. Skupię się dzisiaj na rozszerzeniu i pokażę jak z pomocą tak prostego, łatwego w użyciu narzędzia możemy odkryć błędy naszej aplikacji oraz znaleźć potencjalne miejsca na ulepszenia.

Instrukcje instalacji są dostępne w repozytorium projektu. Aplikacja jest dostępna w sklepie z rozszerzeniami Chrome i instalacja zajmuje krótką chwilkę. Po instalacji w oknie przeglądarki zostaje dodana ikona z latarnią i możemy zabrać się za sprawdzanie aplikacji webowych.

Wystarczy tylko przejść na stronę, którą chcemy przetestować, kliknąć ikonkę i przycisk "generate report" i po kilkunastu sekundach dostajemy ładny raport o stronie i ewentualnych błędach + ogólny wynik strony w 100 punktowej skali.

Na blogu jest jeszcze parę rzeczy do poprawy i mój ogólny wynik wyniósł 38/100 punktów, ale nie jest najgorzej. Przy każdym błedzie jest dokładna informacja o przyczynie i o zalecanych krokach do naprawy tego problemu. Naprawdę polecam każdemu te rozszerzenie, bo pozwala złapać poważne błędy, które możemy czasem poprawić w bardzo krótkim czasie. Aktualnie blog nie ma pliku manifestu oraz service workera i przez to tracę masę punktów, ale reszta wyników jest bardzo dobra.

Nazwa lighthouse wzięła się z tego, że te narzędzie miało być latarnią, która prowadzi do Progresywnych Aplikacji Webowych. Działa bardzo dobrze i warto z niego korzystać, nawet jeśli nie tworzymy progresywnych aplikacji. Twórcy cały czas dorzucają nowe metryki i dzięki temu z czasem będziemy w stanie z Lighthouse wyłapać jeszcze więcej niedociągnięć strony.

Każdemu polecam sprawdzić swoje aplikacje z pomocą Lighthouse i dzięki temu poprawić swoje aplikacje.

Types, reducers, action creators

Fri, 31 Mar 2017 00:00:00 GMT

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.

Skupię się tutaj na głównie na akcjach i ich kreatorach. Część akcji już ma jest zaimplementowana w reduktorze, ale nie wszystkie. W trakcie prac nie spodobał mi się kod reduktorów i muszę znaleźć lepszy sposób na ich pisanie. Tworzenie nowych obiektów, bez mutacji starych nie jest takie proste jak myślałem, więc może tu wykorzystam bibliotekę do immutability. Może będzie nią Immutability.js, ale to już opiszę w następnym poście.

Prace zacząłem od części stanu - projektów. Na początek zabieram się za pisanie akcji. Wszystkie typy akcji są przechowywane w projekcie w osobnym pliku, przez co powinienem uniknąć błędów z źle wprowadzonymi nazwami typów. Jest to polecana dobra praktyka przy organizacji stanu Redux i każdemu polecam jej używać. Dodatkowo dostajemy lepsze wsparcie w edytorze niż w przypadku ręcznie wpisywanych typów.

Dla projektów stworzyłem następujące typy:

export const ADD_PROJECT = 'ADD_PROJECT';
export const REMOVE_PROJECT = 'REMOVE_PROJECT';
export const SET_PROJECT_NAME = 'SET_PROJECT_NAME';
export const SET_PROJECT_DESCRIPTION = 'SET_PROJECT_DESCRIPTION';
export const ADD_PROJECT_CATEGORY = 'ADD_PROJECT_CATEGORY';
export const REMOVE_PROJECT_CATEGORY = 'REMOVE_PROJECT_CATEGORY';
export const SET_PROJECT_CATEGORY_NAME = 'SET_PROJECT_CATEGORY_NAME';
export const SET_PROJECT_CATEGORY_DESCRIPTION = 'SET_PROJECT_CATEGORY_DESCRIPTION';
export const EDIT_PROJECT_ID = 'EDIT_PROJECT_ID';
export const EXPORT_PROJECT_CATEGORY_ID = 'EDIT_PROJECT_CATEGORY_ID';

Teraz pora na kolejną część układanki - kreatory akcji. Kolejna rzecz, ktora może wydawać się niepotrzebna, jeśli zaczynamy pracę z Redux. Przecież przy wywoływaniu akcji zawsze ręcznie możemy sobie stworzyć obiekt akcji, to w takim razie po co nam kreatory akcji? Kreatory mają taką samą funkcję, co w przypadku zmiennych do typów. Mają nam ułatwić pracę i wyeliminować często popełniane błędy. Dzięki temu, że akcję deklarujemy w jednym miejscu nie mamy duplikacji kodu, a jeśli potrzebujemy wywołać akcję to wystarczy teraz tylko wywołać jedną funkcję, zamiast ręcznie tworzyć obiekt akcji.

import { ADD_PROJECT, REMOVE_PROJECT, SET_PROJECT_NAME,
    SET_PROJECT_DESCRIPTION, ADD_PROJECT_CATEGORY, REMOVE_PROJECT_CATEGORY,
    SET_PROJECT_CATEGORY_NAME, SET_PROJECT_CATEGORY_DESCRIPTION,
    EDIT_PROJECT_ID, EDIT_PROJECT_CATEGORY_ID
} from './../types';

export function addProject(projectId) {
    return {
        type: ADD_PROJECT,
        payload: projectId
    }
}

export function removeProject(projectId) {
    return {
        type: REMOVE_PROJECT,
        payload: projectId
    }
}

export function setProjectName(projectId, name) {
    return {
        type: SET_PROJECT_NAME,
        payload: {
            projectId,
            name
        }
    }
}

export function setProjectDescription(projectId, description) {
    return {
        type: SET_PROJECT_DESCRIPTION,
        payload: {
            projectId,
            description
        }
    }
}

export function addProjectCategory(projectId, categoryId) {
    return {
        type: ADD_PROJECT_CATEGORY,
        payload: {
            projectId,
            categoryId
        }
    }
}

export function removeProjectCategory(projectId, categoryId) {
    return {
        type: REMOVE_PROJECT_CATEGORY,
        payload: {
            projectId,
            categoryId
        }
    }
}

export function setProjectCategoryName(projectId, categoryId, name) {
    return {
        type: SET_PROJECT_CATEGORY_NAME,
        payload: {
            projectId,
            categoryId,
            name
        }
    }
}

export function setProjectCategoryDescription(projectId, categoryId, description) {
    return {
        type: SET_PROJECT_CATEGORY_DESCRIPTION,
        payload: {
            projectId,
            categoryId,
            description
        }
    }
}

export function editProjectId(projectId, id) {
    return {
        type: EDIT_PROJECT_ID,
        payload: {
            projectId,
            id
        }
    }
}

export function editProjectCategoryId(projectId, categoryId, id) {
    return {
        type: EDIT_PROJECT_CATEGORY_ID,
        payload: {
            projectId,
            categoryId,
            id
        }
    }
}

Każdą akcję mamy dobrze przygotowaną, widzimy jakie parametry otrzymamy w naszym reduktorze, więc możemy zabierać się za jego implementację.

import _ from 'lodash';
import { ADD_PROJECT, REMOVE_PROJECT, SET_PROJECT_NAME,
    SET_PROJECT_DESCRIPTION, ADD_PROJECT_CATEGORY, REMOVE_PROJECT_CATEGORY,
    SET_PROJECT_CATEGORY_NAME, SET_PROJECT_CATEGORY_DESCRIPTION,
    EDIT_PROJECT_ID, EDIT_PROJECT_CATEGORY_ID
} from '../types';

const projectsReducer = (
  state = {},
  action
) => {
  switch (action.type) {
    case ADD_PROJECT:
      return Object.assign({},state,{[action.payload]: {
        id: action.payload,
        name: '',
        description: '',
        categories: {}
      }});
    case REMOVE_PROJECT:
      return _.omit(state, [action.payload]);
    case SET_PROJECT_NAME:
      return Object.assign({},
        _.set(state,
          `[${action.payload.projectId}].name`,
          action.payload.name))
    case SET_PROJECT_DESCRIPTION:
      return Object.assign({},
        _.set(state,
          `[${action.payload.projectId}].description`,
          action.payload.description))
    case ADD_PROJECT_CATEGORY:
    case REMOVE_PROJECT_CATEGORY:
    case SET_PROJECT_CATEGORY_NAME:
    case SET_PROJECT_CATEGORY_DESCRIPTION:
    case EDIT_PROJECT_ID:
    case EDIT_PROJECT_CATEGORY_ID:
      return state;
    default:
      return state;
  }
};

export default projectsReducer;

Reduktor zawsze powinien zwracać nam nowy obiekt, przez co używam Object.assign. Jest to nowa metoda z ES6, która pomaga w tworzeniu nowych obiektów na podstawie istniejących. Przy usuwaniu atrybutów z obiektu korzystam z _.omit. Ta funkcja biblioteki lodash pozwala usuwac z obiektu pojedyncze atrybuty i wynik zwraca w postaci nowego obiektu, przez co nie jest tutaj wymagana metoda assign dla obiektu. Nieobsłużone przypadki zwracają poprzedni stan zgodnie z dobrą praktyką przy korzystaniu z Redux.

Tak wygląda moje podejście do zarządzania akcjami w Redux. Sam nie miałem jeszcze dużej praktyki z Redux i moje rozwiązania mogą nie być optymalne, więc jeśli możecie coś poradzić, to czekam na komentarze. W następnym poście wrócę do reduktorów i spróbuję podejść do nich z niemutowalnymi obiektami.

Najlepsza nowość w ES6 - modules

Wed, 29 Mar 2017 00:00:00 GMT

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.

Moduły w języku JS pojawiły się już dawno temu, ale tylko w formie konwencji. Były moduły CommonJS i AMD, ale teraz mamy już dostęp do natywnych modułów zdefiniowanych już w standardzie javascript. Dzięki temu powinien zakończyć się odwieczny problem gigantycznych plików JS, w których znajduje się cały kod aplikacji. Pisanie prostego, modularnego kodu jest banalnie proste i moduły powinny być stosowane przy wszystkich nowych projektach. Jedyną aktualną wadą jest brak natywnego wsparcia modułów w przeglądarkach. Z pomocą przychodzi jednak webpack, który bez żadnej dodatkowej konfiguracji transpiluje nasz kod używający modułów ES6 do jednego pliku, który możemy wysłać do każdej przeglądarki. Więcej na temat webpacka i jego instalacji można znaleźć na oficjalnej stronie

To teraz pora na przedstawienie składni modułów. Moduły opierają się na eksporcie i imporcie. Do eksportu używamy polecenia: export, a do importu import. Tak proste są moduły ES6. Pokażę teraz różne rodzaje eksportów: domyślne, nazywane i jak się je obsługuje.

// plik a.js
export const INCREMENT = 5;

export default function (x) {
    return x + INCREMENT;
}

export function doubleIncrement () {
    return 2 * INCREMENT;
}

// plik b.js
import increment, { INCREMENT as b, doubleIncrement } from './a';

increment(3);
console.log(b);
doubleIncrement();


// plik c.js
import * as inc from './a'

inc.increment(3);

Na powyższym przykładzie pokazałem z czego najcześciej korzystam i co wystarczy, żeby zacząć korzystać z modułów. W pliku a.js w pierwszej linii zdefiniowałem standardowy export zmiennej z pliku. Eksportować w ten sposób możemy funkcje, zmienne, klasy.

Kolejnym typem eksportu jest eksport domyślny. Żeby go użyć po słowie export używamy słowa default. Należy tutaj zauważyć, że w jednym pliku możemy tylko raz eksportować domyślnie i wtedy w przypadku zmiennych const i let nie definiujemy zmiennej, tylko zwracamy wartość(np. export default 5). Później eksportuję jeszcze jedną funkcję w taki sam sposób jak zmienną INCREMENT.

Zamiast tej składni możemy wszystkie rzeczy wyeksportować w innym miejscu kodu i nie potrzebujemy wtedy przy każdej zmiennej, czy funkcji pisać słowa export. Wtedy na przykład na końcu pliku deklarujemy export { INCREMENT, doubleIncrement }. Przy takiej deklaracji możemy również zmieniać nazwę eksportu (np. export { INCREMENT as INC, doubleIncrement as default }).

Przejdźmy teraz do tego w jaki sposób zaimportować to co wyeksportowaliśmy z innego pliku. Zaczynamy on słowa import potem deklarujemy co chcemy zaimportować z pliku, następnie słowo kluczowe from i definujemy ścieżkę pliku. W przypadku braku ścieżki plik będzie szukany wśród modułów w node_modules. Rozszerzenie js może zostać pominięte.

Jeśli potrzebujemy zaimportować tylko domyślny eksport to wystarczy nam import nazwa from './plik'. Nazwa może być jakakolwiek i pod nią będziemy móc się dostać do zaimportowanej zmiennej, funkcji, czy klasy. Jeśli chcemy zaimportować jeden z nazwanych eksportów - deklarujemy je w klamrach i podejemy nazwę elementu, który eksportujemy (np. import { a, b as c } from './moj-plik'). W tym przykładzie pokazałem, że nawany eksport można zaimportować pod konkretną nazwą z użyciem słowa as.

Został nam ostatni typ importu. import * as inc from './a' - przy tym imporcie zaimportowane zostaną wszystkie wyeksportowane elementy do obiektu o nazwie inc. Żeby wykonać wyeksportowaną funkcję b wykonujemy inc.b().

Tak oto wygląda praca z modułami w ES6. Opanowanie ich nie jest ciężkie, a składnia jest bardzo prosta. Po poznaniu tej funkcji języka już nigdy nie wrócisz do pisania gigantycznych plików, a cały Twój kod będzie znacznie lepiej uporządkowany. Po więcej informacji na temat modułów zapraszam do artykułu na blogu Dr. Axela Rauschmayer, który jest poświęcony nowym standardom JS.

Struktura stanu aplikacji

Tue, 28 Mar 2017 00:00:00 GMT

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.

Pisanie aplikacji w React to jedna ciągła refaktoryzacja. Cały czas wydziela się nowe komponenty, rozbija zakres odpowiedzalności aktualnych komponentów, niektóre komponenty przerabia się na prezentacyjne, inne stają się kontenerami. Jednak już na początku prac ważne jest dobre rozplanowanie stanu aplikacji w Redux. Zaprezentuję dzisiaj, jak sobie wyobrażam mój stan aplikacji do mojego MVP.

W skład MVP ma wchodzić definiowanie zadań. Każde zadanie może być jednorazowe lub może być zadaniem cyklicznym. Każde zadanie ma swoją wagę w punktach i możemy do zadania przypisać projekt i kategorię w projekcie. Takie są założenia do MVP menedżera życia. Przejdźmy więc do tworzenia struktury stanu aplikacji.

Zacznijmy od mniej skompilkowanej części - projektu.

projects: {
    test: {
        id: "test",
        name: "Testowy projekt",
        description: "Projekt dla sąsiada testa"
        categories: {
            estimation: {
                id: "estimation",
                name: "Estymacja",
                description: "Kategoria dla szacunków"
            },
            development: {
                id: "development",
                name: "Programowani",
                description: "Prace programistyczne"
            }
        }
    },
    drugi_test: {
        id: "drugi_test",
        name: "Kolejny test",
        description: "Opis dla drugiego projektu",
        categories: {}
    }
}

Projekty i kategorie mają zostać w przyszłości użyte do generowania różnego rodzaju statystyk i raportów. Taka struktura powinna zapewnić łatwość dodawania kolejnych atrybutów do projektów, jak również zapewnić proste przeszukiwanie po stronie kodu. Nie zostały tutaj użyte żadne tablice. Do wszystkiego można się dostać po identyfikatorze, co pozwoli uniknąć przechodzenia po całej liście przy próbie znalezienia konkretnego projektu.

Przejdźmy teraz do definiowania zadań.

tasks: {
    5: {
        id: 5,
        name: "Pierwsze zadanie",
        project: "test",
        project_category: "estimation",
        points: 15,
        cyclic: 3
        date: "2017-04-20",
        status: "todo"
    }
},
cyclic_tasks: {
    3: {
        id: 3,
        start_date: "2017-03-21",
        end_date: "2017-06-20",
        repeat: "*",
        name: "Pierwsze zadanie",
        project: "test",
        project_category: "estimation",
        points: 15
    }
}

Obiekt zadań będzie przechowywać wszystkie zadania. Każde zadanie ma swoje atrybuty: nazwę, status, datę i może mieć przypisany projekt i kategorię projektu. Kolejnym obiektem są cykliczne zadania. Tutaj definiujemy zadania cykliczne, jak często mają być powtarzane (* - każdy dzień, liczby 0-6 rozdzielone przecinkiem poszczególne dni tygodnia). Dodatkowo dajemy datę początkową zadań cyklicznych i końcową. Definiujemy także domyślną nazwę, punkty i dane projektu.

Dzięki takiemu rozwiązaniu będziemy mogli generować pojedyncze zadania do obiektu tasks, które będą miały przypisywane domyślne atrybuty. Każde pojedyncze zadanie będziemy mogli osobno modyfikować, jak również będziemy mogli zmienić wszystkie zadania z cyklicznej grupy. Podobnie działa taki mechanizm w kalendarzu Google. Przy edycji wydarzenia cyklicznego możemy edytować pojedyncze wydarzenie lub wszystkie wydarzenia w cyklu. Myślę, że to zapewni odpowiednią elastyczność i nie będzie wymagać dużych zmian w miarę rozwoju aplikacji.

W następnych postach zabierzemy się za implementację przemyślanego dzisiaj stanu aplikacji i zobaczymy, czy to co sobie wymyśliłem będzie działać dobrze.

Yarn - lepszy klient npm?

Wed, 22 Mar 2017 00:00:00 GMT

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 npm install komenda yarn add. 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.

Dla mnie głównym powodem, żeby skorzystać z Yarna były długie czasy instalacji pakietów, czy to przy stawianiu projektu, czy przy instalowaniu pojedynczych modułów. Yarn bardzo mocno reklamuje to, że jest znacznie szybszy od klienta npm. Moje subiektywne wrażenia przy instalacji również to potwierdzają. Wszystko działa znacznie szybciej niż npm, w informacje wyświetlane przy instalacji pakietów są bardziej czytelne. Według benchamrków Yarn jest zazwyczaj 2 razy szybszy niż npm.

Kolejną bardzo fajną funkcjonalnością Yarna jest plik yarn.lock, który blokuje nam pakiety na konkretnych wersjach. W pliku tym są informacje o wersji pakietu, miejsca z którego został pobrany i jego suma kontrolna. W npm też coś takiego istnieje i nazywa się shrinkwrap, ale obsługa tego w kliencie npm jest mniej przyjemna. Nie musimy pamiętać o tym pliku, o jego aktualizowaniu przy zmianie wersji. W Yarn każda instalacja pakietu, aktualizacja automatycznie zaktualizuje plik yarn.lock. Dzięki temu wszyscy zawsze mają takie same wersje pakietów. Problemy z różnymi wersjami pakietów czasem stwarzały problemy, zwłaszcza, jeśli twórca pakietu nie przestrzegał zasad wersjonowania według semver, na którym opiera się cały system npm.

Yarn ma jeszcze jedną drobną nowość, której brakuje w npm. Dzięki poleceniu yarn licences ls można wyświetlić listę wszystkich pakietów z ich licencjami. Drobnostka, a czasem może się przydać.

Start z Yarn jest bardzo prosty. Instalujemy klienta zgodnie z wskazówkami na stronie i możemy zacząć korzystać.

Poniżej lista najważniejszych komend npm i ich odpowiedników w Yarn:

npm	Yarn
npm install	yarn
npm install --save react	yarn add react
npm install --save-dev webpack	yarn add --dev webpack
npm install --global yo	yarn global add yo

Większa lista jest dostępna w dokumentacji Yarna.

Należy tutaj zauważyć, że z Yarn nie możemy zainstalować pakietu bez opcji --save lub --save-dev. Według mnie to duży plus, bo nigdy nie spotkamy się z sytuacją, że tworzymy projekt i instalujemy wszystkie zależności. Następnie dzielimy się projektem z kolegą, mówimy mu, żeby zrobił npm install i wszystko będzie działać. Tu natomiast dostajemy wiadomość, że coś nie działa i brakuje jakiegoś pakietu. Przez to, że w Yarn wszystko jest zawsze zapisywane w package.json unikamy tego powszechnego problemu.

Yarn ma jeszcze parę fajnych funkcji i jeśli chcecie o nich poczytać, to wszystkie informacje znajdziecie na stronie Yarna. Wszystko jest bardzo przejrzyście wyjaśnione i całkowite przejście z npm na Yarn dla mnie nie stanowiło żadnego problemu dzięki tej dokumentacji. Zachęcam każdego do sprawdzenia Yarna, choćby tylko dla szybszych instalacji. Może akurat też się wam tak spodoba, że już nie wrócicie do klienta npm.

Redux - zapis stanu do lokalnej pamięci

Sat, 18 Mar 2017 00:00:00 GMT

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.

Przeglądarka oferuje kilka możliwości przechowywaniu stanu. Wsród nich są sessionStorage, localStorage, indexedDB i ciasteczka. Moim wymaganiem było trzymanie stanu przez cały czas development, a nie tylko na czas sesji. Z tego powodu sessionStorage odpada. IndexedDB lepiej nadaje się do tworzenia lokalnych baz danych, a moim celem jest zapisanie pojedynczego obiektu - przez to indexedDB również odpada. Stan aplikacji ma być dostępny tylko dla klienta i nie musi być wysyłany do serwera, więc ciasteczka też się nie nadają. Tak oto pozostał nam localStorage.

LocalStorage ma bardzo proste API. Oferuje nam dwie metody: setItem(key, value) oraz getItem(key). Jak już znamy API, to możemy zabrać się do pracy. Naszym celem jest zapis przy każdej zmianie stanu aplikacji oraz odczyt stanu aplikacji przy ładowaniu strony.

Stan aplikacji zapiszę pod kluczem reduxState. Tak więc odczyt stanu możemy zrealizować w następujący sposób.

const persistedState = localStorage.getItem('reduxState') ? JSON.parse(localStorage.getItem('reduxState')) : {}

Przy odczycie zserializowany stan muszę przypisać do obiektu. Do parsowania JSON używam funkcji JSON.parse(). Poniżej kod do zapisu stanu.

localStorage.setItem('reduxState', JSON.stringify(store.getState()))

Analogicznie przy zapisie stanu do localStorage obiekt należy najpierw serializować funkcją JSON.stringify().

Teraz zostaji mi tylko połączenie zapisu i odczytu do Redux. Zapis możemy wykonać korzystając z funkcji subscribe() na naszym stanie. Funkcja ta jest wywoływana przy każdej nowej akcji w Redux.

Finalny kod do zapisu stanu wygląda następująco:

store.subscribe(()=>{
    localStorage.setItem('reduxState', JSON.stringify(store.getState()))
})

Stan aplikacji odczytujemy tylko raz, przed inicjowaniem naszego stanu Redux. Przy tworzeniu naszego kontenera stanu jako drugi parametr możemy przekazać stan początkowy i tu własnie przekazujemy odczytany z lokalnej pamięci stan. Tak oto wygląda kod odczytu stanu:

const persistedState = localStorage.getItem('reduxState') ? JSON.parse(localStorage.getItem('reduxState')) : {}
const store = createStore(rootReducer, persistedState)

Taki krótki kod wystarczy, żeby nasz stan był zapisywany w lokalnej pamięci i usprawniał nam proces tworzenia aplikacji. W moim projekcie jest również zaimplementowane renderowanie po stronie serwera. Tu trzeba trochę uważać i używać localStorage tylko po stronie klienta. Żeby sprawdzić środowisko wykonywania skryptu przydaje się sprawdzenie, czy obiekt window jest dostępny: typeof window !== 'undefined'.

Jeśli wspieramy starsze przeglądarki, warto przed użyciem funkcji localStorage sprawdzić, czy to API jest dostępne za pomocą warunku: typeof(Storage) !== 'undefined'. W ten sposób unikniemy błędów w starszych przeglądarkach i strona nadal będzie w nich użyteczna.

Tworzenie prostego bota do Messengera

Wed, 15 Mar 2017 00:00:00 GMT

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.

Wiele popularnych komunikatorów internetowych (np. Messenger, Slack, Skype, Telegram) daje nam dostęp do API komunikatorów i otwiera nam nowe możliwości do komunikacji z naszymi użytkownikami. Dodatkowo ogromna popularność tych komunikatorów pozwala nam dotrzeć do dużej liczby odbiorców.

Stworzenie dobrego bota jest bardzo trudnym wyzwaniem. Wiąże się to z koniecznością prztwarzania języka naturalnego, zrozumienia komunikatów użytkownika, które są przekazane w bardzo swobodnej formie i wysłania odpowiedniej wiadomości zależnej od poprzednich wiadomości. Mimo, że stworzenie dobrego bota jest ciężkie, to rozpoczęcie przygody z tworzeniem botów jest banalnie proste.

Z pomocą przychodzi nam Claudia Bot Builder. Ja z pomocą tego narzędzia byłem w stanie zrobić swojego bota do messengera w ciągu 10 minut. Poniżej pokaże jakie kroki trzeba wykonać, żeby stworzyć swojego pierwszego chat bota na platformę messenger. Finalny rezultat można znaleźć na githubie.

Na początku potrzebujemy zainstalować nasze zależności.

npm install claudia -g
npm install claudia-bot-builder --save

Kolejnym krokiem jest stworzenie kodu naszego bota. Tworzę plik bot.js z następującym kodem:

const botBuilder = require('claudia-bot-builder');

module.exports = botBuilder(request => {
    return 'Hello world!';
});

Tak oto stworzyliśmy cały kod dla naszego pierwszego bota. A teraz przejdźmy do najlepszej części Claudia Bot Builder, czyli łatwgo wrzucania i konfiguracji bota. Nie będę opisywał, jak konfiguruje się dane do konta AWS lokalnie. Wszystko jest dostępne tutaj.

Zaczynamy od wykonania polecenia:

claudia create --region eu-central-1 --api-module bot --configure-fb-bot

Polecenie wrzuca naszą aplikacją na AWS Lambda (w tym przypadku na serwer eu-central-1, który znajduje się w Frankfurcie) i pozwala nam skonfigurować ją z facebookiem. Pod koniec wrzucania w konsoli dostaniemy informację o adresie url bota, jego klucz oraz zostaniemy poproszeni o token strony naszej aplikacji FB i secret.

Na stronie developers.facebook.com tworzymy aplikację i wybieramy jej typ jako bot messenger. Następnie w panelu aplikacji w zakładce Products->Messenger tworzymy token dla wybranej strony oraz uzupełniamy dane w sekcji webhook informacjami, które zostały zwrócone w konsoli. W terminalu wprowadzamy wygenerowany token oraz secret dostępny w panelu aplikacji pod zakładką Settings. Po wykonaniu tych kroków nasz bot jest gotowy do działania.

Wchodzimy na stronę, do której pdopięliśmy bota i piszemy wiadomość. Na każdą wiadomość nasz bot powinien odpowiedzieć Hello world!.

Jak już mamy działającego bota to dodajmy trochę funkcjonalności. Nasz bot ma proponować listę reczy, którą mamy spakować na wyjazdy o różnej długości. Poniżej zamieszczam cały kod bota i już wyjaśniam, co za dziwne elementy tu widzimy.

const botBuilder = require('claudia-bot-builder');
const fbTemplate = botBuilder.fbTemplate;

module.exports = botBuilder(request => {
    if (request.type === 'facebook') {
        if (request.text === 'Co zabrać na wyjazd?') {
            const newMsg = new fbTemplate.Text('Na jak długo wyjeżdżasz?');
            
            return newMsg
            .addQuickReply('1 dzień', '1 dzień')
            .addQuickReply('3-4 dni', '3-4 dni')
            .addQuickReply('tydzień', 'tydzień')
            .addQuickReply('2 tygodnie', '2 tygodnie')
            .addQuickReply('miesiąc', 'miesiąc')
            .addQuickReply('> niż miesiąc', '> niż miesiąc')
            .get();
        } else if (request.text === '1 dzień') {
            return 'przeżyjesz bez niczego :P'
        } else if (request.text === '3-4 dni') {
            return 'zabierz 4 koszulki,\nspodnie,\nładowarkę do telefonu,\nbieliznę,\nkosmetyczkę,\nbatony';
        } else if (request.text === 'tydzień') {
            return 'weź kilka koszulek,\n2 pary spodni,\nbieliznę,\nszampon,\nszczoteczkę,\npastę do zębów,\nżel pod prysznic,\nręczniki,\nsłodycze,\n 🐱';

        } else if (request.text === '2 tygodnie') {
            return 'przykro mi, jak wyjeżdżasz na 2 tygodnie to sobie znajdź inne źródła wiadomości z informacjami co trzeba spakować. Hue hue.';

        } else if (request.text === 'miesiąc') {
            return new fbTemplate.Generic()
                .addBubble('Kompletna lista do spakowania', 'Na tej stronie znajdziesz bardzo szczegółową listę rzeczy do spakowania.')
                .addButton('Kompletna lista', 'http://kropkinamapie.pl/zabrac-gory-morze-wakacje-wyjazd-check-lista.html')
                .addButton('Inna fajna lista', 'http://podrozniczo.pl/10-rzeczy-ktore-warto-zabrac-ze-soba-w-podroz/')
                .addButton('Dzięki', 'Dzięki')
                .get();

        } else if (request.text === '> niż miesiąc') {
            return 'kup tam mieszkanie,\nwszystko kup na miejscu,\nnie zapomnij wziąć pieniędzy,\nweź jeszcze więcej pieniędzy.\nTo wszystko.';
        } else if (request.text === 'Dzięki' || request.text === 'dzięki' || request.text === 'thx' || request.text === 'Dziękuję') {
            return 'Proszę. Taka moja praca :)'
        } else {
            return 'Żeby rozpocząć zadaj mi pytanie: Co zabrać na wyjazd?';
        }
    }
});

Na samej górze funkcji owijam wszystko w warunek request.type === 'facebook'. Jako, że Claudia pozwala nam tworzyć jeden kod na wiele różnych komunikatór jednocześnie musimy specjalne funkcjonalności chatów oferować tylko odpowiednim komunikatorom. Mój bot ma działać tylko na platformie messenger, przez co korzystam z bardziej zaawansowanych elementów, takich jak szybkie odpowiedzi, czy szablony. Kolejnym atrybutem zmiennej request jest text i to właśnie w tym atrybucie dostajemy wiadomość wysłaną nam przez użytkownika. Mój bot w przypadku pytania 'Co zabrać na wyjazd?' zaoferuje kilka szybkich odpowiedzi, dla których zostały przygotowane listy.

W moim przykładzie użyłem specjalnych funkcjonalności messengera, czyli szybkich odpowiedzi i szablonów. Dokładna specyfikacja tych funkcji jest dostępna na stronie dokumentacji claudia-bot-buildera. Te funkcjonalności pozwalają nam na większą kontrolę komunikacji z użytkownikiem. Oferując mu szybkie odpowiedzi możemy dostawać zdefiniowane przez nas komunikaty, a nie odpowiadać na literówki wiadomością Nie rozumiem. W czym mogę pomóc?. Szablony natomiast pozwalają nam przekazać dużo opcji użytkownikowi i pokazanie bardziej multimedialnych komunikatów. Możemy wysyłać załączniki, wiadomości audio, filmy, zdjęcia, linki, a nawet paragony. Bardzo polecam korzystanie z tych elementów, bo jest to jeden z prostszych sposobów, których możemy użyć, żeby nasz bot pomagał użytkowikowi wykonać zadanie, a nie go frustrować.

Zapraszam wszystkich do eksperymentowania z chat botami, bo start naprawdę jest bardzo szybki i łatwy, a można znaleźć do nich kilka bardzo fajnych zastosowań.

Testowanie komponentów prezentacyjnych

Sat, 11 Mar 2017 00:00:00 GMT

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.

W momencie pisania tego posta w aplikacji są dwa kontenery (komponenty, które są powiązane z stanem aplikacji) i jeden bardzo prosty komponent prezentacyjny. Komponent prezentacyjny jest natomiast funkcją. Komponent prezentacyjny nie ma własnego stanu i korzysta jedynie z przekazanych atrybutów. Jako, że te komponenty są bardzo proste, to stwierdziłem, że są dobrym miejscem na start z pisaniem testów jednostkowych.

W projekcie mam skonfigurowany framework do testów mocha i jest uruchamiany z pomocą Karmy. Odpalam polecenie npm run test:watch i wszystkie moje testy są odpalane za każdym razem, gdy zmieniamy kod aplikacji lub testy.

Pliki testów przechowuję w folderze /app/tests z rozszerzeniem -test.jsx. Poniżej zamieszczam kod testu do komponentu wyświetlania pojedynczego todo.

import React from 'react';
import { shallow } from 'enzyme';
import { expect } from 'chai';

import TodoItem from './../components/todo-item.jsx';

describe('<TodoItem/>', function () {
  it('should have an li with todo', function () {
    const wrapper = shallow(<TodoItem>Hey</TodoItem>);
    expect(wrapper.find('li')).to.have.length(1);
  });

  it('should have an li with class todo-item', function () {
    const wrapper = shallow(<TodoItem>Hej</TodoItem>);
    expect(wrapper.find('li').props().className).to.include('todo-item');
  });

  it('should render a children', function () {
    const wrapper = shallow(<TodoItem><span>Hey</span></TodoItem>);
    expect(wrapper.contains(<span>Hey</span>)).to.equal(true);
  })
});

Przy pisaniu testów oprócz frameworka Mocha i Karmy używam jeszcze biblioteki do asercji Chai oraz bibliotekę do testowania komponentów enzyme stworzoną przez Airbnb.

Mi bardzo odpowiada sposób asercji w stylu BDD, ale biblioteka Chai pozwala również na pisanie asercji w klasycznym sposobie (np. assert('foo' !== 'bar', 'foo is not bar');). Styl BDD mnie przekonał, bo testy z takimi asercjami czyta się jak zwykłe zdania. Dla mnie właśnie takie asercje BDD są najbardziej zbliżonym kodem do języka naturalnego. Czyta się je bardzo szybko i nie trzeba się zastanawiać co otrzymujemy.

Biblioteka enzyme natomiast bardzo pomaga testować pojedyńcze komponenty w izolacji. Do biblioteki React jest dodatkowa biblioteka wspomająca testowanie React Test Utilities, ale ze względu na łatwe użycie pozostałem przy enzyme. Biblioteka oferujemy nam 3 główne metody shallow, mount i render. W dokumentacji metody są bardzo dobrze opisane i przedstawione są przypadki użycia każdej z nich. Do testowania komponentów prezentacyjnych najczęściej używa się funkcji shallow oraz render. Każda funkcja zwraca nam obiekty odpowiedniego typy. Dla metody shallow dostajemy objekty typu ShallowWrapper, które oferują nam mnóstwo przydatnych funkcji. W moich testach wykorzystywałem tylko metod find i contains, ale pewnie inne funkcje do moich przypadków testowych nadają się lepiej.

Pisanie testów z wykorzystaniem tych dwóch bibliotek jest bardzo proste i przyjemne, ale to dopiero początek mojej drogi z pisaniem testów jednostkowych. Teraz zostało mi poznawanie innych funkcji tych bibliotek i znajdowanie odpowiednich zastosowań dla nich, by kod był jeszcze bardziej zrozumiały i prosty w utrzymaniu.

Serverless

Wed, 08 Mar 2017 00:00:00 GMT

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".

Pierwszy raz spotkałem się z tym pojęciem w artykule o pisaniu chat botów w node.js na Smashing Magazine. Pojawiło się pojęcie Lambdy - usługi Amazonu opierającej całe swoje działanie na wrzucaniu swojej aplikacji jako funkcji, która może być dynamicznie uruchamiana, gdy jej potrzebujemy. Wokół tego opiera się cały model płatności, gdzie płacimy tylko za wykonywanie funkcji, a czas bezczynności jest bezpłatny. Brzmi to bardzo dobrze, gdy tworzymy usługi, które czasem mogą być używane przez ogromną liczbę osób, a czasem stoją bezczynne(AWS Lambda odpowiada również za skalowanie, żeby funkcja była stanie obsłużyć duży ruch). Dla przykładu obsługa 2 mln wywołań funkcji kosztuje nas około 0.20$. Pierwszy 1mln wywołań w miesiącu jest za darmo. Dokładny cennik jest przedstawiony tutaj.

Przy prostych aplikacjach na własny użytek nie ma prawie szans, żeby wykorzystać bezpłatny limit. Po wstępnym entuzjaźmie co do tej usługi zacząłem się zastanawiać, a gdzie w takim razie mam przechować wszystkie dane, gdzie mam przechowywać pliki? Przez te wątpliwości przestałem się interesować tematem i widziałem zastosowanie tego tylko w prostych przypadkach, takich jak chat boty i proste bezstanowe usługi do przetwarzania danych.

Po długiej przerwie temat powrócił na konferencji "Boiling Frogs". Prezentacja odpowiedziała na moje poprzednie wątpliwości i teraz dopiero zrozumiałem, że "serverless" nie opiera się tylko i wyłącznie na AWS Lambda. Całe podejście "serverless" to nie korzystanie z jednej usługi, a całego ekosystemu usług przystosowanego do współpracy między sobą. Aktualnie najpopularniejszy taki ekosystem ma Amazon. Gdy potrzebujemy korzystać z bazy danych do Lambdy podpinamy DynamoDB, potrzebujemy przechowywać pliki - używamy Simple Storage Service, nazywanego S3. Nasze funkcje chcemy udostępnić jako API - korzystamy z API Gateway. Ekosystem jest tak rozbudowany, że każdy rzeczywisty przypadek, ktory powinien obsługiwać nasz serwer może być zrealizowany za pomocą odpowiedniego łączenia wszystkich narzędzi.

Postanowiłem trochę pobawić się tym ekosystemem z wykorzystaniem frameworka serverless. Pierwsze spotkanie było bardzo przyjemne. Po założeniu konta na AWS po 10 minutach byłem w stanie zobaczyć w przeglądarce Hello World wysłane z serwera w Frankfurcie. Dodanie kolejnych funkcji i podpięcie ich pod konkretne adresy url jest bardzo proste. Wszystko opiera się na zmianie konfiguracji w pliku serverless.yml i zrobieniu deploya. Przy zmianie konfiguracji deploy chwilkę trwa, ale jeśli tylko aktualizujemy konkretną funkcję, zmiana jest błyskawiczna. Korzystanie z API Gateway nie mogło być prostsze.

Potem postanowiłem zrobić przykładowe API z zapisywaniem elementu do bazy i wyświetlaniem rekordów. Samo podpięcie dynamoDB nie jest ciężkie i API jest dostępne w przeglądarce, natomiast dostawałem błędy związane z uprawnieniami mojej funkcji do bazy danych. Walczyłem z tych 30 minut, ale bezskutecznie. Na tym zakończę opis moich dzisiejszych doświadczeń. Widzę duży potencjał w tym podejściu do budowania i hostowania aplikacji. Taka architektura wymaga na nas myślenie o usługach w bardziej granualny sposób i dobrze łączy się z mikro usługami. W najbliższym czasie będę jeszcze eksperymentował z "serverless" i postaram sie zintegrować z dynamoDB, S3 i zrobić jakąś użyteczną apkę.

Kilka słów o konfiguracji projektu

Sun, 05 Mar 2017 00:00:00 GMT

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.

Chcąc uniknąć tworzenia całej konfiguracji od początku postanowiłem skorzystać z wyszukiwarki projektów startowych React. Chciałem stworzyć sobie bardzo przyjemne środowisko do pracy. Wsród moich wymagań były: hot module replacement, możliwość korzystania z ES6, renderowanie po stronie serwera, przygotowany linter i framework do testów oraz już zintegrowany redux i react router. Szukając po tych wymaganiach znalazłem reactGo. Projekt ma ponad 2 tysiące gwiazdek na githubie, przez co zaufałem społeczności, że ten projekt będzie prosty do konfiguracji i będzie usprawniał pracę.

Instalacja jest bardzo prosta. Po prostu sobie klonujemy projekt lub pobieramy archiwum. Potem już w folderze projektu wykonujemy npm install i wszystkie wymagane zależności są zainstalowane. W projekcie jest przygotowanych kilka skryptów do budowy, testów, lintowania i do pracy. Po odpaleniu npm run dev pod adresem localhost:3000 widzimy już przykładowy projekt nad którym możemy pracować.

Teraz zaczyna się trudniejsza część konfigurowania projektu. Usunięcie wszystkich rzeczy, których nie potrzebujemy, żeby móc zacząć budować właściwą aplikację. W projekcie jest już przygotowany routing, logowanie z użyciem Google i przykładowe komponenty z stylami. Postanowiłem wyrzucić to wszystko i rozpocząć od zrobienia prostego Hello world. Po godzinie walki z częścią serwerową i frontową wyrzuciłem wszystkie nieistotne pliki i zakończyłem na prostej aplikacji z jedną stroną i napisem Hello world.

Początkowo planowałem skorzystać z SASS przy pisaniu CSS, natomiast projekt jest skonfigurowany do użycia modułów css i składni cssnext. Spróbuję zostać przy tej konfiguracji i nauczyć się przyszłościowej składni css i integrowania styli do komponentów zamiast pisania globalnych styli. Minusem może być flash strony bez styli przy renderowaniu serwerowym, ale może jeśli zostanie czasu to postaram się to naprawić.

W następnym poście opiszę prace nad pierwszą funkcjonalnością, a w międzyczasie lista blogów znajomych do odwiedzenia:

Rozpoczynam "Daj się poznać 2017"

Wed, 01 Mar 2017 00:00:00 GMT

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.

O konkursie dowiedziałem się od kolegi z pracy, który też podjął wyzwanie. Informacja rozniosła się po firmie i tak do udziału zgłosiło się jeszcze kilka osób. W następnym poście wrzucę linki do blogów wszystkich pracowników Divante, którzy również biorą udział w "Daj się poznać 2017".

Więcej o Daj się poznać

Motywacja

Od jakiegoś czasu chciałem wykonać aplikację, którą będę teraz realizować w ramach tego konkursu. Dodatkowo ostatnio interesuję się React.js i chciałem zrealizować projekt w tej technologii. Spodobała mi się idea tego konkursu i postanowiłem w końcu zabrać się za tę aplikację. Dodatkowe wymaganie pisania o projekcie na blogu pozwoli mi również podszlifować moje umiejętności pisarskie i jednocześnie "Dam się poznać" w Internecie. Liczę na to, że to wyzwanie będzie motywować mnie do regularnej pracy nad projektem i dotrwam do samego końca.

Projekt

Aplikacja ma wspomagać organizację życia i motywować do pracy nad sobą przez wykorzystywanie technik grywalizacji. Na początku zakładam możliwość organizacji wszystkich spraw, które wykonujemy codziennie. Zarządzanie swoją listą zajęć z uwzględeniem wag każdego zadania. Dla przykładu: za zrobienie zakupów dostaniemy 5 punktów, natomiast za oglądanie TV przez 2 godziny stracimy 12 punktów. Z czasem punkty mogą zostać rozbite na rodzaje (punkty za działania poprawiajace zdrowie fizyczne, inne punkty za rozwój kulturowy, intelektualny itp.). W planach jest również możliwość rejestracji czasu spędzanego na poszczególnych zadaniach, żeby stać się bardziej świadomymi tego, gdzie nam "czas ucieka".

Bazowym celem jest organizacja zadań i codziennych czynności, a po osiągnięciu tego celu będę dorzucać następne wymagania. Liczę na osiągnięcie głównego celu po około 6-7 tygodniach i wtedy będę miał jeszcze czas na dalsze usprawnienia projektu i zwiększaniu jego funkcjonalności.

Technologia

Projekt będzie realizowany w React.js i Redux po stronie frontu. Backend planuję wykonać na Node.js z frameworkiem Express.js z użyciem bazy MongoDB. Chciałem ten projekt szybko zacząć, przez co skorzystałem z reactGo.

Uwielbiam zawsze przy rozpoczynaniu projektu wybierać sobie stos technologiczny, konfigurować wszystkie narzędzia, ale w tym projekcie chcę jak najwięcej czasu spędzić na rzeczywistym programowaniu i pracy z React.js. Jestem trochę "uzależniony" od narzędzi i ten projekt będzie takim lekkim detoksem od konfiguracji. Może po zakończeniu wyzwania napiszę parę wpisów o konfiguracji webpack i docker, ale teraz zamierzam mieć działający pierwszy widok w przyszłym tygodniu.

Przy tym projekcie chcę również podszlifować pisanie testów i spróbuję przekonać się do TDD. Zobaczę jak w moim przypadku działa te podejście, czy rzeczywiście oprogramowanie będzie miało lepszą architekturę i będzie bardziej stabilne.

Plany są duże i zobaczymy, czy udaje się je zrealizować. W następnym poście myślę, że pojawi się już trochę kodu i opowiem trochę więcej o środowisku pracy.