Skip to main content

[06 MyFood] Front hierarchia

Stało się… mam opóźnienie 2 tygodniowe, i można powiedzieć że wykorzystałem regulaminową przerwę w pisaniu.

Tak się zaczytałem w 1 tygodniu, że stwierdziłem, że nic nie umiem jeszcze. I nie napisałem nic :(

Drugi tydzień wolnego zużyłem przez natłok zadań w pracy i życiu.

Poniżej rozpiszę hierarchie z WebClient, która będzie obsługiwała Front aplikacji z wykorzystaniem React JS.

Trochę czasu mi zeszło na przygotowanie serwera JS, miałem problem przygotować wszystko. Co chwile coś mi nie działało albo tworzyłem małego potworka.

Znalazłem jednak artykuł na stronie https://nafrontendzie.pl/podstawy-reactjs-kompletny-tutorial/ i stworzyłem pusty projekt, z podstawowymi ustawieniami.

Projekt się pewnie jeszcze zmieni, ponieważ startowy projekt używa „Karma Mocha” do testów. A ja chciałem użyć „JEST” lub „Cucumber w wersji JS

https://github.com/mfratczak/myfood-generator/tree/master/WebClient

Odpalanie serwera front

# uruchomienie w trybie dev
npm start # lub
npm run serve

# uruchomienie wykorzystując pliki z katalogu dist (wersja produkcyjna)
npm run serve:dist

# generowanie plików do katalogu dist + kopiowanie zasobów statycznych
npm run dist

# urumienie testów
npm test

# uruchomienie testów wraz z re-testem przy zmianie pliku
npm run test:watch

# uruchomienie lintera (dzieje się też automatycznie po testach)
npm run lint

# czyszczenie katalogu dist
npm run clean

# kopiowanie statycznych zasobów
npm run copy
Przy bawieniu się dockerem, testowaniu, wielokrotnym odpalaniu środowisk, zdarza się ze nic nie chce działać.

Czemu?

Odpalanie testowych środowisk powoduje ze ściągamy zcachowane warstwy, lub generujemy nowe. Ponowne generowanie, drobne zmiany itp powodują dwa problemy:

  • ilość miejsca na serwerze maleje
  • obraz środowiska, który chciałbyś odpalić od zera powinieneś usunąć i odpalić jeszcze raz

Gdy odpalamy dockera:

to zostają ściągnięte wszystkie warstwy (layers) potrzebne do zbudowania środowiska. Jeśli budujesz środowisko, to jest ono budowane lokalnie.

Normalnie możesz zatrzymać kontenery:

lub całkowicie je usunać:

Czym to się różni?

Jeśli tworzysz nowy kontener, dla jednego obrazu, prawdopodobnie posiada on skrypty inicjujące, które ustawiają wszystko co trzeba do jakiegoś systemu (np system do zarządzania zadaniami Redmine). Kontenery również zapisują dane wewnątrz siebie dane (jeśli nie wyprowadziłeś ich na zewnątrz).

Aby nie stracić tych ustawień, można zastosować STOP. (np wchodzisz w dany kontener i instalujesz coś ręcznie, i się bawisz poznając nowe rzeczy, dzięki stop tego nie stracisz)

Nie powinniśmy zapisywać jednak danych wewnątrz kontenera. Powinniśmy wyjść z założenia, że cokolwiek w nim jest, można usunąć i zresetować do stanu początkowego.

Dlatego jak nie bawię się, lub nie instaluje ręcznie bibliotek celem jakichś testów, to używam DOWN.

Jednym słowem usuwam kontener, i tworze go znowu.

 

Co gdy nie można usunąć obrazów i kontenerów?

Zdarza się, że w testach tak zamieszamy :) przy tworzeniu multum wersji, zmian itp (standard), że nie można wygenerować nic nowego, lub nie widać zmian.

Wtedy tutaj przychodzą do pomocy polecenia dockerowe.

Zatrzymywanie wszystkich kontenerów dockerowych

Usuwanie wszystkich kontenerów, również które są ukryte na pierwszy rzut oka

