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.

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.

Wtorek, 3 czerwca, 22:47. Ostatni test przechodzi. Zielone checkmarki w konsoli. Aplikacja działa.

Mój pierwszy większy projekt w Java jest GOTOWY.

Patrzę na ekran i czuję… dumę? Ulgę? Niedowierzanie? Wszystko naraz.

5 tygodni temu to był tylko pomysł w Notion: „Zbuduj coś prawdziwego, nie tylko ćwiczenia z kursu.” Dzisiaj mam 47 klas, 2847 linii kodu i działającą aplikację do zarządzania terapiami mojego dziecka.

Pierwszy projekt w Java to przełom. To moment, gdy przestajesz być „osobą, która się uczy” i stajesz się „osobą, która buduje”. To jest ogromna różnica.

Dziś opowiem Wam całą historię – od pomysłu, przez architekturę, wyzwania techniczne, do finału. I najważniejsze: co czułam kończąc pierwszy prawdziwy projekt jako programistka.

Skąd pomysł – dlaczego akurat aplikacja do terapii?

Problem, który widziałam codziennie

Moja rzeczywistość:

• 8-9 godzin terapii tygodniowo (SI, logopedia, pedagogika, TUS)
• 3 różne ośrodki
• 5 terapeutów
• Niekończące się faktury, zestawienia kosztów, raporty dla NFZ
• Excel, który się sypie co miesiąc

Próbowałam gotowych rozwiązań:

• Kalendarz Google – za prosty (tylko daty, bez kosztów)
• Excel – chaotyczny, gubię dane
• Aplikacje do zarządzania zdrowiem – zbyt ogólne, nie dla terapii

Pomyślałam: „Co jeśli zbuduję własną aplikację?”

Punkt zwrotny – rozmowa z instruktorem kursu

Napisałam na Discord Zajavka:

„Skończyłam podstawy kursu. Co dalej? Spring? JavaScript?”

Instruktor odpowiedział:

„Przed Springiem zbuduj JEDEN solidny projekt w czystej Javie. Coś co rozwiązuje prawdziwy problem. Pokaże Ci jak projektować aplikacje, nie tylko pisać kod.”

I kliknęło.

Pierwszy projekt w Java – planowanie

Tydzień 1: Research i wymyślanie funkcjonalności

Pytania, które sobie zadałam:

1. Co aplikacja MUSI umieć? (MVP – Minimum Viable Product)
   • Dodawanie sesji terapii
   • Przechowywanie informacji o terapeutach i ośrodkach
   • Kalkulacja kosztów miesięcznych
   • Generowanie raportów
2. Co byłoby FAJNE, ale nie konieczne? (v2.0)
   • Przypomnienia o sesjach
   • Statystyki roczne
   • Export do PDF
   • Integracja z kalendarzem
3. Czego NIE potrzebuję? (scope control)
   • GUI (graficzny interfejs) – na razie konsola wystarczy
   • Baza danych – na razie pliki tekstowe
   • Multi-user – tylko ja używam

Decyzja: Buduję wersję konsolową z podstawowymi funkcjami. GUI później.

Tydzień 2: Architektura – najpierw plan, potem kod

Błąd początkujących: Otwieram IDE i zaczynam pisać kod bez planu.

Lepsze podejście: Planuję strukturę na papierze.

Moja architektura – diagram klas:

MAIN ENTITIES (główne encje):

TherapySession (Sesja terapii)
├── sessionId: String
├── therapyType: TherapyType (enum)
├── therapist: Therapist
├── dateTime: LocalDateTime
├── duration: int (minuty)
├── cost: BigDecimal
├── paid: boolean
├── notes: String

Therapist (Terapeuta)
├── therapistId: String
├── name: String
├── specialization: String
├── phone: String
├── email: String
├── hourlyRate: BigDecimal

TherapyCenter (Ośrodek terapeutyczny)
├── centerId: String
├── name: String
├── address: Address
├── phone: String
├── therapists: List<Therapist>

TherapyType (Typ terapii - ENUM)
├── SI (Integracja sensoryczna)
├── SPEECH (Logopedia)
├── PEDAGOGY (Pedagogika)
├── EARLY_INTERVENTION (Wczesne wspomaganie)

SERVICES (serwisy – logika biznesowa):

TherapySessionService
├── addSession()
├── updateSession()
├── deleteSession()
├── findSessionById()
├── getAllSessions()
├── getSessionsByMonth()
├── getSessionsByTherapist()

ReportService
├── generateMonthlyReport()
├── calculateTotalCost()
├── calculateCostByType()
├── generateYearlyStatistics()

PaymentService
├── markAsPaid()
├── getUnpaidSessions()
├── getTotalUnpaid()

REPOSITORIES (dostęp do danych):

FileRepository<T>
├── save(T entity)
├── findById(String id)
├── findAll()
├── delete(String id)
├── update(T entity)

UTILITIES (narzędzia pomocnicze):

DateUtils - formatowanie dat
ValidationUtils - walidacja danych
FileUtils - operacje na plikach

Dlaczego taka struktura?

Podział odpowiedzialności:

• Entities = Dane (co przechowujemy)
• Services = Logika (co robimy z danymi)
• Repositories = Dostęp (jak zapisujemy/odczytujemy)
• UI = Interfejs (jak użytkownik widzi)

Efekt: Jeśli zmienię sposób zapisywania (z plików na bazę danych) – zmieniam tylko Repository. Services i Entities pozostają bez zmian.

Tydzień 3-4: Implementacja – pierwszy kod

Zaczynanie od Entity

TherapySession.java – pierwsza klasa:

java

public class TherapySession {
    private String sessionId;
    private TherapyType therapyType;
    private Therapist therapist;
    private LocalDateTime dateTime;
    private int durationMinutes;
    private BigDecimal cost;
    private boolean paid;
    private String notes;
    
    // Constructor
    public TherapySession(String sessionId, TherapyType therapyType, 
                         Therapist therapist, LocalDateTime dateTime,
                         int durationMinutes, BigDecimal cost) {
        this.sessionId = sessionId;
        this.therapyType = therapyType;
        this.therapist = therapist;
        this.dateTime = dateTime;
        this.durationMinutes = durationMinutes;
        this.cost = cost;
        this.paid = false; // domyślnie nieopłacone
    }
    
    // Getters and setters
    public String getSessionId() { return sessionId; }
    public TherapyType getTherapyType() { return therapyType; }
    // ... itd
    
    // Business methods
    public void markAsPaid() {
        this.paid = true;
    }
    
    public boolean isInMonth(int year, int month) {
        return dateTime.getYear() == year 
            && dateTime.getMonthValue() == month;
    }
    
    @Override
    public String toString() {
        return String.format("%s | %s | %s | %.2f zł | %s",
            dateTime.format(DateTimeFormatter.ofPattern("dd.MM.yyyy HH:mm")),
            therapyType,
            therapist.getName(),
            cost,
            paid ? "OPŁACONE" : "DO ZAPŁATY"
        );
    }
}

Co się nauczyłam:

• BigDecimal dla pieniędzy (nie double! – problemy z precyzją)
• LocalDateTime dla dat (lepsze niż Date)
• Enum dla typów terapii (type-safe, nie String)
• Business methods w encji (markAsPaid, isInMonth)

Wzorzec repozytorium – pierwsza abstrakcja

Problem: Jak zapisywać dane?

Opcje:

1. Baza danych (za trudne na start)
2. Pliki tekstowe (proste, ale jak czytać/zapisywać?)

Rozwiązanie: Wzorzec repozytorium z plikami JSON

FileRepository.java – generyczny repozytorium:

java

public class FileRepository<T> {
    private final String filePath;
    private final Class<T> entityClass;
    private final ObjectMapper objectMapper; // Jackson dla JSON
    
    public FileRepository(String filePath, Class<T> entityClass) {
        this.filePath = filePath;
        this.entityClass = entityClass;
        this.objectMapper = new ObjectMapper()
            .registerModule(new JavaTimeModule()); // dla LocalDateTime
    }
    
    public void save(T entity) throws IOException {
        List<T> entities = findAll();
        entities.add(entity);
        writeToFile(entities);
    }
    
    public List<T> findAll() throws IOException {
        File file = new File(filePath);
        if (!file.exists()) {
            return new ArrayList<>();
        }
        
        return objectMapper.readValue(file, 
            objectMapper.getTypeFactory()
                .constructCollectionType(List.class, entityClass)
        );
    }
    
    public Optional<T> findById(String id) throws IOException {
        return findAll().stream()
            .filter(e -> getId(e).equals(id))
            .findFirst();
    }
    
    public void update(T entity) throws IOException {
        List<T> entities = findAll();
        String id = getId(entity);
        
        entities.removeIf(e -> getId(e).equals(id));
        entities.add(entity);
        writeToFile(entities);
    }
    
    public void delete(String id) throws IOException {
        List<T> entities = findAll();
        entities.removeIf(e -> getId(e).equals(id));
        writeToFile(entities);
    }
    
    private void writeToFile(List<T> entities) throws IOException {
        objectMapper.writerWithDefaultPrettyPrinter()
            .writeValue(new File(filePath), entities);
    }
    
