• System informacyjny – ludzie, procedury, dane i narzędzia służące gromadzeniu, przetwarzaniu i udostępnianiu informacji.
• Poufność, integralność, dostępność – podstawowe cele ochrony informacji: dostęp dla uprawnionych, brak nieautoryzowanych zmian oraz dostępność wtedy, gdy jest potrzebna.
• Kopia zapasowa – oddzielna kopia danych umożliwiająca odtworzenie po awarii; strategia 3-2-1 oznacza 3 kopie, 2 różne nośniki i 1 kopię poza główną lokalizacją.
• Prywatność i dane osobowe – przetwarzaj tylko dane potrzebne do celu, ograniczaj dostęp i zabezpieczaj okres przechowywania.

• Norma – uzgodniony dokument opisujący zasady, wymagania lub dobre praktyki. Norma nie zawsze jest obowiązkowym przepisem prawa, ale może zostać wskazana w umowie lub regulacji.
• Licencja – określa zasady korzystania, modyfikowania i rozpowszechniania programu. Przykłady: licencje własnościowe, MIT, Apache-2.0, GPL.
• Prawo autorskie – kod, grafiki, teksty i inne utwory są chronione. Korzystaj z materiałów zgodnie z licencją i podawaj wymagane informacje o autorze.
• Ocena zgodności – sprawdzenie, czy produkt, proces lub usługa spełnia określone wymagania, normy albo specyfikację.

Ergonomia to nauka o dostosowaniu warunków pracy do człowieka, żeby nie niszczyć zdrowia. Wyobraź sobie, że siedzisz 8 godzin dziennie – jeśli coś jest ustawione źle, po kilku latach masz problem z kręgosłupem, nadgarstkami albo wzrokiem. Te liczby są na egzaminie, naucz się ich na pamięć.

• Monitor – odległość dobierasz do wielkości ekranu, czytelności i wzroku użytkownika; w materiałach szkolnych często przyjmuje się około 40–75 cm. Górna krawędź ekranu powinna znajdować się na poziomie oczu lub nieco poniżej. Monitor najlepiej ustawić bokiem do okna, aby ograniczyć olśnienie i odbicia.
• Oświetlenie – dla typowej pracy biurowej często przyjmuje się 500 luksów jako wartość normową. Wymagane natężenie zależy jednak od rodzaju zadania i stanowiska. Źródło światła powinno ograniczać olśnienie i odbicia na ekranie.
• Krzesło – regulujesz je tak, żeby stopy leżały płasko na podłodze, uda były równoległe do ziemi, a kąt w kolanach wynosił ok. 90°. Krzesło musi mieć podparcie lędźwiowe (dla dolnej części pleców) i podłokietniki. Jeśli stopy nie sięgają podłogi – używasz podnóżka.
• Nadgarstki – przy pisaniu na klawiaturze nadgarstki powinny być w linii prostej z przedramieniem, nie zgięte w górę ani w dół. Dlatego używa się podkładek pod nadgarstki i regulowanych biurek.
• Przerwy – co godzinę pracy przy monitorze masz prawo do co najmniej 5-minutowej przerwy (Rozporządzenie MPiPS w sprawie bezpieczeństwa i higieny pracy na stanowiskach wyposażonych w monitory ekranowe). Stosuj zasadę 20-20-20: co 20 minut, przez 20 sekund, patrz na obiekt odległy o 20 stóp (ok. 6 m). To rozluźnia mięśnie oka.
• Hałas – przy pracy wymagającej koncentracji należy ograniczać hałas. Wartość około 55 dB bywa stosowana jako punkt odniesienia dla części pomieszczeń biurowych, ale dopuszczalny poziom zależy od charakteru pracy i właściwych norm.
• Temperatura – minimum 18°C w pomieszczeniu przy lekkich pracach biurowych. Optymalna dla pracy umysłowej: 20–22°C.

Na egzaminie bardzo często pojawia się pytanie o to, do jakiej kategorii należy dane zagrożenie. Zapamiętaj cztery kategorie:

• Zespół cieśni kanału nadgarstka (angielska nazwa: Carpal Tunnel Syndrome) – najczęstsze schorzenie programistów. Objawia się bólem, drętwieniem i zaburzeniami czucia w 1., 2. i 3. palcu ręki (kciuk, wskazujący, środkowy). Pojawia się przez długotrwałe, powtarzalne ruchy przy klawiaturze i myszy. Profilaktyka: przerwy, ćwiczenia nadgarstków, ergonomiczna klawiatura, mysz pionowa.
• Asthenopia (zmęczenie wzroku) – ból oczu, łzawienie, pieczenie, bóle głowy, niewyraźne widzenie. Efekt długiego wpatrywania się w ekran. Leczenie: przerwy, reguła 20-20-20, ustawienie monitora (kontrast, jasność, odległość).
• Bóle kręgosłupa – efekt wymuszonej pozycji ciała. Szczególnie odcinek szyjny (od monitora na złej wysokości) i lędźwiowy (brak podparcia krzesła). Profilaktyka: regulowane krzesło, aktywne przerwy.
• RSI (Repetitive Strain Injury) – ogólna nazwa urazów z przeciążenia wynikających z monotonicznych, powtarzalnych ruchów. Zespół cieśni to jeden z rodzajów RSI.
• Wypalenie zawodowe i stres – zaliczane do zagrożeń psychofizycznych. Nie jest to hałas ani promieniowanie – to osobna kategoria.

• Pracodawca musi: przeprowadzić szkolenie BHP przed dopuszczeniem do pracy, zapewnić badania lekarskie (i zapłacić za nie – koszty ponosi pracodawca!), utrzymać właściwą temperaturę, zapewnić środki ochrony osobistej, informować o zagrożeniach.
• Pracownik musi: przestrzegać przepisów BHP, używać przydzielonych środków ochrony, powiadamiać o zagrożeniach, uczestniczyć w szkoleniach BHP.
• PIP (Państwowa Inspekcja Pracy) – organ kontrolny, który nadzoruje przestrzeganie prawa pracy i BHP. Może przeprowadzać kontrole bez zapowiedzi.

• Szkolenie wstępne BHP – obowiązkowe przed dopuszczeniem do pracy. Składa się z dwóch części: instruktaż ogólny (przeprowadza dział BHP lub pracodawca) i instruktaż stanowiskowy (przeprowadza bezpośredni przełożony, dotyczy konkretnego stanowiska).
• Szkolenia okresowe – ich częstotliwość zależy od rodzaju stanowiska i obowiązujących przepisów. Dla pracowników administracyjno-biurowych szkolenie okresowe przeprowadza się nie rzadziej niż raz na 6 lat, przy czym w określonych prawem przypadkach mogą być z niego zwolnieni. Stanowiska szczególnie niebezpieczne wymagają szkoleń częściej.
• Badania lekarskie wstępne – przed zatrudnieniem lub przejściem na nowe stanowisko. Pracownik płaci? NIE – koszty zawsze ponosi pracodawca.
• Badania okresowe – wykonywane regularnie w trakcie trwania stosunku pracy. Częstotliwość zależy od stanowiska i oceny ryzyka.
• Badania kontrolne – po chorobie trwającej powyżej 30 dni. Zanim wrócisz do pracy, musisz się zbadać.
• Badania wykonuje lekarz medycyny pracy (nie lekarz rodzinny ani jakikolwiek inny specjalista – to ważne na egzaminie).

• Definicja wypadku przy pracy: nagłe zdarzenie, wywołane przyczyną zewnętrzną, pozostające w związku z pracą oraz powodujące uraz lub śmierć pracownika. Wszystkie cztery cechy muszą wystąpić razem.
• Wypadek w drodze do lub z pracy – też jest prawnie chroniony, ale to osobna kategoria (nie „przy pracy”).
• Co robić po wypadku: zabezpiecz miejsce wypadku (nikt nie powinien ruszać niczego), wezwij pomoc medyczną (112), powiadom bezpośredniego przełożonego.
• Zespół powypadkowy – bada okoliczności i przyczyny wypadku. Składa się z co najmniej 2 osób: pracownika służby BHP + zakładowego społecznego inspektora pracy (lub innego pracownika zaznajomionego z przepisami BHP).
• Koszty badania wypadku ponosi pracodawca (nie ZUS, nie PIP, nie pracownik – pracodawca!).

