Best Kept Secrets of Peer Code Review

6. prosince 2009 v 21:33 | LR |  Knihovnička
Nechal jsem si zdarma zaslat výtisk knihy "Best Kept Secrets of Peer Code Review" od firmy SmartBear. Velká část knihy je dostupná online, ale zrovna ty zajímavější části nejsou, takže jsem po přečtení online částí vyplnil formulář a čekal na balíček.


Po dočtení ve mě zůstal pocit, že se jedná o docela dobrou a stručnou knihu. Část prodávající produkt SmartBear je docela zanedbatelná. V části porovnávající jednotlivé přístupy je možná trochu více cítit, že cílem je prodat software na podporu revidování kódu, ale obecné závěry ohledně revize kódu jsou docela smysluplné a hezky podložené studiemi (pokud někde není dostatek dat, tak je to přímo zmíněno).

Jedním z argumentů pro praktikování revize kódu je porovnání nákladů na odstranění chyby. Jde o klasické "dříve je lépe" a protože revize má proběhnout před testováním, tak ušetříte za QA a najdete chyby, které třeba ani testování neobjeví. Z tohoto pohledu jsou docela nevýhodné revize ve skupinách (mnoho lidí, velké náklady a přibližně stejný výsledek), upřednostňováno má být samostatné studium kódu.

Dalším argumentem pro revize kódu je vzájemné vzdělávání vývojářů. Jak autor kódu, tak revidující mají šanci objevit něco nového. Samozřejmě se tím i zvyšuje zastupitelnost jednotlivých lidí. Pokud v teamu praktikujete párové programování, tak samozřejmě tento argument neobstojí. Zajímavé je, že i při párovém programování by měl ještě někdo třetí provést revizi, protože dva programátoři v páru postupně sladí svůj styl a také slepotu k určitému druhu chyb.

Knize bych trochu vytknul příliš stručnou část řešící problémy při provádění revizí kódu. Prográmátorské ego je asi největší překážkou a autor k tomu zaujímá dosti optimistický postoj - programátory má přesvědčit fakt, že je to pro ně dobré :)

Jelikož je kniha zdarma, tak cena nehraje roli a rozhodně stojí za čas věnovaný čtení. Cílovou skupinou jsou jak vedoucí teamů, tak i řadoví programátoři, protože obě skupiny by měli mít jasno v tom, proč a jak je vhodné dělat revizi kódu.

Tři videa o testování softwaru

18. října 2009 v 21:21 | LR
Nahromadily se mi tu poznámky ke třem volně dostupným záznamům z prezentací k tématu testování softwaru. Tady jsou:

GTAC 2008: Practicing Testability in the Real World

(Vishal Chowdhar) 2008/10/24


8:00
Testability definition
11:25
Simplicity, Observability, Control, Knowledge
15:25
SDE/T = Test developer
25:00
Waiting in thread testing (asynchronous API)
28:02
Adding more and more - funny traffic sign (simplicity example)
34:30
Simplicity checklist
44:40
Observability checklist
47:16
Control checklist
48:35
Knowledge checklist
49:50
Testability++

K tématu: Test smells

Dobré checklisty, hodí se pro test-code review.

Automating Business Value with FIT and Fitnesse

(David Hussman) 2008/04/26

Video na InfoQ (slidy v odděleném náhledu jsou skvělá věc, ale zrovna u tohoto videa tam zjevně nejsou všechny)
  • story testing = acceptance testing
  • pokud lze postup převést do tabulky, tak to lze testovat pomocí FIT/Fitnesse
  • Core FIT fixtures (Column, Action, RowFixture, DoFixture)
  • Table -> Fixture -> System under Test example (39:20)
  • FIT je vzhledem k testovanému systému v podobné pozici jako jUnit
  • FIT/Fitness ale slibuje čitelnější testy než jUnit - Executable Documentation
FIT ani Fitness jsem doposud nikdy nepoužil, ale tohle video vypadá jako dobrý a přesvědčivý úvod.

Integration Tests Are a Scam

(J. B. Rainsberger) 2009/10/10

