When Is a Rose Not a Rose?
Milloin ruusu ei ole ruusu?
-Mitenkäs olisi 'Kun ruusu ei olekaan ruusu' -Tämä taitaa viitata johonkin eng-kieliseen sanaleikkiin (Rose is a rose is a rose is a rose), tähän sopisi varmaan jokin muu kuin suora käännös (ehkä jokin suomalainen sananlasku/mukaelma, ei nyt vain tule mieleen)
Having studied Linus's behavior and formed a theory about why it was successful, I made a conscious decision to test this theory on my new (admittedly much less complex and ambitious) project.
Tutkittuani Linuksen toimintatapaa ja muodostettuani teorian sen menestymisen syystä päätin testata teoriaani omassa projektissani, vaikka se ei ollutkaan niin monimutkainen ja kunnianhimoinen kuin hänen työnsä.
"Test" - kokeilla, testata vaikuttaa käännöslainalta; Linus-erisnimen taivutus - Linuksen vai Linusin? Nikkasen "Linuxin tarina" kirjassa käytetään Linuksen.; avasin sulkeet 5.12.2008 (JP);
But the first thing I did was reorganize and simplify popclient a lot. Carl Harris's implementation was very sound, but exhibited a kind of unnecessary complexity common to many C programmers. He treated the code as central and the data structures as support for the code. As a result, the code was beautiful but the data structure design ad-hoc and rather ugly (at least by the high standards of this veteran LISP hacker).
Ensiksi kuitenkin uudistin POP-asiakasohjelman rakennetta ja yksinkertaistin sitä. Carl Harrisin toteutusratkaisut olivat päteviä mutta turhan monimutkaisia, mikä on yleistä C-ohjelmoijille. Ohjelmakoodi oli keskeistä, ja tietorakenteiden tehtävänä oli tukea koodia. Harrisin ohjelmointityyli oli kaunista, mutta tietorakenteet oli suunniteltu tapauskohtaisesti improvisoiden, vieläpä kömpelösti ainakin tämän, kaiken kokeneen LISP-hakkerin korkeiden laatuvaatimusten mukaan.
Sopiiko, että pop kirjoitetaan tässä julkaisussa aina POP, eli ollaan tässä johdonmukaisempia kuin alkuperäinen teksti. - Jopi
ad-hoc = tätä (tarkoitusta) varten
-"varta vasten tehty", juuri tätä tarkoitusta varten poikkesin alkuperäisteksistä saadakseni rakenteen näyttämään suomelta veteraani-LISP-hakkeri lienee rumuudestaan huolimatta yhdyssana - käänsin "kaiken kokeneeksi LISP-hakkeriksi" 5.12.2008 (JP)
I had another purpose for rewriting besides improving the code and the data structure design, however. That was to evolve it into something I understood completely. It's no fun to be responsible for fixing bugs in a program you don't understand.
Ohjelman uudelleenkirjoittamiselle minulla oli muukin syy kuin koodin ja tietorakenteiden kohentaminen. Tarkoitukseni oli saavuttaa täysi ymmärrys ohjelmasta. Ei nimittäin ole kiva olla vastaamassa ohjelman virheiden korjaamisesta, jos ei ymmärrä ohjelman toimintaa.
For the first month or so, then, I was simply following out the implications of Carl's basic design. The first serious change I made was to add IMAP support. I did this by reorganizing the protocol machines into a generic driver and three method tables (for POP2, POP3, and IMAP). This and the previous changes illustrate a general principle that's good for programmers to keep in mind, especially in languages like C that don't naturally do dynamic typing:
Arviolta ensimmäisen kuukauden ajan seurailin Carlin perussuunnitelmaa. Ensimmäinen merkittävä muutos tuli, kun lisäsin ohjelmaan IMAP-tuen. Toteutin muutoksen järjestelemällä protokollan toiminnan yleisajuriksi ja kolmeksi menetelmätauluksi (POP2, POP3 ja IMAP). Muutos noudattaa yleistä periaatetta, jota kannattaa pitää mielessä erityisesti C:n kaltaisissa kielissä, jotka eivät luonnostaan tue dynaamista ohjelmistorakennetta:
3. lause sukkaa. - Korjailin, Sukkaako vielä?
9. Smart data structures and dumb code works a lot better than the other way around.
9. On parempi käyttää fiksuja tietorakenteita ja tyhmää koodia kuin toisinpäin.
"Fiksut tietorakenteet ja typerä koodi toimivat paljon paremmin kuin toisinpäin."
Brooks, Chapter 9: "Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious." Allowing for thirty years of terminological/cultural shift, it's the same point.
Fred Brooks toteaa kirjansa yhdeksännessä luvussa: "Näytä minulle vuokaavio ja piilota taulukot, niin en saa mitään tolkkua. Jos näytät taulukon, en yleensä edes tarvitse vuokaaviota, koska se on ilmiselvä." Kuluneen 30 vuoden aikana terminologia ja ohjelmistokulttuuri ovat muuttuneet, mutta periaate pätee yhä.
En saa mitään järkevää aikaiseksi toisesta lauseesta. - Tarkoititko kolmatta? Olisiko se nyt oikein?
MIstä taulukoista tässä puhutaan? Tietokannan tauluista? ei ymmärrä...? Jotain kaivataan taulukoiden tilalle? --rhk
At this point (early September 1996, about six weeks from zero) I started thinking that a name change might be in order—after all, it wasn't just a POP client any more. But I hesitated, because there was as yet nothing genuinely new in the design. My version of popclient had yet to develop an identity of its own.
Tässä vaiheessa elettiin syyskuun alkua vuonna 1996, ja oli kulunut noin puolitoista kuukautta siitä, kun olin aloittanut projektini. Silloin alkoi tuntua, että ohjelman nimen vaihtaminen saattaisi sittenkin olla paikallaan, sillä kyseessä ei enää ollut pelkkä POP-asiakasohjelma. Epäröin, sillä ohjelmassa ei ollut vielä mitään todella uutta. POP-asiakasohjelmaltani puuttui oma identiteetti.
That changed, radically, when popclient learned how to forward fetched mail to the SMTP port. I'll get to that in a moment. But first: I said earlier that I'd decided to use this project to test my theory about what Linus Torvalds had done right. How (you may well ask) did I do that? In these ways:
Kaikki muuttui, kun POP-asiakasohjelma oppi välittämään noudetut viestit edelleen SMTP-porttiin. Palaan tähän pian, mutta ensin kerron, miten testasin tässä projektissa teoriaani siitä, miksi Linus Torvaldsin toimintatapa oli onnistunut. Testasin ajatustani näin:
Miten suomentaa "forward"? "Edelleenlähettää" on huonoa suomea, mutta onko "lähettää edelleen" teknisesti oikein?
- I released early and often (almost never less often than every ten days; during periods of intense development, once a day).
- I grew my beta list by adding to it everyone who contacted me about fetchmail.
- I sent chatty announcements to the beta list whenever I released, encouraging people to participate.
- And I listened to my beta-testers, polling them about design decisions and stroking them whenever they sent in patches and feedback.
- Julkaisin uusia versioita varhain ja tiheästi, yleensä alle kymmenen päivän välein ja intensiivisissä kehitysvaiheissa päivittäin.
- Kasvatin beta-testaajien listaa lisäämällä siihen jokaisen, joka otti minuun yhteyttä Fetchmailiin liittyvissä asioissa.
- Lähetin jutustelevia viestejä beta-listalle aina. kun sain uuden version valmiiksi, ja rohkaisin näin ihmisiä osallistumaan työhön.
- Kuuntelin beta-testaajiani, pidin äänestyksiä suunnittelupäätöksistä ja annoin päänsilitystä aina, kun he lähettivät korjauksia ja palautetta.
Miten on tuo "stroke" -> "paijata"? Olisiko mieluummin vaikka "kehaista"? Käykö imarrella? (ehdotukseni) 5.12.2008 (JP)
The payoff from these simple measures was immediate. From the beginning of the project, I got bug reports of a quality most developers would kill for, often with good fixes attached. I got thoughtful criticism, I got fan mail, I got intelligent feature suggestions. Which leads to:
Pienet teot tuottivat välitöntä tulosta. Kehittäjät tekisivät mitä tahansa, jos heille luvattaisiin niin laadukkaita virheraportteja kuin minulle lähetettiin projektin alusta lähtien. Sain asiantuntevaa kritiikkiä, ihailijapostia, fiksuja ideoita uusista ominaisuuksista. Tästä voidaan päätellä:
Amerikassa rakastetaan murhaamista ja sotaa, suomen kielellä nämä sanat kuulostavat turhan väkivaltaisilta. - Jopi.
10. If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource.
10. Kohtele beta-testaajia arvokkaimpana voimavaranasi, niin se heistä tulee.
One interesting measure of fetchmail's success is the sheer size of the project beta list, fetchmail-friends. At the time of latest revision of this paper (November 2000) it has 287 members and is adding two or three a week.
Yksi mielenkiintoinen Fetchmailin menestyksen mittari on beta-testaajien listan laajuus. Kun kirjoitan tätä marraskuussa 2000 listalla on 287 jäsentä, ja lisää tulee pari kolme viikossa.
Actually, when I revised in late May 1997 I found the list was beginning to lose members from its high of close to 300 for an interesting reason. Several people have asked me to unsubscribe them because fetchmail is working so well for them that they no longer need to see the list traffic! Perhaps this is part of the normal life-cycle of a mature bazaar-style project.
Toukokuussa 1997 listan jäsenmäärä alkoi huveta huipulta, 300:n tasolta kiinnostavasta syystä. Useat henkilöt pyysivät jättämään itsensä pois postituslistalta, koska heidän mielestään Fetchmail toimi jo niin hyvin, ettei heillä ollut enää tarvetta seurata listan viestejä! Ehkäpä tällainen on tavallista basaariprojektin elinkaaren kypsässä vaiheessa.
mature, parempi suomennos tarpeen. "matuurin" tai "kypsän basaariprojektin". - säädin vähän koko kappaletta.