Ściana…

 

Przerwa na zdobycie wiedzy

Natrafiłem na ścianę w postaci nieznajomości Angulara i Spring Security, dlatego dzisiaj krótko. Chcąc nie chcąc bezpieczne połączenie wraz z autoryzacją w dzisiejszych czasach to must have. Bez tego nie ma mowy nawet o zbliżeniu się do profesjonalnego programowania.

Obecnie przerabiam tutorial Spring Security and Angular JS, za mną już  tutorial z samego Angulara. Kolejnym krokiem będzie przepisanie części JavaScriptu do Typescriptu, a dokładniej AngularJS do Angulara.

Przede mną jeszcze długa droga ale jestem dobrej myśli.  Przynajmniej
„Wiem, że nic nie wiem”, a to całkiem dużo.

TL;DR

Nie ma, wpis nie jest przecież długi 🙂

 

Reklamy

O strukturze projektu słów kilka

TL;DR?

  • .gitignore i wiedza jak co działa w projekcie znacznie usprawnia pracę, nie tylko twórcy ale też innych osobą, które być może również będą rozwijać projekt
  • dobrze rozplanowana struktura projektu pomaga w jego rozbudowie
  • dobrze skonfigurowane środowisko przyspiesza tworzenie kodu
  • początki są trudne, dlatego najlepiej zacząć od poznania chociaż szczątkowej teorii aby uniknąć podstawowych błędów

Struktura projektu, dlaczego to takie ważne?

Dobra struktura projektu znacząco ułatwia sprawne poruszanie się po projekcie, a także jego rozwój. Projekt powinien być czysty, pozbawiony niepotrzebnych plików. Zmorą początkujących, jest ogrom plików tworzonych przy konfiguracji lub podczas samego budowania aplikacji. Wiele osób o pliku .gitignore często jest ignorowany, przez co mnóstwo plików niezwiązanych bezpośrednio z projektem lub będących plikami tymczasowymi wygenerowanymi przez narzędzia, ląduje na repozytorium, przez co sam projekt staje się bardzo nieczytelny, a jego rozmiar znacznie przewyższa użyteczny kod. Z własnego doświadczenia wiem, że osoby, które dopiero poznają taki projekt, często mają przez to mnóstwo problemów, zaczynając od otrzymywania wiadomości o błędnej konfiguracji IDE przy otwieraniu projektu, spowodowanych wczytaniem cudzych plików konfiguracyjnych, a kończąc na problemach z commtem, w którego skład domyślnie wchodzi znacznie więcej plików, niż zostało bezpośrednio zmodyfikowanych. Dlatego uważam, że należy najpierw zapoznać się z teorią lub jak kto woli, dokumentacją używanych narzędzi, zanim przystąpi się do działania. Dlatego też, przy nauce dowolnego języka programowania, warto zacząć od „Hello Worlda” kompilowanego w konsoli, zamiast uruchamiać do tego celu wielkie IDE.

Trudne początki

Głównym problemem, zaraz po wymyśleniu tego, co chce się zrobić, jest rozpoczęcie tej czynności. Ile to razy mówimy sobie „od jutra zacznę ćwiczyć”, „od jutra przechodzę na dietę”. Tak samo w programowaniu, najgorzej stworzyć projekt i skonfigurować środowisko, tak aby można było bez problemów pracować i rozwijać projekt. W moim przypadku, musiałem najpierw przekopać się przez tutoriale i dokumentację, żeby dowiedzieć się jak połączyć Jave i Springa z Angularem. Oprócz samej funkcjonalności. moim celem było również uzyskanie środowiska gotowego do działania za pomocą jednego kliknięcia.

Give me six hours to chop down a tree
and I will spend the first four sharpening the axe.

Abraham Lincoln

Parafrazując powyższy cytat: daj mi siedem dni na stworzenie projektu, a pierwsze pięć będę googlować nieznane mi frazy, aby zdobyć potrzebną mi wiedzę. W tym przypadku bardzo pomocny okazał się ten blog.

Przechodząc do sedna, projekt podzieliłem obecnie na dwie warstwy:

  • Frontend – składający się z Angulara i Nodejs
  • Backend – złożony z Javy i Springa

Do połączenia tych dwóch warstw, na razie od strony samego budowania i deployu, z pomocą przychodzi Maven oraz plugin frontend-maven-plugin, który po skonfigurowaniu zajmuje się całym łańcuchem budowania związanym z warstwą frontendu – rozpoczynając od ściągnięcia i instalacji Nodejs i npm , a kończąc na zbudowaniu projektu Angulara.

Uruchomienie samego backendu natomiast sprowadza się już tylko do wywołania polecenia mvn spring-boot:run

Z tak skonfigurowanym środowiskiem jestem już w stanie zacząć na poważnie rozwijać projekt.

 

 

Hello Daj Się Poznać 2017!

Oto i on, pierwszy post, rozpoczynający przygodę z
Daj Się Poznać 2017!

a journey of a thousand miles begins with a single step

Czym jest Devs&Deadlines ?

Z założenia ma być to system do zarządzania projektami zgodnymi z metodyką zwinną z użyciem gamifikacji. Jak nietrudno zauważyć, sama nazwa projektu nawiązuje do serii Dungeons&Dragons, gdyż w tej konwencji chcę stworzyć platformę do zarządzania, a w przyszłości, być może cały system ERP bazujący na tej konwencji.

Dlaczego gamifikacja?

Jako zapalony gracz, który uwielbia gry RPG, uważam, że jest to dobry sposób na zwiększenie motywacji do pracy oraz stworzenie dodatkowych powodów do pracy jako jedna drużyna. W końcu po kilku iteracjach i wydanych wersjach, każdy może wypalić się i stracić zapał do pracy. Szczególnie gdy bugów przybywa, klient jest niezadowolony, a Product Owner z dnia na dzień ustala kolejny deadline. Sytuację tego typu, w grach stanowią wyzwanie, w rzeczywistości często są powodem zmiany pracy. Jest to próba wykrzesania dodatkowych pokładów motywacji wśród developerów i umocnienia poczucia jedności w zespole.

Dodatkowym powodem do zastosowania gamifikacji jest wprowadzenie nowych możliwości  retrospekcji – podsumowania iteracji. Ciekawszym wydaje się podsumowanie bazujące na tym kto zdobył ile doświadczenia, jaki boss stanowił największy problem lub być może, który nas pokonał i jak zamierzamy sobie z nim poradzić w następnej przygodzie (Sprincie) niż, nic nie wnoszące, monotonne retrospektywy znudzonego
Scrum Mastera.

Technologie?

Obecnie wybrałem Jave, Springa i Angular jako podstawy Stacku technologicznego.

  • Java – język, w którym ze względu na codzienną pracę czuję się najlepiej (jednak głównie w wersji SE więc może w końcu czas dokształcić się z Javy EE).
  • Spring – najpopularniejszy z frameworków Javy, którego obecnie znam tylko podstawy.
  • Angular – frontend, moja wiedza w tym zakresie jest obecnie praktycznie zerowa, ale mam nadzieję, że szybko to zmienię.

Dodatkowe technologie na pewno pojawią się wraz z pierwszymi problemami, np wybór bazy danych czy narzędzia do budowania projektu ale to temat na następny post.