Dočtete se o Ruby, které je sice objektové, ale dynamicky typované a zkrátka jiné, než Java na kterou jsem zvyklý.

Dalším jazykem je IO, o kterém jste asi nikdo neslyšel, ale pěkně ukazuje myšlenky objektového programování za pomocí prototypů. Něco jak má JavaScript.

Pak tu máme Prolog, který je starý, známý na univerzitách, ale v praxi se s ním moc často nesetkáte. Zase úplně jiný styl programování. Dovolil bych si říci superdeklarativní.

Nesmí chybět ani Scala, která umí skoro všechno co umí ostatní, ale není díky tomu tak čistá.

Po ní přijde na řadu Erlang, který je výjimečný svojí robustností a paralelizovatelností.

Předposledním jazykem je Clojure, což není nic jiného než zakuklený Lisp běžící nad JVM.

Peloton uzavírá Haskell, zástupce čistě funkcionálních jazyků. Údajně jeden z mála úspěšných jazyků navrhovaných komisí a ne jednotlivci.

Pro mě tato kniha byla hodně užitečná. Docela jsem si rozšířil obzory. Na škole jsme to totiž buď nebrali nebo jsem nedával pozor, takže i uvedené základy pro mě byly přínosné. Jenom musím upozornit, že se opravdu nejde moc do hloubky, u každého jazyka se dozvíte jaké jsou jeho zvláštnosti, pár jeho předností a na co se to asi dá použít. Vše ukázáno na více či méně zajímavých příkladech. Nic víc, nic méně. Z vybraných jazyků jsem znal jen Scalu a o té se v knize dočtete opravdu jen to nejnutnější. Očekávám, že u ostatních jazyků to bude stejné.

Takže nečekejte žádné referenční příručky, spíše jen takové odkazy pro další studium. Ale i tak to mohu doporučit, člověk si rozšíří obzor a uvědomí si, že není jen silně typované objektově orientované programování. Jelikož se to navíc docela dobře čte, tak dávám sedm hvězdiček z deseti.

Pokud ji chcete koupit elektronicky, pak doporučuji stránky vydavatelství. Dostanete jak verzi v PDF, tak mobi pro Kindle a epub pro další zařízení. Všechno bez DRM, jen tam je napsáno, že to je připraveno pro vás. Tak se mi to líbí.

Nevěřím, že cokoliv revolučního bylo kdy vymyšleno komisí. Komise by se na tom totiž nikdy nedohodla!
Steve Wozniak

Jenom chci upozornit na docela zajímavou knížku. Jmenuje se iWoz a je to autobiografie Steve Wozniaka, člověka, bez kterého by nevznikla firma Apple, člověka, který prý jako první sestrojil osobní počítač s klávesnicí a monitorem. Docela dobře se to čte, člověk se tam i dost věcí doví. Knížka mi hodně připomněla „To nemyslíte vážně, pane Feynmane!“, oni si oba pánové byli asi dost podobni. Takže pokud vás zajímá jak fungují a žijí géniové, tak doporučuji.

Docela mě zaujala myšlenka o tom, jak nic revolučního nikdy nebylo vymyšleno komisí. Přesně to samé psal i pan Brooks v knize, o které jsem psal minule. Ten tam měl i takovou pěknou tabulku, kde uváděl produkty, které mají zanícené fanoušky.

Zajímavé je, že věci napravo vznikly pomocí formálního procesu, věci vlevo vznikaly mimo normální produktové procesy. Neznamená to, že by věci vpravo byly horší, jenom už nejsou tak originální a je méně časté, že by k nim lidi měli emocionální vztah. Mimochodem, právě Steve Wozniak, je autorem Apple II.

Nejtěžší část návrhu je přijít na to, co vlastně navrhujeme.

Nakonec mi pomalu začalo docházet, že to nejužitečnější, co pro zákazníka dělám, je pomoc v rozhodování o tom co vlastně potřebuje.

Jakýkoliv pokus o formulaci všech možných požadavků na začátku projektu selže a způsobí podstatné zpoždění.
PAHL AND BEITZ, ENGINEERING DESIGN

