Jason. Cała informatyka w jednym miejscu!

: Opublikowano: 18 kwiecień 2023

Negacja kolejną częścią mini ciągu o operacjach logicznych. Zapraszam serdecznie po dawkę wiedzy na temat operatora "NOT".

OPERATOR "NIE" TO NIC INNEGO JAK NEGACJA!

"Nie" albo "NOT", w zależności od własnego upodobania. Operator negacji powoduje "przestawienie" wartości wyjściowej na bit przeciwny. Czyli zero staje się jedynką, jedynka staje się zerem. To jest proste! Czasami używa się pełnej nazwy "negacja logiczna". Tabelka w ruch:

a	!a
0	1
1	0

To jest operator unarny. Pisząc bardziej zrozumiale, operator jednoargumentowy w przeciwieństwie do alternatywy i koniunkcji. Jak widać powyżej, wystarczy jeden operand żeby negacja odniosła pożądany skutek. Wolno go wstawić także przed zdaniami logicznymi objętymi w nawiasy wykorzystującymi np. koniunkcję:

!(a && b)

Jak możecie dostrzec, w kodzie źródłowym negację określa się wykrzyknikiem (!). Matematyka posługuje się zupełnie innym symbolem (¬), którego nawet nie umiem skojarzyć z czymś znanym ;). Zamiennie używa się tyldy (~).

Teraz posłużymy się kodem. Język C w standardzie C99, bo to w końcu jest materiał ogólnie o programowaniu, a C jest "ojcem" języków wysokiego poziomu:

_Bool a = 0;

printf("%d", !a);

Na wyjściu ujrzycie jedynkę, bo negacja odwraca bit na przeciwny. Przypominam tak skromnie, że nieprawdą jest, że "prawda" to tylko wartość 1. Język C domyślnie odwraca na jedynkę, lecz w rzeczywistości wartość zero jest traktowana jak fałsz, a KAŻDA INNA wartość różna od zera jest traktowana jak prawda. Serio! Jak nie wierzycie, zapraszam do artykułu o "booleanach" w C. Opadnięcie kopary do samej ziemi gwarantowane ;)!

Tak nietypowym stwierdzeniem jak na stronę o nauce informatyki, kończę dzisiejszy materiał.

PODOBNE ARTYKUŁY

Najczęściej czytane

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.

"JAVASCRIPT OD PODSTAW" SPOKOJNIE NAUCZY CIĘ JĘZYKA...OD PODSTAW!

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

GRZESZKI KSIĄŻKI

Od czego by tu zacząć? Może najpierw od konkretniejszych rzeczy, a literówki jakie zawiera "JavaScript od podstaw" sobie zostawimy na koniec.

"VAR" ZAMIAST "LET"!

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.

IMAGE.DESCRIPTION = NULL;

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.

NAGŁA ZMIANA TREŚCI

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.

TE ŁAŃCUCHY SĄ JAKIEŚ INNE

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.

BRAK ODPOWIEDZI

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.

NIE MA TAKIEJ FUNKCJI!

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.

GDZIE MAM TO WSTAWIĆ?

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.

SPÓJRZMY NA TO Z DRUGIEJ STRONY

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!

NIEKOMPLETNE PRZEDSTAWIENIA MODYFIKACJI

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!

LITERÓWKI I INNE DROBNOSTKI

A teraz kochane przez wszystkich literóweczki występujące w książce "JavaScript od podstaw"! Oto one:

"[...] podstawiłem [...]", zamiast "[...] postawiłem [...]" (strona 5)
"[...] gdyż tak stawia się nawiasy [...]", zamiast "[...] gdyż tak stawia się cudzysłowy [...]" (wydaje mi się, że w kontekście chodziło o cudzysłowy angielskie, strona 6)
"(z >>To jest tekst<< [...]", zamiast "(z >>To jest alert!<< [...]" (przykładowy łańcuch znaków oraz wyskakujące okienko są treści "To jest alert!", strona 15)
"Wszystko co znajdzie w środku [...]", zamiast "Wszystko co znajdzie się w środku [...]" (strona 19)
"[...] możemy ją użyć [...]", zamiast "[...] możemy jej użyć [...]" (strona 27)
"[...] (gdzie kolejny element powstaje poprzez podwojenie kolejnego), [...]", zamiast "[...] (gdzie kolejny element powstaje poprzez podwojenie obecnego), [...]" (tak mi się wydaje, strona 68)
"W ciele funkcji możemy użyć wszystko [...]", zamiast "W ciele funkcji możemy użyć wszystkiego [...]" oraz "[...] zmienne, pętle czy nawet same funkcje.", zamiast "[...] zmiennych, pętli czy nawet samych funkcji." (strona 78)
"[...] na przykład do zmiennej albo do innych funkcji.", zamiast "[...] na przykład ze zmiennej albo innych funkcji." LUB "[...] korzystać ze wszystkiego, co zostało zdefiniowane [...]", zamiast "[...] odwołać się do wszystkiego, co zostało zdefiniowane [...]" (strona 81)
"[...] używa się pojęcia pola (of ang. property)", zamiast "[...] używa się pojęcia pola (od ang. property)" (przynajmniej tak mi się wydaje, strona 97)
"Zmienna >>userAddresPostal<< [...]", zamiast "Zmienna >>userAddressPostal<< [...]" (literówka w nazwie zmiennej, strona 99)
"nazwę, np [...]", zamiast "nazwę, np. [...]" (brak kropki przed skrótem, strona 106)
brak przecinka po klamerce zamykającej definicji metody "changeName" (strona 108)
"[...] przy użyciu operatora >>class<<.", zamiast "[...] przy użyciu słowa kluczowego >>class<<." (tak mi się wydaje, strona 114)
"[...], ale pojęcie to nie jest tak jednoznaczne rozumiane.", zamiast "[...], ale pojęcie to nie jest tak jednoznacznie rozumiane." (strona 119)
"[...] mają wiele więcej metod [...]", zamiast "[...] mają o wiele więcej metod [...]" (strona 120)
brak średnika na końcu instrukcji "const array = shoppingList" oraz "const upper = newArray" (strona 129)
nadmiarowy przecinek po ostatnim argumencie tablicy "{name: “Rafał”, score: 3.43, points: 23}," (strona 138)
"[...] rysujemy na nim plansze, [...]", zamiast "[...] rysujemy na nim paletki, [...]" (tak mi się wydaje, gdyż w książce "JavaScript od podstaw" nie pisze się instrukcji wpływających na tło, strona 143)
"Poniżej przedstawiłem gotowe rozwiązanie [...]", zamiast "Powyżej przedstawiłem gotowe rozwiązanie [...]" (chyba, że chodzi o kod źródłowy na obrazku znajdującym się poniżej cytatu, strona 150)
"wysokość i szerokość tej powierzchni", zamiast "szerokość i wysokość tej powierzchni" (metoda "clearRect" przyjmuje najpierw szerokość, a potem wysokość, strona 151)
"[...] oraz keyup, który następuje [...]", zamiast "[...] oraz keyup, które następuje [...]" (TO zdarzenie, strona 159)
"[...] który ustawiliśmy na 3.", zamiast "[...] który ustawiliśmy na 5." (na stronie 161 stała posiada przypisaną wartość 5, strona 166)
"[...] możemy spokojne [...]", zamiast "[...] możemy spokojnie [...]" (strona 168)
"[...] jest równoznaczna [...]", zamiast "[...] jest równoznaczny [...]" (TEN warunek, strona 170)
"Porusza się odpowiednim kierunku [...]", zamiast "Porusza się w odpowiednim kierunku" (strona 179)
"(pamiętaj uwzględnić to [...]", zamiast "(pamiętaj, aby uwzględnić to [...]" (strona 182)
">>shouldBounceFromLeftPaddle<< na >>shouldBounceFromLeftPaddle<<" oraz ">>shouldBounceFromRightPaddle<< na >>shouldBounceFromRightPaddle<<" (nazwy metod nie ulegają zmianie, strona 185)
"[...] i stan ich punków.", zamiast "[...] i stan ich punktów." (strona 187)
"Przyjrzyjmy się [...]", zamiast "Przyjrzymy się [...]" (poprzednie zdanie jest w czasie przyszłym, strona 201)
"[...] ogromną ich liczba [...]", zamiast "[...] ogromną ich liczbę [...]" (strona 208)
"[...] mocno się zastarzała [...]", zamiast "[...] mocno się zestarzała [...]" (strona 221)
"[...] niemal wszyscy wszyscy [...]", zamiast "[...] niemal wszyscy [...]" (powtórzenie słowa, strona 232)
"[...] ani o systemie operacyjnych [...]", zamiast "[...] ani o systemie operacyjnym [...]" LUB "[...] ani o systemach operacyjnych [...]" (strona 244)
"[...] wciąż staje coraz łatwiejsza.", zamiast "[...] wciąż staje się coraz łatwiejsza." (strona 245)
podpunkt "obiektowego i funkcyjnego" (napisane na wyrost, tylna okładka książki "JavaScript od podstaw" tzw. "blurb")

