čtvrtek 17. července 2014

Jak by dopadl Messi, Levák Bob a Němci v softwarovém vývoji

Právě ukončení Mistrovství Světa ve fotbale 2014 bylo pro fanouška hry odehrávající se v intencích - 22 hráčů, jeden míč, rozhodčí a vítězství Německa - balzámem na duši. Přihrávky, góly, trapasy, nějaký ten faul, nafilmované pády, zavedení video rozhodčího, prostě do kupy hromada emocí, které stálo za to rozebrat s přáteli u piva. Bývalá hvězda anglického fotbalu David Backham se nechala před finále slyšet, že Němci nevyhrají, protože v týmu nemají ani jednu hvězdu erste Klasse. Finálový zápas ukázal, jak dalece se tento pán mýlil. Němci, tím že vyhráli, jenom potvrdili vlastní cestu, kterou se rozhodli jít před deseti lety. Shodou okolností k tomu přispěl ostudný výprask od Českého B-týmu na EURO 2004. Při pročítání denního tisku jsem narazil na podobné vlastnosti popisující charakter a cestu Německého týmu. To mě inspirovalo k zamyšlení nad tím, co jsme mohli poslední čtyři týdny sledovat během Mundialu v Brazílii, a tím s čím se potkáváme v každodenním pracovním životě softwarového vývoje.





Jak je dobré nemít svého Neymara či Messiho nebo Robbena?

Týmy spoléhající na jednu svojí hvězdu, skončily těsně pod vrcholem. V softwarovém inženýrství se tomu říká Bus factor 1. Volná definice by mohla znít: kolik vašich inženýrů musí přejet autobus, aby se váš projekt zhroutil jako domeček z karet. Na pokraji vyčerpání hrající argentinský polobůh Lionel Messi a zraněný brazilský super-hrdina Neymar jasně ukázali, že v kolektivním snažení nemůže rozdíl mezi úspěchem a neúspěchem ležet na jednom člověku. Udělejte si retrospektivu s vaším týmem a zjistěte si, jaký je jeho bus factor. Čím nižší to číslo bude, tím větší problém máte. Němci vyhráli protože žádná z jejich ztrát neměla fatálníma vliv na chod týmu.



Teď trochu odbočím z fotbalového prostředí a přejdu k mému oblíbenému mysliteli Nassimu Talebovi. Ten v knize Antifragile mluví o myšlence, že neustálým vnášením neočekávaných fatálních událostí do systému posilujeme jeho robustnost. Vývojáři z firmy Netflix tuhle myšlenku přenesli do praxe tím, že napsali rodinu nástrojů, která jim zcela náhodně shazuje produkční servery, clustery a dokonce geograficky distribuované farmy. Ty nástroje nejsou nic jiného než deterministické generátory Černých labutí (další Talébova myšlenka, díky Křečáku) - tedy událostí, se kterými systém resp. vývojář nepočítá, jejich výskyt nejde předpovědět, a přitom mají nedozírné následky pro jeho fungování. Zcela programovým vnášením katastrofických chyb se Netflixu daří neustále zlepšovat spolehlivost celého systému.


Výše uvedenými řádky jsem nechtěl rozhodně naznačit, že Argentinci měli zkušebně kopnout Messiho pod koleno, aby svůj tým připravili na hru bez něj. Nenaznačuji tím ani to, abyste nějakého nebohého vývojáře nechali zavřít do ústavu, jenom proto, abyste zjistili, jak hodně na něm váš tým závisí. Fungují i méně invazivní metody. Stačí si porovnat výkonost týmu ve sprintech v závislosti na tom, kdy byli jednotlivý členové na dovolené. Pokud se vám vývoj zastavil, třeba při absenci jedné třetiny vývojového týmu, je z toho patrné, jaký máte bus factor. Jedinou a správnou možností, jak tomuto problému čelit, je budovat tým, kde se dokáží jeho členové zastoupit. Je to složité, pracné, bolí to, ale vyplatí se to. Jediná jistota černého scénáře totiž je, že se někdy naplní.


