Subscribe: Banter bloguje
http://blog.zvestov.cz/xml-rss2.php
Added By: Feedage Forager Feedage Grade B rated
Language: Czech
Tags:
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Banter bloguje

Banter bloguje



Blog o softwarovém inženýrství, programování v jazycích Java či Groovy, ale i o mimopracovních věcech, které mi přeletí přes nos.



Published: Thu, 05 Apr 2018 18:57:37 +0000

Last Build Date: Thu, 05 Apr 2018 18:57:37 +0000

 



Starbucks nepoužívá dvoufázový commit

Mon, 12 Mar 2018 00:00:00 +0000

Gregor Hohpe, autor knihy Enterprise Integration Patterns, napsal článek Starbucks Does Not Use Two-Phase Commit, který ani po tolika letech neztratil na aktuálnosti. S jeho laskavým svolením jsem článek přeložil do češtiny. 19. listopadu 2004 Hotto Cocoa o Kudasai Právě jsem se vrátil z dvoutýdenního výletu do Japonska. Jednou z nejznámějších památek je velký počet kaváren Starbucks (スターバックス) obzvlášť kolem Shinjuku a Roppongi. Během čekání na své „Hotto Cocoa“ jsem začal přemýšlet nad tím, jak Starbucks zpracovává objednávky nápojů. Stejně jako většina jiných podniků jsou primárně zaměřeni na maximalizaci propustnosti objednávek. Víc objednávek znamená větší tržbu. A proto používají asynchronní zpracování. Když si objednáte, tak pokladní označí kelímek na kávu vaším jménem a zařadí ho do fronty. Fronta je úplně doslova fronta kelímků na kávu seřazených na vrchu kávovaru. Tato fronta odděluje pokladní a baristu a dovoluje pokladní dál přijímat objednávky, i když je barista zrovna zahlcený. Pokud začne být v kavárně rušno, tak jim to umožňuje nasadit víc baristů ve scénáři Competing Consumer. Korelace Starbucks získal výhody asynchronního přístupu, ale musí se ovšem vypořádat s problémy, které to přináší. Například korelace. Objednávky nápojů nejsou nutně zpracované v pořadí, v jakém přišly. To se může stát ze dvou důvodů. Za prvé různí baristé můžou používat jiné vybavení. Ochucené nápoje můžou zabrat víc času než káva. Za druhé baristé můžou připravovat několik nápojů v dávce, aby optimalizovali čas zpracování. Ve výsledku má Starbucks problém s korelací. Nápoje jsou doručeny mimo sekvenci a musí být přiřazeny správnému zákazníkovi. Starbucks problém vyřešil stejným vzorem, který používáme v messaging architektuře – používají korelační identifikátor. Většina Starbucks v USA používá explicitní korelační identifikátor, takže napíše vaše jméno na kelímek a vyvolá vás, když je nápoj hotový. V jiných zemích korelují podle druhu nápoje Zpracování výjimek Zpracování výjimek ve scénářích asynchronního messagingu může být obtížné. Jestliže skutečný svět píše nejlepší příběhy, tak se možná můžeme něco naučit tím, že se podíváme, jak Starbucks řeší výjimky. Co udělají, když nemůžete zaplatit? Jestliže už byl nápoj vyrobený, tak ho vyhodí, jinak vytáhnout váš kelímek z řady. Pokud vám dají nesprávný nápoj nebo nejste spokojení, tak ho udělají znovu. Když se jim porouchá kávovar a nemůžou připravit váš nápoj, tak vám vrátí peníze. Každý z těchto scénářů popisuje jinou, přesto ale běžnou, strategii zpracování chyb: Odepsání - Tato strategie zpracování je nejjednodušší ze všech: nedělejte nic. Nebo zrušte, co jste udělali. Může se to zdá jako špatný plán, ale v realitě byznysu může být tato volba akceptovatelná. Je-li ztráta malá, tak vyrobit řešení na korekci chyb může být dražší než nechat věci být. Pracoval jsem například pro několik poskytovatelů internetového připojení, kteří vybrali tento přístup, když došlo k chybě při vyúčtování. Ve výsledku mohl zákazník skončit s aktivní službou, za kterou nezaplatil. Ztráta zisku byla dost malá na to, aby byznysu dovolila tímto způsobem fungovat. Pravidelně pak pouštěli report, který detekoval takové bezplatné účty a zavíral je. Zopakování - Pokud selžou některé operace z velké skupiny (např. transakce), máme v podstatě dvě možnosti. Vrátit změny, které už se provedly, nebo zopakovat ty, které selhaly. Zopakování je možná varianta, pokud existuje reálná šance, že zopakování uspěje. Pokud je například porušené byznys pravidlo, tak je nepravděpodobné, že zopakování uspěje. Nicméně pokud je externí systém nedostupný, tak zopakování[...]



Společné čtení knih

Tue, 27 Feb 2018 00:00:00 +0000

