2. Posta musi projit
Od roku 1993 jsem mel na starosti technicke zabezpeceni maleho poskytovatele bezplatneho pristupu k Internetu (Chester County InterLink - CCIL , West Chester, Pennsylvania). Patrim k zakladatelum CCIL a napsal jsem pro nej unikatni mnohauzivatelsky buletinovy software, ktery si muzete prohlednout pres telnet na adrese
locke.ccil.org.
V dnesni dobe podporuje temer 3000 uzivatelu na 30 linkach. Tato prace mi umoznila 24 hodinovy pristup na Internet pres 56K linku CCIL, pro moji prace byl takovy pristup nutnosti.
Diky tomu jsem si zvykl na okamzity pristup k e-mailu. Z ruznych slozitych duvodu bylo obtizne zprovoznit SLIP mezi mym domacim pocitacem (snark.thyrsus.com) a CCIL. Kdyz se mi to konecne podarilo, pravidelne logovani a kontrola posty pres telnet me zacalo obtezovat. Potreboval jsem nejak presunout postu na muj domaci pocitac snark tak, abych byl upozornen pri jejim prijeti. Postu jsem pak chtel dalei zpracovavat s pomoci ruznych programu na mem osobnim pocitaci.
Jednoduche presmerovani posty programem sendmail nepripadalo v uvahu, protoze muj pocitac neni vzdy pripojen k siti a nema stalou IP adresu. Potreboval jsem program, ktery by mne pripojil pres SLIP a pote prenesl postu. Vedel jsem, ze takove programy existuji a ze vetsina z nich vyuziva jednoduchy aplikacni protokol, nazyvany POP (postovni protokol). A skutecne, nas BSD/OS operacni system v sobe obsahoval i POP3 server.
Potreboval jsem tedy POP3 klienta. Rozhledl jsem se po siti a jeden jsem nasel. Tedy ve skutecnosti jsem jich nalezl nekolik. Po nejaky cas jsem pouzival pop-perl, ale tomu chybela funkce, kterou jsem povazoval za podstatnou, nebyl totiz schopen pozmenit adresy prichazejici posty tak, abych mohl na obdrzenou postu primo odpovidat.
Problem spocival v tomto:
rekneme, ze nekdo se jmenem "joe" my poslal e-mail. Pokud jsem si jej stahl na snark a pote se na nej pokusil odpovedet, muj postovni klient se snazil poslat odpoved neexistujicimu joeovi na snarku. Rucni editace adres mne ale brzy zacala unavovat.
Toto byla vec, kterou mohl pocitac delat za mne. Zadny z existujicich klientu ale nevedel jak. A to nam prinasi prve ponauceni:
1. Kazdy dobry program zacina tim, ze resi potize samotneho programatora.
Mozna, ze by to melo byt samozrejme (existuje stare prislovi: "Nutnost je matka pokroku"), ale az prilis casto vyvojari travi svuj cas praci na programech, za ktere jsou placeni, ale ktere ani nemiluji ani nepotrebuji. To vsak neplati ve svete Linuxu a snad prave proto je prumerna kvalita software vyvinuteho v Linuxovem spolecenstvi tak vysoka.
Takze, vrhl jsem se okamzite do horecneho programovani a zacal psat zcela noveho POP3 klienta, ktery by mohl soutezit s existujicimi programy? V zadnem pripade! Peclive jsem prostudoval zname POP programy a hledal takovy, ktery nejvice odpovidal mym predstavam.
2. Protoze dobri programatori vedi co psat. Velci vedi, co prepsat (a znovu pouzit)
Ackoli o sobe netvrdim, ze jsem velky programator, snazim se ty velke napodobit. Dulezitym rysem velkych programatoru je konstruktivni lenost.Vedi, ze clovek neni ocenovan za usili, ale za vysledky, a ze je temer vzdy snazsi zacit od dobrych castecnych reseni nez od upleho pocatku.
Linus Torvalds
take nezacal psat Linux od prve radky. Misto toho pouzil kod a napady Minixu, maleho operacniho systemu napodobujiciho Unix, ktery byl urcen pro pocitace rady 386. Dnes jiz veskery puvodni kod Minixu budto zmizel zcela nebo byl od zakladu prepsan, ale na pocatku vytvarel leseni podpirajici batole, ktere se nakonec stalo Linuxem.
Veden stejnymi motivy jsem prohlizel existujici POP programy a hledal takove, ktere byly vhodne jako zaklad pro dalsi vyvoj.
Tradice sdileni zdrojovych souboru Unixoveho sveta byla vzdy naklonena recyklovani starsich kodu (proto take GNU zvolil Unix jako svuj zakladni operacni system). Linux dovedl tuto tradici temer k jejimu technologickemu limitu. V jeho svete jsou pristupne terabyty volnych zdroju. Jestlize zde hledate temer vyhovujici program, mate vetsi sanci na uspech nez kdekoliv jinde.
Obdobne vse fungovalo i v mem pripade. Spolu s tim, co jsem nalezl jiz drive, muj druhy pruzkum odkryl celkem 9 kandidatu: fetchpop, PopTart, get-mail, gwpop, pimp, pop-perl, popc, popmail a upop. Nejdrive jsem se rozhodl pro `fetchpop' od Seung-Hong Oh. Vlozil jsem do neho moji funkci na prepisovani adres a ucinil nekolik dalsich zmen, ktere autor pozdeji zaradil do verze 1.9.
Nekolik tydnu pozdeji jsem ale narazil na zdroj programu `popclient', ktery napsal Carl Harris, a zjistil jsem, ze stojim pred problemem. Ackoliv fetchpop obsahoval nekolik dobrych puvodnich napadu (napriklad mod demon), dokazal pouze spravovat POP3 a byl programovan ponekud amatersky (Seung-Hong byl schopny, ale nezkuseny programator, a obe tyto charakteristiky se na kodu projevily). Carluv kod byl lepsi, na profesionalni urovni a stabilni, ale jeho programu chybelo nekolik dulezitych funkci, ktere je celkem obtizne naprogramovat, vcetne tech, ktere jsem programoval ja sam.
Zustat pri starem nebo volit zmenu? Pokud bych se rozhodl pro zmenu, musel bych obetovat vsechen dosud napsany kod, ziskal bych ale lepsi vyvojovou zakladnu.
Praktickym argumentem, ktery doporucoval zmenu, byla podpora rady protokolu. POP3 je nejbezneji pouzivany protokol, ale neni jediny. Fetchpop a dalsi podobne programy neumely POP2, RPOP nebo APOP a ja jiz zacinal premyslet o pridani
IMAPu (nejnovejsiho a nejvsestrannejsiho postovniho protokolu).
Mel jsem ale i dalsi, teoreticky duvod, proc premyslet o zmene. Bylo to neco, co jsem se naucil dlouho pred Linuxem.
Pociteje s tim, ze alespon jednou budete muset vse prepsat, stejne vas to nemine ((Fred Brooks, ``The
Mythical Man-Month'', Chapter 11)
Nebo, receno jinymi slovy, tak dlouho problemu doopravdy neporozumite, pokud se ho nepokusite nejak vyresit. Podruhe uz budete mozna vedet, jak na to. Takze pokud chcete najit spravne reseni, budte pripraveni zacit alespon jednou znovu.
Dobre( rekl jsem si), upravy fetchpopu byly mym prvnim pokusem a zmenil jsem programovou zakladnu.
Pote, co jsem 25. cervna 1996 poslal opravy popclienta Carl Harrisovi, zjistil jsem, ze on sam jiz ve sve podstate ztratil o projekt zajem. Kod uz byl trochu zapraseny a bylo v nem nekolik drobnych, snadno opravitelnych chyb. Ja potreboval ucinit radu zmen a tak jsme se rychle dohodli na tom, ze projekt prevezmu.
Aniz jsem si to sam uvedomil, projekt nabral na tempu. Nepracoval jsem jiz pouze na drobnych zmenach existujiciho POP klienta. Prevzal jsem vyvoj celeho programu a v me hlave se rojily napady, od kterych jsem ocekaval, ze pravdepodobne povedou k velkym zmenam.
Ve spolecenstvich programatoru, ve kterych je podporovano sdileni kodu, je takovyto vyvoj projektu prirozeny. Jednal jsem podle nasledujiciho pravidla:
4. Pokud mate spravny pristup, zajimave problemy si Vas najdou sami.
Ale pristup Carla Harrise byl jeste dulezitejsi. Vedel ze:
5. Kdyz ztratite zajem o program, vasi posledni povinnosti je predat jej schopnemu nastupci.
Aniz jsme o tom museli diskutovat, Carl i ja jsme vedeli, ze mame spolecny cil, nalezt to nejlepsi mozne reseni. Jedinou otazkou pro oba zustalo, jak prokazat, ze jsem vhodny nasledovnik. Jakmile se mi to podarilo, zachoval se uctyhodne, a prenechal mi sve misto. Doufam, ze budu jednat stejne, az prijde muj cas.