Minulý týden jsme se podruhé sešli na tzv. "OpenBeer" setkání v Hradci Králové. Tady bych nyní chtěl rozkrýt pozadí a myšlenky, které se za tímto druhem akce skrývají. Nebudu zakrývat, že inspirace přišla od našich severních sousedů z polského Krakowa - kde termín OpenBeer vzniknul. Motivy, které mne vedly k tomu něco podobného zavést taky u nás, jsou jednoduché.

Nevím, jak vy, ale já moc příležitostí popovídat si o IT nemám. V práci na to není moc času a ani doma, ani v mém okolí tohle téma zrovna moc nefrčí. Navíc, se člověk pohybuje neustále v tom samém okruhu lidí, kde se po nějaké době témata začnou opakovat. OpenBeer je skvělá příležitost, jak se jednou za čas odreagovat a nabrat inspiraci od nových lidí.

Partial update neboli částečná aktualizace stránky (pomocí AJAXu) není technika zrovna nová. Po pravdě řečeno však stále není běžná, přestože její správné použití může velmi pozitivní dopady na celkový výkon systému a také je velmi dobře přijímána uživateli. Na otázku proč, můžeme odpovědět problematickou podporou ve frameworcích - některé se na jedné straně snaží o maximální odstínění programátorů od JavaScriptu, čímž z dané techniky dělají věc více méně magickou - jinde naopak použití vyžaduje větší než malé znalosti "skriptování", což zase většinu Javistů, paradoxně, vyřadí ze hry.

Sobotní den mi zlepšil včerejší pocit z WebExpa poměrně radikálně. Dnes jsem měl více méně štěstí na přednášky, takže jsem většinu dne strávil podle mého vkusu. Organizační část se nijak výrazně nezlepšila, nicméně co se týká složení programu a osobnostní v něm, musím pochválit. Navíc se mi po letech "poštěstilo" ochutnat onen klasický rozblemcaný školní špenát, což je zážitek, na který budu zase hodně dlouho zapomínat. Ráno začalo poměrně vlažně přednáškou o Continuous delivery, ve které jsem si myslel, že se dozvím něco víc o závěrečné části - tedy o té "delivery". Bohužel Aleš Roubíček rozebral pouze základní principy CI, které jsou erudovanější části IT publika známé už nějaký ten pátek.

Na WebExpo jsem letos vyrazil poprvé a docela jsem se těšil. Nabízelo poměrně atraktivní mix ze světa webových vývojářů - obchodem počínaje, přes kreativu a použitelnost až k programování. Ne všechno co vypadá dobře na papíře (webu) je ale takové i ve skutečnosti. Pocit, který si z WebExpa dnes odnáším by se dal popsat jedině slovem "nevyrovnané výkony" - a to jak z hlediska organizačního, tak i z hlediska prezentací. Mám-li být hned zkraje kritický, myslím, že některé věci by už na 3. ročníku měly být vychytané. Registrace nebyla připravená na takový nápor lidí a řada účastníků tak přišla o první prezentace, jen pro to, že musela stát frontu jak na banány před revolucí. V materiálech, které jsme dostali s registrací kompletně chyběl program a nějaká mapka, která by lidem usnadnila orientaci v areálu Univerzity (taktéž heslo pro WI-FI v materiálech chybělo). Některé věci (bloky, trička), zdá se, byly jen na požádání pro ty, co věděli kam jít. Dalším klasickým nedostatkem (což je ovšem standard všech konferencí, na kterých jsem byl) je nedostatek elektrických zásuvek - už si to musím někam zapsat, abych si vždycky s sebou bral alespoň pěti-psa.

Po sadě technických článků bych rád napsal zase jeden trošku filozofického charakteru. Rád bych se v něm zamyslel nad způsoby, které používám pro své vlastní vzdělávání a faktory, které osobně vnímám jako pozitivní. Snad každému je jasné, že ten kdo na sobě dál nepracuje může v našem oboru těžko dlouhodobě něco dokázat (a být lépe placen ;-)) a proto se zamyšlení nad tím, jak se vzdělávat co nejefektivněji, určitě hodí každému.

Testing transactional aspect of your application is not easy as we usually use Springs' transaction rollback on tear down testing approach. Though there are solutions to test aspect oriented logic it's not without a price. More than that - we very much got used relying on easy-to-use Spring @Transaction annotation so that we don't usually take an effort to do it. There is a few standard Spring rules for rollbacking transaction in relation to method resolution:

Občas při tvorbě automatických testů potřebujeme otestovat funkcionalitu, která stahuje nějaká data z Internetu. V mém případě to byla funkce na stahování seznamu zneplatněných certifikátů (CRL). Původně jsem měl automatický test napsaný tak, že se seznam skutečně stahoval. To bylo nevýhodné ze dvou důvodů:

