Vuex – getters – enkapsulacja logiki

W dzisiejszym krótkim wpisie opiszę jak wykorzystałem getters w Vuex do implementacji pobrania statusu repozytorium.

Stara wersja

Powyższy kod wykonuje trzy czynności, w pierwszej kolejności wysyła POST na serwer, informując, że dany plik musi przejść na stage. Kolejne dwie to wywołanie akcji, które pobierają status repozytorium w stage unstage.

Widać bardzo duże podobieństwo i niepotrzebne powielenie kodu. Po stronie serwera, pobranie odbywa się poprzez odpytanie tej samej metody RetriveStatus, różnicą jest jedynie typ statusu.

Warto by zmienić lekko podejście, zlikwidować duplikację.

Nowsza wersja

No ok, dwa odpytania serwera po „te same” dane. Zmieńmy to:

Jak widać spore zmiany, pozbyliśmy się dwóch wywołań. Zastąpione one zostały jednym wywołaniem funkcji fetch_repository_status, pobiera ona nie filtrowane dane. Przypisuje je następnie do jednego stanu, repositoryStatus.

Ok, to teraz wyświetlmy to na widoku:

Działa? Działa pięknie. Jest tylko jeden problem z tym rozwiązaniem. Jeżeli będę chciał wykorzystać taka listę w innym miejscu , będę musiał powielić kod. Zobaczmy jak będzie wyglądała implementacja z wykorzystaniem getters.

Najnowsza wersja

Getters w Vuex, są koncepcyjnie tożsame z computted we Vue. Generalnie chodzi o to, że jest to miejsce w którym możemy poddać filtracji nasze dane. Co warto zauważyć, filtracji, a więc procesowi który nie zmienia nam stanu aplikacji.

a teraz wykorzystanie w komponencie Vue:

Korzyści są oczywiste, wydzielenie logiki do osobnego miejsca. Dzięki temu użycie plików ze stage lub ustage sprowadza się do wywołania powyższej linijki. Dodatkowo jakiekolwiek modyfikacje w przyszłości będą znacznie łatwiejsze. Jedno miejsce gdzie jest logika = jedno miejsce do zmiany.

Podsumowanie

Tym rozbudowanym wpisem opisałem dość prosty mechanizm gettersVuex. Jednakże chciałem również nakreślić problem wydzielania logiki i powielania kodu. Powyższy przykład można zastosować do każdego innego frameworka czy języka. Odpowiednie oddzielenie zależności znacznie ułatwi nam pracę oraz utrzymanie kodu, pamiętajmy o tym!

git log, wstęp do D3JS

Dzisiaj więcej kodu! W końcu to blog programistyczny. W dzisiejszym wpisie pokażę jak udało mi się stworzyć wizualizację grafu commitów.

Obecnie graf wygląda tak:

Graf składa się z trzech struktur

node – pojedynczy commit, opisany przez sha, koordynaty x oraz y

link – połączenie pomiędzy dwoma commitami, składa się z identyfikatorów poszczególnych commitów oraz z identyfikatora kolumny. Kolumna to zmienna pomocnicza, przydaje się do wyznaczenia kolorów połączeń

message – dodatkowe informacje o commicie, treść commita, autor, data, identyfikator

Wstęp do d3js

D3js, framework do wizualizacji danych. Niby tyle… lub aż tyle. Możecie zobaczyć ile jest przykładów i jak niesamowicie się one prezentują tu! Naprawdę robi to wrażenie. Widać też jak potężnym narzędziem jest ta biblioteka.

Standardowo możemy sobie ją pobrać za pomocą package managera npm lub załączyć cdn.

Obecnie można się spotkać z dwoma wersjami 3 i 4. Należy na to zwrócić uwagę, ponieważ zmiany są w pewnych przypadkach dość spore i część przykładów z 3 nie będzie nam działać na wersji 4. Zdecydowałem się na wersję 3, ponieważ więcej przykładów znalazłem właśnie w tej wersji.

Bazą grafu do gita będzie element svg. Dlaczego? daje bardzo dużo możliwości, jeżeli chodzi o bardziej zaawansowane animacje czy kształty.

Ok, na początku określmy punkt startowy dla grafu:

W pliku HTML wstawiamy  tag svg, do tego elementu będziemy się odwoływać w naszych skryptach i w ramach tego tagu powstaną wszystkie inne elementy.

W pierwszej kolejności musimy „chwycić” svg przez d3js

naprawdę proste, na obiekcie d3 wywołujemy metodę select, jako jej parametr określamy na jakim elemencie chcemy pracować. W tym przypadku jest to svg, ale nic nie stoi na przeszkodzie aby zaznaczyć jakikolwiek inny tag HTML. Dodatkowo możemy zaznaczyć klasę jak i identyfikator. Dla klasy odwołujemy się poprzez ‚.nazwa_klasy’, a do identyfikatora ‚#identyfikator’.

