neděle 30. prosince 2007

Malá bilancující glosa

Nevím, mám-li na konci kalendářního roku 2007 rekapitulovat věci minulé a nebo se pouštět prognóz ohledně věcí budoucích. Zvolím tedy od každého trochu, aby bylo vyváženosti této glosy učiněno zadost.

Vezmu to trochu obšírněji a začnu tím, že je to pět let co tu s vámi, tu s větším, tu s menším úspěchem, koexistuji formou tohoto blogu. Když jsem v roce 2OO2 začínal, bylo tu pár blogů, tenkrát se jim říkalo weblogy (asi podle zaměření na web), jako Sova v síti a nebo conBlog. O Jave tenkrát nepsal nikdo a ani já jsem neměl nějaké přehnané ambice. Dnes jsem napočítal ve své RSS portfóliu sedm pravidelných českých blogů zaměřených především na Javu. Další blogy vznikají a je o nich čas od času slyšet především skrze Java.cz.

Ještě před dvěma lety bylo něco jako setkání České java komunity spíše zbožným přáním. V roce 2007 jsme se v rámci CZJUG sešli celkem desetkrát. Pro rok 2008 máme zajištěný program (REST, GlassFish clustering, performance) na následující dva měsíce a v zásobě několik možných témat (bezpečnost, OSGi) pro setkání budoucí. Neméně pilně chystáme další díly nepravidelného podcastu.

Nyní trochu něco osobního. Když jsem tady před těmi pěti lety začínal, měl tento blog jediného čtenáře a to jsem byl já sám. Potom se začali návštěvníci nabalovat a jejich počet roste neustále, což mi dělá velkou radost. Postupem času jsem začal zjišťovat, že tento blog čte i plno kolegů, což mi nejednou přivodilo horké chvilky, když jsem si pustil pusu na špacír. Od jisté doby už vím, že je neradno brát si beztrestně na paškál kolegy z jihovýchodní Asie, protože i tam se dostala čeština.

Popravdě řečeno ani pořádně nevím, co nás v následujícím roce čeká za události v Java světě. Ani si s tím nehodlám lámat hlavu, protože těch událostí bude určitě taková záplava, že vybrat z nich nebude problém. To svědčí o tom, že Java jako platforma je zralým a fungujícím ekosystémem, který má před sebou budoucnost. Samozřejmě i Java má před sebou několik výzev a tou nejvýraznější je podle mého soudu hozená rukavice v podobě efektivity vývoje. Uvidíme, které z nich a v jaké míře, se podaří naplnit.

Co by to bylo za bilancující článek, kdybych Vám nepopřál do nového roku. Nuže milí čtenáři, přeji Vám do roku 2008 především hodně zdraví, protože všechno ostatní si koupíme ;-)...

úterý 25. prosince 2007

Sharding: rozčtvrťte data

Horizontální dělení dat alias sharding je přístup pro dosažení škálovatelnosti na velkých objemech dat. Sharding byl úspěšně implementován jako součást architektury Google aplikací a nebo Flickr či Friendster. Myšlenka shardingu je velice jednoduchá, data jsou podle určitého klíče rozloženy do několika fyzických úložišť (databází). Představme si aplikaci typu seznamka. Data je možné rozložit podle různých strategií.

  • data uživatelů A-G jdou do databáze A, data uživatelů H-R jdou do databáze B atd.
  • informace o uživatelích jdou do databáze A, historie jejich konverzaci do databáze B, veřejná diskusní fóra do databáze C
  • všechna data uživatelů z Česka do databáze A, všechna data uživatelů ze Slovenska do databáze B

Sharding nám přinese několik výhod.

  • aplikace pracuje na omezeném (relativně malém) množství dat, z toho plyne jejich rychlejší zpracování - čtení, zápis
  • výpadek jednoho databázového stroje (shardu) neznamená výpadek celé služby, postiženi jsou pouze a jenom data na daném stroji.
  • pri zajištění maximální dostupnosti (high availibility) dat není potřeba replikovat všechna data, ale pouze daný shard.
  • zpracování dat lze paralelizovat, můžeme například jeden dotaz pustit paralelně na několika shardech

Samozřejmě sharding má i svoje nevýhody.

  • data mezi shardy nejsou normalizovány, tedy nemůžeme udělat jednoduše dotaz přes více shardů. To musíme udělat programově spuštěním dotazu nad všemi shardy a spojením jejich výsledků.
  • je potřeba mít speciální strategii pro zjištění v jakém shardu leží data
  • sharding nelze udělat transparentně, logika pro přístup k datům si musí být vědoma toho, že data jsou rozdělená

Pokud nepočítám Hibernate Shards, který mi přijde ještě celkem syrový, tak si celé řešení bude muset člověk ztlouci na koleni. Zkuste si představit, jak to naimplementujete pomocí JDBC, to nebude rozhodně práce na dva dny. Na druhou, stranu celé řešení budeme mít plně pod kontrolou, aniž bychom museli záviset na "krvavě zaplacených" možnostech databáze. Celkově vzato, jakmile začnete horizontálně dělit data, musíte změnit přístup k práci s nimi.

Docela by mě zajímalo jestli sharding využívají vysoce exponované České portály jako například Seznam a nebo Aukro.

V tomto postu jsem hojně čerpal z informací uvedených v článku An Unorthodox Approach to Database Design : The Coming of the Shard, který vřele doporučuji k přečtení.

sobota 22. prosince 2007

Zbytečná skepse kolem skriptovacích jazyků

Po posledním CZJUGu jsme řešili využití skriptovacích jazyků a překvapila mě velká skepse všech diskutujících. Tuto skepsi volně vystihuje článek Skriptovací jazyky v Javě - co s nimi? na Blogu o javičce. Zkusím tedy tuto skepsi trochu rezprášit.

někdy jsou světy Javy a skriptovacího jazyka natolik rozdílné, že to nelze v některých jazycích vůbec implementovat nebo za cenu ne úplně ideálního kódu. Myslím například anotace v Javě.

Je chyba přemýšlet o skriptovacích jazycích jako o náhradě Javy. Skriptovací jazyky jsou samozřejmě pouze vhodným typem doplňku k Jave. K tomu se dostanu později.

větší nároky spojené s údržbou aplikací. Dříve stačilo umět jen Javu, ale teď k tomu potřebuji znát ještě minimálně další jazyk.

Pravda. Položme si ovšem otázku, jak drahé je najmout si člověka, který ovládá J2EE Javu a někoho kdo zvládne například JavaScript? Odpověď nechám na vás...

často se uvádí slabší výkonnost skriptovacího enginu s JVM oproti nativnímu enginu samotnému. Je to dáno tím, že je potřeba provádět řadu kontrol a konverzí mezi oběma světy. Toto např. neplatí úplně pro Groovy, což je jen taková jiná Java.

Slovy klasika: to za nás vyřeší Intel

Takže k čemu já to jen využiji? I když si dokážu představit, že určité části aplikace napíši rychleji např. pomocí Groovy, tak jsem asi moc konzervativní, ale mě to zase taková výhoda nepřijde. Já mám svoji Javu rád :), takže si všechno napíšu v ní. Když to nebudu brát jen z mého osobního pohledu, tak přeci jen otázka údržby aplikace je hodně významná a s použitím více jazyků a technologií se tento problém stává těžší a komplikovanější (a tedy nákladnější). A když už budu psát část aplikace pomocí skriptovacích jazyků, tak proč už to pak nenapíšu celé jen pomocí skriptovacího jazyka?

I já mám svojí Javu rád a právě proto skriptovací jazyky vítám, ale zpět od citových výlevů k faktům. Začnu trochu ze široka. Položili jste si někdy otázku, co stojí za překotným tempem v přijímání nových syntaktických cukrátek? Já osobně si myslím, že to je právě efektivita ostatních jazyků. Jednou z největších výhod Javy, jako jazyka, byla konzervativnost a velice jednoduchá syntaxe. Rozšiřováním syntaxe Javy se všech těchto podstatných výhod zbavujeme. Přijde mi lepší nechat tento boj o efektivitu vybojovat skriptovací jazyky a ty nechat spolupracovat se starou dobrou Javou nad JVM.

Skriptovací jazyky se nehodí na všechny typy úloh, ale můžeme vzít jako příklad systém, který je potřeba podle zákaznických požadavků modifikovat (customization).

  • Uděláme jádro systému, které bude zajišťovat klíčové vlastnosti systému, bez ohledu na to, co zákazník vymyslí. To jádro bude pravděpodobně zajišťovat přístup k datům, řídit transakce, dělat audit a tak dále. Celá implementace bude v Jave.
  • Nad tím uděláme framework, který bude v kostře implementovat základní případy užití systému. Framework bude ovšem nabízet styčné body, kterými bude možné chování rozšiřovat/modifikovat. Zde už je to tak půl na půl s volbou jazyku.
  • Pro vlastní rozšíření se již přímo nabízí skriptovací jazyk a to z několika důvodů. Rozšíření může psát i člověk bez kapesního průvodce Javou v kapse, tedy konzultant. Žádný složitý setup, deploy, kompilace a další nudné věci, které zdržují. Skriptovací jazyk umožní pouze zaměření na daný problém a to bez komplexnosti v podobě zpracování výjimek, přístup do databáze a nebo nutnosti synchronizovat přístup k datům. K tomu musíme připočíst dobrou podporu skriptovacích jazyků v dnešních IDE.

Obecné použití skriptovacích jazyků vidím v tvorbě DSL (Domain Specific Language), pro které se hodí daleko více než staticky typová Java. Zkuste se zamyslet, která část vaší aplikace je ve své podstatě DSL a potom si položte otázku, jestli by nebylo efektivnější ji mít vyjádřenou skriptovacím jazykem. Ne vždy musí být skriptovací jazyk jasnou volbou, ale je to jednoduchý vzor jak určit, pro které části použít skriptovací jazyk a pro které nikoliv.

Pronajmu infrastrukturu značka: levně

V pondělí jsem si na prezentaci Romana Staňka vyslechnul plno zajímavých informací. Asi nejvíce mi utkvěla v hlavě myšlenka pronajmutí infrastruktury. Není se čemu divit i infrastruktura je služba, tak proč jí nepronajímat. V této souvislosti je v poslední době nejvíce slyšet o Amazonu jako poskytovateli virtuálního výpočetního výkonu, datového úložiště a databáze.

Amazon rozjel celkem tři zajímavé služby a to Amazon Simple Storage Service (Amazon S3), Amazon Elastic Compute Cloud (Beta) a Amazon SimpleDB (Beta). Zkusme si nyní představit, jakým způsobem takto pronajmutá infrastruktura funguje a to na příkladu softwarové firmy, jako je třeba ta vaše.

Naše firma F má zdrojové soubory, které je potřeba buildovat. Pronajme si tedy u Amazonu službu S3 jako fyzické úložiště. Zároveň si pronajme službu Compute Cloud, a dodá image s předinstalovaným systémem na správu zdrojových souborů (např. SVN) a CI serverem. Pro výsledky buildu použije jako úložiště službu SimpleDB. Na místě je otázka, co to firmě přinese.

  • nebude muset vlastnit patřičný hardware na buildovací stroje a tím pádem ani oddělení, které se o něj bude starat. Například je zbytečné, aby po dobu víkendu ležely buildovací stroje ladem a skladem. Při nárazových požadavcích, např. blížící se release, lze potřebnou službu dopronajmout.
  • Spolehlivost služeb např. záloha dat, fail over strojů je zajištěna poskytovatelem. To samé platí o bezpečnosti. Všechny tyto atributy služeb bývají podchyceny v takzvaném Service Level Agreementu, tedy jedná se o věc smluvně garantovanou.

