Wartość pomysłów

Podobno w informatyce najcenniejszym zasobem są pomysły. Bo o ile zrealizowanie gotowej idei to praca czysto rzemieślnicza i – przynajmniej teoretycznie – możliwa zawsze do wykonania przy odpowiednim czasie i przy właściwej liczbie osób, to z kolei „wzięcie skądś” pomysłu nie jest taką prostą sprawą. W końcu, jak to ktoś powiedział, pomysły nie rosną przecież na drzewach :)

Tak to zwykle wygląda z rynkowego punktu widzenia. Dlatego bardzo ciekawy jest fakt, że np. na Warsztacie wygląda to – jak się wydaje – zupełnie odwrotnie. Objawem tego jest choćby fakt, że działy z pomysłami i projektami na forum są jednymi z większych i bardziej aktywnych. Jak to możliwe?
Wydaje mi się, że przyczyny są co najmniej dwie. Po pierwsze, na Warsztat trafiają osoby zainteresowane programowaniem gier i przynajmniej część z tych (a w rzeczywistości pewnie całkiem spora część) chcę zająć się tym tematem między innymi dlatego, że mają w głowie pomysł na jakąś grę. Albo na kilka od razu. A że na początkowym etapie nauki nijak nie da się tego zrealizować, owe genialne idee lądują we wspomnianym dziale forum.
Poza tym, nie ma co ukrywać: większość z nich jest w istocie marnej jakości – nawet jeśli litościwie odsiejemy projekty kolejnych MMORPG-ów, jakie dość często się pojawiają :) Oczywiście dla swoich autorów są one zawsze niezwykle innowacyjne i warte zrealizowania, ale nie łudźmy się: tak naprawdę podobne epitety można przypisać tylko ich małemu ułamkowi.

Innymi słowy, jest duża różnica pomiędzy pomysłem a dobrym pomysłem. Tych pierwszych każdy z nas ma pewnie dziesiątki tygodniowo. Nieuchronnie trzeba więc wybierać z nich tylko te najbardziej wartościowe. Do pozostałych najlepiej jest zaaplikować garbage collector :)

Nowoczesne wyliczanie

W chyba każdy języku posiadającym pojemniki (jak wektory czy listy) istnieje koncepcja iteratorów: obiektów, które pozwalają na przeglądanie kolekcji i są uogólnieniem wskaźników. W najprostszym pozwalają one tylko na pobranie aktualnego elementu i przejście do następnego, ale jest to zupełnie wystarczające do celów wyliczania.
Z wierzchu więc wyglądają one całkiem prosto i przejrzyście - zwłaszcza, jeśli język udostępnia pętlę typu foreach, która ładnie i przezroczyście je opakowuje. Dlatego może wydawać się dziwne, czemu zazwyczaj mechanizm ten jest używany właściwie tylko dla pojemników; w teorii bowiem za pomocą iteratorów (zwanych gdzieniegdzie enumeratorami) można by było przeglądać dosłownie wszystko.
Weźmy chociażby wyszukiwanie plików na dysku - sporo programów w jakimś momencie swojego działania musi znaleźć pliki np. o danej nazwie w określonym katalogu. Wtedy zwykle zakasujemy rękawy i piszemy odpowiednią procedurę rekurencyjną lub bawimy się ze stosem czy kolejką. A czy nie fajniej byłoby, gdyby dało się to zrobić po prostu tak:

oczywiście przeszukując w ten sposób również podkatalogi bez jawnego "wchodzenia" do nich?... Według mnie to by było bardzo fajne :)

Od razu zaznaczę więc, że wbrew pozorom taki iterator jest jak najbardziej możliwy do napisania. Problemem jest jednak to, jak należy przechowywać jego stan. Kiedy wyszukiwanie czy przeglądanie zaimplementowane jest bezpośrednio jako jedna funkcja, robi się to w zasadzie samo: w postaci zmiennych lokalnych (stos/kolejka) albo parametrów (rekurencja). Nikt specjalnie nie zwraca na ten fakt uwagi. Jednak w momencie próby "wyciągnięcia" z algorytmu operacji Next (w celu stworzenia iteratora) okazuje się nagle, że wymaga to jawnego pamiętania tych wszystkich danych, które pozwalają obliczyć następny element. Przy przeszukiwania katalogów trzeba by na przykład pamiętać jakiś systemowy uchwyt wyszukiwania dla aktualnego katalogu, poziom zagnieżdżenia oraz analogiczne uchwyty... dla każdego takiego poziomu!
Zawracanie głowy, prawda? :) Nic dziwnego, że traktowanie wyszukiwania "per iterator" nie jest popularną praktyką. Z punktu widzenia piszącego algorytm wyliczania nieporównywalnie łatwiej jest po prostu wymusić jakiś callback i wywołać go dla każdego elementu; niech się programista-klient martwi o to, jak ten callback wpasować w swój kod. A że ten byłby o wiele czytelniejszy, gdyby w grę wchodziły iteratory? No cóż, iteratorów tak łatwo pisać się nie da...

