HTML nr 5 – książka

Właśnie skończyłem lekturę książki Wprowadzenie do HTML5 autorstwa Bruce’a Lawsona i Remy’ego Sharpa, wydanej w wersji polskiej przez Helion. Zakupiłem ją z nadzieją, że wprowadzi nieco porządku w cały ten buzz odnośnie HTML5, którego trudno nie zauważyć, jeśli tylko robi się cokolwiek chociaż pośrednio związanego z tą tematyką. I od razu mogę stwierdzić, że pod tym względem moje oczekiwania zostały rzeczywiście spełnione.

W książce można bowiem znaleźć przegląd kilku elementów składających się na standard HTML5 oraz paru technologii pobocznych, które formalnie do standardu nie należą, ale często są uwzględniane pod parasolem szerszej definicji całego zjawiska/technologii/ruchu/trendu/czegokolwiek-czym-to-jest. Wśród nich mamy takie podstawy jak nowe elementy strukturalne, nowe i przedefiniowane znaczniki opisu tekstu, poszerzone możliwości formularzy i różne drobne usprawnienia składniowo-semantyczne. Nie są one może tak ekscytujące jak “gwiazdy” technologii HTML5, ale fakt ich porządnego uwzględnienia jest według mnie tym bardziej godny uwagi.
Oczywiście nie zabrakło też wielu “nowych wspaniałych API”, dzięki którym możemy chociażby tworzyć SQL-owe bazy danych po stronie klienta i wykonywać szereg innych niezbędnych a właściwych dla stron WWW czynności ;D I tak możemy na przykład dowiedzieć się, co to właściwie jest ten Canvas, w jaki sposób zapewnić wsparcie dla techniki drag & drop i do czego w zasadzie mogą przydać się te całe webowe gniazdka (czyli Web Sockets). Ponieważ wszystko pokazane jest na prostych przykładach, opanowanie podstaw każdego z tych rozwiązań dla ogarniętego programisty nie stanowi żadnego problemu.

Kluczowym słówkiem są tu jednak owe ‘podstawy’. Chociaż różne tematy są tu opisane z różnym poziomem szczegółowości – czasem nawet zbyt dużym, jak choćby w przypadku <audio>/<video> – to jednak w żaden nie jest opisany wyczerpująco. Nie wskazuję tego jako wady, bo przecież mówimy o książce z wyraźnym napisem “wprowadzenie” na okładce. Poza tym w prawie każdym miejscu, gdzie autorzy świadomie coś pomijają, podawane są inne (zwykle internetowe) źródła, z których można czerpać bardziej szczegółowe informacje. Trzeba też powiedzieć szczerze, że właściwie żaden z opisywanych tematów (może poza Canvasem) osobno nie prezentuje się jako specjalnie skomplikowany bądź obszerny. Skondensowane wprowadzenie może więc równie dobrze być całkowicie wystarczające.

Podsumowując więc: lektura okazała się jak najbardziej pożyteczna. Książkę czyta się szybko i bez wielkiego wysiłku, a jednocześnie można się z niej dowiedzieć wielu interesujących rzeczy. Jeśli nawet nie zamierzamy – za przeproszeniem – programować w HTML5, to przeczytanie tej książki da nam ciekawy wgląd w technologie będące podobno przyszłością Internetu czy nawet aplikacji jako takich.

Papier 2.0

Od kilku miesięcy popularność na świecie (w znacznie mniejszym stopniu w Polsce) zdobywają tzw. tablety, czyli komputery przenośne bez klawiatury, a jedynie z ekranem dotykowym. (Ich najbardziej znanym przykładem jest oczywiście iPad). Jako jedno z ich (niezbyt licznych) zastosowań podaje się możliwość wygodnego przeglądania stron internetowych, czytania kolorowych magazynów w wersji elektronicznej oraz e-booków, czyli książek. Co do pierwszych dwóch, mógłbym się ewentualnie zgodzić. Ale co do ostatniego – absolutnie nie, co nie powinno w sumie zaskakiwać. Długotrwałe męczenie oczu podążaniem za jednorodnym tekstem książki na dużym, świecącym i połyskliwym ekranie – połączone z trzymaniem w rękach urządzenia o nietrywialnym przecież ciężarze – trudno bowiem kojarzyć z jakimkolwiek komfortem.

