Skip to main content

e24Cloud Struktura skalowalnego serwisu WWW

Marcin Frątczak 1 komentarz

Przy okazji konkursu chmurowisko (https://chmurowisko.pl/e/) postanowiłem stworzyć przykładowy serwis WWW na chmurze e24cloud.com.

Tworząc złożone serwisy WWW myślimy, że nasz projekt będzie stać zawsze. Nikt ani nic nam nie zagraża. Okazuje się, że serwis może bardzo szybko zniknąć z internetu, i ciężko szybko go przywrócić do działania.

Powody, kiedy serwis może zniknąć z sieci:

  • atak na serwer (np DDOS)
  • nagły wzrost liczby użytkowników (np z 1000 do 100 000 dziennie)
  • złe wdrożenie poprawek na serwerze (czynnik ludzki)
  • awaria serwera
    • administrator coś nabroił, lub…
    • w serwerze popsuły się elementy, które są ważne
  • awaria całego regionu (całej firmy hostingowej)
    • serwer może działać, ale błąd w serwerowni nie pozwala dostać się do niego dostać
    • problemy z łączem do serwerowni (ile to się razy zdarzało, że pan w koparce przerwał światłowód)

Powyżej znajduje się kilka propozycji co może się stać. Powodów, może być mnóstwo. Jak zwiększyć szanse, że nasza strona będzie widoczna zawsze? Czytaj więcej

[xx MyFood] Koniec DSP … a zarazem początek…

Marcin Frątczak 1 komentarz

Od ostatniego postu minęło 2,5 miesiąca. Nie udało mi się zrealizować projektu.

Czuje smutek z tego powodu.

Każdemu brakuje czasu, brakło i mi.Okazało się, że projekt jest bardzo ambitny, gdzie czekała mnie spora dawka nauki. Pojawiły się inne priorytety i cele.

Ale nie martwcie się :) , projekt nie będzie zarzucony. Planuje go skończyć w przyszłości. Myślę, że zostanie dalej jako Open Source.

Konkurs DSP się skończył. Zapraszam na listę finalistów http://uczestnicy.dajsiepoznac.pl/finalisci

Czy był to stracony czas?

Nie. Od kilku lat myślałem nad blogiem, zawsze się bałem go założyć. Okazało się, że to nic trudnego :) i zawsze jest co napisać.

Znalazłem nowe cele, i priorytety w życiu. Powoli przeorganizowuje swoje życie.

Same plusy.

[06 MyFood] Front hierarchia

Marcin Frątczak Zostaw komentarz

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 !

 

 

Docker, kilka wskazówek

Marcin Frątczak Zostaw komentarz

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 !

 

 

[MyFood] Docker – api, web, loadbalancing, ssl (darmowy),mysql – pełny config

Marcin Frątczak 1 komentarz

Nadszedł czas wdrożenia środowiska developerskiego, oraz środowiska produkcyjnego. Od początku moim planem było wykorzystanie dockera. Dzięki niemu łatwo wszystko postawić na nowym serwerze. Najtrudniejsze jak zwykle było stworzenie pierwszy raz kompleksowej konfiguracji, z wszystkimi elementami, które są potrzebne w każdym projekcie.

Co to docker przeczytać możesz tutaj: 1, 2, 3

Spis wszystkich kontenerów

  • serwer api
  • serwer api2 (drugi serwer do testu loadbalancingu – normalnie w swoim projekcie nie używam, dlatego jest to kopiuj / wklej api)
  • serwer web
  • baza danych (mysql)
  • phpmyadmin (tylko dla dev)
  • haproxy
  • letsencrypt (odnawiany 90 dniowy certyfikat SSL)

Dlaczego tyle kontenerów i w czym problem

Zasadą w świecie dockera jest „1 kontener = 1 zadanie” . A więc nie powinno w jednym kontenerze instalować się kilku funkcjonalności: serwer www, skrypty (np php), baza danych. Bardzo ciężko pilnować gdy coś się popsuje , oraz ciężko wgrać aktualizacje do systemu. Dlatego wszystko wydzielamy do kontenerów, która lista jest powyżej.

Problem:

Nie można do kilku kontenerów przydzielić tego samego portu.

Czyli nie można jak niżej:

  • web – nasłuchuje na porcie 80
  • api – nasłuchuje na porcie 80

Przy próbie odpalenia pojawi się błąd:

