čtvrtek 18. prosince 2014

CZ Podcast 109 - Apiary

K natáčení dalšího dílu jsme využili nabídku Hagen Human Capital a pozvali jsme Apiary tým, respektive CEO Jakuba Nešetřila a CTO Lukáše Linharta, tedy hlavy pomazané. Naše povídání se netočili jenom kolem REST API, ale zabrousili jsme i do zákulisí startupového života, který nás baví a zajímá.

úterý 18. listopadu 2014

CZ Podcast 107 - Erlang

Jako téma tohoto dílu jsme zvolili programovací jazyk Erlang, který je nejenom vhodný pro psaní telefoních ústředen, ale jak se dozvíte, i pro distribuované systémy a algoritmy. Hostem tohoto dílu byli pánove Jan Chochol, David Kubečka a Luboš Veselý.


úterý 4. listopadu 2014

Když MVP dláždí cestu do pekel

MVP všichni tu zkratku milujeme nebo lépe řečeno to co se za ní skrývá. Minimum Viable Product - to nejnutnější minimum, které musíte dodat zákazníkovi, abyste vyřešili to nejdůležitější, co ho pálí. Zákazník to miluje, protože dostane v nejkratším čase to co chce nebo si to alespoň všichni myslí. Vývojáři to milují, protože se jim to vejde do sprintu a nebo se to dá alespoň naplánovat na menší části. Architekti to milují, protože nedochází k velkému designu a zbytečným rozhodnutím implikujícím změny, které možná nebudou potřeba. MVP je dobrý sluha, ale špatný pán. Snadno se z něj stane jednosměrka přímo do pekla. Není to bída MVP, ale důsledek toho, kam vede jeho nevhodné použití. Tento článek je o tom, jak se vyvarovat určitých úskalí s ním spojených.

Malé mentální cvičení kolem MVP dovedené ad absurdum.Přijde za vámi zákazník a řekne, že se potřebuje dostat z bodu A do bodu B. Chtěli byste navrhnout auto. To je ovšem složité a vůbec, potřebuje to zákazník? Co třeba motorku? Moc složité. Co třeba kolo? Ten zákazník bude jezdit vždycky z kopce. Ani kolo není potřeba, co třeba koloběžku? Bude jezdit vždy v zimě. Co třeba sáňky nebo rovnou lyže? Lyže budou ještě jednoduší a levnější. No možná bychom to mohli ještě zjednodušit. Co mu takhle dát pod zadek igelitový pytel, který vycpeme slámou? To nakonec stačí a voilà máme MVP. Zákazník má sice omrzliny prvního stupně, občas si rozbije hubu, ale MVP posloužilo svému účelu.

Podobné MVP má v podstatě dvě stinné stránky. To co je MVP pro zákazníka, může být noční můrou pro vývojáře z pohledu nějaké další údržby a rozvoje. Pokud si nasekáte do produkce několik MVP vedle sebe, může se jejich udržování podobat průchodu minovým pole. Mnohdy je totiž MVP velmi provizorní řešení. Mnohem horší problém s MVP je ten, že mnohdy zůstává na věky. To znamená, že už se do nich nikdy neinvestuje ani koruna. Slouží svému účelu, ale nikdo už je nedotáhne do požadovaného stavu. MVP je polovičatá práce jejíchž důsledky vás dříve nebo později doběhnou.

Pokud nehodláte udělat MVP a to dále rozvíjet, případně jej úplně zaříznout, je lepší nedělat ho vůbec. Úplně nejhorší situace je, pokud vám hromada MVP trčí v produktu, jako kostlivci ve skříni, kteří se jenom třesou na to, aby na vás mohli vypadnout v tu nejméně vhodnou chvíli, pokud možno dohromady, protože mezi nimi existuje nějaká vazba. Velmi se mi líbí myšlenka, kterou popsal Martin Fowler v článku SacrificialArchitecture. Ta s MVP souvisí na úrovni architektury. V kostce se jedná o to, že každá architektura je poplatná době svého vzniku a měla by mít datum expirace. Po jeho uplynutí by nám nemělo být líto danou část systému vyhodit a přepsat ji s ohledem na aktuální požadavky. MVP se dá dělat dobře, ale chce to velkou kázeň, mějte jí, až se k jeho použití uchýlíte.

  1. Nedělejte MVP pokud je to váš jediný modus operandi. Soustřeďte se na minimální řešení, kdy MVP nebude jenom výmluva pro oklamání akceptačních kritérií a pašování práce nízké kvality.
  2. Nedělejte MVP pokud ho nehodláte dále rozvíjet. Rozvíjet může znamenat úplně předělat a nebo zrušit, počítejte s tím.
  3. Nedělejte MVP stavějící na jiném MVP neboť riskujete efekt motýlích křídel.

úterý 28. října 2014

(Ne)marný boj s technologickým dluhem

Naše řešení je technologicky složité a bylo by složíte, i kdybychom nestříleli sami sebe do nohou. Pokud děláte distribuovaný systém, bude ten systém prostě složitý. Máme složitý systém, který je navíc okořeněný různorodostí jazyků a middlewaru, a proto je důležité bojovat s technologickým dluhem, aby na nás neustále nepadal nějaký kostlivec ze skříně. Nám se to v GoodData daří se střídavými úspěchy. V tomhle článku jsem zkusil sepsat pár postřehů a technik, které jsme vyzkoušeli.


Škatulata, škatulata hýbejte se


Dlouhou dobu jsme měli celé řešení rozdělené horizontálně, kdy si každý tým spravoval svojí vrstvu respektive službu. V tomhle rozpoložení se nám s technologickým dluhem nedařilo moc dobře bojovat a nejenom to. Vázl nám i vývoj regulérních produktových požadavků a to především pokud bylo potřeba týmovou spolupráci. Udělali jsme velký třesk a týmy jsme přestavěli na vertikální. Před reorganizací jsme měli tým erlangových vývojářů, java vývojářů, javascriptových vývojářů a perlových vývojářů. Teď máme týmy, kde je obrazně řečeno jeden erlangista, jeden javista, jeden perlista a jeden javascriptař.

Tohle rozložení, už z podstaty, moc nenahrává splácení technologického dluhu. Nebo lépe řečeno, nepozoruji žádný významný rozdíl. Troufám si tvrdit, že jsme si ověřili, že hýbání lidí zleva či zprava nemá na technologický dluh žádný vliv (přestože to nebyl hlavni cíl reorganizace).


Přiznejte si, že máte problém a ten kvantifikujte ho

Je to jako na sezení anonymních alkoholiků, tedy ne že bych tam někdy byl, musíte si nejprve přiznat, že máte nějaký problém. My jsme si udělali seznam s popisem jednotlivých oblastí a určili jsme si jejich priority. Seznam nám visí na vstupních dveřích kuchyňky, aby ho nikdo nemohl minout - viditelnost. Důležité je, že je to něco konkrétního, kvantifikovatelného, nejenom něco abstraktního.


Shoda, že s dluhem hodláte něco dělat

Důležitá je shoda s managementem, že je v zájmu všech s dluhem něco dělat. Management má někdy tendence tyhle problémy bagatelizovat, proto je důležité vysvětlovat, vysvětlovat a zase vysvětlovat a to i opakovaně. Technologický dluh nezmizí mávnutím kouzelného proutku. Alergie managementu na jakoukoliv zmínku o technologickém dluhu vyplývá ze snahy inženýrů vždy a za každých okolností se na něj vymlouvat. Právě proto se musíte shodnout, že s ním chcete bojovat.


Boj musí být priorita

Každý kvartál začínáme se seznamem priorit, na které se budeme zaměřovat. Pokud se nám tam nedostal konkrétní bod z výše uvedeného seznamu, nikdy se nic nestalo, dluh zůstal dluhem. Dávat si za prioritu cíl bojovat s technologickým dluhem nestačí. Vyberte si konkrétní bod ze seznamu, se kterým chcete bojovat a tomu dejte stejnou prioritu, jako produktovým požadavkům. Ve scrumu jsme zkoušeli rezervovat část kapacity týmu, ale i to nemělo zářné výsledky. Pocitově mi přišlo nejlepší, když byl celý sprint dedikovaný právě na konkrétní oblast technologického dluhu.


Vlastnictví

Technologický dluh se často obnaží v místech, které jsou vlastněné všemi a zároveň nikým. Je to podobné, jako s kurtizánou, se kterou obcuje půlka fotbalového mužstva, a když otěhotní, nikdo se k tomu nemá, protože to může být kohokoliv. A je úplně jedno jestli se jedná o část code base a nebo nějakou sdílenou službu. Jasné vlastnictví umožňuje lepší plánování a alokaci zdrojů. Pokud není možné určit jednoznačného vlastníka, musí se daná věc nějakým způsobem rozsekat. Pokud to není možné, většinou to indikuje nějaké nezdravé závislosti. Jejich rozmotání bývá často zdrojem všech problémů.


Trpělivost

Obrňte se trpělivostí, protože splácení technologického dluhu je běh na dlouhou trať. Boj s větrnými mlýny je to ve chvíli kdy máte nejasné vlastnictví, kolidující priority a zároveň musíte hasit požáry. V tom případě začněte od začátku výše uvedeného seznamu.

neděle 21. září 2014

QA v roli Důmyslného rytíře dona Quijote de la Mancha

Čas od času slýchám, jak si někdo v agilním vývoji stěžuje na nedostatečnou kvalitu a zároveň vzývá QA inženýry a jejich klíčovou roli. Mýtus spočívá v přesvědčení, že především QA zajišťuje v agilním vývoji kvalitu. Použiji sportovní paralelu. To, že máte v brance nejlepšího brankáře na světě, ještě nic neříká nic o tom, kolik gólu inkasujete. Defenziva je věcí celého týmu nikoliv jednotlivce. Brankář podobně jako QA inženýr je pomyslný dirigent s nejlepším přehledem o celém dění. S architekturou a dalšími aspekty vývoje je to velmi podobné. Ať již vezmeme jakýkoliv aspekt, je za něj vždy odpovědný tým jako celek. V týmu, kde se kvalita produkovaného softwaru odsouvá kamsi na pozadí, vám nepomůže ani QA s brokovnicí mířící na zátylek každého vývojáře. Jaká je tedy role QA v agilním vývoji?