Opět po roce proběhla - v pořadí již třetí - ne-konference nesoucí název jOpenSpace. Na ní se každoročně setkávají zajímaví lidé z celé republiky, které spojuje jediné téma a tím je Java a vývoj aplikací. Základem konference jsou tzv. lightning talky, což jsou mini-přednášky na vybraná témata. Některá z nich se mi podařilo nahrát a v tomto článku je dávám se svolením autorů ke stažení ve formě podcastů. Kromě toho, že některé z nich obsahují skutečně velmi zajímavé informace, je na nich lákavé především to, že s nimi neztratíte moc času - jejich délka se pohybuje do 6 do 25 minut. Takže neváhejte a stahujte ...

Po včerejší after párty se mi dneska skutečně nechtělo příliš vstávat. Niméně diskuse s Hansem Dockterem (autorem Gradle) skutečně stála za to. Hans je skutečně mimořádný člověk se skvělými názory - přidávám další bodík pro Gradle. Styl, jakým se Gradle vyvíjí a filozofie, která za ním stojí, se mi skutečně zamlouvá. U dikuse byl také Vašek Pech z JetBrains, který má na svém kontě také samostatný OS projekt GPars, takže se diskuse odvíjela i na téma zkušeností s vedením OS projektu, respektive firmy, která je živa z konzultací a školení spojených s daným OS projektem. Tyhle chvilky jsou zkrátka na konferencích asi to nejlepší - dostat se do kontaktu s výjimečnými lidmi a mít možnost s nimi mluvit tváří v tvář. Jsem opravdu rád, že tyhle "výlety" na konference jsou ve Forrestu možné, protože to zdaleka není samozřejmost.

V letošním roce jsme s kolegy z Forresta vyrazili na GeeCON v Poznani. Podle referencí z loňského roku se jednalo o velmi dobrou akci, takže jsme plni očekávání vyrazili směr Balt. Cesta do Poznani byla velmi jednoduchá - z Náchoda je to furt rovně :-) , překvapily mne příjemně stavy silnic - takovou po které jsme jeli my aby člověk v Čechách pohledal. Nakonec jsme do Poznani ve zdraví dorazili - čekal jsem spíš menší město a tak mě překvapilo, že Poznaň je větší než Brno. Pro zvědavce přikládám pár fotek z akce od organizátorů.

Člověk neznalý věci by mohl nabýt dojmu, že přes reflexi v Javě půjdou získat všechny informace, které se v signaturách tříd a metod nacházejí. Reflexe v Javě je skutečně velmi mocná, nicméně k některým informacím se nedostává jednoduše (jak jsme si ukázali v minulém článku) a k některým se bohužel nedokážete dostat vůbec. Do té posledně jmenované kategorie právě patří názvy argumentů metod. A právě o nich se chci dnes rozepsat.

Minulý týden jsem řešil zajímavý problém s reflexí a došel jsem k závěru, že generiky v reflexním API jsou opravdu velká legrace. Prototypoval jsem myšlenku automatického generování implementací nad obecným kontejnerem - dejme tomu Map (což není pro účely tohoto článku zase až tak důležité), a došel jsem k potřebě správně číst generické informace z deklarací tříd. Právě této, na první pohled jednoduché, věci, bych chtěl věnovat dnešní článek.

Tento týden proběhl workshop na téma iBatis 3 v Národní technické knihovně. Na workshopu jsem vyhlásil soutěž o licenci vývojového prostředí IntelliJ Idea 9 - Ultimate Edition a v tomto příspěvku najdou soutěžící jak moji verzi řešení příkladů, tak i výsledné vyhodnocení. Kompletní řešení všech testů, které jsme v průběhu workshopu probírali najdete v GitHub repository na stejném místě jako původně (stačí si "pullnout" novou verzi zdrojových kódů):

• GIT klient: git://github.com/novoj/iBatisWorkShop.git
• HTTP: http://github.com/novoj/iBatisWorkShop/tree/master
  (v menu odkaz Download sources)

Děkuji ještě jednou všem, kdo si našli cestu na seminář a kdo se i po něm za mnou zastavili a řekli mi svůj názor na jeho formu a průběh (speciální díky patří chlapcům z MoroSystems za jejich příspěvek na blogu). Není totiž horší pocit než, když se jako přednášející dobu potíte vedle projektoru, pak se publikum potichu rozuteče a vy odcházíte z rozpačitým pocitem a otázkou, jestli to nakonec mělo smysl. Jsem rád, že, pokud nic jiného, tenhle workshop nějaké emoce vyvolal a ke konci za mnou zašlo hodně lidí, a měl jsem šanci si udělat obrázek o tom, jestli jsem to vzal za ten správný konec.

Rád bych vás všechny pozval na workshop na téma iBatis 3 konaný 3. března 2010 od 18 hodin v rámci CZ JUG setkání (pozor tato praktická setkání se konají v Národní technické knihovně v Praze - Dejvicích - viz. mapka dole). iBatis je framework pro mapování dat uložených v relační databázi na Java objekty. Už po několik let je zajímavou alternativkou k ORM frameworkům postaveným na JPA (jehož typickým představitelem je Hibernate). Mottem iBatisu je zjednodušit vývojářům práci s databází a přitom zůstat tak jednoduchý, jak jen to je možné. Právě jednoduchostí a nízkoúrovňovým přístupem k databázi si získal celou řadu vývojářů a v řadě případů poráží i daleko silnější frameworky.

