Měl jsem několik nápadů, ale postupně jsem je zavrhl nebo selhali při realizaci. Až mě nakonec napadlo udělat komunitní web pro amatérské výtvarníky. Něco jako Flickr, ale pro lidi, kteří kreslí, malují, dělají si vlastní náušnice a podobně. Originální, že? No abych se přeci jen trochu odlišil, tak se chci zaměřit hlavně na český trh. Proč? Pro tuto cílovou skupinu je důležitá lokalizace do jejich jazyka. Často jsou to lidé, kteří si s počítačem nebo angličtinou moc nerozumí. Nedivil bych se, kdyby byla klasickou zástupkyní ne už mladá žena, která si s počítačem zas tak úplně nerozumí a Facebook zná jen z televize. Ale to je jen odhad, je pravděpodobné, že se pletu. Na druhou stranu lidé, kteří něco dělají rukama jsou ideální cílová skupina. Prostě se chtějí pochlubit a to nejlépe lidem, kteří mají podobné zájmy. Znám to z vlastní zkušenosti. Není nic horšího než se chlubit lidem, které to nezajímá. Navíc tu může docela fungovat šeptanda mezi kamarádkami. Prostě to znělo docela zajímavě.

Nápad ve mně uzrál včera ráno, tak jsem strávil nějakou hodinku na internetu hledáním, jestli něco podobného už neexistuje. A nic takového se mi nepodařilo najít! Alespoň ne v ČR. Pak přišla ta nejtěžší a nejdůležitější fáze. Vymyslet jméno. Nejlépe takové s volnou CZ doménou. Další hodina přemýšlení a hlavně zkoušení. Nakonec vyhrálo „Já tvořím!“. Jméno nic moc, ale lepší mě prostě nenapadlo. Postupně si na něj začínám i zvykat.

Takže máme jméno, teď už zbývá jen ta realizace. Původně jsem si chtěl vyzkoušet Scalu, Google App engine, Amazon S3 a podobně. Nakonec ale asi převážili zkušenosti a odolal jsem pokušení zavřít se na měsíc do sklepa a kódovat. Nejdřív jsem se podíval na internet, jestli bych nemohl využít nějaký existující projekt. Strávil jsem další hodinku na Google a SourceForge a našel jsem pár vhodných kandidátů. Pak jsem si ale vzpomněl, že existuje projekt Ning, v kterém už to všechno je, včetně hostingu. Stačí to jen naklikat. Což popravdě řečeno byla záležitost na půl hodinky. S výsledkem se můžete seznámit sami zde.

Velikou výhodou Ningu je lokalizace. Češtinu už tam prostě mají. Sice bylo a bude potřeba některé překlady upravit, ale to jde snadno přes administrátorské rozhraní. Ning má samozřejmě i své nevýhody. Hlavní nevýhodou je, že od 20. července nebude zadarmo. Verze, které by mi stačila stojí $20 za měsíc. Ale to je cena, kterou jsem ochoten platit. Popravdě řečeno, kdybych si měl jako programátorovi platit komerční cenu, tak jeden můj člověkoden vydá alespoň na rok provozu.

Další nevýhodou je, že nemám tu svobodu, kterou bych měl, kdybych si to napsal sám. Přizpůsobivost hotové platformy má své meze. Na druhou stranu je pravděpodobné, že kdybych to měl všechno programovat, tak bych to asi stejně nedokončil.

Největší nevýhoda ale je, že to samé může klidně udělat kdokoliv jiný (opovažte se!). Jenže to by mohl, i kdybych se na ten měsíc do sklepa zavřel. V dnešní době se člověk musí odlišit na jiné úrovni než technologické.

A jsme u největšího oříšku, kde sehnat lidi? Na tom to celé stojí a padá. Komunitní web bez komunity nemůže fungovat. Jedna věc je šeptanda, ale na tu člověk potřebuje určitou kritickou masu. Dokud jí nedosáhne, tak nemá kdo šeptat. Včera jsem cvičně hodil dvě věty na Facebook a už tam nejsem sám, přidaly se dvě kamarádky. Mám ještě jeden nápad, který by mohl být úspěšnější, ale je ještě v plenkách, tak mi určitě prominete, že si ho nechám pro sebe. Alespoň se pocvičím v marketingu.

Takže proč to vlastně dělám. No jo, proč vlastně? Určitě nečekám, že mě to bude živit. Popravdě řečeno, počítám s tím, že to bude naopak. Taky se na tom evidentně nenaučím programování. Možné se ale naučím spoustu dalších věcí. Hlavní je ale to, že mě to baví. Je to neuvěřitelný zážitek, když vás ráno něco napadne a odpoledne máte prvního uživatele. To za to stojí. Člověk si připadá, že opravdu něco tvoří.

Samozřejmě, pokud ve vás dříme umělec, neváhejte se přidat. Horší než já být nemůžete.

Let it crash
Jonas Boner

Přednáška bylo o knihovně/frameworku Akka. Zase jsem si připomněl jak funguji aktoři a podobné záležitosti. Vypadá to hodně pěkně a použitelně.

Jelikož jsem mastodont, tak mi to hodně připomnělo vychytanější JMS, ale to se není čemu divit. Celý ten asynchronní přístup je pořád o tom samém.

Hodně se mi líbila softwarová transakční paměť (STM). S tím bych si chtěl pohrát. Možná to zatím není moc užitečné, možná to dokonce podporuje špatné návyky, ale rozhodně to vypadá jako pěkné hračka.
Z přednášky samé mě zaujala následující fakta a hlášky:

Na stroji s 4GB paměti může najednou žít 6,5 milionu aktorů.

V Erlangu umějí dosáhnout spolehlivosti na úrovni 9 devítek (99,999 999 9% dostupnosti)

Teď k vám přednáším a tím měním stav ve vašem mozku. Nedělám to tak, že bych vyndal mozek z vaší hlavy, nezměnil jeho stav a vrátil ho zpátky. (pěkné vysvětlení aktorů)