Do czytania potrzeba więc urządzenia zarówno mniejszego, jak i bardziej do tego przystosowanego – choćby pod względem rodzaju wyświetlacza, bardziej imitującego rzeczywisty papier. Odpowiednie technologie istnieją już od ładnych kilku lat i zostały zastosowane w kilku produktach – z różnym skutkiem. Świeżym przykładem jest Kindle 3, którego to ostatnio sobie sprawiłem i w związku z tym pozwolę sobie podzielić się wrażeniami z jego użytkowania :)
Ale najpierw odpowiem na nasuwające się zapewne pytanie: a po co komuś coś takiego? Posiadanie przenośnego czytnika dokumentów tekstowych (w tym e-booków) okazuje się jednak bardzo przydatne, jeśli czytamy ich dużo lub jeśli często zdarza nam się przymusowe oczekiwanie w warunkach niepozwalających na wyciągnięcie “cięższego sprzętu” elektronicznego (przykładem takich sytuacji są chociażby przejazdy komunikacją miejską). Mogę z pełnym przekonaniem stwierdzić, że możliwość lektury e-booka, dokumentacji, zachowanych wcześniej notek z blogów czy artykułów z sieci w komfortowej, niemęczącej oczu i rąk formie jest doprawdy bardzo wygodna.

Wśród urządzeń, które na to pozwalają, Kindle prezentuje się przy tym bardzo pozytywnie. Wrażenia wzrokowe po dłuższej lekturze są mniej więcej takie, jak po czytaniu kolorowego albumu drukowanego na śliskim papierze. Nie jest to jeszcze matowość kart książki znalezionej u dziadka na strychu, ale fakt ten w niczym nie przeszkadza :) Sam zastosowany tu e-papier posiada doskonały kontrast i ostrość obrazu, a jedyne obserwowalne odblaski (niezbyt duże) pochodzą jedynie z jego plastikowej osłonki. Ogólnie z urządzenia można korzystać tak, jak z tradycyjnej książki.
Lista formatów dokumentów, które Kindle obsługuje bezpośrednio lub pośrednio, jest ponadto całkiem długa. Są na niej zarówno pozycje specyficzne dla czytników (np. MOBI), jak i bardziej znane PDF czy HTML (ten pierwszy odczytywany jest z marszu). Wreszcie jest tu także łączność WiFi (opcjonalnie też 3G) i przeglądarka stron WWW oparta na silniku WebKit (tym od Safari lub Chrome) o zaskakująco dużych możliwościach. Dzięki niej – oraz za pomocą usługi Read It Later i autorskiego skryptu w PHP – udało mi się na przykład znaleźć eleganckie rozwiązanie pewnego use case‘a, który pojawia się niemal natychmiast po rozpoczęciu korzystania z czytnika. Chodzi mianowicie o szybkie zachowanie artykułu znalezionego w sieci (na zwykłym komputerze) do późniejszego przeczytania z użyciem Kindle. Oferowany w tamtejszej przeglądarce tryb Article Mode potrafi bowiem niezwykle skutecznie pozbyć się ze strony wszystkiego, co nie jest głównym tekstem, a samą treść sformatować w sposób eliminujący konieczność przewijania w poziomie.

Obecność w pełni funkcjonalnej przeglądarki przestaje być zaskakująca, gdy weźmiemy pod uwagę to, że Kindle – podobnie jak większość urządzeń elektronicznych bardziej złożonych od mikrofalówki – działa pod kontrolą odpowiednio zmodyfikowanego Linuksa. A to od razu rodzi pytanie co do ewentualnego… tworzenia aplikacji na tą platformę :)
Odpowiedź jest tu także dość typowa i brzmi: albo zhakuj urządzenia i zdobądź prawa roota (z wiadomym skutkiem dla gwarancji), albo użyj autoryzowanego SDK. Ta druga opcja na razie jest dostępna niestety tylko dla wybranych, gdyż SDK (zwane KDK) jest obecnie w fazie na wpół zamkniętej bety. Miejmy nadzieję, że prędko zostanie ono wydane publicznie – albo że przynajmniej moje zgłoszenie chęci udziału w testach zostanie rozpatrzone pozytywnie ;P

Standardy kodowania jako choroba dziedziczna

