0xcafebabe -- per aspera ad astra

Dokument pobrany z: http://www.anadoxin.org/blog/windows-i-jego-prawa

Windows i jego prawa
Tagi:  •    •    •  
W związku z dzisiejszym dniem różnego rodzaju żartów, śmiesznych sytuacji i luźnych konsekwencji (zazwyczaj), postanowiłem dodać swoje kilka groszy na temat równie śmieszny co dzień, czyli temat pracy na systemie Windows Vista. Aby było jeszcze śmieszniej, dorzucę jeszcze pewien spoiler, że rolę główną, a jednocześnie pierwsze skrzypce, będzie grało Visual Studio. Osoby uczulone na trolling, spam i naginanie faktów proszone są o zamknięcie zakładki przeglądarki ;).

Nic dziwnego, że niektórzy wpadają na takie genialne pomysły jak World Backup Day (31 marzec), jeśli każdego dnia biedny użytkownik narażony jest na straty danych. Nie z powodu awarii sprzętu – przed tym obronić się w sumie nie można – ale z powodu błędów oprogramowania. Oczywisty jest fakt, że przed błędami software ustrzec się można jedynie w snach, dlatego też nie mam na celu wytykanie, że te błędy istnieją – bo to wie każdy :) – ale tego, w jaki sposób są prezentowane. Dlatego wybrałem ze swojej kolekcji te, które swoją siłą potrafią podnieść brew nad jednym okiem do góry, drugą natomiast spetryfikować nieugiętą mocą beznadziejnej sytuacji. Jednocześnie prezentują one pewne prawa, którymi wydaje się kierować polityka systemu Windows. Praw tych najprawdopodobniej należy skrupulatnie przestrzegać, by software działał doskonale, bezbłędnie, a frustracja użytkownika była wiecznie na poziomie maksymalnie akceptowalnym ;).

Prawo pierwsze – Nie będziesz robił zbyt wielu rzeczy na raz.

Dość standardowy przypadek okienka wyświetlanego podczas crashu programu. Tym razem ów crash nastąpił w Visual Studio, co – z uwagi na naturę programu – może być bardzo bolesne dla ludzi, którzy nie wyrobili w sobie jeszcze nawyku zapisywania dokumentu po kilku napisanych słowach, czy też języków werbalnych, czy programowania. Dane okienko wyskoczyło podczas przechodzenia kursora z miejsca na miejsce, jak widać to też jest operacja w której można umiejscowić buga, którego nie da się złapać żadną obecnie dostępną technologią przechwytywania błędów. Winowajca jest dość dobrze widoczny, jak też i jego wersja, jednak dużym zaskoczeniem jest bardzo wymowny opis usterki, na temat który można by pisać tomy książek. Zapewne z powodu swojej generyczności...

Prawo drugie – Nie będziesz robił rzeczy, o których nie pomyśleli programiści systemu.

Zawsze wydawało mi się, że szacunek czynnika zaskoczenia danego zdarzenia należy do czynności, które zwykle robione są przez użytkownika, nie program. Jednak Microsoft stara się zawsze ulepszać swój system tak, by każdy mógł przeprowadzać nawet skomplikowane audyty systemowe, co widać na obrazku powyżej. Aplet Task Scheduler podpowiada użytkownikowi, że pewna czynność jest bardzo nieoczekiwana, i że jest powodem katastroficznego błędu systemowego, niemożliwego do odratowania. I to dany ekspert może powtórzyć klientowi, nie wgłębiając się w znaczenie danego komunikatu, bo przecież wymagałoby to przeczytania większej ilości tekstu niż kilka zdań, a przecież za to mu nie płacą. :)

Prawo trzecie – Nie będziesz wiedział lepiej.

Czasami człowiek ma takie uczucie, jakby wiedział o istnieniu jakiegoś faktu. Na przykład, gdy pokazuje się okienko „Windows wyłączy się za minutę” podczas flashowania jakiegoś firmware, wypalania płyty DVD z prędkością 2x, lub też podczas tworzenia ważnego snapshot'a maszyny wirtualnej na przeciążonym systemie. Na nic płacz, próby przeprosin i banalne usiłowania naprawy sytuacji, ponieważ tak naprawdę system nie widzi żadnego problemu w swoim działaniu. Wszystko jest idealnie dopracowane, suma kontrolna każdej struktury i liczniki referencji świecą przykładami, a problem? To chyba ma użytkownik, nie system :)

