Ta strona korzysta z plików cookies.
Korzystając ze strony, wyrażasz zgodę na ciasteczka. Zobacz więcej
Książka jaką teraz wziąłem na celownik to "JavaScript od podstaw" której autorem jest Pan Marcin Moskała. Tytuł bardzo przyjazny dla początkujących i kompletnie "zielonych" w fachu jakim jest programowanie. Mimo iż zostałem w niej "pouczony", że to jest skierowane do ludzi, którzy nie mają zielonego pojęcia o programowaniu, postanowiłem ją sobie przeczytać i odświeżyć swoją wiedzę o języku JavaScript, z którego ostatni raz korzystałem podczas wypuszczania aktualizacji projektu "Marball" (2018). Zostawmy już te wspomnienia i przejdźmy do mojej opinii, popartej jak zawsze dowodami i ze szczyptą osobistych komentarzy.
Tweet |
Ogółem tytuł jest króciutki (ponad dwieście stron samej treści merytorycznej), przyjemny i zawiera w sobie dużo treści typu "konkret" bez lania wody. Uznaję to za plus. Oprowadzanie po tematach też jest dla mnie poprawne. Zaczyna się od prostych zagadnień, a kończy się na trudniejszych i tutaj także nie ma zastrzeżeń. Spodobał mi się też rozdział z pisaniem gry na płótnie HTML, co cieszy moje oko podwójnie jako game developera :). Koniec wieńczy zaprezentowanie w jaki sposób można się uczyć programowania, jakie mamy dostępne źródła, do czego jest zdolny JavaScript, a także podzielenie się planem jak można znaleźć pracę w ciągu roku nie mając pojęcia o programowaniu! Jak w każdej lekturze, tak i tutaj są małe grzeszki w postaci literówek, niedopatrzeń i tym podobnych drobnostek które zaraz wymienię poniżej, jednakże są one na poziomie tolerancyjnym. Mając nadzieję, że to nie urazi autora lektury, pozwolę je sobie wymienić tylko najpierw formalna sprawa:
Recenzując książkę autorstwa Pana Marcina Moskały i prezentując swoje zdanie na jej temat, nie leżało w mojej intencji żadne złośliwe wytykanie błędów ani ośmieszenie. Jedynym moim celem publikacji recenzji było przedstawienie swojej subiektywnej opinii oraz sprostowanie pewnych przytoczonych treści, aby ewentualne ponowne wydanie książki było pozbawione wskazanych błędów, jeśli faktycznie takimi są (bo sam mogę się mylić!).
Już mogę zaczynać.
Od czego by tu zacząć? Może najpierw od konkretniejszych rzeczy, a literówki jakie zawiera "JavaScript od podstaw" sobie zostawimy na koniec.
Strona #87. Niewielka rzecz, naprawdę. Wewnątrz kodu źródłowego dotyczącego pętli "for", możemy znaleźć słowo kluczowe "var". Nie robiłbym z tego zagadnienia gdyby nie to, że na samym dole strony #34 jest wyraźnie zaznaczone, że "let" jest następcą słowa kluczowego "var" (sugestia, że lepiej korzystać z "let"). Więc pozostaje zamienić hasełko na "let" i po sprawie! To samo słowo możecie też znaleźć pod sam koniec strony #131.
Jeden z obrazków wyjątkowo nie posiada żadnego napisu pod sobą! Dokładnie to strona #210 i "screen" z ukazanym kodem źródłowym wykorzystującym bibliotekę "cylon.js". Przykuło to moją uwagę z tego względu, że reszta obrazków posiada opis pod spodem. Też maleńka sprawucha.
Popatrzcie proszę na tę funkcję:
function shouldBounceBallFromTopWall() {
return ballY <= BALL_R && ballDY < 0;
}
To jest strona #178. A na poprzedniej stronie jest to już zapisane trochę inaczej:
function shouldBounceBallFromTopWall() {
return ballY - BALL_R <= 0;
}
Nie chodzi mi o koniunkcję, bo autor książki "JavaScript od podstaw" powiadomił o konieczności modyfikacji z uzasadnieniem, tylko o pierwszy warunek (ballY - BALL_R <= 0). To nic złego, gdyż tylko przeniesiono stałą na prawą stronę równania słusznie zmieniając znak, aczkolwiek w takiej sytuacji także powinno się zawiadomić czytelnika, że treść ulega zmianie żeby była ładniejsza.
To już robi troszkę więcej szkód dla czytelnika. Otwieramy książeczkę na #91 stronie i patrzymy na sam dół, na ostatnie ciało funkcji "callFunction", w której wprowadzono funkcję anonimową. Jest tam łańcuch znaków "Figa", nie? A co widzimy na kolejnej stronie? Łańcuchem jest "Maciek"! Za to komentarz pozostał bez zmian! Autor pomylił się i zamienił łańcuch znaków na inny bez dostosowania komentarza wprowadzając zamieszanie (wartości nie pokrywają się ze sobą). Co więcej, w kolejnych dwóch zestawach kodów źródłowych na tej samej stronie powiela się ten błąd! Łańcuch jest inny i komentarz jest inny!
To nie koniec! Zaraz po następującym wpisie napisanym DRUGI raz (cały czas strona #92):
// Jest równoznaczne z
pomylono Marcina z Maćkiem! Ale też Maję z Martą oraz Maćka z Figą. Wyszło nawet zabawnie.
Strona #106 kończy rozdział o formacie pliku JSON. Mi chodzi tylko o jedno zdanie. Dobra, dwa:
"Przykładowa odpowiedź na końcu rozdziału."
I teraz ciekawostka linijkę niżej:
"Odpowiedzi na końcu książki."
Na następnej stronie jest kolejny rozdział, a rozwiązania brak. Czyli poprzednie zdanie jest bzdurą! Wraz z postępem w czytaniu książki "JavaScript od podstaw" można łatwo wywnioskować, że ostatnie zdanie pojawia się przy każdym ćwiczeniu do rozwiązania (wynika z tego, że autor musiał przekopiować zdanie i wkleić w to miejsce zapominając o podobnym zdaniu wers wyżej). Przypomniał mi się paradoks kłamcy. Tam też jest taka znana formułka: "Poniższe zdanie jest fałszywe. Powyższe zdanie jest prawdziwe.". W tym przypadku to drugie zdanie "mówi prawdę" i przykład rozwiązania został umieszczony na stronie #259, na końcu książki.
Próba wywołania funkcji o nazwie "drawPoints" na stronie #156 spowoduje błąd. Kiedy będziemy "iść" z pisaniem kodu źródłowego zgodnie z książką, to okaże się że przez całą resztę poprzednich stron od rozpoczęcia rozdziału NIE MA definicji takiej funkcji! "drawText" tak, z tym że są to trzy parametry zamiast dwóch. Widocznie zapomniano o definicji funkcji "drawPoints", zdarza się. Dotyka to również strony #194. Funkcja-konstruktor posiada metodę "drawPoints", która wywołuje metodę o tej samej nazwie występującą globalnie, to znaczy próbuje gdyż skończy się to "krzykiem" interpretera i wadliwym działaniem gry. Problem dotknie Was też na stronie #200, gdyż tam jest ta sama sytuacja. Z funkcją "drawBall" na wspomnianej #156 stronie jest podobnie (w tamtym czasie powinno być "drawCircle"). Wywołanie jest, a ciało? Znajduje się dopiero na stronie #193.
Teraz nie jedna, a kilka stron. #174, #178 i #180. Na podanych stronach znajdują się nowe fragmenty kodów źródłowych w formie instrukcji warunkowych. Kłopot w tym, że autor lektury "JavaScript od podstaw" nie ukierunkował w którym dokładnie miejscu powinny się one znaleźć. Nie będę tych fragmentów przedstawiał, gdyż można łatwo je poznać po blokach "if". Wiem, że to może być czepianie się trochę na wyrost, niemniej jednak początkujący ma prawo jeszcze nie wiedzieć w którym miejscu najlepiej wstawić kod. Ja sobie jakoś poradziłem, bo dysponuję jakimś tam doświadczeniem, ale to nadal było kierowanie się własnym zdaniem.
Kiedy przejdziemy na stronę #166, to tam zobaczymy rozdział dotyczący nakładania ograniczeń dla rzędnej paletki, aby nie uciekła poza ekran (rzędną nazywamy w matematyce oś Y). Problem polega na tym, że wyjaśnienie "słowne" przeczy zapisowi kodowemu. Otóż gdy wczytamy się w następujące zdanie (niestety konieczny był cytat pełnego zdania):
Powinniśmy zabronić ruchu w górę (p1Action === UP_ACTION), gdy paletka znajduje się na samym szczycie, czyli gdy jej górna krawędź (p1PaddleY) jest równa lub większa od 0 (p1PaddleY >= 0).
to na pierwszy rzut oka wydaje się prawidłowe. Natomiast, spróbujcie połączyć fragment o zabranianiu z warunkiem. Blokada ruchu w górę istotnie powinna występować kiedy paletka jest na samej górze ekranu, ale kiedy wartość zmiennej ("p1PaddleY") jest MNIEJSZA bądź równa zero, gdyż początkiem układu współrzędnych jest lewy górny róg ekranu, więc idąc w górę wkraczalibyśmy w wartości ujemne! Alternatywnym podejściem mogłaby być zmiana zdania w drugą stronę, czyli:
"Powinniśmy zezwolić na ruch w górę [...], gdy paletka nie znajduje się na samym szczycie [...]"
O, wtedy to ma sens!
Bardzo ważna uwaga, która spowodowała duże "auć!". Problem tkwi w stronach #194-199 (fragment rozdziału o przenoszeniu kodu gry na paradygmat obiektowy). Chodzi o to, że prezentowane fragmenty kodów nie uwzględniają WSZYSTKICH niezbędnych zmian jakie powinny się odbyć, żeby gra nie została popsuta! Największa bolączka była u mnie przy zmiennych "p1PaddleY" oraz "p1.paddle.y" (drugi gracz to samo), po przeniesieniu się na klasy i obiekty. Wprowadzenie wszystkich modyfikacji pobranych z książki spowodowało u mnie wyłożenie się programu! Między innymi dlatego, że zabrakło poprawki w funkcji rysującej paletkę, gdyż nadal sugerowała się starą zmienną odpowiadającą za pozycję paletki ("p1PaddleY", zamiast "p1.paddle.y")! Jak to mogło inaczej się skończyć jak nie błędem? Nawet jeśli przyjąć scenariusz, że nie usuniemy tej starej zmiennej jak ja to uczyniłem, to dalej będzie źle ponieważ modyfikacja wartości nie będzie wpływać na paletkę z powodu przestawienia się na atrybut "y" w metodzie "setY" (metoda rysująca dalej będzie sugerować się starą zmienną). Z tej samej przyczyny problemy wystąpiły również po stronie obiektu "Ball", gdyż tam powstała zależność od zmiennych kontrolujących pozycję obu paletek w osi Y.
"Przeprowadzka" zmiennych odpowiadających za punktację graczy także sprawiła zepsucie się mechaniki, tym razem dodawania punktów po wyjściu piłeczki poza planszę. Na stronie #194 wprowadza się atrybut "points" do obiektu...tylko gdzie jest ukazana modyfikacja instrukcji inkrementującej?
p1.points++; // zamiast p1Points++;
p2.points++; // zamiast p2Points++;
Inkrementuje się nie to, co powinno! Nie każdy mógłby być w stanie się z czymś takim uporać samodzielnie. Jednak taki człowiek będzie oczekiwać, że książka sama go "poprowadzi za rękę". Czytelnicy, uważajcie na ten punkt!
A teraz kochane przez wszystkich literóweczki występujące w książce "JavaScript od podstaw"! Oto one:
A teraz literówki będące błędami w kodzie źródłowym:
Wyjątkowo osobny podział dla braku pogrubienia słów kluczowych (w całej reszcie książki występują dla podanych fraz, a tu ich nie ma):
Wystąpił przypadek, w którym zabrakło czcionki dla wyróżnienia tytułu jednego z rozdziałów książki:
Na deser garść "bugów" na temat przecinków, które (moim zdaniem) zostały wstawione w niewłaściwym miejscu:
A teraz z innej mańki. Przedstawiam dwa ważne podpunkty, których mi zabrakło w tej książce, a które same nie zajmowałyby dużej liczby stron.
Bardzo ważny punkt moim zdaniem którego zabrakło w książce "JavaScript od podstaw", gdyż powinno się poinformować czytelnika (chociaż wtrącając jedno zdanie), że jeśli nie chce mieszać jednego pliku z drugim, to może skorzystać z takiej linijki kodu:
<script src="/[nazwa].js"></script>
a instrukcje pisane w JS wsadzić sobie do odrębnego pliku skryptowego! W mojej ocenie początkujący powinien wiedzieć, że tak można zrobić gdyż może sobie życzyć wstawić kod gdzieś indziej, aby się nie plątał. Dzielenie kodu na małe segmenty jest bardzo ważne (słusznie zostało napisane, że kod oprócz prawidłowego działania powinien być też czytelny)! Im szybciej to wie, tym lepiej.
Po omówieniu instrukcji warunkowych, na stronie #49 możecie znaleźć wspomnienie o instrukcji wielokrotnego wyboru oraz jasne oświadczenie autora, że nie będzie prezentować tłumaczenia, gdyż odchodzi to od prostych do zrozumienia koncepcji. Ja bym tak bardzo nie przesadzał. "switch" potrafi dać do pieca, aczkolwiek może w niektórych sytuacjach skrócić kod i uczynić go piękniejszym, co może jak najbardziej sprzyjać początkującym. Podejrzewam, że autor chciał uchronić czytelnika przed opisywaniem pułapki, która to pokazuje się kiedy zapomnimy wstawić słowo "break" po instrukcjach danego "case'a" (to, na co zwróciłem uwagę w stosownym artykule) i to zaważyło na zdecydowaniu o nieumieszczeniu treści o instrukcji wielokrotnego wyboru. To jest moja hipoteza, więc mogę się mylić. Choć istotnie trzeba uważać, ja bym tak nie tragizował i wytłumaczył nawet początkującym do czego jest zdolna instrukcja "switch-case".
W bonusie macie parę dodatkowych uwag, które nie są już powiązane z jakimikolwiek błędami czy brakami w treści. Traktujcie to jako dygresję.
Natrafiłem na tekst, który zostawił niezłe "XD" na twarzy. Strona #58 i wątek historyjki o chłopcu, który zapragnął gotówki od mamy na kino. Samo przedstawienie opowieści było po to, żeby wytłumaczyć funkcjonowanie alternatywy w programowaniu abstrakcyjnym językiem, ale nie to jest najważniejsze. Chodzi mi o zdanie, które jest wypowiedzią małego bohatera w stronę swojej mamy:
"Użyłaś łącznika lub, który akceptuje zrobienie zarówno jednego, jak i drugiego, podobnie jak || w programowaniu."
Rozśmieszyło mnie to, bo wyobraziłem sobie wyraz twarzy mojej mamy gdybym ja się tak do niej zwrócił po zrobieniu jakichś dwóch rzeczy naraz, oczekując ode mnie jednej z nich (alternatywa). Od razu by zadzwoniła po lekarza :D. W przeciwieństwie do mamy bohatera, moja nie zaakceptowałaby takiego wyjaśnienia. Po prostu XD.
Pod sam koniec książki "JavaScript od podstaw", autor prezentuje plan jak zdobyć pracę programisty od zera do Juniora. Moim skromnym zdaniem nawet trzyma się kupy! To są z pozoru rzeczy oczywiste, jednakże dla wielu osób mogą nie być takie oczywiste i sam zacząłem go wdrażać do swojego życia. Pozwoliłem sobie na ten skromny podpunkt, bo zauważyłem u siebie podobne podejście co do omawianych spraw na temat programowania. Często umykają nam rozwiązania, które powinny być dla nas jasne i które powinny instynktownie wpaść do naszych głów, a jednak błądzimy nawet latami i kaleczymy swoją przyszłość. W taki sposób skrzywdziłem siebie, bo ograniczałem kontakty społeczne do minimum (może dlatego nie mogę się wybić od lat?). A czy tego chcę, czy nie, informatyka to "teamwork".
Komentarz w sprawie "kontrowersji", o której mowa na stronach #190-191. Sprawa dotyczy przeniesienia implementacji sterowania paletką do samego obiektu gracza. Autor twierdzi, że taki manewr kłóci się z zasadą "oddzielania modyfikacji stanu i reagowania na akcje gracza". Odebrałem to tak, że nie będziemy iść tą drogą i zostawimy tę część kodu taką jaka jest. Później się okazuje (strona #194 i #199), że zostało to zaaplikowane w sposób "kontrowersyjny", czyli mamy takie "wiele hałasu o nic". Zabrakło zdania uprzedzenia, że mimo wszystko przeniesie się ten kod (metoda "makeAction") do obiektu, tylko o to mi chodzi.
I jeszcze ostatnia rzecz odnośnie terminologii. Parę razy widziałem w książce "JavaScript od podstaw", jak były zamiennie używane słowa "deklaracja" i "definicja". To się jednak "nie liczy" do powyższej listy, bo zostałem niejako pouczony o tym, że autor kieruje się prostym językiem dla czytelnika (strona #5), więc nie uznaję tego za powód do "przyczepienia się". Gdyby ktoś chciał wnikać w szczegóły, to przypomnę że deklaracja zmiennej kończy się na etapie podania jej nazwy, a przypisanie wartości w tej samej linijce kodu dopiero wtedy jest jej definiowaniem.
Były również zamienniki "stałej" i "zmiennej":
ale i w tym przypadku na stronie #34 jest akapit o świadomości autora o tym, że faktycznie "const" powinno określać się "stałą" dlatego te informacje również zostawiam na uboczu.
Tadam, tadam, a teraz odpowiedź na gorące pytanie, które zostawiam na koniec każdej recenzji. TAK! Lećcie do sklepu albo zamówcie przez Internet, a nie pożałujecie. Nie wypowiem się co do użyteczności dla kompletnie początkujących, bo przeczytałem ją mając już spory kawał doświadczenia w programowaniu, więc większość tematów obleciałem na pstryk, ale faktycznie co zauważyłem, została napisana tak żeby każdy miał szansę ją zrozumieć. Są obrazki, tłumaczenia na chłopski rozum i na każdy temat poświęcono dostatecznie dużo stron. Oprócz tego sporo wiedzy na temat możliwości nauki programowania, prywatne przeżycia autora z życia zawodowego oraz ten plan ekspresowego zdobycia zatrudnienia! Nie widzę powodu, żeby skłaniać Was do odstąpienia od zakupu. Panie Marcinie, szacuneczek!
![]() |
Tytuł "JavaScript od podstaw" to w mojej ocenie bardzo dobra pozycja dla początkujących adeptów w dziedzinie programowania. Spełnia swoją rolę postawioną przez autora, żeby pokazała prostym językiem na czym polega programowanie!
Nie ma co się rozwodzić. Autor summa summarum odwalił kawał dobrej roboty (życzę mu jak najlepiej) i dzięki tej książce na nowo odświeżyłem sobie najbardziej podstawowe wiadomości z JavaScriptu. Teraz już na przykład wiem, że definiowałem zmienne w moich grach pisanych w "Phaserze" przy użyciu słowa "var" nie wiedząc o istnieniu słowa "let", a zamiast zabawy w prototypy mogę skorzystać z wygody normalnej klasy potomnej dla obiektów gry. Program się od tego nie zawali, jednak jest wyciągnięta nauka na przyszłość. Ale w końcu wszyscy jesteśmy ludźmi! JavaScript wstępnie uznaję za temat zamknięty.