W pierwszej kolejności wygenerujmy sobie grupy, które będą nam spajać węzły, dodatkowe informacje oraz ten szary prostokąt w tle.

  • selectAll – zaznacza nam wszystkie tagi g w obrębie elementu svg. Dodam , że tag svg jest o tyle specyficzny, że nie możemy (możemy ale nie będą widoczne) wewnątrz niego dodawać niektórych „klasycznych” tagów min. div. Odpowiednikiem div jest właśnie element g.
    Różnicą pomiędzy metodą select, a metodą selectAll , jest to, że ta druga zwraca nam wszystkie elementy w postaci tablicy.
  • data – przekazujemy tablicę commitów, tak przekazane dane będą służyć do następnych operacji.
  • enter – tworzy powiązanie pomiędzy zaznaczonymi elementami przez funkcję selectAll, a przekazanymi przez funkcję data.
  • append – funkcja tworząca elementy, w tym przypadku tagi g. Ile ich ma stworzyć, to zwraca funkcja enter. Ilość stworzonych elementów określa rozmiar tablicy przekazanej w funkcji data. Istotne jest to, że zostaną stworzone jedynie brakujące elementy. Dzięki temu ilość elementów oraz danych w tablicy zawsze jest taka sama.
  • attr – przekazujemy atrybut dla każdego elementu, tego stworzonego jak i tych istniejących.

Po tej operacji powinna powstać poniższa struktura, oczywiście na widoku na razie nie będzie nic widać, ale to jeszcze chwilka 😉

Dodajmy troszkę elementów wizualnych. Na początku szare prostokąty.

Więc, tak jak w poprzednim przykładzie, rozpoczynamy od funkcji append, która doda nam dokładnie taką samą ilość elementów rect jak g. Ustawiamy, aby prostokąt rozpoczynał się w punkcji x = 0, punkt wyznaczamy dynamicznie na podstawie danych przekazanych poprzez funkcję data.

classed – funkcja spełnia dokładnie takie samo zadanie jak .attr(„class”,’nazwa_klasy’), czyli ustawia klasę dla elementu. W tym jednak przypadku posiada jeden bardzo przydatny parametr setFlag, ustawienie go na true powoduje, że klasa ta będzie dodana do elementu. Wartość false usunie klasę z elementu.

style – oczywiście jeżeli chcemy zmienić jeden parametr wizualny naszego elementu, nie musimy specjalnie tworzyć  do tego klasy w CSS. Możemy przekazać go wprost za pomocą funkcji style. Poniżej to samo wywołanie ale z wykorzystaniem funkcji style zamiast classed:

A efektem tego jest tak ostylowany element:

Dokładnie takim samym sposobem tworzymy commity oraz informacje o commicie.

Do końca pozostały nam jedynie połączenia. Zaimplementować można to tak:

Można zauważyć że wyjściem do generacji jest svg. Jako, że połączenia są pomiędzy elementami różnych grup, to wydzieliłem je na zewnątrz. Jedyną wartą uwagi częścią jest:

W ten sposób odwołujemy się do węzła, w którym aktualnie się znajdujemy, w tym przypadku aktualizujemy wartości punktów granicznych dla linii.

Podsumowanie

Przede wszystkim należy zwrócić uwagę na fantastyczne API jakie udostępnia biblioteka. Bardzo przejrzyste, intuicyjne, naprawdę rewelacja. Tak jak pisałem w poprzednim wpisie, dokumentacja jest… ciężka i toporna, ale jest w niej wszystko. Za to istnieje mnóstwo tutoriali blogów i przykładów. Jest się z czego uczyć. W następnym wpisie postaram się opisać interakcję użytkownika z elementami, jak i również integrację d3js z VueJs.

git log –graph

Od samego początku projektu wiedziałem, że ten etap będzie najtrudniejszy. Nie wiedziałem, że aż tak. Od ostatniego wpisu minęło sporo… czasu. Bynajmniej powodem nie był brak tematów lecz ilość czasu jaki spędzałem nad rozwiązaniem tego problemu. Cały czas pracowałem nad wizualizacją grafu comimtów w gicie. W Togglu mam prawie 30h pracy nad tym komponentem, co w stosunku do ilości pracy włożonej w cały projekt od początku konkursu, wynosi coś koło 25%.

Dobra ale gdzie ten problem? Co mi zajęło tyle czasu. Miałem dwa problemy do rozwiązania:

  • struktura grafu
  • wizualizacja

Co jest ważniejsze?!

Za pomocą biblioteki libgit2Sharp pobranie listy commitów wraz z identyfikatorami rodziców jest trywialne:

Powyższe zapytanie wyciąga commity rozpoczynając od HEAD (najwyższy dostępny lokalnie commit obecnego brancha) oraz są one w kolejności chronologicznej. Jak się okaże później, są to bardzo istotne informacje, szczególnie ta druga.

Podgląd grafu w SourceTree

Na samym początku zadałem sobie pytanie, które już od dawna mnie nurtowało: Które commity wchodzą w skład „głównej” ścieżki ( w powyższym przypadku kolor seledynowy). Postaram się to opisać jeszcze dokładniej. Analizę rozpoczynamy od góry od commita b82… Jego rodzice to 50df.. i a24b… i teraz zakładając, że mogą one przyjmować dowolne daty wcześniejsze niż b82…, który z rodziców jest „głównym” rodzicem? Nie dawało mi to spokoju, uważałem to za najważniejszą informację jaką muszę pozyskać. Odpowiedź przyszła dopiero po długim czasie czytania dokumentacji gita.

Okazuje się, żeby wyznaczyć główną linię grafu należy wykonać komendę git log –first-parent. Dzięki temu uzyskamy wyłącznie commity zaznaczone na seledynowo. GENIALNIE! miałem rozwiązanie mojego problemu. Teraz jak to zaimplementować przy pomocy libgit2Sharp….