Na blogu Think Fort jsem kdysi narazil na společném čtení knih, ale teprve nedávno jsem se rozhoupal taky začít. Cílem aktivity je společně vybrat jednu knihu, kterou si každý doma sám přečte. Následně se sejdeme a o knize diskutujeme. Čteme zhruba 100 stran měsíčně, o kterých pak asi hodinu a půl diskutujeme. Sám čtu dost, díky dojíždění na to mám vyhrazený čas (i když jsou lidé, kteří čtou několikanásobně víc než já). Chtěl jsem zážitek zprostředkovat i ostatním a mít možnost probrat, co nám dává smysl a co třeba už ne. Například loni jsem v jednom code review připomínkoval stořádkovou metodu, která mi přišla příliš dlouhá. Myslím, že jsem tenkrát nebyl moc úspěšný, ale domnívám se, že po společném čtení knihy Clean Code panuje ohledně délky metody větší, byť ne úplná, shoda. Knižní tituly Jako první jsme četli obligátní Clean Code (Robert C. Martin alias Uncle Bob), dnes už je možná trochu zastaralá (třeba kapitola o JUnit je nezáživná a pro diskusi ne příliš vhodná), ale patří ke kánonu a určitě stojí za přečtení. Pokračovali jsme s knihami Effective Programming (Jeff Atwood), Hackers & Painters (Paul Graham) a jako poslední 97 Things Every Programmer Should Know (Kevlin Henney). Všechny tři mají společné to, že se jedná o kratší samostatné celky (v případě 97 Things Every Programmer Should Know možná až příliš krátké), což může pomoc někomu, kdo nemá delší souvislý čas na čtení. Knihy vybíráme hlasováním. Snažím se zařazovat technologicky agnostické knihy, abych nevyloučil Javisty, které by třeba odradil JavaScript (a naopak). Dokážu si představit například Erlang, o kterém všichni víme málo nebo nic, abychom se mohli inspirovat jiným programovacím jazykem. Osobně jsem rád i za méně technické, jako byla zdánlivě i kniha Hackers & Painters. Kluci (bohužel žádné holky s námi ještě nečtou) byli zaražení, že třeba první esej je o americkém školství. Ale je dobře, že si ji přečetli, sami by po ní možná nesáhli, nebo by ji bez vidiny společné diskuse nedočetli. Diskuse Na schůzku je potřeba se řádně připravit. Měl jsem výhodu, že všechny čtyři knihy, které jsme doposud vybrali, jsem už četl. Nicméně přečetl jsem si je znovu a hlavně úplně jinak. Musel jsem dávat větší pozor, psát si poznámky a myšlenky, které bychom mohli probrat. Jsem celkem ukecaný, takže je pro mě schůzka dobré cvičení, abych upozadil svůj názor a víc fungoval jako moderátor. Někteří jedinci knihu nečetli, ale přišli a chtěli by diskutovat. Nikoho jsem vyloženě nevyhodil, ale rozhodně jsem dal najevo, že se mi to nelíbí. Vzpomínám si, jak si učitelka dějepisu dobírala americké studenty, že by jen diskutovali, ale nemají znalosti. V konečném důsledku asi bylo dobře, že na schůzce byli, ale vadilo mi, že do toho nevložili to samé úsilí jako jejich kolegové. Snažím se všechny zapojit, ale občas jsem si připadal jako češtinář na gymplu, který se při probírání Babičky ptal, kdo byli Kristla a Míla. Někdo bezostyšně odpověděl, že koně. V americké armádě mají povinnou četbu. Našel jsem West Point Tips for Teaching. Kladou si otázky jako například: „Které myšlenky z této kapitoly jsou pro tebe nové a obzvláště zajímavé?“ Přidal jsem k tomu: „S čím nesouhlasíš a proč? Co bys u nás zavedl?“ V knize Effective Programming v kapitole o bezpečnosti jsem se ptal: „Jak to děláme my?“ Ale u takhle obecným otázek jsme nezůstali, snažím se být konkrétní. Mám na paměti poučku (snad novinářskou): „Nepřeceňujte znalosti a nepodceňujte inteligenci!“ Stojí rozebrat i to, o čem si myslíte, že je jasné. Když není, udělali jste správně. Pokud ne, lidé budou mít radost, že to vědí. Případně všichni můžou vědět, o co jde, ale budou se třeba výrazně[...]



O náboru juniorů

Fri, 26 Jan 2018 00:00:00 +0000

