Jaký byl pražský GeeCON 2014

Ve dnech 23.-24.10.2014 jsem navštívil konferenci GeeCON, jež byla po řadě ročníků v Polsku pořádána poprvé v Praze. Multikino CineStar na Černém mostě vytvořilo opět nezaměnitelnou atmosféru a na přednášky i doplňkový program konference byly velmi příznivé ohlasy. Ačkoli jsem z naší firmy jel sám, na místě jsem potkal řadu známých tváří z minulosti (především z nedávno skončené nekonference JOpenSpace). Přece jen bylo znát, že konference je v Česku, i když zastoupení polských účastníků bylo poměrně značné.

Sponzorem tohoto článku je společnost Y Soft, které s radostí děkuji za volňáska na konferenci.

Y Soft – platinový sponzor konference a mezinárodní společnost nabízející unikátní tiskové řešení (software i hardware), které umožňuje společnostem a organizacím efektivně kontrolovat náklady, snížit plýtvání, zvýšit komfort uživatelů a pozitivně působit na životní prostředí.

Kdo tedy pro mne byly největší hvězdy konference?

Oleg Šelajev – Unlocking the Magic of Monads in Java 8

Monáda je pojem, o který zakopl každý, kdo o funkcionálním programování aspoň něco málo sleduje a většinou to mají programátoři spojeno s něčím zcela odtrženým od reality, vědou a abstraktní matematikou. Oleg měl celou přednášku na hlavě čepici (černý kulich) s velkým bílým písmenem λ na čele. A to je s nadsázkou asi tak vše, co měla přednáška s matematikou společného. Nejprve se vtipně zeptal, kdo je tady proto, aby se dozvěděl něco o monádách (téměř všichni), a kdo proto, aby ho kontroloval, zda vše říká dobře (jeden člověk zvedl ruku). Na prezentaci bylo vidět, že naprosto realisticky odhadl, jaké mají jeho posluhači o monádách povědomí.

Nás, kdo děláme pouze s Javou, si navíc jistě získal i tím, že před povídáním o samotném tématu nahlas pojmenoval současnou situaci, kdy se z těchto věcí až příliš dělá jakási magie či nástroj zasvěcených. Konkrétními projevy tohoto fenoménu jsou např.: vysvětlování na jazyku s divokou syntaxí (Haskell, Scala), nespočet tutoriálů, které sklouznou moc brzy na hloubku, "machrování" co nejsložitějšími vytrženými matematickými definicemi v popularizačních přednáškách nebo vtipkování – např. tato parodie nebo známý aforismus o nemožnosti vysvětlit monády (o něm sice nemluvil, ale zařadil jsem ho sem vzhledem k tomu, jak se retweetoval můj tweet, rovněž předchozí odkazy doplňuji sám). To vše rozhodně nenapomáhá, aby se do toho zvenčí člověk dostal a podle přípravy prezentace se zdá, že si toho Oleg byl vědom.

Již několik let jsem na žádné přednášce nezažil, že by se speaker tak často ptal posluchačů, zda rozumějí a může jít dál. Ukázalo se nakonec, že to není tak hrozné, pokud se to vysvětluje na nám známé javovské syntaxi a jde se postupně. Monádu si lze v Javě představit jako návrhový vzor realizovaný generickým typem Monad<T>, který má 3 základní metody: tvorba Monad<T> z T, transformace Monad<T> na Monad<R> a vrácení hodnoty T. K čemu je to dobré? K vyjádření sledu kroků, kde na konec každého z nich navazuje další volaný přes callback. Zatímco řešení bez použití monád vede s rostoucím počtem kroků k zesložitění zápisu, jež je zapříčiněno nabalujícím se vnořováním callbacků, použití monád zachová lineární a tím relativně čitelný zápis (není náhoda, že v Javě jsou v módě fluent API, pro navazování monád je to přirozený prostředek). Oleg to vysvětloval na vylepšeném Future (Promise), dalším praktickým příkladem je JDK8 Optional.

Nelze říci, že po odchodu z přednášky budu programovat monády jako když bičem mrská. I přes veškerou snahu nepoplašit matematikou Oleg jasně upozornil, že monády jsou matematický koncept a člověk otevřený matematice bude mít vždy v jejich pochopení náskok. Ale podařilo se mi získat představu a tento fenomén si zařadit. Z přednášky mám velmi málo zápisků, protože jsem od začátku správně tušil, že tady je třeba si sednout, vypnout se a jen koukat, nepsat ani netweetovat.

Útržky:

• 30% účastníků přednášky již používá JDK8 na produkci
• existují algebraické zákony pro monády – levá a pravá identita a asociativita
• jazyky jako Haskell nebo Scala mají monády částečně podporované syntakticky
• naopak u Javy (označoval ji za mortal platform) se musí řešit dodatečné issues, aby to fungovalo
• JDK8 streamy nejsou monády

Lukas Eder – 2000 Lines of Java? Or 50 Lines of SQL? The Choice is Yours

Píšete hodně SQL volaného z Javy? Přijde vám normální, že JDBC se na SQL – ano, na tento statický jazyk s pevně definovanou syntaxí a typy – dívá jen jako na pouhý řetězec? Mně už dlouho ne, ani mě nebaví pořád slepovat SQL ze Stringů nebo tahat z resourců. Podpora v IDE je slabá záplata (uznávám ale, že nápověda v SQL v IntelliJ IDEA je cool), hypotetické přidání multiline String literals do Javy by sice bylo o něco lepší, ale pořád se typová kontrola ztrácí.

Na tuto skutečnost cílí knihovna JOOQ (pozor, nečte se to "jé ó ó kvé" ani "džej ou ou kjů", ale prostě "džúk"). Geniálně jednoduchá myšlenka konstrukce SQL dotazů pomocí javovského fluent API. Lukas je skromně vystupující speaker, jehož přednáška mne lákala především kvůli této knihovně. Paradoxně jsem si nakonec odnesl z přednášky mnohem víc, i když se o JOOQ téměř nezmínil. Šel totiž do hloubky a zaměřil se na to, proč vůbec v dnešní době ORM frameworků zůstat u starého dobrého SQL. ORM frameworky totiž řeší především problém persistence dat. Dotazování se je pro ně až sekundární problém. Nadměrný důraz na dotazování může být symptomem, že ORM nástroj není zvolen resp. používán správně. Pokud zmigrujeme projekt, jehož business logika byla implementována na úrovni SQL, na ORM řešení, a následně potřebujeme dělat dotazy, máme v podstatě dvě možnosti. Buď zůstaneme u SQL, z nějž se stane pouhý String, a tím obětujeme typovou kontrolu. Nebo přistoupíme na dotazování se přes nějaký objektově dotazovací jazyk, což zpravidla vyhovuje u jednoduchých dotazů. U složitějších začíná být přínos sporný jak co do srozumitelnosti, tak výkonu, v porovnání s SQL stojícím na desetiletími ověřené relační algebře. Sklouzává to k mnohem méně efektivní implementaci, případně i k nějaké formě postprocessingu v aplikaci (to je těch 2000 řádek Javy v názvu přednášky). A typová kontrola jde do kytek stejně.

Z tohoto úhlu pohledu tedy vychází SQL jako velmi cool prostředek. Má velkou univerzálnost (zmínil například LHC, jinak Lukas je právě ze švýcarského Zürichu), stojí na spolehlivých základech teorie množin a přesto je ukecaný a tím srozumitelný i lidem-neprogramátorům typu operations, business analytik nebo doménový expert. Mimochodem podle dělení Martina Fowlera bychom na SQL mohli nahlížet jako na externí javovské DSL, JOOQ by pak bylo odpovídající interní DSL.

Většina přednášky byla tedy věnována výhodám SQL. Lukas se zaměřil výhradně na Oracle, což mi nevadilo, protože ho používáme. Ukázal, co vše se dá pomocí Oracle SQL vyjádřit a jak může deklarativní přístup přinést kód, který je stručnější a využívá správnou úroveň abstrakce. Příkaz merge, selecty v selectu, tuples a row value expressions, klauzule with, rekurzivní with, analytické funkce a klauzule model – to vše jsou konstrukty, které na první pohled vypadají jako COBOL, ale po osvojení jsou čitelné a říkají, co se má dělat, nikoli jak. Vše ukázáno na jednoduchém příkladu selectu, který vracel aktuální zůstatky účtu z tabulky jednotlivých transakcí, podloženo explain planem.


Útržky:

• calculations should be done close to the data
• SQL má odlišnou sémantiku díky 3hodnotové logice (puzzlík s NULL)
• klauzule model – selectuje z db podobně jako vzorce v excelu

