Chcete začít se společným čtením v práci a nevíte, jakou knihu zvolit jako první? Doporučuji 97 Things Every Software Architect Should Know.

Za svojí dosavadní pracovní kariéru jsem prošel společnostmi různých velikostí. Od začínajících firmiček o pěti, dvaceti lidech, přes stabilní s padesáti až dvě stě pracovníky, až po molochy s jednotkami a desítkami tisíc zaměstnanců. Každá velikost firmy vyžaduje jiný druh řízení (o tom mluvit nechci) a jiný způsob sdílení informací. Zatímco v…

Moje zkušenosti z toho, jak jsem začal s kroužkem programování.

JPA, metoda toString() a asynchronní logování dokázaly vykouzlit situaci, která nám dala chvilku zabrat.

Návod na programovací úlohu železniční přejezd s Meet Edison.

Jaký byl polský Devoxx 2018?

Překlad článku Starbucks Does Not Use Two-Phase Commit od Gregor Hohpe.

Cílem aktivity je společně vybrat jednu knihu, kterou si každý doma sám přečte. Následně se sejdeme a o knize diskutujeme. Čteme zhruba 100 stran měsíčně, o kterých pak asi hodinu a půl diskutujeme.

Z několika junior kandidátů jsem byl bohužel zklamaný. Myslím, že by mé poznámky mohly některým pomoct s přípra­vou. Mohli by lépe využít svého poten­ciálu, abych je příště nemusel odmítnout.

Jaká byla akce Hour of Code s LightBot a Meet Edison.

Letos jsem se konečně vypravil na jOpenS­pace 2017a bylo to naprosto skvělé. Sepsal jsem si pro sebe pár poznámek, které můžete brát i jako lákadlo na příští jubilejní ročník.

Překlad článku od autora Robert C. Martin, Make the Magic go away. Každý framework, který jste viděli, je ve skuteč­nosti jen ozvěnou výroku: Můj jazyk stojí za starou belu!

Pro Jenkins existuje Bitbucket Pull Request Builder Plugin. Díky němu si můžete nastavit build, který se spustí nad každým pull requestem v Bitbuc­ketu. Rovněž zkont­ro­luje statickou analýzu kódu (pokrytí testy, PMD, FindBugs, Check­s­tyle a dupli­city kódu), jejíž konfi­gu­rací se teď zabývat nebudu. Pokud jsou všechna pravidla splněna, tak…

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.

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 […]

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é?“

Velkou část minulého roku jsem strávil s monitoringem. Nepovažuji se v dané problematice za odborníka, ale minimálně si chci napsat pár poznámek pro sebe, abych vše nezapomněl. Dnes si 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…

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)…