• Ochrona podstawowa (przed dotykiem bezpośrednim) – zabezpieczasz się przed dotknięciem przewodów pod napięciem. Sposoby: izolacja części czynnych (okrywasz przewód izolacją), osłony i obudowy, bariery ochronne.
• Ochrona dodatkowa (przed dotykiem pośrednim) – chroni gdy izolacja jest uszkodzona. Sposoby: samoczynne wyłączenie zasilania (bezpieczniki, wyłączniki różnicowoprądowe RCD), uziemienie ochronne.
• Wyłącznik różnicowoprądowy (RCD) – wykrywa upływ prądu i natychmiast wyłącza zasilanie. To jest ochrona dodatkowa.
• Co robić gdy sprzęt się zapalił: zaalarmuj otoczenie, wezwij pomoc i, jeżeli jest to bezpieczne, odłącz zasilanie. Do elektroniki preferowana jest gaśnica CO₂. Zawsze sprawdź oznaczenia gaśnicy i dopuszczalne napięcie; nie kieruj wody na urządzenie pozostające pod napięciem.

To jest bardzo popularne zagadnienie na egzaminie. Pamiętaj o kolejności działań – najczęstszy błąd to dotknięcie poszkodowanego zanim odłączysz go od prądu.

• Krok 1 – Zadbaj o własne bezpieczeństwo. Nie dotykaj poszkodowanego gołymi rękami jeśli wciąż jest pod napięciem – sam dostaniesz porażenie!
• Krok 2 – Odłącz zasilanie lub odsuń poszkodowanego od źródła prądu za pomocą bezpiecznego, suchego przedmiotu izolacyjnego. Możesz wyciągnąć wtyczkę z gniazdka lub wyłączyć zabezpieczenie w rozdzielnicy. Nie podejmuj działania, jeśli naraża Cię ono na porażenie.
• Krok 3 – Oceń stan poszkodowanego. Sprawdź przytomność: potrząśnij za ramię, głośno zawołaj „Czy mnie słyszysz?”.
• Krok 4 – Zadzwoń pod 112 (lub każ to zrobić komuś innemu, żebyś mógł pomagać poszkodowanemu).
• Krok 5 – Sprawdź oddech (max 10 sekund): patrz czy klatka piersiowa się unosi, słuchaj i czuj powietrze przy ustach.
• Jeśli poszkodowany oddycha ale jest nieprzytomny – ułóż go w pozycji bocznej ustalonej (na boku, tak żeby nie zakrztusił się wymiocinami).
• Jeśli poszkodowany nie oddycha – natychmiast rozpocznij RKO (resuscytację krążeniowo-oddechową).

• Schemat: 30 uciśnięć : 2 oddechy – to jest proporcja, którą musisz znać na pamięć.
• Uciśnięcia klatki piersiowej: dłonie splatasz na środku klatki piersiowej, ramiona wyprostowane, uciskasz na głębokość 5–6 cm, z częstotliwością 100–120 uciśnięć na minutę (to jest bardzo szybkie – mniej więcej w rytmie piosenki „Stayin’ Alive”).
• Oddechy ratownicze: 2 oddechy po 30 uciśnięciach. Odchylasz głowę poszkodowanego do tyłu, unosisz brodę, obejmujesz jego usta swoimi ustami i wdmuchwujesz powietrze przez ok. 1 sekundę. Obserwujesz czy klatka piersiowa się unosi.
• Kontynuujesz 30:2 aż do przejęcia działań przez służby, powrotu prawidłowego oddechu, wyczerpania sił lub pojawienia się zagrożenia. Jeżeli nie umiesz albo nie możesz wykonywać oddechów ratowniczych, prowadź ciągłe uciśnięcia i stosuj się do instrukcji dyspozytora 112.
• AED (defibrylator) – jeśli jest dostępny, użyj go natychmiast. Urządzenie samo mówi co robić. Nie bój się go – prąd oddaje tylko jeśli wykryje wskazania.

• Chłodzenie: po odłączeniu źródła prądu chłodź oparzone miejsce chłodną, bieżącą wodą przez około 20 minut. Nie używaj lodu ani lodowatej wody.
• NIE przekłuwaj pęcherzy – pęcherz stanowi naturalną ochronę uszkodzonej skóry. Przekłucie zwiększa ryzyko zakażenia.
• NIE smaruj maścią, kremem ani tłuszczem – to popularny błąd. Takie substancje utrudniają ocenę i leczenie oparzenia.
• Przykryj jałowym opatrunkiem lub czystą folią spożywczą (nie bandażem, który przylega do rany).
• Zadzwoń 112 – oparzenia elektryczne są zawsze poważne, nawet jeśli wyglądają na małe, bo prąd może uszkodzić narządy wewnętrzne.

Zanim napiszesz pierwszą linię kodu, musisz wiedzieć jakiego rodzaju aplikację tworzysz – bo każdy typ ma inne zasady gry: inne narzędzia, inne ograniczenia i inne oczekiwania użytkownika.

SDLC (Software Development Life Cycle) to cykl życia oprogramowania od pomysłu do wycofania. Niezależnie od metodyki (waterfall, agile, scrum) każdy projekt przechodzi przez te etapy – różni się kolejność i sposób iteracji.

• 1. Analiza wymagań – zbierasz czego klient potrzebuje. Efekt: dokumentacja wymagań funkcjonalnych (co system ma robić) i niefunkcjonalnych (jak szybko, jak bezpiecznie). Bez tego etapu budujesz nie to co trzeba.
• 2. Projektowanie – planujesz architekturę: jakie klasy, jakie bazy danych, jak wygląda UI. Efekty: diagramy UML, makiety interfejsu (mockupy/wireframe), schemat bazy danych (ERD).
• 3. Implementacja (kodowanie) – piszesz kod. Programiści pracują według specyfikacji z fazy projektowania. Używasz systemu kontroli wersji (Git).
• 4. Testowanie – sprawdzasz czy aplikacja działa zgodnie z wymaganiami. Unit testy, integracyjne, UAT (klient sprawdza). Błędy wracają do implementacji.
• 5. Wdrożenie (deployment) – aplikacja trafia do użytkowników: na serwer produkcyjny, do sklepów (Play Store, App Store), na stanowiska robocze. Konfiguracja środowiska produkcyjnego.
• 6. Utrzymanie i rozwój – poprawki błędów (bugfix), aktualizacje bezpieczeństwa, nowe funkcje. Najdłuższa faza – system może być utrzymywany latami.
• 7. Wycofanie – aplikacja jest zastępowana nową wersją lub innym systemem. Migracja danych, informowanie użytkowników.

Aplikacja desktopowa to osobny proces w systemie operacyjnym. Ma jasno zdefiniowany start, działanie i koniec. W C# (WinForms) wygląda to tak:

• Uruchomienie: system operacyjny uruchamia plik .exe → .NET ładuje środowisko uruchomieniowe → wywołana zostaje metoda static void Main().
• Inicjalizacja: Application.Run(new MainForm()) tworzy główne okno → wywołany jest konstruktor formularza (InitializeComponent) → odpala się zdarzenie Form.Load – tu ładujesz dane, inicjalizujesz listy, ustawiasz domyślne wartości.
• Pętla komunikatów (message loop): aplikacja czeka na zdarzenia od użytkownika (kliknięcia, naciśnięcia klawiszy, timery). Każde zdarzenie trafia do kolejki i jest obsługiwane po kolei. Aplikacja jest „żywa” dopóki ta pętla działa.
• Zamykanie: użytkownik klika X lub wywołujesz Application.Exit() → odpala się FormClosing (możesz anulować zamknięcie lub zapisać dane) → FormClosed → pętla komunikatów kończy działanie → proces się kończy.

Aplikacja webowa działa inaczej niż desktopowa – serwer nie „pamięta” użytkownika między żądaniami. HTTP jest bezstanowy.