    // Reflection do wyciągnięcia ID
    private String getId(T entity) {
        try {
            Method method = entity.getClass().getMethod("getSessionId");
            return (String) method.invoke(entity);
        } catch (Exception e) {
            throw new RuntimeException("Entity must have getSessionId method", e);
        }
    }
}

Co się nauczyłam:

• Generics (<T>) – jeden magazyn dla różnych encji
• Jackson ObjectMapper – serialization (proces przekształcania obiektów, tj. instancji określonych klas) do JSON
• Reflection (mechanizm, który umożliwia na odczyt i modyfikację informacji o klasach) – wyciąganie ID dynamicznie
• Exception handling (Obsługa wyjątków )- IOException musi być obsłużone

Service layer – logika biznesowa

TherapySessionService.java:

java

public class TherapySessionService {
    private final FileRepository<TherapySession> repository;
    
    public TherapySessionService() {
        this.repository = new FileRepository<>(
            "data/therapy_sessions.json", 
            TherapySession.class
        );
    }
    
    public void addSession(TherapySession session) {
        try {
            // Walidacja
            if (session.getCost().compareTo(BigDecimal.ZERO) <= 0) {
                throw new IllegalArgumentException("Koszt musi być > 0");
            }
            if (session.getDateTime().isAfter(LocalDateTime.now())) {
                System.out.println("UWAGA: Sesja w przyszłości");
            }
            
            repository.save(session);
            System.out.println("✓ Dodano sesję: " + session);
            
        } catch (IOException e) {
            System.err.println("Błąd zapisu: " + e.getMessage());
        }
    }
    
    public List<TherapySession> getSessionsByMonth(int year, int month) {
        try {
            return repository.findAll().stream()
                .filter(s -> s.isInMonth(year, month))
                .sorted(Comparator.comparing(TherapySession::getDateTime))
                .toList();
        } catch (IOException e) {
            System.err.println("Błąd odczytu: " + e.getMessage());
            return new ArrayList<>();
        }
    }
    
    public void markSessionAsPaid(String sessionId) {
        try {
            Optional<TherapySession> session = repository.findById(sessionId);
            if (session.isPresent()) {
                session.get().markAsPaid();
                repository.update(session.get());
                System.out.println("✓ Oznaczono jako opłacone");
            } else {
                System.out.println("✗ Nie znaleziono sesji");
            }
        } catch (IOException e) {
            System.err.println("Błąd: " + e.getMessage());
        }
    }
}

Co się nauczyłam:

• Walidacja danych (sprawdzanie przed zapisem)
• User feedback (komunikaty co się dzieje)
• Error handling (try-catch, komunikaty błędów)
• Stream API dla filtrowania i sortowania

Report Service – generowanie raportów

To była najtrudniejsza część.

ReportService.java:

java

public class ReportService {
    private final TherapySessionService sessionService;
    
    public void generateMonthlyReport(int year, int month) {
        List<TherapySession> sessions = 
            sessionService.getSessionsByMonth(year, month);
        
        if (sessions.isEmpty()) {
            System.out.println("Brak sesji w tym miesiącu");
            return;
        }
        
        System.out.println("=".repeat(80));
        System.out.println("RAPORT MIESIĘCZNY: " + month + "/" + year);
        System.out.println("=".repeat(80));
        
        // Grupowanie po typie terapii
        Map<TherapyType, List<TherapySession>> byType = sessions.stream()
            .collect(Collectors.groupingBy(TherapySession::getTherapyType));
        
        // Podsumowanie per typ
        byType.forEach((type, typeSessions) -> {
            int count = typeSessions.size();
            int totalMinutes = typeSessions.stream()
                .mapToInt(TherapySession::getDurationMinutes)
                .sum();
            BigDecimal totalCost = typeSessions.stream()
                .map(TherapySession::getCost)
                .reduce(BigDecimal.ZERO, BigDecimal::add);
            long paidCount = typeSessions.stream()
                .filter(TherapySession::isPaid)
                .count();
            
            System.out.printf("\n%s:\n", type);
            System.out.printf("  Liczba sesji: %d\n", count);
            System.out.printf("  Całkowity czas: %dh %dmin\n", 
                totalMinutes / 60, totalMinutes % 60);
            System.out.printf("  Całkowity koszt: %.2f zł\n", totalCost);
            System.out.printf("  Opłacone: %d/%d\n", paidCount, count);
        });
        
        // Suma totalna
        BigDecimal grandTotal = sessions.stream()
            .map(TherapySession::getCost)
            .reduce(BigDecimal.ZERO, BigDecimal::add);
        
        BigDecimal unpaid = sessions.stream()
            .filter(s -> !s.isPaid())
            .map(TherapySession::getCost)
            .reduce(BigDecimal.ZERO, BigDecimal::add);
        
        System.out.println("\n" + "=".repeat(80));
        System.out.printf("SUMA CAŁKOWITA: %.2f zł\n", grandTotal);
        System.out.printf("DO ZAPŁATY: %.2f zł\n", unpaid);
        System.out.println("=".repeat(80));
    }
}
```

**Output przykładowy:**
```
================================================================================
RAPORT MIESIĘCZNY: 5/2026
================================================================================

SI:
  Liczba sesji: 8
  Całkowity czas: 8h 0min
  Całkowity koszt: 600.00 zł
  Opłacone: 8/8

SPEECH:
  Liczba sesji: 8
  Całkowity czas: 6h 0min
  Całkowity koszt: 520.00 zł
  Opłacone: 6/8

PEDAGOGY:
  Liczba sesji: 4
  Całkowity czas: 4h 0min
  Całkowity koszt: 240.00 zł
  Opłacone: 4/4

================================================================================
SUMA CAŁKOWITA: 1360.00 zł
DO ZAPŁATY: 130.00 zł
================================================================================

Co się nauczyłam:

• Collectors.groupingBy() – grupowanie strumieni
• Reduce dla sumowania BigDecimal
• String formatting (printf)
• Prezentacja danych (czytelny output)

Tydzień 5: UI i finiszowanie

Interfejs konsolowy – prosty, ale funkcjonalny

MainMenu.java:

java

public class MainMenu {
    private final Scanner scanner;
    private final TherapySessionService sessionService;
    private final ReportService reportService;
    
    public void run() {
        while (true) {
            displayMenu();
            int choice = getChoice();
            
            switch (choice) {
                case 1 -> addSession();
                case 2 -> listSessions();
                case 3 -> markAsPaid();
                case 4 -> generateReport();
                case 5 -> {
                    System.out.println("Do widzenia!");
                    return;
                }
                default -> System.out.println("Nieprawidłowy wybór");
            }
        }
    }
    
    private void displayMenu() {
        System.out.println("\n" + "=".repeat(50));
        System.out.println("SYSTEM ZARZĄDZANIA TERAPIAMI");
        System.out.println("=".repeat(50));
        System.out.println("1. Dodaj sesję terapii");
        System.out.println("2. Pokaż sesje (obecny miesiąc)");
        System.out.println("3. Oznacz jako opłacone");
        System.out.println("4. Generuj raport miesięczny");
        System.out.println("5. Wyjście");
        System.out.print("\nWybór: ");
    }
    
    private void addSession() {
        System.out.println("\n=== NOWA SESJA ===");
        
        // Wybór typu terapii
        System.out.println("Typ terapii:");
        TherapyType[] types = TherapyType.values();
        for (int i = 0; i < types.length; i++) {
            System.out.printf("%d. %s\n", i + 1, types[i]);
        }
        int typeChoice = scanner.nextInt() - 1;
        TherapyType type = types[typeChoice];
        
        // Wybór terapeuty (z listy wcześniej dodanych)
        Therapist therapist = selectTherapist();
        
        // Data i czas
        System.out.print("Data (dd.MM.yyyy): ");
        String dateStr = scanner.next();
        System.out.print("Godzina (HH:mm): ");
        String timeStr = scanner.next();
        LocalDateTime dateTime = parseDateTime(dateStr, timeStr);
        
        // Czas trwania
        System.out.print("Czas trwania (minuty): ");
        int duration = scanner.nextInt();
        
        // Koszt
        System.out.print("Koszt (zł): ");
        BigDecimal cost = scanner.nextBigDecimal();
        
        // Utworzenie sesji
        TherapySession session = new TherapySession(
            UUID.randomUUID().toString(),
            type,
            therapist,
            dateTime,
            duration,
            cost
        );
        
        sessionService.addSession(session);
    }
}

Co się nauczyłam:

• Scanner dla input użytkownika
• Menu loop (while true + switch)
• UUID dla unikalnych ID
• User experience (komunikaty, formatowanie)

Wyzwania techniczne – co było najtrudniejsze

1. Serializacja LocalDateTime do JSON

Problem:

java

Exception: Cannot serialize LocalDateTime

Rozwiązanie:

java

ObjectMapper mapper = new ObjectMapper()
    .registerModule(new JavaTimeModule())
    .disable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS);

Lekcja: Jackson potrzebuje dodatkowych modułów dla Java 8 Date/Time API.

2. BigDecimal arytmetyka

Problem:

java

BigDecimal total = cost1 + cost2; // BŁĄD! Nie można + dla BigDecimal

Rozwiązanie:

java

BigDecimal total = cost1.add(cost2);

