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

Promowanie wydawnictwa Helion

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 znajdziesz 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.

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.

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.

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ł.

**Uwaga**: Aktualizacja wiedzy dzięki komentarzowi na Wykop.pl autorstwa obereczekpl, możemy się dowiedzieć, że (cytuję):

Literał to zapis wartości literalnej, czy bardziej "czegoś" co posiada taką wartość lub jest takim wyrażeniem.

Idąc dalej za komentarzem, na portalu Wykop.pl, możemy opisać różnicą między koercją a rzutowaniem w sposób następujący (cytuję użytkownika obereczekpl):

• "koercja" to niejako wymuszanie rzutowania, rzutowanie niejawne, dziejące się automatycznie
• "rzutowanie" to zmiana typu, które może być jawne i niejawne (czyli wtedy gdy wprost mówimy "zrzutuj mi tę zmienną do tego typu"), jednak użyte samodzielnie oznacza rzutowanie jawne

Podsumowując: Koercja i rzutowanie to nie synonimy.

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.

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();

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.

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.

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

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.

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.

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".

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.

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

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

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

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.