Před rokem jsem hledal práci, teď občas bývám u pohovorů na druhé straně. Mám rád junior programátory, pamatuji si, že i já byl takový a bylo o mě dobře postaráno, tak bych to rád vracel. Chtěl bych se podělit o své zážitky, protože jsem byl bohužel z několika kandidátů zklamaný. Myslím, že by mé poznámky mohly některým pomoct s přípravou. Mohli by lépe využít svého potenciálu, abych je příště nemusel odmítnout. Základní předpoklady Přijde mi, že po roce (jejich) tvrdé práce a citlivému vedení jsou na tom junioři lépe než leckteří samozvaní senioři (a co si budeme namlouvat, jsou pro firmu i levnější). Jestli se u mě něčemu naučili, nechť posoudí sami. Nechci moralizovat jako Monty Python ve skeči Four Yorkshiremen, ale přemýšlím, co jsem (ne)uměl, když jsem začínal. Především potřebuji vidět jiskru v oku a nadšení pro věc. Ptal jsem se například i na to, proč chtějí být programátorem. Pokud se hlásí na pozici Java vývojáře, tak očekávám znalost minimálně na úrovni učebnice Pavla Herouta, takže třeba dokáží popsat rozdíl mezi interface a abstraktní třídou, kontrakt equals a hashCode případně rozdíl mezi LinkedMap a HashMap. Nikdo vás nebude učit naprosté základy, které můžete nastudovat sami doma. Tak jako na hudební nástroj cvičíte stupnice, tak očekávám, že máte nacvičené hanojské věže, bubble sort…, přestože to v praxi zdánlivě k ničemu není. Ale co můžete jako čerstvý absolvent jiného nabídnout? Předpokládám i základní znalosti hardware: jak dlouho trvá sečíst číslo, http požadavek či zápis na disk (nikoliv přesné jednotky, ale řády). Životopis Nepište si do životopisu blbosti, přijde se na to. Když vidím, že se někdo chlubí scala, groovy, kotlin, tak mě to nadchne, ovšem hned dostanu studenou sprchu, protože jsem se zeptal, jaký je mezi nimi rozdíl. Máte-li tam napsáno MySql, Mongo, opět ode mě očekávejte otázku: „Jaký je rozdíl mezi relační databází a NoSQL?“ To samé platí pro svn, git (i když to se mi stalo asi u někoho „zkušenějšího“). Nicméně neklesejte na mysli, není cílem zjistit, co nevíte, ale naopak, co víte (to jsem se, mám dojem, naučil od SoftWare Samuraje). Ostatně to i kandidátům při pohovoru několikrát opakuji. Pokud jste nedokončili vysokou školu, není to nutně špatně, ale počítejte, že se vás na to zeptám. Zkusili jste první semestr a zjistili, že to není nic pro vás? Vyhodili vás těsně před státnicemi? Vidím awk, fajn, to nebude klikač, něco se od něj naučím. Pošlete odkaz na svůj LinkedIn profil, chci si ověřit reference a zjistit, jestli vás nezná někdo z mých známých, kterých bych se mohl přeptat. Obzvlášť jmenujete-li se například Jiří Novák, tak se hodí přímo odkaz, abych nekoukal na profil úplně jiného Jiřího Nováka. Domácí úkol Předně posílejte odkazy na bakalářky a diplomky, chci je vidět. Je to něco, na čem jste intenzivně pracovali, tak se tím, sakra, pochlubte. O domácí úkolu už jsem psal, ale hodí se některé věci zopakovat a zdůraznit. Kód musí jít zkompilovat a spustit. Měl by splnit zadání. Ukliďte po sobě a nenechávejte tam zakomentovaný kód. Těším se na commity, abych viděl, jak přemýšlíte, ale častým nešvarem je, že je celý úkol commitnutý najednou. Vzdělávání Zajímá mě, jak a z čeho se učíte. V příspěvku Programátorem po čtyřicítce se píše, abyste četli alespoň 6 knih za rok. Přijde mi, že lidi nečtou (jako vůbec), skřípu zuby, ale budiž. Já zase nepřispívám do open source projektů, což by zase mohli rozporovat jiní. Nevadí, jmenujte nějaký podcast, youtube kanál nebo blog (tím nemyslím, abyste podlézali a řekli ten můj). A víte, co místo toho slyším? „Učím se ze StackOverflow.“ Taky tam chodím několikrát denně řešit svo[...]



Hodina kódu s LightBot a Meet Edison

Mon, 27 Nov 2017 00:00:00 +0000

