Reportáž z GeeCON 2012
GeeCON si již vydobyl své místo na slunci mezi evropskými konferencemi a není třeba ho příliš představovat. Osobně jsem s kvalitou přednášek vždy velmi spokojený a proto jsme s kolegy vyrazili na GeeCON letos již potřetí. Organizátorská práce byla jako vždy skvěle odvedená - cateringem počínaje a luxusními prostory v multikině konče. Člověk si musí jen trošku povzdechnout, když si vzpomene na tvrdé židle v přednáškových místnostech a catering univerzity v případě největší české konference WebExpo. Nicméně, člověk nejezdí na konference kvůli sedačkám a jídlu, ale kvůli kvalitnímu obsahu a tak se dá i v případě WebExpa leccos překousnout. Majorita účastníků byla samozřejmě z Polska, ale okolo bylo slyšet i dost češtiny a moravštiny, což mi vážně udělalo radost. Na GeeCONu letos přednášeli i dva češi - Pavel Lahoda o problémech při vývoji na Androidu a Honza Kotek o JDBM (rozepíšu se dále). Pokud vás zajímá, jak vypadal celý GeeCON mýma očima, čtěte dál ...
Jazykový koutek
Pro první den jsem si složil z přednášek takový malý jazykovou koutek - v jednom dni jsem absolvoval prezentace "nových" jazyků nad JVM - Kotlin, Ceylon a tak již docela etablované Scaly. Říkal jsem si, že bude zajímavé vidět jazyky a jejich přístupy vedle sebe a nemýlil jsem se. Z hodně velkého nadhledu by se dalo říci, že Kotlin a Ceylon bez ostychu "vykrádají osvědčené" vlastnosti jiných jazyků (a sebe navzájem).
Ačkoliv by se mohlo zdát toto prohlášení jako urážlivé, myslím to v tom nejlepším slova smyslu. Zdá se mi, že oba jazyky přistupují pragmaticky k technikám v jiných jazycích, kopírují je a upravují tak, aby využily jejich přednosti a potlačily negativa. Pokud si třeba berou inspiraci ze Scaly, oba hlavní autoři shodně prohlašují, že Scala vyzkoušela řadu nových přístupů, které ovšem implementovala v tak obecné a otevřené formě, že je velmi těžké pro běžné programátory je využít správně. Často se tak stává, že si programátoři při jejich používání pod sebou nevědomky podřezávají vlastní větev.
Zajímavé mi přišlo, že Ceylon například opustil poměrně standardní pojmenování základních klíčových slov - místo public používá shared, místo @Override má klíčové slovo actual, zavádí vlastní formát "JavaDocu" - často se i mění sémantika použití. Na první pohled mi připadá Kotlin pro Java programátora o něco srozumitelnější než Ceylon.
Zatím jsou však oba projekty ve velmi rané fázi a celá řada vlastností teprve čeká na implementaci - nicméně už teď se mi zdá, že Kotlin urazil o něco delší cestu než Ceylon, přestože začal později (pracuje na něm také relativně víc lidí). Oba dva jazyky mají za cíl stát se "industriálními jazyky" - tedy zaměřují se na programátorské masy, týmovou spolupráci a servisovatelnost (tj. oba obětují snadnost zápisu ve prospěch snadnosti čtení a pochopení obsahu).
Oba jazyky budou podporovat kompilaci do více cílových "formátů" - kromě bytecode JVM se budou oba umět shodně kompilovat do JavaScriptu, Kotlin navíc i do Dalvik bytecode. Oba jazyky také již na úrovni kompilace hlídají problémy spojené s NullPointerException - ve zdrojovém kódu konkrétního jazyka kompilátor hlídá, které proměnné mohou nabývat NULL hodnoty a u takových striktně vyžaduje ošetření. Problém ovšem nastává na rozhraní s kódem napsaným přímo v Javě, kde nullabilita není normálně vidět. Jsou samozřejmě podporovány anotace @NotNull a @Nullable, ale ty třeba v JDK jako takovém nenajdeme. Ceylon k tomu přistoupil jednoduše - nechává vše na programátorovi, aby si pročetl na konkrétním místě dokumentaci k volané metodě JDK a sám určil, jestli může vrátit NULL hodnotu nebo ne. Kotlin naproti tomu pracuje na čemsi, co by se dalo nazvat hlavičkovými soubory pro JDK, proti kterým by se kompiloval kód Kotlinu a které by obsahovaly informaci o nullabilitě parametrů a výstupů z metod JDK. To mi přijde jako velice zajímavé, protože to samozřejmě může ušetřit dost času - zvlášť zkraje, kdy bude ještě málo knihoven přímo v Kotlinu a většina kódu, který se bude používat bude pocházet přímo z Javy.
K jednotlivým jazykům konkrétněji:
Kotlin
Vlastnosti Kotlinu si už teď můžete vyzkoušet v online interaktivní konzoli. Podpora pro IDE je prozatím vyvíjena samozřejmě jen pro IntelliJ Ideu (myslím, že pokud to myslí s jazykem vážně budou se muset sami postarat i o plugin do Eclipse a nespoléhat na komunitu). Kotlin se pomalu blíží do beta verze, která je pro JetBrains důležitá v tom, že v této fázi chtějí ve větším měřítku nasadit Kotlin pro vývoj i na vlastních projektech (JetBrains) a migrovat některé stávající. Tento přístup se mi dost líbí - JetBrains mají dost rozsáhlou codebase, tým i zkušenosti, aby si na vlastní kůži dokázali otestovat fungování jednotlivých vlastností nového jazyka.
Jazyk by měl být pro verzi 1 zafixován na konci tohoto roku. Hlavní taháky Kotlinu jsou uvedeny na této stránce vlastností. V poslední verzi IntelliJ Idea pluginu (možná budete muset buildit přímo ze zdrojáků) by měl být základ automatického konverzního nástroje z Java kódu do Kotlinu. Návod na zprovoznění Kotlinu v IntelliJ Idea je na blogu Hadi Hariri.
Ceylon
Podpora v IDE je vyvíjena pro Eclipse. Uzavření základní verze jazyka by mělo být také na konci tohoto roku - nicméně v současné době je k dispozici pouze milestone 2 z plánovaných 5. Sympaticky působí sada hodnot, které si Ceylon vytyčil: čitelnost, předvídatelnost, integrovatelnost s IDE, modularita a metaprogramovatelnost (tj. legální otevření AST programátorům).
Ceylon již představil své plánované repository modulů nazvané Ceylon Herd, které tvrdě zavání NIH syndromem (ačkoliv chápu důvody, které je vedly k tomu nepoužít existující repo Mavenu). Zdrojové kódy Ceylonu jsou také umístěny na GigHubu, takže můžete začít hackovat, stejně jako Tomáš Hradec od nás z Čech.
Pel-mel poznámek z dalších přednášek
Bohužel poměrně dost dalších přednášek na letošním GeeCONu pro mě osobně nepřineslo nic objevného nebo zajímavého. Z většiny si odnáším jen pár nevšedních postřehů, ale žádné velké závěry. Dost mě zklamal Bruce Eckel, který plaval hodně po povrchu a nic moc kloudného z něj nevylezlo. Obecnými doporučeními typu - programátor by se měl konfrontovat co nejvíce s lidmi mimo obor a měl by být otevřený k novým jazykům a přístupům dnes už nikoho neohromí ani nepřesvědčí. Ti, co to vážně myslí, už to dávno dělají.
Jediná zajímavá poznámka z jeho přednášek se týká jazyka Go - ten dle všeho nemá otevřenou podporu pro exception handling a informace o výjimečných stavech se předávají v návratových hodnotách typicky pomocí tuples (pokud se zároveň má předávat i jiná výstupní hodnota). To mi přišlo hodně překvapivé - žil jsem v přesvědčení, že chybové návratové kódy jsou přežitek. Zajímavá diskuse je v tomto vlákně na StackOverflow, nicméně i tak mi přijde míchání standardní logiky s ošetřením výjimečných stavů úkrokem stranou.
Z přednášky Ivara Jacobsona jsem si odnesl pár zajímavých čísel - celosvětově je okolo 20 miliónů SW vývojářů (což mi nepřipadá zase tak moc), z univerzitních doktorských prací v oboru SW má na IT průmysl dopad pouze 1% z nich (což je ještě horší skóre než úspěšnost startupů, čekal bych to spíš někde kolem 20%). Dále mi přišla zajímavá idea, že v situaci, kdy nemáme dostatečně jasný cíl kam chceme dospět je třeba si definovat sadu hodnot, kterých se při návrhu, prototypování a "objevitelské cestě" k cíli budeme držet. Už jsem pár projekty, které takto na vodě byly prošel, a aniž bych si to uvědomoval, byly to právě jasně vymezené mantinely a hodnoty, které umožnily projekt dotáhnout do použitelného stavu.
Z přednášky o špatných a dobrých testech si odnáším pár doporučení. Testovací metody neprefixovat slovíčkem "test" (jak to třeba dělám já), ale slovíčkem "should". Slovíčko should daleko lépe povědomně nutí člověka k lepšímu pojmenování testu (název testu není jen pomocná věc, ale jeho zásadním prvkem - především v souvislosti s pochopitelností obsahu testu pro ostatní). Tj. každý test by měl být pojmenován ve smyslu - shouldStoreAccountBalance, shouldWithdrawExistingBalance, shouldFailWhenWithdrawingZeroBalance atd. Pokud test selže, je lépe už z názvu vidět, co fungovat mělo a nefungovalo. Věřím tomu, že tyto drobné pomůcky hrají roli.
Dalším zajímavým postřehem byl způsob jakým řeší extrakci komplikovaných assertů do samostatných znovu použitelných tříd, fungujících na principu builder patternu. Dále doporučoval extrakci boolean hodnot, magických čísel a stringů do konstant testu, s konkrétním pojmenováním vyjadřujícím v daném kontextu podstatu dané hodnoty lidsky čitelným způsobem. Na příkladech bylo skutečně patrné zlepšení čitelnosti testu, takže vynaložená námaha se při prvních pár revizích jistě vrátí. Padla také zmínka o knihovně Hamcrest, která se specializuje na variantní práci s asserty. Pro sebe si poznamenávám, že knížka Practical Unit Testing od autora přednášky, by pravděpodobně stála za pár vynaložených dolárků. Na čitelnosti svých testů musím zapracovat a každá pomůcka se každopádně hodí.
Od přednášky o Apache Mahout jsem čekal nějaké praktické použití učících se algoritmů, které by průměrnému programátorovi (jako jsem já :) ) otevřely cestu k takovým možnostem jako je genetické programování a další adaptivním algoritmům. Bohužel v přednášce toho bylo jen málo konkrétního, takže se v podstatě nedalo vydestilovat o moc víc, než jen to, že knihovna Apache Mahout podobný cíl má. Bez hlubší znalosti algoritmů jako takových, statistiky a dalších věcí, bude nasazení podobné záležitosti na projektu dost obtížné. Na druhou stranu by to možná mohl být přeci jen lepší startovní bod než implementace učících se algoritmů z nuly. Za současného stavu dokumentace to každopádně bude oříšek.
JDBM3 - NoSQL DB pro desktopy
Má předposlední přednáška se týkala NoSQL knihovny JDBM3, která je nyní spravovaná českým autorem Honzou Kotkem žijícím v Irsku. Knihovna je velmi malá, ale dle čísel prezentovaných na přednášce velmi výkonná. Knihovna se orientuje především na desktopy a jednovláknově pracující aplikace - tj. jejím hlavním cílem není škálovat přes sadu nodů v clusteru, ale běžet co nejvýkonněji na jednoprocesorové mašině nebo v rámci jediného vlákna. Na běžném notebooku s velmi omezenou pamětí dokáže operovat s terabajty dat v milisekundových odezvách.
API knihovny není složité a je postavené na standardním rozhraní Java Mapy. Setup je velmi jednoduchý a přibalit se dá lehce do jakékoliv aplikace (a nemá žádné dependence). Ačkoliv naší doménou jsou webové aplikace, mám několik případů, kdy by se mi podobná databáze pro účely dávkového zpracování docela hodila. Myslím, že si nějaký jednoduchý prototyp brzy napíšu, abych si ověřil, jestli JDBM opravdu plní to, co o ní autor povídá.
Mimochodem Honza aktuálně v Irsku shání práci a podle toho krátkého rozhovoru, který jsem s ním měl, myslím, že by byl přínosem v každé firmě. Pokud tedy máte někoho známého v Irsku, kdo hledá kvalitní zaměstnance, určitě mu pošlete kontakt.
Závěrem
Konference není jen o přednáškách, ale i o zajímavých diskusích na večerních "social eventech", které jsem letos velmi rád strávil s Martinem Škurlou a Pavlem Lahodou. Je také o zábavných a odlehčených přednáškách jako byla ta od Kevlina Henneyho Cool Code, kterou doporučuji ke shlédnutí. Mmch. znáte třídící algoritmus Sleep Sort? Ne, je to převratná novinka loňského roku, kterou doporučuji řádně prostudovat - je vhodná především pro vícejádrové processory :)
Atmosféra letošního GeeCONu na vás možná dýchne z fotek, které přikládám na závěr. Takže zase za rok ...
[gallery link="file" order="DESC" columns="4" orderby="post_date" exclude="1960,2010,2011"]
Komentáře