Hackathon: Node Knockout #7 (2017)

Nie ma to jak zacząć rok od postu, który miał się ukazać w zeszłym roku! Przepraszam za to, jednak coś czuję, że mało kto będzie miał mi za złe, bo najważniejsze jest to, że w końcu jest kolejny wpis!

W listopadzie zeszłego roku brałem udział w hackathonie. Jak możecie się domyśleć, nazwa tego wydarzenia to “Node Knockout 2017”.

Jak dobrze wicie nie jest to mój pierwszy hackathon w życiu. Poniżej lista artykułów jakie napisałem na temat poprzednich wydarzeń tego typu:

• Static Showdown #2 (2015)
• Node Knockout #5 (2015)
• Node Knockout #5 (2016)

Pomysł

Tym razem nie była to gra… Już mam dość pisania gier. W sumie ostatnie hackathony kojarzyły mi się już tylko z tworzeniem gier. A ja przecież nie lubię grać w gry!

Tym razem chciałem zrobić coś co mi się przyda. Wpadłem na pomysł, aby stworzyć aplikację, która rozwiąże wiele problemów w społeczności WarsawJS.

Moim pomysłem była aplikacja do wypełniania (oraz ewentualnie tworzenia) quizów. Dzięki temu mógłbym udostępnić quiz na meetupie albo workshopie i wybrać osobę, która otrzyma od sponsorów / partnerów jakiś podarunek, np. bilet na konferencję. Zawsze mamy z tym problem aby kogoś obdarować, no bo jakimi kryteriami mamy się kierować w wyborze takiej osoby, aby było sprawiedliwie?

No właśnie.

Aplikacja “Milva” 🚀

Dzięki Kasi (mojej TŻ-tce) miałem nazwę do aplikacji. “Milva” tak nazwałem projekt. Prawdopodobnie to jakaś postać z Wiedźmina, ale nie mogę potwierdzić, że tak faktycznie jest ponieważ ani nie czytałem książki, ani nie grałem w tą grę.

Na hacakthony zawsze (prawie zawsze) wybieram stack technologiczny, którego jeszcze nie znam, aby nauczyć się nowych bibliotek / frameworków / wzorców. Tym razem postanowiłem wybrać Vue.js jako bibliotekę / framework do tworzenia aplikacji. Oczywiści samo Vue.js nie wystarczyło, musiałem również wykorzystać Vuex oraz vue-router.

Nie ma sensu opisywać aplikacji. Najlepiej będzie zobaczyć co udało mi się zrobić w te 48 godzin (efektywnie 35 godzin - musiałem trochę pospać).

Link do aplikacji: milva.herokuapp.com

Btw. jeśli interesuje Cię opis projektu (po angielsku) jaki przygotowałem, aby oddać aplikację do oceny to zajrzyj tutaj: dumplings.2017.nodeknockout.com

Hackathon Wnioski

Chciałbym przedstawić Ci jakie wyciągnąłem wnioski z mojego przygotowania do tego wydarzenia oraz co mocno pokrzyżowało moje plany szybkiego zakończenia projektu.

1. Wymyślenie celu projektu przed wydarzeniem

   Poświęciłem 2 pierwsze godziny aby wymyślić projekt. Zamiast pisać kod, to ja biłem się z myślami co by tutaj stworzyć.

   Porada nr 1

   Poświęć dowolną ilość czasu na wymyślenie projektu przed wydarzeniem.

2. Wybór technologii przed wydarzeniem

   Podobnie co wyżej. Nie wiedziałem jeszcze co wykorzystam do zrobienia tej aplikacji. Miałem wiele dróg, ale wybrałem Vue.js m.in. z tego powodu, że tydzień później byłem trenerem podczas warsztatów z tej technologii w ramach WarsawJS Workshop.

   Porada nr 2

   Taka sama jak wyżej. Przed wydarzeniem należy wybrać technologię.

3. Przetestowanie deploymentu wybranej technologii przed wydarzeniem

   Tutaj był jakiś dramat. Niby wszystko proste i Heroku to najlepsze miejsce na deployment, ale nie szło. I to dość mocno. 4 godziny spędziłem na ogarnięcie tematu w jaki sposób mogę opublikować aplikację!

   Wszystko sprowadziło się do tego, że aż musiałem spisać te swoje wyczyny, aby inni nie popełniali tych samych błędów co ja. I tak powstał o to artykuł pt. Vue.js na Heroku.

   Porada nr 3

   I to również trzeba było sprawdzić wcześniej!

4. Dużo czasu poświęciłem na layout

   Jestem estetą. Uwielbiam czysty i jasny layout. I kiedy tworzę go SAM, to w mojej głowie tworzy się ponad tysiąc myśli na temat “jak taki layout powinien wyglądać”. A czas leci…

   Porada nr 4

   Stworzyć prosty layout i nie skupiać się przesadnie wyglądzie, kiedy tworzy się aplikację. To przy grach można skupić się bardziej na designie.

5. Ostatnie dwie godziny na Socket.io

   Wpadłem na pomysł, aby dodać do projektu Socket.io. Nic w tym nadzwyczajnego. Zawsze na hackathonie je dodaję, aby projekt była bardziej interaktywny (multiplayer zawsze na propsie!).

   Niestety na ten pomysł wpadłem 2 godziny przed końcem wydarzenia! Chciałbym tylko przypomnieć, że kilka godzin wcześniej spędziłem picując layout.

   Nie ma co ukrywać, że tworzenie aplikacji klient-serwer jest bardziej złożone, niż CSS.

   Porada nr 5

   Nie tracić tyle czasu na inne pierdółki i zająć się bardziej wymagającymi zadaniami!

