Rovněž je nutné upozornit, že celá problematika je velice provázaná a nelze tedy na jednotlivé hry pohlížet v izolaci. Takže i když zde budeme analyzovat jednotlivé hry, je nutné mít na paměti, že se odehrávají v rámci složitého korporátního života, kdy může být rozehráno mezi jednotlivými aktéry více her současně.

Rovněž musíme dopředu upozornit, že zde uvedený výčet her není vyčerpávající. Je rovněž možné, že jednotlivé hry mají v jednotlivých korporacích různé názvy a varianty a proto uvítáme jakoukoliv zpětnou vazbu od ctěných čtenářů, abychom mohli případné nedostatky doplnit.

Plechování prdele

Účel

Vytváření si krytí pro případ, že dojde k případným problémům a ke hře najdi viníka.

Jiný název

Krytí si zad

Typ

Obranná hra

Příklad

Odeslání emailu zúčastněným hráčům, že plánovaný postup hrozí problémem a že ho proto nedoporučujeme.

Motivace a použití

Plechování prdele je užitečná strategie pokud některý z protihráčů rozehraje hru najdi viníka. Pokud hráč před začátkem hledání viníka provedl plechování prdele, významně sníží pravděpodobnost, že hru najdi viníka prohraje. Plechování prdele je nutné provádět průběžně, kdykoliv hrozí hledání viníka. Tento fakt od hráče vyžaduje jistou předvídavost.

Zdůrazňujeme, že plechování prdele je nutné provádět před začátkem hledání viníka, pokusy o plechování prdele po zahájení hledání viníka jsou odsouzeny k neúspěchu.

V korporacích, kde není zvykem hrát hledání viníka, je obvykle zbytečné používat plechování prdele.

Možné protiútoky a obrana proti nim

popři fakta – pokud jsme plechování schopni doložit písemným důkazem, je protiútok hrou popři fakta obvykle neúčinný
nařčení z plechování prdele – plechování je možné kamuflovat upřímným zájmem o úspěch a s ním spojeným včasným varováním. V některých korporacích je plechování prdele natolik uznávanou hrou, že není potřeba ji kamuflovat.

Poznámky

Našemu kolektivu se nepodařilo najít původ malebného názvu této hry. Některé zdroje uvádějí, že je název vystihuje účinnost proti tomu, když vás chce někdo za něco .... kárat.

Interaguje s

najdi viníka, pošli mail, vytvoř zápis, přehoď ticket, založ ticket, popři fakta

Já mám totiž takový problém. Veliký problém. Peníze mě vůbec nemotivují. Jasně, rád si nechám za práci dobře zaplatit. Na můj pracovní výkon to ale nemá žádný vliv.

Takže musím hledat motivaci jinde. Abych byl přesný, ani ne tak jinde, jako spíše uvnitř. Programováním se živím, protože mě to jednoduše baví. Kromě toho, že můžu sedět v teple a nemusím zvedat nic těžkého, tak mě baví řešit zapeklité problémy, bavíme mě vymýšlet jak to dělat co nejlépe. Mám rád pocit, že jsem něco dokázal, něco vytvořil, někomu pomohl. To tvoření je pro mě hrozně důležité. To je důvod, proč se pořád držím kódování. Člověk může přetvářet myšlenky v něco, co se hýbe, občas i funguje a je to k něčemu dobré. Dobrá, nedá se na to sáhnout, ale tím lépe. O to je člověk svobodnější. Nemusí se babrat s ničím fyzickým, může přímo přetvářet myšlenky.

A myslím, že v tom nejsem sám. Spousta známých i kolegů dobrovolně pracuje o víkendech a dovolených protože je to prostě baví. To se ale máme, v práci děláme to co nás baví. Hurá. Hmm.

Jak to, že tedy nejsem šťastný a spokojený hypervýkonný pracant? Proč v práci věčně držkuju, šéfovi odmlouvám a jinak podvracím morálku? Protože mě neuvěřitelně ničí zabijáci motivace. Seznamte se tedy prosím s novodobými jezdci apokalypsy

Schůze a papírování

Pokud je kódování supersíla, pak jsou schůze kryptonit.

Všichni milujeme schůze, proto si na ně nosíme laptopy, abychom si potěšení ještě znásobili nějakým tím kódováním. O tom snad ani není potřeba mluvit, proto se přesunu k dalším položce v této kategorii, k papírování.

Teď, ve století ovocného netopýra už nepapírujeme papírově, ale elektronicky. O to hůř, papírování je mnohem snazší, takže toho člověk zvládne mnohem víc. Tady musím uznat, že k něčemu papírování může být dobré. Ale přimlouvám se za nějakou rozumnou míru. Zamysleme se občas, kolik nás to všelijaké vykazování, odškrtávání, předávání a čertví co ještě stojí a kolik nám to přináší.

Zmar

To mě přivádí k další kategorii a tou je zmar. Už je to pár let, co jsem dělal u jednoho nejmenovaného růžového telefonního operátora. Na produkci jsem dostal své první čtyři řádky kódu po šesti měsících! Moji radost z tohoto kolosálního úspěchu kalil fakt, že se tam to mé veledílo dostalo omylem. Od té doby už jsem se s takovým pocitem zmaru nesetkal. Ale je to klasický a oblíbený zabiják motivace.

Zkuste sami zavzpomínat, stalo se vám někdy toto? Na něčem makáte. Je to hrozně důležité. Zachrání to planetu od hladomoru. Vyhraje vám to důležitou zakázku. Vydělá balíky peněz. Je to fakt něco. Už je to hotové. Super, můžeme to nasadit. Cože marketing si to rozmyslel? Už to nepotřebujeme? Poprvé se s tím člověk smíří. Podruhé to taky nějak skousne, ale potřetí už vás to fakt srazí do kolen.

Vyrušení a multitasking