Lekcja: BigDecimal to immutable (niemodyfikowalny), używaj metod (.add, .subtract, .multiply)

3. File I/O exceptions

Problem: Aplikacja crashuje gdy plik nie istnieje.

Rozwiązanie:

java

public List<T> findAll() throws IOException {
    File file = new File(filePath);
    if (!file.exists()) {
        // Utwórz pusty plik
        file.getParentFile().mkdirs();
        file.createNewFile();
        writeToFile(new ArrayList<>());
        return new ArrayList<>();
    }
    return objectMapper.readValue(file, ...);
}

Lekcja: Zawsze sprawdzaj czy plik/folder istnieje przed czytaniem.

4. Null handling w Optional

Problem:

java

TherapySession session = repository.findById(id); // może null
session.markAsPaid(); // NullPointerException!

Rozwiązanie:

java

Optional<TherapySession> sessionOpt = repository.findById(id);
if (sessionOpt.isPresent()) {
    sessionOpt.get().markAsPaid();
} else {
    System.out.println("Nie znaleziono");
}

// Lub functional style:
sessionOpt.ifPresent(TherapySession::markAsPaid);
```

**Lekcja:** Optional to explicite "może być null", obsługuj zawsze.

## Statystyki projektu - liczby

**Czas pracy:** 5 tygodni (kwiecień-maj 2026)
- Tydzień 1: Planowanie (10h)
- Tydzień 2: Architektura (8h)
- Tydzień 3-4: Implementacja (25h)
- Tydzień 5: UI + testy (12h)
- **Total: ~55 godzin**

**Kod:**
- **47 klas** (entities, services, repositories, utils, UI)
- **2847 linii kodu** (bez komentarzy)
- **89 metod** (średnio 32 linie/klasa)
- **23 pliki testowe** (JUnit tests)

**Biblioteki użyte:**
- Jackson (JSON serialization)
- JUnit 5 (testy jednostkowe)
- SLF4J + Logback (logging)

**Struktura folderów:**
```
therapy-manager/
├── src/
│   ├── main/
│   │   ├── java/
│   │   │   ├── com.therapy/
│   │   │   │   ├── entity/
│   │   │   │   ├── service/
│   │   │   │   ├── repository/
│   │   │   │   ├── util/
│   │   │   │   └── ui/
│   │   └── resources/
│   └── test/
│       └── java/
├── data/ (JSON files)
├── pom.xml (Maven dependencies)
└── README.md

Co czułam finiszując projekt

3 czerwca, 22:47 – ostatni test przechodzi

Uczucia w tym momencie:

1. Niedowierzanie „To naprawdę działa? Ja to zbudowałam?”

5 miesięcy temu nie znałam Javy. Dzisiaj mam działającą aplikację z 47 klasami.

2. Duma Pokazałam partnerowi: „Patrz, to dodaje sesję, to generuje raport…”

On: „Zrobiłaś TO?! To jest niesamowite!”

Ja: wzruszenie (szczęśliwe łzy)

3. Ulga Mogłam odpuścić 100 razy. „Za trudne”, „Nie dam rady”, „Może później”.

Ale nie odpuściłam. I skończyłam.

4. Więcej… To był tylko początek. Już myślałam: „Co dalej? GUI? Baza danych? Spring?”

Perspektywa – co projekt zmienił

Przed projektem:

• „Programowanie to nauka składni i algorytmów”
• „Projekty to coś dla ekspertów”
• „Ja tylko uczę się z tutoriali”

Po projekcie:

• „Programowanie to rozwiązywanie problemów”
• „Projekty to jedyny sposób, żeby naprawdę się nauczyć”
• „Ja BUDUJĘ, nie tylko uczę się”

Mentalna zmiana: Od „osoby która się uczy” do „programistki”.

Co bym zrobiła inaczej

1. Testy od początku, nie na końcu

Zrobiłam: Napisałam kod, potem testy.

Lepiej: TDD (Test-Driven Development) – testy najpierw, kod potem.

Dlaczego: Łatwiej refaktorować, gdy masz testy.

2. Mniejsze commity do Git

Zrobiłam: Wielkie commity „Added 10 classes”

Lepiej: Małe, atomowe commity „Add TherapySession entity”, „Add FileRepository”

Dlaczego: Łatwiej wrócić do poprzedniej wersji.

3. Więcej loggingu

Zrobiłam: System.out.println() wszędzie

Lepiej: SLF4J logger z poziomami (DEBUG, INFO, ERROR)

Dlaczego: Łatwiejszy debugging na produkcji.

4. Dokumentacja w trakcie, nie po

Zrobiłam: Dokumentacja README na końcu (zapomniałam połowę decyzji)

Lepiej: Notatki w Notion podczas budowania

Dlaczego: Świeża pamięć = lepsza dokumentacja.

Co dalej – plany na projekt

Wersja 1.0 (zrobione):

• Konsolowy interface
• JSON file storage
• Podstawowe raporty

Wersja 2.0 (czerwiec-lipiec):

• GUI (JavaFX) – graficzny interfejs
• Eksport raportów do PDF
• Charts (wykresy kosztów)

Wersja 3.0 (sierpień-wrzesień):

• Baza danych (PostgreSQL zamiast JSON)
• Multi-user (mąż też może dodawać sesje)
• Web interface (może Spring Boot?)

Ale najpierw: Przerwa. Odpoczynek. Perspektywa.

Nauki z pierwszego projektu w Java

Techniczne:

OOP design – jak projektować klasy i relacje
Wzorce projektowe – repozytorium, warstwa usług, wstrzykiwanie zależności
File I/O – czytanie/zapis plików, JSON serializacja
Kolekcje i strumienie – filtrowanie, grupowanie, redukcja
Obsługa wyjątków – try-catch, niestandardowe wyjątki
Testing – JUnit, pokrycie testowe

Nietechniczne (ważniejsze!):

Ukończenie > Perfekcja – lepiej skończony prosty projekt niż nie skończony perfekcyjny
Małe kroki – 1h dziennie przez 5 tygodni > 10h przez 1 dzień
Realne problemy – budowanie czegoś co rozwiązuje własny problem = motywacja
Liczy się pęd – 1 dzień przerwy OK, 3 dni = trudno wrócić
Świętuj zwycięstwa – skończony projekt = osiągnięcie, świętuj to!

FAQ – pierwszy projekt w Java

Czy potrzebuję skończyć cały kurs przed projektem?

NIE. Ja zaczęłam projekt po:

• Podstawach składni (zmienne, pętle, warunki)
• OOP (klasy, obiekty, dziedziczenie)
• Collections (List, Map, Set)
• Podstawach Streams

Reszta nauczyłam się w trakcie projektu (JSON, File I/O, design patterns).

Ile czasu dziennie pracowałaś?

Średnio: 1.5h dziennie (10-15h tygodniowo)

Rozłożenie:

• Popołudnia: 1h (14:00-15:00)
• Wieczory: 30 min (21:30-22:00) – gdy energia była

Weekendy: 3-4h (sobota rano, partner z dziećmi)

Jak wybrać dobry projekt dla początkujących?

3 kryteria:

1. Rozwiązuje TWÓJ problem – motywacja wewnętrzna
2. Zakres realistyczny – zrobisz w 4-6 tygodni
3. Trochę za trudny – uczysz się nowego, ale nie przytłaczający

Przykłady dobrych pierwszych projektów:

• Todo list manager (klasyk, ale działa)
• Expense tracker (śledzenie wydatków)
• Library manager (zarządzanie książkami)
• Habit tracker (śledzenie nawyków)
• Recipe organizer (przepisy kulinarne)

Zły projekt: „Zbuduję Facebooka” (gwarantowane rozszerzenie zakresu)

Co jeśli utknę i nie wiem jak coś zrobić?

Moja strategia:

1. Google (15 min) – „How to serialize LocalDateTime to JSON Java”
2. Stack Overflow (15 min) – czytam różne rozwiązania
3. ChatGPT (10 min) – pytam o konkretny problem
4. Discord/forum kursu (24h) – pytam instruktora
5. Następnego dnia świeży umysł– czasem sen rozwiązuje

Zasada: Max 1h szukania rozwiązania. Potem przerwa/pomoc.

Czy pokazać projekt w portfolio?

TAK! Nawet prosty projekt pokazuje:

• Umiesz skończyć, co zaczynasz
• Rozumiesz OOP i design patterns
• Piszesz czysty kod
• Rozwiązujesz problemy

Lepiej: 1 skończony prosty projekt niż 10 nie skończonych „ambitnych”.

Podsumowanie – mój pierwszy prawdziwy projekt

Therapy Manager v1.0:

• 47 klas
• 2847 linii kodu
• 55 godzin pracy
• 5 tygodni od pomysłu do finiszu
• Aplikacja która rozwiązuje mój realny problem

Co zyskałam:

• Umiejętność projektowania aplikacji
• Pewność siebie jako programistka
• Element portfolio (pokazuję na GitHubie)
• Praktyczne narzędzie (używam codziennie!)

Najważniejsza lekcja:

„Programowania nie uczy się przez czytanie poradników. Uczy się przez BUDOWANIE.”

