-
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.
-
Refaktorování nepatří do backlogu
Z některého kódu se mi dělá fyzicky nevolno a mám chuť ho od začátku přepsat, což by se rozhodně dělat nemělo. Další nápad je, přidat refaktorování do backlogu, ale tam nepatří. Ron Jeffries to vysvětluje v článku Refactoring – Not on the backlog! Článek jsem s laskavým svolením autora přeložil do češtiny.
30. července 2014
V nedávné době se objevilo hodně otázek na konferencích a v e-mailových diskusích ohledně toho, zda dávat refaktorovací story do backlogu. I kdyby technický dluh vyrostl, tak to nic nemění na tom, že je to hrozná myšlenka. Vysvětlení proč:
Na začátku projektu je kód čistý. Pole je posekané, život krásný a svět náš. Všechno půjde hladce.
-
Mockování a úskalí času v Javě 8
Adaptace nových verzí Javy jde pomalu. Dodnes vídám, že programátoři neumí či nechtějí používat multi catch, try-with-resources a diamond operátor. Jak chtít složitější posun, který přináší Java 8?
Ovšem sám nejsem bez viny. Java 8 už je tu víc jak dva roky. Při jejím uvedení jsem psal, jak obstojí v Akumulátor testu, ale na projektech ji naplno nevyužíváme. Rozhodl jsem se to napravit tím, že začnu používat java.time.* místo java.util.Date. Jednak kvůli API a taky proto, že jsou nové třídy immutable. Chtěl bych se podělit o to, jak jsem se při tom nachytal.
subscribe via RSS