Invo.academy

Stwierdziłem, iż tym razem zrobię coś nietypowego. A iż ostatnio na grupach na FB mocno reklamowana była platforma Invo.academy, postanowiłem mu się przyjrzeć.

Wstęp

W założeniu Invo.academy (pozwolę sobie używać dalej skrótu IA) ma być miejscem, w którym początkujący frontendowiec ma szansę poćwiczyć swoje umiejętności w kodowaniu designów z Figmy do HTML-a. jeżeli chodzi o sam pomysł – jak najbardziej jestem za! Sam uważam, iż najszybciej uczy się na podstawie praktyki – zwłascza na samym początku. A IA obiecuje jeszcze review do każdego zakodowanego projektu. Ba, w przyszłości ma być choćby możliwość dawania review samemu – co też jest bardzo potrzebną umiejętnością w codziennej pracy programisty.

Na pierwszy rzut oka zatem wszystko wydaje się w porządku. Pora więc zobaczyć, jak to wychodzi w praktyce!

Rekrutacja

Na razie IA jest we wczesnym dostępie, dzięki czemu całość dostępna jest za darmo. Założyłem więc konto i… zderzyłem się z czymś, o czym nie wspominały ani reklamy na grupach, ani strona domowa projektu. Otóż trafiłem do rekrutacji. Odbywała się w postaci gry przypominającej nieco połączenie gry logicznej typu Colobot z językiem programowania Scratch. Moim zadaniem było pomóc rakiecie przelecieć od początku planszy do końca oznaczonego gwiazdką. Żeby nie było za łatwo, gra nie posiadała żadnej instrukcji, a ja miałem tylko 45 minut, by dojść jak najdalej. Dodatkowo zostałem poinformowany, iż wszystkie moje akcje są nagrywane i następnie autorski algorytm zadecyduje, czy zostałem przyjęty do społeczności nowego pokolenia developerów. To byłby spory plot twist, gdyby recenzja IA zakończyła się, zanim na dobre się rozpoczęła!

Dotarłem do poziomu 6. Zasady gry nie okazały się zbyt trudne. Największym przeciwnikiem okazał się mocno „drewniany” interfejs gry. Na domyślnym ustawieniu rakieta poruszała się zdecydowanie zbyt ślamazarnie, a scratchowate bloczki kodu były zbyt ograniczone. Można było je dodawać jedynie przez kliknięcie i nie było możliwości zmiany ich kolejności – można było jedynie usunąć ostatnio dodany bloczek.

Na szczęście dotarcie na poziom 6. okazało się wystarczające i otworzyły się przede mną podwoje do reszty platformy. Niemniej na tym etapie miałem bardzo mieszane uczucia. Tak po prawdzie do teraz nie rozumiem, jaki jest sens tej gry? Zwłaszcza, iż w materiałach promujących platformę nic się o niej nie wspomina. Nie sprawdza też ona umiejętności potrzebnych do kodowania designów. Jedyne, co sprawdza, to umiejętność logicznego myślenia czy znajomość podstaw algorytmiki. Przyjemna gierka… ale no właśnie – to po prostu przyjemna gierka. jeżeli jej zadaniem jest budowanie poczucia ekskluzywności (Patrzcie, zostałem wybrany do bycia członkiem tej grupy!), to myślę, iż to nie jest dobre miejsce na takie rzeczy. Gdybym był początkującym, który po prostu chce sobie pokodzić designy, to po włączeniu się tej gry najprawdopodobniej nigdy bym już do IA nie wrócił. Bo zamiast tego, co mi zareklamowano na grupie, dostaję na start sprawdzian moich umiejętności – i to choćby nie w dziedzinie, którą miałem ćwiczyć na tej platformie.

Design

Ale dobrze, przejdźmy do mięska! Na stonie (w momencie pisania tej recenzji, czyli 6 marca 2023) znaleźć można 24 designy, podzielona na 5 poziomów, różniących się rosnącą trudnością. Na poziomy 1-4 przypada po 6 designów (chociaż część jest w 3 wersjach – dla Reacta, Vue i Angulara), na razie nie ma żadnego designu na poziomie 5. Stwierdziłem, iż nie będę szaleć i wezmę sobie coś prostego. Mój wybór padł na formularz wprowadzania danych do płatności z poziomu 2.

