Postřehy z Devoxxu

Včera jsem se vrátil z Devoxxu 2011 a zase se mi tam moc líbilo. Nedověděl jsem se tam toho tolik nového, ale nabilo mě to energií a napadla mě tam spousta věcí. Důvod, proč jsem se tam toho tolik nedozvěděl je prostý. Jsem prostě dobrej a všechno vim. No nebo to spíš bude tím, že jsem tam byl i vloni a zas tolik se toho za ten rok nezměnilo. Minulý rok mluvili o novinkách Javy 7 a 8. Letos také. Za tu dobu se trochu změnila syntaxe v projektu Lambda, Jigsaw nabyl trošku konkrétnější obrysy, ale to je asi tak všechno. Ve světě Java EE je situace podobné. Jak vtipně poznamenal kolega, EJB a CDI se pomalu blíží ke schopnostem Springu 2.5. Kdyby to tak bylo, tak by to byl velký skok vpřed. Ale nevím jestli to náhodou nemyslel posměšně.

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.

L2 cache v Javě

Nedávno jsem si pořídil knihu o Terracottě a v ní jsem narazil na myšlenku, které úplně převrátila můj pohled na cachování dat v Javě. Řekl jsem si, že se s vámi o ni podělím. Jde o srovnání využití vyrovnávacích pamětí v moderních procesorech a v Javě.

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.

Opusťme ideální svět

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.