DSP17 / Uncategorized

Czas na część techniczną

Dwumiesięczny okres analizy biznesowej na serwerze Cygnus polskiego Ogame’a z 268’791 pkt, 434 miejscem w rankingu i założeniem sojuszu, mam za sobą. Wynikiem był poprzedni, skrócony opis funkcjonalności systemu. Teraz wypada przedstawić technologiczną część projektu.

Co pod maską

Jako programista z 5-letnim doświadczeniem w Javie dla odmiany wybrałem język Java. Oczywiście ze Springiem na pokładzie, a dokładniej naszym ulubionym Spring Bootem. Pod tym wszystkim stoi bezproblemowa i grzeczna baza MongoDB, a za budowanie projektu odpowiada stary dobry Maven. Poprawność działania powyższej ferajny sprawdzam JUnitem IV Wielkim przy niewielkiej pomocy ze strony Mockito.

Pewnie po powyższym akapicie zapytacie czemu NoSQL kiedy akurat tu niemal wypada użyć SQL. Lenistwo. Tak, lenistwo było powodem. Nigdy nie byłem wielkim fanem grzebania w bazach. I w ramach projektu „po godzinach, dla przyjemności” nie chciałem grzebać w czymś czego nie lubię. Tak więc postanowiłem używać jednej z najmniej problematycznych (i nie najuboższych w funkcjonalności) baz jakie znam. Nie ma żąglowania mappingiem, referencjami, scheme’ami i całym tym sh**tem. Chcę zapisać obiekt złożony to zapisuję obiekt złożony. Koniec. Zostało zapisane jako obiekt to moge sobie to podnieść z bazy jako obiekt. Zmienił mi się model, to nie migruje bazy „ALTER TABLE”m, tylko zapisuję jak leci. A wszelkie bardziej złożone operacje joino-podobne jestem w stanie sobie sam oprogramować z pomocą całego Spring Data Mongo i autorskich zapytań. Baza w tym projekcie to tylko worek na dane, a to kodowaniem chcę się bawić!

Co na masce

Nad tym cały czas pracuję, bo mam dużo wątpliwości co do wyboru technologii i… mam małe doświadczenie jako front-dev.

„Kilka” miesięcy temu, kiedy zaczynałem planować ten projekt i powstawały pierwsze kawałki kodu, byłem przekonany o implementacji frontu w Angular 1 z Gulpem w roli pakowaczki – tego używałem w pracy i chciałem to poznać lepiej. Projekt przesunąłem na bok, zająłem się innymi rzeczami i w międzyczasie wyszedł stable release Angular 2. Niedawno przerobiłem sobie Tutorial: Tour of Heroes dla tego frameworka pisząc w TypeScript (szczerze polecam) i budowaniem za pomocą skryptów npm. Następca starego angulara bardzo mi się spodobał, szczególnie przyjemny był nowy dla mnie język – TypeScript, a dokładniej jego „balans między Javą i JS”. Przekonany byłem, że to jest to i… natknąłem się na Vue. Kusi mnie, żeby w nim także chociaż przerobić Getting started, bo później będę miał uczucie, że omija mnie coś ciekawego. Zwłaszcza, że jest to coś świeżego. A instalacja zaleca (bo wymienia jako pierwszy) użycie webpacka, co także zwróciło moją uwagę.

Wybór technologii jest dla mnie dosyć ważny. Niekoniecznie chcę brać coś super-nowoczesnego, bo nie jestem na tyle doświadczony, żeby z braku materiałów samemu zaprojektować całość, ale także nie chcę babrać się w czymś „przestarzałym”. Problemy backendowca, który fullstackiem był ostatnio tylko z przypadku. Czas się ogarnąć.

A co między maską, a silnikiem

Środkiem komunikacji między Frontendem, a Backendem jest stare, standardowe, ale nie do końca pełne REST API. Z racji tego, że obecnie front aplikacji jest tylko w mojej mglistej wyobraźni – do testowania organoleptycznego używam aplikacji Postman. Uważałem, że to niemal tak standardowe narzędzie jak SOAP-UI do testowania WebService’ów SOAP’owych, ale zaskakująco dużo kolegów nie wiedziało o nim. Tak więc proszę – oto informacja o fajnym narzędziu dla Was – mniej doświadczonych lub doświadczonych inaczej kolegów po fachu.

Spis endpointów REST API można zaimportować z mojego pliku postman.json, ale jest ich na tyle niewiele, że pozwolę sobie je tu pokrótce opisać (patrz: koniec wpisu).

Stacja kontroli pojazdów

