Vēstulēm ir jāiet

Kopš 1993. gada esmu atbildīgs par tehniskajām lietām nelielā brīvpieejas interneta pakalpojumu sniedzēju firmā Chester County InterLink (CCIL) Rietumčesterā (West Chester), Pensilvānijā. Es biju CCIL līdzdibinātājs un uzrakstīju savu daudzlietotāju ziņojumu dēļa programmu — jūs varat to apskatīt ar telnetu, pieslēdzoties   telnet://locke.ccil.org/. Šodien tā nodrošina gandrīz trīs tūkstošus lietotāju trīsdesmit līnijās. Darbs man deva iespēju  izmantot 56K pieslēgumu 24 stundas diennaktī pa CCIL līniju — patiesībā darbs man to prasīja!

Es biju pasācis izmantot Instant Internet Email. Un es atklāju, ka nepārtraukti izmantot telnetu, lai pārbaudītu vēstules, ir diezgan nepatīkami. Es vēlējos, kaut manas vēstules man pienāktu uz manu mājas datoru snark, lai es tiktu brīdināts, ka man ir pienācis pasts un es to varētu apstrādāt ar saviem rīkiem uz vietas.

Interneta dabīgais pasta pārsūtīšanas protokols SMTP, nederētu, jo tas strādā, kad mašīnas ir pieslēgtas tīklam nepārtraukti, bet mans personīgais dators nebija nepārtraukti pieslēgts tīklam un tam nebija pastāvīgas IP adreses. Man vajadzēja programmu, kas izmantotu manu nedrošo iezvanpieejas pieslēgumu un pārsūtītu manu pastu uz lokālo datoru. Es zināju, ka šādas programmas ir un vairums no tām izmantoja vienkāršu lietojumu protokolu — POP. POP šobrīd atbalsta vairums e-pasta klientu, bet tajā laikā manā pasta programmā tāda nebija.

Man vajadzēja POP klientu. Es apskatījos Internetā un atradu vienu. Patiesībā es atradu trīs vai četrus. Es tos visus pamatīgi pārbaudīju, bet neviens no tiem nepiedāvāja tādu svarīgu iespēju, kā nosūtītāja adreses maiņu, lai atbildēšana darbotos pareizi.

Problēma bija šāda: piemēram, kāds ar vārdu 'joe' no 'locke' nosūta man vēstuli. Es saņemu vēstuli uz 'snark' un atbildu viņam, un pasta programma priecīgi mēģina nosūtīt vēstuli neesošam 'joe' uz 'snark'a. Atpakaļadreses @ccil.org rakstīšana ar roku ātri vien sagādātu pamatīgas mocības.

Tas noteikti bija kaut kas tāds, ko dators varētu izdarīt manā vietā. Bet neviens no esošajiem POP klientiem to nepiedāvāja! Un tas mums dod pirmo mācību

1. Visas labas programmas sākas, programmētājam kasot niezošo vietu.

Varbūt tas izskatās acīmredzami (kā "vajadzība ir izdomas māte" sakāmvārds), tomēr pārāk bieži programmētāji savas dienas aizvada rakstot programmas, kas tiem nedz patīk, nedz arī ir vajadzīgas. Bet ne Linux pasaulē — un tas varētu izskaidrot, kāpēc vidējā kvalitāte programmām, kas nākušas no Linux kopienas, ir tik augsta.

Vai es momentā sāku rakstīt jaunu POP3 klientu, lai cīnītos ar esošajiem? Nekad mūžā! Es uzmanīgi pārlūkoju visus POP rīkus un jautāju sev: "Kurš no tiem ir vistuvākais manām vajadzībām?", jo:

2. Labi programmētāji zina, ko rakstīt. Izcili zina, ko pārrakstīt (un atkalizmantot).

Lai arī es nepretendēju uz izcila programmētāja godu, vismaz cenšos tādu atdarināt. Izcilu eksemplāru svarīga īpašība ir konstruktīvs slinkums. Viņi zina, ka jūs iegūstat A nevis no piepūles, bet no rezultātiem, un vienmēr ir vieglāk sākt no laba daļēja risinājuma nekā sākt no nekā.

Piemēram, Linuss Torvalds nesāka rakstīt Linux no nulles. Tā vietā viņš sāka ar kodu un idejām no Minix — sīkas Unix-veidīgas operētājsistēmas PC kloniem. Galu galā Minix kods pazuda, jo tika pilnībā pārrakstīts, bet kamēr tas tur bija, un nodrošināja ietvaru aizmetņiem, kas vēlāk kļuva par Linux.

Ar tādu pašu nolūku, lai būtu izstrādes pamats, es izvēlējos kādu no esošajiem labi uzrakstītiem POP rīkiem.

