DSP 2017 – Projekt Boardmastah – Tydzień 1

Początki są zawsze najgorsze. Dużo pracy koncepcyjnej, szukanie rozwiązań, zestawienie projektu i konfiguracja środowiska.

Posty konkursowe

Szczerze mówiąc trochę mnie męczy ten wymóg jednego posta tygodniowo o prowadzonym projekcie. Sprowadza się to do produkcji mało (moim zdaniem) ciekawych wpisów typu “dzisiaj zjadłem obiad i ściszałem telewizor” oczywiście w wersji technicznej czyli “dzisiaj zrobiłem funkcję x, a jutro planuje y”. Postaram się spełnić ten wymóg w wersji najciekawych z możliwych, jeżeli nie w samym podsumowującym tekście, to z pewnością takie podsumowanie wygeneruje u mnie jakieś dodatkowe artykuły już z bardziej konkretną treścią.

Rozpoczęcie projektu

Początki są zawsze najtrudniejsze i… najnudniejsze. Niestety ale start to cała ta zabawa z zestawieniem projektu, ustawieniem gita, deployem i ogólną konfiguracją środowiska do pracy.

Swój projekt zaskakująco zacząłem od… zmiany planów. Chciałem od początku zająć się frontendem gdyż nauka tego interesuje mnie najbardziej. Jednak doszedłem do wniosku, że lepiej będzie jak szybko zestawie sobie backend, który już wysyła jakieś przykładowe dane na których będę mógł operować. Nie dość, że to będzie praca na już docelowych danych to po prostu to co mogę zrobić najszybciej - zrobię na starcie i odciąże się od tej pracy w późniejszym czasie. Tym bardziej, że wchodząc w frontend wchodzę w nieznane sobie rejony więc bardzo obawiam się, że zajmie mi to sporo czasu zanim zrobię coś sensownego.

Backend

Jak wcześniej wspominałem zdecydowałem na postawienie backendu w PHP, a konkretniej na Laravelu. Dlaczego? Bo najszybciej. Nie jest moim celem teraz zabawa w jakiś piękny kod, w nowe czy też minimalistyczne frameworki. Chcę mieć tylko szybko mechanizm, który w prosty sposób wystawi mi dane do frontendu na których będę mógł działać. Tak naprawdę to w tym projekcie backend powinien być do zrealizowania w dowolnej formie i gdybym kiedyś rozwijał ten projekt dalej to wolałbym mieć go w innej technologii (np. w JS albo w Pythonie). Być może przyjdzie kiedyś czas na to (DSP 2018? 😀 ).

Jeżeli chodzi o Laravela i kontrowersje z nim związane. Co by złego o nim nie mówić to w temacie RAD (Rapid Application Development) jest bezkonkurencyjny. W moim przypadku przyda się też wbudowana funkcjonalność nazwana Laravel Echo. Jest to biblioteka opakowująca działanie na WebSocketach, z sterownikami do Pushera czy Redisa. Idealna sprawa do zrobienia czegoś niemal “out of the box”.

Być może do tematu backendu jeszcze wrócę pod koniec konkursu, ciężko mi powiedzieć jak bardzo opornie będzie mi szła nauka JS. W tej chwili priorytetem jest zrobienie MVP (minimalnej wersji produktu) i dopiero jak to będzie miało ręce i nogi to będę mogł zająć się dopieszczaniem tego.

Lokalne środowisko i deploy

Do pracy wykorzystam Laravel Valeta. Nie Vagranta, nie Dockera. Dlaczego? Bo znowu ten sam argument: idealnie nadaje się do szybkiego odpalania projektów. Dodanie nowego projektu kosztowało mnie… 2 sekundy. Docelowo pod koniec projektu chciałbym opakować to w jakiś automat, najlepiej przy użyciu Dockera. Tak aby każdy mógł go pobrać z gita i w parę minut uruchomić u siebie. Ale na czas produkcji dwusekundowy Valet jest idealny.

Do deploya wykorzystam najprostsze na świecie podpięcie zewnętrznego repo oraz ustawienie post-hooka, który w momencie odebrania kolejnego commita przegra go w docelowe miejsce. W temacie deploya jest bardzo wiele możliwości. Ten sposób cechuje się prostotą i idealnie się nadaje do małych projektów, przy których nie trzeba nic więcej ogarniać poza samym sklonowaniem projektu.

Zarówno temat Valeta jak i ten prosty deploy w oparciu o git hooka opiszę w następnych atykułach w tym tygodniu.

Laravel Valet czyli proste i szybkie środowisko PHP na MacOS