Tomáš Záluský: GeeCON 2013

Zápisky z třetího dne konference GeeCON 2013

Bodil Stokke: What Every Hipster Should Know About Functional Programming

Konečně přednáška o funkcionálním programování, u které jsem rozuměl použitému jazyku. Typescript vůbec není špatná věc. (Podle toho, jak jsem se o něm bavil s jinými programátory, zaznamenávám nejen poměrně pozitivní ohlas na samotný jazyk, ale i jakýsi druh příjemného překvapení související s tím, že autorem je Microsoft.)
Před přednáškou jsem se ještě díval na biografii přednášející, a protože mi nebyla jasná poslední věta, potřeboval jsem si doplnit vzdělání. To se nakonec ukázalo jako osudně rozhodující krok k pochopení přednášky, protože veškeré příklady pak obsahovaly postavy z tohoto seriálu.
Po stručném přehledu základních paradigmat a pár teoretických slajdech přednášející ukázala na jednoduchých příkladech základní pojmy:

first class functions = functions are values, can be passed or returned as argument

priklad: hello() je funkce x hello je proměnná (v níž je přiřazená funkce)

functor is collection of X that can apply function f: X->Y over itself to create collection of Y

function map(func: (a:any)=>any, list: any[]) : any[] {
   for (i...) newlist.push(func(list[i]));
}

rozdíl ponies x map(CAPS,ponies) (ponies je seznam, CAPS je funkce pro převod na uppercase)
funktor = např. filter nebo redukce:
function reduce(func:(a,b)=>any, list:any[], initial) {...} reduce(add,[1,2,3,4,5],0);

funkce vyšších řádů jsou vlastně abstraktní továrny na funkce

