Chystám se zase začít hledat práci. Protože blog používám mimo jiné k ujasnění si myšlenek, zkusím si tu sepsat co a proč hledám. Nečekám, že to bude někdo číst, tradičnější CV, je k dostání třeba tady.

Co nabízím

Moje nejsilnější stránka je programování v Javě na back-endu. Dělám to už dlouho, o Javě a velké části jejího ekosystému vím první, poslední. Na druhou stranu se stále mám ještě co učit. Programování mě navíc baví, takže se ho stále snažím držet.

Jsem fanatik do automatických testů. Jsem přesvědčený, že dobré testy dělají rozdíl mezi udržovatelným kódem a hromadou #$!$#, do které se každý bojí šáhnout. Bez dobrých testů není možný agilní vývoj, continuous deployment a další věci, o kterých všichni básní. Proto udržuji open-source projekt JsonUnit, který kdysi vznikl, protože jsem potřeboval v testech porovnávat JSONy a nic na to neexistovalo.

Pak se taky starám o ShedLock, přispěl jsem do Springu kus kódu na mockování WebServiců a tak. Už jsem říkal, že mě programování baví?

Celkem se vyznám v architektuře. Nicméně zastávám názor, že architektura je věc, která se špatně mění, a takovou věc přeci nechcete. Přijde mi důležitější mít dobré testy, které vám umožní refaktoringem napravit špatná rozhodnutí. Zkrátka, nevěřím v neprogramující architekty a v architekturu vytesanou do kamene.

Další moje silná stránka je selský rozum. Umím se držet při zemi, když dostanu zadání, dokážu v něm najít to důležité a to ostatní ignorovat. Umím si v hlavě srovnat, jak je co potřeba udělat a pak to i dokonce i zrealizovat nebo alespoň zařídit. Často vidím věci, které ostatní nevidí. Pravidelně se mi stává, že vidím zřejmé řešení, které ostatní nenapadlo. Samozřejmě to platí i naopak, občas nevidím to, co je jasné ostatním.

Nebojím se udělat rozhodnutí, nejhorší co se může stát je, že bude špatně. Většinou stejně člověk lituje těch rozhodnutí, které udělal jen tak, mimochodem.

Mám zmáknuté agilní metodiky, ale zatímco před deseti lety mi to všechno přišlo snadné, teď už vidím, jak je těžké změnit chování svoje i ostatních, tak aby to nějak v týmu fungovalo.

Pak tak nějak umí i ty věci kolem, jako AWS, Kubernetes, Linux, trochu JavaScriptu s Reaktem, databáze a nevím co ještě, ale spíš jen tak good-enough než nějak skvěle.

Taky mi přijde, že umím věci vysvětlovat, věnovat se mladším kolegům a obecně technické lídršipování.

Slabé stránky

Baví mě programování, nebaví mě většina ostatních věcí. Párkrát jsem jako bokovku dělal Scrum mastera nebo i team leadera, ale nejde mi to a nebaví mě to. Když můžu programovat, tak nemám na ostatní věci chuť a energii. Opravdu si myslím, že mi to programování jde, takže mi přijde škoda dělat věci, které někdo jiný dokáže udělat lépe a nejspíš i levněji. Takže pokud potřebujete někoho, kdo bude lidem schvalovat dovolené a bavit se s nimi o platu, mým směrem se nedívejte.

Dokážu být docela dominantní, což je občas dobře, ale často špatně. Jsou schůze, na kterých dokážu docela dlouho přesvědčivě mluvit, dělat rozhodnutí a tak. Snažím se to omezovat, ale zjistil jsem, že spoustu ostatních programátorů tu potřebu nemá, takže mívám na dominování dost prostoru. Snažím se s tím pracovat.

Občas jsem negativní, když mě věci štvou, tak je to na mě vidět. Občas je to jen upřímnost, když mi něco přijde jako blbost, tak to řeknu. Občas je to ale zbytečná negativita. Snažím se to změnit, ale jde to hrozně ztuha.

Pak taky kladu hloupé otázky. Moje oblíbená je „Jaký problém tím vyřešíme?“. To je vlastnost, kterou neplánuji měnit, ale lidi to občas štve, takže to dávám do kolonky slabých stránek.

Co hledám?

A teď to nejdůležitější, co hledám? Jak plyne z předchozích odstavců, chci programovat v Javě (nebo Kotlinu) na back-endu. Rád předávám své zkušenosti, takže můžu někoho i technicky vést, můžu navrhovat architekturu, navrhovat řešení, ale jen pod podmínkou, že se dostanu i ke kódování.

Rád bych přičichnul k Machine Learningu, mám nějaké základy, ale rád bych si vyzkoušel nějaké uplatnění v praxi. Nicméně ML je něco, co bych se spíš potřeboval naučit než, že bych to dokázal rovnou dělat.

