GeeCON 2013 - 1. den

Zápisky z prvního dne konference GeeCON 2013.

Ve dnech 15.-17.5.2013 jsem poprvé navštívil konferenci GeeCON v polském Krakówě. Už mi začínalo být trochu těsno z běžného pracovního stereotypu a cítil jsem, že je potřeba zas konfrontovat hlavu s novými ideami, jazyky, projekty a trochu ji tím provětrat. Na konferenci jsem jel v autě s kluky z Forrestu, kteří už jsou na rozdíl ode mne ostřílenými návštěvníky GeeCONu - Novojem (otcem Furou) a Petrem Čížkem, a Pavlem Lahodou. Tady jsou poznámky z prvního dne:

Patrick Copeland: Pretotyping (Úvodní keynote)

Člověk z Googlu ve funkci Engineering Director. Nejdřív jsme mysleli, že je to překlep, ale je to dobře. Pretotyping je metodika nebo spíš přístup, který klade důraz na to, aby řešení řešilo skutečný problém a špatná cesta se opustila co nejdříve. Asi to lépe přiblíží heslovité poznámky:

• většina nových myšlenek zfailuje. Grafy ukazující statistický počet všech pokusů, pomalý fail, rychlý fail a úspěch.
• myšlenka nic neznamená, dokud se nepřetransformuje v něco hmatatelného. (Přednáškou se prolínaly vtípky na toto téma, např. nabídka/dražba "úžasné myšlenky od Patrika" v zapečetěné obálce, kterou se snažil prodat publiku postupně za 3000, 1500 a 60 PLN - za 60 se mu to nakonec podařilo a o kupci pak řekl "trouba". Nebo job Ideator: hledám engineera na tvorbu myšlenek, dříve jsem se zabýval převodem myšlenek do praxe, ale teď už se koncentruji pouze na jejich vytváření.)
• building right "it" over building it right
• zlatý střed mezi chybějícími testy a přehnanými testy (přehnaný test = např. použitelnost webu pro 500 různých odstínů modré)
• nehledejte myšlenky, hledejte inovátory
• pretotyping manifesto: innovators beat ideas, pretotypes beat productypes (ukazoval spoustu nezdařených produktů, např. Google wave), data (měření) beats opinion, simple beats complex
• fail fast - nutkání pokračovat v neúspěšném projektu za každou cenu je exponenciálně úměrné množství již investovaného času. Vzpomněl jsem si na radu Tomáše Bati (zdravím tímto Míru Burdu): nepokračujte v práci, která je špatně.
• fake it before you make it - příklad s prázdným odkazem pouze pro změření, kolik lidí na to klikne
• další graf: na ose x pozváni/vyzkoušeli/zůstali po 1/2/4 týdnech - strmě klesal u neúspěšných projektů, u úspěšných projektů pouze malý pokles, rozebíral to ještě podrobněji
• pretostorming x brainstroming: brainstorming přetváří myšlenky v názory, pretostorming myšlenky v data
• další zdroj http://www.pretotyping.org/

Po přednášce dotazy. Pár tazatelů využilo příslušnosti přednášejícího ke Googlu a neodpustilo si rýpnutí, zda považují Google Reader za neúspěšný projekt.

Dalibor Topic: 55 New Things In JDK8

Člověk z Oraclu, už jsem byl na jeho prezentacích před rokem a půl na Oracle Java Developer Day v Brně. Přednáška mě zajímala i kvůli slibovanému formátu 1 téma / min., i když tento formát jsem v tom nakonec nepostřehl. Bylo to spíš do šířky a kdybych o těchto věcech něco nevěděl už předtím, nejsem si jistý, zda bych se to z přednášky naučil. Začátek byla jen řeč o JDK Enhancement Proposals a ukazování webových stránek JDK (ano, těch, jak se na nich pořád odkládají ty termíny milestonů). Opět poznámky bodově:

• lambda, method references, extension methods
• generalized target type inference. Hurá, už konečně nebude třeba psát zobáky (a tudíž bude možno použít statický import) u Collections.<String>singleton() v případech, kdy se ta množina dává do generické metody. Aspoň tak jsem to pochopil, příklad přednášejícího byl obdobný (cons(42,List.nil()))
• anotace u typů
• přístup k názvům parametrů v runtime (to dnes jde jen za použití workaroundu s javac -g)
• opakující se anotace
• odebrání APT
• programový přístup na javadoc (DocTree API, DocLint, javax.tools javadoc support)
• bulk data operations - map, reduce, serial, parallels (připadalo mi, že skáče z tématu na téma, proč to neřekl u lambd?)
• concurrency - ForkJoinPool, ConcurrentHashMap, parallel array sorting Arrays.parallelSort
• Date and Time APIs
• JDBC 4.2
• BASE64, místo dosavadního sun.misc trvalé API
• změny v I18N, Unicode 6.2
• security, SecureRandom je na linuxu zatím work in progress
• java.security.cert nové třídy RevocationChecker|Parameters, nové šifry, algoritmy, digest typy
• @CallerSensitive - podpora metod, jejichž chování je závislé na volající metodě. Pro zjištění volající metody se dnes může použít proprietární třída z Reflection API, ale pokud je volaná metoda volaná přes reflexi, je volající metodou nějaká pomocná z Reflection API a to nechceme. Anotace by měla sloužit k explicitnímu označení metod, v jejichž implementaci je závislost na volající metodě. Příklad by nezaškodil, každopádně to je zajímavé téma, o jehož existenci v Javě jsem dosud netušil. Připomíná mi to dobu, kdy jsme se zamlada učili, že Smalltalk na volající kontext přistupuje přes klíčové slovo thisContext (a kdy jsem se po přechodu na Javu 1.3 divil, že ona to nemá).
• URL permissions
• přímé spouštění JavaFX aplikací
• java commandline launcher
• Compact Profiles - možnost ovlivnit velkost Javy v paměti volbou profilu: static footprint: full/compact3/compact2/compact1 - od 140MB do 10MB
• některé změny, kterými už se připravuje Jigsaw: ClassLoader fixes, ServiceLoader, analyze tool, deprecating java.util.logging.LogManager.addPropertyChangeListener
• Nashorn - nový javascriptový engine, commandline utilita jjs pro spuštění javascriptu
• odstranění zřídka používaných přepínačů GC
• odstranění permgenu, všechny statické proměnné, metadata tříd a internované stringy budou na heapu (nebo nativně v paměti)
• Fence Intrinsic - nějaký trik s JNI pro nepřerovnávání pořadí instrukcí, nové metody v Unsafe
• JDK autoconf based build system - ./configure style build setup 

Szczepan Faber: Automation dogfooding

Autor Gradlu a Mockita. Na začátku dotaz, kdo používá Gradle a úvod do Gradlu. Live demo vypadalo přesvědčivě.