...chyba że programujemy w Pythonie. Tam bowiem "iteratory" (zwane generatorami) piszemy w zupełnie unikalny, łatwy sposób. Weźmy dla przykładu taką oto klasę drzewa binarnego (BST - Binary Search Tree):

Żeby dało się je przeglądać zwykła pętlą for w porządku inorder (dającym posortowanie kluczy), piszemy do niego odpowiedni generator:

I już - to wystarczy, by poniższa pętla:

rzeczywiście "chodziła" po krawędziach drzewa "w czasie rzeczywistym" - bez żadnego buforowania elementów na liście.

Tajemnica tkwi tutaj w instrukcji yield - działa ona jak "tymczasowe zwrócenie" elementu, który jest przetwarzany przez ciało pętli for. Gdy konieczny jest następny element, funkcja inorder podejmuje po prostu działanie począwszy od kolejnej instrukcji - i tak do następnego yielda, kolejnego cyklu pętli i dalszej pracy funkcji. yield działa więc jak callback, tyle że w obie strony. Całkiem zmyślne, czyż nie?
Aż chciałoby się zapytać, czy w innych językach - zwłaszcza kompilowanych - nie dałoby się zrobić czegoś podobnego. Teoretycznie odpowiedź jest pozytywna: przy pomocy zmyślnych sztuczek na stosie wywołań funkcji (technika zwana 'nawijaniem stosu' - stack winding) można uzyskać efekt "zawieszenia funkcji" po zwróceniu wyniku i mieć możliwość powrotu do niej począwszy od następnej instrukcji. Nie jestem jednak przekonany, jak taki feature mógłby współpracować z innymi elementami współczesnych języków programowania, jak choćby wyjątkami. Trudno powiedzieć, czy jest to w ogóle możliwe.

Ale skoro w Pythonie się da, to może już C++2x będzie to miał? ;-)

Triki z PowerShellem #11 – Ćwierkamy

W ramach wyposażania nowozainstalowanego systemu w niezbędne programy, przypomniałem sobie o istnieniu PowerShella. Kiedy jednak chciałem go ściągnąć, spotkała mnie przyjemna niespodzianka: PSh w Windows 7 jest już od razu zainstalowany, więc można go od razu zacząć go używać. Jak sądzę, przyczyni do zwiększenia jego popularności, co jest z pewnością dobrą rzeczą.

Fakt sprawił rzecz jasna, że zaraz zachciało mi się wypróbować go w jakimś nowym zastosowaniu. Padło na wysyłanie update'ów do Twittera, w którym to zresztą niedawno się zarejestrowałem (i wciąż nie wiem, dlaczego ;)). Sprawa na oko nie jest trudna, bo sprowadza się do wykonania jednego żądania HTTP POST. Ale jak wiadomo, diabeł zwykle tkwi w szczegółach. Oto skrypt:

Jednym z owych detali było kodowanie statusu algorytmem dla URL-i (zamieniającym spacje na %20 itd.), wykonywane poprzez System.Web.HttpUtility.UrlEncode - stąd konieczność importowania assembly System.Web. Ale to jest w sumie pikuś.
Znacznie większym "trikiem" jest linijka oznaczona gwiazdką (*). Powoduje ona obejście domyślnego zachowania .NET, który do każdego żądania HTTP typu POST dodaje nagłówek:

Powoduje on wysłanie tak naprawdę dwóch requestów: w pierwszym serwer ma tylko sprawdzić poprawność nagłówków (logowania, na przykład) i zwrócić status 100 (Continue). Dopiero w drugim klient wysyła właściwe dane. Mechanizm ten jest w .NET opakowany przezroczyście i ma zapobiegać niepotrzebnemu przesyłaniu dużych ilości danych w żądaniu, które i tak byłoby odrzucone.
API Twittera jednak tego nie obsługuje i jest to właściwe. Trudno przecież nazwać status, mający maks. 160 znaków, "dużą ilością danych". Lepiej więc przesyłać go od razu, a domyślne zachowanie .NET-a obejść. To właśnie robi zaznaczony wiersz.

