Thursday, April 17, 2014

Plzeňský Barcamp 2014

S komunitou se to lépe táhne a po parádním data hackatonu se v kalendáři v sobotu 12.4. objevila další akce. Protože jsme s double-ex-kolegou Petrem Juzou oba studovali v Plzni na FAV, vyrazil jsem do města piva - jednotné číslo, protože Petr už tam bydlí :-)

V sobotu se v Plzni konal plzeňský Barcamp ve Vědeckotechnickém parku.

Co to je?

Program vybraných přednášek už na první pohled ukazoval, že se nejedná o vývojářskou ani technickou akci. Čas byl vyplněn spíše soft-skills nebo networkingem. S tím jsem tam jel. Nakonec jsme ale zašli i na dvě technické sessions.

Zpětně jsme udělali stejnou chybu jako na data hackatonu a to, že jsme se nepřipravili. Kolik akcí bude ještě trvat, než se poučíme z krizového vývoje? :-) Přednášky jsme vybírali až na místě, ať už z telefonu nebo z mnoha velmi pečlivě vylepených programů. Takhle z místa generála po bitvě šlo určitě vybrat lépe průřez barcampem a ochutnat od každého něco - víc.

Dopoledne

Po uvítací půlhodince, jež zaplnila twitter fotkama zumby, jsme si vybrali něco z našeho soudku - přednášku Honzy Švece o machine learningu. Honza ze ZČU poodkryl inteligentní hlasovou asistentku, nastřelil něco málo technických atributů "učení se" a velmi pěkně pro lajky ukázal, jak na práci s hlasem. Presentace sama byla paradní. Slidy projížděly nad jakousi mind-mapou na obrovském plátně. To chci taky!

Jan Švec - Machine learning

Jelikož jsem měl šanci pobýt před pár týdny v Malajsii, o čemž sepíšu něco málo později, rozhodně nás zajímali digitální nomádi. Vítek Ježek žije dost netradičním životem a ten shrnul do přednášky. Nejdřív pár slov a fotek ze zřejmě dost povedených recesistických akcí via Děsír, potom povídání o fungování demokratických clevis s.r.o. spolu s digitálním nomádstvím. O co šlo? Odjet někam za teplem na pár týdnů a odtud pracovat. Původně jsem čekal spíš něco ve stylu jak jsem pracoval pro softwarovou firmu v emirátech ale i tohle bylo velmi zajímavé.

Vítek Ježek - Digitální nomádi

Po přesunu do hlavní místnosti začala přednáška energické Marie Gráfové o deseti vychytávkách efektivného života. Opět mě dost zaujaly slidy. Povídání o tom jak se samo-organizovat, zefektivnit a zacílit. V delší verzi najdete všechno s omáčkou v Konci prokrastinace. Ze zmiňovaných apps jsem si dneska zkusil znovu toggl - ale zase jsem to zapomněl vypnout :-), zajímavý bude určitě i Boomerang do Gmailu. Nápad již zažitý v iOS' Mailboxu. Diskuze k tématu byla dlouhá. Někoho ze životní letargie zvedl pes, někoho bezlepková strava, jiného zase sport. Nicméně já to dělám docela jinak, tak o tom něco málo napíšu.

Odpoledne

Na obědě se ukázalo, že dorazilo pár ostravaků - chybějící diakritika tam opravdu má chybět :-) Chatting nad tématy vedení projektů nám přelezl do první várky odpoledních přednášek, takže jsme stihli až Davida Šmehlíka s prací z kavárny. Rozebíral, jak pracovat remotně.

Předposlední přednáška se konala v trošku odlehlé posluchárně a tak bylo celkem prázdno. Slibná upoutávka o crowdfundingu se trošku vymkla kontrole. Kluci z tvujprojekt.cz málo mluvili obecně o tématu a hodně rozebírali svůj skoro nerozjetý web. Škoda, protože znalostí měli zřejmě hodně, ale UX verifikace webu na barcamp IMO moc nepatřila.

