:sparkles: PWA :sparkles:
Twarz autora bloga

Piotr Kowalski

Organizator WarsawJS Trener YouTuber

Recenzja: Tajniki języka JavaScript. Na drodze do biegłości

Przeczytałem kolejną książkę z serii You Don't Know JS (YDKJS). Tym razem wziąłem na warsztat książkę pt. Tajniki języka JavaScript. Na drodze do biegłości. Generalnie, to zacząłem czytanie serii w nieodpowiedniej kolejności. Seria YDKJS rozpoczyna się właśnie tą książką, a przeczytałem dopiero ją teraz. Mam nadzieje, że przeczytanie jej w drugiej kolejności, zaraz po Tajniki języka JavaScript. Zakresy i domknięcia, nie będzie stanowiło dla mnie problemu.

Zdradzę Wam sekret. Nie stanowiło.

Autor serii, Kyle Simpson, pod koniec książki stworzył rozdział, gdzie opisał pokrótce całą serię i zdefiniował kolejność czytania. Przedstawia się ona następująco:

Reklama Helionu

Cała seria dostępna jest tutaj. Helion przygotował landing page, aby reklamować YDKJS. Świetny pomysł. Uważam, że Helion od jakiegoś bardziej dba o marketing, i robi często promocje i oferty specjalne. Pamiętam, że jakoś 2-3 lata temu tak niestety nie było.
Nawet przed chwilą dostałem maila, pt: "Dzień Matki - skomponuj książkowy bukiet w promocji 3za2". Moją mamę, raczej nie interesują komputery, więc akurat nie trafili, ale za sam pomysł należą się brawa.

Może i reklamuję wydawnictwo Helion swoim wpisem, ale nie widzę w tym nic dziwnego. Za dobre rzeczy należą się pochwały.

Helion wykonuje dla nas (programistów) bardzo dobrą robotę.

Każdy popełnia błędy, myślę, że Helion sam też wie, kiedy w książkę jest błąd czy to związany z tłumaczeniem, czy błąd merytoryczny, ale może wtedy jest już za późno na poprawę? Przecież rzadko, kto z nas czyta erraty.

Ważne, aby unikać tłumaczenia kodu źródłowego po polsku. Inaczej można uzyskać jakieś "pieseły" albo inne ciekawe polsko-brzmiące słowa.

Oryginalna wersja

W poprzednim wpisie wyjaśniłem, dlaczego czytam książki po polsku. Jednak nie chciałbym, byście mnie żle zrozumieli. Nasza branża rozwija się non stop. Codziennie powstają nowe rzeczy dotyczące JavaScript oraz całego Front-end-u.

Jeśli ktoś chce być na bieżąco ze wszystkimi nowinkami technicznymi, to musi opanować język angielskim, przynajmniej w takim stopniu, aby pozwolił mu czytać, posiłkując się od czasu do czasu słownikiem ang-pol.

Seria książek YDKJS wydana przez Helion, jest po prostu przetłumaczona z jakiegoś czasu, kiedy specyfikacja ES6 nie była jeszcze w zatwierdzona. Miało to miejsce 17 czerwca 2015 roku. Tak więc, od 11 miesięcy najnowszy standard nosi nazwę ES2015 (a.k.a. ES6).

Czytając książki z serii YDKJS, możemy czasami widzieć, że autor nie był jeszcze pewien jak będzie wyglądała specyfikacja. Często to podkreśla, informując czytelnika, że kod może być przestarzały.

Oryginalną wersję YDKJS: Up & Going znajdziecie na GitHubie pod tym linkiem.

Moje notatki

Chciałbym przedstawić teraz moje notatki, które pojawiły się podczas czytania TJJS. Na drodze do biegłości. Tym razem przykleiłem w książce 17 karteczek znajdując przy tym tylko 2 błędy. Błędy te bardziej były wynikiem złego tłumaczenia, niż w braku wiedzy na temat JavaScript.

Sticker 1. Strona 13. Tekst z karteczki: Książka wprowadza do programowania. Jest to pierwszy tom z serii YDKJS.