Nie trzeba!, domyślnie struktura listy parentów dla każdego commita jest posortowana tak, że „główny” commit jest pierwszy! Jest to kluczowa informacja. Trzeba pamiętać że sama lista commitów posortowana jest chronologicznie.

Wizualizacja

Mając przygotowane dane jedyne co mi zostało to je wyświetlić na widoku. Jedynie… Od samego początku odrzuciłem pomysł

Może napiszę framework do generowania grafów!

Od znajomego dostałem cynk, że do tego nada się doskonale d3js!

Czym jest d3js? Oh, dużo by mówić, można zobaczyć tutaj, w skrócie bardzo przyjemne API do wizualizacji różnego rodzaju danych.

Spędzając parę kolejnych godzin na wertowanie dokumentacji (jest straszna i obszerna!) wybrałem sposób na wizualizację mojego grafu. Zastosowałem klasyczne podejście z węzłami i liniami łączącymi.

Po kilku godzinach pracy udało się!

Jeszcze nie jest doskonały, niektóre ścieżki się nie kończą i czasami kolor się miesza (czarny i żółty).  Dodatkowo dochodzi problem wydajności, puki co napisałem to „żeby działało” jest tam jeszcze co optymalizować.

Ale uff udało się, najbardziej bałem się tego etapu. Jak już mnie nic nie blokuje, będę mógł częściej publikować nowe wpisy 😉

Dwa tygodnie już za znami

Dwa tygodnie konkursu mijają za troszkę ponad godzinę. Czas na lekkie podsumowanko postępów.

To były naprawdę dwa intensywne dla mnie tygodnie, w większości nastawione na naukę Vuejs. Jakie mam o nim zdanie można przeczytać w moich poprzednich wpisach. W skrócie to jest całkiem nieźle. Powolutku do przodu posuwały się pracę nad interfejsem graficznym mojej aplikacji. Jako, że nie jestem mistrzem JS ani stylów, powolutku to mało powiedziane. Ale mam! poniżej moja krwawica, ależ jestem z tego dumny!

W poprzednim wpisie pokrótce opisałem poszczególne elementy, teraz możemy je zobaczyć na „żywo”

W górnej części widzimy trzy ściśle powiązane ze sobą komponenty, staged files, unstaged files, commit. Służą one do definiowania zbioru plików które mają wejść w skład commita.

Poniżej nich komponent z którego puki co jestem najbardziej zadowolony! Podgląd zmian w pliku. A czemu akurat z tego? Bo wygląda całkiem nieźle! Ten element i drzewo commitów stanowią niejako serce gitGUI. Cieszę się że mam choć jedną z tych rzeczy.

Co dalej

Krótka mapa drogowa kolejnych dwóch tygodni (właśnie co dwa tygodnie będę publikować tego typu wpisy)

  • Poprawki do powyższego modułu, zwiększenie UX
  • W komponencie z podglądem zmian chciałbym dodać możliwość wyłączenia poszczególnej zmiany z commita
  • GRAF GRAF GRAF aż się boję, zdaję sobie sprawę że może to być najtrudniejsza rzecz podczas tego projektu, zarówno pod względem algorytmicznym jak i również graficznym.

Sporo zadań, zobaczymy co z tego wyjdzie. W nadchodzącym tygodniu chciałbym również rozpocząć serię wpisów dotyczących samego gita, STAY TUNED

Vuex – wstęp

Postępy

Szybkie spojrzenie na to co wykreowało się w aplikacji. Na chwilę obecną są 4 komponenty:

unstagedFiles – komponent odpowiedzialny za wyświetlanie wszystkich plików, które nie mają wejść do kolejnego commita,

stagedFiles – analogicznie- komponent, który wyświetla pliki, które chcemy włączyć do commita,

commitDetails –  komponent odpowiedzialny za „budowanie” commita, na razie jest tylko nazwa oraz przycisk,

fileChangePreview  –  duży komponent odpowiedzialny za podgląd aktualnych zmian w plikach, zarówno tych w stage jak i unstage. W komponencie tym będziemy mieli możliwość podejrzenia zmian jak i wyłączenia z danego commita.

Każdą z tych operacji opiszę jeszcze dokładnie w kolejnym wpisie. W tym chciałbym się skupić na krótkiej relacji z mojej przygody z Vuex.

Vuex

W każdej aplikacji, w której nacisk położony jest na wysoką modularyzację (a takie są aplikacje pisane w VueJs), przychodzi potrzeba komunikacji pomiędzy komponentami. Zarówno komponentami w konfiguracji rodzic-dziecko, jak i w równoległej konfiguracji dziecko-dziecko. VueJs dostarcza nam wbudowany mechanizm komunikacji, lecz wraz ze wzrostem ilości elementów aplikacji, złożoność oraz narzut na jej implementację znacznie rośnie. Dodatkowo chcielibyśmy zapewnić „czystość” komponentom. Chcielibyśmy uniknąć tworzenia sztucznych komponentów służących wyłącznie jako pośrednicy w komunikacji.

Teoretycznie mogłem stworzyć komponent root dla powyższych komponentów i zaimplementować prostą „szynę”, ale patrząc trochę do przodu, zdaje sobie sprawę, że takich szyn i komponentów pomocniczych może być znacznie więcej. No więc co?