Możesz przeczytać 100 tutoriali o Javie. Ale dopiero gdy zbudujesz projekt – rozumiesz jak to wszystko się łączy.

Pierwszy projekt w Java to przełom. Od „osoby która się uczy” do „osoby która buduje”.

I jeśli ja mogłam – z godzinę dziennie, z dziećmi w terapiach, między freelancingiem – to Ty też możesz.

Zbuduj coś. Zakończ to. Świętuj.

PS: Też budujesz swój pierwszy projekt? Utknąłeś gdzieś? Napisz w komentarzu – chętnie pomogę! A jeśli skończyłeś projekt – podziel się, co zbudowałeś? Ciekawa jestem!

Artykuł Learning Log #5: Pierwszy większy projekt w Java – od pomysłu do działającej aplikacji pochodzi z serwisu To co najważniejsze.

Kawa trzecia dzisiaj. Kod na ekranie wygląda… dziwnie. Zamiast pętli for mam

.stream().filter().map().collect()

Zamiast:

java

for (int i = 0; i < list.size(); i++) { ... }

Mam:

java

list.stream().forEach(item -> ...)

Witajcie w świecie programowania funkcyjnego w Java.

Tydzień 13-14 mojej nauki (po oficjalnym zakończeniu podstaw Zajavka) poświęciłam na zaawansowane tematy: strumienie (Streams API), wyrażenia lambda i Optional. Tematy, które na początku wyglądały jak hieroglify, a teraz… no cóż, nadal są trudne, ale już rozumiem PO CO.

Czym są wyrażenia lambda w Java?

Najprostsza definicja:

Lambda to funkcja bez nazwy, którą można przekazać jako argument.

Zamiast pisać:

java

public interface Greeting { 
    void sayHello(String name); 
}

public class PolishGreeting implements Greeting { 
     @Override 
     public void sayHello(String name) { 
         System.out.println("Cześć " + name); 
     } 
}

// Użycie: 
Greeting greeting = new PolishGreeting(); 
greeting.sayHello("Anna");

Możesz napisać:

java

Greeting greeting = (name) -> System.out.println("Cześć " + name); 
greeting.sayHello("Anna");

10 linii → 1 linia. To jest moc lambd.

Składnia lambda – od długiej do krótkiej:

java

// Wersja pełna (typ parametru + nawias + return) 
(String name) -> { return "Cześć " + name; }

// Bez typu (Java infers - wywnioskuje) 
(name) -> { return "Cześć " + name; }

// Bez return (single expression) 
(name) -> "Cześć " + name

// Jeden parametr = bez nawiasu 
name -> "Cześć " + name

Wszystkie 4 wersje robią TO SAMO.

Mój przykład – filtrowanie terapii:

Przed lambdą:

java

public class ExpensiveTherapyFilter {    public List<Therapy> filter(List<Therapy> therapies) { 
          List<Therapy> result = new ArrayList<>(); 
          for (Therapy therapy : therapies) {
               if (therapy.getCost() > 70) {
                   result.add(therapy);
               } 
          } 
          return result; 
   }
}

Z lambdą:

java

List<Therapy> expensive = therapies.stream()     .filter(t -> t.getCost() > 70) 
     .collect(Collectors.toList());

15 linii → 3 linie. Czytelniejsze. Mniej szablonowe.

Streams API – pipeline przetwarzania danych

Czym jest strumień (stream)?

Strumień to sekwencja elementów które możesz przetwarzać w pipeline (rurociąg).

Analogia – taśma produkcyjna:

Wyobraź sobie fabrykę:

1. Źródło: Surowce wchodzą na taśmę
2. Operacje pośrednie: Czyszczenie → Cięcie → Malowanie
3. Operacja końcowa: Pakowanie do pudełka

W Javie:

1. Źródło: list.stream()
2. Operacje pośrednie: .filter() → .map() → .sorted()
3. Operacja końcowa: .collect() lub .forEach()

Podstawowe operacje:

filter() – filtrowanie

java

// Tylko terapie droższe niż 70 zł 
List<Therapy> expensive = therapies.stream()      .filter(t -> t.getCost() > 70) 
     .collect(Collectors.toList());

map() – transformacja

java

// Lista kosztów (z Therapy robi Double) 
   List<Double> costs = therapies.stream() 
        .map(t -> t.getCost()) 
        .collect(Collectors.toList());

// Skrócona wersja (method reference): 
   List<Double> costs = therapies.stream() 
       .map(Therapy::getCost) 
       .collect(Collectors.toList());

sorted() – sortowanie

java

// Posortowane po cenie (rosnąco) 
List<Therapy> sorted = therapies.stream()         .sorted(Comparator.comparing(Therapy::getCost)) 
    .collect(Collectors.toList());

forEach() – akcja na każdym

java

// Wypisz każdą terapię 
   therapies.stream() 
       .forEach(t -> System.out.println(t.getName()));

// Lub krócej: 
   therapies.stream() 
       .forEach(System.out::println);`

Łańcuchowanie operacji (chaining):

java

// Znajdź 3 najdroższe terapie typu "SI" i wypisz ich nazwy 
therapies.stream()    .filter(t -> t.getType().equals("SI")) // tylko SI 
    .sorted(Comparator.comparing(Therapy::getCost).reversed()) // od najdroższych 
    .limit(3) // tylko 3 
    .map(Therapy::getName) // same nazwy 
    .forEach(System.out::println); // wypisz

Piękno: Czytasz to jak zdanie po polsku – „weź terapie, odfiltruj SI, posortuj po cenie malejąco, weź 3, wyciągnij nazwy, wypisz”

Mój projekt – analiza kosztów terapii z Streams

Zbudowałam system analizy moich wydatków na terapie używając Streams API.

java

public class TherapyAnalyzer { private List<TherapySession> sessions;

public TherapyAnalyzer(List<TherapySession> sessions) {
    this.sessions = sessions;
}

// 1. Całkowity koszt wszystkich terapii
public double getTotalCost() {
    return sessions.stream()
        .mapToDouble(TherapySession::getCost)
        .sum();
}

// 2. Średni koszt terapii
public double getAverageCost() {
    return sessions.stream()
        .mapToDouble(TherapySession::getCost)
        .average()
        .orElse(0.0);
}

// 3. Najdroższa terapia
public Optional<TherapySession> getMostExpensive() {
    return sessions.stream()
        .max(Comparator.comparing(TherapySession::getCost));
}

// 4. Grupowanie po typie terapii
public Map<String, List<TherapySession>> groupByType() {
    return sessions.stream()
        .collect(Collectors.groupingBy(TherapySession::getType));
}

// 5. Suma kosztów per typ terapii
public Map<String, Double> getCostByType() {
    return sessions.stream()
        .collect(Collectors.groupingBy(
            TherapySession::getType,
            Collectors.summingDouble(TherapySession::getCost)
        ));
}

// 6. Liczba sesji per typ
public Map<String, Long> getCountByType() {
    return sessions.stream()
        .collect(Collectors.groupingBy(
            TherapySession::getType,
            Collectors.counting()
        ));
}

// 7. Terapie w danym miesiącu
public List<TherapySession> getSessionsInMonth(int year, int month) {
    return sessions.stream()
        .filter(s -> s.getDate().getYear() == year)
        .filter(s -> s.getDate().getMonthValue() == month)
        .sorted(Comparator.comparing(TherapySession::getDate))
        .collect(Collectors.toList());
}

// 8. Top 5 najdroższych sesji
public List<TherapySession> getTop5MostExpensive() {
    return sessions.stream()
        .sorted(Comparator.comparing(TherapySession::getCost).reversed())
        .limit(5)
        .collect(Collectors.toList());
}

// 9. Czy są nieopłacone terapie?
public boolean hasUnpaidSessions() {
    return sessions.stream()
        .anyMatch(s -> !s.isPaid());
}

// 10. Wszystkie opłacone?
public boolean allPaid() {
    return sessions.stream()
        .allMatch(TherapySession::isPaid);
}

}

Użycie:

java

// Przykładowe dane 
   List<TherapySession> sessions = List.of( 
        new TherapySession("SI", LocalDate.of(2026, 4, 1), 75.0, true), 
        new TherapySession("Logopeda", LocalDate.of(2026, 4, 3), 65.0, true), 
        new TherapySession("SI", LocalDate.of(2026, 4, 8), 75.0, false), 
        new TherapySession("Pedagog", LocalDate.of(2026, 4, 10), 60.0, true), 
        new TherapySession("Logopeda", LocalDate.of(2026, 4, 15), 65.0, false) 
   );

TherapyAnalyzer analyzer = new TherapyAnalyzer(sessions);

// Analiza 
   System.out.println("Total: " + analyzer.getTotalCost() + " zł"); 
// Output: Total: 340.0 zł

   System.out.println("Average: " + analyzer.getAverageCost() + " zł"); 
// Output: Average: 68.0 zł

   Map<String, Double> costByType = analyzer.getCostByType(); 
   System.out.println("SI: " + costByType.get("SI") + " zł"); 
// Output: SI: 150.0 zł

   System.out.println("Has unpaid: " + analyzer.hasUnpaidSessions()); 
// Output: Has unpaid: true`

Realny użytek: Teraz mogę w sekundę wygenerować raport miesięczny dla księgowej!

