Miał być jeden artykuł na kwartał, ale wiadomo, iż deserowy czerwiec wciąż trwa…! Dlatego dzisiaj przyjrzymy się e-bookowi oferowanemu przez Rekrutację frontend, który zawiera pytania rekrutacyjne dla juniorów wraz z odpowiedziami.
Forma
Przyznam, iż zdziwiła mnie forma tego e-booka. Spodziewałem się raczej PDF-a, względnie EPUB-a, jednak zamiast tego dostałem po prostu stronę internetową. To samo w sobie nie jest problemem (rzekłbym, iż wręcz przeciwnie). Problemem jest to, że… PDF/EPUB byłby przyjaźniejszy. Wynika to z tego, iż cała ta strona jest stworzona przy pomocy Notiona i pytania wraz z odpowiedziami są przedstawiane jako zwijane i rozwijane sekcje. Z tym, iż Notion używa swojej własnej implementacji, zamiast natywnego details. A to sprawia, iż nie można choćby wyszukać słów kluczowych w odpowiedziach. Dopiero po rozwinięciu pytania można przeszukiwać jego odpowiedź. Przy details można przeszukiwać też zwinięte sekcje – przynajmniej w Chrome (i mam nadzieję, iż pozostałe przeglądarki ostatecznie też to umożliwią).
Notion też średnio lubi się z kotwicami, więc linkowanie do poszczególnych pytań czy ich grup jest niemożliwe. Dodatkowo w prawym górym rogu jest jakiś przełącznik, który… absolutnie nic nie robi. Nie wiem nawet, do czego miał służyć (domyślam się, iż miał przełączać między jasnym i ciemnym motywem). Pomijam już, co się dzieje z focusem, gdy próbuję po tym nawigować klawiaturą… Wygląda więc, iż paradoksalnie wykorzystanie popularnego narzędzia obniżyło finalne dostępność i użyteczność całego rozwiązania.
Treść
Pytania podzielone są na 10 kategorii. Niemniej odnieść można wrażenie, iż początkowo miała to być lista pytań z JS-a, a resztę kategorii doczepiono później. Pytań JS-owych jest zdecydowanie najwięcej, podczas gdy np. o testy są raptem cztery. Same pytania wydają się również mocno ogólne, jedynie muskujące tematy związane z webdevem.
Są tutaj też błędy rzeczowe. Tradycyjnie już przewinąłem do sekcji poświęconej HTML-owi, znalazłem pytanie o DOCTYPE i napotkałem nieprawidłową odpowiedź:
Doctype (skrót od Document Type Declaration) to instrukcja umieszczana na początku dokumentu HTML lub XHTML, która informuje przeglądarkę internetową o typie dokumentu, który ma być renderowany.
Doctype definiuje reguły składniowe dokumentu, takie jak używane elementy, atrybuty, tagi itp., co umożliwia przeglądarce poprawne interpretowanie dokumentu i wyświetlanie go w odpowiedni sposób.
Zacznijmy od tego, iż XHTML de facto już nie istnieje. Specyfikacja HTML mówi zamiast tego po prostu o składni XML. Dodatkowo, przeglądarka w momencie odczytywania DOCTYPE już wie, z jakim typem dokumentu (zasobu) ma do czynienia, bo ta informacja przychodzi w nagłówku HTTP Content-Type. Gdyby to zależało od DOCTYPE, to strony go pozbawione nie renderowałyby się wcale – a jak najbardziej to robią.No i wreszcie – DOCTYPE nie zawiera reguł składniowych dokumentu. W zamierzchłych czasach w teorii była to prawda, ponieważ DOCTYPE zawierał link do pliku .dtd (Document Type Definition – definicji typu dokumentu), np. dla HTML 4.01 DOCTYPE wyglądał tak:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">Plik .dtd faktycznie zawierał reguły opisujące składnię HTML-a. Ale były z nim dwa problemy:
-
DTD nie było w stanie w pełni opisać składni HTML-a i XHTML-a,
-
korzystanie z DTD powodowałoby potężny DDoS serwerów W3C.
Dlatego też przeglądarki od praktycznie zawsze korzystały z wbudowanych reguł parsowania, które z jednej strony uniezależniały silnik przeglądarki od pliku na serwerze W3C, z drugiej strony – pozwalały wymuszać reguły, które nie były (czy wręcz – nie mogły być) opisane w pliku .dtd. Z tego też powodu HTML5 odrzucił fikcję .dtd i uprościł DOCTYPE. Specyfikacja wprost informuje, iż jest on zaszłością historyczną i służy wyłącznie wymuszaniu renderowania stron zgodnie ze standardami (czyli omijaniu trybu dziwactw).
Z innych błędów w sekcji HTML można wskazać na uznanie box modelu (modelu pudełkowego) za pojęcie HTML-owe, podczas gdy jest ono CSS-owe. W HTML-u nie istnieje box model, bo nie jest to język opisu wyglądu.
W sekcji CSS-owej znaleźć można z kolei informację, iż elementy ukryte przy pomocy visibility: hidden są wciąż dostępne z poziomu czytnika ekranowego. To nie jest prawda. Błędna jest też informacja, iż jednostka em odnosi się do wielkości fonta rodzica. Ta jednostka odnosi się do wielkości fonta danego elementu, co można łatwo udowodnić. Prawdopodobnie błędne przekonanie pochodzi z faktu, iż najczęściej tej jednostki używa się do ustalania wielkości fonta. Wówczas faktycznie, efekt jest identyczny jak w przypadku, gdyby obliczenia zachodziły na podstawie wielkości fonta rodzica. Aczkolwiek należy pamiętać, iż w CSS-ie większość własności jest dziedziczona, w tym wielkość fonta. Wyobraźmy sobie następującą sytuację:
<style> p { font-size: 20px; } span { font-size: 0.8em; } </style> <p>Paragraph with a <span>span inside</span></p>Dla całego akapitu ustalona wielkość fonta to 20 pikseli. Element span dziedziczy ten rozmiar i dopiero po odziedziczeniu następuje obliczenie wartości w jednostce em (20*0.8=16). Tym sposobem w żadnym przypadku nie trzeba odnosić się do wielkości fonta rodzica.
Z kolei w sekcji JS pada stwierdzenie, iż w trybie ścisłym nie można używać zmiennej arguments wewnątrz funkcji. To nie jest prawda, ta zmienna działa bez najmniejszego problemu. To samo tyczy się funkcji eval(). Być może chodziło o to, iż tryb ścisły zabrania nadpisywania arguments i eval().
Niektóre odpowiedzi nie zawierają także najnowszych sposobów radzenia sobie z konkretnymi problemami webdevowymi, np. odpowiedź opisująca tworzenie głębokiej kopii obiektów nie wspomina o strukturalnym klonowaniu.
Nie wymieniam tutaj wszystkich błędów rzeczowych, znalazłoby się jeszcze kilka innych (np. dotyczących hoistingu).
Podsumowanie
Sam pomysł na tego typu e-booka nie jest zły, chociaż ostatnio wydaje się mocno eksploatowany przez liczne grono autorów. Problemem jest za to forma, w jakiej e-book został wydany, oraz liczne błędy rzeczowe. Przydałoby się też dać nieco miłości kategoriom innym niż JS, bo takie testowanie wydaje się mocno zaniedbane.
Cytując klasyka: not great, not terrible.