Předně je stejně důležitá, jako jakákoliv jiná v daném týmu. Stejně jako nemůžete hrát bez brankáře (až na malé výjimky jako je hra bez brankáře v hokeji), nemůžete fungovat bez kvaliťáka. A to bez ohledu na to, jestli z vás padá kód s jednou nebo deseti chybami. Čím lepší kvalitu produkovaný kód vykazuje, tím rozdílnější roli bude QA člen týmu hrát. V jakémkoliv případě bude jeho role nezastupitelná, protože vždy může nabídnout minimálně jiný úhel pohledu na daný problém. Roli QA lze rozdělit podle toho, jak je tým zkušený, kdy zkušenost je přímo úměrná důrazu na kvalitu. Čím zkušenější tým, tím větší pozornost věnuje kvalitě.


Nezkušený tým

QA zde funguje jako bič na vývojáře. Je to autorita, která nejenom rozhoduje o tom, co splňuje či nesplňuje kritéria kvality, ale zároveň působí jako mentor pro vývojáře. Jejím úkolem je vysvětlovat vývojářům roli testů, pomáhat se zaváděním automatických testů (cukr) a držet štábní kulturu psaní testů. Samozřejmě pokud testy neprocházejí je jeho důležitou povinností vývojáře tepat. Nezkušené týmy mnohdy chtějí psát testy, jenom nevědí jak na to. Právě proto je důležité, aby fungoval nejenom v roli represivní, ale i v roli osvětové. Přerod nezkušeného týmu přichází ve chvíli, kdy tým začne chápat přínos testů jako integrální součásti vývoje a nijak jej nezpochybňuje např. výmluvami na nedostatek času.

Středně zkušený tým

Tým už chápe všechny výhody, oceňuje přínos testů a role QA je postrčit na další úroveň. To mohou být další řekněme specializované testy např. výkonu, výdrže nebo různých katastrofických scénářů. QA hraje opět roli osvěty a pomáhá se zaváděním. Větší roli začíná hrát automatizace celého testovacího procesu - testovací pipeline - a vůbec měření kvality a sledování trendů. Role QA je stále nezastupitelná například během odhadování míry rizika regrese a definice akceptačních testů. Obecně by se dalo říci, že jeho role se pomalu posouvá směrem od mentora k partnerovi.

Zkušený tým

Testovací pipeline je nastavená, tým koučuje, co se testů týká, sám sebe, a QA role se posunula. QA je partner, který poskytuje podporu při testování. Jeho role je klíčová v tom, že jednak nabízí pohled nezatížený vlastním vývojem a jednak pomáhá se složitějšími případy testování - to mohou být testy ve specifickém prostředí nebo testy speciálních okrajových případů. QA již nehraje roli represivní složky a vývojáři velmi dobře chápou, že jim QA usnadní život a nikoliv hází klacky pod nohy.

Hranice mezi zkušeností týmu, rolí a konkrétními aktivitami QA se může prolévat a mnohdy závisí i na jiných okolnostech jako je například firemní kultura a procesy. Rád bych ješte jednou zdůraznil, že QA samo osobě nikdy kvalitu nezajistí, pokud ji jako nedílnou součást nepřijme vývojářský tým. V jakémkoliv jiném případě hraje totiž QA roli Důmyslného rytíře dona Quijote de la Mancha.

neděle 14. září 2014

CZ Podcast 105 - Osmibity

Do dalšího dílu jsme pozvali Martin Malého alias A. Denta, nestora osmibitové scény, aby zavzpomínal na staré dobré osmibitové počítače. Tenhle díl stojí za poslechnutí ať již osmdesátá léta a hrátky s osmibitovými počítači pamatujete či nikoliv.

čtvrtek 4. září 2014

CZ Podcast 104 - Akka, Spray, Play

Hostem 104. dilu je Jan Macháček, autor několika knih například Pro Spring, který se nyní věnuje vývoji reaktivních aplikací nad TypeSafe stackem tj. Scala, Akka, Play.io, Spray.io.

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.

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

pátek 30. května 2014

CZ Podcast 99 - Bezpečnost a biometrie

Někteří hosté se neomrzí a některá témata jsou nadčasová, proto jsme po třetí pozvali do CZ Podcastu Tomáše Rosu a Petra Dvořáka, abychom je vyzpovídali z oblasti biometrie a jejího použití v bezpečnosti.

pondělí 21. dubna 2014

Postupný rollout

Kolikrát už jsem jenom zažil tu situaci. Mám testy, kterým věřím, jsem skálopevně přesvědčený, že tahle změna nemůže nic rozbít, a pak se nakonec ukáže, že přece jenom rozbila. Tohle není litanie proti testům, v tomto článku se pokusím o zamyšlení nad tím, že kromě baterie testů, kterým věříte, potřebujete i způsob, kterým minimalizujete škody, které způsobí neznámé neznámo. Článek jsem zařadil do kategorie cynického software, protože účelově testovat na uživateli mi přijde dosti cynické. Nakonec drobná míra cynismu není na škodu, pokud je to win-win strategie.

Neznámé neznámo

Přihlašování je jedna z mála věcí jakéhokoliv systému, která když se pokazí, vede k jeho nedostupnosti. V GoodData máme několik způsobů, přes které je možné dělat Single Sign On (SSO) tj. uživatel se přihlásí v mateřském systému a jeho identita se propaguje dále do GoodData, kde nevyžadujeme již její ověření uživatelem. Výsledkem je, že uživatel se přihlásí právě a jenom jednou. Starší způsob je založený na tom, že Identity provider posílá podepsanou a šifrovanou zprávu - JSON dokument. JSON obsahuje login uživatele a validitu (timestamp platnosti), tedy do kdy platí GoodData autentizační kontext vydaný na základě této zprávy.

{"email": "user@domain.com","validity": 123456789}

Z důvodů většího zabezpečení jsme tuto strukturu rozšiřovali o dva nepovinné atributy (notBefore, notOnOrAfter), definující platnost samotné zprávy. Úplně původně byl kód obsluhující tento typ přihlášení napsaný v Perlu. Při přepisu do Javy se JSON parsoval ručně. Při rozšiřování jsem nechtěl mít v kódu takovou věc, jako je ruční pársování JSONu. Čuchal jsem trochu problémy se zpětnou kompatibilitou a proto jsem v kódu nechal původní metodu jako fallback. Kód vypadal následovně.

try{
 return parseStrictly(loginSessionMessage, defaultNotBefore, defaultNotOnOrAfter);
} catch(IOException e) {
 log.info("Cannot parse login message '{}'. Using fallback method for parsing its content.", loginSessionMessage);
 return parseQuirkly(loginSessionMessage, defaultNotBefore, defaultNotOnOrAfter);
}

Pokud by kód nebyl validní JSON, Jackson knihovna na práci s JSON by vyhodila potomka IOException. S důvěrou jsem tenhle kód nasadil na produkci. První problém se objevil po pár hodinách a znamenal, že jsme museli celou funkcionalitu revertovat. Na vinně byl následující řádek uvnitř metody parseStrictly.

final Long validity = (Long) map.get(VALIDITY_FIELD_NAME);

Bohužel někdo občas poslal v JSONU místo čísla řetězec a fallback catch blok nechytil ClassCastException. Největší potupa byla poslouchat jízlivé poznámky vedle sedících Perl programátorů, že tohle by se jim v Perlu nestalo.

Tohle je jeden z mnoha případů, kdy by ani sebelepší code review nebo testování nepomohlo. Všechny testy operují nad množinou stavů, která je vám předem známá. Pokud tedy nepočítáte s nějakým stavem, těžko ho můžete otestovat. Jedná se o takzvané neznámé neznámo. V tomhle případě jsme problém mohli odhalit jenom ve chvíli, kdy jsme kód vypustili na produkci.

Tak trochu jiné testování na uživateli

Vývojáři občas, při malém pokrytí testy, utrousí, že testují na uživatelích. To je samozřejmě špatný přístup. Někdy ovšem neexistuje jiný stejně efektivní způsob a nebo vůbec cesta, jak prozkoumat neznáme neznámo. V jakémkoliv software je alespoň jeden neodhalený bug a testy jsou jenom pomůckou k objevení toho zbytku. Pokud přistoupíte na tento fakt, a já se obávám, že nic jiného nám ani nezbývá, musíte nutně dojít k tomu, že je potřeba minimalizovat škody, které může tento bug nebo bugy napáchat. Jednou z technik, která k tomu pomáhá je postupné uvolňování nových vlastností nebo verzí.

Myšlenka je to velmi jednoduchá. Namísto toho, aby se k nové verzi dostali všichni uživatelé najednou, uvolňujete ji postupně. Pokud se tam objeví chyba, nezasáhne ihned všechny uživatele, ale pouze jejich omezené množství. Pokud máte navíc v systému dobrou telemetrii, můžete problém detekovat automaticky a udělat rollback na původní verzi nebo v případě složitějších změn zastavit uvolňování nové verze dalším uživatelům. Právě postupné uvolňování nových verzí a telemetrie s automatickým rollbackem je něco na čem teď v GoodData pracujeme a co bychom chtěli mít v blízké době v provozu.

Je potřeba říci a to velmi důrazně, že ve skutečnosti netestujeme na uživateli. Výše popsaný mechanismus slouží k minimalizaci škod, ke kterým může vždy dojít. Vždy musí platit, že kód, který uvolňujeme na produkci, prošel všemi mechanismy zajištujícími odpovídající kvalitu. Jinými slovy, mechanismus neslouží jako náhražka testů, ale jako doplněk a ochranná bariéra.

V další části textu najdete moje postřehy, které odpovídají míře pochopení problému v danou chvíli a diskuzím, které jsme kolem tématu zatím vedli. Vlastní implementace se může v budoucnu odlišovat, ale zřejmě pouze v detailech. Rovněž nepředpokládám, že dáme vše na první ránu a ke konečnému stavu postupně dojdeme.

Vypustíme kanárky

Uvolňování nové verze a její deployment se může dělat pomocí Canary releasingu. Nejdříve se nasadí nová verze, která funguje paralelně s tou původní. Zároveň se uživatelé začnou směrovat na novou verzi. Pokud jde vše podle plánu, přesměrují se všichni na novou verzi, a stará verze se zahodí. V případě GoodData máme jednu vstupní bránu, přes kterou tečou všechny HTTP požadavky, proto není problém na vstupu požadavek distribuovat do staré nebo nové verze dané služby. Afinita (příslušnost) k verzi je možné držet v cookies (může být problém pro programatické REST klienty) a nebo pomocí HTTP hlaviček. V případě HTML aplikace máme mechanismus, který umožňuje bootstrap konkrétní verzí. Tento mechanismus již používáme v rámci podpory více datových center, kde mohou být rovněž nasazeny různé verze.

