[python] Fwd: Vydání knihy o pythonu
slush
slush na centrum.cz
Pátek Květen 23 21:44:40 CEST 2008
Na napsani knihy neni nic spatneho, byl to jen maly dodatek o tom, ze
samotny tisk knihy je az tresnicka na dortu.
Ja myslim, ze ke konci dlooouhe diskuze mezi mnou a supermanem jsme pomalu
nachazeli spolecnou notu. Rozhodne si nemyslim, ze by tu vzniklo nekolik
rozdilnych taboru :). Zatim spis nevidim tabor ani jeden ;).
Marek
2008/5/23 Jarek Krcmar <krcmar1 na volny.cz>:
> Zdravím,
>
> také bych byl pro napsání knihy, na tom není nic špatného.
>
> Nevím, kdo je moderátorem této konference, ale myslím, že nezáleží na tom,
> kdo má jakou přezdívku.
>
> Ať Slush nebo Supermann, všichni by měli táhnout za jeden provaz.
>
> Doufám, že tímto mailem jsem si nevysloužil kamenování.
>
> Jarek
>
> ----- Original Message -----
> From: "superman" <feed na centrum.cz>
> To: "Konference PyCZ" <python na py.cz>
> Sent: Friday, May 23, 2008 3:06 PM
> Subject: Re: [python] Fwd: Vydání knihy o pythonu
>
>
> slush napsal(a):
> >
> > Dokonalá je jenom smrt. Vždycky je množství lidí schopných účastnit
> se
> > jakéhokoli projektu omezené, a nikdo to nebylo a nebude jinak.
> >
> >
> > Ano, ale někde (účastníci české konference py.cz <http://py.cz>) je ta
> > množina ještě omezenější, než jinde (programátoři pythonu celého
> > světa, schopní psát).
>
> Množina lidí píšících tuto knihu (pokud se rozjede) je mnohem větší, než
> množina lidí pro řadu jiných kolektivních projektů.
>
> > > Z toho plyne, že definovat a zakonzervovat obsah publikace
> > předem, než
> > > známe cokoliv víc, než že můj nick je slush a Váš superman je
> prostě
> > > nesmysl. Kolektivní práce tak nefunguje, cokoliv se může kdykoliv
> > > změnit/upravit, pokud se najde někdo, ochotný dopsat zajímavou
> > > kapitolu a ostatní s tím budou souhlasit.
> > Proč je to nesmysl? To za prvé a za druhé nikdo o zakonzervování
> > nemluvil.
> >
> >
> > Minimálně to nemá smysl. Není k tomu důvod.
>
> Je nesmysl začít stavět jen na chaosu, a stejný nesmysl je začít stavět
> na zkonstnatělé struktuře. Teď jde o to nebýt ani v jednom extrému.
>
>
> >
> >
> > Bůh možná minimalizoval své náklady - protože on neplatí v dolarech a
> > jeho náklady jsou vyjádřené jinou "měnou". Pro něj bylo nejméně
> pracné
> > stvořit třeba evoluci a pouze to nastartovat a pak to běželo bez jeho
> > zásahu. Můžeme knížku udělat stejně - stvořit roboty schopné napsat
> > knížku, kteří se dokáží rozmnožovat a evolučně tu knihu časem
> napíšou.
> >
> >
> > Ženete to do extrémů. Na druhou stranu si můžete sednout na chatu a
> > napsat tu knížku sám a za den. To nic neříká o tom, jestli budete
> > úspěšnější než ostatní. Jsou to jen dva druhy přístupů.
>
> Jasan, že ženu. Nicméně řešili jsme spíše otázky Božích záměrů :-)
>
> >
> >
> > To, že mě nikdo nebude platit neznamená, že moje práce nemá cenu, a
> že
> > si jí nevážím, byť jí třeba dělám zadarmo. Klidně udělám 2x tolik
> > práce,
> > když výsledkem bude lepší kvalita, nebo vyšší spokojenost. Ale i když
> >
> > dělám věci zadarmo, nerad bych aby moje práce šla vniveč a nikdo si
> jí
> > nevážil jen proto, že jí neplatil. Nebo snad mi chcete říct, že když
> > dělám něco zadarmo, že mi budete dávat najevo, že jsem blb, který
> > klidně
> > může té práce udělat 10x tolik jen proto, že se špatně
> > zorganizuje, a že
> > nikomu nezáleží na tom, aby se práce dělala dobře a s nejmenší možnou
> > námahou?
> >
> >
> > Overhead != špatná organizace. Může to být jen důsledek vylepšování
> > kvality. Ano, může to být i známka chaosu. Neuvidíme, dokud nezkusíme.
>
> Matematicky řečeno, overhead nerovná se špatná organizace, ale obrácená
> věta platí, tedy špatná organizace rovná se obrovský a zbytečný
> overhead. Zkoušet něco, co zbytečný overhead generuje už z principu v
> 99,99999% a spoléhat se na to, že budete patřit do 0,00001% případů, kdy
> to vyjde bez overheadu je možné, ale mě to třeba nestačí. Raději zvolím
> metodu, která overhead využije ke zvýšení kvality, a ne k potlačení
> choasu, který je zbytečný a vznikl jen proto, že nikdo nechtěl nc
> jasného na začátku definovat.
>
>
> >
> > Snažit se o dělání práce s co nejmenší námahou sice dlouhodobě
> > zajišťuje rozvoj lidstva, někdy je ale lepší začít dělat věci vůbec
> > nějak než čekat, že vymyslíme dokonalý způsob.
>
> Souhlasím. Někdy je lepší plánovat, a někdy se prostě do toho vrhnout a
> přemýšlet až pak. Ale nejsem si jist, zda druhý způsob v krystalicky
> čisté podobě je vhodný pro psaní knížky nad pár desítek stran.
>
> >
> > A pokud ty texty na sebe nebudou navazovat, výsledkem je 100%
> toaletní
> > papír a zbytečná práce dvaceti lidí.
> >
> >
> > Zkuste definovat pravidla tak, aby se to nestalo.
>
> Já je definoval, nastavme na začátku témata, osnovu, základní (byť velmi
> volná) pravidla psaní a styl (šablonu) a máte velkou šanci, že knihu
> dopíšete, i kdyby zbytek byl v chaosu.
>
>
> >
> >
> > > Když už jsme u toho, zatímco tvůrčí potenciál MS je víceméně
> > > konstantní (firma nemůže najmout výrazně více kvalitních lidí),
> > tempo
> > > vylepšování linux kernelu se stále zrychluje.
> > Důkazy?
> >
> >
> > Velikost changelogu v roce 1997 a v roce 2007?
>
> Jednou jsem dělal na sw projektu, kde projekt řídil marketinkový
> odborník dosazený ze známosti. Po cca měsíci jsem odešel, nicméně
> kritérium kvality byla výsledná velikost binárky. Čím větší binárka, tím
> spokojenější vedoucí. Jistě cítíte, že kvalita takto nevzniká. A mě už
> nebavilo zvětšovat počet prvků v poli s názvem make_binary_image_look_big.
>
> >
> > Nenutil. Ale ani jsem o to neměl zájem, což bylo to co jsem chtěl
> > říci.
> > Zato jsem měl zájem o jinou systémovou práci a užil jsem si jí
> > dosytosti. Z hlediska uspokojení jsem zcela spokojen.
> >
> >
> > Já za tvorbou té knihy vidím naopak nutnost dobrého systému. Jen jde o
> > to měřítko, kterým zkoumáte, co je dobré a co špatné. Pro Vás to je
> > minimalizace overheadu, pro mě to je možnost kooperace a iterativní
> > zvyšování kvality.
>
> A obě věci nejdou proti sobě. Uvědomte si ještě jednu věc, pokud budete
> iterativně zvyšovat kvalitu - což nutně znamená, že výsledek bude za
> několikanásobek času, než když použijete metodu promyslím pořádně základ
> na začátku - spousta lidí odpadne, protože je nebude bavit čekat
> nekonečně dlouho na nějaký výsledek. A možná, že projekt se ani
> nedokončí, protože nebudou lidi. Ono je to spíš velmi pravděpodobný
> výsledek iterativního postupu.
>
> >
> >
> > Část práce se zahodí vždy, protože ne vše se na začátku odhadne. Ale
> > zahodit práce jen proto, že někdo je shnilý to seriózně definovat -
> do
> > toho nejdu a těch 80% je velmi optimistických, v reále toho bývá
> > daleko
> > váce zahozeno.
> >
> >
> > Tak do toho nechoďte. Pokud s něčím nesouhlasíte, nemusíte se toho
> > účastnit a brojit proti tomu v diskuzi.
>
> Chcete, aby s Vámi diskutoval jen přikyvovač a člověk, který Vám bude
> vyprávět jak jste geniální? Měl jste to říct rovnou.
>
> >
> > Část práce se zahodí, kdykoliv někdo napíše část textu lépe než Vy.
> > Napište ji stoprocentně a zůstane ve finální revizi. Napište mi jiný
> > důvod, proč by někdo měl vyjímat kvalitní text, který jste publikoval.
>
> Protiřečíte si. Na jedné straně na začátku mluvíte o omezeném počtu
> lidí, kteří se toho budou účastnit. Na druhé straně uvažujete o
> vícenásobném přepisu kapitol. Tato varianta nastat může, ale můžu se s
> Vámi vsadit, že do první finální revize častěji uvidíte Yetiho, než že
> by někdo přepsal kapitolu po někom, a ještě lépe. Varianta přepisu se
> uplatňuje až u projektů, které to někam dotáhly, a nebo kterým lidi
> strašně věří - a to bývá až tehdy, když je nějaký výsledek.
>
>
>
> _______________________________________________
> Python mailing list
> Python na py.cz
> http://www.py.cz/mailman/listinfo/python
>
> _______________________________________________
> Python mailing list
> Python na py.cz
> http://www.py.cz/mailman/listinfo/python
>
------------- další část ---------------
HTML příloha byla odstraněna...
URL: http://www.py.cz/pipermail/python/attachments/20080523/a177fda9/attachment.htm
Další informace o konferenci Python