• Pull request verifier

    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 Softwa­rový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 dokona­losti chybělo pár drobností. Dost věcí z code review checklistu jsme kontro­lo­vali 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čer­pávající, takže už se tolik nesou­stř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?

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

    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ředs­ta­vili myšlenku OOP (objek­tově orien­to­vané progra­mová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.

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

    Překlad článku Painless Functional Speci­ca­tions – Part 4: Tips, jednoho ze série článků o psaní speci­fi­kace, který napsal Joel Spolsky (mimo jiné spolu­autor stackoverflow.com) již v roce 2000 a až na pár technic­ký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).

  • Statický web s Jekyll

    Tento blog píšu už nějakých deset let. Tenkrát sice už existoval WordP­ress, 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 nehac­knul (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 static­ký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 genero­vaný pomocí Jekyll a hosto­vaný na CDN Netlify.

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

    V code review jsem připomín­koval stořád­kovou 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é?“

  • Monitoring

    U zákaz­níka jsme měli nasazené řešení (sestávající se z několika málo desítek kompo­nent), ke kterému jsme posky­to­vali second level support. Selhání byť jediné kompo­nenty mohlo způsobit zasta­vení celé produkce. Identi­fi­kace toho, která kompo­nenta zapříč­i­nila výpadek, bylo zbytečně zdlou­havé. Nehledě k tomu, že jsme nedokázali problémy dosta­teč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 monitorin­gem. Nepovažuji se v dané proble­ma­tice za odbor­níka (podle kompe­tenční matice bych to viděl tak na n2), ale minimálně si chci napsat pár poznámek pro sebe, abych vše nezapom­něl. Měl jsem zahrnout monito­rování do Joel Test 2.0, protože si dnes už nedokážu předs­tavit provo­zovat komplexní systém bez monitoringu.

    Chci se nejprve obecně věnovat proble­ma­tice monitoringu a pak konkrétní imple­men­taci a to Nagios, respek­tive Eyes of Network, které nad Nagiosem staví.

  • Kódující architekt

    Napsal jsem a přeložil několik článků o stárnutí programátorů a změně jejich pozice. Završím to pohledem na kódujícího archi­tekta. Zatímco v článku Technický lídr si zoufám, že jednou z nejtěžších voleb technické hvězdy, ze které se stává lídr, je ztráta kontaktu s nejnovější technologií, tak kniha Software Archi­tec­ture for Develo­pers (Simon Brown) mi dává určitou naději. Podle autora je softwa­rový archi­tekt technická kariéra.

  • Aby test neselhal na první­ assert (JUnit 5)

    Už jsem psal o tom, jak v JUnit 4 dosáh­nout toho, aby test neselhal na první assert. JUnit 5 již dosáhl miles­tone 2 (podrob­nosti v článku JUnit 5 State Of The Union), tak je potřeba se podívat, jak s novou verzí API dosáh­nout téhož.

    Jsem zastáncem toho, aby jednot­livé testy byly co nejkratší a samozřejmě na sobě nezávislé. Raději napíšu deset testo­vacích metod s jedním asser­tem, než jednu metodu s deseti asserty. Výhodu spatřuji v tom, že při jediném běhu testu vidíte na jediný pohled všechny vadné případy. A ne že opravíte první assert, spustíte test a padne vám hned druhý assert v pořadí.

    Jiné je to v případě integ­rač­ních testů, například Selenium (WebD­ri­ver). Samotná příprava dat je náročná, takže je vhodné asserty sdružovat do větších celků. Ale jak z jediného běhu získat co nejvíce infor­mací, aniž byste museli test znovu a znovu opakovat?

  • Bus faktor v praxi

    Bus faktor je číslo, které říká, kolik lidí by muselo odejít, aby to vážně ohrozilo projekt. Nejhorší číslo je 1. Z pohledu manažerů, by bylo skvělé, kdyby lidé byli snadno zaměni­telní jako součástky stroje. My si někdy můžeme nafou­kaně myslet, že jsme takřka nepostra­da­telní (i když jako manažer, bych se snažil takových lidí zbavit). Pravdou je, že každý je nahra­di­telný. Otázkou je, za jakou cenu.

    Slyšel jsem příběh, u kterého jsem osobně nebyl, ale byla by škoda ho neposlat dál. Nejspíš jde o urban legend, takže jakákoliv podob­nost s vaší firmou je čistě náhodná.

  • Nečitelný příběh Marie Navarové

    Případ Marie Navarové, poslední kniha Arnošta Lustiga, vznikla na základě článku PhDr. Ericha Rennera. Je to příběh hodný Shakes­peara, ale mistr ho psal asi jen tak na okraj. Ostatně to v rozhovoru, jakkoliv žertovně, přiznává (vzal zálohu a neměl, co psát). Chtěl jsem si tedy přečíst původní článek (Neči­telný příběh Marie Navarové), který byl knize předlo­hou. Bohužel vyšel pouze v regionálním tisku. S laskavým svolením autora jsem text převedl do elekt­ro­nické podoby a tímto posky­tuji ve formátech pdf, ePub i mobi. Poděkování patří rovněž Martinu Javorkovi, který po mně sazbu četl.

subscribe via RSS