Jak już wspomniałem na początku wpisu, książka jest skierowana do wszystkich tych, którzy chcą zacząć swoją przygodę z programowaniem od JavaScriptu. Pierwszy tom serii YDKJS (w polskim tłumaczeniu TJJS) porusza podstawowe kwestie języka, takie jak opis składni, zmiennych, typów, domknięć itd.

Sticker 2. Strona 14. Tekst z karteczki: Wartość literalna? Co to?

Znalazłem w słowniku PWN informację, że literalny to synonim słowa dosłowny.

Myślałem, że literalny to może być tylko obiekt, ale tu chodzi o polskie tłumaczenie, gdzie znaczenie jest trochę inne.

Sticker 3. Strona 23. Tekst z karteczki: "literał" czy to synonim "wartości literalnych"?

Według Wikipedii, słowem literał oznaczana jest jednostka leksykalna reprezentująca ustaloną wartość (liczbową, tekstową itp.) wpisaną przez programistę bezpośrednio w danym miejscu w kod programu. (...) Poza tym funkcje anonimowe są literałami dla typu funkcyjnego. (...) W przeciwieństwie do literałów, stałe i zmienne są identyfikatorami (...).

Po tych wytłumaczeniach dalej bałbym się zastępować określenie literał wartością literalna. No trudno. Może kiedyś spotkam polonistę, który by mi to wytłumaczył.

Sticker 4. Strona 24. Tekst z karteczki: koercja? Co to? Jakie jest dokładne znaczenie?

Według słownika: koercja - natężenie pola magnetycznego potrzebne do rozmagnesowania danego ferromagnetyka. Jaki to ma związek z programowaniem? Może jakiś tam pośredni (może pole magnetyczne można jakoś zaprogramować, nie wiem). Wydaje mi się, że lepszym słowem byłoby użyci po prostu słowa rzutowanie.

Znalazłem jeszcze tutaj, zestawienie ze sobą trzech wyrazów: Koercja, konwersja, rzutowanie. Jak widać, te wyrazy idą ze sobą w parze. Tak też je potraktujmy - jako synonimy.

Sticker 5. Strona 25. Tekst z karteczki: "kod tworzysz nie tylko dla komputera" święta racja!

To zdanie to jest święta racja. Kod, który piszemy, nie piszemy dla komputera, on jest dla nas, developerów. Komputer zrozumie dziwną składnię, człowiek już nie.
Jestem tego zdania, że kod trzeba pisać taki, aby się za niego nie wstydzić, kiedy do Twojego projektu dołączy nowa osoba i będzie musiała się w niego wdrożyć.

Bardzo dobrym zwyczajem jest pisać komentarze. Po kilku latach doświadczenia z językiem, przyjąłem takie zasady:

  • w funkcjach, metodach i procedurach, piszę komentarze jednolinijkowe
  • nad funkcjami piszę JSDoc, do tworzenia którego wykorzystuję komentarze wielolinijkowe, korzystając ze specyfikacji tagów. Polecam przejrzeć wszystkie wspierane tagi na stronie usejsdoc.org.
Sticker 6. Strona 26. Tekst z karteczki: "komentarze powinny wyjaśniać dlaczego?, a nie co?"

Kolejna mądrość. Czasami zdarza mi się zobaczyć taki kod:

// Tworzę nowy obiekt
var fred = new Person();

Jak sens ma ten komentarz? Żaden. Bez sensu jest tworzyć komentarz, które opisują co tu się robi. Przecież to widać po kodzie źródłowym. Zdecydowane lepiej było napisać tak:

// Obiekt nowej osoby potrzebny, aby zarządzać jego danymi w procesie xyz.
var fred = new Person();
Sticker 7. Strona 29. Tekst z karteczki: A czy toFixed nie zwraca zawsze stringa?

W książce jest napisane, że: Jeżeli zachodzi konieczność to generowany jest ciąg tekstowy (string). Według specyfikacji, to toFixed zawsze zwraca stringa, nie tylko gdy zachodzi konieczność. Więcej informacji w specyfikacji.

Sticker 8. Strona 45. Tekst z karteczki: void chyba przypisując wynik tego operatora do zmiennej

