“Nie działa! Jejku, co ja zrobię?!”

Na forum Warsztatu zdarzają się różne problemy. Część z nich dotyczy nieznanych przyczyn błędnego funkcjonowania programu lub jakiegoś kawałka kodu. Z pewnością nie jest tak, że takie wątki są z góry uznawane za niepożądane. To, co o tym decyduje, to przede wszystkim treść, opisowość i precyzja.

A z tym bywa kiepsko. Bardziej doświadczeni programiści wiedzą oczywiście, że do wyeliminowania błędu potrzebna jest dokładna wiedza, w jakich okolicznościach on występuje. A już zupełnie niezbędne jest określenie, co tak naprawdę się dzieje: błędny rezultat funkcji, wyjątek czasu wykonania, zawieszenie się programu, bluescreen, spalenie płyty głównej (no, może przesadzam ;)) ?…
Nierzadko jednak za cały opis ma wystarczać mgliste stwierdzenie, że coś nie działa. “Serio?” – chce się odpowiedzieć – “więc idź i to napraw ;P”. Przy tak skąpo opisanych objawach trudno przecież oczekiwać, żeby ktokolwiek mógł wywróżyć, co tak naprawdę jest ich przyczyną.

Czasem ta lakoniczność jest spowodowana tym, że dana osoba traktuje fakt niedziałania napisanego przez siebie kodu wręcz jako życiowe niepowodzenie lub – co gorsza – osobistą zniewagę. A gdy w grę wchodzą takie emocje, z zebraniem potrzebnych informacji może być kłopot…
Próbuję się tu wczuć w taką postawę, ale prawdę mówiąc zupełnie jej nie rozumiem. Może każdy na początku przygody z programowaniem reaguje podobnie, a ja zdążyłem już po prostu zapomnieć, że kiedyś mi się to zdarzało? A może jednak zależy to od charakteru i sprawia, że osoby biorące wszelkie niepowodzenia (w tym przypadku błędy) za bardzo do siebie mają trudności w zostaniu dobrymi programistami?

I czy faktycznie podejście emocjonalne tak bardzo przeszkadza?… Nie wiem, jak w jest w istocie, lecz wiem jedno: ostatnio zdecydowanie za często zajmuję się dziwnymi problemami :)

Liczenie stałych

Dzisiaj pokażę pewną sztuczkę, mogącą nieco ułatwić życie programiście, który – jak wiadomo – zawsze ma za dużo pracy. Nie jest ona zbyt odkrywcza ani pomysłowa, ale ponieważ wielokrotnie zdarzyło mi się z niej korzystać (ostatni raz całkiem niedawno), sądzę że zasługuje na wzmiankę.

Sprawa dotyczy typów wyliczeniowych w C++ – czyli tworów, które pojawiają się często w większości programów. W moim ostatnim przypadku był to prosty typ definiujący wachlarz kolorów używanych w różnych miejscach systemu GUI:

Jest to podobny zestaw do tego, jaki można zobaczyć w Windows w oknie Właściwości: Ekran, na zakładce Wygląd. Naturalnie jest on dość okrojony, jako że nie potrzebujemy tutaj niczego aż tak skomplikowanego. Nie jest jednak wykluczone, że kiedyś się rozrośnie…
Każdemu z tych “systemowych” kolorów trzeba teraz przyporządkować kolor rzeczywisty – żeby wiedzieć, jak narysować konkretne kontrolki. Można zdefiniować do tego sporo zmiennych w stylu clActiveCaptionColor czy clControlNormalColor, ale lepszym rozwiązaniem jest tablica:

Problem w tym, że trzeba podać jej rozmiar. Można oczywiście wpisać tam na sztywno 5, ale doskonale wiadomo, jakie są skutki stosowania w kodzie “magicznych liczb”. Można zdefiniować sobie stałą, lecz wtedy też będziemy musieli ręcznie modyfikować jej wartość, jeżeli liczba kolorów się zmieni.

Potrzebujemy więc sposobu na automatyczne określenie liczby stałych zdefiniowanych w typie wyliczeniowym. W językach dysponujących dynamicznymi informacjami o typie – jak C# czy Java – byłoby to zapewne proste, lecz tutaj nie mamy tego komfortu. Zamiast tego możemy sobie jednak poradzić inaczej – dodając do typu wyliczeniowego kolejną stałą:

Kompilator nada jej wartość o jeden większą od poprzedniej. Ponieważ pierwszej stałej przypisał zero, GC_COUNT będzie odpowiadało liczbie 5 i to będzie właśnie liczba użytecznych stałych w typie wyliczeniowym. Teraz można już zadeklarować potrzebną tablicę:

Podobnie można zrobić dla każdego typu wyliczeniowego. Najlepiej działa to wtedy, gdy kompilator sam numeruje jego stałe. Jeżeli sami to robimy, to oczywiście trik nadal będzie działał (zmienna *_COUNT będzie zawsze miała największa wartość). W tablicy pojawią się jednak niewykorzystane elementy i te dziury ewentualnie trzeba będzie omijać.

System GUI #2 – Model klas