Usuwanie wszystkich obrazów dockerowych na serwerze (ściągnięte, lub wygenerowane przez nas)

Usuwanie reszty obrazów,  jeśli nie usuneło wszystkiego a jest na liście docker images

Zdarza się, że nie można usunąć obrazów, ponieważ pojawia się błąd:

Error response from daemon: conflict: unable to delete ba62b42dad38 (cannot be forced) – image has dependent child images

Musimy wtedy skorzystać z flagi Force. (mówimy oczywiście o serwerze developerskim, gdzie możemy wszystko usuwać i niczego się nie obawiać, że stracimy dane :) )

Sprawdzamy czy usuneliśmy wszystko możemy poleceniami

 

Aliasy – czyli jak ułatwić sobie pracę

Sam korzystam z aliasów, które można znaleźć tutaj https://github.com/tcnksm/docker-alias/blob/master/zshrc

Krótkie wyjaśnienie: https://kartar.net/2014/03/useful-docker-bash-functions-and-aliases/

Jednym słowem, używam głównie poleceń:

dstop – zatrzymanie WSZYSTKICH kontenerów

drm – usunięcie wszystkich kontenerów

dri – usunięcie wszystkich obrazów

dalias – spis wszystkich aliasów dockerowych

dex nazwa-kontenera bash – wejście w dany kontener

 

I to tyle :) 

Mogłem dać spis poleceń na usuwanie pojedynczych obrazów lub kontenerów, ale o tym wszędzie piszą :) więc na pewno umiesz to robić, lub znajdziesz rozwiązanie.

Na lokalnym komputerze, korzystam z wszystkich poleceń, usuwam wszystko itp. Na serwerach w internecie, trzeba wsiąść pod uwagę, że możesz posiadać limit transferu. Więc każdorazowe usuwanie obrazów, i zaciąganie ich, spowoduje jego zużywanie. Ja wtedy usuwam, konkretny obraz (jeśli trzeba)

W razie pytań, lub moich błędów, pisz !

 

 

[05 MyFood] Hierarchia i podział projektu (docker, flask, react)

We wcześniejszym poście napisałem, że musiałem zrobić krok wstecz. Okazuje się, że musiałem zrobić kolejny krok wstecz.

Dlaczego?

Moim planem jest stworzenie projektu gdzie backend to flask. Będzie on serwował API, z którym komunikować się będzie front.

Na froncie stanie React, czyli technologia JS. Im więcej o nim czytam, i tworze tutoriale, tym bardziej mi się podoba :)

Moim błędnym podejściem było to, że python będzie odpowiadał za API, oraz serwował statyczną stronę. Na tej statycznej stronie miał być React.

Co tu jest błędnego?

Każda część projektu frontend i backend powinna być całkowicie oddzielnym bytem. Nie powinny być ze sobą powiązane. Front nie powinien być zależny od serwera API. Nie powinien być nawet na tym samym serwerze.

To oznacza że muszę przebudować hierarchie projektu.

Muszę wspomnieć, że mój błąd uświadomił mi kolega Dariusz (może kiedyś przekonam go do blogowania ;d )

Plusy:

  • możliwość łatwiejszego skalowania serwerem (baza, itp), wydzielenie backendu na inny serwer niż frontend
  • w razie potrzeby można zmienić technologię api, bez wpływu na front
  • możliwość łatwej modyfikacji wygładu aplikacji, bez ryzyka że coś popsujemy w danych
  • za rok może się okazać, że pojawi się coś lepszego niż React, dzięki oddzieleniu frontu od backendu nic nie stoi na przeszkodzie
  • łatwe stworzenie aplikacji mobilnej w dowolnej technologii dla dowolnego urządzenia (android, ios, windows) , cała komunikacja odbywać się będzie przez API,

Minusy:

  • konieczność poznania 2 technologii
  • … (jak wyjdzie w praniu to dopiszę :) )

Przebudowa repozytorium – zmiany

