Wyniki egzaminu

<script src="jquery-3.5.1.min.js"></script>

Niepoprawna odpowiedź. W kontekście załączonego kodu HTML należy zauważyć, że jego celem jest przede wszystkim załadowanie lokalnej kopii zewnętrznej biblioteki JavaScript, w tym przypadku jQuery. Koncepcja umieszczania kodu JavaScript pomiędzy znacznikami script dotyczy innego sposobu osadzania kodu, gdzie kod JavaScript jest bezpośrednio wpisywany pomiędzy te znaczniki, a nie poprzez atrybut src. Taki sposób jest często używany dla krótkich skryptów lub gdy nie korzystamy z zewnętrznych bibliotek. Pobieranie z Internetu w momencie odsłony strony i zastosowanie biblioteki jQuery wymagałoby wskazania zewnętrznego adresu URL w atrybucie src, co nie ma miejsca w przypadku lokalnie zapisanych plików. Wskazywanie na adres URL pozwala na dynamiczne ładowanie bibliotek z zewnętrznych serwerów, co jest powszechną praktyką dla bibliotek o szerokim zastosowaniu, takich jak jQuery, jednak w tym pytaniu mowa jest o pliku lokalnym. Deklarowanie własnej funkcji JavaScript o nazwie min.js jest nieporozumieniem. min.js zwykle wskazuje na zminifikowaną wersję skryptu, co oznacza zoptymalizowaną pod kątem rozmiaru wersję biblioteki, a nie nazwę funkcji. Rodzi to błędne przekonanie co do znaczenia struktury nazw w kontekście plików JavaScript i ich stosowania. Ważne jest, aby rozróżniać lokalne i zdalne metody załadowania zasobów i zrozumieć kiedy i dlaczego każda z nich jest stosowana w praktyce projektowej.

Niepoprawna odpowiedź. Wiele osób zaczyna od skojarzenia tego symbolu z prawami autorskimi, Creative Commons albo prawem cytatu, jednak to prowadzi na manowce. Po pierwsze, standardowy symbol praw autorskich to samo „C” w kółku, bez przekreślenia – i on oznacza, że utwór jest objęty ochroną z mocy prawa i wszelkie wykorzystanie wymaga zgody twórcy lub spełnienia warunków ustawowych wyjątków. Natomiast tutaj mamy przekreślone „C”, co jednoznacznie sugeruje brak ochrony. Creative Commons to zupełnie inny zestaw symboli, z typowymi oznaczeniami: CC i różnymi dodatkami jak BY, SA, NC, ND, które precyzują warunki korzystania z utworu. Te licencje nadal wprowadzają ograniczenia, chociaż są dużo bardziej elastyczne niż klasyczne prawa autorskie – ale nigdy nie oznaczają całkowitego braku praw. Prawo cytatu z kolei to wyjątek w ustawie o prawie autorskim, który pozwala na ograniczone wykorzystywanie fragmentów cudzych utworów w określonych sytuacjach, ale nie oznacza, że cały utwór można wykorzystywać dowolnie i bez ograniczeń. Typowy błąd polega na utożsamianiu każdego oznaczenia związanych z literą C z szeroko rozumianą „wolnością” korzystania – a to nieprawda. Domena publiczna jest zupełnie oddzielną kategorią, gdzie utwór jest trwale wyjęty spod ochrony prawnej i można go używać naprawdę dowolnie. W praktyce, nieznajomość tych niuansów może prowadzić do błędów prawnych, np. nieświadomego naruszenia czyichś praw, albo niewłaściwego oznaczenia własnej pracy. W środowisku profesjonalnym bardzo ważne jest właśnie rozróżnianie tych pojęć i symboli – to wpływa na bezpieczeństwo prawne projektów i buduje zaufanie do twórcy.

Niepoprawna odpowiedź. Pozostałe odpowiedzi są zadaniami, które w większości przypadków mogą być realizowane indywidualnie, co czyni je zadaniami jednostkowymi. Implementacja funkcji dodajZdjecie() dotyczy konkretnego aspektu programistycznego, który może być wykonany przez jednego dewelopera. Wymaga ona znajomości języka programowania oraz logiki potrzebnej do dodawania zdjęć do galerii, co zazwyczaj nie wymaga współpracy z innymi członkami zespołu. Przygotowanie i skonfigurowanie repozytorium dla projektu natomiast to techniczny proces, który również najczęściej realizuje jedna osoba, odpowiedzialna za ustawienie środowiska pracy. Tworzenie testu jednostkowego dla funkcji przegladajZdjecia() to kolejny krok, który można wykonać samodzielnie, koncentrując się na testowaniu konkretnej funkcji w izolacji, bez potrzeby angażowania innych programistów. W przypadku tych zadań, choć mogą one być częścią większego projektu, to ich realizacja nie wymaga współpracy zespołowej, co sprawia, że nie są to zadania zespołowe.

function Heading(props) {
    return (
        <h1> {props.title} </h1>
    );
}

return (
    <Heading title="Egzamin zawodowy" />
);

import {Component} from '@angular/core';
@Component({
    selector: 'app-heading',
    templateUrl: './heading.component.html',
    styleUrls: ['./heading.component.css']
})

export class HeadingComponent {
    title:String = "Egzamin zawodowy";
    ...
}

<h1>{{title}}</h1>

