Znów o testach jednostkowych

Poprzednia notka o “rootkitach i innych nieszczęściach” zdołała utrzymać się długo, więc mogła stworzyć wrażenie, że cały czas źle się u mnie dzieje :) Nieprawda to oczywiście, więc wypadałoby w końcu coś na tę dezinformację poradzić.
Ostatnio cierpię na niewielki brak czasu spowodowany koniecznością dokładania nieco poważniejszych wysiłków co do pewnego dzieła, które docelowo ma zapewnić mi otrzymanie tytułu inżyniera informatyki. Z pewnych względów nie zdradzę, czym ono jest, ale pozwolę sobie wspomnieć o pewnych wnioskach, które przy okazji mi się nasunęły.

Parę miesięcy temu wypowiadałem się pochlebnie na temat testów jednostkowych, mając wtedy raczej niezbyt duże doświadczenie w ich stosowaniu. Dzisiaj jest już ono zdecydowanie większe i w związku z tym stwierdzić muszę, że… Nie, nie chcę powiedzieć, że wtedy myliłem się całkowicie ;P Chodzi raczej o równowagę zalet i wad.
To prawda, że unittesty dobrze sprawdzają się jako narzędzie znajdowania błędów i zapobiegania im. Do pewnego stopnia pomagają też w poprawianiu interfejsu tworzonych klas, tak aby ich użycie było wygodniejsze i bardziej intuicyjne. Te korzyści mają jednak swoją cenę, którą jest przede wszystkim czas poświęcony na pisanie owych testów – zwłaszcza w niektórych metodykach wytwarzania oprogramowania, które kładą na nie ogromny nacisk. Całkiem normalna jest bowiem sytuacja, że kod testowy jest dłuższy niż testowany (czasem nawet kilkakrotnie). Dodatkowo nie mamy przecież znikąd żadnej gwarancji, że ów testowy kod sam nie zawiera jakichś błędów… W sumie więc dochodzi nam sporo dodatkowej pracy w zamian za większą niezawodność tworzonego oprogramowania.
Drugi wniosek jest bardziej – że tak powiem – filozoficzny :) Otóż programowanie wedle zasady:

może i jest efektywne, ale na dłuższą metę zaczyna się robić nużące i trochę zniechęcające. Pomyślmy jak łatwo jest pisać kod “rozgrzebany”, którego nie planujemy od razu kompilować i poprawiać tych wszystkich pomyłek, których kompilator nam zasygnalizuje. Porównajmy to z pisaniem kodu, który nie tylko jak najczęściej kompilujemy, ale i regularnie przepuszczamy przez własnoręcznie napisane testy! Toż to straszne, tak samemu kręcić na siebie bat :) Gdzie tu koderska wolność artystyczna? :D
Ale nie ma rady, czasami trzeba zakasać rękawy i testować…

Rootkity i inne nieszczęścia

Jedną z rzeczy, którą musiałem wykonać w trakcie (tymczasowej) przesiadki na komputer stacjonarny, było dogłębne sprawdzenie go programem antywirusowym – co “z pewnych względów” nie było czynione przez dobrych kilka miesięcy :) Skan nie wykrył aczkolwiek w zasadzie nic bardziej niebezpiecznego niż typowe ‘śledzące ciasteczka’ (tracking cookie). Dopiero później zaczęło się robić ciekawie.
Zło (i to przez duże Z) zostało bowiem wkrótce wykryte przez skaner działający w tle, który zidentyfikował je heurystycznie jako rootkit i oprócz tej informacji nie powiedział zresztą nic więcej. Przyznam, że było to moje pierwsze zetknięcie z tego typu szkodnikami, więc tym bardziej energicznie zabrałem się do rozwiązywania problemu – zwłaszcza że ze wszystkich typów złośliwego oprogramowania to właśnie rootkity sa zdecydowanie najgroźniejsze.
Na szczęście ten okazał się dość znanym i nawet nieszczególnie niebezpiecznym drobnoustrojem, przenoszącym się – o dziwo – nie przez sieć, lecz przez dyski wymienne. Zapewne dlatego też moje kilkugodzinne starcie z przeciwnikiem zakończyło się (prawdopodobnie) sukcesem, zaś wnioski z tego są następujące:

• Antywirusy nie radzą sobie z rootkitami i zwykle potrafią jedynie zasygnalizować, że w systemie “coś siedzi”. Do wykrywania rootkitów istnieją dedykowane programy, których najlepiej jest używać grupowo, a i tak pozytywnym wynikom nie należy do końca ufać.
• Google pomaga :) Jedną z dobrych metod identyfikacji niechcianych programów jest bowiem przejrzenie listy procesów (stworzonej przez narzędzie w rodzaju IceSword) i kolejne sprawdzenie wszystkich potencjalnie podejrzanych pozycji poprzez wyszukanie informacji na ich temat w Internecie.
• Najbardziej znanym narzędziem do usuwania rootkitów jest ComboFix, który pomógł zresztą w moim przypadku. W ogólności jednak naprawa może być niemożliwa. Tak naprawdę zaleca się zresztą, by po wykryciu rootkita poważnie zastanowić nad sformatowaniem dysku i odbudową systemu od podstaw. Brr :)

Krótko mówiąc, wykrywanie i walka z tym rodzajem szkodliwego oprogramowania to coś znacznie poważniejszego niż wciśnięcie przycisku Scan i czekanie na wyniki :] Rezultaty też nigdy nie są pewne.

O reinstalacji systemu na komputerze stacjonarnym trzeba więc będzie pomyśleć jak najszybciej, a od wczoraj stało się to prostsze, gdyż mój laptop wrócił z naprawy. Okazało się, że konieczna była wymiana płyty głównej (!) – oryginalna prawdopodobnie miała fabryczną usterkę… No cóż, dobrą stroną jest to, że za tę skomplikowaną operację nie musiałem zapłacić ani grosza; niech żyją gwarancje :)

Coś się zepsuło

No to wykrakałem… Niecały rok temu pozwoliłem sobie ironizować na temat dziwnych przypadków dotykających komputery w Ministerstwie Sprawiedliwości, a teraz przytrafiło mi się coś w pewnym stopniu podobnego. No, może nie do końca – wprawdzie na pierwszy rzut oka mój przenośny komputer nadal wydaje się cały, ale trudno go nazwać działającym. Pewnego razu parę dni temu po prostu bardzo ładnie się zwiesił, zaś po sprzętowym restarcie nie okazuje żadnych znaków życia poza migającą kontrolką zasilania.
Na szczęście istnieją jeszcze serwisy gwarancyjne, które teoretycznie potrafią uporać się z każdą naprawą w średnio dwa tygodnie. Cokolwiek się więc zepsuło (strzelam w przegrzanie karty graficznej lub procesora), powinno zostać naprawione w jakimś rozsądnym czasie. A zanim tak się stanie, muszę przeprosić się z nieco zaniedbanym komputerem stacjonarnym :)

Jeszcze jeden nowy rok

I znów całkiem długie wakacje się skończyły, więc chcąc nie chcąc trzeba wrócić z powrotem ‘do szkoły’ ;] Ponieważ jednak w tym przypadku mówimy tu o studiach, i to już na czwartym roku, to tragizm tego wydarzenia nie jest znowu aż tak wielki ;) W tym semestrze główną atrakcją jest oczywiście praca inżynierska, której to pisanie ostatecznie mnie nie ominie.

Jednym słowem, oto znów zaczyna się kolejny studencki rok :)

Prawie jak DirectX

Przedwczoraj w końcu udało mi się skończyć pewien “drobny” projekt, który – pomimo tego że był ściśle związany z programowaniem grafiki – nie należał wcale do lekkich, łatwych i przyjemnych. To pewnie dlatego, że chodzi tu o software’owy renderer, który (na)pisałem w Javie (!) jako projekt uczelniany. Niewykluczone, że niektórzy pamiętają jeszcze, o co chodzi ;-)
W wymaganiach przewidziana była na szczęście tylko jedna, za to konkretna scena – mianowicie pewien znany skądinąd most. W porównaniu z oryginałem nie wyszedł on może specjalnie imponująco, ale nie zapominajmy, że każdy z jego pikseli musiał zostać pieczołowicie wyliczony przez biedny procesor ;) Rezultaty prezentują się zaś następująco:

I wprawdzie tego nie widać, ale manipulowanie tą sceną (złożoną z kilkuset trójkątów) mogło się odbywać w sposób całkiem płynny – o ile oczywiście powiększenie nie było zbyt duże :) Tym niemniej nie wróżę jednak temu rozwiązaniu zbyt wielu praktycznych zastosowań. Co oczywiście ani na jotę nie zmienia faktu, że jego implementacja okazała się całkiem pouczająca. Jednym z praktycznych wniosków jest chociażby to, że modelowanie za pomocą ręcznego opisywania sceny we własnym formacie opartym na XML to zdecydowanie nie jest dobry pomysł ;]

Interesujące puzzle

Jedna z figur

