středa 13. srpna 2014

CZ Podcast 103 - vývoj indie her aneb pankáčem snadno a levně

Hostem dílu 103. byli Vladimír Hrinčár, Ján Ilavský indie vývojáři ze studia Hyperbolic magnetism. Na jedné straně romantismus indie game vývoje a na druhé straně složenky za nájem. Pankáčové každým coulem. No tedy až na ty cloudové aplikace ;-).

neděle 27. července 2014

Kniha Bod zlomu

Kniha Malcolma Gladwella Bod zlomu popisuje jednoduchou myšlenku a to že Vznik módních trendů, nástup a ústup vln zločinnosti… se šíří jako epidemie. V určitou chvíli dosahuje epidemie okamžiku, ve kterém vše ustane nebo naopak propukne. Tomuto okamžiku se říká bod zlomu. Autor popisuje několik příkladů epidemií, které v určitou chvíli propukly či ustaly, a pomocí nich ilustruje zákonitosti, kterými se obecně vznik epidemií řídí. Na úvod je potřeba říci, že slovo epidemie nemusí nutně znamenat něco špatného - asi každému se vybaví chřipková epidemie - v knize jsou příklady epidemií v dobrém slova smyslu tj. například nástup módních trendů nebo proměna knihy v bestseller. Všechny je provázela mimořádná rychlost se kterou propukly, vysoká nakažlivost a malé změny, které k tomu vedly. Bod zlomu, tedy jestli epidemie ustane (může znamenat i rovnovážný stav) či propukne, ovlivňují tři činitelé změn - Zákon malého množství, Faktor chytlavosti a Síla kontextu.


Zákon malého množství

Zákon malého množství říká, že za rozpoutání epidemií šířících se ústním podáním jsou zodpovědní spojovatelé, maveni a prodavači. Při epidemii je kritickým faktorem charakter nositele sdělení. Boty, varování , infekce nebo nový film mohou být vysoce nakažlivé a zlomit se čistě díky tomu, že jsou spojeny s určitým typem člověka.

Spojovatelé
Jsou to lidé, ke kterým se všichni dostaneme v pár krocích (přes pár známých), protože z jakéhosi důvodu dokáží obývat mnoho různých světů, subkultur a prostředí.
Maveni
Maven - slovo z jidiš označující někoho kdo shromažďuje informace - jsou lidé, kteří jsou studnicí informací a jejíchž touhou je o ty informace se dělit.
Prodavači
Jsou lidé, kteří nás dokáží přesvědčit, když nevěříme tomu, co slyšíme.

Faktor chytlavosti

Faktor chytlavosti říká, že určitými způsoby lze docílit toho, aby nakažlivé sdělení bylo zapamatovatelnéů jisté poměrně jednoduché změny v prezentaci a strukturování sdělení mohou mít velký vliv na to, jaký dopad má.


Síla kontextu

Konkrétní malé prvky prostředí mohou sehrát klíčovou roli bodu zlomu. Lidé jsou na okolní prostředí mnohem citlivější než by se mohlo zdát.



Kniha je mixem poznatků z ekonomie, behaviorální psychologie, a případových studií. Pokud se mě zeptáte, co jsem si z ní odnesl, bude toho docela dost. Nemám v úmyslu rozpoutat epidemii čehokoliv, ale některé myšlenky jsou celkem přenositelné.

Skupiny a jejich velikosti, pravidlo 150

Malé semknuté skupiny mají schopnost znásobit epidemický potenciál sdělení nebo myšlenky. Bez ohledu na to, jestli budete chtít rozpoutat nějakou epidemii, nebo jenom zaručit, že vaše firma bude škálovat při růstu počtu lidí, měli byste mít na paměti kritickou velikost skupiny, která je 150. S větší skupinou nejsme schopni udržovat kontakt


Číslo 150 zřejmě představuje maximální počet jednotlivců, s nimiž můžeme mít opravdu společenský vztah, který spočívá v tom, že víme, kdo jsou a jaký je jejich vztah k nám. Můžeme to říci také tak, že to je počet lidí, ke kterým byste se nerozpakovali si bez pozvání přisednout na skleničku, kdybyste je náhodou potkali na baru

Gore associates

Firma, ve které přísně aplikují pravidlo 150, má několik dalších zvláštností

  • technologická firma
  • nepromokavé látky Gore-tex, vlákno na čištení zubů Glide, vývoj pro farmaceutický a elektrotechnický a automobilový průmysl
  • ve firmě nejsou žádné tituly bez ohledu na to kolik člověk vydělává nebo jakou pozici zastává či jak je ve firmě dlouho
  • lidé nemají šéfy, ale patrony, kteří dbají o jejich zájmy
  • nejsou zde žádné organizační schémata, žádné rozpočty, žádné propracované strategické plány
  • o platech se rozhoduje kolektivně

