Asynchroniczność w JavaScript to temat, o którym każdy, kogo pytałam, mówił to samo: „To jest ten moment, kiedy JavaScript przestaje mieć sens, a potem nagle zaczyna mieć sens zupełnie inny niż myślałaś.”

Mieli rację w obu częściach tego zdania.

Po tygodniach walki z tym tematem – dosłownie tygodniach, nie dniach, jak przy poprzednich Learning Logach – w końcu czuję, że rozumiem obietnice (promises) i składnię async/await na tyle, żeby napisać o tym w sposób, który mógłby zaoszczędzić komuś innemu część tej frustracji.

Dziś w Learning Log #8 pokażę Wam, dlaczego kod w JavaScript nie zawsze wykonuje się w kolejności, w jakiej go piszemy, jak wyglądała ewolucja rozwiązywania tego problemu (od wywołań zwrotnych, przez obietnice, po async/await), i jakie konkretne błędy sprawiły, że ten temat kosztował mnie więcej godzin niż cała reszta JavaScriptu razem wzięta.

Dlaczego ten temat jest tak trudny – problem u podstaw

Założenie, które trzeba porzucić

Ucząc się Javy, a potem podstaw JavaScriptu, przyzwyczaiłam się do jednej fundamentalnej zasady: kod wykonuje się linijka po linijce, od góry do dołu, w kolejności, w jakiej go napisałam.

javascript

console.log('Pierwsze');
console.log('Drugie');
console.log('Trzecie');

Wynik jest oczywisty: „Pierwsze”, potem „Drugie”, potem „Trzecie”. Zawsze w tej kolejności.

Problem zaczyna się, kiedy JavaScript musi na coś poczekać – na odpowiedź z serwera, na wczytanie pliku, na upłynięcie określonego czasu. I tu okazuje się, że JavaScript nie czeka grzecznie w miejscu, tylko leci dalej do kolejnej linijki kodu, zanim operacja oczekująca się zakończy.

Prosty przykład, który pokazuje ten problem:

javascript

console.log('Pierwsze');

setTimeout(function() {
    console.log('Drugie (opóźnione)');
}, 2000);

console.log('Trzecie');

Intuicyjne oczekiwanie: Pierwsze, Drugie (po 2 sekundach), Trzecie

Rzeczywisty wynik: Pierwsze, Trzecie, Drugie (po 2 sekundach)

WTF moment #1, ten fundamentalny: „Dlaczego 'Trzecie’ pojawia się PRZED 'Drugie’, skoro w kodzie jest napisane po nim?!”

Dlaczego JavaScript działa w ten sposób

JavaScript jest jednowątkowy (single-threaded) – w danym momencie może robić tylko jedną rzecz. Gdyby przy każdym oczekiwaniu (na serwer, na timer, na dowolną operację trwającą jakiś czas) zatrzymywał się i czekał bezczynnie, cała strona internetowa by „zamarzała” – nie dałoby się kliknąć przycisku, przewinąć strony, nic.

Rozwiązaniem jest model asynchroniczny – JavaScript „odkłada na bok” operacje, które wymagają czekania, kontynuuje wykonywanie reszty kodu, a kiedy odłożona operacja się zakończy, wraca do niej i wykonuje jej dalszą część.

Analogia, która w końcu do mnie dotarła:

Wyobraź sobie, że gotujesz obiad. Wkładasz ziemniaki do gotowania (to potrwa 20 minut). Nie stoisz bezczynnie przy garnku przez 20 minut – zajmujesz się w tym czasie krojeniem warzyw, przygotowaniem mięsa. Kiedy timer przypomni, że ziemniaki są gotowe, wracasz do nich.

JavaScript robi dokładnie to samo z kodem – „wkłada ziemniaki do gotowania” (operację asynchroniczną), leci dalej do następnych linijek, a kiedy operacja się zakończy, wraca i wykonuje to, co miało się stać po jej zakończeniu.

Wywołania zwrotne (callbacks) – pierwsze rozwiązanie problemu

Jak to działało, zanim poznałam coś lepszego

Zanim poznałam obietnice (promise), JavaScript rozwiązywał asynchroniczność za pomocą funkcji zwrotnych (callback functions) – funkcji przekazywanych jako argument, która wykonuje się dopiero po zakończeniu operacji asynchronicznej.

javascript

function pobierzDaneUzytkownika(id, funkcjaZwrotna) {
    setTimeout(function() {
        const uzytkownik = { id: id, imie: 'Anna' };
        funkcjaZwrotna(uzytkownik);
    }, 1000);
}

pobierzDaneUzytkownika(1, function(uzytkownik) {
    console.log('Otrzymano użytkownika:', uzytkownik);
});

To rozwiązywało podstawowy problem – kod wewnątrz funkcji zwrotnej wykonuje się dopiero, kiedy dane faktycznie są gotowe, nie wcześniej.

Problem, który pojawiał się przy złożonych operacjach – „piekło wywołań zwrotnych”

Kiedy trzeba było wykonać kilka operacji asynchronicznych jedna po drugiej (na przykład: pobierz użytkownika, potem na podstawie jego ID pobierz jego zamówienia, potem na podstawie zamówień pobierz szczegóły produktów), kod zaczynał wyglądać tak:

javascript

pobierzUzytkownika(1, function(uzytkownik) {
    pobierzZamowienia(uzytkownik.id, function(zamowienia) {
        pobierzSzczegolyProduktu(zamowienia[0].produktId, function(produkt) {
            pobierzOpinieOProdukcie(produkt.id, function(opinie) {
                console.log('Wreszcie mam wszystkie dane:', opinie);
// im głębiej, tym trudniej czytać
            });
        });
    });
});

To zjawisko ma nawet swoją nazwę – „callback hell” (piekło wywołań zwrotnych), ze względu na charakterystyczny kształt kodu przypominający schody prowadzące coraz głębiej w prawo.

WTF moment #2: „Jak ktokolwiek czyta i debuguje kod, który wygląda jak trójkąt?!”

Zrozumienie tego problemu było dla mnie kluczowe, żeby docenić, dlaczego wprowadzono obietnice – to nie była zmiana „dla mody”, tylko realna odpowiedź na realny problem czytelności i zarządzania kodem.

Obietnice (Promises) – eleganckie rozwiązanie

Czym jest obietnica

Obietnica (Promise) to obiekt reprezentujący ostateczny wynik operacji asynchronicznej – może zostać spełniona (fulfilled, operacja się powiodła) albo odrzucona (rejected, operacja się nie powiodła).

Analogia, która pomogła mi to zrozumieć:

Obietnica to jak numerek w McDonald’s. Zamawiasz jedzenie (rozpoczynasz operację asynchroniczną), dostajesz numerek (obietnicę) – jeszcze nie masz jedzenia, ale masz coś, co reprezentuje przyszłe jedzenie. Kiedy jedzenie jest gotowe (obietnica spełniona), możesz je odebrać. Jeśli restauracja ma problem i nie może zrealizować zamówienia (obietnica odrzucona), dostajesz inną informację.

Podstawowa składnia

javascript

function pobierzDaneUzytkownika(id) {
    return new Promise(function(resolve, reject) {
        setTimeout(function() {
            if (id > 0) {
                resolve({ id: id, imie: 'Anna' });
            } else {
                reject('Nieprawidłowe ID użytkownika');
            }
        }, 1000);
    });
}

pobierzDaneUzytkownika(1)
    .then(function(uzytkownik) {
        console.log('Sukces:', uzytkownik);
    })
    .catch(function(blad) {
        console.log('Błąd:', blad);
    });

Kluczowe elementy:

• resolve() – wywoływane, kiedy operacja się powiodła
• reject() – wywoływane, kiedy operacja się nie powiodła
• .then() – kod wykonujący się po pomyślnym zakończeniu
• .catch() – kod wykonujący się w przypadku błędu

Łańcuchowanie obietnic – rozwiązanie problemu „piekła wywołań zwrotnych”

To był dla mnie moment przełomowy – zamiast zagnieżdżania funkcji w funkcjach w funkcjach, obietnice można łańcuchować:

javascript

pobierzUzytkownika(1)
    .then(function(uzytkownik) {
        return pobierzZamowienia(uzytkownik.id);
    })
    .then(function(zamowienia) {
        return pobierzSzczegolyProduktu(zamowienia[0].produktId);
    })
    .then(function(produkt) {
        return pobierzOpinieOProdukcie(produkt.id);
    })
    .then(function(opinie) {
        console.log('Wreszcie mam wszystkie dane:', opinie);
    })
    .catch(function(blad) {
        console.log('Coś poszło nie tak w którymkolwiek kroku:', blad);
    });

Różnica wizualna jest ogromna – kod płynie w dół, nie w prawo. I co szczególnie doceniłam: jeden .catch() na końcu łapie błąd z DOWOLNEGO miejsca w łańcuchu, zamiast konieczności obsługi błędu osobno w każdej zagnieżdżonej funkcji zwrotnej.

WTF moment #3, ale w dobrym sensie: „Czekaj, to jedna linijka .catch() obsługuje błędy z czterech różnych operacji naraz?!”

Async/Await – składnia, która wszystko zmieniła

Dlaczego to było moje „aha!”

Po tygodniu oswajania się z .then() i .catch(), natrafiłam na składnię async/await, która – jak się okazało – to po prostu wygodniejszy sposób pisania tego samego, co robią obietnice, ale wyglądający jak zwykły, sekwencyjny kod.

javascript

async function pobierzWszystkieDane() {
    try {
        const uzytkownik = await pobierzUzytkownika(1);
        const zamowienia = await pobierzZamowienia(uzytkownik.id);
        const produkt = await pobierzSzczegolyProduktu(zamowienia[0].produktId);
        const opinie = await pobierzOpinieOProdukcie(produkt.id);

        console.log('Wreszcie mam wszystkie dane:', opinie);
    } catch (blad) {
        console.log('Coś poszło nie tak:', blad);
    }
}

pobierzWszystkieDane();

To wygląda niemal identycznie jak zwykły, synchroniczny kod! Żadnych .then(), żadnego zagnieżdżania – po prostu linijka po linijce, jakby wszystko działo się w kolejności (mimo że pod spodem dalej jest to asynchroniczne).

Kluczowe elementy składni

• async – słowo kluczowe umieszczane przed definicją funkcji, oznaczające, że funkcja będzie zawierała operacje asynchroniczne i automatycznie zwraca obietnicę.
• await – słowo kluczowe używane WEWNĄTRZ funkcji async, „wstrzymujące” wykonanie tej konkretnej funkcji (nie całego programu!) do momentu, aż obietnica się rozstrzygnie.
• try/catch – standardowy mechanizm obsługi błędów w JavaScript, który przy async/await zastępuje .catch() z obietnic.

Moment, w którym w końcu zrozumiałam różnicę między „wstrzymaniem funkcji” a „zamrożeniem programu”

To była kluczowa rzecz, którą myliłam przez dobry tydzień. await nie zamraża całej strony internetowej – zamraża tylko wykonanie tej jednej konkretnej funkcji, w której się znajduje. Reszta programu (obsługa kliknięć, inne funkcje) działa dalej normalnie.

Przykład, który to zilustrował:

javascript

async function wolnaOperacja() {
    console.log('Zaczynam wolną operację');
    await new Promise(resolve => setTimeout(resolve, 3000));
    console.log('Wolna operacja zakończona');
}

wolnaOperacja();
console.log('Ten tekst pojawi się NATYCHMIAST, nie czeka na wolnaOperacja()');

Kolejność wykonania:

1. „Zaczynam wolną operację”
2. „Ten tekst pojawi się NATYCHMIAST…” (bo wolnaOperacja() nie blokuje reszty kodu)
3. Po 3 sekundach: „Wolna operacja zakończona”

Praktyczny projekt – pobieranie danych z prawdziwego API

Po opanowaniu teorii, zbudowałam mój pierwszy projekt wykorzystujący asynchroniczność w praktyce – prostą wyszukiwarkę informacji o miastach korzystającą z darmowego, publicznego API pogodowego.

javascript

async function pobierzPogodeDlaMiasta(nazwaMiasta) {
    const kluczApi = 'TWOJ_KLUCZ_API';
    const url = `https://api.przykladowaPogoda.com/dane?miasto=${nazwaMiasta}&key=${kluczApi}`;

    try {
        pokazLadowanie(true);

        const odpowiedz = await fetch(url);

        if (!odpowiedz.ok) {
            throw new Error(`Błąd serwera:${odpowiedz.status}`);
        }

        const dane = await odpowiedz.json();

        wyswietlPogode(dane);

    } catch (blad) {
        wyswietlKomunikatBledu('Nie udało się pobrać danych pogodowych: ' + blad.message);
    } finally {
        pokazLadowanie(false);
    }
}

function wyswietlPogode(dane) {
    const kontener = document.getElementById('wynikPogody');
    kontener.innerHTML = `
        <h3>${dane.miasto}</h3>
        <p>Temperatura:${dane.temperatura}°C</p>
        <p>Warunki:${dane.opis}</p>
    `;
}

function wyswietlKomunikatBledu(wiadomosc) {
    const kontener = document.getElementById('wynikPogody');
    kontener.innerHTML = `<p class="blad">${wiadomosc}</p>`;
}

function pokazLadowanie(czyPokazac) {
    const spinner = document.getElementById('ladowanie');
    spinner.style.display = czyPokazac ? 'block' : 'none';
}

// Podpięcie do przycisku
document.getElementById('przyciskSzukaj').addEventListener('click', function() {
    const miasto = document.getElementById('inputMiasto').value;
    pobierzPogodeDlaMiasta(miasto);
});

Co się nauczyłam budując ten projekt:

• fetch() – wbudowana funkcja JavaScript do pobierania danych z zewnętrznych źródeł, zwracająca obietnicę
• response.json() – konwersja odpowiedzi serwera na obiekt JavaScript, sama w sobie też asynchroniczna (stąd drugi await)
• try/catch/finally – blok finally wykonuje się zawsze, niezależnie od tego, czy operacja się powiodła czy nie (idealne miejsce na ukrycie animacji ładowania)
• Obsługa różnych typów błędów – błąd sieci (serwer nie odpowiada) versus błąd logiczny (serwer odpowiedział, ale z kodem błędu)
• Łączenie manipulacji DOM (o czym pisałam w poprzednim Learning Logu) z operacjami asynchronicznymi

Czas realizacji: 5 godzin, rozłożone na cztery dni – znacznie dłużej niż poprzednie mini-projekty, ale też znacznie więcej się nauczyłam.

Typowe błędy, które popełniłam – i jak je naprawiłam

Błąd 1: Zapominanie o await

javascript

// ŹLE
async function pobierzDane() {
    const wynik = fetch('<https://przykladowe-api.com/dane>');
    console.log(wynik); // Promise { <pending> } - nie dane, tylko sama obietnica!
}