Dělám na něčem co mě fakt baví. Už to mám skoro vyřešené. Najednou na mě začne mávat kačer. To mi Adium signalizuje, že se mnou chce někdo četovat. To bude další obdivovatel, kterého můžu ohromit svoji genialitou a bezmeznými znalostmi. Bravurně mu odpovím. Ale i tak mi to pár minut zabere. Cože jsem to předtím dělal? Nevím. Nevadí, využiji vyrušení a kouknu do mailu. Cože, někdo na mě hodil bug? Critical. Hmm, vždyť je to v jiné komponentě. Něco jsem řešil. Co to vlastně bylo? Nemá cenu se k tomu vracet, za pět minut mám schůze a po ní oběd. Odpoledne to samé. Cože jsem to vlastně za dnešek udělal? Nevím.

Dneska jsem si schválně zapisoval co všechno jsem dělal, u dvacátého řádku, někdy ve dvě odpoledne mě to přestalo bavit. Co s tím? Někde mají vyhrazených deset minut v každé hodině na vzájemnou komunikaci. Kolega má v kalendáři vyznačené dopoledne, že nechce být vyrušován. Moc mu to nefunguje. Já vážně přemýšlím, že si to vyhlásím soukromě. Něco v tom smyslu, že pokud minuta nezačíná na 5 nebo hodina není větší než 13 tak nechci být rušen. Alespoň to posílí moji pověst excentrika. Nebo si pořídím klobouk neviditelnosti. Když ho budu mít na hlavě, tak budu předstírat, že tam nejsem. Hmm, abych to s tou svojí pověstí nepřehnal.

Povyšování

Každý je povyšován na úroveň své nekompetence.

Ano, pro mě je povýšení demotivující faktor. Jsem fakt divnej. Ale má to logiku, každá vyšší funkce sebou přináší více schůzí, papírování a vyrušení. Hloupě jsem se nechal jmenovat architektem a teď za to pykám. Zatracená ješitnost.

No, ještě jsem měl pár témat, která jsem tu chtěl rozebrat. Třeba trestání za dobré skutky, řízení metrikami a podobně. Padla z toho na mě ale nějaká chmura. Takže nechám doplnění seznamu na každém z vás.

Abych si spravil náladu, tak se zamyslím nad tím co dělat, když se v takové situaci ocitnete. Nejdůležitější je pokusit se to změnit. Štve vás něco? Tak to změňte. Že jste na to příliš malý pán? Ale jděte. Taky jsem si to myslíval, ale není to tak. Před pár lety jsem tu citoval pana DeMarca.

Osoba, která si nejvíce přeje přehodit tuto zodpovědnost někam výše je přesně tou osobou která ví, že by mohla tuto změnu uskutečnit, ale že to nebude jednoduché.

Zkuste to změnit ze své pozice. Když nevíte jak, tak se seberte, dejte si sraz se šéfem a proberte to s ním. Pak to s ním proberte ještě jednou. Pak znova. Pak pár týdnu počkejte. Pak ještě jednou. No a pak se to třeba pomalu změní.

Místo můžete změnit vždycky, ale věřte zkušenému fluktulantovi. Jinde to o moc lepší nebude. Bude to jiné, ze začátku to bude mnohem lepší, ale pokud jste šikovní, tak vás životní cyklus programátora stejně nemine.

Now stop for a minute and make your guess. Is it
a) 1
b) 10
c) 100
d) 1,000
e) 10,000
f) 100,000

Well, the right answer is that it depends. It depends on your CPU, hard drive, network connection, request size, number of concurrent connections, day of the week and other important factors.

Ok, so I will tell you that I am testing it on an old Lenovo laptop with Intel® Core™2 Duo Processor T8100, 4gigs of RAM and 7200rpm disc, running Linux Mint 11 64bit, Java 6 and Tomcat 7. No performance tuning whatsoever.

I am generating the load from the same machine using JMeter with 50 threads that send requests one after another without any sleep. Each thread sends 20,000 messages containg string "Test ${counter}" where counter goes from 1 to 500,000. Yes, I know that doing tests like this is stupid. Having the test client on the same machine is just wrong. To make it even more stupid, I am writing this article while running the test. On the same old machine, of course.

The data are read from the request reader, stored in a String and sent to Logback to be logged in a file. Nothing fancy. Yes, and I restart the JVM before each test. Another stupid thing. Now you have all the information you need. Make your guess, please.

It turns out that at the and Tomcat is processing ~5,000 request/second. JIT needs some time before it optimizes the code. If I re-execute the test without JVM restart, it gets to ~5,200 requests per second and it does not climb any further. Nice performance. 5,000 request per second.

In my configuration the bottleneck is clearly the CPU. Well, it's not surprising, JMeter eats half of it. I have also tried to run the test on a MacBook Pro with 8 cores and SSD drive. The throughput is around 22,000 requests per second. Yes, more the 20k requests even in such silly test. On the Mac, JMeter consumes more CPU than Tomcat.

As I have already admitted, my test setup is just wrong. If you want, you may make it better. The source code and the JMeter test are here. It's just one servlet and few implementation classes, each for different logging strategy (direct, null and using a queue). Feel free to take, change, deploy and test it as you wish. I will be glad to see your results.

import static net.javacrumbs.jsonunit.JsonAssert.assertJsonEquals;

...

assertJsonEquals("{\n" +
			"   \"test\":[\n" +
			"      1,\n" +
			"      2,\n" +
			"      {\n" +
			"         \"child\":{\n" +
			"            \"value1\":1,\n" +
			"            \"value2\":true,\n" +
			"            \"value3\":\"test\",\n" +
			"            \"value4\":{\n" +
			"               \"leaf\":5\n" +
			"            }\n" +
			"         }\n" +
			"      }\n" +
			"   ],\n" +
			"   \"root2\":false,\n" +
			"   \"root3\":1\n" +
			"}",
			"{\n" +
			"   \"test\":[\n" +
			"      5,\n" +
			"      false,\n" +
			"      {\n" +
			"         \"child\":{\n" +
			"            \"value1\":5,\n" +
			"            \"value2\":\"true\",\n" +
			"            \"value3\":\"test\",\n" +
			"            \"value4\":{\n" +
			"               \"leaf2\":5\n" +
			"            }\n" +
			"         },\n" +
			"         \"child2\":{\n" +
			"\n" +
			"         }\n" +
			"      }\n" +
			"   ],\n" +
			"   \"root4\":\"bar\"\n" +
			"}");

