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.

V předchozím článku jsme si ukázali vylepšení iBatisu v souvislosti s XML deklaracemi. Tento navazující článek rozebírá novinky v oblasti Java API. Základem pro toto rozšíření se staly vlastnosti dostupné od verze Javy 1.5 - tedy generiky a anotace. Jednou z velkých kritik původního iBatisu bylo množství XML, které bylo nutné psát. Našlo se mnoho lidí, kterým tento přístup vadil a kteří by spíše uvítali mít vše na jednom místě v kódu. Autoři tyto kritiky vyslyšeli a vytvořili plnohodnotné API, před které je možné využít libovolnou funkcionalitu iBatisu.

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

Poslední várka zpracovaných záznamů z letošního jOpenspace na sebe nechala chvilku čekat, ale nakonec se mi ji přeci jen podařilo zpracovat. Myslím, že si v ní každý najde něco pro sebe - rozhodně bych doporučil třeba lightning talk Petra Šmída o API Festu pořádaném v HP, ZFS filesystému v Open Solaris Roumena a související přednáškou Petra Adámka, ale myslím, že i ostatní session stojí za poslech. Kvalita je myslím velmi dobrá, podobně jako u ostatních přednášek z jOpenSpace 2009.

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.

Školení Selenium testování - základy je určeno pro začátečníky a seznamuje s prvními kroky s nástrojem pro automatizované testování webových aplikací v prohlížeči.
Popisuje jednotlivé příkazy frameworku, různé typy selektorů a způsoby spouštění testů. Nahrávka byla pořízena během přednášky  pro studenty pana Pavla Kříže na Univerzitě Hradec Králové.

Stejně 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 ...

Dnes skončil druhý ročník Javovské ne-konference s názvem jOpenSpace, kterou pořádají pánové z Inmite. Podle metody obrácené pyramidy, přejdu rovnou k závěru: letošní ročník byl daleko více uvolněnější než ten minulý (dokonce i na sport se čas našel), přesto mi přinesl dostatek inspirace do příštích měsíců a především řadu kontaktů na zajímavé osobnosti české Java scény. Ty nejhodnotnější informace jsem spíš než z "organizovaného" programu získal z neformální konverzace při jídle a v přestávkách. Ze všech bych vypíchl snad jen skvělé zkušenosti a rady Lukáše Vlčka v oblasti fulltextového vyhledávání (díky Lukáši) nebo skvělou dvouhodinovou konverzaci v kroužku Pavla Juhoše (HP), Václava Pecha (JetBrains) a Maaartina o budoucnosti jazyka Java, porovnání progresivity oproti .NET, jazycích jako je Groovy / Scala apod. Zkrátka a jednoduše, přestože vznikly záznamy z oficiálních "session", ty nejcennější zážitky / informace zachytit na pásku nelze. Ty si člověk odnese, jen když na konferenci prostě je.

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

Dnes se mi podařilo vychytat velmi dobré přednášky, takže jsem si po včerejším dm Serveru rozhodně spravil chuť. První dnešní přednášky se týkala Groovy a především novinek ve verzi 1.6. Zprvu se zdálo, že Guillame pojede pouze po povrchu Groovy, ale brzy se přednáška rozjela, takže si z ní člověk nakonec odnesl opravdu hodně. Přednáška stavěla na publikovaném článku o Grovy 1.6 na InfoQ. Groovy by ve verzi 1.6 mělo být výrazně rychlejší (různé micro benchmarky ukazují zlepšení výkonnosti od 150% do 430%), díky hotspotu dle Guillama dokonce předběhnou některé jiné dynamické jazyky mimo JVM platformu (konkrétně zmiňoval Ruby). Groovy běží bez problémů na GAP - dokonce je tam k vyzkoušení volně dostupná Groovy konzole. Rozvoj Groovy jede raketovou rychlostí, řekl bych že věci, které tam jsou, v Javě neuvidíme ještě léta a kdo ví jestli vůbec (closures, tuples, properties, statická inicializace properties v rámci konstruktoru). Jediné co nám brání dosud ve firmě nasadit Groovy, je zajištění aby groovy instance vytvořené Springem a naše vlastní instance nad společným Groovy classoaderem sdílely podobné rekompilační chování jako nabízí GroovyScriptingEngine. Groovy je ale rozhodně směr, kterým se chceme ubírat.