• Přiblížení Gradlu začalo hláškou: "its like Maven but if it was like Maven I would kill myself"
• Gradle má taky pluginy. Pro Java projekty je Java plugin. Pluginy se zapojí pomocí apply
• ekvivalent pom.xml - build.gradle
• UP-TO-DATE mechanismus - hlídá jednotlivé fáze buildu, aby se nespouštěly zbytečně ty, které není potřeba pouštět
• Přednáška pokračovala povídáním o Gradleware. Výraz dogfooding (nebo eating your dog's food) v názvu přednášky znamená, že společnost sama používá produkty, které nabízí svým klientům
• důraz na automatizaci - maximálně automatizovat vše, co jde
• jak dlouho trvá novému programátorovi, než se zapojí do projektu, a kolik z toho je kvůli neaktuální wiki? Důsledek: minimalizovat i wikistránky, raději nahradit automatizovaným procesem. Příklad: gradle idea vyrobí metadata pro Ideu, podobně i pro Eclipse. Toto mě oslovilo, protože na wiki máme spoustu zastaralých informací a páky pro údržbu textu nikdy nejsou tak silné jako pro údržbu živého kódu.
• task wrapper - nemusím mít instalován Gradle, použitím tasku se nahraje jen malý jar, který stáhne zbytek Gradlu
• AbstractIntegrationSpec - podpora pro integrační testy, používá spock (o tom byla pozdější výborná přednáška)
• módy - embedded, forking, daemon (zůstává v paměti po skončení buildu), parallel (u Gradleware se používá tento mód, využívá více jader)
• je možné pustit testy proti různým verzím gradlu (crossversion)
• testují se i příklady v users guide, v javadocu jsou příklady podobně jako u Mockita. Další věc, ve které mě Gradle zaujal, protože na Mockitu mi přijde praktické mít dokumentaci frameworku jako součást javadocu jeho ústřední třídy.
• automatický deployment dokumentace - u nás další prostor pro inovaci, možnosti gradlu - wiki formát a samozřejmě rozkopírování na potřebná místa
• Gradle nabízí i nástroje pro kvalitu kódu (dokumentace public API, přidání licence headers, spouštění nástrojů pro statickou analýzu) a napojení na webové rozhraní a údaje o buildu v Teamcity

Rozhodně jsem si představu o Gradlu vylepšil, nevypadá tak nevyzrále jako dřív. Po zkušenostech s Mavenem, kde stejně máme pár procedurálních prvků (volání antrun pluginu), se zdá snaha Gradlu o skloubení toho nejlepšího z deklarativního a imperativního přístupu jako přirozená a dobrá.

Daniel Spiewak: Life in a Post-Functional world

Spíše teoretická přednáška, která začala slajdem s definicí funkcionálního programování a po představení základních pojmů pak nastoupily příklady ve Scale, Haskellu a Clojure. Což mně osobně funkcionální programování moc nepřiblížilo, protože v těchto jazycích jsem zatím nic v praxi nepsal.

• funkce je striktně matematická funkce (pro stejný vstup vždy dostaneme stejný výstup, neexistují vedlejší efekty)
• u funkcionálního programování je funkce primární jednotka abstrakce (u OOP objekt)
• jmenné prostory modulů řeší kolizi jmen, ale kolize jmen není hlavní problém, tím je vyjádření vazby mezi moduly
• pojmy pak demonstroval na příkladu rozhraní fronty (což mě vrátilo do školních let - na takových příkladech si člověk uvědomí, jak už si zvykl na vysokoúrovňové API současných jazyků a knihoven a že takové věci nemusí řešit)
• ve Scale ukazoval příklad, který mi připomínal situaci známou z použití návrhového vzoru Visitor - když mám hierarchii tříd a sadu metod, vyplatí se visitor jen pokud se hierarchie tříd moc nemění a  metody se mění hodně. Pokud je to naopak, pak je lepší mít metody u tříd a nedávat je do visitorů. Akorát v příkladu tomu říkal cases a problems a modeloval to nějakými konstrukcemi ve Scale (pattern matching, ale zbytek jsem moc nepochytil, neznám Scalu dobře).
• ne vše objektové/procedurální je špatné
• některé myšlenky mají důsledky v modularizaci a organizaci projektu a mohly by být zajímavé z pohledu JDK9 a Jigsawu.

Přednáška byla zajímavá, ale teorie tam bylo dost a málo návodu na aplikování v praxi. Utkvěla mi v paměti výrazná rétorika "this difference is very very very important" u situací, kde mi ten rozdíl jako moc výrazný nebo pro praxi důležitý nepřišel.

Andrzej Grzesik, Marcin Sawicki: Continuous delivery antipatterns

Přednáška dvou lidí, kteří se střídali po odstavcích a na představovacím slajdu měli každý uvedeno "I hate computers.". Pro situaci projektů u nás měla omezenou použitelnost, jednak protože zahrnovala celkový proces dodání (nešlo od toho čekat antipatterny jen v oblasti continuous integration), jednak že některé rady se týkaly virtualizovaného prostředí (Puppet x Chef). Jako v mnoha ostatních přednáškách i zde byl důraz na automatizaci (sarkastický vtípek: manual deployment = job security). Další střípky:

• release more often
• know what is where
• paralelizovat proces dodání produktu vytipováním míst, která na sobě nezávisí
• samotný pohled na release jako něco, co se musí zkompilovat a udělat (ve smyslu, že je to nedotknutelný artefakt někoho, kdo právě kompiluje a nikdo jiný mi na to nesahejte), je antipattern - release by měl být schopný udělat kdokoli
• deployování přes scp = antipattern, zřejmě myšleny ruční pokoutní zásahy
• protein-based automation process = proces založený na lidském faktoru

Celkový dojem jsem měl povrchní - viděl jsem, že to, co děláme, neděláme úplně špatně a tam, kde máme rezervy, to víme většinou i bez této přednášky.

Sandro Mancuso: Testing and refactoring legacy code

Taky občas prožíváte ten deadlock, kdy byste rádi refaktorovali kód a přísně vzato nesmíte kvůli absenci testů, ale testy se těžko píšou, protože kód vyžaduje refactoring? Já jsem si kvůli tomu tuto přednášku vybral a nezklamal jsem se. Úžasná přednáška, nejlepší z celého dne a nejspíš i celého GeeCONu, poctivě programátorská bez rozjásaných slajdů a buzzwordů.
Většinu času byl na plátně Eclipse s dvěma editory, vlevo test, vpravo kód. Přednášející začal příkladem fiktivní sociální sítě cestovatelů, kde existovala servisní metoda pro nalezení výletů všech přátel přihlášeného uživatele. To byla legacy metoda - špagetový kód plný ifů a forů (popravdě tak moc zašpagetěné to nebylo, ale to mělo podle mne jen pedagogické důvody, které přednášejícímu rád prominu - musel to přizpůsobit časovému rozsahu prezentace a nemohly tam být úplné špeky). Cíl: refaktoring kódu a a vytvoření testů zajišťujících jeho plné pokrytí. Vtipem jsou pravidla hry: smí se použít pouze nástroje automatizovaného refactoringu v IDE.
Na začátku byla tedy jedna servisní metoda, na konci bylo více menších metod a tříd plus testy k veškeré napsané logice. To, co bylo mezi, bylo napínavé pozorovat. Pokud má kód projít skutečně pouze automatizovanými transformacemi, musí si programátor rozmyslet, co má udělat jako první a kde začít s rozbitím příslovečného "deadlocku". Během procesu např.

• vznikaly nové pomocné metody a zase zanikaly
• některé části kódu původně vznikly v testu, ale přesunuly se do testované třídy (např. UserBuilder - builder pattern pro vytvoření instancí třídy User)
• dočasně existoval i anonymní potomek testované třídy kvůli překrytí jedné metody pro test
• uživatelé s určitými vlastnostmi (GUEST, ANONYMOUS) byli extrahováni do static final fieldů testu
• zabýval se přesným a vypovídajícím pojmenováním testovacích metod (should...)
• změna ifu s dvěma rovnocennými větvemi na if, který představuje spíš assert (oproti původnímu ifu podmínka testuje chybu a při splnění metoda ihned končí)
• na závěr pár kosmetických změn pro lepší čitelnost, atd.

Názornost zvýrazňovalo použití doplňkových nástrojů: Eclipse plugin zajišťující spuštění testu při uložení (tuším, že říkal infinitest, ale je jich jinak dost), plugin pro zobrazení pokrytí kódu zeleno-červeným podbarvením (podle screenshotu se zdá, že to byla eCobertura) a samozřejmě git, do kterého každou změnu hned commitnul a na konci prezentace ukázal téměř dvoustránkový log git messagí (mezi nimiž bylo vždy tak 3-5 minut).
Střípky:

• legacy kód může být i kód se singletony a statickými metodami, ne pro samotný fakt, že jsou statické, ale proto, že pro ně kvůli této vlastnosti nemůže být vytvořen tak spolehlivý test. Snažit se ze statických metod udělat instanční (na začátku ukázky byla statická i metoda DAO, což bylo do očí bijící a zjevně jen kvůli prezentaci).
• metodika pro rozkrytí motanice:
• refactoring začněte od nejvíce zanořené větve a postupujte směrem k nejkratší (hlavní) větvi
• testování začněte od nejkratší větve a postupujte směrem k nejhlubší větvi
• takže když bylo tělo metody tvořeno bezmála jedním velkým ifem, zda přihlášený uživatel je null, nejprve se napsal test na null
• při refactoringu bylo důležité u zašpagetěného kódu identifikovat, že metoda má více chování (porušení S v SOLID). Tomu odpovídá i skladba a minimalizace budoucích testů: např. to, že uživatel, který je přítel Paula, není přítel Boba - to jediné má být předmětem testu, nikoli už např. test přihlášení nebo počtu jeho výletů.
• menší ruční refactoringy, které neporušují pravidlo hry, ale byly tam také: proměnné by se měly deklarovat v blízkosti jejich použití (např. proměnná byla použita jen v jedné větvi ifu a tím bylo možné if rozdělit na validaci a vlastní logiku), if nahrazen za ?:
• nepojmenovávat field servisy v testu jako testee, ale podle třídy, tj. FooService fooService.
• používal mocky - Mockito a anotaci @InjectMocks
• dával privátní členy až na konec těla třídy a docela mi to začíná připadat dobré (prokládání mezi public metody stírá na pohled rozdíl mezi public a private členy, naopak u takovýchto refactoringů na viditelnosti záleží)
• další rady:
• snažte se o jednoduchost
• znejte dobře používaný framework
• preferujte malé a bezpečné inkrementální změny
• boy scout rule (zanechte po sobě kód v lepším stavu)
• no broken windows (vzepřít se postoji "tohle můžu naprasit, už je to stejně celkově zprasený")

Přednáška mi hodně dala i proto, že jsem si řadu zkušeností sám zažil a snažím se takto při tvorbě a údržbě postupovat. Samozřejmě v praxi bývají komplikovanější úkoly a programátor by si měl osvojit i cit vědět, kdy tam může risknout střelit změnu, která není bezpečná a jejíž rozdělení na malé kousky by bylo buď zdlouhavé a pracné nebo z principu nemožné. Doporučil bych ji všem, kdo se řídí přístupem "nešahej do toho, ať tam něco nerozbiješ" nebo "všechno to zahodíme a napíšeme znovu", jako konstruktivní protiklad.
Zdrojáky zde.

Google IO Extended

Krakovská Google Developer Group streamovala live přenos z konference Google IO v San Franciscu a účastníci GeeCONu měli možnost se na přenos podívat přímo v Googlu v Krakově. První den jsem toho využil a chvíli se koukal na představování hračiček:

• autodráha na několika mobilech s Androidem (demonstrace komunikace)
• rozpoznání obrázků na G+ (např. Eiffelovka), i když obrázek nemá hashtag
• automatická detekce lepších (highlight) fotek (podle úsměvu)
• úpravy fotek á la Photoshop filtry
• když je několik fotek, kde na každé se směje někdo jiný, Google z toho udělá fotku, kde se smějou všichni 
• hlasové ovládání vyhledávače: "Ok, google..." a otázky jako např. "kam v Santa Cruz na procházku" nebo "kde je manžel"

Nedokoukal jsem to celé, protože jsem už toho měl za den dost, ale některé věci mi přišly jako technologická exhibice, i když je pravděpodobné, že za pár let je budeme používat zcela normálně.
Cestou z Googlu jsem ještě chtěl vidět na vlastní oči Wavel.

Druhý den.