Rozwiązać ten problem chce Vuex. Czym jest Vuex ? Dla mnie Vuex to mechanizm zarządzania stanem aplikacji, przypomina mi trochę taki globalny singleton. Oczywiście z możliwością pełnej modularyzacji i ograniczeniem kontekstów działania.

Instalacja

Na samym początku instalujemy wszystko za pomocą npm.

Struktura plików Vuex w aplikacji jest prosta, wszystkie pliki znajdują się w folderze store.

Poniżej przestawiłem cały kod jaki jest wymagany aby uruchomić Vuex w swojej aplikacji VueJs.

W pliku main.js importujemy sobie instancję Vuex znajdującą się w pliku index.js i przekazujemy do konstruktora Vue.

Sam plik index.js również wygląda bardzo prosto. Pokrótce, na samym początku importujemy sobie wymagane referencje oraz akcję i mutację (o nich później). Jak widać zostały one wydzielone do osobnych plików ale nic nie stoi na przeszkodzie, żeby na początku umieć je w taki sposób jak state.

Należy zwrócić uwagę na tą linię:

Ważne jest aby ona była umieszczona przed inicjalizacją Vuex.

Implementacja

Poniżej opiszę poszczególne elementy, które wchodzą w skład instancji Vuex. Za przykład wezmę instancję z mojej aplikacji.

state– Nic innego jak stan naszej aplikacji.

W powyższym przykładzie, chcemy aby w skład stanu naszej aplikacji wchodziły dwie kolekcje plików.

Przekazując store do instancji Vue automatycznie mamy do niej dostęp, jako globalny obiekt, pod zmienną $store.  Jeżeli w którymś z komponentów chcielibyśmy się odwołać do tych zmiennych, należy to zrobić tak:

Naprawdę proste. Ale czym w takim razie rożni się od zwykłego globalnego obiektu zawierającego zmienne? W Vuex mamy ściśle określone zasady jakimi powinniśmy się kierować, aby zmieniać stan.

mutations- aby poprawnie zmienić stan naszej aplikacji musimy zaimplementować tzw. mutacje. Są to funkcje, które operują na stanie. Tylko w tych funkcjach implementujemy logikę, która ten stan zmienia. I teraz jeżeli mamy potrzebę zmienić stan, wywołujemy daną mutację:

Poniżej implementacja mutacji APPLY_UNSTAGED_FILES

Strict Mode – No dobra ,ale zaraz ktoś spyta

a co mi szkodzi  żeby wywołać ten kod

W tym przypadku czyścimy listę plików poza funkcją mutacji. Oczywiście to przejdzie, ale łamiemy tym samym całą ideę Vuex, równie dobrze moglibyśmy go wywalić.

Oczywiście taka implementacja może być mniej lub bardziej świadoma. Dlatego przychodzi nam z pomocą strict. Jeżeli ustawimy tę flagę na true, to Vuex podczas każdej zmianie stanu z „zewnątrz”, wyrzuci nam wyjątkiem.

Bardzo pomocne, szczególnie w przypadku gdy uczymy się Vuex lub do zespołu dołącza mniej doświadczony programista.

Akcje – główna zasada w Vuex mówi, mutacje wykonujemy synchronicznie. Oczywiście świat, jak i pewnie większość framworków w JS są asynchroniczne, ale nie chcemy z nich rezygnować. W odróżnieniu od mutacji, akcje mogą wywoływać operacje asynchroniczne.

Oczywiście, jeżeli po wykonanej akcji chcemy wywołać mutację to nic nie stoi na przeszkodzie. Wywołujemy poprostu metodę commit z odpowiednimi parametrami.

W powyższym przykładzie, zadeklarowałem akcję, która asynchronicznie odpytuje API o wszystkie pliki, a następnie wywołuje mutację i aktualizuje pliki.

Samo wywołanie akcji w komponencie również jest trywialne, wystarczy wywołać funkcję dispatch oraz przekazać nazwę akcji, którą chcemy wywołać.

W powyższym pliku możemy zwrócić uwagę na jeszcze jedną rzecz. Mianowice import pliku types.

W pliku  types.js znajdują się wszystkie nazwy akcji i mutacji jakie mamy zadeklarowane. Dzięki temu zabiegowi z kodu znikają nam wszystkie „magic strings”. Prosty rozwiązanie, ale niezwykle pomocne.

Podsumowanie

Generalnie sam mechanizm mi się podoba, jak się go opanuje to naprawdę ułatwia komunikację pomiędzy komponentami. Bardzo przydał mi się StrictMode, dzięki niemu wyłapałem nie jeden kardynalny błąd.

Oczywiście, przedstawione rozwiązanie z podziałem implementacji Vuex na osobne pliki nie uchroni nas przed zbytnim ich rozrośnięciem. Potrzebne są nam jakieś moduły. Oczywiście Vuex dostarcza nam taką możliwość. W kolejnym wpisie z tej serii opiszę ten mechanizm.

VueJS daj się poznać

Długo się zastanawiałem jaki framework dla frontendu wybrać. Na rynku mamy wielu kandydatów m.in: Angulara 1.x, Angulara 2.x, Aurelię, VueJs i klasyk- React. Oczywiście to nie wszystkie i pewnie nie wspomniałem o jakichś ważnych, ale tylko tymi miałem jakąkolwiek styczność, czy to przez petprojects czy też na prezentacjach. Jeżeli chodzi o Angulara 1.x, pisałem w nim drobne aplikacje i całkiem nieźle mi się z nim pracowało. Przyjemna separacja zależności, wsparcie dla DI, serwisy, fabryki itp. To co lubię. Wiele złych rzeczy można na jego temat wyczytać, ale ja ich nie odczułem, może dlatego, że nie robiłem w nim żadnego większego projektu.