Závěrečná session byla ale perfektní, ta to vynahradila. Štěpán Bechyňský mluvil a ukazoval 3D tiskárny. Svoji vlastní si vzal s sebou na barcamp, takže během povídání tlačil dvě kočičky z plastového vlákna. Tohle jsem viděl poprvé naživo, takže informace maximálně relevantní :-) Po téhle presentaci bude určitě nejeden z účastníků hodně přemýšlet, jak si těch 25 tisíc obhájit před manželkou :-)

Nakonec přišla rozlučovací hodinka a párty dole v hale.

Štěpán Bechyňský - 3D tiskárny

Jaké to bylo?

Příjemný den na příjemných přednáškách. Technické session na střídačku se skillama by byly lepší. Ale i tak jsem rozhodně nelitoval.

Schopnost přednášet

Co mě tedy nejvíc upoutalo nebyl David Grundl, jak asi všechny ostatní :-), ale přednášecí skill lídí, co sebrali odvahu vystoupit před publikem. Gratulace! To bylo sakra dobré. Hezké a příjemné presentace - příjemná změna po těch našich korporátních - klidné vystupování, vtipné reakce na dotazy a žádná nervozita. Dobře se na to koukalo. Dost mě tohle motivovalo příště si to zkusit taky, abych trošku zkazil průměr. Nejden posluchač měl totiž určitě dojem, že takovéhle pěkné presentování jde samo. Mě teda ne :-)

Organizace barcampu

Jestli mě něco uchvátilo tak tohle. Klobou dolů. Přestože bylo vše zdarma, tak jsme za celý den nepřekonali to množství jídla, které organizátoři připravili. Všechno pěkně klapalo, nikde nic nevypadávalo, všechno bylo perfektně zařízené. Ještě jednou klobouk dolů. Speciálně před Jirkou Kolaříkem, Denisou a Verčou.

Vědecko-technický park

Tohle taky stálo za to. Jelikož moje první práce sídlila kousínek vedle, tak jsem prostředí znal. Za těch pár let tam ale vyrostl pěkný park budov, posluchárny pro dvě stovky lidí, výborné zázemí. A to na rozdíl od Prahy, všechno pěkně v zeleni a v lese. Věřím, že se tam hezky pracuje.

Suma sumárum to bylo velmi dobré! Plzeň je příjemná a barcamp byl taky!

Data Hackaton - motivační víkend

Poslední únorový víkend patříl díky Petru Ocáskovi v Node5 eventu jménem Data Hackaton. Akce to byla početná, celkem se přihlásilo přes 70 lidí. Každý s trošku jiným očekáváním. Jelikož jsme se něčeho podobného účastnili poprvé, vyrazili jsme spíše poznat komunitu lidí, networking, než si zahackovat a udělat nějaký reálný výsledek v podobě zanalyzovaných dat. Ve finále jsme se o to do poslední chvíle snažili, bohužel, řečeno sportovní hantýrkou, jsme zaplatili nováčkovskou daň a padli :-)

Ale od začátku.

Pátek

Ten patřil úvodu akce, pár přednáškám. Po nezbytném přivítání od Petra, následovalo pár mini-přednášek. Jelikož tématem hackatonu byla data, jednalo se převážně o představení problémů, které chceme na eventu řešit, popř. co vlastně nabízíme a nebo které problémy vám vyřešíme/pomůžeme řešit.

Zdroje dat byly ruzné. Akcie a tweety, hluk na D1čce, vývoj kriminality popř. data o firmách. Všecho znělo docela lákavě. Tady jsme udělali první chybu :-) Přestože networking, chtěli jsme vlastní téma. Náležitě jsme rozhodili sítě a sešlo se nám pár kandidátů, které bychom za víkend mohli zanalyzovat. Výběr pokračoval do soboty.