Ponieważ programowaniem zajmuję się już od dość długiego czasu, mam w tym nieco doświadczenia praktycznego. Przez ten czas zdążyłem też zmienić część swoich poglądów na niektóre rzeczy z tym związane. Mówiąc trochę górnolotnie: stałem się bogatszy o wiedzę z życia wziętą :)
Jedną z takich nauczek życiowych jest to, by nie ufać zbytnio standardom, zaleceniom i innym tzw. dobrym praktykom podpowiadających (a czasem wręcz nakazujących), jak powinien wyglądać pisany przez nas kod. Dotyczy to na przykład instrukcji rzekomo złych “z natury” i innych tego rodzaju przesądów. Tak, uważam określenie ‘przesądy’ za uprawnione w wielu przypadkach.

Nie jestem ponadto odosobniony w tych poglądach – ba, wśród swoich kolegów po fachu mógłbym wskazać wielu kilku, którzy są pod tym względem nawet bardziej… radykalni :) Jak już jednak wspomniałem na początku, nie zawsze tak było. Kiedyś miałem bardziej rygorystyczne i pryncypialne podejście do kwestii tego, jak kodować należy lub nie należy. Skąd brałem dla niego uzasadnienie, jeśli nie z praktyki, której wtedy zbyt wiele jeszcze nie miałem?…
Ano właśnie – tu dochodzimy do sedna. Przekonanie to brało się głównie – jeśli nie wyłącznie – ze wszelkiego typu materiałów pomocniczych do nauki programowania: książek, kursów, artykułów, czasem dokumentacji. Choćby nie wiem jak techniczne i merytoryczne były te teksty, w każdym – co do jednego, z moim skromnym dziełem włącznie – znajdą się rady, zalecenia, wskazówki i inne “metainformacje” odnośnie tego, jak programować należy – a nie tylko o tym, jak można. Czy ktoś widział w kursie programowania opis instrukcji goto (że pozwolę sobie użyć najbardziej typowego przykładu), który nie zawierał chociaż śladowej wzmianki o tym, iż.. no, w zasadzie to nie należy jej używać?… …Tak myślałem ;-)

Nasuwającą się od razu repliką w obronie autorów jest sugestia, że w sumie to przecież całkiem dobrze, iż uczą oni nowicjuszy tego, co sami musieli wcześniej wypracować przez lata. Nie wątpię wręcz, że taka intencja – oszczędzenia początkującym trudności – rzeczywiście autorom przyświeca. Dodają oni do pisanych przez siebie tekstów, kursów, tutoriali, itp. liczne wskazówki, te wszystkie dos and don’ts właśnie dlatego, iż wierzą w to, że w ten sposób pomogą swoim czytelnikom od razu, już na starcie kodować w sposób przejrzysty, efektywny, elastyczny, elegancki, “łatwo konserwowalny”, i tak dalej.

“Pamiętaj synku, by się zabezpieczać:
dawaj const, gdzie tylko możesz.”
(Źródło obrazka)

Chwalebne intencje – nie da się ukryć. Ale nietrudno jest wskazać przynajmniej dwa błędy takiego rozumowania. Pierwszym jest założenie, że każdą wiedzę i każdą umiejętność da się przekazać innym – czyli że w ogóle istnieje “droga na skróty”, niejako omijająca zdobywanie doświadczenia praktycznego w danej dziedzinie (w tym przypadku w programowaniu). Żeby stwierdzić, że to jednak nieprawda, wystarczy zastanowić się, czy ukończenie podstawowego kursu szachów u arcymistrza da nam od razu ELO 2500. Niestety w rzeczywistości dojście do takiego poziomu wymaga dziesiątków tysięcy rozegranych partii – i nic się na to nie poradzi.
Drugim błędem jest przyjmowanie, że przekazywane mądrości są faktycznie odpowiednie dla odbiorców. Nie, nie chcę wcale sugerować, że ktoś może mieć traumę z powodu wczesnych doświadczeń z hermetyzacją czy wzorcem fabryki ;) Raczej sugeruję, że przywiązując zbyt wielką wagę do przekazywanych zaleceń, początkujący mogą stracić wiele czasu na dopasowywanie swoich pierwszych programów do ich wysoko zawieszonej poprzeczki – najczęściej zupełnie niepotrzebnie. Gra w zgadywanie liczby, kółko i krzyżyk czy tetris nie potrzebują zwykle skomplikowanej, wewnętrznej architektury z dokładnie zaprojektowanymi relacjami między klasami i starannym oddzieleniem interfejsu od implementacji. Prosi się to bowiem o przytoczenie znanego powiedzenia na temat artylerii i pewnego gatunku insekta :)