Prawo czwarte – Nie będziesz się lenił.

Pisanie programów to podobno trudna sztuka, wymagająca dużej cierpliwości do schematycznego postępowania. Linijka kodu, kompilacja. Druga linijka kodu, ponowna kompilacja. Jeśli wszystko się nadal zgadza, następuje trzecia linijka kodu i trzecia kompilacja. Ale co się dzieje? Nagle kompilacje przestają działać, a zamiast błędów w kodzie źródłowym pokazuje się błąd w kompilatorze, z prośbą o naprawę! Ponowne próby kompilacji powodują ten sam problem, aż programista sięga po ostatnią deskę ratunku: metodę have you tried to turn it off and on again? Metoda okazuje się skuteczna, co tylko potwierdza jej 99 procentową skuteczność. Zwiększa to poczucie zakłopotania i poziom mętliku w mózgu, jednak podczas myślenia na ten temat, w głowie zaczyna dominować raczej pytanie: jak naprawić coś, co jest instalowane w postaci zepsutej?

Prawo piąte – Nie będziesz zachłanny.

To normalne, że człowiek chce więcej. Więcej pieniędzy, większe mieszkanie, większy samochód. Dlatego dobry system temperuje nieco użytkownika, by nie popadł w spiralę żądzy i władzy, bez względu na to, czy chodzi o większe pieniądze, czy większe wersje programów. Pozostaje jedynie dziękować opatrzności, że ktoś opracował koncept braku konieczności deinstalacji w tym instalatorze, czyżby iluzja oferowania jakiegoś wyboru? ;) Mam nadzieje, że brak pamięci o tym, co stało się po naciśnięciu przycisku Next, nie powinienem tłumaczyć za pomocą psychologicznego pojęcia wyparcia ze świadomości traumy.

Prawo szóste – Będziesz chodził jak zegarek, będziesz tańczył jak zagramy.

Muszę napisać, że na początku ciężko było mi zrozumieć prawdziwy sens tego komunikatu. Nie mogłem za bardzo znaleźć prawdziwego powodu, dla którego ten problem mógłby być problemem wielkim na tyle, by anulować całą operację otwierania pliku i zasygnalizowania błędu użytkownikowi, by spróbował tego samego, ale przy użyciu wpisu w menu. Jedyna rzecz, która przyszła mi do głowy to fakt, że chyba ktoś z drużyny Visual Studio nie dostał jakiejś wypłaty i rozwiązał umowę ;). Tak czy inaczej, podany screenshot jest również swojego rodzaju projekcją sytuacji, gdy prawo drugie naginane jest zbyt często. O tym, jak bardzo system cierpi na usiłowaniu obsługi nieprzewidzianych okoliczności, świadczy błąd rysowania okienka w prawym dolnym rogu, występujący wtedy, gdy zmienimy wielkość globalnej czcionki okien dialogowych w ustawieniach Windowsa o 1 punkt w górę.

Prawo siódme – Nic nie jest takie, jakie może się wydawać.

Błąd z cyklu Z Archiwum X, jest prawdopodobnie dowodem na istnienie życia pozaziemskiego. Dlaczego? Ponieważ na naszej planecie stwierdzenie „Brak błędu” oznacza brak błędu, natomiast w Visual Studio jest kolejnym, jednym z wielu powodów (wielu błędów), którymi można oznaczyć dany błąd. Prawdopodobnie na ich planecie istnieją też wpisy w instrukcjach obsługi programu typu: „Jak rozwiązać problem ze znanym problemem: brak błędu?” - jednak nie posiadam takich marsjańskich wersji, osoby posiadające nawet zniszczone kopie proszone są o kontakt ;).

Prawo ósme – mów wyraźnie, wyrażaj się jasno, bądź konkretny i precyzyjny.