Taktéž z InfoQ.

Integrační testy (end to end testy) mají velké nevýhody:
  • pokud test selže, tak stejně většinou nevíte přesně proč, protože testy jsou z principu dosti složité
  • trvají dlouho
  • dostatečně velké pokrytí je nemožné, protože s každou testovanou komponentou/vrstvou se násobí počet možností
Cesta ven: mít plné pokrytí rozhraní a interakcí mezi objekty, pak je celková základní funkčnost otestována, protože v systému se nemůže objevit odpověď, kterou příjemce nečeká a nic neposílá požadavek, který by nebyl otestován. Test kontraktu. Tímto se převede geometricky rostoucí množství integračních testů na přijatelnější množství řešící jen testy izolované komunikace mezi částmi.

S problémy realizace integračních testů souhlasím, ale navrhované nahrazení pomocí testů interakcí se mi zdá příliš teoretické a v reálu realizovatelné jen pro jednodušší interakce. Složitá interakce je sice znakem špatného návrhu, ale zatím se setkávám spíše s pragmatickými řešeními ve stylu "tady to trochu přiohnem", namísto vypiplaných rozhraních zbavených všech nectností a zápachů.

Alan Cooper: The Inmates Are Running the Asylum

17. května 2009 v 21:55 | LR |  Knihovnička
Why High-Tech Products Drive Us Crazy and How to Restore the Sanity


Zajímavé čtení o tom, jak moderní technika zanedbává interakci s uživatelem, proč se tak děje a z čeho bychom si (ne)měli brát příklad.

Kniha začíná mnoha variacemi na téma co se stane, když zkřížíte užitečnou věc s počítačem. Odpovědí je vždy popis těžkopádnosti obsluhy některého přístroje (video, digitální foťák, ....), který nabral spoustu běžně nepoužívaných funkcí za cenu nepřehledného rozhraní. Téma je dále obecně rozebíráno pod pojmem "cognitive friction". Častým přirovnáním pro moderní technologii je tancující medvěd - tancuje velmi neohrabaně a vlastně hrozně nepěkně, ale podivem je to, že vůbec tancuje. Uživatelé jsou tak stavěni do stejné pozice jako diváci sledující medvěda. Ovládání je nepohodlné, ale zázrakem je, že ta věcička vůbec funguje.

Uživatele autor dělí na dvě skupiny - apologists (zastánci) a survivors (přeživší). Ty první jsou typičtí programátoři, kteří byli schopní se vyrovnat se složitostí a to považují za takovou výhodu, že složitost nejen omlouvají, ale i dále propagují (Ano, asi tam patří i "Ovládání Vimu je přeci jednoduché. Třeba pro uložení a ukončení zmáčkneš jen Esc :wq" :-) Druhá skupina se prostě cítí neskutečně blbě, protože nezvládá ovládání, ale přesto je nucena systém používat (prakticky každý, kdo si chtěl vybrat hotovost z bankomatu a musel na obrazovce vybrat typ účtu, ačkoliv má jen jeden).

Programátoři jsou špatní návrháři uživatelského rozhraní, protože vše vidí z pohledu návrhu pro použití funkce a nikoliv z pohledu uživatele, který chce něco udělat, něčeho dosáhnout a nikoliv jen použít funkci. Typického programátora baví složité systémy a prostě mu to nedá, aby alespoň trochu té "krásné" složitosti nepřenesl na chudáka uživatele. Je to vlastně způsob šikany, jakým si mentálně zdatnější jedinci v pozici programátorů honí své ego na těch méně obdařených uživatelích. Autor knihy otevřeně přiznává, že se choval také tak :)

Po rozsáhlé kritice postupů následuje konstruktivní část knihy s popisem zlepšení metod návrhu uživatelského rozhraní.

Definujte si konkrétně zaměřeného uživatele a dělejte produkt pro něj (Personas). S produktem pro všechny je mnohem těžší potěšit alespoň někoho. Posuzujte požadavky zákazníků z původně definovaného pohledu klíčových uživatelů, aby se z produktu nestal rozplizlý neurčitý balík poskládaných funkcí, které zrovna někdo chtěl.

