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é "

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.

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:

O autorovi: Jetyho blog | LinkedIn Pavel Jetenský se věnuje Java/J2EE vývoji již od roku 2003, z toho několik let v Irsku. Zajímají ho techniky automatického testování. V současné době pracuje jako metodický vedoucí Java/J2EE v Deltax Systems a.s. 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.

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.

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.

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.

Č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. Problém mohu ukázat na příkladě:

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ů): Sponzor přednášky:

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

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.

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.

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.

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.

The first thing one should undestand before he tries to integrate scripting support into his application / framework are class loading issues. One of the main reasons (next to the ability to easily switch from Java) why we have chosen Groovy as our primary scripting language is very good support for live refresh of Groovy classes when source file has changed. But what does Groovy exactly do when it "refreshes" its loaded classes to conform to a newly modified source file?

Ještě něž jsem zahájil svou dovolenou, jsme při dokončování projektu narazili na výkonnostní problém při velkém importu dat do MySQL databáze. V našem případě se jednalo o cca 30 tisíc záznamů do tří tabulek navzájem provázaných cizími klíči. Úvodní verze importního algoritmu trvala cirka 50 minut, po dvou dnech jsme se dostali na jednotky minut. Nedalo mi to, a udělal jsem pár testů, které snaží tento problém rozkrýt do většího detailu, tak abych pro příště věděl, co a především jak významně ovlivňuje rychlost importu takto rozsáhlých dat.