// DOBRZE
async function pobierzDane() {
    const wynik = await fetch('<https://przykladowe-api.com/dane>');
    console.log(wynik); // teraz faktyczna odpowiedź
}

Lekcja: Bez await, dostajesz samą obietnicę (obiekt „w trakcie realizacji”), nie faktyczny wynik operacji. To był mój najczęstszy błąd przez pierwsze dwa tygodnie – kod „działał” bez błędu, ale wyświetlał kompletnie bezużyteczne dane.

Błąd 2: Używanie await poza funkcją async

javascript

// ŹLE - błąd składni
function pobierzDane() {
    const wynik = await fetch('<https://przykladowe-api.com/dane>');
}

// DOBRZE
async function pobierzDane() {
    const wynik = await fetch('<https://przykladowe-api.com/dane>');
}

Lekcja: await działa TYLKO wewnątrz funkcji oznaczonej jako async. To była prosta zasada, ale zapominałam o niej regularnie, szczególnie przy pisaniu krótkich funkcji pomocniczych.

Błąd 3: Sekwencyjne wykonywanie operacji, które mogły działać równolegle

javascript

// NIEOPTYMALNIE - operacje wykonują się jedna po drugiej, mimo że nie muszą
async function pobierzWszystko() {
    const uzytkownik = await pobierzUzytkownika(1); // czeka 1 sekundę
    const produkty = await pobierzProdukty(); // czeka kolejną sekundę
// razem: 2 sekundy, mimo że te operacje nie zależą od siebie!
}

// LEPIEJ - operacje wykonują się jednocześnie
async function pobierzWszystko() {
    const [uzytkownik, produkty] = await Promise.all([
        pobierzUzytkownika(1),
        pobierzProdukty()
    ]);
// razem: tylko 1 sekunda, bo obie operacje leciały równolegle!
}

Lekcja: Promise.all() pozwala uruchomić kilka niezależnych operacji asynchronicznych jednocześnie, zamiast czekać na jedną, żeby zacząć następną. To był koncept, który zrozumiałam dopiero po przeanalizowaniu, dlaczego mój projekt z pogodą dla kilku miast naraz działał wolniej niż powinien.

Błąd 4: Brak obsługi błędów

javascript

// RYZYKOWNIE - brak try/catch
async function pobierzDane() {
    const odpowiedz = await fetch(url); // co jeśli serwer nie odpowiada?
    const dane = await odpowiedz.json();
    return dane;
}

// BEZPIECZNIE
async function pobierzDane() {
    try {
        const odpowiedz = await fetch(url);
        const dane = await odpowiedz.json();
        return dane;
    } catch (blad) {
        console.error('Nie udało się pobrać danych:', blad);
        return null;
    }
}

Lekcja: Bez bloku try/catch, błąd w operacji asynchronicznej powoduje niewyjaśniony „cichy” upadek funkcji, bez żadnej informacji dla użytkownika, co poszło nie tak. To szczególnie problematyczne przy pracy z zewnętrznymi API, które mogą nie odpowiadać z wielu różnych powodów (brak internetu, przeciążony serwer, nieprawidłowe zapytanie).

Dlaczego warto było poznać wywołania zwrotne, zanim poznałam obietnice

Zastanawiałam się, czy nie lepiej było od razu uczyć się async/await, pomijając wywołania zwrotne i obietnice jako „przestarzałe”. Po przejściu przez wszystkie trzy etapy jestem przekonana, że ta kolejność miała sens.

Zrozumienie wywołań zwrotnych pokazało mi PROBLEM, który asynchroniczność w ogóle stwarza.

Poznanie obietnic pokazało mi, JAK ten problem został rozwiązany na poziomie koncepcyjnym.

Zrozumienie async/await pokazało mi wygodniejszy SPOSÓB ZAPISU tego samego rozwiązania.

Gdybym zaczęła od razu od async/await, prawdopodobnie umiałabym pisać kod, który działa, ale bez zrozumienia, co dokładnie dzieje się pod spodem – co utrudniałoby debugowanie w momencie, gdy coś pójdzie nie tak w bardziej złożonym scenariuszu.

Zasoby, które pomogły mi zrozumieć asynchroniczność

1. „JavaScript Visualized: Promises” – Lydia Hallie (★★★★★)

Wizualne, animowane wyjaśnienie, jak dokładnie obietnice działają „pod maską”. To był zasób, który sprawił, że nagle wszystko „kliknęło” po tygodniu czytania czysto tekstowych wyjaśnień.

2. JavaScript.info – rozdziały o Promise i Async/await (★★★★★)

Jak zawsze przy tym źródle – szczegółowe, dokładne wyjaśnienia z licznymi przykładami. Wracałam do konkretnych fragmentów wielokrotnie.

3. „What the heck is the event loop anyway?” – Philip Roberts (★★★★★)

Prezentacja konferencyjna (dostępna na YouTube) wyjaśniająca pętlę zdarzeń (event loop) – mechanizm, dzięki któremu JavaScript w ogóle może obsługiwać operacje asynchroniczne, mimo że jest jednowątkowy. To wyjaśnienie dało mi zrozumienie „dlaczego” na poziomie znacznie głębszym niż samo „jak pisać kod”.

4. Praktyka – budowanie własnych mini-projektów z prawdziwymi API

Żadne wyjaśnienie teoretyczne nie zastąpiło realnego zderzenia się z błędami przy pracy z prawdziwym, zewnętrznym API, które czasem nie odpowiada, zwraca nieoczekiwane dane, albo działa wolniej niż się spodziewałam.

Plany na listopad – co dalej

Tydzień 1-2 października (kontynuacja):

• Utrwalenie async/await przez kolejne mniejsze projekty
• Praca z kilkoma różnymi publicznymi API dla praktyki

Listopad:

• Pierwszy kontakt z React – framework, który intensywnie wykorzystuje te same koncepty asynchroniczności, tylko w innym kontekście
• Może pierwsza integracja JavaScript z projektami WordPress dla praktycznego zastosowania

Cel realistyczny: Czuć się na tyle pewnie z asynchronicznością, żeby móc czytać i rozumieć kod innych osób wykorzystujący te koncepty, nawet jeśli sama jeszcze nie piszę wszystkiego od razu bezbłędnie.

FAQ – asynchroniczność w JavaScript

Czy muszę rozumieć wywołania zwrotne, jeśli i tak będę używać tylko async/await?

Nie jest to absolutnie konieczne, ale mocno polecam przynajmniej podstawowe zrozumienie problemu, który wywołania zwrotne rozwiązywały. Ułatwia to zrozumienie, DLACZEGO async/await wygląda tak, jak wygląda, zamiast traktowania tej składni jako magicznej formułki do zapamiętania.

Ile czasu zajęła Ci nauka tego tematu?

Znacznie więcej niż poprzednich tematów – około trzech tygodni intensywniejszej nauki, w porównaniu do jednego-dwóch tygodni przy wcześniejszych Learning Logach. To zdecydowanie najtrudniejszy temat JavaScriptu, z jakim się do tej pory zmierzyłam.

Czy asynchroniczność jest unikalna dla JavaScriptu?

Nie – większość nowoczesnych języków programowania ma jakąś formę obsługi operacji asynchronicznych, w tym Java (którą poznałam wcześniej), choć mechanizmy i składnia różnią się znacząco. Koncepcja „czekania na coś bez blokowania całego programu” jest uniwersalna w programowaniu.

Co było najtrudniejsze w tym temacie?

Zdecydowanie zrozumienie, dlaczego kod nie wykonuje się w kolejności, w jakiej go napisałam – to fundamentalnie łamało moje dotychczasowe intuicje wyniesione z Javy. Dopiero po zrozumieniu pętli zdarzeń (event loop) na poziomie koncepcyjnym, reszta zaczęła mieć sens.

Czy warto uczyć się wszystkich trzech podejść (wywołania zwrotne, obietnice, async/await), czy tylko najnowszego?

Polecam przynajmniej podstawowe zrozumienie wszystkich trzech, nawet jeśli w praktyce będziesz pisać kod głównie z użyciem async/await. Duża część istniejącego kodu (w bibliotekach, starszych projektach, dokumentacji) nadal korzysta z obietnic bezpośrednio, a zrozumienie wywołań zwrotnych pomaga docenić, dlaczego w ogóle powstały nowsze rozwiązania.

Podsumowanie – Learning Log #8

Asynchroniczność w JavaScript okazała się najtrudniejszym tematem, z jakim zmierzyłam się do tej pory w mojej nauce programowania – trudniejszym niż podstawy Javy, trudniejszym niż manipulacja DOM, trudniejszym niż cokolwiek wcześniej.

Co osiągnęłam:

• Rozumiem, dlaczego JavaScript nie wykonuje kodu zawsze w kolejności zapisu
• Znam historię rozwiązań tego problemu – od wywołań zwrotnych, przez obietnice, po async/await
• Potrafię pisać funkcje asynchroniczne z poprawną obsługą błędów
• Rozumiem różnicę między operacjami sekwencyjnymi a równoległymi (Promise.all())
• Zbudowałam działający projekt pobierający dane z prawdziwego, zewnętrznego API
• Znam cztery najczęstsze błędy początkujących i wiem, jak ich unikać

Najważniejsza lekcja tego etapu:

Niektóre tematy w programowaniu wymagają nie tylko więcej czasu, ale wręcz zmiany sposobu myślenia. Asynchroniczność nie jest po prostu „trudniejszą składnią” – wymaga porzucenia fundamentalnego założenia o tym, jak w ogóle działa wykonywanie kodu.

Trzy tygodnie frustracji, diagramy strzałkami na kartce papieru, i wieczory gapienia się w konsolę pokazującą undefined – to była cena zrozumienia tego tematu. Ale teraz, kiedy w końcu „kliknęło”, czuję satysfakcję, jakiej nie dała mi żadna łatwiejsza lekcja.

Czasem najtrudniejsze tematy dają najwięcej, kiedy się w końcu poddadzą.

PS: Pamiętasz swój moment zrozumienia asynchroniczności? Albo może dopiero się z nią zmagasz i chcesz się podzielić frustracją? Zostaw komentarz – obiecuję, że rozumiem tę walkę lepiej niż większość rzeczy, o których pisałam do tej pory!

Artykuł Learning Log #8: Asynchroniczność w JavaScript – promises i async/await pochodzi z serwisu To co najważniejsze.

Brzmi banalnie, prawda? Przycisk zmienia kolor. Wielka rzecz.

Ale to JA to zrobiłam. Napisałam kod, który sprawił, że strona internetowa reaguje na to, co robi użytkownik. Nie odświeżam strony. Nie klikam linku. Element na ekranie po prostu… reaguje. Na żywo.

Po dwóch miesiącach mikroedukacji w wakacje (o czym pisałam w poprzednim wpisie) i powrocie do pełnego tempa we wrześniu, wreszcie dotarłam do tematu, na który czekałam najbardziej: manipulacja DOM i zdarzenia w JavaScript. To jest moment, w którym JavaScript przestaje być „kolejnym językiem do nauki” i staje się narzędziem, które tchnie życie w strony internetowe.

Dziś w Learning Log #7 pokażę Wam czym jest DOM, jak JavaScript nim manipuluje, czym są nasłuchiwacze zdarzeń, i opiszę te momenty „wow”, kiedy pierwszy raz zobaczyłam własny kod reagujący na kliknięcie myszką.

Czym jest DOM – wyjaśnienie które w końcu do mnie dotarło

Problem: rozumiałam składnię, ale nie rozumiałam koncepcji

Przez pierwsze tygodnie nauki JavaScript umiałam pisać pętle, funkcje, warunki – ale nie rozumiałam, jak to wszystko łączy się ze stroną internetową, którą widzę w przeglądarce.

To była luka, która blokowała mnie od tworzenia czegokolwiek realnego.

Wyjaśnienie które zadziałało – analogia z domem

DOM (Document Object Model, po polsku: obiektowy model dokumentu) to sposób, w jaki przeglądarka „widzi” stronę internetową – nie jako tekst HTML, ale jako strukturę drzewa obiektów, którymi można manipulować.

Analogia która mi pomogła:

Wyobraź sobie dom (budynek, nie stronę). HTML to plan architektoniczny domu – papierowy dokument opisujący, gdzie są ściany, drzwi, okna.

DOM to sam dom, zbudowany na podstawie tego planu – fizyczna struktura, którą można otworzyć, zamknąć, przemalować, przestawić meble.

HTML (plan):

html

<div id="salon">
    <button id="przycisk">Kliknij mnie</button>
    <p id="tekst">Witaj!</p>
</div>

DOM (dom zbudowany z planu): Przeglądarka tworzy strukturę drzewa:

document
  └── div#salon
        ├── button#przycisk
        └── p#tekst

JavaScript może wejść do tego „domu” i:

• Otworzyć drzwi (znaleźć element)
• Przemalować ścianę (zmienić styl)
• Przestawić meble (zmienić strukturę)
• Zainstalować dzwonek reagujący na naciśnięcie (dodać nasłuchiwacz zdarzenia)

Pierwsza manipulacja DOM – znajdowanie elementów

Podstawowe metody wyszukiwania elementów:

javascript

// Po ID (najczęściej używane)
const przycisk = document.getElementById('przycisk');

// Po klasie (może zwrócić wiele elementów)
const wszystkieKarty = document.getElementsByClassName('karta');

// Po selektorze CSS (najbardziej elastyczne)
const pierwszyPrzycisk = document.querySelector('.przycisk');
const wszystkiePrzyciski = document.querySelectorAll('.przycisk');

WTF moment #1: „Czekaj, mogę wyszukiwać elementy DOKŁADNIE tak samo jak w CSS?!”

To była pierwsza rzecz, która sprawiła, że JavaScript nagle „kliknął” (nie mylić z tym przyciskiem, o którym za chwilę). Znałam już selektory CSS z pracy z WordPressem. Nagle mogłam użyć tej samej wiedzy do wyszukiwania elementów w JavaScript.

Manipulacja DOM – zmienianie tego, co widać na ekranie

Zmiana tekstu

javascript

const naglowek = document.getElementById('naglowek');
naglowek.textContent = 'Nowy tekst!';

Pierwsza rzecz, którą zrobiłam: Zmiana powitania na stronie w zależności od pory dnia.

javascript

const godzina = new Date().getHours();
const powitanie = document.getElementById('powitanie');

if (godzina < 12) {
    powitanie.textContent = 'Dzień dobry!';
} else if (godzina < 18) {
    powitanie.textContent = 'Dzień dobry (popołudniu)!';
} else {
    powitanie.textContent = 'Dobry wieczór!';
}

Efekt na ekranie: Odświeżam stronę – tekst się zmienia w zależności od tego, o której godzinie to robię. Proste, ale to był mój pierwszy prawdziwy moment „wow”.