Největší oříšek představuje požadavek na zpětnou kompatibilitu. Interně jsou GoodData vystavěné jako služby, které spolu komunikují přes REST rozhraní. Každá služba má svůj vlastní subcluster a v podstatě i vlastní životní cyklus. Některé služby jsou vyvíjeny poměrně agilně, to znamená, že i několikrát za týden je uvolněná jejich nová verze. Je proto nutné, aby všechny změny, uvolňované tímhle způsobem, byly zpětně kompatibilní. Pokud změna není zpětně kompatibilní, musí být nasazena v plánovaném okně pro odstávku celé platformy. To je jediný způsob, jak koordinovaně nasadit nekompatibilní změny přes více služeb.

Strategie uvolňování tedy výběr uživatelů je možný po několika liniích. V GoodData jsou to uživatelé nebo projekty, případně větší celky, do kterých patří. Čili uvolňování řežete na úrovni uživatelů a nebo projektů, které používají. Například nová verzi SSO dává smysl uvolnit po ose uživatelů. Mě osobně se hodně libí metoda, které říkám dog fooding, tedy že se nová verze nejdříve uvolní interním uživatelům z řad GoodData. To v praxi vypadá tak, že uživatelé s loginem @gooddata.com ,případně ty přistupující přes naše interní adresy, by dostaly vždy nejnovější verzi. Pokud by se neobjevila regrese, bylo by možné pokračovat v uvolňování dalším uživatelům. Podobný model má například Facebook.

Chcíplý kanárek

Celý proces uvolňování a případného rollbacku musí být dostatečně automatický. Jednou z klíčových součástí je detekce anomálii, které mohou signalizovat, že v nové verzi je něco v nepořádku. V současné době sbíráme celou řadu dat z telemetrie provozu, díky kterým bychom měli dokázat rozpoznat běžný provozní stav od toho neobvyklého, který se projeví nějakou anomálií. Anomálie je prakticky cokoliv, co se odlišuje od normálů - například poměr HTTP statusů (vnitřní chyba serveru nebo chyba klienta) může celkem spolehlivě indikovat nějaký problém. Když tuhle myšlenku - detekce anomálií - rozvinu dále do budoucnosti, potřebujeme něco co se naučí rozpoznávat anomálie ze historických dat o provozu. Umělou inteligenci, kterou vytrénujeme na historických datech a které periodicky předhazujeme aktuální data z provozu. Při detekci anomálie (automatika) můžeme rozhodnout (člověk) jestli pokračovat v uvolňování a nebo jej docčasně zastavit a nebo provést rollback.

Závěr

Bez ohledu na to, kam se nám celou myšlenku podaří dopracovat, je zjevné že testy v klasické podobě postačují pouze k pokrytí stavů, které jsou nám známe. Pro stavy, o kterých nevíme, musíme použít přístup, kdy případné problémy zůstanou izolované pouze na omezenou a ideálně velmi malou skupinu uživatelů. K tomu nám dopomáhají výšše zmiňované metody.

středa 16. dubna 2014

CZ Podcast 97 - Internet věcí

V 97. dílu jsme velmi rádi přijali pozvání do firmy Inmite, kde nás čekala celá řada technologických hraček - Google glasses, Oculus rift, Leap motion, a Air-Bond hardwarového zařízení přímo od InMite - a povídání které zprostředkovali pánové Michal Šrajer a Petr Dvořák. Videa najdete na naší fanouškovské stránce, kde uvítáme i vaše ohlasy.

pondělí 7. dubna 2014

Zdeformovaný programátorský trh aneb chybějící kus pokory

Docela jsem si zvykl, a bylo to zvykání příjemné, že má profese a vůbec celé odvětví je nadstandardně dobře placeno. Když jsem na podzim roku 2001 nastupoval do svého prvního zaměstnání, činila má hrubá mzda dvanáct tisíc korun. To byly na poměry maloměsta, ve kterém jsem tehdy žil, a pochopitelně doby, velmi slušné peníze. Úroveň mých vědomostí s bídou odpovídala úrovni programátorského eléva a jedinou devizou byl můj ničím neutuchající elán. Postupem času vzrůstala moje mzda, a to i násobně, a já měl pocit, že to odpovídá tomu, kolik jsem si toho odkroutil a kolik jsem se toho naučil. Po nějaké době jsem zjistil, že od určité hranice přestávám rozlišovat jestli je výplatní pásce o pár tisíc víc a nebo méně. Zní to možná komicky, ale kdyby mi tehdy přišla polovina výplaty, asi bych to ani nepoznal.


V roce 2010 jsem nastoupil do GoodData a moje tehdejší mzda byla nižší než v předchozím zaměstnání. Dostal jsem sice stock options (velmi zjednodušeně řečeno budoucí podíl na prodeji firmy), ale ty nemají, až do prodeje firmy a nebo její vstupu na burzu, cenu ani papíru na kterém jsou vytištěny. Bral jsem to tak, že je to dobrá příležitost se něco nového naučit. Kdybych to bral z pohledu mzdy, nedával tento krok z krátkodobého hlediska žádný smysl. Z dlouhodobého hlediska to teoreticky mohlo být zajímavější, protože jsem mohl doufat v to, že se naučím něco specifického, co mi dá přidanou hodnotu na trhu práce. Po čtyřech letech v GoodData stále nemám mzdu, která by odpovídala té z předchozího zaměstnání, ale za to vím, že jsem se naučil velkou spoustu věcí a získal vhled do oblastí, o kterých jsem neměl ani ponětí nebo jsem je vnímal jenom povrchně - cloud, škálovatelnost, NoSQL, distribuované systémy, agile a tak bych mohl pokračovat dále. Z mého pohledu jasná konkurenční výhoda na trhu práce.


Od určité doby jsem se začal účastnit pohovorů s případnými kandidáty na pozice k nám do firmy. Skoro vždy mě překvapilo, jaká byla disproporce mezi tím, co si člověk představoval na výplatní pásce, a tím, kolik toho potom věděl. K vysvětlení toho zjevného rozporu si stačilo nechat aktivovat možnost zasílání pracovních nabídek z LinkedIn. Jestliže je mi někdo ochoten zaplatit 4500,- eur za měsíc a práci, která by odpovídala mnou kladeným nárokům na začínajícího vývojáře, pak je něco v nepořádku. To se dá vysvětlit různě. Mohu mít přemrštěné nároky na vývojáře a nebo jsou tady firmy, které reálně přeplácejí a vytváří tyhle deviace.


Můžeme si tu na krásně říkat, že to je zákon trhu - nabídka odpovídá poptávce - ale výsledek na sebe nemusí nechat dlouho čekat. Pokud je méně kvalifikovaná práce placená jako práce, která vyžaduje vyšší kvalifikaci (úroveň vědomostí, dovedností a zkušeností), pak si dříve nebo později někdo spočítá, že za tu samou práci někde na východ od Košic zaplatí mnohonásobně méně. Jsem dalek tvrdit, že na naší práci se třesou hordy indických vývojářů dřepících někde v Bengalore, ale rozhodně bych to nebral na lehkou váhu. Já osobně raději příjmu a dobře zaplatím eléva, který se bude ochoten učit novým věcem. Budu u něj mít jistotu, že nebude zhýčkaný pětihodinovou pracovní dobou a kolbenkářským přístupem. Není jistě bez zajímavosti, že mzda dlouhodobě nefunguje jako hlavní motivační faktor. Mnohem důležitější jsou, co se týká nejen pracovního výkonu a spokojenosti, vnitřní motivátory - baví mě práce, učím se nové věci, dává má práce smysl, vidím za svojí práci nějaký výsledek.


Hloupý kdo dává, hloupější kdo nebere. Pokud vám někdo nabídne krásné peníze a je to pro vás motivace, určitě je v pořádku na takovou nabídku kývnout. Je to soukromá věc každého a nezadatelné právo. Každopádně trocha pokory by nám všem prospěla...

neděle 16. března 2014

Svět mikro služeb

Architektura většiny aplikací odpovídá jedné velké kouli bahna, pro kterou se vžilo označení monolitická. Na úrovni aplikace jsou typickými rysy bobtnající závislosti na knihovnách, vzájemné svázané části aplikace vedoucí k nulové odolnosti vůči selhání jednotlivých částí. Na úrovni operačního systému se jedná o jeden velký proces s velkými nároky na zdroje. Monolitické aplikace mají jednu obrovskou výhodu a to je jednoduchost vývoje. Nemusíte řešit, jak bude daný kód spolupracovat se zbytkem systému, prostě ho napíšete a on se stane součástí aplikace. Monolitické aplikace mají ovšem celou řadu nevýhod. Můžete je škálovat pouze jako celek. To vede k neoptimálnímu využití zdrojů. V případě selhání jedné části aplikace, byť absolutně nekrytické pro fungování z pohledu uživatele, dochází lavinovitě k selhání celé aplikace. Klasickým příkladem může být memory leak, který postihne celou aplikaci. Alternativou k monolitickému uspořádání aplikace představuje architektura micro services.


Architektura micro services vychází z toho, že aplikace a její funkcionalita se skládá z velkého množství malých služeb pospojovaných do větších celků. Důležitou charakteristikou tohoto architektonického přístupu je nebo by měla být izolovanost jednotlivých služeb. Adrian Cockcroft (Netflix, eBay, Sun) prosazoval myšlenku, že každá mikro služba může selhat a její konzumenti s tím musí apriori počítat. Byl to právě Adrian Cockcroft a firma Netflix pod jeho vedením, která postavila celý svůj stack právě na této architektuře.


Na velikosti záleží

Velikost mikro služby se těžko kvantifikuje. Četl jsem názory, že by to mělo být maximálně pár stovek řádků kódu, ale to mi nepřijde směrodatné. Mnohem důležitějším aspektem je dodržení takzvané jedné odpovědnosti (single responsibility principle). Každá mikro služba by měla dělat právě a jenom jednu věc - login, checkout, hledání, zobrazení nákupního košíku atd. V případě REST rozhraní mi přijde jako vhodná granularita jeden resource odpovídající mikro službě nebo alespoň funkcionalita z pohledu uživatele. Docela velkým nebezpečím je opačný extrém, tedy že aplikaci příliš fragmentujete vytvořením stovek mikro služeb. Každá mikro služba má svoje nároky, například v Jave musíte počítat s režií pro JVM, a musíte počítat se síťovým overheadem pro každou komunikaci mezi jednotlivými mikro službami. Někde jsem viděl poměrně vtipné přirovnání, že mikro služby představují Enterprise Java Beans pro hipstery.