Zapoznałem się więc z briefem projektu, a następnie ściągnąłem tzw. starter. W jego środku znajdował się design w formacie Figmy oraz katalog ze startowym kodem. jeżeli chodzi o sam design – trudno mieć tu jakieś zastrzeżenia. Jest podział na widok mobilny, tabletowy i desktopowy, jest choćby prosty styleguide, opisujący podstawowe kolory i stany elementów. Natomiast mam pewien problem z zaproponowanym kodem startowym. Jego struktura plików wyglądała tak:

├── index.html ├── package.json ├── package-lock.json ├── public │ ├── files │ ├── images │ │ └── javascript.svg │ └── json ├── README.md ├── src │ ├── global-scripts │ │ ├── main.js │ │ └── scripts │ │ └── counter │ │ └── counter.js │ ├── global-styles │ │ ├── styles │ │ │ ├── fonts.scss │ │ │ ├── normalize.scss │ │ │ └── root.scss │ │ └── style.scss │ └── pages │ └── home-page │ ├── scripts │ │ └── home-page.js │ └── styles │ └── home-page.scss └── vite.config.js

Sporo się tutaj dzieje.

• Mamy tutaj do czynienia z projektem przeznaczonym do uruchamiania przy pomocy Node’a/npm-a.
• Całość pochodzi też z jakiegoś repozytorium gita – na co wskazuje plik .gitignore.
• Dodatkowo plik vite.config.js wskazuje na to, iż jest to projekt wykorzystujący Vite.
• Sam kod jest podzielony na skrypty i style globalne oraz na style dla poszczególnych podstron. W przypadku tego startera istnieje tylko jedna podstrona – główna (home-page).

Przyznam się szczerze, iż zaskoczyła mnie aż tak skomplikowana struktura plików. Wydaje się zdecydowanie zbyt złożona jak na projekt dość prostego formularza płatności. Co więcej, mocno kontrastowała też z przykładowym projektem, który znajdował się w starterze – przyciskiem zliczającym kliknięcia w siebie (screenshot). Może jestem nadmiernym minimalistą, ale… to można było serio zmieścić w trzech plikach: 1 HTML, 1 (S)CSS i 1 JS. I tak, wspominam o SCSS-ie, ponieważ starter zakłada, iż używać będziemy Sassa. I jeżeli 2 lata temu, czy choćby rok temu byłbym skłonny przyznać temu rację, tak w 2023 natywny CSS jest na tyle potężny, iż Sass na dobrą sprawę sprawdza się głównie jako system modułów, pozwalający pisać style z podziałem na pliki. Bo choćby takie killer ficzery jak zagnieżdżanie powoli docierają do CSS-a. I tym bardziej, iż – jak już wspominałem – projekt formularza płatności nie jest jakoś szczególnie skomplikowany i jest możliwy do ogarnięcia spokojnie przy pomocy czystego CSS-a.

Z ciekawości sprawdziłem też, jak wygląda starter w przypadku projektu z 1. poziomu. Jest ten sam. Wydaje mi się, iż dobrym rozwiązaniem byłoby przygotowanie starterów oddzielnie dla wszystkich poziomu. Bo dla osób, które chcą po prostu zakodować prosty design, żeby w ogóle wsiąknąć w temat, nagłe zderzenie z ekosystemem npm-a i Vite może odrzucić od webdevu. Zwłaszcza, iż projekt takiej choćby karty na blogu naprawdę nie wymaga nic ponad 3 pliki. A zamiast Vite (które służyłoby tutaj wyłącznie do podglądu na żywo) można zasugerować odpowiednie dodatki do edytora kodu, np. Live Server.

Dodatkowo, w pliku README.md znajduje się informacja, iż więcej informacji o starterze znajduje się w bazie wiedzy. Postanowiłem zatem rzucić do niej okiem.