Przypomnę jeszcze tylko - gdy ktoś zechciał powyższego skryptu używać do przesyłania tweetów - że uruchomienie skryptu PSh z poziomu zwykłej linii poleceń wymaga parametru -Command i kropki:

Do takiej komendy można np. utworzyć skrót i przypisać mu kombinację klawiszy w celu szybkiego uruchamiania.

Powtórka z DirectX

Za sprawą przedmiotu o nazwie Grafika Komputerowa 3D musiałem ostatnio przypomnieć sobie, jak tak naprawdę i w praktyce koduje się w DirectX. Pewnie brzmi to dziwnie, ale w rzeczywistości przez ładnych kilka miesięcy nie pisałem większych ilości kodu, który by z tej biblioteki korzystał.

Piękna scena ;-)

Projekt, który musiałem teraz napisać, nie był ani trochę ambitny, bo polegał li tylko na wyświetleniu zupełnie statycznej sceny z kilkoma modelami, oświetleniu jej i zapewnieniu możliwości poruszania się w stylu strzelanek FPP. Oczywiście nie było też mowy o żadnych shaderach.

Niby banalne, ale jednak rzecz zajęła mi w sumie jakieś cztery znormalizowane wieczory (czyli od 3 do 4 godzin każdy). Częściowo było tak pewnie dlatego, że pokusiłem się jeszcze o teksturowanie, możliwość regulacji paru opcji renderowania czy bardzo, bardzo prosty menedżer sceny - czytaj: drzewko obiektów + stos macierzy ;)
Wydaje mi się jednak, że ważniejszą przyczyną był nieszczęsny fixed pipeline, którego byłem zmuszony używać. Jeszcze kilka lat temu nigdy bym nie przypuszczał, że to powiem, ale... shadery są po prostu łatwiejsze w użyciu. Porównując chociażby trywialne mieszanie koloru diffuse wierzchołka z teksturą przy użyciu pixel shadera:

oraz stanów urządzenia:

nietrudno jest ocenić, w której znacznie lepiej widać, co faktycznie dzieje się z kolorem piksela. No, chyba że dla kogoś multum stałych w rodzaju D3DABC_SOMESTRANGEOPTION jest czytelniejsze niż po prostu mnożenie ;P

Inną sprawą jest też to, że w DirectX napisanie aplikacji od podstaw jest stosunkowo pracochłonne. Brak "złych" funkcji typu glVertex* ma rzecz jasna swoje zalety, lecz jest też jednym z powodów, dla których tak opłaca się posiadanie własnego frameworka, a może nawet i - tfu tfu - silnika ;-)

Pola i akcesory wewnątrz klasy

Zgodnie z zasadami programowania obiektowego pola klas nie powinny być bezpośrednio dostępne na zewnątrz. Należy jest zawsze opakowywać w akcesory: właściwości lub krótkie metody typu get i set. Z nich właśnie korzysta potem kod zewnętrzny, dzięki czemu nie może on (w dobrze napisanej klasie) niczego zepsuć poprzez - chociażby - ustawienie jakiegoś pola na nieprzewidzianą wartość.
Taka praktyka jest powszechnie przyjęta i raczej nie budzi wątpliwości. Inaczej jest z używaniem tychże pól lub akcesorów wewnątrz klasy, a więc w jej własnych metodach. Tutaj często mamy wybór: czy odwołać się do "gołego" pola, czy też poprzez odpowiednią właściwość/metodę.

Które podejście jest właściwsze? C#/.NET od wersji 3.0 zdaje się to rozstrzygać, umożliwiając półautomatyczne tworzenie właściwości:

Nie ma tutaj nie tylko bloków get i set, ale i ukrytą pod tą właściwością pola. Przy korzystaniu z tego feature'a żadnego dylematu więc nie ma.
Wydaje mi się jednak, że wybór nie jest taki oczywisty i że niekoniecznie należy używać akcesorów wewnątrz klasy. Argumentem przeciw, który od razu przychodzi do głowy, jest troska o wydajność - zwykle jednak przesadzona, bo proste gettery i settery są bez problemu rozwijane w miejscu użycia. Drugim 'ale' jest wygląd kodu w językach bez właściwości; zwłaszcza dotyczy to Javy, w której odpowiednik C#-owego:

roiłby się od getów. W końcu można by się jeszcze pokusić o uzasadnienie na wpół merytoryczne: skoro bądź co bądź prywatne pole jest składnikiem klasy do jej wyłącznej dyspozycji, to dlaczego metody miałyby obchodzić je dokoła zamiast odwoływać się doń bezpośrednio? A może jednak lepiej jest skorzystać z tej dodatkowej warstwy pośredniczącej (mogącej np. wykrywać jakieś błędy)?...

Na razie - mimo całkiem przyzwoitego doświadczenia w programowaniu w językach wszelakich - trudno jest mi na te pytania odpowiedzieć. Ostatnio aczkolwiek skłaniam się ku bezpośredniemu dostępowi do pól w metodach klas. Chętnie poznałbym jednak opinie innych koderów na ten temat.

Jak naprawić GRUB-a

Jeśli oprócz systemu okienkowego rodem z Microsoftu mamy też jakiegoś *niksa, to reinstalacja Windows będzie dla nas miała jeden nieprzyjemny efekt uboczny. Otóż instalatory Okienek radośnie nadpisują sektor startowy dysku (czyli MBR - Master Boot Sector), przez co Windows staje się jedynym systemem dającym się uruchomić w zwykły sposób. Ot, zwyczajowe MS-owe praktyki monopolistyczne ;-)

Jak temu zaradzić? Trzeba oczywiście przywrócić boot sector do właściwego stanu, co oznacza ponowne zainstalowanie używanego przez nas wcześniej bootloadera. W większości przypadków (jeśli mówimy o Linuksie jako drugim systemie) jest nim GRUB; w takim wypadku jego ponowne zainstalowanie wymaga:

1. Uruchomienia Linuksa przy użyciu płytki typu LiveCD, dystrybucji uruchamianej z pendrive'a, itp. Graficzny interfejs jest niepotrzebny, bo jak to zwykle w Linuksie, wszystko można zrobić z konsoli.
2. Następnie należy uruchomić GRUB-a - koniecznie z prawami roota, a więc np. poprzez sudo grub.
3. Z poziomu jego wiersza poleceń należy najpierw ustawić partycję, w której znajdują się pliki z danymi bootloadera. Jeśli nie wiemy, która to, najlepiej użyć polecenia find /boot/grub/stage1. Potem rezultat przekazujemy do komendy root, np. root (hd0,5).
4. Na koniec komendą setup instalujemy GRUB-a na wybranym dysku fizycznym - zazwyczaj jest to setup (hd0).

Tyle powinno wystarczyć, by po ponownym uruchomieniu komputera z tego dysku pojawiło się nam menu bootowania GRUB-a. Przy odrobinie szczęścia oba systemy będą więc uruchamiały się normalnie ;)

Operacja reinstalacja

Wczorajsza premiera Windows 7 to dobry pretekst, żeby nowy system w końcu przetestować - zwłaszcza, że większość opinii, których o nim słyszałem, była zdecydowanie przychylna. W połączeniu z faktem, iż system operacyjny na moim laptopie już od dobrych paru miesięcy domaga się skrócenia swoich cierpień, otrzymujemy tylko jeden logiczny wniosek: czas zakasać rękawy i zabrać się za reinstalację!

Ktokolwiek choć raz zajmował się ponownym stawianiem systemu od zera wie, że czynność ta nie należy do relaksujących. Chociaż drobne komplikacje są praktycznie gwarantowane: a to zapomnimy o jakimś sterowniku, a to zapodziejemy gdzieś numer seryjny systemu, i tak dalej. Posiadanie komputera "zapasowego" (w moim przypadku tradycyjnego - stacjonarnego) znacznie redukuje dolegliwość takich problemów, ale nawet i w tej sytuacji warto się do całej operacji dobrze przygotować.
I właśnie dlatego sporządziłem poniższą listę kontrolną czynności, które dobrze jest wykonać przed rozpoczęciem zabawy w reinstalację systemu. Nie gwarantuję oczywiście, że da się przy jej użyciu uniknąć wszelkich kłopotów. Powinna być ona jednak w dużym stopniu pomocna. A wygląda ona następująco:

1. Zrób kopie zapasowe. Jest to oczywiste, a jednocześnie na tyle ważne, że warto o tym wspomnieć na początku. Niestety we współczesnych systemach dane, które chciałoby się zachować, prawie nigdy nie znajdują się w jednym miejscu. Dlatego właśnie można niemal zagwarantować, że przy robieniu przedinstalacyjnego backupu uda nam się coś pominąć.
   Żeby zminimalizować prawdopodobieństwo tego zdarzenia, warto do robienia kopii podejść dwojako:
   • Najpierw pomyślmy, co chcemy zachować. Edytowane dokumenty czy pisane programy są pewnie najważniejsze, ale to zdecydowanie nie wszystko. Co z ustawieniami używanych przez nas programów? Ulubionymi łączami w przeglądarce? Ciastkami (cookies)? Zapisanymi stanami gier (save'ami)? Co z wszelkiego rodzaju przydatnymi materiałami, które kiedyś ściągnęliśmy nie wiadomo skąd i które jeszcze mogą się przydać? O różnego typu multimediach (muzyka, filmy) też nie wypadałoby zapomnieć. W sumie więc lista robi się całkiem pokaźna i pewnie każdy jeszcze mógłby coś na nią wpisać.
   • Następnie upewnijmy się, że o niczym nie zapomnieliśmy, przeglądając typowe miejsca, w których mogły się ukryć przydatne pliki. Moje dokumenty czy katalog /home będą pierwszym przystankiem. Potem warto odwiedzić Program Files (tudzież /usr/bin itp.) w poszukiwaniu aplikacji, których katalogi mogą zawierać ustawienia do skopiowania. W końcu warto spojrzeć do głównego katalogu dysku, do folderu z plikami ściąganymi z sieci, a w końcu na... Pulpit. Zwłaszcza jeśli tego ostatniego dawno nie sprzątaliśmy ;)
2. Sprawdź, czy masz pod ręką odpowiednie płyty z systemami operacyjnymi. Celowo użyłem tu liczby mnogiej, bowiem nierzadko w grę wchodzi tutaj więcej niż jeden system. W szczególności chodzi więc tutaj o:
   • dysk z systemem, który będziemy instalować - dość oczywiste :)
   • dysk z systemem, którego aktualnie używamy - jeśli jest on inny niż ten instalowany, dobrze jest mieć na wszelki wypadek możliwość powrotu, gdyby up/downgrade okazał się porażką
   • dyski od pozostałych systemów, których używamy - jak chociażby LiveCD jakiegoś Linuksa, jeśli zdarza nam się mieć takowego

   Pamiętaj też o wszelkich kluczach produktów czy numerach seryjnych, jeśli któryś z systemów ich wymaga.

3. Wyciągnij na wierzch dyski ze sterownikami do urządzeń, których używa twój komputer. Większość z nich pewnie będzie działała od razu, ale i tak warto mieć płytki pod ręką. Alternatywnie możemy zaufać sieci i stamtąd zaopatrzyć się w drivery - upewnijmy się jednak wpierw, że posiadamy sterowniki do modemu :)
4. Przygotuj też wersje instalacyjne dużych programów, których używasz do pracy. Chodzi tu o takie rzeczy jak pakiet biurowy, środowisko programistyczne (wraz z wszystkimi SDK-ami!), program graficzny, itp. Nawet jeśli można się w nie zaopatrzyć poprzez sieć, dobrze jest mieć je nagrane na nośnikach DVD/CD.
5. Nie zapomnij o programie antywirusowym i firewallu. Nie ma co, rzecz jasna, wierzyć przeróżnym badaniom stwierdzającym, że niezabezpieczony komputer podłączony do Internetu już po kilku minutach złapie megabajty wszelkiego rodzaju złośliwych programów. Nawet w przypadku Windows standardowy Windows Defender na początek w zupełności wystarczy. Tym niemniej warto w miarę szybko wyposażyć nowy system w aplikacje zabezpieczające.
6. Zaopatrz się w listę małych programów, których używasz. Zachowywanie ich wersji instalacyjnej zwykle nie ma sensu, ale dobrze jest mieć przynajmniej ich nazwy, aby dało się je szybko odnaleźć w sieci i zainstalować na nowym systemie.
7. Znajdź sobie jakieś zajęcie na czas instalacji systemu i większych programów; to może długo potrwać. Niewątpliwym utrudnieniem będzie tu oczywiście fakt, że zajęcie to nie może wymagać komputera ;-) (No, chyba że masz zapasowy :]). Tym niemniej przez te parę godzin warto skupić się na czymś bardziej produktywnym niż obserwowanie paska postępu.

Uff, spora ta lista. Jej rygorystyczne przestrzeganie może nie zawsze jest konieczne, ale nie wydaje mi się, żeby mogło komukolwiek zaszkodzić :) Akurat w przypadku tej nieczęsto (i coraz rzadziej) wykonywanej czynności, jaką jest reinstalacja systemu, zbytnia przezorność na pewno nie zawadzi.