A teraz literówki będące błędami w kodzie źródłowym:

"varDefinition" i "variableDef" (niejednoznaczne etykiety, strona 72)
"p2.paddle.setY(p1PaddleY [...]", zamiast "p2.paddle.setY(p2PaddleY [...]" (strona 189)
"context.clearRect", zamiast "ctx.clearRect" (od samego początku rozdziału obowiązuje nazwa stałej "ctx", strona 151)
"p2PaddleY >= 0" (zbędne i nieaktualne wyrażenie od strony #168, strona #189 i #190)
"paddleX" (zbędny parametr funkcji-konstruktora, gdyż nie jest nigdzie wykorzystywany, strona 192)

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):

"const" (strony #183, #185, #187)
"function", "this" i "return" (strony #185, #186)
wartości atrybutów obiektów (strony #183, #185, #186, #187)

Wystąpił przypadek, w którym zabrakło czcionki dla wyróżnienia tytułu jednego z rozdziałów książki:

"[...] przedstawionego w rozdziale Pierwszy program [...]" (strona 145)

Na deser garść "bugów" na temat przecinków, które (moim zdaniem) zostały wstawione w niewłaściwym miejscu:

"[...] jest przeniesienie, do tego obiektu funkcji, [...]" (strona 184)
"[...] nie musimy, o tym dodatkowo informować w nazwie." (strona 185)
"[...] kontrolować, jak zmienia się obiekt, [...]" (strona 189)
"[...] odpowiem na pytanie, jak tę drogę kontynuować." (strona 200)
"Większy problem pojawia się, gdy chcemy, [...]" (strona 203)
"[...] jak Disqus, albo bazy danych [...]" (strona 203)

TEGO MI ZABRAKŁO!

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.

KOD W JĘZYKU JAVASCRIPT MOŻNA OSADZAĆ NIE TYLKO W ŚRODEK PLIKU HTML

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.

NIE MA "SWITCH'A"? SMUTECZEK...

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

DODATKOWE UWAGI

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

DOWCIPNA HISTORYJKA

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.

TEN PLAN MA RĘCE I NOGI

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

NUTKA KONTROWERSJI

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.

TERMINOLOGIA NA LUZIE

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

"Przy użyciu tej zmiennej [...]" (strona 145)
"Zacznijmy od zdefiniowania wymienionych stałych (dodatkowe komentarze objaśniające znaczenie zmiennej [...]" oraz "Ciekawą zmienną jest PADDLE_START_Y [...]" (strona 154)

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.

CZY KSIĄŻKA JEST WARTA ZAKUPU?

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!

"JavaScript od podstaw"

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.

PODOBNE ARTYKUŁY