Co oznacza tyle że port już jest używany i nie można odpalić kontenera. Jest to oczywiście logiczne, bo jak wchodzimy np na localhost, to system by nie wiedział na który kontener przekierować ruch.

Kolejny problem to domeny. Konfiguracja dockera nie używa takiego pojęcia jak domena / subdomena. Każdy kontener sam powinien rozpoznawać domenę, i serwować odpowiednie dane.

W konfiguracji dockera nie możemy podzielić ruchu dla danej domeny i dla danego portu.

Jak to zrobić?

Musimy sami to obsłużyć prz pomocy serwera proxy. Użytkownik wchodzi na stronę w danej domenie, to serwer proxy wyświetla mu dane z odpowiedniego kontenera dockera.

Serwer proxy rozpoznaje domene, oraz port, i odpowiednio serwuje dane.

Rozwiązań jest kilka, np:

  • na serwerze (host) instalujemy proxy i w konfiguracji ustawiamy i przekierowujemy domenę na dany kontener (1)
  • wykorzystujemy tylko kontenery dockerowe, i serwer proxy również jest w nim (2)

Wybieram rozwiązanie 2. – dobrze jest mieć porządek :)

Serwer Proxy – HAProxy – Load Balancing – SSL

Postawienie proxy, pozwala nam zainstalować również certyfikaty SSL, i je odpowiednio skonfigurować. Nie trzeba tego robić w każdym kontenerze. Wystarczy w jednym :)

Wykorzystamy tutaj certyfikaty „Let’s encrypt” https://letsencrypt.org/ – pozwala nam to za DARMO posiadać na swojej domenie ssl.

Certyfikat jest ważny 90 dni. Całe generowanie i pobieranie jest automatyczne, więc nie musimy się o to martwić.  PEŁNA AUTOMATYKA !

Serwer proxy również umożliwia wykorzystanie loadbalancingu. Co to jest? Jeśli ustawimy dla danego adresu np: https://api.myfood.love/ dwa kontenery. To proxy dzieli ruch po połowie i wysyła go to kontenera. Jak wejdziesz na testowy serwer api to po odświeżeniu strony będą się na przemiennie pojawiać informacje:

Ip:xxx.xxx.xxx.xxx Host: 8ca086de8527

oraz

Ip: xxx.xxx.xxx.xxx Host: cccc89c4b35c

Dla przykładu wyświetlam ip oraz host. Host się zmienia w zależności od wybranego kontenera.

Po co load balancing?

Jeśli strona posiada duży ruch i maszyna nie wytrzymuje, to można dodać kolejną maszynę i obsłużyć dwa razy większy ruch. Klient nawet nie zauważy że ruch idzie z dwóch maszyn.

Konfiguracja środowiska – docker-compose.yml

Wszystkie obrazy jakie wykorzystuje znajdują się w pliku docker-compose.yml. Dzięki temu wystarczy odpalić jedno polecenie (docker-compose up -d) i dzieje się magia.

Oddzielnie stworze post z poleceniami, trickami itp, więc tutaj tylko suche fakty na temat pliku konfiguracyjnego :)

Aktualnie cały plik konfiguracyjny jest w wersji „3.1”. Oznacz to, że wersja dockera jaka powinna być to min. 1.13, a wersja docker-compose 1.11

Pełny plik konfiguracyjny (api z load balancingiem)

Pełne wyjaśnienie – hierarchia plików i katalogów https://github.com/mfratczak/myfood-generator

– api.myfood.love – load balancing z api i api2

  • build – budowanie kontenera gdzie plik Dockerfile znajduje się w podkatalogu
    • context: Docker/python – katalog kontenera (Docker/python)
    • dockerfile: Dockerfile – nazwa pliku z konfiguracją kontenera, można np zmienic na Dockerfile-dev i będą ustawienia developerskie (jeśli taki plik istnieje)
  • environment: – zmienne systemowe przekazywane do środka kontenera
    • FORCE_SSL=yes – zmienna wykorzystywana w kontenerze haproxy – bardzo ważna zmienna dla haproxy i certyfikatu SSL
    • VIRTUAL_HOST=xxx – spis hostów które kierować mają na dany kontener, można podać kilka  – bardzo ważna zmienna dla haproxy i certyfikatu SSL
  • volumes: – mapowanie katalogów, aby projekt znajdował się poza kontenerem. Dzięki temu można usunąć całkowicie kontenery i utworzyć jeszcze raz a dane zostają
    • ./WebServer:/app – w katalogu WebServer znajduje się cały projekt systemu Api
  • links: – połączenie między kontenerami, kontener API ma dostęp do kontenera MYSQŁ, gdzie znajduje się baza danych
  • command: python server.py – możliwość zadeklarowania polecenia z jakim ma się uruchomić kontener, tutaj odpala serwer pythona, można dla wersji developerskiej zrobić np: python server-dev.py, czyli odpalić serwer pythona z ustawieniami pełnego logowania itp
  • restart: always – deklaracja co ma się stać jak kontener padnie, lub polecenie (python server.py) spowoduje błąd, czyli szybki restart maszyny
  • network_mode: „bridge” – wybór podsieci