Tak oto okazuje się więc, że zalecenia i rady tudzież – szumnie nazywane – standardy kodowania są “dziedziczone” przez początkujących programistów od autorów książek, kursów i tutoriali, którzy je tam umieszczają pomiędzy objaśnieniami kolejnych konstrukcji językowych czy elementów API. A że ponadto, jak opisałem wyżej, standardy te zbyt wcześnie poznane mogą być nie tyle nawet zbędne, co wręcz szkodliwe, pozwalam sobie nazwać je ‘chorobami dziedzicznymi’. Nic tak bowiem nie trafia do wyobraźni jak obrazowe porównanie ;>
Zakończyć chcę jednak optymistycznym akcentem. Otóż choroby te są jak najbardziej uleczalne. Terapia jest też nieskomplikowana i – jak sądzę – skuteczna. Trzeba po prostu kodować, kodować i jeszcze raz kodować :)

Książka o szablonach

Dzisiaj chciałem polecić pewną książkę, która jest prawdopodobnie jedyną pozycją, opisującą w tak dokładny sposób pewne bardzo obszerne, a ważne i zwykle nie do końca znane zagadnienie. Chodzi o szablony języka C++ i książkę pt. C++. Szablony. Vademecum profesjonalisty (autorzy: D. Vandevoorde, N.M. Josuttis), która o nich właśnie traktuje.

O szablonach co nieco wie prawie każdy programista zajmujący się C++, ale często wiedza ta jest raczej powierzchowna – choć niekiedy zupełnie wystarczająca. Okazuje się jednak, że ten element języka może być wykorzystany na wiele bardziej interesujących sposobów niż tylko do tworzenia klas pojemnikowych podobnych do tych z STL. We wspomnianej książce znajdziemy kilka przykładów takiego zaawansowanego operowania szablonami, łącznie z metaprogramowaniem.
Naturalnie jest tam także dokładny opis wszystkich możliwości języka C++ związanych z szablonami, obejmujący także te mniej znane ich elementy. W skrócie można powiedzieć, że znajdziemy tak niemal wszystko, co każdy programista C++ chciałby wiedzieć o szablonach, lecz boi się zapytać ;)

Taka specjalistyczna wiedza (dotykająca często szczegółów tego, w jaki sposób sam kompilator traktuje kod z klauzulami template<>) nie jest oczywiście niezbędnie potrzebna. Tym bardziej, że większość z opisanych “sztuczek” (jak np. rozpoznawanie cech typów) została już zaimplementowana w ogólnodostępnych bibliotekach (głównie częściach Boosta). Mimo to chyba warto mieć książkę, która cały bardzo ciekawy (przynajmniej wg mnie ;P) temat szablonów opisuje bardzo dogłębnie.

Podsumowanie magicznej siódemki

Pozwolę sobie poczynić zupełnie niekoderski wpis, jako że od ostatniego podobnego minęło już dobrych kilka miesięcy. Myślę, że mogę od czasu do czasu pozwolić sobie na coś takiego :) Zwłaszcza, że mam ku temu pewną dość szczególną okazję…

Dotarłem właśnie do końca niezbyt może ambitnego, za to niezwykle popularnego kawałka literatury. Mówię tu oczywiście o serii książek pod tytułem Harry Potter i jeszcze coś, której to (prawdopodobnie) ostatni tom niedawno trafił na półki polskich księgarń. Jak nietrudno się domyślić, mam nieodpartą ochotę, aby podzielić się wrażeniami z lektury ;P
I muszę przyznać, że jestem nią w pełni usatysfakcjonowany. Opowieści o przygodach Pottera już od jakiegoś czasu nie były bajkami dla dzieci, lecz chyba dopiero w tym ostatnim tomie ujawniło się, iż mamy tutaj do czynienia z całkiem dojrzałą pozycją z gatunku fantasy. Pod względem fabularnym też nie można jej wiele zarzucić, chociaż wiadomo, że dla wszystkich najważniejsze były suche fakty: jak to się skończy, kto zwycięży, kto przeżyje?… Tym niemniej cieszy to, że ostatecznie kilka spraw wyjaśnia się na sposób daleki od przewidywań: ci, którzy wydawali się być charakterami bezwarunkowo czarnymi, nie zawsze takimi się okazują, a na kryształowych obliczach postaci wyjątkowo “czystych” pojawiają się wyraźne rysy.

