-
Nechte kouzlo zmizet
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?
-
Energetická náročnost rodinného domu
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,
-
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 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?
-
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ř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.
-
Funkční specifikace bezbolestně – Část čtvrtá: tipy
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).
-
Statický web s Jekyll
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.
-
Pravidlo 30 – kdy jsou metoda, třída nebo subsystém příliš velké
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é?“
-
Monitoring
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í.
-
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 architekta. 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 Architecture for Developers (Simon Brown) mi dává určitou naději. Podle autora je softwarový architekt technická kariéra.
-
Aby test neselhal na první assert (JUnit 5)
Už jsem psal o tom, jak v JUnit 4 dosáhnout toho, aby test neselhal na první assert. JUnit 5 již dosáhl milestone 2 (podrobnosti v článku JUnit 5 State Of The Union), tak je potřeba se podívat, jak s novou verzí API dosáhnout téhož.
Jsem zastáncem toho, aby jednotlivé testy byly co nejkratší a samozřejmě na sobě nezávislé. Raději napíšu deset testovacích metod s jedním assertem, 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ě integračních testů, například Selenium (WebDriver). 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 informací, aniž byste museli test znovu a znovu opakovat?
subscribe via RSS