will result in

java.lang.AssertionError: JSON documents are different:
Different keys found in node "". Expected [root2, root3, test], got [root4, test].
Different value found in node "test[0]". Expected 1, got 5.
Different types found in node "test[1]". Expected NUMBER, got BOOLEAN.
Different keys found in node "test[2]". Expected [child], got [child, child2].
Different value found in node "test[2].child.value1". Expected 1, got 5.
Different types found in node "test[2].child.value2". Expected BOOLEAN, got STRING.
Different keys found in node "test[2].child.value4". Expected [leaf], got [leaf2].

Neat, isn't it?

Předpokládám, že se vám něco podobného také někdy stalo. Řešení zapeklitých problémů často člověka napadá, když na nich nepracuje. Při jízdě autem, ve sprše, při cvičení, na záchodě a i ve spánku. Někomu údajně přicházejí nápady ve snech, mě se obvykle zjevují hned po probuzení. Jednu dobu jsem se dokonce bál, že mě kolegové budou podezírat z toho, že nejsem tak neskonale geniální jak ve skutečnosti jsem. Že si budou myslet, že mám doma poradce, který mi všechno poradí. Večer nikdy nic nevím a ráno mám řešení. Podezřelé, není-liž pravda?

Samozřejmě nejsem první, kdo si toho jevu všiml, takže to tu nebudu moc rozebírat. V zásadě jsem si tu jen chtěl zaznamenat tuto radu.

Nemůžeš na to přijít? Tak vypadni od toho počítače a jdi dělat něco jiného.

Ideálně něco, u čeho se nedá myslet na programování. U mě je to těžké, na programování dokážu myslet skoro u všeho. Ale je pár věcí u kterých to nedovedu. Třeba kreslení. Nebo spánek. Někdo dokonce tancuje, ale tak špatně jsem na tom ještě nikdy nebyl.

A jsou to právě ty činnosti, které nás donutí to pustit z hlavy a po kterých nás to prostě napadne. Nevím čím to je. Psychologové si myslí, že to vědí, ale moc bych jim nevěřil. Pokud by vás snad zajímali detaily, tak si přečtěte Pragmatic Thinking and Learning, tam je to rozpitvané dost. Kdo nerad čte může si pustit video o Hammock Driven Developmentu.

Já už budu končit, musím vypadnout od počítače a vymyslet, jak přesvědčit šéfa, aby mě platil i za čas kdy spím.

Pokud je to jádro vašeho podnikání, dělejte to sami bez ohledu na cokoliv

Ano, Joel to jako obvykle věděl už deset let zpátky. Pokud máte něco, čím se odlišujete od konkurence, je NIH nezbytností. Takže, pokud se od konkurence odlišujete vychytaným UI, nemůžete na to použít stejné komponenty jako má konkurence. Pokud se chlubíte bleskovou rychlostí, občas vám nezbyde nic jiného, než si připravit vlastní Linuxovou distribuci. Pokud prodáváte databáze, musíte si kupodivu napsat vlastní databázi. Pokud jste Apple, tak si myslíte, že jste byli seslání shůry a pověřeni výrobou naprosto dokonalých věcí a musíte si dělat sami úplně všechno. A v tom je ten problém. Zatímco Apple si může dovolit navrhovat vlastní procesory, vy si to dovolit nemůžete.

NIH je neuvěřitelně drahý

Cokoliv si totiž vyvíjíte sami, je neuvěřitelně drahé. Opravdu neuvěřitelně. Fakt hodně. Představte si obrovitánské číslo. NIH je ještě mnohem dražší.

To nám je jako programátorům obvykle jedno, ale našim zákazník a zaměstnavatelům by to jedno být nemělo. Začíná to vývojem. Nejdřív vám to přijde jednoduché. Pak narazíte na pár hraničních případů, které jsou opravdu hnusné. No a nakonec vás dorazí změna požadavků, která vás donutí to přepsat. Jako všude jinde vývoje SW platí, že to jak to mělo vypadat, víme až když už je pozdě.

Vývojem to samozřejmě nekončí. Máme tu ještě dokumentaci a testování. Infrastrukturní kód se hrozně blbě testuje. Případy užití jsou obvykle špatně definovatelné, je tam spousta možností pro nečekané stavy a podobně. Často to nedokáže testovat nikdo jiný než programátor a programátoři jsou velmi špatní testeři.

Dále tu máme zaučování nových kolegů. Každý kdo chce u vás začít pracovat, se to musí naučit používat za vaše peníze. Když použijete existující technologii, máte velkou šanci najít někoho, kdo se to naučil za peníze vaší konkurence.

V neposlední řadě je tu údržba. Přicházejí stále nové a nové požadavky a vy pořád musíte platit někoho, kdo se o ten NIH musí starat. Často je to váš nejšikovnější člověk, kterého už dávno potřebujete na něco jiného.

Aby se všechno toto vyplatilo, musíte si být hodně jisti, že to opravdu nezbytně nutně potřebujete. Vyplatí se investovat hodně času a úsilí, a zjistit, jestli by se vám přeci jen něco existujícího nehodilo.

Hlavní je, opravdu se snažit najít něco, co by nám mohlo vyhovovat. I za cenu obětování některých požadavků. I když víme, že to není dokonalé. I když se bojíme, že nám to za pár let nebude stačit. I tak je velká šance, že existující technologie sice nebude super, ale bude vám prostě stačit. Jak říkají latiníci, bude good enough.

Dvakrát měž, jednou řež

Míval jsem kolegu, který říkával: "Každý, kdo se rozhodne napsat si vlastní knihovnu, by měl před tím desetkrát oběhnout barák, aby si to dobře rozmyslel." Takže ano, NIH je často nezbytný. Ale aby se vám vyplatil, musíte si být sakra jistí, že chápete kolik vás to bude stát a kolik vám to přinese.

