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: Tue, 24 Oct 2017 21:02:17 +0000

Last Build Date: Tue, 24 Oct 2017 21:02:17 +0000

 



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í: Computer Science Unplugged, Micro:bit či PRIM. Myslím, že jsme se dost vyhecovali, tak snad se mi podaří něco p[...]



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í situace. Nevybírají nejpřijatelnější možnost, ale mstí se vládě za to, že si nesplnili své sny o 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ě prohlašovat, jak moc rychleji můžete programovat, jak snadněji můžete postavit systém a jak lépe jso[...]



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 jsem si i krb. Architekti říkají, že jsme jedni z mála, kdo ho chtěl, a nakonec v něm doopravdy topí. P[...]



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řeby code review to nevadí, ale před finálním mergem do develop větve takzvaně squashnu: sloučím vš[...]



Proč stojí objektové programování za starou belu

Mon, 26 Jun 2017 00:00:00 +0000

Překlad článku Why OO Sucks, který napsal Joe Armstrong. S jeho laskavým svolením jsem text přeložil do češtiny (překlad uvolňuji pod licencí Creative Commons by-nc-sa). Když mi poprvé představili myšlenku OOP (objektově orientované programování), tak jsem byl skeptický, ale nevěděl jsem proč. Prostě jsem jen cítil, že je to špatně. OOP se stalo velmi populárním (později vysvětlím proč) a jeho kritika byla něco jako klení v kostele. OOP se stalo něčím, co každý slušný jazyk musel mít. Jak se Erlang stával populárnějším, ptali se nás: „Je Erlang objektově orientovaný?“ Pochopitelně správná odpověď byla: „Samozřejmě, že ne!“, ale neříkali jsem to nahlas. Takže jsme vymysleli důmyslnou odpověď, která měla zanechat dojem, že Erlang je (tak trochu) objektově orientovaný (když budete hodně mávat rukama) ale ne doopravdy (pokud jste poslouchali, co jsme ve skutečnosti říkali, a pečlivě četli drobné písmo). Vzpomínám si na úvodní přednášku, kterou tehdy měl ředitel francouzské IBM na sedmém ročníku konference IEEE Logic programming v Paříži. IBM prolog přidal spoustu objektově orientovaných rozšíření. Na moji otázku proč, odpověděl: Naši zákazníci chtěli objektově orientovaný prolog, tak jsme udělali objektově orientovaný prolog. Jak snadné, bez výčitek svědomí, bez sebezpytování, bez ptaní se: „Je to správná věc?“ Proč stojí objektové programování za starou belu Moje zásadní námitky k OOP se týkají základních myšlenek. Některé z nich vyjmenuji a přidám k nim svoje námitky. Námitka 1 - Datové struktury a funkce by se neměly míchat Objekty svazují funkce a datové struktury v nedělitelné jednotky. Domnívám se, že jde o základní chybu, protože datové struktury a funkce patří do úplně odlišných světů. Proč? Funkce něco dělají. Mají vstupy a výstupy. Tyto vstupy a výstupy jsou datové struktury, které jsou modifikované funkcemi. Ve většině jazycích jsou funkce vytvořeny sekvencí imperativů: „Udělej tohle a pak tohle…“ Abyste porozuměli funkcím, musíte porozumět pořadí, v jakém věci vykonají. Datové struktury prostě jsou. Nedělají vůbec nic. Jsou ve své podstatě deklarativní. Porozumění datové struktuře je mnohem snazší než porozumění funkci. Funkce jsou vnímány jako černé skříňky, které transformují vstup do výstupu. Jestliže rozumím vstupu a výstupu, tak rozumím funkci. To ovšem neznamená, že zvládnu funkci napsat. Funkcím obvykle porozumíme pozorováním, že jsou věcmi v počítačovém systému, jejichž úkolem je transformovat datové struktury typu T1 do datové struktury typu T2. Jelikož jsou funkce a datové struktury úplně odlišné živočišné druhy, je zásadní chybou zamykat je do jedné klece. Námitka 2 - Všechno musí být objekt Vezměme si čas. V OOP jazycích musí čas být objekt. Ale v ne-OOP jazycích je čas instancí datového typu. Například v Erlangu je mnoho různých variant času, který může být jasně a jednoznačně specifikovaný následujícím způsobem: -deftype day() = 1..31. -deftype month() = 1..12. -deftype year() = int(). -deftype hour() = 1..24. -deftype minute() = 1..60. -deftype second() = 1..60. -deftype abstime() = {abstime, year(), month(), day(), hour(), min(), sec()}. -deftype hms() = {hms, hour(), min(), sec()}. ... Všimněte si, že tyto definice nepatří žádnému konkrétnímu objektu. Jsou všudypřítomné a datové struktury reprezentující čas můžou být zpracovány jakoukoliv funkcí v systému. Neexistují žádné související metody. Námitka 3 - V OOP jsou definice datových typů rozprostřené úplně všude V OOP patří definice datových typů objektům, takže nemůžu najít všechny definice datových typů na jednom místě. [...]