Během pátečního večera jsme potkali především kluky z keboole. Petr Šimeček nám dal úvodní intro jak do keboole, tak gooddata tak nakonec i do HP Vertica. Za posledně jmenovanou věc nám bylo trošku stydno, protože jako zaměstnanci HP jsme Verticu neměli nikdy v ruce. Nakonec se ukázalo, že po dlouhé instalaci by nás asi čekalo zklamaní. Slovy klasika: prostě někdo musel ukázat, že vyfukováním cigaretového kouře do vody zlato nevznikne.

Po přečtení Petrova blogpostu si vlastně vzpomínám ještě na pár zajímavých věcí prvního dne. Jednak o excelovském power query jsem neměl ani páru. Po prvotním failu Stěpán Bechynský ukázal sílu excelu a já se nestačil divit. "Big data" excel asi nedá, ale na něco menšího by to nemuselo být vůbec špatné.

Kluci z attacama.com ukázali trošku promo svojí firmě. Zaujalo mě jejich dost profesionální vystupování před kamerou (i ta tam byla), na jejich věk tleskám :-)

Jelo se v pátek i ve 22:30.

Sobota

Plni velmi pozitivních zkušeností z prvního dne jsme ráno natěšeně dorazili na devátou do node5. Petr nám představil Radovana, který nás ubezpečil, že obě vyprofilovaná témata jsou dobrý nápad. Bohužel zpětně se ukázalo, že to nebyla pravda, ale po bitvě ...

Pro jistotu jsme udělali rychlý research, jak de-mixing bitcoin servisy, která měla neutralizovat spletení proudu bitcoinů, tak i analýzy jsonu, který produkuje flightradar24.com. Na obědě jsme udělali druhou a asi nejvíc podstatnou chybu - nad pizzou jsme si plácli na to, že rozemeleme bitcoiny.

Po návratu z oběda jsme to commitnuli na standup meetingu. Během odpoledne začalo studium a naše nervozita exponencielně rostla. Zhruba v šest večer jsme měli mavenem staženou bitcoinj knihovnu připojenou do lokální peněženky, ze které to četlo bloky dat.

Během odpoledne nás Petr ještě provedl Node5. Nádhera. Velmi inspirativní prostředí, pěkný prorůstový koncept. Speciálně sekci startupistů, kde se několik měsíců žere rýže a kečup by mělo navštívit hodně lidí.

Tou dobou kluci odvedle, kterým Petr a jeho kolegové z keboole pomáhal dostat data do gooddaty - tady bych udělal menší vsuvku, protože mi přijde divné to tohle skloňovat, na hackaton zaznělo třeba i v gooddatě, já bych to prostě neskloňoval - skončili a šli hotovy domů.

My jsme měli pár řádků kódu, nic moc networking, protože s tím nám nědokázal nikdo pomoct a plnou hlavu toho, jak ten doménový model asi funguje. Kluci z keboola nás ještě obešli, zda něco máme a nechtěli bychom to dostat do gooddata platformy, popř. Verticy. V koutku duše jsme si ještě mysleli, že možná něco v neděli dáme.

Nicméně v osm jsme to vzdali. Kluci z click2streamu dřeli na gooddata via keboole ještě při našem odchodu.

Neděle

Celou noc jsem nemohl spát. Snažím se být co nejvíc produktivní a nedokázal jsem si představit, že nemáme vlastně vůbec nic - protože sen o tom, že se naučíme strukturu bitcoinů, knihovnu a datový model plus ještě na papír vymyslíme demixer a to vše během jednoho a půl dne byla naprosto bláhová :-)

V záchvěvu ranní inspirace jsme ještě něco zkusili. Nevyšlo to. Tak jsme si řekli, že je čas uznat porážku a hecnout se něco udělat neboť až ve 14:30 je deadline.

Štefan s toptopicem a bagetou ze včerejšího dne a já se starou houskou z Lídlu v ruce jsme započali straighforward plán, jak skončit se ctí. V jedenáct jsme se rozhodli, že dodáme analyzer flighradaru, ze kterého si vybereme nějakou stats a tu spočítáme v čase.

