Przejdź do głównej zawartości

Jak pisać książki dla programistów?

Nie, nie jest to poradnik dla początkujących - nie posiadam wystarczających kompetencji ani doświadczenia, żeby doradzać w tej dziedzinie. Jest to raczej wytknięcie sobie kilku błędów, które popełniłem pisząc książki przeznaczone - jak by nie było - dla programistów, głównie początkujących lub mających już pierwsze kroki w dziedzinie programowania za sobą.
Gdzies w czeluściach Internetu wygrzebałem artykuł "On Writing Books for Programmers", którego autor porusza temat właściwego podejścia do tworzenia publikacji (głównie książek) przeznaczonych dla programistów. Artykuł ten jest poniekąd streszczeniem maila otrzymanego przez autora (Victor Noagbodji) od Briana Kernighana, w którym guru twórców książek informatycznych odpowiada Victorowi na pytanie, jak pisać dla programistów. Nie będę tutaj oczywiście tłumaczył tego artykułu - polecam jego lekturę. Przytoczę tylko kilka aspektów, które bezpośrednio dotyczą moich prac. Poniższe punkty maja formę trybu rozkazującego, bo zwracam się do siebie :-)

1. Jeśli już piszesz, to pisz o tym, nad czym pracujesz, co cię pasjonuje, a nie o tym, co jest aktualnie na fali

Niestety, nie wszystkie moje drukowane publikacje były dokładnie związane z codzienną pracą, ale też nie pisałem o pojęciach dla mnie kompletnie abstrakcyjnych, ani też nie podniecałem się totalnymi, nie sprawdzonymi jeszcze i nie przetestowanymi przeze mnie nowościami. Były jednak tematy, które poruszałem, bo należało to zrobić, choćby z racji pełnego ujęcia danej problematyki. Tutaj chyba popełniłem najmniej błędów. Zresztą nie podjąłem współpracy z wydawnictwem przy wznowieniu elektronicznego poradnika o PHP właśnie z powodu związanego z zakończeniem wykorzystywania tego języka w codziennej pracy (w zasadzie całkowicie odpuściłem sobie PHP parę już lat temu, po publikacjach).

2. Załączaj do publikacji działające, rzeczywiste przykłady

Tak, to prawda. Niektóre z przykładów w moich publikacjach to sztuka dla sztuki. Teraz już wiem, że nie tego oczekują czytelnicy, choć wydawać by się mogło, że proponowane przeze mnie przykłady dobrze wyjaśniają różne kwestie związane z programowaniem. Ale OK, sztuczne przykłady mogą nie przekonać czytelnika do danej technologii, biblioteki itp.
Kolejna sprawa, to przykłady działające. Jeżeli załączałem przykłady, to raczej dobrze przetestowane w środowiskach referencyjnych, w domyślnej konfiguracji itd. Poza tym na przykłady czytelnicy się nie skarżyli (tylko na ich brak w ostatniej książce - mój błąd!).

3. Dziel się wiedzą, nie przechwalaj

Jak większość informatyków, lubię popisywać się wiedzą :-) Ale - jak wspomniano w artykule, do którego się odwołuję - nie o to chodzi, żeby udowadniać czytelnikom, jaki jestem wielki i wspaniały. Chodzi o to, że czytelnik sięga po moją książkę żeby się czegoś nauczyć. Muszę więc pisać tak, żeby ten cel osiągnął. I tu wydaje mi się, że też nie mam sobie wiele do zarzucenia. Co prawda kilku czytelników wytknęło mi zbyt pobieżne potraktowanie niektórych tematów, ale też taki miałem zamiar - nie zawsze chcemy, żeby książka, po którą sięgamy, miała 1000 stron i zawierała wszystko, co się da o danym narzędziu, technice itp. napisać. Czasem zależy nam na "szybkiej" książce, która będzie stanowiła odskocznię, punkt zaczepienia do pogłębiania wiedzy.

4. Współpracuj z kimś, kto krytycznie podejdzie do twojej twórczości