Po kilku dniach niezbyt intensywnego zastanawiania się nad strukturą systemu GUI zdołałem wysmażyć coś, co można nazwać schematycznym modelem klas. Jest on wybitnie poglądowy i przedstawia się następująco:

Na pierwszy rzut oka może wydawać się nieco pokręcony, ale z odrobiną wysiłku można go odcyfrować :] To co jest w nim chyba najważniejsze, to dość wyraźny podział na część rysującą (lewa strona) i tę zawierającą kontrolki. Łączy je “most” złożony z głównej klasy systemu, nazwanej bardzo oryginalnie: System :) Taki podział zapewni między innymi prostsze rysowanie samych kontrolek, które będą renderowane przy pomocy takich poleceń jak: narysuj ramkę, narysuj wciśnięty przycisk, itp. To rozwiązanie zaczerpnąłem z Windows.Forms, gdzie jest zresztą ono posunięte o wiele dalej.
Lista kontrolek jest, jak widać, skromna i odpowiada tej, którą wcześniej ustaliłem jako minimalną. Oprócz abstrakcyjnej klasy dla wszystkich kontrolek wprowadziłem też osobną dla takich, które mogą zawierać i grupować inne kontrolki. Póki co jedynym obiektem tego rodzaju jest okno, ale GUI zna ich więcej: jak np. panel czy pole grupy (groupbox).

Niezbędna aktualizacja

Oparcie strony o powszechnie znany system CMSowy jest wygodne, ale ma przynajmniej jedną wadę. Podobnie jak popularny system operacyjny (ciekawe, który dokładnie mam na myśli ;)) wymaga on pewności, że zawsze używa się najnowszej wersji. Inaczej można nietrudno paść ofiarą tego, co nazywamy eufemistycznie security issues.
Na szczęście w przypadku WordPress ciężko jest przegapić wydanie nowej wersji. Wiadomość o tym jest bowiem wtedy wyświetlana na głównej stronie panelu administracyjnego. Tak było i dzisiaj, kiedy pojawiła się wersja 2.2.2.

Uaktualnienie poszło gładko i sprawnie. Sądzę więc, że kolejne upgrade’y będą na tyle mało znaczącymi wydarzeniami, że nie będzie warto o nich pisać :)

Pytania o bardzo długich odpowiedziach

Jako moderator forum Warsztatu dość często spotykam się z różnymi przejawami tak zwanego lamerstwa. Część z nich jest bardzo typowa, na czele z pokazywaniem kawałka kodu (zwykle obleśnego) i zadawaniem nieśmiertelnego pytania:

No i co tu jest źle?!

Nie trzeba się domyśleć, że reakcja na takie kwiatki jest zwykle dość gwałtowna :)

Innym przykładem lamerstwa są zbyt ogólne pytania – czyli takie, na których odpowiedzi (o ile w ogóle istnieją) kryją za sobą całe, nierzadko bardzo obszerne dziedziny. “Jak napisać grę podobną do …?” czy “Jak dodać do gry tryb multiplayer?” to całkiem reprezentatywne przykłady. Co można zrobić, kiedy napotka się tego rodzaju okaz?
Oczywiście można zareagować drastycznie i represyjnie. Twierdzę jednak, że każdego (no, prawie każdego ;)) lamera da się w końcu odlamić. Nie dysponujemy naturalnie nieograniczonym czasem, by w ten sposób załatwiać wszystkie przypadki. Z odrobiną dobrych chęci można chyba jednak coś zdziałać.

Otóż według mnie dobrą receptą na ogólne pytanie są… pytania bardziej szczegółowe. I to w dużych ilościach, zadawane w sposób logiczny i rzeczowy. Osoba zasypana gradem takich konkretnych pytań, poruszających szczegółowe kwestie z danej dziedziny, na pewno będzie przynajmniej uświadomiona o obszerności tematu, który tknęła. A jeśli posiada odpowiedni zasób umiejętności wyszukiwania – którym to powinien się wykazywać każdy programista i delikwent aspirujący do tego miana – wtedy użyje tych pytań jako wskazówek do poszukiwania informacji na własną rękę. Na forum powróci zaś wówczas, gdy pojawią się bardziej konkretne zapytania i problemy, które z pewnością będą mogły liczyć na przyjaźniejszy odzew.

Czy to zbyt optymistyczny scenariusz? Być może. Na szczęście dość szybko okazałoby się, czy taka okrojona marchewka działa. Jeśli nie, wtedy zawsze można sięgnąć po kij :)

Drugi dodatek do WoW

Przedwczoraj Blizzard oficjalnie potwierdził to, co parę dni wcześniej wyciekło do Internetu. Szykuje się drugi dodatek do gry World of Warcraft. Chociaż nie przewiduję, bym w bliskiej przyszłości powrócić do tej gry, muszę przyznać, że informacja ta wybitnie mnie zainteresowała.