Po delší době se mi do rukou dostala technická knih, který mě opravdu zaujala. Nespáchal ji nikdo jiný než Fredercik Brooks a jmenuje se The Design of Design: Essays from a Computer Scientist.

Pokud si nevybavujete, kdo je pan Brooks, tak vám připomenu, že to je člověk, který napsal v roce 1975 klasiku „The Mythical Man Month“, dělal projekťáka při konstukci IBM System/360, pomáhal americké armádě s projekty a podobně. Zkrátka je to člověk, který ví, o čem mluví.

Z té knihy je to vidět. Mluví v ní obecně o návrhu software, hardware, domů nebo i knih. Dost se v knize opírá do našeho oblíbeného vodopádového modelu. V zásadě říká, že vodopád nemůže efektivně fungovat, což mě od člověka takového formátu těší. Kniha by se dala číst jako chvála agilního vývoje, i když slova agilní jsem si všiml jenom jednou. Ale jinak tam prosazuje většinu agilních fint jako používání vlastní hlavy, používání iterací, důraz na talentované lidi nebo třeba častou komunikaci se zákazníkem. Staví se také proti používáni rigidních procesů, když chce člověk vymyslet něco inovativního.

V první části představuje racionální postup při návrhu. Něco ve stylu „dokud nejsou splněny všechny požadavky a návrh není dost dobrý, procházej všechny možnosti návrhu a hledej ty které maximalizují užitnou hodnotu.“ V dalších částech vysvětluje proč tento postup nejde použít. Například proto že možností návrhu je nesmírné množství, požadavky jsou nejisté a nestálé, užitná hodnota je vágně definovaná a podobně. Určitě to znáte sami, pan Brooks to ale pěkně systematizuje.

Zajímavá kapitola je o racionalizmu a empirizmu. Je to trochu filozofický problém, ale pro nás velmi důležitý. Točí se kolem otázky: „Dokáži jenom pomocí přemýšlení správně navrhnout složitý objekt?“ Racionalisté věří že ano, empirici věří že ně. Já se stejně jako autor řadím mezi empiriky, ale dovedu si představit, že někdo věří i v opak. Mám za to, že ho z toho praxe rychle vyléčí, ale je možné že ne. V knize se dozvíte více detailů i argumentů pro empirizmus.

V dalších kapitolách se zamýšlí, jak tedy ten návrh dělat, pokud na to není žádný recept. V zásadě tvrdí něco podobného jako agilisti: „Sežeňte si šikovné designéry a dejte jim prostor a prostředky k tomu, aby se mohli realizovat.“

Samozřejmě i na této knize najdete pár mušek. Třeba v kapitolách 17 a 18 navrhuje dokonalý systém pro domovní architekty. Musím se přiznat, že tyto části jsem přeskočil. Dobrý úlet je i část 16, kde popisují, jak se ještě s jedním spoluautorem pokoušeli zaznamenat rozhodnutí kolem návrhu. Kdyby se jim to povedlo, bylo by to užitečné. Často totiž potřebujete vědět, proč je daná věc navržená zrovna takto, z jakých požadavků rozhodnutí vycházelo, proč to není uděláno jinak a podobně. Bohužel narazili na problém, že struktura popisu odráží strukturu navrhovaného systému, no a když se mění struktura návrhu, musíte měnit i strukturu popisu a je v tom zmatek. Takže je to něco ve stylu průkopníci slepých uliček.

Ale jinak je to kniha hodně dobrá, takže dostává úžasných osm hvězdiček z deseti. No a protože jsem v poslední době okouzlen službami Amazonu, přikládám odkaz na místa, která si čtenáři v knize často zvýrazňují.

