Wyniki egzaminu

Niepoprawna odpowiedź. Zdalne wykonywanie aplikacji na urządzeniu klienta oznacza model przetwarzania lokalnego, co nie jest główną cechą architektury klient-serwer. Brak podziału na funkcje klienta i serwera narusza podstawową ideę tego modelu, który zakłada rozdzielenie ról pomiędzy te dwie jednostki. Wyłącznie komunikacja synchroniczna ogranicza elastyczność aplikacji i może prowadzić do opóźnień w przetwarzaniu danych.

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ń.

Niepoprawna odpowiedź. Przy przekształcaniu wartości szesnastkowych RGB na system dziesiętny łatwo popełnić błąd, bo wystarczy źle podstawić którąś cyfrę albo zmieszać kolejność. W przypadku koloru #AA41FF każda para znaków odpowiada jednej składowej: AA to czerwona, 41 to zielona, a FF to niebieska. Najczęściej błędy pojawiają się, gdy niepoprawnie zinterpretujemy cyfry szesnastkowe jako dziesiętne lub po prostu pomylimy kolejność składowych. Przykładowo, '160' w odpowiedzi zamiast '170' wynika być może z błędnego odczytania AA – bo łatwo pomylić literę A (10) z cyfrą 6 czy 0, zwłaszcza jeśli ktoś nie jest przyzwyczajony do liczb szesnastkowych. Podobnie, '64' zamiast '65' dla 41 to typowy efekt nieuwagi w liczeniu: 4*16+1 daje 65, a nie 64, co pokazuje, jak ważna jest precyzja w prostych działaniach matematycznych. Z kolei zamiana AA na 160 może świadczyć o mechanicznej zamianie liter na liczby bez uwzględnienia ich pozycji w zapisie szesnastkowym. Powszechnym błędem jest też zamiana kolejności składowych lub skupianie się tylko na końcowych cyfrach, przez co mylnie przyjmuje się, że na przykład AA to 160, bo pierwsza cyfra to 1, a nie 10. W praktyce branżowej takie niedokładności prowadzą do złych efektów wizualnych – np. kolor na stronie mocno różni się od zamierzonego lub nie pasuje do reszty projektu. Moim zdaniem takie błędy wynikają zwykle z braku nawyków w przeliczaniu systemów liczbowych. Warto zawsze pamiętać, że każda cyfra szesnastkowa ma swoją wagę, a zamiana wymaga precyzyjnego policzenia: pierwsza cyfra razy 16 plus druga cyfra. W codziennej pracy z grafiką cyfrową czy webdesignem taka pomyłka bardzo rzuca się potem w oczy użytkownikowi, więc lepiej od początku ćwiczyć dokładność niż potem szukać, gdzie zniknęła ta właściwa barwa.

Niepoprawna odpowiedź. Lista pozwala na dodawanie powtarzających się elementów, więc nie daje ci unikalności. Tablica działa podobnie, bo też trzyma duplikaty, bez jakiegoś mechanizmu, który by je automatycznie usuwał. Kolejka priorytetowa przechowuje rzeczy według określonej kolejności, ale tu znowu nie jest mowa o unikalności. Każda z tych struktur ma swoje zadania, ale żadna nie jest tak dobra jak zbiór, jeśli chodzi o trzymanie unikalnych danych. Dziwne, nie?

Niepoprawna odpowiedź. XCode to zintegrowane środowisko programistyczne stworzone przez Apple, które służy głównie do tworzenia aplikacji na platformy iOS oraz macOS. Jego użycie ogranicza się do systemów operacyjnych Apple, co wyklucza możliwość tworzenia aplikacji cross-platform. W kontekście programowania w C#, XCode nie oferuje wsparcia ani funkcji, które umożliwiałyby rozwój aplikacji mobilnych na różne platformy. React Native jest frameworkiem stworzonym przez Facebook, który umożliwia tworzenie aplikacji mobilnych w JavaScript, a nie w C#. Choć React Native wspiera wiele platform, to jednak nie jest to technologia zgodna z C#, co czyni ją nieodpowiednią dla deweloperów preferujących ten język. Android Studio to z kolei oficjalne IDE dla systemu Android, oparte na Javie oraz Kotlinie, co również eliminuje możliwość wykorzystania C#. Tak więc, ani XCode, ani React Native, ani Android Studio nie są odpowiednie do tworzenia aplikacji mobilnych w języku C#, co czyni je niepoprawnymi odpowiedziami w kontekście tego pytania.

