Archive for Thoughts

Granice

2007-12-20 20:20

Bariery, granice, strefy rozdzielające i podobne twory potrafią często utrudniać życie i prowadzić do straty cennego czasu. Jednak w prawdziwym świecie jest możliwe, aby przynajmniej w pewnym obszarze je znieść lub uczynić niewidocznymi – tak jak to stanie się dzisiaj o północy z zachodnią i południową granicą Polski. Naturalnie jest to wielkie przedsięwzięcie logistyczne, organizacyjne i polityczne. Ale doprowadzono je do końca, nie pierwszy raz zresztą – widać więc, że to możliwe.
Podczas programowania też napotykamy na przeróżne granice. Tutaj sytuacja nie przedstawia się aż tak różowo. Nikt ich nie zniesie jakimś odgórnym traktatem i zawsze pozostanie nam ich mozolne przekraczanie…

Cóż to za bariery? Są one bardzo różnego rodzaju, mają jednak pewną wspólną cechę. Występują mianowicie tam, gdzie spotykają się takie okołoprogramistyczne twory, które nie są ze sobą do końca kompatybilne – a mimo to muszą ze sobą współpracować. Przykładów jest mnóstwo i zwykle każdy z nich wymaga osobnego rozwiązania. Oto kilka próbek:

  • Wzorzec Most
    Wzorzec Most pozwala przekraczać granicę
    między interfejsem a implementacją

    Pewne języki programowania (z C/C++ na czele) mienią się wieloplatformowymi. Teoretycznie więc granica między systemami operacyjnymi powinna być łatwo przekroczona poprzez ponowną kompilację. W praktyce pisanie programów działających na wielu systemach wymaga albo wielkiej dbałości o zgodność, albo napisania po prostu osobnych kodów dla fragmentów, które na różnych systemach implementuje się różnie.

  • Programy do grafiki 3D zapisują stworzone modele w wielu różnych formatach. Niektóre odpowiadają naszym oczekiwaniom i możemy je odczytywać bezpośrednio (co aczkolwiek banalne nie jest, ale o tym kiedy indziej), ale jeśli chcemy zapisywać z modelem jakieś niestandardowe informacje albo robić to w nieprzewidziany sposób, potrzebujemy zwykle pluginu do edytora 3D. W tym przypadku wtyczka ta jest sposobem na przekroczenie granicy między wspomnianym edytorem a naszym silnikiem.
  • Kiedy aplikacja zaczyna się komunikować przez sieć, owo przełamywanie barier (w tym przypadku jednej maszyny) jest od razu widoczne i, oczywiście, przysparza kłopotów :) Zależnie od tego, o jakim poziomie abstrakcji mówimy, możemy spotkać się z: taką obsługą odczytu i zapisu danych, by nie blokowało to reszty aplikacji; niedostatkami istniejących i nieco przestarzałych protokołów sieciowych (albo koniecznością tworzenia własnych) czy nawet inną kolejnością bajtów przy interpretowaniu danych liczbowych na maszynie źródłowej i docelowej.

Można by niemalże pomyśleć, że kodowanie polega przede wszystkim na godzeniu ze sobą takich niezgodnych platform, systemów, bibliotek, i tak dalej. Jednak wśród tych wszystkich granic tak naprawdę tą najważniejszą, którą powinniśmy nieustannie przekraczać, jest granica naszych własnych możliwości.

Tags:
Author: Xion, posted under Programming, Thoughts » 2 comments

Koder, istota niepokorna

2007-12-09 21:52

Tę notkę mógłbym zacząć znanym stwierdzeniem: A miało być tak pięknie :) Przecież to w końcu na studiach człowiek zaczyna w pełni kierować własną edukacją i może zająć się poznawaniem tych zagadnień, które go naprawdę ciekawią. Koniec z wyjaśnianiem, dlaczego Słowacki wielkim poetą był i zapamiętywaniem szczegółów budowy mięśni poprzecznie-prążkowanych. Nareszcie przychodzi czas na bardziej przydatne i interesujące umiejętności – czyli programowanie, rzecz jasna.