Zaujala mě rozsáhlá kritika špatného iterativního návrhu. Cooper kritizuje postup, kdy se zplácá produkt a vrhne se na trh jenom kvůli tomu, aby se zjistilo, jestli se to uchytí. Když ne, tak se produkt upraví podle připomínek a jde se do toho znovu. Uváděn je příklad prvních třech verzí Windows, které byly nepoužitelné, ale MS prostě tak dlouho nahazoval nové verze, až se to chytlo (Brooks: build one^H^H^H three to throw it away:-). Muselo to stát nepředstavitelně peněz. Tato špatná praktika vedla nakonec k velkému úspěchu a tak je omylem považována za vhodnou. Běžnou firmu tento postup nejspíš položí.

V jedné kapitole je vývoj SW přirovnáván k tvorbě filmu. Filmový štáb věnuje velké úsilí k dokonalé přípravě, aby omezil zbytečné výdaje v nejdražší fázi filmování. Tohle mě na první pohled přišlo jako doporučení waterfall procesu, ale není tomu tak. Autor jen říká, že je levnější realizovat návrh rozhraní na papíře, než až v programu.

S čím v této knize nesouhlasím? Kritika souborového systému a poukazování na jeho nesrozumitelnost pro uživatele je asi oprávněná, ale nabízené řešení, aby programy skrývaly filesystem před uživatelem se mi zdá jako nesmyslné cílení na skupinu začátečníků. Osobně úplně nesnáším programy, které mají vlastní dialogy pro manipulaci se soubory a nebo jsou vázané na jednu složku.

Druhá připomínka je trochu obecnější - popisované postupy a připomínky předpokládají ideální stav, kdy si dokážete najít dostatek prostředků pro realizaci všech možných optimalizací uživatelského rozhraní. Problém vidím v tom, že prakticky neexistuje objektivní posouzení stavu hotovo a každý může říct že teď už to stačí (nebo naopak připomínkovat prakticky do nekonečna, což se u GUI často opravdu děje). Navíc se v celé knize předpokládá, že máte cosi jako osvíceného produktového manažera - návrháře uživatelského rozhraní, který přesně ví, co je pro uživatele dobré a za tím si stojí od začátku do konce. Tohle by si samozřejmě přál každý, ale šance vytvoření produktu na míle vzdálenému skutečným potřebám se snižuje právě iterativním postupem, při kterém se konečný cíl upřesňuje podle aktuálních požadavků. Obdobně tu máme demokracii, která je horší než dokonalý monarcha, ale chrání nás před úplným fiaskem ve formě krutého diktátora.

Závěr knihy vyznívá jako popis další silver bullet v podobě silného návrháře uživatelského rozhraní, který má držet směr celého vývoje a odpovídat za kvalitu produktu. Zcela v souladu Brooksova There Is No Silver Bullet beru doporučení v knize jako další přístup, který za určitých podmínek může přinášet popisované výsledky, ale bezhlavá aplikace situaci asi nezlepší. Autor samozřejmě propaguje svůj postup prodávaný jeho konzultantskou firmu.

Kniha byla poprvé vydána v roce 1999 a myslím si, že nic neztratila na své aplikovatelnosti na současnost, ačkoliv je postavena hlavně na příkladech, které jsou z dnešní perspektivy považovány za téměř historické. Sám autor píše: "We are too busy assimilating new technologies to reflect on the misconceptions surrounding the older ones."

Autorova firma má blog na téma designu a věcí okolo, opakuje se tam i popis konceptů z této knihy.


Agilní programování - Metodiky efektivního vývoje softwaru

22. března 2009 v 22:56 | LR |  Knihovnička
Ve firemní knihovničce jsem vyhmátl tuto knihu z roku 2004 od Václava Kadlece (web vydavatele, recenze na LinuxZone). Vzhledem k poměrně malému počtu stran a dosti obecnému názvu se dočkáme pouze průřezového popisu bez hlubších detailů. Ideální jako úvod do problematiky metodik a nebo jako nástroj pro osvěžení znalostí.

