# Driver license - wiki

## ToDo

### Refaktor kodu
Organizmy:
- [ ] Authentication (login)
- [ ] Header
- [ ] Hero
- [ ] MainContent
- [ ] Navbar
- [ ] PracticeOrganisms/Regular/Menu
- [ ] PracticeOrganisms/Regular/TaskBottom
- [ ] PracticeOrganisms/Regular/TaskTop
- [ ] PracticeOrganisms/Review/Menu
- [ ] PracticeOrganisms/Review/TaskBottom
- [ ] PracticeOrganisms/Review/TaskTop
(Rozjebao sie taskinfo naprawie to)
- [x] Registration
Chyba w pełni zrobiony, usunięto mobilkę i scalono z desktopem oraz dano form do molekuły.
- [x] Summary
Utworzono molekułę tabeli, raczej nic więcej do roboty
- [ ] Theory
- [ ] UserOrganims/SavedQuestions
- [ ] UserOrganims/Settings
- [ ] UserOrganims/Statistics

### Praca pisemna
- [x] streszczenie po angielsku
- [ ] plan pracy
- [x] Atomowa struktura -- Zastosowanie rozwiązania 4.1.2 Przykłady zastosowania
- [x] 9. Podsumowanie i przyszłość projektu.
- [x] Projekt interfejsu 3.2
- [x] 4. Implementacja projektu, a
rzeczywistość -- może da się coś dopisać
- [x] 7. Baza danych -- opisać krótko
- [ ] 5. Frontend -- trzeba zrobić całość
- [x] 8. Przypadki użycia -- dokończyć
- [x] 2. Trzeba się upewnić, że mamy podane wymagania funkcjonalne i niefunkcjonalne.
- [x] Gdzieś dodać porównanie z istniejącymi rozwiązaniami, ale może rozdział 2. już to pokrywa.

**Czego chce od nas Zychla?:**

- [x] praca powinna być złożona w systemie LateX który ma akceptowalną typografię. Składanie pracy w jakimkolwiek innym systemie (np. Word) obniża jej subiektywną wartość w kategorii “forma” - zbyt trudno jest nad tą formą w czymś innym niż LateX zapanować

- [x] praca powinna mieć obowiązkowo wstęp w którym jeśli to możliwe znajduje się, po opisaniu tego czego praca dotyczy, link do repozytorium kodu - jeśli repozytorium jest publiczne. Link do repozytorium należy powtórzyć w części pracy gdzie opisuje się część techniczną

- [x] praca powinna mieć obowiązkowo plan pracy. Plan pracy jest częścią pierwszego rozdziału (wstęp) i jest akapitem lub osobnym podrozdziałem, który zbudowany jest następująco “W rozdziale drugim opisano ….”, “W rozdziale trzecim opisano …”, “W kolejnym, czwartym rozdziale opisano ….” …

:::warning
- [x] praca powinna mieć obowiązkowo część dotyczącą “porównania z innymi rozwiązaniami”. W zależności od ważności tego elementu, może to być część wstępu (mniejsza ważność) albo osobny rozdział (większa ważność). W tym porównaniu należy umieć wskazać co najmniej jeden, dwa przykłady aplikacji/rozwiązań/pomysłów, które dotyczą podobnego obszaru co ten opisany w pracy. Pominięcie tego elementu jest błędem formalnym. Również celowe pominięcie istnienia jakiegoś podobnego rozwiązania jest błędem - należy liczyć się z tym że recenzent wykaże minimum zainteresowania i znajdzie podobne rozwiązania - jeśli istnieją - a jeśli je znajdzie sam i w pracy nie będą one wzmiankowane, to recenzent potraktuje to jako mankament
:::

:::warning
- [x] praca powinna mieć obowiązkowo rozdział “teoretyczny”, opisujący problem/zagadnienie od strony wymagań funkcjonalnych i niefunkcjonalnych - jaki jest kontekst tego co się robi
:::