Funkční specifikace bezbolestně – Část čtvrtá: tipy

Mon, 29 May 2017 00:00:00 +0000

Překlad článku Painless Functional Specications – Part 4: Tips, jednoho ze série článků o psaní specifikace, který napsal Joel Spolsky (mimo jiné spoluautor stackoverflow.com) již v roce 2000 a až na pár technických nástrojů jako kdyby ho psal dneska. S jeho laskavým svolením jsem text přeložil do češtiny (překlad uvolňuji pod licencí Creative Commons by-nc-sa). 15. října 2000 Dobrá, mluvili jsme o tom proč potřebujete specifikaci, co specifikace obsahuje a kdo by ji měl psát. Ve čtvrtém a posledním dílu této série se s vámi podělím o některé své rady, jak psát dobrou specifikaci. Největší stížnost, kterou slýchávám od týmů píšící specifikaci, je, že nikdo specifikace nečte. Když nikdo nečte specifikace, tak lidé, kteří je píší, mají sklon být trochu cyničtí. Je to jako starý Dilbert komiks, ve kterém inženýři použili deset centimetrů tlustý štos specifikace pro přestavění své kancelářské kóje. Ve vaší typické velké a byrokratické firmě každý tráví měsíce psaním nudné specifikace. Jakmile je specifikace hotová, uloží se na polici a už se nikdy nesundá. Produkt je implementován od píky a bez ohledu na to, co je napsané ve specifikaci, protože nikdo specifikaci nečetl, jelikož je tak ubíjející. Samotný proces psaní specifikace mohl být dobré cvičení, protože to alespoň každého přinutilo nad věcí se zamyslet. Ale fakt, že specifikace leží na polici (nepřečtená a nemilovaná), dává lidem pocit, že to bylo k ničemu. Jakmile bude produkt doručen, dostanete se do mnoha sporů kvůli tomu, že vaše specifikace nebyla nikdy čtená. Někdo (management, marketing nebo zákazník) řekne: „Počkejte! Slíbili jste mi, že tam bude pařáček na mušle! Kde je pařáček na mušle?“ A programátoři řeknou: „Ne. Když se podíváte do specifikace do kapitoly 3, podkapitoly 2.3.0.1, uvidíte, že říká celkem jasně ‚žádný pařáček na mušle.‘“ To ale neuspokojí zákazníka, který má vždycky pravdu, takže nevrlí programátoři to musí dovybavit pařáčkem na mušle (což je učiní ještě cyničtější ohledně specifikací). Nebo manažer řekne: „Hele, všechna ta slova v tomhle dialog boxu, to je moc ukecané. Nad každým by měl být nadpis.“ A frustrovaní programátoři řeknou: „Ale ty jsi schválil specifikaci s přesným obsahem a rozvržením každého dialog boxu!“ Ale manažer samozřejmě specifikaci nečetl, protože když se pokusil, jeho mozek začal unikat skrz oční důlky a stejně to kolidovalo s jeho úterním golfem. Takže specifikace jsou dobré, ale nikdo je nečte. Jako autor specifikace musíte lidi přimět, aby vaše věci četli. Pravděpodobně byste se měli snažit nezpůsobit to, aby už tak malý mozek unikl skrz oční důlky. Přimět lidi, aby četli vaše věci, je obvykle jen otázkou dobrého psaní. Ale nebylo by ode mě fér říct jen: „buďte dobrými spisovateli,“ a nechat to tak. Zde jsou čtyři jednoduchá pravidla, která musíte následovat, abyste vytvořili specifikaci, která je čtena. Pravidlo 1: Buďte vtipní Jo, pravidlo číslo jedna. Abyste přiměli lidi číst vaši specifikaci, je nutné udělat z toho zážitek. Neříkejte mi, že jste se narodili nudní. To neberu. Každý má neustále zábavné nápady, jen je vyřadíme autocenzurou, protože máme za to, že jsou „neprofesionální“. Pche. Občas musíte porušit pravidla. Pokud jste četli tu spoustu smetí, které jsem na tomto webu napsal, jistě jste si všimli několika roztroušených chabých pokusů o vtip. Čtyři odstavce zpět jsem vtipkoval na tekutost těla a utahoval si z manažerů za hraní golfu. Ačkoliv ve skutečnosti nejsem tak vtipný, přesto se snažím být zábavný ve stylu smutného klauna. Píšete-li specifikaci, tak vhodné[...]