Ještě jsem měl připravených pár historek o tom, jak i já, ač jinak dokonalý, k NIHu pravidelně nevědomky sklouznu. Ale tím bych ten článek jen zbytečně natahoval a zkazil bych si pointu. Teď slibuji, že už se o NIHu nebudu nějaký čas vyjadřovat.

Tento článek si bere za vznešený cíl poradit vám, jak se tomuto veskrze nechutnému trendu bránit. Za svých pár let práce v korporacích jsem se něco přiučil od zkušenějších kolegů, tak bych chtěl tuto moudrost předat dál.

Pro názornost si představme, že chceme napsat úžasný Nový Inovativni Hypernástroj (dále NIH). Je jedno jestli je to nová databáze, framework, distribuovaný systém nebo, pokud máte štěstí, vlastní operační systém. Následující rady jsou platné univerzálně.

Je to jednoduché / už jsme do toho hodně investovali

Nejlepší metoda je nikoho se neptat a pustit se do práce. Většinou se vám podaří na tom strávit pár týdnů, než si někdo všimne. Občas se ale přeci jen objeví nějaký šťoural, který se vás bude hloupě ptát proč nepoužijete něco existujícího. Zkuste ho odbít s tím, že to je jednoduchý problém, který za pár dní vyřešíte. Nejlepší na tom je, že to je pravda. Co může být těžkého na tom napsat si vlastní NIH? Člověk vašeho formátu a kvalit to musí mít hned. Když se vás za týden bude ptát, jestli už to máte, můžete mu popravdě říci, že už zbývá jen týden na vyřešení pár detailů. Už máte to hlavní, zbývá jen pár nezajímavých hraničních případů, které sfouknete levou zadní.

V této fázi nezapomeňte někoho přesvědčit, ať to začne produkčně používat. Ohromně vám tím usnadní testování. Nepotřebujete se zdržovat nudnými testy, udělají to za vás zákazníci. Navíc si tím připravujete půdu pro druhou fázi.

Ta se hodí po pár měsících vývoje, kdy už i vám začíná docházet, že jste pár věcí nedomysleli a že architektura měla být malilinko jiná. Je potřeba první verzi označit za prototyp, začít se divit že to někdo používá a celou situaci zachránit tím, že to předěláte. Málokoho napadne vám v tom bránit, vždyť už se do toho tolik investovalo. A vy můžeme v klidu začít psát verzi 2.0. Na té si většinou užijete ještě více než na té první. Při psaní první verze jste se jen tak rozkoukávali, při psaní druhé se můžete pořádně rozletět. Vždyť už jste vlastně experti. Musím ocitovat z článku o pozitivech efektu druhého systému

• Poprvé když používáte technologii nebo stavíte nový typ systému víte, že jste začátečníci a máte sklon k tomu být konzervativní
• Podruhé už máte zkušenosti. Víte co děláte. Už jste jednou uspěli, takže odhodíte zábrany a uděláte všechny věci, které jste se napoprvé báli udělat.

To zní jako skvělá příležitost k tomu si zaprogramovat.

Nikdo vám nedá tolik, kolik já vám můžu slíbit

Pokud pracujete ve větší firmě, je možné, že budete mít zdatné soupeře. Často se jim říká projektový manažer, architekt nebo dokonce zákazník. To je ta havěť, co nás nás nutí dělat všechny ty nezajímavé věci, které ona považují za důležité. Tito protivníci se nám často snaží bránit v naší kreativitě a snaží se nás donutit použít už existující řešení. Proti tomu je snadná obrana. Musíme využít jejich největší slabosti. Protivník totiž málokdy ví co vlastně chce. Například zákazníci jsou známí tím, že si navymýšlí spoustu věcí, které podle nich naprosto nutně potřebují. A to je naše šance. Představme si, že po nás podle chtějí analýzu toho, která stávající technologie by jim vyhovovala. S naprosto čistým svědomím můžeme říci, že žádná. Už jim nemusíme říkat, že jejich požadavky jsou nejasné, nesplnitelné nebo dokonce protichůdné.

Pokud je protivník tak záludný, že nevěří našemu slovu, stačí vyrobit jednoduchou tabulku, v které vyjmenujeme jednotlivá konkurenční řešení a u nich seznam požadavků, které nesplňují. Nevěřili byste tomu, jaká je to legrace něco takového připravovat. Je to skoro tak kreativní jako programování. První produkt je pomalý, protože všechno zapisuje na disk. Druhý produkt má moc velké paměťové nároky, protože si všechno drží v paměti. Třetí produkt dokonce nemá podporu pro psaní zprava doleva! Na tom se člověk dokáže docela vyřádit. Nemusím zmiňovat to, že váš NIH to samozřejmě bude všechno umět.

FUD je váš přítel

Může se vám také stát, že soupeř přijde s nějakou technologií XYZ, kterou by chtěl použít a je přesvědčený, že by mu vyhovovala. To je trochu těžší oříšek, ale v zásadě se dá použít předchozí rada. Vzhledem k tomu, že máte jenom jednoho konkurenta, je dokonce snazší najít nějaké ty objektivní důvody, proč se nedá použít. Můžete strávit víc času hledáním hrůzostrašných historek o tom jak XYZ sežrala server i s uklízečkou, jak dva roky stará verze zaměňovala zavináče za znak pro bž a podobně. Jelikož žádná technologie není dokonalá, takových historek najdete dost a dost. Nesmíte se samozřejmě zmínit o tom, že ty problémy už jsou dávno vyřešeny. Hodně vám v tom pomohu lidé, kteří XYZ použili na něco na co není dělaná nebo ji špatně nakonfigurovali. Tito lidé jsou pak obvykle autory nejužitečnějších článků. V tom je asi největší výhoda NIHu. Když někdo na internetu bude hledat jeho nevýhody, nic nenajde. Co by také mohl najít, NIH je přeci dokonalý!