https://github.com/mfratczak/myfood-generator – wstępne zmiany

  • Docker
    • server backend
    • server frontend
    • server bazodanowy
  • WebClient
    • aplikacja React
  • WebServer
    • aplikacja Flask Api
  • docker-compose.yml (plik konfiguracyjny dockera)

Wstępna hierarchia jak wyżej. Prawdopodobnie się zmieni o elementy CI (Continuous Integration), Testy automatyczne, i kilka innych.

Do testów lokalnych, docker będzie odpalany na dwóch portach.

  • Port 80 -> localhost -> aplikacja web
  • Port 1025 -> localhost:1025 -> api backend

Docelowo jak już projekt zostanie wrzucony na domenę to podział będzie następujący:

  • http://myfood.love – front na porcie 80 (standardowo)
  • http://api.myfood.love – backend na porcie 80 (standardowo)

W kolejnym poście (mam już nadzieję) przygotuje aplikacje front i backend z „hello world”.

 

[04 MyFood] Jeden krok w tył, dwa do przodu …

Intensywny tydzień, brak czasu na pracę przy projekcie. W weekend zasiadłem i co się okazało?

Wcześniejszy post „Stworzenie szablonu HTML” jest ciut nie trafiony :) . W moim projekcie chce użyć React. Myślałem, że użyje normalnego szablonu html, i dodam elementy JS. Okazało się, że to nie takie proste.

Szablon semantic ma oddzielną wersje http://react.semantic-ui.com/, którą „zacząłem” wdrażać. Mogę powiedzieć zacząłem, bo jak faktycznie siadłem do tego to … straciłem czas i chęci, bo nic nie działało jak należy. Nie mogłem porządnie się wyspać bo ciągle myślałem co zrobiłem źle i czemu nie działa.

Z jedną ideą się jednak obudziłem: „Zacznij od podstaw!”

A więc dzisiaj pół dnia straciłem na tutoriale podstaw. Co najlepsze 3h zajeło mi ogarnianie czemu tutorial nie działa jak należy. Przejrzałem 3 różne, porównywałem czemu jeden działa jeden nie. Wspomogłem się stackoverflow.com. Wyciągnąłem wnioski, z którymi podzielę się w kolejnym już poście bardziej technicznym, oraz będę mógł pokazać pierwszy efekt wizualny.

2 dni działań, ponad 10h zabawy, i projekt nie ruszył o krok. 10h zabawy od podstaw, dzięki czemu zaoszczędzę przynajmniej kolejne kilka h w przyszłości.

Jeden wniosek z którym już dzisiaj się podzielę.

Męczysz się z gotowym projektem? Brakuje ci wiedzy? Cofnij się. Zacznij od podstaw jeśli musisz. Przejdź kilka kroków, które pozwolą ci zrozumieć gotowy projekt. Stracisz 2-3 dni na starcie, ale zyskasz wiedzę, która pozwoli ci ukończyć coś szybciej. Jeśli nie szybciej to ukończyć wspanialszy projekt !

[01 MyFood] Geneza projektu, i jego cele

Start Projektu MyFood Generator

Jeśli śledzisz mojego bloga, to wiesz, że startuje w konkursie „Daj się poznać” edycja 2017. Dla tego konkursu wybrałem projekt „MyFood Generator” czyli w skrócie „Generator posiłków”.

Projekt będzie dostępny pod domeną: http://myfood.love

Geneza projektu

Walczę aktualnie z nietolerancją pokarmową, i co miesiąc dostaje pełny jadłospis dla dwóch osób, na 30 dni. Każdy posiłek może posiadać 2 warianty [dla każdej osoby inne ilości].

Przygotowanie listy dań, listy zakupów, oraz następnie gotowanie (5 posiłków) zabiera mnóstwo czasu :) . Samego gotowania nie można usprawnić programistycznie, można za to usprawnić przygotowanie posiłków :).