Jednym z wielu technik dostosowywania produktu software do wersji stabilnych, jest redukcja niepotrzebnych funkcji, by zmniejszyć ilość występowanych (lub potencjalnych) błędów. Jeśli to nie wchodzi w grę, stosować można też np. negatywne decyzje przy napotykaniu pomysłów co do funkcji, które nie będą stały bezpośrednio na ścieżce, którą w zamyśle autorów miałby podążać program. Nie wiem w jaką grę grali panowie z Microsoft, usuwając funkcję zastosuj dla wszystkich, ale na pewno nie była to gra w ułatwienie użytkownikowi pracy z systemem. Dobra strona jest taka, że by poznać prawdziwe Zen obsługi Windows, najpierw należy wyklikać podstawy, zupełnie jak Karate Kid malował płot podczas swoich nauk u wielkiego mistrza.

Prawo dziewiąte – to, co powstaje w Fight Cl... Visual Studio, zostaje w Visual Studio.

Niektórzy chyba wzięli sobie film Fight Club za bardzo do serca, patrząc na ilość zaalokowanej pamięci. Wszelkie alokacje, referencje, struktury, bajty odczytane z plików, zapewne zostają w puli zaalokowanych regionów managera pamięci Visual Studio, który za to z kolei ma dość łatwą pracę, która nie przewiduje zapewne konceptu zwalniania pamięci. Chociaż, z drugiej strony, zawsze można się pochwalić, że naciukało się tyle klas w C++ ;)

Prawo dziesiąte – Przezwyciężaj swoje ograniczenia!

Instalacja niektórych programów potrafi popychać nas w stronę samodoskonalenia. Bo czymże jest codzienne poruszanie się w ramach własnych ograniczeń, jeśli nie staniem w miejscu? A czymże jest stanie w miejscu, jeśli nie poruszaniem się, w tył? Otóż właśnie. Z tego też powodu niektóre aplikacje pompują w nas determinację, która rozciąga nasze ograniczenia, otwiera nam oczy coraz szerzej, byśmy widzieli lepiej, byśmy następnego dnia do dyspozycji mięli więcej narzędzi niż dzień wcześniej, do walki z przeciwnościami losu, z trudnymi decyzjami i z naszymi wrogami. Ale nie jest to rzecz łatwa. Na dowód owej trudności, polecam każdemu na odnalezienie funkcji „Wyjście” w programie „Windows Explorer”...

Prawo jedenaste – Nie zadawaj głupich pytań, jeśli nie chcesz być głupio olanym.

Jest to przykład zaawansowania technologicznego rendererów błędów w Visual Studio. Treść błędu zostaje rekurencyjnie wygenerowana z podciągu ciągu znaków otaczających ten błąd. Oczywisty zysk pamięci! Stosowanie takich trików wydaje się być całkowicie uzasadnione, biorąc pod uwagę fakt opisany w prawie dziewiątym, czyli brak funkcji zwalniania zaalokowanej pamięci...

Prawo dwunaste – Ciesz się z tego, co masz.

Windows wprowadził w świat graficznych interfejsów użytkownika wiele istotnych zmian. Przykładowo, uwstecznił nieco postrzeganie środowiska programowania GUI. To znaczy, nakazał społeczności wierzyć w wysoką wagę faktów o wyższości kernelowego rozwiązania rysowania GUI nad rysowaniem z poziomu user-mode, jednocześnie milcząc zupełnie na temat kompletnego braku wsparcia dla dynamicznego rozmieszczania kontrolek w oknie, czyli wsparcia dla Layout'ów. Wynik prezentowany jest na zrzucie ekranu powyżej – pytanie postawione poza oknem rysowane jest 25 razy szybciej, niż konkurencyjne rozwiązania. Ponieważ przecież nikt nie dopuści się tak niedorzecznej rzeczy, jak skorzystanie z możliwości zwiększenia globalnej czcionki okien dialogowych o 1 punkt! Poza tym, przecież sam wiesz, co przed chwilą zrobiłeś, więc wszelkie okna dialogowe wynikające z twojej akcji są jedynie demonstracją dobrej woli programistów, więc powinieneś cieszyć się, że w ogóle dostałeś jakiś wybór.

Prawo trzynaste – Nie rozdrapuj starych ran, by nie zaczęły krwawić.