• Uruchomienie serwera: serwer (np. IIS, Kestrel w ASP.NET Core) startuje, ładuje konfigurację i zaczyna nasłuchiwać na porcie (np. 443 dla HTTPS). Inicjalizuje dependency injection, połączenia z bazą, middleware.
• Obsługa żądania (request–response cycle): przeglądarka wysyła żądanie HTTP → serwer przetwarza je przez pipeline middleware (logowanie, uwierzytelnianie, routing) → kontroler lub endpoint buduje odpowiedź → serwer odsyła response. Żądanie jest zakończone, ale połączenie sieciowe może pozostać otwarte i obsłużyć kolejne żądania.
• Bezstanowość: serwer nie pamięta poprzednich żądań. Stan symulowany jest przez: cookies (po stronie klienta), sesje (ID w cookie, dane na serwerze), JWT (token w nagłówku), localStorage (po stronie przeglądarki).
• Zatrzymanie serwera: graceful shutdown – serwer kończy obsługę bieżących żądań, a dopiero potem się wyłącza.
• Frontend SPA (np. Angular/React): aplikacja ładuje się raz do przeglądarki → JavaScript zarządza widokami lokalnie → do serwera wysyła tylko żądania API (JSON), nie przeładowuje strony.

Android zarządza zasobami agresywnie – system operacyjny może zabić Twoją aplikację w tle, gdy brakuje pamięci. Dlatego musisz rozumieć cykl życia i zapisywać stan we właściwych momentach.

• onCreate() – Activity tworzona (lub tworzona ponownie po rotacji). Tworzysz UI, inicjalizujesz ViewModel, odczytujesz savedInstanceState.
• onStart() → onResume() – aplikacja staje się widoczna i aktywna. Tu wznawiasz animacje i kamery.
• onPause() – Activity traci fokus, ale może być nadal częściowo widoczna. Wstrzymaj krótkie operacje zależne od pierwszego planu, np. podgląd kamery. Nie wykonuj tutaj ciężkiego zapisu, operacji sieciowych ani transakcji bazodanowych.
• onStop() – aplikacja niewidoczna. Zwalniasz ciężkie zasoby.
• onDestroy() – Activity niszczona. Przy rotacji ekranu Android wywołuje onDestroy() i tworzy Activity od nowa – dlatego ViewModel przeżywa rotację, a zwykłe pole klasy nie!
• Wznowienie po zabiciu przez system: gdy pamięć jest potrzebna, Android może zabić aplikację w tle. Przy powrocie tworzy Activity od nowa – dlatego stan UI zapisujesz w onSaveInstanceState() (Bundle).

Big-O mówi jak szybko rośnie czas wykonania algorytmu w zależności od rozmiaru danych (n). Im wolniej rośnie, tym lepiej.

• Stos (Stack, LIFO) – Last In First Out. Ostatnio włożony = pierwszy wyjmowany. Wyobraź sobie stos talerzy – kładziesz na górę, bierzesz z góry. Zastosowanie: cofnij (Ctrl+Z), rekurencja (stos wywołań), sprawdzanie nawiasów.
• Kolejka (Queue, FIFO) – First In First Out. Jak kolejka w sklepie: pierwszy wchodzi, pierwszy wychodzi. Zastosowanie: obsługa żądań, wydruki w kolejce, bufory.
• Kolejka priorytetowa – element o najwyższym priorytecie wychodzi pierwszy, niezależnie od kolejności dodania. Zastosowanie: harmonogramowanie zadań, algorytm Dijkstry.
• Lista jednokierunkowa – każdy element wskazuje na następny. Wstawianie na początku O(1), ale dotarcie do k-tego elementu to O(n), bo musisz przejść od początku.
• Drzewo BST (Binary Search Tree) – lewy potomek jest mniejszy od rodzica, prawy większy. Wyszukiwanie O(log n) dla zbalansowanego drzewa, O(n) dla zwyrodniałego (jak lista).
• Tablica haszowana (Hash Map / Dictionary) – pary klucz–wartość. Dostęp po kluczu O(1) (średnio). To właśnie Dictionary<K,V> w C#.
• Graf – węzły (wierzchołki) połączone krawędziami. Może być skierowany (z kierunkiem) lub nieskierowany. Reprezentacja: macierz sąsiedztwa lub lista sąsiedztwa.

• Bubble sort (sortowanie bąbelkowe) – O(n²), najprostszy do zrozumienia. Porównuje sąsiednie elementy i zamienia miejscami. Pętla po pętli, największe „bąbelkuje” na koniec.
• Insertion sort (sortowanie przez wstawianie) – O(n²) najgorzej, O(n) gdy dane prawie posortowane. Bierzesz kolejny element i wstawiasz go na właściwe miejsce w już posortowanej części.
• Selection sort – O(n²). Szukasz najmniejszego elementu w nieposortowanej części i zamieniasz z pierwszym nieposortowanym.
• Merge sort – O(n log n) zawsze, stabilny. Strategia „dziel i zwyciężaj”: dzielisz tablicę na połowy rekurencyjnie, potem scalasz posortowane połówki.
• Quick sort – O(n log n) średnio, O(n²) najgorzej (gdy pivot źle wybrany). Szybki w praktyce, niestabilny. Wybiera pivot, dzieli tablicę na mniejsze i większe od pivota, rekurencja.
• Binary search (wyszukiwanie binarne) – wymaga posortowanych danych! Sprawdza środkowy element, jeśli szukany jest mniejszy – szuka w lewej połowie, jeśli większy – w prawej. O(log n).
• Algorytm Dijkstry – wyszukuje najkrótszą ścieżkę w grafie z wagami (nieujemnymi). Stosowany w nawigacji GPS, routingu sieciowym.

• Rekurencja – funkcja wywołuje samą siebie. MUSI mieć warunek stopu (base case), inaczej nieskończona pętla i przepełnienie stosu (StackOverflowException). Przykład: silnia → 0! = 1 (base case), n! = n × (n-1)! (rekurencja). Każde wywołanie rekurencyjne „czeka” na stos do momentu powrotu – to zużywa pamięć.
• Schemat blokowy – kształty: elipsa/owal = start/stop, prostokąt = operacja/instrukcja, romb = decyzja (if / warunek pętli), równoległobok = wejście/wyjście (I/O). To jest kluczowe – romb to decyzja!
• Pseudokod – zapis logiki algorytmu niezależny od języka programowania. Czytelny dla człowieka, nie można go uruchomić na komputerze. Używasz go na etapie projektowania.

OOP to sposób myślenia o programowaniu. Zamiast jednej długiej listy instrukcji, grupujesz dane i funkcje w obiekty, które ze sobą współpracują.

• Hermetyzacja (enkapsulacja) – ukrywasz dane wewnątrz klasy (pola private) i udostępniasz je przez publiczne metody lub właściwości. Dzięki temu nikt z zewnątrz nie może przypadkowo zniszczyć stanu obiektu. Wyobraź sobie pilot do TV: widzisz przyciski, nie widzisz elektroniki w środku.
• Dziedziczenie – klasa pochodna „dziedziczy” wszystkie pola i metody klasy bazowej i może je rozszerzać. W C#: class Pies : Zwierze. Słowo kluczowe base odwołuje się do klasy bazowej. W C# dziedziczysz tylko po jednej klasie (nie ma wielodziedziczenia klas).
• Polimorfizm – ten sam kontrakt może mieć różne implementacje zależnie od faktycznego typu obiektu. Przy nadpisywaniu metod klas używasz virtual i override; polimorfizm może też wynikać z implementowania interfejsów.
• Abstrakcja – ukrywasz szczegóły implementacji, eksponujesz tylko to co niezbędne dla użytkownika klasy. Realizowana przez klasy abstrakcyjne i interfejsy.

• Klasa abstrakcyjna – nie możesz jej zinstancjonować. Może mieć metody z implementacją i metody abstract. Pierwsza konkretna klasa pochodna musi zapewnić implementację odziedziczonych metod abstrakcyjnych.
• Interfejs – definiuje kontrakt funkcjonalności. Klasa może implementować wiele interfejsów. Od C# 8 interfejs może także zawierać domyślne implementacje wybranych elementów, ale nie przechowuje stanu instancji w polach.
• Klasa vs struct: klasa jest typem referencyjnym, a struct typem wartościowym. Wybór zależy od semantyki danych, kosztu kopiowania, mutowalności i sposobu użycia, a nie od prostej zasady „struct zawsze szybszy”.
• Enum – skończony zbiór nazwanych stałych całkowitych. Zamiast pisać if (status == 1) piszesz if (status == Status.Aktywny) – eliminuje „magiczne liczby”, kod jest czytelniejszy.
• Sealed class – nie można po niej dziedziczyć. Używasz gdy chcesz zabezpieczyć klasę przed rozszerzaniem.
• Konstruktor – specjalna metoda wywoływana przy tworzeniu obiektu (new). Ma taką samą nazwę jak klasa, nie ma zwracanego typu.

