Dagblog

Pět a jeden absurdní důvod proč nemáme v JDK podporu JSON

2012-05-28T15:24:00.000+02:00

Pokaždé když pracuji v Jave s JSON mám pocit, že jsme stopadesát let za opicemi. Většinou sice používám skvělou knihovnu Jackson (pozor nejedná se o pohrobka ikony pop music Michaela Jacksona), ale i její použití je jako jíti s kanonem na vrabce. Mám úplně jednoduchou strukturu {"l":"0","u":"1","v":1338207547}, kterou bych rád deserializoval do mapy. Opravdu nerozumím tomu proč už v standardním JDK Javy neexistuje stupidní jednoduché API, které mi to umožní. Napadá mě několik vysvětlení.

Někoho rajcuje představa 100MB WARu k jehož dosáhnutí není potřeba vytvářet složitou aplikaci, ale vývojář si vystačí s pár základními problémy.
Tvůrci Apache Jakarta Commons nevědí co dělají. Nicméně to nebrání většině aplikací používat právě jejich knihovny.
JCP proces pro rozšiřování Javy je úplně k ničemu, neboť přidávání nových a potřebných API nefunguje. Mimochodem jak dlouho už čekáme na nové API pro práci s datumy?
Nevylučuji ani možnost, že moje požadavky na něco čemu se říká JDK, tedy standardní vývojový kit, jsou značně přemrštěné a všichni si posledních deset let vystačíme přibližně s jedněmi a těmi samými prostředky.
Práce na JSON je pro mě z nepochopitelných důvodů vázaná na Java EE. Touto logikou by ovšem v JDK nemohl skončit například HTTP server a nebo JAXB. O nesmyslech typu embedované databáze ani nemluvě.
JSON je technologie, o které nikdo v Oracle neslyšel. Případně si jí spojuje s konkurencí v podobě JavaScriptu.

Opravdu tomu nerozumím. Přidání nových API a rozšíření JDK je totiž oproti změnám syntaxe jazyka věcí zpětně kompatibilní. Můžeme se zde točit na faktu, že i nafouknuté JDK by bylo problém, ale z toho důvodu přece voláme po jeho modularitě. Vlastně je to takový deadlock a teď se pomalu čeká na to kde to vyhnije.

Tam kde je možné Javu inovovat za cenu menšího rizika se to neděje. Namísto toho se její autoři pouští to riskantních podniků změny syntaxe.

Pozor na minor updaty Javy

2012-05-25T09:47:00.002+02:00

Do Javy 7u6 (update 6) a Javy 8 se chystá změna hashovacího algoritmu pro stringové klíče do všech standardních implementací java.util.Map (HashMap, Hashtable, LinkedHashMap, WeakHashMap, ConcurrentHashMap). Tvůrci si slibují, že díky těmto změnám sníží riziko kolizí a tím pádem nebude docházet ke zpomalení. Více si můžete ostatně přečíst v oznámení této změny. To co je na celé téhle záplatě zajímave je následující poznámka.

The iteration order of keys, values and entries for hash-based maps where the new algorithm has been invoked will vary for each HashMap instance. While the Java SE Map documentation makes no promises that iteration order of items returned from Maps will be consistent, developers should check if their applications have incorrectly created a dependency on the iteration order of Map entries, keys or values.

Přestože to je explicitně zmíněné v kontraktu Mapy, stejně bude existovat, a to bych se klidně vsadil, hromada kódu který třeba i nepřímo závisí na pořadí, v jakém se budou klíče vracet. Z mého pohledu je tohle zpětně nekompatibilní změna, ačkoliv skrytá a efektivní pokud dojde k naplnění určité podmínky (možná o to hůře protože to neodhalí standardní testy), a neměla jít rozhodně do updatu Javy 7. Osobně už jsem několikrát nepěkně sedl na lep vlastní slepé víře v to, že změny v updatech Javy jsou kompatibilní a nehrozí žádné riziko, a dal svolení k provedení updatu, protože nám přece nic nehrozí... Zvedám proto v tomhle případě varovný prst. Pozor na tenhle update, chyby v kódu se mohou projevit za velmi specifických podmínek a tedy velmi zákeřně.

Spring framework tréninkové materiály

2012-05-13T20:23:00.004+02:00

Tréninkové materiály k mému školeni Spring framework, jsou k dispozici na GitHubu. Prezentace k jednotlivým částem jsou odlinkované přímo z README.md a najdete je i na mém SlideShare profilu.

CZ Podcast 64 - iOS, iPhone, iPad

2012-05-09T22:53:00.002+02:00

S tím zvukem to zase není úplně ono, ale jinak se nám s panem velkostatkářem Filem povedl dost luxusní podcast s týpkama z Inmite o vývoji pro iOS. Poslechněte si to a dejte nám vědět. Příště se bude točit buďto o hrůzostrašných historkách z korporací, abychom zase najeli na méně vážnou notu. Nebo budeme mít, a teď pozor, low level téma a podiváme se na zoubek hackování mobilních a webových aplikací. Slovy klasika: jsme otevřeni všem možnostem přátelé.

MongoDB pro Java vývojáře

2012-05-03T10:50:00.001+02:00

Na včerejším setkání JBoss User Group v Brně jsem měl prezentaci na téma MongoDB. Slajdy najdete o kousek níže, rád bych ještě vypíchnul pár myšlenek, které zazněly, ale ze slajdů nemusí být úplně patrné.

NoSQL není jenom o velkých data. Speciálně MongoDB výrazně redukuje složitost persistentí vrstvy. Rozdíl mezi světem dokumentů a modelu tříd je mnohem menší než je to v případě relačních databází. Pro většinu aplikací, které v uvozovkách vezmou data a pošlou je na výstup, nepřináší relační databáze žádný benefit (kromě toho, že jste s ní pracovali posledních deset let ;-)
Při použití MongoDB a obecně NoSQL řešíte jiný typy problému, než které jste zvyklí řešit v relačním světě. Na druhou stranu vám odpadají problémy, které souvisí s managementem persistentního kontextu.
MongoDB není náhrada relačních databází, je to vhodný doplněk nebo alternativa chceteli. Relační databáze dávají perfektní smysl pro určité typy úkolů.
Smiřte se s tím, že občas povede návrh dokumentů k tomu, že budete mít redundantní data. Jinými slovy rovnou zapomeňte na nějakou normalizaci.

MongoDB for Java Developers

View more presentations from Roman Pichlik

CZ Podcast 63 - Mezinárodní spolupráce

2012-04-22T23:01:00.003+02:00

V tomto díle jsme se rozhodli v trochu uvolněné atmosféře probrat téma mezinárodní spolupráce. Přece jenom v IT dochází k tomu, že se práce v mezinárodním prostředí stává normou. Jaké jsou jednotlivé národy, ke komu máme my čechoslováci blíž a ke komu naopak dále. Hostem tohoto dílu byl Jan Tajzich ze společnosti Vendavo CZ.

Technologie a netechnická kritéria

2012-04-08T15:38:00.000+02:00

Když jsem v předchozím článku podle některých totálně sepsul Javu, nezazněla od nikoho poznámka na téma komunita a nabídka pracovního trhu, doba nutná k zapracování nových vývojářů. Troufám si tvrdit, že na vývojářskou pozici v Jave jsme schopni do měsíce najít kvalitního člověka a za další měsíc jej efektivně zapracovat. To sice nic nevypovídá o tom, že Java je technologicky na špičce, ale vypovídá to cosi o tom, že existuje obecně akceptovaný způsob vývoje. To velmi usnadňuje spolupráci všech vývojářů neboť máme postupy, které se jenom mírně liší firmu od firmy.

Pokud pracujete s velmi novými a neprozkoumanými technologieme a nebo jdete až na dřeň (náš případ použití JavaScript - tlustý klient MVC, vlastní grafová knihovna), rovnou počítejte s tím, že obtížné bude jenom ty vývojáře najít. Neexistující a nebo malá komunita vám nenabídne skoro žádné možnosti ty vývojáře oslovit, případně si budovat pozici. Platí li teze Joela Spolskeho:... nejlepší lidé práci mají a rozhodně nechodí po pohovorech, pak si můžete rovnou najmout Sherlocka Holmese, aby vám je našel.