Díky všeobecnému nadšení na jOpenSpace se zvýšilo moje odhodlání ohledně výuky programování dětí. Než stačilo nadšení trochu opadnout, upozornil mě Martin Javorek se svým účtem Programujeme hrou na akci Hour of Code (česky Hodina kódu), které se účastní desítky milionů žáků z více než 180 zemí světa, jejímž cílem je ukázat, že informatika je zábavná a tvůrčí, že není třeba se jí bát a že to zvládne každý. Napsal jsem do školy, kam chodí syn, jestli se nepřipojíme, a bylo to. Příprava Sestrojil jsem... - http://t.co/qOmAlbc8ti pic.twitter.com/jyK21A0Ety— Jentak (@mjentak) October 15, 2015 How to write maintainable code (Peter Hilton) Původně jsem k přednášce přistupoval s nedůvěrou, zda se k tématu Clean Code dá říct ještě něco nového. Byl jsem příjemně překvapen, že to lze. Nakonec patřila k tomu nejlepšímu, co jsem na konferenci slyšel. Snažím se sledovat řečnický projev, abych se od přednášející něco naučil. Už u jOpenSpace jsem vyzdvihoval to, zda jsou přednášející schopní na sebe reagovat. Hilton zašel ještě dál: Do svých slidů stihl zapracovat fotku z předchozí přednášky a navázat na ni. A ham sandwich walks into a bar. The bartender says, “Sorry, we don’t serve food here.” Slova můžou mít více významů, na tom jsou založené vtipy. Navrhuje používat slovník při výběru názvů proměnných (Mac ho má přímo vestavěný v systému). Osobně si vzpomínám, jak jsme na jednom projektu zaměnili request a demand (není požadavek jako požadavek). Důvěřujete svým kolegům, že vždy píší čistý kód? Připomněl mi knihu Specification by Example (Gojko Adzic) Dlouhá papírová dokumentace, stejně jako levné víno, stárne rychle a způsobuje bolest hlavy, pokusíte-li se ji použít rok po tom, co byla vytvořena. Na druhou stranu udržovat systém bez jakékoliv dokumentace rovněž způsobuje bolest hlavy. Podle Hiltona se Uncle Bob mýlí a pokud nemáte komentáře, nemáte vůbec žádnou dokumentaci. Nemáme to přehánět s principem DRY. Mluvil o sirénách abstrakce. Abstrahovat bychom měli až při třetím psaní a nějakou duplicitu tolerovat. Popisoval nástroj architecture decision record. Zapisujte si svá rozhodnutí, co jste zvažovali a proč jste se rozhodli zrovna takhle. Používáme a můžu taky doporučit. Po roce si třeba sami nevzpomenete, případně ukážete nově příchozím. Architecting for performance. A top-down approach (Ionut Balosin) Clean code nepíšeme jen kvůli čitelnosti, ale má dopad i na výkon. Nepíšu takto na výkon vyladěné programy, ale přesto bylo zajímavé si to poslechnout. Na škole mi to dost vadilo, ale zpětně doceňuji, že je dobré trochu rozumět tomu, jak funguje hardware. Vysvětloval, že třeba cohesion je důležité pro CPU cache. Nebo že není jedno, zda dvojrozměrné pole procházíte po řádcích či po sloupcích. ‘Built To Last’ …and the end of migrations (Adam Bien) Přestože dávám přednost Springu, tak sleduji blog Adama Biena, který propaguje čistou Javu EE a CDI, abych zůstal v obraze (poslední dobou přepnul víc na videa, ale já raději text). Svou přednášku pojal jako live coding, kde ukázal, čeho lze dosáhnout bez frameworků jen se standardními technologiemi: čistá Java, javascript a css. Máme si případně jen vyzobat komponenty jako třeba PrimeFaces (asi myslel PrimeNG). To je mi sympatické. Ostatně nedávnou jsem překládal článek Nechte kouzlo zmizet a již dříve jsem se vztekal nad velikostí waru (ten jeho měl 8 kB). Adamova přednáška do toho pěkně zapadá. Mimo jiné třeba říkal: Minification will die because of http/2 preloading. Mluvil o své zkušenosti konzultanta, kdy jeden zákazník uvázl na staré verzi Angularu a migrace byla složitá ne-li nemožná. Povýšení Javy bylo vždy v pohodě. Z [...]



jOpenSpace 2017

Tue, 24 Oct 2017 00:00:00 +0000

