GeeCON - Krakow 2013

Forrestí výprava opět vyrazila do Polska na Java konferenci GeeCON a nebyl bych to já, kdybych vám nepřinesl detailní reportáž o věcech, které mne tam zaujaly. Letos byl můj výlet sponzorován brněnskou firmou YSoft, která byla platinovým sponzorem celé konference a které bych chtěl prostřednictvím tohoto článku také poděkovat. Na společnou výpravu se s námi vydal i Tomáš Záluský z písecké společnosti Intelis a spolu s ním bychom pro vás měli připravit i krátkou rekapitulaci konference na pražském CZJUG.

Pokud bych měl popsat témata konference v jedné větě, řekl bych, že převážná část přednášek se týkala aspektů funkcionálního programování, big data, automatizací, continuous delivery a soft skillech. A na nejzajímavější věci se pojďme kouknout hned teď ...

Pretotyping (Patrick Copeland)

Úvodní keynote se týkala hnutí za úspěšnější produkty a plula na vlně soudobého startupového šílenství. Základní myšlenka se týkala omílané pravdy, že nápady jsou zadarmo - teprve lidi, kteří dokáží vytěžit jejich potenciál, by se měli vyvažovat zlatem. Většina nápadů totiž nemá šanci přežít a to i v případě, že za nimi stojí velká společnost a známá jména.

Podle manifesta pretotypingu je důležité pěstovat kulturu hledání, zkoušení a opouštění nápadů, které se neosvědčily. A to nejlépe ve velkém - protože jen jeden nápad z mnoha má skutečnou hodnotu, navíc tato kultura dělá z lidí inovátory.

Kritické místo celého cyklu je validace nápadu a případné odmítnutí, pokud výsledky neodpovídají očekávání. Bohužel je v lidské přirozenosti držet se myšlenky, do které jsme již investovali (čas i peníze) - a čím víc jsme proinvestovali, tím méně se nám chce nápad opustit. Proto je potřeba, aby validace nápadu proběhla co nejdříve - tj. při vynaložení minimálně nutných nákladů.

V tomto ohledu je potřeba někdy i "podvádět" a toho bychom se neměli bát. Dřív, než se pustíme do programování složitého výpočtu, zkusme v rámci testování použít místo počítače lidskou sílu - s tím, jak člověka nahradit automatem si můžeme lámat hlavu později, až zjistíme, že to někdo vůbec chce. Než se pustíme do vytváření produktu, zkusme si zadat pár PPC reklam, které vedou zatím na jednoduchou upoutávku na neexistující produkt. Přivedly nám reklamy někoho? Ne? Možná je to signál, že jsme na zlatou žílu nenarazili.

Pokud vás zajímá víc detailů, odkážu vás na knížku na dané téma, která je ke stažení zdarma a která detailněji rozebírá veškerou argumentaci, která byla vyložena v průběhu přednášky.

JDK 8 (Dalibor Topic)

V nové verzi Javy je na co se těšit - škoda jen, že se její vydání o rok odložilo. Produktový manažer Oracle proběhl ve zkratce řadu zajímavých věcí od těch zásadních až po ty drobné. Kromě dlouho očekávaných closures v jazyce samotném se můžeme těšit na přepracování API, které z nové funkcionality mohou těžit nejvíce - např. práce s kolekcemi (která je do jisté míry inspirována i M$ LINQ), dostupnost názvů parametrů přes reflexi - bolest na kterou jsem si už dávno stěžoval, vytvoření několika profilů JRE umožňujících bundlovat s aplikacemi tenký embedovaný runtime (minimální velikost má být < 10MB), zrychlení javac kompilátoru použitím paralelní kompilace, nový embedovaný JavaScript engine Nashorn, zrušení paměťového prostoru PermGen - který má být nahrazen standardní heapou, nové DateTime API, vyřešení problémů s vyhladověním generátoru náhodných čísel pro SecureRandom a mnoha dalších vylepšení třeba v oblasti kryptografie.

Gradle eating own dogfood (Sczepan Faber)

Autor mého oblíbeného frameworku Mockito, který aktuálně pracuje pro Gradle, v této přednášce popisoval, jak v Gradle používají jejich vlastní nástroj pro automatizování buildů. Škoda, že byla většina přednášky především o vlastní show než o faktech, kterými se může Gradle určitě pochlubit. Z hromady balastu se mi podařilo vylovit pár zajímavých informací, které představují poměrně zásadní argumenty, které by nás ve Forrestu mohly konečně nakopnout k migraci na Gradle.