Samozřejmě vždycky se můžete pokusit vychovat si vývojáře z nováčků. To má ovšem zásadní nevýhodu v tom, že se to projeví v produktivitě celého týmu, a navíc nikdy nemáte jistotu, že se to povede. Jedná se o klasický kompromis mezi krátkodobým a dlouhodobým přínosem.

Na technologie můžete nahlížet několika různými pohledy a tyto netechnická kritéria mají skoro stejnou váhu jako ta technická.

p.s. Kdybych si měl vybrat technologii, pomocí které budu dělat klasické podnikové aplikace, šáhnul bych bez váhání po Jave. A to jenom z toho důvodu, že velmi snadno najmu lidi.

CZ Podcast 62 - Nette framework

2012-04-03T20:20:00.000+02:00

V díle 62. jsme vyzpovídali nestora české PHP scény a autora webového frameworku Nette Davida Grudla. Kromě technických aspektů jsme se bavili o tom jak Nette vznikalo, kdo ho používá, jak se David dostal k programování, no prostě klasické czpodcastí interview. Tímto bychom vás chtěli zároveň pozvat na natáčení dalšího dílu s pracovním označením Vývoj v multikulturním prostředí aka Asijská spolupráce, které proběhne 19.4.2012 od 18:30 ve firmě Vendavo CZ v Praze. Další detaily budou oznámeny na našem Twitter účtu. Pokud máte nějaké otázky, náměty, postřehy a komentáře sem s nimi do diskuze a nebo na náš email czpodcast zavinač gmail.com.

Stavíme infrastrukturu kolem MongoDB - model

2012-03-31T22:11:00.000+02:00

V poslední době jsem strávil nějaký čas psaním a vymýšlením konceptu persistentní vrstvy, nástrojů a jejich implementace, který nám umožní ukládat JSON dokumenty do NoSQL databáze MongoDB. Dokumenty i kolekce nemají žádné schéma. To má za následek, nebo alespoň u nás mělo, a divil bych se kdyby to někdo začal používat nějak sofistikovaněji, že moc nepřemýšlíte o struktuře dokumentů a prostě je ukládáte jak se vám zrovna hodí. To je velice příjemné a nějaký čas s tím vydržíte. Problém nastane ve chvíli kdy potřebujete ty dokumenty začít zpracovávat automaticky, například chcete udělat zálohu dokumentů vztahujících se k určité entitě v systému a nebo potřebujete zjistit, že odkazované dokumenty existují. Jinými slovy bez modelu popisujícího dokumenty, kolekce a jejich vztahy se neobejdete. Samozřejmě pokud si to nechcete dělat ručně v kódu pro každý typ dokumentu.

My jsme si data uložená v MongoDB popsali jednoduchým modelem reprezentovaným JSON dokumentem, který je sám v MongoDB uložený. Tento model slouží jednak pro nástroje, které dělají servisní operace, jako zálohy a jejich obnovu, validaci dat, čištění pohrobků apod.m a zároveň jím chceme řídit (zatím není implementováno) vlastní persistentní vrstvu, kterou ukládáme dokumenty.

Struktura modelu vypadá následovně.

DocumentStorageModel reprezentuje vlastní model. Má verzi, která nám umožňuje otestovat kompatibilitu dat s ním asociovaných. Typickým příkladem je záloha, ze které se snažím obnovit data, a rád bych se přesvědčil, že aktuální data a tedy i runtime je kompatibilní, a nepotkají mě nepříjemnosti po jejich obnovení. Verzí se zároveň řídí například migrace dat.

DocumentStorageModel obsahuje seznam kolekcí Collection. Každá kolekce má jméno, pod kterým existuje v MongoDB. Zároveň má dokumentaci Documentation. Ta obsahuje lidský srozumitelný popis toho, jaký typ dokumentu je v ní uložený. Dále release, ve kterém vznikla a URI template, pod kterým je vystavený na REST API. Záróveň může mít kolekce asociovaný ToolHints. Ten umožňuje popsat kolekci z pohledu nástrojů pro vytváření a validaci její definice přímo v MongoDB. Například dočasná data se vkládají do takzvané Capped collection, která automaticky odmazává nejstarší vložené dokumenty. Díky těmto hintům je možné ověřit, že je kolekce skutečně tímhle způsobem zkonfigurovaná.

Dokumenty a jejich struktura je popsaná v DataDefinition. Pro jejich validaci je možné definovat RelaxNG schéma (více o tom psal Lukáš Křečan v článku Converting JSON to XML). To se dá použít jednak v persistentni vrstvě pro validaci při změnách/zápisu a zároveň i pro verifikaci například po migraci dat.

Samostatnou kapitolou jsou relace. Šťastnější pojmenování by bylo reference v tomhle případě, aby to v člověku nevyvolávalo pocit, že se snažíme modelovat svět relačních databází. Dokumenty mezi sebou odkazujeme pomocí URI referencí. Máme celkem tři druhy relací: sama na sebe (SelfDocumentRelation), interní na jiný dokument v MongoDB (InternalDocumentRelation) a externí na dokumenty/entity uložené mimo náš systém (ExternalDocumentRelation). Každá relace má u sebe dva atributy cestu k fieldu, ve kterém je v dokumentu uložena a URI template, pomocí které je jí možné rozložit na jednotlivé segmenty. To se používá ve chvíli kdy potřebujeme zjistit příslušnost dokumentu k projektu nebo uživateli. Jednoduchým rozpársováním pomocí URI template víme konkrétního uživatele nebo projekt, ke kterému se dokument vztahuje.

Ukázka modelu

{
       "documentStorageModel":{
          "collections":[
             {
                "collection":{
                   "name":"subscriptions",
                   "affiliation":"PROJECT",
                   "resourceUriTemplate":"/gdc/projects/{project}/users/{user}/subscriptions/{subscription}",
                   "documentation":{
                      "description":"Contains notification subscriptions for given user in given project",
                      "releaseVersion":"R59"
                   },
                   "dataDefinition":{
                      "self":{
                         "selfDocumentRelation":{
                            "path":"subscription.meta.uri",
                            "uriTemplate":"/gdc/projects/{project}/users/{user}/subscriptions/{subscription}"
                         }
                      }
                   }
                }
             }
             ... další kolekce
             ],
             "version":"1.0.0"
        }
    }

Ukázka dokumentu popsaného modelem

{
     "subscription" : {
      "channels" : [
       "/gdc/account/profile/xxx/channelConfigurations/4f4b7e5ce4b0413360a0c4d5"
      ],
      "meta" : {
       "title" : "Test subscription",
       "author" : "/gdc/account/profile/xxx",
       "category" : "subscription",
       "updated" : "2012-02-27 14:00:12",
       "created" : "2012-02-27 14:00:12",
       "uri" : "/gdc/projects/FoodMartDemo/users/xxx/subscriptions/4f4b7e5ce4b0413360a0c4d7"
      },
      "message" : {
       "template" : {
        "expression" : "Hello World"
       }
      },
     }
    }

Z modelu je vidět, že v dokumentu by měl být field na cestě subscription.meta.uri a jeho hodnota by měla odpovídat URI template /gdc/projects/{project}/users/{user}/subscriptions/{subscription}. Z instance dokumentu je vidět, že tomu jak je viz /gdc/projects/FoodMartDemo/users/xxx/subscriptions/4f4b7e5ce4b0413360a0c4d7. Jednoduchou introspekcí této URI reference vidíme, že náleží k projektu FoodMartDemo.

Závěr