Baza wiedzy

Rozwieję od razu ten hitchcockowski suspens – nie znalazłem tam informacji o starterze. w tej chwili w całej bazie wiedzy znajdują się tylko 3 artykuły. Dwa z nich traktują o importowaniu i eksportowaniu rzeczy z Figmy. Trzeci z kolei – o dobrych praktykach przy pisaniu SCSS-a.

Same opisane tam praktyki są jak najbardziej w porządku. Problemem jest raczej to, jak zdawkowo są opisane. Brakuje też większych przykładów. Jedną z zasad jest choćby to, iż należy dzielić kod na komponenty. Jak najbardziej się zgadzam – komponenty to podstawa współczesnego webdevu! Problem polega na tym, iż całą kwestię podziału strony na komponenty sprowadzono do prostego stwierdzenia:

Komponenty mogą być różne – może być to cała sekcja, bądź jej fragment. Jeden komponent może też zawierać w sobie inne komponenty. Nie ma tutaj reguły – to ty decydujesz, jaka część widoku stanie się komponentem.

I tak, ten fragment jest jak najbardziej prawdziwy. Problem polega na tym, iż początkujący jest, well, początkujący. Podziału na komponenty też trzeba się nauczyć i trudno samemu od razu „poczuć”, jak to należy robić. Baza wiedzy wspomina wcześniej o BEM. Aż się prosi, żeby przygotować jakikolwiek prosty przykład podziału strony na komponenty z wykorzystaniem tej metodyki. Zwłaszcza, iż o komponentyzacji i modularności napisano już – dosłownie – książki.

Wśród dobrych praktyk SCSS-owych jest też jedna, która mnie zastanawia: używaj zmiennych CSSowych (sic!). Ta praktyka nasuwa mi na myśl jedno: iż faktycznie SCSS ma służyć głównie jako system modułów dla CSS-a. Problem w tym, iż obecnie mamy lepsze narzędzia od tego. A wysnuwam taki wniosek, ponieważ SCSS ma też swoje zmienne. I różnica między nimi a zmiennymi w CSS-ie jest zasadnicza. Zmienne w SCSS-ie zostają zamienione w trakcie transpilacji SCSS-a do CSS-a na statyczne wartości. Z kolei zmienne w CSS-ie są dynamiczne, ich wartość zależy od obecnego środowiska, w którym uruchamiana jest strona. Dobrym przykładem SCSS-owej zmiennej może być kolor fonta. Nie jest to coś, co zmienia się w trakcie działania strony, więc nie zyskujemy za bardzo, robiąc z tego CSS-ową zmienną. Z kolei dobrymi kandydatami na zmienne w CSS-ie mogą być np. obliczanie odstępów między elementami przy pomocy jednostek zależnych od viewportu albo zmienne środowiskowe. Dlatego uważam, iż obydwa typy zmiennych mogą koegzystować w radosnej hipisowskiej komunie i prawdziwą sztuką jest nie wykluczyć z użycia jakiś, a umieć uzasadnić, czemu w danej sytuacji wykorzystało się akurat ten.

Warto też zwrócić uwagę na aspekt dostępności bazy wiedzy. Fragmenty kodu prezentowane są w niej jako screenshoty. To oznacza, iż nie da się ich skopiować, nie da się ich łatwo odpalić na choćby Codepenie, ani nie da się w prosty sposób poprawić ich kontrastu (np. przeklejając je do swojego edytora albo stosując tryb wysokiego kontrastu w przeglądarce). Co więcej, atrybuty [alt] dla tych fragmentów kodu duplikują informacje z podpisów pod screenshotami. Dobrze, iż nie ma sekcji o dobrych praktykach dostępności, bo nadmiar ironii byłby zbyt duży.

Review

Pozostała zatem ostatnia rzecz do sprawdzenia: review zakodowanego designu. Co oznaczało, iż muszę go zakodować. Tak też zrobiłem. Z oczywistych względów nie przykładałem się zbytnio, próbując sprawdzić, jakie błędy zostaną wykryte. A było ich trochę, m.in.:

• niewłaściwa struktura nagłówków w HTML-u,
• niepoprawne użycie elementu section,
• ominięcie elementu main,
• niewłaściwe wartości atrybutów [alt],
• niepoprawne użycie elementów label,
• brak zastosowania BEM,
• błędy w logice kodu JS (walidacja formularza przepuszczała część niepoprawnych danych),
• stosowanie let i var,
• stylowanie po [id],
• brak sensownego podziału kodu SCSS,
• niedokładne odwzorowanie designu (chociaż tutaj od razu przyznaję, iż to był ten element, na którym mi zależało najmniej).

Słowem: nasi starzy, dobrzy znajomi z WebKrytyka! Byłem ciekawy, ile z nich zostanie wyłapanych. Skończyłem projekt w piątek późnym wieczorem i postanowiłem go wysłać. I tutaj zaciekawiła mnie jedna rzecz: nie jest wymagane używanie gita. W kontekście całego starteru (z plikiem .gitignore!) brak tego wymogu nieco mnie zdziwił, ale nie przywiązywałem do tego większej wagi. Zwłaszcza, iż w formularzu do wysłania skończonego zadania należało załączyć zipa z kodem gotowej strony. Problem w tym, iż tuż poniżej należało podać adres wersji demonstracyjnej projektu. I była tutaj lista proponowanych usług: Vercel, GitHub Pages oraz Netlify. Każda z nich najlepiej działa z gitem lub wręcz nie działa bez niego. Nie wiem, czy nie lepiej byłoby wymagać używania gita i zamiast paczki przesyłać po prostu link do repozytorium. W każdym razie postawiłem stronę.

Posłałem projekt i review przyszło w poniedziałek. Szybko. Kliknąłem w link prowadzący do review i znalazłem się w dokumentach Google’a. Zaskoczyło mnie to, ponieważ – jakby nie patrzeć – review jest jednym z głównych ficzerów IA. Spodziewałem się istnienia jakiejś zintegrowanej formy review wewnątrz samej platformy. Na dobrą sprawę uważam, iż lepiej działałoby już choćby przesyłanie i reviewowanie projektów wewnątrz jakiejś organizacji na GitHubie czy np. prywatnej instancji Gitei.

Niemniej najważniejsza jest kwestia samego review. Zastanowił mnie już sam tytuł – Kopia Najczęstsze błędy – Formularz wprowadzania danych do platnosci. Wskazuje bowiem na fakt, iż całe review zostało stworzone na podstawie jakiegoś szablonu. I to, niestety, widać. Niektóre punkty nie odnoszą się do projektu, który przesłałem, np. Stan inputów przed wprowdzeniem danych jest niezgodny ze Styleguidem – nazwa pola powinna byc na caly input i przeskakiwac dopiero przy wprowadzaniu danych.. W mojej wersji jak najbardziej nazwa pola jest na cały input i zmniejsza się dopiero przy wpisywaniu danych. Co więcej, niektóre z uwag stwierdzają, iż wykonałem coś niezgodnie z briefem, podczas gdy w briefie tego po prostu nie ma. Jednym z tego typu punktów było wskazanie, iż elementy interaktywne powinny mieć animację przy pomocy transition. Brief o tym nie wspomina, mówi jedynie o odpowiedniej obsłudze elementów interaktywnych. Część punktów z review jest też mocno zdawkowa i tak naprawdę nie wskazuje, na czym polega błąd. Weźmy dwa przykłady:

Błędne RWD – nie chodzi o to, żeby od razu poniżej 834px pokazywać wersję na mobile. Content powinien się skalować, a dopiero od jakiegos momentu przyjmowac wersję przygotowaną przez design

Co to znaczy od jakiegoś momentu? Na jakiej podstawie mam zdecydować i na jakiej podstawie reviewer stwierdzi, iż jest to „ten moment”?

Niepoprawnie shermetyzowany kod