Pokud se vám přeci jen negativní reference nepodaří najít, můžete použít jednoduchou fintu. Vždy když zaslechnete XYZ se musíte uchechtnout a obrátit oči v sloup. To v soupeři potřebnou nejistotu také vzbudí.

Obvyklé protiútoky

Pokud se vaši soupeři pohybují v oboru delší dobu, budou na vás zkoušet různé finty. Na to si dejte pozor, následující protiargumenty jsou opravdu záludné. Jsou totiž pravdivé. Kromě osvědčeného FUD můžete zkusit i následující:

• Proč nepoužijeme stejnou technologii jako všichni ostatní? - NIH nám přinese konkurenční výhodu. - To je moje nejoblíbenější, proti této obraně se těžko hledá další protiútok.
• Proč nepoužijeme relační databázi? - Zkoušeli jsme Oracle a ten je moc složitý a drahý. - Všimněte si prosím geniálního úkroku stranou, málokdo si uvědomí že existuje hromada dalších relačních databází, které by tyto nevýhody mít nemusely.
• Proč jste neudělali analýzu možných alternativ? - Na to nám nikdo nedá čas, musíme začít programovat. - Klasická variace na téma měsíc v laboratoři vás uchrání od týdne v knihovně.
• Proč když je XYZ dost dobré pro Twitter, není to dost dobré pro nás? - Právě Twitter kvůli tomu měl dvě hodiny výpadek. - Rozhodně se nezmiňujte o tom, že to tam i nadále spokojeně používají.
• Na existující technologii snáze seženeme zaměstnance. - V ČR určitě nikoho kdo by znal XYZ neseženete.
• Na XYZ si můžeme zaplatit podporu. - Platit? Pch, já vám to udělám zadarmo.

Pár slov závěrem

Doufám, že se vám tyto rady budou hodit. Spousta lidí totiž nechápe jak je ten váš problém unikátní. Nerozumí tomu, že je vaše firma tak odlišná od ostatních, že si všechno musíte řešit sami. Požadavky jaké mají vaši zákazníci ještě nikdo nikdy neviděl. Nikdo také ještě neřešil problémy jaké máte vy. A pokud je řešil, tak to dělal naprosto, ale naprosto špatně. Doufám také, že vám tento článek pomůže v psaní dalších unikátních produktů, které tento svět posunou k světlejším zítřkům.

První den

Java EE keynote

Tu jsme naštěstí prošvihli díky zpoždění letadla. Stihli jsme jen konec, ale bylo to neuvěřitelně nudné. Oracle předváděl jak nasadit aplikaci do cloudu ve stylu: „Tady vyberete na WAR, tady kliknete a máte aplikaci nasazenou v cloudu“. Jakoby největší problém nasazení v cloudu bylo, že to nejde udělat stisknutím jednoho tlačítka. Prostě jsem nepochopil, co tím chtějí říci.

Java: The Good, the Bad, and the Ugly Parts

Po obědě jsem si trochu spravil chuť povídáním mého oblíbence Joshe Blocha o dobrých, zlých a ošklivých stránkách Javy. Byl to takový výlet do historie, procházel všechny třídy z Javy 1.02b. Zajímavé, zábavné, ale ne moc užitečné.

Continuous Delivery

Zajímavé povídání od člověka, který o tom napsal knihu. Mám ji, ale ještě jsem se jí neprokousal. Je na mě moc těžkopádná. Nicméně přednáška moji pozornost udržela. Mluvil o tom, jak zařídit, abyste mohli nasazovat aplikace stisknutím jednoho tlačítka. Takže něco, co se asi snažil ukázat i Oracle, ale tady jsme se dozvěděli to důležité. Tzn. co udělat, abyste se nebáli to tlačítko stisknout. Celé bych to shrnul do jedné věty.

Pokud to bolí, dělejte to častěji.

Takže, pokud nasazení vašeho produkčního clusteru bolí, zkoušejte to dělat něco podobného co nejčastěji. To vás donutí to zautomatizovat a pak to tolik bolet nebude. Ukazoval tam takovou kaskádu kroků, kterou potencionálně může projít každý commit. V ní jsou unit testy, automatické akceptační testy, manuální testy, unit testy zaměřené na výkonost, integrační testy zaměřené na výkonost a nakonec produkce.

Zdůrazňoval, že je důležité mít všechno ve version control systému, mít co nejvíc automatických testů a hlavně mít jeden a ten samý skript pro nasazení na všechna prostředí. Tím si zajistíte, že při testování testujete nejen kód, ale i konfiguraci. Na tu často zapomínáme, i když je stejně, ne-li více důležitá.

Snadněji váš systém shodím jednou změnou v konfiguraci než jednou v změnou kódu.

Takže každá změna konfigurace by měla projít přes to samé kolečko testů jako kód. Konfigurace musí tím pádem škálovat od notebooku až po produkční cluster, ale to se dá zařídit.

Také ukazoval pěknou fintu na automatické testy. V podstatě si napsali knihovnu, která izoluje jejich API a test skripty, takže je změna v API nenutí měnit hromadu testů, musí jenom změnit tu knihovnu. Mohou také ty testy psát ve vlastním DSL, takže je pochopí i neprogramátor. K takovému stavu bych se chtěl někdy dopracovat.

PhoneGap

Zajímavé povídání ze světa, kterému vůbec nerozumím. Pravděpodobně také nejsprostší řečník na letošním Devoxxu, ale v takovém tom zábavném stylu. PhoneGap je pro lidi, kteří chtějí psát HTML5 aplikace, ale zároveň chtějí výhody nativního kódu.

PhoneGap je jenom takový vychytaný prohlížeč.

V podstatě obalí váš HTML kód a udělají z něj nativní aplikaci na iOS, Androidu a vlastně všech chytrých platformách. Navíc dostanete přístup k věcem, ke kterým se z prohlížeče nedostanete. Například váš kód může běžet, i když telefon spí. Tady mi to nedá a musím ocitovat pár hlášek.