V bývalém týmu hodně pomohlo, když jednotlivé role rotovaly. Existovala například role Elitního opraváře chyb s týdenní expirací. Vývojář měl v první řadě na starosti odstranění menších chyb, které přicházely z manuálního testování, a které by narušovaly fungování týmu ve sprintu. Ve zbytku času pracoval na vylepšování infrastruktury a dalších úkolech mimo produktový backlog. Ideálně měl pomoci odmazávat technologický dluh. Zastupitelnost člena týmu zodpovědného za produkční nasazení a produkční zásahy jsme budovali vývojem nástroje pro automatizované nasazování změn v produkčním clusteru a nástrojem, který umožňoval provádět operační úkoly přímo týmu zákaznické podpory.


Levák Bob a cargo kult defenziva

Historická a potupná prohra 1:7 Brazílie s Německem v semifinále turnaje odhalila vážné nedostatky kanárků. Říká se tomu cargo cult. Kmeny na Polynéských ostrovech si stavěly napodobeniny letadla a věřily, že se díky tomu vrátí bílý muž, jehož příchod měly historicky spojený právě s příletem nákladního letadla. Brazilci si mysleli, že složením obrany z hráčů hrajících v nejlepších klubech, získají nepropustnou obranu. To že máte v obrané řadě hráče Realu Madrid, Barcelony, Bayernu Mnichov a k tomu Chelsea - to jest absolutně nejlepších mužstev na klubové úrovni - neznamená, že bude vaše obrana fungovat lépe než banda nekopů Jirky Luňáka ze seriálu Okresní přebor. Podobný cargo cult je často vidět při pokusu o agilní vývoj. Napodobování technik jednotlivých agilních metodologií ještě neznamená, že děláte agilní vývoj. Střízlivění Brazilců z cargo cultu jejich defenzívy potrvá dlouho dobu. Pokud se týká agilního vývoje, doporučoval bych pročtení Manifest Agilního vývoje software, abyste si ověřili, jestli jste opravdu agilní a nebo pěstujete cargo cult. Sebepoznání bývá často prvním krokem k nápravě...



Jogiho mantra

Němci se k zlaté sošce Niké nedostali náhodou, nebyl to tým, který by především spoléhal na vrtkavou přízeň štěstěny. Mimochodem byla to jejich pátá medaile v řadě. Na každém Mistrovství Světa nebo Mistrovství Evropy od roku 2006 postoupili minimálně do semifinále. Kromě dodržování propracovaného systému bránění nesvazoval trenér Joachim Löw útočnou činnost žádnými pravidly. Po hráčích chtěl, aby se do útoku zapojovali v co největším počtu. Strávil jsem část své kariéry tím, že jsem dělal věci, které po mě nikdo nechtěl. Nebyly v žádném backlogu, prostě jsem měl pocit, že je správné je v určitou chvíli dělat. Zakutat se do nějakého frameworku, refaktorovat kód, který mi pil krev v žilách, udělat prototyp něčeho co jsem považoval za užitečné. Nežádal jsem o povolení, ale o odpuštění, když to náhodou nevyšlo. Kreativitu není možné nařídit. Je možné pouze vytvořit prostředí, ve kterém pro ní nejsou formální či neformální zábrany. Německy tým dodržoval systém, který byl dostatečně bezpečný, ale zároveň poskytoval hráčům dostatek volnosti, která byla nezbytná pro jejich kreativitu. Každé pracovní prostředí, organizace nebo tým by se měl budovat podle podobné mantry - minimum pravidel zajištujících spolehlivé fungování a dostatek volnosti umožnující rozvoj kreativních schopností.



Fotbal je hra s jednoduchými pravidly a v podání těch nejlepších vypadá jednoduše. Paralela se softwarovým vývojem není čistě náhodná. Věřím, že nejlepší softwarové týmy fungují a mají podobnou charakteristiku jakou měl ten Německý na tomto Mistrovství Světa.

Autor tohoto článku je amatérský hráč fotbalu živící se vývojem softwaru

středa 16. července 2014

Deset let, které neotřásly Spring frameworkem