Java 7 Update
Dalibor Topic

Zajímavé povídání o Javě 7. Ale už si pomalu začínám zvykat. Rozdílem oproti obdobné přednášce na Devoxu 2008 bylo to, že některé věci už mají naimplementovány. Ale nevím, jestli mám věřit tomu, že Java 7 někdy spatří světlo světa. Uvidíme jak se k tomu postaví Oracle.
Po přednášce jsem si odchytil řečníka a snažil jsem se zjistit, jak to bude s tím modulárním systémem, který mi dost nahání hrůzu. Moc mě neuklidnil. Když jsem se ho zeptal, jak to budu dělat, když si budu chtít zvolit JDBC ovladač a nebudu mít classpath, tak mi moc neodpověděl. A to je prosím člověk, který se podílí na části implementace toho modulárního systému! Nezbývá mi, než si stáhnout OpenJDK a vyzkoušet na vlastní pěst.

Squeezing Java Performance: When you need a little more
Thomas Enebo

Hodně zajímavé, ale už to popsal otec Fura. Já jsem se tam dozvěděl, že dlouhé metody nejsou špatné jen z důvodu čitelnosti, ale že s nimi má problém i JVM. Takže tady má dobrý návrh bod k dobru. Bohužel jsem se taky dozvěděl, že za určitých okolností JVMku nedělá dobře polymorfismus, ale to mě neodradí od toho ho používat. (Slyšel jste někdo někdy o tzv. „megamorphic“ stavu? Já poprvé až na GeeCONu).

Apache Camel as a DSL for system integration
Roman Kalukiewicz

Camel mě docela překvapil. Původě jsem myslel, že to je jeden z mnoha dalších ESB nástrojů, ale nakonec jsem zjistil, že je to umí něco navíc. Přednáška se točila kolem jejich DSL, který umožňuje celý ten proces elegantně popsat. Například:

from("jms:aQueue")
  .filter().xpath("/person[@name='Jon']")
  .to("file:c:\tmp");

Snad ani nebudu vysvětlovat, co to dělá, je to samopopisné. Největší legrace je, že mi stačí napsat podobných pár řádků a už se to dá spustit z main metody. Samozřejmě se to dá i zaintegrovat do vašeho oblíbeného serveru. Další věc na kterou se chci podívat.

Abych to shrnul, GeeCON příjemně překvapil. Sice tam nabylo tolik špičkovách řečníků jako třeba na Devoxxu, ale i tak se tam člověk dozvěděl neuvěřitelné množství věcí. Už mám seznam věcí, na které se chci rozhodně podívat. Je vidět, že v oblasti Javy se docela inovuje, i když souhlasím s Dagim, že Jazyk samotný nám tak trochu stagnuje.

Keynote

Keynote byla docela zajimava, tocila se kolem Oraclich planu ohledne Javy.

Vypada to optimisticky, Oracle udajne chce do Javy hodne investovat. A to nejen na serveru, ale pry i na jinych zarizenich.

Velky Lary si dokonce pry hral s JavaFX, libilo se mu to a tak to budou dal rozvijet.

Prezentator byl super, musim se s vami podelit o par jeho hlasek:

Harry Ellison je geek jako vy nebo ja. Jenom ma o trochu vic penez. A lodi. A ma krasnou zenu. Ale jinak je to normalni geek.

Geeks do not have friends, geeks have peers.

There are 300 language implementation runnig on Java. Half of them are Lisps

Co se tyce novinek zaujaly me hlavne tyto dve. Prvni je o tom, ze se chystaji sloucit Hotspot an JRockit. Pokud by se jim to povedlo, tak by to mohlo byt zajimave.

Druha je take potesuji. Snazi se napravit cele to divadlo kolem JCP. Hura

Pak take tvrdil, ze se rozhodne nechystaji zabit ani Glassfish, ani NetBeans a dokonce ani JDeveloper.

Apache Aries

Dalsi prezentace byla o Apache Aries. Mela ji Holly Cummins, ale nejak nebyla ve sve kuzi. Asi to bylo tim, ze uz nema modre vlasy. Nebo tim, ze nepovidala o performance.

Jak jsem pochopil, tak Aries je pokus o pouziti OSGi v Java EE. Neco mezi Spring DM serverem, Felixem a Springem. Je to postavene na nejakem standardu a vypada to docela nadejne. Vic jsem nepochytil. Ale chystam se na to mrknout podrobneji.

Spring Roo
Pak jsem se byl podivat na Spring Roo. Prezentator hodne spatny, demem to trochu vylepsil. Roo je neco jako Grails nebo Rails, ale pro Javu a Spring. Jeste nevim jestli se mi to libi nebo ne, na prototypy by se to ale urcite hodilo. To je zatim vse.

Počítače ale pořád ještě pracují s nulami a jedničkami, od kterých je k penězům setsakra daleko. A od toho tu právě jsou abstrakce. Operační systém mě odstíní od těch nul a jedniček, virtuální stroj mě odstíní od operačního systému a správně zvolené knihovny mě odstíní od virtuálního stroje.

V ideálním případě bych měl psát kód, který co nejblíže popisuje řešení daného business problému. Pokud to tak není, je něco špatně. Pokud musím v kódu kopírovat pole bytů, starat se o vlákna, řešit systémové výjimky, starat se o paralelizaci, tak vím, že je někde chyba. Já chci prostě a jednoduše psát jenom business kód.

A nejsem to jenom já, podívejme se tímto pohledem na úspěšné technologie. Můžeme začít třeba samotnou Javou. Ta uspěla také díky tomu, že programátora odstínila od spousty do té doby běžných infrastrukturních starost. V Javě už jste se nemuseli starat o dealokování paměti, nemuseli jste řešit, jestli je String ukončený nulou nebo čím, nemuseli jste řešit jaký typ procesoru používáte nebo jaký je rozdíl mezi endianem a indiánem. V Javě jste se mohli jste se soustředit na psaní kódu. (Ano vím, že Smalltalk to uměl už o sto let dříve).