Stavěl jsem a zařizoval dům, takže jsem pár let trochu zanedbával konference (kromě třeba Devel 2016). Letos jsem se konečně vypravil na jOpenSpace 2017 a bylo to naprosto skvělé. Sepsal jsem si pro sebe pár poznámek, které můžete brát i jako lákadlo na příští jubilejní ročník. jOpenSpace je nekonference v tom smyslu, že každý návštěvník musí přijít s vlastní prezentací. Na jOpenSpace jsem potkal 41 chytřejších lidí, než jsem já. Platí, že jste průměrem lidí, kteří vás obklopují, takže podobné akce vás táhnou nahoru. Je to úplně jiný zážitek, potkat lidi z twitteru naživo a s některými si i zaběhat. Na přednášku bylo k dispozici deset minut, takže se ukázalo, jak se kdo připravoval, jaký má respekt k posluchačům a zda přetahuje. Nehodlám rozebírat všechny přednášky, ale rád bych vykreslil celkový dojem, který jsem si odnesl. Krouhači zelí Velký úspěch sklidil Lukáš Křečan s Theory of Constraints z knihy The Goal, která je sice zaměřená na fabriky, ale Lukáš dokázal téma přiblížit i pro IT. Přesto zvolil příklad hipsterské restaurace specializované na knedlo, vepřo, zelo. Krouhač zelí sice maká, seč může, ale když výroba knedlíků nestíhá a zelí se vyhodí, tak firmě může i škodit. Nejste placeni za psaní kódu, ale za nějaký přínos pro byznys, takže místo strouhání zelí může programátor jít pomoc testerovi. Víte, kde je vaše úzké hrdlo? Dobrá konference a kvalitní přednášející se poznají tak, že řečníci jsou schopní a ochotní reagovat na kolegy, kteří vystoupili před nimi. Je to zážitek jako z not, které souzní v akordu. Tím se dostávám k Romanu Pichlíkovi, který se věnoval lead or follow aneb pro už není programátorem. A vzbudil značné kontroverze tím, že bychom se neměli věnovat strouhání zelí. Z publika zazněla námitka, že je to falešné dilema velkých firem, že v malých firmách se nemusíte vzdávat svého struhadla a přesto můžete věci ovlivňovat. Téma pak bylo předmětem diskusí snad všech přestávek až do konce. Přednášky nejsou od toho, abychom se souhlasně plácali po zádech. Dagimu se podařilo nastolit téma, smekám. Podle mě nechtěl říct, vykašlete se na strouhání, nechceme přece technologicky zaostat, ale výborně se mu povedlo lidi nakopnout k přemýšlení, abychom se nezasekli jenom v technikáliích, ač v tomto výkladu jsem byl osamocený. Ženy Kamil Ševeček ukázal fotografii přednáškové místnosti asi pro tři sta lidí, kde seděla možná jen jedna žena. Mluvil o svých zkušenostech z projektu Czechitas a o tom, že ženy mají o programování zájem. Bohužel jsem se nedobrali důvodu, proč je v IT málo žen. Přitom historie je plná velkých žen jako Ada Lovelace (vymyslela programování tak, jak je známé dnes) či Margaret Hamilton, programátorka softwaru pro Apollo. Ze současné Java komunity můžu jmenovat třeba Trisha Gee. Na jOpenSpace jedna žena dorazila, i s dítětem. Forenzní genetička Nasťa Sedláčková vyprávěla o webové prezentaci dat z jazyka R. Úžasné na tom bylo, že nešlo o programování pro čisté programování, ale že jde o aplikaci programování do biologie, ze které má doktorát. Ukázala programování jako prostředek k dosažení cílů v jiném oboru. Podobné praktické využití by mohlo přitáhnout víc lidí. Využil jsem příležitosti a o přestávkách se Nasti na vědu, kriminalistiku a akademickou sféru vyptával. Děti Leitmotivem letošního jOpenSpace byla výuka programování pro děti. Hojně jsme o tom o přestávkách diskutovali, přestože takovou přednášku neměl původně nikdo připravenou. Dává to smysl, když už se sešlo tolik rodičů. Osobně mám zkušenost se Scratch Junior, LightBot a SpriteBox. K tomu jsem posbíral spoustu odkazů k prostudování: Compute[...]



Volby

Tue, 26 Sep 2017 00:00:00 +0000

Nad tímto příspěvkem přemýšlím snad po každých volbách, a protože se blíží další, pro nás důležité parlamentní volby, je čas ho konečně sepsat. Moje hlavní rozčarování neplyne z toho, koho lidi volí (i když to také), ale hlavně z toho, jak málo chodí k volbám. Jsou lidé, kteří se mi přímo chlubili, že k volbám nechodí a jsou na to hrdí. V Toulkách českou minulostí (myslím, že díl 1105) zaznělo: …my si totiž nedovedeme vysvětlit, proč davy nevzdělaných dělníků vycházely do ulic, aby se domohly nikoliv vyšší mzdy, ale volebního práva. Přitom se často střetávaly s orgány státní moci, která v několika případech použila i střelné zbraně. Měla by se nařídit povinnost volit? V některých zemích to funguje. Povinnost se rozděluje na vymáhanou a nevymáhanou. Vymáhaná je například v Lucembursku. Často slýchávám názor, že kdyby bývalo bylo možné volit elektronicky, tak bude účast ve volbách mnohem vyšší. Ovšem v knize o behaviorální ekonomii Freakonomics (první český překlad Špekonomie prý za moc nestál) mají opačný názor. Podle nich existuje ve Švýcarsku a USA silná společenská norma, že spořádaný občan by měl chodit k volbám. A nejsilnějším podnětem není ani tak to, co nám výsledek voleb osobně přinese, ale spíš to, být ve volební místnosti viděn (sousedy, kolegy…). Z čehož mi vychází, že elektronické volby by volební účast výrazně zhoršily. Kniha Hvězdná pěchota je pěkný román z vojenského prostředí a má zajímavou linku, která se týká právě voleb. Možnost volit je tam právo, které ovšem není zadarmo, lidé za něj tvrdě a ochotně platí. Nechám na vašem posouzení, zda se vám to zdá více jako utopie či dystopie, nicméně dovolím si citovat recenzi z www.fantasya.cz Volební právo mají pouze ti, kdo prošli vojenským výcvikem – a ti také mají status plnoprávných občanů. Což však ostatním nebrání žít život podle vlastních představ (většinu obchodu řídí občané bez volebního práva). Vojna je ryze dobrovolná a záleží na „morálu“ každého rekruta (a na jeho schopnostech), zda dokáže výcvik dokončit. Což se podaří málokomu. Můžete se uklidňovat faktem, že při nižší volební účasti roste váha vašeho hlasu. Nicméně hrozí nerovnováha normálního rozložení a snadno může dojít k nějakým extrémům. V komunálních volbách má třeba můj hlas při stoprocentní účasti váhu zhruba 3 ‰, celá naše rodina hlasuje silou 1,6 %. Třeba při 40 % účasti je to už 4 %, což je zajímavé číslo. Při posledních senátních volbách jsem si celkem snadno vybral kandidáta v prvním kole. Bohužel nepostoupil do kola druhého. Tam se dostali Mládek (ČSSD) a Větrovský (nezávislý za ANO). Pro mě obě nesympatické a na první pohled nepřijatelné možnosti. Celý týden jsem nad volbou přemýšlel. Přesto jsem byl přesvědčený, že k volbám určitě půjdu a že jako nejhorší variantu a důkaz mé nerozhodnosti vhodím prázdnou obálku. Poslechl jsem si rozhovory na Českém rozhlasu a zhlédl duel na DVTV. Nakonec se Větrovský ukázal jako dobrá volba, protože mimo jiné vrátil okleštění zákona o registru smluv. Saša Mitrofanov psal o cestě z poddanství zase zpátky . Všeobecné, rovné a přímé volební právo se zavedlo, aby se méně vzdělaní občané vymanili z područí bohatých a bezohledných pánů. Dnes právě tito občané utíkají zpět do onoho područí a táhnou tam všechny. Karel Hvížďala psal, že Němci chtějí stabilitu, zato Češi se mstí vládě Většina lidí není sama zodpovědná za svůj osud, je závislá na státu či na velkopodnikatelích, a proto její příklon k různým politickým subjektům je rozkolísaný podle momentální s[...]



