Hackerská etiketa

O hackerskou etiketu se jedná proto, že hacker je vývojář svobodné technologie. Vývojáři proprietární technologie mají etiketu jinou, a ta se v zásadě omezuje pouze na vnitřek podniku, pro který pracují, takže nemá pro veřejnost význam.

Netvrdím, že následující postřehy jsou nějakou obecně platnou normou. Jedná se o moje vlastní postřehy ze zkušenosti z této oblasti.

Z hlediska uživatele

Typická situace je, že uživatel přijde na stránky projektu, nalezne místo jasně označené jako startovní bod pro příchozí (zde začněte, about, o projektu, …) a přečte si, co od projektu očekávat, nejlépe i jeho specifikaci. Určí, zda projekt odpovídá jeho potřebám.

Pokud projekt jeho potřebám odpovídá, pokud má balíčkovací distribuci, program nainstaluje a pokračuje začátkem uživatelské dokumentace. Jinak typicky stáhne zdroják a pokračuje souborem README. Pokud není README, je instalační návod v INSTALL, případně v doc/README.html a podobně.

Pokud projekt neodpovídá potřebám uživatele, může hledat projekty další. Je zde Freshmeat, což je databáze projektů, a také Sourceforge, což je takový „zadarmo“ (za reklamy) hosting projektů a také jejich rejstřík. Dále existuje Free Software Directory, společný projekt Free Software Foundation a UNESCO.

Uživatel může očekávat, že program bude fungovat tak, jak má. Pokud nefunguje, je odpovídající akcí zjistit, zda to, jak se chová, je v rozporu s jeho specifikací, a pokud ano, poslat bugreport.

K čemu jsou specifikace a proč nestačí programy samotné? Slouží k zjednodušení práce s programy (obecně objekty reálného světa, lidskými produkty). Umožňují jakési abstraktní, stavebnicové a hierarchické chápání světa, které podstatně redukuje práci, v čemž právě přínos specifikace spočívá.

Svět se rozpadne na stavební kostky – moduly, objekty – a jejich rozhraní (specifikace). Je nutné, aby moduly byly jednoznačné – proto není dobré, když se dva projekty jmenují stejně, nebo když někdo udělá klon projektu a nechá mu původní jméno (např. existují dva programy jménem „jade“).

Uživatel s rozhraním pracuje tak, že moduly k sobě spojuje a kontroluje, zda rozhraní (specifikace) na obou stranách spojení odpovídají. Dá se snadno intuitivně nahlédnout, že pokud je větší systém složen z modulů, které jsou všechny BugFree™, a rozhraní na sebe pasují, pak musí i celek být BugFree™.

V případě, že celek nechodí, analyzuje se, zda sedí specifikace, a pokud nesedí, chybu udělal uživatel. Pokud sedí, nutně alespoň jeden modul se musí chovat v rozporu se svými specifikacemi. Tento přístup k realitě umožňuje pracovat předvídatelně i se systémy, jejichž vnitřní struktura je natolik složitá, že ji jeden člověk nemůže v jednom okamžiku celou chápat (natožpak uživatel). Typickým takovým systémem je počítač, na kterém běží nějaký software.

V případě nalezení chyby musí uživatel nejdříve ověřit, že to je skutečně chyba. Ve světě, kde se používají specifikace, to znamená najít rozpor mezi chováním programu a specifikací. A pak poslat bugreport nejlépe ve formě:

Strana 22, kapitola 22.3: "Přepínač -a způsobuje
zapnutí 8-bitového zpracování textu"
clock@beton: cat a.txt | program -a > vystup.txt
program: unknown option "-a"

Specifikaci neplést se „zříkám se odpovědnosti úplně za vše“ klauzulí v GPL. Ta je zde jen proto, aby se zamezily právní komplikace, a ve skutečnosti to tak nikdo nemyslí.

Při posílání bugreportů je nutno striktně odlišovat fakta, kterými jsme si jisti („program je vadný“) od domněnek („a na základě toho si myslím, že by to mohla být chyba, ale neumím to dokázat“), aby mohly být bugreporty hladce smysluplně zpracovávány a nepravdivá tvrzení nesváděla vývojáře (a případně uživatelské čtenáře mailing listu) zbytečně na zcestí.

Velmi vhodným se ukazuje program script. Ten způsobuje, že se vydávané příkazy i hlášky běžících programů zapisují do souboru (defaultně typescript), takže člověk pak tento soubor může vzít, editovat (je vhodné nechat jen relevantní fakta) a použít jako bugreport. Zaručí se tím mimo jiné, že člověk má přesnou kopii toho, co se dělo, a nehlásí jako chybu něco, co byl jeho překlep (i to se stane).