Statický web s Jekyll

Mon, 24 Apr 2017 00:00:00 +0000

Tento blog píšu už nějakých deset let. Tenkrát sice už existoval WordPress, ale z nějakého důvodu jsem zvolil redakční systém Nucleus, který už je dnes úplně mrtvý. Divím se, že mi za ta léta blog nikdo nehacknul (nebo o tom alespoň nevím). S příchodem Let’s Encrypt jsem si říkal, že by kovářova kobyla nemusela chodit bosa a že bych taky mohl přejít na https, ale nechtělo se mi šťourat v PHP. Jednou jsem narazil na deset nejlepších statických generátorů stránek, na nějakou dobu jsem si odkaz založil a nakonec se rozhodl do toho říznout. Takže tento blog je dnes staticky generovaný pomocí Jekyll a hostovaný na CDN Netlify. Už dříve si lidé (a Google) stěžovali, že se moje stránky nedají moc číst na mobilu, tak jsem se na začátek spustil audit Testmysite.io a výsledky nebyly vůbec lichotivé, vlastně byly dost tristní. Stav před Jekyll První weby byly statické. Mně z dynamičnosti neplynula žádná výhoda. Web to zpomalovalo a hrozilo mi bezpečnostní riziko. Podrobněji vše rozebírá článek Why Static Website Generators Are The Next Big Thing. Zbývalo vybrat generátor statických stránek a nejsympatičtější mi přišel Jekyll. Při migraci se potvrdilo, že to byla dobrá volba. Dobrá dokumentace, fungující komunita a ani Ruby pro mě nebylo překážkou. Netlify Již zmiňovaný článek srovnávající deset nejlepších statických generátorů stránek byl na stránkách Netlify, poskytovatele CDN (Content delivery network), který se mi zalíbil. Navíc se vejdu do programu zdarma. Jistě se ptáte, proč jsem nezvolil GitHub Pages. Ty totiž nemají způsob, jak konfigurovat 301 redirect. Dalo by se to možná obejít pluginem pro http refresh, ale to mi nepřišlo tak elegantní, systémové a ani se mi nechtělo zkoušet, jak se k tomu staví vyhledávače. Výrazné zlepšení připisuji i HTTP/2, pro jehož nastavení jsem nemusel dělat vůbec nic. K problematice doporučuji HTTP/1.1 vs. HTTP/2: A Performance Analysis a pokračování Part 2 - performance. Pluginy Použil jsem následující pluginy jekyll-paginate - stránkování jekyll-gist - vkládá gist jekyll-twitter-plugin - vkládá tweety jekyll-archives - konfigurovatelný archiv, používám kategorie i18n_filter - lokalizuje datum zveřejnění článků jekyll-hyphenate_filter - vkládá dělitelnou mezeru HTTPS Na stránkách jakpsatweb.cz vyšel pěkný článek, jak již fungující stránky převést na protokol https s podrobným návodem. Není to žádná věda, ale přesto se hodí seznam věcí, na co nezapomenout. Jedná se třeba o obrázky z jiných stránek, které musíte také vkládat s https adresou. Vše pak zkontrolujete pomocí nástroje JitBit SSL Check. Na Netlify nakonec jen zaškrtnete, že chcete HTTPS, a je to. Stav poté je mnohem lepší Co mi ještě nefunguje Dělení článků jen pomocí kategorií je možná příliš hrubé a asi by se hodily tagy. Je to jen otázka konfigurace. Mnohem větší výzvou jsou pevné (nedělitelné) mezery. Vzpomněl jsem si, jak jsem sázel bakalářku v LaTexu. Používali jsme program vlna, který do textu nedělitelné mezery vkládal (v syntaxi LaTeXu je to právě vlna, ~). Potřeboval bych vytvořit plugin pro Jekyll, který vkládá nedělitelné mezery podle českých pravidel. Dobrý námět na vedlejší projekt a způsob, jak se naučit Ruby. Poslední věc, kterou jsem ještě nezmigroval, jsou komentáře. U novějších článků už jsem používal Disqus, kde byla migrace snadná (šlo jen o změnu url), ale ty nejstarší mám pouze v databázi. Import se mi zdá příliš komplikovaný až nemožný (jestli to někdo umíte, dejte prosím vědět). Zdrojové kódy Zdrojové kódy blogu jsou k dispozici na GitHubu. Závěr Staticky generovaný web j[...]



