Design for usability!

...czyli Wojciech Cejrowski kontra nowoczesna łazienka:

Nieudokumentowany hack

Dziś zacznę górnolotnie - jak inspektor BHP: W pracy ważna jest higiena.

Co konkretnie kryje się pod pojęciem "higiena", zależy oczywiście od rodzaju wykonywanej pracy. Dla mnie, jako programisty, istotnym pojęciem jest higiena kodu. Tych których to pojęcie bawi, tym bardziej zachęcam do dalszej lektury.

Dlaczego higiena kodu jest ważna? Jest mnóstwo źródeł które wałkują to do granic wytrzymałości układu pokarmowego przeciętnego człowieka, więc ograniczę się do zdawkowego stwierdzenia: jak sobie pościelesz, tak reszta zespołu się wyśpi. Nie będę się tutaj rozwlekał nad kwestiami ogólnymi, bo nie o to dzisiaj mi chodzi. Chodzi mi o rzecz całkiem konkretną.

Jeśli bowiem mam wskazać najbardziej szkodliwy grzech przeciwko higienie kodu, co bym wskazał? Niestosowanie się do przyjętych w danej firmie reguł formatowania kodu? Wprowadzanie zmian podczas gdy continuous build leży i kwiczy? Używanie imion Twoich byłych dziewczyn do nazywania funkcji (tak, tak, są tacy którzy tak robią)?

Nie. Według mnie, najbardziej szkodliwy bywa nieudokumentowany hack.

Tutaj należy się odrobina sprostowania: Jak to? W jaki sposób nieudokumentowany hack może być bardziej szkodliwy niż nazywanie zmiennych kolejnymi słowami Biblii czytanymi wspak? Czy to nie przesada? Otóż nie. Zwróćcie uwagę, że "szkodliwy" to nie to samo co "potencjalnie szkodliwy". Ile bowiem razy widzieliście w swoim życiu zmienną o nazwie asdf? A ile razy widzieliście nieudokumentowany hack? No właśnie. To tak jakby rozważać co jest bardziej szkodliwe dla ludzkości: palenie papierosów czy cracku. Wiadomo, że to drugie wpływa na człowieka bardziej destrukcyjne, ale to papierosy są o wiele popularniejsze i to one pociągają za sobą do piachu wielokrotnie więcej ludzi.

Podobnie jest z nieudokumentowanymi hackami. Są jak papierosy. Wyglądają niewinnie, i byłbym skończonym hipokrytą, gdybym próbował Wam wmówić, że nigdy w życiu nie napisałem ani linijki takiego "sprytnego" kodu.

Problem polega na tym, że czasem nie ma innego wyjścia i trzeba, z różnych względów, zastosować coś co nazwałbym nieortodoksyjnym sposobem rozwiązania problemu. Czyli po prostu hackiem. Każdy z nas bywa w takich sytuacjach i każdy z nas czasami decyduje się na zastosowanie mało eleganckiego rozwiązania. Czy jest w tym coś złego? I tak, i nie - wszystko zależy od umiaru i zdrowego rozsądku.

Co w takim razie jest ewidentnie szkodliwe? Ano brak dokumentacji. Przyjrzyjmy się w skrócie cykolwi życia nieudokumentowanego hacka.

Cykl ten zaczyna się, gdy teściowa zapowiada że za godzinę wpadnie do Twojego domu. Stosujesz hack, zostawiasz napisanie komentarza na później, zamykasz edytor, wkładasz komputer do pancernej skrzyni, żeby dzieciak nie zepsuł, i zadowolony z siebie idziesz odgruzować mieszkanie.

Pół roku później jesteś już w innym projekcie, a inny programista musi wykonać refaktoring kodu. Napotyka na przeszkodę w postaci kilku linii, których przeznaczenia nie jest w stanie odgadnąć. Myśli sobie: "Oho. Hack!"