Java, maven, Redis = to byl náš plán. Redis má tak jednoduché a geniální API, že volit cokoliv jiného byl nesmysl. Jedna servisa parsovala kontinuálně json a plnila data do Redisu, ta druhá kontinuálně přepočítávala průměrnou letovou hladinu. Já programoval, Štefan dělal ops, protože Redis jede na linuxu a v Node5 VPN zase nejede k nám do firmy. Nakonec se tam dostal.

Začali jsme plnit data a pár minut před deadlinou jsme měli spočtenou první průměrnou letovou hladinu. Bohužel na graf se už nedostalo, stejně tak jako na nějakou více smysluplnou analýzu dat. Jedna či dvě hodiny navíc a něco presentovatelného by z toho vypadlo.

Tak jsme si poslechli ostatní. Výsledky byly opravdu povznášející, protože ostatní týmy do toho opravdu šláply a ukázaly, jak se chopit dvoudenní akce. V hlasování všech aktérů zvítězil bluetooth monitoring lidí via sinfin.cz, druhý agilní Adam Kurzok s analýzou firem via daty.cz v závěsu za futurelytics s analýzou kriminality.

Zajímé byly i výsledky analýzy akcií a tweetu, především Štěpán měl velmi pěknou presentaci i pro nezasvěcené.

Na závěr dorazil i Zdeněk Farana a tak jsme se mohli pobavit s někým, kdo dělá realně ve scale.

Poděkování

Petr Ocásek uspořádal parádní event, díky!
Gazdinka parádně navařila a nemohli jsme neochutnat, díky!
Kluci z keboole nám dali čichnout jak funguje jejich BI via goodata a tak všechno okolo, díky!
Všichni ostatní vytvořili velmi inspirativní atmosféru, díky!
Node5 sám za sebe, protože myšlenka i provedení je úctyhodné, díky!

Postřehy

přijít nepřipravení byl kámen úrazu - měli jsme přijít s tématem a využít nabízených platforem, gooddata či google big query, a něco do toho nalít a prostě si to vyzkoušet + někoho k tomu strhnout
ikdyž jsme něpřišli s tématem, měli jsme alespoň vsadit na networking a seznámit se s lidmi - dát s nimi něco dohromady
potkat se s namotivovanými lidmi je nová krev do žil
Node5 je dechberoucí místo, tiše doufáme, že tam někdy uspořádáme podobný event v budoucnu okolo Service Virtualizací
když má člověk nosnou myšlenku, lze za víkend udělat dost práce
sušený ibišek je neskutečně dobrý
po nakládaných hermelínech se těžko běhá :-)

Kniha: Konec prokrastinace

Hodně lidí věnuje ve svém životě podstatnou část svého času práci. Avšak výsledek našeho odborného snažení nemůsí odpovídat úsilí, kterému do něj vkládáme. Já to často připisuju neefektivnosti toho, co děláme.

"Přes stromy nevidí les."

Tohle známé přísloví mi občas charakterizuje stav do kterého tu a tam spadnu. Jak se člověk noří do problému hloubš a hloubš, tak zapadne, a místo jednoduchého řešení z high-level pohledu volí komplikované - často výrazně náročnější - postupy. Člověku pak chybí jakási efektivnost v tom co dělá.

Tohle se často vyřeší tím, že o problému začnu vyprávět kolegovi a sám si většinou přijdu na řešení popř. problém. Nicméně v tomhle čase je už pozdě.

Proč tohle píšu?

Snažím se popsat motivaci, kterou mám k tomu, že si tu a tam přečtu nějakou motivační nebo sebe-zefektivňující knížku. Moje asi nejvíc oblíbené jsou Get Things Done a Rework. Důležité však je to, občas si připomenout obsah a postupy, protože rád zapomínám a zklouzávám z toho, co se mi na začátku zdálo tak efektvivní. To je důvod, proč nečtu stále dokola jen výpisky z výše uvedených, ale raděj nové :-)