1. Pochopte systém – Přečtěte si manuál, zjistěte si jak se to má chovat, jak se mají chovat komponenty a podobně.
2. Nechte to selhat – Pokud chceme odstranit chybu, musíme se ji naučit reprodukovat. Bez toho nemáme moc šanci zjistit co je špatně, a ani to, jestli už jsme to opravili.
3. Přestaňte přemýšlet a začněte se dívat – Člověku se často stane, že uhodne důvod problému a pak už ignoruje všechny náznaky toho, že je chyba jinde. Tato rada nám připomíná, že máme přestat hádat a začít se pořádně koukat.
4. Rozděl a panuj – Klasika, prostě si systém rozdělíme a zkusíme zjistit v které části ta chyba je.
5. Měňte pouze jednu věc – Často se stane, že člověk zkusí udělat jednu opravu, ta nepomůže, tak udělá další a pak ještě další, až problém nakonec možná zmizí. Neúspěšné pokusy o opravu v systému nechá. To je chyba. Pokud oprava nepomohla, vraťte všechno zpět a až pak se pouštějte do dalších pokusů.
6. Držte si kontrolní záznam – Pokud narazíte na problém, je dobré si napsat všechny okolnosti, které se při něm vyskytovali. Pokud je chyba dost zákeřná, bude se vám to hodit při analýze příčin. U software se tento bod dobře mapuje na logování.
7. Zkontroluje zástrčku – Často je chyba v té nejsamozřejmější věci. V autě není benzín, počítač není v zásuvce, aplikace není spuštěna.
8. Získejte čerstvý pohled – Nevíte si s něčím rady? Zkuste se někoho zeptat. Možná vám to docvakne při vysvětlování, možná něco napadne toho druhého. Důležité je, neříkat mu svoje hypotézy, ať ho nezatáhnete do stejné slepé uličky v které už jste vy.
9. Pokus jste to neopravili, není to opraveno – Ano, pokud chyba zmizí sama od sebe, je pravděpodobné, že se znovu objeví. A to pravděpodobně v ten nejnevhodnější okamžik.

V knize jsou samozřejmě jednotlivé rady rozepsány do hloubky, ale největší přínos vidím právě v tom seznamu. Má potenciál člověka odpoutat od zákysu a donutit ho nezkoušet to samé pořád dokola. V knize je také hromada „válečných historek“, ale ty jsou většinou hardwarové. Něco ve stylu: „špatně se nám ukládala data v paměti, tak jsme mysleli, že to je způsobeno šumem na vodiči a ono to přitom bylo špatným signálem časovače. Ha ha ha.“ Pro člověka hardwarem nezasaženého jako jsem já zas tak zajímavé nebylo. I když, historku o tom, jak se někomu odmítalo rozjet auto, podle toho jakou si dal zmrzlinu jsem pochopil i já.

Takže abych to shrnul, kniha byla zajímavá, ale řekl bych, že se bez ní obejdete. Nejužitečnější je určitě ten seznam pravidel.

Celý obsah knihy se dá vyjádřit jediným obrázkem (ukradeno bez svolení autora).

Zobrazuje počet stažení jednotlivých titulů ze serveru Rhapsody. Samozřejmě kniha není jenom o muzice, tvrdí v ní, že podobné rozložení se týká v podstatě všeho. Od kuchyňských mixérů, přes filmy, knihy, webové stránky, hledané termíny v Google až po příchutě piva.

Jak už název napovídá, kniha se zaměřuje hlavně na ten dlouhý ocas, tzn. na tu část grafu, která se nachází vpravo. Proč? Protože tu část vlevo všichni známe, tam jsou úspěšné hity, věci které se dají koupit v obchodě, věci které uvidíte v kině nebo televizi. Ale kromě nich existuje spousta dalších. Dokonce těch věcí, které nejsou takto středněproudé je mnohem, mnohem víc. (Proč graf vypadá tak jak vypadá se můžete dočíst v „V Pavučine Sítí“)

Schválně zkuste hádat. Kolik knih z prvních 100 000 titulů prodávaných na Amazonu se prodá alespoň jednou za čtvrt roku? Troufnete s tipnout? Nebojte, já jsem byl taky úplně mimo. Tak kolik? Prý je to 98%. Jinými slovy, Amazon prodá alespoň jeden výtisk z 98 000 titulů! Odhaduji, že na celém Václaváku mají k dispozici tak čtvrtinu, nemluvě o tom kolik z toho prodají. To je ostatně hlavní ponaučení z toho obrázku. Tam se pohybujeme v pomyslném žebříčku hitů na miliontém místě a přeci nejsme na nule. I tak hluboko se občas něco prodá!