Dnes jsem náhodou zjistil, že už je to pěkných pár let - konkrétně 10 - co se s touto ctihodnou technologií setkávám. Když se psal rok 2004, existovala nemalá skupina vývojářů, která věřila, že jediná a správná cesta vývoje aplikací spočívá v následování Java EE, tehdy ještě J2EE (ve zbytku článku zůstanu u aktuálního označení). Jako každá jiná v uvozovkách správná cesta i tahle nebyla úplně správná, jak potvrdilo právě uplynulých deset let. V tomto článku se pokusím vyložit historický kontext, ve kterém Spring framework vznikal, a nastínit hlavní důvody, které vedly k tomu, že i přes posun v architektuře aplikací, je stále platným nástrojem a de facto standardem pro vývoj Java aplikací.



Abychom pochopili historický kontext a vznik Spring frameworku, je potřeba vrátit se na přelom milénia. V té době internetová bublina dosahovala svého vrcholu a akcie technologických společností, jako byl Sun, stoupaly do nebes. Slovy Ivana Horníka - neslavně známého díky fotbalové korupční aféře - s municí nebyl problém vole a peníze do vývoje tekly proudem. V té době přišel Sun - a asi nejenom on, tipoval bych určitě na Microsoft - s myšlenkou vytvořit platformu, která by umožňovala vývoj enterprise (podnikových?) aplikací tempem Fordovy pásové výroby. Na jedné straně měli být vývojáři a na straně druhé dodavatelé middleware řešení - rozuměj aplikačních serverů. Mezi nimi měla stát standardizovaná platforma s kontraktem v podobě API a specifikací. Toto rozdělení mělo zaručit snadnou přenositelnost aplikací a zároveň vytvořit konkurenční prostředí pro dodavatele aplikačních serverů. Myšlenka to nebyla vskutku špatná, ale v praxi měla celou řadu problémů.



Předně celá Java EE byly navržená jako rodina technologií, které byly vzájemně provázané. Když jste například chtěli používat Enterprise Java Beans, znamenalo to, že jste se museli naučit další navazující technologie, jako například Java Transaction API. Další problém byl v tom, že Java EE vám v podstatě předurčovala architekturu vašich aplikací. Tvůrci počítali s tím, že jedna velikost stačí všem, čili že všechny aplikace budou mít víceméně stejné požadavky. Celý koncept vznikal v době, kdy si mohl těžko někdo představit, jaké typy aplikací se budou vyvíjet s masivním rozšířením internetu to doslova za pár let. Někdy kolem roku 2002 začala pomalu nastupovat první vlna frustrace z používání Java EE. V té době se objevila poměrně zásadní kniha J2EE design and development napsaná duchovním otcem Spring frameworku Rodem Johnsomem. Johnson se v této knize snažil poskytnout recept na správné používání Java EE a to včetně "frameworku", který pro tyto účely vyvinul. Není bez zajímavosti, že zdrojové kódy z této knihy (asi 30000 řádků kódu) se staly pozdějším základem Spring frameworku. Rod Johnson přesně trefil oblasti, které lidi pálily, a kniha zaznamenala velký úspěch.



Hlavní myšlenkou byla jednoduchost vývoje, testování a nasazení aplikací. Řečí technologie to bylo použití pár jednoduchých vzorů, které v té době již existovaly. Inversion of Control pro řízení vztahů mezi objekty, Template method pro izolaci často se opakujícího kódu, Aspektově orientovaného programování - pro řešení aspektů kódu prostupujících napříč aplikací. Johnson si díky zkušenosti s Java EE světem uvědomil, že celé řešení musí být co nejméně invazivní ve vztahu k uživateli. Díky tomu byl hned od počátku Spring framework koncipován jako modulární technologie - použij co potřebuješ - a tím pádem nenutil vývojáře ohýbat architekturu aplikací, tak aby vyhovovala frameworku. Udělal to přesně naopak, framework byl jako Lego skládačka, ze které si člověk vzal to co potřeboval.



Celou tuto filozofii a zmiňované tři vzory můžeme potkat v jakémkoliv dalším projektu, který se stavěl v Spring ekosystému. Spring framework nebyl nikdy žádná raketová věda a jediné kouzlo bylo v eleganci jeho používání. Elegance vycházela z jednoduchosti. Bylo to přesně jako podle příručky, framework by měl řešit často se opakující problémy a ulehčit život aplikačnímu programátorovi. Nic víc, nic míň. To je důvod, díky kterému přežil bez výraznějších veletočů a změn, prakticky ve stejné podobě, posledních deset let.


