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 <[EMAIL PROTECTED]>: > 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" <[EMAIL PROTECTED]> > To: "Konference PyCZ" <python@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@py.cz > http://www.py.cz/mailman/listinfo/python > > _______________________________________________ > Python mailing list > Python@py.cz > http://www.py.cz/mailman/listinfo/python >
_______________________________________________ Python mailing list Python@py.cz http://www.py.cz/mailman/listinfo/python