A jak wygląda przełożenie tej teorii na praktykę? Otóż po dwóch latach mogę stwierdzić, że… dość kiepsko :) W istocie mamy tu do czynienia z wielkim dylematem – może nie natury filozoficznej, ale jednak całkiem ciężkiego kalibru.
Gdy bowiem zajmujemy się kodowaniem czysto hobbystycznie, automatycznie wydaje się nam ono o wiele rzędów wielkości atrakcyjniejsze niż to, nad czym musimy się skupiać przy okazji edukacji szkolnej. Działa tu pewnie prawo człowieka jako istoty przekornej, lubiącej podążać własnymi ścieżkami. Jednocześnie jednak tęskni się do wyidealizowanego czasu przyszłego, kiedy w końcu swoje zainteresowania będzie można realizować także w trakcie nauki i pracy.
Najwyraźniej wspominane prawo jest tak silne, że gdy ów czas w końcu przychodzi, zaczynamy lepiej wspominać wcześniejszy okres. Nie oznacza to oczywiście, że wolałbym dalej “przymusowo” uczyć się czegoś zupełnie niezwiązanego z szeroko pojętą informatyką; wręcz przeciwnie, nie zamieniłbym aktualnego kierunku studiów na żaden inny :) Problem w tym, że gdy ktoś zaczyna nas programowania uczyć i egzekwować wyniki, traci ono część swojej ‘magii’; podejrzewam, że dotyczy to chyba każdej dziedziny. Ponadto nie da się ukryć, że spełnianie stawianych wymagań oznacza konieczność napisania sporych ilości kodu i ostatecznie na własne kodowanie pozostaje mniej czasu i ochoty.

Wnioski są dwa. Pierwszy to – że użyję wychodzącego już na szczęście z mody sformułowania – oczywista oczywistość: każdy etap nauki czy pracy ma swoje dobre i złe strony, i do każdego trzeba się odpowiednio dostosować. Drugi zaś jest taki, że zawsze wierzymy, iż w przyszłości będzie lepiej. W tym przypadku faktycznie się to sprawdza, lecz chyba nigdy nie dzieje się to w sposób całkowicie zgodny z naszymi oczekiwaniami.
Wypada tylko się tym pogodzić i dalej robić swoje. Dla mnie też na pewno będzie to lepsze niż pisanie pseudofilozoficznych notek ;)


Author: Xion, posted under Programming, Studies, Thoughts » 8 comments

Wyrafinowane sposoby marnowania czasu

2007-11-29 12:33

Grać każdy może – trochę lepiej lub trochę gorzej :) Wśród gier komputerowych każdy gatunek ma pozycje wybitne, które pierwsze przychodzą na myśl, kiedy tylko o nim wspomnimy. Przy każdej z nich można przesiedzieć długie godziny i dni, a inne gry często bywają nazywane “podobnymi do…” – Starcrafta, Quake’a, SimCity, Baldur’s Gate, i tak dalej.

Screen z gry KalOnlineAle jest też pewien szczególny gatunek gier, mających już na starcie uprzywilejowaną pozycję. Należące do niego tytuły nie zawsze muszą odznaczać się wyjątkową oprawą graficzną, nowatorskim gameplayem, wieloma możliwymi sposobami prowadzenia rozgrywki – a mimo to często zdobywają rzesze graczy, którzy są im wierni przez całe miesiące, a nawet lata. Pewnie nietrudno zgadnąć, jaki gatunek gier mam na myśli. Chodzi mi bowiem o te określane akronimem MMORPG – Massive Multiplayer Online Roleplaying Game.
Screen z gry Cabal OnlineZastanawiałem się niedawno, jaka jest tego przyczyna. W końcu mam pewne doświadczenia z kilkoma grami tego typu (a zwłaszcza z jedną :)), więc miałem nadzieję dojść do jakichś sensownych wniosków. W końcu wymyśliłem trzy powody, które wydają mi się najważniejsze.
Są to:

  • Magia numerków, gdzie tymi numerkami są głównie przeróżne statystyki postaci gracza na czele z tym najważniejszym – aktualnym poziomem (level). Podnoszenie tych wartości – ukryte pod eufemistycznym określeniem ‘rozwoju postaci’ – jest głównym celem MMORPGów. Różnią się one tutaj znacząco od klasycznych gier RPG, gdzie mimo wszystko najbardziej istotnym składnikiem jest linia fabularna – choćby po drodze wymagała wyrżnięcia tysięcy potworów.
  • Społeczność, czyli kontakty z innymi graczami: począwszy od przygodnych rozmów na chatach, poprzez granie w jednej drużynie, aż po najbardziej zaawansowaną formę, czyli gildie i klany. Każda z nich jest zresztą aktywnie wspierana przez mechanizmy samych gier. Nie da się ukryć, że często to inni ludzie są tym czynnikiem, który potrafi zatrzymać graczy – nawet jeśli pozostałe stracą już swoją przyciągającą moc.
  • Screen z gry World of WarcraftZłożoność. Gry typu MMORPG są skomplikowane, i to na wielu płaszczyznach. Dotyczyć to może rozległego świata, liczby dostępnych klas postaci i możliwych strategii grania każdą z nich, samej mechaniki gry, dodatkowych profesji pozwalających wytwarzać nowe przedmioty (crafting), specjalnych lokacji dla małych i wielkich grup graczy wraz z zamieszkującymi je bossami, systemu walki pomiędzy graczami (PvP) i pewnie jeszcze kilku innych aspektów rozgrywki. Dogłębne poznanie ich wszystkich jest zapewne niemożliwe, chociaż każdemu wydaje się, że może to zrobić :) Faktem jest jednak, że w dobrym MMORPGu, niezależnie od aktualnego stopnia rozwoju postaci, gracz zawsze ma co robić.