Trochę wyrwane z kontekstu. Nakreślę go Wam. Książka chce określić różnice między:

var a;

względem:

var a = undefined;

Nie ma różnicy.
Na zakończenia akapitu jest zdanie:

Zmienna może przejść do stanu "niezdefiniowanego" na wiele różnych sposobów, między innymi na skutek działania funkcji, która nie zwraca wartości, i przez użycie operatora void. Kyle Simpson

Zrozumiałem to tak, jak by operator void coś robił. To nieprawda, no może nie wprost. On zapewnia, że wyrażenie zawsze zwróci wartość undefined. Autorowi musiało chodzić o taką operację.

var a = void 0;

Po wykonaniu takiego kodu, zmienna a również będzie miała wartość undefined.

Sticker 9. Strona 51. Tekst z karteczki: "Operator == sprawdza równość wartości wraz z dozwoloną koercją, natomiast === bez zezwolenia na koercję"

Bardzo ciekawe wytłumaczenie. Nigdy się z takim nie spotkałem, ale to prawda. Operator == nie sprawdza typów ponieważ żagluje nimi, sprowadza obie strony do tego samego typu, a potem dopiero porównuje. Natomiast operator ===, nie zmienia typów. Sprawdza na początku, czy są one takie same. Jeśli nie są to od razu zwraca false. Przykład:

console.log(1 == '1'); // true
console.log(1 === '1'); // false
Sticker 10. Strona 52. Tekst z karteczki: Zerknąć do specyfikacji ECMAScript 5

Wszystkie reguły koercji znajdziemy w specyfikacji, w rozdziale 11.9.3.

Trzeba koniecznie się temu przyjrzeć!

Algorytm jest trochę skomplikowany, nie będę go tutaj umieszczał. Zapraszam do przeczytania. Chociaż raz, każdy developer JavaScript powinien ten algorytm przeczytać. Rozumiem, że zapamiętanie całego procesu, może być trochę kłopotliwe, ale zawsze możemy posiłkować się internetem podczas weryfikacji, jak dokładnie wygląda ten algorytm koercji.

No chyba, że jesteśmy na rozmowie rekrutacyjnej, ale to inny temat.

Dodam jeszcze, że ten algorytm jest również w ECMAScript 6.

Sticker 11. Strona 60. Tekst z karteczki: Czy funkcje można deklarować w if-ie?

Dobre pytanie, czy można to robić? Jak sprawa wygląda w Trybie ścisłym? Zrobiłem do tego projekt na GitHubie, obrazujący co się będzie działo, gdy w strict mode będziemy próbowali zdefiniować funkcję w instrukcji warunkowej.

Zapraszam do zapoznania się z nim: github.com/piecioshka/test-define-function-in-if.

Sticker 12. Strona 66. Tekst z karteczki: "publiczne API"? a może być niepubliczne? masło maślane

API czyli Application Programming Interface oznacza pewien interfejs, który wcale nie musi być publiczny. Więc można zrobić prywatne oraz publiczne API. Więcej można poczytać na Wikipedii.

Pisząc tą karteczkę byłem w błędzie i myślałem, że API jednoznacznie daje nam do zrozumienia, że jest tylko PUBLICZNE. Po przeczytaniu Wikipedii wiem, że tak nie jest. Nie ma tutaj "masła maślanego".

Sticker 13. Strona 72. Tekst z karteczki: literówka: zamiast X !== x powinno być x !== x

Literówki się zdarzają. Jeśli zdarzają się w kodzie, to mogą one spędzić nam sen z powiek i zająć nas na bardzo długo. Takie błędy w książce, mogą co najwyżej spowodować problemy po przepisaniu kodu z książki do komputera.

Sticker 14. Strona 72. Tekst z karteczki: transpiling = transforming + compiling

Dobrze wiedzieć, od czego pochodzi słowo transpiling. W dobie transpilacji Babela i innych narzędzi tego typu.

Sticker 15. Strona 80. Tekst z karteczki: No nie wiem, czy koercja jest faktycznie tym, co powinienem używać w JS-ie