Cel

  • wrzucenie wszystkich posiłków do systemu (śniadanie, 2 śniadanie, obiad, kolacja, podwieczorek)
    • możliwość przypisania posiłku do diety, grupy, tag’a
  • stworzenie jadłospisu dla x dni, z istniejących dań w systemie
    • użytkownik sam wybiera listę dań
    • użytkownikowi losuje jadłospis (wg kryteriów, wszystkie w systemie)
  • dla każdego jadłospisu stworzenie możliwości generowania listy zakupów
    • pełna lista zakupów dla wybranych dań, lub wybranych dni
    • możliwość zmiany listy zakupów (np posiadamy marchewkę w lodówce, to nie chcemy aby ona była na liście zakupów)
    • generowanie plików w różnych formatach (pdf, txt), możliwość wysłania listy na email
  • wyszukiwarka
    • możliwość wyszukania dania po wybranych składnikach (np. mamy w lodówce 5 składników, i chcemy znaleźć dostępne dania)
    • szukanie po nazwie
    • szukanie po czasie przygotowania posiłku
    • szukanie po rodzaju posiłku
  • opcje socialmedia: dzielenie się posiłkami z innymi użytkownikami systemu, lub udostępnianie postów na fb (itp)
  • kalendarz / pamiętnik posiłków – oznaczanie posiłku (zjedzony, nie zjedzony, itp), możliwosć dodania opisu do dania, zdjęcia, czasu wykonania
  • statystyki i raporty [czas wykonywania posiłku, zjedzone posiłki w miesiącu, zjedzone kalorie, itp]
  • możliwośc wydruku przepisu, jadłospisu, listy zakupów
  • inne (np podpięcie toggl time tracker do mierzenia czasu wykonywania posiłków, …)

Technologie wykorzystywane w projekcie

Na codzień pracuje z PHP i w nim tworze strony i systemy IT. Postanowiłem więc rozpocząć projekt w którym wszystkiego musze nauczyć się prawie od początku :) a więc:

  • backend: python 3(framework flask) w którym napisane będzie api
  • frontend: react (framework js)
  • docker – do odpalenia projektu w izolowanym wirtualnym środowisku, używając jednego polecenia
  • szablon strony napisany przy wykorzystaniu semantic-ui.com (Semantic UI to zestaw komponentów wspomagający tworzenie interfejsu użytkownika)
  • baza danych mysql
  • testy automatyczne
  • zewnętrzna baza składników (? opcja) – użytkownik wpisuje marchewka do dania, i jak jej nie znajduje to pobiera dane z zewn systemu (kalorie, itp)
  • … (wyjdzie w praniu)

Dlaczego python api? Chciałbym w przyszłości stworzyć aplikacje na komórki. Istniejące API pozwoli zrobić to niższym kosztem :) . W czym to napisze, jeszcze nie wiem. Wstępnie będzie to w Electronie -> https://electron.atom.io/

Posty związane z projektem

W regulaminu konkursu, musza pojawiać się dwa posty tygodniowo z tagiem DSP2017

  • minimum raz na tydzień pojawiać się będzie post dotyczący projektu #MyFood
  • drugi post może być powiązany z projektem, ale nie musi

Moim planem jest rozpisanie krok po kroku tworzenia projektu.  Nie będą to jednak szczegółowe posty typu: to skopiuj, tu wklej, tu zrób to i to. Wpisy mają cię nakierować na rozwiązanie istniejącego problemu, rozpisanie działania, linków do bazy wiedzy / tutoriali z których skorzystałem. Przykładowe problemy:

  • postawienie dockera, posiadające skonfigurowane biblioteki python, mysql (itp)
  • stworzenie środowiska dla semantic-ui do stworzenia szablonu projektu (gulp, npm, less)
  • stworzenie testów automatycznych (jestem całkowicie zielony w tym :(  )

I to tyle na starcie :) , sporo pracy przedemną. Nie wiem czy uda mi się skończyć projekt do końca konkursu. Celem jest stworzenie kompleksowo napisanego kodu, którym będę mógł się pochwalić bez wstydu :) . Przy okazji osoby będą mogli skorzystać z postów i wykorzystać części rozwiązań w swoich projektach.


Repozytorium git: https://github.com/mfratczak/myfood-generator – tutaj możesz obejrzeć kody źródłowe, i odpalić projekt na swoim serwerze.

Google Analytics Alternative