Niepoprawna odpowiedź. Sortowanie bąbelkowe jest jednym z najwolniejszych algorytmów i rzadko jest używane w praktyce ze względu na złożoność O(n^2). Sortowanie kubełkowe może być szybkie, ale jego efektywność zależy od równomiernego rozkładu danych. Sortowanie przez scalanie jest bardziej uniwersalne, ale ma większą złożoność obliczeniową niż Counting Sort i może być mniej efektywne dla dużych zbiorów danych o ograniczonym zakresie.

Niepoprawna odpowiedź. W tym zadaniu łatwo pomylić pojęcia, bo kilka odpowiedzi brzmi podobnie technicznie, ale opisują zupełnie inne zachowanie. Stos działa według zasady LIFO, czyli Last In, First Out. Oznacza to, że element dodany jako ostatni jest zdejmowany jako pierwszy. Gdyby bufor drukowania działał jak stos, to najnowszy dokument byłby drukowany przed starszymi. W praktyce byłoby to dość kiepskie i niesprawiedliwe, bo starsze zadania mogłyby czekać bardzo długo, a nawet zostać ciągle spychane przez nowsze dokumenty. Z mojego doświadczenia uczniowie często kojarzą dodawanie na koniec z operacją push na stosie, ale zapominają, że kluczowe jest też to, skąd element jest później pobierany.

Sterta też nie jest właściwym wyborem dla zwykłego bufora drukowania. Heap służy głównie do sprawnego wybierania elementu o największym albo najmniejszym priorytecie, na przykład w kolejce priorytetowej. To ma sens, gdy zadania mają priorytety, terminy lub koszty, ale w treści pytania nie ma nic o priorytetach. Jest za to wyraźnie powiedziane, że najstarsze zadanie ma iść do wydruku. LIFO jako sama zasada również odpada, bo jest przeciwieństwem oczekiwanego zachowania. Poprawne myślenie jest takie: skoro pierwszy dokument, który trafił do bufora, ma być pierwszy obsłużony, to potrzebujemy kolejki FIFO. W profesjonalnych systemach taki wybór daje przewidywalność, prostszą diagnostykę i zachowanie zgodne z intuicją użytkownika.

Niepoprawna odpowiedź. Wydaje mi się, że często początkujący mają problem z rozróżnieniem między polami, metodami a funkcjami, szczególnie że w niektórych językach te pojęcia się trochę mieszają. Funkcje i metody służą do wykonywania operacji – czyli do działania, modyfikowania czegoś, wyliczania, a nie do przechowywania danych. Jeśli próbujesz zrobić z ‘marka’ czy ‘rocznik’ funkcję lub metodę, tracisz całą strukturę danych, bo te wartości powinny być częścią obiektu – czyli być przechowywane jako pola. Interfejsy to zupełnie inna bajka – one opisują, co klasa powinna potrafić (czyli jakie metody ma mieć), ale same nie przechowują żadnych danych. To tak jakbyś powiedział, że samochód jest instrukcją obsługi, a nie fizycznym przedmiotem z konkretnymi atrybutami. Typowym błędem jest też mylenie pojęcia 'parametry' jako argumentów funkcji – tutaj chodzi o właściwości opisujące obiekt, więc nie pasuje to do funkcji ani metod. Dopiero po zrozumieniu, że pola są miejscem przechowywania stanu obiektu, można dobrze zaprojektować klasę oddającą realny obiekt z rzeczywistości. W praktyce, złe przypisanie atrybutów do funkcji czy interfejsów skutkuje chaosem w kodzie, trudnościami w utrzymaniu aplikacji oraz problemami z rozwojem projektu. Pola są po prostu fundamentem do budowania logiki obiektowej i każda próba ich zastąpienia innymi mechanizmami rodzi niepotrzebne komplikacje.

