sobota 19. listopadu 2011

Postřehy z Devoxx 2011

S kolegy z GoodData jsme vyrazili na konferenci Devoxx, a musím říci předeslat, že to stálo za to. Devoxx je určitě nejlepší konference co se týká Javy v Evropě, která se konala letos po desáté v Antverpách. Paralelně běželo od půl desáté ráno do sedmi večer sedm prezentačních slotů, ze kterých si člověk mohl vybrat to co ho zajímalo. Přestože je to Java konference, byla v nabídce poměrně pestrá škála prezentací z přidružených jazyků a technologií postavených kolem Java Virtual Machine (JVM). Osobně jsem se snažil vybírat prezentace, které neměly s Javou moc společného a to ze dvou důvodů. Jednak nesdílím názor, že postupné nafukování jazyka je cesta, kterou by měly jít další verze Javy. Jednak razím tezi, že člověk by měl chodit na prezentace o technologiích a postupech, které nezná, protože ty ho nejvíce obohatí. Za celou dobu jsem proto z Javy slyšel jenom pár útržků na různých prezentacích.

Clojure

Poprvé v životě jsem viděl Lisp, tedy konkrétně Clojure v dvou prezentacích Alexe Millera. Přiznám se, že syntaxe jazyka pro mě byla natolik exotická, že jsem většinu slajdů v rámci zachování duševního zdraví musel vypustit. Pár postřehů, které jsem si udělal: Lisp dialekt, funkcionální jazyk, kompilovatelný do bajt kódu JVM, imutabilní struktury, kód jsou data, žádné IDE ale Emacs. Síla Clojure se ukázala v prezentaci Stream Execution with Clojure and Fork/Join. V něm bylo prezentováno použití Clojure ve firmě revelytix.com, která umožňuje vyhledávání SPARQL jazykem v RDF dokumentech uložených v relačních databázích. Funguje to asi následujícím způsobem. HTTP rozhraní na které posíláte SPARQL dotazy, z nich se postaví AST a na jeho základě exekuční plán, ten se zoptimalizuje a převede na SQL příkazy, které jsou paralelně vykonány a jejich výsledek sloučen dohromady a vrácen jako odpověď. To všechno prosím pěkně na plus mínus 3000 řádcích kódu Clojure. To na mě udělalo velký dojem, přestože bych spíš pochopil básničky v jazyce Elfů než zdrojový kód, který se tam párkrát objevil.

Continuous Delivery

Každá změna ve verzovacím systému je automaticky přetavena v novou verzi produktu a může se objevit na produkci. Člověk je skoro v pokušení si zaťukat na čelo a jít o dům dál, ale ono to skutečně funguje. Prezentaci měl Dave Farley autor stejnojmenné knihy. Výše zmíněný postup přetavili do praxe ve firmě LMAX, což není garážová firmička, ale pořádný enterprise bumbrlíček, který se živí zprostředkováním finančních transakcí. Kromě toho co jsem psal dříve v článku Continuous Deployment (pozn: ve skutečnosti vaším cílem není deployovat novou verzi, ale doručovat nějakou hodnotu vašim zákazníkům) bych vypíchnul jednu zásadní myšlenku, která zazněla. Pokud chcete někdy kontinuálně doručovat váš software, musíte mít spolehlivý release proces na každé úrovni s dovětkem, že cokoliv co je závislé na zásahu člověka se považuje za nespolehlivé. Více 8 Principles of Continuous Delivery.

HTML 5

HTML 5 byla oblast, kterou jsem v minulosti totálně ignoroval. Musím se přiznat, že HTML 5 pro mě bylo asi největším drahokamem který jsem v Antverpách objevil Někdo použil větu HTML 5 is a game changer a já s tím musím souhlasit, protože nabízí jednu vývojovou platformu pro svět mobilních telefonů, tabletů a osobních počítačů. Ve všech prezentacích zaznělo kolik má problémů z některých jmenujme: nekompatibilita prohlížečů, chybějící nástroje, výkonnost oproti nativním aplikacím, na druhou stranu nabízí obrovský potenciál. Z technologického hlediska mě zaujala jedna zásadní myšlenka. HTML 5 umožňuje (nikoliv znamená!) změnu architektury webových aplikací. Díky HTML 5 si můžeme dovolit napsat aplikaci, která nebude přímo závislá na online připojení k serveru a bude si dokonce moci držet stav.