Cílem tohoto článku bylo nechat vás trochu nahlédnout do toho kam se v GoodData ubírá naše práce s NoSQL databází MongoDB. Potřeba modelu popisujícího data se ukázala jako nutnost. Na druhou stranu to není specifikum NoSQL světa, protože k podobné řešení, jsme již používali v HP SOA Systinet klasickou relační databází. Pokud máte podobné zkušenosti, a nebo naopak používáte jiný způsob k popisu dat a řízení nástrojů pro práci s nimi, určitě se podělte v komentářích pod tímto článkem.

Java s prstem na tepu doby

2012-03-29T10:02:00.000+02:00

Java a celý její ekosystém čelí zásadním a novým výzvám, které jsou způsobeny posunem v oblasti mobilních zařízení, objemu zpracovaných dat i uživatelů. Ruku v ruce s tím jde vzájemná integrace heterogeních aplikací. Klíčová otázka zní, jakým způsoben je platforma Java, schopna na tyto výzvy reagovat a zároveň si zachovat statut klíčové technologe. Tento článek nemůže a ani nemá ambice na tuto otázku odpovědět, ale pokusí se přiblížit hlavní výzvy a možnosti, kterými se Java může ubírat.

Úkrok stranou

Prvotní a správná otázka je: proč se to všechno děje. Jedna z odpovědí leží pro programátory těžko uchopitelné a o to více ignorované škatulce s nápisem Business. Je historicky prokazatelné, že pouze pár programátorů (nedá moc velkou námahu si domyslet jejich jména) toto pochopilo a dokázalo úspěšně propojit technologickou výhodu s úspěchem komerčním. To je zároveň důvod, proč v čele většiny technologických společností nestojí programátor, ale někdo kdo dokázal spojit oba světy. Každý člověk, bez ohledu na vzdělání, pracovní pozici či věk, má inovativní nápady. Ovšem pouze menší část lidí dokáže začít tyto nápady realizovat. Ještě menší část těchto lidí na nich dokáže kontinuálně pracovat a dále je rozvíjet. A ta nejmenší část lidí je dokáže přetavit v úspěch [1].

První klíčovou veličinou je čas, za který se podaří nápad uvést do stavu, který je možné zpeněžit [2], bez ohledu na fakt jestli se jedná o jednotlivce nebo firmu. Druhou klíčovou veličinou jsou náklady, které s tím jsou spojené, provozní i startovací. Jedním ze způsobů, kterým lze výrazně redukovat čas nutným pro uvedení na trh, představuje volba správné technologie a platformy. Náklady lze do jisté míry redukovat pronájmem bez ohledu na to jestli se jedná o svět virtuální a nebo ten fyzický.

Kromě faktoru času a nákladu hrají přímou roli i veličiny, které není možné ovlivnit. Podle statistik World Internet Usage používalo Internet na konci roku 2000 celkem 360 985 492 uživatelů, ke konci roku 2011 je to již uživatelů 2 095 006 005 [3]. Podle typu operací je možné si udělat celkový obrázek o celkovém objemu dat. Za rok 2010 například služba Flickr hostovala 5 000 000 000 obrázků. Za ten samý rok bylo na sociální síti Twitter poslánu 25 000 000 000 zpráv takzvaných tweetů [4]. Podle odhadů firmy Cisco bude v roce 2015 připojeno 15 000 000 000 zařízení [5]. Zjednodušeně řečeno, velké množství uživatelů používá velké množství zařízení a produkuje velké množství dat. Čísly těžko uchopitelný údaj představuje i změna používání webu. Od prohlížení statických stránek nastal výrazný posun k dynamickému chování a webovým aplikacím. Tato změna je označována jako Web 2.0.

Výše zmíněné údaje jsou ve velké míře příčinou, a následkem je zrod přístupů či technologií jako Cloud computing, NoSQL databází nebo HTML 5. Tyto technologie zpětně způsobily a způsobují částečnou změnu architektury aplikací, a v neposlední řadě přímo ovlivňují jakým způsobem se aplikace samotné vyvíjí. Jestliže v polovině devadesátých let převládala dvouvrstvá architektura s takzvaným tlustým klientem, na začátku nového století došlo k posunu k architektuře třívrstvé, díky které mimochodem vznikla Java EE, a konceptu takzvaného tenkého klienta [6]. V dnešní době se již dá těžko mluvit o tenkém klientovi. Požadavky z pohledu uživatelského rozhraní i interaktivity aplikace vedou k přesunu části logiky ze serveru zpět na klienta. Ačkoliv by se mohlo zdát, že střední vrstva a server by si mohl oddechnout, opak je pravdou. Server musí být schopen velmi efektivně škálovat vzrůstající počet HTTP požadavků.

Java ekosystém

Když se řekne Java, mnoho lidí si představí pouze jazyk, ale ve skutečnosti se jedná o celý ekosystém též nazývaný platforma. Ta se skládá z několika klíčových součástí: srdcem je Java Virtual Machine, kolem ní je jazyk, dále nástroje pro vývoj a monitorování, a v neposlední řadě i knihovny. Ty standardní umožňující práci například se souborovým systémem, a potom velké množství open source knihoven pokrývajících prakticky cokoliv co člověk potřebuje.

Jazyk

Jazyk je jednou z možností, kde se může Java inovovat. Pokud se bavíme o jazyku, jedná se především o změny a rozšíření jeho syntaxe. Ty lze označit buďto jako zásadní viz případ Lambda výrazů (closures) [7] a nebo jako syntaktických cukrátek v podobě Diamantového operátoru (přidaný již v Jave 7). Společný problém těchto změn je zvýšení komplexity syntaxe jazyka a tím pádem zhoršení udržovatelnosti zdrojového kódu. Právě jednoduchá syntaxe a jistá míra konzervativnosti stále za velkou oblibou Javy jako jazyku. Mnohem závažnějším problémem je zpětná kompatibilita. Skryté nebezpečí totiž představuje provázanost jazyka a standardních knihoven resp. jejich API. Zavedení Lambda výraz totiž dává smysl pouze se změnou API např. u standardních kolekcí (Mapa, Seznam atd.), se kterými dává jejich použití teprve smysl. Nekompatibilní změna v těchto API by ovšem vedla k nemožnosti přenést velké množství existujícího kódu. Podobně velká změna syntaxe tohoto ražení v podobě Generik v Jave 5 dopadla dosti tristním způsobem.

Z dalších možností inovace na úrovni jazyku přichází v úvahu zbrusu nový jazyk. Původní Java by zůstala nedotčena a vytvořil by se nový jazyk, říkejme mu Java 2.0. Problém s Java 2.0 je v tom, že nikdo nedokáže říci, jak by měl takový jazyk vypadat a jaká kritéria by měl splňovat, aby přežil a byl úspěšný minimálně jako Java. Bez ohledu na finální rozhodnutí je pro Java platformu štěstím, že nad ní vyrostlo celé množství dalších jazyků tu s větší (Groovy) tu s menší (Scala) či dokonce žádnou podobností (Clojure), které je možné použít pro řešení specifických úkolů.

Standardní knihovny

Jednou z motivací, která stojí za snahou změnit jazyk, je komplexnost psaní kódu, který bude dobře škálovat na víceprocesorovém hardware, který je dnes běžně k dispozici. Bohužel vlákna a paměťový model, synchronizační primitiva to je oblast v Jave, která je příliš složitá a její plné pochopení představuje těžko proniknutelnou bariéru pro většinu programátorů včetně autora těchto řádků. Jenom málo na tom mění balík java.util.concurrent, který byl představen v Jave 5. Z programovacího jazyku Erlang a dalších se ukazuje, že je potřeba ještě vyšší úroveň abstrakce, kterou nabízí Aktory [8], Dataflow proměnných [9] nebo Softwarová Transakční Paměť [10]. Tyto konstrukty mohou být poskytovány jako nové standardní knihovny. I další úpravy standardních knihoven se týkají zvýšení propustnosti, například v podobě asynchronní podpory k blokujícím API jako je JDBC nebo HTTP klient.

JVM