• Delegat – typ przechowujący referencję do metody (lub metod). Podstawa mechanizmu zdarzeń. Możesz przypisać metodę do delegata i potem ją wywołać.
• Lambda – (x) => x * 2. Anonimowa funkcja przekazywana jako delegat lub argument. Zamiast definiować osobną metodę, piszesz ją w miejscu użycia.
• Func i Action: Func<int, int> – delegat z wynikiem (ostatni param = typ zwracany). Action<int> – delegat bez wyniku (void).
• Generyki – List<T>, Dictionary<K,V>. Piszesz kod raz, działa bezpiecznie dla każdego typu. T to placeholder na typ.
• LINQ – lista.Where(x => x > 5).OrderBy(x => x).ToList(). Zapytania na kolekcjach, czytelne i bezpieczne typowo. Działa na tablicach, listach, wynikach z bazy (EF Core).
• async/await – asynchroniczne wykonanie bez blokowania wątku UI. Używasz do operacji I/O (baza danych, sieć, plik). Metoda async zwraca Task lub Task<T>.
• try/catch/finally – obsługa wyjątków. NullReferenceException = wywołanie metody na obiekcie null. finally wykonuje się zawsze, nawet po wyjątku.

• + = public, - = private, # = protected, ~ = package
• Pusty trójkąt (strzałka pusta) → dziedziczenie (wskazuje klasę bazową)
• Przerywana linia + strzałka → implementacja interfejsu
• Wypełniony romb → kompozycja (część nie istnieje bez całości, np. silnik–samochód)
• Pusty romb → agregacja (część może istnieć samodzielnie, np. student–uczelnia)
• Prosta linia → asocjacja (ogólny związek między klasami)

SOLID to 5 zasad dobrego projektowania klas i systemów. Zasady zostały opisane przez różnych autorów, Robert C. Martin je zebrał i spopularyzował, a akronim SOLID przypisuje się Michaelowi Feathersowi. Pomagają tworzyć kod łatwiejszy do zmiany i testowania.

• Singleton – zapewnia, że istnieje tylko jedna instancja klasy w całym programie. Przykład użycia: logger, pula połączeń z bazą danych, konfiguracja aplikacji.
• Factory Method – tworzysz obiekty bez wskazywania ich konkretnej klasy. Podklasy decydują co tworzyć. Przydatne gdy logika tworzenia jest skomplikowana.
• Observer – jeden obiekt (subject) zmienia stan, wszyscy obserwatorzy są automatycznie powiadamiani. W C# to mechanizm event. Przykład: kliknięcie przycisku → wiele reakcji.
• Decorator – dynamicznie dodajesz nowe funkcje do obiektu, owijając go innym obiektem, bez zmiany oryginalnej klasy.
• Strategy – rodzina algorytmów w osobnych klasach, wymiennych w czasie działania. Przykład: różne algorytmy sortowania jako wymienne strategie.
• Facade – uproszczony, przyjazny interfejs do złożonego podsystemu. Ukrywa skomplikowanie od użytkownika.
• Template Method – klasa bazowa definiuje szkielet algorytmu, a klasy pochodne nadpisują wybrane kroki bez zmiany całej kolejności działań.
• Composite – pozwala traktować pojedyncze obiekty i ich złożenia w jednolity sposób, np. plik oraz folder zawierający pliki.
• Repository – oddziela logikę dostępu do danych od logiki biznesowej. Klasy biznesowe nie wiedzą czy dane są w bazie SQL, w pliku czy w API.

• DRY (Don’t Repeat Yourself) – każda część logiki istnieje w jednym miejscu w kodzie. Kopiowanie kodu = gwarancja błędów gdy coś trzeba zmienić.
• KISS (Keep It Simple, Stupid) – najprostsze rozwiązanie jest często najlepsze. Nie komplikuj bez powodu.
• YAGNI (You Ain’t Gonna Need It) – nie implementuj funkcji dopóki jej nie potrzebujesz. Programiści często dodają „na wszelki wypadek” i marnują czas.
• Clean Code (Robert C. Martin) – sensowne nazwy zmiennych i metod, krótkie metody z jedną odpowiedzialnością, komentarze gdy wyjaśniają dlaczego, nie co.

• Where(x => warunek) – filtruje, zostawia tylko elementy spełniające warunek
• Select(x => przekształcenie) – przekształca każdy element (jak map w funkcyjnym)
• OrderBy(x => klucz) / OrderByDescending() – sortuje
• FirstOrDefault(x => warunek) – pierwszy pasujący element lub wartość domyślna typu, np. null dla klasy albo 0 dla int
• Any(x => warunek) – czy istnieje jakikolwiek pasujący element (bool)
• Count(x => warunek) – ile elementów spełnia warunek
• GroupBy(x => klucz) – grupuje elementy
• ToList() / ToArray() – materializuje wynik zapytania

WinForms to dojrzała technologia do budowania aplikacji okienkowych Windows. Warto ją znać, ponieważ dobrze pokazuje pracę z kontrolkami, właściwościami i zdarzeniami.

• Właściwość Text – tekst wyświetlany w kontrolce (etykieta na przycisku, tytuł okna). (Name) to nazwa obiektu w kodzie C# – nie mylić z Text!
• Podłączanie zdarzeń: button1.Click += ObsługaKliknięcia; lub dwukliknięcie na kontrolce w designerze. Możesz podłączyć wiele metod do jednego zdarzenia.
• ShowDialog() – otwiera dialog modalny (blokuje okno nadrzędne, musisz zamknąć dialog żeby wrócić). Show() – niemodalny (możesz pracować w oknie nadrzędnym).
• Enabled = false – wygasza kontrolkę (widoczna ale nie reaguje). Visible = false – ukrywa kontrolkę (jakby jej nie było).
• Aktualizacja UI z innego wątku – w WinForms możesz użyć m.in. Invoke() lub BeginInvoke(). W nowym kodzie często wygodniej użyć async/await i wracać do kontekstu wątku UI.
• DataGridView – tabela do wyświetlania i edycji danych. Podłączasz ją z listą obiektów lub DataTable przez DataSource.
• Zdarzenie Load – uruchamia się przy inicjalizacji formularza, przed wyświetleniem. Tu umieszczasz kod ładujący dane (np. z bazy).
• Zdarzenie Click vs MouseClick: Click reaguje też na Enter/Space, MouseClick tylko na mysz.
• ContextMenuStrip – menu kontekstowe (prawa myszka). Przypisujesz do kontrolki przez właściwość ContextMenuStrip.
• Dialog modalny vs niemodalny: modalny = wymaga zamknięcia żeby wrócić do głównego okna (np. MessageBox). Niemodalny = można jednocześnie korzystać z okna głównego.

• XAML – Extensible Application Markup Language. Deklaratywny XML-owy opis interfejsu. Logika w plikach .cs (code-behind), ale w MVVM staramy się trzymać logikę w ViewModelu.
• MVVM (Model–View–ViewModel):
  • Model – klasy danych (np. Klient, Zamówienie), logika biznesowa
  • View – XAML, czysto wizualny, bez logiki aplikacji
  • ViewModel – logika interfejsu, komendy i właściwości udostępniane przez binding. Nie zna widoku bezpośrednio.
• Data Binding – powiązanie danych między źródłem a kontrolką UI. Kierunek synchronizacji zależy od trybu bindingu, np. OneWay albo TwoWay.
• INotifyPropertyChanged – interfejs implementowany zwykle przez ViewModel. Zdarzenie PropertyChanged informuje UI, że właściwość się zmieniła.
• ObservableCollection<T> – kolekcja, która informuje UI gdy dodasz lub usuniesz element. Zwykła List<T> tego nie robi.
• ICommand (RelayCommand) – enkapsuluje akcję przycisku jako obiekt. W XAML: Button Command="{Binding ZapiszCommand}" zamiast event handlera w code-behind.
• IValueConverter – przekształca dane w bindingu. Np. bool → Visibility (gdy Active=true, pokaż element), enum → kolor.