Gradle má bouřlivý vývoj už za sebou - základní koncepty se už nemění a kvalita produktu je na vysoké úrovni (čehož důkazem je i migrace celého Spring Frameworku na Gradle a nebo nedávná migrace Android SDK). Již z raných verzí má Gradle tu vlastnost, že provádí pouze nezbytně nutné operace k aktualizaci buildovaného artefaktu - nedělá tedy zbytečnou práci. Standardně je nyní spouštěn v daemon režimu, což vede k rychlejší odezvě, protože nemusí pokaždé startovat Java JVM. Navíc dostává větší prostor hotspot, který dokáže běh dále urychlit. Nebude to dlouho trvat a přibudou i paralelní buildy, které jsou již v aktuálním snapshotu Gradle a které nám umožní využít sílu všech jader při buildu artefaktů. Pro zjednodušení instalace v nových prostředích je k dispozici tzv. wrapper, který si sám zajistí instalaci potřebných knihoven Gradle.

Gradle samozřejmě používá pro build sama sebe sám sebe (hezká slovní rekurze že? :)). Co mi přišlo jako velmi zajímavé je to, že v rámci testů ověřují funkčnost i všech snipettů kódu, které mají uvedené v dokumentaci (parsují je z javadocu). Pro integraci používají TeamCity od JetBrains a veškeré releasy jsou plně automatizované až po instalaci nové verze webu na produkci včetně webu. Při tvorbě dokumentace jsou aplikovány všechny principy, ke kterým jsem se dopracoval i já sám. Všechnu dokumentaci drží blízko kódu, verzovanou v Gitu společně se zdrojovým kódem a pro její úpravu nemusí ani na chvilku opustit vývojové IDE. Prostě paráda.

Mimochodem, kdybyste chtěli dělat pro Gradle, začněte dělat na nějaké open-source knihovně, protože to je nutná podmínka pro to, aby se s vámi vůbec začali bavit ;)

HBase (Lars George)

Tato přednáška vynikala především tím, že byla natřískaná fakty od podlahy až na půdu (obrazně řečeno). Tím byla pro letošní GeeCON skutečně výjimečná. HBase je sloupcově orientovaná NoSQL databáze vyvíjená pod hlavičkou Apache. Svojí povahou je podobná Cassandře (nebo BigTable), ale má v některých ohledech lehce jiné charakteristiky (abych nezjednodušoval, tady máte komplexní porovnání s Cassandrou a tady s BigTable). HBase je postavena nad HDFS (správa souborů) a Hadoopem a jestli to chápu správně dodává logiku a strukturu souborům ukládaným na HDFS (který zajišťuje pouze "virtuální" file systém) - tedy onu "databázovou" povahu.

HBase zapisuje data do writeahead logu a do paměti. Při naplnění kapacity paměti se data flushují na disk po 64MB blocích. Data zapsaná na disk již nelze změnit. Na úrovni API se měnit sice dají, ale ve výsledku ústí v nové "modifikační" (diff only) záznamy v nových souborech. Při čtení takového záznamu musí tedy HBase navštívit několik existujících bloků na disku, aby dokázala rekonstruovat obsah záznamu. Obdobně se řeší i odstranění záznamů. Do DB se interně zapíše nový záznam nazvaný "tombstone", který označí existující záznam za "odstraněný". Při vyhledávání záznamů se postupuje od novějších záznamů ke starším a tím pádem fungují náhrobní kameny i diffy správně. Na pozadí potom běží aktualizační démoni, kteří v cyklech čistí existující fragmenty na HDFS (tj. vytvářejí nové bloky, ve kterých se již nevyskytují odstraněné záznamy a slučují updaty do jednoho záznamu). Vlastností HBase je verzování obsahu jednotlivých sloupců (standardně uchovává 3 verze zpět, ale je možno nastavit víc).

HBase udržuje pouze 2 indexy - primární podle klíče řádku a sekundární podle názvu sloupce. Sloupce mohou být pro každý záznam jiné. Null Hodnoty HBase nestojí ani byte v úložišti a je klidně možné mít pro jeden řádek milion sloupců. HBase nepodporuje transakce - atomická operace je uložení jednoho kompletního řádku. Sloupce se mohou seskupovat do tzv. column families a řádky do regionů. Region je vždy celý uložen na konkrétní instanci serveru. Distribuce dat do regionů se děje buď automaticky nebo si ji můžeme kontrolovat ručně. Co je ovšem klíčové je kompozice primárního klíče, protože ten je zásadní pro umístění v regionu (data se třídí lexikograficky podle PK). Podobné klíče se budou nacházet ve stejném regionu, což urychluje (dotaz vyřídí jeden server) a nebo zpomaluje (všichni se ptají jen jednoho serveru) čtení. Navíc díky tomu, že je primární klíč zároveň hlavním indexem (a máme k dispozici jen dva) je nutného využít pro zachycení základních údajů, podle kterých můžeme omezovat hledání (a ne ho vyplácat na nějaké inkrementální číslo, jak jsme zvyklí z relačních databází).