Optional – koniec z NullPointerException?

Problem z null:

java

public Therapy getMostExpensiveTherapy(List<Therapy> therapies) { 
       Therapy result = null; for (Therapy t : therapies) {
               if (result == null || t.getCost() > result.getCost()) { 
               result = t; 
               } 
       } return result; 
// Co jeśli lista pusta? → null 
}

// Użycie: 
Therapy expensive = getMostExpensiveTherapy(therapies); System.out.println(expensive.getName());   // BOOM! NullPointerException jeśli lista pusta`

Rozwiązanie – Optional:

java

public Optional<Therapy> getMostExpensiveTherapy(List<Therapy> therapies) {
       return therapies.stream() 
       .max(Comparator.comparing(Therapy::getCost)); 
}

// Użycie - wersja 1 (sprawdź czy jest) 
Optional<Therapy> expensive = getMostExpensiveTherapy(therapies); 
if (expensive.isPresent()) { 
    System.out.println(expensive.get().getName());
} else { 
    System.out.println("No therapies"); 
}

// Użycie - wersja 2 
(functional style) getMostExpensiveTherapy(therapies) 
     .ifPresent(t -> System.out.println(t.getName()));

// Użycie - wersja 3 (default value) 
String name = getMostExpensiveTherapy(therapies) 
       .map(Therapy::getName) 
       .orElse("No therapies");

Optional mówi wyraźnie: „Ta metoda może NIE zwrócić wartości”

Kiedy używać Optional:

TAK:

• Zwracane wartości metod które mogą być puste
• Rezultat wyszukiwania
• stream().findFirst(), .max(), .min()

NIE:

• Pola w klasach (ciężkie, memory overhead)
• Parametry metod (null-check prostszy)
• Collections (używaj pustej listy zamiast Optional<List>)

Method references – skróty lambd

Czasem lambda to tylko przekazanie do innej metody:

java

// Lambda 
list.forEach(item -> System.out.println(item));

// Method reference 
list.forEach(System.out::println);`

Typy method references:

1. Static method

java

// Lambda 
list.stream().map(s -> Integer.parseInt(s))
// Method reference 
list.stream().map(Integer::parseInt)

2. Instance method

java

// Lambda 
therapies.stream().map(t -> t.getName()) 
// Method reference 
therapies.stream().map(Therapy::getName)

3. Constructor

java

// Lambda 
list.stream().map(name -> new Therapy(name))
// Method reference 
list.stream().map(Therapy::new)

Typowe błędy które popełniłam

1. Modyfikowanie źródła w stream

Błąd:

java

List<Therapy> therapies = new ArrayList<>(originalList); therapies.stream() 
      .forEach(t -> therapies.add(new Therapy("Copy"))); // ConcurrentModificationException!

Lekcja: Streams NIE mogą modyfikować kolekcji źródłowej.

2. Używanie side effects w lambda

Błąd:

java

int[] counter = {0}; // zmienna zewnętrzna zmienna  therapies.stream()       .forEach(t -> counter[0]++); // ŹLE! Efekt uboczny

Lepiej:

java

long count = therapies.stream().count(); // Sposób funkcjonalny

3. Zapomnienie .collect()

Błąd:

java

therapies.stream()      .filter(t -> t.getCost() > 70) 
     .map(Therapy::getName); // To NIE zwraca List! To Stream!

Poprawka:

java

List<String> names = therapies.stream()      .filter(t -> t.getCost() > 70) 
     .map(Therapy::getName) .collect(Collectors.toList()); // Teraz tak!

4. Używanie Optional.get() bez sprawdzenia

Błąd:

java

Optional<Therapy> therapy = findTherapy();System.out.println(therapy.get().getName()); // NoSuchElementException jeśli empty!

Lepiej:

java

therapy.ifPresent(t -> System.out.println(t.getName())); 
// Lub 
String name = therapy.map(Therapy::getName).orElse("Unknown");

Kiedy używać programowania funkcyjnego, a kiedy imperatywnego?

Użyj functional (streams, lambda):

Transformacja danych:

java

List<String> names = therapies.stream()     .map(Therapy::getName) 
    .collect(Collectors.toList());

Filtrowanie:

java

List<Therapy> expensive = therapies.stream()     .filter(t -> t.getCost() > 70) 
    .collect(Collectors.toList());

Agregacja:

java

double total = therapies.stream()     .mapToDouble(Therapy::getCost) 
    .sum();

Użyj imperative (pętla for):

Wczesne wyjście (early exit):

java

for (Therapy t : therapies) {      if (t.getName().equals("SI")) { 
         return t; // Znalazłem, wychodzę 
     }
}

(Stream też może: .filter().findFirst() ale pętla czytelniejsza)

Modyfikacja elementów in-place:

java

for (Therapy t : therapies) {     t.markAsPaid(); // Zmieniam obiekt 
 }

Proste iteracje:

java

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

(Stream: IntStream.range(0, 10).forEach(System.out::println) – przesada)

Wydajność – czy streams są szybkie?

Benchmark test (100,000 elementów):

Pętla FOR:

java

// Czas: ~15ms 
List<Integer> result = new ArrayList<>(); for (Integer num : numbers) {        if (num % 2 == 0) { 
           result.add(num * 2); 
        }
  }

Stream:

java

// Czas: ~25ms 
List<Integer> result = numbers.stream()      .filter(n -> n % 2 == 0) 
     .map(n -> n * 2) 
     .collect(Collectors.toList());

Parallel stream:

java

// Czas: ~10ms (na multi-core!) 
List<Integer> result = numbers.parallelStream()       .filter(n -> n % 2 == 0) 
      .map(n -> n * 2) 
      .collect(Collectors.toList());

Wnioski:

• For pętla najszybsza dla prostych operacji
• Stream ~30-50% wolniejszy (ogólnie)
• Parallel stream może być najszybszy (jeśli CPU ma wiele rdzeni)

Ale: Różnica 10ms vs 25ms? W 99% aplikacji nieistotna. Czytelność > Performance (chyba że przetwarzasz miliony rekordów).

Co dalej – moja droga nauki

Po 17 tygodniach z Java (podstawy Zajavka + zaawansowane tematy):

Decydowałam się: JavaScript!

Dlaczego nie Spring/zaawansowana Java:

• Za ciężkie przy dzieciach i freelancingu
• Potrzebuję czegoś bardziej natychmiast przydatnego

Dlaczego JavaScript:

• Synergia z WordPress (mogę od razu stosować!)
• Frontend umiejętności są rynkowe
• Łatwiejszy balans życie/nauka

Ale Java była nieoceniona:

• Nauczyła mnie OOP solidnie
• Pokazała, że mogę uczyć się programowania
• Dała fundamenty które pomogą w JS

Next: Learning Log #5 będzie o… JavaScript! Od Javy do JS – co jest podobne, co inne, pierwsze wrażenia.

Podsumowanie – tydzień 13-14

Nauczyłam się: Lambdy, Streams API, Optional, method references
Napisałam: TherapyAnalyzer – realny użytek streams
Zrozumiałam: Kiedy programowanie funkcyjne, kiedy imperative
Odkryłam: Parallel streams (game changer dla dużych zbiorów!)
Czas nauki: 12h w ciągu 2 tygodni (poprawiła się regularność!)

Programowanie funkcyjne w Java początkowo: Hieroglify
Programowanie funkcyjne w Java teraz: Potężne narzędzie które skraca kod 3x

Czy było warto? Absolutnie. Stream API to must-know dla każdego Java developera.

PS: Też uczysz się Java? Streams wydają Ci się trudne czy intuicyjne? A może przechodzisz z Javy na inny język? Zostaw komentarz – ciekawa jestem Waszych doświadczeń!

Artykuł Learning Log #4: Strumienie, lambdy i funkcyjne programowanie w Java pochodzi z serwisu To co najważniejsze.

Siedemnasty tydzień od startu z kursem Zajavka. Oficjalnie tydzień 12 – ostatni tydzień podstawowej części kursu.

Kawa się parowała. Słuchawki na uszach. Dziecko spokojne. I ja, patrząc na ekran z napisem „Gratulacje! Udało Ci się ukończyć kurs podstawowy!” czułam… ulgę. I dumę. I lekki strach „co dalej?”.

Interfejsy w Java brzmiały dla mnie przez długi czas jak jakaś magiczna zaawansowana rzecz. Dziś wiem, że to jeden z najpotężniejszych narzędzi w OOP. I pokażę Wam dlaczego.

Gdzie jestem w kursie Java?

Oficjalnie: Tydzień 12/12 kursu „Java w 12 tygodni Zajavka” – koniec podstaw ✓

Realnie: 17 tygodni od startu (czyli ~4 miesiące kalendarzowe)

Co dalej: Zajavka ma część zaawansowaną – Spring, bazy danych, REST API. Decyduję czy kontynuować czy przejść na JavaScript.

Czas nauki w tym tygodniu: 10 godzin (wracam do formy!)

Czym są interfejsy w Java? (w końcu rozumiem!)

Analogia która mi pomogła – umowa o pracę:

Wyobraź sobie że zatrudniasz pracownika. Nie obchodzi Cię:

• Jak dokładnie wykonuje pracę
• Jakie narzędzia używa
• Jaki ma proces myślowy

Obchodzi Cię tylko: czy potrafi zrobić to co potrzebujesz.

Interfejs w Java to właśnie taka „umowa” – deklaracja „potrafię to i to” bez szczegółów „jak”.

Przykład z życia – Payment:

java

`// INTERFEJS = umowa public interface Payment { boolean processPayment(double amount); String getPaymentStatus(); }