Úpravy JVM [11] se musí týkat podpory velkých dat. Jedná se například o efektivnější reprezentaci řetězců a dalších datových struktur [12]. Problémy představuje je i správa velkých heapu (>10GB) a chování garbage collectoru, kdy při Full GC dochází ke kompletnímu zastavení práce JVM v řádu desítek minut [13]. Kromě úpravy chování bude potřeba přidat i další vlastnosti, které se dnes drátují manipulací s byte kódem. Řeč je především continuations, zmrazení a obnovení aktuálního stack frame, které umožní efektivní psaní aplikací postavených na asynchroniích voláních.

Z pohledu nasazení JVM do Cloudu se jedná především o podporu modulárního systému pro nasazování aplikací. Současný deployment model neumožňuje definovat moduly a jejich verze, které bude aplikace potřebovat, a vede k nulovým možnostem poskytování knihoven cílovým systémem. Typická aplikace díky tomu vypadá jako obrovský chumel JAR archivů, kde není jasné co je a není opravdu potřeba. Výsledkem jsou zvýšené paměťové nároky a pomalý start aplikací, který se díky čtení souborů ze systému podobá spíše zátěžovému testu souborového systému.

Nejsme tu sami

Vývoj v oblasti Javy dlouho trpěl díky přehlížení okolních trendů. Díky tomu je Enterprise verze (Java EE) v podstatě odepsanou technologií pro vývoj webových aplikací. V prostředí veřejných public cloud poskytovatelů to platí dvojnásob. Použitím technologie Java EE se vystavujete obrovským problémům při vývoji i nasazení tohoto typu aplikací. K zásadním nedostatkům patří složitost vývoje a nasazení. Bohužel většina technologií z Java EE stacku je absolutně nevhodná. Kromě ryze technických problémů jsou tu problémy v návrhu jednotlivých technologií. Většina z nich je totiž navržena stavově a s ohledem na to, že vývojář je absolutně odstíněný od prostředí ve kterém aplikace běží. S množstvím dat a požadavcích jednoduchosti vývoje se mění i architektura aplikací. Kromě návratu tlustého klienta, o kterém již byla řeč, se jedná o využívání NoSQL databází jako alternativy k databázím relačním. Je to plíživá revoluce, podobná té kterou spustil kolem roku 2007 framework Ruby On Rails, která bude ovlivňovat vývoj, technologie a knihovny v Jave. Největší chybou pro Javu a celý ekosystém by bylo, stejně jako v roce 2007, tyto trendy podcenit a nebo úplně ignorovat.

Jednou z nejsilnějších a zároveň nejslabších stránek Javy je její fragmentace. Neexistují jeden postup a knihovny pro řešení určitých typů problémů, na druhou stranu to umožňuje dynamicky se přizpůsobit na měnící se podmínky a vybrat vždy tu nejlepší kombinaci. Doufejme tedy, že se Java bude dál "fragmentovat" pod různými vlivy, kdy ty překonané uvolní cestu těm adaptabilnějším, díky nímž budeme my vývojáři schopni přetavit inovativní myšlenky a nápady.

Post mortem dovětek

Vzhledem k záplavě reakcí, které jsem k tomutu článku dostal, jsem se rozhodl, že uvedu pár věcí na pravou míru. Nebylo cílem Javu jakkoliv hanit, ale podívat se na její současný stav v kontextu trendů, které se v architektuře a vývoji aplikací objevují. Pokud některým čtenářům přijde, že z tohoto pohledu Java vychází bídně, je to čistě jejich interpretace výše uvedených řádků. Přiznávám, že jedním z postraních úmyslů, které mě při psaní článku vedly, bylo rozbití kliše, že existuje jedna správná technologie a tou je Java. Tím důvodem nejsou mé pochybnosti o Jave, ale víra, že žádná taková technologie neexistuje a existovat nemůže. Jsem hluboce přesvědčen o tom, že jediná správná cesta pro Javu je inovace na základě okolního světa, a nikoliv přešlapování na místě a předstírání, že Java je středobod vývoje okolo kterého se vše točí.

Celý článek je rovněž k dispozici na ABC Linuxu. Článek tam byl vydán jako součást kampaně firmy GoodData, ve které pracuji jako Java architekt. Věřím, že laskavý čtenář některého z těch přibližně 850 článků na tomto blogu, chápe že vše co píši, vyjadřuje můj osobní pohled a názory, pod které se vždy mohou podepsat. Proto zde článek uvádím v plném rozsahu s tímto dovětkem a možností jej komentovat.

Odkazy

1.
Andy Hunt, Pragmatic Thinking and Learning strana 66 - Everone has good ideas.

2. Wikipedia definice Time To Market.

3. Statistiky používání internetu.

4. článek Internet 2010 in numbers.

5. BBC new Technology předpověd firmy Cisco ohledně počtu zařízení.

6. Wikipedia definice Client–server model.

7. Projekt Lambda JSR-335 dedikovaný Lambda výrazům.

8. Wikipedia definice Aktor model

9. Wikipedia definice Dataflow proměnné

10. Wikipedia definice Softwárová transakční paměť

11. Úpravy JVM zaštiťuje projekt the Da Vinci Machine.

12. Prezentace JVM goes big data vysvětluje některé z problémů velkých dat nad JVM.

13. Článek objasňuje použíti konceptu BigMemory a odstranění GC přerušení BigMemory Explained a bit...

CZ Podcast 61 - Roumen se vrací

2012-02-24T23:23:00.000+01:00

Skoro nás na natáčení dílu 61. do CA nepustili, ale nakonec to stálo za to. Super jsme si s Roumenem pokecali a myslim, že to bude zajímavé i pro vás.

Otrávené API

2012-01-29T14:14:00.000+01:00

Otrávené API představuje situaci, která je důvěrně známá každému programátorovi. Během vývoje uděláte nějaké rozhodnutí, které se promítne do návrhu, struktury, výkonnosti či vhodnosti použití. Postupem času se ovšem ukáže, že to nebylo rozhodnutí úplně šťastné. Najednou máme v aplikačním kódu nebo hůře v infrastrukturním kódu něco o čem jsme přesvědčeni, že je špatně. Vždycky mi drásá srdce někomu vysvětlovat, že má použít ztrouchnivělé API, o kterém vím, že by tam nemělo být a nebo by mělo vypadat jinak. Chtěl bych se zmínit jaké možnosti máme, pokud tento problém nastane.

Metoda vyhnívání

Jedná se trochu o alibistický přístup ve stylu něco tam je, funguje to, sice je to špatně navržené, ale dá se s tím žít. Je to následování pravidla Pokud něco funguje, nesahejte do toho. Osobně tuhle metodu volím jenom když není jiného zbytí. Pokud jste nespokojeni s relativně izolovanou částí nejlépe aplikačního kódu, která se nepoužívá nijak často, prostě to nechte být. V případě, že se jedná o exponovanou část vaší infrastruktury, rovnou na vyhnívání zapomeňte a řiďte se dalšími radami.

Obalující rozhraní

Obalíte novým API to původní otrávené. Bohužel tahle metoda není úplně vždy proveditelná, protože málokdy se vám podaří úplně odizolovat implementační detaily. Jinými slovy, jestliže máte otrávené API, budete mít s velkou pravděpodobností i otrávenou implementaci, a kolem té se bude špatně stavit nové čisté API. Tato metoda vám nezabere tolik času na implementaci a testování jako metoda Paralelního API, která je popsána dále.

Paralelní API

kud řešíte zpětnou kompatibilitu. Ne vždy znáte nebo můžete změnit všechny místa použití. Proto vytvoříte paralelní implementaci s rozhraním. Nové a Otrávené API žijí v míru vedle sebe. Otrávené API můžete označit jako deprecated. Bohužel použití Otráveného API vám tam stále straší. V určitou chvíli proto zavřete oči a použijete metodu vykostění.

Vykostění

Pokud se rozhodnete pro nejradikálnější řešení problémů s Otráveným API. Jedná se o úplného odstranění Otráveného API a jeho nahrazení novou verzí. Preferujte tuhle metodu vždy pokud máte vaší code base plně pod kontrolou a zpětná kompatibilita pro vás nepředstavuje závažný problém. Všechny tři předešlé metody totiž hřeší na to, že prohlubují technologický dluh. Rizikem tohoto přístupu je, že po nějakém čase nemusíte byt s výsledkem spokojeni, a budete opět stát ve výchozím bodě.