Testowanie całej maszynerii pozostawiam JUnitowi 4 i mockerowi Mockito. Pomimo standardowych libek moje podejscie w tym projekcie nie będzie dla mnie standardowe. Uwaga uwaga! Próbuję w TDD, a nie umiem w TDD! Jak dotąd wychodzi mi to średnio poprawnie. Piszę mnóstwo opisowych wydmuszek testów, część z nich implementuje, później dorabiam implementację funkcjonalności i wszystko na bierząco refaktoryzuje. Napewno to nie są te słynne podręcznikowe małe kroczki, bo zauważyłem, że takie podejście jest niezwykle frustrujące. Często i tak po skończonej implementacji dopisuje trochę testów na dziko, bo znajdę jakiś szczególny przypadek lub zauważę, że nie testuję wartości granicznych itp. Jak na razie kod ma 89% pokrycie! …przy 1500 linii kodu.

REST API

Logowanie

Logowanie użytkownika do systemu
url: 
/login
metoda: POST
input: formularz z polami username i password
output: status 200 lub 401

Wylogowanie uzytkownika z systemu
url: 
/logout
metoda: GET
output: status 200

Gracze

Pobierz zalogowanego gracza
url: 
/players/current
metoda: GET
output: status 200 i obiekt lub 401 jeśli niezalogowany

Stwórz nowego gracza
url: 
/players
metoda: POST
input:

output: status 200 i obiekt lub 400 jeśli wystąpił błąd walidacji

Zmień hasło zalogowanego gracza
url: 
/players
metoda: PUT
input:

output: status 200 i obiekt lub 401 jeśli niezalogowany

Planety

Pobierz wszystkie planety gracza
url: 
/planets
metoda: GET
output: status 200 i obiekt lub 401 jeśli niezalogowany

Pobierz planetę gracza po id
url: 
/planets/{id}
metoda: GET
output: status 200 i obiekt, 404 jeśli nie istnieje/nalezy do innego gracza lub 401 jeśli niezalogowany

7 thoughts on “Czas na część techniczną

  1. Czekam na więcej, udało Ci się zachęcić mnie do Angulara 2. Właśnie przerabiam Tour of Heroes 🙂

    1. Jak już przerobisz podstawowy ToH, to zobacz sobie na http://blog.scottlogic.com/2015/12/24/creating-an-angular-2-build.html 😀 ja do tego się powoli zabieram, bo podstawowa wersja ToH nie daje zbytnio fajnie zorganizowanego builda, ale za to daje niezłe pojęcie o samym ng2. To jest jakby kontynuacja/rozszerzenie.
      Mam nadzieje, że ten wpis nie jest jakoś strasznie przestarzały, bo dopiero teraz zauwazyłem że to sprzed ponad roku 😉

  2. Fajny projekt, swego czasu sam męczyłem się z napisaniem klonu polan.

    Od siebie polecę narzędzie swagger, jest to fajna zamiana dla postmana. Działą na tej zasadzie że wpinasz go do projektu i skanuje on wszystkie metody wystawione w API i generuje na podstawie tego dokumentację w JSON, a swagger UI generuje stronę z przeglądem tej dokumentacji wraz z możliwością wysyłania zapytań. Wygląda to tak http://gielda.dev.silver.sggw.pl/swagger , a z dokumentacji json można też generować kod do aplikacji np androidowej.

    1. Używałem kiedyś swaggera w projekcie w pracy i wtedy to było tak słabo zorganizowane, że strasznie się zniechęciłem do niego. Na slacku devsPL za to dużo ludzi go bardzo poleca i mam już w planach dołączenie go do swojego projektu 😉

      1. Polecam swaggera, co prawda jakoś mocno z niego nie korzystałem, ale widziałem efekt jego pracy w jednym z projektów który był strasznie porypany jeżeli chodzi o API.

  3. Hej!
    Co przemawia bardziej za użyciem springa, zamiast zwykłej EE6/7 EJB/CDI ? Jakie są plusy i minusy Springa? Wybrałeś go z konkretnych powodów, czy tylko dlatego, że zawodowo (tak tylko zakładam) w nim programujesz i czujesz się pewnie ?

    1. od lat kodzę w Springu i dla mnie to naturalne środowisko. JEE poznałem jak nie był jeszcze w wersji 7, więc odstraszyło mnie grzebanie w xmlach kiedy Spring już wprowadzał adnotacje. Czemu Spring – bo backend chciałem robić najmnijeszą linią oporu a skupić sięna tym, czego nie znam, czyli frontend. Plusy i Minusy? Minus taki, że Spring jest raczej ciężki i nie nadaje się do budowania microservice’ów, plus taki, że napisanie podstawowej działającej appki webowej to kwestia minut (Spring Boot).

Leave a Reply

Your email address will not be published. Required fields are marked *