A to nejproblematičtější nakonec, rád bych dělal něco užitečného. Co to je? Úplně nejradši bych se podílel na řešení klimatické katastrofy, do které se řítíme, ale chápu, že takové projekty nejspíš zatím v Čechách nejsou. Takže se spokojím i s děláním něčeho, co někomu alespoň trochu zlepší život. Do Liftaga mě třeba nalákali na to, že se snaží z města dostat zbytečná osobní auta.

Asi jsem v tomhle idealista, ale přijde mi zbytečné budovat další banku, další nástroj na posílání spamu, zobrazování reklamy, další skvělou mobilní hru na výměnu virtuálních kartiček nebo něco co už tu dávno je, ale tentokrát na blockchainu. Rád bych jednoduše dělal něco, co je užitečné.

Takže pokud byste věděli o práci, na kterou bych se mohl hodit, napište mi prosím na lukas@krecan.net.

Zeptal se mistr žáka: „Jak poznáš, že je tvoje práce hotová?”
„Když skončí vývoj”, odvětil žák. Mistr ho praští holí.

Další den se mistr zeptal na to samé.
„Když je to otestované“, odvětí žák a dostane další ránu.

Mistr se ptá potřetí a žák odpovídá „Už vím, když je to nasazené na produkci!“ Mistr jen smutně zavrtí hlavou.

Čtvrtého dne přijde žák za mistrem sám a říká: „Moje práce je hotová, když je vyřešen daný problém.“ Mistr se usměje a zeptá se: „A jak to poznáš?“

Ano, naše práce není hotová, když nám odpadne kód od ruky, ani když už je otestovaný, dokonce ani když je nasazený na produkci. Naše práce je hotová, až když jsme vyřešili problém, který je potřeba vyřešit. Ale jak to poznáme?

Na to potřebujeme metriku neboli kritérium úspěchu. Nějaké číslo na které se podíváme a poznáme, jestli problém stále máme nebo jestli jsme ho už vyřešili.

Tato metrika by měla splňovat dvě kritéria, která jdou trochu proti sobě. Měla by být co nejblíž businessu a zároveň co nejblíž změně, kterou jsme udělali. V ideálním případě bychom měli udělat změnu a poznat, kolik nám zrovna ta změna přinesla peněz. To většinou bohužel nejde, takže hledáme něco mezi.

Upravujeme registrační formulář, protože teď na něm odpadne 50% potencionálních zákazníků? Můžeme si říci, že to snížíme na 25%. To je pěkná metrika, která se dá přibližně převést na peníze a zároveň drží naší pozornost u registračního formuláře.

Máme pocit, že část naší aplikace je nepřehledná? Jak to měřit? Hledání metriky není vůbec jednoduché, ale i samotné hledání je nesmírně užitečné. Donutí nás to pochopit, co vlastně řešíme. Proč konkrétně nám vadí, že je aplikace nepřehledná? Vadí nám, že zákazníci nedokončí objednávku? Pojďme měřit to. Vadí nám, že zahlcují podporu? Pojďme počítat čas, který tím podpora stráví. Vadí nám, že lidi nechtějí naši aplikaci používat? I to se dá měřit. Tím, že si definuji metriku se donutím myslet na to proč ten problém vlastně řeším.

Musím zdůraznit to, že metrika by měla mít business smysl. Máme občas nutkání měřit jenom přidanou věc. Pro jednoduchost si představme, že přidáváme nové tlačítko. Můžeme měřit kolik lidí na něj kliklo? Můžeme, ale moc nám to neřekne. Tlačítko jsme tam přidávali z nějakého důvodu. Řešili jsme nějaký problém, kterým pravděpodobně nebylo chybějící tlačítko, ale něco úplně jiného. To že změříme, že lidi na tlačítko klikají neznamená, že to pomohlo s řešením problému. Co když na něj klikají omylem?

Vždycky říkám, že programátoři jsou placeni za to, že dodávají hodnotu. Metrika přesouvá moji pozornost z featury na hodnotu.

Když mám metriku, tak ji využiji v celém vývojovém procesu. Nevím který požadavek je důležitější? Ten, který má větší šanci metriku přesunout správným směrem. Cpe mi někdo něco do backlogu pod záminkou řešení aktuální priority? Zeptám se, jestli to opravdu s danou metrikou pomůže.

Největší přínos metriky je ale na konci vývojového procesu. Zabraňuje nám stát se feature factory (tenhle článek si určitě přečtěte). Často totiž tvrdíme, jak jsme agilní a děláme věci iterativně, ale když něco dodáme, tak se k tomu nevracíme. Bez metriky nemáme důvod. Když máme za úkol předělat registrační formulář a nemáme k tomu metriku, tak ho předěláme, oddemujeme nasadíme, přesuneme lísteček a hotovo, hurá na další featuru. Dodali jsme nějakou hodnotu? Koho to zajímá, vždyť to stejně neumíme poznat.