Závěrečné doporučení

Refaktor kódu a jeho čištění by mělo patřit k základům práce každého vývojáře. Je to mravenčí práce, kterou málokdo ocení a nebo vám na ní poskytne čas. Nicméně s ní musíte počítat pokud nechcete mít problémy s udržováním a dalším rozvojem vašeho kódu. Já osobně preferuji Vykostění Otrávéného API. Takřka vždy se mi totiž ukázalo, že problémy které způsobilo jeho prorůstání do zbytku code base, byly nesrovnatelné s tím, co by stálo jeho včasné odstranění.

CZ Podcast 60 - User Experience Design

2012-01-27T18:04:00.000+01:00

V tomto díle jsme se věnovali User Experience Designu, tedy tomu jak navrhovat produkt/službu tak, aby z ní uživatel měl co nejlepší prožitek.

Nepoužívejte Mapu ani String v rozhraní vašich tříd

2012-01-08T19:52:00.000+01:00

Když se zpětně dívám, za APIs které jsem vytvořil, dochází mi, že jednou z největších chyb bylo použití tříd ze standardního SDK v jejich rozhraní. Použití tříd, jako java.lang.String java.util.Map apod., bylo samozřejmě dané mojí leností zavádět si speciální typy vyjadřující danou entitu. V budoucnu jsme platil za tuhle lenost velkou cenu.

Použití Mapy

Použití Mapy se mi hodilo pro reprezentaci jednoho řádku, který vracelou jedno vzdáleného API.

    public void processRow(java.util.Map row) {
        ...
    }

Na první pohled jednoduché použití, ale... Za několik týdnu broušení objektů nad touhle reprezentací řádku jsem potřeboval rozšířit informace, které by o sobě řádek mohl prozradit. Potřeboval jsem metadata k jednotlivým sloupcům, ba co hůře, potřeboval jsem kontrolovat jestli je to řádek originální a nebo synteticky vytvořený. Problém byl na světě. Do Mapy totiž žádnou metodu nepřidáte. Musel jsem pracně předávat metadata jinou cestou. Pokud šlo o typ řádků testoval jsem typ na speciální implementaci Mapy, kterou jsem musel vytvořit. Poučení pro příště, mate-li v API java.util.Map pravděpodobně je něco špatně. Čest výjimkám potvrzujícím pravidlo.

Použití Stringu

Měl jsem třídu, která vyjadřovala kontext aktuálně přihlášeného uživatele. Identifikátor uživatele byla prostý java.lang.String přestože se jednalo o číselný identifikátor. Opět chyba, za kterou bych si dal rákoskou přes prsty.

    public String getUserId() {
        ...
    }

Co čert nechtěl, původní reprezentace se změnila z čísla opravdu na řetězec. Ve všech navázaných API byl String a na místech, kde bylo potřeba rozeznat původní číslo a nově řetězec, se muselo provést rozpársování. Správné řešení bylo použití hned od počátku objekt reprezentující uživatelův identifikátor.

    public UserIdentifier getUserId() {
        ...
    }

Další typické zneužití java.lang.String občas přichází v podobě konstant, které by bylo možné vyjádřit výčtovým typem. Mimochodem doporučuji přečíst poměrně kontroverzní, ale poučný článek Stefana Schmidta Never, never, never use String in Java (or at least less often :-).

Stejný problém představují tyto typy na místě návratových hodnot. Občas si dokonce pomůžeme například polem a nebo zavedeme nějaký tuple. Opět se toho vyvarujte. Sváže vám to do budoucna ruce, API nebude přehledné a těžko se vám bude rozšiřovat s ohledem na zpětnou kompatibilitu.

MongoDB pár tipů na zajímavé prezentace

2012-01-07T23:14:00.000+01:00

Čím víc proníkám do MongoDB tím vice se mi zamlouvá. Líbí se mi jak na ní inženýři s 10gen makají a neustále jí vylepšují a jak otevřená je komunita kolem této dokumentové NoSQL databáze. Tenhle týden mě zaujaly tři prezentace, na které vám dám tipy.

Utvrzené názory za rok 2011

2012-01-01T18:23:00.000+01:00

Začnete-li psát článek v první den nového roku máte jenom dvě možnosti. Rekapitulovat rok předcházející a nebo věštit budoucnost pro rok nový. Protože protože mé předchozí předpovědi byly spolehlivé asi jako odhad míry zadlužení Řeckého statistického úřadu nebude se do nich letos pouštět. Nechci zároveň ani psát o roce 2011 ve formě jakési rekapitulace. Rozhodl jsem se proto, že se s vámi zkusím podělit o názory, ve kterých mě rok 2011 utvrdil.

Život v IT

Většina problémů v IT je jenom z malé části ovlivněna metodologií, technologií a kvalitou lidí, které máte k dispozici. Nejzásadnější příčinou je špatná komunikace tedy spíše nekomunikace a nejasná zodpovědnost. S tím souvisí i alibismus, který bych si troufal označit za typickou českou vlastnost (nejen v IT).

Dobrá zpráva. Zlaté české ručičky není mýtus. Špatná zpráva je, že to platilo pro generaci našich otců, které tady tvrdě vycepoval socialismus, kde většina zboží bylo nedostatková. V kontextu IT to ovšem znamená, že naše budoucnost je limitovaná naší cenou, po kterou budeme brání jako levná pracovní síla z východu. Pokud to chceme změnit musíme udělat tři věci: tvrdě pracovat, snažit se inovovat a neustále si rozvíjet naše vědomosti a znalosti.

Koncept renesančního člověka není jenom oblíbená Filemonova průpovídka, ale věc, kterou vám potvrdí kdokoliv kdo překročil vlastní stín. Pokud se budete úzce profilovat pouze v jedné oblasti, nedej bože jenom IT, nikdy nezískáte potřebný nadhled a inspiraci, která vás posune o úroveň výše. Ve všech knihách a oborech lze najít plno paralel, které můžete s úspěchem v IT uplatnit. Bylo by velkou chybou před nimi zavírat oči.

Jedno přísloví říká: "Lepší být jeden den orlem než celý život ovcí". Steve Jobs tuším prohlásil: "Je lepší být pirátem než se dát k námořnictvu". Tím chci říci, pokud něčemu věříte, bez ohledu jestli je to technologie či přístup, řiďte se tím bez ohledu na to, že jdete hlavou proti zdi.

Nejlepší konfrontace vlastních myšlenek a názorů je jejich veřejná prezentace. Můžete se plést, můžete mít pravdu, nejhorší přístup je mlčet. Chyba není mít opačný názor, chyba je nemít žádný názor. Nejlepší konfrontace bývá s lidmi absolutně opačného názoru.

Programování

Programování je řemeslo jako každé jiné. Pokud v něm chcete být opravdu dobří počítejte s tím, že vám to zabere minimálně deset let intenzivní práce. Počítejte s tím, že se mnohokrát spletete a budete muset korigovat svoje předchozí způsoby, o kterých jste si mysleli, že jsou to správnou cestou.

Složitý kód není dobře jednotkově testovatelný. Jednotkově netestovaný kód není dobře objektově navržený. Nedobře objektově navržený kód je kýbl hnoje. Do kýblu hnoje je lepší kopnout a začít znovu a lépe. Objektový návrh a tvorba API se nepovede nikdy na první pokus. Refaktorujte do té doby než jste absolutně spokojeni s každým detailem kódu. Každý dluh, i ten technologický, který uděláte vás později dožene.

Není nic jako kolektivní vlastnictví kódu. Každý jeden řádek kódu, každá třída, každý modul má jednoho jediného vlastníka, který je za něj zodpovědný. Nikdy neakceptujte kód v formě kontribuce pod který byste se sami nepodepsali.