• .NET MAUI – Multi-platform App UI. Jeden projekt C# + XAML działa na Windows, macOS, Android i iOS. Następca Xamarin.Forms.
• Entity Framework Core (EF Core) – ORM (Object-Relational Mapper). Zamiast pisać SQL ręcznie, operujesz na danych przez klasy C# (context.Klienci.Where(...).ToList()).
• Wzorzec Repository – warstwa abstrakcji nad dostępem do danych. Logika biznesowa nie wie czy dane są w SQL Server, SQLite czy w API.

JavaScript (JS) to dynamicznie typowany język, który działa w przeglądarce, a dzięki środowiskom takim jak Node.js także po stronie serwera i w narzędziach. Ten sam język może więc obsługiwać interfejs oraz backend aplikacji.

• Typowanie dynamiczne – typ zmiennej jest określany w czasie wykonania, nie kompilacji. let x = 5 → x jest liczbą. x = "hello" → x jest teraz stringiem. To wygodne, ale łatwo o błędy.
• var / let / const: var – stara składnia, zasięg funkcji, unikaj. let – zmienna blokowa, można zmieniać wartość. const – stała blokowa, nie można przypisać nowej wartości (ale obiekt w środku można mutować).
• Funkcje strzałkowe (arrow functions): const dodaj = (a, b) => a + b. Krótsza składnia, nie ma własnego this – ważne przy callbackach.
• async / await: const dane = await fetch(url). Asynchroniczne operacje (żądania HTTP, odczyt pliku) bez blokowania wątku. Metoda musi być oznaczona async.
• Promise: obiekt reprezentujący wynik asynchronicznej operacji, który nastąpi w przyszłości. then() / catch() lub await.
• DOM (Document Object Model): JavaScript może modyfikować strukturę strony HTML. document.getElementById('id'), element.innerHTML, element.classList.add('klasa').
• Zdarzenia: element.addEventListener('click', funkcja). Reagowanie na akcje użytkownika.
• fetch() / AJAX: pobieranie danych z serwera bez przeładowania strony. const res = await fetch('/api/dane'); const json = await res.json();

• Selektory: div (element), .klasa (klasa), #id (identyfikator), div > p (bezpośredni potomek), div p (każdy potomek). Specyficzność: ID > klasa > element.
• Box model: każdy element to prostokąt: content + padding (wewnętrzny margines) + border (ramka) + margin (zewnętrzny margines).
• Flexbox: display: flex na rodzicu. Dzieci układają się w linii lub kolumnie. justify-content = wyrównanie wzdłuż osi głównej, align-items = wzdłuż osi poprzecznej.
• CSS Grid: display: grid; grid-template-columns: repeat(3, 1fr). Dwuwymiarowy układ. Flexbox = 1D (wiersz lub kolumna), Grid = 2D (wiersze i kolumny jednocześnie).
• Media queries (RWD): @media (max-width: 768px) { ... } – inne style dla różnych szerokości ekranu. Podstawa Responsive Web Design.
• Zmienne CSS: --kolor-glowny: #5b7cf8; w :root, potem color: var(--kolor-glowny). Łatwa zmiana motywu w całym projekcie.

• TypeScript (TS) – nadzbiór JavaScript stworzony przez Microsoft. Dodaje statyczne typowanie do JS. Piszesz w TS → kompilator (tsc) tłumaczy na czysty JS, który rozumie przeglądarka i Node.js.
• Typy: let wiek: number = 25, let imie: string, let aktywny: boolean, let lista: string[], let para: [string, number] (tuple).
• Interfejsy: interface Uzytkownik { id: number; imie: string; }. Definiujesz kształt obiektu. Kompilator pilnuje żebyś używał właściwych pól.
• Opcjonalne pola: adres?: string – pole może być undefined. Bez ? pole jest wymagane.
• Typy union: let status: 'aktywny' | 'nieaktywny' | 'zawieszony' – zmienna może być jedną z kilku wartości.
• Generyki: function pierwszyElement<T>(lista: T[]): T – ta sama funkcja działa bezpiecznie dla tablic dowolnego typu.
• Dlaczego TS zamiast JS: błędy wykrywane w edytorze (nie w runtime), lepszy IntelliSense, łatwiejszy refactoring dużych projektów. Angular wymaga TypeScript. React działa z obydwoma.

• Node.js – środowisko uruchomieniowe JavaScript poza przeglądarką. Bazuje na silniku V8 (Chrome). Pozwala pisać serwery, narzędzia CLI, skrypty w JS/TS.
• npm (Node Package Manager) – menadżer pakietów JS. Instalujesz gotowe biblioteki i frameworki jednym poleceniem.
• package.json – serce projektu Node. Zawiera: nazwę projektu, wersję, skrypty (npm start, npm run build), listę zależności (dependencies) i dev-zależności (devDependencies).
• node_modules/ – folder ze wszystkimi zainstalowanymi pakietami. NIE wrzucasz go do Git! Jest w .gitignore. Współpracownik odtwarza go przez npm install.

# Instalacja zależności z package.json (po sklonowaniu projektu)
npm install
 
# Instalacja konkretnego pakietu i zapis do package.json
npm install axios
npm install --save-dev typescript     # tylko do dev (nie na produkcję)
 
# Uruchomienie skryptu zdefiniowanego w package.json
npm start
npm run build
npm run test
 
# Globalna instalacja narzędzia CLI (np. Angular CLI)
npm install -g @angular/cli

• Angular – komponentowy framework do budowy aplikacji webowych i SPA, oparty na TypeScript. Ma wbudowany DI, router, formularze i klienta HTTP oraz narzuca spójną strukturę projektu.
• Komponent – podstawowy budulec Angular. Składa się z: klasy TS (@Component), szablonu HTML i opcjonalnego pliku CSS. Każda strona/widget to osobny komponent.
• Angular CLI (ng) – narzędzie do tworzenia i budowania projektów Angular.

# Tworzenie nowego projektu Angular
ng new nazwa-projektu
 
# Uruchomienie deweloperskiego serwera (http://localhost:4200)
ng serve
ng serve --open          # od razu otwiera przeglądarkę
 
# Generowanie komponentu, serwisu, modułu
ng generate component moj-komponent
ng generate service moj-serwis
ng g c produkty          # skrócona składnia
 
# Budowanie produkcyjne (minifikacja, optymalizacja)
ng build --configuration production

• Dyrektywy w szablonie: *ngFor="let p of produkty" – pętla po liście, *ngIf="isLoading" – warunkowe wyświetlanie, [(ngModel)]="pole" – two-way binding (zmiana w polu = zmiana w zmiennej i odwrotnie).
• Serwis (Service) – klasa z logiką biznesową lub wywołaniami HTTP. Wstrzykiwana do komponentów przez DI. Zasada: komponent zarządza widokiem, serwis zarządza danymi.
• Routing – RouterModule. Definiujesz ścieżki URL → komponenty. <router-outlet> w szablonie = miejsce gdzie Angular wyświetla aktualny komponent.
• HttpClient – moduł do żądań HTTP. this.http.get<Produkt[]>('/api/produkty') zwraca Observable.
• Observable / RxJS – strumień danych, możesz subskrybować i reagować na każdą emitowaną wartość. Angular używa go wszędzie (HTTP, Router, formularze).