I tutaj łatwo jest popełnić błąd w ocenie sytuacji. Myślisz, że ten drugi programista podrapie się po głowie, a następnie po prostu będzie kontynuował refaktoring, modyfikując bądź wycinając pozornie bezsensowny kod? Jeśli tak, może zapłacić za Twój nieudokumentowany hack w jeden z możliwych sposobów: wprowadzając błąd, którego nie był w stanie przewidzieć. Pół biedy, jeśli błąd zostanie wyłapany przez testy; gorzej jeśli pojawi się w postaci brzydkiej regresji.

Jeśli nie, będzie musiał odgadnąć znaczenie Twojego hacka. I tutaj płaci również cenę, tym razem tracąc czas. Jak myślisz, ile czasu straci?

Nie wiem. Ale na pewno straci więcej czasu niż Ty potrzebowałbyś na napisanie komentarza. To czysty rachunek ekonomiczny: jeśli wprowadzasz nieudokumentowany hack, to tak jakbyś naiwnie zakładał, że nikt Twojego kodu nie zmodyfikuje, wypali na płycie, wstawi do monstrancji i będzie go czcił aż do momentu, gdy sprowadzi na siebie gniew Pana. Nie, nie, i jeszcze raz nie. Rzadko używam wyrażenia "na pewno", ale tutaj jestem stuprocentowo pewien, że na tym etapie załatwienie tego jak należy zajmie więcej czasu. Powód jest prosty: kiedyś w końcu ten komentarz trzeba napisać. Jeśli Twój następca poświęci czas na zrozumienie hacka, a potem nie napisze odpowiedniego komentarza, to zostawi analogiczny prezent dla swojego sukcesora. To nie jest oszczędzanie czasu, tylko odkładanie go na później - tyle że później znów trzeba będzie hack ponownie odszyfrować i zrozumieć. To trochę jak spłacanie wyłącznie odsetek od kredytu, bez spłacania właściwego zadłużenia.

Jest jeszcze jedna możliwość: Twój następca ani nie będzie w stanie zrozumieć w rozsądnym czasie, co oznacza Twój kod, ani też nie będzie miał dość odwagi żeby go po prostu wyciąć lub przerobić. Zostawi wtedy Twój hack w nienaruszonej postaci i ominie go szerokim łukiem. I najprawdopodobniej tego "łuku" nie udokumentuje, jak znam życie, tworząc jeszcze większy hack, tym razem zupełnie zbędny z obiektywnego punktu widzenia. I w ten sposób, jak złośliwy nowotwór, Twoje kilka linii może utworzyć całą wyspę kodu, którego przeznaczenia nikt nie zna i boi się go ruszyć, żeby wszystko się nie zawaliło.

Tak czy inaczej, jak widać, za nieudokumentowane hacki płacimy zawsze. Każdy z nich jest jak kredyt, który kiedyś trzeba spłacić. Więc lepiej zrobić to szybko, jeśli nie od razu.

Gears a żonglerka ciasteczkami

Jedną z kluczowych cech modułu LocalServer w Gears jest możliwość zabezpieczenia dowolnego ResourceStore'a przy pomocy ciasteczek. Dzięki temu możemy spokojnie przechowywać zasoby w naszym repozytorium, bez obawy o to, że aplikacje z obcych domen będą mogły je odczytać. Na przykład:

var localServer = google.gears.factory.create('beta.localserver');
var store = localServer.createStore('MyStore', 'a=foo');

W tej sytuacji, każdy zasób Pojawia się jednak ciekawy detal. Dokumentacja API Gears mówi wyraźnie:

The combination of name and requiredCookie (along with the domain) identify a unique store.

Wynika z tego, że jeśli w dwóch różnych magazynach, zabezpieczonych przy pomocy dwóch różnych ciasteczek, umieścimy dwa różne zasoby pod tym samym adresem, to potem, odczytując z tego adresu, dostaniemy odpowiednie zasoby, w zależności od wartości ciasteczek. Kontynuując nasz przykład:

store.capture('http://mydomain.com/SomeResource');
store.enabled = true;