Lidé se nás ptají, jak na open sourcu vyděláváme peníze. Já se jich na oplátku zeptám, jestli si někdy koupili balenou vodu.

XCode je něco jako horší Eclipse, ale vypadá to jako iTunes.

Donuťte zaákazníka popsat co chce v jedné větě, bez použití spojky „a“.

Také ukazoval debug.phonegap.com, což by vám mělo umožnit vzdáleně ladit kaýkoliv váš JS kód. To by se také mohlo hodit.

NoSQL for Java developers

Pěkné porovnání NoSQL databází Redis, Cassandra a MongoDB z pohledu Javisty. Zajímavá ukázka toho, jak je těžké použít některá NoSQL řešení, když potřebujete vyhledávat přes něco jiného než klíč. Předváděl, jak si ručně v Redisu a Cassandře nasimulovat index. Fakt hrůza, dávat do Javy kód, který při změně dat aktualizuje i „tabulku“ v které simuluji index. Některé NoSQL databáze jsou prostě dělané na jiný use case a ne na vyhledávání. MongoDB v tomto ohledu výjimkou, ve vyhledávání je mnohem podobnější relačním databázím.

Meh! It's only cross site scripting what's the big deal?

Děsivá přednáška o XSS od člověka, který se živí penetračními testy. Děsivá v tom smyslu, že mě vyvedla z iluze o bezpečnosti Webu. Ten člověk evidentně věděl o čem mluví. Jednou se dokonce přeřekl a místo slova zákazník skoro řekl slovo oběť. Bohužel to jak mě vyděsil nedokážu předat i vám. Můžete si například pustit následující video. Fakt se na to podívejte a pak se zamyslete co se stane, když vám někdo pošle podobný link a vy se pak přihlásíte do administrace vaší aplikace.

Ještě tu uvedu jen pár věcí, které jsem si zapsal

• 80% procent útoků na webové stránky jsou XSS.
• Salámová metoda – každého desátého zákazníka přesměrujeme na vlastní platební bránu. Tento útok může běžet několik měsíců bez povšimnutí.
• Nepoužívejte veřejně přístupnou admin stránku. Zaručeně ji najdeme a to heslo prolomíme.
• Validujte data která přijímáte, ale i ta která čtete z databáze. Útočník může dostat data do vaší databáze a ty pak použít k XSS.
• Při validaci nepoužívejte blacklist, ale whitelist. Nesnažte se vyjmenovat co uživatel nesmí zadat, ale to co smí.
• Některé prohlížeče jsou interpretují hex encodováný Javascript i ve jménech obrázků. K infekci stačí nahrát správně pojmenovaného avatara.
• Jen v Rusku je asi 300 000 hackerů. 100 z nich je fakt dobrých.
• Zero-day exploit se dá koupit za 10 000 – 20 000 liber.

Druhý den

Z druhého dne mám výrazně méně zápisků.

Android keynote

Tim Bray mluvil o Androidu a mobilech. Kdo byl na GDD se nedozvěděl moc nového. Vypíchnu dvě věci.

Tvrdil, že ho Java štve na serveru, ale na mobilu ne. Na serveru prý může snadno psát unit testy, dělat TDD a tudíž nepotřebuje silně typovaný jazyk. Na mobilu se mu testy píší mnohem hůře, takže jich nepíše tolik, kolik by správně měl. Tam je za Javu rád. Zajímavé. Navíc je zajímavé i to, že takovýto člověk stále píše kód.

No a nesmím zapomenou dojemnou výzvu, že pokud opravdu chceme změnit svět, měli bychom vyvíjet aplikace pro třetí svět. Tam můžeme opravdu něčeho dosáhnout. Musím se přiznat, že se dostal i pod moji hroší kůži a začal jsem o tom opravdu uvažovat. Kdyby měl někdo nějaký nápad, tak se ozvěte, rád se přidám.

Ještě přihodím pár citátů:

Teď už nestačí když vaše aplikace bude dobrá. Aby uspěla, musí být úžasná.

Sežeňte si profesionálního designéra.

Prodejem aplikací nezbohatnete.

Aplikační programátoři prostě nechápou sdílený měnitelný stav.

Socializing Your Spring Applications

Na toto povídání jsem šel z čistě pracovního popudu. Přišel jsem tím o mnohem zajímavější přednášku o Akka frameworku. Ale zase jsem se dověděl, že je snadné pomocí Springu přistupovat na API zabezpečené pomocí OAuth a že ve Springu mají abstrakci spousty REST API jako jsou Twitter, Facebook atp. To se mi bude hodit.

What's in store for Scala?

Chtěl jsem se jít podívat na Martina Oderského. Ale bohužel zabředl do akademického rozboru toho, jak ve Scale budou dělat reflexi. Jediné co jsem si odnesl bylo, že se musím znova do té Skaly pustit. Prý už konečně mají použitelnou podporu pro Eclipse, takže se nebudu muset učit Ideuu a Scalu současně. Zajímalo by mě, na co se budu vymlouvat teď?

HTML5 with Play/Scala, CoffeeScript and Jade

Po obědě nás probral Matt Raible. Ten předvedl, že když umíte prezentovat, tak nemusíte ani moc umět to o čem mluvíte. V podstatě popisoval, jak si psal pokusnou aplikaci za pomocí Play/Scala, CoffeeScript a Jade. Nešel moc do detailů, ale pěkně člověka nasměroval na co se podívat.

O frameworku Play bylo letos podezřele hodně přednášek, asi se na to budu muset kouknout. Také docela chválil Scalate. Více detailů na jaho blogu. je tam i odkaz na video, ve kterém, celý ten svůj pokus pěkně shrnul. Úžasná finta jak zaujmout obecenstvo.

Cloud Foundry and Spring, a marriage made in heaven