Skryté náklady

Nejvíce přitažlivé na monolitické architektuře jsou nulové náklady, které máte s přidáváním nových vlastností do aplikace. V případě mikro služeb potřebujete poměrně slušnou infrastrukturu a to pro každou ze služeb. Řekněme, že máme mikro služby, které mají všechny jednotné REST rozhraní (HTTP, JSON). Pro každou z mikro služeb potřebujete kontejner, ve kterém poběží. Potřebujete monitoring, alerting. Každá z mikro služeb by měla být high available. Klienti služeb, další mikro služby, se musí nějakým způsobem dozvědět kde tyto služby běží. Můžete začít tím, že endpointy služeb bude někde v konfiguraci, ale dříve nebo později budete potřebovat nějaký registr služeb a jejich endpointů, protože služby mohou vznikat v nových verzích a nebo kolabovat v průběhu života celé aplikace. To se bavíme jenom o nárocích na běhové prostředí, k tomu je potřeba připočítat automatizaci na úrovni deploymentu (Puppet, Chef).


Kdy začít

Vždycky když merguji pull request, trnu hrůzou z představy, aby nějaká chyba nesprovodila ze světa celý server a já nemusel vstávat ve dvě hodiny ráno a něco řešit. Můžete si zkusit aplikaci rozdělit na kritické a nekritické komponenty z pohledu uživatele, zkusit se zamyslet, jestli byste mohli efektivně škálovat jednotlivé části aplikace, ale nejspolehlivější indikátor je obava, že už vám komplexita aplikace přerůstá přes hlavu. V takovou chvíli je vhodné začít přemýšlet o mikro službách. Velkou výhodou tohoto architektonického přístupu je, že můžete migrovat postupně jednotlivé části aplikace. Nemusí se hned od začátku jednat o velký třesk. Mikro služby nejsou sami o sobě spásou, i zde můžete udělat chybu, ale pokud to uděláte dobře, je velká pravděpodobnost, že chyba složí jenom jednu malou část aplikace.

Zdroje a užitečné odkazy

sobota 15. března 2014

CZ Podcast 96 - QA panel v Avastu

Do 96. dílu jsme si pozvali, tedy co my, ale Roumen pozval a zorganizoval, QA diskuzní panel ve společnosti QA. Společně s ním dorazil Pavel Chytil, Lukáš Hasík a Jaromír Cvrček. Celou dobu jsme se si povídali o tom, jak klucí zajišťují kvalitu antivirového řešení Avastu, jak využívají Virtual Box pro testování nových verzí a vůbec o infrastruktuře, kterou používají. Vaše ohlasy, komentáře a otázky uvítáme na naší oficiální Facebook stránce.

čtvrtek 27. února 2014

Go není další Jenkins a je to dobře

ThoughtWorks oznámili uvolnění platformy Go jako open source. Go realizuje myšlenky, které ThoughtWorks dlouhodobě razí tj. Continuous Integration a především Continuous Delivery. Samotné Go je zajímavé z několika úhlů pohledu. Přestože existuje celá řada CI serverů, s uceleným konceptem realizace Continuous Delivery zatím nikdo nepřišel až do představení Go - kolega to trefně nazval post Jenkinsovou érou. Go je postavený podle myšlenek a zkušeností, které popsali pánové Jez Humble a David Farley v knize Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation.

One size fits all vs. Lego

Jenkins se stal v mnoha firmách páteří Continuous Integration infrastruktury neboť nabízí velmi dobrou rozšiřitelnost. Existuje celá řada rozšíření, pomocí kterých můžete nad Jenkinsem vystavět prakticky jakýkoliv proces v oblasti testování a nasazení. Jenkins a jeho rozšíření představují Lego skládačku, ze které si postavíte cokoliv. Když vám náhodou nějaká funkcionalita chybí, můžete si jí naprogramovat. Díky Lego konceptu dostanete kostičky, které si musíte sestavit dohromady, aby dávaly dohromady požadovanou funkcionalitu. Bohužel neexistují v uvozovkách Lego stavebnice, které by obsahovaly jenom otestovanou sadu realizující konkrétní use case například Continuous Delivery. Lego koncept umožňuje teoreticky postavit cokoliv, ale prakticky, a to jsme si v GoodData vyzkoušeli mnohokrát, to je velmi nákladné a velmi křehké.

Náklady na skládání kostiček nesete nejenom na úrovni vývoje a testování výsledného řešení, ale i jeho udržování. Při vývoji si musíte nejdříve najít pluginy, pomocí kterých by šel váš scénář realizovat, zjistit jestli by spolu nějak mohly spolupracovat a potom je umě pospojovat dohromady. Prakticky jakýkoliv upgrade Jenkinse a nebo jednoho z jeho rozšíření může vést k tomu, že se celé řešení rozsype jako domeček z karet. Nezanedbatelnou roli hraje doménová znalost problému např. Continuous Delivery. Pokud nevíte co máte postavit, těžko to postavíte.

Doménová znalost Continuous Delivery a realizace jeho základních konceptů přímo v jádru systému je podle mého obrovskou výhodou Go oproti Jenkinsu. Go nabízí rozšiřitelnost, díky které můžete systém přizpůsobit vašim potřebám. Go mi dává smysl v tom, že se nesnaží profilovat jako další Continuous Integration server, ale jako realizace Continuous Delivery infrastraktury. Go nebude zcela určitě Jenkins killer, stále tu budou společnosti, které budou využívat jeho Lego vlastností v oblasti testovací infrastruktury a Continuous Integration.

Kdybych měl dnes znovu začít na vývoji platformy, kterou se v GoodData snažíme realizovat Continuous Integration/Delivery viz Evoluce Continuos Integration infrastruktury v GoodData, určitě bych jí začal stavět právě nad Go. Ušetřilo by nám to spoustu programování a práce s ohýbáním a laděním Jenkinse (pipeliny, propagování artefaktů, vizualizace a mohl bych pokračovat dál). S Go nemám žádné zkušenosti a možná se tahle implementace dlouhodobě neprosadí, ale koncept je krok správným směrem. Mimochodem dejte mi vědět pokud by vás práce s Go zajímala.

středa 26. února 2014

Příběh jednoho selhání, katarze a poučení v agile vývoji

Tohle je příběh jednoho selhání, katraze a poučení našeho týmu při doručování re-brandované login a registrační stránky. Mohl bych ho volně zařadit do série, říkat že dělám agile vývoj je rozdíl oproti tomu dělat agile opravdu, ale neudělám to, protože na tomhle selhání jsme se hodně naučili a přijali pár opatření, které náš tým posunuly. Moje poznatky v tomhle článku pochází z poznámek, které jsem si stačil udělat během retrospektivy. Skoro bych řekl, že se v tomhle příběhu zrcadlí několik ukázkových problémů, a proto o něm píšu. Na tomhle selhání se všechny zainteresované složky podílely přibližně stejnou měrou a protože proběhla retrospektiva, kde jsme bez emocí pojmenovaly všechny problémy a příjmuli opatření k jejich odstranění, můžu zde o nich psát aniž by se to někoho dotklo.


Dobrý úmysl dláždí cestu do pekel

Původně jsme chtěli jenom udělat re-branding login a registrační stránky do GoodData. Designer navrhl vizuální stránky a jeden vývojář měl zmapovat flows, pomocí kterých se může uživatel dostat na login a registrační stránku. Přestože si řeknete, že login a registrační stránka je jenom jedna, existují různé kontexty, ve kterých login stránka vystupuje. Namátkou , embedované módy, potvrzení registrace ,Single Sign On a jeho selhání, vypršení autentizační session atd. Od začátku jsme se nechtěli pouštět do předělání logiky těchto flows. Nakonec nás stála tahle sranda dva měsíce práce, nevrhla na nás úplně nejlepší světlo u vyššího managementu a trochu narušila vztahy s Product Management (zkráceně PM). Zpětně viděno, nasekali jsme několik ukázkových chyb, které v dobré víře vycházely z našeho přesvědčení, že zvolený přístup je správný.


Dělejte jenom to co musíte, ani o chlup více

Když někomu řeknete, že se pustíte do re-designu něčeho, dělejte skutečně re-design a nic dalšího. My jsme se v rámci re-designu pustili do upgradu na novější verzi knihovny Ember.js, přepisu kódu na tuto technologii, budování a ladění infrastruktury pro automatické testy v prohlížeči. Jinými slovy jsme se v rámci re-designu, to jest v chápání normálního smrtelníka maximálně změny CSS a HTML kódu, pustili do splácení technologického dluhu. To nás stálo plno času, který jsme nemohli trávit na vlastní funkcionalitě. Mixování funkcionality a splácení technologického dluhu je nebezpečné v tom, že se velmi těžko odhaduje jeho pracnost a dochází k vazbě mezi doručením funkcionality a umáznutím dluhu. Navíc se to dost špatně komunikuje - "no víte, už by to dávno bylo, ale musíme tady ještě pošolíchat testovací framework, abychom mohli otestovat X. No a ještě musíme něco udělat se stabilitou těch testů, protože teď ty testy vlastně nemají vypovídající hodnotu. A kdy to bude? To se dá těžko odhadnout...". Proto jsme zavedli pravidlo: splácení technologického dluhu děláme separátně od vývoje funkcionality a nespojujeme jej dohromady s vývojem nových vlastností.


Rozděl, ale i doručuj po částech

Celou práci jsme si rozdělili na několik logických kroků, podle kterých jsme chtěli postupovat. Doručení a předání bylo plánované, jako celek ovšem! Díky tomu jsme měli reálnou zpětnou vazbu až úplně na konci vývoje tj. po několika sprintech. Ze zpětné vazby vyplynulo, že je potřeba předělat například validaci, protože nevyhovovala use case. To docela pocuchalo nervový aparát celého týmu. Celá story byla zpožděná, čili všichni cítili tlak na její doručení, a hlavně všichni už byli přesvědčeni, že jsou v cíli a místo toho následovalo další kolečko vývoje.