Vybudovat takovouto infrastrukturu na vlastní pěst nen í záležitost na týden nebo měsíc. Samozřejmě za předpokladu, že software někde neztloukáte na koleni. Další ne nepodstatnou výhodou pronájmu služeb je lidský faktor. Při modelu služeb, nebudete více potřebovat lidi a nebo oddělení, které by se vám jinak o infrastrukturu staralo.

Softwárová firma by se měla zaměřit na vývoj softwaru a nemrhat prostředky na výstavbu infrastruktury, kterou nemůže udělat stejně efektivně a kvalitně jako někdo, kdo se zaměřuje pouze a jenom na infrastrukturu. Samozřejmě tyto služby jsou pořád daleko od masivního využití. Neřekl bych, že je to problém technický spíše jde o to udělat pověstný mentální kotrmelec a nebo počkat až ten kotrmelec udělá někdo jiný a v případě úspěchu jej následovat.

Nepochybuji o tom, že Roman Staněk tenhle kotrmelec udělal...

středa 12. prosince 2007

Do pranice: kontrolované vs. běhové výjimky

Napsal jsem, nebo lépe řečeno zrefaktoroval jsem, velké množství kódu, z kontrolovaných výjimek na běhové a všude to bylo ku prospěchu věci. Principiálně souhlasím s tím, že kontrolované výjimky mají své uplatněni a to tam, kde je z kontextu možné zotavení. Typickým příkladem jsou vstupy od uživatele. Těchto případů je možná 20%. Zbylých 80% jsou výjimky systémové-běhové, ze kterých se není schopen klient se v daném kontextu zotavit, příkladem budiž výpadek databázového stroje.

Největší nevýhodu kontrolovaných výjimek vidím v jejich invazivnosti do klientského API. Tato invazivnost způsobuje dva problémy: narušuje zpětnou kompatibilitu a ve většině případů vede k často se opakujícímu kódu (konverze výjimky na běhovou). Nicméně souhlasím s tím, že je potřeba mít ošetřenou práci s výjimkami, ale nemyslím si, že je nějaká extra výhoda to vynucovat kompilátorem. Naopak to spíše vede k anarchii v jejich ošetření.

I v případě běhových výjimek lze dosáhnout správného ošetření. Klíčem je centralizované místo (může to být aspekt), které se bude starat o chytání a zpracování výjimek. Další velice užitečnou technikou je použití takzvané deklarované běhové výjimky. Běhové výjimky jsou nadeklarovány v throws klauzuli, takže minimálně při pohledu na signaturu metody je vidět, k čemu může dojít.

neděle 9. prosince 2007

Pětka technologií pro budoucnost enterprise Javy

Technologie jako Spring, Hibernate a nebo Seam charakterizují nebo charakterizovaly určitý stupeň vývoje. V současnosti se jedná de facto o standardy, které lze jenom stěží považovat za žhavou novinku. Na následujících řádcích jsem se pokusil sepsat pár technologií a konceptů, které by rozhodně neměly ujít vaší pozornosti, protože v budoucnu může dojít k jejich masivnímu použití v enterprise aplikacích.

OSGi

O OSGi jste si mohli již na Dagblogu přečíst. Ve zkratce řečeno, jedná se o způsob jakým spravovat služby v řízeném prostředí. Jedná se o deployment, vyhledání a použití služby. OSGi rozhodně není žhavou novinkou, nicméně do pětice technologií pro budoucnost rozhodně patří. I přes to, že je OSGi staršího data, k jejímu zapojení v oblasti enterprise Javy dochází teprve nyní.

OSGi má v současnosti problém, že s ním nebylo v předchozích verzích enterprise Javy počítáno. To způsobuje celou řadu problémů, ale pokud se podaří nějakým způsobem začlenit OSGi do připravované J2EE 6, měla by to být zelená pro jeho masivnější použití.

AOP

AOP alias Aspektově Orientované Programovaní je tu sice nějaký ten pátek, ale k jeho masivnímu rozšíření zatím podle mého názoru nedošlo. Pokud jste o AOP nikdy neslyšeli, můžete si udělat představu z mého článku Transparentní cache pomocí AOP. Aspekty se dají využít jak pro funkčnost, která má svoje místo v produkčním nasazení, tak pro funkčnost, která nám slouží pouze v době vývoje. Díky deklarativnímu nasazení AOP je možné pohodlné řídit přesnou množinu funkčnosti, která se dostane do výsledného kódu aplikace.

Pomocí AOP například snadno vytvoříte kód, který bude trasovat počet a trvání SQL příkazů v rámci jednoho HTTP požadavku na aplikaci. AOP se dá použít k tomu, aby jste například pro testy nasimulovali chybu v zpracování požadavku a testovali zotavení-chování dané části systému. To je jenom v rychlosti pár tipů, ve skutečnosti je AOP výtah, který posunuje možnosti Javy o pořádný kus dále.

REST

O RESTu jsem nejenom psal, ale i povídal. Protože věřím, že přijde čas online služeb, přijde mi REST jako nejlepší způsob jejich integrace. Nevýhodou RESTu je špatná infrastruktura, to znamená že si zatím takřka vše musíte lepit na koleni a pokud to slepíte, pak pravděpodobně narazíte na problémy s nestandardnímy požadavky na deployment.

Gridy

Grid computing je přirozeným vyústěním požadavků na výkonné a škálující aplikace. Klíčem k úspěchu je držet se hesla rozděl data a paralelizuj zpracování. V současnosti existují dva typy gridů - datové a výpočetní. Datové gridy umožňují zpracování velkého množství dat jejich rozdělením a výpočtové gridy umožňují paralelizaci zpracování. Samozřejmě nejlepší je kombinace datového i výpočetního gridu, moje sympatie patří Terracota a GridGain.

Grid řešení lze dnes integrovat se standardy, o kterých jsem psal na začátku článku. Například Terracotu můžete použít jako efektivní distribuovanou cache (Hibernate second level cache, replikace HTTP session). GridGain lze použít například pro paralelizaci testů.

Skriptovací jazyky

Skriptovací jazyky se budou prosazovat díky jejich efektivitě a nenáročnosti. Neočekávám, že by snad měli nahradit Javu jako jazyk, ale budou používány k jejímu doplnění. Klíčové části aplikací budou stále psány v Jave a skriptovací jazyky budou sloužit k tvorbě nadstaveb např. UI vrstva aplikace a nebo k zákaznické customizaci. Skriptovací jazyky mají blíže k tvorbě takzvaných DSL, což je zkratka pro Domain Specific Languages. Díky skriptovacím jazykům půjde lépe vytvořit a používat DSL oproti staticky typové Jave.

Další výhodou skriptovacích jazyků je jejich nenáročnost na deploymentu a ladění aplikace. Žádné restarty/reloady aplikací pro načtení nových změn. Současné IDE již dnes také nabízejí velkou podporu skriptovacích jazyků jako debuggovaní, zvýrazňování syntaze a další.

Tak to je moje pětice, pokud jsem na nějaký směr či technologii zapomněl, rád se to dozvím v komentářích. Prosím nepište ovšem o konkretních implementacích (např. JBoss Seam), ale spíše o přístupech či architektonických směrech.

sobota 8. prosince 2007

Eclipse tipy a triky: inkrementální packaging

Náhodou jsem narazil na tento screencast, který ukazuje možnosti inkrementálního packagingu v Eclipse za použití JBoss Tools. Kromě komprimovaného módu zvládá i exploded (rozbalený) mód. Největší výhodu, kterou spatřuji, je možnost vlastní (custom) definice, které projektové soubory či souborové typy se mají kde ocitnout v daném výstupnim package(JAR, WAR, EAR atd.). JBoss Tools navíc umí držet automaticky projektové soubory v synchronizaci s daným packagem a s každou jejich změnou je inkrementálně přidávat. A tím pádem samozřejmě ušetřit volání Antu či Mavenu.

Plugin jsem zatím nezkoušel, čeká mě to následující tyden. Každopádně na první pohled přináši custom packaging s inkrementální synchronizací, což je vlastnost, po které jsem já osobně volal dlouhou dobu.

středa 5. prosince 2007

CZ podcast 19

Na tenhle pdocast jsem byl tak nabuzený, až byl můj záznam od druhé poloviny trochu přebuzený. Za to se omlouvám a slibuji, že se příští podcast polepšim. Taky jsem dnes slíbil Mikulášovi, že už nebudu dělat nejapné žerty na Roumenův účet a především NetBeans.

pondělí 3. prosince 2007

Neměňte jazyk, změňte infrastrukturu

Lehce jsem se orosil při poslechu posledního Javaposse podcastu. Pánové tam probírali změny do syntaxe a rozšiřování sémantiky jazyku Java. Nechci říkat, že mi všechny ty syntaktická cukrátka nejsou sympatická, ale vidím plno jiných oblastí, které by mohla Java 7 či 8 pokrýt a vývojáři by to dozajista ocenili také. Jednou z těchto oblastí je samotná infrastruktura Javy (kompilátaor, VM) , kterou lze rozšířit i bez toho, aby byla výrazně narušená zpětná kompatibilita. Tady jsou moje tipy.

Dynamický znovunačtení tříd

Každý kdo dělal webové aplikace vám potvrdí, že neustálý redeploy aplikace je peklo. Každá větší změna v třídách znamená redepoloy aplikace a to i v případě, že používáte hot swap funkcionalitu JVM. Nepředpokládám, že by byl problém rozšířit JVM o možnost dynamického znovunačtení tříd. Obzvláště když existují v tomto směru průkopníci JavaRebel Brings Class Reloading to Java.

Deklarativní modifikátory viditelnosti

Modifikátory viditelnosti (public, private, protected, implicitní) jsou nedostačující. Bylo by dobré mít možnost říci deklarativní cestou (anotace, descriptor), které třídy či metody chci exportovat k veřejnému použití. Inovátorem budiž OSGi a jeho bundle descriptory. Doufejme, že se z nich poučili všechny ty superpackage a JAMy.

Izolace uvnitř JVM

Koncept izolace uvnitř JVM je vypůjčen z Multitasking Virtual Machine. Jde o to, že více aplikací běžících v jedné VM by se mělo co nejméně ovlivňovat viz problém hostingů. To je typicky problém webových aplikací, běžících v jedné instanci JVM. Bylo by velice užitečné umožnit řízení míry ovlivnění mezi aplikacemi (nejlépe žádné). S tím souvisí i schopnost nastavení hranice prostředků (CPU, paměť, síťové IO), které může maximálně aplikace využít.

A tak by se jistě dalo pokračovat dále. Můžete si sami dosadit vaši oblíbenou funkčnost, kterou by měla infrastruktura Javy poskytovat. Bohužel obávám se, že místo investic do zlepšení infrastruktury nám ústa zalepí nějaká syntaktická cukrátka, což je jenom trochu levnější pozlátko.

pátek 30. listopadu 2007

Čas online služeb

Nedávno jsem přecházel na Linux a protože mám dva notebooky, potřeboval jsem nějakým způsobem sdílet soukromou poštu a RSS agregátor. Po všech peripetiích a pokusech jsem nakonec skončil u Googlu a jeho aplikací Gmail a Reader. K tomu musím připočíst i další Google služby, které používám pravidelně - Notebook, Blogger a nepravidelně Analytics, Picasa a Docs. Když se podívám na strukturu těchto služeb, pak mi Google poskytuje: emailovou poštu, RSS agregátor, památníček na odkazy, možnost tvorby dokumentů a prezentací (články, fotoalba atd.).