Cloud Foundry vypadá zajímavě pro ty, kteří se chtějí pokusit o cloud. V podstatě to má být otevřený standard pro Platform As A Service. Takže pokud uvažujete pustit se do cloudů a nechce se vám všechno si konfigurovat ručně, Cloud Foundry vypadá jako dobrý start. Nemusím si vybírat, jestli budu odkázán na jednoho dodavatele platformy jako je Google App engine nebo jestli si budu sám instalovat servery na virtuální mašiny. Toto je něco mezi. Pokud to dobře chápu, tak je to standard, který by měl zjednodušit cloudovým uživatelům přecházet mezi dodavateli nebo dokonce si podle toho nasadit i cloud sami. Další věc, kterou bych si měl pořádně nastudovat.

Třetí den

Tak dneska to bylo opravdu charita.
Dagi

Technical Discussion Panel

Panel se zajímavými hosty, ale nezajímavými otázkami. Promarněná příležitost.

The Evolution of Java: Past, Present, and Future

Zase Josh Bloch. Zase zajímavé a zábavné. Zase ne moc užitečné. I když tady musím přidat hodně nekvalitní fotku jeho slidu o přidávání nových funkcionalit. To by se mělo tesat do kamene a platí to nejen pro vývoj jazyka.

Takže, jaký je závěr? Zajímavá konference, kterou doporučuji. Jenom člověk musí mít dobrou ruku při výběru přednášek. Letos se jelo v sedmi paralelních proudech! Sám jsem si odvezl dvě stránky nápadů a věcí, které potřebuji vyzkoušet nebo udělat.

Také to vypadá, že nás cloud nemine. I když, možná se to přežene stejně jako SOA. Také jsem si všiml věcí, které byly nápadné tím, že na ně člověk nenarazil. Všiml jsem si jenom jedné přednášky o build systémech, jenom jedné o JPA a o SOAPu snad nebyla vůbec žádná. Asi už je to stará vesta a lidé už řeší jiné problémy. Třeba si píší vlastní programovací jazyky. Těch tam bylo několik.

Nestydatá reklama: Nechcete nad cloudem, NoSQL a podobnými technologiemi je toužebně vzdychat? Chcete zažít vzrušení z práce s technologiemi krvavé hrany? Pojďte k nám do GoodData. Pořád hledáme šikovné lidi. Pokud vás budou zajímat detaily, tak se ozvěte naším HR kolegům nebo mě. Můžeme to probrat někde u piva.

Začneme tím procesorem. Procesor zpracovává instrukce, které provádějí operace nad daty. Tato data se načítají z paměti. Paměť je ale od procesoru vzdálena neuvěřitelně dlouhých několik centimetrů a mezi ní a procesorem jsou všelijaké řadiče, a jiná hejblátka. Tím pádem je přístup do paměti relativně pomalý. To donutilo autory procesorů navrhnout L1 cache (vyrovnávací paměť první úrovně). Ta je hned u jádra procesoru takže je přístup do ní rychlý. Je s ní ale jedna potíž, je dost malá. Proto se do procesorů přidává ještě L2 cache, která je podstatně větší. Jelikož je ale složitější, je od jádra trochu dál, a proto je přístup do ní pomalejší. Někdy je dokonce i sdílena mezi jádry, což přináší výhody například, když se mi vlákno dostane na jiné jádro. Občas je dokonce použita i L3 cache, která je zase o něco větší a pomalejší.

Celé to pak funguje jednoduše, pokud data nejsou v L1 paměti, kouknu se do L2, případně L3 a když to ani v jedné není, jdu až do hlavní paměti. Samozřejmě se musí nějak řešit i invalidace a uložení změněných dat, ale to už bych se pouštěl na tenký led. Už tak jsem se pustil do vod, kterým nerozumím.

Takže se radši vrátím do Javy. Paralela je nasnadě. Z Javy často potřebuji přistupovat k pomalým nebo přetíženým zdrojům a tak si pomáhám vyrovnávací pamětí. Použijme pro příklad relační databázi. Ta bývá přístupná přes pomalou síť a často špatně škáluje, tak si některá data ukládám na heap. V přirovnání k CPU tu databáze odpovídá relativně pomalé RAM a heap nám tu slouží jako L1 cache. To přirovnání docela sedí. Heap je to nejrychlejší co v Javě máme. Samo sebou se pohybujeme v úplně jiných řádech než u CPU jak do velikosti tak i rychlosti.

Na ale každá sranda něco stojí, tak i cache není bez problémů. Největší problém s tímto řešením je v tom, že já obvykle dopředu nevím, která data s vyplatí držet v paměti, a která ne. To poznám až při opakovaných dotazech. Celou věc ještě mnohonásobně komplikuje nasazení aplikace na více serverech. Každý node má pak svoji cache. Abych si zjednodušil argumentaci, budu předpokládat, že data jenom čteme a neměníme. Uznávám, to se nám v praxi moc často nestává, ale i tak se dostáváme se do zajímavých problémů. Aby vyrovnávací cache k něčemu byla, musíme z ní data číst opakovaně. Čím více máme ale serverů, tím je menší šance, že k tomu dojde. Řekněme, že nám na jeden server přijde dotaz, který způsobí načtení dat do vyrovnávací paměti. Čím více máme serverů, tím menší pravděpodobnost je, že příští obdobný dotaz přijde na ten samý server a data v paměti využije. Větší šanci má, že tento dotaz přijde na jiný server, který ta data zase musí odněkud stáhnout.

V praxi se to řeší například použitím chytrým load balancerem, který nám zajistí, že dotazy od jednoho uživatele chodí na ten samý server. Toto řešení může fungovat, například u aplikace typu Gmail, ale vůbec to nepomůže například u zpravodajského serveru.

Dalším populárním řešením je sdílení vyrovnávací paměti mezi servery. Tzn. pokud jeden server načte data do cache, pošle je všem svým kamarádům. Toto řešení obvykle špatně škáluje. Navíc si představme situaci, kdy jsou daná data potřeba jen jednou. Nejen, že je zbytečně budu držet v paměti na jednom serveru, já je i pošlu na několik dalších strojů. Tam nebudou přečtena ani jednou. Zato však budou nafukovat paměť, zpomalovat garbage collector, zatěžovat síť a dělat jinou neplechu.