Jiný z pohledů, kterým se na obrázek můžeme dívat je, že budeme ignorovat konkrétní data a budeme se na něj dívat jako na ideální křivku poptávky. Hodně lidí touží po hitech, proto máme tu špičku vlevo. Každý z nás má ale svoje zvláštní choutky, svoji niku (niche), která je pro něj specifická. Tato vlastnost formuje poptávku vpravo.

V dávné době kamenných o fyzického zboží, ale bylo fyzicky nutné omezit nabídku. Náklady na výrobu, skladování, prodej a dopravu zboží jednoduše na grafu nakreslí čáru, za kterou se prostě nevyplatí dané zboží prodávat.

Dnes ale žijeme ve století ovocného netopýra a existuje spousta produktů, která se dá vyprodukovat a prodat skoro zadarmo. Dlouhý ocas se nás tedy dotýká mnohem a mnohem více. V zásadě se spojily tři faktory, které umožňují realitě, aby dostihla tuto ideální křivku poptávky. První z nich je demokratizace výrobních prostředků. Ano dávný Marxův sen je konečně tu. V podstatě každý (na té šťastnější polokouli) má prostředky a dost času produkovat svoji hudbu, filmy, knihy, víno, obrazy... prostě (téměř) cokoliv. Tento faktor protahuje ocas doprava. Pak tu máme demokratizaci distribuce. Jinými slovy internet. Ten umožňuje komukoliv své výtvory distribuovat. Tento faktor dlouhý ocas zesiluje. No a nakonec tu máme propojení poptávky s nabídkou. Je to hlavně Google ale i různá doporučení na internetu od iTunes, přes Amazon až po blogy nebo Facebook. Tento faktor přesouvá lidi od hitů směrem doprava.

Jaké jsou důsledky? Například údajně stále méně lidí kouká na televizi. Proč? Protože mají volbu, můžou koukat na to co chtějí, ne na to co jim někdo vybere. Zeptejte se velkých hráčů zábavního průmyslu jaké to mělo důsledky pro ně. I když vlastně za jejich problémy můžou piráti, já zapomněl.

Samozřejmě jsou tu i pozitivní důsledky. Pokud proti tomuto trendu nebojujete, ale přimete ho za svůj, můžete na něm i vydělat. Protože pokud vás napadne spočítat si plochu toho ocasu, zjistíte, že je skoro stejně velká jako ta část vlevo! Takže pokud se vám ho podaří tuto poptávku nasytit, můžete na ní vydělat stejně nebo i víc než na hitech (ještě se tam projevuje marže, ale do takových detailů zabíhat nebudu). Pokud se vám tedy podaří za podstatě nulových nákladů prodávat velké množství knih, muziky nebo třeba inzerátů, máte na důchod vystaráno.

Tedy pokud jste ve správné části toho kolotoče. V doslovu posledního vydání se totiž dočtete jednu zásadní informaci. Na celé té mašinérii se podílí tři typy hráčů. Spotřebitelé, výrobci a agregátoři (viz. tři faktory výše). Spotřebitelé získávají možnost volby, výrobci si najdou těch svých pár spotřebitelů, ale ti hlavní kdo na tom vydělávají jsou agregátoři. To je ten Google, Apple, Amazon a eBay. Ti nic neprodukují, jenom spojují nabídku s poptávkou. Takže vlastně nic nového.

Ještě si neodpustím povzdechnutí, proč to u nás sakra nefunguje u videa a určité míry i hudby. Proč si nemůžu za rozumný peníz legálně stáhnout z internetu co chci. Proč se těch málo internetových obchodů co tu funguje chová jako kamenný obchod a mají v nabídce hrstku titulů? To se mi nějak nedaří pochopit. Ještě, že alespoň ty pivovary to u nás pochopily.