Před vánoci jsem však narazil na knihu, o které chci psát. Konec prokrastinace českého autora Petra Ludwiga.

Po prolistování obsahu jsem se do ní rád pustil, protože to vypadalo, že kniha shrnuje to nejlepší z mnoha knížek a nakonec jsem se vůbec nemýlil.

Co je prokrastinace?

Prokrastinace je výrazná a chronická tendence odkládat plnění (většinou administrativních či psychicky náročných) povinností a úkolů (zejména těch nepříjemných) na pozdější dobu. Může představovat rizikový fenomén pro duševní zdraví. Psychologové často popisují takové chování jako mechanismus pomáhající jedinci vyrovnat se s úzkostí spojenou s výkonem dané činnosti. Podle některých vědců jsou kritéria definující prokrastinaci následující: je kontraproduktivní, zbytečná a zdržující.

Tak tímhle rozhodně netrpím! Ale to vůbec nevadí, protože kniha obsahuje spoustu zajímavých informací a hlavně reálných postupů, které člověka mohou zefektivnit. Je rozdělena do čtyřech částí:

Motivace
Akceschopnost
Výstupy
Objektivita

Zajímavé jsou pro mě první dvě. Dagi psal nedávno o vnitřní motivaci, existuje také jedna pěkná kniha o motivaci zvenčí.

Motivace

Hned první kapitola pro mě byla stěžení. Celé povídání mi dalo dohromady ideu, proč lepší výplatou nadšenějšího programátora z člověka neuděláš. Zajímavá pro mě byla hlavně část, kde se probírá motivace cestou.

O co jde?

Je dobré si dávat úkoly. Je určitě dobré si dávat vyšší úkoly než byly ty předchozí. Jenomže dlouhodobě vzniká problém, že člověk plní úkoly a nemá z nich radost v pohledu na ty další a často těžší a těžší věci. Logicky z toho tedy vypadne, že to nadšení a uspokojení nepramení ze splnění a vyřešení problémů, ale spíš z toho, jak to člověk udělal, jak se mu tohle a to další podařilo, co se naučil, jak do toho zatáhl další lidi a vůbec jak to bylo skvělé a zábavné :-)

Ruku v ruce s motivací a s radostnou náplní toho, co člověk dělá, jde také určitá osobní vize člověka, co by v životě chtěl dělat. Tohle jsem už mnohokrát četl, ale vždycky jsem se na to vykašlal, že to udělám později. Neudělal, takže napraven z předchozích neúspěchů - prokratisnace? - jsem tentokrát strávit pár hodin přemýšlením. Samozřejmě vizi toho, co bych chtěl dělat, jsem měl v hlavě už dávno. Důležité pro mě bylo k tomu přihodit pár zajímavých postupů a výstupů, které jsou popsané v knize - uvidíte.

Co z toho vypadlo? Celkem pěkná náplň na rok či dva s trochou objasněné mlhy za let pět.

Opravdu hodnotná pro mě také byla část, kde autor popisuje pracovní uspokojení člověka. Vysvětluje tam, že krom práce na sebe člověk niterně velmi oceňuje práci pro druhé a skupinovou motivaci stejně nadšených lidí.

Akceschopnost

Úspěšné lidi od neúspěšných odděluje také to, jak a že vůbec se dokáží rozhodnout pro tu či onu věc. Určitě se Vám často stane, že si nemůžete vybrat z jídel v menu nebo třeba cestu, jak vyřešit nějaký technický problém. Efektivní lidé neprokrastinují v mysli a ihned nahodí postup, kterým vybrat to, co je pro mě dobré.

Chci dneska maso? Ano. Půjdu dneska sportovat? Ne. Mám velký hlad? Ano. Tak to si mohu dát XYZ.