// IMPLEMENTACJA 1 - Karta kredytowa public class CreditCardPayment implements Payment { private String cardNumber;

public CreditCardPayment(String cardNumber) {
    this.cardNumber = cardNumber;
}

@Override
public boolean processPayment(double amount) {
    System.out.println("Processing " + amount + " PLN via credit card");
    // Tutaj logika połączenia z operatorem kart
    return true;
}

@Override
public String getPaymentStatus() {
    return "Credit card payment successful";
}

}

// IMPLEMENTACJA 2 - BLIK public class BlikPayment implements Payment { private String phoneNumber;

public BlikPayment(String phoneNumber) {
    this.phoneNumber = phoneNumber;
}

@Override
public boolean processPayment(double amount) {
    System.out.println("Processing " + amount + " PLN via BLIK");
    // Tutaj logika BLIK
    return true;
}

@Override
public String getPaymentStatus() {
    return "BLIK payment successful";
}

}

// UŻYCIE - najważniejsze! public class PaymentProcessor {

public void executePayment(Payment payment, double amount) {
    // Nie wiem CZY to karta, BLIK czy coś innego
    // Wiem tylko że payment POTRAFI processPayment()
    if (payment.processPayment(amount)) {
        System.out.println(payment.getPaymentStatus());
    }
}


}

// W praktyce: PaymentProcessor processor = new PaymentProcessor();

Payment creditCard = new CreditCardPayment("1234-5678"); Payment blik = new BlikPayment("123456789");

processor.executePayment(creditCard, 100.50); processor.executePayment(blik, 200.00);`

Co mnie zaskoczyło?

PaymentProcessor nie wie, czy dostaje kartę czy BLIK. Wie tylko że dostaje coś co implementuje Payment. I to wystarczy!

To jest cała magia interfejsów – loose coupling, flexibility, extensibility.

Dlaczego interfejsy są lepsze niż klasy abstrakcyjne?

To było moje największe „aha!” tego tygodnia.

Klasa abstrakcyjna:

java

`public abstract class Animal { protected String name;

public Animal(String name) {
    this.name = name;
}

public abstract void makeSound();

public void sleep() {  // Konkretna implementacja
    System.out.println(name + " is sleeping");
}


}

public class Dog extends Animal { public Dog(String name) { super(name); }

@Override
public void makeSound() {
    System.out.println("Woof!");
}


}`

Problem: Dog może dziedziczyć tylko z JEDNEJ klasy. Co jeśli Dog ma być też Trainable? Nie można.

Interfejsy – wiele implementacji!

java

`public interface Animal { void makeSound(); }

public interface Trainable { void train(String command); boolean isTraned(); }

public interface Playful { void play(); }

// Jedna klasa, WIELE interfejsów! public class Dog implements Animal, Trainable, Playful { private String name; private boolean trained = false;

@Override
public void makeSound() {
    System.out.println("Woof!");
}

@Override
public void train(String command) {
    System.out.println("Training: " + command);
    trained = true;
}

@Override
public boolean isTrained() {
    return trained;
}

@Override
public void play() {
    System.out.println("Playing fetch!");
}

}`

Java nie ma multiple inheritance (dziedziczenia wielokrotnego) ale ma multiple implementation (implementacji wielokrotnych)!

To rozwiązuje problem „co jeśli potrzebuję cech z wielu źródeł”.

Kiedy używać czego? (moja ściąga)

Praktyczna zasada: Domyślnie używaj interfejsów. Klasy abstrakcyjne tylko, gdy naprawdę potrzebujesz współdzielić implementację.

Mój projekt – Therapy Management System

Postanowiłam stworzyć coś użytecznego – system zarządzania terapiami mojego dziecka.

Design z interfejsami:

java

`// INTERFEJSY - umowy public interface Schedulable { LocalDateTime getDateTime(); int getDuration(); boolean reschedule(LocalDateTime newTime); }

public interface Billable { double getCost(); boolean isPaid(); void markAsPaid(); }

public interface Reportable { String generateReport(); Map<String, Object> getStatistics(); }

// IMPLEMENTACJA - terapia ma wszystkie 3 cechy public class TherapySession implements Schedulable, Billable, Reportable { private String therapyType; // "SI", "Logopeda", "Pedagog" private LocalDateTime dateTime; private int durationMinutes; private double cost; private boolean paid; private String notes;

public TherapySession(String type, LocalDateTime dateTime, 
                     int duration, double cost) {
    this.therapyType = type;
    this.dateTime = dateTime;
    this.durationMinutes = duration;
    this.cost = cost;
    this.paid = false;
}

// Schedulable methods
@Override
public LocalDateTime getDateTime() {
    return dateTime;
}

@Override
public int getDuration() {
    return durationMinutes;
}

@Override
public boolean reschedule(LocalDateTime newTime) {
    this.dateTime = newTime;
    System.out.println("Rescheduled to: " + newTime);
    return true;
}

// Billable methods
@Override
public double getCost() {
    return cost;
}

@Override
public boolean isPaid() {
    return paid;
}

@Override
public void markAsPaid() {
    this.paid = true;
    System.out.println("Marked as paid: " + cost + " PLN");
}

// Reportable methods
@Override
public String generateReport() {
    return String.format("Therapy: %s | Date: %s | Duration: %d min | Cost: %.2f PLN | Paid: %s",
        therapyType, dateTime, durationMinutes, cost, paid ? "Yes" : "No");
}

@Override
public Map<String, Object> getStatistics() {
    Map<String, Object> stats = new HashMap<>();
    stats.put("type", therapyType);
    stats.put("duration", durationMinutes);
    stats.put("cost", cost);
    stats.put("paid", paid);
    return stats;
}

}

// MANAGEMENT CLASSES - pracują z interfejsami! public class BillingManager {

public double calculateTotalUnpaid(List<Billable> items) {
    return items.stream()
        .filter(item -> !item.isPaid())
        .mapToDouble(Billable::getCost)
        .sum();
}

public void processPayments(List<Billable> items) {
    items.stream()
        .filter(item -> !item.isPaid())
        .forEach(item -> {
            item.markAsPaid();
        });
}

}

public class ScheduleManager {

public List<Schedulable> getUpcoming(List<Schedulable> items) {
    LocalDateTime now = LocalDateTime.now();
    return items.stream()
        .filter(item -> item.getDateTime().isAfter(now))
        .sorted(Comparator.comparing(Schedulable::getDateTime))
        .toList();
}

}

public class ReportGenerator {

public void generateMonthlyReport(List<Reportable> items) {
    System.out.println("=== MONTHLY REPORT ===");
    items.forEach(item -> {
        System.out.println(item.generateReport());
    });
}

}`

Użycie w praktyce:

java

`public class Main { public static void main(String[] args) { // Tworzę sesje terapii List<TherapySession> sessions = new ArrayList<>();

    sessions.add(new TherapySession("SI", 
        LocalDateTime.of(2026, 3, 20, 14, 0), 60, 75.00));
    sessions.add(new TherapySession("Logopeda", 
        LocalDateTime.of(2026, 3, 22, 10, 0), 45, 65.00));
    sessions.add(new TherapySession("Pedagog", 
        LocalDateTime.of(2026, 3, 25, 15, 0), 60, 60.00));
    
    // Billing - obsługuje Billable
    BillingManager billing = new BillingManager();
    double unpaid = billing.calculateTotalUnpaid(
        new ArrayList<>(sessions));  // TherapySession implements Billable!
    System.out.println("Total unpaid: " + unpaid + " PLN");
    
    // Schedule - obsługuje Schedulable
    ScheduleManager schedule = new ScheduleManager();
    List<Schedulable> upcoming = schedule.getUpcoming(
        new ArrayList<>(sessions));  // TherapySession implements Schedulable!
    System.out.println("Upcoming sessions: " + upcoming.size());
    
    // Reports - obsługuje Reportable
    ReportGenerator reports = new ReportGenerator();
    reports.generateMonthlyReport(
        new ArrayList<>(sessions));  // TherapySession implements Reportable!
}

}


**Output:**