• The Passionate Programmer: Creating a Remarkable Career in Software Development*
• Beginning Scala
• Debugging
• Rework*
• Prezentace a zen*
• Krajiny vnitřní a vnější
• Židovský policejní klub

Petr Hamerník ještě doporučil V pavučině sítí*. Mezi řečí jsem pochytil doporučení na Krach * a The Long Tail.

Zatím jsem četl ty z hvězdičkou a všechny mohu jen doporučit.

Když už jsme u knih, ještě doporučuji knihkupectví The Book Depository, knihy jsou tam sice dražší než na Amazonu, ale mají dopravu zdarma, takže to ve finále vyjde levněji. Navíc člověk nemusí čekat, až se mu toho nakupí víc.

Kniha má podtitul, který přesně vyjadřuje její obsah: „vytváříme pozoruhodnou kariéru ve vývoji software“. Je prostě o tom, jak dělat práci, která člověka baví a jak v tom být dobrý. Jde o druhé, upravené vydání, první se jmenovalo „My Job Went to India: 52 Ways to Save Your Job“. V druhém vydání se změnil nejenom název, kniha prý byla předělána aby kladla důraz právě na tu „pozoruhodnost“ vaší kariéry.

Jde o takový mix ne příliš navazujících kapitol, které se dívají na práci vývojáře z různých stran. Dočtete se, jak se stát špičkovými programátory, jak o tom dát vědět nadřízeným, jak se neustále zlepšovat, jak si vybrat zaměření a jak se stát slavným. Krása, škoda že už slavný jsem.

Ani moc nevím co bych víc napsal, je potřeba si tu knížku přečíst. Pokud obsah knihy shrnu, tak bychom si měli správně vybrat obor, stát se v něm nejlepší, dát to všem vědět a zajímavá kariéra nás nemine. Zní to sice samozřejmě, ale snadné to není. V knížce se právě dočtete dost triků a tipů jak toho všeho dosáhnout. Doporučuji.

Pokud se chcete dozvědět co to vlastně ten REST je, tak je to ta pravá kniha pro vás. Dozvíte se tam hodně o filozofii RESTu, o jeho výhodách, o tom jak takové služby navrhovat a jaké technologie k tomu používat. Většina příkladů je sice napsána v jakémsi obskurním jazyce jménem Ruby, ale pochopí je i Javista.

Kniha je napsána i docela čtivě, musíte jenom překousnout demagogii typu „REST je nejlepší, RPC je k ničemu“. Co se mi hodně líbilo je to, že jsem snad konečně pochopil principy RESTu. Je to totiž jedna z těch technologií, o kterých všichni mluví, ale málokdo ji plně rozumí. Pokusím se tu shrnout to nejdůležitější.

Dělej to jako Web

To je asi hlavní krédo RESTovaných aplikací. Web funguje, je snadno použitelný, dobře škáluje, tak proč bychom nemohli dělat webové služby úplně stejně. Je tu veliký rozdíl v tom, že normální web je určen pro lidi a webové služby pro stroje. Ale proč nepoužít stejných osvědčených principů?

Zdrojově orientované

Zdrojově orientované je můj geniální překlad pro Resource-Oriented. Znamená to, že se místo na služby, orientujeme na zdroje. Místo na slovesa typu udělej, založ, smaž se soustředíme na podstatná jména typu účet, zákazník a podobně. Je to podobné jako objektové programování, v něm bychom se měli soustředit hlavně na objekty samotné, jejich operace by z nich měli vyplývat. Stejné princip by měl platit u RESTu. Tady musím dát příznivcům RESTu za pravdu, normální WS jsou silně funkcionální, o objektech tam není ani památky. Na druhou stranu je spousta služeb, které se jako RESTové jenom tváří, ale v podstatě jsou také jen RPC.

Adresovatelnost