Zmiana stylu (CSS przez JavaScript)

javascript

const przycisk = document.getElementById('przycisk');
przycisk.style.backgroundColor = 'niebieski';
przycisk.style.color = 'biały';
przycisk.style.padding = '10px 20px';

Zmiana klasy (lepsza praktyka niż zmiana pojedynczych stylów):

javascript

const karta = document.querySelector('.karta');
karta.classList.add('podswietlona');
karta.classList.remove('nieaktywna');
karta.classList.toggle('rozwiniety'); // dodaje jeśli nie ma, usuwa jeśli jest

Dlaczego classList jest lepsze niż bezpośrednie zmienianie style:

Bezpośrednia zmiana stylu (element.style.color = 'red') miesza logikę JavaScript ze stylowaniem CSS. Lepsza praktyka to przygotowanie klas CSS wcześniej (np. .aktywny { color: red; }) i dodawanie/usuwanie tych klas przez JavaScript.

Tworzenie nowych elementów dynamicznie

To była kolejna rzecz, która mnie zachwyciła – możliwość tworzenia całkowicie nowych elementów HTML za pomocą kodu, bez wcześniejszego pisania ich w pliku HTML.

javascript

function dodajZadanie(tresc) {
// Tworzę nowy element
    const nowyElement = document.createElement('li');
    nowyElement.textContent = tresc;
    nowyElement.classList.add('zadanie');

// Dodaję go do listy na stronie
    const lista = document.getElementById('listaZadan');
    lista.appendChild(nowyElement);
}

dodajZadanie('Nauczyć się manipulacji DOM');
dodajZadanie('Zbudować listę zadań');

WTF moment #2: „Mogę tworzyć elementy które nigdy nie istniały w oryginalnym HTML?!”

To otworzyło mi drzwi do zrozumienia, jak działają aplikacje typu lista zadań, komentarze dodawane na żywo, czy dynamiczne galerie zdjęć.

Zdarzenia (events) – jak strona reaguje na użytkownika

Czym są zdarzenia

Zdarzenie to sygnał, że coś się wydarzyło na stronie – kliknięcie, najechanie myszką, wpisanie tekstu, przewinięcie strony, załadowanie się dokumentu.

Nasłuchiwacz zdarzenia (event listener) to fragment kodu, który „czeka” na konkretne zdarzenie i uruchamia się, kiedy ono nastąpi.

Pierwszy nasłuchiwacz zdarzenia – moment przełomowy

javascript

const przycisk = document.getElementById('przycisk');

przycisk.addEventListener('click', function() {
    console.log('Kliknięto przycisk!');
});

To był moment, o którym pisałam na początku posta. Kliknęłam przycisk w przeglądarce, i w konsoli pojawił się mój tekst. Coś, co napisałam, zareagowało na moje działanie w czasie rzeczywistym.

Rozwinięcie do praktycznego przykładu – zmiana koloru po kliknięciu:

javascript

const przycisk = document.getElementById('przycisk');
let jestAktywny = false;

przycisk.addEventListener('click', function() {
    jestAktywny = !jestAktywny; // odwrócenie wartości logicznej

    if (jestAktywny) {
        przycisk.style.backgroundColor = 'zielony';
        przycisk.textContent = 'Aktywne!';
    } else {
        przycisk.style.backgroundColor = 'szary';
        przycisk.textContent = 'Kliknij mnie';
    }
});

Rodzaje zdarzeń które poznałam

Zdarzenia myszy:

javascript

element.addEventListener('click', funkcja);        // kliknięcie
element.addEventListener('mouseover', funkcja);     // najechanie myszką
element.addEventListener('mouseout', funkcja);      // zjechanie myszką
element.addEventListener('dblclick', funkcja);      // podwójne kliknięcie

Zdarzenia klawiatury:

javascript

element.addEventListener('keydown', funkcja);       // naciśnięcie klawisza
element.addEventListener('keyup', funkcja);          // puszczenie klawisza

Zdarzenia formularzy:

javascript

formularz.addEventListener('submit', funkcja);       // wysłanie formularza
input.addEventListener('input', funkcja);             // zmiana wartości podczas pisania
input.addEventListener('change', funkcja);            // zmiana wartości (po opuszczeniu pola)

Zdarzenia strony:

javascript

window.addEventListener('load', funkcja);             // strona się załadowała
window.addEventListener('scroll', funkcja);            // przewinięcie strony
window.addEventListener('resize', funkcja);            // zmiana rozmiaru okna

Obiekt zdarzenia – dodatkowe informacje o tym, co się stało

Kiedy funkcja obsługująca zdarzenie się uruchamia, automatycznie dostaje dostęp do obiektu zdarzenia – zawierającego szczegółowe informacje o tym, co dokładnie się wydarzyło.

javascript

przycisk.addEventListener('click', function(zdarzenie) {
    console.log(zdarzenie.target);        // który element został kliknięty
    console.log(zdarzenie.clientX);       // pozycja X kursora
    console.log(zdarzenie.clientY);       // pozycja Y kursora
});

Praktyczne zastosowanie – walidacja formularza podczas pisania:

javascript

const inputEmail = document.getElementById('email');
const komunikat = document.getElementById('komunikatEmail');

inputEmail.addEventListener('input', function(zdarzenie) {
    const wartosc = zdarzenie.target.value;

    if (wartosc.includes('@')) {
        komunikat.textContent = 'Wygląda dobrze!';
        komunikat.style.color = 'zielony';
    } else {
        komunikat.textContent = 'Brakuje znaku @';
        komunikat.style.color = 'czerwony';
    }
});

WTF moment #3: „Mogę sprawdzać co użytkownik pisze W CZASIE RZECZYWISTYM, bez klikania jakiegokolwiek przycisku 'sprawdź’?!”

To był moment, który uświadomił mi, dlaczego nowoczesne formularze internetowe pokazują błędy na bieżąco, zamiast dopiero po wysłaniu.

Mój pierwszy prawdziwy projekt interaktywny – lista zadań

Po dwóch tygodniach nauki manipulacji DOM i zdarzeń, zbudowałam mój pierwszy w pełni interaktywny projekt – prostą listę zadań (to-do list).

HTML:

html

<div class="kontener">
    <h1>Moja Lista Zadań</h1>
    <div class="formularz">
        <input type="text" id="noweZadanie" placeholder="Wpisz zadanie...">
        <button id="dodajPrzycisk">Dodaj</button>
    </div>
    <ul id="listaZadan"></ul>
</div>

JavaScript:

javascript

const input = document.getElementById('noweZadanie');
const przyciskDodaj = document.getElementById('dodajPrzycisk');
const lista = document.getElementById('listaZadan');

function dodajZadanie() {
    const tresc = input.value.trim();

// Walidacja - nie dodawaj pustych zadań
    if (tresc === '') {
        alert('Wpisz treść zadania!');
        return;
    }

// Tworzenie nowego elementu listy
    const nowyElement = document.createElement('li');
    nowyElement.classList.add('zadanie');

// Tekst zadania
    const tekstZadania = document.createElement('span');
    tekstZadania.textContent = tresc;

// Przycisk oznaczenia jako wykonane
    const przyciskWykonaj = document.createElement('button');
    przyciskWykonaj.textContent = '✓';
    przyciskWykonaj.classList.add('przycisk-wykonaj');

    przyciskWykonaj.addEventListener('click', function() {
        tekstZadania.classList.toggle('wykonane');
    });

// Przycisk usunięcia
    const przyciskUsun = document.createElement('button');
    przyciskUsun.textContent = '✗';
    przyciskUsun.classList.add('przycisk-usun');

    przyciskUsun.addEventListener('click', function() {
        nowyElement.remove();
    });

// Składanie wszystkiego razem
    nowyElement.appendChild(tekstZadania);
    nowyElement.appendChild(przyciskWykonaj);
    nowyElement.appendChild(przyciskUsun);
    lista.appendChild(nowyElement);

// Czyszczenie inputu po dodaniu
    input.value = '';
    input.focus();
}

// Dodawanie przez kliknięcie przycisku
przyciskDodaj.addEventListener('click', dodajZadanie);

// Dodawanie przez naciśnięcie Enter
input.addEventListener('keydown', function(zdarzenie) {
    if (zdarzenie.key === 'Enter') {
        dodajZadanie();
    }
});

Co się nauczyłam budując ten projekt:

• Łączenie manipulacji DOM z obsługą zdarzeń – to nie są osobne tematy, tylko dwa elementy tej samej całości
• Tworzenie zagnieżdżonych elementów dynamicznie (element wewnątrz elementu wewnątrz elementu)
• Wielokrotne nasłuchiwacze zdarzeń na różnych elementach jednocześnie
• trim() – usuwanie białych znaków z początku/końca tekstu (zapobiega dodawaniu „pustych” zadań ze spacjami)
• zdarzenie.key – sprawdzanie, który konkretnie klawisz został naciśnięty

Czas realizacji: 3 godziny (rozłożone na trzy dni po godzinie)

Porównanie: Pierwszy mini-projekt w lipcu (kalkulator) zajął mi 2 godziny, ale był statyczny w tym sensie, że nie tworzył nowych elementów. Lista zadań to pierwszy raz, kiedy strona rozrasta się i zmienia strukturę w odpowiedzi na to, co robi użytkownik.

Wyzwania techniczne – co sprawiało najwięcej trudności

1. Zrozumienie this wewnątrz nasłuchiwaczy zdarzeń

Problem:

javascript

przycisk.addEventListener('click', function() {
    console.log(this); // co to jest "this"?
});

W kontekście nasłuchiwacza zdarzenia, this odnosi się do elementu, na którym zdarzenie zostało zarejestrowane (czyli do samego przycisku).

Ale przy funkcji strzałkowej (arrow function) this zachowuje się inaczej:

javascript

przycisk.addEventListener('click', () => {
    console.log(this); // to NIE jest przycisk, tylko kontekst zewnętrzny
});

Lekcja: Przy pracy z DOM i zdarzeniami, zwykłe funkcje (function() {}) i funkcje strzałkowe (() => {}) zachowują się różnie względem this. To był mylący temat przez dobry tydzień.

2. Event bubbling – „wypływanie” zdarzeń

Problem: Kliknięcie na przycisk wewnątrz elementu <li> uruchamiało nasłuchiwacz zarejestrowany na samym <li>, mimo że kliknęłam tylko przycisk.

Wyjaśnienie: Zdarzenia w DOM „wypływają” od elementu, na którym się wydarzyły, w górę przez wszystkich rodziców w strukturze drzewa.

javascript

lista.addEventListener('click', function(zdarzenie) {
    console.log(zdarzenie.target); // dokładny element, który został kliknięty
    console.log(zdarzenie.currentTarget); // element, na którym zarejestrowano nasłuchiwacz
});

Praktyczne zastosowanie – delegacja zdarzeń (event delegation):

Zamiast dodawać osobny nasłuchiwacz do każdego elementu listy (co jest nieefektywne przy dynamicznie dodawanych elementach), dodaje się JEDEN nasłuchiwacz do rodzica i sprawdza, co dokładnie zostało kliknięte:

javascript

lista.addEventListener('click', function(zdarzenie) {
    if (zdarzenie.target.classList.contains('przycisk-usun')) {
        zdarzenie.target.closest('.zadanie').remove();
    }
});

WTF moment #4, ale w dobrym sensie: Ta technika rozwiązała problem, z którym walczyłam tydzień wcześniej, próbując dodawać nasłuchiwacze do elementów tworzonych dynamicznie.

3. Zapobieganie domyślnemu zachowaniu przeglądarki

Problem: Formularz po wysłaniu odświeżał całą stronę, co usuwało wszystkie wprowadzone dane.

Rozwiązanie:

javascript

formularz.addEventListener('submit', function(zdarzenie) {
    zdarzenie.preventDefault(); // blokuje domyślne odświeżenie strony
// reszta logiki obsługi formularza
});

Lekcja: Wiele elementów HTML ma wbudowane „domyślne zachowanie” (formularz wysyła i odświeża stronę, link przenosi na inną stronę). preventDefault() pozwala przejąć kontrolę i zdecydować, co ma się stać zamiast tego.

Momenty „wow” – lista moich ulubionych

Podsumowując te dwa tygodnie nauki, oto konkretne momenty, które sprawiły, że poczułam prawdziwą radość z programowania:

1. Pierwszy klik konsoli – kiedy console.log('Kliknięto!') faktycznie się pojawił po kliknięciu przycisku

2. Zmiana koloru w czasie rzeczywistym – przycisk zmieniający kolor tła po kliknięciu, bez odświeżania strony

3. Tworzenie elementów, których nigdy nie było w HTML – dodanie nowego zadania do listy, które fizycznie nie istniało w pliku HTML

4. Walidacja na żywo – komunikat błędu pojawiający się i znikający, kiedy piszę w polu formularza, bez klikania czegokolwiek

5. Delegacja zdarzeń działająca poprawnie – moment, kiedy zrozumiałam, dlaczego mój kod przestał działać po dodaniu nowych elementów, i jak to naprawić jednym uniwersalnym nasłuchiwaczem

6. Ukończona lista zadań – moment, kiedy mogłam dodać zadanie, oznaczyć je jako wykonane, i usunąć – wszystko bez odświeżania strony ani jednej linijki PHP

Zasoby, które pomogły mi zrozumieć DOM i zdarzenia

1. JavaScript.info – rozdział „Document” (★★★★★)

Najbardziej szczegółowe i zrozumiałe wyjaśnienie manipulacji DOM, jakie znalazłam. Wracałam do niego wielokrotnie.

2. MDN Web Docs – dokumentacja Event (★★★★★)

Kiedy potrzebowałam sprawdzić, jakie właściwości ma dany typ zdarzenia (np. co dokładnie zawiera obiekt zdarzenia przy keydown), dokumentacja MDN była niezastąpiona.

3. Traversy Media – „JavaScript DOM Crash Course” (★★★★★)

Godzinny film, który pokazuje budowanie kilku małych projektów interaktywnych na żywo. Zobaczenie procesu myślowego kogoś doświadczonego bardzo pomogło mi zrozumieć, jak łączyć poszczególne koncepty.

4. FreeCodeCamp – sekcja „DOM Manipulation” (★★★★☆)

Ćwiczenia praktyczne z natychmiastową weryfikacją. Trochę oderwane od kontekstu (pojedyncze zadania, nie cały projekt), ale świetne do utrwalenia składni.

Plany na wrzesień-październik – co dalej

Tydzień 1-2 września:

• Dokończenie tematu zdarzeń (event delegation, custom events)
• Rozbudowa listy zadań o zapisywanie w localStorage

Tydzień 3-4 września:

• Fetch API – pobieranie danych z zewnętrznych źródeł
• Praca z JSON w JavaScript

Październik:

• Pierwsze starcie z asynchronicznością (promises, async/await)
• Może pierwszy kontakt z React, jeśli poczuję się gotowa