Koniec sagi o młodym czarodzieju to pewnie najlepsza okazja, aby zastanowić się, dlaczego historie te stały się aż tak popularne. Bo chyba stwierdzenie, że obecnie przy sprawnym marketingu można wypromować cokolwiek, nie będzie w pełni zadowalające (miejmy przynajmniej taką nadzieję). Ten produkt musi mieć po prostu takie obiektywne coś, co zadecydowało o jego sukcesie. Według mnie lista tych “cosiów” zawiera przynajmniej trzy pozycje:

• Dopracowany i bogaty w szczegóły świat. Książki o Potterze są osadzone w świetnie zaprojektowanych, fikcyjnych realiach. Może nie mają one rozmachu tolkienowskiego Śródziemia, ale bezsprzecznie działają na wyobraźnię. Dodatkowo świetnie sprawdzają się jako miejsce akcji dla historii dowolnego typu, od przygodowych po obyczajowe.
• Historia oparta na sprawdzonym niezliczoną ilość razy motywie. Oto bohater, który nagle znajduje się w zupełnie nieznanych dla siebie okolicznościach i musi przy tym spełnić ogromnie trudną i niezwykle ważną misję, od której zależy bardzo, bardzo wiele. Seria Star Wars, Matrix, Władca Pierścieni, większość opowieści o superbohaterach, a nawet część starożytnych mitów i chrześcijańskie ewangelie – wszystkie opierają na wariantach tego pomysłu. Nie inaczej jest z Harrym Potterem, który z każdym kolejnym tomem coraz bardziej czuje na sobie ciężar nieuchronnego przeznaczenia.
• Dopasowanie stylu do grupy docelowej. Wyjątkową cechą książek o Potterze jest to, że zdają się dorastać wraz ze swoim czytelnikiem. O ile pierwsze części są prostymi i efektownymi historyjkami dla dzieci, o tyle dalej rozwijają się w znacznie bardziej rozwinięte (także objętościowo) powieści. Pomijając potwornie nudny i okropnie infantylny tom szósty, są one też świetnie skrojone pod względem fabularnym i stylistycznym. Na początku dominują w nich dialogi i wartka akcja, lecz potem (czyli po odpowiednim wyrobieniu czytelnika) autorka pozwala sobie – i słusznie – na dłuższe popisy narracyjne.

Czy to prosty przepis na sukces? Bynajmniej. Połączenie tych wszystkich elementów w spójną i atrakcyjną całość to z pewnością wielka sztuka.
Najciekawsze jest jednak to, że powyższą receptę można wcale nieźle dopasować do… wytworów działalności koderskiej. W końcu tu też liczy się dobry projekt, korzystanie ze sprawdzonych rozwiązań oraz dobra treść i forma. Efekty może nie są aż tak “magiczne”, ale niekiedy udaje się nimi zachwycić nawet mało obeznanych z tematem mugoli ;-)

‘No i co tu jest źle?’ w wersji książkowej

Kiedy ma się dość pokaźną biblioteczkę książek, czasami natrafia się na pozycję, która nie wiadomo skąd się w niej wzięła. Pytanie takie staje się tym bardziej uzasadnione, gdy rzeczoną książkę otworzymy, przekartkujemy i pobieżnie przeglądniemy, by po krótkim czasie uznać, że najchętniej widzielibyśmy ją w… punkcie skupu makulatury :P
Coś takiego przytrafiło mi się zupełnie niedawno. Książką o której mam taką “pochlebną” opinię, jest dziełko opatrzone tytułem Jak NIE programować w C++. Jeszcze ciekawszy jest chyba podtytuł, który mówi, że wewnątrz znajdziemy dokładnie 111 programów z błędami oraz trzy działające. Statystyka jest imponująca, ale o co tak naprawdę tutaj chodzi?… Autor przedstawia nam mianowicie coś w rodzaju zbioru koderskich zagadek do samodzielnego rozwiązania, które polegają oczywiście na znalezieniu błędu w przedstawionym kawałku kodu.