Zajímavý vývoj za tu dobu prodělala architektura aplikací. Dlouhou dobu byla celkem běžná monolitická architektura aplikací - eufemismus používaný pro jednu velkou kouli propletených špaget. Tato architektura se pomalu začala měnit a její transformaci akceleroval příchod chytrých mobilních zařízení. Najednou nebylo možné podporovat jedno zařízení - webový prohlížeč - ale jejich celou řadu - mobilní telefony, tablety. Díky sociálním sítím a obchodům s aplikacemi (Appstore) přišla jednoduchá možnost oslovit levně velké množství uživatelů. Všichni měli potřebu a nebo zadání vyvíjet aplikace rychlostí kulového blesku. Jednu z možností, jak zkrátit dobu potřebnou k doručení aplikace koncovému zákazníkovi, představoval Cloud.


Zatímco enterprise aplikace se provozovaly na zakoupeném a spolehlivém hardware pěkně v datových centrech bank a korporací, začala růst rodina aplikací provozovaných na hardwaru, který byste označili za komoditní. Aplikace nevznikaly roky, ale spíše měsíce nebo týdny. Při jejich úspěchu pak často docházelo k problémům se škálovatelností a stabilitou. Ne že by tyto problémy neexistovaly před tím, ale docházelo k nim mnohem méně často. Za poslední dva roky jsme mohli zaznamenat změny v architektuře, která se posouvá směrem od monolitických aplikací k aplikacím založeným na mikrošlužbách běžících v Cloudu - bez ohledu na to, jestli je privátní nebo veřejný. Jestliže je dnes ten poměr 80/20 ve prospěch monolitických aplikací, do dvou let může být pro nové aplikace přesně opačný. Když se dnes rozhodnu postavit si aplikaci s architekturou postavenou na mikroslužbách, budu jako vývojář opět vyžadovat to samé co v roce 2004 - jednoduchost vývoje, testování a nasazení. Možná to nebude znít dost sexy pro technologické hypstery, ale Spring - ta deset let stará technologie - mi přesně tohle splní. Bavíme se tady o kódu jehož závislosti popisuji pomocí anotací, používám convention over configuration, každá mikroslužba používá REST rozhraní a REST klienta, případně komunikuje přes messaging a běží v Spring Boot kontejneru.

Spring ušel za těch deset let dlouhou cestu a pro mnohé je to technologie, která se vlastně moc nemění a vlastně ji skoro každý zná. Je to pravda. Spring byl vždy postavený na jednoduchých konceptech, které skvěle fungovaly, a vývojáři s nimi byli spokojení. Přejme si, aby se této filozofie držel i nadále, protože jenom díky ní skvěle splňuje nároky architektury aplikací, která se diametrálně liší od architektury aplikací pocházejících z doby svého vzniku. Co by za to jiné technologie daly...

pondělí 14. července 2014

CZ Podcast 102 - programátorky a pohlavní (ne)vyváženost aneb proč se před holkama neprdí

V tomto díle jsme otevřeli otázku proč je mezi námi programátory tak málo holek. Abychom jenom neteoretizovali, pozvali jsme si rovnou dvě zástupkyně něžného pohlaví a programátorky - Vlaďkou Janů a Alenou Varkočkovou - okořenili jsme to pár vlastními historkami. Rozsah našeho povídání osciluje mezi tím, jak holky začínaly, až po to, kdy nandavají sluchátka, aby se vyhnuly košatým historkám. Vaše ohlasy uvítáme na naší Facebook fanouškovské stránce.

čtvrtek 19. června 2014

CZ Podcast 101 - Rozpoznávání řeči

V dalším díle jsme zavítali do společnosti ZOOM international, kde byli našimi hosty Šimon Vostrý, Václav Hanžl a Pavel Šuchmann a tématem se stalo rozpoznávání řeči. Prosím omluvte nižší kvalitu zvukové stopy, ke které dochází jednou, maximálně dvakrát, za deset let (máme sice super mikrofony, za to dementní aplikaci). Vaše ohlasy uvítáme na naších fanouškovských stránkách.