mapReducer(func:(a:any) => any) {
    return function(a,b) {
        return a.concat(func(b));
    }

reduce(mapReducer(CAPS),ponies,[])

combinators

function square(x:number):number {return x*x;}
function addThree(func) {return function(x) {return func(x)+3}}
addThree(square)(5) ... 28

praktičtější aplikace: nullSafe - ošetří volání funkce na null a tváří se jako funkce

kompozice funkcí

function CAPS ... převede na uppercase
function hi ... vypíše hello arg
func compose(f1,f2) {return function(x:any) {return f2(f1(x));}}
compose(hi,CAPS)("everypony") ... totéž co CAPS(hi("everypony"))

applicative functors, příklad s kombinací dvou listů - kartézský součin, aplikuje mapu na 2 listy
currying (schonfinkeling) - transformuje funkci o mnoha argumentech na řetěz funkcí o 1 argumentu tak, že posloupnost volání dává identický výsledek (tady už to začínalo houstnout a nešlo opisovat, nicméně lepší než na fotky je podívat se přímo na prezentaci)
partial application
monads

Celkově oceňuji názornost příkladů a motivaci podívat se na Typescript. Příklady ke konci si ještě budu muset projet, protože pak už jsem nestíhal.

Ken Sipe: Making Java Unit Test Groovy with Spock

Přednáška o Groovy testovacím frameworku Spock. Opět jedna z kvalitnějších přednášek s mnoha praktickými ukázkami. Spock je framework založený na JUnit umožňující psát testy formou specifikace předpokladů a následných očekávání přímo do testovací metody. Pomáhá řešit také další související situace při psaní testů, např. zastínění jednoho předpokladu druhým (neotestování dalšího při selhání prvního) nebo testy s parametry. Využívá k tomu sílu jazyka Groovy umožňující definovat podmínky a očekávané chování pomocí srozumitelného DSL.

anotace umožňují vynechat test při splnění/nesplnění určitých podmínek
```
@IgnoreIf({!jvm.java8})
def java8feature() { ... expect: friends.stream().getFirst() != null;}
```
nebo naopak
```
@Requires({jvm.java8})
```
Zde se uplatňují výhody dynamického jazyka, ve statickém by se to díky .stream() pro Javu nižší než 8 nezkompilovalo.
názvy metod v groovy mohou být řetězce s mezerou. Oproti Javě, kde se u názvu metod musíme přizpůsobit syntaxi identifikátoru a řešit to různými náhražkami v podobě podtržítek a velbloudí konvence, tohle je další výhoda Groovy - čitelnější popis, dokumentace je součástí názvu metody.
zápis testu - given: ... when: ... then: ...

given odpovídá setUp resp. @Before
when je jako obsah testu před asserty - vlastní stimul
then odpovídá assertům - testuje odpověď

lze testovat i mocky
def subscriber1 = Mock(Subscriber)
Subscriber subscriber1 = Mock() - ekvivalentní zápis
flexibilní zápis testu pomocí přetížených operátorů, lambd nebo wildcard podtržítek:

1 * subscriber1.receive("event") ... na instanci subscriber1 byla jednou volána metoda receive s uvedeným parametrem
receive(!null) ... voláno receive s čímkoli různým od null
receive({String s -> s.contains("event"}) ... vlastní ověřovací lambda výraz
subscriber1./rec.*/(!null) ... volána metoda, jejíž název splňuje regex
subscriber.receive(_ as String) ... nebo jejíž parametr je cokoli určitého typu
2 * _.receive ... ale nerozlišuje, zda byla na jednom mocku zavolána metoda dvakrát nebo na dvou mockách po jednom
_ * _._(_) ... validní zápis - libovolný počet volání libovolné metody s libovolnými argumenty na libovolném objektu

expect: je when a then zároveň, je to šablona pro nějaký testovací příklad
where: je pro doplnění parametrů do šablony, při syntaxi parametr << [list] to doplňuje parametry ze seznamu. Pokud je více parametrů, berou se pro příslušný běh testu stejnolehlé hodnoty ze všech seznamů.
cool feature - pokud nastane chyba, vymaluje to jednoduchý ascii art vyznačující volání a pomocí svislítek popis argumentu metody a místa chyby (mám rád ascii malůvky)
parametry pro expect/where lze zapsat i ve formě tabulky á la wiki, v buňce tabulky může být i volání metody
@Shared - použít pro resource náročný na tvorbu, existuje na úrovni třídy a mohou přes něj spolu komunikovat jednotlivé testovací metody, podobné použití static fieldů u obyčejného JUnitu.
old() closure - přístup na původní hodnoty před spuštěním testu
then: map.example != old(map.example)
násobná klauzule then definuje, že očekáváme testované interakce v daném pořadí (naproti tomu více podmínek v jedné klauzuli then představuje podmínky testované jako celek)
možnost vlastních anotací na testech a další řízení testů podle anotací. Příklad:
definice vlastních anotací:
```
@Fast, @Slow
```
použití:
```
runner {
    exclude {
        annotation Slow
    }
}
```
Na našem Java projektu něco podobného máme a oproti Spocku je to celkem pracné.
extension annotation - umožňují nadefinovat si vlastní anotace, pověsit je na proces testování (specifikaci) a udělat kód onSuccess nebo onFailure (ukázka kódu, který na chybu reagoval promluvením "Failure is not an option"). Podobnou věc jsem si jednou udělal i v Javě (úspěch zahrál fanfáru, neúspěch zvuk havárie), ale bylo nutné se pořádně vlomit do tříd JUnitu.
další menší poznámky: anotace @Stepwise, Hamcrest expect: ... that ..., JUnit Rules už přednášející nestihl, protože značně přetáhl, ale mně osobně to vůbec nevadilo

Shrnutí: přednáška zvýšila nejen můj zájem o Spock, ale i o samotné Groovy. Není sice u nás reálné přejít s projektem na Groovy a statické jazyky kvůli typové kontrole stále preferuji. Nicméně v případě některých testů si dovedu představit úsporu práce, pokud by byly založeny na tandemu Groovy+Spock.
Za povšimnutí stojí i jednotlivé konstrukce a DSL (wiki tabulka, přetížení operátorů, klauzule). Tyto zápisy jsou sice elegantní, ale domnívám se, že je potřeba dobře znát, na jakém jazykovém principu jsou postaveny. Přistupovat k nim bez znalosti Groovy jako k magii, která funguje, se může vymstít, (resp. to člověka stejně přinutí pochopit, až s tím bude experimentovat).

Piotr Gabryanczyk: Typeclasses, Monads - Functional and simple!

Přednáška orientovaná na Scalu a NoSQL databázi Cassandra, aspekty funkcionálního programování tam byly zmíněny tak, že už to teď nedám dohromady. Poslouchal jsem jen napůl a stejně jsem v polovině odešel. Ostatní témata ve slotu mne nelákala, proto jsem využil čas alespoň pro vyzkoušení obou mindballů (ilustrační fota) na stáncích YSoftu, kde bylo jinak o přestávkách narváno. A musím uznat, že to fakt funguje :-).

Bert Ertman, Paul Bakker: Building Modular Cloud Applications in Java - Lessons Learned

Architektonická přednáška předvádějící cloudovou aplikaci postavenou na OSGi pro podporu učení pro děti. Cloudové aplikace jsou pro mě jako programátora nevyzkoušená věc, přednášku jsem si proto vybral záměrně. Architektura založená na HTML5 + javascriptu, RESTful ws, OSGi servisách, OSGi frameworku Amdatu a Eclipse pluginu BndTools, které napomáhají modularitě, a MongoDB. Střípky:

důraz na modularitu - schopnost vyměnit část za běhu
autoscaling - během školního vyučování se očekává větší zátěž -> potřebují kapacitu, ale neplatit za idle provoz serverů v noci -> Amazon autoscaling
bezestavová architektura - dobrá škálovatelnost (HTML5 umožňuje více bezestavové klienty, zmínka o Angular.js)
tip na knihu: Building modular applications (O'Reilly)

Discussion panel: Functional Programming - radical thinking shift and step towards clearer and reliable software

Formát diskusního panelu jsem na GeeCONu ještě nezažil a toto znělo podle názvu slibně. Diskuse se účastnilo 7 hostů + moderátor. Byla to zčásti teoretická, zčásti praktická diskuse, asi podle povahy jednotlivých hostů. První půl hodiny však nebyl prostor pro otázky publika, a i potom se ke každé otázce vyjadřovala většina hostů, takže na konci bylo hodně tazatelů, na které se nedostalo. Zajímavosti:

citát Martina Oderskeho (přibližně): je výzvou pro dnešní dobu, jak provést přechod z imperativního na paralelní distribuované programování při zohlednění omezených schopností lidské mysli, které jsou třeba k jeho zvládnutí
vylepšení paralelismu je řízeno modernizací hardwaru, hardware už je dnes lepší a může podporovat náročnější paradigma
funkcionální programování je jen prostředek k dosažení paralelismu
neexistuje čistě funkcionální jazyk (M. Odersky)
nejde říct o jazyku, že je funkcionální, ale že některé jeho rysy jsou funkcionální
změna paradigmatu je větší problém než změna jazyka
otázka, jak dlouho bude trvat adopce paradigmatu v business světě

Sven Peters: How To Do Kick-Ass Software Development (závěrečná keynote)

Odlehčená přednáška na závěr, nicméně i tak s hodnotnými informacemi. Pojem vypůjčen z filmu Kick-ass (český překlad Nářez), který jsem neviděl, ale z kontextu (tím, jak tento pojem přednášející používal v každé druhé větě) se tomu dá rozumět jako "pořádný", "úžasný", dobrý postřeh měli taky kluci, že by to šlo nahradit za "agilní". Přednášející ze společnosti Atlassian (JIRA).

diabolical developer: compiles? == ship it!
team which works with legacy code != legacy team == hard to refactor if member leaves, adding processes helps, old decisions still apply, changing stuff is too complicated
deliver kickass software

kickass feedback - musí být jednoduchý, ne: vidět chybu, mít odkaz úplně jinde, odkaz zavede do JIRA, projdu wizardem, registrací a pak musím vyplnit x polí formuláře
easy to find, fast to submit
protect your developers
google sh't umbrealla: 425mil. users, 100 developers
týmy dělají daily meeting 1/2 hod. jen nad feedbackem

have kickass teams

Developer On Test - dejte testování developerům
QA = Quality Assistance (ne Assurance)
6 tips for kickass DoTing

training - týdenní školení, jak psát testy, pro všechny developery
pairing
blitz test - všichni se podílí na testování důležité funkcionality, odhalí hodně chyb
test recipe
split sessions - opposite of pairing, dev a tester testují jiným způsobem
bug hunter - člen týmu, který se snaží to shodit

quality is everybody's responsibility
developers are doing design
"jednou jsem dělal GUI a dopadlo to takhle: (plný panel fieldů a checkboxů)", "pak jsem k tomu přidal barvy (strašně nabarvená složitá aplikace)"
design workshop for developers
designers are also developers - umi zaklady gitu, html atd.

kickass collaboration

lone cowboy x trouble starts with team
development rules protecting from making mistakes as traffic rules from accidents
fast,simple workflow for parallel coding
pull requests - what do you think?
atlassians prefer collocated teams - everybody in one office
vyhýbejte se emailům (alternativa: chatroom v ramci firmy, twitterový formát zmínky o jiném člověku: @someone)
v Atlassian chatují i lidi ve stejné místnosti - sluchátka na uších udržují v zóně soustředění

kickass automation

kolik času strávíte týdně automatizací vašeho softwarového vývoje?
buildy - dlouhé, složité, nestabilní, bez koncepce
4 rady, jak se vypořádat s monster buildy

vynechat součást buildu, která to zpomaluje
paralelizovat testy
mít strategii buildů, např. zbuildování projektu a unit testy pokaždé, integrační testy 1x/hod., výkonové 1x/noc
sledovat statistiky

rychlé buildy = snížené přepínání vývojářů mezi úkoly
viditelné výsledky testů: wallboards, televize s dashboardem
freud bot - statická analýza kódu v pull requestu
release button = single push deployment

další kickass věci mimo vývoj softwaru: rychlost vývoje, kvalita, škálovatelnost, tým, zákazník - vše kickass
hledejte cesty, jak to zlepšit - ohnout pro váš tým, ne jak poslouchat nějakého gurua
manažeři jsou lidi, někteří se nechají přesvědčit snadněji, někteří obtížněji (u každého ilustrativní foto, u "obtížněji" to bylo foto Larryho Ellisona :-)
share success and failures
kickass firemní kultura
můžu si na konci dne říct: did I kickass today?

Shrnutí

Automatizace, funkcionální programování, cloudové aplikace a testování patřily mezi nejčastější témata konference. Nejvíce mne obohatily přednášky s praktickými kusy kódu, obzvlášť pokud si přednášející troufnul na live demo.
Na závěr bych také rád poděkoval společnosti YSoft, díky které jsem měl na konferenci volnou vstupenku. Budeme o GeeCON také mít lightning talk na některém setkání CZJUG. Tyto články i lightning talk jsou výsledkem snahy předat získaný užitek zas dál.

Tomáš Záluský

23. 5. 2013

GeeCON 2013 - 3. den