Po přednášce jsem ještě za Lukasem došel současně s dalším zájemcem. Lukas nám ochotně ukázal na svém notebooku demo ukázku JOOQ v akci a vnitřnosti kódu – jak řešili ochranu před SQL injection, inlinování hodnot parametrů, fígly s generikami zajišťující typovou bezpečnost a fluent API, napojení na JDBC, injektnutí dodatečné konfigurace (např. jak zajistit generování všech SQL identifikátorů v uvozovkách). Zajímavou debatou jsme strávili ještě 3/4 hodiny, takže následující slot přednášek jsem kompletně vynechal, ale rozhodně toho nelituji.

Anton Arhipov – Having fun with Javassist

Po Olegu Šelajevovi další JRebel. Javassist je knihovna pro manipulaci s bytekódem. Povídání plné praktických ukázek, jak se napíchnout na běžící aplikaci a změnit v ní třídy za běhu, živá ukázka spuštění Java agenta.

Java agent je třída, která má metodu public static void premain(String args, Instrumentation instrumentation). Nejedná se tedy o interface, ale o předpis pro signaturu statické metody, podobnou situaci důvěrně známe z public static void main(String[]). K jejímu spuštění dochází po startu JVM ještě před vlastním nahráním aplikace (nutno upravit manifest a spustit JVM s příslušným přepínačem). Parametr typu Instrumentation je vstupní branou k instrumentation API java.lang.instrument, které umožňuje pomocí metody ClassFileTransformer.transform modifikovat bajty třídy po jejich načtení ze souboru, ale před nahráním třídy do JVM.

A právě implementace metody transform je velmi jednoduchá, pokud použijeme Javassist. Ten od metody převezme pole bajtů a pomocí relativně vysokoúrovňového rozhraní se dostane až na modifikovanou metodu, do níž se vloží přidaný kód jako Java řetězec (ukázka).


Útržky:

• transformují se classy, ne zdrojový kód
• use casy: profilování kódu, optimalizace
• ukázka "logování": když nemůžeme změnit třídu a chceme na konec metody přidat System.out.println(parametr)
• odkazování se na parametry přes index ($0, $1...)
• složitější změny pomocí method.instrument(new ExprEditor() {...})
• ukázka generování proxies, napojení na metodu finalize() ukáže, kdy byl objekt uklizen
• princip "A tool shouldn't force user into specific programming model" (to je i vlastnost AOP)
• přidání příkazu na konec metody m se dělá pomocí m.insertAfter("{System.out.println(\"x\");}",true), kde druhý parametr říká, zda to přidat do finally (a tedy volat i při opuštění metody výjimkou) anebo zda přidat tak, aby se to volalo jen při řádném opuštění metody. Helemese – kolik pouček říká, neřiďte takově věci boolean parametry a i takový cool produkt to dělá a nikomu to nevadí? Mně tedy taky ne, poučky nejsou žádné dogma. Pro více info viz javadoc, je zajímavý i kvůli dalším metodám.
• další ukázky JRebel pluginů pro reloadnutí Spring a Hibernate konfigurací
• injection lze i do konstruktoru
• pomocí třídy VirtualMachine lze agenta nahrát i do běžící JVM (mindmapa pojmů), roli metody premain přebírá metoda agentmain.
• zajímavost: jeden bystrý posluchač v publiku položil přednášejícímu šťouravou otázku, sice ji už nedokážu zreprodukovat, ale přednášející se musel přiznat, že v podobě uvedené v prezentaci to Javassist nepodporuje a že si museli v ZeroTurnaround udělat vlastní hack Javassistu.
• přednáška zmínila i další nástroj ZeroTurnaroundu: XRebel, kde manipulaci s bytekódem využívají tentokrát k profilování aplikací.
  

Celkově se jedná o velmi zajímavý nástroj, který stojí za to si osahat. Zvažuji, že místo dlouhého povídání uspořádám spíš malý hands-on lab, protože toto je téma, které si člověk dobře zažije až při experimentování.

Neal Ford – Functional Thinking in Java 8, Clojure, Groovy, and Scala