Nie zdziwiłbym się naturalnie, gdyby powyższa lista okazała się o wiele za krótka. Przeciwnie, byłoby to dość zaskakujące, jeśli fenomen gier MMORPG dało się zanalizować w tak trywialny sposób. Nadal też nie rozwiązałem dylematu, czy nad grami tego typu pożyteczniej jest się zastanawiać, czy może w nie… grać. Jak na razie obie te czynności wydają mi się marnowaniem cennego czasu ;D

Tags:
Author: Xion, posted under Games, Thoughts » 5 comments

Wiedza czysto użytkowa

2007-11-26 22:11

Spotykam się ostatnio z osobliwym podejściem do przeróżnych wiadomości tyczących się programowania. Mogę je określić dość zaskakująco jako nadmiar “chęci rozumienia” lub ewentualnie “nieuzasadnioną dociekliwość”. Dotyczy to bardzo wielu narzędzi używanych w zasadzie każdej dziedzinie programowania – jak języki, środowiska czy biblioteki – oraz większości jego aspektów.

Czym to się objawia? Otóż symptomem jest pragnienie dogłębnego zrozumienia jakiegoś mechanizmu w sposób jak najszerszy i jak najgłębszy jednocześnie – zanim jeszcze spróbuje się go zastosować. Ten pęd to wiedzy dla samej wiedzy skutkuje najczęściej pozyskaniem dużego zasobu informacji, z których sensownym połączeniem i – przede wszystkim – stosowaniem są później pewne, a często spore, kłopoty.
Czy twierdzę więc, że nadmiar wiedzy szkodzi? Bynajmniej. Chodzi mi raczej o chęć zadawania raczej pytań w rodzaju “jak to działa?” niż “jak tego użyć?”. Sądzę bowiem, że zdecydowana większość programistycznej wiedzy ma charakter czysto użytkowy i jako taka jest na tyle przydatna, na ile daje się użyć w praktyce. Koder powinien być raczej przygotowany na poszukiwanie potrzebnych informacji w trakcie rozwiązywania danego problemu, a nie na kompletne poznanie tematu przez przystąpieniem do pracy.

Jeśli aczkolwiek życzymy sobie poznać głębiej jakieś zagadnienie z racji tego, że jest ono interesujące, wszystko jest w porządku. Jeśli jednak chodzi nam tylko o osiągnięcie zamierzonego celu, nie musimy poznawać rozgałęzień każdej drogi, która do niego prowadzi. Jak zawsze, najważniejsze jest zachowanie odpowiedniej równowagi.


Author: Xion, posted under Programming, Thoughts » 8 comments

Mniejsze zło debugowania

2007-11-13 12:44