Valnou většinu těchto služeb jsem měl dříve lokálně a poskytovaly mi je desktopové aplikace. Google si uvědomil, asi jako spousta jiných, že je možné všechny tyto služby nabízet online. Na rozdíl od ostatních tuto myšlenku dotáhnul nejdále. Podle jeho přístupu můžeme odvodit společnou charakteristiku pro online služby.

  • 1.)přístupnost z webového prohlížeče s minimálními požadavky
  • 2.)sdílení dat
  • 3.)částečná schopnost běžet offline
  • 4.)integrovatelnost - spolupráce s dalšími službami

Přístupnost z webového prohlížeče, bez zvláštních nároků na jeho vybavení, je základní charakteristikou online služby. Služba využívá na plno konceptu all-in-one, kdy prohlížeč nabízí vše potřebné pro její ovládání. Žádná instalace, upgrade, konfigurace. Díky webovému prohlížeči je zaručena široká dostupnost služby - není potřeba žádný speciální program-klient.

Google online služby jasně ukazují, že je důležité minimalizovat požadavky na webový prohlížeč. Každá minimální nutná součást, která vyžaduje instalaci, představuje celou řadu problémů - bezpečností počínaje a interoperabilitou konče. Služba vyžadující na klientu takový Flash či Javu se může spolehnout, s pravděpodobností hraničící s jistotou, že na mobilních zařízeních utře nos.

Služba nám umožňuje sdílení dat, které její pomocí spravujeme. Díky tomu, že jsou data sdílena přes službu, stačí k jejich dosažení opět pouze webový prohlížeč.

Částečná schopnost služby běžet offline sice dnes trochu odporuje zvýšeným požadavkům na prohlížeč, nicméně v budoucnosti by to zas až takový problém být nemusel. Třeba výše zmíněný Reader je možné přepnout do offline módu. Tím je možné pročítat jednotlivé kanály (feedy) pročítat s odpojeným prohlížečem od internetu.

Integrovatelnost umožňuje služby kombinovat do větších celků a nebo je adhoc využívat. Výsledná řešení přesahují rámec služby, například služba kalendáře se může nejen použít v kombinaci s poštou, ale můžete kolem ní postavit celou vlastní službu, která bude sloužit k časovým rozvrhům.

Z pohledu uživatele online služby přinášejí spoustu výhod a také několik vlastností, které je potřeba dobře zvážit. Zásadní změnou u online služeb je fakt, že většina rizikových faktorů leží na straně poskytovatele, o jehož infrastruktuře nemá uživatel žádné informace. Vzájemný vztah je založen na důvěře, případně ošetřen zákonem či smlouvou.

Někdo cizí má přístup k datům, které vlastním. Nevím nic o tom, jak jsou data zabezpečena, kdo další k nim má přístup a ani jaké procesy a postupy tyto data chrání. Znalost charakteru dat a jejich obsahu se na mě může zaměřit, například cílenou reklamou. Díky provázání služeb mezi sebou funguje takzvané SSO (Single Sign-On), kdy se autentizovaný uživatel považuje za autentizovaného i v dalších službách (nemusí prokazovat svou identitu). To ovšem znamená, že prolomení se do jedné služby otevírá částečně dveře do zbylých služeb. Záloha dat a nebo failover jsou rovněž faktory, které má v režii poskytovatel služby.

Poskytovatelům umožňují online služby daleko lepší kontrolu. Poskytovatel může bez větších problémů provádět údržbu služby. Další výhodou je možnost selektivně službu zapínat a vypínat např. pouze pro platící zákazníky. Poskytovatelé mohou lépe monitorovat a vyhodnotit chování uživatelů služeb a podle toho službu dále zlepšovat.

Podle mého soudu budou online služby pomalu, ale jistě, vytlačovat lokální aplikace, které používáme pro běžnou práci a nebo zábavu. Profitovat z toho budou jak uživatelé, tak i poskytovatelé. Jenom doufejme, že tu v budoucnosti nebude jedna jediná firma, která bude mít takřka monopol na většinu služeb...

úterý 27. listopadu 2007

Závislosti v Mavenu

Závislosti jsou jednou z vlastností, kterou na Mavenu oceňuji. Bohužel závislosti, především ty tranzitivní, mají i některé nevýhody. Pro neznalé Mavenu, tranzitivní závislosti jsou ty závislosti, na kterých váš kód závisí nepřímo. Příklad to osvětlí, máme komponentu A, která závisí na komponentě B a ta na C. Z pohledu A, je B přímá závislost a C nepřímá závislost.

Možná si říkáte, kde je problém. Problém nastane ve chvíli kdy se vám začnou do projektu tranzitivně dostávat závislosti, které nejsou potřeba (nechtěné) a nebo dojde ke konfliktu verzí. Klasickým příkladem je Commons Logging 1.1. Pokud se rozhodnete, že váš kód bude pro logování používat Commons Logging a zadefinujete tuto závislost, máte rázem problém. Problém se jmenuje nechtěná závislost na Servlet API 2.3, kterou tam zanese Commons Logging. Commons Logging má tuto závislost špatně nadefinovanou resp. je tam špatný scope. Podle scope se Maven rozhodne v jakých classpath je závislost potřeba. Pokud není uveden scope, je závislost propagována do všech classpath. To má pro vás ten důsledek, že se Servlet API 2.3 dostane například do výsledného packagingu což může být WAR, kde jistě nemá co dělat.

Dalším problém mohou být licence. Tranzitivní závislosti mohou zavléct do výsledného produktu licence, které nejsou úplně kompatibilní s licenční politikou produktu. No a aby těch možných konfliktů nebylo málo, tak si představme situaci kdy máme komponentu A, která závisí na komponentě X a Y. Jak X tak Y závisí na Commos Logging nicméně každý definuje jinou verzi této knihovny.

Pro ovlivnění tranzitivní závislosti máme pouze omezený výčet možností. Můžeme použít exclusion, kterým lze definovat, která tranzitivní závislost se má ignorovat. Další možností je využít znalosti Maven algoritmu pro řešení konfliktu verzí, takzvanou nejkratší cestu. Tím můžeme určit společnou verzi pro X a Y, a to tak že A bude záviset na konkrétní verzi Commons-Loggig. Bohužel všechny tyto možnosti nejsou příliš pohodlné pokud to musíme dělat pro více závislostí. Navíc je potřeba neustále brát na zřetel fakt, že jakákoliv závislost může zavléct něco nechtěného.

Když se nad tím zamyslím, tak tyto problémy nejsou chybou Mavenu, ale důsledkem špatné definice závislostí. Maven s tím těžko může něco dělat, kromě toho že poskytne prostředky pro jejich odhalení. Každopádně je tu problém, který je potřeba řešit. Jedině možné řešení je podle mého názoru vzít si závislosti kompletně pod svou kontrolu a to znamená:

  • Odpojení interní artefakt repository od internetu. Tím se nám do repository nedostane žádná závislost, kterou tam vlastnoručně nedáme. Bohužel tím taky odstřihneme Maven od nejnovějších pluginů, které jsou rovněž získávaný přes repository.
  • Post zpracování všech POM souborů v repository. To je práce, která může být pouze částečně zautomatizovaná. Nechtěné závislosti musí být ovšem vyhledány a opraveny ručně. Pro odstranění kolize verzí je možné využít takzvaný management závislostí. To znamená, že u všech tranzitivních závislostí se odstraní jejich verze případně se nahradí proměnnou. Její hodnota se nadefinuje v hlavním projektovém POM souboru, případně v profilu.

Když to vezmu a kolem, tak je s podivem, že při oblíbenosti Mavenu nevznikají komerční repository, které tyto služby profesionálně nenabízejí. Ty by mohly garantovat jednak konzistenci (verze, licence) daných stromů závislostí a jednak jejich původ - podepsané JARy. Navíc by zajistily to, že jsou k dispozici zdrojové soubory a javadoc závislostí. Další pěknou vlastností by byla možnost verzování repository. To znamená mít možnost různého stavu repository v čase a možnost se k nim vracet. Když vám dnes někdo prodává infrastrukturu jako je verzovací sýstém a nebo bug tracking systém či wiki, tak proč by nemohl nabídnout i artefakt repository.

středa 21. listopadu 2007

Spring 2.5 je venku

Spring 2.5 se oficiálně dočkal uvolnění. Verze 2.5 je stále kompatibilní s Javou 1.4.2+ a J2EE 1.3+. Pokud chcete rychle vstřebat největší novinku, což je podle mého názoru zavedení anotací pro konfiguraci IoC kontejneru, doporučuji článek What's New in Spring 2.5: Part 1, kde najdete vyčerpávající popis. Další novinkou kolem Springu je přejmenování společnosti Interface 21 na SpringSource, která stojí komerčně za Spring frameworkem.

Novinky verze 2.5

  • Full Java 6 and Java EE 5 support (JDBC 4.0, JTA 1.1, JavaMail 1.4, JAX-WS 2.0)
  • Full-featured annotation-driven dependency injection, including support for 'qualifiers'
  • Support for auto-detecting application components in the classpath and auto-configuring them as Spring managed objects
  • A new bean name pointcut element in AspectJ pointcut expressions
  • Built-in support for AspectJ load-time weaving based on the LoadTimeWeaver abstraction
  • New XML configuration namespaces "context" and "jms", for maximum convenience
  • A completely revised integration test framework, with first-class support for JUnit 4 and TestNG
  • A new annotation-based controller model for Spring MVC supporting Servlet and Portlet environments
  • Extended SimpleJdbcTemplate functionality, including support for named SQL parameters
  • Officially certified WebSphere support
  • The packaging of Spring Framework jars as OSGi-compliant bundles out of the box
  • The ability to deploy a Spring ApplicationContext as a JCA RAR file, for headless application modules
  • JCA 1.5 message endpoint management, for Spring-managed JMS and CCI message listeners

Další články o Spring frameworku na Dagblogu

neděle 18. listopadu 2007

Listopadový CZJUG - proč nezůstat doma?

V pondělí 26.11.2007 od 18h proběhne další setkání CZJUG. Pokud si kladete otázku přijít či nepřijít, pak jsem pro vás připravil několik důvodů proč se nevyplatí zůstat doma.

  • V první řadě nás čekají dvě velice zajímavé prezentace a to Swing in Action a Google Guice - Dependency Injection. Já osobně se o trochu více těším na druhou zmiňovanou. Google Guice nabízí totiž alternativu k Spring IoC kontejneru.
  • Bude pizza! Rozvědka sice nic nehlásí o sličných hosteskách, nicméně v nejhorším něco sebereme na Karláku v parku ;-).
  • Patologická latence u AVC jistě způsobí, že záznam neuvidíte dřív jak za půl roku.
  • Neoficiální ukončení akce opět proběhne v některé z přilehlých restaurací a putyk. Této trachtace se povětšinou účastní pitoreskní skupina pisálků mnou počínaje a Vlastou konče.

sobota 17. listopadu 2007

Případ Android

Android logoGoogle v průběhu tohoto týdne spustil pekelný sled událostí. Prstem na spoušti se stalo oznámení platformy Android pod záštitou The Open Handset Alliance. Android je zajímavý nejen z technického hlediska, ale především kvůli bezprecedentnímu přístupu k Jave, který může znamenat její samotné rozštěpení. Zkusme se tedy podívat na všechny aspekty případu Android.

Aspekt technický