Přednáška částečně podobná této z Osla 2011, stejný příklad s NumberClassifier, stejný font, stejné čtverečky (psal jsem o ní už v září). Pouze přešel z poněkud akademické knihovny FunctionalJava na JDK8 streamy. Je vidět, že Neal, jak jezdí po světě evangelizovat funkcionální paradigma, své přednášky úspěšně recykluje, ale vůbec mi to nevadí. Přednáška vynikala přehledností a důrazem na smysl paradigmatu i jednotlivých kroků. Paradigma je těžší věc než jen naučit se syntax.

Útržky:

• rozdíl mezi OO a funkcionálním přístupem: OO makes code understandable by encapsulating moving parts, FP by minimizing moving parts (Michael Feathers)
• ukázal imperativní řešení problému, pak řešení pomocí "less functional version" (vzájemně volané statické metody) a až nakonec plně funkcionální
• hezké grafické znázornění základních stavebních bloků funkcionálního programování (kolekce něčeho, co vypadalo jako brambory): filter, map, flatten, flat-map, reduce, fold-left/right ...
• puzzlík demonstrující, že v případě zprava asociativní reduce operace nemusí jít výsledek intuitivně odhadnout: operace odečtení sousedních prvků volaná jako fold-right na seznamu 1..10 vede na odčítání 8-9, 7-(-1), 6-8, 5-(-2)... s konečným výskedkem 5
• Bentley-Knuthův problém (1986) – umělá vzorová úloha na výběr a řazení slov ze zadaného textu. Z hlediska funkcionálního paradigmatu zajímavá tím, že je to typ úlohy řešitelný sledem kroků map a reduce. Více info např. zde nebo v článku Neala Forda.
• currying ... nevolá transformaci, pouze popisuje skládání jiných transformací
• aplikace curryingu: mám funkci volající db, která dostává mj. jméno a heslo. Po přihlášení uživatele je možné tuto funkci curryfikovat na jinou funkci pro zafixované jméno a heslo, argumenty druhé funkce už jsou pouza zajímavé vstupy pro volání konkrétního dotazu.
• laziness – konkrétní projevy: odkládání výpočtu výrazu (např. metoda pro rozdělení řetězce produkuje jednotlivé prvky, až když o ně klient požádá, ukazoval to na příkladu v Clojure, ale např. Guava Splitter to dělá taky), vytváření nekonečných kolekcí
• vliv FP na design patterny: např. Command zcela zaniká, je pohlcen paradigmatem; Flyweight zůstane, ale díky memoizaci může být implementován zcela odlišně než při objektovém paradigmatu. (více info)

Přednáška většinou neříkala nic, co by pro mne bylo zcela nové, ale byla výborná pro uvědomění si souvislostí. Poměrně podstatná věc zazněla v samém závěru: jestliže jazyk podporuje více paradigmat, přináší to větší nároky na disciplínu a code review. Ano, pokud bylo dosud možné napsat program v Javě imperativně i objektově, tak teď přibyde ještě třetí možnost – funkcionálně.

Oliver Gierke – Whoops! Where did my architecture go?

Co tvoří vaši aplikaci, pokud byste ji měli rozdělit podle toho, jak ji vidí programátor a naopak podle toho, jak ji vidí zákazník? To je téma, kolem nějž kroužilo povídání Olivera Gierkeho. Project lead Spring data přišel se slibným abstraktem a po dobré zkušenosti z loňského GeeCONu jsem si jeho přednášku vybral i letos a nelitoval. Začátek byl poměrně obecný o architektuře jako takové. Zajímavá byla ukázka grafu závislostí mezi jednotlivými moduly pro junit. Velmi zajímavý byl popis konceptu layers a slices a motivací pro ně. Na něj navazovaly konkrétní praktické ukázky, jak architekturu realizovat a udržovat v codebase. Sympatické bylo, že vše popisoval na plain Javě, neexistoval sebemenší náznak lock-inu na konkrétní technologii nebo framework.

Útržky:

• provokativní slajd "if you think architecture is expensive, try no architecture"
• Architecture is like weather, you can't have none.
• makroarchitektura = jak systémy spolu komunikují, mikroarchitektura = jak jsou vystavěny uvnitř
• znejte závislosti
• co je single unit of understand/change
• jaké riziko přináší změna - v případě znovupoužitého modulu: co změna rozbije, v případě copypastu: jaké jsou náklady plynoucí z rozdělení
• layers – repository, servisy,..., nezajímají zákazníka, dobře jim ale rozumějí programátoři
• slices – uživatelé, účty..., klíčové business koncepty, kterým dobře rozumí zákazník, pro programátory nové a těžko srozumitelné
• programátoři tíhnou k tomu si projekt rozdělit podle kritéria, kterému lépe rozumí
• závislosti jsou jak mezi layers, tak mezi slices, mezi slices je více podstatná
• když se dají závislosti vyjádřit jako acyklický graf, je to kvalitativně lepší než když existuje v závislostech cyklus
• u layers by závislost DAO na service byla nápadná, cyklické závislosti mezi slices jsou lépe přehlédnutelné ("I see tons of systems where Account calls Customer and Customer calls Account and nobody fucking cares.")
• core systému je taky slice, závislosti se sbíhají na něm
• nástroje pro analýzu codebase: JDepend, Sonar, Sonargraph (dříve SonarJ)
• jak architekturu namapovat na package? přístup layers first, slices first, slices only
• layers first – prosakují interní vlastnosti slice, které měly zůstat skryté před okolním světem
• slices first/only – spousta věcí může být jen package-private. Compiler tak zadarmo pomáhá zavádění architektonických pravidel.
• začněte s co nejméně packagi a co nejnižší možnou viditelností, rozhodnutí o zvýšení viditelnosti odložte na později
• OT: prezentovaný projekt měl pěkné formátování logů (zkrácení packagů na 1. písmeno a dostatečná šířka všech sloupců, že log vypadá jako tabulka)
• zajímavý Maven plugin: JQAssistant – umožňuje prozkoumat projekt a vyhodnotit parametry jeho kvality podle vlastního nastavení (prozkoumat)

Nebylo mnoho lidí, kteří se přihlásili k přístupu slices first/only, ale argumenty pro něj mi přijdou velmi přesvědčivé. Doufám, že si příště při návrhu struktury packagů co nejvíce účastníků vzpomene na tuto přednášku. Pozor na rozhodování od stolu, zaměřit se na měření správných veličin potřebných pro příslušné rozhodnutí. Prozkoumat nástroje (nebo v jednoduchých případech i napsat jen skripty) pro analýzu codebase, příp. databáze. Zmapovat závislosti, získat lepší představu, co smazat a jak se blokují práce. Dbát na omezování viditelnosti.

Martin Škurla – When assertThat(you).understandUnitTesting() fails

Původní plán jít na paralelní přednášku Václava Pecha Speaking your language jsem přehodnotil a vybral si téma, které je pro mne aktuálnější. Byla to přednáška nabitá od začátku do konce poučkami, tipy, patterny, antipatterny a nejrůznějšími radami. Přesněji: do půl hodiny po konci – přednášející značně přetáhl rozsah a měl svým způsobem štěstí, že měl poslední slot prvního dne a nikdo nás nevyhazoval. Řada rad mi přišla trochu kontroverzních, nicméně nelze popřít, že celé povídání mělo myšlenku, se kterou se nemusím v našich podmínkách ztotožnit, ale která mi přišla svým způsobem konzistentní. Textový soubor se zápisky mám asi 2x delší než je průměrná délka zápisků z ostatních přednášek, budu se snažit to sem na blog nenatahovat.

Obecné:

• rozdíl mezi čitelností a srozumitelností testu. Čitelný = dokážu to přečíst jako program a dává to smysl. Srozumitelný = čitelný plus rozumím doméně testovaného problému. Čitelný test nemusí být ještě srozumitelný.
• pro metodu s názvem nameOfTheMethod je antipatternem nazvat testovanou metodu testNameOfTheMethod, lépe je složit název ze 3 částí: testovanéChování_vstup_výstup.
• pro třídu s názvem NameOfClass je opět antipattern nazvat testovací třídu NameOfClassTest. Testovací kód vztahující se k jediné třídě nemusí nutně být v jediné testovací třídě, v jedné testovací třídě by měla být logická skupina testů testující jedno pravidlo nebo jev, které API testované třídy nabízí (např. test na hodnoty atributů, test na pořadí aplikování pravidel).
• různé test smells: podmínky v testu (např. na počet jader procesoru) navozují více exekučních cest – nahradit více testy nebo pomocí JUnit assumptions; cykly v testu představují schování více testcasů do jednoho – nahradit za parametrizované testy
• SUT = System Under Test = testovaný objekt. Asserty by se měly vztahovat pouze k SUT, ne k jinému objektu. (To bychom jako pak neměli používat mocky?)
• používání assertTrue, assertEquals se považuje za bad practice, odůvodňoval to nesprávnou úrovní abstrakce, takové asserty obvykle testují hodnoty proměnných a samotný smysl testu je pak musí napsat do dlouhého sofistikovaného řetězce v message u assertu
• Martin preferuje custom assertions – fluent API pokračující za assertThat(SUT) a umožňující si definovat i vlastní matchery. Custom Assertions zachovávají kontext, i chybová zpráva se sestaví automaticky. Kdybych četl název přednášky pozorněji, přišel bych na to dřív.
• nepoužívat logování a System.out.println, nikdo výstupy testů nečte
• pozor na sofistikované testy složitých situací jako GC, memory leaků nebo latence odezev (A co testování threadů?)
• nepřehánět to s vysušováním – u unit testů je opakování stejného kódu v určité míře zdravé a jeho odstranění může zakrýt některé okrajové případy, stejně tak literály by se měly extrahovat do konstant pouze u hodnot nedůležitých pro test a jinak by měly zůstat v testu. Teď mě nenapadá konkrétní případ, ale myslím, že jsem na to někdy narazil; každopádně zdlouhavě napsané testy se mi špatně čtou a spíš se snažím je omezovat.
• inicializace SUT v @BeforeMethod (TestNG ekvivalent junitového @Before) je prý taky antipattern, protože neodpovídá vzoru Arrange-Act-Assert – chybí část Arrange. (Tedy toto nepovažuji za nevýhodu a rád inicializaci nechám v @Before metodě, vždyť pro každou testovací metodu mi framework vytvoří novou instanci testu a na ní zavolá metodu @Before – proč bych měl jít proti filozofii testovacího frameworku?)
• ukázka deklarativního testování: testovací metoda oanotovaná anotacemi s řetězcovými parametry tak, že řetězce lícovaly svislítky pod sebou a vypadalo to jako tabulka. Připomínalo mi to Spock (o něm byla přednáška na GeeCONu loni). 
• paralelně vykonávané testy – smysl paralelního běhu není v lepším výkonu, ale lepší izolaci, testy nutí mít dobře vyřešen sdílený stav.

Co bych přednášce vytkl, je paušální prohlašování mnoha věcí za antipattern, zdrženlivost ve stylu "do toho se radši nepouštějte" a šermování mnoha principy, kde hledání kompromisu mezi nimi mi už přijde pouze jako akademický problém. Testy nejsou na hraní, považuji je za pouhý nástroj, jak lépe dosáhnout business hodnoty očekávané zákazníkem, nikoli za její přímou součást. Jsem proto rád, když programátoři nějak sami dojdou k vědomí jejich užitečnosti a začnou je psát, a porušení nějakých pouček zas tak moc neřeším. Máme testy i proti databázi, testy, kde stačí nespadnout na výjimku, i testy, kde se např. čeká na vlákno. Na druhou stranu: možná je lepší, aby přednáška propagovala ideál čistého kódu a já jej zde v článku zlehčoval, než aby mlžila a neměla jasné poselství. Takže celkově hodnotím přednášku pozitivně, Martin to má srovnané a ví, co chce.

Ostatní

Neal Ford – This is water

Úvodní keynote připodobňující naše prostředí k vodě, ve které plujeme, ale kterou nevidíme. Připodobnění tří věcí z fyziky k aspektům tvorby softwaru: μ (koeficient tření – interakce mezi různými subsystémy, continuous integration), δ (změny a diverzita), λ (veličina je funkcí jiné veličiny). Obecné povídání, zajímavé útržky:

• metawork is more interesting than work (proč existuje tolik frameworků)
• yesterday's best practice is tomorrow's antipattern
• build architecture that support, rather than punish
• počítání indexů od 0 nebo od 1? V céčkových jazycích počítáme od nuly, protože se tak lépe sčítají pointery. Protože se to zažilo, už jsme se naučili to považovat za přirozené, i když v normálním životě to přirozené není. (Také neříkáme: Kolik máte nohou? Nultá, první.)

Bruce Eckel – Do Languages Matter?