Mám pocit, že týmy obvykle plánují práci způsobem, že výsledek je vidět až úplně na konci. Představte si, že máte silnici po které chcete nechat projet auto a v jednom pruhu leží balvan. Tým tedy naplánuje nejdříve odstranění balvanu a potom nechá projet auto. Pokud se vám ovšem nepodaří ten balvan odvalit, ohrozíte tím to hlavní, průjezd toho auta. Opačný přístup je nechat to auto projet v protisměru - přestože jenom dočasně. To je podlě mě správný přístup. Zavedli jsme proto pravidlo sprintu: doručit vždy něco, co si může zákazník osahat - minimální produkt (doručit minimální viditelnou změny pro zákazníka).


Můj zákazník můj pán

Dalším problémem představovalo předání, kdy nebyl přesně známý zákazník dané funkcionality. Docházelo k ping pongu mezi PM a týmem. Z jedné části PM znělo: ano jdeme, a z druhé části: nejsme spokojeni, je potřeba ještě upravit to a to. Docela dost to vyostřilo vztahy, protože vývojáři nevěděli, kdo je ten hlavní s kým komunikovat změny. Velký vliv mělo předání celé funkcionality v PM oddělení, a k problémům by zřejmě nedošlo, kdyby byl od začátku do konce za danou věc odpovědný jeden člověk z PM. Zavedli jsme proto pravidlo: během plánování sprintu se všichni shodneme na tom, kdo je zákazník - pro koho pracujeme.

< h3>Jedno prostředí

Vlastní předvádění zákazníkovi nám komplikoval fakt, že různé části měli vývojáři ve svých větvích. Demo a verifikace probíhala vždy na lokální verzi na stavu code base, kterou měl vývojář k dispozici. Při vlastním předvádění si zákazník nemohl vyzkoušet funkčnost jako celek. Pokud se někdo objevila chyba, nebylo zřejmé, jestli je to aktuální problém a nebo to je již v jiné větvi u jiného vývojáře vyřešené. Pro zákazníka je klíčové, aby měl jedno referenční prostředí, na kterém dochází k předání a kontrole odvedené práce. Zavedli jsme proto pravidlo: na akceptačním prostředí se dohodneme během plánování. Komplikovaný merge a chyby, které se projevily až po zamergování do hlavní vývojové větve, byly násobené změnami v infrastruktuře viz upgrade Ember.js. Asi by nám pomohl mainline development (integrační problémy jsou viditelné ihned), ale na to by bylo potřeba vyřešit procesní věci spojené s plněním Service Organization Controls 2.


Neznámé neznámo

Docela dost času jsme strávili analýzou existujícího kódu, abychom zjistili stavy, při kterých dochází k přechodu na login a registrační stránku. Vznikly flows, které nám měly pomoci pochopit, kam je potřeba šáhnout, protože jsme nejenom re-brandovali, ale přepisovali inkriminované části na novou technologii a psali nové testy. Ne že by nám flows nepomohly, ale to co přinesly neodpovídalo investovaným nákladům. Neodhalily například krajní případy, ze kterých na nás během manuálního testování vypadlo větší množství chyb. Analýza nám určitě pomohlo pochopit, co všechno budeme muset otestovat, ale z pohledu odhadu pracnosti byl její přínos zanedbatelný. Shodli jsme se na tom, že mnohem více by nám pomohl opačný přístup - začít z jedné vody na čisto s minimálním produktem případně s variantou v podobě funkčního prototypu, který je rychlejší a poukáže na problémy stejně dobře. I prototyp totiž můžete někomu ukázat a nechat ho ošahat. Analýza jsou slova a slova jsou vítr jak věděl Jon Snow a sním všichni čtenáři pentalogie Píseň Ohně a Ledu. Prototyp lépe pomáhá odhalit problémy, které by vás během analýzy nemusely napadnout - neznámé neznámo, nevím že existuje proto jej ani nemůžu analyzovat.



Strategie

Žádný plán nepřežije první dotek s nepřítelem, jak pravil von Moltke, to ale neznamená, že by neměla existovat strategie, jak řešit situace se kterými ze začátku nepočítám. Ve chvíli kdy se objevily nějaké problémy, neexistoval postup jak se z nich vymotat. Strategie může být: "dodávám malé kousky, které na několikadenní bázi ukazuji zákazníkovi. Změny přijímáme operativně na základě trvalé zpětné vazby ze strany zákazníka. Pokud se najde problém, který nedokážeme vyřešit z časových důvodů nebo je to velká změna do zadání, vyřešíme to během dalšího sprintu jako navazující úkol." My jsme žádnou strategii neměli, protože celý úkol byl pojatý jako monolit na všech úrovních - plánování, vývoj, testování, předání atd. Strategie, a teď myslím strategie vývoje té vlastnosti, by nás mohla donutit snažit se ten monolit rozsekat již při plánování.


Závěr

Když to shrnu do pár základních pravidel, na kterých jsme se shodli na základě retrospektivy.

  • Doručujeme něco viditelného co si může zákazník ošahat v každém sprintu
  • Během plánování zná celý vývojový tým, kdo je zákazníkem resp. kdo hraje jeho roli
  • Při plánování určujeme strategii vývoje tj. teď uděláme X a další sprint Y
  • Neděláme detailní plán, protože stejně nepřežije první dotek s realitou
  • Při plánování se zákazníkem dohodneme na akceptačním prostředí
  • Nemícháme infrastrukturu do vývoje nových vlastností

neděle 16. února 2014

CZ Podcast 93 a 94 - Rekapitulace a Virtualizace

93. byla rekapitulační, s Filemonem jsme se ohlédnuli za rokem 2013 a do 94. si naše povedená trojička pozvala Igora Kopřivu a tématem byla virtualizace a fakt to stojí za poslechnutí.

sobota 15. února 2014

Podpořte si kreativní myšlení jednoduchými triky

Piš opilý, reviduj střízlivý, tuhle poučku jsem četl v knize Andyho Hunta Pragmatic Thinking and Learning: Refactor Your Wetware v kapitole věnované stimulaci kreativního myšlení. Lidský mozek má dvě hemisféry - levou a pravou [1]. Každá z těchto hemisfér má na starosti jinou činnost a krom toho se ještě chovají mírně odlišně. Levá hemisféra je zodpovědná více za verbální, analytické, abstraktní a logické úkoly. Její způsob práce by odpovídal synchronnímu zpracování, který známe z počítačového světa - vložíte úkol, počkáte na jeho zpracování, dostanete výsledek, vložíte další úkol, počkáte na jeho zpracování dostanete, výsledek a tak pořád dokola [2]. Oproti tomu pravá hemisféra je neverbální, umožňuje rozpoznávat vzory vcelku, používá analogie k rozpoznávání vztahu mezi věcmi, je intuitivní - schopnost vytvářet vnuknutí na základě neúplných vzorů. Její fungování by odpovídalo asynchronnímu zpracování, zjednodušeně - vložíte úkol, na nic nečekáte a jdete na další, někdy v budoucnu dostanete výsledek.


Pokud levá hemisféra funguje v módu command and control a dokážeme ji ovládat, pak pravá hemisféra funguje přesně naopak a nemáme nad ní úplně kontrolu. Pokud vytížíme levou hemisféru - většina z nás to dělá většinu pracovního času, protože levá hemisféra je takzvaně analytická - potlačíme tím funkci pravé hemisféry. Občas se mi stává, že usilovně pracuji na nějakém problému a nemůžu se dobrat řešení, a v úplně nesouvisející okamžik - například doma ve vaně - mě bez zjevné příčiny napadne jeho řešení. V tu chvíli nebyla potřeba levá hemisféra a pravá hemisféra mohla převzít kontrolu. Pravá hemisféra je klíčová pro intuici a kreativní myšlení, ale nemůžete jí ovládat jako tu levou. Jinými slovy nejde si říci a od teď budu myslet kreativně. Na druhou stranu existuje pár způsobů, jak potlačit levou hemisféru a nechat vyniknout pravou hemisféru a psát opilý a revidovat střízlivý je jenom jednou z nich. V tomhle článku uvedu pár způsobů, které stimulují mé kreativní myšlení

Monotónní nenáročná fyzická činnost

Víte jaký je rozdíl mezi bludištěm a labyrintem? V bludišti musíte hledat cestu ven, labyrint vás vede ven sám. Labyrint je skvělý v tom, že jakmile do něj vejdete, nemusíte přemýšlet o tom jak se dostanete ven. Zatímco procházíte labyrintem, vaše levá hemisféra nemusí dělat vůbec nic a pravá hemisféra najednou dostane prostor a může začít pracovat. Není překvapením, že labyrinty se stavěly v blízkosti center vzdělanosti např. kláštery, protože umožňovaly tehdejším učencům rozjímat [3.]. Labyrint jsem nezkoušel, ale procházka u mě spolehlivě funguje a levou hemisféru se mi daří "vypnout" při jakékoliv monotónní nenáročné fyzické činnosti. Rád bych zdůraznil, že to musí být monotónní a nenáročná - jak fyzicky tak psychicky - činnost např. hrabání listí nebo sekání trávy. Mám vyzkoušené, že když se z monotónní nenáročné stane náročná, např. běh ve vyšší tepové frekvenci, kontrolu převezme opět levá hemisféra.


Podpořte vaší hodinu

Každý z nás preferuje jiné denní období, kdy cítí, že mu to nejvíc myslí - ranní a noční ptáci. Přizpůsobte tomuto období vaší aktivitu. Já jsem například ranní pták a mám vypozorováno, že asi nejvíc nápadů jsem dostal ráno během procházky z cvičení do práce - efekt vypnuté hlavy, levá hemisféra není potřeba. Jistý vliv může mít to, že si před cvičením v MHD čtu. Během té chůze mi krystalizují nápady, které mohou být ovlivněné tím, co jsem četl. Proto je důležité být připraven udělat si poznámky viz dále.



Jiná kreativní činnost

Jako skvělý stimulátor působí jiná kreativní činnost. Dost věcí mě napadlo nebo vzniklo jako vedlejší efekt hackathonu. Vzal jsem prostě nápad, který jsem si dříve zaznamenal a během jeho rozpracování mě napadlo něco dalšího a tak jsem si to opět poznamenal. V mém případě je spouštěčem jiná kreativní činnost. Pokud nebude dělat něco kreativního těžko budete kreativně myslet. Sezením u televize vás nic nenapadne.