Banałem będzie stwierdzenie, że szukanie błędów w kodzie bywa wkurzające. Odpowiedź na proste pytanie – dlaczego coś nie działa? – to czasami długie godziny dłubania w programie, mało przyjemnych rendez-vous z debuggerem czy nawet stosowania bardziej drastycznych metod. Ale ponieważ w programowaniu nic nie dzieje się bez powodu (a przynajmniej chcemy w to wierzyć ;D) i przy założeniu, że dysponujemy odpowiednio dużymi zasobami: czasu, samozaparcia, a przede wszystkim umiejętności, w końcu uda się znaleźć tę upragnioną przyczynę błędu…

Bug :)A przyczyny mogą być trywialne. Pomyłka o jedynkę, nieopacznie wstawione x zamiast y, pomylenie plusa z minusem , i tak dalej. Takie błahostki zgodnie z prawem Murphy’ego mają wybitną skłonność do pojawiania się akurat w tych newralgicznych miejscach, które mają największy wpływ na działanie całego kodu – i oczywiście całkowicie je rozstrajają. A co gorsza, z bliżej niewiadomych przyczyn programistę uważnie oglądającego fragmenty z takimi “literówkami” ogarnia najczęściej chwilowa ślepota tudzież niewytłumaczalny zanik spostrzegawczości. Dopiero za n-tą inspekcją, przeprowadzoną najlepiej po długim odpoczynku od kodu, da się cokolwiek znaleźć.
Z drugiej strony poważne i trudne do znalezienia błędy mogą mieć poważne i trudne do usunięcia przyczyny. Inżynieria oprogramowania mówi, że im wcześniej w cyklu tworzenia programu błąd się pojawił, tym trudniej jest go potem wyeliminować. Jeżeli więc kruczek tkwił w założeniach projektowych, w modelu programu lub, co gorsza, w określeniu funkcjonalności, to nie będzie łatwo poradzić sobie z nim na etapie implementacji. Wyburzenie kilku ścian nie pomoże, jeśli fundamenty położono na niestabilnym gruncie.

Którego z tych dwóch rodzajów błędów oczekiwalibyśmy, jeżeli spędziliśmy już na debugowaniu dużo, naprawdę dużo czasu? Błąd drugiego typu to sprawa ciężkiego kalibru. Można wówczas powiedzieć, to oto odkryliśmy problem, który rzeczywiście jest adekwatny do tych godzin czy dni spędzonych na polowaniu na niego. Inaczej mówiąc, możemy uznać, że faktycznie zrobiliśmy wszystko, co w naszej mocy, i że cały ten wysiłek był naprawdę potrzebny, gdyż nie było innej drogi.
Z kolei pierwszy typ błędu to właściwie przeciwny biegun. Teoretycznie można było go załatwić w najwyżej kilkanaście minut, po prostu przeglądając jeszcze raz kod i dopisując ten zapomniany przecinek czy cokolwiek innego. Jak mogliśmy w ogóle spędzić nad tym tyle czasu, który przecież powinno się wykorzystać bardziej produktywnie?

Jeżeli kiedykolwiek ktoś odkryje przyczynę owej chwilowej ślepoty programistów na drobne omyłki, to osobiście uważam, że zasługuje przynajmniej na Ig Nobla :) Sądzę też jednak, że o wiele lepiej jednak paść jej ofiarą niż stwierdzić, że znaleziony błąd jest ową “ciężką sprawą”. Może i obniży to nieco naszą samoocenę, ale przynajmniej oszczędzi mnóstwa roboty.

Tags:
Author: Xion, posted under Programming, Thoughts » 7 comments

Wielokąty radarowe

2007-11-12 9:28

Dane liczbowe przedstawiać można na wiele sposobów. Najbardziej kompletnym jest zwykle tabelka, ale o wiele ładniejszą jest odpowiedni wykres. Czasem sztuką jest dobrać jego odpowiedni typ, gdyż rodzajów wykresów jest wbrew pozorom bardzo dużo. Jeżeli ktoś nie wierzy, niech sprawdzi w dowolnym arkuszu kalkulacyjnym :)

Radarowy wykres powierzchniowy w grze StepmaniaJednym z ciekawszych jest wykres radarowy. W nim ze środka wykresu na zewnątrz wypuszczone są osie (różna może być ich liczba), na których z kolei zaznaczone są wartości. W najprostszej wersji wygląda to jak pajęczyna z napaćkanymi punktami i w sumie nie jest specjalnie sugestywne.
Ciekawiej zaczyna się robić, jeżeli punkty na poszczególnych osiach połączymy ze sobą i zamalujemy wnętrze tak powstałego wielokąta. Jeżeli bowiem wartości na osiach przedstawiają pewne właściwości jednego obiektu lub zjawiska, to powstała figura niejako opisuje go w sposób całościowy. Weźmy na przykład taki wykres, w którym w subiektywny sposób ocenimy sobie różne charakterystyki jakiegoś hipotetycznego kawałka kodu źródłowego:

Radarowy wykres powierzchniowy cech kodu

Figura taka ma jeszcze jedną istotną cechę: powierzchnię. Na pierwszy rzut oka dość ciężko określić, w jaki sposób zależy od wartości na poszczególnych osiach. Czy na przykład gwałtowny wzrost jednej zmiennej przy identycznych wartościach pozostałych da ostatecznie większe pole wielokąta niż równomierny przyrost na wszystkich osiach?
Nie jest to oczywiste i dlatego wydaje się całkiem interesujące :) Naturalnie znając wszystkie wartości, rzeczone pole policzyć jest bardzo łatwo.

Dlaczego jednak wspominam o tym wszystkim? Otóż uważam, że gry w których przedstawia się graczowi bardzo dużo danych – a więc na przykład ekonomiczne, strategiczne czy RPG – są zwykle dość ubogie pod względem sposobów prezentacji tych danych. Prawie zawsze królują w nich nieśmiertelne tabelki i czasami tylko jakieś wykresy liniowe czy słupkowe.
A przecież można by nieco się wysilić i zafundować graczowi jakąś bardziej atrakcyjną formę. W końcu jeśli ktoś nie lubi odmóżdżających strzelanek to jeszcze nie znaczy, że uśmiecha mu się wpatrywanie się w rzędy numerków ;P

Tags: , ,
Author: Xion, posted under Games, Programming, Thoughts » 3 comments

Właściwy balans

2007-11-02 22:24

Podobno nie ma głupich pytań, są tylko głupie odpowiedzi. Być może to rzeczywiście jest prawda. Jako moderator forum Warsztatu już nieraz widziałem wątki, które na pierwszy rzut oka nadawały się do eliminacji, ale akurat jakimś dziwnym zrządzeniem losu nie przykuły uwagi żadnego przedstawiciela służb porządkowych i zdążyły się rozrosnąć. Jaki był często skutek? Otóż zamieniały się one w całkiem rzeczowe dyskusje, chociaż – trzeba to przyznać – zazwyczaj trochę niezwiązane z początkowym tematem. Na pewno jednak zasługiwały na dalsze istnienie.
Z tej przyczyny jestem teraz chyba nieco bardziej tolerancyjny niż kiedyś. Zdarza się, że nawet jeśli mam uzasadnione podejrzenia (jak to ktoś ładnie nazwał: “przypuszczenie graniczące z pewnością” ;)), iż z danego wątku nie wyniknie nic dobrego, staram się nie kierować tym pierwszym wrażeniem. Aczkolwiek już ponad rok zajmuję się moderowaniem forum Warsztatu i pewnie daje mi to jakieś doświadczenie pozwalające dokonywać takich intuicyjnych przewidywań.

Zamiast (przed)wczesnych interwencji skłaniam się więc raczej do postawy wyczekującej. Można mi więc zarzucić, że zawsze czekam, aż problemami zajmie się ktoś inny. Albo że – mówiąc dosadniej – pośrednio pozwalam, by forum zalała fala lamerstwa. Ale to chyba nie jest takie proste. Prawdopodobnie bowiem każdy ma inne wyobrażenie tego, jakie wątki powinny się na forum pojawiać, a jakie nie, i oczywiste jest, że wszystkim dogodzić nie można. Plan minimum to eliminacja tych niepożądanych zachowań, co do których nikt nie ma żadnych wątpliwości. Lecz by robić coś więcej, potrzebna jest odpowiednia równowaga między restrykcyjnością a tolerancją.

Niełatwo ją znaleźć. Ale gdyby było inaczej, nie mógłbym co jakiś czas utyskiwać nad ciężką dolą moderatora ;]

Tags: ,
Author: Xion, posted under Thoughts » 3 comments
 


© 2017 Karol Kuczmarski "Xion". Layout by Urszulka. Powered by WordPress with QuickLaTeX.com.