Rzutowanie, szczególnie te niejawne, czasami może przysporzyć problemy (szczególnie z falsy values). Jednak bez rzutowania jawnego daleko byśmy nie "pojechali" w programowaniu w języku JavaScript.

A jak ja konwertuje zmienne? Używam funkcji konstruktorów!
Aby np. zrzutować string na number używam takiej konstrukcji:

console.log( Number( '1.1' ) ); // 1.1

Nie wiem, czemu, ludzie często używają funkcji parseInt - ona służy do konwersji na liczbę całkowitą.

console.log( parseInt( '1.1' ) ); // 1
Sticker 16. Strona 83. Tekst z karteczki: destrukcja w ES6? chyba destrukturyzacja

Tutaj wina leży po stronie tłumaczenia. Autorowi chodziło o destructuring, czyli rozbijcie struktury. Zaprezentuje przykład o co chodzi z "destrukturyzacją".

let [a] = [1, 2];
console.log( a ); // 1
Sticker 17. Strona 85. Tekst z karteczki: Kto znajduje się w komitecie TC39?

Ostatnia karteczka. Czysto teoretyczna. Jak zdobyć listę członków komitetu zajmującego się rozwijaniem naszego ulubionego języka programowania? Wystarczy wejść na oficjalną stronę, na której znajduje się podział względem typu danego członka. Najważniejsi to "Ordinary members", czyli firmy, które mają największe prawa.

Ordinary members - firmy zainteresowane i mające doświadczenie w kwestiach związanych z jednym lub więcej Technicznym Komitetem Stowarzyszenia, chcące korzystać z prawa do głosu na zgromadzeniu ogólnym i chcące korzystać z innych wyłącznych praw zdefiniowanych w Statucie i Regulaminie.

Najlepszym źródłem na zdobycie listy członków w postaci listy osób będzie weryfikacja listy obecności w notatkach ze spotkań komitetu. Tutaj znajduje się projekt z notatkami z regularnych spotkań komitetu w sprawie specyfikacji standardu ECMAScript. Notatki z ostatniego spotkania możemy przejrzeć tutaj. Na liście obecności znajdują się:

  1. Dave Herman
  2. Michael Ficarra
  3. Jordan Harband
  4. Adam Klein
  5. Mark Miller
  6. Brian Terlson
  7. Domenic Denicola
  8. Brad Nelson
  9. JF Bastien
  10. Joe Lencioni
  11. Sebastian Markbage
  12. Jeff Morrison
  13. Kevin Smith
  14. Lars Hansen
  15. Saam Barati
  16. Keith Miller
  17. Michael Saboff
  18. Eric Ferraiuolo
  19. Eric Faust
  20. Chip Morningstar
  21. Dean Tribble
  22. Shu-yu Guo
  23. Tim Disney
  24. Waldemar Horwat
  25. Bert Belder
  26. Peter Jensen
  27. Daniel Ehrenberg
  28. Caridy Patiño
  29. Diego Ferreiro Val
  30. Jean Fraucois Paradis
  31. Shelby Hubick
  32. Leo Balter
  33. Misko Hevery - autor Angular.js
  34. Allen Wirfs-Brock
  35. Kevin Gibbons
  36. Steven Lumis
  37. Zibi Braniecki

Dość długa lista. Pewnie niepełna. Ktoś nie przyszedł. Nie szkodzi, przynajmniej teraz już widzę, ilu ludzi zaangażowanych jest w rozwój języka JavaScript.

Podsumowanie

O książce Tajniki języka JavaScript. Na drodze do biegłości mogę wypowiedzieć się w samych superlatywach. Pięknie opisuje ona podstawy i motywuje do tego, aby zacząć programować w JavaScript już dziś!

Jak dla mnie, porusza ona ciut za mało tego co znajduje się w języku, ale może po prostu tak myślę, ze względu na doświadczenie w tej branży. Nie wiem. Grube lektury nigdy nie zachęcają.

Kolejną książką którą opiszę na łamach mojego bloga będzie: Tajniki języka JavaScript. Wskaźnik this i prototypy obiektów.