Android je open source stack pro běh aplikací cílených na mobilní zařízení. Skládá se ze třech základních vrstev: operační systém, middleware pro běh aplikací a základní (systémové) aplikace.

  • Základem celé platformy je Linux Kernel verze 2.6 (doufám, že na hardwaru daných mobilních zařízení bude fungovat lépe než na mém notebooku ;-), který slouží jako vrstva pro přístup k hardwaru.
  • Nad kernelem je postavená hradba céčkových knihoven poskytujících základní služby a rozhraní pro vyšší vrstvy. Mezi základní služby patří 2D/3D (včetně podpory akcelerace) knihovna, embedded relační databáze a webový prohlížeč a nebo knihovna pro práci s audio/video formáty. Hned vedle leží takzvaný runtime což je virtual machine a sada základních systémových API.
  • O patro výše sedí aplikační framework, který poskytuje základní API například pro tvorbu uživatelského rozhraní nebo sdílení dat mezi aplikacemi. Zároveň umožňuje fungovat jako service registry, kde se mohou registrovat jednotlivé služby, které jsou nabízeny k další konzumaci.
  • Úplně na vrchu sedí základní aplikace jako emailový klient, mapa, kontakty atd.

Zatím jsme mluvili v abstraktních pojmech jako API, knihovna, virtual machine a teď se na ně podíváme detailněji. Ona zmiňovaná virtual machine se nazývá Dalvik a je speciálně odladěná pro mobilní zařízení s ohledem na co nejmenší paměťovou náročnost. Každá aplikace běží ve svém vlastním procesu ve vlastní instanci VM. Všechny krabičky z obrázku, které jsou vybarvené modře, jsou psané v jazyce, který je přeložen do meziformátu, který je VM interpretován.

Aspekt politický

Poznámka: nejsem právník.

Bystrého čtenáře jistě napadne paralela s programovacím jazykem Java a JVM (Java Virtual Machine). Jenže Android není ani Java, ani JVM, dokonce ani J2ME a ani J2SE. Důvod je jednoduchý a jmenuje se licence Androidu. Ten je totiž kromě kernelu, který je pod GPL v2, vydán pod Apache Software Licence (dále ASL) a to je kámen úrazu.

Všechny klíčové části, které mohly být použity z platofrmy Java, jsou pod GPL v2 licencí a Sun dobře ví co dělá. Oblast mobilních zařízení je jedna z mála, ve kterých mu Java generuje zisk a proto bylo rozumné držet si určité věci pod kontrolou. Google se ovšem zachoval jako chytrá horákyně. Nemají JVM, ale Davlik VM, který zpracovává Dalvik Executable (.dex) formát což je mírně modifikovaný byte code produkovaný standardním java kompilátorem.

Vývojář tedy píše klasicky ve vývojovém prostředí pro Javu. Před tím než spustí aplikaci v Androidu, je potřeba zavolat speciální konvertor, který převede byte code do Davlik formátu. Další zajímavostí je, že core API Androidu obsahuje každému vývojáři dobře známe knihovny ze standardní Javy jako java.lang.Object a další. Při bližším pohledu člověk zjistí, že to nejsou knihovny všechny. Například chybí knihovny pro tvorbu grafického rozhraní - Swing a AWT.

Je na místě ptát se, jak může Android vzít API Javy a prostě z něj vyextrahovat co potřebuje a dát to pod jinou licencí. Může jednoduše, protože na Core API se uplatňuje takzvaná classpath výjimka. Výjimka existuje proto, aby programy využívající toto API nemusely být vydávané pod GPL v2 licencí a zároveň, aby mohly vznikat další open source implementace Javy s jiným typem open source licence.

Roumenova interpretace:

Google ale vubec nepouziva Sunovsky kod (pouziva kod z projektu Harmony a tim padem je jedno pod jakou licenci jsou zdrojove kody Sunovskeho API pro Java SE nebo Java ME). Navic Classpath exception slouzi pouze k tomu, aby aplikace pouzivajici OpenJDK nemusely byt licencovane pod GPL v2, neumoznuje vsak volbu licence implementacim Javy odvozenych od OpenJDK. Naopak implementace Javy odvozene od OpenJDK MUSI byt licencovane pod GPL v2.

Jinymy slovy, Google nema pravo vzit API Sun Javy, vyextrahovat co chce a publikovat pod jinou licenci jak ty pises. Muze vsak urcite pouzit kod projektu Harmony, kdyz zachova licenci, coz udelal. Classpath vyjimka neexistuje kvuli tomu, aby umoznila implementace Javy s jinym typem open source licence. Implementace Javy s jinym typem open source licence existovaly uz davno pred tim nez OpenJDK bylo licencovano pod GPL v2 s classpath vyjimkou (Harmony, GCJ, atd.). Tomu zadna licence nezabrani, existuji ale jine ochranne prvky (copyright pro ochranu zdrojovych kodu - aby nikdo nekopiroval Sunovsky kod, trademark pro ochranu znacky Java a loga Java a pak jeste patenty pro jednotlive principy, kterych ale Sun z principu nezneuziva a jen je sbira kvuli obrane proti firmam, ktere se rady soudi). Jinym implementacim Javy, ktere nevychazeji z OpenJDK, se nemuze rikat "Java" kvuli trademarku a proto Google na tento trademark nema u Androidu opravneni. OpenJDK umoznuje vytvaret derivaty pouze pod licenci GPL v2 a classpath exception s ostatnima implementacema Javy nema co do cineni.

Přesně tohoto faktu využil Google, který nevzal originál zdrojáky Sunu, ale ty z projektu Harmony, který jsou již pod ASL licencí. Zajímavé je zaptrát po důvodech, které vedly Google k tomu, že byl Android licencován pod ASL. Google zřejmě vsadil na to, že ASL licence umožňuje dobře kombinovat open a closed source projekty. Celkem detailně je to rozebráno v článku Why Google chose the Apache Software License over GPLv2 for Android.

Aspekt sociální

Android si vzal z Javy jenom to co se mu hodilo zrovna do krámu (syntaxe, částečně API). To by mohlo ovšem znamenat nebezpečný precedent do budoucna. Klidně se může stát, že se bude opakovat historie v podobě Mictosoft Javy a vznikne něco co se bude tvářit jako Java, ale Java to ve skutečnosti nebude. Bylo by špatné, kdyby mělo dojít k nějakému štěpení Javy. V případě Androidu je to nebezpečné především díky jeho síle, protože je potenciálně mířen na obrovský segment mobilních zařízení. Bude zajímavé sledovat, jak se k celému problému postaví Sun, který nevydal zatím žádné oficiální stanovisko.

Další zajímavé články k tématu

středa 14. listopadu 2007

CZ podcast 18

Pohodlně se usaďte, dejte si sluchátka na uši, otevřete láhev "božolé" a nechte se orestovat podcastem číslo 18.

Distribuované CVS? Proč ne

Píšu CVS, ale myslím ve skutečnosti distribuovaný version control systém (zkráceně DVCS).

CVS, SVN a další systémy jsou centralizované. Je pouze jedna lokální repository, ke které se přistupuje. Pokud chcete udělat změnu, potřebujete patřičná přístupová práva. Pokud chcete dělat paralelní vývoj, např. potřebujete současně spravovat hlavní vývojovou linii a zároveň historickou (fixy), musíte si v těchto systémech udělat (fork) větev (branch). Rozvětvení je jedinou možností jak paralelně pracovat nad jednou repository. Pokud potřebujete spojit práci ve dvou větvích musí dojit k jejich spojení (merge). Každý kdo to kdy dělal, určitě ví jak je to bolestná operace.

Jednou z typických situací, která se špatně řeší s nástroji jako CVS, je případ kdy dva vývojáři pracují nad jednou sadou souborů paralelně, a v určitý okamžik by potřebovali změny od sebe navzájem. Mají dvě možnosti: manuálně si vyměnit změny a aplikovat je a nebo změny promítnout přímo do repository. Obě možnosti jsou bolestivé. V prvním případě je to především nutnost udělat manuální diff nad změnami a následně jeho aplikaci, což je činnost v pravdě nešikovná. V druhém případě může dojít k zanesení neodladěných změn, které mohou dočasně způsobit problémy (centrální repository byla použita pouze pro synchronizaci mezi vývojáři).

Distribuovaný version control systém (DVCS)

Předchozí povídaní mi umožnilo vytvořit oslí můstek k DVCS. Distribuované verzovací systémy se od těch centralizovaných liší v tom, že namísto jedné centrální repository může existovat repositoří více. Způsob práce se liší od centralizovaného přístupu v tom, že vývojář si může lokálně zkopírovat repository a nad ní začít pracovat. Může dělat commit, update a další dobře známe operace. Tyto změny jsou propagovaný do jeho lokální repository. Ve chvíli kdy se rozhodne, že jeho repository resp. stav práce je v patřičném stavu, provede se merge jeho lokální repository a jiné repository.

Na našem předchozím příkladu si popíšeme jak je možné jej řešit s DVCS. Máme hlavní vývojovou repository. Z ní si udělá vývojář číslo jedna lokální kopii, vývojář dva udělá to samé. Ve chvíli kdy se potřebují synchronizovat, využijí DVCS merge mezi svými lokálním repositořemi. Všechny změny mají u sebe lokálně. Po dohodě může jeden z nich pronést změny (klasický commit) do centrální vývojové repository.

Možné modely práce s DVCS popisuje článek Workflows, který je součástí dokumentace DVCS systému Bazaar. Článek doporučuji k nakouknutí, protože vše je pěkně ilustruje na obrázcích. Modely v něm popsané jsou následující:

  • Solo
  • Partner
  • Centralized
  • Centralized with local commits
  • Decentralized with shared mainline
  • Decentralized with human gatekeeper
  • Decentralized with automatic gatekeeper

Mě osobně zaujaly poslední dva a vysvětlím proč. Decentralized with human gatekeeper je velice vhodný pro open source projekty. Představte si situaci, kdy pracujete na open source projektu, ale nemáte práva k pronesení změn. V případě DVCS si správce open source projektu vytáhne změny z vaší lokální repository, provede merge a pokud je vše v pořádku, pronese je do centrální repository. Tento přístup razí například Jason Van Zyl jakožto hlavní vývojář projektu Maven viz email ve vývojářském mailling listu (GIT je konkrétní DVCS).

For anyone who wants to make changes to Maven but doesn't have access I am going to setup a GIT repository to try and enable some distributed development. After using GIT for about a week I'm having a hard time using SVN but obviously we're not going to be switching anytime soon. But for anyone who has patches or wants to try and work with me to get changes in I am going to try this method of publishing Maven as a GIT repository which will allow anyone to clone the repository and work on any changes you like in a controlled way. Once you clone you can commit changes to your own copy of Maven and do whatever you like. Then in order for me to see your changes I can simply pull from your originally cloned repository to a branch on my side and merge. Merging is sooooooo easy with GIT. So easy in fact that it makes you wonder how SVN got it so wrong and makes it so painful compared to GIT.

Obdobný model se používá například pro Linuxové jádro. Filozofii DVCS pěkně popisuje Lins Torvalds v mailu clarification on git, central repositories and commit access lists, kde se snaží vysvětlit přínos DVCS pro vývoj desktopového systému KDE.

Druhý model práce s DVCS, nazvaný Decentralized with automatic gatekeeper, mě zaujal z toho důvodu, že je v něm integrován takzvaný delayed commit. Tedy commit, který projde až při splnění určitých podmínek, například projdou testy, někdo udělá review apod. Tento přístup se hodí v čase před releasem, kdy je potřeba každou změnu důkladně zvážit, aby nebyla zavlečena nějaká chyba.