Do wielu produktów dołącza się teraz różnego rodzaju dodatki, które mają zachęcić potencjalnego nabywcę do ich zakupu. Zazwyczaj nie są one w ogóle warte uwagi, ale niekiedy zdarzają się wyjątki. Dzisiaj na przykład natrafiłem na specyficzne puzzle dołączone do dużego opakowania pewnej herbaty. Składają się one z zaledwie 4 dużych, drewnianych elementów. Rozmieszczając je odpowiednio, można z nich jednak ułożyć okrągłą liczbę aż 64 figur, zilustrowanych na dołączonej ulotce. Mimo pozornej prostoty jest to w praktyce dość trudne. Oczywiście według producenta doskonale pomaga przy tym filiżanka herbaty, ale w rzeczywistości nie zauważyłem jakiejś istotnej różnicy ;)
Przy okazji przypomniałem sobie też o istnieniu podobnych puzzli, tyle że w wersji elektronicznej. Gra nazywa się Liquid Crystals Puzzle, zawiera 37 figur do ułożenia z 7 elementów, jest całkowicie darmowa i prawie tak samo wciągająca. Polecam ją tym, którzy zamiast herbaty preferują inne napoje, a też chcą poćwiczyć szare komórki :)

Takie ćwiczenie jest swoją drogą wybitnie wskazane. Zwłaszcza tym, którzy mają wciąż to nieszczęście, że wraz z początkiem września muszą owe komórki zacząć znowu poważnie wysilać ;]

Laboratoria kontra projekty

Studia techniczne – a więc także i informatyka – różnią się od innych choćby tym, że tutaj nie obejdzie się bez dużej ilości zadań praktycznych. Brudzenie tablicy pyłem kredowym na wykładach i ćwiczeniach to bowiem za mało – zwłaszcza, jeśli mówimy o uczelniach technicznych, a nie uniwersytetach.
Mamy więc dwa dodatkowe rodzaje zajęć: laboratoryjne i projektowe. Oba mają na celu wykorzystanie zdobytej przez studenta wiedzy w praktyce oraz nabranie pewnej porcji doświadczenia. Cel chwalebny, wykonanie niestety nieco gorsze…

Dotyczy to głównie laboratoriów, które w pewnej formie są według mnie kompletnym nieporozumieniem, jeśli chodzi o większość dziedzin informatyki – zwłaszcza tych związanych bezpośrednio lub pośrednio z programowaniem. Zajęcia takie wyglądają mniej więcej tak: student otrzymuje takie-a-takie zadanie – którym jest zwykle napisanie programu – i do końca zajęć ma się z niego wywiązać, czyli rzeczony program napisać. Potem wyniki jego pracy są oceniane przez prowadzących.
W czym ta formuła jest zła? Ano można jej wytknąć całkiem sporo mankamentów:

• Nieżyciowość. W pracy nikt przecież nie koduje na akord: wiadomo, że z ośmiogodzinnego dnia programista na efektywną pracę przeznacza najwyżej 4 do 5 godzin. Kogo zresztą byłoby stać na to, by każdy projekt rozparcelować na małe kawałki, które potem byłyby pisane przez koderów w ściśle określonych ramach czasowych? To zapewne całkowicie niemożliwe, a co najmniej wysoce nieopłacalne.
• Złe nawyki. Jeśli mamy tylko godzinę lub dwie, by oddać działający kawałek kodu, na bardzo daleki plan schodzą takie kwestie jak jego czytelność, odpowiedni stopień nasycenia komentarzami, elastyczność, możliwość ponownego wykorzystania, i tak dalej. Krótko mówiąc, produkuje się wtedy kod “tylko do zapisu”, zgodnie z zasadą 3Z: Zakodź, Zalicz, Zapomnij :) Nabyte przy okazji przyzwyczajenia do programistycznego niechlujstwa mogą się odbijać czkawką jeszcze przez bardzo długi czas.
• Stres. Takie laboratoria to tak naprawdę nic innego, jak kartkówka wklepywana na klawiaturze. Nie jest to nic przyjemnego i w (zbyt) dużych dawkach prawdopodobnie może nawet skutecznie odstręczyć od kodowania jako takiego.

W przeciwieństwie do laboratoriów, projekty właściwie nie mają wymienionych wyżej wad. Są też na pewno bardziej pouczające, szczególnie wtedy gdy należy je wykonywać w grupach. Zdobyte przy okazji doświadczenie jest z pewnością o wiele cenniejsze, bo obejmuje przecież także organizowanie pracy i planowanie kolejnych jej etapów. Czegoś takiego nie można raczej powiedzieć o zadaniach wykonywanych na szybko na laboratoriach.