:::danger
- [x] praca powinna mieć obowiązkowo rozdział techniczny opisujący użyte technologie, model danych (może schemat bazy danych lub diagram modelu pojęciowego). Jeśli chodzi o prezentację architektury aplikacji to proszę się wzorować na modelu C4 (https://c4model.com/) w którym poziomy 2 i 3 (odpowiednio Container i Component) podpowiadają jak to można opisać (i zilustrować)
:::

- [x] praca powinna zawierać inne elementy wymienione w wymaganiach na stronie https://ii.uni.wroc.pl/dla-studenta/prace-dyplomowe Wyjątkiem jest sytuacja w której dla prac licencjackich mówi się o instrukcji dla uzytkownika i spisie przypadków użycia - z tych dwóch elementów można wybrać tylko jeden (zwykle wybiera się instrukcję dla użytkownika z przykładowymi ekranami aplikacji)

- [x] praca powinna mieć obowiązkowo rozdział ostatni “podsumowanie” w którym należy jeszcze raz powtórzyć co udało się zrobić, czego udało się nauczyć, czego się nie udało lub co się pominęło. Ten rozdział powinien mieć też obowiązkowo sekcję “future work” czyli “a gdyby tę pracę / tę aplikację” trzeba było kontynuować, to co jest do zrobienia, jakie kierunki badawcze / praktyczne ta praca otwiera

**w rozdziale technicznym powinny znaleźć się elementy:**

- [x] komponenty techniczne użyte w implementacji

- [x] instrukcja kompilacji (w tym powtórzony link do repozytorium) oraz klarowne, zrozumiałe i łatwe polecenia uzyskania działającej wersji. Ideałem jest instrukcja typu “sklonować repozytorium i wykonać polecenie npm install a potem npm start” ale dopuszczalna jest oczywiście instrukcja typu

* sklonować repozytorium
* zlokalizować skrypt bazy danych (foo.sql), uruchomić ten skrypt na pustej bazie PostreSQL
* ciąg połączenia do bazy danych wpisać do pliku appSettings.js (lub gdziekolwiek)

- [x] jeżeli kompilacja/uruchomienie aplikacji wymaga dodatkowych narzędzi (node.js, visual studio, android sdk, docker itd) to należy je traktować jako “czarne skrzynki” - nie wypisywać instrukcji instalacji tylko napisać “zainstalować X, Y, Z” i założyć że ktoś wie jak to zrobić

- [x] należy założyć że recenzent spróbuje skompilować aplikację, jeżeli mu się to nie uda, to zwróci uwagę że instrukcja kompilacji była niekompletna, niezrozumiała, nieaktualna itd.

:::danger
- [ ] część techniczna powinna obowiązkowo statystyki kodu, wykonane na przykład narzędziem cloc (https://github.com/AlDanial/cloc), z pominieciem oczywiście zewnętrznych bibliotek (tylko kod wchodzący w skład pracy)
:::

**Wymagania techniczne do kodu**

- [ ] kod źródłowy powinien zawierać komentarze, przynajmniej na składowych (klasach/metodach) publicznych. Kod bez komentarzy obniża wartość pracy

- [ ] wszystkie stałe w kodzie powinny być jawnie deklarowane jako stałe (a nie użyte jako “magic numbers”)

- [ ] parametry konfiguracyjne (ciągi połączeń do baz danych, tokeny dostępu itd. itp.) powinny być najlepiej w jednym pliku, typu (przykładowo) appSettings.js, opisane jako “maski”, znaczy bez konkretnych wartości ale z komentarzem że tu trzeba wstawić konkretną wartość. Podawanie konkretnych wartości w repozytorium (na przykład prawdziwe hasło albo prawdziwy token dostępu) jest traktowane jako błąd

:::danger
- [ ] kod musi mieć obowiązkowo jakiś zestaw testów jednostkowych - należy się wykazać umiejętnością ich przygotowania. W instrukcji dla programisty należy, oprócz opisanych wcześniej statystyk kodu, napisać ile jest testów jednostkowych i jak je uruchomić
:::

### Aplikacja

**Exam**
1. [x] logo przesuwa się w navbarze
2. [x] gwiazdka ma biały fill, ma byc jak na figmie
3. [x] zakończ egzamin ma się pogrubiać przy hoverze, gwiazdka też
4. [x] content za nisko
:::danger
6. [x] trzeba zmienić logikę losowania pytań (powinna być zgodna z państwowym egzaminem). Może pobierać wszystkie pytania z bazy i losować je po stronie klienta? Uprościmy zapytanie do BD, a będziemy ciągnąć co najwyżej kilka megabajtów danych.
:::

**Hero**
1. [x] buttony mają mieć hover
2. [x] subtitle maja złe interlinie
3. [ ] dodać stopkę (jak Karolina zrobi)

**Trening**
1. [ ] rozmiary fontów w kategorii i tytule są złe
2. [ ] wyjebać slajdy
3. [ ] bg za nisko
4. [ ] znajomość przenieść pod wyjaśnenie
5. [ ] zakończ i wyjaśnienie w jednej linii
6. [ ] czarny jest zbyt czarny
7. [ ] odległość tekstu do buttona taka sama jak w znajomości
8. [ ] w zegarze tekst od lewej krawedzi buttona
9. [ ] WSZYSTKO ZA NISKO
11. [x] typ pytania (?) literami
12. [x] liczba zadań nie działa
13. [ ] odpowiedzi się nie podswietlaja przy wyborze
14. [ ] teksty w brak mediów zły font
15. [ ] pytanie wiekszym fontem
16. [ ] hovery maja rózne kolory
17. [ ] gwiazdka ma byc pomarańczowa jak reszta buttonów
18. [ ] buttony tak i nie maja byc w srodku w (?) w (?)
19. [ ] z modala wywalic ramke i krzyzyk (powiela funkcję "nie")
20. [ ] wszystkie buttony na (?)

**Userpage**
1. [ ] za duze strząłki w dacie, nie ma hovera na strzałkach
2. [x] donut chart za duży
3. [ ] legenda wykresu w jednej linii i z boku
4. [ ] hover na pytaniu zapisanym i (?)
5. [ ] za duże fonty i złe
6. [ ] za duze padding w pytaniu
7. [ ] żółte buttony są za wielkie
8. [ ] pokaz wyjaśnienie w złym miejscu
9. [ ] dorobić avatary
10. [ ] bg za komponentami trzeba dodać (jak na figmie)
11. [ ] (?) w innym miejscu
12. [ ] usunąć kurstankę (tylko imie)
13. [ ] poprawić ustawienia (złe rozstawienie, jak na figmie)

**Register**
:::danger
1. [x] Brakuje treści marketingowej na stronie rejestracji. Powinno być jak na obrazku: 
:::

**Mobile Register**
1. [x] zły font w buttonie
2. [ ] hamburger do krawedzi a nie na srodku
3. [ ] hamburger bez ikon, zamist tego "konto"
4. [x] reload page z normalnym fontem, a nie fancy (imo z fancy jest bardzo ładnie, zostawiam tak)

**Ogólne**
1. [ ] HAMBURGER JEST MODALEM
2. [ ] Dodać animacje do wszystkiego

**Review**
1. [ ] wróc takie samo jak zakończ egzamin
2. [ ] wywal pusty button z gwiazdką
3. [ ] usuń shadow
4. [ ] nie da sie zamknkac modala
5. [ ] wywal ramke z modala

**Frontend**
:::danger
1. [x] wysłanie zapytania o zapisanie egzaminu ma stały userID. Trzeba to naprawić (pobrać id z backendu albo je przechowywać na froncie).
:::

---

**Zrobione**

1. [x] Dodać strony z wynikiem egzaminu do symulacji egzaminu i trybu nauki.
<!-- 
 -->

2. [x] **[Do ustalenia]** Zrefaktoryzować tryb nauki (wybór zapisanych pytań albo po poziomie znajomości).

3. [x] Dodać ilustracje na stronę.

4. [x] Umówić się z Zychlą na konsultacje.

5. [x] Przerobić `Paragraph`, żeby pobierał dziecko w `><` a nie przez `innerhtml`.

6. [x] Poprawić style w `hero`, żeby korzystało z `tailwind styled components`.

7. [x] Przerobić stronę praktyki na to co w figmie.

8. [x] Dokończyć stronę podręcznika.

9. [x] Zacząć pisać tekst rozdziału w podręczniku.

10. [x] Skrypt do przerabania pytań z csv do json (*crude edition*).

11. [x] Przerobić timer zgodnie z Figmą.

12. [ ] Dokończyć podręcznik (content)

13. [x] Przygotować bazę danych obrazków do podręcznika.

13. [x] Przeskalować fonty i buttony :black_square_button: :white_square_button:

14. [x] Dodać rozwijane wyjaśnienie do menu :scroll:

15. [x] Paralaksa / Karolinowe hero

16. [x] Skończyć tryb przeglądania odpowiedzi

17. [x] Dokończyć egzamin !!! Bo wygląda jak gówno :shit: (potwierdzam)

18. [x] Zacząć ogarniać bazę danych w **postresie**. 

18. [x] Wybrać syf do backendu (**POSTREEEEEES**)

19. [x] Poprawić inline'owe style w komponentach Krystiana na style bartkowe. (~~Hero~~, ~~Register~~, ~~Textbook~~)
20. [x] Refactor w praktyce (zbijanie kodu). Wszystko jest w `organisms`, a można je dodać do `molecules`.
21. [x] Dodać `grida` do praktyki, żeby załatwić responsywne kolumny i rozwijane menu.
22. [x] Pomyśleć nad ogólnym szablonem forma do `register` i `login`. Bartek coś mówi, że komponent ma być nakładką ze stylistyką, ale bez zawartości. Jest przekazywana jako `children` albo `props`. Podobnie do `modala`. Można też tak zrobić w podręczniku.
23. [x] Wywalić niepotrzebne branche.

---

## Wymogi do pracy pisemnej

Prace magisterskie i dyplomowe/inżynierskie
Wymagania ogólne do pracy

Składając wersję pisemną pracy należy zweryfikować jej zgodność z następującymi wymaganiami ogólnymi:

praca magisterska - praca na zakończenie studiów II stopnia

praca inżynierska/dyplomowa - praca na zakończenie studiów I stopnia

praca inżynierska zawiera elementy praktyczne

praca dyplomowa obejmuje raczej zagadnienia teoretyczne

uwaga ogólna - czym więcej praca wymienia elementów “subiektywnych”, zwraca uwagę na to co się udało samemu zrobić, czym się odróżnia od innych, czego udało się nauczyć, tym lepiej dla pracy.

praca powinna być złożona w systemie LateX który ma akceptowalną typografię. Składanie pracy w jakimkolwiek innym systemie (np. Word) obniża jej subiektywną wartość w kategorii “forma” - zbyt trudno jest nad tą formą w czymś innym niż LateX zapanować

praca powinna mieć obowiązkowo wstęp w którym jeśli to możliwe znajduje się, po opisaniu tego czego praca dotyczy, link do repozytorium kodu - jeśli repozytorium jest publiczne. Link do repozytorium należy powtórzyć w części pracy gdzie opisuje się część techniczną

praca powinna mieć obowiązkowo plan pracy. Plan pracy jest częścią pierwszego rozdziału (wstęp) i jest akapitem lub osobnym podrozdziałem, który zbudowany jest następująco “W rozdziale drugim opisano ….”, “W rozdziale trzecim opisano …”, “W kolejnym, czwartym rozdziale opisano ….” …

praca powinna mieć obowiązkowo część dotyczącą “porównania z innymi rozwiązaniami”. W zależności od ważności tego elementu, może to być część wstępu (mniejsza ważność) albo osobny rozdział (większa ważność). W tym porównaniu należy umieć wskazać co najmniej jeden, dwa przykłady aplikacji/rozwiązań/pomysłów, które dotyczą podobnego obszaru co ten opisany w pracy. Pominięcie tego elementu jest błędem formalnym. Również celowe pominięcie istnienia jakiegoś podobnego rozwiązania jest błędem - należy liczyć się z tym że recenzent wykaże minimum zainteresowania i znajdzie podobne rozwiązania - jeśli istnieją - a jeśli je znajdzie sam i w pracy nie będą one wzmiankowane, to recenzent potraktuje to jako mankament

praca powinna mieć obowiązkowo rozdział “teoretyczny”, opisujący problem/zagadnienie od strony wymagań funkcjonalnych i niefunkcjonalnych - jaki jest kontekst tego co się robi

praca powinna mieć obowiązkowo rozdział techniczny opisujący użyte technologie, model danych (może schemat bazy danych lub diagram modelu pojęciowego). Jeśli chodzi o prezentację architektury aplikacji to proszę się wzorować na modelu C4 (https://c4model.com/) w którym poziomy 2 i 3 (odpowiednio Container i Component) podpowiadają jak to można opisać (i zilustrować)

praca powinna zawierać inne elementy wymienione w wymaganiach na stronie https://ii.uni.wroc.pl/dla-studenta/prace-dyplomowe Wyjątkiem jest sytuacja w której dla prac licencjackich mówi się o instrukcji dla uzytkownika i spisie przypadków użycia - z tych dwóch elementów można wybrać tylko jeden (zwykle wybiera się instrukcję dla użytkownika z przykładowymi ekranami aplikacji)

praca powinna mieć obowiązkowo rozdział ostatni “podsumowanie” w którym należy jeszcze raz powtórzyć co udało się zrobić, czego udało się nauczyć, czego się nie udało lub co się pominęło. Ten rozdział powinien mieć też obowiązkowo sekcję “future work” czyli “a gdyby tę pracę / tę aplikację” trzeba było kontynuować, to co jest do zrobienia, jakie kierunki badawcze / praktyczne ta praca otwiera

w rozdziale technicznym powinny znaleźć się elementy:

komponenty techniczne użyte w implementacji

instrukcja kompilacji (w tym powtórzony link do repozytorium) oraz klarowne, zrozumiałe i łatwe polecenia uzyskania działającej wersji. Ideałem jest instrukcja typu “sklonować repozytorium i wykonać polecenie npm install a potem npm start” ale dopuszczalna jest oczywiście instrukcja typu

sklonować repozytorium

zlokalizować skrypt bazy danych (foo.sql), uruchomić ten skrypt na pustej bazie PostreSQL

ciąg połączenia do bazy danych wpisać do pliku appSettings.js (lub gdziekolwiek)

jeżeli kompilacja/uruchomienie aplikacji wymaga dodatkowych narzędzi (node.js, visual studio, android sdk, docker itd) to należy je traktować jako “czarne skrzynki” - nie wypisywać instrukcji instalacji tylko napisać “zainstalować X, Y, Z” i założyć że ktoś wie jak to zrobić

należy założyć że recenzent spróbuje skompilować aplikację, jeżeli mu się to nie uda, to zwróci uwagę że instrukcja kompilacji była niekompletna, niezrozumiała, nieaktualna itd.

część techniczna powinna obowiązkowo statystyki kodu, wykonane na przykład narzędziem cloc (https://github.com/AlDanial/cloc), z pominieciem oczywiście zewnętrznych bibliotek (tylko kod wchodzący w skład pracy)

Aspekt “naukowy” pracy

Praca magisterska powinna, oprócz elementów praktycznych/technicznych, mieć element określany jako “naukowy”.

W pracy inżynierskiej typu “program realizujący określone zadanie użytkowe” ten element może występować w postaci szczątkowej lub wręcz być pominięty, natomiast jeśli istnieje to stanowi dodatkowy atut.

Szczególny typ prac inżynierskich i magisterskich, zakładający opracowanie o walorach dydaktycznych / przeglądowych, w oczywisty sposób odwołuje się do istniejących wyników naukowych i wypełnia to wymaganie.

Natomiast w pracach bardziej “technicznych”, następujące elementy mogą być uznane za wypełniające to wymaganie:

opracowanie autorskiego projektu “czegoś” (języka, specyfikacji), rozszerzenie istniejącej specyfikacji o jakiś istotny element

opracowanie autorskiej implementacji “czegoś” (wzorca projektowego, narzędzia użytkowego) i porównanie go z jakimiś istniejącymi rozwiązaniami:

porównanie pod kątem listy funkcjonalności / zgodności ze standardem

jeżeli narzędzie implementuje jakiś standard to lista funkcjonalności aplikacji na tle listy wynikającej ze standardu

jeżeli narzędzie autorskie i narzędzie istniejące pokrywają się funkcjonalnie to po prostu zestawienie które (oczekiwane) właściwości są realizowane w jednym i drugim narzędziu

porównanie pod względem jakościowym

testy wydajnościowe - spreparowane przypadki testowe dla różnych rozmiarów “danych wejściowych” (cokolwiek to znaczy w kontekście rozwiązywanego zagadnienia) i pokazanie jak autorskie narzędzie wypada na tle istniejących

testy zużycia pamięci - jeżeli da się to mierzyć

Inne uwagi techniczne do pracy

praca moze być napisana w języku polskim lub angielskim

najbezpieczniej jest używać form bezosobowych, “zrobiono, zaproponowano” zamiast “zrobiłem/zrobiłam”. Jeżeli forma osobowa, to bezpieczniej mnoga “w pracy pokazujemy że…”.

jeżeli rozdział zawiera tylko jeden podrozdział (na przykład rozdział 3 ma tylko 3.1) albo podrozdział ma tylko jeden podpodrozdział (na przykład 3.1 ma tylko 3.1.1) to jest to błąd struktury. Należy albo usunąć ten jeden podrozdział (i zostawić zero) albo dodać co najmniej dwa

pracę należy obowiązkowo przepuścić przez spellchecker, błędy stylistyczne można przegapić, ale literówki - są niedopuszczalne

ryciny, rysunki, diagramy w tekście - niedopuszczalna jest sytuacja w której diagram nie ma numeru i podpisu. Niedopuszczalna jest sytuacja w której numer pod diagramem nie występuje w tekście. Czyli nie wolno napisać “ilustacja znajduje się poniżej”. Należy napisać “ten element jest przedstawiony na diagramie 4.5”

jeżeli rycina pochodzi z zewnątrz (np. z witryny internetowej) to niedopuszczalne jest jej po prostu wklejenie do pracy, trzeba wtedy napisac w podpisie że “źródło diagramu: {link}”. Najbezpieczniej jest takie ryciny przemalowywać samodzielnie, np. w Visual Paradigm lub innym narzędziu.

ryciny oraz inne elementy pracy nie powinny być oznaczone kolorami, ilustracja która ma coś np. czerwonego i zielonego a potem opis który się do tego odnosi to błąd. Proszę pamiętać że po standardowym wydrukowaniu (odcienie szarości) czerwień i zieleń będzie wyglądała dokładnie tak samo. Dlatego wykresy, ryciny itd używają elementów graficznych do odróżnienia elementów - na przykład linie na wykresie nie “czerwona i zielona” ale “kropkowana i złożona z małych plusików”

Kod źródłowy lub pseudokod w pracy - tylko czcionką o stałej szerokości i jeżeli z numerami linii, to zawsze osobne numerowanie w każdym snippecie (niedopuszczalna jest sytuacja że snippet pierwszy ma numery linii 1-22 a snippet kolejny numery linii 23-27, jeżeli to jest nowy, kolejny snippet to ma mieć swoje własne numery linii, od 1)

Poprawna bibliografia zawiera kompletne referencje bibliograficzne: nazwiska autorów, tytuł, rok wydania, wydawnictwo. W przypadku linków obowiązkowa jest nazwa strony (jeśli to jest strona domowa to należy napisać “Strona domowa projektu”....), adres oraz obowiązkowo - adnotacja “data dostępu xx.yy.zzzz” żeby było wiadomo kiedy autor pracy odwiedził konkretną witrynę internetową

Przykładowa struktura (spis treści) pracy inżynierskiej

poniższa propozycja powinna być traktowana jako punkt odniesienia, to nie znaczy że tak musi być, a jedynie że tak może być (i jak tak będzie to będzie poprawnie). Ta propozycja jest właściwa dla pracy typu “Implementacja aplikacji realizującej określone zadania użytkowe”

Wprowadzenie

Przedstawienie problematyki

Plan pracy

Opis i analiza zagadnienia

Historyjki użytkownika

Dodatkowe wymagania funkcjonalne

Wymagania niefunkcjonalne

Porównanie z innymi implementacjami (może być również częścią wprowadzenia przed planem pracy)

Implementacja

Spis użytych technologii i narzędzi (narzędzia pracy grupowej, github, narzędzia do przygotowania makiet itd.)

Model danych (+ diagramy)

Architektura (+ diagramy)

Opis rozwiazania wybranych problemów

Instrukcja użytkownika (+ zrzuty ekranów)

Część dla programisty

Instrukcja instalacji

Statystyki, testy jednostkowe

Podsumowanie i dalszy rozwój

Bibliografia

Wymagania techniczne do kodu

kod źródłowy powinien zawierać komentarze, przynajmniej na składowych (klasach/metodach) publicznych. Kod bez komentarzy obniża wartość pracy

wszystkie stałe w kodzie powinny być jawnie deklarowane jako stałe (a nie użyte jako “magic numbers”)

parametry konfiguracyjne (ciągi połączeń do baz danych, tokeny dostępu itd. itp.) powinny być najlepiej w jednym pliku, typu (przykładowo) appSettings.js, opisane jako “maski”, znaczy bez konkretnych wartości ale z komentarzem że tu trzeba wstawić konkretną wartość. Podawanie konkretnych wartości w repozytorium (na przykład prawdziwe hasło albo prawdziwy token dostępu) jest traktowane jako błąd

kod musi mieć obowiązkowo jakiś zestaw testów jednostkowych - należy się wykazać umiejętnością ich przygotowania. W instrukcji dla programisty należy, oprócz opisanych wcześniej statystyk kodu, napisać ile jest testów jednostkowych i jak je uruchomić

APD

Składając pracę w systemie APD należy się upewnić że uploaduje się dwa pliki, PDF z pracą i ZIP z kodem źródłowym jako załącznik. To powinien być ten sam kod który jest w repozytorium (jeśli jest repozytorium), oczywście sam kod (bez pakietów, zawartości node_modules itd. itp.)

Prezentacja/obrona

praca magisterska ma obronę. Obrona pracy magisterskiej składa się z kilku części:

prezentacja samej pracy przez studenta

pytania/dyskusja na temat pracy. Pytania mogą mieć charakter dociekliwy i nie należy odbierać tego jako próby podważenia wartości pracy tylko jako próbę poszerzenia wiedzy członków komisji na temat tego jak szeroko temat pracy został zbadany, zarówno w obszarze tym który jest spisany w ramach pracy jak i tym który nie jest spisany

3 pytania z wybranych przedmiotów - wybór możliwych przedmiotów jest opisany w programie studiów (https://ii.uni.wroc.pl/dla-studenta/II-stopnia) (cytat: Do ukończenia studiów konieczne jest złożenie pracy magisterskiej i zdanie egzaminu magisterskiego. Do pracy magisterskiej musi być załączone streszczenie w języku angielskim. W trakcie egzaminu student musi wykazać się znajomością tematyki pracy, ogólną wiedzą informatyczną i szczegółową znajomością trzech zaawansowanych dziedzin informatycznych (z zakresu przedmiotów: Języki formalne i złożoność obliczeniowa oraz przedmiotów z grupy I2), w tym dwóch spoza tematyki pracy. Wybór dziedzin zatwierdza przewodniczący komisji egzaminacyjnej

praca inżynierska/dyplomowa nie ma obrony, ma prezentację

prezentacja samej pracy przez studenta

pytania/dyskusja - zwykle mniej dociekliwa niż w przypadku prac magisterskich, regułą jest raczej to że recenzent dzieli się uwagami bardziej krytycznymi (zwraca uwagę na rzeczy które można było poprawić) a promotor bardziej wspierającymi (stara się docenić to co zostało zrobione dobrze)

prezentacja pracy w każdym przypadku (praca magisterska/inżynierska) trwa 15 do 20 minut. Prezentację należy sobie w głowie podzielić na trzy części

dwie części (z trzech) prezentacji zajmuje opowieść o pracy. Do tego należy obowiązkowo mieć prezentację ze slajdami (tym razem nie ma wymagań na to jak jest przygotowana, może być Powerpoint, Canva, cokolwiek). Bardzo proszę o pilnowanie czasu. Typowe błędy tej części prezentacji

prelegent ma za dużo slajdów - optymalna liczba slajdów to 10, góra 15

prelegent zbyt dużo czasu spędza na pierwszych, nieciekawych slajdach - czasu jest naprawdę mało. Jeżeli widać że prezentacja ma 15 slajdów a po 8 minutach ktoś jest na 3 slajdzie, to już wiadomo że nie jest dobrze

dlatego należy obowiązkowo co najmniej jeden raz zrobić próbę - samemu do lustra, do kolegi, koleżanki, rodzeństwa, do gumowej kaczuszki, jabłka: zaprezentować to co się ma do pokazania i zmierzyć czas. Jeśli wychodzi więcej niż 15 minut, trzeba przeprojektować prezentację i ją skrócić lub nauczyć się opowiadać zwięźlej

prezentacja krótsza niż 10-12 minut też jest uznawana za błąd, oznacza że się nie ma wiele do powiedzenia

ostatnia część (z trzech) prezentacji to pokaz na żywo - przejście przez główne/ciekawsze ścieżki aplikacji. Recenzenta nie zainteresuje jak się tworzy konta i rejestruje użytkowników ani czy hasło ma wymaganą określoną złożoność. Recenzenta zainteresują główne przypadki użycia, zrobienie wrażenia czymś unikalnym, a nie tym co na pewno w aplikacji musi być. Jeśli jest ryzyko że ta część się nie uda z powodów technicznych, można mieć awaryjnie film ze zrzutem pulpitu, gdzie się klika po aplikacji (nagrany wcześniej na przykład w OBS Studio) i tylko puścić ten film. Film - jeśli ma być, to raczej bez dźwięku, należy samemu na żywo dodać do niego narrację.

jeśli prezentacja jest stacjonarna - należy mieć swój laptop do slajdów i pokazu

jeśli prezentacja jest zdalna - należy być przygotowanym na udostępnienie pulpitu i pokazanie slajdów i pokaz aplikacji zdalnie

Uwagi inne

recenzent jest osobą bardzo techniczną. Może nie znać konkretnej technologii, ale zna zasady projektowania i programowania. Należy unikać mówienia o rzeczach oczywistych, nie tłumaczyć czym jest React czy PHP, bo to wiadomo

recenzent ma obycie, wie jakie rzeczy są trudne a jakie łatwe, próba budowania fałszywego wrażenia że coś było trudne w sytuacji gdy tak nie jest, jest skazana na niepowodzenie

recenzent potrafi korzystać z wyszukiwarki i zadawać jej dobre pytania. Próba powtórzenia czyjejś pracy, sklonowania czyjegoś repozytorium jest oczywiście niedopuszczalna i oznacza bezwarunkową dyskwalifikację pracy

proszę pamiętać że pracę ocenia głównie recenzent i to jego wrażenie jest ważne. Promotor jest tylko doradcą, podpowie czy jaki jest jego zdaniem wkład pracy studenta. Ale z propozycją oceny zwyczajowo wychodzi recenzent.

Praca poprawna, niezawierająca błędów, kompletna, jest zasadniczo wyjściowo oceniana na ocenę dobrą. Ocenę bardzo dobrą dostaje praca, która zdaniem recenzenta wyróżnia się w jakimś aspekcie, należy więc potraktować ewentualną ocenę bardzo dobrą jako wyróżnienie. Ocena dobra oznacza dokładnie tyle ze to jest “dobra” praca, że takie prace chcemy i z przyjemnością czytamy i recenzujemy. Słabsza ocena niż dobra oznacza że były jakieś istotne mankamenty, na przykład zignorowanie którejś z powyższych wskazówek.

---

## Przydatne linki

* Atomic design - https://blog.logrocket.com/atomic-design-react-native/
* Modyfikacja starego commita - https://stackoverflow.com/questions/1186535/how-do-i-modify-a-specific-commit
* shadow - https://ethercreative.github.io/react-native-shadow-generator/
* jak robić stroked text, można to potem zaimplementować - https://stackoverflow.com/questions/38755258/react-native-font-outline-textshadow
* tiled menu easy way (native) - po gthttps://www.npmjs.com/package/react-native-menu-viewer?activeTab=readme

---

## Informacje o projekcie

### Podręcznik
Robimy tylko podrozdział "Znaki Nakazu" (bo jest krótki). Jego rodzicem jest rozdział "Znaki Pionowe" i jego też trzeba zrobić.
Jak starczy czasu to zrobimy też znaki zakazu i informacyjne -- przydatne, żeby pokazać mechanizm strzałek, przenoszących między rozdziałami.

### Projekt na figmie
***https://www.figma.com/file/FNVNOGCFQiLekkb7R3aVA1/Testy-na-prawko?node-id=0-1***

### Struktura katalogów


### Workflow github

* każdy feature na osobnej gałęzi develop
* jeśli to nowy **feature** to nazwa `--develop--nazwa-featura--nick`
* jesli to **bugfix** to nazwa `--bugfix--nazwa-featura--nick`
* jeśli to **refactor** to nazwa `--refactor--nazwa-featura--nick`
* **przykład**: `--develop--basic-navbar--masterdeveloper2137`

### Konwencje kodowe

### Wykorzystane technologie

* React (frontend)
* PostgreSQL (backend)

### Practice/Exam 2.0
Exam:
- Zawiera full review, po wypełnionym egzaminie, design review dostępny na figmie
- Skończone egzaminy lecą do bazy danych (trzymamy max 5-10-15)
- gdy użytkownik chce zobaczyć review egzaminu, to ładujemy go z bazy danych (użytkownik może wybrać konkretny egzamin z menu na swoim koncie)
- odświeżenie strony resetuje egzamin (z db są pobierane nowe pytania i przechowywane lokalnie)

:::warning
Trzeba ogarnąć różnice między logiką review w komponentach Exam i Practice. Może wystarczy dodać kilka ifów, zamiast robić nowy, duży komponent.
:::


Review (full):
- osobna strona, w linku będziemy uwzględniać id zapisanego egzaminu (z db)
- działanie identyczne jak teraz w practice
- dotyczy tylko egzaminu
- **to ta sama strona co exam/practice ale z properties które zmienia zachowanie**

Practice:
- usuwamy tryb review
- odświeżenie podobne jak w examie
- dodajemy tryb live review (wyjaśnienie i wynik dla ostatniego pytania)