Jak podejrzewam, celem tej książki w zamyśle autora było ustrzeżenie programistów C++ przez różnego rodzaju typowymi błędami, jakie mogą się zakraść do pisanego przez nich kodu. Cel to chwalebny, chociaż dość utopijny – w końcu nie wystarczy wiedzieć, na czym błąd polega, aby w magiczny sposób już nigdy więcej go nie popełnić. Trochę więcej wątpliwości mam natomiast co do obranej metody. Nie wiem, w jaki sposób obejrzenie ponad stu błędnych kodów ma sprawić, że będziemy częściej pisali poprawny kod. Spodziewałbym się raczej podświadomego nauczenia się prezentowanych tam złych przykładów i ich spontanicznego stosowania w rzeczywistych programach, co raczej nie ułatwiłoby nikomu pracy :)
Byłoby oczywiście świetnie, gdyby przykłady te były jedynymi niepoprawnymi kawałkami kodów, z którymi przychodzi nam się mierzyć. Ale przecież jest to odległe od prawdy o całe lata świetlne. Jako koderzy sami nieuchronnie produkujemy niepoprawny kod, który co rusz musimy korygować. Prawdopodobnie więc nie potrzebujemy dodatkowych łamigłówek tego rodzaju, bo wystarczą nam te, które w nieumyślny sposób tworzymy sami dla siebie. I niestety nie możemy w ich przypadku – w przeciwieństwie do kodów z książki – zajrzeć do części końcowej po wskazówki i odpowiedzi.
Jednak nawet wobec takich mankamentów, prezentowane w książce przykłady mogłyby mieć pewną wartość poznawczą. Rzecz w tym, że naprawdę interesujące zagadki można bez trudu policzyć na palcach obu rąk. Pozostałe są albo pomyłkami aż do bólu klasycznymi (na czele z pomyleniem operatora przypisania i równości w warunku logicznym), albo trywialnymi literówkami, albo świadectwami na – delikatnie mówiąc – niekompletną znajomość języka. (Moim faworytem jest deklaracja int n = 1,000,000;, w założeniu inicjująca zmienną wartością równą milion).

Aż chce się zapytać, czy są w tej książce jakieś cechy pozytywne. Odpowiadam prędko, że jak najbardziej, tyle że mają się one nijak do jej zasadniczej treści. Do każdej zagadki autor dołączył bowiem krótką, zabawną historyjkę “z życia wziętą” lub inny śmieszny tekst – wszystko oczywiście z dziedziny IT. Paradoksalnie więc ta “książka o C++” lepiej sprawdza się jako książka z dowcipami.
Jest też druga dobra strona. Przypomniałem sobie mianowicie, skąd u mnie wzięła się ta dziwna pozycja. Otóż zakupiłem ją podczas jakichś tragów wydawniczych, które akurat odbywały się na uczelni, zapłaciwszy za nią około dziesięć złotych. Nietrudno przeboleć taką niewielką sumę, nawet mimo tego, że nikomu nie poleciłbym wydania na tę książkę nawet jednej złotówki :)

Różne rodzaje książek koderskich

Programowanie to nie tylko ciągłe stukanie w klawiaturę i pisanie kilometrowych listingów (względnie intensywne wyklikiwanie interfejsu użytkownika). Zawsze od czasu do czasu przychodzi czas, gdy trzeba się odwołać do źródła wiedzy fachowej. Na pierwszej linii frontu stoi wtedy zwykle dokumentacja do konkretnego środowiska czy języka, ale nie jest to jedyne źródło wiedzy, z którego programista korzysta. Wśród nich są również książki.

