Archive for the ‘Uncategorized’ Category

Jak poznáme, že to je hotové?

Thursday, March 21st, 2019

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.

Devoxx 2018

Saturday, November 17th, 2018

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:

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.

Zápisky z pražského GeeCONu

Sunday, October 25th, 2015

Pražský GeeCON letos velmi příjemně překvapil. Většinou se z podobných akcí vracím s otázkou proč jsem se nic moc nenaučil. Může to být tím, už jsem tak dobrý nebo to může být nízkou úrovní konference. Letos jsem to řešit nemusel, většina přednášek mě alespoň někam posunula.

Dangers of Parallel Streams

Lukáš Křečan

Pro mě rozhodně nejpřínosnější příspěvek, hlavně proto, že jsem ho přednášel já. Byla to moje první zkušenost s mluvením na akci podobné úrovně. Přípravou jsem strávil neuvěřitelné množství času, dost jsem se toho bál, ale stálo to za to. Nebylo to o mnoho těžší než mluvit před víc kolegy v práci. Ani se nenaplnily moje obavy, že mi z hlavy zmizí všechna anglická slovíčka nebo že mi vypadne technika, bez které by to nedávalo smysl. Nejhorší moment byl, když jsem si celou strašně dlouhou sekundu nemohl vzpomenout na jméno jedné třídy. Celé to byla hrozně zajímavá zkušenost, rozhodně vám doporučuji si to taky zkusit. Připravte si téma, obešlete pár konferencí a vyražte. Výmluvy, že nemáte o čem mluvit neberu, myslíte si, že jsem před tím něco věděl o paralelních streamech? Kdyby vás náhodou nikde nechtěli, tak se ozvěte Dagimu, zjevně má nouzi o řečníky na CZJUG. Mimochodem, pokud jste o můj skvělý výkon přišli, ještě to někdy v příštích měsících budu opakovat pro CZJUG, takže budete mít šanci. Navíc jsem měl pozitivní ohlasy, takže jsem si i dost načechral ego, to není k zahození.

On a Quest Towards the Fastest VM on the Planet!

Jaroslav Tulach

Zajímavé povídání o tom, co se peče v pražském Oraclu – projekt Graal a Truffle DSL Musím se přiznat, že jsem to nepochopil úplně do detailu, ale měla by to být náhrada jednoho kroku JIT kompilace Javy, kdy se bere bytecode a všelijak se optimalizuje. Současná verze je v céčku, Graal je v Javě což údajně umožňuje dělat složitější optimalizace. Zajímavé na tom je to, že k tomu mají API, které vás nechá se do procesu zaháčkovat a upravit ho. To dává možnost pro lepší optimalizaci ostatních jazyků. Na Ruby to ukazuje několikanásobné zrychlení i proti JRuby. Ještě víc neuvěřitelné je to, že se v tom úspěšně pokoušejí pouštět i céčko. To nedává smysl jen do té doby, než si uvědomíte, že spousta jazyků závisí na C knihovnách takže je problém je portovat na JVM. Kdybych dokázal pracovat v korporaci, tak se k nim snad přidám.

Clean Coders Hate What Happens To Your Code When You Use These Enterprise Programming Tricks

Kevlin Henney

Kevlin je profesionální řečník, na kterého narazíte skoro na každé konferenci. Vymakané představení, kde se toho zas tak moc nedozvíte. Navážel se do toho jak často píšeme zbytečně složitý kód jenom ze zvyku. Měl zajímavý příklad s importy v Javě. Opravdu potřebujeme mít na začátku každé třídy desítky řádek s importy? Jakou hodnotu to přináší? Proč nepoužíváme hvězdičkové importy? Má pravdu, není pro to žádný racionální důvod, děláme to jen ze zvyku. Je to zajímavá ilustrace, nicméně problémy se složitostí kódu jsou někde jinde a teprve po deseti letech dennodenního programování jsem tomu začal přicházet na kloub. Čekám, že mi to ještě pár let zabere a tato přednáška mi hlavně připomněla, že se o tom mám pořád pokoušet.

Domain Specific Languages with pleasure

Václav Pech

Musím se přiznat, že na tuto přednášku jsem šel z pocitu viny. S Václavem se znám docela dlouho a ještě nikdy jsem ho přednášet neviděl. Já hlupák. Docela mě to chytlo a otevřelo oči. Pro mě nejzajímavější myšlenka byla to, že vlastně nepřemýšlím v kódu, ale v AST. Krásný příklad je jazyk Scratch pro výuku programování. Ty kostičky jsou AST jak to, že jsem toho ještě nevšiml? Takže já mám v hlavě AST, přepíšu ho do textu, kde to parser vezme a zas z toho udělá AST. Pro programátory to asi dává smysl, ale normálním lidem to nevyhovuje. proto v JetBrains dělají MPS, který vám s AST umožní pracovat i jinak než pomocí textu – třeba pomocí obrázků nebo symbolů.

The dangers of building microservices

Christopher Batey

Pěkně udělaná přednáška o mikroslužbách. Točilo se to kolem toho, že vás mikroslužby vystaví síťovým voláním. A takové volání po síti se může rozbít spoustou různých způsobů. Nejen že ty způsoby ukazoval, ale hlavně předváděl, jak na to psát testy. Přiznejte se, kdo z vás píše automatické testy simulující chování vaší aplikace s nezvykle velkou síťovou latencí. Pokud nevíte jak na to, tak doporučoval Wiremock a Saboteur

Power to the Programmers!

Tom Gilb

Pan Gilb se prý označuje jako dědeček agilního vývoje. Od roku 1958 programoval, agilně pracoval od roku 1960. Ještě pamatuje primitivní doby, kdy lidi chtěli vidět čísla, když se o něčem rozhodovali. Od té doby jsme už naštěstí pokročili a pro rozhodování nám stačí dojmy. Vyprávěl zajímavou historku o tom, jak se na architektonické konferenci zeptal, kolik z nich odhaduje cenu navrhovaného řešení. Z tří set architektů se mu prý přihlásili tři. To je hrozně zajímavé, navrhujeme architekturu a neřešíme kolik to bude stát.

Přednáška se hlavně točila kolem toho, jak je důležité dát programátorům kontrolu nad procesem, kterým pracují. Demonstroval to na tvrdých číslech o množství chyb. V jeho dřevních dobách trávili programátoři opravováních chyb asi tak 30% svého času. Nezapomínejte, že to bylo před nějakými čtyřiceti lety, to by se nám dnes nemohlo stát. Zkusili to změnit. Nejdřív to dali za úkol manažerům, ale to nevedlo k žádnému zlepšení. Když ale dali prostor lidem dole, kteří vědí kde je tlačí bota, tak to výrazně pomohlo. Detaily a odkazy na studie najdete tady

Don't Give Up on Agile Just Yet

J. B. Rainsberger

Poslední byla keynote o agile. Staré známe pravdy, které stojí za to připomínat pořád dokola. Agile je hlavně tom dělat bezpečné a měřitelné experimenty a podle nich se rozhodovat. Vypíchnu dvě myšlenky. První je, že standup je především o risk managementu. Pokud ho děláte kvůli něčemu jinému, tak ho zrušte. Druhá je o to, že laťka v oboru je pořád nastavená hrozně nízko. Stačí přestat dělat úplné pitomosti a budete za hvězdu.