Opakovaně jsme se setkali s tím, že okolo 150 všechno začíná být neohrabané

Pravidlo 150 umožňuje vznik skupinového tlaku. Gore ve svých malých továrnách nepotřebuje formální struktury řízení - obvykle úrovně nižšího a vyššího managementu - protože v tak malých skupinách jsou neformální osobní vztahy účinější.

Skupinový tlak

Skupinový tlak, který cítíte , když továrna není efektivní, když nemáme dobré tržby, je neuvěřitelný. Tak to chodí, když pracujete v malých týmech, kde se každý s každým zná. Skupinový tlak je silnější než postava šéfa. Mnohem silnější. Lidé chtějí splnit co se od nich očekává.

…tlak, o kterém mluvím, vzniká tak, že lide z prodeje se pohybují ve stejném světě jako lidé z výroby. Prodejce, který chce vyřídit nějakou zakázku, může přímo zajít za někým z výroby, koho zná… Jsou to dva lidé, jeden se snaží výrobek udělat, druhý ho prodat. Postaví se k sobě čelem a vyříkají si to. To je skupinový tlak. V … nic takového neuvidíte, protože každý je tam sám za sebe. V úseku výroby měli 150 lidí, již úzce spolupracovali, a byl tam cítit skupinový tlak na to, aby byli nejlepší a nejinovativnější. Ale mimo tuto skupinu tlak nedosáhl, protože dál už se neznali


Ke stejnému závěru, tedy maximální velikosti 150, došli vojenští plánovači zkušenostmi k pravidlu, že funkční bojové jednotky nemohou mít více než 200 mužů. Citace antropologa Robina Dunbara, který se tímto pravidlem poměrně detailně zabýval.


Podle mého názoru to není jen výrazem toho, jak generálové ze zázemí provádějí kontrolu a koordinaci, protože navzdory veškerému pokroku v komunikačních technologiích od první světové války si roty tuto velikost tvrdošijně udržují. Zdá se spíš, že že v průběhu století plánovači metodou pokusu a omylu zjistili, že je obtížné, aby se větší množství mužů poznalo dostatečně dobře na to, aby byli schopni společně působit jako funkční jednotka.

Je samozřejmě možné mít větší skupinu… k udržení loajality a soudržnosti musíte ale zavádět komplikovanou hierarchii, pravidla, předpisy a formální opatření. Pod hranicí 150 je možné docílit téhož neformálně. Při této velikosti lze plnit rozkazy a udržovat kázeň na základě osobní loajality a přímých mezilidských kontaktů. U větších skupin to není možné.


Teorie rozbitých oken aneb proč se zaměřit na detaily

S teorií Rozbitých oken přišli kriminologové James Q. Wilson, George Kelling. Přijde mi inspirativní v tom, že mnohdy kolem sebe ve vývoji vidíme drobnosti, nad kterými mávneme rukou. Podle této teorie právě tyto drobnosti vedou k větším a mnohem závažnějším problémům.

… zločinnost je nevyhnutelným důsledkem nepořádku, Když rozbité okno zůstane neopravené, lidé , kteří chodí kolem, usoudí, že je to všem jedno a nikdo není za nic odpovědný. Brzy přibudou další rozbitá okna a pocit anarchie a signál, že vše je dovoleno, se z domu rozšíří na ulici v níž stojí.

Relativně podružné problémy jako graffiti, nedodržování veřejného pořádku a agresivní žebrání jsou podle těchto autorů všechno obdoby rozbitých oken. Jsou to výzvy k vážnějším zločinům.

… zloději, ať již příležitostní nebo profesionální, chápou, že pravděpodobnost jejich dopadení je nižší, jestliže operují na ulicích , kde jsou potenciální oběti již zastrašeny stávajícími podmínkami. Jestliže se nějaká čtvrť není schopna zbavit protivného žebráka obtěžujícího kolemjdoucí, může zloděj usoudit , že tím spíš nikdo nezavolá policii a nebude identifikovat potenciálního zloděje a ani nezasáhne, pokud dojde k nějakému přepadení


Závěr

Nakonec jsem knihu ohodnotil čtyřmi z pěti hvězdiček na GoodReads. Knihu považuji za velmi inspirativní a to přestože není ze světa softwarového vývoje a programování. Paralel tam nicméně najdete habaděj.


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