Literatura programistyczna jest naturalnie niezwykle bogata i dotyczy każdego pola koderskiej działalności, wszystkich możliwych bibliotek, języków, metodologii i wszelkich innych aspektów programowania. W takiej klasyfikacji nietrudno się odnaleźć i zazwyczaj łatwo możemy stwierdzić, o czym dana pozycja traktuje. Trochę gorzej bywa z oceną, jak dany temat został w tej konkretnej książce potraktowany.
Jako że przydarzyło mi się przeczytać dość sporą liczbę programistycznych książek, a jeszcze większą – mniej lub bardziej pobieżnie przekartkować, mogę chyba pokusić się o klasyfikację na podstawie tego drugiego, mniej widocznego kryterium. Uważam zatem, że możemy wyróżnić kilka rodzajów książek programistycznych:

• Kompletne omówienia, czyli – nie bójmy się użyć tego słowa – wykłady. Takie książki nie muszą mieć oczywiście arcyporywającego stylu, charakteryzującego większość podręczników akademickich. Wręcz przeciwnie, mogą być napisane w sposób żywy, wciągający i intrygujący. Ich naczelną cechą jest to, że koncentrując się na danym temacie opisują go w sposób dokładny, obszerny i uporządkowany. Kolejne rozdziały przedstawiają poszczególne zagadnienia, pełne są omówień, przykładów, czasem dygresji. To coś w rodzaju koderskiej beletrystyki, dobrej do czytania w wolnych chwilach i do nauki zupełnie nowych treści.
• Książki kucharskie. Jak sama ich nazwa wskazuje, zawierają one przepisy (czasem zwane wręcz recepturami) na mniej lub bardziej konkretne rozwiązania praktycznych problemów. Mogą to być kompletne sposoby na realizację jakichś fragmentów programu albo tylko artykuły sygnalizujące istnienie pewnych narzędzi i metodyk. Zawsze jednak zakładają pewną wiedzę czytelnika w danym temacie, co nie przeszkadza im jednocześnie wyłożyć przy okazji jakichś drobnych fragmentów obszerniejszych zagadnień. Najważniejsze jest jednak to, że są one skoncentrowane na praktycznym wykorzystaniu zawartych w nich “sztuczek”.
• Notatki z pola bitwy to bardzo ciekawy typ książek, z którymi zetknąłem się dopiero niedawno. W założeniu mają one umożliwić “zaglądanie do warsztatu” doświadczonego programisty i stanowią luźny (lecz uporządkowany) zbiór uwag, fragmentów kodu i komentarzy, tyczących się jakiegoś zagadnienia – zwykle języka, biblioteki lub technologii. Ich celem jest przekazanie wiedzy maksymalnie praktycznej i jednocześnie obszernej. Wymagają dobrego przygotowania ze strony czytelnika, lecz jeśli spełnia on wymagania, może on zyskać nie tylko przydatne informacje, ale i bardzo użyteczne umiejętności.
• Leksykony i materiały referencyjne. Te pozycje mają najwięcej wspólnego z klasyczną, elektroniczną dokumentacją. Systematyczny opis funkcji, klas, właściwości, pól, metod, wyjątków, sygnałów, interfejsów i wszystkich tych elementów, które składają się na dane narzędzie programistyczne. Te grube książki najlepiej jest trzymać na biurku w trakcie pisania kodu. Ich przewaga nad dokumentacją polega zwykle na trafnych przykładach zastosowań opisywanych elementów i lepszą organizacją treści.
• Ciekawostki okołokoderskie. W tych książkach możemy znaleźć właściwie wszystko: od przykładów najczęściej popełnianych błędów po wskazówki, w jaki sposób należy czytać kod napisany przez innych. Jeśli wpadnie nam w ręce któraś z tego rodzaju książek, zwykle albo ją pokochamy i będziemy co jakiś czas do niej wracać, albo uznamy pomysł jej napisania za zupełnie nietrafiony i szybko o niej zapomnimy. Nie muszę chyba wspominać, że systematyczne ułożenie wiedzy i orientacja na teorię/praktykę nie są kategoriami, których powinniśmy używać do oceniania takich książek. W większości jest to bowiem całkowity freestyle – z różnymi skutkami, oczywiście.

Jak w każdej arbitralnej klasyfikacji, także i tutaj szufladki te są rzecz jasna rozmyte i wiele książek zmieściłoby się bez problemu na kilku półkach. Prawdopodobnie takie właśnie są najlepsze i najbardziej użyteczne. W końcu skoro już decydujemy się na treści zapisane na papierze, powinniśmy dążyć do korzystania z nich na wiele sposobów… ;]