Cel realistyczny: Do końca września chcę umieć budować w pełni funkcjonalne, interaktywne komponenty dla stron klientów – formularze z walidacją, proste kalkulatory, dynamiczne galerie.

FAQ – manipulacja DOM i zdarzenia w JavaScript

Czy manipulacja DOM to to samo co React/Vue?

Nie, ale jest fundamentem, na którym te frameworki się opierają. React i Vue „pod maską” też manipulują DOM, tylko robią to bardziej efektywnie i za pomocą swojej własnej, uproszczonej składni. Zrozumienie czystego (vanilla) DOM znacznie ułatwia późniejszą naukę frameworków.

Czy potrzebuję znać jQuery, żeby manipulować DOM?

Nie. jQuery było popularne, kiedy natywne API JavaScript do manipulacji DOM było bardziej niewygodne. Dzisiaj nowoczesny JavaScript (metody jak querySelector, classList, addEventListener) jest wystarczająco przyjazny, że jQuery stało się w dużej mierze zbędne dla nowych projektów.

Ile czasu zajęła Ci nauka tego tematu?

Około dwóch tygodni intensywniejszej nauki (po powrocie do pełnego tempa po wakacjach) – łącznie może 12-15 godzin, plus dodatkowy czas na budowę projektu listy zadań.

Co było najtrudniejsze w tym temacie?

Zdecydowanie zrozumienie event bubbling i delegacji zdarzeń. To jest koncept, który na papierze brzmi prosto, ale dopóki nie napotkałam realnego problemu (nasłuchiwacz nie działający na dynamicznie dodanych elementach), nie rozumiałam, po co to jest potrzebne.

Czy manipulacja DOM jest przydatna, jeśli pracuję głównie z WordPressem?

Zdecydowanie tak. Nawet przy pracy z gotowym CMS-em, umiejętność dodania własnego, lekkiego JavaScript do konkretnych interakcji (zamiast instalowania kolejnej wtyczki) to ogromna przewaga – i pod względem wydajności strony, i pod względem tego, co możesz zaoferować klientom.

Podsumowanie – Learning Log #7

Manipulacja DOM i zdarzenia w JavaScript to temat, który zmienił moje rozumienie tego, czym w ogóle jest programowanie frontendowe. Wcześniej JavaScript był dla mnie „kolejnym językiem ze składnią podobną do Javy”. Teraz jest narzędziem, które sprawia, że strony internetowe żyją.

Co osiągnęłam:

• Rozumiem czym jest DOM i jak przeglądarka go tworzy
• Potrafię wyszukiwać, tworzyć i modyfikować elementy dynamicznie
• Rozumiem nasłuchiwacze zdarzeń i obiekt zdarzenia
• Znam delegację zdarzeń i wiem, kiedy jej używać
• Zbudowałam pierwszy w pełni interaktywny projekt (lista zadań)
• Widzę bezpośrednie zastosowanie w pracy freelance

Najważniejsza lekcja tego etapu:

Programowanie frontendowe to nie pisanie kodu, który „coś robi”. To pisanie kodu, który reaguje.

Ten przycisk, który zmienia kolor po kliknięciu – to nie jest wielka rzecz techniczna. Ale to jest moment, w którym zrozumiałam, dlaczego ludzie kochają programowanie frontendu: piszesz coś, i to coś odpowiada Ci na żywo.

Po wakacyjnej przerwie i strategii mikroedukacji, wrzesień przywrócił mi pełne tempo – i przyniósł jeden z najbardziej satysfakcjonujących etapów nauki do tej pory.

PS: Pamiętasz swój pierwszy moment „wow” w programowaniu? Co to było? A jeśli dopiero zaczynasz naukę DOM i zdarzeń – z czym masz największe trudności? Zostaw komentarz, chętnie pomogę albo po prostu poczuję się mniej samotna w tym zachwycie nad zmieniającym kolor przyciskiem!

Artykuł Learning Log #7: JavaScript – manipulacja DOM, zdarzenia i pierwsza prawdziwa interaktywność pochodzi z serwisu To co najważniejsze.

Siedem dni. W lipcu byłam dumna z serii 45 dni z rzędu. Teraz patrzę na pusty plik script.js i czuję coś między winą a rezygnacją.

Nauka programowania w wakacje brzmi pięknie w teorii – „więcej czasu, luźniejszy grafik, może nawet uda się przyspieszyć”. Rzeczywistość: mniej czasu (szkoła zamknięta), więcej rozpraszaczy (upał, wyjazdy, dzieci non-stop w domu) i harmonogram, który sypie się codziennie.

Dziś, po dwóch miesiącach prób i błędów, dzielę się tym, co faktycznie zadziałało – i czego się nauczyłam o utrzymywaniu nawyku nauki, kiedy wszystkie zewnętrzne struktury znikają.

Dlaczego wakacje są tak trudne dla nawyku nauki

Problem 1: Znika struktura zewnętrzna

Przez rok szkolny mój dzień ma naturalne bloki: szkoła 8:00-16:00 = okno na pracę i naukę. Wakacje = zero tej struktury.

Skutek: Muszę SAMA tworzyć strukturę, zamiast korzystać z gotowej. To wymaga dodatkowej energii mentalnej, której mam mniej (bo jestem non-stop z dziećmi).

Problem 2: Siła woli jest już wyczerpana na coś innego

Wcześniej pisałam o wyczerpaniu siły woli (willpower depletion) w kontekście wieczornej nauki. W wakacje ten mechanizm działa cały dzień, nie tylko wieczorem.

Każda decyzja – jak zająć dzieci, jak poradzić sobie z przegrzaniem, jak nie zwariować od hałasu – zużywa tę samą pulę zasobów, której potrzebuję do nauki kodu.

Problem 3: Rozpraszacze są dosłownie w tym samym pokoju

W roku szkolnym: cisza, mogę się skupić 50 minut bez przerwy.

W wakacje: dziecko przychodzi co 8-12 minut. Nie da się wejść w głęboki stan skupienia (deep focus), bo mózg cały czas jest w trybie czuwania na przerwanie.

Problem 4: Poczucie winy w obie strony

To był dla mnie największy problem psychologiczny. Kiedy się uczę – czuję się winna, że „zaniedbuję” dziecko w wakacje. Kiedy nie się uczę – czuję się winna, że „marnuję czas” i „tracę momentum”.

Efekt: Zamiast cieszyć się ani jednym, ani drugim, czułam ciągły niepokój.

Co NIE zadziałało – moje błędy z lipca

Błąd 1: Utrzymywanie tego samego celu co w roku szkolnym

W czerwcu uczyłam się 1h dziennie. W lipcu próbowałam utrzymać ten sam cel.

Rezultat: Porażka za porażką. Codzienne niepowodzenie w osiągnięciu celu = frustracja = w końcu całkowita rezygnacja (te siedem dni przerwy).

Błąd 2: Sztywne trzymanie się jednej pory dnia

Moja „złota godzina” (14:00-15:00) w wakacje po prostu nie istnieje. Dzieci o tej porze są najbardziej aktywne, najmniej skłonne do samodzielnej zabawy.

Próbowałam wciskać naukę w ten slot mimo wszystko. Efekt: 10 minut skupienia, 40 minut frustracji.

Błąd 3: Traktowanie każdej przerwanej sesji jako porażki

Dziecko przerywa po 15 minutach? W mojej głowie: „No i po nauce, cały dzień stracony.”

To binarne myślenie („albo pełna sesja, albo nic”) sabotowało mnie bardziej niż same przerwania.

Błąd 4: Brak planu na „zero energii”

Zakładałam, że zawsze będę miała choć trochę energii na naukę. Ale niektóre dni wakacyjne – te po nieprzespanej nocy, po długim upale, po trudnym zachowaniu dzieci – zostawiają zero.

Bez planu B, te dni = całkowita rezygnacja zamiast małego kroku.

Strategie mikroedukacji, które faktycznie zadziałały

Po tygodniu przerwy usiadłam i przeprojektowałam całe podejście. Oto co wprowadziłam w sierpniu i co realnie działa.

1. Redukcja celu o 80%, nie o 20%

Zamiast „1h dziennie zamiast 1h dziennie, ale postaram się bardziej”, zrobiłam radykalne cięcie:

Nowy cel wakacyjny: 10 minut dziennie.

Brzmi śmiesznie mało? To jest clou strategii. Mikroedukacja (microlearning) polega na tym, żeby cel był tak mały, że niemożliwość jego osiągnięcia praktycznie nie istnieje.

Efekt psychologiczny: 10 minut nauki JavaScript codziennie = utrzymanie nawyku = poczucie sukcesu, zamiast codziennej porażki przy celu 1h.

2. Elastyczna pora zamiast sztywnego bloku

Zamiast „14:00-15:00 zawsze”, wprowadziłam zasadę: „gdziekolwiek znajdę 10 minut, tam się uczę”.

Realne przykłady z ostatniego tygodnia:

• 6:40 rano, zanim dzieci się obudziły – 15 minut czytania dokumentacji na telefonie
• 12:30, dzieci oglądają bajkę podczas obiadu – 10 minut ćwiczenia na FreeCodeCamp
• 21:15, po położeniu dzieci, zanim opadłam z sił – 20 minut kodowania

Kluczowa zmiana myślenia: Nauka nie ma jednego „właściwego” momentu w wakacje. Ma dowolny moment, w którym się pojawia okazja.

3. Zadania podzielone na fragmenty 5-10 minutowe

Przeprojektowałam sposób planowania nauki. Zamiast „dzisiaj zrobię moduł o pętlach w JavaScript” (który wymaga 45 minut skupienia), dzielę na:

• Fragment 1 (10 min): Przeczytać teorię o pętli for
• Fragment 2 (10 min): Zobaczyć 2 przykłady kodu
• Fragment 3 (10 min): Napisać jeden własny przykład
• Fragment 4 (10 min): Rozwiązać jedno zadanie ćwiczeniowe

Każdy fragment jest samodzielną jednostką – mogę go zrobić w dowolnej kolejności, w dowolnym momencie, i przerwanie po jednym fragmencie nie niszczy niczego, bo to nie jest „połowa czegoś”, tylko „cały mały kawałek”.

4. Nauka pasywna podczas aktywności rodzinnych

To była dla mnie rewelacja. Zamiast traktować naukę i czas z dzieckiem jako całkowicie rozłączne kategorie, znalazłam formę nauki, która współistnieje z byciem rodzicem.

Podcasty i audiobooki o programowaniu podczas:

• Spaceru z dzieckiem do parku (20-30 minut)
• Jazdy samochodem na wycieczki (nawet godzina!)
• Gotowania obiadu (dziecko bawi się obok)

Nie piszę wtedy kodu, ale słucham o konceptach, wyjaśnieniach, historiach z branży. To nie zastępuje praktycznej nauki, ale utrzymuje mózg w kontakcie z tematem, co znacznie ułatwia powrót do praktycznej nauki.

5. Notatki głosowe zamiast pisania

Kiedy mam pomysł albo „aha moment” podczas dnia, ale nie mogę usiąść przy laptopie – nagrywam 30-sekundową notatkę głosową na telefonie.

Przykład notatki: „Pamiętać – destructuring w JavaScript to jak wyciąganie zmiennych z obiektu jednocześnie, muszę to przetestować z tablicą zagnieżdżoną”

Wieczorem, w swoich 10-20 minutach, odtwarzam notatki i przekuwam je w konkretną naukę. To zapobiega utracie przelotnych myśli, które inaczej by zniknęły bezpowrotnie.

6. „Sesja ratunkowa” na dni zero energii

Wprowadziłam plan B dla dni, kiedy dosłownie nie ma siły na nic.

Sesja ratunkowa = 3 minuty.

To może być:

• Przeczytanie jednego akapitu z dokumentacji
• Przejrzenie własnych notatek z poprzedniego tygodnia
• Obejrzenie 3-minutowego fragmentu tutorialu

Cel nie jest nauka nowej wiedzy. Cel to utrzymanie kontaktu z tematem, żeby nawyk fizycznie nie umarł.

Efekt: W ciągu sześciu tygodni wakacji miałam może 4 dni z „sesją ratunkową” zamiast pełnego zera. To 4 dni więcej momentum niż gdybym całkowicie odpuściła.

Jak wygląda mój wakacyjny tydzień teraz – konkretny przykład

Poniedziałek:

• 6:45 – 15 min czytania dokumentacji (telefon, jeszcze w łóżku)
• 13:00 – 10 min ćwiczeń praktycznych (dziecko na drzemce, ale krótko)
• Total: 25 minut

Wtorek (dzień wyjazdu do rodziny – mało czasu):

• 3 minuty sesji ratunkowej wieczorem
• Total: 3 minuty

Środa:

• 30 min podcastu podczas spaceru z dzieckiem (nauka pasywna)
• 10 min notatek wieczorem na podstawie tego co usłyszałam
• Total: 40 minut (w tym 30 pasywnych)

Czwartek (bardzo trudny dzień, dziecko chore):

• 0 minut – kompletna rezygnacja, i to jest OK

Piątek:

• 20 min rano (dziecko wstało później niż zwykle)
• 15 min wieczorem
• Total: 35 minut

Sobota-niedziela (rodzina, mniej struktury):

• Sobota: 10 min sesji ratunkowej
• Niedziela: 0 minut

Tygodniowy total: ~113 minut (niecałe 2 godziny)

Porównanie z rokiem szkolnym: W czerwcu miałam ~420 minut tygodniowo (7h). To jest 75% mniej.

Czy to problem? Nie tak, jak myślałam. Bo najważniejsza rzecz się utrzymała: nawyk siadania do nauki nie umarł całkowicie.

Dlaczego małe kroki wystarczą – nauka z psychologii nawyków

W jednej z moich ulubionych książek o budowaniu nawyków pojawia się zasada: „nie przegap dwa razy z rzędu”. Jedna przegapiona sesja to wypadek. Dwie z rzędu to zaczątek nowego (złego) nawyku.

W wakacje zastosowałam tę zasadę dosłownie.

Kiedy miałam dzień zero (jak ten czwartek z chorym dzieckiem), następnego dnia MUSIAŁAM zrobić choćby sesję ratunkową – 3 minuty. Nie dla wiedzy. Dla utrzymania łańcucha (streak).

Dlaczego to działa psychologicznie:

Mózg nie rozróżnia dobrze między „10 minut nauki” a „1 godzina nauki” jeśli chodzi o utrzymanie identyfikacji z rolą. Jeśli codziennie robisz cokolwiek związanego z programowaniem, Twój mózg wciąż kategoryzuje Cię jako „osobę, która się uczy programowania”.

Jeśli robisz przerwę na dwa tygodnie, ta identyfikacja zaczyna się rozmywać. Wracasz nie jako „osoba wracająca do rutyny”, ale jako „osoba zaczynająca od nowa” – co jest znacznie trudniejsze psychologicznie.