Jeśli teraz powtórzymy procedurę, podstawiając 'a=bar' zamiast 'a=foo', otrzymamy dwie wersje zasobu SomeResource. Jeśli za każdym razem zasób ten będzie taki sam, nie zauważymy różnicy. Jeśli jednak obie operacje przechwycenia napotkają różne zasoby, wtedy ustawiwszy przed odczytem ciasteczko a na wartość foo uzyskamy pierwszą wersję zasobu, a ustawiwszy je na bar uzyskamy drugą wersję.

Należy pamiętać, aby w czasie przechwytywania odpowiednie ciasteczko (w naszym przypadku a) miało wartość zezwalającą na dostęp do magazynu, do którego będziemy przechwytywać zasoby.

Wspomniałem wcześniej o pewnym detalu. Mianowicie, nikt nam nie zabroni zadeklarowania magazynów chronionych przez ciasteczka a=foo i b=bar. Co w takiej sytuacji? Chcąc uzyskać dostęp do zasobu posiadającego różne wersje w obu magazynach, możemy wpaść w kłopoty. Jeśli bowiem w momencie żądania zasobu nasza aplikacja będzie posiadała oba ciasteczka, nasuwa się pytanie: którą wersję dostaniemy?

Odpowiedź brzmi: na dwoje babka wróżyła. Nawet nie próbuj się zastanawiać, po prostu zabezpieczaj ResourceStore'y wzajemnie wykluczającymi się ciastkami.

Jeśli kogoś ciekawi konkretny algorytm, według którego wybierany jest zasób do zaserwowania, polecam lekturę zawartości pliku gears/localserver/common/localserver_db.cc, a w szczególności metody WebCacheDB::DoServiceQuery().

Inwencja

Jak wiadomo, każdy inżynier w Google musi się umieć wykazać wiedzą i umiejętnością jej wykorzystania. Na przykład: jak z inwencją wykorzystać kopalnię wiedzy na temat analizy danych tekstowych w sytuacji, gdy złamał się nam uchwyt siatki przy stole pingpongowym? Rozwiązanie jest oczywiste:

Oren Lavie "Her Morning Elegance"

Parę dni temu moja żona wypatrzyła w sieci coś takiego:

Jak widać, żona się przydaje. Klip świetny, i to zarówno pod względem muzyki, jak i aranżacji wizualnej. Normalnie od razu chce się kupić płytę.

Kiedy pokazałem ten teledysk koledze, od razu spytał ile czasu to kręcili. Otóż okazuje się, że niedługo -- zaledwie dwa dni. Inna sprawa, że wcześniej przez cztery tygodnie powstawała komputerowa animacja z trójwymiarowymi makietami aktorów, która potem została klatka po klatce "przełożona" na ruchy prawdziwych ludzi.

I jeszcze jedna ciekawostka: to delikatne i subtelne dziewczę z teledysku, Shir Shomron, w wieku 18 lat zaciągnęło się do izraelskiej armii. Jak widać całe szczęście, że w końcu wylądowała w szkole teatralnej. ;-)

Aktualizacja materiałów o Gears

Drugiego grudnia, zgodnie z obietnicą, ponownie dałem wykład o Gears. Tym razem odbył się on w ramach spotkania Polish Java User Group na AGH. Ponieważ trwał o wiele dłużej niż poprzedni, bo półtorej godziny, również i materiały są nieco mniej prowizoryczne. Dlatego też zaktualizowałem stronę z materiałami. Można tam obejrzeć zaktualizowaną prezentację i pobrać nową przykładową aplikację. Wszelkie komentarze mile widziane.

Gears raz jeszcze

Tak jak obiecałem poprzednio, wykład na temat Gears wygłoszę raz jeszcze. Nastąpi to 2 grudnia 2008, o godzinie 19:00. Miejsce: AGH, Pawilon C2, sala 429, Kraków. Wykład odbędzie się w ramach spotkania Polish Java User Group.

Wszystkich chętnych serdecznie zapraszam.