No ale mamy przecież Daj Się Poznać i fajnie byłoby nauczyć się czegoś nowego. Angular 2.x i Aurelię widziałem na kilku prezentacjach i wydają mi się zbyt „ciężkie”. Szukałem czegoś bardziej finezyjnego, lżejszego. Został React oraz VueJs. Reacta kojarzę tylko za sprawą Facebooka, a VueJs dlatego, że od jakiegoś czasu stał się dosyć modny. Długo nie mogłem się zdecydować. Po spotkaniu na gliwickiej grupie DevDuck postawiłem na VueJs.
Tym postem z przydługim wstępem chciałbym rozpocząć „mikro” serię wpisów na temat mojej męki w świecie frontendu.
Początki? To zawsze jest trudne. A w froncie? To jest coś niesamowitego… Dla osoby, która dość długi czas siedzi w backendzie, przestawienie się jest co najmniej trudne. Ilość rzeczy, które trzeba ogarnąć jest naprawdę spora.

Tak więc VueJs. Oj, ależ inne podejście od znanego mi AngularaJS. Przede wszystkim, odejście od klasycznego MVC i warstw na rzecz architektury „wertykalnej”, architektury luźno powiązanych komponentów.

Single File Components

W pierwszej kolejności podczas nauki szukałem sposobu na kopozycje projektu, zastanawiałem się jak rozdzielać te małe moduły w systemie plików. Jeżeli komponent ma zawierać swój template HTML, obsługę w JS oraz styl, to musi być coś co to „opakuje”. Tym czymś są pliki .vue. Tworzymy jeden plik per komponent:

Segregacja komponentów

Poniżej przykład prostego komponentu:

Mamy w nim trzy podstawowe elementy:

  • template – w ramach tego tagu piszemy cały kod HTML jaki ma być wyświetlony w miejsce naszego komponentu. Ważna rzecz, taki element może zawierać wyłącznie jeden nadrzędny element, także składnia poniżej będzie powodować błędy podczas budowania paczki w webpacku.

A poniżej poprawna implementacja:

  • script – w nim umieszczamy całą logikę komponentu. Jest ściśle określona struktura takiego skryptu. Opiszę go w kolejnym wpisie.
  • style – w nim możemy „upiększyć nasz komponent”. Zwrócić należy uwagę, że nie jesteśmy wcale zmuszeni pisać w czystym CSS. Jeżeli dołączymy atrybut z nazwą składni (w tym przypadku lang=scss) oraz dołączymy odpowiedni loader w webpacku, możemy porzucić pisanie czystego CSS na rzecz SCSS, LESS czy innych.

Ciekawym dodatkiem do tego fragmentu jest możliwość zamknięcia (ang. scoped) stylu na wyłącznie ten komponent, wystarczy, że umieścimy atrybut scoped w tagu.

Dzięki temu style zawarte w komponencie będą miały wyłącznie zasięg lokalny. Oczywiście nic nie stoi na przeszkodzie aby jednym komponencie dodać style lokalne oraz globalne.

Kolejną kwestią jaką należy mieć na uwadze korzystając z tych plików to fakt, że potrzebujemy czegoś co nam to zepnie je w całość. Ja w tym przypadku korzystam z webpacka. Aby wszystko działało, musimy dodać odpowiednią sekcję do rules :

Do uruchomienia aplikacji jeszcze potrzebna jest jedna rzecz. Punkt startowy:

W powyższym przykładzie tworzona jest instancja VueJs, w której jest wywoływany komponent App. Będzie on w moim przypadku głównym komponentem aplikacji, składającym się z mniejszych części.

Musimy to jeszcze zintegrować z ASP.MVC, na którym wszystko stoi. Tak jak w większości frameworków należy wywołać na głównym widoku komponent root’a, czyli w tym przypadku „app”.

Tym sposobem, jeżeli uruchomimy sobie webpacka, a następnie odpalimy projekt powinno na ekranie pojawić się nam piękne „Hello World”!

Postępy

Bardzo dużo czasu przeznaczyłem na wertowanie dokumentacji oraz tutoriali związanych z VueJs. Także czasu na stworzenie samej aplikacji nie zostało zbyt wiele.  Do momentu pisania tego posta widok mojej aplikacji prezentuje się tak jak na załączonym obrazku:

Jak widzimy, z lewej strony kreuje się już panel do zarządzania zmianami w repozytorium. Jako, że jestem kompletnie lewy w sprawach designu to paletę kolorów biorę z VSCode, w którym to piszę.

Co dalej

Do kolejnego wpisu dalej będę zgłębiał tajniki VueJsa, ponieważ jestem dopiero na szczycie góry lodowej. Na pewno chciałbym dokończyć to co mam oraz dołożyć prosty podgląd zmian dla pliku. Zostało mało czasu do końca tygodnia, także zabieram się do pracy.

Wroc# 2017!