Total unpaid: 200.00 PLN Upcoming sessions: 3 === MONTHLY REPORT === Therapy: SI | Date: 2026-03-20T14:00 | Duration: 60 min | Cost: 75.00 PLN | Paid: No Therapy: Logopeda | Date: 2026-03-22T10:00 | Duration: 45 min | Cost: 65.00 PLN | Paid: No Therapy: Pedagog | Date: 2026-03-25T15:00 | Duration: 60 min | Cost: 60.00 PLN | Paid: No`

Dlaczego to jest piękne?

BillingManager nie wie, że pracuje z TherapySession. Wie tylko, że dostaje Billable.

Jutro mogę dodać DoctorVisit implements Billable i BillingManager będzie działać BEZ ZMIAN!

To jest siła interfejsów – rozszerzalność bez modyfikacji istniejącego kodu.

Default methods w interfejsach (Java 8+)

To mnie totalnie zaskoczyło – interfejsy mogą mieć implementację!

java

`public interface Reportable { String generateReport();

// DEFAULT METHOD - konkretna implementacja!
default void printReport() {
    System.out.println("=== REPORT ===");
    System.out.println(generateReport());
    System.out.println("==============");
}

default String getShortSummary() {
    String full = generateReport();
    return full.substring(0, Math.min(50, full.length())) + "...";
}

}`

Teraz każda klasa implementująca Reportable automatycznie dostaje printReport() i getShortSummary()!

Kiedy używać:

• Gdy większość implementacji będzie miała tą samą logikę
• Gdy chcesz dodać metodę do interfejsu bez łamania istniejącego kodu

Typowe błędy które popełniłam

1. Zbyt duże interfejsy (zanieczyszczenie interfejsów)

Błąd:

java

public interface TherapyManagement { void schedule(); void reschedule(); void cancel(); double getCost(); void markAsPaid(); String generateReport(); void sendReminder(); void exportToCalendar(); // ... 20 metod później }

Lekcja: To narusza ISP (Interface Segregation Principle – Zasada Segregacji Interfejsów ). Lepiej wiele małych interfejsów niż jeden wielki.

Poprawka: Rozdziel na Schedulable, Billable, Reportable, Notifiable.

2. Interfejs z jedną metodą bez sensu

Błąd:

java

public interface CanExist { boolean exists(); }

Lekcja: Nie każda metoda potrzebuje interfejsu. Czasem po prostu metoda w klasie wystarczy.

3. Mieszanie abstrakcji

Błąd:

java

public interface Payment { boolean processPayment(double amount); void setCardNumber(String card); // Co jeśli to BLIK? Nie ma karty! }

Lekcja: Interfejs powinien opisywać zachowanie wspólne dla WSZYSTKICH implementacji.

Functional Interfaces – bonus

Odkryłam że interfejs z JEDNĄ metodą abstrakcyjną to „functional interface” i może być użyty z lambda!

java

`@FunctionalInterface public interface TherapyCostCalculator { double calculate(int sessions, double pricePerSession); }

// Użycie z lambdą: TherapyCostCalculator standard = (sessions, price) -> sessions * price; TherapyCostCalculator withDiscount = (sessions, price) -> sessions * price * 0.9; // 10% discount

System.out.println("Standard: " + standard.calculate(8, 75)); // 600.0 System.out.println("Discount: " + withDiscount.calculate(8, 75)); // 540.0`

To otwiera drogę do programowania funkcyjnego w Java!

Koniec podstaw Zajavka – co dalej?

Tydzień 12 = koniec fundamentów. Przeszłam przez:

• Podstawy składni Java
• OOP (klasy, obiekty, dziedziczenie)
• Agregacja i kompozycja
• Interfejsy i klasy abstrakcyjne ✓

Co dalej – moje opcje:

Opcja 1: Zajavka – poziom zaawansowany

• Spring Framework
• Hibernate / JPA
• REST APIs
• Microservices

Plusy: Kontynuacja, naturalny postęp, solidna backend-dev ścieżka Minusy: Jeszcze więcej Java, może za ciężkie przy dzieciach

Opcja 2: JavaScript

• Naturalny krok dla freelancerki WordPress
• Synergia z moją pracą
• Frontend interaktywność

Plusy: Praktyczne dla mojej kariery, lżejsze od Springa, już mam podstawy JS Minusy: Restart w kolejnym języku, powtarzanie podstaw

Opcja 3: Konsolidacja + Budowa

• Zatrzymać się na podstawach Java
• Zbudować 2-3 solidne projekty
• Pokazać portfolio

Plusy: Solidne fundamenty, działający kod Minusy: Może za mało dla ryneku pracy

Moja decyzja: Myślę, że… JavaScript. Powody:

1. Synergia z WordPress (mogę od razu używać w pracy!)
2. Łatwiejszy balans z dziećmi (dużo mniej ciężki niż Spring)
3. Frontend umiejętności są wartościowe
4. Zawsze mogę wrócić do Java później

Podsumowanie nauki Java – 17 tygodni

Co osiągnęłam:
Podstawy składni Java – solidnie
OOP – rozumiem i używam
Agregacja/kompozycja – odhaczone
Interfejsy – w końcu rozumiem!
2 projekty robocze (Family system, Therapy Management)

Statystyki:

• 17 tygodni (zamiast 12)
• ~120 godzin nauki całościowo
• ~7h tygodniowo średnio
• 2 pełne projekty
• Setki linii kodu

Czy było warto? TAK. Java nauczyła mnie:

• Myślenia obiektowo
• Projektowania systemów
• Że mogę uczyć się programowania przy dzieciach
• Że 1h dziennie wystarczy

Następny krok: Learning Log #4 będzie o… JavaScript albo o PHP (?!) ! Czekać na dalsze informacje.

PS: Też kończycie kurs/etap nauki? Co dalej planujesz? Zostaw komentarz – ciekawa jestem Waszych ścieżek. A jeśli macie pytania o interfejsy w Java – pytajcie, teraz gdy w końcu rozumiem chętnie pomogę!

Artykuł Learning Log #3: Tydzień 12 Zajavka – interfejsy, klasy abstrakcyjne i koniec podstaw Java pochodzi z serwisu To co najważniejsze.

Kubek kawy numer trzy dzisiaj. Słuchawki na uszach. Dzieci w końcu się uspokoiły i bawią się same. Mam może godzinę.

Tydzień 10 i 11 kursu Zajavka był… intensywny. Dwa tygodnie zajęło mi przebrnięcie przez materiał, który teoretycznie powinien zająć jeden. Ale wiesz co? I tak jestem z siebie dumna.

Dziś o tym jak klasy współpracują ze sobą w Java – o agregacji, kompozycji i relacjach które sprawiają że kod przestaje być zbiorem przypadkowych kawałków, a zaczyna być… systemem.

Gdzie jestem w kursie Java?

Oficjalnie: Tydzień 10-11 z kursu „Java w 12 tygodni Zajavka”

Realnie: Gdzieś na 13-14 tygodniu od startu (pamiętajcie – życie z dziećmi ma swoje tempo)

Postęp: ~65% kursu. Podstawy mam solidne, teraz wchodzę w zaawansowane OOP.

Czas nauki: ~8 godzin w ostatnich dwóch tygodniach (mniej niż zwykle – dzieci były częściej wymagające)

Co to jest agregacja i kompozycja?

Przez pierwszy dzień myślałam, że to jakaś magiczna zaawansowana rzecz. Potem zrozumiałam: to po prostu jak klasy trzymają inne klasy w sobie.

Najprostsza analogia – mój dom:

Agregacja = Mebli w domu

• Dom MA meble
• Meble mogą istnieć bez domu (można je przenieść)
• Dom przestaje istnieć → meble dalej są

Kompozycja = Pokoje w domu

• Dom SKŁADA SIĘ Z pokoi
• Pokoje nie mogą istnieć bez domu
• Dom przestaje istnieć → pokoje też przestają

W kodzie Java:

// AGREGACJA - słabszy związek
public class House {
    private List<Furniture> furniture;  // meble mogą być w innym domu

    public House(List<Furniture> furniture) {
        this.furniture = furniture;  // dostajemy meble z zewnątrz
    }
}

// KOMPOZYCJA - silny związek
public class House {
    private List<Room> rooms;  // pokoje należą TYLKO do tego domu

    public House() {
        this.rooms = new ArrayList<>();
        rooms.add(new Room("Bedroom"));  // tworzymy pokoje WEWNĄTRZ
        rooms.add(new Room("Kitchen"));
    }
}

Mój pierwszy projekt z agregacją – Family

Postanowiłam zrobić coś bliskiego sercu – system zarządzania rodziną (bo przecież mam doświadczenie ).

public class Person {
    private String name;
    private int age;
    private String role;  // "parent", "child"

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

    public String getName() {
        return name;
    }

    public String getRole() {
        return role;
    }

    @Override
    public String toString() {
        return name + " (" + age + " years, " + role + ")";
    }
}

public class Family {
    private String familyName;
    private List<Person> members;  // AGREGACJA - osoby mogą istnieć poza rodziną

    public Family(String familyName) {
        this.familyName = familyName;
        this.members = new ArrayList<>();
    }

    public void addMember(Person person) {
        members.add(person);
        System.out.println(person.getName() + " joined " + familyName + " family");
    }

    public void removeMember(Person person) {
        members.remove(person);
        System.out.println(person.getName() + " left the family");
    }

    public void showFamily() {
        System.out.println(familyName + " Family:");
        for (Person member : members) {
            System.out.println("  - " + member);
        }
    }

    public List<Person> getParents() {
        return members.stream()
                .filter(p -> p.getRole().equals("parent"))
                .toList();
    }
}