Ve stručnosti pár bodů, které mě zaujaly (podotýkám, že s XP, SCRUM a TDD jsem již poměrně dost seznámen):

XP
Zajímavá polemika o nevhodnosti nasazení v těchto končinách vzhledem k zakořeněným postojům a obavám z rizika.

Lean development
Odvozeno z průmyslové praxe (Toyota) - minimalizace zbytečných artefaktů.

Crystal
O výběru metodiky na základě rozsahu a důležitosti projektu - pokud jde o život a nebo o velké peníze, tak zcela určitě potřebujete rigidní metodiku s mnoha dokumenty.

Adaptive Software Development
Tato metodika mě přišla jako nejvíce anarchistická :) To už není ani iterace, ale vše tak nějak dohromady a najednou. Metodiku popisují tři fáze: spekulace, spolupráce a učení. Tohle prostě nejsou slova, která by se běžně asociovala s popisem vývoje SW.

Dynamic Software Development Method
Docela chytlavý mem pro rozdělení priorit: MoSCoW - Must, Should, Could, Won't.


Při čtení jsem často porovnával s tématicky podobným školením od Logosu (absolvováno asi tak před rokem) a prostě jsem se neubránil pocitu, že jediný přínos školení bylo několik příkladů a historek navíc, ale jinak by kniha stačila. Především z poměru cena/výkon je kniha lepší než školení. A to už nemluvím o tom, že se zase potvrzuje mnohokrát zmiňovaná zkušenost - jakmile nestíháte, tak házíte všechny moderní metodiky za hlavu a snažíte se dodat požadovaný kus SW prostě po staru :)

Krize v indickém IT: ztráta výhodné pozice na sňatkovém trhu

15. března 2009 v 19:12 | LR |  Zábava
Současný vývoj ekonomické situace může zcela oprávněně vyvolávat různé obavy, ale následující článek z Times of India je z pohledu člověka žijící v západní kultuře opravdu kuriózní :-)

Pár vysvětlivek:
1 lakh = 100.000 Rs
1 indická rupie (Rs) je asi 0,50 Kč



(z 20. 11. 2008)

Čitelnější podoba článku na webu Times of India.

Telekomunikace v Nepálu

17. února 2009 v 21:18 | LR |  Fotografie
V listopadu 2008 jsem strávil nějakou dobu v Nepálu (viz zápisky z Nepálu) a ačkoliv jsme většinou chodili po horách, tak se mi přesto podařilo zachytit dva obrázky s technickou tématikou :)

První fotka je z Kathmandu.


Druhý obrázek zachycuje venkovní instalaci jakýchsi zařízení (žlutý kabel může být optické vlákno) na sloupu u cesty ke vstupu do parku Chitwan.

NCTUns - síťový simulátor a emulátor pro Linux

20. ledna 2009 v 22:39 | LR |  Podobné projekty
Na thaiwanské National Chiao Tung University vytvořili poměrně kvalitní a obsáhlý projekt nazvaný NCTUns (viz domovská stránka projektu - klikněte na Products -> NCTUns). Co všechno tento simulátor síťových protokolů umí? Začíná na fyzické vrstvě, kde je možné použít klasický přenos po metalických kabelech, optice a nebo přenos vzduchem. Na transportní vrstvě je dostupný Ethernet či 802.11b a ve vyších vrstvách jsou například protokoly RIP, OSPF, IP, TCP, UDP, RTP/RTCP, FTP, HTTP, .... Zajímavá je simulace GPRS (to se často nevidí) a směrovacích protokolů pro mobilní sítě. Návodem k použití je nejen detailní manuál, ale i instruktážní videa (sice bez komentáře, ale za to s klasickou hudbou).

Program běží jedině na Linuxu a doporučená je distribuce Fedora Core. Doporučená konfigurace je CPU rychlejší než 1,6 GHz a 512 MB RAM, na disku potřebujete asi 300 MB.

Pro stáhnutí programu se musíte registrovat.


Kam dál