Wpadki i wypadki #6

Dawno już nie było Wpadek i wypadków, więc najwyższa pora wrzucić kilka pchełek zebranych od ostatniego razu.

• Na początek smaczek związany z CEIDG. Pewien mój znajomy był zmuszony wypełnić jeden z wniosków online dostępnych na stronie. Ohoczo przystąpił do działania, po czym okazało się, że… musi bawić się w inspektorze elementów, gdyż walidacja formularzy nie była zbyt wyszukana.

  Oczywiście, jako dobry developer, po zabawie z formularzem napisał do supportu, by poinformować o istniejącym błędzie. Trzeba przyznać, że odpowiedź jest dość zaskakująca:

  […] Proszę zatem o zmianę języka przeglądarki na polski. Po wyborze języka polskiego problem powinien ustąpić. Proszę o weryfikację. […]

  Oczywiście nie było to rozwiązanie działające. Niemniej, nawet gdyby się takim okazało, to wina i tak leży po stronie aplikacji. Przygotowanie porządnego systemu walidacji nie jest zadaniem trywialnym, więc mogą się w nim zdarzyć błędy. Jednak warto ostro takie rozwiązania testować i czasami wręcz specjalnie przyzwalać na wpisywanie nie do końca poprawnych danych (bo np. – choć w teorii nie ma prawa się to zdarzyć – ktoś ma PESEL niezgodny z systemem).

• Drugi smaczek związany jest z programem Megapanel PBI/Gemius. Wziąłem se kilka miesięcy temu udział w tym badaniu – tak dla rozrywki. Pierwszy etap polegał na wypełnieniu prostej ankiety, więc tutaj żadnych problemów nie było. Niemniej na drugim etapie pojawił się problem – jeden, ale za to uniemożliwiający mi dalszy udział w badaniu. Poproszono mnie bowiem o zainstalowanie prostego programu, który będzie monitorował moją aktywność w Sieci. Szkoda tylko, że jedyna wersja jest na Windowsa, a ja siedzę na Linuksie i jakoś nie mam ochoty babrać się z wine. Machnąłem zatem ręką na to i zapomniałem o sprawie.

  Kilka dni temu dostałem maila, że mój komputer nie wysyła im żadnych danych (no patrzcie państwo…) i że naprawdę chcą, bym znów uczestniczył w badaniu. Ba, nawet konkurs jest – wystarczy zainstalować ten program. Z racji tego, że program dalej dostępny jest tylko dla użytkowników Windowsa, napisałem mail z pytaniem, czy istnieje wersja dla innych systemów. Odpowiedź była odrobinę zaskakująca:

  […] Pragniemy poinformować, że program netPanel zbiera dane jedynie od użytkowników systemu Windows, ponieważ stanowią oni 95% użytkowników polskiego internetu.

  Jeśli jednak korzysta Pan chociaż czasem z systemu operacyjnego Windows, to zachęcamy Pana do kontynuacji uczestnictwa w badaniu.

  Niestety aktualnie nie mamy w planach stworzenia wersji programu netPanel współpracującej z innymi systemami operacyjnymi, chociaż niewykluczone, że w przyszłości taka wersja powstanie. […]

  Owszem, 5% nie jest jakoś szczególnie istotne ze statystycznego punktu widzenia, niemniej tego typu podejście mnie dziwi. Zwłaszcza, że obecnie tworzenie crossplatformowych aplikacji jest bardzo ułatwione, dzięki takim wynalazkom, jak nw.js czy Electron.js. Ba, jeśli mówimy o narzędziu monitorującym ruch sieciowy, to przecież można też wykorzystać w tym celu dodatki do przeglądarek – nie przechwycą co prawda całego ruchu, ale najbardziej interesujące nas rzeczy (odwiedzane strony wraz z czasem odwiedzin) mielibyśmy podane na tacy.

  No i nie mogę wygrać iPada nano…

• Dzisiaj oberwie się także WP.pl, za niepoprawne kodowanie znaków w komunikacie o cookies.

• A teraz gwóźdź programu: zadanie rekrutacyjne Ideamotiv na junior frontend developera. Rekrutacja skończyła się dość dawno temu, więc pojawiło się już oficjalne rozwiązanie. Problem polega na tym, że nie jest najlepsze i cierpi na kilka problemów:

  • Plik JS ma inne formatowanie niż plik CSS (2 spacje vs 4 spacje). Ba, formatowanie nie jest spójne nawet w obrębie jednego pliku (wystarczy popatrzeć na stosowanie klamerek w pliku CSS).
  • Kod JS jest mocno przeinżynierowany – zwłaszcza równoczesne zastosowanie biblioteki underscore do rzeczy, którą jQuery ma wbudowaną. Linijki 3-11 można spokojnie zamienić na pobranie zaznaczonych pól i jeden warunek z odpowiednio napisanym selektorem, np. :not([value=dark_side]):checked.
  • Obecny kod obsługujący odtwarzanie dźwięku jest bardzo kulawy, bo kilkukrotne wciśnięcie przycisku formularza powoduje rozpoczęcie kilkukrotnego odtworzenia marszu. Tym samym jesteśmy raczeni po prostu nieznośną kakofonią. A wystarczy plik z muzyką wczytać raz i później po prostu operować na nim, zerując czas odtwarzania.
  • Selektory w pliku CSS są całkowicie nieefektywne. Zasada kciuka głosi, że selektory zawierające więcej niż dwa elementy są złe. Nie po to stworzono metodologie, takie jak BEM, żeby straszyć setkami poziomów zagłębień w selektorach. Gdy uzmysłowi się sobie, że przeglądarki czytają selektory od prawej do lewej, wówczas łatwo dojść do wniosku, że im mniej poziomów do przetrawienia, tym wydajniej. Jeszcze inny problem – być może nawet ważniejszy – to absurdalnie wysoka specyficzność tych selektorów. I znów BEM się kłania.
  • Skoro rozwiązanie ma działać tylko w najnowszym Chrome, to warto zwrócić uwagę także na jeszcze inną rzecz: składnia CSS rozróżnia pseudoklasy (np. :hover, :active) od pseudoelementów (np. ::before, ::after) po ilości dwukropków. Warto o tym pamiętać.

  Inna rzecz, że kod HTML, na którym zadanie miało zostać wykonane, sam w sobie również wymaga poprawek – ale to już pozostawię jako zadanie domowe dla moich wytrwałych czytelników. Od siebie przygotowałem lekko poprawioną wersję oficjalnego rozwiązania, która naprawia w/w problemy.

  Jeszcze jedna rzecz mnie frapuje: czemu to zadanie jest tak łatwe? Wydawało mi się, że junior powinien mieć ciut większą wiedzę na temat CSS i JS… Tutaj nawet nie trzeba zbytnio się wysilać – można de facto skleić gotowca z ogólnie dostępnych materiałów (i prawdopodobnie uzyskać efekt lepszy od oficjalnego rozwiązania!). Raczej nie tak powinien wyglądać webdev.

Tyle mojego marudzenia na dzisiaj. Widzę, że udaje mi się popełniać tekst średnio raz w miesiącu, więc… do przeczytania pod koniec lutego!