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.
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. To bylo nevýhodné ze dvou důvodů:
Č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
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ů):
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 ...
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:
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.
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? What about existing instances referencing to this class? Is it even possible in JVM to change class structure in runtime? Yes JavaRebel can do this, but it needs special setup and debug mode for hotswap. And how does all this fit into the existing Spring support? From the documentation it seems, that it all just magically works! Dozens of questions ran in my mind when I started to strive for Groovy integration in our product. Those questions gets answered in this article.
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.
Po letech jsme se konečně dočkali třetí verze populární knihovny iBatis. Nová verze přináší velkou řadu novinek a jedná se o kompletní rewrite, který využívá generik, anotací a dalšího API Javy 1.5. iBatis je prozatím ve verzi Beta 1 (doposud ještě není dostupný ani v Maven repository), ale doufejme že nebude dlouho trvat a dočkáme se verze stabilní.
Společně s iBatisem vychází i úplně nový produkt iBATIS Schema Migration System inspirovaný Rails Migrations. Migrations představují podporu pro konzistentní úpravy databázových schémat s důrazem na: konzistenci, opakovatelnost, reverzibilnost, verzování, auditovatelnost a automatizaci. Jedná se o nástroj pro příkazovou řádku, s jehož pomocí je možné systémově vytvářet a spravovat databázové change skripty, které jsou přehledné, dají se kdykoliv revertovat a měly by výrazně ulehčit práci v týmu (pro čtenáře z Forresta: pokud vám to připomíná náš DbAutoupdater, jste doma :-) ).
Tento článek píšu se záměrem zjistit, zda jsme k těmto závěrům dospěli sami, nebo je to evoluční záležitost, ke které časem dospěje každý tvůrce produktů sloužících k dalšímu vývoji. Ve Forrestu k realizaci webů a webových aplikací používáme interní CMS systém, který je nadstavbou nad vybranými Javovskými knihovnami a frameworky. Namátkou například Spring Framework, Freemarker, Groovy, Spring Security, Stripes, DWR, iBatis a řada dalších. Tím, že jsme CMS systém (ona už je to vlastně tak trochu programová platforma) postavili nad existujícími knihovnami jsme dosáhli toho, že můžeme využívat většiny jejich širokých možností a máme zdarma zajištěn i další vývoj, který nás v podstatě bezpracně posouvá zase dál.
Čas od času řeším problém jak hromadně zkonvertovat sadu souborů z kódování A do kódování B, popřípadě jak ze sady souboru odstranit UTF-8 BOM. Vždy jsem na hledání nějakého jednorázového vehementu strávil plno času, především proto, že to obvykle nefungovalo tak úplně jak bych potřeboval. Na odstranění BOMu, jsem navíc nenašel vůbec nic. Nakonec mi došla trpělivost a za 20 minut jsem si spíchnul utilitku, kterou jsem si problém jednou provždy (doufám) vyřešil. A pak že je Java na takovéhle utilitky nešikovná (vím že v Groovy bych to měl na polovině řádku, ale ještě nejsem úplně Groovy ready) ...
V druhé várce záznamů ze session na letošním jOpenspace uzavřeme sobotní den. Témata jsou poměrně lákavá a věřím, že si najdou své posluchače. Spolu s oživlým CZ Podcastem budete mít tedy v červnu nabité MP3 přehrávače kvalitním audiem.
Webové služby se Spring WS, Lukáš KřečanStejně jako minulý rok, i letos budou některé talky z jOpenspace k dispozici ve formě podcastů. Letos jsme výrazně zapracovali na kvalitě nahrávání a řekl bych, že kvalita je "téměř" profesionální :-) . Řada přednášek byla opravdu výborná, takže doporučuji si je poslechnout. Velmi zajímavý je i formát - ligtning talky omezené 7 minutami dávají skvěle poslouchatelný záznam i pro ranní cesty tramvají. Nuže tu je máte ...
Představení účastníků
Podcast [10:36] 3.8 MB
Tušil jsem, že to je jednoduché, ale že to je AŽ tak jednoduché, to jsem nevěděl. Dokončujeme projekt pro jednu velkou českou banku a potřebovali jsme mít podrobným logováním pokrytou co největší část aplikace pro případ, že by se vyskytly problémy na prostředí, do kterého, z bezpečnostních důvodů, nemáme a nikdy nebudeme mít přístup.
Jako principiální odpůrce manuální práce jsem ihned zavrhnul myšlenku na manuální procházení kódu a rutinní vkládání debug logování pro strýčka příhodu (krom složitějších metod, kde je to nezbytně nutné).
Dynamic proxies can be very nasty if you don't know what happening under the cover. Last week I was searching for the memory leak that caused our application to crash. Even though Tomcat had assigned 1GB memory for heap and 0,5GB for PermGenSpace it stood alive for only approximately twelve hours. It's pretty nasty situation having known that application is only in betatesting with relatively low traffic.
When analyzing generated heap dump I have found, that memory leak was caused by web application classloader, that managed thousands of CgLib dynamically generated classes. I was using Eclipse Memory Analyzer, that's probably the best tool for memory heap dump analysis I have ever seen. It's the third time it quickly identified the suspicious classes, by heuristic analysis called Leak suspect.
V prosinci jsem znovu řešil problém s kódováním českých znaků při AJAXové komunikaci se serverem. Znovu říkám proto, že jsem stejný problém řešil před pár měsíci, ale řešení jsem stihnul úplně zapomenout. Tentokrát jsem si ale poklepal na čelo a říkám si: "Furo tvá paměť se horší, zapiš to nebo nad tím budeš za měsíc trávit čas znovu".
Problém je poměrně obecného charakteru - kdysi jsem na to narazil při používání knihovny Prototype.js, nyní to byla jQuery s Tomcatem na straně serveru. Obě dvě knihovny mají pro AJAX (jQuery, Prototype.js) velmi pěknou podporu - ačkoliv bych řekl, že Prototype.js je v tomto ohledu o kousek dál.