Pravidlo 30 – kdy jsou metoda, třída nebo subsystém příliš velké

Thu, 09 Mar 2017 00:00:00 +0000

V code review jsem připomínkoval stořádkovou metodu, která mi přišla příliš dlouhá. Hranice může být otázkou osobního vkusu, tak jsem hledal zdroje, čím bych svůj názor podpořil. Narazil jsem přitom na článek Rule of 30 – When is a method, class or subsystem too big?, který napsal Jim Bird. S laskavým svolením autora jsem článek přeložil. 4. prosince 2012 Lidé, kterým záleží na psaní dobrého kódu, neustále kladou otázku: „Jaká je správná velikost metody, funkce, třídy, balíčku nebo jiného kusu kódu? Od určité chvíle může být kód příliš velký na to pořádně ho pochopit – ale jak velké je příliš velké?“ Začíná to na úrovni metody nebo funkce. V knize Code Complete Steve McConnell říká, že teoreticky nejlepší maximální limit pro metodu nebo funkci je počet řádek, které se vejdou na obrazovku (tj. co vývojář může vidět najednou). Jmenuje studie z 80. a 90. let, podle kterých je ideální velikost funkce mezi 65 a 200 řádky. Takhle velké funkce je levnější vyvinout a mají méně chyb na řádek kódu. Nicméně od určitého místa za 200 řádky vstupujete do nebezpečné zóny, kde kvalita a porozumění kódu bude upadat. Kód, který nelze testovat, nemůže být bezpečně změněn. Případně skončíte u něčeho, čemu Michael Feathers říká „runaway methods“. Funkce jsou dlouhé několik stovek či tisíc řádek, jsou neustále měněny, což je průběžně dělá většími a děsivějšími. Patrick Duboy se ponořil hlouběji do analýzy délky metod a poukázal na novější studii z roku 2002, která říká, že kód s kratšími funkcemi má méně chyb, což odpovídá intuici a zkušenosti většiny lidí. Menší musí být lepší Bob Martin v knize Clean Code dovedl myšlenku „jestli malé je dobré, tak menší musí být lepší“ do extrému. První pravidlo funkcí je, že by měly být malé. Druhé pravidlo funkcí je, že by měly být ještě menší než to. Funkce by neměly být 100 řádek dlouhé. Funkce by měly být stěží 20 řádek dlouhé. Martin přiznává: „Tento předpoklad nemůžu dokázat. Nemůžu citovat žádný výzkum, který říká, že velmi malé funkce jsou nejlepší.“ Takže stejně jako mnoho další pravidel a doporučení v komunitě softwarového vývoje je tento soud založen na jejich osobní zkušenosti s psaním kódu, estetických a etických argumentech, spíše než na těch ověřených experimentem. Styl nad hmotu. Stejný návod „menší je lepší“ platí pro třídy, balíčky a subsystémy – všechny stavební bloky systému. V knize Code Complete je zmíněná studie z roku 1996, která zjistila, že třídy s více funkcemi mají více chyb. Podle knihy Clean Code mají být třídy (stejně jako funkce) rovněž „menší než malé“. Někteří doporučují 200 řádek jako dobrý limit pro třídu (nikoliv metodu) nebo tak málo jako 50 až 60 řádek (Ben Nadel Object Calisthenics). Takové třídy by se měly skládat z „méně než 10“ nebo „ne víc jak 20“ metod. Slavný projekt C3, kde vzniklo extrémní programování, měl v průměru 12 metod na třídu. A nemělo by být víc než 10 tříd na balíček. PMD, nástroj statické analýzy, který pomáhá upozornit na problémy ve struktuře a stylu kódu, definuje nějaké výchozí hodnoty pro velikost kódu: 100 řádek na metodu, 1 000 řádek na třídu a 10 metod na třídu. Podobný nástroj Checkstyle navrhuje odlišné limity: 50 řádek na metodu a 1 500 řádek na třídu. Pravidlo 30 Hledání doporučení jako jsou tato mě přivedlo k „pravidlu 30“ v knize Large Software Projects (Martin Lippert, Stephen Roock). Skládá-li se element z více než 30 subelementů, tak je vysoká pravděpodob[...]