• React – biblioteka (nie framework!) do budowy interfejsów użytkownika. Nie narzuca struktury całego projektu – ty decydujesz o routerze, zarządzaniu stanem, żądaniach HTTP. Popularny i szeroko stosowany.
• JSX – rozszerzenie składni JS, które pozwala zapisywać strukturę interfejsu podobną do HTML w kodzie JavaScript. Narzędzie budujące tłumaczy JSX na kod wykonywalny przez przeglądarkę; współczesny transform nie musi bezpośrednio używać React.createElement().
• Komponent funkcyjny – prosta funkcja JS/TS zwracająca JSX. To standardowy sposób pisania komponentów od React 16.8.
• useState – hook do zarządzania lokalnym stanem komponentu. const [licznik, setLicznik] = useState(0). Wywołanie setLicznik(1) re-renderuje komponent.
• useEffect – hook do efektów ubocznych (wywołania API, subskrypcje, timery). useEffect(() => { fetchDane(); }, []) – pusty array = wykonaj raz po pierwszym renderze.
• Props – parametry komponentu przekazywane z rodzica do dziecka. Jednokierunkowy przepływ danych (z góry w dół). <Przycisk tekst="Zapisz" onClick={handleSave} />

# Tworzenie projektu React (Vite – szybszy od Create React App)
npm create vite@latest nazwa-projektu -- --template react-ts
 
# Instalacja zależności i uruchomienie
cd nazwa-projektu
npm install
npm run dev              # serwer dev na http://localhost:5173
 
# Budowanie produkcyjne
npm run build            # wynik w folderze dist/

• Bootstrap – najpopularniejszy framework CSS. Daje gotowe komponenty (przyciski, karty, navbar, modal, formularze) i responsywny system siatki. Używasz klas CSS zamiast pisać style od zera.
• System siatki (Grid) – 12 kolumn. Wiersz: <div class="row">, kolumna: <div class="col-md-6"> (6 z 12 kolumn na ekranie md i większym = 50% szerokości). Breakpointy: sm (≥576px), md (≥768px), lg (≥992px), xl (≥1200px).
• Klasy użytkowe (utility classes): mt-3 (margin-top), p-2 (padding), d-flex (display:flex), text-center, fw-bold, text-primary. Szybkie stylowanie bez pisania CSS.
• Komponenty Bootstrap: btn btn-primary (przycisk), card (karta), navbar (pasek nawigacji), modal (dialog), alert alert-danger (komunikat).
• Instalacja przez npm: npm install bootstrap, potem import w głównym pliku: import 'bootstrap/dist/css/bootstrap.min.css'.
• Bootstrap Icons – darmowy zestaw ikon: npm install bootstrap-icons, użycie: <i class="bi bi-trash"></i>.

• Flutter – framework Google (open source). Rysuje własne widżety na płótnie (Canvas), nie używa natywnych komponentów OS. Efekt: identyczny wygląd na wszystkich platformach. Android + iOS + Web + Desktop + Embedded z jednej bazy kodu.
• Dart – język programowania rozwijany przez Google, najczęściej kojarzony z Flutterem, ale możliwy do użycia także w aplikacjach serwerowych, webowych i narzędziach CLI. Jest statycznie typowany i może być kompilowany do kodu natywnego lub JavaScript.

• React Native – framework Meta (Facebook). JavaScript/TypeScript, ale renderuje natywne komponenty UI (nie HTML/WebView jak hybrydy). Most między JS a natywnymi API.
• Google Play – format AAB (Android App Bundle) – Google Play wymaga AAB dla nowych aplikacji publikowanych w sklepie. Na podstawie pakietu generuje zoptymalizowane APK dla konkretnych urządzeń. APK nadal służy m.in. do instalacji i testów poza Google Play.
• App Store (iOS) – zarządzasz przez App Store Connect. Testy beta przez TestFlight. Każda aplikacja musi przejść review Apple – trwa od kilku godzin do kilku dni.

Activity jest głównym komponentem interfejsu Androida i zwykle udostępnia okno aplikacji. Może reprezentować ekran, ale współczesna aplikacja może również mieć jedną Activity i wiele ekranów zbudowanych za pomocą fragmentów lub Jetpack Compose.

• onCreate() – wywoływany przy tworzeniu każdej nowej instancji Activity, także po jej odtworzeniu. Tu ustawiasz interfejs, inicjalizujesz widoki i odczytujesz zapisany stan.
• onStart() – Activity staje się widoczna dla użytkownika.
• onResume() – Activity na pierwszym planie, użytkownik może interagować. Tu wznawiasz animacje, odtwarzanie mediów.
• onPause() – Activity traci fokus. Wstrzymujesz krótkie operacje, które nie powinny trwać bez aktywnego fokusu. Metoda jest krótka; nie zapisuj w niej dużych danych ani nie wykonuj operacji sieciowych.
• onStop() – Activity jest całkowicie niewidoczna. Zwalniasz ciężkie zasoby.
• onDestroy() – Activity jest niszczona (użytkownik zamknął lub rotacja ekranu). Rotacja = Android niszczy i na nowo tworzy Activity!

• Activity – komponent udostępniający okno i punkt wejścia do interakcji użytkownika. Aplikacja może mieć wiele Activity albo jedną Activity obsługującą wiele ekranów.
• Fragment – modułowy komponent UI osadzany w Activity. Ma własny cykl życia. Używasz gdy chcesz tego samego UI na telefonie i tablecie.
• Intent – komunikat/żądanie między komponentami. Explicit intent: bezpośrednio wskazujesz klasę docelową (new Intent(this, DetailActivity.class)). Implicit intent: opisujesz co chcesz zrobić, Android wybiera aplikację (ACTION_VIEW dla linku = otwiera przeglądarkę).
• Service – komponent bez własnego UI do pracy, która ma trwać niezależnie od ekranu. Foreground service pokazuje trwałe powiadomienie i ma wyższy priorytet, ale system nadal może zakończyć jego proces w krytycznej sytuacji.
• BroadcastReceiver – reaguje na systemowe zdarzenia rozgłoszeniowe (np. BOOT_COMPLETED = urządzenie się uruchomiło, CONNECTIVITY_CHANGE = zmiana sieci).
• AndroidManifest.xml – deklaruje wszystkie komponenty aplikacji, wymagane uprawnienia i minimalną wersję Androida (minSdkVersion).

• ViewModel – przechowuje dane UI i przeżywa rotację ekranu (gdy Activity jest niszczona). Komunikuje się przez LiveData lub StateFlow.
• LiveData – obserwowalny kontener danych uwzględniający cykl życia. UI aktualizuje się automatycznie, ale tylko gdy Activity/Fragment jest aktywny (zapobiega crashom na zabitym widoku).
• Room – ORM nad SQLite. Składa się z: Entity (klasa = tabela), DAO (interfejs z metodami dostępu), Database (klasa zarządzająca). Kompilator sprawdza SQL w czasie kompilacji.
• RecyclerView – efektywna lista z recyclingiem widoków (nie tworzy N widoków dla N elementów, tylko tyle ile widać + kilka). Wymaga ViewHolder i Adapter.
• WorkManager – zalecany do odraczalnych, gwarantowanych zadań w tle, które mogą zostać wykonane później także po restarcie urządzenia. Nie zastępuje AlarmManagera, gdy zadanie musi uruchomić się o dokładnej godzinie.
• Jetpack Compose – nowoczesne, deklaratywne UI w Kotlinie. Funkcje oznaczone @Composable opisują jak wygląda UI, a nie jak je zbudować krok po kroku.

• SharedPreferences – proste pary klucz–wartość w pliku XML. Idealne na ustawienia: motyw, język, ostatni użytkownik. Nie używaj do wrażliwych danych.
• SQLite / Room – pełnoprawna lokalna baza relacyjna na urządzeniu. Dla danych strukturalnych, większej ilości danych.
• Pliki aplikacji – pliki wewnętrzne są prywatne dla aplikacji i kasowane przy odinstalowaniu. Dostęp do katalogu aplikacji w pamięci zewnętrznej od Androida 4.4 nie wymaga uprawnień do pamięci; dostęp do innych plików zależy od wersji Androida i zasad scoped storage.
• Wzorzec offline-first – dane lokalne w Room, synchronizacja z API gdy jest sieć. Aplikacja działa nawet bez internetu.

Piramida testów to model mówiący jak dużo testów każdego rodzaju powinieneś mieć. Na dole jest ich dużo (testy jednostkowe), na górze mało (testy E2E). Im wyżej, tym wolniejsze, droższe w utrzymaniu i trudniejsze w diagnostyce.