Nechte kouzlo zmizet

Mon, 18 Sep 2017 00:00:00 +0000

Robert C. Martin (Uncle Bob) svolil k překladu svého článku Make the Magic go away (z roku 2015). Díval jsem se na rxJava. Jde o pěkný malý framework, který pomáhá vytvářet a spravovat observery. Zdá se, že filozofií návrhu je, že vše může být pozorováno, vše tudíž může být spravováno callbacky. To je samozřejmě velmi stará myšlenka, které se datuje už pro data flow jazyky, funkcionální a jiné deklarativní jazyky. Tato myšlenka měla dokonze dozvuk v pozdních 90. letech, kdy byla poprvé vydána kniha GOF. Ti z vás, kteří v té době programovali, si možná pamatujete, že několik měsíců si každý myslel, že návrhový vzor observer je tak úžasný. Viděli jsme mnoho špatných návrhů postavených nad observerem. Pak se to zastavilo, protože takový návrh byl příliš nepřímý. Kód bylo obtížné debugovat. (Testoval to někdo?) Neříkám, že rxJava je špatný nápad. Jak říkám, vypadá celkem pěkně. Jen že to není úplně nová myšlenka. Ostatně co je? Nekonečný úkol Autoři rxJava, Spring, JSF, JPA, Struts a [dosaďte svůj oblíbený framework] všichni hledají stejnou věc. Tyto fameworky vznikly kvůli frustraci z jazyka a jsou pokusem daný jazyk zlepšit. Každý framework, který jste viděli, je ve skutečnosti jen ozvěnou výroku: Můj jazyk stojí za starou belu! A tak píšeme frameworky, abychom kompenzovali vlastnosti, které bychom si přáli mít v našem jazyce. A když to nezafunguje, tak, jako James Gosling, Bjarne Stroustrup, Alan Kay, Brad Cox, Dennis Ritchie, Rich Hickey a mnoho mnoho dalších, píšeme nový jazyk. Nový jazyky! Zlatý! Čistý! Perfektní! Nový jazyk vyřeší všechny nedostatky. Nový jazyk, který nahradí všechny ostatní. Nový jazyk, který odpoví na všechny stížnosti, vyřeší všechny slabiny a urovná veškeré spory. Nový jazyk, kterým se lze snadno vyjádřit, je bezpečný, úsporný, hutný, pružný, disciplinovaný a a a — perfektní! Bzzz! Špatná odpověď! Samozřejmě že taková bestie neexistuje. Není perfektního jazyka. A v neposlední řadě, všechny „nové“ jazyky už tu byly, jsou to jen předělávky té samé staré … té samé staré … té samého staré věci. Upřímně si nemyslím, že by od pozdních 70. a raných 80. let vznikla nová myšlenka v programovacích jazycích. Myslím tím, že pokud jste jednou programovali v Assembler, FORTRAN, C, Pascal, C++, Smalltalk, Lisp, Prolog, Erlang a Forth, tak jste je viděli všechny. Ach, předpokládám, že byste mohli nadhodit jazyky jako Snobol, ML, Cobol, and XSLT (chce se mi zvracet). Ale většina jejich myšlenek již byla pokryta předchozím seznamem. To samé platí pro frameworky. Kdy jste naposledy viděli framework s opravdu novou myšlenkou? Pro mě to byl framework Inside Macintosh napsaný v Pascalu v pozdních 70. a raných 80. letech. A to ve skutečnosti bylo jen předělání o pár let staršího Smalltalk frameworku. Co je nového v software? Za posledních třicet let celkem nic. Santayanova kletba Tak proč pokračujeme ve psaní nových jazyků a frameworků? Myslím, že odpověď je velmi snadná: Ti, kdo si nepamatují minulost, jsou odsouzeni k tomu ji opakovat. Jorge Agustin Nicolas Ruiz de Santayana y Borras Jinými slovy, každá nová skupina programátorů, která přijde, je předurčena (odsouzena!) k tomu, přepsat ty samé staré jazyky a ty samé staré frameworky. Hm, budou vypadat trochu jinak a budou nepatrně jinak natočené, ale nebudou nové v ničem smysluplném. Některé z těchto jazyků a frameworků získají jistou nechvalnou proslulost a stanou se na chvíli populární, jako kdyby byly něco nového a kouzelného, ale to bude jen iluze způsobená pohledem z krátkodobého hlediska. Zastánci těchto „nových“ jazyků a frameworků budou hlasitě[...]