Prokrastinace znamená i to, že ikdyž člověk jednu variantu jistě vybere, tak se vrací k dalším - na stejné úrovni - a znovu je zhodnocuje. To samozřejmě vede k tomu, že má člověk v hlavě stále mnoho možností a celková množina, ze které vybíra, se prostě nezmenšuje. Nakonec si nevybere, protože se prostě nerozhodne.

Samozřejmě výběr z jídelního menu je to nejsnažší, co nás v životě čeká :-)

Velmi mě v posledních měsících motivoval poslech podcastu s Lukášem Hudečkem z Node5, který v něm v jednom momentě říká, že má takové životní krédo:

Člověk by měl v životě dělat vždycky to, co se mu chce nejméně.

Autor Petr Ludwig jde ještě dál v části o osobních hrdinstvých. Tvrdí, že když člověk udělá něco odvážného má sklon dělat odvážné věci víc a víc. Myšleno v kontextu puštění se do hromady TODO věcí nebo vyzkoušení prototypu odvážného nápadu místo jeho odkládání.

Zárověn to ukazuje na příkladu, kdy si člověk ráno může dát studenou sprchu - což je třeba pro mě dosti hrdinský čin - čímž bude zbytek dne motivován dělat takové věci dál. A ono to funguje :-)

Závěr

Další dvě kapitoly jsou také zajímavé, ale pro mě už ne tak podstatně. Úplně bych zapomněl na praktickou část knihy, které ukazuje jak se v reálu pomocí např. buzer-lístku vyrovnat s odkládáním úkolů. Všechny tyhle formuláře jsou také dostupné na autorově webu.

Abych to shrnul. Kniha je říznutá seznamem psycho výzkumů, což přináší často úsměvná zjištění, jak se lidé chovají. Zároveň shrnuje hromady dalších knížek a jako by je propojovala v jeden smysluplný celek jak dělat věci smysluplně a zakousnout se do nich.

Za to se sluší autorovi zatleskat a knihu jednozančně doporučit.

Coursera: Functional Programming Principles in Scala by Martin Odersky

It's almost half year when I found a link on Twitter when someone pointed out to new course of functional programming in Scala. The course prepared Martin Odersky who also recorded all video materials. All enthusiastic programmers know that Odersky is author of Scala programming language. I've studied hard so after couple weeks I obtained a certificate. I have to note that it was my first meet with coursera itself and it left as best impressions as it could. But lets start from the beginning.

The course took 7 weeks. There was also first, zero, week which supposed to define targets, make people to understand topics etc. Everyone could also follow steps how to setup scala environment from the scratch along with Eclipse and SBT. SBT build system was new for me and I already put it into my notes as thing I need to study later. Contrary to course recommendations I used IntelliJ Idea all the time and I've not met any problem. It was just about the first setup of your environment but nothing new for me as I already made few REST services in scala using Spray. But back to the course itself.

Martin Odersky published couple of videos every week. The total length was about 1 hour (per a week) so nothing which would consume some significant part of your time. I've already have couple real experiences, some books too, with Scala so first weeks was crucial for me. As the name of course indicates, it's not only about scala itself but about functional programming. This was the point of first weeks. I finally found out basic terms, designs and flows how modern functional programming works. Well, everyone attended some course regarding functional programming at a college but this was really good.

The work of every week was covered by one or more exercises. Despite my original feeling I have to say that those exercise were brilliant and seems for me that it was the crucial part of overall understanding. My original feeling was much more worse that today - three months after the end of course. Why? It seemed for me as little bit academical. What's going on?

Odersky and his team prepared skeleton in scala, provide couple tests in the solution and lead you to provide the rest of missing programming code. The solution was compilable all the time but those tests where failing. You supposed to read the tutorial for an assignment and put missing code in there. The difficulty was changing in the time, especially assignment at the end of the whole course was little bit hard but everyone will understand working with collections or stream approach in scala to death :-)