Okazuje się, że Microsoft czasem przyznaje się do popełnionych przez siebie błędów. Mimo tego, że robi to po cichu, ale stara się zadziałać na podświadomość programisty, by odstąpił od pewnego zamiaru, bez mówienia mu tego wprost. Jest tak np. podczas zgłębiania dokumentacji na temat struktury VersionInfo w zasobach plików wykonywalnych PE. Widać strona z tabelą „prawidłowych identyfikatorów” jest tak bardzo dla Microsoftu wstydliwa, że aż się schowała.

Prawo czternaste – Szanuj środowisko.

Siedząc w pracy długie godziny, zużywamy dużo energii, swojej, jak i energii elektrycznej. Jako, że nasz opiekuńczy rząd nie zastanawia się nad naszą energią, ponieważ zostaje ona potem przekształcona na podatek trafiający do ich sakiewek, jak też i energią elektryczną, ponieważ ona też zostaje potem przekształcona na ich sakiewki, to nasi przyjaciele w Microsofcie opracowali (kolejną już) rewolucyjną metodę na ograniczenie zużywania energii przez monitor LCD. Poprzez wyłączenie reakcji odpowiednich, najmniej w aktualnej chwili używanych, pikseli na ekranie, są w stanie zmniejszyć pobór prądu monitora LCD o jakieś 15%. Wybór, które piksele są w danej chwili ważniejsze, a które mniej, jest dokonywany przez opatentowane technologie dostępne tylko w najnowszych wersjach Windows. Reasumując, to jest feature, nie bug!

Prawo piętnaste – Bój się Ninja!

Seria błędów, które byłyby wszędzie, gdyby programowaniem Windows zajmowali się wojownicy Ninja. Nie dość, że nie wiadomo dlaczego wystąpił dany błąd, to nie wiadomo też gdzie on jest. Ani też kiedy się pojawił. Właściwie to nie wiadomo niczego, poza tym, że jest. I będzie nadal. Jeśli minie podczas jednego restartu, być może pojawi się kiedy indziej. Ale nie jest to pewne, bo prawdziwy błąd Ninja jest taki, jak jego programista, czyli potężny i nieprzewidywalny, pojawiający się na chwilę, by potem zniknąć, ale skutecznie zostawiając po sobie ten charakterystyczny strach, umacniający pamięć o nim w każdej chwili naszego dalszego istnienia. Ale pojawił się, oj tak, a to, co zrobił, wprawiło w osłupienie każdą instrukcję kompilatora tak bardzo, że nikt nie jest w stanie powiedzieć co się tak naprawdę stało...

Jak widać, praca z systemem Windows jest rzeczywiście łatwa, przyjemna, a czasami wręcz śmieszna i rozrywkowa. Ciężko czasami odmówić sobie tej przyjemności pracy w tym kontrolowanym środowisku, gdzie uczucie bezwładności występuje na porządku dziennym, uczucie, że jest się tylko szarą boją na morzu, pyłem na wietrze, jest się targanym przez siły zbyt duże, by się im przeciwstawiać. Czasami myśli te mogą prowadzić do chęci spróbowania innych polityk korzystania z komputera, czyli innego systemu operacyjnego – jednak w przypadku powstania, takie myśli należy jak najszybciej odrzucić, bo kilka sekund myślenia o tym za długo, i stajemy się od razu przebrzydłym Linuxowcem (nie polecam!).

PS.

Prawo szesnaste – Integracja jest drogą ku przyszłości!

Usługi typu Cloud Computing świecą w oddali, kusząc swoim blaskiem użytkowników, jak lampa owadobójcza kusi komary. Prastara chęć posiadania ma swoje echo wśród dzisiejszych czynności w chmurze, gdzie w łatwy sposób możemy dodawać sobie nowych przyjaciół, nawet jeśli ich nie znamy. Wrodzona próżność i egocentryzm nakazuje nam myśleć, że inni wciąż śledzą każdy szczegół naszego życia, skrupulatnie opisywany na naszej ścianie nowości, która pełni rolę narzędzia wspomagającego crowdsourcing żmudnej pracy wypełniania teczek na każdego obywatela kraju. Aby temu zapobiec, w moim przypadku, sugeruję proste rozwiązanie:

Ale... gdzie w tym prawie znajduje się błąd? Profil na Facebooku jest błędem ;)