Energetická náročnost rodinného domu

Thu, 31 Aug 2017 00:00:00 +0000

Jedna věc je dům postavit a druhá zaplatit. A to nejen hypotéku, ale i energie. Máte představu, kolik stojí vaše domácnost na energiích? Já si vše každý měsíc zapisuju. Pokusil jsem se z čísel něco spočítat. Pokud právě uvažujete o vlastním bydlení a propočítáváte návratnost investice nebo se jen chcete porovnat, jak umíte hospodařit, tak by vás to mohlo zajímat, Situace Žijeme v pětičlenné domácnosti s dětmi předškolního věku. Jedná se o novostavbu rodinného domu z pálené cihly Porotherm 42,5 T Profi v poměrně chladné oblasti na pomezí České Sibiře a Vysočiny, navíc v údolí, které funguje jako mrazová kotlina. Dům má v obýváku velkou prosklenou plochu, která může čísla výrazně ovlivňovat. Bydlíme v něm již třetím rokem, ale spotřebu vezmu za posledních dvanáct měsíců, jelikož v počátku stavba zraje a člověk se s domem teprve sžívá. Plyn Plynem topíme, ohříváme vodu a vaříme. Naše celková roční spotřeba je 1200 m3 (12,7 MWh). Tady už začíná čarování s čísly. Na plynoměru totiž máte metry kubické, ale nás zajímají kilowatthodiny nebo rovnou cena. Přepočet je zajímavý, ale složitý, bere totiž v potaz vliv tlaku a teploty, objemový koeficient a spalné teplo. Nicméně přibližný přepočet je 1 m3 ~ 15 Kč, 1 kWh ~ 1,46 Kč, 1 m3~ 10 kWh. Z grafu je patrné, že plyn se spotřebovává i v létě, zhruba 50 m3 měsíčně. Spotřeba vaření se udává přibližně 10 m3 za měsíc, zbytek je tedy ohřev vody, ten jsme letos doplnili o solární panely (čísla a výpočty návratnosti dodám za rok). Na topení zbývá 600 m3, tedy 9 tisíc korun za rok. Ohřev vody je zatížen ztrátami z oběhového čerpadla. To zajišťuje cirkulaci teplé vody, která sice není nepřetržitá, ale i tak vede k vychládání vody v potrubí. Cirkulace zajišťuje pohodlí, jelikož otočíte kohoutkem a okamžitě teče teplá voda. Nemusím před sprchováním odtáčet litry vody, než se konečně dočkám teplé. Máme kondenzační kotel s koaxiálním komínem (spaliny předehřívají nasávaný vzduch). Dnes jsou kotle programovány na pokud možno nepřetržitý provoz, jelikož neustále zhasínání a zapalování má velkou spotřebu. Pomáhá takzvaná ekvitermní křivka. Kotel ví, jaká je venkovní teplota a podle toho upravuje svůj výkon, jelikož počítá se spádem tepla. Funguje to dobře, jen si na začátku trochu pohrajete s křivkou, aby odpovídala vašemu domu. To znamená, abyste neměli přetopeno, když je venku teplo, a naopak když je zima, aby vám bylo dostatečně teplo. Kotel pochopitelně bere data i z prostorového čidla v domě. Ovšem navíc porovnává teplotu vody, kterou vypouští do systému, s teplotou vody, která se mu vrací. V domě je kombinace podlahového vytápění a radiátorů s termostatickými hlavicemi. S tepelnou pohodou jsem naprosto spokojen. Rozhodně se nestalo to, že by v nějaké části byla zima nebo přetopeno. Jediné úskalí venkovního čidla a ekvitermní křivky bylo to, když začalo měřit nesmysly (asi o deset stupňů tepleji, než bylo ve skutečnosti). V domě začalo být chladno. Čidlo je umístěné u skladu s dřevem, tak jsem ho musel odkrýt. Změnu teploty způsobilo nejspíš myší hnízdo nebo tlející dřevo. Zajímavé je, že venkovní teplota nemá na spotřebu příliš velký vliv (třeba jestli je venku -3 °C nebo -10 °C). Co ovšem zvyšuje spotřebu hodně, je vítr, který dům výrazně ochlazuje. V mém případě ovlivňuje i tepelnou pohodu, jelikož je ekvitermní čidlo v závětří, tudíž se neochlazuje tolik jako návětrná strana. Ale nedá se nic dělat, čidlo totiž nesmí být ani na přímém slunci, takže lepší místo ani nenajdu. Krb Pořídili js[...]