The problem I pointed out few lines above is that I spent a lot of time with reading and undestanding of the problem itself, e.g. how works very popular game of infection, or how they design the skeleton, e.g. words decomposition in the assignment of anagrams.

Once you was satisfied with your solution you just use git with SBT's commit and send your solution to repository. I've already written that original solution already contained few tests. The lecturer developed more non-public test used to testing when someone committed his solution. This sometimes arouse passion because you have developed your solution, your tests works so you decided to commit it to coursera's repository. After couple minutes when their tests were done you found out that your solution is not working for large data. What to do now? You do not have that test, you even do not have attributes of large test. One can just look into his code and try to find problem without any real point where to start.

The last thing was the only issue on perfect course in all other respects. There was also a follow-up in the form of course about Reactive Programming. Thing went around Akka, async/await, Futures and promises and so on.

I really enjoyed the course. After few moths I have to say that it's much more efficient than any kind of reading - obviously because of assignments. It turns out into my almost primary target where to learn new things as there is multiple things to learn.

Redis messaging using Spring and Kryo serialization

Redis is famous enterprise key/value data store which provides simple messaging using publisher/subscriber. I've decided to use the system to notify remote nodes (components) about a change of state between those components.

Spring among the others allows to use it's templating system to decouple business logic from messaging system used under the hood. The use of spring data for Redis guarantees a solution which does not utilize any redis command in the code.

Redis contains serialized content, either byte[] or string. So the last thing to reveal is domain model serialization. I've decided to fast binary serialization using Kryo framework as a winner of battle of serializators.

Maven

First of all, it's necessary to define all dependant components. Obviously, usual component like spring itself missing.

<dependency>
 <groupId>com.esotericsoftware.kryo</groupId>
 <artifactId>kryo</artifactId>
 <version>2.22</version>
</dependency>
<dependency>
 <groupId>org.springframework.data</groupId>
 <artifactId>spring-data-redis</artifactId>
 <version>1.1.0.RELEASE</version>
</dependency>
<dependency>
 <groupId>redis.clients</groupId>
 <artifactId>jedis</artifactId>
 <version>2.1.0</version>
</dependency>

Kryo Serializator

I used domain model's entity which hold identifier of our internal service, this is just UUID. The point is to setup kryo serializator which get the entity and returns byte[]. The entity itself is not important.

public class MyEntitySerializer extends Serializer<MyEntity> {

    @Override
    public void write(Kryo kryo, Output output, MyEntity object) {
  return ...;
    }

    @Override
    public MyEntity read(Kryo kryo, Input input, Class<MyEntity> type) {
        return ...;
    }
}

Redis Message Handler

The beautiful part is the complete definition of async message handling within xml configuration of redis message container.

Note that I used Jedis client as java redis client.

<bean id="jedisConnectionFactory" class="org.springframework.data.redis.connection.jedis.JedisConnectionFactory"
  p:host-name="${redisHost}" p:use-pool="true"/>

<bean id="myEntitySerializer" class="MyEntitySerializer" />

<bean id="redisContainer" class="org.springframework.data.redis.listener.RedisMessageListenerContainer">
  <property name="connectionFactory" ref="jedisConnectionFactory"/>
  <property name="messageListeners">
    <!-- map of listeners and their associated topics (channels or/and patterns) -->
    <map>
      <entry>
        <key>
          <bean id="messageListener"
              class="org.springframework.data.redis.listener.adapter.MessageListenerAdapter">
            <constructor-arg>
              <bean class="MyEntityListener"
                  autowire="constructor"/>
            </constructor-arg>
            <property name="serializer" ref="myEntitySerializer"/>
          </bean>
        </key>
        <bean class="org.springframework.data.redis.listener.ChannelTopic">
          <constructor-arg value="${channelName}"/>
        </bean>
      </entry>
    </map>
  </property>
</bean>

What is going on?

Message container references both redis factory and given list of message listeners. It's a class (or set of classes) having registered method as a callback when a new message arrives.