Podobně úspěšné je servlet API. To nám zas umožňuje chovat se k vícevláknovému systému tak, jako by v něm bylo jen jedno vlákno. Ano, jako každá abstrakce i tato prosakuje, ale v zásadě to tak je. Vsadil bych se, že tato podařená abstrakce stojí za úspěchem servlet API a tím pádem i enterprise Javy. Naopak špatnou abstrakci poznáte podle toho, že vás nutí dělat něco, co byste jinak nedělali. Třeba EJB 2 a jeho šílená rozhraní.

Nejen že mi dobrá abstrakce umožňuje se soustředit na můj business problém, ona mi i umožňuje držet krok s vývojem. Změní se operační systém? Nic se neděje. Změní se architektura procesoru? Nezájem, já jsem svůj program napsal v obecnější rovině, takže mě to (pravděpodobně) neovlivní. Naopak, já mohu využít novinek aniž bych na svůj kód třeba jen šáhnul. Procesor má tisíc jader? Nevadí, jenom změním konfiguraci serveru a mám vystaráno. Práce s více vlákny je pomalá? Nevadí, udělám update JVM a hned je vše jinak. Moje problémy za mě řeší někdo jiný.

A to je vlastně důvod, proč to všechno píši. Pokud mě někdo nutí zahrnout do programu něco, co nevyjadřuje business problém, vím že je to špatně. Pokud mě někdo například nutí používat asynchronní API a z mých požadavků to přímo nevyplývá, vím, že se snaží řešit problém na nesprávném místě. Často není vyhnutí, často není technologie dost pokročilá. Ale většinou je to prostě jen špatná volba.

Představme si, že například nechci, aby uživatel čekal, až se mi data zapíší do databáze, tak jak to píše Dagi. Samozřejmě, že to mohu řešit v kódu. Ale tam já to řešit nechci, tam já chci řešit jenom business. Musím se proto zamyslet jak to dělat jinak. Použít rychlejší databázi? Použít lepší JDBC ovladač? Použít databázi, která bere transakce velmi benevolentně? Všechno je možné, změna kódu je až poslední varianta.

Je tu ještě jeden z argumentů, který jsem zatím nezmínil. Lidé, kteří píší knihovny, databáze nebo virtuální stroje tomu rozumí mnohem lépe než já. Já vím jak převádět peníze, oni rozumí transakcím. Já vím co zajímá zákazníka, oni vědí jak synchronizovat data mezi vlákny. Kdykoliv to musím řešit za ně, vím, že buď odvedli špatnou práci nebo že já jsem si zvolil špatnou technologii.

Vemte si například ParallelArray. To mi umožňuje provádět operaci nad poli paralelně. Úžasná a i převratná knihovna. Ale z mého pohledu je špatná v tom, že mě nutí řešit thread pooly. To já nechci, to zákazníka vůbec nezajímá. Zamysleme se, proč to za mě nemůže řešit někdo jiný. Řekněme, že zavolám klasické Arrays.sort(). Proč nemůže běžet paralelně? Že JVM neví kolik vláken se má použít? Jak to že ne? To to ví dokonce lépe než já. Virtuální stroj dokonce i ví, kolik přesně má v daném okamžiku volných procesorů. To já nikdy v okamžiku psaní programu nevím a vědět nikdy nebudu. Že neví jestli je to operace k paralelizaci vhodná? Jak to? HotSpot to ví zase mnohem přesněji než já. To je stejné, jako kdybyste tvrdili, že je lepší, když programátor ručně uvolňuje paměť nebo optimalizuje kód.

Tak se nad tím prosím zkuste zamyslet. Třeba nad tím jak do toho všeho zapadají dynamické jazyky, DSL a podobně. Připadá mi, že to všechno dává docela smysl.

Ještě musím podotknout, že budu psát o klasickém serveru, který má problém s tím, že má moc uživatelů. Rozhodně se to netýká třeba dávkového zpracování velkého množství dat, to je úplně jiná kapitola.

Takže o co jde? V pondělí jsem viděl bleskořeč o node.js. Zaujal mě příklad, na kterém bylo předvedeno asynchronní čtení z databáze. Motivace je jednoduchá. Čtení z databáze je obvykle pomalé a je škoda zdržovat drahé a cenné vlákno čekáním. Je lepší ho poslat obsluhovat další požadavky. Výsledek databázového dotazu může být zpracovaný později, buď tím samým, nebo jiným vláknem. Tím pádem bude náš systém skoro neomezeně škálovatelný. To dává smysl, že? Ani náhodou!

Původně jsem chtěl napsat, že to je špatně zvolený příklad, že asynchronní JDBC je nesmysl. Ale pak se mi to rozleželo a jsem ochoten připustit, že by v tom něco být mohlo. Ale jen malinko.

Nejdřív si musíme uvědomit, že databázový dotaz trvá dlouho proto, že databáze nestíhá. Chudinka totiž bývá tím jedním bodem, na který se všichni připojují. Tím že aplikačnímu serveru umožním zpracovat víc připojení celou situaci jen zhorším. Je to stejné, jako když na pomalém internetu čekáte na načtení stránky a z nudy si otevřete druhou. Ta samozřejmě také dlouho trvá a proto si otevřete třetí. A ono pořád nic. Dokonce to vypadá, jako by ten internet byl ještě pomalejší. Stejná věc by se vám mohla stát i u databáze. Takže si prosím zapamatujte, že pokud máte pomalou databázi, tak ji více souběžnými dotazy moc nepomůžete.

Naštěstí máme obvykle omezený pool připojení do databáze takže to akutně nehrozí (Jirka Mareš má bod za postřeh). Za domácí úkol se zkuste zamyslet co by se v takovém případě stalo? Čekaly by požadavky ve frontě (jaké, jak dlouho) na uvolnění připojení nebo by to vyhazovalo chybu?

Obdobný problém máme, i pokud čekáme na pomalý disk nebo zatížený procesor. Tím že budeme přijímat víc práce, situaci jen zhoršíme. V takovém případě asynchronní volání smysl moc nedává. Naopak, potřebujeme požadavky co nejdříve přibrzdit, aby měl server čas na zotavení.

Představme si ale situaci, kdy nečekáme na nedostatkový zdroj, ale na něco, co prostě jen dlouho trvá. Jsou lepší vlákna nebo asynchronní volání? Já hlasuji pro vlákna. Asynchronní volání až moc smrdí předčasnou optimalizací. Nutí programátora myslet úplně jinak, jenom kvůli strachu z něčeho, co možná nenastane. Bojíme se, že náš systém nezvládne dost vláken a proto znepřehledňujeme zdrojový kód. Klasická předčasná optimalizace.

Schválně, zkuste odhadnout kolik vláken zvládne JVM na běžném serveru? 10, 100, 1K, 10K nebo 100K? Víte to? Já jsem také nevěděl, tak jsem se vydal hledat. Moc zdrojů k tomu není, ale narazil jsem na užasnou prezentaci. Tu si určitě přečtěte. Kromě jiného se v ní dočtete, že 10 000 vláken by neměl být problém (s menším laděním velikosti zásobníku)! Navíc je to prý i dost rychlé. Najdou se i tací, kteří tvrdí, že použití vláken je dokonce rychlejší než událostní řízení! Takže je možné, že si chceme znepřehledňovat kód jen proto, abychom ho zpomalili. Nevím jestli už jsem to psal, ale to by byla klasická předčasná optimalizace. Zapamatujte si proto prosím, že spící vlákno (skoro) nic nestojí.

Ale i kdyby vlákna byla pomalejší, radši bych počkal až to za mě Oracle vyřeší při dalším updatu Javy, než abych kvůli tomu učil spoustu programátorů myslet jinak! Schválně, jak dlouho vám bude trvat pochopit asynchronní servlety. Mě se to pořád ještě pořádně nepodařilo. A to jsem se docela snažil. (Pěkný úvod najdete zde.)

Ale abych přeci nebyl jen tak jednostranný, je spousta míst, kde se asynchronní zpracování hodí. Jedním z nich může být šílený AJAX dotaz, který drží otevřené připojení a tím i vlákno desítky sekund. Třeba proto, že čeká až vám přijde mail. Pak má možná smysl uvažovat nad tím, uvolnit vlákno pro někoho jiného. Ale i to by mělo jít řešit transparentně. Něco ve smyslu: JVM si všimlo, že toto vlákno dlouho spí, tak jeho zásobník někam schová a uvolní prostředky. Já se pak se nebudu musit učit úplně jinému způsobu myšlení a moje programy budou zároveň škálovatelné i čitelné.

Rozloučím se pár citáty:

What's harder, synchronizing 2 threads or synchronizing 1000 threads?

We examined the code structure of the Flash web server and of several applications in Ninja, SEDA, and TinyOS. In all cases, the control flow patterns used by these applications fell into three simple categories: call/return, parallel calls, and pipelines. All of these patterns can be expressed more naturally with threads.

[Rob von Behren, Jeremy Condit and Eric Brewer, Why Events Are A Bad Idea (for high-concurrency servers)]

Většina vývojářů věří, že je dobrá v ladění výkonu, ale obecně se ukazuje, že většina vývojářů v tom dobrá není.
Kirk Pepperdine

Tento citát z rozhovoru s Kirkem Pepperdinem jsem tu použil záměrně. Chci tu psát o svých nedávných zkušenostech s měřením a laděním výkonu, ale vzhledem k tomu, že jsem docela dobrý vývojář, je velká pravděpodobnost, že jsem na to šel špatně.

Takže jste byli varováni a já se může pustit do popisu problému. Pracuji na jednom velkém a zbytečně složitém systému. Nedávno se po jedné podařené marketingové akci velká skupina zákazníku rozhodla, že ho začne volat v jeden okamžik najednou. Navíc ještě k tomu v pátek večer. No a protože to je docela velká skupina, náš systém s tím měl drobné potíže. Kolegové s řešením strávili pěkných pár dnů, nakonec našli místa potencionálních problémů a před systém postavili pár obraných mechanizmů, které ho chrání před přetížením. Nicméně problém stále trvá a bylo by pěkné ho vyřešit. Jinak by se mohlo stát, že se z velké skupiny stane malá, což by mohlo potěšit naše administrátory, ale rozhodně ne náš marketing.

Teď přicházím do hry já. Kolegové mi ukázali na jednu věc, kterou aplikace dělá evidentně zbytečně a ať prý vymyslím, jak se jí zbavit, aniž by se něco rozbilo. Jenže já jsem známý potížista a navíc jsem si vzpomněl na jednu přednášku Kirka Pepperdineho, v které říkal něco v tomto smyslu (nedaří se mi najít zdroj, takže cituji z paměti):

1. Nejdřív si zjistěte jaký je požadovaný výkon (SLA)
2. Naměřte současné hodnoty
3. Zjistěte možné problémy
4. Jeden z nich opravte
5. Naměřte nové hodnoty
6. Opakujte dokud nesplníte 1. nebo dokud má zákazník ještě nějaké peníze

Takže jsem si zjistil SLA a začal měřit. A už tady jsem možná udělal chybu. Začal jsem měřit na svém notebooku a ne na prostředí, které se podobá produkci. Mojí výmluvou je to, že jsem si myslel, že už víme v čem je problém. A opravdu, při testech se projevovala potíž v té jedné nadbytečné operaci. Zbytečně se tam zapisovala data do jedné tabulky. Z té se obratem zase četlo a občas tu jeden select zabíral desítky sekund. Cože? Desítky sekund u dotazu nad tabulkou v které je jen pár set tisíc záznamů? Něco je špatně. Po chvíli pátrání jsem objevil, že někteří klienti mají v dané tabulce stovky záznamů místo očekávaného tuctu a pro ně trvá dotaz neúnosně dlouho. Jeden dobře mířený index nad tabulkou, která na daný dotaz zdánlivě neměla vliv to vyřešil.

Tento problém moji pozornost obrátil na test samotný. Jak je možné, že data vypadají jinak, než je očekáváno? Ukázalo se, že chyby mohou být i v testu samotném. Místo simulace tisíců různých klientů, simuloval tisíce přístupů od pár desítek klientů. Takže den testování v čudu, ale jsme alespoň o krok blíž. Máme opravený test.

Spustím opravené testy a aplikace je stále podezřele pomalá. Navíc i když spouštím JMeter, aplikaci i databázi na jednom stroji, zátěž procesoru dosahuje ubohých 75%. Brzdou je něco jiného. Vypadá to, že disk. A opravdu MySql proces zapisuje a čte jak divoký. Že by to přece jen byly ty zbytečné inzerty. To se zjistí velice snadno, prostě je vyhodím.

Po pár minutách hledání nejlepšího místa pro sabotáž, vyřazení inzertů z boje a desítkách minut buildu a startu serveru nedočkavě spouštím test a ... chvilka napětí ... jste tak napjatí jako já ? ... vážně ? ... výsledky jsou srovnatelné s předchozími. Obě jádra se pořád flákají, disk maká jak afroameričan.

Takže dalších pár hodinek pátrání a nacházím tabulku, která na první pohled s testem moc nesouvisí. Ale předchozí testy do ní nasypaly hromadu dat, která teď zdržují. Vymažu obsah tabulky, znovu spustím test a graf výkonu málem proletěl vrškem monitoru. Požadovaný výkon bych možná splnil i na notebooku!

Problém vyřešen. Nebo ne? Co se stane, když inzerty vrátím? Další desítky minut strávené novým buildem a spouštím test. Sakra, je to srovnatelně rychlé, jako když tam ty inzerty nejsou.

Ukazuje se, že obsah databáze a způsob testování má na výkon větší vliv, než struktura kódu! To je trochu nečekaný výsledek. Jediné co jsem udělal bylo, že jsem opravil test, přidal jeden index a promazal tabulky. A už to mělo za následek dvojnásobné zvýšení výkonu. Alespoň toho naměřeného. Takže jsem tam kde jsem začal. O tom kde nás tlačí bota nevím skoro nic. Že by měl Kirk pravdu? Že by programátoři byli opravdu špatnými testery? Tomu se mi nechce věřit. Nevzdávám to a zítra se vrhnu na testy v reálném prostředí. To by v tom byl čert, abych na něco nepřišel.

Není důležitý cíl, ale cesta k němu
Budha

Jsem členem týmu, který se zrovna formuje. To s sebou nese trochu tápání, diskuzí ohledně toho co a jak chceme dokumentovat, jak se mezi sebou domlouvat, jak testovat, jak dělat revize kódu a podobně. V poslední době se mi stává, že uprostřed živé diskuze vyslovím svoji zabijáckou otázku. Vždy je to něco ve smyslu „Proč to chceme dělat?“, „Jaký je cíl?“, „Pro koho to chceme psát?“ nebo „What's the objective?“. Většinou si za podobnou otázku vysloužím pár pohledů, některé z nich říkají „Vždyť je to přece jasné“, jiné „Ty seš zas úplně mimo“. Málokdy zahlédnu pohled říkající „Děkuji, že jsi nás přivedl na pravou a jedinou cestu, ó velký.“.

Tak jsem si řekl, že napíši tento zápisek, aby kolegové věděli, jak ke mně mají vzhlížet. Myslím si totiž, že ať už člověk dělá v práci cokoliv, měl by se nejdřív zamyslet nad cílem. Napadají mě tyto příklady

• Připravuji prezentaci. Musím se zamyslet nad tím co je ta nejdůležitější věc, kterou chci sdělit. Pak už bývá snadné vymyslet, jak má prezentace vypadat.
• Píši dokument. Musím se zamyslet pro koho ho píši a při jaké příležitosti ho bude číst. Jinak vypadá dokument pro manažery, který ho (možná) bude číst jednou při schvalování a jinak pro programátora, který v něm bude občas něco hledat.
• Organizuji schůzku. Musím se zamyslet co je ten nejdůležitější výstup. Má někdo něco zařídit? Chci se něco dozvědět? Jakmile v tom mám jasno, mám z půlky vyhráno.
• Dělám revizi kódu. Musím se ujistit, že vím proč ji chci dělat. Chci se ujistit, že nováčci píší kód který je konzistentní se stávajícím? Vím že revizi musí dělat zkušenější kolega. Chci zachytit největší chyby co nejdřív? Musím dělat revize průběžně. Chci šířit znalosti? Stačí mi jedna revize na konci za účasti všech.
• Píši aplikaci. Měl bych vědět, co je ten hlavní důvod její existence.
• Jdu se pohádat s kolegou. Nejdřív bych se měl nadechnout a zamyslet se nad ideálním výstupem z hádky. Čeho jí chci dosáhnout?
• Píšu zápisek do blogu. Co je ta hlavní myšlenka, kterou chci sdělit?

Zní vám to povědomě nebo dokonce samozřejmě? Není divu. Se stejnou myšlenkou se setkáváme na různých školeních, v agilních metodikách, v chytrých knihách, zkrátka všude. Zamyslete se ale, jak často tento postup dodržujete. Mě se to povede jen občas a to se docela snažím. Ono to totiž není vůbec jednoduché.

Na každou otázku existuje jednoduchá, snadno pochopitelná, nesprávná odpověď.

Ještě víc se to zesložití, když vám řeknu, že ten cíl by měl být ideálně jen jeden. Já vím, že chcete zabít víc much jednou ranou. Je ale neuvěřitelně užitečné zformulovat jediný snadno popsatelný cíl. Pak si můžete nadefinovat i pár vedlejších cílů, ale pořád musíte vědět, který je ten primární. Je to podobné jako měli posádky bombardérů za druhé světové. Ty také dostali jeden primární cíl. Pak samozřejmě měli i pár druhotných cílů, kterým se měli věnovat, kdyby jim náhodou nějaká bomba zbyla nebo kdyby byl prvotní cíl nedosažitelný. Ale ten hlavní byl jen jeden. Proč to tak bylo? Přece proto aby věděli kam letět. Kdyby dostali cílů dvacet, tak by jim to k ničemu nebylo.

My jsme v úplně stejné situaci. Jakmile si řekneme, že dokument je určen pro manažery, ale vlastně i pro programátory a přihodíme tam i pár kapitolek pro testery, tak nakonec skončíme s dokumentem, který nebude vhodný pro nikoho.

Dejme tomu, že jsme investovali velké úsilí a dost času a máme cíl, s který je jasně sdělitelný a pochopitelný. Čeká nás další krok. Musíme cíl roztroubit. Musíme zajistit, aby všichni zúčastnění věděli co ten cíl je. Napíšeme to do pozvánky, na začátek dokumentu, řekneme to v úvodu, prostě se ujistíme, že to všichni vědí. U opakovaných akcí to čas od času zopakujeme. Ještě lepší je, když se na cíli zúčastnění dohodnou sami, ale to už bych toho chtěl moc.

Promiňte mi tento dlouhý dopis, ale neměl jsem čas napsat krátký.
Pascal

Jakmile mám super cíl a všichni o něm vědí, můžeme si začít užívat jeho pozitivních účinků. Nejlépe je to vidět na schůzkách. Když lidé vědí proč tam sedí, vědí o čem mají mluvit. Organizátor dokonce může schůzku nasměrovat, když se stáčí někam kam nemá. Lidé dokonce dopředu vědí, jestli jsou na té schůzce potřeba. Někdy se dokonce při vymýšlení cíle schůzky zjistí, že není vůbec potřeba, že se ten cíl dá naplnit úplně jinak, jednodušeji.

To je hrozně důležité. Při vymýšlení cíle, často přijdeme na to, že k jeho naplnění by se nám hodily úplně jiné prostředky.

Cíle také umožňují prioritizaci. Pokud vím co je cílem iterace, mohu si při nedostatku času vybírat, které úkoly jsou důležitější. Všechno co s cílem nesouvisí musí pryč. Stejně tak u dokumentů, co neslouží k cíli tam nemá co dělat. O prezentacích nemluvě, dobrá prezentace se pozná podle toho, že je jasné co se vám přednášející snaží říci.

Zbývá nám tedy otázka, proč se to tak málo vidí? Proč chodíme na schůzky, u kterých nevíme proč jsou svolávány, proč čteme dokumenty, u kterých není jasné komu jsou určeny, proč píšeme programy, u kterých si nejsme jisti k čemu mají sloužit? Důvodů je asi víc.

Hlavně si všichni myslí, že cíl je přeci jasný. Všichni přeci víme, proč se každý týden scházíme a říkáme si co kdo dělal a bude dělat, všichni vědí, proč píšeme ten který typ testů, všichni přece víme proč děláme revizi kódu, všichni víme proč píšeme design. Opravdu? Tak mi to řekněte jednou větou.

Mám podezření, že dalším problémem s cílem je, že nutí lidi myslet. Já například myslím hrozně nerad. Je jednodušší svolat schůzku a o něčem si povídat, než si lámat hlavu s cílem. Jasné cíle také lidi neuvěřitelně omezují. Když třeba dělám prezentaci, tak chci předvést co všechno o tématu vím, nechci se nějak omezovat. Když píšu dokument pro manažery, chci se vytáhnout, tak tam švihnu jak bude vypadat databáze. Když píšu blog, tak chci předvést jak jsem skvělý, ne se soustředit na na nějaký trapný cíl. Na druhou stranu, kdybych to udělal, byl by i tento zápisek dvakrát kratší a mnohem lepší.

Mítinky jsou boje o moc mezi lidmi, kteří něco chtějí, a těmi, kteří jim to nechtějí dát.

Pravidelnější čtenáři tohoto nepravidelného blogu už jistě tuší, že je čeká další minirecenze. Tentokrát se jedná o knihu „Managing humans“ (na ten odkaz rozhodně klikněte) od Michaela Loopa (Jírovy patří dík za tip). Kniha je to stylem podobná Joel on Software a musím přiznat, že se mi líbila skoro stejně. Je sice o hodně méně technická, ale zato mnohem víc o lidech.

Dal bych ji za povinnou literaturu lidem, kteří se snaží vést (nebo nedejbože řídit) bandu nerdů. Ale je hodně zajímavá i pro nás nerdy samotné. Hodně užitečná je i pro lidi, kteří pracují v korporaci.

Takže co se v knize dočtete? Hodně mě zaujala kapitola o tom, jak uhodnout, co se děje na pracovní schůzce. Znáte to, sedíte na mítinku a přemýšlíte co tam sakra děláte, co a proč se ti lidé snaží říci. V kapitolách „Agenda detection“ a „Meeting creatures“ se to dočtete.

Zajímavé jsou i části, které popisují jak se připravit na pohovor, napsat životopis a podobně. To jsem měl sakra vědět před pár měsíci.

No a neméně zajímavé jsou i kapitoly o nerdech samotných. Například NADD. Ale třeba "Přiručka k nerdovi" se do knihy nedostala.

Jak jste si všimli, většina kapitol je volně ke čtení i na autorově blogu, ale mě se kniha čte mnohem lépe. Jenom si dovoluji upozornit, že je to psané pokročilejší angličtinou, takže se docela procvičíte. Například na straně 188 mě dostalo sloveso „to grok“, ale jelikož jsem nerd tak jsem to pochopil i bez slovníku. I když jak tak koukám, tak se to dostalo i do slovníků, zajímavé. Ale zpátky ke knize, ta zaslouženě dostává neuvěřitelných deset hvězdiček z deseti.

No a abych vás neochudil o tradiční ukázku z knihy, uvedu pár položek z vysvětlivek na konci knihy:

Agenda – Seznam věcí, které se musí na dané schůzce odehrát aby byla kompletní. Pokud všichni účastníci na dané schůzce nejsou seznámeni s agendou, bude docházet ke ztrátě času.

Spolupráce – Slovo používané k tomu, aby vás přesvědčili pracovat s lidmi, kterým byste se raději vyhnuli.

Milník (Milestone) – Chabě nadefinované, přehnaně vytrubované datum, které je částí softwarového vývoje. Vývojový tým při něm přemýšlí o tom jak je v pytli.

Proces – Šestipísmenné slovo začínající na P. Proces není špatná věc. Obzvlášť ve velkých organizacích kde ohromné množství lidí ztrácí velké množství času děláním té samé věci.

Specka (Specifikace) – Dokument, který říká jak to je. Proces psaní specifikace bývá víc užitečný než výsledný dokument.

O co tedy jde? Těžko se to popisuje, je to něco mezi Gmailem, gTalkem, Facebookem, Picasou, Androidem a GoogleDocs. V zásadě se na to můžete dívat jako na nadopovaný gTalk. Základním stavebním prvkem je jedna Vlnka (wave). Je to podobné jednomu diskuznímu vláknu, v němž si můžete povídat s několika lidmi, okamžitě vidíte jejich odpovědi, můžete vytvářet soukromé poddiskuze, zkrátka nic světoborného. Co je převratné jsou způsoby rozšířitelnosti. Diskuze se například mohou účastnit roboti. Jeden robot vám třeba může v reálném čase opravovat pravopis, druhý vaši diskuzi může překládat do Klingonštiny, třetí může poznávat vložené odkazy. Roboty si můžete napsat sami za použití přiloženého API a pustit je třeba na Google App Enginu.

Samozřejmě si také můžete napsat vlastní rozšíření samotné Wave aplikace (Gadgets). Je to něco jako plugin do prohlížeče nebo vlastní Androidí aplikace, akorát v tomto případě běží na serveru (alespoň jsem to tak pochopil). Takže do Vlnky můžete kromě textu vložit i třeba šachovnici a zahrát si šachy.

No a jelikož to má všechno běžet na otevřeném a jednoduchém protokolu, nemělo by být problémem napsat si vlastní server. Dokonce tvrdili, že část kódu zveřejní jako open source. Když to shrnu, tak Wave je rozšířitelný chat. Rozšířitelný tak, že do něm můžete vkládat fotky, mapy, aktivní obsah, hry a v podstatě co skoro všechno co vás napadne. Pro podrobnosti si pusťte tu prezentaci, nudit se u ní rozhodně nebudete.

public class PureJdbcBankDao implements Bank {
	public void setBalance(String accountNumber, BigDecimal balance) {
		Connection conn = null;
		PreparedStatement ps = null;
		try {
			conn = ConnectionFactory.getConnection();
			ps = conn.prepareStatement("UPDATE ACCOUNT SET BALANCE = ? WHERE ACCOUNT_NUMBER = ?");
			ps.setBigDecimal(1, balance);
			ps.setString(2, accountNumber);
			ps.execute();
		} catch (SQLException e) {
			throw new ApplicationException("JDBC failure", e);
		} finally {
			if (ps != null) {
				try {
					ps.close();
				} catch (SQLException e) {
					// what to do here?
				}
			}
			if (conn != null) {
				try {
					conn.close();
				} catch (SQLException e) {
					// what to do here?
				}
			}
		}

	}

Je to metoda pro zápis do databáze pomocí čistého JDBC. Toto je nádherná ukázka míchání dvou druhů kódu. Jednomu druhu říkám hezky česky „business kód". To je kód, který je užitečný pro zákazníka. V našem příkladu po nás někdo chce, abychom změnili hodnotu v databázi. To obvykle děláme pomocí SQL příkazu, který vidím jenom na jednom řádku. Zbytek je „infrastrukturní kód". Tak říkám kódu, který někdo udělat musí, ale zákazníkovi je v podstatě k ničemu. V našem příkladě to jsou všechny řádky kromě jednoho. Ano opravdu, zákazníkovi je naprosto jedno, že potřebuji připojení do databáze, je mu dokonce jedno, že ho musím po sobě zavřít, on po mě chce abych něco zapsal do databáze. Popravdě řečeno, často po mě nechce ani to, chce jen, aby jeho důležitá data byla dobře uložena.

Ale zpátky k věci. Když to přeformuluji tak mohu říci, že business kód je ten, co dělá něco zajímavého pro zákazníka, infrastrukturní kód je ten, který zajímá jen programátora. Samozřejmě potřebujeme oba druhy, je ale důležité si uvědomit který je který a přistupovat k nim rozdílně. Úplně nejdůležitější je držet oba druhy odděleně. Pokud máte JDBC kód v business vrstvě nebo nedej bože v kontroleru, tak vám nepomůže ani svěcená voda. Pokud ho máte schovaný v DAO vrstvě, tak jste v trochu lepší situaci. Ale i tak je obtížné takový moloch testovat a měnit. Představte si, že bych si vzpomněl, že potřebuji transakce. Musel bych upravit všechny metody v DAO vrstvě. To nezní jako dobrý nápad.
Existují i další argumenty proč infrastrukturní kód nepsat. Nejenže je takový kód nečitelný, on je navíc náchylný na chybu. Když náhodou zapomenu zavřít PreparedStatement nemusí to nějaký čas vadit. Po změně databáze ale můžu začít dostávat veselé chyby a může mi trvat pěkných pár dní než najdu jejich zdroj.

Já jsem obecně přesvědčen, že programátoři, kteří píší kód pro zákazníky, by se měli infrastrukturnímu kódu co nejvíce vyhýbat. Myslím si že je mnohem lepší psát kód takto:

public class JdbcBankDao extends SimpleJdbcDaoSupport implements Bank {

	public void setBalance(String accountNumber, BigDecimal balance)
	{
		getSimpleJdbcTemplate().
			update("UPDATE ACCOUNT SET BALANCE = ? WHERE ACCOUNT_NUMBER = ?", balance, accountNumber);
	}
}

Nejen, že rovnou vidím, co daná metoda dělá, já tam ani nemám moc co zkazit. Téměř všechen infrastrukturní kód zmizel. Samozřejmě že tam stále je, ale napsal ho za mě někdo jiný. V tomto případě autoři Springu. Ano mohl jsem si napsat vlastní framework, ale tím bych si moc práce neušetřil. Navíc bych do něj musel přidat podporu transakcí, podporu testování a podobně. Takže bych víc času strávil vývojem frameworku než něčím, co přináší zákazníkovi užitek.

Příklad s JDBC je samozřejmě trošku extrémní, málokdy se nám stane, že bychom motali JDBC kód s business kódem. Často ale vyvíjíme jiné typy infrastruktury a často nás ani nenapadne, že bychom to dělat neměli. Nebo nás to napadne, ale najdeme si nějakou výmluvu. Ze své praxe pamatuji několik případů, které jsem spáchal já nebo některý z mých kolegů.

1. Asi nejčastější jsou všelijaké implementace vyrovnávací paměti (cache). Znáte to, máte číselníková nebo jiná málo se měnící data v databázi. Místo toho abyste je četli při každém dotazu tak si je přednačtete do mapy a pak je už jen taháte z paměti. Klasické míchání infrastrukturního a business kódu a také klasický kandidát na vlastní framework popřípadě knihovnu. Přitom stačí vhodně použít cache přes AOP (spring-modules nebo AOP cache).
2. Načítání konfigurace je také oblíbené. S nástupem Springu už se s tím tak často nesetkáte, ale doby kdy si každý implementoval svoji variantu konfigurační knihovny neminuly zas tak dávno. Občas ještě v business kódu tu a tam zahlédnu načítání properties souboru a vytahování příslušné hodnoty.
3. Logování je další klasický případ. Zde bych udělal výjimku z pravidla a řekl bych, že míchání logování a business kódu není na škodu, někdy může být i užitečné. Logy mohou pěkně zastupovat komentáře. Když ale říkám že logování samotné škodlivé není, psaní si vlastní knihovny na logování už škodlivé je. Myslím si, že zrovna logovacích knihoven máme v Javě dost.
4. Skoro vždy se setkáme s vlastními utility třídami. Tedy třídami, které usnadňují věci, které v Javě nejsou zrovna jednoduché. Ať už se jedná o práci s časem a datem, kopírování input streamu do output streamu, načítání obsahu souboru do stringu a podobně. Ano, standardní knihovny jsou v tomto ohledu neohrabané, to ale neznamená, že si to musíme psát sami. Jakarta commons, Joda nebo i Spring nám v tomto ohledu rozhodně dokáží pomoci.
5. Jednou jsem strávil krásný týden implementací skoro transparentního šifrování dat na úrovni Hibernate. Tzn. v Javě se s daty pracovalo normálně, ale i při ukládání a načítání do databáze se data automagicky šifrovala a dešifrovala. Měl jsem z toho projektu docela radost. Tu mi zkazily dvě věci. Týden po tom, co jsem to dopsal jsem zjistil, že už podobné řešení existuje. Druhou vadou na kráse bylo, že kolegové začali přes Hibernate dávkově zpracovávat desetitísíce záznamů a moje geniální knihovna na to nebyla stavěná a dost celé zpracování zpomalovala.
6. Jsem si jist, že další příklady z praxe si doplníte sami.

Já jsem přesvědčen, že v dnešní době už člověk sežene knihovnu skoro na všechno. Pokud má to štěstí a knihovna mu umožní zbavit se infrastrukturního kódu, měl by ji použít. Pokud štěstí nemá a musí si opravdu napsat infrastrukturní kód, měl by ho důsledně oddělit od business kódu. Ale jak říkával kolega, každý, kdo se rozhodne napsat si vlastní knihovnu, by měl před tím desetkrát oběhnout barák, aby si to dobře rozmyslel. Ono to totiž není o tom ji jen napsat. Ono je potřeba ji zdokumentovat, otestovat, verzovat, donutit kolegy aby se ji naučili, dávat si pozor jestli máme dobře nadefinované API a spoustu dalších věcí.

Podle mě je jen jeden případ, kdy se vyplatí psát si vlastní knihovnu. A to v případě kdy do ní dávám kód specifický pro daného zákazníka. Například nějaké specifické výpočty, které chci sdílet mezi různými moduly, kód pro volání jeho backendu a podobně. Ale i tak je potřeba počítat s tím, že údržba takové knihovny zabere neuvěřitelné množství času a vaši kolegové z jejího používaní nebudou moc nadšení.

Takže abych to shrnul. Ať už píšete cokoliv, je dobré uvědomit si, který typ kódu to je. Pokud se jedná o business kód, tak je vše v pořádku. Pokud zrovna píšete infrastrukturní kód a není to hlavní náplní vaší práce (zdravím chlapce ze Sunu), zamyslete se nad tím, jestli je to opravdu potřeba. Zamyslete se jestli to už náhodou někdo nevyřešil za vás. Já vím, naučit se novou knihovnu je mnohem menší legrace než si ji napsat. Ale připomíná mi to jedno staré rčení, které říkalo něco v tom smyslu, že "Půl roku v laboratoři vás dokáže uchránit od deseti minut v knihovně."