Drobne wyjaśnienie odnośnie network_mode. Normalnie wszystkie kontenery z danego katalogu (z jednego pliku dockerfile) znajdują się w osobnej podsieci. Okazuje się, że serwer proxy działa tylko w głównej podsieci o nazwie „bridge”, dlatego wszystkie kontenery są dodane do niej.

Drugie drobne wyjaśnienie to FORCE_SSL. Dla testów lokalnych linijkę tą mam wyłączoną, ponieważ dla lokalnych domen (localhost, itp) nie można utworzyć certyfikatu

Ustawienie: VIRTUAL_HOST w api i w api2 na te same domeny powoduje, że proxy stosuje load balancing i dzieli ruch między te dwa kontenery.

– myfood.love – serwer web

W pliku konfiguracyjnym powyżej, tworzę również serwer pythona do testów. Jednak różnicą jest zmiana w VIRTUAL_HOST, co powoduje, że ruch tutaj jest obsługiwany tylko przez jeden kontener.

W przyszłości tutaj będzie zmiana pliku konfiguracyjnego na ten z katalogu Docker/npm/Dockerfile (teraz jest tylko szybka kopia aby sprawdzić działanie haproxy)

– mysql oraz phpmyadmin

  • image: sameersbn/mysql:latest – popularny gotowy obraz mysql (posiadają również postgresql itp)
  • volumes: – ./Data/database:/var/lib/mysql – cała baza została wydzielona do podkatalogu database. Dzięki temu można wyłaczać i włączać kontener bazodanowy bez utraty danych
  • environment – zmienne z danymi do utworzenia pustej bazy

oraz

  • image: phpmyadmin/phpmyadmin – gotowy obraz z phpmyadminem
  • ports: – „9999:80” – kontener dostępny np pod localhost:9999 lokalnie, lub myfood.love:9999 w sieci, w wersji produkcyjnej dostęp do phpmyadmina powinien być WYŁĄCZONY!!!
  • environment: PMA_HOST: mysql – zmienna wskazuje na kontener w której jest baza

Małe wyjaśnienie: Przy tworzeniu bazy (pierwsze odpalenie kontenera mysql) dane są zapisane w katalogu Data/database. Tworzona jest czysta baza o podanej nazwie, loginie i haśle. Restart / Wyłączenie / Usunięcie i ponowne utworzenie kontenera nie powoduje utraty danych bazy. Aby usunąć dane, należy opróżnić katalog. Po opróżnieniu katalogu, ponowne uruchomienie kontenera bazodanowego powoduje utworzenie czystej bazy.

– letsencrypt

  • image: interaction/letsencrypt:master – gotowy obraz
  • environment:
    • DOMAINS=api.myfood.love myfood.love – domeny które powinny mieć ssl, dla nich jest generowany certyfikat, nie mogą to być domeny lokalne lub zmapowane w pliku host systemu
    • [email protected] – email który jest zawarty w certyfikacie, powinien to być istniejący adres email
  • expose: – „80” – port na którym nasłuchuje kontener
  • volumes:
    • ./Data/letsencrypt:/etc/letsencrypt – zmapowany katalog z wygenerowanymi certyfikatami
    • ./Logs/letsencrypt:/var/log/letsencrypt – zmapowany katalog gdzie można przejrzeć logi

– haproxy – serwer proxy przez który przechodzi cały ruch z portu 80 i 443 (każda domena i subdomena)

  • image: interaction/haproxy:master
  • links: – kontener musi być podłączony do letsencrypt oraz do wszystkich kontenerów na który ma być kierowany ruch
  • depends_on: – polecenie to sprawia, że haproxy odpalane jest na końcu, oraz że zależy jego działanie od innych kontenerów
  • ports: – „80:80” – „443:443” – cały ruch przechodzi przez ten kontener, potrzebne są do obsługi dwa porty 80 (zwykły ruch http) oraz 443 (ruch https)
  • volumes: – ./Data/letsencrypt:/etc/letsencrypt – haproxy oraz letsencrypt muszą dzielić ten sam katalog, z wygenerowanymi certyfikatami