Koda pieejamības tradīcijas Unix pasaulē vienmēr ir palīdzējušas koda atkalizmantošanai (tāpēc GNU projekts izvēlējās Unix kā bāzes OS, neskatoties uz vēso attieksmi pret pašu operētājsistēmu). Linux pasaule ir pieņēmusi šo tradīciju gandrīz vai kā tehnoloģisku likumu — tajā ir terabiti publiski pieejama atvērtā koda. Tāpēc, meklējot kādu gandrīz-vai-labu izstrādi, Linux pasaulē gūsiet labākus panākumus, kā jebkur citur.

Un arī es atradu. Kopā ar tiem, ko es jau biju apskatījis iepriekš, otrajā meklējumā es atlasīju deviņus kandidātus - fetchpop, PopTart, get-mail, gwpop, pimp, pop-perl, popc, popmail un upop. Pirmais, kam es pievērsos, bija Sendžhonga O (Seung-Hong Oh) fetchpop. Es ieliku tajā savu galvenes pārrakstīšanu un ieviesu vēl dažus uzlabojumus, ko autors iekļāva fetchpop 1.9 laidienā.

Pāris nedēļas vēlāk es tomēr iemaldījos Karla Harisa (Carl Harris) popclient kodā, un nonācu grūtas izvēles priekšā. Lai arī fetchpop bija dažas labas idejas (kā piemēram fona režīms), tas tomēr varēja apstrādāt tikai POP3 protokolu un bija uzrakstīts diezgan amatieriski (Sendžhongs tajā laikā bija spilgts, bet nepieredzējis programmētājs, un abas iezīmes atspoguļojās kodā). Karla kods bija labāks, pietiekami profesionāls un solīds, bet viņa programmā nebija daudzu svarīgu un diezgan viltīgi uztaisītu fetchpop īpašību (ieskaitot arī manis rakstītās).

Palikt vai pāriet? Ja es pārietu, es pazaudētu darbu, ko jau biju veicis, bet iegūtu labāku izstrādes bāzi.

Praktisks iemesls pārejai bija daudzu protokolu atbalsts. POP3 bija visizplatītākais pasta serveru protokols, bet ne vienīgais. Fetchpop un citi neatbalstīja ne POP2, ne RPOP, ne arī APOP, un man jau bija vārgas idejas par IMAP — visjaunākā un visspēcīgākā pasta apstrādes protokola pievienošanu.

Bet man bija arī daudz nopietnāks teorētisks pamats domāt, ka pāriet tomēr bija nepieciešams, jo šo to es biju iemācījies jau ilgi pirms Linux:

3. Plāno, kad pāriet! Tu to izdarīsi tik un tā!¹

Jeb citiem vārdiem, tikai tad, kad tu  esi sācis kaut ko reāli īstenot, tu pilnībā saproti problēmu. Otrreiz tu varbūt zini, kā to izdarīt pareizi. Tātad, ja gribi to izdarīt pareizi, esi gatavs sāk to no jauna vismaz vēl vienu reizi (JB).

Labi (es sev teicu) — izlabot fetchpop bija mans pirmais mēģinājums. Es pārgāju.

Kad es 1996. gada 25. jūnijā aizsūtīju savus pirmos popclient labojumus Karlam (Carl Harris), atklāju, ka viņš par to jau labu laiku ir pazaudējis interesi. Kods bija nedaudz putekļains, lēca ārā dažas sīkas kļūdas. Man vajadzēja veikt daudzas izmaiņas, un mēs ātri vienojāmies, ka būtu tikai loģiski, ja es turpinātu programmas izstrādi.

Tā, man gluži nemanot, projekts bija uzņēmis apgriezienus. Es vairs netaisīju sīkus ielāpus esošajā POP klientā. Es uzņēmos pārvaldīt visu, un manā galvā jau mutuļoja idejas, kā to visu radikāli pārmainīt.

Programmu izstrādes kultūrā tas iedibināja koda koplietošanu, un tas bija dabīgs projekta attīstības veids. Es sapratu sekojošu principu:

4. Ja tev ir pareiza attieksme, tevi atradīs interesantas problēmas.

Bet Karla Harisa attieksme bija vēl nozīmīgāka. Viņš saprata, ka: 

5. Kad tava interese par programmu ir zudusi, tavs pēdējais pienākums ir nodot to cienīgam pēcnācējam.

Bez īpašām diskusijām mēs ar Karlu sapratām, ka mums ir kopīgs mērķis — izveidot labāku risinājumu. Vienīgais jautājums bija, vai es varu pierādīt, ka mans roku pāris ir gana drošs. Kad es to izdarīju, viņš rīkojās ar cieņu un atkāpās. Es ceru, ka rīkošos tikpat cienīgi, kad pienāks mana kārta.

1. ^ Freds Brūks (Fred Brooks, The Mythical Man-Month, 11. nodaļa)