Po raz pierwszy usłyszałem o tej konferencji ponad rok temu, w
dniu zapisów. Jak to nagle bilety rozeszły się w kilkadziesiąt
sekund. Pomyślałem sobie- woot!? Może ludzie sobie pomylili to z jakimś koncertem wielkiej pop gwiazdy? Nie byłem wstanie pojąć dlaczego, co jest takiego w tym wydarzeniu, co sprawia, że bilety rozchodzą się w takim tempie. Postanowiłem sobie, że sprawdzę to w tym roku choćby nie wiem co. Parę dni przed rejestracją można było wyczuć rosnące napięcie w społeczności. Wszyscy się zastanawiali, jak szybko rozejdą się bilety. W tym roku szansa na zakup wydawała mi się znacznie większa dlatego, że pierwszy raz wprowadzono opłatę rejestracyjną w wysokości 150zł. Ależ
się myliłem! Minutę przed rozpoczęciem rejestracji spamowałem f5,
w pewnym momencie wszystko się zwiesiło, pomyślałem- oho!
Jednak opłata nie odstraszyła nikogo. Ale udało się, uff.. Bilety
podobno rozeszły się w dwie minuty sic!. Co ciekawe (i tu pełen szacunek dla organizatorów) całą kwotę, która była zebrana z biletów przeznaczono na jeden z trzech celów charytatywnych. Naprawdę jest to godne podziwu.

Rejestracja

No dobra, a teraz sama konferencja. Będę nawiązywał często do konferencji BoilingFrogs, która odbyła się tydzień wcześniej. Jej
relację opisałem tutaj.

Zacznijmy standardowo od rejestracji. Jako, że jechaliśmy ze Śląska, trzeba było dość wcześnie wstać, ale dzięki temu, że pogoda była rewelacyjna, podróż nie sprawiła większych problemów. Jak w poprzednich latach wszystko odbywało się na Stadionie Miejskim we Wrocławiu. Przybyliśmy o 8:30, więc spodziewałem się niemałego tłoku. I tak jak na BoilingFrogs, tak i tu rejestracja była zorganizowana bardzo dobrze. Bez kolejek, szybko, sprawnie i przyjemnie. Miłym zaskoczeniem były identyfikatory wykonane coś na wzór płytek drukowanych, nieźle, nieźle.

Nasze identyfikatory

Cała oprawa prezentowała się naprawdę bardzo dobrze. Wszystko
odbywało się w jednym wielkim pomieszczeniu podzielonym na
kilka sekcji. Najważniejsza, znajdująca się w samym centrum była
oczywiście scena, na której były prowadzone prezentacje.

Główna scena. Zdjęcie dzięki @konradkokosa

Organizatorzy zorganizowali parę miejsc, gdzie można było w czasie przerw odpocząć, m.in.: sekcja gier , chiling room, itp. Była nawet strefa gaszenia pożarów na swojej produkcji, super pomysł! Widziałem nawet, że parę osób tam siedziało 😉 . Jeżeli chodzi o jedzenie to jestem pod wielkim wrażeniem, wydaje mi się, że wyższy poziom niż na Boiling, rewelacja, ilość różnego rodzaju przekąsek powalała, naprawdę.

Prelekcje

Tu muszę być bardziej surowy, jeśli chodzi o ocenę. Domyślam się, że bardzo trudno jest zadowolić wszystkich, mając tylko jedną ścieżkę prelekcji do dyspozycji. Na BolingFrogs były trzy, więc prawdopodobieństwo, że akurat na trzech będzie temat, który nas
nie zainteresuje jest znacznie niższe. No ok, ale mieliśmy jedną,
więc poniżej krótki opis:

(niestety jeszcze nie znalazłem nagrań, jak się pojawią to podlinkuję)

Frans Rosen Go hack yourself…or someone else will – Zastanawiam się ile osób po tej prelekcji powiedziało, kurde wracam do domu i będę kopał, kopał, aż znajdę jakieś bugi w jakimś popularnym serwisie internetowym. Może w nagrodę, jak nie pieniądze to chociaż koszulkę mi wyślą 😉 . Dla tych co nie widzieli to, Frans opowiadał jak zaczął wyłapywać błędy w największych serwisach internetowych na świecie i co z tego ma, a ma naprawdę spoooro ;D Wspomina jak odnalazł błędy w mechanizmach takich firm jak Google czy Facebook. Lekka, przyjemna prelekcja na
początek długiego dnia.

Chris Klug AngularJS Tips from the Trenches – Dobrze poprowadzona prezentacja, o dobrych praktykach programowania w AngularJs (głównie skupił się na wersji 1.x). A może Angular był tu tylko nośnikiem, przykładem? Ja takie wrażenie odniosłem. Wydaje mi się, że równie dobrze w jego miejsce można by wstawić cokolwiek innego np. Aurelie czy VueJS. Ogólny przekaz był taki: nie pisz dziadowego kodu, staraj się, unikaj zależności, wydzielaj konteksty. Nie była to prelekcja wyłącznie o AngularJS, nie próbował nam go „sprzedać” i dlatego uważam, że była dobra i wartościowa.