Cloud a Java

Viděl jsem keynote věnovanou Java EE, ve které byl hlavním tématem cloud. Původně jsem chtěl napsat, že to jak si cloud a aplikace v něm napsané představují chlpaci z Oracle, a jak si jej představují já, jsou dva naprosto odlišné světy. Nakonec jsem dospěl k tomu, že moje představa je pokřivená mými zkušenostmi a agilitou potřeb firmy, pro kterou pracuji. Java EE je opravdu úsilí, které je zaměřeno na dodání standardů pupkatým pánům v korporacích. Když to akceptujete, bude váše chápání Enterprise Javy mnohem méně kritické. Proto snahu o podporu JSONu, JPA nad NoSQL databázemi v další verzi berete s jemným přimhouřením oka. To co nejvíce kontrastovalo s mým chápáním, a nebo to na mě přinejmenším tak působilo, byla vize homogenního cloudu z pohledu hostovaných aplikací a služeb. V případě Java EE to byl EAR/WAR v aplikačním serveru. To si myslím může platit pouze pro určitou skupinu aplikací v určitém typu prostředí a napadají mě opět pupkatí páni... Pokud nemáte jenom EARy, WARy a nebo se jinak odlišujete od představy cloudu, například technologiemi které používáte, už pro vás Java EE koulí na noze.

S tím kontrastovaly prezentace Platform As A Service poskytovatelů, kterým byli Heroku a Cloud Foundry. Přestože by se mohlo zdát, že Java EE a tyto dvě služby k sobě mají stejně daleko, jako Řekové k vyrovnanému státnímu rozpočtu, opak je pravdou. V obou službách totiž přesně pochopili, že vývoj dnešních aplikací se neodehrává v jednom jazyce a za použití jedné technologie. Speciálně bych se zastavil u Cloud Foundry, jehož myšlenka mi přijde skvělá. Skrytý problém dnešního cloud computingu se nazývá vendor lock-in. Česky by se to dalo přeložit jako přikování k jednomu dodavateli. Když si dneska postavíte svojí aplikaci nad Amazonem, budete více či méně svázáni s jeho infrastrukturou a migrace na jiného poskytovatele bude velmi bolestivá. Cloud Foundry by se dala popsat jako prostředník mezi vaší aplikací a poskytovatelem cloud. Namísto toho, abyste aplikaci a nástroje pro monitoring a správu stavěli proti konkrétním službám daného poskytovatele, stavíte je proti API Cloud Foundry, které je adaptuje na konkrétní podvozek. Přechod z jednoho poskytovatele na dalšího pak není tolik bolestivý. Za Cloud Foundry stojí VMware, ale projekt jako takový je open source, tento model bych přirovnal k linuxovým distribucím, jako příklad bych to ilustroval na Stackato.

Závěr

Zaujal mě framework Disruptor pro pekelně rychlé předávání dat mezi dvěma vlákny, když si ovšem přečtete jejich tech paper zjistíte, že máte k dispozici asynchronní event framework. Zaujaly mě rovněž Remote Actory v Akka 2.0 viz strana 27 a Play framework, který kompletně obchází Servlet API a je postavený právě kolem konceptu Actorů. Naopak mě zklamala keynote Tim Braye, ze které jsem si odnesl pouze odvážnou myšlenku, že trh pro aplikace na mobilní zařízení leží v rozvojových zemích. Pocit politicky korektního, rozuměj nic neříkajícího, tlachání jsem měl z diskuzního panelu kde byli mimo jiné pánové jako Joshua Bloch, Brian Goetz, Ben Evans a Mark Reinhold. Buďto všichni právě střízlivěli z párty předešlého dne a nebo tomu chybělo lepší moderování a výběr otázek. Jsem v pokušení napsat, že Filemon by to zvládnul lépe než Tor Norbye. Nikdo z nich v podstatě nepřinesl na stůl nic nového a především se snažili hlavně někoho neurazit.

To byl Devoxx 2011 mýma očima.

Mimochodem doporučuji i postřehy Lukáše Křečana, které jsou vtipnější než ty moje a navíc jsme navštěvovali až na pár vyjímek různé prezentace.