Další důležitý princip je adresovatelnost. Každá věc která je v daném systému důležitá, by měla mít vlastní adresu. To znamená, že každá instance objektu, by měla mít vlastní URI. Hodně to souvisí s orientací na zdroje. Každý zdroj, má svoji adresu, například takovouto http://www.exaple.com/v1/bank/client/12345. Pokud použijeme přirovnání k objektům, tak URI je podobná referenci.

Propojenost (Connectedness)

Propojenost hodně souvisí s předchozími body. Znamená to, že jako výsledek operací dostávám odkazy na další zdroje. Pokud se například zeptám na seznam klientů banky, měl bych dostat seznam jejich URI a ne jen jejich ID. Pokud bereme URI jako referenci na instanci, tak to dává smysl.

Idempotentnost

Krásné české slovo označující, to, že by mělo být možné zavolat jednu službu vícekrát, aniž by hrozilo něco ošklivého. To znamená, že operace by pokud možno neměly mít žádné vedlejší účinky. Pokud mění stav systému, měly by to dělat tak, aby se nic nestalo, pokud ho změní vícekrát. Je překvapivé, že takových operací je valná většina. Nic se nestane, pokud například vícekrát nastavím stejnou hodnotu nebo něco smažu. Jsou tu samozřejmě výjimky, ale i u těch se dá idempotentnost zařídit.

Bezstavovost

Bezstavovost je často nepochopené téma. A není se čemu divit, je to hodně matoucí. Pokusím se to ale vysvětlit. Bezstavovostí se v tomto případě myslí, že webová služba neukládá stav klienta. Rozhodně tam není žádná session. Klient může navíc volat operace v libovolném pořadí, takže by se nemělo objevovat žádné flow jak ho známe z normálního webu. Ale aplikace samotná samozřejmě stav má. Takže si samosebou pamatuje, kolik kdo má na účtu, kam chce letět na dovolenou nebo kam rád chodí do restaurace. Ale nejedná se o stav klientské aplikace, jedná se o stav zdrojů. V tom je veliký rozdíl.

Bezstavovost je docela rozumný princip, díky ní se například dobře škáluje. Bohužel často k jejímu dodržení musíme švindlovat. Občas prostě potřebujeme držet stav klientské aplikace. V RESTu proto dělají krok stranou a prohlásí stav klienta za stav systému. Takže když potřebují uložit obsah nákupního košíku, řeknou, že to není stav klienta, ale stav aplikace. Nákupní košík je vlastně takový zdroj, jehož stav aplikace naprosto přirozeně drží. Takový košík má pak svoji URI, své operace a je to prostě normální zdroj. Problém vyřešen. Tedy kromě té škálovatelnosti, s ní jsem na tom úplně stejně jako kdybych používal session. (Kvízová otázka. Jak zajistit, aby přidání položky do nákupního košíku bylo idempotentní?)

No zbytek z těch asi 400 stránek tu opisovat nebudu. Radši napíšu proč se budu držet dál normálních (tlustých) webových služeb.

V první řadě se mi nelíbí úzká vazba na HTTP. To je jedna z věcí, která mi ještě nedošla, takže budu rád když mi ji někdo vysvětlí. Na jedné straně čtu, že REST je na HTTP úplně nezávislý. Na druhé straně, je ale REST s HTTP neuvěřitelně úzce spjat. Chcete-li změnit stav zdroje, máte použít HTTP PUT, chcete-li ho smazat, použije HTTP DELETE, chcete zjistit jeho stav, použijte GET. Nastane chyba? Dostanete ten a ten HTTP chybový kód. Tak je to závislé nebo ne? Mě spíš připadá že jo.

Dalším důvodem, proč zatím zůstanu u klasického ošklivého SOAPu je to, že mi vyhovuje. Já prostě nepíši aplikace, které jsou podobné webovým stránkám. Píši věci, které jsou svoji podstatou spíše procedurální než objektové. Navíc mi vyhovuje to, že existuje něco jako WSDL, které je sice ošklivé jak noc, ale které i přes své mouchy funguje. Ano pro REST máme WADL, ale že by byl široce rozšířen se říci nedá.