Co do samej zawartości dodatku, większość spekulacji okazała się słuszna. Zabiera on graczy do mroźnego kontynentu Northrend na północy Azeroth, nad którym obecnie niepodzielnie panuje władca nieumarłych, czyli Król Lisz (Lich King; to niezbyt zgrabne tłumaczenie jest z WarCrafta 3).
O stronie fabularnej ciężko powiedzieć coś więcej, bo od czasu rozpoczęcia się ery WoW Blizzard nieco zaniedbał tę stronę świata gry. Więcej wiadomo o nowych elementach gry, które mają być wprowadzone w dodatku, jak choćby:

• podniesionego maksymalnego poziomu postaci do 80
• nowym kontynencie Northrend, który ma być mniej więcej tak duży jak Outland
• nowym dużym, neutralnym mieście – Dalaran
• wprowadzeniu klas bohaterskich (Hero Classes), zapowiadanych zresztą od bardzo dawna; pierwsza taką klasą ma być Death Knight
• dodaniu broni oblężniczych do pól walk PvP – też obiecywanych od niepamiętnych czasów
• nowej profesji Inskrypcji, pozwalających na zmianę parametrów umiejętności postaci (np. czasu rzucania czarów)

Póki co nic jeszcze nie wiadomo o ewentualnych nowych rasach, jakie mogłyby się pojawić w dodatku.

Na początku trochę mnie zdziwiło, że kolejny dodatek ma się pojawić tak szybko – przecież od wydania poprzedniego minęło ledwie pół roku. Po chwili zastanowienia jest to jednak dość oczywiste: pierwszy dodatek przyniósł Blizzardowi krociowe zyski i rzesze nowych i powracających graczy. Nic dziwnego, że chcą szybko powtórzyć ten manewr.
Dla istniejących graczy problem z nowym dodatkiem i z podniesieniem maksymalnego poziomu postaci polega na tym, że w ten sposób dewaluuje się cały wysiłek włożony w zdobywanie potężnych przedmiotów. Po wyjściu dodatku zostaną one bowiem szybko zastąpione przez zwyczajne nagrody za questy wykonywane podczas podnoszenia poziomu postaci. Innymi słowy, za zabicie kilku potworków będzie można dostać coś, co jest lepsze od łupu wziętego ze zwłok bossa, do którego zabicia potrzebnych było 10 lub 25 osób. Czy to jest fair?

Z pewnością nie, ale Blizzard się tym nie przejmuje. Chodzi tu bowiem o jakieś 10% graczy, którzy mają możliwość brania udziału w tak wielkich i trudnych raidach. Wymaga to oczywiście czasu i poświęcenia, ale nagrody są tego warte. Dopóki, rzecz jasna, ktoś nie zdecyduje się, że trzeba znowu podnieść limit poziomów i wcześniej potężny ekwipunek staje się kupą śmieci.
To oczywiście nie dotyczy pozostałych graczy, których jest zdecydowana większość. A więcej graczy to więcej pieniędzy z abonamentów – bo w końcu głównie o to tutaj chodzi. Tyle że skutkiem ubocznym może być “zmęczenie materiału” graczy zmuszonych co roku do kupowania nowego dodatku, nabijania kolejnych 10 poziomów i zdobywania ekwipunku od nowa. Niewykluczone, że w ten sposób Blizzard zarżnie kurę znoszącą złote jajka.

Dalsze badania nad relacją zawierania

Nie tak dawno temu w notce Trzy rozwiązania dla relacji zawierania zastanawiałem się nad tym, jak elegancko i odpornie (na błędy) zrealizować interfejs klasy-kontenera zawierającego różne elementy. Po jakimś czasie jednak zapomniałem o całej sprawie, gdyż zająłem się menedżerem fontów, gdzie kwestia ta nie była mi potrzebna.
W końcu przyszła pora na zastanowienie się nad systemem GUI i wtedy przypomniałem sobie o tym problemie. Rezultatem tego jest wątek na forum Warsztatu.

Wywiązała się w nim ciekawa dyskusja, ale ostatecznie tylko odrobinę przybliżyła mnie do dokonania jakichś decyzji. Bardziej interesujące są może nieco inne wnioski, które przy tej okazji wyciągnąłem… Tak, chciałbym sobie teraz trochę pofilozofować :)
Zaskoczyło mnie trochę to, że na proste i jednoznaczne pytanie (“Które rozwiązanie jest lepsze?”) w dziedzinie tak zdawałoby się ścisłej jak programowanie nie ma dobrze uzasadnionej i obiektywnej odpowiedzi. Właściwie wszystkie argumenty, jakie tam padały były wielce subiektywne, na zasadzie: “wydaje mi się”, “bardziej naturalne będzie”, “najbardziej logiczne jest”, itd.
Okazało się, że programowanie – a zwłaszcza faza projektowania – wcale nie musi być taką ścisłą dziedziną, a każdy jego wytwór może mieć indywidualny charakter. Oczywiście, spora część podejmowanych przy okazji decyzji ma inny charakter niż dylemat, czy ładniejszy jest kolor zielony czy czerwony. Zdarzają się jednak i takie, gdzie kryteria są niejasne, nieostre i subiektywne.

Prostota, przejrzystość, elegancja… estetyka… piękno? Czy to dowód, że programowanie można w pewnym stopniu uważać za dziedzinę sztuki?