Co się dzieje z postępem technicznym przy tak małych dawkach

Uczciwie: postęp techniczny jest wolniejszy. Nie oszukujmy się.

W czerwcu przerabiałam jeden moduł kursu JavaScript tygodniowo. W wakacje – jeden moduł na dwa-trzy tygodnie.

Ale jest różnica między „wolniejszy postęp” a „brak postępu”.

Gdybym całkowicie przerwała na dwa miesiące wakacji, wrzesień oznaczałby:

• Zapomnienie sporej części tego, czego się nauczyłam
• Konieczność „rozgrzewki” przez tydzień-dwa, zanim wrócę do pełnej produktywności
• Utratę pewności siebie („czy ja w ogóle to jeszcze umiem?”)

Z mikroedukacją, mimo wolniejszego tempa:

• Materiał się nie zapomina (bo mam z nim kontakt co kilka dni)
• Wrzesień będzie płynnym przyspieszeniem, nie startem od zera
• Pewność siebie zostaje („uczę się, tylko wolniej”)

Rozpraszacze – jak sobie z nimi radzę

Upał

Sierpień w Polsce potrafi być dokuszający. Kiedy jest 32 stopnie, a klimatyzacji brak, koncentracja spada drastycznie.

Moje rozwiązanie: Przenoszę naukę na najchłodniejsze godziny (wczesny ranek, późny wieczór). W środku dnia, kiedy jest najgoręcej, robię tylko naukę pasywną (podcasty) albo nic.

Wyjazdy i zmiana otoczenia

Podczas tygodnia nad morzem (opisywałam to w poprzednim wpisie o planie na wakacje) całkowicie odpuściłam naukę. To był świadomy wybór – urlop to urlop.

Ale: Przed wyjazdem i po powrocie zrobiłam „sesje przejściowe” – krótkie przypomnienie tego, co robiłam wcześniej, żeby ułatwić powrót.

Zmęczenie fizyczne

To był mój największy wróg. Po całym dniu z aktywnym dzieckiem, wieczorem mam dosłownie zero energii mentalnej.

Rozwiązanie: Przesunęłam część nauki na rano, kiedy jestem świeższa, zamiast walczyć z wieczornym wyczerpaniem.

Media społecznościowe jako ucieczka

Kiedy jestem zmęczona, naturalny odruch to sięgnięcie po telefon i scrollowanie, nie nauka.

Rozwiązanie: Ustawiłam limit czasu na aplikacjach społecznościowych (30 minut dziennie) w telefonie. Kiedy limit się kończy, telefon pyta „czy na pewno chcesz kontynuować” – to małe tarcie często wystarcza, żeby zamiast tego sięgnąć po notatki z JavaScript.

Kiedy warto całkowicie odpuścić – i dlaczego to jest OK

Ważne zastrzeżenie: nie każdy dzień musi mieć choćby 3 minuty.

Tydzień nad morzem – zero nauki, i uważam to za słuszną decyzję. Dni kiedy dzieci są naprawdę chore, kiedy sama jestem wyczerpana emocjonalnie, kiedy coś poważnego się dzieje w rodzinie – całkowita rezygnacja to nie porażka, to zdrowy rozsądek.

Różnica między „świadomą przerwą” a „utratą nawyku”:

Świadoma przerwa: „Dzisiaj/w tym tygodniu odpuszczam, bo [konkretny powód], i wrócę [konkretny plan powrotu].”

Utrata nawyku: „Nie uczę się, bo… nie wiem, jakoś nie wyszło, może jutro, może pojutrze” (bez konkretnego planu powrotu).

Pierwsza opcja jest częścią zdrowego podejścia. Druga to ślizganie się w kierunku całkowitego porzucenia.

FAQ – nauka programowania w wakacjach

Czy 10 minut dziennie naprawdę coś daje?

Tak, ale inaczej niż myślisz. Nie chodzi o ilość przyswojonej wiedzy w tych 10 minutach – chodzi o utrzymanie neuronalnych ścieżek aktywnymi i zachowanie tożsamości „osoby uczącej się”. To fundament, na którym łatwo odbudować pełne tempo we wrześniu.

Czy nie lepiej zrobić sobie prawdziwą przerwę od nauki na całe wakacje?

Dla niektórych osób – tak, i to jest w pełni uzasadniony wybór. Jeśli wiesz, że łatwo Ci wrócić do nawyku po dłuższej przerwie, pełna przerwa może być zdrowsza niż wymuszanie mikrosesji.

Dla mnie, po doświadczeniu tych siedmiu dni całkowitej przerwy w lipcu, wiem, że łatwiej jest utrzymać choćby minimalny kontakt niż zaczynać kompletnie od nowa.

Jak przekonać się psychicznie, że 10 minut „się liczy”?

Zmiana definicji sukcesu. Sukces w wakacje to nie „ile się nauczyłam”, tylko „czy nawyk przetrwał”. Przy takiej definicji, 10 minut codziennie to pełny sukces, nie kompromis.

Co z nauką z dzieckiem obok – czy to w ogóle możliwe?

Częściowo tak. Nauka pasywna (podcasty, audiobooki) działa świetnie przy dziecku w tle. Nauka aktywna (pisanie kodu) wymaga chwil, kiedy dziecko jest zajęte samo sobą – drzemka, zabawa, bajka. To nieregularne okna, ale realnie istnieją, jeśli się na nie czeka zamiast planować sztywno.

Czy warto zmieniać temat nauki latem na coś „lżejszego”?

To zależy od osoby. Ja zostałam przy JavaScript, ale obniżyłam intensywność. Niektórzy wolą latem czytać książki o programowaniu (bez praktyki) zamiast pisać kod – to też forma utrzymania kontaktu z tematem, mniej wymagająca energetycznie.

Podsumowanie – czy da się utrzymać momentum w wakacje

Krótka odpowiedź: tak, ale nie w tej samej formie co w roku szkolnym.

Kluczowe zasady, które wprowadziłam:

• Redukcja celu o 80% (z 60 minut do 10 minut dziennie)
• Elastyczna pora zamiast sztywnego slotu – uczę się gdziekolwiek znajdę okazję
• Zadania podzielone na fragmenty 5-10 minutowe – łatwiej wcisnąć w krótkie okna
• Nauka pasywna podczas aktywności rodzinnych – podcasty na spacerze, w aucie
• Notatki głosowe – zapisuję przelotne myśli, przetwarzam wieczorem
• Sesja ratunkowa (3 minuty) na dni zero energii – utrzymuje łańcuch nawyku
• Świadome przerwy są OK – tydzień urlopu bez poczucia winy

Nauka programowania w wakacje to nie kwestia „utrzymać tempo z roku szkolnego za wszelką cenę”. To kwestia znalezienia minimalnej dawki, która utrzymuje nawyk żywym, bez wywoływania chronicznego poczucia winy czy wypalenia.

Wrzesień przyjdzie. Szkoła będzie. Struktura wróci. A ja będę miała za sobą nie „stracone lato”, tylko wolniejsze, ale ciągłe lato – z nawykiem, który przetrwał, mimo wszystkich przeszkód.

To wystarczy.

PS: Też walczysz z utrzymaniem nauki (programowania, języka, czegokolwiek) w wakacje? Jakie strategie u Ciebie działają? Podziel się w komentarzu – potrzebujemy nawzajem swojego wsparcia w tym sezonie chaosu!

Artykuł Nauka programowania w wakacje – czy da się utrzymać nawyk? pochodzi z serwisu To co najważniejsze.

Tworzę plik: index.html. Potem script.js. Nie .java.

Zaczynam naukę JavaScript.

Po 6 miesiącach z Javą (styczeń-czerwiec 2026) postanowiłam dodać drugi język. Dlaczego JavaScript? Dlaczego teraz? Czy Java mi pomoże czy przeszkodzi?

Trzy tygodnie później (dziś) mogę powiedzieć: nauka drugiego języka programowania jest ZUPEŁNIE inna niż nauki pierwszego. Masz fundamenty (zmienne, pętle, funkcje), ale szczegóły są diametralnie różne. To jak uczyć się francuskiego po hiszpańskim – podobne, ale gwarantowany chaos w głowie.

Dziś w Learning Log #6 opowiem Wam dlaczego wybrałam JavaScript, jak zaczynałam, co jest podobne do Javy (więcej niż myślałam!), co kompletnie inne (WTF momenty!), i jakie zasoby do nauki wykorzystuję.

Dlaczego JavaScript? Decyzja strategiczna

Opcje, które rozważałam po zakończeniu podstaw Java:

1: Spring Framework (kontynuacja Java)

• Zalety: Naturalna progresja, rozwój zaplecza, rynek pracy
• Wady: Ciężkie przy dzieciach, wymaga dużo czasu

2: Python

• Zalety: Łatwy, wszechstronny, data science, automatyzacja
• Wady: Zero synergii z WordPressem

3: JavaScript

• Zalety: OGROMNA synergia z WordPress, umiejętności front-endowe, natychmiastowe wykorzystanie, lżejszy niż Spring
• Wady: „Dziwny język” (słyszałam), może mylące po Javie

Wybrałam JavaScript. Dlaczego:

1. Synergia z WordPressem

Aktualnie: Robię strony WordPress z page builderami (Elementor)

• Mało custom kodu
• Ograniczone możliwości
• Nie mogę zrobić custom funkcjonalności, które bym chciała

Z JavaScriptem: Mogę dodawać:

• Niestandardowe interakcje (animacje, efekty)
• Formularze zaawansowane (walidacja, multi-step)
• Kalkulatory (cenniki dynamiczne)
• Niestandardowa funkcjonalność (cokolwiek wymyślę)

2. Natychmiastowe praktyczne zastosowanie

Java projekt: Therapy Manager – używam tylko ja
JavaScript: Mogę użyć w KAŻDYM projekcie dla każdego od jutra

Motywacja: Widzę natychmiastowy rezultat = łatwiej się uczyć

3. Łatwiejszy balans życie/nauka niż Spring

Spring: Wymaga 20-30h tygodniowo, żeby ogarnąć (backend, bazy danych, API, deployment)
JavaScript: Mogę uczyć się 1h dziennie i widzieć progres

Z dziećmi: JavaScript = realistyczne, Spring = przytłaczający

4. Umiejętności frontendowe można sprzedać

Backend (Java/Spring): Duża konkurencja, wymaga doświadczenia
Frontend (JS/React): Też konkurencja, ale łatwiej pokazać portfolio (strony działają w przeglądarce)

Perspektywa freelancera: Frontend łatwiej „sprzedać” klientom (widzą efekt natychmiast)

Pierwsze kroki – od czego zaczęłam

Tydzień 1 (1-7 lipca): Setup i podstawy składni

Narzędzia, które zainstalowałam:

1. VS Code (zamiast IntelliJ)

• Lekki, szybki
• Rozszerzenia: ESLint, Prettier, Live Server
• Czas setup: 30 minut

2. Node.js

• Do uruchamiania JS poza przeglądarką
• Package manager (npm) – jak Maven dla Javy
• Instalacja: 10 minut

3. Chrome DevTools

• Już miałam (przeglądarka)
• Konsola do testowania kodu
• Debugger

Total setup: 1 godzina (vs Java było 3 godziny – IntelliJ, JDK, Maven)

Pierwszy program – Hello World:

Java (dla porównania):

java

`public class HelloWorld {
    public static void main(String[] args) {
        System.out.println("Hello World");
    }
}`

JavaScript:

javascript

console.log("Hello World");

Reakcja: „WAIT, to wszystko?! Gdzie klasa? Gdzie main?”

Welcome to JavaScript – język bez szablonów.

Mój plan nauki JavaScript:

1. Fundamenty (lipiec):

• Składnia (zmienne, typy, operatory)
• Funkcje i scope
• Tablice i obiekty
• DOM manipulation (zmiana HTML/CSS przez JS)

2. Średniozaawansowany (sierpień):

• ES6+ funkcje (funkcje strzałkowe, destrukturyzacja, promises)
• Asynchroniczność (async/await, fetch API)
• Events i event handling

3. Framework (wrzesień – może):

• React basics
• Albo zostać przy vanilla JS (czystym JS) i opanować dobrze

Źródła nauki:

• FreeCodeCamp (darmowy kurs online) – główne
• JavaScript.info (dokumentacja) – odniesienie
• YouTube: Traversy Media, Web Dev Simplified
• Praktyka: Projekty WordPress

Czas: 1h dziennie (vs Java było 1.5h) = lżejsze podejście

Co jest PODOBNE do Javy – zaskakujący!

1. Fundamenty programowania (koncepcje)

Zmienne:

Java:

java

int age = 30; 
String name = "Anna"; 
boolean isActive = true;

JavaScript:

javascript

let age = 30; 
let name = "Anna"; 
let isActive = true;

Podobne: Koncept zmiennej, przechowywanie wartości
Różne: let zamiast typu (int, String), JS = dynamicznie typowane

Pętle:

Java:

java

`for (int i = 0; i < 5; i++) {
    System.out.println(i);
}`

JavaScript:

javascript

`for (let i = 0; i < 5; i++) {
    console.log(i);
}`

Identyczne! (prawie – let zamiast int)

Warunki:

Java:

java

`if (age > 18) {
    System.out.println("Adult");
} else {
    System.out.println("Minor");
}`

JavaScript:

javascript

`if (age > 18) {
    console.log("Adult");
} else {
    console.log("Minor");
}`

Identyczne! (prawie – console.log zamiast System.out.println)

Spostrzeżenia: Fundamenty są takie same. Java nauczyła mnie myślenia programistycznego – to przenosi się 1:1 do JS.

2. Funkcje (podobne, ale…)

Java (metoda):

java

`public int add(int a, int b) {
    return a + b;
}`

JavaScript (funkcja):

javascript

`function add(a, b) {
    return a + b;
}`

Podobne:

• Słowo kluczowe function (vs public int w Javie)
• Instrukcja: Return
• Parametry

Różne:

• Brak typów (a, b – nie wiesz czy int, string, object)
• Brak modyfikatory dostępu (public, private)

3. Tablice (arrays)

Java:

java

`int[] numbers = {1, 2, 3, 4, 5};
System.out.println(numbers[0]); // 1`

JavaScript:

javascript

`let numbers = [1, 2, 3, 4, 5];
console.log(numbers[0]); // 1`

Prawie identyczne!

Różnica: JS arrays są bardziej elastyczne (możesz mix typów)

javascript

`let mixed = [1, "two", true, {name: "Anna"}]; // OK w JS
// W Javie: BŁĄD (tablica musi mieć jeden typ)`

4. Obiekty vs Klasy

Java (klasa):

java

