-
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?
-
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ěnitelní jako součástky stroje. My si někdy můžeme nafoukaně myslet, že jsme takřka nepostradatelní (i když jako manažer, bych se snažil takových lidí zbavit). Pravdou je, že každý je nahraditelný. 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 podobnost 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ý Shakespeara, 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čitelný příběh Marie Navarové), který byl knize předlohou. Bohužel vyšel pouze v regionálním tisku. S laskavým svolením autora jsem text převedl do elektronické podoby a tímto poskytuji ve formátech pdf, ePub i mobi. Poděkování patří rovněž Martinu Javorkovi, který po mně sazbu četl.
-
Zpráva o stavu IT trhu
Po třech letech jsem se rozhodl změnit práci. Oběhal jsem pár firem, máte-li zájem, tak se na následujících řádcích podělím o své zkušenosti a podám zprávu o stavu IT trhu. Líčení je to značně subjektivní, zúžené na svět Javy, ale dost možná platí i pro vás.
subscribe via RSS