The last property is channel with important channel name. The code uses two variables, first is redis host and already mentioned channel name.

Message Listener

The last thing to do is to define message listener containing callback method, MyEntityListener. The class instance is called always once new message arrive using channel topic.

Crucial point was to discover the signature of callback's method because spring's documentation is little bit sloopy. Quick look into org.springframework.data.redis.listener.adapter.MessageListenerAdapter's onMessage shows the correct way.

public class MyEntityListener {

    public void handleMessage(MyEntity entity, String channel) {
      // provide handling code
    }
}

Incoming message is automatically deserialized so the method accepts entity itself.

Conclusion

Look at previous code. Every redis related code is defined in spring's context and container class. No boilerplate code. Pretty nice.

Architectural note should explicitly show that the entity serves as a notification only. This is very important as such messaging is not reliable. Although the entity holds some information all the persistent data is defined within another place, e.g. as key/value pairs. Approaching message just notifies subscriber that new content is available to refresh and it's supposed to GET key(s).

Scala: get rid of not-null validations

Scala has been always known as a language which allows special handling of null values. There is ton of articles regarding Some[T], None, Option[T].

What is most annoying code for me? Null validations, see usual example:

class Entity {

}

class ServiceA {
  def method(a: Entity, b: Entity, c: Entity, d: Entity) = {
    Validate.notNull(a)
    Validate.notNull(b)
    Validate.notNull(c)
    Validate.notNull(d)
  }
}

class ServiceB(val a: ServiceA) {
  def method() = {
    a.method(null,null,null,null)
  }
}

When you start to write save code in the term of fails-as-fast-as-possible, your code, services or even domain model, will be weedy, you will find such boilerplate code at every method because you can't be sure which parameter supplied someone to you class or method.

Unfortunately Scala has beautiful way how to achieve nice and simple code - without these checks. If you don't think that null is proper state for your class, just dismiss this option. How to do that?

1
2
3

class Entity extends NotNull{

}

Well, that's all. Look at screenshot from my IDE what is about to happen:

Now, if you are sure that you don't want to allow null value for your entity, you can implement NotNull trait and you can remove many lines from your source code.

I was surprised when I found this trait in scala code, because many tutorials or even famous Scala for the Impatient book does not mention this simple but beautiful piece of code.

Tomcat 7 remote deployment

I decided to provide automatic deployment of war packaged application using Jenkins and Deployment plugin. The target platform is Amazon with Tomcat 7, see nice set of articles to find out how to setup such environment for free.

Well, there is couple of tutorials but they missing some points so it pushed me to lost one hour of my work.

What I got

Fresh installation of Tomcat 7 on remote machine with opened 8080 port on firewall
Personal war file supposed to be deployed

How to push it to tomcat?

1. First of all, there is simple configuration of tomcat users in file tomcat-users.xml - it was my pain in the ass :-) As original comprehensive documentation says, it's necessary to define user, but which one(s)?

Here is working example of tomcat-users.xml:

<tomcat-users>
<user username="manager-gui" password="changeit" roles="manager-gui"/>
<user username="manager-script" password="changeit" roles="manager-script"/>
</tomcat-users>

The important part is manager-script, contrary to Tomcat 6 where it had not exist yet. This user allows access to /text sub-namespace in management uri. The first user called manager-gui is the one which you use in GUI console, e.g. http://localhost:8085/manager/html

Once you run tomcat using bin's bat file, you can move to second bullet.

2. Now, it's possible to use remote deployment using curl command, e.g. in my use-case:

curl --upload-file my.war "http://manager-script:changeit@localhost:8080/manager/text/deploy?path=/myPath&update=true"

The command is working using manager-script user contrary to my original manager-gui. Another interesting part is path=/myPath. This attribute say which URL sub-namespace is to be used.

Even if you deploy my.war and common Tomcat's approach is to deploy application in /my subname, the application is to be exposed on /myPath.

Menu