Pull request verifier

Mon, 31 Jul 2017 00:00:00 +0000

Koukám, že už je to čtyři roky, co jsem se tu zamýšlel nad tím, že mi chybí code review. Od té doby jsem se já i náš obor trochu posunuli. Se Softwarovým Samurajem jsme používali branch-by-feature (i když už pak nedopsal, že jsme to později vylepšili o plugin hg-flow). K dokonalosti chybělo pár drobností. Dost věcí z code review checklistu jsme kontrolovali manuálně, jako například formátování, pokrytí testy či postřehy, které by odhalila statická analýza kódu (PMD, FindBugs…). Je to otravné a vyčerpávající, takže už se tolik nesoustředíte na věci jako design, logování atd. Navíc build běžel až nad develop větví, takže se mohlo stát, že jste sice krásně schválili pull request, ale ten po zamergování shodil build. Jak to vylepšit? Jenkins a BitBucket Pro Jenkins existuje Bitbucket Pull Request Builder Plugin. Díky němu si můžete nastavit build, který se spustí nad každým pull requestem v Bitbucketu. Rovněž zkontroluje statickou analýzu kódu (pokrytí testy, PMD, FindBugs, Checkstyle a duplicity kódu), jejíž konfigurací se teď zabývat nebudu. Pokud jsou všechna pravidla splněna, tak pak pull request jako jakýkoliv jiný reviewer schválí. Schválený pull request v Bitbucketu Konfigurace Používáte-li feature branche ve tvaru feature/bitcoint-payment, tak nastavíte masku na */${sourceBranch}. Vhodné je zapnout volbu Cancel outdated jobs, která zajistí to, že nový commit zruší již běžící build nad danou větví (zbytečně se tak nezatěžuje server). Může se stát, že build selže, přestože je kód v pořádku, třeba kvůli chybějící závislosti v maven repository. V takovém případě do komentáře pull requestu v Bitbucketu napíšete to, co je nakonfigurované v Comment phrase to trigger build a build se spustí znovu. V našem případě je to. test this please U statické analýzy můžete nastavit práh (počet porušení pravidel), kdy má build selhat (červený) či se má označit za nestabilní (žlutý). V ideálním případě by to měla být nula, ale to se ne vždy daří. Buď máte pravidla, která nedodržujete, a pak by stálo za to je zrevidovat, nebo pracujete s legacy kódem, který sice zlepšujete, ale po malých krůčcích. Jenkins porovnává počet nových chyb vůči předchozímu buildu, což nemusí vždy být ta samá feature branch. V takovém případě se může stát, že opravíte jednu chybu, ovšem zavlečete jinou, přesto čísla zůstanou stejná. A to mi přijde škoda. Nastavení prahu pro Checkstyle Jako vylepšení můžete nakonfigurovat, že se má Jenkins před buildem pokusit o lokální merge, který se nedostane do remote repository. To pomůže zavčasu odhalit nekonzistenci mezi zdrojovou a cílovou větví. Plugin nemá podporu webhook, takže se build spouští přes klasický cron trigger (aktivní čekání). Existuje Violation Comments to Bitbucket Server Plugin, který umí vkládat komentáře do pull requestu přímo ke kódu, ale funguje jen pro standalone Bitbucket Server. Nicméně dá se žít i bez něj, prostě se prokliknete na daný build a chyby si dohledáte na Jenkinsu. Jenkins a GitHub Pochopitelně se někteří budou ptát, jak je to s podporou GitHubu. Osobně nemám vyzkoušené, ale očekávám, že postup bude analogický. Podělte se o své zkušenosti v komentáři pod článkem. Můžete se podívat třeba na GitHub pull request builder plugin Pár poznámek k Gitu Pokud používáte feature branche, určitě jste v historii Gitu viděli spoustu čar, kterým mnozí říkají „nádraží“, a někdy není přehledné zjistit odkud kam vedou. Osobně rád často commituju svoje meziřešení, abych měl stabilní kroky, ke kterým se můžu vracet, čímž čáry prodlužuju. Pro pot[...]