Ďábel leží v detailech. Buďte perfekcionisté nejenom co se týká kódu samotného, ale i jeho dalších detailů. Struktuře, dokumentaci interní i veřejné, konzistenci.

Výkonnost ovlivňujte na úrovni návrhu nikoliv na úrovni kódu. Změnami v kódu jste schopni ovlivnit výkon v řádu procent, změnami v návrhu ovlivňujete výkonnost v řádu desítek procent.

CZ Podcast 59 - Automatizace a Configuration management

2011-12-20T21:14:00.000+01:00

Díl 59. je venku přátelé, a to je pro tento rok z naší estrády definitivně všechno. Sosejte, poslouchejte a doufam, že to neni jenom mlácení prázdné slámy, jak si z toho občas děláme s Filemonem srandu.

CZ Podcast 58 - Výuka Informatiky na vysokých školách

2011-12-13T23:26:00.000+01:00

Přátelé čekal jsem to horší, že to jde s výukou od desíti k pěti. Nakonec konfrontován s realitou jsem si uvědomil, že úplně totálně v pasti to naše školství není. Poslouchněte si další díl.

Další krok k Continuous Delivery

2011-12-04T23:59:00.002+01:00

V několika předešlých článcích jsem se věnoval continous delivery a ještě ve starším článku jsem se zamýšlel nad buildováním z jedné hromady oproti releasovatelným celkům. Když nad tím teď přemýšlím, přijdou mi releasovatelné celky jako výborný krok k continous delivery, alespoň v našem prostředí v GoodData. V tomhle článku vám nechám trochu nahlédnout do kuchyně toho jakým způsobem vyvíjíme Java komponenty a připojím pár postřehů, které si myslím, že by nám mohli pomoci k plnému continous delivery, protože zatím jsme schopni doručovat nové verze produktu přibližně každých 14 dní.

Na začátku všeho je commit

Chtělo by se začít tímto titulkem, ale já to neudělám, a začnu organizací kódu která se nám osvědčila. Úplně původně jsme měli všechen zdrojový kód na jedné hromadě. V heterogenní aplikaci, kterou v GoodData vytváříme, jsme měli sice strukturované, ale stále na jedné hromadě zdrojové kódy všech služeb UI klientem počínaje a ROLAP enginem konče. Tahle směska má speciální buildovací skript, který volá jednotlivé buildovací nástroje poplatné pro daný jazyk/platformu, v případě Javy to byl Maven. Výsledkem buildovacího procesu jsou RPM balíčky, které umožňují nainstalovat celý produkt.

Ve verzovacím systému pro správu zdrojových souboru (používáme Git) používáme při vývoji nové funkcionality koncept feature branch, to znaméná, že máme Master větev, do které je možné zamergovat z Feature větve až potom co člověk projde prověrkou kvality, která se skládá z důkladné sborky a rozborky, code review a kurately záludných otázek. Merge do Masteru je úzkým hrdlem celého procesu, a code review je docela komplikované ve chvíli kdy měníte různé komonenty. V Jave máme navíc velké množství komponent, které používáme skrze různé služby a proto je potřeba být velice obezřetnými při jednotlivých změnách. Při buildu na jedné hromadě je prakticky nemožné používat stabilní verze komponent a zároveň mít vývojové verze, protože komponenty mají různý vývojový cyklus. Navíc máme odladěné verze komponent, do kterých se prakticky nesahá a nechceme jimi neustále zdržovat kontinuální buildy ať již z důvodů rychlosti či zdrojů.

Releasovatelné komponenty v praxi

Z výše uvedených důvodů jsme se rozhodli postupně migrovat Java komponenty z jedné velké hromady do separátních repositářů na GitHub a releasovat je jako binární artefakty Maven infrastrukturou. Co se týká Javy máme něco kolem třiceti GitHub repositářů. Každý repositář má svého strážce (gatekeeper), tedy člověka který je zodpovědný za komponenty v daném repositáři. Pokud chci něco v dané komponentě změnit udělám to ve vlastní větvi, ze které vytvořím Pull request. GitHub na to má skvělou podporu bez toho aniž bychom si museli cokoliv programovat vlastními silami. Strážce dostane emailovou notifikaci, s odkazem na Pull request. Přes webové rozhraní si prohlédne změny a má dvě možnosti. Pokud je vše v pořádku akceptuje Pull request a GitHub se postará automaticky o zamergování změn. Pokud se strážci něco nezdá, může do zdrojového kódu, případně k Pull request, dopsat svoje komentáře přes webové rozhraní. Ty jsou žadateli o Pull request zaslány formou emailu. Výhrady se zapracují a pokud není jiných námitek Pull request se akceptuje. Tím je pokryté code review.

Nad zdrojovými repositáři na GitHubu máme post commit hooky, které se postarají o klasické kolečko build, test a deploy výsledného artefaktu do binárního Maven repositáře. Jediné bílé místo představuje release management komponenty, který dělá strážce manuálně. Pokud je potřeba vyrealsovat stabilní verzi komponenty musí strážce spustit manuálně Maven release plugin, který se postará o všechny záležitosti (build artefaktu, změna verze POMu, přiřazení tagu atd.). I release komponent bychom chtěli dělat automaticky (pravděpodobně speciánlí commit message a nebo manuálně z CI serveru).

Pravidla

Release notes

Každá komponenta má u sebe soubor RELEASENOTES.md, ve které zaznamenáváme změny v lidsky snadno pochopitelné podobě, aby to člověk nemusel dohledávat z commit logu. Používáme markdown syntaxi, kterou dokáže GitHub renderovat ve webovém rozhraní když člověk prochází repositář.

## 1.1.2
* Added `AbstractMediaTypeAwareFilter` filter provides support for detection  media types from  HTTP headers
* Added `RetainingHttpServletResponse` special `HttpServletResponse` implementation allowing manipulation with the response body and HTTP headers until the flush method is called
* Added `RetainingResponseFilter` this filter wraps `HttpServletResponse` to `RetainingHttpServletResponse`

## 1.1.1
* Added support for altering the Content-Type header (ContentTypeAlteringRequestWrapper)
* Added support for changing the entire request body (BodyAlteringRequestWrapper)

Verzovací schéma

Používáme klasické trojčíselné označení verze X.Y.Z. Tímto způsobem verzujeme, aby bylo na první pohled patrné, k jakému typu změny v dané verzi komponenty došlo. Číslo X označuje generaci komponenty, je vždy 1 a nepředpokládám, že bude jiné, snad jenom kdybychom se rozhodli danou komponentu totálně překopat. Číslo Y označuje zásadní změny, které mohou být nekompatibilní s předchozí verzí. K nekompatibilním změnám se ještě vrátím. Poslední verze označuje inkrementální změny, bugfixy atd.

Pokud se rozhodnete releasovat komponenty stane se pro vás zpětná kompatibilita velkým zaklínadlem. Nevíte totiž kde kdo v jaké verzi vaší knihovnu používá a kdy se rozhodne nebo případně bude donucen (tranzitivní závislosti) používat novější verzi.

Postupem jsem dospěli k tomu, že nejlepší je dělat zpětně kompatibilní změny především u nízkoúrovňových komponent např. HTTP klient, protože jinak se vám výsledný celek může sesypat jak domeček z karet. Mimochodem to je jedna z nevýhod releasovatelných komponent oproti buildu z jedné hromady. U aplikačních komponent už na to není třeba brát zas takový ohled.

Readme

Většina komponent by u sebe měla mít popis toho k čemu slouží a jak se používají. To usnadňuje orientaci při jejich použití.

JSON
===========
This repository consists of two parts