Nie współpracowałem. I to był zasadniczy błąd. Ale na przyszłość będę o tym pamiętał. Chodzi tu zarówno o stronę merytoryczną publikacji, jak i o styl oraz poprawność językową. Ktoś zarzucił mi niechlujny język (w ostatniej publikacji) - cóż, nie wydawało mi się nigdy, że takowego używam, ale przejrzałem po pewnym czasie książkę i... coś w tym jest. Chyba po prostu za bradzo zaufałem korektorowi ;-)

Jakie wnioski na przyszłość wysnułem z artykułu Victora? Otóż pierwszy i najważniejszy to konieczność pisania zgodnie z zainteresowaniami, na tematy dobrze mi znane (w 150%), nad którymi pracuję i które mnie pasjonują. Następnie postaram się unikać głupich przykładów. No i oczywiście podejmę współpracę z kimś, kto krytycznym okiem spojrzy na moje wypociny (i każe je wyrzucić do kosza i zacząć pisać od nowa).

Chciałbym jeszcze, żeby - w przypadku pisania książek na zamówienie - wydawnictwa dawały autorom trochę więcej czasu :-) Ale to już nie ode mnie zależy.

Tym czasem staram się pisać od czasu do czasu słów parę na blogu, który poświęcony jest własnie tym rzeczom, którymi się zajmuję. Mało tego co prawda, ale też - wierzcie mi - nie wszystko, co robię, nadaje się do publikacji, a czasem też zleceniodawcy nie bardzo by chcieli, żebym się rozwodził na temat przygotowywanych dla nich projektów ;-)

Komentarze

  1. Książki, po które ja często sięgam (sięgałem jak programowałem):
    A. Zalewski Borland C++ - to taki manual, ale mi odpowiada
    A. Sopala Pisanie programów internetowych - tylko część opisująca protokoły, programowanie pominąłem; świetna esencja tego, co znaleźć można w RFC.
    A. Dudek Jak pisać wirusy - świetna pomoc dla uczących się assemblera; tytuł niech nikogo nie zmyli.
    Teraz szukam książki (publikacji), która opisywać będzie podstawy - wspólne części dla każdego programu. Gdzie wpisać nazwisko autora, oznaczenie wersji, itp. Jak zaprojektować aktualizację on-line. Jak obsługiwać parametry (pliki XML, własna struktura pliku, baza, itd.). Czasami piszę drobne programy, które nie mają żadnych założeń początkowych, a potem wykorzystywane są w kilkunastu miejscach i wersjach i robi się prawdziwy bałagan. Nie mam czasu żeby drążyć tematy, o których powyżej, ale jeśli miałbym 'gotowca', korzystałbym za każdym razem z jednego mechanizmu.

    OdpowiedzUsuń
  2. @guzik:
    Zalewski i Dudek to klasyka, jednak nie udało im się osiągnąć takiej ponadczasowości, jaką niewątpliwie może się poszczycić dzieło Kernighana i Ritchiego "Język ANSI C". U Zalewskiego to zrozumiałe, bo książka faktycznie była manualem do bodajże BC++ 3.1, które to środowisko nawet za czasów mojej nauki programowania było przestarzałe i wyrabiało bardzo złe nawyki (jakieś dziwne było to C++) :-) Ale nic lepszego o borlandowskim produkcie wtedy nie istniało.
    Niestety, również "Wirusy" Dudka są dziś raczej ciekawostką, tym bardziej, że asemblera używa się obecnie "trochę" inaczej... Ale dla miłośników hardcoru - jak najbardziej.

    A jeśli chodzi o książkę, którą chciałbyś "dorwać", obawiam się, że tak, jak nie ma jednego standardu dotyczącego poruszonych przez Ciebie spraw, tak zapewne nie ma ostatecznej książki o nim traktującej. Ja po prostu przeglądam publikowane od czasu do czasu przez społeczności dokumenty typu "Jak prawidłowo kodować w ...", "Jak pisać komentarze" itp. oraz zaglądam w źródła i staram się naśladować dobre rozwiązania (inna rzecz, to rozróżnić te dobre - ale wydaje mi się, że to nie powinien być dla nas problem).

    Polecam również system kontroli wersji (np. GIT - moim zdaniem najwygodniejszy), choć sam przez długi okres czasu nie zauważałem zalet płynących z tego typu oprogramowania.

    OdpowiedzUsuń
  3. Ja mam nadzieję, że tą książkę wkrótce kupię (albo ściągnę PDF'a). Autorem będzie ten sam gość, co napisał "Microsoft Visual C++ 2008. Tworzenie aplikacji dla Windows" ;-)

    OdpowiedzUsuń

Prześlij komentarz

Popularne posty z tego bloga

Niesamowicie prosty czujnik zmierzchowy.

Tym razem zero programowania, będzie natomiast nostalgiczno-wspomnieniowy układzik, lekko zmodyfikowany.
Otóż kilka dni temu rozmawialiśmy w gronie znajomych o różnego rodzaju czujnikach zmierzchowych i czujnikach ruchu. Ponieważ należę do tych wariatów, co to hołdują jeszcze owej przestarzałej i kompletnie odrealnionej dziś zasadzie: "po co kupować, gdy można zrobić", stwierdziłem, że poskładam takie coś (czujnik zmierzchowy; sensor ruchu faktycznie lepiej nabyć, choćby ze względu na rozmiary ;)) i być może podłączę do jakiegoś mikrokontrolera. Przypomniało mi się też przy okazji, że znalazłem ostatnio w elektronicznych śmieciach stary fotorezystor (dla niewtajemniczonych: element zmieniający rezystancję, czyli opór elektryczny, pod wpływem działania strumienia światła) RPP130, jeden z kilku pozostałych po montowanych wieki temu układach tranzystorowych do zdalnego sterowania pracą urządzeń za pomocą latarki... No OK, nie było to specjalnie rozbudowane zdalne sterowanie ;)