each developer has their own branch or branches, plus read-only access to the mainline. A software gatekeeper (e.g. PQM) has commit rights to the main branch. When a developer wants their work merged, they request another person to review it. Once passed review, either the original author or the reviewer asks the gatekeeper to merge it, depending on team policies. The gatekeeper does a merge, a compile, and runs the test suite. If the code passes, it is merged into the mainline.

Decentralized with automatic gatekeeper

DVCS má jak výhody, tak nevýhody a asi určitě se nehodí pro všechny typy projektů. Na druhou stranu musím dodat, že i distribuované verzovací systémy se dají používat stejným způsobem jako centralizované a do těch centralizovaných se naopak začínají přidávat vlastnosti těch decentralizovaných (SVN a lokální commit). Pokud vás DVCS přístup zaujal, pak bych doporučoval k přečtení ještě následující dva články z ruky spoluautora SVN.

sobota 10. listopadu 2007

Měním operační systém

Asi dva měsíce mi leží na stole v nerozbalené krabici nový notebook. Uvedení do provozu jsem odkládal dílem kvůli času a dílem protože jsem čekal na vhodnou linuxovou distribuci (syndrom příliš nového hardwaru). Příští týden budu mít dovolenou a protože je tu Gutsy Gibbon (to není moje milenka, ale kódové označení Ubuntu 7.10), tak mi nic nebrání v migraci. Ač jsem čistokrevný Windows uživatel, rozhodl jse s konečnou platností přejít v práci na Linux a to přesto, že mi Windows plně vyhovuje.

Poznámka na okraj ohledně volby distribuce. Ubuntu jsem zvolil, protože mi přišlo jako začátečníkovi nejpřívětivější. Druhým důvodem byl fakt, že Ubuntu používá několik kolegů, takže mi mohou poradit. Moje důvody k opuštění Windows jsou směska ideologických, pocitových a jiných iracionálních důvodů. Ve zkratce:

  • V celé firmě je jako standard Windows. Moje osobní přesvědčení je vybočovat z řady pokud mohu a obohacuje mě to.
  • Je jen málo radostí, které geeka uspokojí více než hrátky s něčím tak komplexním jako je nepoznaný hardware/software. Linux je pro mě ideálním prostředkem pro rozšíření mikro i makro znalosti v oblastech mě mlhou obestřených.
  • Libí se mi design GNOME. K tomu musím připočíst compiz-fusion pro akcelerovaný 3D desktop, po kterém jsem vždycky slintal.

  • Všichni linuxáci mi tvrdí, že práce se souborovým systémem je daleko rychlejší.
  • Valná většina nástrojů, které používám pro svou práci, existuje i pro Linux. Nejsem tedy s Windows nijak zásadně spjatý. Osobně mám malinko obavy z toho, že mi bude chybět Total Commander a PsPad. V případě prvního mi snad stejný komfort poskytne Krusader a v případě druhého se nechám překvapit. O Firefoxu, Thunderbirdu, Eclipse či OpenOffice nemluvím, protože je již používám nyní.

Doufám, že tu za týden nebudu psát jako Lukáš Křečan na téma Jak jsem nepřešel na Linux. Pokud si chcete Ubuntu vyzkoušet bez nutnosti instalace, pak doporučuji live distribuci a nebo některý VMware image. Ja jsem našel jeden s Ubunut 7.10 a předinstalovanou Javou 6 a Eclipsem 3.3.

středa 7. listopadu 2007

Mikro a makro znalosti

Kdysi dávno jsem znal všechno. Dělal jsem dynamicky generované stránky pro webovou aplikaci. Můj svět byl ohraničen magickou kombinací XML, XSLT, HTML, JavaScript a CSS. Postupem času jsem přibalil Javu na straně serveru. Můj svět se stal trochu složitějším, ale pochopit, jak konvertovat číslo na řetězec, nebylo příliš náročným mentálním cvičením. Tak to šlo dál a dál. Dneska jsem jako architekt zodpovědný za infrastrukturu našeho produktu a můj svět se rozšířil o všechny ty J2EE technlogoie a buzzwordy.

Z hlavy se mi sice vykouřilo, jakým způsobem se zapisuje selektor v CSS pro třídu a identifikátor, ale vím, že něco takového existuje. Nevím přesně, jak se jmenuje thread safe implementace mapy s výkonostně optimalizovaným čtením, ale na požádání to mohu dohledat. Nikdy jsem nepracoval s EntityManagerem z JPA, ale vím, že koncepčně odpovídá Session z Hibernate, takže můžu komukoliv vysvětlit, jak se s ním pracuje. Takto bych mohl pokračovat dál, ale to není účelem.

Předchozími řádky jsem chtěl říci: "čím víc se toho dozvídám, tím méně toho vím". Případně: "čím toho víc vím, tím méně to znám do detailu". Z mikro znalostí, které jsem měl, již moc nezůstalo. Zato mám hromadu makro znalostí a ty mikro znalosti jsem schopen vstřebat. Jsem exot a nebo to máte stejné?

Volně navazující reakce:

pondělí 5. listopadu 2007

Spring != XML

Myslíte si, že Spring rovná se tuna XML? Pak máte poněkud zastaralé informace. Ostatně i v dřevních dobách tomu tak nebylo. Od verze 2.5, v těchto dnech je k dispozici RC1, přináší Spring podporu anotací, kterými lze řídit IoC kontejner. Právě k anotacím a obecně postoji ke konfiguraci Springu vyšly dva zajímavé články od Jurgena Hoellera a Roda Johnsona.

If you think that Spring = XML it's time to rethink. (It was never strictly accurate, in any case, as the Spring core container has always used its own Java metadata, and doesn't know about XML or any other representation.)

This brings us to an important philosophical principle: our mission with Spring is to provide the best component model for enterprise Java, setting the standard for flexibility to meet complex requirements, and providing a comprehensive solution to real-world problems. We don't believe that there is any one size fits all model for configuration, and we believe in accommodating choice, within our strong, extensible model.

O verzi 2.5 si můžete přečíst v článku Spring 2.5 - podpora anotací, testovací framework a další. V rámci našeho programu vzdělávání budu mít na téma Spring 2.5, a speciálně na anotace, prezentaci. Možná to vydá na i větší článek na blog...

středa 31. října 2007

Neagilní open source projekty

Mám rád open source knihovny. Ke svojí práci používám řádově desítky až stovky open source knihoven. Nebudu zde sepisovat všechny výhody open source, nýbrž vypíchnu jednu nevýhodu, která mě mě neskutečně irituje. Onou nevýhodou je malá agilnost ve vztahu ke komunitě. Alespoň moje zkušenost je negativní.

Nedávno jsem potřeboval nějaký fix v Hibernatu a v issue trackeru pro to existoval záznam. Sedl jsem tedy, fix napsal, přidal unit test a to všechno jsem společně s diffem přilepil k onomu záznamu. Po nějaké době bez odpovědi jsem se naštval a poslal to přímo člověku odpovědnému za danou komponentu. Ani od něj nedorazila žádná odpověď. Další příklad. O víkendu dorazila míra ohýbání DbUnit hranice, kdy jsem byl nucen sáhnout přímo do zdrojáků a rozšířit jej. Poučen z předchozích nezdarů jsem rovnou patch poslal jednomu z autorů DbUnitu s připojeným vysvětlením o co se jedná. Opět žádná odpověď.

Nevím jestli jsem měl smůlu na projekty, ale podobných malých zkušeností jsem udělal více. Překvapující je to především u Hibernatu, protože člověk by očekával, že v zádech s Red Hatem bude o podporu postaráno. Marná sláva. Vzhledem k tomu, že jim z toho asi netečou peníze, tak není ani podpora. Abych byl upřimný, zaznamenal jsem i pozitivní zkušenost. Nedávno jsem reportoval jednu chybu ve Springu a odpověď přišla velice rychle.

Věřím, že Hibernate (JBoss ;-) je jenom výjimka potvrzující moje soukromé pravidlo. To pravidlo zni: pokud za projektem nestojí někdo v něm komerčně zainteresovaný, je projekt agilní jak lidovci v kauze Čunek (pro neznalé politických reálií - přístup mrtvého brouka). Firma která za projektem stojí, má přirozeně zájem na tom, aby byly služby (dokumentace, podpora/konzultace, práce s komunitou) kvalitní. Důvod je ten, že nic jiného ani v případě open source vydělávat nemůže.

V případě, že za projektem nikdo komerčně nestojí je jenom otázka času, kdy to s projektem začne jít z kopce. To není chyba autora(ů) toho projektu, protože na to přirozeně nemusí být čas ani prostředky. Čest výjimkám... Řekl bych, že cesta k větší agilitě open source projektů by mohla vést přes zpětné zainteresování firem, které daný open source komerčně využívají. Určitou část pracovní doby by měl vývojář vyhrazenou na to, aby mohl zpětně přispívat do open source řešení, které firma využívá. Vznikla by tak přirozená vazba „komerčně zainteresovaný“.

pátek 26. října 2007

Potřebujeme silné nástroje

Dnes jsem si v jedné nejmenované diskusní skupině přečetl, že vizuální návrháře nepatří do IDE, protože jsou často zneužívány v rukouch méně zkušených vývojářů. Tento názor je odvozen podlé mého soudu z ještě obecnější teze, a to že nástroje, které se snaží zakrývat komplexnost dané technologie jsou špatné, protože vedou k špatnému používání dané technologie. Já osobně tento názor nesdílím a považuji jej za jeden z velkých mýtů přeživších z dob špatných HTML editorů. Na následujících řádcích vám zkusím nastínit proč.

Skrývání komplexnosti vývoje je právě ten důvod proč používáme IDE (vývojová prostředí). Kdyby byla tato komplexnost vývoje malá, používali bychom dodnes textový editor a kompilátor ovládaný z příkazové řádky. Dnešní vývoj je ohraničen mantinely jako znovupoužitelnost, standardizace a dalšími. Ty mají za jediný cíl posunout celý proces vývoje dál, výše rychleji s co nejnižšími náklady.

Z tohoto důvodu jsou dnešní programy protkané různými abstrakcemi a technologiemi, které řádově zvyšují jeho složitost a tím pádem se zvyšuje i komplexnost vývoje. IDE by nám měly umožnit držet tuto komplexnost na přijatelné úrovni vzhledem k naší znalosti kontextu. Zkušený a nezkušený vývojář má na IDE různé nároky a IDE by mělo umožnit stejnou efektivitu oběma. V případě méně zkušeného vývojáře to mohou klidně být různí průvodci (wizzardy) pro vytipované případy užití (nová stránka, přechod mezi stránkami, mapování entity) a nebo vizuální editory. Zkušenému vývojáři budou stačit méně specifické prostředky jako editor kódu.

IDE by se rozhodně nemělo snažit upřednostňovat jeden způsob na úkor druhého, rozhodně ne z důvodu možného zneužití dané technologie. Ta jde totiž zneužít bez ohledu na jestli použijete vizuální návrhář a nebo to napíšete ručně. Dnešní IDE si vzala lekci z vizuálních HTML editorů přelomu tisíciletí a nesnaží se pouze o co největší efektivitu, ale i o to, aby vývojáře částečně vedly k správnému používání dané technologie.

Samozřejmě ne vše je úplně ideální. V oblasti IDE pro platformu Java je znát rozdílná filozofie jednotlivých produktů. NetBeans jsou vhodným nástrojem pro méně zkušené vývojáře, naopak Eclipse a IntelliJ IDEA je vhodnější pro zkušenější uživatele. Kdyby bylo možné tyto tři IDE spojit dohromady, získali bychom velice silný nástroj pro skrývání komplexnosti v závislosti na úrovni znalostí vývojáře.