Vždy připraven

Protože pravá hemisféra a tedy intuice a kreativity pracuje více méně nahodile, je potřeba si nápady a myšlenky zaznamenat právě ve chvíli kdy k tomu dojde. Já osobně sebou nosím mobil namísto papírového zápisníku a tužky. Protože mám všechny zařízení od Applu, zapisuji si vše do Notes, které se mi přes iCloud synchronizuje na všechny zařízení. Když mě třeba během procházky do práce napadne něco zajímavého, vždycky si to poznamenám na mobilu a než dojdu do práce, už to mám k dispozici na počítači, kde se k tomu mohu kdykoliv vrátit.Tímhle způsobem vznikly poznámky nejenom k tomuto článku, ale i podklady pro řadu dalších článků na tomto blogu. Často si zaznamenávám i zdánlivé maličkosti, které mi vyvstanou v mysli, ty později spojím a dále rozpracuji. Věřím tomu, že kdybych si je nepoznamenal, byly by nenávratně ztraceny v toku mých myšlenek. Samozřejmě vám může vyhovovat jiný technologický nástroj, nabízí se Evernote, ale ať již to bude cokoliv, je důležité mít ho neustále při sobě, abyste si mohli udělat poznámky v jakoukoliv chvíli.


Odkazy Pragmatic Thinking and Learning

[1.] Označení na levou a pravou část mozku je pouze symbolické a používá se v psychologii, strana 70. Left brain vs. Right brain

[2.] Characteristics of L-mode Processing, strana 71.

[3.] Harwest R-Mode cues, strana 112.


neděle 2. února 2014

Proč je dobré konzumovat psí žrádlo aneb jak si kdo ustele...

V angličtině se tomu říká eating your own dog food, v češtině používáme pořekadla co sis navařil, to si taky pěkně sníš a nebo nápaditější jak si kdo ustele, tak si i lehne. Tyto fráze popisují nejčistší možnou zpětnou vazbu, kterou můžete dostat. Zpětná vazba je klíčovým faktorem v zdokonalovacím procesu jakékoliv činnosti a při vývoji software to platí ještě více. V tomhle článku vám zkusím vysvětlit, proč je potřeba na eating your own dog food neustále myslet a proč je jedním ze základních pravidel psaní cynického software.


Slabá vs. Silná zpětná vazba

Když jsem před lety pracoval pro Hewlett-Packard, software, který jsme vytvářeli, byl instalován přímo zákazníky. Zákazník dostali CD/DVD a manuál, podle kterého jejich systémoví administrátoři provedli instalaci. Jestli se ten software vůbec používal, případně jakým způsobem, se k nám nikdy nedostalo. Byly to šťastná doba mého života, protože jsem nemusel žít s plody vlastní práce. Doslova a do písmene, žil jsem ve sladké nevědomosti. Tomu říkám slabá zpětná vazba. O pocit vlastní dokonalosti z dobře odvedené práce jsem začal přicházet během mých začátků v GoodData. Zlomový okamžik si pamatuji naprosto přesně. Seděl jsem zrovna s kamarádkou v oblíbené řecké restauraci a u druhé lahve výborného vína mi začal kolem půlnoci zvonit mobil. Představy o příjemném zbytku večera vzaly za své během letmého pohledu na jméno volajícího. Pokud vám o půlnoci volá šéf operations málokdy to věstí radostné noviny. Už si přesně nevzpomínám na příčinu problému, který jsem způsobil, ale během přebíhání potemnělého Žižkova směrem do našich kanceláří v Karlíně jsem si uvědomil, že co jsem si navařil, to si taky pěkně vyžeru. Silná zpětná vazba, s trochou nadsázky řečeno: i po letech mě ten večer mrzí.

Rozdíl mezi GoodData a jinými společnostmi a projekty, na kterých jsem do té doby pracoval, byl v tom, že jedna verze software - pravidelně se aktualizující každých 14 dní - sloužila všem zákazníkům. Pokud jste tedy udělali chybu, byla to většinou chyba, která se obvykle projevila u všech zákazníku v jeden okamžik a to většinou hned. Kromě nočních zásahů byl dalším důležitým faktorem ovlivňujícím zpětnou vazbu přechod z organizačního modelu s takzvanými sily - jedno oddělení GoodData vyvíjelo a jiné GoodData provozovalo - na model DevOps, kdy máme sobestačné týmy vyvíjející a provozující části GoodData. V modelu se sily docházelo u lidí z operations k neurotickým změnám v chování před každým releasem. Zatímco vývojáři měli snahu všechno doručit za 14 dní do konce sprintu v modus operandi commit a děj se vůle boží, administrátoři nechtěli prakticky povolit jakoukoliv změnu, která by měla jakkoliv byť jen hypoteticky narušit jejich již tak značně nalomené psychické zdraví.

Po přechodu do DevOps modu, kdy se náš tým začal starat nejenom o vývoj, ale i provoz naší části systému jsem začal jejich výtky chápat. Kromě drobností, jako bylo nedostatečné logování, jsem velmi rychle pochopil, jaký je rozdíl mezi dodat software a dodat provozuschopný software. Tahle zkušenost vedla k tomu, že tým najednou začal mnohem více koukat administrátorskýma očima a snažil se vymyslet, jak by se administrační úkoly daly co nejvíce zefektivnit. Tam kde jsme dříve administrátory odháněli mávnutím ruky, s tím že na to bude nějaké API, si dneska děláme management nástroj s grafickým rozhraním. Stačilo se jenom párkrát vykoušet, jak se některé úkoly dělají našemu administrátorovi přes ruku.


Proč je dobré býti konzumentem

Sníst si co jste si navařili je dobré nejenom v případě provozu software, který sami produkujete, ale prakticky pokaždé když existuje oddělení rolí producenta a konzumenta. Jedním z těch případů, který jsem několikrát zažil na vlastní kůži, byl vývoj frameworku. Tým A zodpovědný za dodání frameworku, a tým B za jeho používání. Asi nejhorší možný setup. Tým A chce po týmu B, aby přesně definoval požadavky. Tým B to s větším či menším úspěchem udělá. Tým A to podle požadavků vyprodukuje, případně si to alespoň myslí, a výsledek předá týmu B. Tým B začne framework používat a dochází k frustraci. Tým A sice vyprodukoval to co po něm tým B chtěl z funkční stránky, ale z hlediska použitelnosti to byla katastrofa. Tým A nevěděl přesně, jak to bude tým B používat. Bohužel to často nevěděl ani tým B. To je jeden z důvodů, proč by tým, který produkuje nějaký framework, měl být jeho prvním konzumentem.


eating your own dog food má jeden velmi důležitý efekt, který se projeví prakticky ihned. Lidé a týmy jsou daleko více vtažení do hry řečeno sportovní terminologií. Vývojáře přece jenom daleko více baví pracovat na něčem co sami používají. Začíná fungovat vnitřní motivace. Najednou přestanou výmluvy typu: to v zadání nebylo. Tým aktivně hledá místa, kde by se systém dal vylepšit, a přebírá z části roli zákazníka.


Jak začít konzumovat vlastní jídlo

Na závěr pár rád, které jsou jednoduché, ale hlavně tu první hodně týmů často z nepochopitelných důvodů ignoruje.

  • Začněte používat produkt, který sami vyvíjíte. Platí pokud je to alespoň trochu myslitelné.
  • Roztrhněte stereotyp konzument a producent a snažte se o vzájemné prolnutí těchto rolí. Platí to nejenom ve vztahu vývoj a provoz software, ale i pro design a vývoj, vývoj a používání.
  • Pokud nemůžete tento stereotyp roztrhnout, alespoň ho z části naleptejte viz DevOps a nebo rotace lidí v rolích. Dostaňte vývojáře blíže k zákazníkovi. Pokud je nemůžete nechat přímo komunikovat, zahrňte je třeba do řešení support tickets.

úterý 21. ledna 2014

CZ Podcast 92 - Reaktivní programování

Hostem tohoto dílu je Aleš Roubíček a tématem reaktivní programování. Věnovali jsme se základním architektonickým kamenům tohoto přístupu - responsivnosti, škálovatelnosti, odolnosti a událostnímu modelu. Vaše ohlasy očekáváme na naší fanouškovské stránce.

CZ Podcast 91 - Agile a retrospektivy

V tomto díle jsme se opět vrátili k Agile. Hostem dílu je Zuzana Šochová, kterou jsme vyzpovídali z jejích zkušeností ze zavádění Agile a koučování. Věnovali jsme se i retrospektivám jako základnímu stavebnímu kamenu Agile přístupu.

neděle 19. ledna 2014

Kniha The myths of innovation

Jsou knihy, ve kterých můžete listovat tam i zpět a stále nacházet nové a nové zdroje inspirace. Kniha The Myths of Innovation od Scotta Berkuna je přesně jednou z nich. Hlavním tématem je inovace a mýty, které se k ní vážou. Každý z nás dokáže inovovat - vytvářet zásadní pozitivní změny - a tato kniha vás o tom přesvědčí pomocí zboření deseti největších mýtů. Její přečtení bych doporučil nejenom pokud je vaše práce alespoň trochu kreativní, ale i pokud máte pocit zkostnatělé nudy.


Božské vnuknutí

Mnoho lidí věří, že geniální nápady, vynálezy - zvolte si vhodný termín - jsou věcí božského vnuknutí. Pro příklad nemusíme chodit daleko. Co mi odpovíte, když se vás zeptám, jak objevil sir Isaac Newton gravitaci? Většina z nás má ještě z dob ve školních lavicích zafixovaný příběh s jablkem dopadajícím na hlavu. Faktem zůstává zbývajících dvacet let práce, které sir Isaac Newton věnoval studiu hvězd, pozorování planet a vůbec přírody. Příhoda s jablkem uspokojuje romantismus v našich srdcích, ale těžko ji můžeme považovat za hlavní událost vedoucí k objeveni gravitace. To se mimochodem zabývali už egypťané. Jestli mají inovace něco společného, pak je fakt, že nikdy nevzniknou na základě božského vnuknutí. Místo romantismu spíš očekávejte nekonečné hodiny tvrdé práce omylů a drobných úspěchů.

Nearly every major innovation of the 20th century took place without claims of epiphany. The World Wide Web, the web browser, the computer mouse, and the search engine — four pivotal developments in the history of business and technology — all involved long sequences of innovation, experimentation, and discovery.