A tady vstupuje do kdy L2 cache. Místo toho, abych se snažil distribuovat všechna data na všechny ostatní JVM, uložím je někam mimo heap. Toto bych chtěl zdůraznit. Já ta data opravdu dám někam mimo JVM. Můžu buď do Terracotty nebo pokud si chci trochu zaprogramovat, třeba do NoSQL databáze. Tato data jsou mimo heap, takže přístup k nim je pomalejší. Ale tato L2 cache je trapně jednoduchá a může běžet na stejném serveru jako moje JVM takže přístup do ní může být stále řádově rychlejší než do relační databáze. Jen pro představu, autor Terracotty Ari Zilka tvrdí, že přístup na heap trvá kolem 1 mikrosekundy, přístup do Terracoty 4 milisekundy.

L2 cache navíc může být schopna využít mnohem více paměti než Java. Lidé z Terracotty se chlubí, že umí držet v paměti stovky gigabajtů dat. Není se co divit, nemusí řešit garbage collection, v podstatě se jen starají o takovou trochu větší hash mapu.

Toto řešení má mnohem větší šanci na to, aby škálovalo. Samozřejmě se mi komplikuje změna dat. Musím je změnit nebo smazat nejen v L1 cache ale i v L2 cache. Ale to je podle mě malá cena za to, že můžu svoji aplikaci pouštět na víc než čtyřech serverech. Navíc mohu aplikaci zmodularizovat, pouštět ji ve více JVM a i tak využít toho, že mám data někde v cache. Jediné co musím udělat je uvědomit si, že vytažení dat na půl cesty mezi jejich zdroj a místo spotřeby je docela dobrý nápad. Něco, co si výrobci procesorů uvědomili už dávno.

Oko a mozek mají mezi sebou dohodu. Mozek souhlasí s tím, že bude věřit tomu co oko vidí, ale na oplátku oko souhlasí s tím, že bude koukat jen na to, co chce mozek vidět.
Daniel Gilbert, Stumbling on Happiness

V poslední době často narážím na ideální svět. Lidé v tomto ideálním světe čtou dokumentaci, programátoři používají API tak jak mají, prohlížeče dodržují specifikace, lidé nedělají chyby a chovají se racionálně, zadání zůstávají konstantní, holky vám samy skáčou kolem krku a pečení holuby lítají sami do huby. Krásná představa, skoro jako Utopie kolegy Platóna.

Problém je, že se jedná pouze o představu. Nic z toho, co se děje v ideálním světe, se neděje v realitě. Opravdu nic. To samozřejmě všichni víme, ale ani to nám nebrání v tom, chovat se tak, jako by ideál a realita byli jedno a totéž.

Občas někoho vidím divit se, jak to, že jeho kolegové něco nevědí. Vždyť to přeci napsal do dokumentace, kterou po něm sami chtěli. Jak je tedy možné, že ji nečetli?

Protože lidi nečtou! Bez ohledu na to, že to po vás chtěli sepsat, že jste s tím strávili spoustu času a práce. Prostě nečtou. Tečka. Vykřičník. Je je fakt, s kterým se nedá nic dělat. Slovy klasika, můžeme o tom diskutovat, můžeme o tom vést spory, můžeme s tím nesouhlasit, ale to je tak všechno, co se proti tomu dá dělat.

“PLEASE READ THIS OWNER'S MANUAL
BEFORE UNPACKING THE DEVICE.
You’ve already unpacked it, haven’t you? You’ve unpacked it and plugged it in and turned it on and fiddled with the knobs, and now your four-year old child, the same child who once shoved a Polish sausage into your new VCR and pressed fast forward, this child is also fiddling with the knobs, right? We might as well just break these devices right at the factory before we ship them out, you know that?”

Samozřejmě toto není jediný příklad. Například s dodržováním standardů a kontraktů API je to podobné. Když programátoři chtějí použít nějakou knihovnu, tak to prostě zkouší, dokud to nezačne fungovat. Jakmile to začne fungovat, tak toho nechají. Nezajímá je, co je v dokumentaci nebo nedejbože ve standardech. Tak to prostě je. Chovám se tak já, chovají se tak vaši kolegové, vaši zákazníci, prostě všichni, až na pár podivných výjimek.

A tím se dostávám k tomu, proč to vlastně všechno píšu. Je to takový můj první krok k pokusu o akceptaci reality. Z vlastní zkušenosti vím, jak je to těžké nežít v ideálním světě. Často se sám přistihnu při tom, jak se divím, že se lidé (mě nevyjímaje) chovají iracionálně. Nebo něco ťukají do počítače, když na schůzi mluvím. Nebo naprosto, ale naprosto špatně chápou mé skvěle vyargumentované články na blogu a naprosto, ale naprosto falešně je vykládají. Nemluvě o tom, že se uživatelé mých skvělých knihoven ptají na něco, co mají naprosto jasně napsané v dokumentaci. Hrůza. Skoro jako bych žil v reálném světě.

A aby toho nebylo málo, akceptace reality není všechno, je to jen první krok. Správně bychom podle toho měli také konat. Například bychom neměli rozbíjet klientům kód, pod hloupou záminkou, že nedodržují standardy. Ano, ve standardu je napsáno, že můžeme vracet také nějaké jiné návratové kódy než zrovna vracíme. Ale to nás neopravňuje k tomu najednou změnit chování a tím všechny naštvat. Prostě žijeme v realitě a klienti s tím nepočítají.

Nebo jiný příklad. Když něco přednášíme, měli bychom se snažit to udělat co nejzajímavější. V ideálním světe by samozřejmě všichni chtěli poslouchat co jim chceme zdělit, v realitě ale mají za sebou těžký den a sami dobře víte jak je snadné při přednášce se začít dloubat se v nose a přemýšlet o vaší krásné sousedce.

Takže tímto vyhlašuji válku ideálnímu světu a chtěl bych vás, ale hlavně sebe poprosit, přestaňme snít a začněme přijímat realitu.