podtitul: tvorba aplikačního software na bázi multiagentových systémů
Kniha má cca 240 obsahových stránek, je brožovaná (a ta moje už má i oslí uši) a vyšla v roce 2004. Kniha o agentových technologiích v češtině od českého autora se jen tak nevidí. Autor se snaží v knize zmapovat celé rozsáhlé téma agentového přístupu k návrhu software.
Na začátku knihy autor popisuje základní abstraktní architektury agentů. Poté se věnuje učení, komunikaci a přesunu agentů mezi architekturami. V poslední kapitole se autor pak věnuje existujícím agentovým prostředím a jazykům pro modelování agentů. Knize bych možná trochu vyčinil příliš široký záběr, který neumožňuje danou problematiku úplně popsat. Kniha se tak stává spíše přehledem a rozcestím na další zdroje. V knize mi přijde problematické přílišné spoléhání na matematický formalismus (v místech kde se dále nevyužívá a možná i čtenáře mate) a pak zabíhání do přílišných podrobností (hlavně v příkladech). V celé knize je použito několik jazyků (přičemž dle mého názoru by stačil pseudokód). Našel jsem jedno místo, kde bylo vynechané slovo, jinak je text s pravopisné a typografické strany v pořádku.
Domnívám se, že u zdůvodnění účinnosti Hayekova stroje (jehož návrh je imho inspirován hlavně vírou v trh) se neporovnávají různé algoritmy korektně. (opomíjí se vliv počtu barev na složitost problému). Srovnání využívá efektivitu při řešení problému jak zkopírovat sekvenci barev kostek postavených v jednom ze 3. sloupců do dalšího sloupce. Přičemž lze manipulovat pouze s kostkami navrchu sloupců. Také velmi podrobné líčení různých technologických aspektů mě nepřišlo šťastné. Pouze podle knihy bych agentový systém nebyl schopen implementovat.
Naopak co na knize oceňuji je kapitola o učení (bohužel se sem nevešli všechny učící algoritmy) a speciálně část o učení reaktivních agentů. Také je trošku možné, že jsem příliš přísný neboť jsem již četl pojednání o agentech o Wooldridge. Rozhodně jsem rád že podobná kniha vznikla a čtenáři neobeznámenému s technologií agentů může poskytnout základní vhled.
Hodnocení 5/10
PS: Sám mám určité vnitřní pochybnosti, zda termín agent přináší něco nového (spíš se domnívám, že jde jen o podobný hype jako dřív byli expertní systémy nebo neuronové sítě). Rád se v diskuzi nechám vyvést z omylu ;)
Zobrazují se příspěvky se štítkemknihy. Zobrazit všechny příspěvky
Zobrazují se příspěvky se štítkemknihy. Zobrazit všechny příspěvky
středa 15. dubna 2009
středa 4. března 2009
Helmut Herold: Awk&Sed
Podtitul: Příručka pro dávkové zpracování textu
Tato kniha z nakladatelství Addison-Wesley (překlad Computer Press) popisuje dva úlohově orientované jazyky z prostředí UNIX. Na cca 170 stranách je rozepsán programovací jazyk awk a na 64 stranách proudový editor sed. Kniha je brožovaná a obsahuje tak na půl vysvětlující text a na půl příklady. Po učebnicovém vysvětlení základní syntaxe se autor dostává i ke komplikovanějším příkladům. Např. realizaci relačního operátoru JOIN, řešení problému umístění 8mi dam na šachovnici nebo výpisu síťových plánů. V některých příkladech se pak začínají projevovat omezení programovacího jazyka. V knize jsem nenašel využití na zpracování češtiny a jak se sed a awk vyrovná s českým textem. (dle mých pokusů ne moc dobře)
Kniha je přeložena z německé verze, neboť na pár místech překladatel zapomněl názvy přeložit (ausdruck, freiplat). Co je více zarážející je množství překlepů, možná by se měl někdo v nakladatelství naučit používat kontrolu pravopisu (přeci jen to není až tak moderní funkce). V knize jsem nenarazil na logické nesmysly a text knihy je dobře čitelný. Překládat zdrojový kód do češtiny mě zavání nevkusem (v němčině by to však nebylo lepší - řídící konstrukce jsou v angličtině, klíčová slova v angličtině, proč by tedy funkce, komentáře a názvy proměnných měli být v češtině?). V některých příkladech je rozhozené odsazení a zvýraznění klíčových slov ve zdrojovém kódu bych už dnes považoval za standard (avšak tady chybí).
Přesto knihu mohu doporučit, protože poskytuje zajímavý náhled do dvou základních UNIXových nástrojů. A pro ty co nepracují s UNIXem poskytuje ukázku dvou řešení specifických problémů práce s textem. Hlavně bych chtěl vyzdvihnout pěkně zvolené příklady, které jsou občas propojeny zdrojovým kódem BASHe. Domnívám se, že právě pěkně zvolené příklady z praxe jsou na této knize nejpěknější.
Hodnocení 7/10
Tato kniha z nakladatelství Addison-Wesley (překlad Computer Press) popisuje dva úlohově orientované jazyky z prostředí UNIX. Na cca 170 stranách je rozepsán programovací jazyk awk a na 64 stranách proudový editor sed. Kniha je brožovaná a obsahuje tak na půl vysvětlující text a na půl příklady. Po učebnicovém vysvětlení základní syntaxe se autor dostává i ke komplikovanějším příkladům. Např. realizaci relačního operátoru JOIN, řešení problému umístění 8mi dam na šachovnici nebo výpisu síťových plánů. V některých příkladech se pak začínají projevovat omezení programovacího jazyka. V knize jsem nenašel využití na zpracování češtiny a jak se sed a awk vyrovná s českým textem. (dle mých pokusů ne moc dobře)
Kniha je přeložena z německé verze, neboť na pár místech překladatel zapomněl názvy přeložit (ausdruck, freiplat). Co je více zarážející je množství překlepů, možná by se měl někdo v nakladatelství naučit používat kontrolu pravopisu (přeci jen to není až tak moderní funkce). V knize jsem nenarazil na logické nesmysly a text knihy je dobře čitelný. Překládat zdrojový kód do češtiny mě zavání nevkusem (v němčině by to však nebylo lepší - řídící konstrukce jsou v angličtině, klíčová slova v angličtině, proč by tedy funkce, komentáře a názvy proměnných měli být v češtině?). V některých příkladech je rozhozené odsazení a zvýraznění klíčových slov ve zdrojovém kódu bych už dnes považoval za standard (avšak tady chybí).
Přesto knihu mohu doporučit, protože poskytuje zajímavý náhled do dvou základních UNIXových nástrojů. A pro ty co nepracují s UNIXem poskytuje ukázku dvou řešení specifických problémů práce s textem. Hlavně bych chtěl vyzdvihnout pěkně zvolené příklady, které jsou občas propojeny zdrojovým kódem BASHe. Domnívám se, že právě pěkně zvolené příklady z praxe jsou na této knize nejpěknější.
Hodnocení 7/10
Umění programování v Unixu - Kapitola 1
Technická polemika - Po zhodnocení formální stránky knihy, bych se rád dostal k zajímavým myšlenkám v knize obsaženým.
Úvodní kapitola se zabývá historií UNIXu jeho postavením mezi ostatními operačními systémy. Snaží se ukázat, že UNIX jako technologie i filozofie musela přijmout spoustu změn a překonat změny trendů. Přechod z prostředí mainframe na osobní počítače, dále do distribuovaného prostředí internetu a nakonec i překonat změnu související se zavedením GUI. Kniha se snaží popsat základní trendy, které si UNIX zachovává a v podstatě dochází k tomu, že je to svoboda práce se zdrojovým kódem systému i programů a dobrý inženýrský návrh, postavený na spoustě malých spolupracujících programů. IMHO: Pravidla uvedená v této kapitole se hodí k návrhu libovolného software a lze je označit za pravidla dobrého návrhu aplikace. Pravidla jsem trošku přeformuloval a mnohdy doplnil svým pohledem, takže se nejedná o překlad knihy, jde spíš rozvití myšlenek v knize obsažených.
Ke konci kapitoly je je uveden krátký popis jiných systémů a v čem se liší. Přijde mi, že tento popis je trošku zaujatý a nejde moc do hloubky, ale nejsem odborníkem na operační systémy.
Pravidla psaní software
Držte se jednoduchých, propojitelných rozhraní – Zde jsou myšlena hlavně rozhraní textová, popř. založená na XML. Rozhraní je to co určuje zda program bude použitelný ve větším kontextu nebo zůstane zastrčený v šuplíku. Složité rozhraní znesnadňuje použití programu v kontextu ostatních programů.
Srozumitelnost je důležitější než efektivita – Prostě jen přeformulované tvrzení D.Knutha: “Předčasná optimalizace je kořenem všeho zla.”. Složitý algoritmus obsahuje více místa pro chyby a hůře se opravuje i rozšiřuje. Zdrojový kód by měl být opatřen komentáři. V knize lze dokonce potkat i myšlenku literárního programování a to v té podobě, že každý algoritmus by měl být snadno vysvětlitelný pomocí přirozeného jazyka a podobným způsobem i zapsán ve zdrojovém kódu.
Navrhuje programy propojitelné s jinými programy – V duchu zásady program má dělat jednu věc dobře a nesnažit se řešit vše. Dokládané je to na možnosti zvolit si editor, který jiné programy budou používat pro vstup a editaci textu. Jiným příkladem je realizace stránkování výpisu na obrazovku, přes příkazy more, less.
Navrhujte jednoduché programy, složité piště jen v případě nutnosti – Zde se lze odkázat na knihu Steve McConell: Odhadování softwarových projektů, kde se dozvíte, že s velikostí programu roste pravděpodobnost překročení rozpočtu i toho, že se program nepodaří dokončit. Přičemž náročnost vývoje s velikostí programu roste kvadraticky! (protože tímto způsobem roste počet možných vazeb v programu)
Navrhujte transparentní programy – Tedy programy, ze kterých lze na základě vstupu snadno zkontrolovat výstup a ověřit, že program plní to co má.
Pravidlo robustnosti – Program se musí vypořádat i s krajními případy a vyprodukovat smysluplný výstup. Při propojení s jinými programy se na vstupu může objevit skoro cokoliv. V podstatě se jedná o defenzivní programování.
Volte deklarativní zápisy ne procedurální – Zápis gramatiky v BNF je daleko snazší než její zápis v syntaktickém analyzátoru. Stejně tak je tabulka jednodušší reprezentací, než složitý příkaz switch nebo mnoho konstrukcí if, else.
Pravidlo nejmenšího překvapení – Rozhraní by uživatele nemělo překvapovat. Snaha dodržovat běžnou kulturu zápisů – způsob značení komentářů, zápisu programu, … Rozhodně se však vyvarujte označování rozdílných věcí stejným způsobem. Příkaz return, který by místo ukončení funkce ukončil program, je takovým příkladem.
Mluvte jen když je třeba – Program má mluvit, jen když je potřeba sdělit něco důležitého. Ukecané programy nikdo neposlouchá. Pokud je však třeba upozornit na chybu, tak nejlépe hlasitě a co nejdříve! Informace o chybě by měla být dostatečně konkrétní. Je velký rozdíl mezi hláškou “Hups chyba!” a “Chyba soubor config.ini: Na řádku 35, je uveden neexistující uživatel pepa3”.
Programátorův čas je dražší než čas CPU – Za 2 roky poběží vaše programy 2x rychleji. A to bez námahy. V podstatě zas odkaz na předčasnou optimalizaci. Optimalizace se totiž řeší až naposled, kdy je jasné jaké části (cca 20% programu) zpomalení způsobují. 80% programu nemá smysl optimalizovat, dokonce to škodí přehlednosti, rozšiřitelnosti a poštu chyb v programu. Pokud program běží dost rychle i tak, lze si ušetřit i optimalizaci těch 20% ;).
Pravidlo generování – Počet chyb na řádku je v podstatě nezávislý na jazyce, snažte se tedy psát úsporně a manuální úkony (jako generování kódu) nechat na počítači. Věřte, že je spolehlivější. Pozn. Výstup generátorů pokud možno neupravujeme! (to bychom se o výhodu malého počtu řádek připravili)
Optimalizace až na konec – už bylo řečeno, ale je potřeba opakovat do zblbnutí ;)
Není jen jeden správný způsob – Snažte se vymyslet různá řešení a vyberte nejlepší ne to první. Nespadněte do pasti prvního návrhu. Nebojte se vymyslet spoustu návrhů a ty ohodnotit.
Navrhujte pro budoucnost – Nechte si otevřená vrátka pro budoucí rozšíření (datových formátů a struktur, protokolů i funkcí). Zde se třeba poznamenat, že váš program se může hodně rozšířit a pak už se zpětně nekompatibilní změny neprovádí bezbolestně.
Úvodní kapitola se zabývá historií UNIXu jeho postavením mezi ostatními operačními systémy. Snaží se ukázat, že UNIX jako technologie i filozofie musela přijmout spoustu změn a překonat změny trendů. Přechod z prostředí mainframe na osobní počítače, dále do distribuovaného prostředí internetu a nakonec i překonat změnu související se zavedením GUI. Kniha se snaží popsat základní trendy, které si UNIX zachovává a v podstatě dochází k tomu, že je to svoboda práce se zdrojovým kódem systému i programů a dobrý inženýrský návrh, postavený na spoustě malých spolupracujících programů. IMHO: Pravidla uvedená v této kapitole se hodí k návrhu libovolného software a lze je označit za pravidla dobrého návrhu aplikace. Pravidla jsem trošku přeformuloval a mnohdy doplnil svým pohledem, takže se nejedná o překlad knihy, jde spíš rozvití myšlenek v knize obsažených.
Ke konci kapitoly je je uveden krátký popis jiných systémů a v čem se liší. Přijde mi, že tento popis je trošku zaujatý a nejde moc do hloubky, ale nejsem odborníkem na operační systémy.
Pravidla psaní software
Držte se jednoduchých, propojitelných rozhraní – Zde jsou myšlena hlavně rozhraní textová, popř. založená na XML. Rozhraní je to co určuje zda program bude použitelný ve větším kontextu nebo zůstane zastrčený v šuplíku. Složité rozhraní znesnadňuje použití programu v kontextu ostatních programů.
Srozumitelnost je důležitější než efektivita – Prostě jen přeformulované tvrzení D.Knutha: “Předčasná optimalizace je kořenem všeho zla.”. Složitý algoritmus obsahuje více místa pro chyby a hůře se opravuje i rozšiřuje. Zdrojový kód by měl být opatřen komentáři. V knize lze dokonce potkat i myšlenku literárního programování a to v té podobě, že každý algoritmus by měl být snadno vysvětlitelný pomocí přirozeného jazyka a podobným způsobem i zapsán ve zdrojovém kódu.
Navrhuje programy propojitelné s jinými programy – V duchu zásady program má dělat jednu věc dobře a nesnažit se řešit vše. Dokládané je to na možnosti zvolit si editor, který jiné programy budou používat pro vstup a editaci textu. Jiným příkladem je realizace stránkování výpisu na obrazovku, přes příkazy more, less.
Navrhujte jednoduché programy, složité piště jen v případě nutnosti – Zde se lze odkázat na knihu Steve McConell: Odhadování softwarových projektů, kde se dozvíte, že s velikostí programu roste pravděpodobnost překročení rozpočtu i toho, že se program nepodaří dokončit. Přičemž náročnost vývoje s velikostí programu roste kvadraticky! (protože tímto způsobem roste počet možných vazeb v programu)
Navrhujte transparentní programy – Tedy programy, ze kterých lze na základě vstupu snadno zkontrolovat výstup a ověřit, že program plní to co má.
Pravidlo robustnosti – Program se musí vypořádat i s krajními případy a vyprodukovat smysluplný výstup. Při propojení s jinými programy se na vstupu může objevit skoro cokoliv. V podstatě se jedná o defenzivní programování.
Volte deklarativní zápisy ne procedurální – Zápis gramatiky v BNF je daleko snazší než její zápis v syntaktickém analyzátoru. Stejně tak je tabulka jednodušší reprezentací, než složitý příkaz switch nebo mnoho konstrukcí if, else.
Pravidlo nejmenšího překvapení – Rozhraní by uživatele nemělo překvapovat. Snaha dodržovat běžnou kulturu zápisů – způsob značení komentářů, zápisu programu, … Rozhodně se však vyvarujte označování rozdílných věcí stejným způsobem. Příkaz return, který by místo ukončení funkce ukončil program, je takovým příkladem.
Mluvte jen když je třeba – Program má mluvit, jen když je potřeba sdělit něco důležitého. Ukecané programy nikdo neposlouchá. Pokud je však třeba upozornit na chybu, tak nejlépe hlasitě a co nejdříve! Informace o chybě by měla být dostatečně konkrétní. Je velký rozdíl mezi hláškou “Hups chyba!” a “Chyba soubor config.ini: Na řádku 35, je uveden neexistující uživatel pepa3”.
Programátorův čas je dražší než čas CPU – Za 2 roky poběží vaše programy 2x rychleji. A to bez námahy. V podstatě zas odkaz na předčasnou optimalizaci. Optimalizace se totiž řeší až naposled, kdy je jasné jaké části (cca 20% programu) zpomalení způsobují. 80% programu nemá smysl optimalizovat, dokonce to škodí přehlednosti, rozšiřitelnosti a poštu chyb v programu. Pokud program běží dost rychle i tak, lze si ušetřit i optimalizaci těch 20% ;).
Pravidlo generování – Počet chyb na řádku je v podstatě nezávislý na jazyce, snažte se tedy psát úsporně a manuální úkony (jako generování kódu) nechat na počítači. Věřte, že je spolehlivější. Pozn. Výstup generátorů pokud možno neupravujeme! (to bychom se o výhodu malého počtu řádek připravili)
Optimalizace až na konec – už bylo řečeno, ale je potřeba opakovat do zblbnutí ;)
Není jen jeden správný způsob – Snažte se vymyslet různá řešení a vyberte nejlepší ne to první. Nespadněte do pasti prvního návrhu. Nebojte se vymyslet spoustu návrhů a ty ohodnotit.
Navrhujte pro budoucnost – Nechte si otevřená vrátka pro budoucí rozšíření (datových formátů a struktur, protokolů i funkcí). Zde se třeba poznamenat, že váš program se může hodně rozšířit a pak už se zpětně nekompatibilní změny neprovádí bezbolestně.
pátek 13. února 2009
Eric S. Raymond: Umění programování v Unixu
Tak jsem se zas dostal k nějakému čtení a přečetl si knížku Umění programování v Unixu od Eric S. Raymond(a). V originále se kniha jmenuje The art of UNIX Programming a lze si ji stáhnout z internetu. Knížku u nás vydalo nakladatelství Computer press. Kniha je brožovaná a má cca 480 dobře vysázených stránek.
Obsah
V knize se pojednává o filozofii operačního sytému UNIX, kterou zdědily i operační systémy Linux, FreeBSD a další. Přístup k tvorbě a implementaci programů pod linuxem je podrobně vysvětlen. Kniha určitě stojí za přečtení, protože obsahuje spoustu myšlenek, se kterými můžete nebo nemusíte souhlasit, ale určitě Vás přimějí uvažovat o tom jak navrhovat software a jaké mají jednotlivé návrhy výhody a nevýhody. Nečekávejte, že v knize najdete sebereflexi UNIXové filozofie, kniha se spíše snaží být obhajobou. Za nejcennější části knihy pokládám rozbor jednotlivých unixových programů a ilustrování myšlenek z knihy na existujících implementacích. Knihu z tohoto důvodu doporučuji přečíst, nejlépe v originále.
Překlad
Bohužel co mě na knize zarazilo je kvalita překladu. Kniha je psána dost náročně od programátora pro programátory a člověk, který knihu překládal, rozhodně UNIXový programátor nebyl a korektura zaspala a nestihla si to před puštěním knihy do oběhu uvědomit. Překladatel se jal knihu překládat doslova, takže některé věty v češtině znějí zvláštně a marně přemýšlíte, jak technický termín zní v originále. Uvádět u prvního výskytu překladu originální termín nebo na konec zařadit tabulku překladu termínů nikoho nenapadlo. *Českému překladu této knihy se proto vyhněte!*.
Příklady překladu
Pro ilustraci překladu dodávám mnohdy humorné příklady. Příklady řadím od největších absurdit po menší. První je vždy uvedeno znění v originále, následuje originální překlad.
Obsah
V knize se pojednává o filozofii operačního sytému UNIX, kterou zdědily i operační systémy Linux, FreeBSD a další. Přístup k tvorbě a implementaci programů pod linuxem je podrobně vysvětlen. Kniha určitě stojí za přečtení, protože obsahuje spoustu myšlenek, se kterými můžete nebo nemusíte souhlasit, ale určitě Vás přimějí uvažovat o tom jak navrhovat software a jaké mají jednotlivé návrhy výhody a nevýhody. Nečekávejte, že v knize najdete sebereflexi UNIXové filozofie, kniha se spíše snaží být obhajobou. Za nejcennější části knihy pokládám rozbor jednotlivých unixových programů a ilustrování myšlenek z knihy na existujících implementacích. Knihu z tohoto důvodu doporučuji přečíst, nejlépe v originále.
Překlad
Bohužel co mě na knize zarazilo je kvalita překladu. Kniha je psána dost náročně od programátora pro programátory a člověk, který knihu překládal, rozhodně UNIXový programátor nebyl a korektura zaspala a nestihla si to před puštěním knihy do oběhu uvědomit. Překladatel se jal knihu překládat doslova, takže některé věty v češtině znějí zvláštně a marně přemýšlíte, jak technický termín zní v originále. Uvádět u prvního výskytu překladu originální termín nebo na konec zařadit tabulku překladu termínů nikoho nenapadlo. *Českému překladu této knihy se proto vyhněte!*.
Příklady překladu
Pro ilustraci překladu dodávám mnohdy humorné příklady. Příklady řadím od největších absurdit po menší. První je vždy uvedeno znění v originále, následuje originální překlad.
Perl is shell on steroids.
Jazyk Perl je příkazovým prostředím steroidů.
notably first-person shooters
především první střelci
Perhaps root is too powerful
Kořen systému je možná příliš vlivný
It economizes the far more valuable resource that is human time, by making it…
Tento formát totiž zachází šetrně s mnohem hodnotnějšími prostředky, než je lidský čas.
so sporadic dropouts are tolerable, but lag is fatal.
když se jeden z příkazů ztratí velká potíž nevznikne. Kdyby však hra běžela pomalu, byl by to velký problém.
Its devotees speak an argot that is dense and forbidding even by computer-science standards,...
Nadšenci hovoří v hantýrce, která je poměrně neproniknutelná a odpuzuje dokonce i standardy počítačových věd.
Emacs Lisp is a Lisp. It follows as the night the day that it manages memory automatically and…
Jazyk Emacs Lisp je jazykem Lisp. Stejně jako po dni následuje noc, zajišťuje jazyk Lisp automatickou správu paměti.
Though small programs in Perl can be extremely powerful, careful discipline is required to maintain modularity and keep a design under control as program size increases.
Přestože mohou být malé programy v jazyce Perl velmi výkonné, je třída pro zachování modularity a udržení návrhu pod kontrolou dodržovat velmi důsledně disciplínu.
and, in fact, be separated by an Internet connection spanning half the globe
mohou být ve skutečnosti spuštěny na různých polokoulích naši Země
This is called ‘System V IPC’—or, among old timers, ‘Indian Hill’ IPC after the AT&T facility where it was first written.
Tomuto modelu se se říká meziprocesorová komunikace Systému V (System V IPC) nebo “indiánský kopec” (“Indian Hill” IPC) – podle první funkce tohoto typu firmy AT&T.
Gabriel porovnává filozofii Massachusettského technického institutu, která nejvíce cení jednoduchostí v rozhraní, s filozofií institutu v New Jersey, která nejvíce oceňuje jednoduchost v rozhraní. (správně v implementaci)
By contrast, vi looks rather bloated and flabby.
Naproti tomu vypadá návrh editoru spíše přebuleje a fádně. (jakého editoru?)
even moderate size (more than a few hundred lines)
i středně velkých programů obsahujících několik řádků kódu.
which is what makes projects like Expect reasonable
právě proto jsou projekty, jako je Expect, potřebné
thread
podproces
signals, poll, and select
signály, žádosti a výběry
GTK and Qt use a slot-and-signal apparatus for event-handling…Poznamenávám, že pravopisné chyby se v textu nevyskytují, takže pokud je najdete v ukázkách jedná se o můj překlep. Abych však jen nehanil jeden překlad se mi velmi líbil frontend – průčelí. Předpokládám, že o knize napíšu ještě jeden příspěvek o jejím obsahu.
Knihovny GTK a Qt používají pro ošetření událostí mechanismy drážek a signálů,...
neděle 4. ledna 2009
Steve McConell: Odhadování softwarových projektů
Podtitul: Jak správně určit rozpočet, termíny, zdroje
Tato kniha je brožovaná obsahuje cca 300 stránek za doporučenou cenu 500 Kč. Knihu jsem četl v českém překladu od Jiřího Fadrného, kterému nic nevytýkám.
Kniha se zabývá jednoduchým odhadováním softwarových projektů od shora i od spoda, snaží se vysvětlit základní matematické principy, rozdíl mezi odhadem a intuitivním hádáním co odhad je, jak zlepšit odhad v rámci skupiny a jak se vyvarovat systematických chyb.
Všechny použité principy postupy vysvětluje a ilustruje. Nejlepší na knize je, že není třeba hlubších znalostí matematiky, než procenta, odmocnina, násobení, mocnění, trojčlenka a nepřímá úměra.
Sice bych ocenil i pokročilejší metody (už jen pro krásu matematiky), ale kniha přesvědčivě argumentuje, proč to stačí. (kvůli počtu proměnných, které je třeba stanovit a chyby při jejich stanovení, stejně tak i vzhledem k neurčitostí v podkladech pro odhadování a změn ve vývoji projektu oproti předchozím projektům.
Při předpokladech znalosti základů statistiky, by se některé kapitoly knihy dali podstatněji redukovat a věřím, že by se kniha i o třetinu zmenšila. Přesto jsem rád, že se autor zaměřil i na nováčky.
Na knize se mi líbí, že použité metody vztahuje vzhledem k jejich použitelnosti ve vývojovém cyklu projektu.
V předmluvě knihy stojí, že pomocí metod v ní obsažených, lze získat jistotu odhahu na přibližně 25% a to už stojí si za to přečíst.
Známka 9/10
Bohužel jak se v knize dozvíte, tak věrohodný odhad nelze udělat bez vstupních dat z předchozích projektů nebo minimálně z části projektu, počet mých softwarových pokusů není největší a stejně tak i potřeba stanovování přesných termínů. Proto jsem se zatím neodhodlal přesně měřit čas strávený na jednotlivých částech, počty částí a projekty poctivě dokumentovat. Věřím však, že při větší motivaci se knuhu rozhodně vyplatí přečíst. A znalosti z knihy by měli patřit mezi nástroje pokročilého vývojáře. Skoro bych knihu zařadil do povinné četby.
sobota 3. ledna 2009
Jack Goldsmith, Tim Wu: Kdo řídí Internet
Kniha vyšla v roce 2008 a po jejím neúspěšném shánění po knihovnách jsem se odhodlal si ji koupit, jako dárek pod stromeček.
Cena 300 Kč za cca 220 stránek mi přijde trochu nadsazená, ale kniha má tvrdé desky a je pěkně zpracovaná s pěknou sazbou, která se dobře čte. Knihu zdařile přeložil Jiří T. Pelech. (i když anglický originál jsem v ruce neměl, soudím tak tedy proto, že se v knize nevyskytují zřejmé technické nesmysly a neobvyklá spojení)
Kniha se zaměřuje na zmapování původní vize o svobodné společnosti na internetu a důvodů konce této vize. Probírá spoustu historických konfliktů a precedentů v přístupu k Internetu. V části, kde Jon Postel převezme DNS, nechybí vůbec vylíčení dramatičnosti tohoto okamžiku.
Dále kniha na jednotlivých příkladech ukazuje, jak státy regulují společnosti a jednotlivce za svými hranicemi. Že moc státu Internetem nebyla omezena, ale že stát se vzdal určitého prosazování moci na Internetu za účelem podpory ekonomiky a jeho prosazení. Kontrola internetu probíhá, ale není líčena jako zlý úmysl velkého bratra, ale jako předpoklad rozumného fungování výměny zboží a služeb.
Mimo konkrétních případů jak státní moc reguluje internet se kniha zabývá i regulací internetu ve státech, kde svoboda projevu má menší prioritu. Také rozebírá reakci západních firem na požadavky Čínských úřadů.
Autoři knihy se snaží poskytnout čistý pohled na vše toto hemžení kolem Internetu a knihu ukončují optimisticky.
Knihu můžu vřele doporučit k přečtení. Není v ní mnoho technických informací a v podstatě jde o humanitní četbu pro zimní večery.
Známka 9/10
pátek 2. ledna 2009
Jan Polzer: GNU Emacs a Vim: Kapesní přehled
Tuto knihu jsem si koupil kvůli prohloubení znalostí editoru VIM, přeci jen spousta užitečných příkazů tohoto editoru mi zůstala skryta. Kniha mě stála 100 Kč, tedy celkem malý peníz. Její zpracování je dáno nižší cenou a knížka připomíná svou kroužkovou vazbou sešítek o 139 stránkách. Z toho se cca 80 stránek věnuje editoru VIM.
Protože VIM obsahuje poměrně zdařilí tutoriál vimtutor kniha rezignuje na to působit jako učebnice a spíše se snaží probrat jednotlivé oblasti voleb editoru VIM. Přijde mi tedy líto, že některé oblasti kniha popisuje přespříliš podrobně (8 stránek tabulky různých speciálních znaků a jejich kódů) a o jiné ani nezavadí vůbec (buffery, vývoj v jiných jazycích než C).
Kniha neuvádí všechny použitelné aliasy příkazů a ani všechny příkazy, proto nemůže být pokládána ani za manuál. Přijde mi, že autor spíše straní editoru EMACS /čert jeden (o:/ a proto uvádí aliasy, které se podobají příkazům z EMACSu.
Vysloveně škoda mi přijde, že autor nevložil do sešitu volné stránky pro poznamenání vlastních příkazů. V knize jsem objevil i několik chyb a to typografických i faktických.
Z části o VIMu jsem proto zklamán, neboť pročtením dokumentace bych se dozvěděl informací více a podrobněji. Přesto mě však přečtení knihy upozornilo na některé mechanismy VIMu, o kterých jsem netušil a chtěl bych autora pochválit za to, že správně vylíčil editor VIM jako prostředí, které si efektivně přizpůsobíte pro vaše editování.
Část o editoru EMACS jsem pouze zběžně prohlédl a nedovolím si ji tedy soudit. Nechápu však proč obsahuje: popis editace emailů a výčet her dostupných v EMACSu.
Známka 4/10.
Přihlásit se k odběru:
Příspěvky (Atom)