Reakce

středa 24. října 2007

Do pranice: Spring Web Flow a nebo JBoss Seam

Právě jsem s naším UI architektem rozebíral dilema, jaký framework zvolit pro naš webový front end. Celá diskuse se se točila kolem Spring Web Flow (dále SWF) a Jboss Seam (dále Seam). Oba frameworky nabízejí přibližně stejné možnosti a tak jsme sklouzávali k drobným nuancím, které alespoň pro mě vyznívají ve prospěch SWF.

Pokud jste ani o jednom z frameworků neslyšeli, pak Vás v případě SWF odkážu na článek Vlasty Vávrů Spring web flow - framework pro management toku web aplikace a v případě SEamu k Petrovi Ferschmannovi na jeho přednášku Seam (a JSF).

Pro nás je důležité, že oba web frameworky nabízejí takzvané konverzace neboli definice toku aplikace. Konverzace je několik request/response cyklů, které jsou z pohledu aplikace jedním logickým celkem např. objednávka (vyplnění objednávky, kontrola dat, volba dopravy, způsob platby, preview, odeslání k vyřízení). Oba dva frameworky lze také integrovat se Springem a to je důležité z toho důvodu, že aplikační logika je z valné většiny skládána Springem.

Co mi u obou frameworků naopak chybí, je větší podpora ve vývojových nástrojích. Oba mají podporu pouze pro Eclipse, škoda že na tom nic nezmění, alespoň pro SWF, oznámená Spring Tool Suite.

Seam

Po mém soudu má Seam dvě zásadní vlastnosti, které pokládáte buďto za výhodu, nevýhodu a nebo minimálně za kontroverzi. Seam vede k masivnímu používání anotací a k obcházení controller/view helper komponenty. Abych byl spravedlivý, pak musím dodat, že i Seam nabízí xml konfiguraci. Na kolik je ekvivalentní anotacím nedokážu posoudit. Controller/view helper je obejit tím, že do se modelové třídy přimo nastavují/vyzvedávají z aplikační logiky. S tím už mám trochu větší problém z hlediska architektury neboť se aplikační logika ohýbá pro potřeby web frameworku. Protože je ta samá logika vystavená přes REST, pak toto svázání přináší problémy.

Výhodu Seamu vidím v tom, že se skrze WebBeans stane J2EE standardem. To přinese rozšíření konceptů, které Seam představil a z toho vyplývající plusy. Abych nezapomněl early draft WebBeans specky je k dispozici, případně si můžete přečíst sérii článků Web Beans Sneak Peek, které představil dvorní autor Gavin King.

SWF

SWF nabízí tři velice zajímavé vlastnosti, které použijeme. První je programové rozšiřování konverzací a programové ovládání (integrační testy). Druhou výhodou je fakt, že SWF je mnohem benevolentnější k volbě view technologie (JSF, Spring MVC, Struts). Třetí výhodou je jako u většiny Spring projektů Open Closed princip, to je pro nás důležité z toho důvodu, že máme stávající framework, který musí spolupracovat.

Seam ani jednu z těchto vlastností pořádně nepodporuje. Řekl bych, že je to způsobené jeho zaměřením. Seam už pomalu přechází do roviny aplikačního frameworku, viz například podpora scheduleru. Oproti tomu SWF je úzce zaměřeno na oblast frontendové části aplikace. Pokud se tedy bude rozšiřovat SWF, bude to pravděpodobně směrem k frontendu, oproti tomu Seam poroste směrem opačným.

Po zvážení těchto kladů a záporů jsem se nakonec rozhodl přiklonit k SWF. Pokud máte nějaký argument pro/proti Seam/SWF rád si jejv diskusi přečtu.

pondělí 22. října 2007

Tanečky kolem rychlosti Springu

Lukáš Křečan sice neumí moc psát bulvární titulky, nicméně o to lépe mu jde psaní seriozního obsahu. V článku Je Spring pomalý? odhaluje jádro pudla.

Spring jenom věci spojuje a veškerou práci na někoho deleguje. Napadají mě jenom dvě oblasti, kde by teoreticky mohl Spring někoho zpomalovat. První je start aplikace, kdy startuje aplikační kontext, vytvářejí se proxy a injektují se závislosti. Z mých zkušeností start aplikačního kontextu probíhá velmi rychle i u rozsáhlých projektů (jenom kdyby nezdržoval ten Hibernate). Další oblastí, kde by teoreticky mohl Spring běh aplikace zpomalit je AOP. Ale i to z velké části deleguje na JRE nebo CGLIB. Skoro všechno ostatní neřeší Spring, ale jiné produkty (Hibernate, aplikační server, JDBC, Quartz, …). Takže zopakujme si to znovu. Spring nic nedělá, jenom nám spojuje kousky skládačky dohromady. Pokud je ta skládačka pomalá, nemůže za to lepidlo, můžou za to ty kousky samotné.

Lukáš má samozřejmě pravdu, ale o tom jsem nechtěl psát. Chtěl jsem se s vámi podělit o to, že se najdou extrémisté, kteří jsou schopni měřit rychlost toho lepidla. William Louth napsal článek Benchmark Analysis: Guice vs Spring, ve kterém je srovnání rychlosti IoC kontejneru Spring a Google Guice. O přínosu naměřených dat a potažmo celého benchmarku by se dalo spekulovat. Můj osobní nazor je ten, že celý benchmark nemá žádný význam pro praktické nasazení.

čtvrtek 18. října 2007

Podcast #17

Repro here, podcast here.

Obojživelník jménem Eclipse RAP

Eclipse Rich Ajax Platform (RAP) je tak trochu zvláštní framework. Na první pohled se zdá, že je to konkurence Google Web Toolkitu (můj článek o GWT), na ten druhý je to trochu jinak. Cílem RAPu je umožnit vytvářet aplikace postavené na Eclipse RCP, které kromě desktopu poběží i v prostředí webového prohlížeče. Přístupem tedy RAP konkuruje spíše Adobe AIR.

Místo složitého popisu vás odkážu na dema, která ukazují RAP v plné kráse.

Architekturu RAPu, v porovnání s tím jak vypadá Eclipse RCP, ilustruje následující obrázek.

Eclipse RAP architekture v porovnání s Eclipse RCP

Ale co bych vám tu opakoval, co již napsali jiní.

úterý 16. října 2007

A REST

Representational State Transfer (REST) je koncept pro design distribuované architektury. Distribuovaná architektura v tomto smyslu znamená, že části programu běží na různých strojích a pro svojí komunikaci využívají síť. Pod programem si můžete představit například webovou aplikaci, kde internetový prohlížeč komunikuje s webovým serverem, aplikaci pro výměnu dat mezi finančními institucemi, kde dochází k vzájemnému volání mezi servery.

REST navrhnul a popsal v roce 2000 Roy Fielding v rámci disertační práce Architectural Styles and the Design of Network-based Software Architectures. V kontextu práce je nejzajímavější kapitola 5, ve které Fielding odvozuje principy RESTu na základě známých přístupů k architektuře.

Základní principy RESTu

  • stav aplikace a chování je vyjádřen takzvaným resourcem (klíčová abstrakce)
  • každý resource má unikátní identifikátor (URL, URN)
  • je definován jednotný přístup pro získání a manipulaci s resourcem v podobě čtyř operací CRUD (Create, Read, Update, Delete)
  • resource může mít různé reprezentace (XML, HTML, JSON, SVG, PDF)
Komunikační protokol
  • client/server - slouží k oddělení odpovědností
  • bezestavovost (stateless)- každý požadavek musí obsahovat všechny informace nutné k jeho vykonání
  • cache - každý požadavek může být explicitně označený jako cacheovatelný či necacheovatelný, to umožňuje transparentně zvýšit výkonnost přidáním cache mezi klient a server
  • Code-On-Demand - funkcionalita klienta může být rozšířena kódem, který zašle server (například JavaScript)
  • vrstevnatost - umožňuje skládání vrstev poskytujících služby za účelem zvýšení variabilnosti (cache, transformace, rozložení zátěže atd.)

Existují samozřejmě i další přístupy k řešení distribuované architektury jako Remote Procedure Call (RPC). Obecně můžeme říci, že rozdíl mezi RESTem a RPC je ve dvouch rovinách, sémantice operací a tím co se distribuuje. Sémantika operací v RESTu je konečná a tvoří ji pouze CRUD (create, read, update, delete) na daném resourcu. Oproti tomu v RPC sémantika odpovídá metodám, které jsou volány. V RESTU se distribuuje stav (data představovaná resourcem), oproti chování, které se distribuuje v RPC.

Výhody REST konceptu oproti RCP jsou následující.

  • jednoduché a změnám odolné rozhraní - snadná rozšiřitelnost
  • malé nároky na klienta z hlediska porozumění sémantice operací
  • transparentnost - resource lze na "cestě" velice snadno cahceovat, transformovat atd.

Nevýhody REST konceptu oproti RPC jsou následující.

  • klient musí s každým požadavkem posílat všechny informace nutné k jeho vykonání
  • chybějící podpora na úrovni middleware - všechno si člověk musí napsat sám

Právě chybějící podpora na úrovní middleware je asi největším problémem protože vede k velkému nepohodlí při práci s RESTem. Samozřejmě existují výjimky jako Google a jeho GData, pomocí kterých je využívání Google služeb přes REST pohodlné. GData mají klientské knihovny pro Java, JavaScript, .NET, PHP, C++ a Python.

V Jave se můžeme těšit na JSR 311 - Java API for RESTful Web services, které doufejme přinese usnadnění práce s RESTEm v Jave. Referenční implementace této specky nese název Jersey a můžete se o ní něco dozvědět v rozhovoru RESTful Web Services and Jersey. Spíše bych vám doporučil prezentaci JSR 311: JAX-RS, ve které jsou vidět praktické ukázky.

REST bude tématem některého z příštích CZJUGu a o Jersey bychom se měli pobavit přímo s jedním z jeho autorů v dalších podcastech. Na závěr přidávám pár zajímavých odkazů.

středa 10. října 2007

OT:programování není intelektuálně náročné

Dneska mě pobavil kolega, který musí z nějakého důvodu zjistit proč nefungují naše testy. Co čert nechtěl, testy nepsal on sám, ale naše pobočka v jihovýchodním koutě Asie.

Cyklus od jedné

for (int i = 0; i < CONTRACT_NAMES.length; i++) {
  if (i != 0) {
    ...
  }
}

Už vím k proč je v JUnit fail metoda