V rámci zátěžových testů, které jsem v minulém týdnu prováděl jsem přišel na jednu zajímavou věc. Při velké zátěži došlo k "zaseknutí" Tomcatu, ze kterého se systém již nedokázal zotavit. Průvodním jevem byly otevřené konekce na databázi, přes které neprocházely žádné dotazy (tj. databáze nic nedělala), nulové zatížení procesoru Tomcatem, žádné Exception v logu. Příznaky nasvědčovaly tomu, že problém vězel v nějakých deadloccích - buď při práci s konekcemi do databáze nebo mezi aplikačními vlákny.

Je to asi rok co jsem psal článek o implicitních commitech při provádění DDL příkazů. Řešil jsem tehdy problém velmi složitého selectu, který se výrazně zjednodušil, pokud jsem jej rozdělil na dvě části s uložením mezivýsledků. Jelikož jsem potřeboval zachovat transakčnost, nemohl jsem využít temporárních tabulek a šel jsem cestou stálé tabulky s aplikačním hashem rozlišující mezivýsledky jednotlivých transakcí mezi sebou. To jsem ještě netušil, jaké mi to přinese komplikace ...

Před lety jsem psal článek o debugování aplikací v Javě. K mému překvapení jsem se totiž setkal s programátory, kteří v Javě k debugování kódu používali System.out(...) místo debug režimu. Po letech otvírám stejné téma z jiného pohledu. Jak efektivně používáme nástroje debug režimu, které nám naše IDE nabízí? Je totiž plno situací, kdy se můžeme s debugováním dost nadřít, nebo ... vědět co a jak v daném okamžiku nastavit tak, abychom se k výslednému pochopení problému dostali zkratkou. IntelliJ Idea těchto nástrojů nabízí celou řadu a v tomto článku bych rád rozebral několik z nich, které sám rád používám.

Tradic je nutno se držet - i když je to jen tradice dvouletá. Proto i letos rekapituluji dění na mém blogu výtahem několika málo statistik, které mám k dispozici a také informacemi z mého osobního života, které mají s blogem souvislost. Doufám, že tím milé čtenáře neurazím, že v mé závěrečné rekapitulaci (kterou dělám i kvůli sám sobě) najdou pár zajímavých informací.

Rekapitulace

V letošním roce jsem měl o něco málo více čtenářů než v roce minulém. Počty přístupů odrážejí i skutečnost, že se díky vyhledávačům dostávají čtenáři i ke starším příspěvkům, kterých není na blogu úplně málo (v současné době je 91 publikovaných článků). Těší mě dvojnásobný nárůst čtenářů, kteří sledují novinky na blogu přes RSS čtečku - podle statistik zdrojů provozu většina z vás přichází právě buď přes RSS čtečky, z portálu Java.cz nebo při hledání rad přes Google.com. Tento fakt je patrný už ze statistik minulého roku, nicméně letos, řekl bych, většina lidí konvertovala právě k RSS formě odběru.

Znát velmi dobře IDE, se kterým pracujete deno denně, je pro vaši produktivitu zcela zásadní. Poslední rok mne utvrdil v tom, že přesto že IntelliJ Ideu používám už několik let, přesto je plno věcí, které nevím a které mi nakonec ušetří plno práce. Příkladem budiž pár klávesových zkratek o kterých jsem absolutně nevěděl a které jsem se dozvěděl teprve z DZone IntelliJ Cheatsheetu od Hamleta D'Arcyho - kupříkladu:

• Ctrl+Shift+Insert - vertikální výběr oblasti (skvělé pro hromadné úpravy CSV souborů, SQL apod.)
• Ctrl+Shift+U - změna case vybraného textu (tzn. na upper-case nebo lower-case)
• Ctrl+Alt+Left, Ctrl+Alt+Right - posun na předchozí / následující lokaci kurzoru (používal jsem ikony) - skvělé pokud si prohlížíte jinou část třídy, včetně přesunutí kurzoru a pak se chcete vrátit rychle zpět
• F11 - vložení rychlého bookmarku do kódu, který se vám ukazuje po pravé straně a je možné se na něj rychle vrátit

Možná, že teda i já vím pár věcí, které tak úplně známé nejsou, a třeba někomu z vás pomůžou.

In the last post I described the basic principles I found behind the scenes of GroovyScript refresh. Now imagine that you want to create your own long living Groovy instances with auto-refresh behaviour when source code changes. You can use out-of-the-box Spring support - but there are some limitations I stated in the previous article.

In this post I am going to present an alternative solution that addresses some of the painful issues I noticed. As I stated before, key is to wrap the reference to Groovy instance into an another object managed by the Java class loader and that is exactly the main point of the solution presented.