Niepoprawna odpowiedź. Zdarza się, że łatwo pomylić różne sposoby prezentacji tekstu na stronie, zwłaszcza gdy ma się do czynienia z wieloma frameworkami naraz. W przedstawionych fragmentach kodu zarówno w React, jak i w Angularze, kluczowe jest użycie tagu <h1>, czyli nagłówka pierwszego poziomu. Jeżeli uznałeś, że zostanie wyświetlony tekst w akapicie, to być może zasugerowałeś się inną składnią, bo <p> w kodzie w ogóle nie ma. Możliwe też, że patrząc na słowo „title”, pojawiła się skojarzenie z atrybutem title w HTML (który odpowiada za tzw. tooltip po najechaniu kursorem lub tytuł strony), ale w tym przypadku title to po prostu nazwa właściwości przekazywanej do komponentu lub pola w klasie, nie specjalny atrybut HTML. Kolejna zmyłka, nadawanie tytułu wszystkim elementom HTML – brzmi jak coś, co można by zrobić globalnie stylem, ale tutaj nic takiego się nie dzieje. W kodzie nie występuje żaden mechanizm, który iteruje po wszystkich elementach i ustawia im atrybut, to nie jest ten przypadek. Jeśli chodzi o tytuł strony, to w przeglądarce jest on definiowany przez <title> w sekcji <head> dokumentu HTML, a tutaj pracujemy tylko z zawartością renderowaną w widocznym DOM, nie konfigurujemy meta-danych strony. To częsty błąd – mylić zmienne używane w kodzie z atrybutami HTML o tej samej nazwie. Warto pamiętać, że w React i Angularze komponowanie widoków opiera się głównie o manipulację treścią w obrębie renderowanego drzewa DOM, a nie bezpośrednią modyfikację atrybutów meta czy stylów całego dokumentu. Dobrze jest też zawsze spojrzeć na strukturę znacznika – gdy widać <h1>, od razu powinno się zakładać, że chodzi o nagłówek – i, szczerze mówiąc, takie pytania świetnie pokazują, jak ważne jest rozumienie, co faktycznie renderuje się na stronie, bo czasem pozorne podobieństwo nazw prowadzi do błędnych wniosków.

Niepoprawna odpowiedź. Wbudowany debugger w IDE jest całkiem pomocny, zwłaszcza w debugowaniu, ale czasami może nie zauważać błędów, które wybuchają później, jak działasz w przeglądarce. Narzędzia serwerowe są bardziej nastawione na błędy backendu, a więc nie pomogą, gdy zamierzasz analizować, co się dzieje w frontendzie. No i tak, JavaScript jest interpretowany, nie kompilowany, więc nie ma tradycyjnego kompilatora.

Niepoprawna odpowiedź. Często można się pomylić, sądząc, że narzędzia do projektowania interfejsów użytkownika generują od razu kod w takich językach jak Java czy implementują obsługę konkretnych zdarzeń, np. wciśnięcia przycisku. Z mojego doświadczenia wynika, że to jeden z najczęstszych błędów myślowych na początku nauki programowania. W praktyce, narzędzia typu drag&drop koncentrują się na warstwie prezentacyjnej – opisują, jak mają wyglądać poszczególne elementy, ale nie zajmują się logiką działania. Kod Java albo inny kod źródłowy odpowiedzialny za obsługę zdarzeń czy funkcjonalności aplikacji musi być dopisany ręcznie przez programistę. Automatyczne generowanie kodu logicznego przez edytory graficzne jest raczej niezalecane, bo prowadzi do trudnego w utrzymaniu kodu i sprawia, że aplikacja traci na przejrzystości. Jeśli chodzi o obsługę wciśnięcia przycisku czy przycisku ekranu dotykowego, to są to akcje, które definiuje się później w kodzie źródłowym – na przykład poprzez implementację listenerów w kodzie Java w Androidzie albo przez bindingi w innych frameworkach. Te narzędzia mają za zadanie generować opis struktury interfejsu, a nie jego zachowanie. Często spotyka się też przekonanie, że to właśnie kod Java stanowi podstawę aplikacji – oczywiście to prawda, ale nie w kontekście automatycznego generowania przez narzędzia graficzne; one skupiają się na XML, który jest dużo bardziej uniwersalny do takich celów. Moim zdaniem najlepszą praktyką jest wyraźne oddzielenie warstwy prezentacji (np. XML) od logiki biznesowej i ręcznego kodowania zdarzeń, bo to pozwala na wygodne rozwijanie i utrzymywanie aplikacji, szczególnie w większych zespołach.

console.log(0.1 + 0.2 === 0.3);
console.log(0.1 + 0.2);

Niepoprawna odpowiedź. Niepoprawne odpowiedzi wynikają z nieporozumienia dotyczącego reprezentacji liczb zmiennoprzecinkowych w JavaScript. Wiele osób ma tendencję do sądzenia, że operacje matematyczne z użyciem liczb dziesiętnych będą prowadziły do oczekiwanych rezultatów. Przykład `0.1 + 0.2`, który wydaje się prosty, w rzeczywistości ujawnia istotne różnice w precyzji. W przeciwieństwie do liczb całkowitych, które są reprezentowane jednoznacznie, liczby zmiennoprzecinkowe mogą wprowadzać błędy zaokrągleń. Gdyby nasze porównanie zwracało `true`, wskazywałoby to na to, że na poziomie binarnym liczby te są identyczne, co jest w przypadku JavaScript nieprawdziwe. Z kolei podanie `0.3` jako wyniku sumy w niektórych odpowiedziach nie uwzględnia tej samej zasady, co sugeruje, że porównanie tych wartości jest właściwe, mimo że nie jest. Warto zrozumieć, że takie błędne wnioski mogą prowadzić do poważnych problemów w bardziej złożonych obliczeniach, zwłaszcza w aplikacjach finansowych, gdzie precyzja jest niezbędna. Dobrym zwyczajem jest korzystanie z odpowiednich metod, które pozwalają na bezpieczne porównywanie wartości zmiennoprzecinkowych, minimalizując ryzyko błędów. Stosując podejście oparte na tolerancji błędu, można uniknąć pułapek związanych z reprezentacją liczb i poprawić dokładność obliczeń.