Maarten Balliauw Whats is going on? Tips and tricks arround aplication diagnostics on Azure – Co zapamiętałem z tej prezentacji najbardziej? Problemy z internetem. No niestety, po raz kolejny spotykam się z tą sytuacją. Według mnie rozwiązania są dwa, albo dedykowane łącze internetowe dla prelegentów lub prelegent powinien przygotować się na brak neta (screen, jakiś filmik). Wydaje mi się, że znacznie by to polepszyło odbiór. To jak w naszej codziennej pracy programisty, jak przyjmiesz happy path to masz przechlapane. A sama prezentacja? Była w porządku. Na pewno wartościowa dla osoby, która nie siedziała nigdy w
Application Insights. Jako, że używam ich na co dzień to niestety
nic nowego się nie dowiedziałem.

Steve Sanderson ASP.NET Core for Angular 2, React, and Knockout developers – nie wiem, naprawdę nie wiem jak ocenić tą prezentację. Niestety nie jestem fanem tego typu prelekcji. Uważam, że na konferencji tej rangi trzeba pokazać coś więcej niż template’y w jakimś środowisku. Pierwsza połowa prezentacji zupełnie do mnie nie trafiła, naprawdę. Na szczęście w drugiej połowie było więcej „technikaliów” i ciekawostek. Między innymi wywoływanie paczek npm w backend’zie, co zdecydowanie
przykuło moją uwagę. Zastanawiam się czy naprawdę taki ficzer
jest potrzebny. Chyba, że jest to niejako furtka dla funkcjonalności,
które nie zostały jeszcze dostosowane dla .NET Core, a istnieją w JS.

Tess Ferrnandez Debuging .NET performance problems, memory leaks and crashes – oj jakie to było… dziwne? Jeszcze oklaski powitalne nie umilkły, a już na slajdach leciały jakieś niezrozumiałe dla mnie komendy w jakimś narzędziu. Jako, że ludzie jeszcze klaskali, nie usłyszałem zupełnie nic. Mówię: „ale to będzie kicha”. A jednak nie. Kilka chwil, pełne skupienie, kolejne przykłady i wiedziałem już o co chodzi, a później z górki. Kolejne przykłady leciały, a ja w głowie miałem już scenariusze gdzie i jak to wykorzystać. Super! To lubię! Kocham prezentacje, które sprawiają, że chcę po nich wyjść, wsiąść w pociąg/samochód/samolot i wracać do domu aby wykorzystać to wszystko, co usłyszałem. Nie była to
prosta prezentacja, domyślam się, że wiele osób mogło ją nisko ocenić. Ale według mnie była najlepsza. Tak jak na BoilingFrogs najbardziej podobały mi się najtrudniejsze prezentacje Szymona i Konrada.