Také mi vyhovuje, že v SOAPu jsou metadata součástí zprávy a ne protokolu, kterým se zpráva posílá. Prostě mi to připadá bezpečnější. Když volám webovou službu tak volání bohužel často přejde přes několik JMS front a pár HTTP připojení. Takže se na to radši dívám tak, že posílám XML dokument, který přes nějaké složitosti snad doputuje k svému adresátu.

Tím rozhodně nechci říci, že je REST špatný. Pokud bych vystavoval webové služby pro něco, co má svůj ekvivalent ve webové aplikaci, asi bych nad RESTem vážně uvažoval. Protože se ale pohybuji v jiném světě, tak je moje volba jiná. To mi ale nebrání se poučit a pár fint od RESTu okoukat.

Mítinky jsou boje o moc mezi lidmi, kteří něco chtějí, a těmi, kteří jim to nechtějí dát.

Pravidelnější čtenáři tohoto nepravidelného blogu už jistě tuší, že je čeká další minirecenze. Tentokrát se jedná o knihu „Managing humans“ (na ten odkaz rozhodně klikněte) od Michaela Loopa (Jírovy patří dík za tip). Kniha je to stylem podobná Joel on Software a musím přiznat, že se mi líbila skoro stejně. Je sice o hodně méně technická, ale zato mnohem víc o lidech.

Dal bych ji za povinnou literaturu lidem, kteří se snaží vést (nebo nedejbože řídit) bandu nerdů. Ale je hodně zajímavá i pro nás nerdy samotné. Hodně užitečná je i pro lidi, kteří pracují v korporaci.

Takže co se v knize dočtete? Hodně mě zaujala kapitola o tom, jak uhodnout, co se děje na pracovní schůzce. Znáte to, sedíte na mítinku a přemýšlíte co tam sakra děláte, co a proč se ti lidé snaží říci. V kapitolách „Agenda detection“ a „Meeting creatures“ se to dočtete.

Zajímavé jsou i části, které popisují jak se připravit na pohovor, napsat životopis a podobně. To jsem měl sakra vědět před pár měsíci.

No a neméně zajímavé jsou i kapitoly o nerdech samotných. Například NADD. Ale třeba "Přiručka k nerdovi" se do knihy nedostala.

Jak jste si všimli, většina kapitol je volně ke čtení i na autorově blogu, ale mě se kniha čte mnohem lépe. Jenom si dovoluji upozornit, že je to psané pokročilejší angličtinou, takže se docela procvičíte. Například na straně 188 mě dostalo sloveso „to grok“, ale jelikož jsem nerd tak jsem to pochopil i bez slovníku. I když jak tak koukám, tak se to dostalo i do slovníků, zajímavé. Ale zpátky ke knize, ta zaslouženě dostává neuvěřitelných deset hvězdiček z deseti.

No a abych vás neochudil o tradiční ukázku z knihy, uvedu pár položek z vysvětlivek na konci knihy:

Agenda – Seznam věcí, které se musí na dané schůzce odehrát aby byla kompletní. Pokud všichni účastníci na dané schůzce nejsou seznámeni s agendou, bude docházet ke ztrátě času.

Spolupráce – Slovo používané k tomu, aby vás přesvědčili pracovat s lidmi, kterým byste se raději vyhnuli.

Milník (Milestone) – Chabě nadefinované, přehnaně vytrubované datum, které je částí softwarového vývoje. Vývojový tým při něm přemýšlí o tom jak je v pytli.

Proces – Šestipísmenné slovo začínající na P. Proces není špatná věc. Obzvlášť ve velkých organizacích kde ohromné množství lidí ztrácí velké množství času děláním té samé věci.

Specka (Specifikace) – Dokument, který říká jak to je. Proces psaní specifikace bývá víc užitečný než výsledný dokument.

Na začátku je tam na můj vkus docela dost filozofování, ale možná to ke knize podobného zaměření patří. Zabývá se totiž pohledem na návrh API v Javě z trochu vyššího hlediska. To znamená, že se nebabrá v detailech, jako například správné pojmenování metod a rozdělení balíků. Kouká se na to víc shora. Tzn, jak dělat API tak, aby přežilo alespoň pár verzí. Dočtete se co dělat a co nedělat, na co si dát pozor. Autor se prostě pokusil o nemožné, zaznamenat na papír a předat své dlouholeté zkušenosti z návrhu NetBeans API.

