• 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.

  • 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ásle­dujících řádcích podělím o své zkuše­nosti a podám zprávu o stavu IT trhu. Líčení je to značně subjek­tivní, zúžené na svět Javy, ale dost možná platí i pro vás.

subscribe via RSS