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.

Lidi mají radši mail

V pátek večer jsem strávil zbytečnou hodinu hledáním, proč náš Jenkins server nechce vytvořit build, který jsem potřeboval nasadit na produkci. Příčina i řešení se nakonec ukázaly jako triviální: kolega před půl rokem přesunul Jenkins na lepší stroj (na kterém stačilo Jenkins službu pouze zrestartovat), ale na interní wiki byl stále uveden starý. Protože URL zůstalo stejné a ke všemu, co od Jenkinsu potřebuji, mi stačí webové rozhraní, neměl jsem až do včerejška potřebu připojovat se k počítači vzdáleně. Pro zjištění stroje jsem automaticky šel na wiki, na informační mail od kolegy jsem si pod tlakem nevzpomněl.

Taky používáte groupware systémy a přesto dostáváte nebo píšete spoustu mailů? Půjčím si formát výborného článku Lidi nečtou napsaného před půldruhým rokem Lukášem Křečanem. Můžete vypiplat písemný projev, ale pokud nepřitáhne a je dlouhý, vaše snaha přijde vniveč. Analogicky: můžete zavést groupware, ale když nepřekonáte bariéry, které brání lidem ho začít používat, neujme se. Proč? Protože lidi mají radši mail.

Příklady ze života: lidi raději pošlou informaci (když už vůbec chtějí informovat) mailem namísto aktualizace patřičné stránky na wiki. Nebo sice aktualizují wiki stránku, ale stejně o tom pošlou mail. To sám dělám, jelikož vím, že ne všichni odebírají novinky z wiki přes RSS. Nebo posílají mailem copypaste úryvku stránky z wiki namísto URL s #id příslušného oddílu a tento úryvek si začne žít vlastním životem. V issue trackeru je s velkou slávou založen nový projekt/task/bug, ale další informace, přílohy, upřesnění požadavků apod. se šíří mailem (dokonce jsem zažil i posílání souboru přes Skype). Nebo existuje mnoho dalších nástrojů – portál, sdílený disk, Google Drive... – a překážka je paradoxně v jejich velkém počtu a mnoha drobných omezeních: více různých přihlášení, restriktivní ACL, rozmlžené hranice jejich kompetencí. Co je pak jednodušší? Poslat mail.

Zdá se, že tu proti sobě stojí dva přístupy. Na jedné straně groupware – vymakaný software. Z logického hlediska uzná jeho výhody asi každý: centrální úložiště informace, různé způsoby prezentace, přístup "vše má své URL" (mj. tento přístup vedl i k popularizaci RESTu). Když ale dojde na to ho používat, objeví se psychologické bariéry – počínaje nutností spustit prohlížeč a konče samotným osvojením konkrétních dovedností (např. wiki markup) a UX daného nástroje. V jejich důsledku získá nástroj stigma těžkotonážního tanku, často bez ohledu na jeho objektivní složitost.

Na druhé straně je mail a obecně peer-to-peer systémy (např. Skype, ICQ a jiné IM aplikace) – jednoduché, každý jim rozumí. Abych udělal radost Dagimu, přirovnáno k armádě: když groupware systémy jsou tank, mail je Kalašnikov. Co na tom, že se maily hromadí a mám bordel ve složkách a tagách? Máme vyhledávače. Co na tom, že jednou odeslaný mail nelze opravit? Pošlu mail znovu resp. zeptám se mailem, jak je to správně. Co na tom, že nemám historii dokumentu? Mám ji trochu zachycenou ve stromu konverzace a to většinou stačí.

Pro pozorování těchto rozdílů ale není třeba chodit do práce, stačí se rozhlédnout po soukromé emailové schránce. Máte tam skupinu nazvanou Rodina, Třída nebo Kamarádi? Jiný příklad: v našem týmu ultimate frisbee projednáváme týmové záležitosti (pokud spolu nejsme osobně) přes webovou aplikaci tymy.cz. Podotýkám, že aplikace umožňuje zřízení diskuse omezené účelem a přizvanými osobami. Přesto se občas stane, že se někdo utrhne a nějaký problém řeší rozesláním hromadného mailu. Ostatní pak ochotně odpoví přes Odpovědět všem. Výsledkem je dlouhá nečitelná konverzace s předměty ve tvaru Re: Re: Fwd:... "Proč jste to neřešili přes týmy?" "Moc složitý." Lidi mají radši mail.

Jako vývojář tíhnu k omezování mailu a preferování groupware řešení. Při programování si taky neposíláme změny mailem, ale používáme verzovací systém, proč stejný přístup nepřenést i na jiné druhy práce? Loňský GeeCON byl zakončen přednáškou How to do Kick-Ass Software Development, která se tohoto tématu taky dotkla a maily poměrně striktně zavrhla (viz slajdy 88-93; mj. jistě není náhoda, že přednášející Sven Peters je z Atlassianu – tvůrce issue trackeru JIRA). Nicméně stále budeme narážet na to, že někoho to prostě nepřesvědčí. A síla davu rozesílačů mailů je velká. Dobře to ilustruje zajímavý článek, jenž svého času vyšel na idnesu, o společnosti, která se rozhodla tomuto nadužívání mailů vzepřít extrémním způsobem – jejich zrušením. Nevím, jak to s ní dopadlo, ale struktura článku je v souladu s mým pozorováním: vzletné myšlenky, s nimiž nelze nesouhlasit, a poslední věta jako studená sprcha, která vrací do reality.

Neodvažuji se tvrdit, proč je tomu tak. Napadá mne např. vysvětlení, že člověk je tvor sociální; podobně jako je pro něj přirozené vyhledávat setkání s jinými lidmi, je pro něj přirozená i komunikace peer-to-peer. Lidi taky chodí cestou nejmenšího odporu. Nejsem hlubinný psycholog a následující domněnka může vypadat šíleně, ale možná by se dalo hledat i v "temnějších" koutech – mail více uspokojí lidský egocentrismus (posílám ho tolika lidem a ó všichni mě čtou) a lidskou ješitnost (je to přece můj výtvor), alespoň na podvědomé úrovni, když ne na vědomé. Tak jako tak, u groupware tím středem pozornosti nejsem já. Ani kolega. Je jím to společné dílo. Software. Dokument. Entita. Neživá studená věc. U mailu je na druhém konci drátu živý člověk. Možná proto lidi mají radši mail.

Abych se nedopouštěl zbytečné polarizace a vyhrocování, dlužno dodat, že oba přístupy mají jistě i mnoho společného. Způsob vyjadřování popisovaný v článku Lidi nečtou platí nejen pro maily. U obou přístupů se nerad setkávám s nadmírou překlepů a chyb. Oba vyžadují nějakou systemizaci obsahu. A ani hranice mezi nimi není ostrá – např. s diskusemi a mailovými konferencemi si "povídám" posíláním mailů, ale ve výsledku je vše v archivu na webu, čímž čerpám výhody groupwarového přístupu. Podobně i např. možnosti publikace blogpostu posláním mailu.

Lidi mají radši mail. Přiznávám, že v tuto chvíli nedokážu kategoricky říct: smiřte se s tím. Ale trávit příliš mnoho energie bojem za to nebo ono řešení taky nedává smysl. Kde vidím cestu? Dělat, co považuji za dobré. Pomáhat dobrým řešením se prosadit. Být nad věcí – mít na zřeteli cíl, komunikační nástroje jsou pouze prostředky. Ocenit, že lidi vůbec komunikují, i když je to mailem (natož mailování nějak kriminalizovat). Zůstat ostražitý a spoléhat na selský rozum. Máte taky podobnou zkušenost?