* [JSON validation](https://confluence.gooddata.com/confluence/display/analysis/JSON+validation+documentation)
* JSON serialization support - also contains [AbstractJsonObject (de)serialization](https://confluence.gooddata.com/confluence/display/Development/Abstract+JSON+object+serialization)

Continous delivery

V Continous delivery alespoň u Java služeb nám brání několik překážek. Zatím nemáme releasovatelné úplně všechny high level služby. Nicméně se držíme pravidla, že v stabilizační větvi (forknutá z Master větve) nepoužíváme SNAPSHOT závislosti. Tím je build reprodukovatelný a nehrozí, že jej rozbijeme. Ve chvíli kdy budeme mít releasovatelné všechny služby už bude jenom několik kroků ke kýženému cíli. Předně psychologická zábrana, které říkám suma všech strachů. Mít tolik testů, schválně neuvádím procento code coverage, které mi umožní udělat commit s vědomím, že případný problém bude zachycen.

Další věcí je staging repository pro binární artefakty služeb. Po tom co je artifakt připravený v Maven repository a tedy úspěšně proběhly jednotkové a integrační testy je potřeba ho otestovat se zbytkem systému. Pokud tyto testy projdou, je možné artefakt posunout do staging repository, ze které je možné brát artefakty pro finální distribuci, která jde k manuálnímu verifikaci.

No a poslední překážkou je neschopnost částečného releasu/rollback jenom některých částí. Zatím dokážeme releasovat jeden velký celek, což samozřejmě zvyšuje náklady spojené s celým releasem.

Závěr

Cesta ke Continous delivery je dlouhá a trnitá, navíc nikdo vám nedá plánek. Funguje jenom postupné zlepšování a učení z vlastních chyb. Doufám, že za půl roku se budu moci pochlubit jak jsme pokročili.

CZ Podcast 57 - Pokec s Alešem Roubíčkem o Windows Azure, Code retreat a Agile vývoji

2011-11-22T23:28:00.000+01:00

Další díl s Alešem Roubíčkem. Windows Azure mě docela mile překvapil. To se ovšem nedá říci o zvuku, který jsme zachytili mikrofónem. Zakouzlil jsem v Audacity a doufam, že se vám to bude líbit.

Postřehy z Devoxx 2011

2011-11-19T16:51:00.006+01:00

S kolegy z GoodData jsme vyrazili na konferenci Devoxx, a musím říci předeslat, že to stálo za to. Devoxx je určitě nejlepší konference co se týká Javy v Evropě, která se konala letos po desáté v Antverpách. Paralelně běželo od půl desáté ráno do sedmi večer sedm prezentačních slotů, ze kterých si člověk mohl vybrat to co ho zajímalo. Přestože je to Java konference, byla v nabídce poměrně pestrá škála prezentací z přidružených jazyků a technologií postavených kolem Java Virtual Machine (JVM). Osobně jsem se snažil vybírat prezentace, které neměly s Javou moc společného a to ze dvou důvodů. Jednak nesdílím názor, že postupné nafukování jazyka je cesta, kterou by měly jít další verze Javy. Jednak razím tezi, že člověk by měl chodit na prezentace o technologiích a postupech, které nezná, protože ty ho nejvíce obohatí. Za celou dobu jsem proto z Javy slyšel jenom pár útržků na různých prezentacích.

Clojure
Continuous Delivery
HTML 5
Cloud a Java

Clojure

Poprvé v životě jsem viděl Lisp, tedy konkrétně Clojure v dvou prezentacích Alexe Millera. Přiznám se, že syntaxe jazyka pro mě byla natolik exotická, že jsem většinu slajdů v rámci zachování duševního zdraví musel vypustit. Pár postřehů, které jsem si udělal: Lisp dialekt, funkcionální jazyk, kompilovatelný do bajt kódu JVM, imutabilní struktury, kód jsou data, žádné IDE ale Emacs. Síla Clojure se ukázala v prezentaci Stream Execution with Clojure and Fork/Join. V něm bylo prezentováno použití Clojure ve firmě revelytix.com, která umožňuje vyhledávání SPARQL jazykem v RDF dokumentech uložených v relačních databázích. Funguje to asi následujícím způsobem. HTTP rozhraní na které posíláte SPARQL dotazy, z nich se postaví AST a na jeho základě exekuční plán, ten se zoptimalizuje a převede na SQL příkazy, které jsou paralelně vykonány a jejich výsledek sloučen dohromady a vrácen jako odpověď. To všechno prosím pěkně na plus mínus 3000 řádcích kódu Clojure. To na mě udělalo velký dojem, přestože bych spíš pochopil básničky v jazyce Elfů než zdrojový kód, který se tam párkrát objevil.

Continuous Delivery

Každá změna ve verzovacím systému je automaticky přetavena v novou verzi produktu a může se objevit na produkci. Člověk je skoro v pokušení si zaťukat na čelo a jít o dům dál, ale ono to skutečně funguje. Prezentaci měl Dave Farley autor stejnojmenné knihy. Výše zmíněný postup přetavili do praxe ve firmě LMAX, což není garážová firmička, ale pořádný enterprise bumbrlíček, který se živí zprostředkováním finančních transakcí. Kromě toho co jsem psal dříve v článku Continuous Deployment (pozn: ve skutečnosti vaším cílem není deployovat novou verzi, ale doručovat nějakou hodnotu vašim zákazníkům) bych vypíchnul jednu zásadní myšlenku, která zazněla. Pokud chcete někdy kontinuálně doručovat váš software, musíte mít spolehlivý release proces na každé úrovni s dovětkem, že cokoliv co je závislé na zásahu člověka se považuje za nespolehlivé. Více 8 Principles of Continuous Delivery.

HTML 5

HTML 5 byla oblast, kterou jsem v minulosti totálně ignoroval. Musím se přiznat, že HTML 5 pro mě bylo asi největším drahokamem který jsem v Antverpách objevil Někdo použil větu HTML 5 is a game changer a já s tím musím souhlasit, protože nabízí jednu vývojovou platformu pro svět mobilních telefonů, tabletů a osobních počítačů. Ve všech prezentacích zaznělo kolik má problémů z některých jmenujme: nekompatibilita prohlížečů, chybějící nástroje, výkonnost oproti nativním aplikacím, na druhou stranu nabízí obrovský potenciál. Z technologického hlediska mě zaujala jedna zásadní myšlenka. HTML 5 umožňuje (nikoliv znamená!) změnu architektury webových aplikací. Díky HTML 5 si můžeme dovolit napsat aplikaci, která nebude přímo závislá na online připojení k serveru a bude si dokonce moci držet stav.

Cloud a Java

Viděl jsem keynote věnovanou Java EE, ve které byl hlavním tématem cloud. Původně jsem chtěl napsat, že to jak si cloud a aplikace v něm napsané představují chlpaci z Oracle, a jak si jej představují já, jsou dva naprosto odlišné světy. Nakonec jsem dospěl k tomu, že moje představa je pokřivená mými zkušenostmi a agilitou potřeb firmy, pro kterou pracuji. Java EE je opravdu úsilí, které je zaměřeno na dodání standardů pupkatým pánům v korporacích. Když to akceptujete, bude váše chápání Enterprise Javy mnohem méně kritické. Proto snahu o podporu JSONu, JPA nad NoSQL databázemi v další verzi berete s jemným přimhouřením oka. To co nejvíce kontrastovalo s mým chápáním, a nebo to na mě přinejmenším tak působilo, byla vize homogenního cloudu z pohledu hostovaných aplikací a služeb. V případě Java EE to byl EAR/WAR v aplikačním serveru. To si myslím může platit pouze pro určitou skupinu aplikací v určitém typu prostředí a napadají mě opět pupkatí páni... Pokud nemáte jenom EARy, WARy a nebo se jinak odlišujete od představy cloudu, například technologiemi které používáte, už pro vás Java EE koulí na noze.

S tím kontrastovaly prezentace Platform As A Service poskytovatelů, kterým byli Heroku a Cloud Foundry. Přestože by se mohlo zdát, že Java EE a tyto dvě služby k sobě mají stejně daleko, jako Řekové k vyrovnanému státnímu rozpočtu, opak je pravdou. V obou službách totiž přesně pochopili, že vývoj dnešních aplikací se neodehrává v jednom jazyce a za použití jedné technologie. Speciálně bych se zastavil u Cloud Foundry, jehož myšlenka mi přijde skvělá. Skrytý problém dnešního cloud computingu se nazývá vendor lock-in. Česky by se to dalo přeložit jako přikování k jednomu dodavateli. Když si dneska postavíte svojí aplikaci nad Amazonem, budete více či méně svázáni s jeho infrastrukturou a migrace na jiného poskytovatele bude velmi bolestivá. Cloud Foundry by se dala popsat jako prostředník mezi vaší aplikací a poskytovatelem cloud. Namísto toho, abyste aplikaci a nástroje pro monitoring a správu stavěli proti konkrétním službám daného poskytovatele, stavíte je proti API Cloud Foundry, které je adaptuje na konkrétní podvozek. Přechod z jednoho poskytovatele na dalšího pak není tolik bolestivý. Za Cloud Foundry stojí VMware, ale projekt jako takový je open source, tento model bych přirovnal k linuxovým distribucím, jako příklad bych to ilustroval na Stackato.

Závěr

Zaujal mě framework Disruptor pro pekelně rychlé předávání dat mezi dvěma vlákny, když si ovšem přečtete jejich tech paper zjistíte, že máte k dispozici asynchronní event framework. Zaujaly mě rovněž Remote Actory v Akka 2.0 viz strana 27 a Play framework, který kompletně obchází Servlet API a je postavený právě kolem konceptu Actorů. Naopak mě zklamala keynote Tim Braye, ze které jsem si odnesl pouze odvážnou myšlenku, že trh pro aplikace na mobilní zařízení leží v rozvojových zemích. Pocit politicky korektního, rozuměj nic neříkajícího, tlachání jsem měl z diskuzního panelu kde byli mimo jiné pánové jako Joshua Bloch, Brian Goetz, Ben Evans a Mark Reinhold. Buďto všichni právě střízlivěli z párty předešlého dne a nebo tomu chybělo lepší moderování a výběr otázek. Jsem v pokušení napsat, že Filemon by to zvládnul lépe než Tor Norbye. Nikdo z nich v podstatě nepřinesl na stůl nic nového a především se snažili hlavně někoho neurazit.

To byl Devoxx 2011 mýma očima.

Mimochodem doporučuji i postřehy Lukáše Křečana, které jsou vtipnější než ty moje a navíc jsme navštěvovali až na pár vyjímek různé prezentace.

MongoDB - komentář k posledním událostem

2011-11-11T23:05:00.000+01:00

V posledním týdnu se po různých diskusích začalo trousit hodně negativní reklamy na MongoDB. Jedním z těch příkladů je anonymní Don't use MongoDB s odpovědí přímo od 10gen. Samozřejmě konkurence si taky přihřála polívčičku ačkoliv to později uvedla na pravou míru. Kdybych to měl shrnout MongoDB je designované s určitými vlastnostmi a vy je buďto akceptujete a budete s nimi počítat a nebo budete nemile překvapeni.

Prvním poměrně zásadním designovým rozhodnutím bylo vypnutí (default) potvrzovacího módu pro write operace. To má za následek, že sice z vašeho pohledu zapíšete data, ale to neznamená, že se data byla ve skutečnosti zapsána na disk. Důvod k tomuto rozhodnutí je přesvědčení autorů, že ne všechny zápisu musí být kritické a zdržovat klienta. Pokud například používáte MongoDB pro sběr logovacích událostí tak vás pravděpodobně nebude mrzet, že některé z nich nebudou za určité konstelace trvale zapsány. Každopádně, a to je důležité zdůraznit, potvrzení zápisu můžete ovládat klientem a to do té míry, že můžete například vynutit zápis na určitý počet replikačních instancí Mongo v clusteru.

Dalším poměrně často kritizovaným aspektem MongoDB designu byla možná korupce datového souboru při pádu serveru. MongoDB používá mapované soubory do paměti a jednou za čas udělá fsync, kterým se zapíše aktuální stav na disk. Může dojít k porušení integrity pokud ustřelíte MongoDB v ten pravý okamžik, potom vám nezbývá nic jiného než pustit recovery. Od verze 1.6 můžete použít žurnál a máte vystaráno. To má sice negativní implikace na výkon zápisových operací, ale v nereplikovaném řešení je to jediná možnost. Pokud provozujete MongoDB v master/slave módu a nebo replica setu, můžete nechat sesynchronizovat porušený node z masteru či dalších replikantů a máte po problému (teorie - nezkošuel jsem zatím).

Posledním designovým rozhodnutím, které bývá často kritizované, je globální read/write zámek. Díky němu si nikdo jiný neškrtne pokud běží zápisová operace. To je docela nemilé, ale... Záleží kolik zápisových operací máte vzhledem ke čtení. Moje domněnka je, že rozhodnutí použít globální zámek udělali, protože je to nejjednodušší způsob, jak vyřešit zamykání dat bez zvýšení paměťové náročnosti (nevýhoda MVCC). Každou novou verzi databáze se optimalizuje výkonnost zkracováním kritické cesty, aby se zámek držel pokud možno co možná nejkratší dobu.

Toliko k nejčastěji uváděným "nedostatkům" nebo designových rysům MongoDB. Celá ta diskuze mi velmi připomíná debatu Ruby on Rails versus zbytek světa asi před třemi lety: "No vy to sice umíte krásně, ale to se nedá použít, protože požadavky se odbavují jeden po druhém. To nemůže nikdo nikdy použít pro reálný projekt". Samozřejmě kdo chce psa bíti hůl si vždycky najde. V tomhle případě se krásně ukázalo, že pokud existuje technické řešení, pak to není vůbec problém. Pokud bych to převedl zpět na MongoDB, firma 10gen si všechno velmi dobře uvědomuje a velmi se snaží všechny defekty řešit a databázi dál vylepšovat.

Nástup NoSQL řešení je změnou paradigmatu, kterým jsme vyvíjeli webové aplikace posledních deset let. Relační databáze jsou nahrazovány alternativními úložišti z různých důvodů, které jsou dostatečně známé. Ten kdo dneska pošilhává po NoSQL řešení by neměl počítat s tím, že dostane hotový produkt typu relační databáze, jinak bude dost zklamaný. Pokud hodláte MongoDB použít mějte všechny tyto věci na paměti.

CZ Podcast 56 - Cloud computing, Amazon AWS

2011-11-07T22:24:00.000+01:00

56. díl jsme natočili opravdu údernickou formou. Filemon šlohnul na fotbalovém zápase Plzeň - Barcelona ruchový mikrofon, ale ten jsme nestačili zapojit, jaký byl fofr tenhle díl natočit. Teď trochu vážně, podařilo se nám vyzpovídat Teherána, což je náš šéf Operations v GoodData, a člověk který pracuje s Amazon AWS každý den.

CZPodcast 55 - NoSQL databáze

2011-10-28T15:58:00.000+02:00

Tímto dílem o NoSQL databázích jsem si udelěl radost, protože se o ně zajímam docela dlouhou dobu. Podařilo se nám ulovit celkem zajímavé hosty. Karmi, Augi i Honza jsou lidé kteří dnes a deně pracují s různými NoSQL databázemi (Riak, CouchDB, MongoDB, Redis, Cassandra) a mají ten dar, že o tom dokáží zasvěceně povídat. Pokud jste o NoSQL databázích neslyšeli a nebo se chcete dozvědět něco nového, pak je tenhle podcast přesně pro vás.

CZ Podcast 54 - Práce v zahraničí exkluzivně z WebExpo

2011-10-15T12:17:00.000+02:00

Natáčení tohoto dílu byla celkem velká taškařice. Jediné jasné bylo, že ho "spácháme" na konferenci WebExpo. V plánovaném čase natáčení proti nám běžely dvě jiné přednášky a nebylo moc jasné kolik lidí nakonec dorazí. Mimochodem byl to vůbec první podcast před publikem. Nakonec dorazilo kolem 30 lidí, což nás docela potěšilo, vzhledem k tomu, že proti nám šla těžká váha v podobě Johna Vanhary. Můžete si prohlédnout fotografie z natáčení.