V HBase je samozřejmě možné vyhledávat podle primárního klíče, ale je možné provádět i tzv. scany - tj. pomocí map-reduce získávat záznamy, které odpovídají naší podmínce. Scany je možné omezit na konkrétní rozsah primárních klíčů (od-do) a tím vymezit scan na konkrétní regiony (což výrazně urychluje hledání). Při vyhledávání je možné získávat data na úrovni column families. Efektivnost hledání je dána touto posloupností: rowkey, columnfamily, column qualifier (název sloupce), timestamp a nakonec hodnota sloupce. HBase kromě základních put, get, delete operací umožňuje také increment, atomický get + compare + swap.

Nechci tu přepisovat dokumentaci HBase, ale těch informací bylo prostě od Larse tolik, že teprve teď dokážu rozpoznávat konceptuální rozdíly mezi relační DB a NoSQL DB jako je HBase. Pro mě byla tato přednáška zásadní pro změnu přemýšlení o NoSQL datech.

SOAP sucks, doesn't it? (Tom Bujok)

V této přednášce představil Tom Bujok svoji knihovnu Reficio SOAP-WS, která by měla zmírnit bolest při konzumaci webových služeb postavených na SOAP. Je postavená nad Spring-WS, které už samy o sobě představují abstrakci nad knihovnami pracujícími se SOAP protokolem (pokud máme třetí vrstvu abstrakce, něco to o tom, co je dole, svědčí, ne?). Reficio se nesnaží zaštítit SOAP nějakou objektovou reprezentací a cílí přímo na práci s XML, které mezi poskytovatelem a konzumentem teče a v kombinaci s XML podporou v Groovy skutečně dává smysl. Knihovna řeší jak stranu serveru, tak i klienta a její přednosti jsou charakterizovány nejlépe autorem v tomto seznamu.

Kdyby jste něměli toho punku dost, zkuste si přečíst článek Object have failed, který autor Reficio doporučuje ke čtení (já ho už ve svém Instapaperu mám).

What Every Hipster Should Know About Functional Programming (Bodil Stoke)

Jak jsem již psal v úvodu, velká část GeeCON konference se týkala funkcionálního programování. Osobně mám před každým matematikem velký respekt a funkcionální programování je v podstatě matematika aplikovaná na programování. A přesně v tomto duchu se odvíjela i přednáška této Dámy, která se vyžívá v seriálu My little Pony. Jsou chvíle, kdy si připadám jako zedník, který náhodou narazí na architekta - a tohle byla jedna z nich.

My, obyčejní smrtelníci, musíme praktikovat TDD, abychom si dokázali, že to co vytvoříme skutečně spolehlivě funguje. Lidi, jako ONA toto jednoduše matematicky dokáží.

V přednášce pomocí jednoduchých příkladů, které jsou ke shlédnutí zde, předvedla základní koncepty funkcionálního programování jako jsou: first class functions, functors, high order functions, combinators, composition, applicative functors, currying (respektive správněji schönfinkeling) a samozřejmě monády. Jo a mimochodem, kdyby někdo chtěl vědět, co znamená ZYGOHISTOMORPHIC PREPROMORPHISMS, obraťte se přímo na @bodil.

Nechtějte po mně, abych vám to vysvětloval. Hej, ale ten reveal.js použitý v prezentaci je fakt cool, no ne? :)

Btw.: Kdybyste nevěděli jak vyhodnotit výrazy v interaktivních oknech prezentace, zkuste zkratku Ctrl-S ;)

Making Java Unit Test Groovy with Spock (Ken Sipe)

Spock je Groovy framework cílený na automatické testování aplikací a staví na osvědčeném JUnitu. Ačkoliv na mě přednáška udělala velký dojem, není jednoduché popsat všechny přednosti Spocku nehledě na to, že toto již za mě udělali jiní, povolanější. Z této přednášky bych vypíchnul snad jen nejzásadnější argumenty, které mne určitě donutí udělat další krok tímto směrem:

• na existujících knihovnách by mělo být možné bez problémů kombinovat existující JUnit testy se Spockem (Groovy)
• ze všech příkladů byla vidět extrémní čitelnost testů, kterou je těžké v Javě dosáhnout
• Groovy udělalo od svých začátků obrovský pokrok a to včetně podpory v IDE
• součástí jsou zabudované profily testů, které umožní kategorizovat testy do jednoduše spustitelných oddělených sad (fast, slow, performance, integration a kdo ví jaké ještě sady testů)
• krásně implementované testování sady vstupních dat ideální třeba pro matematické výpočty (kalkulačky atp.)

Každopádně doporučuji si projít příklady Kena na GitHubu, ve kterých popisuje a prakticky ukazuje všechny základní koncepty Spock frameworku.

O Spocku jsem sice už slyšel, ale nedocenil jsem přínos, který, oproti kombinaci JUnit + Mockito, může přinést. Z GeeCONu si teď odvážím úplně jiný pocit.