Monitoring

Wed, 22 Feb 2017 00:00:00 +0000

U zákazníka jsme měli nasazené řešení (sestávající se z několika málo desítek komponent), ke kterému jsme poskytovali second level support. Selhání byť jediné komponenty mohlo způsobit zastavení celé produkce. Identifikace toho, která komponenta zapříčinila výpadek, bylo zbytečně zdlouhavé. Nehledě k tomu, že jsme nedokázali problémy dostatečně předvídat. Zákazník zcela logicky začal požadovat monitoring celého řešení. Velkou část minulého roku jsem tak strávil s monitoringem. Nepovažuji se v dané problematice za odborníka (podle kompetenční matice bych to viděl tak na n2), ale minimálně si chci napsat pár poznámek pro sebe, abych vše nezapomněl. Měl jsem zahrnout monitorování do Joel Test 2.0, protože si dnes už nedokážu představit provozovat komplexní systém bez monitoringu. Chci se nejprve obecně věnovat problematice monitoringu a pak konkrétní implementaci a to Nagios, respektive Eyes of Network, které nad Nagiosem staví. Úvod do monitorování Co to je monitoring? Z mého pohledu jde o sledování a hlášení kritických chyb, nebo ještě lépe včasné varování, pokud se nějaká chyba blíží. Mezi základní kritéria si můžete představit volné místo na disku či operační paměti, čas do vypršení certifikátu, ping, telnet… Představivosti se meze nekladou. Mám vyzkoušené, že analýza toho, co monitorovat a jaký nastavit threshold (práh, hranice) zabere mnohem víc času než samotná implementace, která je v podstatě jednoduchá. Platí, že měření by nemělo ovlivnit měření či v lékařské terminologii vyjádřeno primum non nocere (především neškodit). Technologie Job trends na Indeed.com U samotného výběru technologie jsem nebyl, šlo o politické rozhodnutí, ale myslím, že (zpětně viděno) šlo o dobré rozhodnutí. Byla vybrána technologie Eyes Of Network (dále jen EoN) postavená na technologii Nagios, která je de facto průmyslovým standardem. Jedná se o open-source řešení (pod licencí GPL2, se kterou ovšem můžete někde v komerční sféře mít problémy, ale neměli byste, protože k EoN budete nejspíš přistupovat jen jako k black-box). Distribuované jako CentOS image. Projekt sponzoruje firma APX, u které si můžete objednat konzultanty. Jediná nevýhoda je, že je to francouzský kód, takže občas na mě v logu nebo některých návodech vykoukla francouzština. Architektura Eyes of Nework, zdroj: www.eyesofnetwork.com Nagios Pár termínů, se kterými se setkáte v Nagiosu. Host je cokoliv, s čím se domluvíte přes TCP. Service je logická entita, která běží na hostu (pozor, nezaměňovat za windows service). Hard/soft state, zdroj: JBsWiki (cc-by-sa 3.0) Nagios rozlišuje tzv. hard a soft state. Jde o to, že když se zatoulá jeden ping, tak aby vás to zbytečně neděsilo či dokonce nebudilo. Indikuje-li se chyba, výrazně se zkrátí interval kontroly a teprve když se chyba potvrdí, přepne se do hard state. SNMP SNMP (Simple Network Management Protocol) je protokol pro správu sítí, ale my ho můžeme využít i pro monitoring, aniž bychom museli instalovat nějaké agenty (o nich později). Můžete tak monitorovat třeba místo na disku, volnou operační paměť… Potřebujete, aby vám na monitorovaném stroji běžela windows služba SNMP (pokud ne, musíte si featuru přidat). Službu si musíte nastavit. Bude vás zajímat především community name, stačí přístup READ ONLY. Dobré omezit na IP adresu monitorovacího serveru. Ano vím, lze podvrhnout, ale jednak jsme zapnuli READ ONLY režim a jednak doufám, že vaše síť má ochranu proti ARP poisoning. Každopádně vyšší verze SNMP už umí i TLS (nezkoušel jsem). Lokální Pluginy Pro Nagios exis[...]