• Unit testy (jednostkowe) – testujesz jedną metodę lub klasę w izolacji od reszty systemu. Używasz zaślepek (mock, stub) zamiast prawdziwych zależności (baza, API). Szybkie (milisekundy), dużo ich powinno być.
• Testy integracyjne – testujesz współdziałanie kilku modułów razem (np. warstwa biznesowa + baza danych). Wolniejsze, wykrywają błędy na styku komponentów, które testy jednostkowe pomijają.
• Testy E2E (end-to-end) – symulują prawdziwego użytkownika klikającego w aplikację (Selenium, Cypress, Playwright). Najwolniejsze, testują cały system od UI do bazy. Kosztowne w utrzymaniu.
• Testy regresji – po każdej zmianie kodu uruchamiasz wszystkie testy żeby sprawdzić, że nic starego się nie zepsuło.
• Testy akceptacyjne (UAT) – klient lub użytkownik końcowy weryfikuje czy system spełnia wymagania biznesowe. To oni decydują czy funkcja jest gotowa.
• Smoke test – szybki test podstawowych funkcji po deploymencie. „Czy aplikacja w ogóle się uruchamia i logowanie działa?”
• Testy wydajnościowe: load testing (normalne obciążenie), stress testing (ponad limity), endurance testing (długo przy stałym obciążeniu).
• A/B testing – dwie wersje funkcji dla różnych grup użytkowników. Decyzja co wdrożyć – na podstawie danych, nie intuicji.

• Black-box – testujesz wejście → oczekiwane wyjście. Nie znasz implementacji. Skupiasz się na wymaganiach, nie na kodzie.
• White-box (glass-box) – testujesz znając implementację. Sprawdzasz czy każda gałąź kodu jest przetestowana (code coverage).
• Partycjonowanie równoważności – dzielisz dane wejściowe na klasy, w których program zachowuje się tak samo (np. poprawne wiek: 0–120, za małe: poniżej 0, za duże: powyżej 120). Testujesz jeden reprezentant z każdej klasy.
• Analiza wartości brzegowych – testujesz tuż pod, dokładnie na i tuż nad granicą zakresu. Dla zakresu 1–100: testujesz 0, 1, 2, 99, 100, 101. Tu najczęściej są off-by-one błędy.
• TDD (Test-Driven Development) – Red → Green → Refactor. Najpierw piszesz test (który nie przechodzi, bo kodu nie ma – czerwony), potem piszesz minimalny kod żeby test przeszedł (zielony), potem refaktorujesz kod zachowując zielone testy.
• BDD (Behavior-Driven Development) – testy opisane językiem naturalnym (Given-When-Then). Narzędzia: Cucumber, SpecFlow.