Android i zewnętrzny moduł GPS

Od kilku dni jestem w posiadaniu smyrfona z Androidem 4.1.1 na pokładzie. Kwestie związane z wyborem systemu roztrząsałem już na G+, a ten artykuł tutaj ma konkretny temat, więc nie będę wyjaśniał po raz n-ty. Po prostu zwyciężyły popularność i ekosystem oraz przywiązanie do produktów sieciowych Google. Mniejsza.

Zbliża się sezon urlopowy :-) Moi podopieczni już mają wakacje, a ja wyjeżdżam wkrótce. W każdym bądź razie wakacje to podróże - samochodem, rowerem, na piechotę, żaglówką, motorówką, samolotem... Zaawansowane urządzenia mobilne przyzwyczaiły nas już do usług lokalizacyjnych, z których najważniejszą jest GPS (na dalszym planie mamy A-GPS, lokalizacje w oparciu o sieci WiFi itp.). Często korzystamy z programów, które w coraz ciekawszy sposób wiążą naszą lokalizację, pobraną z np. GPS-a, z przeróżnymi danymi, nieraz ocierając się o AR.
Każdy współczesny smartfon, a przynajmniej znakomita ich większość, wyposażona jest we wbudowany odbiornik sygnału lokalizacyjnego (GPS, GLONASS…

Po co mi to całe Arduino?

Oczywiście tytuł ma być jedynie prowokacją. Chociaż nie do końca - artykuł jest właśnie poświęcony pracy w Arduino IDE z mikrokontrolerami, ale bez płytek Arduino.
Czym jest Arduino - wiemy wszyscy, zarówno początkujący fani programowania elektroniki, jak i zaawansowani mikrokontrolerowcy. Jeśli jednak nie do końca wiemy, zachęcam do odwiedzenia strony domowej projektu (link 5 na końcu artykułu) oraz zerknięcia np. w poradnik (link 4).

Jakiś czas temu, przełamując się i zmieniając zdanie ("o 180 stopni" ;-)) nabyłem sobie Arduino Leonardo, głównie w celu jego "obwąchania" i zapoznania się z bogatym zbiorem bibliotek dostępnych dla tej platformy. Zgoda, różne biblioteki są dostępne niezależnie od Arduino, ale i tak się zdecydowałem. Dlaczego Leonardo? Otóż miałem ochotę przyrządzić dwie pieczenie na jednym ogniu - mieć Arduino i przetestować ATmegę 32u4. Dziś doskonale zdaję sobie sprawę, że żeby pobawić się Arduino nie trzeba go w ogóle posiadać... Ale po kolei.

Pi…