6. Deploy Socket.io na Heroku

   Poległem. Nie potrafię uruchomić serwera z WebSocketami na tym środowisku. Przeczytałem jakieś tam artykuły opisujące jak to niby zrobić ale jednak “nie pykło”.

   Zadanie do zrobienia!

   Wymyślić / dowiedzieć się / shakować rozwiązanie jak uruchomić serwer WebSocketowy na Heroku. Gdy już to zrobię napiszę o tym artykuł. Jestem przekonany, że przyda się taki wpis dla społeczności.

7. Wykorzystanie Bulmy przyspieszyło development

   O tak! Wreszcie jakiś pozytyw! Nie ma sensu pisać wszystkiego od nowa. Po to są frameworki CSS, dzięki którym budowanie layoutu w oparciu o siatkę jest bardzo przyjemne!

   Porada nr 6

   Polecam Bulmę jako framework CSS. Dobre nazewnictwo klas i świetne możliwości w budowaniu kontrolek.

8. Wykorzystanie paczki debug pomagało mi odnajdywanie się w logach

   Podczas hackathonu wykorzystałem jedną z moich ulubionych paczek. Jest nią paczka debug, która ulepsza prymitywnego console.log-a.

   Porada nr 7

   Kto jeszcze nie korzystał z tej biblioteki, to szczerze polecam. W każdym produkcyjnym projekcie wykorzystuję tą paczkę!

9. is-my-json-valid stała na straży spójności danych!

   Moja ulubiona biblioteka to is-my-json-valid (od nie dawna ajv). Super szybka walidacja schemy to jest coś czego potrzebuję i ani TypeScript ani Flow tutaj by nie pomógł! Mówię to z pełną sympatią do TypeScript-a 😄

   Po so mi imjv? Walidacja JSONa po to, aby zweryfikować, czy faktycznie dostaję do czego oczekuję.

   Porada nr 7

   Gorąco polecam tą bibliotekę do walidacji JSONów.
   Kiedyś opowiedziałem na jej temat lightning talka.

10. Literówka przy definiowaniu schema-y

    Wspomniana literówka spowodowała stworzenie nowego formatu do sprawdzenia “czy wartość nie jest pusta?”. Omawiana literówka to:

    - require
    + required
    

    Najważniejsza porada!

    Strzeżcie się literówek!
    To one są zabierają nam (programistom) najwięcej czasu.

•

Wideo

Kilka dni po hackathonie nagrałem film, w który opowiadam o projekcie “Milva”:

•

Problem z Vue CLI

Podczas deploymentu miałem spory problem z opublikowaniem aplikacji przez domyślną konfigurację package.json. Ten plik został wygenerowany w procesie budowania aplikacji za pomocą vue-cli z użyciem template webpack.

Aplikacja posiada błąd dotyczący formatu wersji w package.json:

- "node": ">6.12.0",
- "npm": ">3.10.10"
+ "node": "8.x",
+ "npm": "5.x"

Walczyłem z tym tematem dosyć długo. Szkoda. Mógłbym ten czas poświęcić na ulepszanie aplikacji.

Co mi się spodobało w Vue.js?

1. Bardzo prosta składnia

   Duży plus za prosty przepis na tworzenie komponentów. Połączenie markupu ze zdarzeniami UI to też prosta sprawa. A komunikacja między komponentami w obie strony (rodzic → dziecko i odwrotnie) to istna przyjemność!

2. Czytelny kod

   • warstwa prezentacji - Vue.js
   • warstwa przetrzymywania stanu - Vuex
   • warstwa routingu - vue-router

3. Definicja komponentu w jednym pliku

   Nie trzeba przełączać się po plikach. Ten punkt można traktować jako plus ale i pewnie takie rozwiązanie znajdzie swoich przeciwników.

   Trudno. Dla mnie takie rozwiązanie to plus 👍

4. Wsparcie do Sass-a

   Wystarczy ustawić atrybut <style lang="scss"> oraz doinstalować:

   Copy + paste

    npm install node-sass sass-loader
   

   aby korzystać z SCSS w stylach!

   Zapomnijcie o Webpacku i jego “pięknej” konfiguracji.

5. Wsparcie WebStorma

   Dobry edytor to taki, który podpowiada programiście to, co chce on za moment napisać. Moim zdaniem WebStorm króluje w tej kategorii. Pomalutku goni do Visual Studio Code, ale to inna liga.

   WebStorm zna dyrektywy m.in. v-if, v-for, dzięki czemu pisanie markupu to przyjemność!

6. Ekstremalnie szybki development - Hot Module Reloading robi robotę!

   Wreszcie przekonałem się do HMR. Wystarczy uruchomić:

   Copy + paste

    npm run dev
   

   i cieszyć się pracą bez odświeżania strony!

7. Świetne narzędzie developerski Vue.js Devtools

   Gdy korzystać z SSoT (Redux, Vuex) to możesz cofać się w historii stanów, aby dowiedzieć się jak aplikacja wyglądała “kiedyś”.

   Aby to robić musimy mieć odpowiednie narzędzie.
   React ma swoje. Vue nie jest gorsze.

Co mi się nie spodobało w Vue.js?

Nie chciałbym kończyć tego artykułu negatywnie (w końcu to pierwszy wpis w tym roku), więc wcale nie napiszę, że dokumentacja mogła by być lepsza, bo ZAWSZE może być lepiej. Na pewno jest lepiej niż u konkurencji (patrz Angular).

•

Daj znać w komentarzu, czy lubisz brać udział w hackathonach?

•

Wiesz, że za miesiąc organizuję ze znajomymi hackathon? Jeśli nie, to zerknij tutaj.