// Użycie:
public class Main {
    public static void main(String[] args) {
        Person mom = new Person("Anna", 32, "parent");
        Person dad = new Person("Marek", 34, "parent");
        Person child1 = new Person("Kasia", 5, "child");
        Person child2 = new Person("Tomek", 3, "child");

        Family smiths = new Family("Smith");
        smiths.addMember(mom);
        smiths.addMember(dad);
        smiths.addMember(child1);
        smiths.addMember(child2);

        smiths.showFamily();
        // Output:
        // Smith Family:
        //   - Anna (32 years, parent)
        //   - Marek (34 years, parent)
        //   - Kasia (5 years, child)
        //   - Tomek (3 years, child)
    }
}

Co mnie zaskoczyło?

To że osoby (Person) nie wiedzą o rodzinie (Family). Mogą istnieć osobno. Mogą być w kilku rodzinach jednocześnie (np. rozszerzona rodzina). To jest cała idea agregacji!

Kompozycja – silniejszy związek

Kompozycja to, gdy obiekt nie może istnieć bez swojego „rodzica”.

Mój przykład – Therapy Session

public class TherapySession {
    private String type;  // "SI", "logopeda", "pedagog"
    private LocalDateTime dateTime;
    private int durationMinutes;

    // Konstruktor pakietowy - tylko TherapySchedule może tworzyć sesje
    TherapySession(String type, LocalDateTime dateTime, int durationMinutes) {
        this.type = type;
        this.dateTime = dateTime;
        this.durationMinutes = durationMinutes;
    }

    @Override
    public String toString() {
        return type + " therapy on " + dateTime + " (" + durationMinutes + " min)";
    }
}

public class TherapySchedule {
    private String childName;
    private List<TherapySession> sessions;  // KOMPOZYCJA

    public TherapySchedule(String childName) {
        this.childName = childName;
        this.sessions = new ArrayList<>();  // tworzymy listę TUTAJ
    }

    public void addSession(String type, LocalDateTime dateTime, int duration) {
        // Tworzymy sesję WEWNĄTRZ harmonogramu
        TherapySession session = new TherapySession(type, dateTime, duration);
        sessions.add(session);
        System.out.println("Added: " + session);
    }

    public void showSchedule() {
        System.out.println("Therapy schedule for " + childName + ":");
        sessions.forEach(System.out::println);
    }

    public int getTotalHoursThisMonth() {
        return sessions.stream()
                .mapToInt(s -> s.durationMinutes)
                .sum() / 60;
    }
}

// Użycie:
TherapySchedule schedule = new TherapySchedule("Michaś");
schedule.addSession("SI", LocalDateTime.now().plusDays(1), 60);
schedule.addSession("Logopeda", LocalDateTime.now().plusDays(2), 45);
schedule.addSession("Pedagog", LocalDateTime.now().plusDays(3), 60);

schedule.showSchedule();
// Output:
// Therapy schedule for Michaś:
// SI therapy on 2026-02-19T14:30 (60 min)
// Logopeda therapy on 2026-02-20T10:00 (45 min)
// Pedagog therapy on 2026-02-21T15:00 (60 min)

Różnica kluczowa:

W agregacji Person jest tworzony NA ZEWNĄTRZ i przekazywany do Family.

W kompozycji TherapySession jest tworzony WEWNĄTRZ TherapySchedule.

Relacje między klasami – has-a vs is-a

To był dla mnie moment „aha!” tego tygodnia.

IS-A = dziedziczenie (inheritance)

public class Animal {
    String name;
}

public class Dog extends Animal {
    // Dog IS-A Animal
}

HAS-A = agregacja/kompozycja

public class Person {
    String name;
}

public class House {
    Person owner;  // House HAS-A Person
}

Kiedy używać czego?

IS-A gdy mówimy: „X jest typem Y”

• Pies jest zwierzęciem
• Samochód elektryczny jest samochodem
• Student jest osobą

HAS-A gdy mówimy: „X ma Y” lub „X składa się z Y”

• Osoba ma adres
• Samochód ma silnik
• Harmonogram ma sesje terapii

Typowe błędy, które popełniłam

1. Mylenie agregacji z kompozycją

Błąd:

public class Family {
    private List<Person> members = new ArrayList<>();

    public void addMember(String name, int age) {
        members.add(new Person(name, age));  // To jest kompozycja!
    }
}

Poprawka:

public class Family {
    private List<Person> members = new ArrayList<>();

    public void addMember(Person person) {  // Agregacja - dostajemy obiekt z zewnątrz
        members.add(person);
    }
}

2. Publiczny konstruktor w kompozycji

Błąd:

public class TherapySession {
    public TherapySession(...) { }  // Każdy może tworzyć sesje!
}

Poprawka:

public class TherapySession {
    TherapySession(...) { }  // Package-private - tylko TherapySchedule może tworzyć
}

3. Zapomnienie o null safety

Błąd:

public void showFamily() {
    for (Person member : members) {  // Co jeśli members jest null?
        System.out.println(member);
    }
}

Poprawka:

public void showFamily() {
    if (members == null || members.isEmpty()) {
        System.out.println("No family members");
        return;
    }
    members.forEach(System.out::println);
}

Praktyczne zastosowanie – mój mini projekt

Zbudowałam system do śledzenia kosztów terapii (bardzo przydatne w moim życiu!).

Klasy:

• Therapy – pojedyncza terapia (typ, koszt jednostkowy)
• TherapySession – konkretna sesja (data, czas trwania)
• Child – dziecko (ma listę terapii – agregacja)
• MonthlyReport – raport miesięczny (tworzy sesje wewnątrz – kompozycja)

public class Therapy {
    private String type;
    private double costPerSession;

    public Therapy(String type, double costPerSession) {
        this.type = type;
        this.costPerSession = costPerSession;
    }

    public double getCostPerSession() {
        return costPerSession;
    }

    public String getType() {
        return type;
    }
}

public class Child {
    private String name;
    private List<Therapy> therapies;  // AGREGACJA

    public Child(String name) {
        this.name = name;
        this.therapies = new ArrayList<>();
    }

    public void enrollInTherapy(Therapy therapy) {
        therapies.add(therapy);
    }

    public double calculateMonthlyCost(int sessionsPerTherapy) {
        return therapies.stream()
                .mapToDouble(t -> t.getCostPerSession() * sessionsPerTherapy)
                .sum();
    }
}

Rezultat: Mam working code, który pokazuje mi że:

• 2x terapia SI po 75 zł = 600 zł/mies (8 sesji)
• 2x logopeda po 65 zł = 520 zł/mies (8 sesji)
• 1x pedagog po 60 zł = 240 zł/mies (4 sesje)
• Total: 1360 zł/mies

Bonus: Kod, który faktycznie rozwiązuje mój realny problem!

Nauka Java z życiem w tle

Jak wyglądały te dwa tygodnie:

Tydzień 10:

• Dzieci niewymagające wzmożonej uwagi = 6h nauki
• 4x po godzinie + 2h w weekend
• Zbudowałam Family system

Tydzień 11:

• Dziecko wymagające uwagi = 2h nauki
• Tylko wieczory gdy spało
• Dokończyłam Therapy cost tracker

Total: 8h na 2 tygodnie = mniej niż zwykle

Reakcja: Mogłam się stresować, że „za wolno”. Zamiast tego myślę: „8h to 8h więcej niż zero. Progress!”

Co pomaga, gdy czas jest ograniczony:

1. Małe cele – nie „skończę tydzień 10”, ale „zrozumiem agregację dziś”
2. Praktyczne projekty – Family, Therapy – rzeczy z mojego życia
3. Notatki głosowe – gdy dziecko się budzi, a ja mam pomysł
4. Akceptacja – niektóre dni = zero nauki. I to OK.

Plany na tydzień 12

Przede mną:

• Interfejsy – co to i dlaczego
• Abstrakcyjne klasy – kiedy używać
• Polimorfizm – ostatecznie zrozumieć

Kurs Java Zajavka powoli zbliża się do końca podstawowej części. Czuję że solidne fundamenty są już położone.

Dla kogo jest ten learning log?

To nie jest tutorial „jak programować w Java”. To jest real talk o nauce programowania jako mama.

Jeśli:

• Uczysz się przy dzieciach
• Masz 5-10h tygodniowo, nie 40h
• Czasem tydzień mija bez linii kodu
• Zastanawiasz się „czy to w ogóle ma sens”

To TAK, ma sens. 8h to 8h. Progress nie musi być liniowy.

Podsumowanie tygodnia 10-11

Nauczyłam się: Agregacja, kompozycja, relacje między klasami
Napisałam: Family system, Therapy cost tracker (working code!)
Zrozumiałam: HAS-A vs IS-A, kiedy używać agregacji a kiedy kompozycji
Walczę z: Null safety, poprawne projektowanie relacji
Czas nauki: 8h w ciągu 2 tygodni (mniej przez chorobę dziecka)

Następny Learning Log: Tydzień 12 – interfejsy i abstrakcyjne klasy. Zapisz się do newslettera, żeby nie przegapić!

PS: Też walczysz z nauką przy dzieciach? Też masz tygodnie gdzie zero czasu? Napisz w komentarzu – przypomnimy sobie nawzajem że nie jesteśmy sami. A jeśli masz pytania o agregację, kompozycję czy Zajavka – pytaj śmiało!

Artykuł Learning Log #2: Tydzień 10-11 Zajavka – agregacja, kompozycja i kiedy klasy się przyjaźnią pochodzi z serwisu To co najważniejsze.