Niepoprawna odpowiedź. Wielu ludzi myśli, że normalizacja zmniejsza liczbę dostępnych produktów, ale to nie tak. W rzeczywistości standardy sprawiają, że pojawia się jeszcze więcej różnych produktów, które spełniają określone normy. A ten pomysł, że pozbywanie się kontroli jakości to coś dobrego, to chyba jakieś nieporozumienie – normalizacja wcale nie zastępuje kontroli jakości, ona ją raczej wspiera. I nie ma co mówić, że innowacji technologicznych jest mniej przez normalizację – wręcz przeciwnie, standardy dają solidny podstawy do tego, żeby rozwijać nowe technologie i produkty, które odpowiadają potrzebom rynku.

class MojaKlasa
{
    private static int licznik;
    ...

Niepoprawna odpowiedź. Warto się chwilę zatrzymać i przeanalizować, skąd biorą się błędne przekonania dotyczące pól statycznych. Bardzo częstym nieporozumieniem jest utożsamianie słowa static z czymś „niezmiennym” albo uniemożliwiającym modyfikacje. Tymczasem static oznacza tyle, że pole nie jest związane z pojedynczym obiektem, tylko z całą klasą – czyli wszystkie obiekty tej klasy dzielą jedną, wspólną wartość licznik. To nie jest tak, że static czyni pole stałym – żeby pole było niezmienne, potrzeba słowa kluczowego final (w Javie), a tutaj go ewidentnie nie ma. Często osoby początkujące mylą static z final i stąd pojawia się przekonanie, że pole nie może być modyfikowane – co nie jest prawdą. Równie błędne jest zakładanie, że każde pole, które nie jest static, jest automatycznie unikalne per instancja. Gdybyśmy usunęli static z definicji licznik, wtedy rzeczywiście każda instancja MojaKlasa miałaby swoją własną wersję tej zmiennej, ale w tym przypadku wszystkie obiekty współdzielą tę samą wartość. Jeszcze inny błąd to przekonanie, że pole prywatne (private) nie może być zmieniane w kodzie klasy – w rzeczywistości private ogranicza dostęp do pola tylko do wnętrza klasy, ale metody tej klasy mają pełne prawo je modyfikować. Tak więc, patrząc z perspektywy dobrych praktyk programistycznych i samej składni, static to po prostu cecha, która decyduje o zakresie współdzielenia pola pomiędzy instancjami, a nie o jego niezmienności czy widoczności na zewnątrz. Moim zdaniem kluczowe jest wyciągnięcie z tego wniosku, że static to współdzielenie, a nie blokada zmian – i na tym polega istota poprawnej odpowiedzi w tym pytaniu.

Niepoprawna odpowiedź. Odpowiedzi 1000, 2048 i 512 są błędne z różnych powodów. Zaczynając od 1000 – często spotykana w reklamach, zwłaszcza w kontekście dysków twardych, odnosi się do systemu dziesiętnego, gdzie 1 TB to 1 000 GB. Ale w informatyce to tak nie działa, bo 1 TB to 1024 GB, co może nieco mylić. Odpowiedź 2048 to też nie to, bo tu mamy do czynienia z pomyleniem jednostek – 2048 wynika z 2^11 i nie pasuje do terabajtów i gigabajtów. Na koniec, 512, to w ogóle nie gra, bo 512 MB to tylko 0,5 GB, co w porównaniu do 1 TB jest po prostu za małe. Dlatego warto ogarnąć te różnice między systemami binarnym i dziesiętnym, żeby dobrze wiedzieć, jak przeliczać jednostki pamięci.

Niepoprawna odpowiedź. Projektowanie bez wcześniejszej specyfikacji technicznej prowadzi do chaosu i zwiększa ryzyko błędów na późniejszych etapach rozwoju. Pisanie kodu bez dokumentacji utrudnia jego późniejsze utrzymanie i sprawia, że inne osoby w zespole mogą mieć trudności z rozumieniem funkcjonalności. Skupienie się wyłącznie na wyglądzie aplikacji pomija kluczowe aspekty jej funkcjonalności i nie pozwala na dostosowanie systemu do zmieniających się potrzeb użytkowników.