Dnešní den přenesl (alespoň v mém případě) řadu roztrpčení. K tomu se ale dostanu až o pár odstavců později. Dnešní keynote se nesla v duchu Lean software development - a to především ve smyslu, jak se co nejrychleji dostat z fáze vývoje do fáze produkčního běhu. Přednáška byla poměrně zajímavá - Adrian Colyer ukazoval prostřednictvím STS živý deployment Spring / Grails aplikací (byť) triviálních přímo na Google App Engine nebo na Amazon EC2. Ačkoliv pro to zatím nemám usecase, praktická ukázka byla skutečně impresivní. Adrian je především skvělý přednášející, který je schopný živě reagovat na odezvu publika a vkládat skutečně zajímavé oživující prvky, které udrží dobrou náladu a pozornost posluchačů (jako třeba bílý tučnák, kterého v průběhu přednášky trestal za jakoukoliv chybu, která se mu ukázkách povedla). Kéž bych uměl své přednášky udělat tak zajímavé jako on ;-) . To co jsem si z přednášky odnesl je to, že nasadit Spring aplikaci na GAE nebo EC2 nemusí být zase tak těžké, jak by se na první pohled mohlo zdát.

Dnes začala v Amsterodamu konference Spring One zaměřená na technologie okolo Spring Frameworku (Spring samotný, Spring MVC, Spring WebFlow, Grails, Spring Batch, Spring Security, Spring tc a dm Server atd.). Konference se koná v hotelu Krasnopolski v úplném centru Amsterodamu. My jsme přijeli o den dříve, abychom si město stihli v klidu prohlédnout a projít si zajímavá místa (Red light district apod. :-) ). Nějaké fotografie si můžete prohlédnout zde. Kromě všudy přítomných coffee shopů mě zarazilo především to, že holanďané si vůbec nepotrpí na soukromí a ve velkých oknech řada domů nemá ani záclony, takže je jim běžně vidět téměř až do postele. Druhá věc, která vás na Amsterodamu zarazí, je neuvěřitelné množství kol - ty jsou tu daleko běžnějším dopravním prostředkem než třeba automobil. Průměrné stáří kol, je ovšem (soudě dle vzhledu) snad 20 let - jelikož jsou tu běžná kola podobná tomu, o kterém se v naší rodině traduje, že je předválečné. Zdá se, že tu holanďané soutěží o ošklivější kolo s největším zámkem, což mě přivádí k myšlence, že se tu musí kola poměrně dost "ztrácet".

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.

Tento týden proběhla na Univerzitě v Hradci Králové přednáška na téma iBatis SqlMaps. V přednášce jsem se snažil projít všemi základními funkcionalitami iBatisu a porovnat jej krátce s několika dalšími přístupy k implementaci datové vrstvy (plain JDBC, JPA / Hibernate) a podívat se co nového nás čeká v nové verzi iBatis číslo 3.

Kvůli omezenému rozsahu (1,5 hodiny) nemohlo dojít na trošku sofistikovanější záležitosti jako je použití diskrimintárů a resultObjectFactory, integrace se Springem, dávkovému zpracování dotazů do databáze a použití iBatoru. Pokud byste měl kdokoliv nějaké otázky týkající se těchto oblastí, neváhejte je napsat do komentářů k tomuto postu, a já se je pokusím zodpovědět a popřípadě publikovat i další příklady.

Absolutním Cimrmanovým rýmem začínám další ze série článků o Javascriptu. V něm bych chtěl rozebrat pár postřehů při práci s časovači (timery) v JavaScriptu. Ty se používají k lecčemu - při jQuery animacích, zobrazování aktuálního času, periodickém dotazováním serveru atp. Intuitivně jsme vždycky tušili, že jejich časování nemusí být úplně přesné, ale přesto jsme hrubě podcenili význam pro aplikaci, pro kterou je aktuální čas zásadní.

Stáli jsme před relativně jednoduchým problémem. Odpočítávat čas do okamžiku T a vypočítávat slevu v ceně na základě času, který do okamžiku T zbývá. Samozřejmě všechny údaje (ať čas nebo cena) musely být u všech klientů naprosto stejné a musely se měnit každou vteřinu. Tento jednoduchý problém nás ale docela potrápil a proto vznikl tento článek, který by měl zachytit problémy a jejich řešení.