Fetchmail Grows Up
Fetchmail kasvaa isoksi
There I was with a neat and innovative design, code that I knew worked well because I used it every day, and a burgeoning beta list. It gradually dawned on me that I was no longer engaged in a trivial personal hack that might happen to be useful to few other people. I had my hands on a program that every hacker with a Unix box and a SLIP/PPP mail connection really needs.
Ja siinä sitä sitten oltiin, minä, siisti ohjelmakoodini ja paisuva beta-testaajien lista. Koska käytin ohjelmaa joka päivä, tiesin että se toimi hyvin. Asteittain minulle valkeni, että kyseessä ei enää ollutkaan tyhjänpäiväinen henkilökohtainen viritelmä, josta saattaisi olla hyötyä muutamalle muullekin. Tekeillä oli ohjelma, jota jokainen Unix-konetta ja SLIP/PPP-sähköpostiyhteyttä käyttävä hakkeri tarvitsisi.
"Beta list" on jatkumoa aloituslauseen koodille, eli sen lisäksi oli beta-lista versomassa 5.12.2008 (JP)
With the SMTP forwarding feature, it pulled far enough in front of the competition to potentially become a "category killer", one of those classic programs that fills its niche so competently that the alternatives are not just discarded but almost forgotten.
Ohjelmallani oli SMTP-välityksen ansiosta niin pitkä etumatka kilpailijoihin verrattuna, että sillä oli mahdollisuus tulla ylivoimaiseksi omassa luokassaan. Siitä voisi kehkeytyä yksi klassikoista eli ohjelmista, jotka ovat alallaan niin ylivertaisia, että vaihtoehdot jäävät pois käytöstä ja joutuvat lähestulkoon kokonaan unohduksiin.
'Killer' on taas yksi väkivaltainen ilmaus josta on koetettu tehdä alan slangia, mutta se on yhä huonoa englantia, ja sen takia kirjoittaja koettaa suojella sanavalintaa lainausmerkeillä. Suomessa 'tappaja' on liian konkreettinen ilmaus tässä yhteydessä. - Jopi
I think you can't really aim or plan for a result like this. You have to get pulled into it by design ideas so powerful that afterward the results just seem inevitable, natural, even foreordained. The only way to try for ideas like that is by having lots of ideas—or by having the engineering judgment to take other peoples' good ideas beyond where the originators thought they could go.
Mielestäni tällaista lopputulosta ei voi tavoitella etukäteen. Ohjelmoija vain tempautuu ideoiden vietäväksi, ja joskus niiden imu on niin vahva, että lopputulos näyttää jälkeenpäin luonnolliselta, väistämättömältä ja jopa ennalta määrätyltä. Tähän pääsee, jos tuottaa monia ideoita tai jos pystyy kehittäjän näkemyksellä viemään muiden esittämiä hyviä ideoita pidemmälle kuin niiden esittäjien usko kantaa.
Tarkastettava: foreordained?; poistin sinä-passiivin (korvattu "koodarilla")
Andy Tanenbaum had the original idea to build a simple native Unix for IBM PCs, for use as a teaching tool (he called it Minix). Linus Torvalds pushed the Minix concept further than Andrew probably thought it could go—and it grew into something wonderful. In the same way (though on a smaller scale), I took some ideas by Carl Harris and Harry Hochheiser and pushed them hard. Neither of us was `original' in the romantic way people think is genius. But then, most science and engineering and software development isn't done by original genius, hacker mythology to the contrary.
Andy Tanenbaumin alkuperäinen idea oli laatia yksinkertainen natiivi Unix-käyttöjärjestelmä IBM PC:ille opetuskäyttöön. Hän antoi työlleen nimen Minix. Linus Torvalds vei Minix-idean pidemmälle kuin Andrew oli ajatellut, ja lopputuloksesta tuli mahtava. Samalla tavalla vaikkakin pienemmässä mittakaavassa otin joitakin ideoita Carl Harrisilta ja Harry Hochheiseriltä ja vein niitä mahdollisimman pitkälle. Kumpikaan meistä ei ollut omaperäinen siinä romantisoidussa mielessä, jossa puhutaan neroista. Se on vain niin, että suurinta osaa tieteestä, tekniikasta ja ohjelmistonkehityksestä eivät ole tuottaneet omaperäiset nerot, vaikka esimerkiksi hakkerimytologia niin väittää.
The results were pretty heady stuff all the same—in fact, just the kind of success every hacker lives for! And they meant I would have to set my standards even higher. To make fetchmail as good as I now saw it could be, I'd have to write not just for my own needs, but also include and support features necessary to others but outside my orbit. And do that while keeping the program simple and robust.
Joka tapauksessa tuloksena syntyi varsin laadukasta koodia. Juuri sellaista, jota tuottaakseen jokainen hakkeri elää! Se tarkoitti samalla, että vastaisuudessa minun olisi asettava tavoitteet vielä korkeammalle. Päästäkseni Fetchmailissa siihen, minkä näin mahdolliseksi, ei riittäisi että saisin ohjelman toimimaan tavalla, jota itse tarvitsin. Ohjelmaan tuli liittää ominaisuuksia, joita kaivattiin oman lähipiirini ulkopuolella. Samalla tuli säilyttää ohjelman yksinkertaisuus ja vakaus.
Korjattu 2 aikamuotovirhettä, esimerkiksi 'And they meant I would have to set my standards even higher' ei ole '...että minun olisi pitänyt asettaa tavoitteeni korkeammalle.' Nämä olivat jälleen kiusallisia virheitä, sillä korjaamattomina ne olisivat saaneet kirjoittajan kuulostamaan hölmöltä ja koko tekstin uskottavuus olisi kärsinyt. - Jopi
robust=vakaa,vankka,roteva
The first and overwhelmingly most important feature I wrote after realizing this was multidrop support—the ability to fetch mail from mailboxes that had accumulated all mail for a group of users, and then route each piece of mail to its individual recipients.
Tajuttuani tilanteen liitin ohjelmaan tuen viestien jakelulle moneen osoitteeseen (multidrop). Se tarkoittaa viestien noutamista niitä keränneistä postilaatikosta ja niiden jakamista suoraan usealle vastaanottajalle.
Tässä voi olla paikallaan liittää suomenkieliseen tekstiin suluissa alkuperäinen englanninkielinen termi, jotta kiinnostunut lukija löytää siitä helposti lisätietoa. 'Fetchmail can either retrieve mail from specific mailboxes and deliver it to specific mailboxes, in what is called singledrop mode, or it can retrieve messages from one source mailbox and deliver them to multiple recipient mailboxes, in what is called multidrop mode.' Ks. http://www.scalix.com/wiki/index.php?title=HowTos/Fetchmail - Jopi.
I decided to add the multidrop support partly because some users were clamoring for it, but mostly because I thought it would shake bugs out of the single-drop code by forcing me to deal with addressing in full generality. And so it proved. Getting RFC 822 address parsing right took me a remarkably long time, not because any individual piece of it is hard but because it involved a pile of interdependent and fussy details.
Lisäsin monijakelun tuen osittain sen vuoksi, että eräät käyttäjät olivat vaatineet sitä. Tärkein syy oli kuitenkin, että uskoin muutoksen paljastavan virheitä alkuperäisestä, kertajakeluun perustuneesta ohjelmasta. Uskoin, että uuden ominaisuuden toteuttaminen pakottaisi minut käsittelemään viestien välitystä yleisemmästä näkökulmasta. Niin tapahtuikin. RFC 822 -standardin mukaisen osoitteiden käsittelyn toteuttaminen vei minulta huomattavan paljon aikaa. Mikään yksittäinen osa ei ollut vaikea, mutta työ vaati tarttumista kokonaiseen kasaan toisistaan riippuvia ja huolenpitoa vaativia yksityiskohtia.
But multidrop addressing turned out to be an excellent design decision as well. Here's how I knew:
Monijakelun toteuttaminen osoittautui erinomaiseksi suunnittelupäätökseksi, sillä:
14. Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.
14. Jokaisen työkalun tulee palvella tarkoitetulla tavalla; mahtava työkalu sopii yllättäviinkin tarkoituksiin.
The unexpected use for multidrop fetchmail is to run mailing lists with the list kept, and alias expansion done, on the client side of the Internet connection. This means someone running a personal machine through an ISP account can manage a mailing list without continuing access to the ISP's alias files.
Fetchmailin monijakelun yllättävä käyttötarkoitus on postituslistojen hallinta. Listoja voidaan hallita ja listanimet muuttaa vastaanottajien osoitteiksi internet-yhteydenpitoon käytetyllä henkilökohtaisella tietokoneella. Tietokoneella ei tarvitse olla jatkuvaa yhteyttä palveluntarjoajan osoitetiedostoihin.
Kankeaa. alias expansion tarkoittaa sähköpostilistan nimen muuttamista vastaanottajien osoitteiksi (tähän liittyy alias-listat, joissa kerrotaan mitä osoitetta tai osoitteita mikäkin nimi tarkoittaa).
Another important change demanded by my beta-testers was support for 8-bit MIME (Multipurpose Internet Mail Extensions) operation. This was pretty easy to do, because I had been careful to keep the code 8-bit clean (that is, to not press the 8th bit, unused in the ASCII character set, into service to carry information within the program). Not because I anticipated the demand for this feature, but rather in obedience to another rule:
Beta-testaajat vaativat myös tukea 8-bittiselle MIMElle (Multipurpose Internet Mail Extensions). Se oli melko helppo tarjota, koska olin pitänyt huolen siitä, että ohjelma käsittelee oikein 8-bittisiä merkkijoukkoja. Toisin sanoen en ollut hyödyntänyt ASCII-merkkijoukossa käyttämättömäksi jäänyttä kahdeksatta bittiä ohjelman sisällä. En ollut arvannut, että 8-bittisyydelle alettaisiin vaatia tukea, vaan olin vain noudattanut seuraavaa sääntöä:
'Eight-bit clean describes a computer system that correctly handles 8-bit character sets, such as the ISO 8859 series and the UTF-8 encoding of Unicode.' Ks. http://en.wikipedia.org/wiki/Eight-bit_clean - Jopi.
15. When writing gateway software of any kind, take pains to disturb the data stream as little as possible—and never throw away information unless the recipient forces you to!
15. Mitä tahansa yhdyskäytäväohjelmaa laaditkin, häiritse datavirtaa mahdollisimman vähän, äläkä koskaan heitä hukkaan mitään informaatiota, ellei vastaanottaja pakota siihen!
"...äläkä koskaan heitä pois mitään informaatiota"
Mikä on yhdyskäytäväohjelma?!
Had I not obeyed this rule, 8-bit MIME support would have been difficult and buggy. As it was, all I had to do is read the MIME standard (RFC 1652) and add a trivial bit of header-generation logic.
Jos en olisi noudattanut tätä sääntöä, 8-bittisen MIME-tuen toteuttaminen olisi ollut vaikeaa, ja toteutukseen olisi tullut virheitä. Nyt minun tarvitsi vain lukea MIME-standardi (RFC 1652) ja lisätä ohjelmaani yksinkertainen koodinpala viestien otsakkeiden muodostamiseksi.
käännetäänkö buginen? on kyllä aika mukava sana, kun sitä ei liikaa käytetä (melkein kaikkialta muualta suomennettu)
Some European users bugged me into adding an option to limit the number of messages retrieved per session (so they can control costs from their expensive phone networks). I resisted this for a long time, and I'm still not entirely happy about it. But if you're writing for the world, you have to listen to your customers—this doesn't change just because they're not paying you in money.
Jotkut eurooppalaiset käyttäjät kinusivat minua lisäämään mahdollisuuden rajoittaa istunnon aikana noudettavien viestien määrää. Näin he voisivat vähentää kalliiden puhelinyhteyksien aiheuttamia kuluja. Vastustelin ehdotusta pitkään, enkä ole vieläkään täysin tyytyväinen siihen. Jos kuitenkin tekee ohjelmia maailmalle, on kuunneltava asiakkaita. Sillä ei ole merkitystä, että siitä ei makseta rahaa.
olisiko "to bug" sanalla parempi käännös kuin "kinuta"? "kärttää?"