Kilka spraw:

Ważną kwestią aby haproxy działał z SSL, to współdzielenie katalogu letsencrypt. Kontener letsencrypt przy odpaleniu oraz co 24h sprawdza certyfikat i generuje nową wersje. Gdy haproxy wykryje że pliki w katalogu się zmieniły, uaktualnia certyfikaty u siebie. Nigdy więc nie wygaśnie certyfikat SSL ponieważ jest on generowany co 24h

Dodatkowo można wydzielić haproxy razem z letsencrypt z pliku konfiguracyjnego dockerfile, i utworzyć 2 kontenery globalne.

Dzięki temu, w przyszłości można utworzyć całkiem nowe domeny, z nowymi kontenerami, i dodać ich obsługę w haproxy. Ale przykład podam następnym razem.

Koniec

Jeśli dotarłeś do końca, to podziwiam, i dziękuję. Jeśli uważasz, że można to rozpisać łatwiej, zostaw komentarz, na pewno zaktualizuje w przyszłości tą rozpiskę.

 

Ważne linki:

  • https://github.com/docker/dockercloud-haproxy – czysty haproxy bez SSL (przykład docker-compose >>)
  • https://github.com/ixc/letsencrypt-dockercloud-haproxy – użyty obraz haproxy z SSL ‚let’s encrypt
  • https://letsencrypt.org/ – darmowy certyfikat SSL
  • https://docs.docker.com/compose/compose-file/#dockerfile – opis dockerfile u źródeł

 

Systematyczność, metodyczność, efektywność

Marcin Frątczak Zostaw komentarz

Dzisiaj poruszę kilka spraw na temat codziennej pracy, ale nie tylko. W internecie,  w pracy, w domu, słyszycie pewnie często „weź się za siebie”, „zorganizuj sobie czas” itp.

Niby to łatwe… pełno w internecie kursów, szkoleń, youtubów o tym. Normalnie cały świat powinien być zorganizowany i efektywny :)

Nikt jednak nie wziął pod uwagę lenistwa, oraz jak ja to nazywam „nie dorosłem do tego” lub „to nie był mój czas„.

Wiele osobom nie potrzeba tych wszystkich rzeczy. Jakoś udaje im się prześlizgnąć przez życie.

Mi także się udaje.

Udaje mi się, ale to jest męczące :) . Siedzenie przez cały dzień przy komputerze, kiedy masz wrażenie że życie ucieka ci przez palce. Mówisz sobie to już ostatni raz, zmienisz to. I tak setki razy.

Jeśli chcesz zmiany to się nie poddawaj

Moim problemem jest to, że znam teorie, dużo teorii. Ale na mnie nie działa (nie działała). Nawet mój brat, który zajmuje się szkoleniem ludzi z efektywności (polecam: http://projektantczasu.pl) powiedział, że nie zmusi ludzi do zmiany jeśli sami tego nie chcą. W tamtym momencie nie chciałem zmian (wtedy o tym nie wiedziałem), a brat nie mógł nic zrobić nie powodując wielkiej kłótni itp. Łatwiej pomóc obcej osobie niż rodzinie.

Dalej mam problem z efektywnością, ale pracuje nad tym. Nad chodzeniem spać o północy pracuje całe życie. Nawet w podstawówce chodziłem spać koło północy. Aktualnie rozbudzam się o 22.00 i jestem pełni sił i energii.

Od roku postanowiłem zmienić swoje życie. Tak na poważnie. Nadszedł mój czas zmian.

Prawie cały rok mi zajął, aż zaczęły być malutkie efekty widoczne. Jestem na początku drogi. Bez zmian nie dołączył bym do DSP, nie poznawał nowych technologii, nie założył bloga. Aktualnie mam kolejne podejście do stworzenia listy zadań tygodniowych, miesięcznych. Notowania i uporządkowania wszystkich materiałów, aby lepiej się żyło :) . Ograniczenia rozpraszaczy. Trzymanie porządku.

Więc jeśli ty, mój czytelniku, masz z tym problem, nie poddawaj się!!! Podziel się swoją opinią w komentarzu. Jak walczysz!

Tak jak mam problem z efektywnością czasu :) tak nie mam problem z:

Systematycznością, metodycznością

Ludzie dzielą umysł na humanistyczny, i matematyczny. Pewnie jest kilka innych podziałów mniej popularnych. Mój umysł to umysł analityka (?) pragmatyka . Jednym słowem podchodzę do działań metodycznie, oraz praktycznie.

np. popsuła się pralka? Mój umysł już ma plan działania w ciągu minuty.

  • wezwać serwisanta
  • potrzeba kupić nową pralkę?
    • przejrzenie top testów pralek,
    • wybór pośrodku między ekonomią / praktyką / a ilością miejsca w łazience (wielkość mikro),

np. projekt systemu – w ciągu kilku minut mam cały plan działania w głowie :), który

  • rozpisuje w notatkach, od pomysłów realnych do nie realnych,
  • przygotowuje plan działania,
  • jak projekt ruszy to co tydzień / dwa sprawdzanie czy jest realizowany w dobrym kierunku, i ewentualna korekta kierunku

np. testowanie systemu

  • rozpisanie wszystkich scenariuszy co trzeba przetestować,
  • co można popsuć,
  • jak inne osoby myślą,

 

Myślałem, że każdy tak ma :) , jak nie każdy to przynajmniej osoba powiązana z IT. Jak nie każdy z IT to programiści… okazuje się że jednak nie.

a więc:

Chcesz zostać dobrym programistą?

  • działaj metodycznie, rozkładaj wszystko na części pierwsze
  • działaj systematycznie
    • przeznacz dany dzień tygodnia na stałe działania
    • przeglądaj rzeczy do zrobienia, przygotowuj plan działania (min. raz na tydzień)
    • co x okres czasu rób przegląd narzędzi jakich używasz. Może uda się je poznać lepiej / udoskonalić / zamienić na coś lepszego.
      • (ja co 1-2 miesiące staram się wyeliminować elementy, które systematycznie mnie denerwują)
  • pracuj nad swoim zarządzaniem czasu.
  • pracuj nad zarządzaniem zadaniami

I to tyle koniec złotych myśli. Łatwe to nie jest :) , ale przyjemność z życia każdego dnia jest większa.

 

 

 

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

Marcin Frątczak Zostaw komentarz

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 …

Marcin Frątczak Zostaw komentarz

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 !

W końcu wprowadzanie zmian…

Marcin Frątczak 1 komentarz

Zmiany…

Co jakiś czas trzeba wprowadzać zmiany w życiu. Czasem idzie to automatycznie, nieświadomie, bezboleśnie. A czasem nie idzie wcale.

Czas kilku lat przestoju, braku weny, chęci zmian zaczyna topnieć. Startuje w konkursie Dsp2017, ulepszam małymi krokami swoją produktywność, uczę się robić zdjęcia :) . Wyrzucam zagłuszacze życia.

Nie idzie łatwo :) ale powoli i sukcesywnie. Na tapetę wróciło porządne zarządzanie zadaniami (porządny podział projektów firmowych, życiowych itp), porządkowanie poczty :) (inbox 0 maili przede mną) . Kolejna próba :) ale tym razem widzę światełko w tunelu…

 

[03 MyFood] Stworzenie szablonu HTML

Marcin Frątczak Zostaw komentarz

Od czego zacząć jak niczego nie ma

Wpis powiązany z projektem MyFood. Szczegóły tutaj »
  • Stworzenie repozytorium [zrobione] – https://github.com/mfratczak/myfood-generator
  • Stworzenie szablonu szablonu html [w trakcie]
  • Wgranie aktualnej wersji projektu na domenę [wymyślam nazwę domeny, masz propozycje? pisz!]

Github

Przy tworzeniu nowego repozytorium, github automatyzuje tworzenie pliku z licencją (wybrałem licencje MIT). Drugą rzeczą ułatwiającą życie jest utworzenie automatycznie pliku .gitignore na podstawie wybranej technologii projektu. Co daje ten plik?

Git sprawdza plik .gitignore, i przy kolejnym pushu, ignoruje pliki nie powiązane z projektem, lub pliki które są generowane automatycznie (cache, kompilacje itp).

Dzięki temu nie wysyłamy do repo zbędnych plików, oraz trzymamy porządek.

Czytaj więcej

Google Analytics Alternative