Shawn Wildermuth Developing ASP.NET Core in VS Code – tutaj
muszę się przyznać- większości nie słuchałem ;( Byłem pochłonięty
graniem w tą pierońską grę, którą organizatorzy przygotowali dla
nas. Nagrodą był przejazd Teslą. No i niestety nie będę mógł ocenić
Shawn’a. Jak pojawi się relacja to zobaczę i odpowiednio również
skomentuję.

Jako że wybieraliśmy się na afterparty, niestety, ale ominęliśmy
panel dyskusyjny, trzeba było odwieźć samochód do hotelu.

Intensywny dzień, ale to jeszcze nie koniec.

Afterparty

Ekhm… Napisałem już 1000 słów, a o samym afterze mógłbym
dołożyć jeszcze kolejny tysiąc, tyle się działo. To będzie mega
skrócona wersja.
Jakież to było dobre, śmiem twierdzić, że tak dobrze nie bawiłem
się na żadnej konferencji. To co ludzie mówili w 100% się potwierdziło, było wręcz epicko! Jedzenie – grillbar – rewelacja, open bar z kraftowymi piwkami ! Sekcja gier ! Nawet był DJ i pełen parkiet ludzi, szok. Dodatkowo udało mi się poznać bardzo dużo ludzi ze Slacka, co dodatkowo utwierdziło mnie w przekonaniu, że warto było zostać. Wisienką na torcie był przejazd Teslą. To jest demon, a nie samochód, zrobił na mnie przeogromne wrażenie, tyle mocy w samochodzie, który wygląda jak zwykły Renault!

Grillbar. Zdjęcie dzięki @konradkokosa

Nie wiem dokładnie o której to się skończyło ale na podstawie
historii z Ubera, wyjechaliśmy stamtąd jakoś 30 min po północy ;D

Podsumowanie

Hype na tą konferencję był przeogromny, coś a’la najnowsza część
Gwiezdnych Wojen na naszym polskim podwórku, wielka niepewność czy organizatorzy dadzą radę, i co? Rewelacja! Najlepszy event na jakim byłem. Tak jak pisałem wyżej, sam poziom prelekcji był na średniowysokim poziomie i dla doświadczonych czasami mogło wyjść troszkę nudnawo, ale cała otoczka tego wydarzenia sprawiała, że długo nie zapomnę tego dnia we Wrocławiu. Widzimy się za rok!

PS.

Zacząłem przygodę z Twitterem (właśnie na tej konferencji). Jakby ktoś chciał poczytać co mam do powiedzenia na różne tematy to zapraszam @NorbertRozmus.

 

Daj się poznać

Cześć

Mam na imię Norbert, od kiedy pamiętam wszyscy do mnie mówią Norek, więc tak mnie najłatwiej namierzyć. Programuję już prawie od 5 lat, głównie jest to .NET, i postanowiłem rzucić się na głęboką wodę i wziąć udział w konkursie Daj się poznać 2017.

Tak jak dla większości uczestników, tak dla mnie motywacją do udziału w konkursie jest chęć rozwoju osobistego, poznania nowych technologii, sprawdzenia się jako blogger. Konkurs ma mi dać kopniaka w tyłek i krzyknąć „zrób coś więcej, niż 8h w pracy”. Rok temu niestety nie udało mi się wziąć udziału w konkursie i bardzo z tego powodu żałowałem. Szczególnie jak popatrzyłem ile mogłem zrobić przez te dziesięć tygodni, a ile udało mi się zrobić bez tej dodatkowej motywacji.

Oczekuje od siebie dużo jeżeli chodzi o udział. Na pewno chciałbym dotrwać do końca. Będzie to o tyle trudniejsze że nigdy w życiu nie pisałem bloga, a to wydaje mi się największym wyzwaniem. Już po tym wpisie widzę że nie jest to najłatwiejsza rzecz na świecie, podobno z biegiem czasu będzie łatwiej, zobaczymy.

Co

Celem projektu w DSP2017 jest stworzenie projektu o wdzięcznej nazwie gitWeb. Wzorując się na SourceTree oraz przepięknym GitKraken, chciałbym stworzyć swojego klienta do obsługi repozytoriów GIT. Obsługiwane będzie lokalne repozytorium z możliwością podłączenia do zdalnego repo na GitHubie.

W ramach konkursu chciałbym przede wszystkim zaimplementować takie funkcjonalności jak:

  • Inicjalizacja, klonowanie repozytoriów
  • Drzewo commitów
  • Możliwość commitowania
  • Podgląd zmian na pliku z możliwością częściowego włączenia/wyłączenia zmiany do commita
  • Branching, a więc dodawanie nowych branchy, płynne przełączanie się między branchami, usuwanie
  • Komunikacja ze zdalnym repozytorium – na pewno chciałbym zaimplementować mechanizm uwierzytelniania jak i również mechanizmy push pull.

Dodatkowo bardzo chciałbym zaimplementować prosty MergeTool. Będzie to trudne zadanie zapewne ale się postaram!

Lista spora, czasu mało, zobaczymy ile z tych funkcjonalności uda mi się zrealizować.

Dlaczego

Dlaczego taki pomysł, co mną kierowało wybierając taki projekt. Od zawsze chciałem poznać bardziej git’a coś więcej niż komendy commit i push. Chciałbym z tego stworzyć pełnowartościowe narzędzie do zarządzania swoim repo.

Chyba dwa lata temu przeczytałem książkę „TDD. Sztuka tworzenia dobrego kodu” autorstwa Kena Beck’a, jedną z ciekawszych rzeczy w niej był przykład na którym Ken pokazywał pisanie testów jednostkowych. A mianowicie pisał on testy do swojego własnego frameworka do tworzenia testów jednostkowych. Strasznie mnie to zaciekawiło. Pomyślałem sobie, fajnie było by z robić taką aplikację/kawałek kodu w podobnym stylu. Dzięki czemu na bieżąco bym wiedział czego mi w tej aplikacji brakuje, brakuje mi megreTool’a to go dopiszę. No i chodziłem z tym pomysłem i myślałem aż doszedłem do gita. Od jakiś dwóch lat w firmie w której aktualnie pracuje korzystamy z gita. I od samego początku nie podobały mi się dostępne na rynku toole do zarządzania repo. Tak wiem jestem lamą i powinienem korzystać z konsoli!! no i jeszcze z Vima !! Ale nie, nie jestem w stanie się do tego przyzwyczaić. Mając te dwie rzecz czyli chęć napisania git gui oraz „samo testującej” się aplikacji pewnego dnia stwierdziłem: to może być to!. Już w poprzedniej edycji chciałem się wziąć za to ale niestety brakło mi czasu i chyba troszkę odwagi. albo może czas był ale tego drugiego nie 😉

Jak

Co do samego projektu i jego formy. Początkowo chciałem napisać to w elektronie jak gitKraken lub VisualStudio Code, ale nie chciałem iść w 100% w JS. Postawiłem w pewnik. Aplikacja w formie SPA gdzie w backendzie będzie standard MVC + WebAPI na .NET. Do obsługi gita będę wykorzystywał bibliotekę libgit2sharp. Całość chciałbym utrzymać w metodyce TDD.

Jeżeli chodzi o frontend to tu mam troszeczkę mniej doświadczenia. Pisałem kiedyś coś w Angularze2 ale wydawał mi się za „ciężki”, dlatego postanowiłem spróbować sił w czymś mniejszym, z pośród miliona frameworków dla JS na placu boju pozostał: weterana ReactJs oraz w „miarę” nowy VueJs. Jeszcze nie wiem który z nich wybrać, moja wiedza jest zbyt mała, poczytam i zobaczę co będzie lepsze dla mojego przypadku.

Oczywiście chciałbym również wykorzystać testy jednostkowe do testowania frontendu.

Kiedy

Mamy 10 tygodni, to zarazem dużo, trzeba napisać aż 20 postów, a zarazem mało na taki projekt. Nie chciałbym zbyt mocno skakać pomiędzy backendem a frontendem więc postanowiłem to podzielić. Tydzień skupie się na backendzie a tydzień na wyglądzie i tak do końca wymiennie. Zobaczymy co z tego wyjdzie, już wydaje mi się że jednak na JS oraz Css pójdzie więcej czasu niż przypuszczam ale ważne mieć jakiś plan.