• NUnit / xUnit / MSTest – frameworki testów jednostkowych dla .NET/C#. Atrybuty: [Test], [Fact], [TestMethod]. AAA: Arrange (przygotuj), Act (działaj), Assert (sprawdź).
• Mock – obiekt symulujący zależność, kontrolujesz jego zachowanie. Stub – zwraca ustalone wartości. Fake – uproszczona implementacja (np. InMemoryDatabase). Spy – prawdziwy obiekt + śledzenie wywołań.
• Code coverage – procent kodu wykonanego przez testy. Narzędzia: Coverlet (.NET), JaCoCo (Java). 100% coverage ≠ brak błędów!
• Debugger – breakpointy (F9), step into (F11, wchodzisz do metody), step over (F10, wykonujesz i idziesz dalej), step out (Shift+F11, wychodzisz z metody), watch (obserwujesz wartości zmiennych).
• Bug report – musi zawierać: kroki reprodukcji, wynik oczekiwany, wynik rzeczywisty, środowisko (OS, wersja, browser), screenshoty/video.
• Linter – narzędzie do statycznej analizy kodu (ESLint dla JS, StyleCop dla C#). Wykrywa potencjalne błędy i wymusza styl bez uruchamiania kodu.

SDLC (Software Development Life Cycle) to sposób organizacji pracy nad projektem informatycznym. Na egzaminie pojawia się pytanie: „W którym modelu SDLC występuje etap analizy ryzyka?” – odpowiedź: spiralnym.

• Model kaskadowy (Waterfall) – klasyczny, sekwencyjny. Fazy: Analiza → Projektowanie → Implementacja → Testowanie → Wdrożenie → Utrzymanie. Każda faza kończy się przed rozpoczęciem następnej. Zalety: przewidywalny, dobra dokumentacja. Wady: bardzo trudno cofnąć się do poprzedniej fazy. Sprawdza się gdy wymagania są stabilne i z góry znane.
• Model spiralny (Spiral) – każde „okrążenie” spirali to pełny cykl: planowanie, analiza ryzyka, tworzenie prototypu, ocena przez klienta. Dla każdego okrążenia wraca do analizy ryzyka. Dobry dla dużych, ryzykownych projektów. Zapamiętaj: analiza ryzyka = model spiralny.
• Model z prototypem – buduje szybki prototyp, pokazuje klientowi, zbiera feedback, poprawia, znowu pokazuje. Dobry gdy klient nie wie dokładnie czego chce.
• Model iteracyjny (przyrostowy) – buduje system w kolejnych iteracjach, każda dodaje nowe funkcje. Klient dostaje działający produkt szybko, choć niepełny.
• Agile / Scrum – rodzina metodyk zwinnych. Krótkie sprinty (1–4 tygodnie), ciągłe dostarczanie wartości, adaptacja do zmian. Manifesto Agile: ludzie i interakcje > procesy i narzędzia; działające oprogramowanie > obszerna dokumentacja; współpraca z klientem > negocjowanie umów; reagowanie na zmiany > realizacja planu.
• RAD (Rapid Application Development) – szybkie tworzenie aplikacji dzięki narzędziom wizualnym, komponentom wielokrotnego użytku i minimalnej dokumentacji. Skupia się na szybkim prototypowaniu i iteracjach z klientem.

• Wymagania funkcjonalne – co system ma robić. „Użytkownik może dodać produkt do koszyka.” „System wysyła e-mail po rejestracji.”
• Wymagania niefunkcjonalne – jak dobrze ma działać. Wydajność: „System obsługuje 200 równoczesnych użytkowników.” Bezpieczeństwo, dostępność (uptime 99,9%), skalowalność, utrzymywalność.

• README.md – opis projektu, jak zainstalować, jak uruchomić, przykłady użycia. Pierwsza rzecz jaką widzi ktoś odwiedzający repozytorium.
• CHANGELOG.md – historia zmian z podziałem na wersje. Konwencja Keep a Changelog i Semantic Versioning (MAJOR.MINOR.PATCH).
• XML Doc (C#) – komentarze /// <summary> generują IntelliSense i dokumentację API automatycznie.
• Swagger/OpenAPI – automatyczna, interaktywna dokumentacja REST API. Programiści mogą testować endpointy bezpośrednio z przeglądarki.
• Plan testów – zakres testowania, metody, środowisko, role, harmonogram, kryteria zakończenia (co znaczy „gotowe”).
• Przypadek testowy – ID, warunki wstępne, dane wejściowe, kroki, wynik oczekiwany, wynik rzeczywisty, status (pass/fail).

• Aktywne słuchanie – parafrazuj wypowiedź rozmówcy, zadawaj pytania doprecyzowujące i upewniaj się, że dobrze rozumiesz wymaganie.
• Informacja zwrotna – opisuj konkretną sytuację i jej skutek; oceniaj rozwiązanie, nie osobę.
• Negocjowanie – przedstawiaj ograniczenia, szukaj rozwiązania korzystnego dla projektu i potwierdzaj ustalenia.
• Rozwiązywanie problemów – zbierz fakty, odtwórz problem, zaproponuj warianty i oceń skutki każdego rozwiązania.

Scrum to framework zwinny do zarządzania pracą zespołu. Opiera się na krótkich, regularnych cyklach pracy zwanych sprintami.

• Planowanie – określ zakres, rezultaty, zależności, ryzyka, terminy i kryteria ukończenia zadania.
• Przydział zadań – dopasuj zadania do kompetencji i dostępności osób, zapewniając możliwość konsultacji i rozwoju.
• Monitorowanie – regularnie sprawdzaj postęp, blokady, jakość rezultatów oraz zgodność z harmonogramem.
• Dokumentowanie – zapisuj decyzje, wymagania, statusy, wyniki testów i zmiany w sposób dostępny dla zespołu.
• Ocena jakości – stosuj kryteria akceptacji, code review, testy i retrospektywę, a następnie wprowadzaj usprawnienia.

• git init – inicjalizuje nowe repozytorium w bieżącym folderze
• git add . – dodaje wszystkie zmienione pliki do staging area (poczekalni)
• git commit -m "Opis" – zapisuje snapshot zmian w lokalnym repozytorium z komentarzem
• git push – wysyła lokalne commity na zdalny serwer (GitHub, GitLab)
• git pull – pobiera i scala zmiany ze zdalnego repo do lokalnego
• git branch nazwa – tworzy nową gałąź
• git checkout -b nazwa – tworzy i przełącza się na nową gałąź jednocześnie
• git merge gałąź – scala wskazaną gałąź do bieżącej
• git log – historia commitów
• git status – stan roboczego drzewa (które pliki zmienione, które w staging)
• git reset --soft HEAD~1 – cofa ostatni commit, ale zachowuje zmiany w staging
• git reset --hard HEAD~1 – cofa ostatni commit i usuwa zmiany (destrukcyjne!)
• .gitignore – plik z listą plików/folderów ignorowanych przez Git (np. bin/, node_modules/, pliki .env)
• Pull Request (PR) / Merge Request (MR) – prośba o włączenie gałęzi do głównej. Umożliwia code review przed scaleniem. To jest główny mechanizm współpracy zespołowej w Git.
• Code Review – inny programista analizuje Twój kod przed mergem. Cel: wykrywanie błędów, poprawa jakości, transfer wiedzy w zespole.

• CI (Continuous Integration) – po każdym commit/push automatycznie uruchamia się build i testy. Błędy wykrywane natychmiast. Narzędzia: GitHub Actions, GitLab CI, Jenkins.
• CD (Continuous Delivery) – przetestowany kod jest gotowy do wdrożenia jednym kliknięciem. CD (Deployment) – wdrożenie odbywa się automatycznie bez ingerencji człowieka.
• Jira – zarządzanie zadaniami (ticketami), sprint board, backlog. Obsługuje Scrum i Kanban. Integruje się z Git.
• Kanban – ciągły przepływ zadań przez kolumny (To Do → In Progress → Review → Done). Bez stałych sprintów. Limit WIP (Work In Progress) na każdej kolumnie – zapobiega wielozadaniowości.
• Diagram Gantta – słupki zadań na osi czasu z zależnościami między nimi. Narzędzie do planowania harmonogramu projektu.
• Event Storming – warsztat odkrywania domeny biznesowej. Karteczki sticky notes: pomarańczowe = zdarzenia, niebieskie = komendy, żółte = aggregaty. Angażujesz ekspertów domenowych.

OWASP publikuje aktualizowany dokument OWASP Top 10 opisujący najważniejsze kategorie ryzyka aplikacji webowych. Poniższa tabela zawiera praktyczne przykłady zagrożeń, ale nie jest dosłowną listą OWASP Top 10:2025.

• SQL Injection – atakujący wstrzykuje fragment SQL przez pole formularza (np. wpisuje ' OR '1'='1). Może odczytać całą bazę, usunąć dane lub ominąć logowanie. Ochrona: parametryzowane zapytania lub ORM (nigdy nie sklejasz SQL ze stringiem!).
• XSS (Cross-Site Scripting) – atakujący wstrzykuje złośliwy JavaScript do treści strony (np. w komentarzu). Inny użytkownik odwiedza stronę, jego przeglądarka wykonuje skrypt. Ochrona: escapowanie danych wyjściowych, nagłówek Content-Security-Policy (CSP).
• CSRF (Cross-Site Request Forgery) – złośliwa strona nakłania przeglądarkę zalogowanego użytkownika do wysłania żądania do innej strony (np. przelew bankowy bez wiedzy użytkownika). Ochrona: tokeny CSRF (unikalny token w każdym formularzu, serwer sprawdza).
• MITM (Man-in-the-Middle) – atakujący wchodzi między klienta a serwer i przechwytuje komunikację (odszyfrować, odczytać, zmienić). Ochrona: HTTPS z ważnym certyfikatem TLS.
• Brute force – automatyczne próbowanie wszystkich możliwych haseł. Ochrona: rate limiting (ograniczenie ilości prób), CAPTCHA, blokada konta po N próbach, wymaganie silnych haseł.
• Path Traversal – atakujący wychodzi poza dozwolony katalog przez ../../etc/passwd w ścieżce pliku. Ochrona: walidacja i sanityzacja ścieżek.

• Szyfrowanie symetryczne – ten sam klucz do szyfrowania i deszyfrowania (np. AES). Szybkie, ale problem jak bezpiecznie przekazać klucz drugiej stronie.
• Szyfrowanie asymetryczne (klucz publiczny/prywatny) – dwa powiązane klucze. Klucz publiczny = możesz go udostępnić każdemu. Klucz prywatny = tylko Ty go znasz. Wiadomość zaszyfrowana kluczem publicznym = tylko Ty możesz odszyfrować kluczem prywatnym. Przykład: RSA. Podstawa TLS/HTTPS.
• HTTPS + TLS – szyfruje całą komunikację między przeglądarką a serwerem. Certyfikat SSL/TLS weryfikuje tożsamość serwera. Bez HTTPS dane są przesyłane plaintext.
• Haszowanie haseł (bcrypt) – hasła nigdy nie są przechowywane jako tekst jawny. bcrypt tworzy hash z solą (losowy string dodany przed haszowaniem). Celowo wolny algorytm – utrudnia brute force. NIE używaj MD5 ani SHA1 do haseł (za szybkie, złamane).
• Funkcja skrótu (hash) – jednokierunkowa. Z danych wejściowych otrzymujesz stały hash. Hash NIE jest odwracalny (nie możesz odzyskać oryginalnych danych). Używana do: weryfikacji integralności plików, przechowywania haseł.
• JWT (JSON Web Token) – format tokenu: header.payload.signature (Base64URL). Bezstanowa autoryzacja w REST API – serwer nie musi trzymać sesji. Podpis cyfrowy weryfikuje autentyczność. NIE przechowuj wrażliwych danych w payloadzie (jest tylko zakodowany, nie zaszyfrowany!).
• OAuth 2.0 i OpenID Connect – OAuth 2.0 służy przede wszystkim do delegowanej autoryzacji dostępu do zasobów. Logowanie użytkownika realizuje zwykle OpenID Connect zbudowany na OAuth 2.0.
• Zasada najmniejszych uprawnień (Least Privilege) – każdy komponent, użytkownik i konto ma tylko minimalne uprawnienia niezbędne do działania. Konto bazy danych aplikacji webowej nie potrzebuje DROP TABLE.
• CSP (Content-Security-Policy) – nagłówek HTTP ograniczający skąd mogą pochodzić skrypty, style, obrazy. Skuteczna ochrona przed XSS.
• CORS (Cross-Origin Resource Sharing) – mechanizm nagłówków określający, czy skrypt z innego originu może odczytać odpowiedź. Niektóre proste żądania cross-origin są wysyłane, ale bez właściwych nagłówków odpowiedź nie zostanie udostępniona skryptowi.

• Uwierzytelnianie (Authentication) – kto to jest? Sprawdzasz tożsamość (login + hasło, biometria, klucz API).
• Autoryzacja (Authorization) – co mu wolno? Sprawdzasz czy zalogowany użytkownik ma prawo do danego zasobu/akcji.
• 401 Unauthorized – brak uwierzytelnienia (nie zalogowany lub błędne dane). Mylna nazwa – tak naprawdę chodzi o autentykację, nie autoryzację.
• 403 Forbidden – zalogowany, ale bez uprawnień do zasobu.
• Walidacja po stronie serwera – zawsze obowiązkowa! Walidacja JavaScript w przeglądarce = tylko dla wygody użytkownika. Atakujący używa Postmana i wysyła żądania z dowolnymi danymi, omijając JS.
• Sanityzacja danych wejściowych – oczyszczasz dane zanim je wyświetlisz lub zapiszesz. Usuwasz lub escapujesz potencjalnie niebezpieczne znaki.