Co to tak naprawdę znaczy? Ten punkt co prawda jest wyjaśniony (do pewnego stopnia) w dobrych praktykach, ale mimo wszystko przydałby się przykład bezpośrednio tutaj, w review, odnoszący się do tego konkretnego kodu. Rzucanie samymi hasłami w review dla mnie osobiście mija się z celem. Zawsze staram się uargumentować swoją opinię, pokazując przykłady błędów oraz proponowane możliwości poprawy. Co prawda na końcu review jest wspomniane, iż można dopytać o szczegóły na forum dyskusyjnym IA, ale… po co? Gdyby zamiast bardzo ogólnego, generycznego review, zrobić je dogłębnie, nie istniałaby (albo przynajmniej zostałaby mocno zminimalizowana) potrzeba późniejszego dopytywania się. No i – jakby mimo wszystko trzeba było dopytać, to forma pracy z wykorzystaniem wspomnianych GitHuba lub Gitei bardzo by to ułatwiała.

Co mnie jednak najbardziej uderzyło, to fakt, iż większość review sprowadzała się do porównywania zakodowanego przeze mnie designu ze screenem projektu. Sensowność pixel perfect to temat na osobny wpis i nie chcę tego tutaj poruszać – zwłaszcza, iż faktycznie, nie przykładałem się jakoś szczególnie do samego wyglądu. Bardziej zależało mi na review kodu. Ale tego akurat nie otrzymałem. W całym review nie ma ani słowa o kodzie HTML czy kodzie JS. Wspomina się jedynie o kodzie SCSS i to w kontekście dobrych praktyk z bazy wiedzy. Wszystkie problemy z semantyką, dostępnością czy wykorzystaniem przestarzałych mechanizmów w JS-ie zostały całkowicie pominięte.

Opcji dawania review, niestety, nie sprawdziłem, bo wciąż nie działa.

Społeczność

Jest jeszcze jedna część IA: forum dyskusyjne/komunikator zbudowany na circle.so. Trochę mnie to zaskoczyło, ponieważ strona główna IA wspomina o grupie na FB. Ale to akurat mało istotne. Chciałem jedynie sprawdzić, jak żywa jest społeczność. I, prawdę mówiąc, mam mieszane odczucia. Rozumiem, czemu takie miejsce do wymiany doświadczeń powstało, ale w moim odczuciu duplikuje istniejące grupy na FB, Discordy oraz fora dyskusyjne. Jedynie dyskusje wokół review, moim zdaniem, miałyby sens wewnątrz takiego forum, ale znów – czy platforma typu Gitea nie byłaby lepsza? Co jednak dziwne, akurat kanał przeznaczony do rozmowy o otrzymanych review jest jednym z najcichszych.

Na innym kanale z kolei znalazłem taki kwiatek:

Tak, jak w pracy – jest zadanie do wykonania, a jak je zrobic to juz umiejetnosci i googlowanie

I znów: mam mieszane uczucia. Z jednej strony się zgadzam, bo umiejętność szukania informacji jest jedną z najważniejszych w zawodzie webdevelopera. Z drugiej: najpierw trzeba wiedzieć, czego szukać. No i skoro się jest już platformą dla początkujących i ma się bazę wiedzy, to byłoby fajnie, gdyby w tej bazie wiedzy można było znaleźć nieco więcej, niż kilka praktyk pisania kodu SCSS.

Podsumowanie

IA ma bardzo fajny pomysł, ale – na razie – wykonanie pozostawia naprawdę sporo do życzenia. Osobiście raczej szedłbym w bardziej zintegrowane rozwiązania, choćby oparte na wspomnianej Gitei. No i warto rozbudować bazę wiedzy, dać tam więcej przykładów, może choćby jakieś interaktywne tutoriale z dzielenia strony na komponenty. To by też pośrednio rozwiązywało problem z ogólnikowymi review – bo istniałyby materiały, do których można odsyłać.

Osobiście odnoszę wrażenie, iż IA jest w naprawdę wczesnym dostępie i musi jeszcze sporo dojrzeć, by być dobrym narzędziem do nauki.