Rozumíme historii inovace

Tenhle mýtus spočívá v tom, že pohledem do historie se zdá být všechno jasné. Vezměte si například příchod automobilů se spalovacím motorem. Z dnešního pohledu se zdá přirozené, že automobil byl dalším logickým krokem technické revoluce. Inovace není nikdy narýsovaná jako přímá čára, kterou vidíme pohledem historie. Inovace a její průběh je nepředvidatelný a závisí nejenom na technických atributech, ale i na těch ekonomických.

Existuje zaručený způsob inovace

The myth of methodology, in short form, is the belief that a playbook exists for innovation and it removes risk from the process of finding new ideas

Žádný zaručený způsobe neexistuje. Existují jenom různé vstupy, které slouží jako iniciátor inovací.

  • potřeba - něco konkrétního bylo potřeba, ale nebylo to k dispozici. Inovátor byl řízen vlastní potřebou. Pěkným příkladem je McDonald ... The founders of McDonald's developed a system for fast food production to simplify the management of their local homespun hamburger stand.
  • peníze a bohatství - The founders of many great companies initially planned to sell their ideas and designs to larger corporations but, unable to sell, reluctantly chose to go it alone. Google tried to sell to Yahoo! and AltaVista, Apple to HP and Atari, and Carslon (photocopier inventor) to nearly every corporation he could found.
  • vedlejší efekt - vynálezce mikrovlné trouby Percy Spencer pracoval na vývoji radaru. Při práci na tomto zařízení se stalo něco zvláštního, v kapse měl tyčinku, která se roztekla. Protože to byl člověk zvídavý, nedalo mu to a začal experimentovat. Nejdříve zkusil co se bude v blízkosti radaru dít s kávovými zrnky. Když zjistil, že se upražila, začal pátrat po příčinách a později experimentovat s mikrovlným zářením. Trvalo další dva roky, než došlo k uvedení první mikrovlné trouby.
  • zajímavost/hoby - příkladem je Linux Curiosity Many innovations begin with bright minds following their personal interests. The ambition is to pass time, learn something new, or have fun.

Lidé milují nové nápady

The love of new ideas is a myth: we prefer ideas only after others have tested them. We confuse truly new ideas with good ideas that have already been proven, which just happen to be new to us.

Čím více přelomový nápad je, tím je větší bariéra pro jeho přijetí. Lidé nemají rádi změny pokud k ním nemají dobrý důvod. Je to od nás chytré, nikdo z nás nechce sloužit jako pokusný králík. Proto čteme různé recenze a hledáme na internetu zkušenosti a doporučení.

We reuse ideas and opinions all the time, rarely committing to the truly new. But we should be proud; it’s smart. Why not recycle good ideas and information? Why not take advantage of the conclusions other people have made to efficiently separate what’s good and safe from what’s bad and dangerous? Innovation is expensive: no one wants to pay the price for ideas that turn out to be not quite ready for prime time.

Překonání strachu ze změny je jednou z věci, se kterou musí inovátoři bojovat. A je úplně jedno jestli se jedná o řešení hladomoru v Africe a nebo zlepšení vašeho vývojového procesu.

How much effort is required to transition from the current thing to the innovation? If this cost is greater than the relative advantage, most people won’t try the innovation. These costs include people’s value systems, finances, habits, or personal beliefs. Rogers describes a Peruvian village that rejected the innovation of boiling water because of cultural beliefs that hot foods were only for sick people. You could argue all you wanted about the great benefits of boiling water, but if a religious or cultural belief forbids it, you’re wasting your breath. Technological compatibility is only part of what makes an innovation spread: the innovation has to be compatible with habits, beliefs, values, and lifestyles.


Osamělý vynálezce

Představa vynálezce, který někde o soli a kůrkách v temné místností s chaotický poházenými papíry, udělá o samotě velký objev, je více romantická než reálná. Všechny dnešní inovace jsou založené na inovacích již existujících. Často si inovaci asociujeme s konkrétním člověkem, produktem nebo firmou, ačkoliv ta inovace nebo produkt již existoval před dlouho dobou. Určitě jste se alespoň jednou účastnili učené dišputace na téma, jestli je lepší Android nabo iPhone, kdo koho vykradl nápady a kdo byl první. Ve skutečnosti asi nikdo z nich, jenom protože se staly dominantními, máme tendenci si s nimi vše asociovat. Mobilní telefon nebo osobní počítač vznikl na základě mnoha a mnoha inovací, které se udály v minulosti.


Dobré nápady je těžké najít

Lidé jsou od přírody kreativní bytosti, bohužel systém ve kterém žijeme kreativitu spíše potlačuje. Mýtus je v tom, že je dobré nápady těžké najít. Ne není, problém je v tom, že většinou neděláme nic pro jejich nalezení. Kreativita většiny končí složením nábytku z IKEA.


...advance of civilization, creativity may have moved, for many, to the sidelines. Idea reuse is so easy — in the form of products, machines, websites, and services — that people are enabled to go for years without finding ideas on their own. Modern businesses thrive on selling prepackaged meals, clothes, holidays, entertainments, and experiences, tempting people to buy convenience rather than make things themselves. I don’t believe everyone should make everything themselves, or even most things. But I do believe everyone has the capacity to enjoy creating something, and the temptation for convenience inhibits many people from discovering what it is they’d like to make. Passive consumption of television and the Web has absorbed time we could be using for active hobbies and pastimes, age-old places for nurturing our creative selves.


Einstein said, “ Imagination is more important than knowledge,” but you’d be hard-pressed to find schools or corporations that invest in people with those priorities. The systems of education and professional life, similar by design, push the idea-finding habits of fun and play to the corners of our minds, training us out of our creativity. We reward conformance of mind, not independent thought, in our systems — from school to college to the workplace to the home — yet we wonder why so few are willing to take creative risks. The truth is that we all have innate skills for solving problems and finding ideas: we’ve just lost our way.


Váš šéf toho ví o inovacích víc

V knize je uvedený pěkný příklad. Myslíte si, že by nějaký skvělý inovátor, dokázal dosáhnout stejného úspěchu, kdyby musel pracovat ve vašem prostředí. Představte si Steva Wozniaka, jak se musí prokousávat byrokracií vaší společnosti. Pokud si myslíte, že by byl se svými inovacemi odsouzen k nezdaru, jaká je šance, že vám se to podaří. Obecně inovacím nepřeje prostředí s modus operandi command and control.

Despite how progressive some modern management programs are, their roots are in a tradition most unkind to innovation. Management as a discipline is steeped in an old-school command and control attitude that is alive and well in the Internet Age.

U popisu kreativního prostředí, mě zaujalo, že autor došel prakticky k tomu samému, co jsem četl v Team Geek viz moje recenze. Proto to zrekapituluji jenom v bodech: učení se z chyb, skládání týmu, ochrana týmu, podpora myšlenek.

Nejlepší nápad vyhrává

V historii inovací najdete naopak mnoho příkladů, kdy nejlepší nápad nevyhrává. Naopak vyhrávají nápady nebo spíše jejich realizace, které nejlépe v daný moment splňují kulturní, ekonomické a politické faktory.

The goodness or newness of an idea is only part of the system that determines which ideas win or lose. When we bemoan our favorite restaurant going out of business (“But they make the best cannelloni!”) or why our favorite band can’t sell albums (“They have the best lyrics!”), we’re focusing on a small part of the picture that affects us personally, which is only one factor in the circumstances determining its fate. These environmental, or secondary, factors have as much influence as the quality of the idea, talent, or innovation itself.

Problém a řešení

Nevím jak hodně je to mýtus, ale v této kapitole se autor věnuje rozdílu mezi problémem a řešením. Mýtus možná v tom, že všichni inovátoři strávili velkou část nikoliv řešením problému, ale jeho studiem a definicí. Hodně často se setkávám s opačným přístupem, kdy řešíme problém který neexistuje a nebo je důsledkem jiného problému. To vede většinou k velkému zklamání. Pokud dokážeme problém definovat, dokážeme hledat i cesty k jeho řešení.

Discovering problems actually requires just as much creativity as discovering solutions. There are many ways to look at any problem, and realizing a problem is often the first step toward a creative solution.

Inovace je vždy prospěšná

Když bratři Wrightové provedli první let se strojem těžším než vzduch, jenom těžko mohli tušit, jaký dopad bude mít jejich vynález na ozbrojené konflikty a nepřímo na zabíjení lidí. Inovace jsou vždy někomu prospěšné a často se to během doby mění. Každá inovace má svojí negativní stránky. Osobní počítače, veskrze vynález prospěšný, mohou vést ve formě odpadu k velkému znečištění planety.


This is an essential paradox of innovation: no one knows, not even the inventors, how their creations will impact the world until they are used.

Závěr


Největší hodnotu knihy vidím v tom, že mi otevřela oči. Inovace a kreativita nejsou činností pro vyvolené. Každý člověk je schopen inovovat a kreativně řešit problémy a je na každém jestli ten dar využije či nikoliv. Historie inovací je toho důkazem.




sobota 11. ledna 2014

Eclipse, IntelliJ IDEA a má cesta tam a zase zpět

Jsou dva způsoby, jak přitáhnout pozornost k článku, buďto použijete bulvární titulek a nebo uděláte bulvární tweet s odkazem na ten článek. Já jsem původně nechtěl ani jedno ani druhé, ale nakonec se mi podařilo obojí. Když k tomu připočítám téma, IntelliJ IDEA a Eclipse, které je mezi vývojáři podobně vyhrocené jako situace na Blízkém východě, jsem už na poměrně tenkém ledě a v situaci, do které jsem se nechtěl dostat. Po více než šesti měsících každodenního používání jsem se rozhodl opustit IntelliJ IDEA a vrátit se zpět k Eclipse a v tomhle článku vám vysvětlím proč.


Jak jsem se dostal k IntelliJ IDEA

