GeeCON 2011
Polská konference GeeCON nabírá na popularitě a letos již byla s předstihem vyprodána. Možná to není takový tahák jako Google I/O, které se vyprodalo hned po 2 dnech, ale myslím, že pro Java pozitivního středoevropana je to jedna z velmi lákavých událostí roku. S kolegy z Forresta jsme na ni vyrazili již v úterý, abychom se ve středu zúčastnili University day s rozšířenými (3h) prezentacemi na konkrétní témata.
Kluci z polského JUGu mají akci perfektně zvládnutou a za celé 3 dny jsem nenašel jedinou chybičku, kterou bych jim mohl vytknout. Multikino je pro pořádání těchto akcí, řekl bych, ideální prostor a tak je mnohahodinové sezení v pohodlných sedačkách v klimatizované místnosti snesitelné. Nakonec jsme na konferenci všichni stejně kvůli speakerům, ale tyhle drobnosti dělají hodně - myslím, že GeeCON má ve velké míře všechno co chybělo na českém @WebExpo (prostory, organizace, stravování).
Dost planého tlachání ... pokud máte zájem podívejte se, co mne připadlo zajímavé na přednáškách letošního GeeCONu.
University day
V první přednášce rozebíral @aalmiray základní stavební kameny Groovy ekosystému a v podstatě jen prolétnul základní knihovny, o kterých se obecně ví už nějakou dobu: Grails, Griffon, Gant, Gradle, GPars, GroovyServer. V této přednášce tedy nic zásadně zajímavého, krom jediné zmínky mimo hlavní téma - SpringSource prý pracuje na podpoře reloadingu class za běhu podobném tomu, které dodává JRebel, s horizontem releasu do konce tohoto roku. Každá aktivita v této oblasti se vítá, navíc se dá předpokládat, že by tato funkcionalita mohla být dostupná zdarma v rámci frameworku jako takového. No uvidíme.
Druhý blok si vzali na starosti @agoncal a alexismp a týkal se Java EE 6. Poměrně zajímavou informací bylo, že některé části (např. CMP 2.X, JAX-RPC a další) budou z Java EE 7 odstraněny, to je věc v Java ekosystému velmi nezvyklá - obvykle jsou pečlivě ošetřovány i hroby dávno zemřelých. Většina dalších věcí jde směrem další standardizace a zjednodušování věcí, které jsou nejvíce bolestivé jako např. standardizace JNDI pojmenování mezi různými aplikačními servery, možnost embedování EJB kontejneru pro účely testů a použití pro desktop (hmm), standardizace Dependency Injection anotací (i když odklon od @Resource k @Inject v CDI ve mě zanechává smíšené pocity).
Velmi zajímavé změny (konečně!) jsou v oblasti Servlet 3.0 specifikace - pouhým přilinkováním JARu konečně dostaneme automatickou registraci servletů a filtrů do webového kontextu. Jednotlivé knihovny však mohou provádět nejen to - pomocí /META-INF/web-fragment.xml mohou v podstatě nadefinovat část web.xml souboru, kterou pro svůj běh potřebují. Jelikož tato automatizovaná registrace představuje jisté riziko, že se ve vaší aplikaci objeví něco, co byste nechtěli, máte nad touto samoregistrací možnost kontroly pomocí definice ve web.xml.
Prakticky použitelné jsou anotace @Schedule se zápisem časování podobném Linux Cronu a @Asynchronous, které jsou taktéž dostupné ve Springu.
Jelikož nepoužíváme JSF byla pro mě poměrně překvapivá informace o podpoře partial update v JSF 2, která se velmi podobá té naší, ke které jsme nezávisle také dospěli. Bohužel se mi nikde nepodařilo nalézt, jak se JSF v takovém případě chová k historii prohlížeče, graceful degradation nebo frontování duplicitních ajaxových požadavků. Pokud některý z čtenářů ví o tomto chování JSF 2 víc, budu rád, když se o to podělí v komentářích článku.
V poslední přednášce středečního odpoledne rozebíral @HamletDRC existující možnosti pro generování byte kódu v Javě. Od Spring Roo, přes Lombok až ke Groovy AST transformacím. Ačkoliv se jedná o velmi elegantní řešení některých problémů, obávám se, že pro řadu nasazení mají stále zásadní omezení - počínaje podporou v IDE a konče srozumitelností pro "průměrného" vývojáře. Při ukázkách cílového kódu používal Hamlet Groovy konzoli, kde se pomocí menu dá otevřít AST Browser, který obsahuje nejen vizualizaci AST, ale také i dekompilovaný kód, který je jím představován. Byl jsem velmi překvapen, jak může být automaticky generovaný byte kód při zpětné dekompilaci čitelný.
Den první
První den začal keynote o nadcházející Javě 7, která by konečně měla vyjít někdy v létě letošního roku. V tomto ohledu žádné nové věci (kromě těch již dávno známých) samozřejmě nepadly. Důležité spíš je, že Oracle alespoň drží slíbený termín.
Zajímavé věci v jazyce jako takovém jsou plánované až do verze 8. Danny Coward hovořil o Lambda funkcích (closures) a o (pro mě dosud neznámé) podpoře "interface extension", díky níž by mělo být možné bezpečně rozšiřovat stávající interfacy. To je věc, která by mně osobně, skutečně vytrhla velký trn z paty (mí kolegové budou vědět o čem hovořím), protože nastřelit hned napoprvé dokonalý interface se mi podaří jen málokdy.
Vydání Java 8 se plánuje na konec roku 2012, ale do té doby ještě uplyne hodně vody, takže na těšení máme spoustu času.
V následující přednášce Jurgen Hoeller rozebíral nové funkcionality v nadcházející verzi Spring 3.1 a základní vlastnosti stávající verze 3.0. Jednalo se pravděpodobně o recyklovanou přednášku z loňského Spring One, kterou zachytil už jiný blogger zde: SpringOne 2010: What's New in Spring Framework 3.1, takže ji tady nebudu přepisovat. Deklarativní podpora cachí zní zajímavě a opět nám trošku zjednoduší běžnou programátorskou práci - stejně tak jako podpora odlišných deployment prostředí.
Následující 2 přednášky byly pro mně takové osvěžující, jelikož v nich Heinz Kabutz a Hamlet D'Arcy z JetBrains akademie popisovali programátorské techniky, které se jim v praxi osvědčily. Počínaje takovými základními pravidly jako je psaní všemi deseti, aniž by se člověk díval na monitor či klávesnici, osvojení si klávesových zkratek vašeho IDE pro jeho ovládání bez pomoci myši až k doporučením tykající se strukturování kódu:
- dekomponovat kód do tříd o průměrné velikosti 80 řádků na třídu
- vymazávat zakomentovaný kód (od toho je přeci VCS)
- před refactoringem zajistit rozumné pokrytí původního kódu testy (jinak slovy klasika: "you're not refactoring, you're just changing shit")
- komentovat nikoliv to, co metoda dělá (to by mělo být patrné z názvu metody, vstupních parametrů a jejího kódu) ale proč to dělá
- použitím final keyword u lokálních i globálních proměnných, se často vyhneme nepříjemným chybám
- co nejvíce se vyhnout použitím globálních proměnných, instanční privátní metody převést na statické, čímž se donutíme do jejich parametru vložit všechny potřebné vstupy pro jejich běh (je tak lépe čitelný kontrakt metody)
- v případě, že nevíme kde začít s testováním, nebo na co se při testování soustředit - je dobré začít s třídami, které se mění nejvíce (tj. mají nejvyšší verzi v našem VCS)
- nebojte se experimentovat pomocí "scratch refactoringu" - tj. refaktoringu, který pravděpodobně rollbacknete
, ale něco si na něm vyzkoušíte nebo se naučíte
Poslední přednáška od @nicolasleroux a @mbknor se týkala evangelizace frameworku Play!, který víc než frameworkem je plnohodnotným full-stack ekosystémem pro realizaci webových řešení. Přednáška byla velmi zábavná především díky skvělému výkonu Nicolase Leroux a jeho francouzskému temperamentu. Během 25 minut zvládli pánové na pódiu vytvořit z nuly chatovací aplikaci pomocí HTML5 websocketů, což na nás všechny udělalo opravdu dojem. Play! má celou řadu zajímavých vlastností jako třeba kompilace Java tříd za běhu (PHP like style development), připravený a přizpůsobený stack osvědčených Java technologií pro web development, Groovy šablonovací systém a další. Zajímavé je, že Play! má vlastní implementaci web serveru a nepodporuje Servlet specifikaci (určuje si vlastní pravidla). Vlastní implementace je kompletně postavená na asychnronním zpracování požadavků pomocí NIO a díky tomu také dokáží efektivně zpracovávat komunikaci pomocí websocketů. Kolegové byli z dema úplně unešení a myslím, že si s Play! trošku pohrajeme, což bych ostatně doporučoval i Vám.
Den druhý
Dnešní den začal vystoupením @jimwebber na téma SOA ve velkých organizacích. Konkrétně rozebíral projekt jednoho britského telefonního operátora, který měl nasazené SOA řešení na řešení voice to mail služby, které v dané době absolutně neškálovalo a v daném objemu přenášených zpráv na každé zprávě operátor prodělával. Technické řešení bylo pro operátora takovým problémem, že si nechal od renomovaného konzultanta zpracovat návrh změny stávajícího řešení, které by stav změnilo. O několik měsíců později dodal konzultant několika set stránkovou studii, která končila doporučením nasadit ESB řešení v základní ceně $50 mil. s následnými implementačními pracemi nejméně ve stejné hodnotě (s rozsahem 2-4 let na finální nasazení). Jim následně prosadil vyzkoušení odlišného řešení v čistě agilním duchu. Navrhoval vytvořit levný prototyp, který se pokusí řešit některé hlavní problémy částí systémů, které identifikovali jako úzké hrdlo (tj. nikoliv kompletní předělávka celého systému, jak doporučoval původní konzultant). S minimálními investicemi dokázali sestavit prototyp, který svými vlastnostmi přesvědčil investora pokračovat dál v tomto "partyzánském" experimentu. Po 14 iteracích a 5 měsících práce předali zákazníkovi nové řešení části systému postavené na komoditizovaných komponentách dostupných ZDARMA!, které vyřešilo zásadní výkonnostní nedostatky původní komponenty v systému a zvýšilo kondici celého systému odlehčením zátěže okolních "komponent". Tímto způsobem pokračovali s další částí identifikovanou jako úzké hrdlo a nakonec ve velmi krátkém čase po jednotlivých iteracích dostali celý systém do černých čísel s vynaložením o řád menších nákladů než byl původní návrh nasazení ESB. Tento kousek se asi každému nepovede a já sám mám také spíš negativní zkušenosti s enterprise řešeními, takže mi toto vystoupení vyloženě hrálo do noty.
Další zajímavou přednáškou dnešního dne bylo hackovací sezení s autorem Vaadin frameworku @joonaslehtinen, který na praktických ukázkách představil nevýhody RIAA frameworků s logikou umístěnou na straně klienta. Obdobné kousky, které prováděl na pódiu, si můžete vyzkoušet sami na testovací stránce PayMate. Kromě jednoduchého SQL injection, byly zajímavé praktické ukázky Request Forgery, ve kterých jednoduchou prací s Firebugem sniffoval komunikaci GWT se serverovou částí a manipuloval s parametry volaných funkcí. Zajímavý byl i útok pomocí tzv. "reference forging", kdy při volání podhodil Joonas id cílového objektu a načetl tak data, na která neměl právo. Cílem bylo upozornit na relativně triviální chyby, které se běžně stávají, pokud je technologie jako taková umožňuje. Doporučení samozřejmě směřovalo na RIA framework Vaadin, který tyto věci provádí na serverové straně a je tedy z podstaty proti těmto útokům imunní, aniž by se o to musel programátor starat.
V dalším bloku přednášel @bbosola o Gitu. V demu prošel základní vlastnosti Gitu a osobně jsem zde zaznamenal pár pro mě nových informací:
- Git neukládá ve verzích souborů delty, ale tzv. snapshoty - tj. kompletní verze změněných souborů / symlinky na nezměněné soubory představující konkrétní stav v daném čase (v čase commitu)
- vzhledem k držení kompletní historie na klientovi není Git vhodný pro verzování binárních souborů jako jsou fotky, videa atp. - pro naše účely (rozsáhlé webové prezentace) by bylo nutné využívat funkcionality submodulů, aby pro nás Git škáloval
- před commitem je nutné i modifikované (ne jen nové) soubory přidat do "staging area" pomocí příkazu add (toto je oproti CVS, na které jsem zvyklý docela změna) - do commitu se dostává jen to, co je součástí staging oblasti (zajímavé ovšem je, že při použití Gitu v IDE toto potřeba není)
- git pull = git fetch + git merge
- místo mergování změn se často používá rebase, který zanechává commit history čistší
Při hledání detailů nedostatečně vysvětlených v přednášce jsem narazil na komunitní knížku o Gitu, která většinu věcí poměrně srozumitelně vysvětluje.
A teď se dostávám k poslednímu vystoupení na téma "nosql" databáze Neo4J v podání @jimwebber. Neo4J je databáze určená pro ukládání grafově orientovaných dat, ve kterých dokáže velmi rychle vyhledávat. Příklad, který zazněl na přednášce je požadavek na vyhledání přátel do "5tého kolene" v databázi přátel. V relační databázi se skutečně jedná o nelehký ale realizovatelný úkol - v případě 1000 uživatelů si MySQL s tímto problémem poradila za 2000ms, kdežto Neo4J za 2ms, v případě 100 tisíc uživatelů už měření z MySQL nebylo realizováno (ale dokážu si výsledek představit) - nicméně Neo4J i v tomto počtu stačily stále pouhé 2ms na dodání výsledku. Zajímavostí Neo4J databáze oproti ostatním "nosql" databázím je plná podpora ACID. Neo4J nemá žádné schéma, je možné vytvářet neomezený počet uzlů s neomezeným počtem vztahů s ostatními uzly, na každém uzlu i vztahu je možné vložit libovolné množství metadat. Neo4J má Javovské API ve kterém se definuje struktura grafů i provádí vlastní traverzování. Pro prohledávání vznikl i nový dotazovací jazyk s názvem Gremlin, což je DSL postavené nad Groovy. Zajímavou myšlenkou je použití Neo4J jako index pro vyhledávání relačních dat v případě složité vztahové struktury. Neo4J má dva druhy licencí, přičemž verze zdarma má GPL licenci - nicméně pro webové aplikace je možné tento druh verze využít, jak nám potvrdil i Jim Webber osobně. Zdá se tedy, že by se Neo4J pro některé naše use-casy mohla docela hodit.
Závěrem
GeeCON konference je organizačně skutečně velmi dobře provedená a organizátoři ví, že networking je druhou nejdůležitější věcí na konferencích, a proto na každý večer připravili společnou párty, kde bylo možné si popovídat s ostatními účastníky konference. Osobně nemám co GeeCONu vytknout a myslím, že i výběr speakerů byl velmi dobrý. V některých ohledech bych možná uvítal trošku hlubší průnik do některých oblastí, ale nejsem si jist, jestli je to před tak širokým publikem vůbec možné. Na konec přidám pár fotek z konference a opravdu úchvatného centra Krakowa:
Komentáře