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 ;-)

Dla początkujących: jak zautomatyzować wysyłanie informacji na Twittera

Posłużmy sie przykładem.

Problem:
Używam Twittera i Google Buzz. Ponieważ powiązałem obie usługi w taki sposób, że tweety są automatycznie publikowane (duplikowane) w Buzzie, nie ma sensu duplikować wpisów z Buzza na Twittera - zresztą sami zauważcie, jak to dziwnie brzmi :-) Wpadlibyśmy w nieskończoną pętlę i najprawdopodobniej zyskalibyśmy hm... dezaprobatę społeczności. Jak więc dawać znać użytkownikom Twittera o swojej aktywności na Buzzie?

Rozwiązanie (typu "jedno z...")
Można na przykład napisać sobie prosty program/skrypt, którego jedynym zadaniem będzie wysyłanie komunikatu na Twittera z linkiem do naszego Buzza i krótkim opisem, o co nam chodzi. Następnie można wykorzystać cron (w Linuksie; inne systemy również posiadają aplikacje/usługi pozwalające na uruchamianie programu w wyznaczonym czasie) i kazać mu uruchamiać nasz program/skrypt np. codziennie o 21:00.
Jedyne, o czym należy pamiętać, to rejestracja naszego programu w serwisie Twitter.

Oto przykładowy kod, realizujący opisane wyżej zadanie:



Przyda się jeszcze szablonowy program do autoryzacji aplikacji w danym profilu użytkownika usługi Twitter (po wcześniejszej rejestracji aplikacji):



I na koniec - dla wszystkich, którzy kochają graficzne interfejsy użytkownika, a nie przepadają za składnią plików konfiguracyjnych crona - zrzut konfiguracji zadania za pomocą Gnome Schedule: