Měl jsem vyrobit čtyři webové služby, jejichž odpovědi se lišily jen v pár detailech. V zásadě vypadaly takto:

<XXXResponse>
        <Version>1</m:Version>
        <RequestId>XYZ123</RequestId>
        <Result>SUCESS</Result>
        <XXXTransactionId>ABC456</XXXTransactionId>
</XXXResponse>

Místo XXX si představte různé fáze transakce. Můj problém spočíval v tom, že jsem nechtěl mít v programu čtyřikrát ten samý kus kódu pro generování odpovědi, chtěl jsem ho tam mít jen jednou. Jenže se to nedařilo, zkoušel jsem všelijaké finty s dědičností, vymýšlel jsem sofistikované wrappery, ale pořád jsem měl čtyři docela ošklivé bloky, které si byly ohromě podobné. Jediný rozdíl byl v jménu odpovědi a jménu transactionId. Ale tyto drobné rozdíly mi bránily v tom, udělat znovupoužitelný kód pro všechny webové služby.

Až mě napadla jednoduchá věc. Vždy jsem tvrdil, že generování kódu je zlo, kterému je potřeba se za každou cenu vyhnout. Ale u webových služeb jsem to tak nějak bral za dané. Znáte to, contract first přeci spočívá v tom, že začnu s návrhem XSD a podle něj píši kód. Je jen přirozené si ten kód pak nechat vygenerovat. A to je právě ta chyba. XML a Java jsou různé světy. Ano jsou si docela podobné, ale každý má jiný účel, jiné zvyklosti a jiné potřeby. Problém je, že, generovaný kód vždy odráží svůj původ.

Když generuji kód na základě XML, dostanu anemický model se kterým se mi pak špatně pracuje. Často pak skončím u toho, že mapuji vygenerované třídy na nějaké svoje vymazlené třídy a pak zase zpátky.

Když na druhou stranu generuji XSD na základě Javy, riskuji, že se s výsledným XML bude mým klientům špatně pracovat, že bude špatně rozšířitelné a podobně.

Je to podobný problém jako u objektově relačního mapování. Objekty a tabulky jsou si hrozně podobné, ale přesto je mezi nimi obrovská propast. Pamatuji si doby, kdy jsem generoval Javovské třídy na základě tabulek. Výsledek byl vždy žalostný. V poslední době jednoduše namapuji ručně psanou Javu na ručně optimalizovanou databázi a obě strany jsou spokojené.

Proč něco podobného nejde u XML? Pokud jste byli na mém lightning talku, možná si vzpomenete jak jsem si stěžoval, že v roce 2010 musím ručně mapovat XML třídy na normální třídy a zpátky. Mýlil jsem se, nemusím. Mohu udělat to samé jako s databází. Díky JAXB 2 mohu jednoduše namapovat svoje třídy na XML. Samozřejmě, v první iteraci si mohu pro jednoduchost ty třídy vygenerovat, ale pak už je ručně upravím a nikdy je negeneruji znovu.

A přesně tak jsem vyřešil svůj problém s duplicitou kódu. Ručně jsem si upravil JAXB třídy. Nejdřív jsem si vyrobil abstraktního předka všech odpovědí. To by ještě šlo zařídit úpravou XML schematu. Ale pak jsem do toho abstraktního předka přidal abstraktní metodu setTransactionId a dokonce jsem ho nechal implementovat nějaké rozhraní. To jsou koncepty, které v XML vůbec nemají smysl! Tím pádem ani nemá smysl pomýšlet na jejich generování.

Tím, že jsem udělal JAXB třídy nezávislé na XSD, jsem si zajistil, že je nemusím kopírovat do jiných interních tříd. Mohu svůj business kód udělat závislý jen na rozhraních, které XML třídy implementují. Konkrétně u mě to ušetřilo desítky řádků ošklivého kódu.

Kdybych měl dost odvahy, mohly bych dokonce i k těmto třídám přidat JPA anotace a ukládat je bez obav do databáze. Ale tak silný žaludek zatím ještě nemám.

Samozřejmě i tento přístup má své nevýhody. Asi největší je, že se mi může Java odchýlit od XML schematu. Může se mi stát, že udělám chybu, a začnu generovat nevalidní XML. Od toho ale máme testování, můžete použít třeba moji úžasnou knihovnu, která vám to pohlídá.

Zkuste se nad tím zamyslet. Generovaný kód nefungoval nikdy, vždy s ním byly jen problémy. Ale u webových služeb jsem ho alespoň já bral jako hotovou věc. Když se ho ale zbavíme, ušetříme si spoustu starostí. Náš kód může vypadat o něco víc objektově a my si užijeme mnohem víc legrace s programováním užitečných věcí.

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)]

Pokud se chcete dozvědět co to vlastně ten REST je, tak je to ta pravá kniha pro vás. Dozvíte se tam hodně o filozofii RESTu, o jeho výhodách, o tom jak takové služby navrhovat a jaké technologie k tomu používat. Většina příkladů je sice napsána v jakémsi obskurním jazyce jménem Ruby, ale pochopí je i Javista.

Kniha je napsána i docela čtivě, musíte jenom překousnout demagogii typu „REST je nejlepší, RPC je k ničemu“. Co se mi hodně líbilo je to, že jsem snad konečně pochopil principy RESTu. Je to totiž jedna z těch technologií, o kterých všichni mluví, ale málokdo ji plně rozumí. Pokusím se tu shrnout to nejdůležitější.

Dělej to jako Web

To je asi hlavní krédo RESTovaných aplikací. Web funguje, je snadno použitelný, dobře škáluje, tak proč bychom nemohli dělat webové služby úplně stejně. Je tu veliký rozdíl v tom, že normální web je určen pro lidi a webové služby pro stroje. Ale proč nepoužít stejných osvědčených principů?

Zdrojově orientované

Zdrojově orientované je můj geniální překlad pro Resource-Oriented. Znamená to, že se místo na služby, orientujeme na zdroje. Místo na slovesa typu udělej, založ, smaž se soustředíme na podstatná jména typu účet, zákazník a podobně. Je to podobné jako objektové programování, v něm bychom se měli soustředit hlavně na objekty samotné, jejich operace by z nich měli vyplývat. Stejné princip by měl platit u RESTu. Tady musím dát příznivcům RESTu za pravdu, normální WS jsou silně funkcionální, o objektech tam není ani památky. Na druhou stranu je spousta služeb, které se jako RESTové jenom tváří, ale v podstatě jsou také jen RPC.

Adresovatelnost

Další důležitý princip je adresovatelnost. Každá věc která je v daném systému důležitá, by měla mít vlastní adresu. To znamená, že každá instance objektu, by měla mít vlastní URI. Hodně to souvisí s orientací na zdroje. Každý zdroj, má svoji adresu, například takovouto http://www.exaple.com/v1/bank/client/12345. Pokud použijeme přirovnání k objektům, tak URI je podobná referenci.

Propojenost (Connectedness)

Propojenost hodně souvisí s předchozími body. Znamená to, že jako výsledek operací dostávám odkazy na další zdroje. Pokud se například zeptám na seznam klientů banky, měl bych dostat seznam jejich URI a ne jen jejich ID. Pokud bereme URI jako referenci na instanci, tak to dává smysl.

Idempotentnost

Krásné české slovo označující, to, že by mělo být možné zavolat jednu službu vícekrát, aniž by hrozilo něco ošklivého. To znamená, že operace by pokud možno neměly mít žádné vedlejší účinky. Pokud mění stav systému, měly by to dělat tak, aby se nic nestalo, pokud ho změní vícekrát. Je překvapivé, že takových operací je valná většina. Nic se nestane, pokud například vícekrát nastavím stejnou hodnotu nebo něco smažu. Jsou tu samozřejmě výjimky, ale i u těch se dá idempotentnost zařídit.

Bezstavovost

Bezstavovost je často nepochopené téma. A není se čemu divit, je to hodně matoucí. Pokusím se to ale vysvětlit. Bezstavovostí se v tomto případě myslí, že webová služba neukládá stav klienta. Rozhodně tam není žádná session. Klient může navíc volat operace v libovolném pořadí, takže by se nemělo objevovat žádné flow jak ho známe z normálního webu. Ale aplikace samotná samozřejmě stav má. Takže si samosebou pamatuje, kolik kdo má na účtu, kam chce letět na dovolenou nebo kam rád chodí do restaurace. Ale nejedná se o stav klientské aplikace, jedná se o stav zdrojů. V tom je veliký rozdíl.

Bezstavovost je docela rozumný princip, díky ní se například dobře škáluje. Bohužel často k jejímu dodržení musíme švindlovat. Občas prostě potřebujeme držet stav klientské aplikace. V RESTu proto dělají krok stranou a prohlásí stav klienta za stav systému. Takže když potřebují uložit obsah nákupního košíku, řeknou, že to není stav klienta, ale stav aplikace. Nákupní košík je vlastně takový zdroj, jehož stav aplikace naprosto přirozeně drží. Takový košík má pak svoji URI, své operace a je to prostě normální zdroj. Problém vyřešen. Tedy kromě té škálovatelnosti, s ní jsem na tom úplně stejně jako kdybych používal session. (Kvízová otázka. Jak zajistit, aby přidání položky do nákupního košíku bylo idempotentní?)

No zbytek z těch asi 400 stránek tu opisovat nebudu. Radši napíšu proč se budu držet dál normálních (tlustých) webových služeb.

V první řadě se mi nelíbí úzká vazba na HTTP. To je jedna z věcí, která mi ještě nedošla, takže budu rád když mi ji někdo vysvětlí. Na jedné straně čtu, že REST je na HTTP úplně nezávislý. Na druhé straně, je ale REST s HTTP neuvěřitelně úzce spjat. Chcete-li změnit stav zdroje, máte použít HTTP PUT, chcete-li ho smazat, použije HTTP DELETE, chcete zjistit jeho stav, použijte GET. Nastane chyba? Dostanete ten a ten HTTP chybový kód. Tak je to závislé nebo ne? Mě spíš připadá že jo.

Dalším důvodem, proč zatím zůstanu u klasického ošklivého SOAPu je to, že mi vyhovuje. Já prostě nepíši aplikace, které jsou podobné webovým stránkám. Píši věci, které jsou svoji podstatou spíše procedurální než objektové. Navíc mi vyhovuje to, že existuje něco jako WSDL, které je sice ošklivé jak noc, ale které i přes své mouchy funguje. Ano pro REST máme WADL, ale že by byl široce rozšířen se říci nedá.

Také mi vyhovuje, že v SOAPu jsou metadata součástí zprávy a ne protokolu, kterým se zpráva posílá. Prostě mi to připadá bezpečnější. Když volám webovou službu tak volání bohužel často přejde přes několik JMS front a pár HTTP připojení. Takže se na to radši dívám tak, že posílám XML dokument, který přes nějaké složitosti snad doputuje k svému adresátu.

Tím rozhodně nechci říci, že je REST špatný. Pokud bych vystavoval webové služby pro něco, co má svůj ekvivalent ve webové aplikaci, asi bych nad RESTem vážně uvažoval. Protože se ale pohybuji v jiném světě, tak je moje volba jiná. To mi ale nebrání se poučit a pár fint od RESTu okoukat.

Některé části aplikace se ale testují dost špatně. Většinou jde o „okraje“ aplikace jako například JSP, komunikaci s databází, volání webových služeb nebo proprietárního kódu. Jinými slovy, pokud je testovaný kód používaný pouze mým kódem, testuje se docela dobře. Pokud je ale na rozhraní mezi mnou a uživatelem, databází nebo něčím jiným, testování se komplikuje.

Proto je důležité psát takové části co nejtenčí. Co to znamená? Vaše JSP stránky by měly být co nejjednodušší, DAO vrstva by neměla obsahovat žádnou logiku a knihovny které používáte by měly být co nejméně invazivní.

Pokud ale tyto věci na periferii chci otestovat, musím se často uchýlit k funkčním testům. K testům, které jsou sice automatizované, ale které vyžadují běžící aplikační server, Spring kontext nebo třeba databázi v paměti jako HSQL. Takové testy jsou obvykle komplikovanější a také jejich spouštění trvá výrazně děle.

Podobný problém mívám i s testy volání webové služby. Samosebou mám toto volání zapouzdřeno ve speciální vrstvě, ale i tu bych rád otestoval. Kód často vypadá podobně jako tento.

public List<Flight> getFlights(String origin, String destination) {
	//prepare request
	GetFlightsRequest request = new GetFlightsRequest();
	request.setFrom(origin);
	request.setTo(destination);
	request.setServiceClass(ServiceClass.ECONOMY);
	request.setDepartureDate(Calendar.getInstance());
	//call the service
	GetFlightsResponse response = (GetFlightsResponse)webServiceTemplate.marshalSendAndReceive(request);
	//convert response
	return response.getFlight();
}

Na začátku musím vyrobit dotaz. Obvykle musím naplnit nějaký objekt vygenerovaný XML mapovacím nástrojem. Pak zavolám službu a její odpověď musím zase převést na něco čemu rozumí moje aplikace.

Jak něco takového otestovat? Samozřejmě to jde, jenom mě to vůbec nebaví. Nejdřív potřebuji otestovat, že jsem správně vytvořil dotaz. Pokud to testuji klasicky, tak ten test vypadá podezřele stejně jako kód samotný. Hrozně mě nebaví testovat, jestli když nastavím datum odletu, tak je opravdu dobře nastaveno. Navíc je to hrozně odtrženo od požadavků. Nikdo po mě přeci nechce, abych plnil nějaký hloupý vygenerovaný objekt. Chtějí po mě, abych vygeneroval XML. Věřím sice, že XML mapovací knihova funguje správně, ale pořád mám pocit, že by bylo pěkné to otestovat nějak lépe.

Pak by bylo dobré otestovat, jestli opravdu volám tu webovou službu. Další trapný a nudný test. Nastavím mock a ověřím, jestli se opravdu zavolá. Nůůůda.

No a pak mě čeká otestovaní, jestli se dobře konvertují data z odpovědi do objektu, který má často podobnou strukturu. Další nuda.

Dá se to dělat lépe? Samozřejmě. Za pomocí našeho skvělého patentovaného přípravku, který vyčistí všechny vaše testovací skvrny bez narušení podstaty látky. Můžeme si totiž připravit požadovaný dotaz i odpověď jako XML, použít naši speciální knihovnu a napsat test například takto

@Test
public void testGetFligts()
{

	//create control
	WsMockControl mockControl = new WsMockControl();
	//teach mock what to do and create it
	WebServiceMessageSender mockMessageSender = mockControl.expectRequest("PRG-DUB-request.xml").returnResponse("PRG-DUB-response.xml").createMock();
	webServiceTemplate.setMessageSender(mockMessageSender);

	//do the test
	List<Flight> flights = client.getFlights("PRG","DUB");
	assertNotNull(flights);
	assertEquals(1, flights.size());
	assertEquals("PRG",flights.get(0).getFrom().getCode());
	assertEquals("DUB",flights.get(0).getTo().getCode());

	//verify that everything was called at least once
	mockControl.verify();
}

Krásné, jednoduché a elegantní. Popis XML dat je realizován v k tomu nejvhodnějším jazyce - v XML. Test mi i automaticky ohlídá, že jsem opravdu službu zavolal. A to nezmiňuji spoustu dalších vymožeností, které zde pro jistotu nezmiňuji, abyste ohromením neomdleli.

Pokud jste tedy zůstali při vědomí vězte, že to všechno je k mání zdarma, na adrese http://javacrumbs.net/spring-ws-test/. Jenom račte prominouti, že dokumentaci ještě nestačila býti plně dohotovena. Naše dokumentační oddělení na ní pilně pracuje tudíž se lze domnívati, že bude dohotovena v nedaleké budoucnosti. Prozatím račte vzíti v potaz příklad použití, který Vám návod jistojistě poskytne.

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.

	/**
	 Adds positive numbers. If one of the parameters is negative,
	 IllegalArgumentException is thrown.
	 * @param a
	 * @param b
	 * @return
	 */
	public int addPositive(int a, int b)
	{
		if ((a<0) || (b<0))
		{
			throw new IllegalArgumentException("Argument is negative");
		}
		return a+a;
	}

No coverage - wow, that's interesting

The fact that some piece of code is not covered at all is really interesting. It either means, that we have to start writing tests at once or that the piece of code has to be deleted. Either way we know that we should do something. Moreover, we know exactly what to do. For example, we can start with the following test.

	@Test
	public void testAddition()
	{
		assertEquals(2, math.addPositive(1, 1));
	}

It will get us partial coverage like this

Partial coverage - cool, I know what to test next

If I have partial coverage, I can see what other tests I am supposed to write. In our example I see that I have to test what happens if I pass in a negative numbers.

	@Test(expected=IllegalArgumentException.class)
	public void testNegative1()
	{
		math.addPositive(-1, 1);
	}
	@Test(expected=IllegalArgumentException.class)
	public void testNegative2()
	{
		math.addPositive(1, -1);
	}

Total coverage - I have no clue

Now we have 100% coverage. Well done! Unfortunately, I have no clue what to do next. I have no idea if I need to write more tests, I do not know if I have complete functional coverage. I have to stop looking at the coverage and I have to start thinking. You see, when the coverage was low it gave me lot of useful information, when it's high I am left on my own. For example I can think hard and come up with following complex test scenario.

	@Test
	public void testComplicatedAddition()
	{
		assertEquals(3, math.addPositive(1, 2));
	}

Please note, that the coverage was already 100% before I have written the test. So one more test could not make it higher. Nevertheless the test actually detected a bug that was there from the beginning. It means that 100% code coverage is not enough, we have to aim higher. We should care about functional coverage and not about code coverage!

That's also one of many reasons why we should do test driven development. Or at least test first development. If we write the tests before the code, we are forced to think from the beginning. In TDD we do not care about the coverage. We just think about the functionality, write corresponding tests and then add the code. Total coverage is automatically achieved.

In the opposite situation, when we write the code first and then add the tests as an afterthought, we are not forced to think. We can just write some tests, achieve the target coverage and be happy. Test coverage can be really deceitful. It can give us false sense of security. So please remember, test coverage is a good servant but a bad master.

Again, I am scratching my own itch. I am quite test infected and I have needed something that allows me to write functional tests of my application without having to depend on an external server. Until now, you basically had two options. This first one is to test WS client application using plain old JUnit together with a library like EasyMock. But usually this test are quite ugly and hard to read. Moreover this type of tests does not test your configuration. The second option is to create a functional test that calls an external mock service. But this solution requires you to have two JVM, its configuration is complicated and error prone.

I have been looking for something in between, for something that would allow me to write functional tests using JUnit and would be able to run in the same JVM as the test. Unfortunately I have not been able to find anything similar.

That's the reason why I have created Spring WS Test project. It's quite simple and easy even though I had to spent lot of my evenings getting it into a publishable state.

Basic configuration looks like this

<beans ...>
  <!-- Creates mock message sender -->
  <bean id="messageSender" class="net.javacrumbs.springws.test.MockWebServiceMessageSender"/>

  <!-- Injects mock message sender into WebServiceTemplate -->
  <bean class="net.javacrumbs.springws.test.util.MockMessageSenderInjector"/>

  <!-- Looks for responses on the disc based on the provided XPath -->
  <bean class="net.javacrumbs.springws.test.generator.DefaultResponseGeneratorFactoryBean">
     <property name="namespaceMap">
         <map>
            <entry key="soapenv"
                value="http://schemas.xmlsoap.org/soap/envelope/"/>
            <entry key="ns"
                value="http://www.springframework.org/spring-ws/samples/airline/schemas/messages"/>
         </map>
     </property>
     <property name="XPathExpressions">
         <list>
             <value>
                 concat(local-name(//soapenv:Body/*[1]),'/default-response.xml')
             </value>
         </list>
     </property>
 </bean>
</beans>

Here we have MockWebServiceMessageSender that replaces standard Spring WebServiceMessageSender. The replacement is done by MockMessageSenderInjector. The only other thing you have to do is to define ResponseGenerator. It's main purpose is to look for files in you test classpath and return them as mock responses.

Of course it has to decide, which file to use. By default a XPath expression is used to determine the resource name. In our example it is concat(local-name(//soapenv:Body/*[1]),'/default-response.xml'). It takes name of the payload (first soap:Body child) and uses it as a directory name. File “default-response.xml” from this directory is used as the mock response. Simple isn't it?

Of course you can define more complicated XPaths, you can use XSLT templates to generate your responses, you can validate your requests etc. More details can be found in the documentation.

Now I am looking for some end-user feedback. So please, if you are using Spring WS on the client side do not hesitate and test it. It should be stable enough to be used although there might be a bug here and there.

Dnes jsem si řekl, že je ideální počasí na to, vyzkoušet jestli se dá sta procent dosáhnout. Povedlo se mi to během dopoledne a nyní bych se chtěl podělit o své zkušenosti.

Pracuji na jednom menším projektu, který v podstatě jen zpracovává REST volání a přeposílá je pomocí SOAP na další systémy. Není to nic složitého, ale není to ani žádná trivialita. Prostě ideální kandidát na pokusy. I před tím, než jsem se rozhodl dosáhnout vytoužené mety, jsem se snažil unit testy dělat poctivě. Jen občas jsem něco neotestoval s tím, že to je příliš triviální na to, abych se patlal s testem. Většinou jsem ale svoji lenost ovládl. Proto mě překvapilo, že moje pokrytí testy bylo něco kolem 60%.

Začal jsem pátrat po příčinách a zjistil jsem, že nejsem tak svědomitý, jak jsem si myslel. Narazil jsem například na neotestovanout třídu, kterou jsem jen odněkud zkopíroval Fůůůůůj. Ale občas je to potřeba. Znáte to, potřebujete něco podobného co umí nějaká metoda ve Springu, jenom je to potřeba trochu ohnout, má to implementovat jiné rozhraní a navíc je to v tom Springu private. Tak to vezmete, zkopírujete a trochu přiohnete. Pokud se pokoušíte o stoprocentní pokrytí, musíte to i otestovat. Pokud se spokojíte s pokrytím nižším, je velice lákavé si říci, že to už je vlastně otestovaný kód, tudíž není potřeba testovat. Ještě jednou fůůůj. Ještě že se stydím jenom před děvčaty. Nakonec jsem byl rád, že jsem tu zkopírovanou metodu musel otestovat. Díky tomu jsem se nad ní pořádně zamyslel a zkrátil ji na polovinu.

Pak jsem ještě napsal pár testů na metody, které jsem nepovažoval za hodné testu. Potěšilo mě, že jsem narazil jenom na jednu metodu, kterou jsem evidentně netestoval, protože by to bylo moc práce. Díky své nové stoprocentní mantře jsem se donutil otestovat i ji. Nakonec to ani moc nebolelo, jenom jsem se musel ponořit do vnitřností Spring-WS abych zjistil jak nejlépe vytvořit instanci jednoho rozhraní (SoapMessage). Alespoň jsem se něco naučil. Pak už zbývaly jen zapeklitější věci.

Get a Set metody
Jedním ze zádrhelů byly get metody. Poté co jsem otestoval všechen kód, který něco dělá, zbyla mi jedna skupina metod, které prostě v žádném testu nebyly potřeba. Byly to get metody u Spring bean. Když totiž potřebuji pomocí Springu něco injektnout, automaticky vygeneruji set a get metody. A to i když používám autowiring přímo do polí. Set metody využívám právě v unit testech. Ukázalo se, že pokud není v testu set metoda použita, je v tom testu něco špatně. A to bez výjimky. Buď to, co nastavuji, není vůbec potřeba nebo netestuji funkcionalitu, která danou hodnotu využívá. Takže si prosím zapamatujte:

Pokud není otestována set metoda, je něco špatně.

Ale zpátky ke get metodám u Spring bean. Ty pro test potřeba nejsou. Ony totiž nejsou potřeba vůbec. Jenom jsem měl hrozný psychický problém s tím je smazat. Pořád jsem si říkal, že je tam nechám, co kdyby byly potřeba. Co kdyby někdo potřeboval vědět, jak je daná třída nakonfigurována atp. Ale pak mě stoprocentní mantra donutila je smazat a myslím, že si na ně nikdo nevzpomene. Jenom je to divné mít set bez getu. Kdybych ty get metody opravdu někdy potřeboval, třeba kvůli JMX, tak je prostě přidám a otestuji.

Equals
Dalším špekem je equals metoda. Pokud byste náhodou nevěděli jak vypadá, tak vám ukáži, to co mi normálně generuje Eclipse

	public boolean equals(Object obj) {
		if (this == obj)
			return true;
		if (obj == null)
			return false;
		if (!(obj instanceof Person))
			return false;
		Person other = (Person) obj;
		if (firstname == null) {
			if (other.firstname != null)
				return false;
		} else if (!firstname.equals(other.firstname))
			return false;
		if (secondname == null) {
			if (other.secondname != null)
				return false;
		} else if (!secondname.equals(other.secondname))
			return false;
		return true;
	}

A teď si představte jak otestovat všechny možnosti takového krasavce. Abyste dosáhli plného pokrytí, museli byste napsat cca devět testů. To vše kvůli vygenerovanému kódu. K tomu mě nikdo nedonutí. Zkusil jsem použít EqualsBuilder, ale moc jsem si nepomohl. I s jeho pomocí jsou tam asi čtyři kombinace, které je potřeba otestovat. Mumlaje si pod vousy „sto procent, sto procent“ jsem se zeptal pana Googla a ten mě navedl na EqualsTester. Problém vyřešen, jsem zas o krok blíže k vytouženému cíli.

Nemožná výjimka
Zbývala mi jen jedna úplně poslední past nastražená na mě pány ze Sunu:

	private byte[] toByteArray(String data)
	{
		try {
			return data.getBytes("UTF-8");
		} catch (UnsupportedEncodingException e) {
			LOG.error("Can not happen",e);
			throw new RuntimeException(e);
		}
	}

Abych dosáhl kompletního pokrytí, musím otestovat i catch blok. Ten je bohužel dosažitelný jen pokud vaše JVM nepodporuje UTF-8. Vzhledem k tomu, že by pak JVM nesplňovalo specifikaci není tato situace moc pravděpodobná. Bohužel, tím pádem ani otestování není moc snadné. Nakonec jsem musel kód změnit takto:

	private static final Charset UTF8 = (Charset)Charset.availableCharsets().get("UTF-8");

	private byte[] toByteArray(String data)
	{
		return data.getBytes(UTF8);
	}

Není to moc elegantní, ale alespoň se mohu utěšovat tím, že je to výkonově efektivnější. Pokud znáte lepší cestu, podělte se o ni, rád se něco přiučím.

A to je vše, dosáhl jsem stoprocentního pokrytí. Zde mi samozřejmě hrálo do karet, že jsem nemusel řešit připojení k databázi. To bych se musel uchýlit k mockování JDBC template nebo k mé oblíbené in-memory databázi ve spojení s JPA. To už by sice nebyl unit test, ale třeba by to nikdo nepoznal.

Takže mám stoprocentní pokrytí, co mi to dalo? Donutilo mě to otestovat věci, na které bych se pravděpodobně jinak vykašlal. U některých z nich jsem byl rád, že jsem je nakonec otestoval. Přivedlo mě to k lepšímu kódu. Potěšilo mě, že jsem nemusel psát žádné nesmyslně testy, jenom kvůli pokrytí. Toho jsem se ze začátku trochu bál. Samozřejmě nesmím usnout na vavřínech. To že mám kód zcela pokryt neznamená, že v něm není chyba. Těch tam naprosto jistě ještě hodně zůstalo. Nicméně mám z toho docela dobrý pocit, myslím si, že 100% je docela dobrá laťka. Na jednu stranu vám nedovolí vymýšlet si výmluvy, proč něco netestujete, na stranu druhou se ukázala jako dosažitelná. Proto se příště jako správný úderník pokusím pokrýt na 105%.

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ší.