2. Pošta musí projít
Od roku 1993 jsem měl na starosti technické zabezpečení malého poskytovatele bezplatného přístupu k Internetu (Chester County InterLink - CCIL , West Chester, Pennsylvania). Patřím k zakladatelům CCIL a napsal jsem pro něj unikátní mnohauživatelský buletinový software, který si můžete prohlédnout přes telnet na adrese
locke.ccil.org.
V dnešní době podporuje téměř 3000 uživatelů na 30 linkách. Tato práce mi umožnila 24 hodinový přístup na Internet přes 56K linku CCIL, pro moji práce byl takový přístup nutností.
Díky tomu jsem si zvykl na okamžitý přístup k e-mailu. Z různých složitých důvodů bylo obtížné zprovoznit SLIP mezi mým domácím počítačem (snark.thyrsus.com) a CCIL. Když se mi to konečně podařilo, pravidelné logování a kontrola pošty přes telnet mě začalo obtěžovat. Potřeboval jsem nějak přesunout poštu na můj domácí počítač snark tak, abych byl upozorněn při jejím přijetí. Poštu jsem pak chtěl dálei zpracovávat s pomocí různých programů na mém osobním počítači.
Jednoduché přesměrování pošty programem sendmail nepřipadalo v úvahu, protože můj počítač není vždy připojen k síti a nemá stálou IP adresu. Potřeboval jsem program, který by mne připojil přes SLIP a poté přenesl poštu. Věděl jsem, že takové programy existují a že většina z nich využívá jednoduchý aplikační protokol, nazývaný POP (poštovní protokol). A skutečně, náš BSD/OS operační systém v sobě obsahoval i POP3 server.
Potřeboval jsem tedy POP3 klienta. Rozhlédl jsem se po síti a jeden jsem našel. Tedy ve skutečnosti jsem jich nalezl několik. Po nějaký čas jsem používal pop-perl, ale tomu chyběla funkce, kterou jsem považoval za podstatnou, nebyl totiž schopen pozměnit adresy přicházející pošty tak, abych mohl na obdrženou poštu přímo odpovídat.
Problém spočíval v tomto:
řekněme, že někdo se jménem "joe" my poslal e-mail. Pokud jsem si jej stáhl na snark a poté se na něj pokusil odpovědět, můj poštovní klient se snažil poslat odpověď neexistujícímu joeovi na snarku. Ruční editace adres mne ale brzy začala unavovat.
Toto byla věc, kterou mohl počítač dělat za mne. Žádný z existujících klientů ale nevěděl jak. A to nám přináší prvé ponaučení:
1. Každý dobrý program začíná tím, že řeší potíže samotného programátora.
Možná, že by to mělo být samozřejmé (existuje staré přísloví: "Nutnost je matka pokroku"), ale až příliš často vývojáři traví svůj čas prací na programech, za které jsou placeni, ale které ani nemilují ani nepotřebují. To však neplatí ve světě Linuxu a snad právě proto je průměrná kvalita software vyvinutého v Linuxovém společenství tak vysoká.
Takže, vrhl jsem se okamžitě do horečného programování a začal psát zcela nového POP3 klienta, který by mohl soutěžit s existujícími programy? V žádném případě! Pečlivě jsem prostudoval známé POP programy a hledal takový, který nejvíce odpovídal mým představám.
2. Protože dobří programátoři vědí co psát. Velcí vědí, co přepsat (a znovu použít)
Ačkoli o sobě netvrdím, že jsem velký programátor, snažím se ty velké napodobit. Důležitým rysem velkých programátorů je konstruktivní lenost.Vědí, že člověk není oceňován za úsilí, ale za výsledky, a že je téměř vždy snažší začít od dobrých částečných řešení než od úplého počátku.
Linus Torvalds
také nezačal psát Linux od prvé řádky. Místo toho použil kód a nápady Minixu, malého operačního systému napodobujícího Unix, který byl určen pro počítače řady 386. Dnes již veškerý původní kód Minixu buďto zmizel zcela nebo byl od základu přepsán, ale na počátku vytvářel lešení podpírající batole, které se nakonec stalo Linuxem.
Veden stejnými motivy jsem prohlížel existující POP programy a hledal takové, které byly vhodné jako základ pro další vývoj.
Tradice sdílení zdrojových souborů Unixového světa byla vždy nakloněna recyklování starších kódů (proto také GNU zvolil Unix jako svůj základní operační systém). Linux dovedl tuto tradici téměř k jejímu technologickému limitu. V jeho světě jsou přístupné terabyty volných zdrojů. Jestliže zde hledáte téměř vyhovující program, máte větší šanci na úspěch než kdekoliv jinde.
Obdobně vše fungovalo i v mém případě. Spolu s tím, co jsem nalezl již dříve, můj druhý průzkum odkryl celkem 9 kandidátů: fetchpop, PopTart, get-mail, gwpop, pimp, pop-perl, popc, popmail a upop. Nejdříve jsem se rozhodl pro `fetchpop' od Seung-Hong Oh. Vložil jsem do něho moji funkci na přepisování adres a učinil několik dalších změn, které autor později zařadil do verze 1.9.
Několik týdnů později jsem ale narazil na zdroj programu `popclient', který napsal Carl Harris, a zjistil jsem, že stojím před problémem. Ačkoliv fetchpop obsahoval několik dobrých původních nápadů (například mód démon), dokázal pouze spravovat POP3 a byl programován poněkud amatérsky (Seung-Hong byl schopný, ale nezkušený programátor, a obě tyto charakteristiky se na kódu projevily). Carlův kód byl lepší, na profesionální úrovni a stabilní, ale jeho programu chybělo několik důležitých funkcí, které je celkem obtížné naprogramovat, včetně těch, které jsem programoval já sám.
Zůstat při starém nebo volit změnu? Pokud bych se rozhodl pro změnu, musel bych obětovat všechen dosud napsaný kód, získal bych ale lepší vývojovou základnu.
Praktickým argumentem, který doporučoval změnu, byla podpora řady protokolů. POP3 je nejběžněji používaný protokol, ale není jediný. Fetchpop a další podobné programy neuměly POP2, RPOP nebo APOP a já již začínal přemýšlet o přidání
IMAPu (nejnovějšího a nejvšestrannějšího poštovního protokolu).
Měl jsem ale i další, teoretický důvod, proč přemýšlet o změně. Bylo to něco, co jsem se naučil dlouho před Linuxem.
Počíteje s tím, že alespoň jednou budete muset vše přepsat, stejně vás to nemine ((Fred Brooks, ``The
Mythical Man-Month'', Chapter 11)
Nebo, řečeno jinými slovy, tak dlouho problému doopravdy neporozumíte, pokud se ho nepokusíte nějak vyřešit. Podruhé už budete možná vědět, jak na to. Takže pokud chcete najít správné řešení, buďte připraveni začít alespoň jednou znovu.
Dobře( řekl jsem si), úpravy fetchpopu byly mým prvním pokusem a změnil jsem programovou základnu.
Poté, co jsem 25. června 1996 poslal opravy popclienta Carl Harrisovi, zjistil jsem, že on sám již ve své podstatě ztratil o projekt zájem. Kód už byl trochu zaprášený a bylo v něm několik drobných, snadno opravitelných chyb. Já potřeboval učinit řadu změn a tak jsme se rychle dohodli na tom, že projekt převezmu.
Aniž jsem si to sám uvědomil, projekt nabral na tempu. Nepracoval jsem již pouze na drobných změnách existujícího POP klienta. Převzal jsem vývoj celého programu a v mé hlavě se rojily nápady, od kterých jsem očekával, že pravděpodobně povedou k velkým změnám.
Ve společenstvích programátorů, ve kterých je podporováno sdílení kódu, je takovýto vývoj projektu přirozený. Jednal jsem podle následujícího pravidla:
4. Pokud máte správný přístup, zajímavé problémy si Vás najdou sami.
Ale přístup Carla Harrise byl ještě důležitější. Věděl že:
5. Když ztratíte zájem o program, vaší poslední povinností je předat jej schopnému nástupci.
Aniž jsme o tom museli diskutovat, Carl i já jsme věděli, že máme společný cíl, nalézt to nejlepší možné řešení. Jedinou otázkou pro oba zůstalo, jak prokázat, že jsem vhodný následovník. Jakmile se mi to podařilo, zachoval se úctyhodně, a přenechal mi své místo. Doufám, že budu jednat stejně, až přijde můj čas.