K IntelliJ IDEA jsem se dostal dílem náhody a dílem okolí. Skoro všichni kolegové přešli z Eclipse na IntelliJ IDEA a ohromě si to pochvalovali. V určitou chvíli mi přestalo v Eclipse fungovat stahování zdrojových souborů k Maven artefaktům. Po jedné z těch security změn, které rozhodně nic nemůžou rozbít chlape, začalo HTTPS spojení do firemního Maven repa vyžadovat podporu SNI. Z tohoto důvodu bylo potřeba nahradit jednu knihovnu, kterou Maven používá pro HTTP komunikaci. To se jednoduše udělá pro Maven, který vám někde leží na disku, ale mnohem hůře se to děla v Mavenu, který je v Eclipse jako OSGi bundle. Strávil jsem tím nějaký čas a nepovedlo se mi to. Jenom podotýkám, že Eclipse je sice schopný používat externí Maven pro určité úlohy, ale pro resolving závislostí se vždy používá embednutý Maven.

Všichni kolegové s IntelliJ IDEA v mém okolí svorně tvrdili, že jim tenhle use case funguje. Řekl jsem si, že občas je potřeba opustit zónu komfortu, abyste se posunuli někam dál a něco nového se naučili. Když se sečetly všechny tyhle důvody - nefunkční stahování zdrojových souborů, výborné reference, touha naučit se něco nového - nebylo moc o čem přemýšlet. Rozhodl jsem se, že začnu IntelliJ IDEA používat. Přirozeně jsem se od prvních okamžiků neubránil pocitu porovnávání s Eclipse a proto jsem si dělal poznámky, které se staly základem pro tento článek.


Proč jsem se vrátil zpátky

IntelliJ IDEA i Eclipse jsou výborná vývojová prostředí s přibližně stejnou výbavou vlastností a udělátek, které tu více a tu méně vývojář upotřebí. Ve chvíli, kdy začnete tyhle IDE srovnávat, dopouštíte se nevědomky faulu na jednom nebo na druhém. Pochopil jsem to ve chvíli, když mi došlo proč mi IntelliJ IDEA nevyhovuje. Každý vývojář má v IDE svůj osobitý styl práce a buďto mu do něj IDE vyhovuje a nebo nikoliv. Můžete například říci - teď fábuluji - IntelliJ IDEA má lepší podporu práce s XML. To je ovšem nepodstatné pro vývojáře, který viděl XML naposledy během kurzu na J2EE před deseti lety a od té doby píše Java aplikace pro embedovaná zařízení. Vazba mezi stylem práce a IDE je ovšem obousměrná. Pokud začnete programovat s Eclipse, bude váš styl práce ovlivněný tím, na co si v Eclipse zvyknete. Při přechodu mezi IDE pak logicky srovnáváte, jestli váš styl práce funguje stejně komfortně. Někdy může a někdy nemusí.


Můj styl práce nefungoval v IntelliJ IDEA optimálně nebo řekněme komfortně. V následující části se podíváme na ty body, které mi konkrétně nevyhovovaly. Předesílám, že něco z toho chování, které mi vadilo, šlo možná překonfigurovat v samotném IDE, ale já jsem to buďto nedokázal a nebo se to nechovalo přesně tak, jak jsem si představoval.


Hlavní překážky

Na co jsem si i přes velkou snahu nedokázal nikdy zvyknout. Tato část se nese v duchu toho co mě to v tom lepším případě iritovalo a v tom horším mě to nadzvedlo ze židle. Pojmu to s trochou nadsázky, aby to nebyla nuda. Autoři IntelliJ IDEA se za trochu humoru snad neurazí a pohoršeným fanatickým uživatelům tohoto jinak skvostného IDE se omlouvám.


Můj styl práce v IDE má několik stěžejních bodů. Většinu času jsem pouze v Java editoru, pracuji v rychlých iteracích - compile, test, refactor. Často kusy kódu vytvářím jako prototypy, které postupně obrušuje podle toho, jak se mi to hodí. Často pouštím testy a hlavně dost často mám jednotlivé části projektu v nekompilovatelném stavu, protože když pracuji na jedné třídě a jejím testu, nepotřebuji aby se mi kompilovaly i další části prototypového kódu. Hodně často používám code completion, aby pochopil API nějaké třídy a k tomu potřebuji instantně zobrazit její dokumentaci.


Kompilátor

Při prvním použití kompilátoru jsem měl pocit, že je zpět rok 2002 a já jako elév pracuji s JBuilderem - nechť odpočívá v pokoji. Kompilátor a jeho bezešvou integraci do zbytku IDE považuji za něco esenciálního. Dokážu se přenést prakticky přes cokoliv, ale pokud mám při použití kompilátoru pocit, že jsem se vrátil o dekádu zpátky - a to nikoliv u jedné z jeho vlastností - je něco špatně. Kdyby se takhle choval textový editor za 15$, zvedl bych obočí, ale u softwaru za 500$ mi to hlava nebere.

  • Compile on save. IntelliJ IDEA zdrojový kód kompiluje až když je to opravdu potřeba. Když v debug modu editujete třídu, uložíte jí a čekáte, že se s dalším průchodem kód v běžící JVM zaktualizuje, tak se nic nestane. Teprve potom, co si uvědomíte, že musíte třídu explicitně zkompilovat, vám IntelliJ IDEA milostivě nabídne reload třídy v běžící JVM.
  • Compile Proceed on error. Pokud máte v projektu kompilační chybu, a chcete pustit například test,pak máte smůlu. IntelliJ IDEA se snaží celý projekt nejdříve zkompilovat a to přestože ten test vůbec s kompilační chybou nesouvisí. Jak mi nějaká dobrá duše poradila na Twitteru, můžete z testovací fáze vyjmout závislost na kompilační fázi. To jsem s nadšením provedl, a pak jsem si hodinu drbal hlavu s tím, proč se mi nepoužívá aktuální verze třídy. Odpověď: chybí Compile on save - čili změněné třídy jsem musel vždy kompilovat explicitně. Pokud máte styl práce založený na tom, že refaktorujete částečně odladěné kousky kódu, je tenhle přístup vývoje předem odsouzený k záhubě.
  • Performance. Díky tomu, že se kompilace odkládá až na chvíli kdy jí opravdu potřebujete např. puštění testů, trvá logicky delší dobu, protože se musí zkompilovat všechny změn. Pokud kompilace jedné třídy o sedmi řádcích kódu s chybou trvá 2s - podle toho co hlásí samotné IDE - začne vás to dříve nebo později dost obtěžovat.

Kontextová nápověda

IntelliJ IDEA si dala za cíl, že se díky ní nejenom naučíte znát nazpaměť pořadí a význam parametrů v metodách, ale dokonce i jejich dokumentaci. Píšu System.out. dám ctrl+space v marné naději, že uvidím dokumentaci k jednotlivým metodám. Když najdu konečně tu kýženou metodu s pěti parametry a u třetího zapomenu jeho význam, očekávám, že to samé ctrl+space mi napoví minimálně jeho jméno. Bohužel první klávesovou zkratku, kterou se musíte naučit, je cmd+P pro zobrazení parametrů. Druhou neméně důležitou zkratkou je ctrl+J, kterou IDE přesvědčíte, aby vám ukázalo/obnovilo okno s Javadocem v závislosti na kontextu. Pro uživatele, který je zvyklý dostat celý kontext jedním a tím samým způsobem - code completion - je to dost frustrující. Obzvláště vás to štve při práci s API, které neznáte.


Drobnosti

Nic zásadního, co by nešlo vyřešit jinak, přesto drobnosti, které mě tu více tu méně rozčilovaly.

Favorizované statické importy

Pokud často píšete testy víte, že většina API jsou statické metody doslova na pár třídách (Assert, CoreMatchers, Mockito). V Eclipse si tyhle třídy můžete nastavit do code completion. IDE je potom automaticky nabízí a udělá statický import. Příklad - pokud v Eclipse napíšu v jakémkoliv místě kódu mock a vyvolám code completion IDE mi nabídne odpovídající metody z třídy org.mockito.Mockito, a pokud si nějakou vyberu, provede její statický import. Oproti tomu v IntelliJ IDEA jsem musel nejdříve tu třídu naimportovat a potom nechat danou statickou metodu staticky importovat.


Klávesové zkratky

Nevím z jakého důvodu, ale měl jsem pocit, že klávesové zkratky jsou z nějakého důvodu Windows centric a nerespektují zvyklosti operačního systému. Například zavření editoru pomocí cmd+F4, když v celém zbytku MacOS se používá cmd+W, je mírně řečeno zvláštní. Navíc některé klávesové zkratky jsou spíše cvičení na roztažení prstů než užitečným pomocníkem - ctrl+J (klávesnice MacBooku nemá pravý ctrl) pro refresh dokumentačního okna.


Chybějící Display okno v debugu

V Eclipse jsem si při debugovaní zvykl používat Display okno. To mi umožňuje psát kód, který potom provádím v debugovacím kontextu ve chvíli kdy mi debugger stojí na nějakém break pointu. V IntelliJ IDEA jsem měl něco podobného jenom s tím rozdílem, že to okno bylo vždy popup. To vás začne rozčilovat ve chvíli, kdy ten kód chcete provést s každým průchodem cyklu a vždy musíte ten popup vyvolat.


Celkové dojmy

IntelliJ IDEA je dobré IDE a dokázal jsem v něm i s těmi výhradami fungovat půl roku. Všechny zkušenosti v tomhle článku jsou ryze subjektivní. Umím si představit, že někomu jinému vadí/nevadí jiné chování a vlastnosti ať již jednoho nebo druhého IDE. IntelliJ IDEA mi přišla trochu více přeplácaná všemi možnými UI prvky než by bylo potřeba a trochu méně svižná. Navíc někdy se snažila být papežtější než papež, při rename rafactoru mi například přejmenovala nějaké nesouvisející výskyty řetězce, čehož jsem si vůbec nevšiml. Těch šest měsíců bylo dobrých v tom, že jsem se naučil nové IDE a zjistil, že v něm můžu bez velkých problému fungovat. Na druhou stranu, čím déle jsem v tom IDE trávil, tím více jsem měl dojem, že mi toho oproti Eclipse tolik nepřináší. Chtěl bych dodat, že jsem se poctivě učil klávesové zkratky, které by mi mohly práci urychlit. Později jsem si uvědomil, že to není chybou IDE, ale stylem mojí práce, který byl formován v Eclipse a v IntelliJ IDEA prostě nefunguje stejně efektivně.


V celém článku se odkazuji na zkušenosti s IntelliJ IDEA 13, kterou jsem používal v rámci Early Access Programu. Jenom pro pořádek dodávám, že stahování artefaktů z Maven repa vyžadujícího SNI v rámci HTTPS nefunguje ani v IntelliJ IDEA.