Dalšími podstatnými informacemi jsou verze programu (přepínače -v, -V, –version) a verze různých komponent systému (jádro, gcc, glibc, bash, automake, autoconf, make…). Spoustu práce ušetří, když si človek udržuje soubor pojmenovaný např. system.info, ve kterém má všechny verze systémových utilit poznamenány.

Bugreporty se posílají buď mailem autorovi, na nějaký mailing list, a nebo existuje automatizovaný systém (sourceforge, Bugzilla). Tento systém má sice výhodu, že chyba se zpracovává komplexně, ale člověk se musí typicky přihlašovat, což zdržuje. Také se občas vyskytují předvařené formuláře, které ne vždy mají vhodné možnosti nebo vystihují to, co je třeba sdělit. Projekt od projektu se systém hlášení chyb liší.

Hlásit je nutné i mezery v dokumentacích. Pokud při používání programu dojde k „zákysu“ (typicky se ve specifikaci píše, že program umí nějakou funkci, ale z dokumentace nelze zjistit, jak funkci vyvolat, případně dokumentace připouští dvě hypotézy, jak by se tohle mohlo dělat, spory v dokumentaci apod.), je nutno považovat to za chybu dokumentace a okamžitě hlásit.

Na druhou stranu je nutno se před takovým hlášením ujistit, že v dokumentaci skutečně mezera je. Dokumentace by měla být rozumně lokální – věci by se neměly popisovat v nějaké jiné kapitole, než kam patří. Například tomu odpovídá přečíst si od začátku do konce celou relevantní kapitolu, případně SEE ALSO na konci manuálové stránky, nebo v dokumentaci klíčové slovo vyhledat (i synonyma).

Poslední možností, když selhává dokumentace a specifikace, je Google. Toto je nouzový prostředek. Uživatel může s klidným svědomím očekávat, že všechny funkce programu jdou použít pouze s oficiálním manuálem v ruce. Může se totiž stát, že se program používá na stroji, jehož síťové připojení není plně nakonfigurováno, chybí prohlížeč, nebo je prostě linka do sítě zrovna spadlá.

Kromě Google pomůžou: FAQ, RFC (http://www.faq­s.org/) a HOWTO (přidejte do googlu slovo faq nebo howto). Pokud se jedná o systém Linux, je zde The Linux Documentation Project. RFC jsou standardy, které standardizují informační provoz v rámci Internetu.

Zpětná vazba od uživatele je důležitá. Uživatel je důležitý, protože vývojář nemá možnost ozkoušet, zda bude systém schopen použít člověk, který neví, jak funguje uvnitř, jen rozumí jeho dokumentaci. Je to stejný jev, který způsobuje, že látku ve škole dokáže lépe vysvětlit spolužák, který ji teprve před půl hodinou pochopil, než profesor, který ji učí už 20 let. Není důležité, zda uživatel umí nahlášený problém vyřešit, není se třeba obávat, že vývojář po něm bude řešení požadovat. Není třeba považovat toto počínání za kverulantní paranoiu. Hlášení chyby je příspěvek vývoji.

Neposlat bugreport, když by měl být poslán, je do určité míry nezodpovědné a nemělo by se to dělat, pokud člověk není v opravdu velké časové tísni. Čas strávený řešením nějakého „zákysu“ je čas ztracený. Posláním bugreportu tento kus času z říše času ztraceného vyjmeme a umístíme ho do říše času stráveného smysluplně.

Dále je užitečné, když uživatel navrhuje nové vlastnosti programu – víc hlav víc ví (nejlépe na mailing listu; ovšem i automatické systémy hlášení chyb typu bugzilla mají někdy možnost zadat bugreport jako feature request).

V případě, že program uživateli spadne, je z hlediska ladění důležité core. Aby se získalo, musí se jeho dumpování zapnout pomocí ulimit -c. core je dobré zagzipovat a někde uložit, kdyby se vývojář potřeboval podívat, co se ve spadlém programu dělo. Současně vývojář potřebuje binárku, kterou je dobré zaarchivovat, když hrozí, že bychom program smazali nebo přeinstalovali jinou verzí. Nakonec potřebuje zdrojáky, u kterých je třeba zjistit jejich verzi.

K programu může existovat několik míst, které obsahují dokumentaci. Jsou to manuálové stránky (man), dokumentace ve formátu texinfo (info), adresáře /usr/share/doc, /usr/local/sha­re/doc, web projektu (typický formát bývá HTML, PDF, PS). Neoficiální dokumentace může být i v HOWTO, které se vyskytuje někde na webu (například raidtools mají mezery v dokumentaci, které lze dohledat pouze v neofic. HOWTO). A nakonec když spustíme program s parametrem -help, -h nebo–help, vypíše nám typicky informaci, jaké má parametry z příkazové řádky, a jejich význam.

V tomto dílu jsem popsal, jak vypadá symbióza mezi uživatelem a vývojářem z hlediska uživatele. V příštím díle bude pohled z opačné strany.