catch (SomeException e) {
  fail(e.getMessage());
catch (SomeOtherException e) {
  fail(e.getMessage());
}

Postupným zabořováním do kousků kódu vyprodukovaných v jihovýchodní Asii mě napadají tři vysvětlení, případně jejich kombinace.

  • programování není intelektuálně náročné
  • jiná mentalita, splnit úkol a moc nad tím nepřemýšlet
  • plat odvinutý od počtu vyprodukovaných řádků

Související linky

úterý 9. října 2007

Lekce ze škálovatelnosti

V článku Teorie a praxe v J2EE světě jsem se pozastavoval nad rozdílem mezi tím, co si můžeme přečíst v chytrých knihách o J2EE a tím jaká je praxe. Praktický pohled poskytla prezentace o architektuře systému eBay. Nati Shalom otevřel související diskusi na téma Why most large-scale Web sites are not written in Java.

Nati Shalom vyšel z dat sesbíraných ze serveru HighScalability viz následující tabulka.

Tabulka ukazuje, že preferovaným stackem je LAMP (Linux, Apache, MySQL, PHP|Perl). Je více než patřičné ptát se proč. Nati správně poukazuje na patrný rozdíl mezi požadavky web aplikací a mission-critical aplikací, které jsou obvykle stavěné nad J2EE stackem. Nicméně v oblasti škálovatelnosti vidí společné oblasti pro oba typy aplikací.

  • cacheování na úrovni datové vrstvy (minimalizace diskových IO operací)
  • snaha o Horizontal partitioning
  • minimalizace distribuovaných transakcí
  • snadná paralelizaci na úrovni aplikační vrstvy

Problém J2EE je v tom, že škálovatelnost je jakýsi virtuální pojem, který se táhne specifikací a marketingovými materiály. Z praktické zkušenosti s J2EE stackem mohu říci, že řádně škálují maximálně tak servlety. Pokud tedy chcete napsat vysoce škálovatelnou aplikaci v J2EE, nezbude vám nic jiného než spoustu technologií úplně vynechat.

K dobru přikládám moje tipy na architekturu dobře škálující střední vrstvy.

  • Bezestavový design a idempotentnost operací
  • lokální transakce
  • Hibernate
  • In memory data gridy
  • Spring

Stateless nebo česky bezestavový design je první předpoklad k dobré škálovatelnosti, znaméná totiž že není potřeba synchronizace stavu přes cluster. Pro dobré fungování aplikace je potřeba brát v potaz jistou toleranci k chybovosti, to by měla zaručit idempotentnost operací (výsledek operace se nemění v závislosti na počtu volání). Lokální transakce, protože JTA nepřináší žádné výhody v případě jediného transakčního participanta, naopak přidává zbytečnou režií.

Hibernate protože má podporu pro transakční cache (first level cache), velice snadno lze nakonfigurovat vysoce výkonnou second level cache (Comparing Memcached and Ehcache Performance díky Kolesi!), navíc by měl umožnit i horizontal partitioning. In memory data grid pokud již potřebujete držet nějaký stav, protože prostě řešení určená pouze a jenom pro škálování fungují lépe, než podpora v aplikačních serverech. A konečně Spring, kterým to všechno spojíte bezbolestně dohromady.

Závěrem, i v J2EE jde napsat aplikace, která bude dobře škálovat jenom musí člověk vědět jak na to...

pondělí 8. října 2007

Grid pro testy - realita nebo utopie?

Máte hromadu integračních a jednotkových (unit) testů a přemýšlíte jak z nich dostat co nejrychleji výsledky? Především integrační testy, které potřebují časově náročnější setup (start kontejneru, inicializace databáze atd.), jsou pověstnou žábou na prameni. My máme takových testů celou řadu a tak mě samozřejmě zajímá jakým způsobem urychlit jejich exekuci.

Nedávno jsem četl článek Jak na rychlé integrační testy ve Springu, který sice nabízí určité řešení pro testy závisle na databázi, ale má také poměrně dost nevýhod (nepoužitelné pro Hibernate, složitější vyjádření testovaných dat atd.). Novojovo řešení nabízí jistou míru urychlení, ale nikoliv dostačující.

Klíč k urychlení totiž neleží v urychlování sekvenčních operací, ale v jejich paralelizaci. To znamená prosté spuštění testů paralelně na různých strojích. Koncepce je následující.

  • Máme určité množství počítačů jejichž výkon není plně využit. Z nich můžeme postavit grid.
  • Do gridu můžeme dávat úkoly, které představují exekuce testů a report jejich výsledků.
  • Vývojář z IDE, Mavenu či příkazové řádku spustí test a nebo jejich sada. Tento úkol se vypropaguje do gridu, asynchronně provede a výsledky jsou reportovány zpět.

Grid přináší výpočetní výkon nezávislý na hardwaru vývojáře a umožňuje paralelizaci testů s efektivním využitím dostupných prostředků. Řešení, která umožňují distribuované testy, skutečně existují.

Samozřejmě distribuované testy mají několik hluchých míst. Především chybí infrastruktura pro spouštění testů. Spuštění testů nad stálou strukturou (konkrétní revize source code systému) je realizovatelné. Horší je to s lokálními změnami, nad kterými by měly testy běžet resp. vývojář by rád. Musela by se udělat tranzitivní uzávěrka a změny by se musely vypropagovat s testem.

Další možností je použití dvoufázového commitu (ve skutečnosti se tomu možná říká jinak). Lokálně pustíme pouze testy, které přímo verifikují danou změnu, Provedeme commit, tím dojde k naplánování puštění kompletní sady testů. Pokud testy projdou dojde k provedení vlastního commitu. Dvoufázový commit podporuje Team City od IntelliJ.

Distribuované testy vyžadují jistou kázeň při jejich tvorbě. Například nesmí docházet k vzájemnému ovlivnění testů. Pro testy, které mohou běžet na dané konfiguraci v jeden okamžik pouze jednou, například z důvodů kolize primárních klíčů, by musely existovat metadata (anotace), podle kterých by testovací framework řídil jejich spuštění. Podobných zádrhelů bychom asi našli o trochu více, ale to souvisí se zmiňovanou infrastrukturou.

Osobně se mi myšlenka využití gridu pro spouštění testů velice zamlouvá. I přes hluchá místa jsi dokážu představit relativně jednoduchý setup, který by se mohl využít v rámci continuous integration.

středa 3. října 2007

Změní tvář J2EE?

Rod Johnson, duchovní otec Springframeworku a CTO Interface 21, definoval v jednom ze svých článků body, které budou charakterizovat přístup lidí kolem něj, v rámci práce na standardu Java EE 6. Nemá cenu zde tyto body opakovat, ostatně přečíst si to můžete sami.

Z prozatímních vyjádření Roda Johnsona je cítit, že by rád přenesl myšlenky a duch, které stály za vznikem Springu i do J2EE 6. Bude se zřejmě opakovat, ale za jednu z největších chyb a nedostatků J2EE považuji následující oblasti.

  • komplexnost a malá pružnost - jednoduché věci složitě, snaha "jedna velikost sedí všem"
  • takřka nulová integrace mezi komponentovým modelem (EJB) a web modelem (JSF)
  • snaha standardizovat nezralé technologie
  • nicotný prostor pro rozšiřitelnost
  • velice pomalé adoptování technologie (mezera mezi specifikací a produkčními implementacemi)

Pokud někdo tvrdí, že to nejsou problémy, pak nemá, stejně jako autoři původních J2EE specifikací, smysl pro realitu případně tím sleduje vlastní zájmy (dodavatelé aplikačních serverů). Sama expertní skupina deklarovala, že hodlá tyto problémy řešit viz článek J2EE 6 - krok správným směrem. Pokud by se jim to povedlo, neznamenalo by to nic menšího než, že J2EE definitivně mění svojí tvář.

Já osobně vkládám největší naděje do začlenění OSGi a Web Beans. Minimálně v oblasti zprávy tříd a jejich packagovani nabízí OSGi daleko pružnější model oproti stávajícím classloader hierarchii v J2EE. Bohužel právě stávající classloader chování aplikačních serverů a to, že specifikace nepočítala s možnosti v uvozovkách OSGi like., způsobuje že nasazení aplikace využívající OSGi je mírně řečeno problematické. Web Beans jsou silně inspirované frameworkem JBoss Seam a jejich úkol je zmenšit mezeru mezi komponentovým modelem (EJB) a web modelem (JSF).

středa 19. září 2007

NetBeans 6.0 Beta 1

Je to beta, není to beta, tak čí je to sakra beta? Nějak podobně probíhaly tanečky kolem uvolnění NetBeans 6.0 ve verzi Beta 1. Celý příběh se má asi tak, že Beta release byl objeven chtivými uživateli na veřejných stránkách NetBeans ačkoliv se vlastně asi nepočítalo s tím, že by měl být již uvolněn.

Chronologicky z Roumenova blogu

13.9.2007

Although some developers already found the hidden link to download beta1 release of NetBeans 6 (which I am obviously not going to provide :), this is not the official release yet. We appreciate the large amount of interest into our testing bits, but please wait for the official announcement, otherwise you may download a version which is not the final version of beta1 - the bits may be respun. Beta1 release is coming in few days!

17.9.2007

NetBeans 6 beta1 has just been released. Get it from netbeans.org. We'll discuss it in the 35th episode of NetBeans podcast which will go live tonight. While you're at it, you can also download final release of Glassfish v2 from glassfish.dev.java.net. Released just a while ago, too!

Oblasti vylepšení v samotném IDE

  • Editor Improvements
  • Ruby/JRuby/Ruby on Rails Support
  • Easier Installation and Upgrading
  • Swing GUI Development
  • Profiling

Detailní seznam najdete na New and Noteworthy stránce.

Poznámka: mám Betu 1 nainstalovanou především kvůli podpoře Mavenu a UML, bohužel nemám čas si sní pohrát, ale ten čas přijde a potom se těš evangelisto...

pondělí 17. září 2007

Do pranice: code review patří automatickým nástrojům

Občas slýchávám, že je konvenční technika nechat dělat vývojáře či architekty code review. Osobně považuji tento názor do určité míry jako přežitek. Na úrovni developmentu vidím jako přínosnější nechat tuto úlohu na nástrojích jako PMD, Checkstyle, které tuto činnost automatizují. Jejich čas je levný a docela dobře škálují, což se o vývojářích říci nedá.

Samozřejmě je code review a code review. Jsou typy chyb, na které lze přijít pomocí výše zmíněných nástrojů, ale potom jsou chyby a nebo nevhodně zvolené implementační detaily, které vyžadují jistou míru inteligence. Může se jednat například o nekonzistentni práci s výjimkami, chybějící transakce a další špeky a špíčky.

Na většinu chyb, které odhalí manuální code review upozorní stejně dobře nástroje jako PMD. Řekl bych, že bude platit otřepané 80% k 20%. Proto si myslím, že ušetřený čas mohou vývojáři věnovat přínosnějším činnostem jako například sebevzdělávání, což je bude možná bavit daleko více. V code review vidím nástroj represe a kloním se spíše k prevenci. Ale možná je můj názor příliš radikální a vy mě v diskusi pod tímto článkem přesvědčíte o tom, že se hluboce mýlím.

Reakce

neděle 16. září 2007

CZ podcast číslo 16 - Maven představení

V rámci propagace nadcházejícího setkání CZJUG jsme se s virtuálním mikrofonem vydali za českým Maven evangelistou Petrem Ferschmannem a natočili jsme podcast s podtitulem Maven představení.

sobota 15. září 2007

O architektech...

Občas přemýšlím o tom, co děla rozdíl mezi architekty a co by měl takový architekt umět a jaké by měl mít vlastnosti. Je dobrou praktikou rozdělovat architekty do rodin, minimálně do dvouch zásadních: funkční architekt a technický architekt. Občas to sice bývá spojené, ale na tom z pohledu tohoto článku nezáleží. Protože mi je bližší práce technického architekta, tak budu dále v textu mluvit v kontextu jeho práce.

Za svou praxi jsem spolupracoval s třemi architekty, které mojí práci ovlivnili a nebo ovlivňují zásadním způsobem. Dva z nich nebudu jmenovat, protože s nimi stále spolupracuji a oni určitě vědí o koho se jedná. Tím třetím do party je můj exkolega Jirka Kotal, který mě hodně ovlivnil a jsem mu věčný za spoustu věcí. Ještě jednou díky.

Jestli tyto architekty něco spojovalo, pak to byly následující vlastnosti, které já osobně považuji za nejdůležitější pro práci architekta.

  • pragmatismus
  • vizionářství
  • analytické myšlení
  • zkušenosti
  • obecný rozhled

Pragmatik vs Vizionář

Je to tak trochu zvláštní, že jsem vedle sebe vypíchnul pragmatismus a vizionářství. Ten důvod je takový, že architekt musí být dostatečný vizionář, ale zároveň musí být dostatečně pragmatický smýšlející, aby ty vize byly vůbec realizovatelné. Výrazná převaha jedné či druhé vlastnosti je spíše na škodu. Prostě a jednoduše musí to být vyvážený mix.

Analytické myšlení

Propracované analýzy, smysl pro detail, schopnost nahlížet na problém z několika úhlů pohledu. Málokdy jsem v analýzách těchto lidí našel bílé místo. Pokud architekt nedokáže problém zanalyzovat, pak je celkem k ničemu. Z hlediska analýz bych ještě vypíchnul fakt, že architekt musí být schopen závěry analýzy obhájit před developmentem. Pokud to nedokáže, tak se mu může prostě stát, že si to vývojáři udělají po svém.

Zkušenosti

Nejhorší je technický architekt, který sice zná "všechno" teoreticky, ale prakticky nic nevyzkoušel a nebo nepoužil. Pokud jsem se nedávno obouval do certifikací, tak to je přesně ten případ, kdy je člověk certifikovaný architekt, ale v praxi nejsou jeho názory podpořený praktickou zkušeností a nebo s ní nekorespondují. Do jisté míry to také souvisí s výše zmiňovaným pragmatismem. Na druhou stranu zkušenosti nejsou všechno a je to opět jenom jedna z ingrediencí.

Obecný rozhled

Architekt musí mít obecný rozhled a povědomí i o technologiích, které zrovna nepoužívá. To platí i o oblastech, které s jeho prací souvisí jak přímo tak nepřímo. Obrazně řečeno architekt musí umět vidět za roh, to tak trochu souvisí se zmiňovaným vizionářstvím. Ono se to nezdá, ale ve výsledku to dává docela solidní škálu informaci, které musí absorbovat.

Nikde v článku nezmiňuji technologie, protože to je podružný detail. To že někdo zná například J2EE, z něj nedělá automatický kandidáta na pozici architekta. Znalost konkrétních technologií je dobrá, ale ve výsledku to nemusí vůbec nic znamenat. Protože právě v oblasti technologií se začnou projevovat výše uvedené vlastnosti: Pragmatismus, Vizionářství, Ananlytické myšlení, Zkušenosti a Obecný rozhled.

středa 12. září 2007

Spring 2.5 - podpora anotací, testovací framework a další

Nedávno uvolněný 4 milestone verze 2.1 Spring framewroku mě přinutil k migraci na tento release. Na začátek bych ovšem rád vysvětlil jak to bude s verzováním dalších releasu Springu, prototože je to trochu zmatečné. Takže číslo 2.1 se používá pro označení milestonů, číslo označující nadcházející verzi Springu je 2.5 (stále ompatibilní s J2SE 1.4) a finálně by měla být k dispozici v říjnu. Dalším zásadní verzí bude 3.0, pro kterou se očekává jako cílové prostředí J2SE 5.0.

Pokud s ptáte co bude na 2.5 tak zásadního, pak odpovím oficiální podpora anotací. Ano je to tak, řídící metadata pro IoC kontejner je možné vyjádřit pomocí anotací viz dokumentace 3.10. Annotation-based configuration. S tím souvisí i automatické vyhledávání anotovaných tříd na classpath.

    
@Component
public class SimpleMovieLister {

    private MovieFinder movieFinder;

    @Autowired
    public void setMovieFinder(MovieFinder movieFinder) {
        this.movieFinder = movieFinder;
    }
}    
    
    

Další zásadní novinkou je integrace s novými verzemi testovacích frameworků JUnit a TestNG. Předchozí API využívané k psaní integračních testů záviselo na trojkové verzi JUnit, která nepodporovala anotace. Pokud jste tedy chtěli použít původní podporu a JUnit 4.x bylo potřeba využít workaround.

Do podpory testování bylo vloženo dost úsilí, které nechalo vzniknout Spring TestContext Frameworku. Psaní testů, ve kterých lze využít transakce, dependency injection je teď mnohem snašší. První rozdíl je v tom, že není potřeba dědit od konkrétní třídy.

    
@RunWith(SpringJUnit4ClassRunner.class)
// specifies the Spring configuration to load for this test fixture
@ContextConfiguration(locations={"daos.xml"})
public final class HibernateTitleDaoTests {

    // this instance will be dependency injected by type
    @Autowired    
    private HibernateTitleDao titleDao;

    public void testLoadTitle() throws Exception {
        Title title = this.titleDao.loadTitle(new Long(10));
        assertNotNull(title);
    }
}    
    
    

Druhý rozdíl je v koncepci, kdy se veškerá přidaná funkčnost řeší pomocí TestExecutionListeneru. Spring má tyto listenery předimplementované pro řízení transakcí a nebo dependency injection. Vy si samozřejmě můžete naimplementovat vlastní listener, kterým dodáte potřebnou funkčnost. Pokud jste četli výborný článek Honzi Novotného Jak na rychlé integrační testy ve Springu, tak pomocí listeneru a řízení transakcí anotacemi by to šlo naimplementovat elegantněji. Právě něco podobného implementuji ještě navíc s využitím DbUnit, takže se můžete v budoucnu těšit na obsáhlejší článek.

Samozřejmě 2.5 je i o dalších velice užitečných vlastnostech. Oficiálně certifikovaná podpora WebSphere 6, možnost deploynutí kontextu pomocí resource adapterů (lepší management zdrojů - vlákna) a další. Kompletní soupis pocházející z oficiálního postu Jurgena Hoellera následuje.

  • full Java 6 and Java EE 5 support (JDBC 4.0, JTA 1.1, JavaMail 1.4, JAX-WS 2.0, etc)
  • full-featured annotation-driven dependency injection (including support for 'qualifier' annotations)
  • support for component scanning in the classpath (autodetecting annotated classes)
  • "beanName" pointcut element in AspectJ pointcut expressions
  • built-in support for for AspectJ load-time weaving (based on Spring's LoadTimeWeaver abstraction)
  • further XML configuration namespaces ("context", "jms") for maximum convenience
  • extended SimpleJdbcTemplate functionality (support for named parameters etc)
  • officially certified WebSphere support (support for the WebSphere 6 UOWManager facility etc)
  • Spring ApplicationContext can be deployed as RAR file (for headless application modules)
  • JCA 1.5 message endpoint management (for Spring-managed JMS and CCI message listeners)
  • completely revised framework for integration tests (with support for JUnit 4 and TestNG)

úterý 11. září 2007

Deset rad jak psát kód efektivně

NkD má tezi o tom, že dneska již neprogramujeme, ale spojujeme dohromady pouze části frameworků, které napsal někdo jiný. Do jisté míry s tím lze souhlasit a já osobně na tom nevidím nic divného, každopádně v poslední době jsem strávil nezvykle množství času vlastním kódováním. Při té příležitosti mě napadlo se s vámi podělit o oblíbené rady a postupy, které se mi osvědčily. Nechci úplně papouškovat Joshe Blocha a jeho Effective Java, takže pokud se vám tato kniha nedostala do ruky, pak ji vřele doporučuji.

1.) Null object

Null object též řečený Active nothing je návrhový vzor, který částečně oprošťuje kód od ošetření null referencí.

2.) Inversion of Control a Dependency injection