Nelze říct, že bych na některé z přednášek zaznamenal nějak konfliktní či kontroverzní prosazování některého jazyka či paradigmatu. Nicméně jen z toho, jak pestrá je nabídka současné doby, je zřejmé, že i programovací jazyky soupeří o pozornost technicky orientovaných lidí a snaží se uspět na trhu stejně jako kterýkoli jiný produkt. Pokud bylo úmyslem organizátorů tuto situaci vyvážit přednáškou někoho, kdo má charisma autority a dokáže hovořit s příslušným nadhledem, pak se jim to výběrem Bruce Eckela rozhodně podařilo. Závěrečná keynote byla provedením historií programovacích jazyků v kontextu hlavní otázky proč (nikoli jak nebo co). Zajímavé vyzdvihnutí toho, jak každý přechod provázel odpor těch, kdo považovali nový přístup za neschopný vyrovnat se výhodám předešlého (zřeknutí se assembleru při přechodu na C, systém knihoven při přechodu na C++, zavedení VM a GC při přechodu na Javu, v současnosti automatizace paralelismu a správy stavu).

Markus Eisele – 50 new features of Java EE 7

Přehledová přednáška systémem 1 featura za minutu, navštívil jsem ji za účelem aktualizace povědomí o světě JEE, když normálně používáme Spring + Hibernate. JEE je samozřejmě rozsáhlý stack, takže tam bylo od každé části kousek. Dojem: JEE se modernizuje, používají se anotace, i když ukázce s Batch se věnoval Markus celkem dlouho a tu měl v XML.

Michael Heinrichs – Do-It-Yourself Usability Design for Developers

Přednáška o UX, principy návrhu, the curse of knowledge, propagátor papírového prototypování.

Lightning talky

Heather VanCura o JCP, Krzysztof Debski a Fabian Förster o architekturách jejich aplikací.

Shrnuto

Na GeeCONu jsem byl celkově podruhé. Připojuji ještě pár postřehů z atmosféry konference:

• Twitter – oproti loňskému roku jsem ho začal víc používat, je to skvělý nástroj pro sdílení postřehů a čerpání informací. Výborná věc jsou zvací tweety ještě před přednáškou, které mnohdy doplňují abstrakt a pomáhají se rozhodnout v paralelním programu. Účet na Twitteru měl snad každý speaker a častokrát na něm po přednášce uváděli odkaz na prezentaci, také bylo velmi fajn jim přes tento kanál poděkovat. Sběr tweetů s hashtagem #geecon se hodí i k přejití na vedlejší zajímavější přednášku.
• Nesmím zapomenout na dobře zvládnutý catering a toleranci k nošení jídla na přednášky do sálů.
• Zásuvky pro notebook byly po stranách a občas byly všechny obsazeny, takže příště si beru rozdvojku.
• Doplňkový program: stánky, soutěže a GeeCoiny – pro zábavu a zpestření je to fajn, ale kvůli tomu na GeeCON nejedu. Když už tam jsem, odevzdám dotazníky s rébusy do srandasoutěží a vezmu dětem domů hračky, aby měly radost. Ale když se losovačka soutěže kryje s pásmem dotazů po zajímavé přednášce, tak žádný problém, losovačka má smůlu. Je to jen hra a člověk se nesmí brát moc vážně :-). Nahlíženo z tohoto úhlu, přesně tak jsem to měl i s geecoiny, necítil jsem motivaci účastnit se "miningu" a počítat si po každé přednášce svoje penízky. Velmi kreativní nápad, ale pokládám dotaz, abych se něco dozvěděl a ne abych dostal bílý geecoin. A moc speakerů o jejich rozdávání taky explicitně nemluvilo.

GeeCON 2014 Praha byl velmi podařená akce, za kterou vyslovuji organizátorům velký dík a uznání. Pozitivně hodnotím, že přednášky byly o řemeslném programování s hojným množstvím konkrétních ukázek kódu a reálným sdělením, případně o zkušenostech z konkrétních projektů. Takové jsou pro mne víc obohacující nežli přednášky, kde slajdy obsahují pouze metaforu, zábavný obrázek, provokativní otázku nebo jiný oslí můstek k nosnému tématu, o němž speaker mluví pouze z hlavy a nemám to před sebou. Z tématického hlediska byla zastoupena většina horkých témat okolo moderních trendů programování. Odcházet z konference s hlavou plnou nápadů, jak bychom to či ono mohli dělat lépe, to je přece její smysl?! A ten se podařilo naplnit.