Když máme za úkol zvýšit procento lidí, kteří se skrz registraci dostanou, tak nás to nutí se podívat na to jestli se to povedlo a pokud ne, tak co je další krok. Metrika nás tlačí do toho dělat věci opravdu iterativně, ne jen si na to hrát.

Po letech jsem se byl podívat na Devoxxu, takže je na čase oprášit na blogu pavučiny a zapsat si, co jsem se naučil.

Reactive vs. Loom

Nejvíc mě dostala prezentace o projektu Loom. Na současném přístupu ke škálování mi cosi nesedělo, ale nedokázal jsem pojmenovat co. Pár firem potřebuje opravdu škálovat, a proto všichni musí začít připisovat knihovny na to, aby podporovaly RxJavu, Reactor a podobné. Musíme přepsat databázové ovladače, HTTP knihovny, přístup k souborovému systému tak, aby byl reaktivní. Za to se nám dostane té odměny, že už nebudeme muset psát v Javě, ale v jakémsi DSL, kterým budeme krásně skládat asynchronní potrubí.

Když se nad tím zamyslíte, tak je to neuvěřitelně prosakující abstrakce. Abych ji mohl použít, musím moji asynchronní knihovnu zadrátovat do API. Takže metody už nevrací T ale Mono<T>. To není prosakující abstrakce, ale cedník.

V projektu Loom si chlapci v Oraclu řekli, že to jde možná dělat lépe. Co nám vadí na vláknech? Jsou drahá, žerou paměť a jsou zbytečně blokována při čekání na sít, souborový systém nebo zámek. Co kdybychom použili jinou abstrakci, říkejme jí třeba Fiber (nitka?). Nitka se veze na vlákně, ale když narazí na blokující operaci, tak se vlákna pustí a to může jít vozit jiné nitky. Když blokující operace skončí, blokovaná nitka naskočí na jiné vlákno a provádí další můj kód. Jelikož se všechny blokující operace obvykle provádí skrz standardní Java knihovnu, kód který řeší opuštění vlákna a opětovné naskočení zpět je schovaný v JVM a jeho knihovnách. Já nemusím nic řešit. (Kdo můj poetický popis nepochopil, nechť se stydí a pustí si video).

To znamená, že jako programátor dostanu škálování v podstatě zadarmo. Můžu dál psát svůj staromódní imperativní kód a JVM zajistí, že to poběží efektivně. Samozřejmě nedostanu všechny výhody reaktivního přístupu jako backpressure (protitlak), ale možná mi to za čistší API, čitelné stack tracy a jiný konfort, na který jsem zvyklý, stojí.

Na Dovoxxu ukazovali zajímavé demo, kde vzali Jetty, místo ThreadPoolu podvrhli něco co používá Fibers a když to zrovna nespadlo, tak klasická aplikace v JAX-RS škálovala jako divá. Bohužel bude ještě pár let trvat, než dořeší všechny detaily jako ThreadLocals a podobně, ale vypadá to nadějně.

Trochu s tím rezonovala přednáška o Briana Goetze o Objektovém a funkcionálním programování. Síla objektového programování je v místech, které překračují hranice (boundaries). Tam potřebuji mít silný kontrakt v čemž OOP exceluje. Uvnitř hranic dává občas smysl zahodit ceremonii s objekty spojenou a využít sílu FP.

Nejlepší přednášky:

• Java in 2018: Change is the Only Constant – co nás čeká v Javě, na konci demo projektu Loom
• Java developer’s journey in Kubernetes land – tipy na to jak požívat Kubernetes, když jste Javista. GitHub projekt s příklady. Na Devoxxu se hodně skloňovalo Istio, jako doplňěk pro Kubernetes pro A/B testy a podobně. Na to se musím podívat.
• REST beyond the obvious – API design for ever evolving systems – pěkná přednáška o architektuře. Zajímavý postřeh je, že čím víc low-level API, tím víc coupluje komponenty dohromady. Nicméně výhody HATEOAS jsem stále nepochopil. Chtěl jsem se zeptat, jak se zajistí, že se klient magicky sám od sebe přeprogramuje, ale nestihl jsem to.
• Event Sourcing – You are doing it wrong – super povídání které by měl vidět každý, kdo se pokouší o Event Sourcing. Přednášející vypadal, že ví o čem mluví. S Oliverem Girkem co mluvil o RESTU se shodli, že verzování API přináší víc škody než užitku.

Co říci závěrem? Devoxx je super konference, člověk si rozšíří obzory, uvědomí si, jak moc ho programování baví a jak živý je Java ekosystém. Až na pár ojedinělých výjimek byly všechny přednášky skvělé, takže několikrát litoval, že se nemůžu rozkrájet a jít do víc sálů najednou. Nevadí, 10 Mistakes Hackers Want You to Make si pustím z YouTube.