Mám pocit, že Inversion of Control a Dependency injection (popis) jsou vnímány vývojáři hodně kontroverzně. To je částečně dáno dřívější nutností vyjadřovat závislosti v XML, ovšem moderní IoC kontejnery umožňují i další způsoby např. anotace. Každopádně pokud přijmete tento přístup při tvorbě API za vlastní neradi jej opouštíte.

3.) Neměnitelné třídy

Neměnitelné alias immutable třídy nedovoluji na instanci změnit její stav, který je nastaven během inicializace. Pěkně se o nich rozepsal Lukáš Křečan ve spotu Neměnitelné třídy. Ne všechny třídy lze pojmout jako neměnitelné, ale je dobré se nad tím minimálně zamyslet.

4.) Programování rozhraním

Další prubířský kámen mezi vývojáři. Je zvláštní jak každý ve svém API vystavuje java.util.List či java.util.Map namísto jeho implementace, ale pokud má stejný přístup aplikovat i pro své třídy, pak se začíná cukat. Já osobně raději programuji rozhraním protože je to trochu více konzistentní z hlediska budoucnosti a párkrát se mi to už vyplatilo. Z mého pohledu je rozhraní více striktnější z hlediska designu API, protože člověk nesklouzává k implementačním detailům.

5.) Open/Closed princip

Kombinaci protected metod a final public metod jsem okoukal ze Spring frameworku. Třídy, které mohou být potenciálně rozšiřitelné definují chování pomocí veřejných neměnitelných metod, potomek může překrýt protected metody a rozšířit (nikoliv změnit) chování předka. Přesně v duchu myšlenky Open/Closed principu - software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.

6.) Runtime výjimky

Zkoušeli jste zjistit kolik výjimek ve vašem API musí být kontrolovaných? Ve většině API to nebylo více jak 20%, 80% připadal na výjimky běhové. Při tvorbě API zakládám skoro jako první věc hierarchii výjimek, tím se vyhýbám zbytečným změnám, když výjimky přetečou mimo kontrolu. Celkem dobrým přístupem pro určitý typ běhových výjimek je Deklarovaná runtime výjimka. No a samozřejmě nesmím zapomenout fault barieru.

7.) Kontrolujte argumenty metod

Bolí to, ale funguje to. Pokud si nechcete vytvářet vlastní sadu programových kontrol, použijte například třídu Validate z balíku Jakarta Commons Lang či Springovskou org.springframework.util.Assert, pokud nevadí závislost na Spring API.

8.) Neopakujte se

Tomáš Záluský mi kromě jiných mouder předal jedno, které se mi vždycky aktivuje jaksi automaticky. Pokud se někde v kódu objevuje na vice místech jeden a ten samý kus kódu, něco není v pořádku a programátorovi by se měla v hlavě rozsvítit červená kontrolka. Jeden ze způsobů jak neopakovat kód je popsán v článku Návrhový vzor Template method a jeho aplikace v prostředí JDBC.

9.) Dokumentujte poctivě

Pokud vám někdo tvrdí, že dobře napsaný kód se dokumentuje sám, pak si o něm můžete myslet tři věci.

  • dělá si z vás srandu a zkouší vaší reakci
  • v životě nenapsal API, které by používal někdo jiný
  • pravděpodobně je to diletant a nebo chorobný optimista

Pište javadoc, pište interni komentáře uvnitř kódu, uveďte nějaký příklad použití daného API, případně nalinkujte UML schéma. To všechno jsou informace, které jsou velice cenné pokud pracujete nejen v týmu.

10.) Nebojte se refaktoru

Refaktoring je úžasný přístup k tomu, aby váš kód nezahnil špatnými rozhodnutimi a hacky. Bohužel to do jisté míry stojí na faktu, že máte k dispozici testy. Ale možná právě proto je to o důvod více proč psát testy. Takže kromě brutálních refaktoru půlky code base se uchylujte i k menším akcím jako extract method, extract local variable. Kód bude lépe čitelný a pochopitelný.