Building Modular Cloud Applications in Java - Lessons Learned (Bert Ertman, Paul Bakker)

Z této přednášky jsem chtěl asi po 10 minutách odejít, ale nakonec jsem rád, že jsem zůstal. Výše jmenovaní pánové zde přednášeli o tom, jak je stavěná architektura aplikace pro PulseOn, která slouží k interaktivní výuce na školách.

Osobně na úspěch OSGi ve velkém už nevěřím - stejně tak jako mainstream, nicméně to neznamená, že libovolnou technologii, do které se investuje patřičné množství energie není možné s úspěchem použít. Společnost Luminis, šla tímto směrem a atributy aplikace, které prezentovala na GeeCONu jsou minimálně zajímavé.

Aplikace je stavěná modulárně (jak jinak s OSGi :)) a serverová část končí vystavením RESTových služeb, které konzumuje Javascriptový klient běžící v prohlížeči, který je zase postaven na Angular.js a HTML5. Kromě rychlého turnaroundu při vývoji (write-save-reload-see), který podle mého není zase až tak potřeba, když se praktikuje TDD, jim tento přístup umožňuje za běhu aplikace instalovat / aktualizovat moduly do živé aplikace.

Pro řízení deploymentu (provisioning) modulů používají open-source knihovnu Apache ACE, pomocí které dokáží aktualizovat novou verzi modulu (tj. JARu) a během několika vteřin ji dostat na stovky serverů v Amazon EC2 cloudu. Vše kompletně bez restartu. Přednášející se odvolávali na příklad Netflixu, který pro instalaci nové verze aplikace (i jen kvůli aplikaci hot-patche) musí vytvořit kompletně nový image včetně OS a veškeré infrastruktury okolo. Jim v tomto případě stačí runtime aktualizace JARu v běžícím OSGi kontejneru.

Věci, které ukazovali v rámci přednášky se mi principielně velmi líbily, protože i my se pokoušíme provozovat modulární architekturu. Otázka je, jestli cena, kterou museli zaplatit při vývoji není  za možnost instalace aktualizací za běhu příliš vysoká. Technologie použité v aplikaci (s výjimkou Angular.js) jsou poměrně "exotické" - počínaje OSGi kontejnerem Apache Felix, přes Ant a konče AMDATU komponentami. Jednou větou řečeno - cestu s OSGi si ve valné většině museli prorážet sami, protože svět se ubírá jiným směrem.

Každopádně KUDOS Luminis - zdá se, že cestu jste si prošlápli a máte plné právo sklízet ovoce svého snažení. Nebál bych se nastoupit k vám do týmu a na podobně rozjetém projektu s chutí pracovat. Z nuly bych to sám rozjíždět ale rozhodně nechtěl ;)

Už to začíná být dlouhé, pojďme to uzavřít

GeeCON je konference, kterou byste si rozhodně neměli nechat ujít. Organizačně je vše zvládnuté na jedničku a já pevně doufám, že české WebExpo dosáhne jednou podobné kvality. Nikde nic nedrhnulo a i catering byl skvělý.

Trochu s nelibostí sleduji nastupující trend prezentací, které jsou víc show než prostředek pro sdělování zajímavých faktů a zkušeností. Pokud bych měl srovnat třeba náš provinční DevFest v Pardubicích s přednášejícími jako je Spazef0rze, Steida - nevyšli bychom z toho vůbec špatně. Tuším, že jako obyčejný kluk z Pardubic, nemůžu nastupující trend "exhibičních přednášek" ovlivnit, ale kdybych přeci jen mohl pár proseb na potenciální přednášející:

• přednášejte s pokorou, v publiku jsou dost možná chytřejší lidé, než jste vy na stagi (nemluvím o sobě)
• legrace je bezpochyby potřeba, ale nezapomeňte ji doplnit dostatkem faktů a ideálně věcí, které mohou, i v době internetu, posluchače něčím překvapit nebo poučit
• buďte induktivní - pokud sdělujete nějaký poznatek, doprovoďte jej příklady z praxe (nejlépe vlastní)
• když budete jen zábavní, jste jako televize - zítra si vás nikdo pamatovat nebude ... když budete zajímaví, dostanete se do článku jako je tento a jste věční :D

Do Krakowa se budu za rok zase rád vracet. Mimochodem, letos se nám povedlo spojit GeeCON konferenci s večerním sledováním keynote z Google I/O s googlery ve zdejší centrále Googlu a následnou párty s prezentujícími uprostřed úžasného historického centra města. Pro mě to byl nezapomenutelný zážitek - sice vzdáleně, ale možná alespoň trochu podobný tomuhle.

Myslím, že i vám by se tam líbilo - tak si příští rok zkuste udělat 3 dny času ;).