`public class Person {
private String name;
private int age;

public Person(String name, int age) {
    this.name = name;
    this.age = age;
}

public String getName() {
    return name;
}

}

Person person = new Person("Anna", 30);`

JavaScript (obiekt):

javascript

`const person = {
    name: "Anna",
    age: 30,
    getName: function() {
        return this.name;
    }
};`

Podobne: Koncept „obiektu” (dane + metody)
Różne: JS nie wymaga klasy! (można tworzyć obiekty dosłownie)

JavaScript ma też klasy (ES6):

javascript

`class Person {
constructor(name, age) {
this.name = name;
this.age = age;
}

getName() {
    return this.name;
}

}

const person = new Person("Anna", 30);`

To wygląda prawie jak Java! Ale pod spodem JS działa inaczej (prototypy, nie prawdziwe klasy).

Co jest KOMPLETNIE RÓŻNE – WTF momenty

1. Typy dynamiczne (loosely typed)

Java: Statycznie typowane

java

`int number = 5;
number = "Hello"; // BŁĄD kompilacji!`

JavaScript: Dynamicznie typowane

javascript

`let number = 5;
number = "Hello"; // OK! 😱
console.log(number); // "Hello"`

WTF moment #1: „Czekaj, mogę zmienić typ zmiennej w trakcie?!”

Plusy Elastyczność, mniej kodu
Minusy: Błędy runtime (nie kompilacji), trudniejszy debugging

Moja reakcja: Początkowo mylące. Teraz doceniam elastyczność, ale brakuje bezpieczeństwa typu Java.

2. == vs === (porównywanie)

Java:

java

`int a = 5;
int b = 5;
if (a == b) { } // true`

JavaScript:

javascript

`let a = 5;
let b = "5";

console.log(a == b); // true 😱 (porównuje wartość, konwertuje typy)
console.log(a === b); // false (porównuje wartość I typ)`

WTF moment #2: „Czemu jest DWA operatory porównania?!”

Zasada: W JS ZAWSZE używaj === (ścisła równość), nigdy == (luźna równość)

Przykład dlaczego:

javascript

`console.log(0 == false);  // true 😱
console.log(0 === false); // false (poprawnie!)`

3. var vs let vs const (szaleństwo zakresów)

Java: Wszystko ma zakres bloku

java

`{
    int x = 5;
}
System.out.println(x); // BŁĄD - x nie istnieje poza blokiem`

JavaScript: var ma zakres funkcji (WTF), let/const mają zakres bloku

javascript

`// VAR (stary sposób - unikaj!)
function test() {
if (true) {
var x = 5;
}
console.log(x); // 5 😱 (x istnieje poza if!)
}

// LET (nowy sposób - używaj!)
function test() {
if (true) {
let y = 5;
}
console.log(y); // ERROR (jak w Javie - dobrze!)
}`

WTF moment #3: „Czemu var działa inaczej niż w normalnym języku?!”

Zasada: Nigdy nie używaj var. Zawsze let (zmienne) lub const (stałe).

4. Hoisting (podnoszenie deklaracji)

Java: Musisz zadeklarować zmienną PRZED użyciem

java

`System.out.println(x); // BŁĄD - x nie istnieje
int x = 5;`

JavaScript: Deklaracje są „podnoszone” na górę

javascript

`console.log(x); // undefined (nie błąd!) 😱
var x = 5;`

Co się dzieje:

javascript

`// JS interpretuje to jako:
var x; // deklaracja "podniesiona"
console.log(x); // undefined
x = 5; // przypisanie`

WTF moment #4: „Jak to możliwe, że kod działa, ale źle?!”

Z let jest lepiej:

javascript

console.log(y); // ERROR (jak w Javie) 
let y = 5;

Zasada: Używaj let/const, unikaj var = unikasz problemy z podnoszeniem.

5. Funkcje są „first-class citizens” (obiekty pierwszej klasy)

Java: Funkcje (metody) należą do klas. Nie możesz przekazać metody jak zmienną.

JavaScript: Funkcje można przypisać do zmiennej, przekazać jako argument, zwrócić z funkcji

javascript

`// Funkcja w zmiennej
const sayHello = function() {
console.log("Hello");
};

// Przekazanie funkcji jako argument
function greet(name, callback) {
console.log("Hi " + name);
callback();
}

greet("Anna", sayHello);
// Output:
// Hi Anna
// Hello`

WTF moment #5: „Funkcja w zmiennej?! Funkcja jako parametr?!”

Java odpowiednik (rodzaj):

java

`// Java 8+ lambda
Runnable sayHello = () -> System.out.println("Hello");
sayHello.run();`

Podobne: Java lambdy, ale w JS to jest główna funkcja, w Javie dodane później.

6. undefined vs null (dwa „nic”)

Java: null (tylko jeden „brak wartości”)

JavaScript: undefined I null (dwa różne „nic”)

javascript

`let a; // zadeklarowana, nie przypisana
console.log(a); // undefined

let b = null; // explicite "brak wartości"
console.log(b); // null

console.log(typeof a); // "undefined"
console.log(typeof b); // "object" 😱 (JS bug od początku języka)`

WTF moment #6: „Czemu DWA rodzaje 'nic’?! I czemu typeof null to 'object’?!”

Zasada:

• undefined = JS default (zmienna istnieje, nie ma wartości)
• null = programista wyraźnie mówi „tutaj jest nic”

7. Brak TypeScript (ale mogę użyć później)

Java: Kompilator sprawdza typy PRZED uruchomieniem

java

int x = "Hello"; // BŁĄD kompilacji

JavaScript: Błędy widoczne DOPIERO w runtime

javascript

let x = 5; 
x.toUpperCase(); // ERROR runtime! (number nie ma toUpperCase)

Problem: Łatwo zrobić błąd, który widzisz dopiero, gdy uruchamiasz.

Rozwiązanie: TypeScript (JavaScript + typy)

typescript

let x: number = 5; 
x = "Hello"; // BŁĄD kompilacji (jak Java!)

Mój plan: Najpierw opanuję vanilla JS, potem może TypeScript (wrzesień-październik).

Pierwszy mini-projekt w JavaScript – Kalkulator interaktywny

Po tygodniu nauki (7.07) zrobiłam pierwszy mini-projekt.

Co: Kalkulator terapii – użytkownik wpisuje liczbę sesji i koszt, dostaje podsumowanie

Technologie:

• HTML (struktura)
• CSS (wygląd)
• JavaScript (logika)

HTML:

html

`<!DOCTYPE html>
<html>
<head>
<title>Therapy Cost Calculator</title>
<link rel="stylesheet" href="style.css">
</head>
<body>
<div class="calculator">
<h1>Kalkulator Kosztów Terapii</h1>

    <label>Liczba sesji miesięcznie:</label>
    <input type="number" id="sessions" placeholder="np. 8">
    
    <label>Koszt jednej sesji (zł):</label>
    <input type="number" id="costPerSession" placeholder="np. 75">
    
    <button onclick="calculateTotal()">Oblicz</button>
    
    <div id="result"></div>
</div>

<script src="script.js"></script>

</body>
</html>`

JavaScript (script.js):

javascript

`function calculateTotal() {
// Pobierz wartości z inputów
const sessions = document.getElementById('sessions').value;
const costPerSession = document.getElementById('costPerSession').value;

// Walidacja
if (!sessions || !costPerSession) {
    alert('Wypełnij oba pola!');
    return;
}

if (sessions <= 0 || costPerSession <= 0) {
    alert('Liczby muszą być większe od zera!');
    return;
}

// Kalkulacja
const total = sessions * costPerSession;

// Wyświetl wynik
const resultDiv = document.getElementById('result');
resultDiv.innerHTML = `
    <h2>Wynik:</h2>
    <p><strong>Sesji:</strong> ${sessions}</p>
    <p><strong>Koszt sesji:</strong> ${costPerSession} zł</p>
    <p class="total"><strong>TOTAL:</strong> ${total} zł/miesiąc</p>
