Zápisky z třetího dne konference GeeCON 2013
První den zde. Druhý den zde.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
poniesxmap(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
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
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.