Kromě toho je tam také hodně zajímavých myšlenek, které vás donutí se zamyslet. Třeba tvrzení, že krása kódu je věc sice pěkná, ale v podstatě neužitečná. Zní to jako samozřejmost, ale poprvé jsem to takhle natvrdo napsané uviděl až v této knize.

Nejvíc mě zaujala strana 173, která se zabývá tím, co o metodě řeknou její modifikátory. Tzn. věci jako public, final, abstract a podobně. To je věc, která mi do té doby nedošla. Pokud totiž chceme aby měla metoda jeden jediný účel, připadají v úvahu jedině následující kombinace:

• public final – Metoda je tu k tomu aby ji někdo volal
• protected abstract – metoda je to k tomu, aby ji někdo zastínil (naimplementoval)
• protected final – metoda má být volaná podtřídami

Všechny ostatní kombinace, které obsahují public nebo protected mají víc významů, takže by se jim člověk měl vyhýbat. Například public se dá jak volat tak zastínit, takže není moc jasné, co je její správné použití. Jen pro úplnost upozorňuji, že private a (package) nás u API nezajímá.

A tady s dostáváme k věci, na kterou je třeba u knihy upozornit. Psal ji člověk, který se dlouhá léta zabývá návrhem API pro jiné programátory a to navíc pro Javu na desktopu a to ještě navíc v dynamickém prostředí, kde se moduly za běhu magicky načítají do paměti a zase se z ní vyhazují. Jeho styl myšlení a případy užití jsou tedy o hodně jiné než u mě. Já jsem zvyklý na serverovou Javu, která je zatím dost statická a navíc moji spotřebitelé jsou hlavně koncoví zákazníci. (více viz. v sesterském článku). Nejenže řeším úplně jiné problémy, některé rady jsou pro mě dokonce chybné!

Například stránka 221, kde autor řeší vzájemnou závislost listeneru a sledovaného objektu. Objekt v tomto případě drží odkazy na listenery a když se s ním něco stane, dá jim vědět. Autor tvrdí, že by objekt měl na své listenery odkazovat jen slabou (weak) referencí. Tak mohou být listenery uvolněny z paměti, když už nejsou potřeba, ale objekt samotný žije dál.

V případě NetBeans je to asi užitečná rada. K čemu držet v paměti listener, který sleduje změny v editačním okně, když leží v modulu, na který už se nikdo neodkazuje a tedy ho ani nepotřebuje. Tím, že editační okno drží na listener odkaz, znemožňuje odstranění celého modulu z paměti.

Když se ale na danou radu člověk podívá z mé serverové perspektivy, tak je to naprosto zvrhlé. Mám často listener, který na startu aplikace zaregistruji a pak už mě nezajímá. On dělá něco užitečného, může být třeba součástí složitého auditovacího modulu. Často je ten listener jediným pojítkem mezi daným modulem a zbytkem aplikace. Rozhodně nechci aby mi auditovací modul přestal fungovat, jen proto, že garbage collector uvolní listener z paměti. Tady vidíme, že rada která je naprosto legitmní pro NetBeans nemusí být platná pro server. Na to je potřeba dát pozor.

To je jen jeden aspekt. Navíc jsem přesvědčen, že „obyčejní“ programátoři jako já moc API nepíší. Původně jsem to chtěl na tomto místě víc rozebrat, ale věnuji tomu speciální článek.

Takže podle mého názoru je kniha hodně užitečná buď pro lidi, kteří opravdu píší knihovny, což není můj případ, nebo pro lidi kteří se rádi zamýšlí nad tím jak dělat software, což můj případ je. Je na vás, abyste se rozhodli, jestli do těchto skupin patříte. Pokud ano, rozhodně si ji nenechte ujít. Pokud ne, radši si znovu přečtěte Java Efektivně.