`;
}

Co się nauczyłam:

Manipulacja DOM – `document.getElementById()`
Obsługa zdarzeń – `onclick=”calculateTotal()”`
Walidacja danych wejściowych – sprawdzanie czy pola wypełnione
Szablony literałów – „ `${variable}` „ (lepsze niż konkatenacja)
Debugging – Chrome DevTools console

Czas: 2 godziny od zera do działającego projektu

Porównanie z Javą:
– Java projekt (Therapy Manager): 55 godzin
– JS projekt (Kalkulator): 2 godziny

Różnica: JS =natychmiastowa gratyfikacja (widzisz w przeglądarce od razu), Java = długi proces, ale solidniejszy fundament.

Zasoby nauki JavaScript – co NAPRAWDĘ używam

1. FreeCodeCamp (★★★★★)

Link: freecodecamp.org

Co: Darmowy kurs "JavaScript Algorithms and Data Structures"

Format: 
- Krótkie lekcje (5-10 min)
- Wyzwania (zadania do rozwiązania)
- Projekty na końcu sekcji

Dlaczego działa:
- Interaktywny (piszesz kod w przeglądarce)
- Natychmiastowa informacja zwrotna(widzisz czy poprawnie)
- Darmowe (100%)

Mój progres: 30% kursu (3 tygodnie)

Czas: 1h dziennie

2. JavaScript.info (★★★★★)

Link: javascript.info

Co: Dokumentacja/tutorial JavaScript - od podstaw do zaawansowanych

Format:
- Artykuły (szczegółowe wyjaśnienia)
- Przykłady kodu
- Zadania na końcu rozdziałów

Dlaczego używam:
- Wyczerpujący (wszystko w jednym miejscu)
- Dobrze wyjaśnia "dlaczego", nie tylko "jak"
- Darmowe

Jak używam: Odniesienie, gdy czegoś nie rozumiem z FreeCodeCamp

3. YouTube – Traversy Media (★★★★☆)

Kanał: Traversy Media

Co: Tutoriale JavaScript, projekty, web development

Format: Video tutorials (30-60 min)

Ulubione video:
- "JavaScript Crash Course For Beginners" - 1h 40min
- "Build a Calculator with JavaScript" - projekt
- "DOM Crash Course" - manipulation HTML/CSS

Dlaczego: Widzę jak ktoś pisze kod (łatwiej zapamiętać)

Jak używam: Wieczory (21:00-22:00,) gdy dzieci śpią

4. MDN Web Docs (★★★★☆)

Link: developer.mozilla.org

Co: Oficjalna dokumentacja webowe technologie(HTML, CSS, JS)

Format: Dokumentacja referencyjna

Jak używam: 
- Gdy potrzebuję szczegółów konkretnej funkcji/metody
- "JavaScript Array methods" - pełna lista
- Przykłady użycia

Nie dla początkujących: Sucha dokumentacja, lepsze jako odniesienie niż zasób edukacyjny.

5. ChatGPT (★★★★★)

Jak używam:

Wyjaśnianie pojęć:

Ja: "Wyjaśnij mi hoisting w JavaScript jak dla 5-latka"
ChatGPT: [proste wyjaśnienie z przykładami]


Debugging:

Ja: "Czemu ten kod nie działa? [wklejam kod]"
ChatGPT: "Błąd w linii 5 - używasz var zamiast let, to powoduje..."


Code review:

Ja: "Czy ten kod jest OK? Jak mogę go ulepszyć?"
ChatGPT: [sugestie, najlepsze praktyki]

Zalety: Natychmiastowe odpowiedzi, nieograniczone pytania, dostępne 24/7
Wady: Czasem się myli, trzeba weryfikować

Java vs JavaScript – podsumowanie pierwszych 3 tygodni

Co jest ŁATWIEJSZE w JS niż w Javie:

Setup – 1h vs 3h (Java)
Szablon – prawie zero (vs dużo w Javie)
Natychmiastowa informacja zwrotna – odświeżenie przeglądarki vs kompilacja
Krzywa uczenia się – szybszy start (widzisz efekty od razu)
Projekty – 2h mini-projekt vs 55h w Javie

Co jest TRUDNIEJSZE w JS niż w Javie:

Typ bezpieczeństwa – brak (łatwo zrobić błąd)
Dziwactwa języka – == vs ===, podnoszenie, var zakres
Debugging – błędy run-time (nie czas kompilacji)
Konsekwencja – wiele sposobów na to samo (mylące!)
Asynchroniczność – callbacks, promises, async/await (jeszcze przed mną, ale słyszałam że trudne)

Co się przenosi z Javy 1:1:

Pętle (for, while)
Warunki (if/else, switch)
Funkcje (koncept)
Tablice (koncept, podobna składnia)
Obiekty/klasy (trochę inne, ale koncept ten sam)
Myślenie programistyczne – algorytmy, rozwiązywanie problemów

Czy Java pomogła w nauce JS?

TAK, ogromnie.

Bez Javy:

• Musiałabym uczyć się fundamentów (pętle, warunki, funkcje) od zera
• Nie rozumiałabym OOP
• Nie wiedziałabym jak projektować kod

Z Javą:

• Fundamenty mam (przeskoczyłam 50% kursu JS)
• Rozumiem klasy w JS (bo znam z Javy)
• Myślę algorytmicznie (transfer skill)

Ale:

• Java-owe nawyki czasem przeszkadzają (próbuję deklarować typy, których JS nie ma)
• Muszę „oduczyć się” od Java ścisłość

Werdykt: Java była świetnym pierwszym językiem. JavaScript jako drugi = łatwiejszy, niż gdyby był pierwszy.

Plany na sierpień – co dalej z JS

Tydzień 1-2 sierpnia:

• Dokończenie FreeCodeCamp „Basic JavaScript” (50% pozostało)
• Praktyka: 3-4 mini-projekty (todo list, quiz, countdown timer)

Tydzień 3-4 sierpnia:

• ES6 funkcje (arrow functions, destructuring, spread operator)
• Zaawansowana manipulacja DOM
• Pierwszy projekt dla klienta WordPress (walidacja formularza niestandardowego)

Wrzesień:

• Asynchronous JS (promises, async/await, fetch API)
• Może React basics (jeśli czuję się ready)
• Większy projekt (może blog z fetch API)

Cel: Do końca sierpnia czuć się komfortowo z vanilla JavaScript.

Realistycznie: Nie zostanę ekspertem w miesiąc. Ale będę mogła używać JS w projektach klientów.

FAQ – nauka drugiego języka programowania

Czy powinnam kończyć Java całkowicie przed JS?

NIE.

Nie musisz być ekspertem Javy, żeby zacząć JS.

Wystarczy:

• Rozumieć podstawy (zmienne, pętle, funkcje, obiekty)
• Zbudować 1-2 projekty

Reszta: Nauczysz się w trakcie lub później.

Jak nie pomieszać Java i JS w głowie?

Początkowo: Mieszam. Piszę System.out.println zamiast console.log.

Pomaga:

• Używanie różnych IDE (IntelliJ dla Java, VS Code dla JS)
• Projekty w jednym języku naraz (nie przełączać co godzinę)
• Praktyka (mózg się przyzwyczaja)

Po 3 tygodniach: Już rzadziej mieszam.

Czy TypeScript zamiast JavaScriptu?

TypeScript = JavaScript + typy (jak Java)

Argument ZA: Jeśli znasz Javę, TypeScript będzie bardziej podobny

Argument PRZECIW: Nauka TypeScriptu = nauka JS + nauka TypeScript w działaniu (więcej naraz)

Moja decyzja: Vanilla JS najpierw. TypeScript może później (wrzesień-październik).

Ile czasu dziennie poświęcam?

JavaScript: 1h dziennie (vs Java było 1.5h)

Rozłożenie:

• Rano: 30 min (FreeCodeCamp wyzwania)
• Wieczór: 30 min (projekt/praktyka)

Weekendy: 2-3h (większe projekty)

Dlaczego mniej niż Java: Wakacje, dzieci, jestem zmęczona. 1h = zrównoważony.

Czy warto uczyć się wielu języków naraz?

Moim zdaniem: NIE.

1 język na raz. Opanuj podstawy, potem dodaj drugi.

Dlaczego:

• Mylące (mieszasz składnie)
• Przytłaczający (dwa razy więcej nauki)
• Powolny postęp (rozmywasz czas)

Lepiej:

• 6 miesięcy Java (solidnie)
• Potem JavaScript (z fundamentami z Javy)

Podsumowanie – Learning Log #6

Nauka drugiego języka programowania:

• Łatwiejsza niż pierwszego (fundamenty mam)
• Trudniejsza niż myślałam (dziwactwa, różnice, mieszanie)
• Wartościowe – widzę konkretny benefit (projekty WordPress)

Java vs JavaScript:

• Podobne: Fundamenty (pętle, warunki, funkcje)
• Różne: Typy, scope, dziwactwa, filozofia języka
• Werdykt: Java pomogła ogromnie, ale JS wymaga „oduczyć się” od ścisłość

Progres po 3 tygodniach:

• 30% FreeCodeCamp kursu
• 1 mini-projekt (calculator)
• Rozumiem podstawy
• Czuję się komfortowo z kodem

Cel sierpień:

• 80% FreeCodeCamp
• 5-7 mini-projektów
• Pierwszy większy projekt (custom JS w WordPress)

Najważniejsza lekcja:

„Drugi język ≠ zaczynać od zera. Masz fundamenty. Użyj ich.”

Java nauczyła mnie programowania. JavaScript uczy mnie praktyczności i elastyczności.

Oba są potrzebne. Oba mają miejsce w moim portfolio.

Od osoby, która się uczy do osoby, która buduje – teraz w DWÓCH językach.

PS: Też uczysz się drugiego języka programowania? Z czego na co przeszłaś/przeszedłeś? Co było najtrudniejsze? Zostaw komentarz – ciekawa jestem Waszych doświadczeń!

Artykuł Learning Log #6: Java vs JavaScript – zaczynam drugi język programowania pochodzi z serwisu To co najważniejsze.

dlaczego ta…?

Z bardzo prostej przyczyny. Większość książek traktujących o językach programowania jest dosyć techniczna. I nikt się temu nie dziwi, prawda?

Ta jest inna. Po pierwsze jest pisana dla dzieci, ma również dostęp do materiałów udostępnianych na stronie internetowej. Wszystko wytłumaczone jest bardzo prostym językiem … na przykładach.

Szczerze po przeczytaniu dwa razy, od razu wiedziałam jak taką czy inną funkcję napisać i zastosować w praktyce.

Dziś ten wpis będzie bardzo, ale to bardzo krótki. Z kilku powodów. Mianowicie o tej książce nie można dużo powiedzieć. Trzeba ją przeczytać. Albo jeszcze lepiej (tak ja robiłam za pierwszym razem) czytać i od razu pisać w przeglądarce. Właśnie tak jest najlepiej się uczyć kodowania.

Jeśli będziesz mieć możliwość wypożyczyć lub kupić tą książkę to polecam to zrobić.

Miałam dostęp przez IBUK Libra, ale niestety skończył mi się, nad czym bardzo boleję. Teraz będę musiała poszukać jej gdzieś indziej

Co jeszcze można w Java Script? Na przykład ten kuras: https://kursjs.pl/ Podstawy, które koniecznie trzeba opanować. Wiadomości na temat tego języka zdecydowanie muszę odświeżyć. Bez samozapracia niestety się nie obejdzie.

Zaczynam akcję #reaktywacjajs

Jeśli znajdziesz jeszcze jakieś fajne źródła z JS, daj znać: w komentarzu lub wyślij do mnie wiadomość.

Artykuł Java Script dla dzieci – mój poziom 😁 pochodzi z serwisu To co najważniejsze.

Najlepiej by było uczyć się „na żywym organizmie”. Ale w moim przypadku to odpada, nie mam tyle wolnej przestrzeni czasowej.

metoda małych kroczków

Zaczniemy od „jak”.
Z pewnością musisz mieć plan nauki, zwłaszcza gdy każda minuta w ciągu dnia jest na wagę złota.

Z pewnością słyszałaś już o:

• zjadaniu słonia
• lub zjadaniu żaby,
• małych kroczkach.

Kiedy powiemy sobie: „nauka JavaScript”, to … robimy wielkie oczy. Rany, przecież tego jest tak dużo… Tutaj przychodzi z pomocą „zjadanie wielkiego słonia”.

Projekt pod tytułem „Nauka JS” zamieniamy na malutkie, strawne dla naszego umysłu „kawałeczki”.

A co z tą żabą? Najobrzydliwsze i ogromniaste żaby zjada się zawsze jako pierwsze, na początku dnia, aby mieć to jak najszybciej z głowy.

Jeśli zaplanujemy sobie 15-minutową sesję z kodem codziennie o 8 rano, to ze spokojem (i bez wyrzutów sumienia!) będziemy mogły się zająć innymi rzeczami.
Przecież to na czym nam zależało mamy już odhaczone na ten dzień, prawda?
Taka metoda sprawdza się zwłaszcza kiedy zaczynamy.

Kiedy wprowadzałam nawyk codziennej praktyki jogi i medytacji, to właśnie rano, zaraz po obudzeniu się rozkładałam matę. Dlaczego? Mój nawyk nie był na tyle jeszcze mocny, aby ryzykować niewykonanie zaplanowanego zadania na dany dzień.
Dziś spokojnie mogę przenieść medytację na wieczór, a jogę na popołudnie, aby podładować się trochę. Zmienił się też rodzaj praktyki jogi. Teraz częściej ćwiczę bardziej energiczną odmianę .
Wcześniej bazowałam na bardzo bezpiecznych i spokojnych asanach.

A wracając do kodowania. Małe kroczki i zaplanowane bloki czasowe. To mój wybór. Siadam do laptopa, kiedy mam to w harmonogramie dnia. Odfajkowuję kolejne kroczki.

Koniecznie zapisuj swoje postępy. Dlaczego? Aby czuć zadowolenie z tego, co robisz i … no cóż, nie oszukujmy się… aby trochę dowartościować swoje EGO. Zrozumiesz, kiedy zobaczysz śliczny rządek odfajkowanych dni.

Czy czasami się nie chce? Powiedziałabym, że zazwyczaj się nie chce. Mój sposób na to: „tylko ten fragment” lub „tylko minutka”, „tylko zerknę”. Działa cudownie, bo jak już zerknęliśmy do kursu, książki, kodu, to trochę trudno to zostawić w spokoju…

javascript na tapet

JavaScript to mój jedyny temat na ten rok, który dotyczy kodowania. Dlaczego? W zeszłym roku trochę się rozpraszałam na rzecz WordPressa, CSS i innych rzeczy, co skutkowało tym, że SJ schodził na plan dalszy.

Od kogo będę się uczyć JS? Tak jak już pisałam we wcześniejszym wpisie muszę skupić się na jednym konkretnym źródle na raz. Łapanie kilku srok za ogon nie sprawdzi się w moim przypadku.

Wybrałam na początek jednego pana – Wesa Bosa i jego kurs pt. „JavaScript 30”.
Jak można się domyślać to challenge trwający 30 dni, na każdy dzień przypada jeden konkretne zagadnienie do zakodowania.
Z racji tego, że nie czuję się pewnie w języku angielskim, pewnie u mnie będzie to trwało znacznie dłużej niż 30 dni.

Zaczynam już w lutym, czyli za kilka dni! Następnie biorę się za przerwany w zeszłym roku kurs z FreeCodeCamp. Tym bardziej że znalazłam kanał na YouTube FCC – będzie robione.

Zapytasz pewnie: „a nie ma czegoś po polsku?” Z pewnością jest.
Z całą świadomością wybieram wersje anglojęzyczne. Nie czuję się w tym języku zbyt pewnie, dlatego chcę upiec dwie pieczenie na jednym ogniu – język i JS.

Kolejnym kursem, który mnie kusi jest od Traversy Media, kurs dla absolutnie początkujących. Tak, trochę liznęłam JS już, ale bądźmy szczerzy, sporo wyleciało z głowy, bo … nie kodowałam! Tak to już się dzieje, zamiast utrwalić informacje, jakie zdobyłam, przerzuciłam się na coś całkowicie innego.

A ty masz jakiś malutki plan na nauczenie się czegoś nowego lub odświeżenie czegoś dawnego?
Co by się tobie przydało, aby łatwiej było ogarnąć naukę logistycznie? Wsparcia moralnego, ślicznych trackerów do monitorowania postępów? Napisz w komentarzu.

Artykuł Gdzie szukać pomocy w nauce kodowania? pochodzi z serwisu To co najważniejsze.

Potocznie pragmatyzmem nazywana jest także postawa, polegająca na realistycznej ocenie rzeczywistości, liczeniu się z konkretnymi możliwościami i podejmowaniu działań, które gwarantują skuteczność.

Wikipedia

Co było.

Ciężko sobie przypomnieć co było. Nasza pamięć bardzo lubi przekłamywać i tam, gdzie nie widzieliśmy problemu mógł, tkwić zalążek porażki. Z każdego zdarzenia powinniśmy wyciągać wnioski i na nich się uczyć. Nie warto popełniać wciąż te same błędy. To strata czasu!

Dlatego najlepszym rozwiązaniem czasem jest prowadzenie dziennika. I nie chodzi mi nawet o „pamiętnik” z prawdziwego zdarzenia… Miejsce, gdzie zapiszesz, jakie podejmowałeś wyzwania, i w jakim stopniu je zrealizowałeś. Ja ma troszkę ułatwione zadanie, bo nie dość, że wpisy na blogu usprawniają mi przypominanie to jeszcze w zeszycie, w punktach mam bardzo wiele rzeczy rozpisanych.

Blogowanie.

Aby nie przedłużać, przejdę do tego, co było.
Blog nadal istnieje. 71 wpisów. Rozwinęłam fanPage. I rozhulałam Instagram. Przeprowadziłam Małą Rewolucję (w lipcu). Pojawiło się więcej ekspercki (jakoś dziwnie mi się to pisze) wpisów na tematy około programowe.

Z rzeczy blogowych ciągle zastanawiam się nad właściwą formą. Próbuję, zmieniam i dodaję lub odejmuję tematy. Piszę tak, aby zainteresować. Nawet nie chodzi o ogromne grono odbiorców, ale stałe. Właśnie z taką myślą zakupiłam kursy Jasona Hunta: Masterclass: Blogger i Masterclass: Blogger&Biznes. Wstyd przyznać, ale jestem na nich dopiero na początku. Wybrałam podejście: bez presji. Dostęp mam jeszcze kawał czasu, więc nie muszę wszystkiego robić naraz. Wszystko w swoim czasie. Tak więcej wyciągnę z tego.

Kodowanie.

Tu było sporo. Zacznę od WordPressa. Ulepszyłam blog (nieistotne, że nie widać ). Zbudowałam nową stronę, która czeka na opublikowanie. Planowałam to na końcówkę roku, ale nie bardzo to wyjdzie. Zbyt dużo mam rzeczy do przemyślenia w związku z nią, muszę napisać teksty i nadal ciągle zdjęcia i grafiki są do bani. Ale! Zrobiłam ją praktycznie w 3 dni! To sukces.
W końcu pożegnałam kurs Eweliny Muc „WP dla Zielonych”. Nie dlatego, że już nie jest wartościowy, ale szukam wszędzie oszczędności…
Mija rok (prawie), od kiedy skończyłam Bootcamp w Kodilli. Wnioski? Czeka mnie jeszcze ogrom pracy nad font-endem. Wiem już bardzo dużo, potrafię też wiele. Niestety w moim odczuciu ciągle zbyt mało. Dopiero po roku niektóre sprawy i informacje zrozumiałam. Już nie boję się ich używać i (co ważniejsze) nie boję się publikować na GitHubie moich postępów. W swoim skrzywionym zamyśle uważałam, że nie powinnam pokazywać, jak bardzo niedopracowany jest mój kod. Chyba jest prawie osiem stronek… Dużo, nie dużo.
W kodowaniu jeszcze przerobiłam huk kursów. Był Bootstrap, zwykły html, css oraz zaczęłam kurs GIT-a. Hmmm… co jeszcze? W listopadzie wzięłam w cudownym wyzwaniu #codenovember (u The Awwwesomes), który bardzo mnie zmotywował do dalszej nauki.
Nieodłączna pozostała strona FreeCodeCamp.

Coś jeszcze.

Regularne trenuję i uważnie się odżywiam. Dzięki temu czuję się lepiej i wyniki tarczycowe już tak nie skaczą. Poza tym – miły bonusik – schudłam i nie puchnę.
Jestem bardziej skupiona tym, co jest tu i teraz. W końcu nauczyłam się wybierać, a nie gonić za wszystkim na raz. Miałam czas na wakacje i czytanie książek (w tym roku przeczytałam ich 60).
Zaczęłam bardziej myśleć o sobie. Zaczęłam kurs „Wirtualna Asystentka” i zakończyłam kurs „Pisz tak, aby sprzedawać”.
Bardziej świadomie kupuję i używam codziennych rzeczy. Nie twierdzę, że jestem hiper pro, eko, zero waste itp… Ale staram się i wybieram mądrze.
Zaczynam rozumieć, że tylko ja jestem w stanie pokierować siebie we właściwym (moim) kierunku.

Co będzie.

Blogowanie.

Jeśli chodzi o tę sferę to mam tu dokładnie rozpisane już tematy przewodnie. Zdecydowałam, że ten rok będzie na blogu należał do kodowania.
1⃣ kwartał – Strona www // Front-end;
2⃣ kwartał – Narzędzia developerskie;
3⃣ kwartał – Frameworki;
4⃣ kwartał – Dobre praktyki // Clean code.
To jeśli chodzi o posty eksperckie. Dopuszczam również wpisy typowo lifestylowe. Ale na kodowaniu chcę się bazować.
W ramach pogłębiania wiedzy na temat blogowania i pisania wartościowych tekstów, mam do zrobienia kursy Jasona Hunta oraz kurs SEO.
Instagram, facebook? Zostanie tak, jak dotychczas było. Posty przynajmniej jeden na dzień.

Kodowanie.

Tu popłynęłam z moimi marzeniami i planami. HA! Zbyt wiele i wszystko na raz bym chciała. Już wiem, że w ten sposób nie wiele bym pojęła. To, jaki jest plan? Ugruntowanie tego, co już wiem, czyli html i css. Muszę poczuć się w tym na tyle pewnie, żebym raczej zastanawiała się czym się posłużyć, aby osiągnąć dany efekt, niż szukał rozwiązania. W tym roku chciałabym również nauczyć się JavaScript, bo puki co „liznęłam” go jedynie pobieżnie. I niestety zaniedbałam to, co już wiedziałam. Efekt? Zaczynam od nowa. W kodowaniu najważniejsza jest praktyka.

Wszystkie moje zmagania z kodem będą na GitHubie, a co za tym idzie w trakcie będę robić kurs GIT-a. Dodatkowo muszę popracować nad responsywnością stron (RWD), bo niestety bardzo kuleje w moich projektach.
Chciałam zacząć jeszcze coś w WordPressie, ale chyba tego będzie już za moc. Jak rozpisałam zagadnienia, jakie powinnam opanować lub pogłębić… okazało się, że czasu może braknąć.

Coś jeszcze.

I już ostatnia prosta. Co jeszcze? Treningi, zdrowa dieta, kontrolowanie tarczycy, czas dla rodziny (zwłaszcza Pana Męża – często nasze połówki czują się zaniedbane).

Chcę jeszcze popracować (zadbać) nad swoimi nerwami. Niestety stres zbiera u mnie bardzo duże żniwo, a ja czasami czuję, że wybuchnę w najmniej oczekiwanym momencie. Co do sposobu na poprawę koncentracji, cierpliwości i pamięci (a one najczęściej pogarszają się ze stresem) jeszcze nie podjęłam konkretnych decyzji. Będę szukać odpowiedniego narzędzia. Czy będzie to joga, medytacja lub mainfulness… Nie zdecydowałam. Zobaczymy po wypróbowaniu każdego.

Z rzeczy mało istotnych, ale wciąż odkładanych na później. Muszę na poważnie zabrać się do języka angielskiego. Z tym że nie może to być klasyczna metoda. Dlaczego? Bo ja tak naprawdę dużo rozumie, ale wciąż się boję mówić lub sytuacji, że coś przekręcę, inaczej pojmę i … no właśnie, co będzie?

Tak wiele by się chciało, a to jedynie rok. Raptem 52 tygodni, 365 dni. Odlicz czas przeznaczony na wakacje i święta, weekendy. Należy nam się odpoczynek przecież. Ile nam czasu zostanie na realizacje naszych planów? Jakie masz plany? Zaplanowane cele i rozpisane w kolejnych krokach?

Do dzieła, przed Tobą nowy rok życia.

Artykuł Plany na nowy czas. pochodzi z serwisu To co najważniejsze.

Obecnie wszyscy mają swoje miejsce w internecie. Niektórzy mają profil na Instagramie, inni na Facebooku. Są również osoby, które chcą własnej strony www. Czy to możliwe, jeśli nie chce się za to komuś płacić i nie potrafi się kodować? A może chcą się nauczyć tej sztuki? Wszystko jest obecnie możliwe. Wystarczy chcieć i znaleźć trochę czasu. 

Przyda się też sporo samozaparcia, kiedy motywacja co jakiś czas będzie spadać.

Zbuduj stronę

W internecie można znaleźć wszystko. Dlatego niektórzy chcą mieć tam swoje miejsce. Czy prowadzić bloga, czy postawić stronę wizytówkową – to kwestia motywacji. Jeśli chcemy coś przekazać od siebie, to blog jest dobrym wyborem. Każda opinia jest dobra. A tak na dobrą sprawę nie trzeba wybierać pomiędzy wizytówką a blogiem. Można mieć obie te rzeczy na raz.  

Aby strona faktycznie była nasza, warto kupić sobie domenę oraz miejsce na serwerze. Wtedy jak długo płacimy (raz do roku) tak długo jesteśmy jedynym właścicielem naszej strony. 
Gdzie kupimy domenę i serwer? Wpisując w Googla frazę  „hosting” wyskoczą nam firmy, które się tym zajmują. 
Ja mam serwer na Zenbox.

Którędy droga?

Aby postawić stronę, musisz się zastanowić, jak to zrobić. Nie chcesz nikomu za to płacić? Naucz się tego!. 
Masz dwie drogi. Prostą i tą bardziej czasochłonną.
Wybierając WordPress, możesz dosyć szybko postawić stronę samodzielnie. Ja tak zrobiłam. Ten blog, który czytasz, powstał dzięki Ewelinie Muc i jej kursowi „WP dla zielonych”. I faktycznie jest dla całkiem „zielonych” jeśli chodzi o technologie internetowe.

 Kilka razy w roku może zakupić ten kurs.
Obecnie, do poniedziałku – 08.10 – Ewelina prowadzi jego sprzedaż.

To jest ta prostsza droga. A ta bardziej absorbująca to już faktyczne kodowanie jak front-endowiec. Będziesz potrzebować ogarnięcia HTML5 oraz CSS3. W późniejszym czasie przyda się znajomość JavaScriptu. 
Ogarnięcie tego z pewnością zajmie dużo więcej czasu niż WordPress, ale co się nauczysz to Twoje.

Avocode i Brackets

Jeśli wybierasz tę dłuższą drogę … no cóż, czeka cię trochę pracy. Ale za to jaka satysfakcja! Dwa programy, które Ci pomogą w programowaniu to (według mnie) Avocode – link oraz Brackets – link. 

Avocode

Avocode to program do obróbki plików PSD. Cóż to plik PSD? To format pliku do zapisu grafiki dwuwymiarowej.  Tak zapisuje się projekty stron. Poniżej jej przykład. 
Oczywiście, jeśli chcesz wymyślić stronę całkowicie sama, to nie potrzebujesz tej aplikacji i gotowych projektów. Ale! To narzędzie warto poznać. Zwłaszcza że ma ono 14-dniowy okres próbny. Później płaci się miesięczną subskrypcję, którą zawsze można albo zwiesić lub z niej zrezygnować.

Co potrafi Avocode? Możemy wycinać zdjęcia, pobierać fragmenty kodu, dokładne wymiary elementów oraz ich rozmieszczenie. Mamy gotowe informacje m.in. na temat wysokości, szerokości elementu, czcionki i jej rozmiaru, kolorów; wszystko od razu z odpowiednimi jednostkami. Możemy skopiować wszystko jednym kliknięciem i wkleić do bezpośrednio swojego edytora. Oczywiście nie zakoduje to naszej strony od razu ;), ale bardzo usprawni sam proces.

Brackets

To edytor tekstu stosowany do pisania kodu. Istnieje jeszcze wiele innych stosowanych przez programistów. Dlaczego ten? Próbowałam kilku i ten jest dla mnie najwygodniejszy. Można w nim włączyć opcję Emmet – super sprawa. Co jeszcze? Możesz zmienić jego wygląd, dorzucać masę wtyczek oraz co chyba na początku drogi z kodowaniem jest to prosty w obsłudze program. Koloruje kod. Co to znaczy? Od razu zauważysz, gdzie masz przypisaną kasę, tag czy jakikolwiek inny element (np. zmienne, funkcje w JS).
Poza tym jest dostępny podgląd „na żywo”. Coś jak CodePen, ale lokalnie
Brackets jest dostępny w wersji polskiej i można go podpiąć do GIT-a.

WordPress

Ok. Zdecydowałaś się jednak najpierw poznać WordPress. Też dobra droga, bo oswaja Cię z technologią. Tak ja wspomniałam wyżej – możesz kupić kurs u Eweliny  albo …gdziekolwiek indziej. W internecie wiele osób proponuje kursy WordPressa. W każdym Udemy czy Strefie Kursów znajdziesz to, co potrzebujesz. Możesz też znaleźć na You Tube darmowe kursy WordPressa – czy są dobre? Nie wiem, bo tak jak już pisałam – wierna jestem Ewelinie Muc.
Jest jeszcze jedna osoba, która zajmuje się tą technologią. To Ola Gościniak. Nie tak dawno polecałam ją na naszym fanpage’u na Facebooku. 

Bądź online

Ola napisała książkę o tworzeniu strony www na podstawie WordPress. Od kompletnych podstaw, czyli celu strony do SEO i innych takich spraw. Wszystko opisała prostym językiem i okrasiła ćwiczeniami. Mamy sporą dawkę teorii popartej praktyką. Nic tylko działać. Książkę możesz kupić tu. Ola poza tym prowadzi bardzo merytorycznego bloga na tematy związane z blogowaniem i WordPressem oraz sprzedaje również swój kurs WordPressa. Nie przechodziłam go, ale jeśli jest choć trochę zbliżony stylem do książki, to jest to bardzo fajny wybór. 

Co będzie?

Jeśli chodzi o WordPressa, to warto go znać. I jest mnóstwo kompetentnych osób, które Cię poprowadzą „za rączkę”.

Dodatkowo nauka html, css i JS to inwestycja w Twoje umiejętności. W serii wpisów o front-endzie chce Ci pokazać, co można zakodować samej. Dlatego na początek wybierz projekt. Tak jak już wspomniałam, taki projekt zapisany jest w pliku PSD. Gdzie znaleźć takie projekty? 
Masz dwie drogi (znowu!;)).
Wpisz w wujka googla: „projekt PSD free”.

Albo skorzystaj z linku poniżej. Zapisując się na darmowe konto, możesz wybierać, przebierać w setkach projektów stron. 

Artykuł Moja www… pochodzi z serwisu To co najważniejsze.

Za każdym razem, kiedy przestawałam na jakiś czas (tydzień, dwa) coś robić, okazywały się dwie rzeczy:

• zapominałam po części tego, co się nauczyłam – wtedy ratują nas dobre notatki.
• strasznie trudno wrócić do codziennej praktyki.

A co się u mnie działo w czerwcu? Kilka rozpoczętych wyzwań, tych całkowicie prywatnych i tych publicznych.

Wyzwania:

• #webdevchallenge – pisałam o nim ostatnio. I … pokonało mnie. Tak bywa. Próbowałam i próbowałam, ale frustracja spowodowana moimi brakami w wiedzy i umiejętności wygrała. Ale, ale … odkładam je jedynie na później podobnie jak ogarnięcie paru kursów z JavyScript. „Nie mówię nie – mówię: później”.
• #100DaysOfCode – działam i raportuję na Twitterze codziennie czego się uczyłam i co robiłam związanego z kodowaniem.

Kursy:

• ciągle nadal na tapecie jest FreeCodeCamp;
• skończyłam kurs o Bootstrap4 na udemy;
• zaczęłam kolejny o Bootstrap 4 na … strefa kursów – zapytacie, po co robić dwa kursy w tej samej tematyce? Odpowiedź jest nader prosta. Pierwszy kurs był w języku angielskim i nie jestem osobiście pewna czy wszystko dobrze zrozumiałam… nie ufam na tyle mojej znajomości języka angielskiego… Podskórnie czuję, że coś mi chyba w głowie źle się zakodowało.

Lecę jeszcze z aplikacją na telefon: SoloLearn. W maju zaczęłam podstawy HTML i CSS. W czerwcu skończyłam CSS i zaczęłam podstawy JavaScript.

Poza tym w końcu przeczytałam do końca ( a ciągnęła mi się niemiłosiernie) „JavaScript dla dzieci” Nick Morgan.

Cóż o niej mogę napisać? W bardzo prosty wręcz „łopatologicznie” (serio!) tłumaczy wszystko, co najważniejsze w JavaScripcie. Pokazuje krok po kroku jak napisać prostą grę i tłumaczy co każda funkcja, metoda itp. robi. Zdecydowanie jest to książka dla tych, którzy nie mieli z programowaniem nic wspólnego.
Dlaczego szło mi tak opornie jej czytanie? Po pierwsze miałam darmowy ( no, powiedzmy – wypożyczony przez moją bibliotekę ) ebook, który czytałam na aplikacji zainstalowanej na komórce. Często owa appka mi się wieszała i (co tu dużo mówić) przegrywała z papierowymi książkami. Sorry … taki mamy klimat.

Aktualnie na tapecie pojawił się również ebook z biblioteki p.t. „HTML5 i CSS3 Definicja nowoczesności” Dawid Mazur. Na razie nie mam wyrobionej opinii. Choć to znowu będą podstawy podstaw. Grunt to usystematyzować wiedzę.

Zrobiłam też malutką stronkę, jeśli chcecie zobaczyć, to zapraszam. – link.

Artykuł Raport 5 pochodzi z serwisu To co najważniejsze.

Ale nie jest tak, że nic nie zrobiłam. Po prostu w moim odczuciu zrobiłam zbyt mało. Ale możliwe jest, że tak sugeruje mój wewnętrzny krytyk. Popycha mnie do zbytniego perfekcjonizmu na każdym polu.

Szczerze Avocode odpaliłam w zeszłym miesiącu, zdaje się, że tylko z dwa razy (?). Nie ma co się chwalić, bo nie posunęłam się zbytnio do przodu w tej materii.
Książka Ducketta  „HTML i CSS. Zaprojektuj i zbuduj witrynę www” jest na bieżąco czytana, bardziej jako uzupełnienie kursu na FreeCodeCamp.
JavaScript w 30 dni ostatecznie odłożyłam na bliżej nieokreślony czas. Niestety tego wszystkiego było za dużo, a dodatkowo (muszę się do tego przyznać) mój angielski jest raczej toporny i wszystko, co Wes Bos mówi, ja niestety muszę na spokojnie sobie przetłumaczyć (nierzadko z tłumaczem google), aby zrozumieć. No i oczywiście czegoś się nauczyć.

Zostaje jeszcze pan Linux. Zrobiłam to! Na ten temat planuję posta. Opiszę, jak to wygląda i jak się do tego zabrać krok po kroku. Jedno przesłanie – Bój się i działaj. Naprawdę nie wiem, dlaczego tak długo zwlekałam z tym. Nowego Windowsa bym nie kupiła ekstra dla Toshiby. To by się nie kalkulowało, bo bym musiała ją jeszcze dodatkowo podkręcać. W końcu to staruszka – ma osiem(!!) lat.

Kolejna partia książek do Skupbook.pl już poleciała. Planuję kolejne. A Wy jak pozbywacie się swoich książek?

Artykuł Raport 3 pochodzi z serwisu To co najważniejsze.