Java

Není se třeba obávat, že by můj zájem o publikaci přednášek z jOpenSpace 2008 zveřejněním té mé ochladl. Ba naopak - předkládám Vám druhou várku záznamů a ještě nás čeká jedna várka, na kterou se můžete do konce roku těšit.

Pro úplnost ještě uvádím odkaz na předchozí záznamy:

• Audio #1

Lightning Talk - Using Spring in large applications, Roman Pichlík

V této přednášce Dagi popisuje zkušenost s nasazením (a používáním) Spring Frameworku na velkém projektu v Hewlett-Packard. Velkým projektem se rozumí projekt složený z cca. 150 Maven subprojektů = 150 aplikačních kontextů, na kterém pracuje cca 40 vývojářů. Od šesté minuty se probírá zajímavý problém skládání velkého množství aplikačních kontextů Springu, na toto téma navazují já ve 13 minutě s narážkou na řešení popsané v seriálu o modulárních systémech ve Springu. Od 11 minuty se diskutuje o problematice autowiringu na velkých projektech. Po 15 minutě se naráží na použitelnost OSGI v J2EE projektech a obecně o rychlosti adopce nových Java standardů u velkých zákazníků. Po 20 minutě se probírají problémy vendor descriptorů a způsob instalace takto velké aplikace u různých zákazníků.

Nice thing about Aspect Oriented Programming is that you can easily add piece of logic to several (possibly other way not connected) parts of your application. You'll only write an Advice (piece of code that should be weaved into original code and executed at exactly specified point of time) and define Pointcut (an expression defining which classes and methods shall be advised). Please, keep in mind, that above description is somewhat simplyfying and that AOP could be much broader than this. Describing AOP is not the aim of this post - the aim lies in something else, and that is - testing. What's the best approach to test application logic modified in runtime (or compile time) with AOP process?

V reportáži z tohoto setkání jsem sliboval, že se pokusíme uveřejnit audio záznamy z jednotlivých session. Od slov došlo k realizaci a je připravena první várka záznamů ve formě podcastů.

Open Space Talk - ORM, Roman Pichlík

V této session se vede diskuse obecně o knihovnách pro objektově relační mapování. Zkraje se probírají obtíže s použitím Hibernate v prostředí desktopových Swingových aplikací v souvislosti s lazy loadingem v AWT threadu (do 16 minuty). Navazuje obecnější diskuse o ORM a jejich používání / zneužívání. Od 19 minuty probíhá porovnávání plnotučných ORM (JPA/Hibernate) s lehčími řešeními (konkrétní probíraný zástupce je iBatis). Od 24 minuty se reší problém N+1 pro dotahování master-detail dat v prostředí iBatis. Ve 27 minutě přebírá slovo Filemon a převádí řeč na Ruby a jeho Active Record. 29 minuta otvírá diskusi na téma faktoru složitosti. Po 30 minutě zmiňuje Petr Ferschman nástroj pro monitoring výkonnosti SQL v Hibernate (znovu otevřeno také po 54 minutě). Od 31 minuty se řeší problém automatického založení (a aktualizace) databázového schématu. Po 35 minutě se diskuse stáčí na MDA přístup pro řešení datové vrstvy aplikace. Od 44 minuty je probírána nutnost jednoznačných identifikátorů v tabulkách při použití Hibernate. 58 minuta odstartuje diskusi na téma cachování a performance v Hibernate a navazuje také popis principů cachování v iBatis.

I've run into interesting and very strange problem. I was writing transactional Spring test that opens transaction at the beginning of it, and rollbacks at the end. First part of my test performed bunch of INSERT and UPDATE SQL commands and after that I was checking persisted changes by loading data back from the database. Suddenly my tests started to fail. And I was searching for the reason ...

Existují situace, kdy aplikaci neinstalujete sami, ale instaluje ji třetí strana - ať už je třetí stranou myšlen technik zákazníka nebo kolega z jiného oddělení firmy. Vy posléze přijdete už k nainstalované aplikaci, u které si nikdy tak úplně stoprocentně nemůžete být jisti verzí neřkuli verzemi knihoven, které daná aplikace používá. Přesto tato znalost může být pro řešení některých problémů zásadní (např. proto, že oprava může spočívat v pouhé instalaci nové verze knihovny / modulu). Můžete se s tím setkat i v daleko prostším případě - pokud vyvíjíte nějaký produkt s velkým množstvím instalací - chvíli vám může trvat než zjistíte jakou verzi má daný zákazník, u kterého řešíte nahlášené problémy.

Je tomu už drahně let, co jsem používal k populaci JavaBean Commons-BeanUtils z rodiny Apache Jakarta. Od chvíle, kdy stavím svoje aplikace nad Springem, pozbývá používání této knihovny smysl - naopak bylo by bláhové se této knihovny držet, když Spring nabízí již ve svém základu mnohem víc. Prostým logickým úsudkem lze odvodit, že Spring coby IoC kontejner bude obsahovat promyšlenou logiku pro injektování dat do Java Bean. Nicméně v dokumentaci o tom najdete jen poměrně krátkou kapitolu Validation. Proto jsem se rozhodl vyextrahovat ze svého kódu pár příkladů, které standardní Spring dokumentaci trochu rozvádí do podrobností.

Templatovací jazyky v Javě mají poměrně dlouhou minulost. První a zřejmě nejznámnější jsou JSP, které jsou součástí javy. Jsou nejstarší z rodiny templatovacích jazyků a přestože jsou masivně používány dodnes, mnoho lidí k nim má své výhrady:

• psaní JSP je obtížné pro ne-java programátory - přestože původní myšlenkou bylo, aby JSP psali odborníci na web (tedy "webdevelopeři") tato myšlenka zcela jistě minula realitu; praxe je taková, že JSP píší z různých důvodu opět Java developři, jejichž je jednak nedostatek a jednak jejich zaměření je spíš na aplikační kód než na validitu a použitelnost HTML výstupu
• JSP stránky nejsou použitelné, díky životnímu cyklu JSP (JSP -> .java -> .class), mimo servletový kontejner - to znamená, že teprve servletový kontejner po nadeployování web aplikce JSP převede na implementace Servletů a přeloží je do binární podoby. Dopady tohoto mechanismu jsou poměrně jasné
  • JSP stránky mají své pevné umístění - hledají se vždy na filesystemu v adresáři web aplikace; nelze je umístit na classpath (a učinit je tak součástí přenositelných knihoven), nelze je načítat z jiného zdroje - např. databáze (a umožnit tak vznik nových stránek za běhu na systémech, kde nemáme přístup na filesystém), nelze definovat jakoukoliv složitější logiku načítání stránek krom dodání Erorr 404 stránky (např. custom logika ve smyslu neexistuje-li primární šablona, použij záložní, neexistuje-li ani ta, zobraz chybu)
  • JSP stránky není možné jednoduše testovat - jejich výstup získáme teprve až dotazem na servletový kontejner
  • JSP nelze použít pro skládání jiného výstupu než do web browseru - např. pro skládání těl emailů musíme volit jiný templatovací engine
  • debugování JSP nebylo poměrně dlouho možné a ani dnes to není zcela samozřejmá a jednoduchá věc (co se setupu týče)
  • chybové hlášky JSP stránek jsou při určitém (často standardním) nastavení kontejnerů nečitelné (vztahují se k vygenerovaným servletům a nikoliv k původní template) - změna tohoto nastavení typicky vyžaduje stop/start kontejneru
• JSP stránky díky možnosti psaní scriptletů vybízejí k míchání aplikační logiky do prezentační vrstvy - s tím se myslím setkal každý z nás a leckdo se k tomu někdy i uchýlil
• v případech některých kontejnerů je při změně JSP a požadavku na její opětovné vyrenderování znatelná časová prodleva - kompilace JSP vyžaduje nějaký čas (možná se jedná jen o zlomky vteřiny, maximálně vteřiny, ale při ladění nějakých drobnostní na stránce se jakákoliv prodleva počítá)

Reakcí na zmíněné nevýhody byl vznik interpretovaných templatovacích jazyků. V tomto příspěvku bych se chtěl podívat na zoubek dvěma nejznámnějším - Apache Velocity a FreeMarkeru.

Na dovolené se mi podařilo vyšetřit čas na sestříhání záznamu z přednášky Automatické testování v praxi, která se konala dne 21.4.2008 na Univerzitě Hradec Králové. Na přednášce se sešlo přes 30 posluchačů převážně z řad studentů univerzity. Přesto že jsem původně anoncoval, že se pokusím zabrousit i do pokročilejších témat, jako jsou testovací patterny a antipatterny, nástroje apod. musel jsem svůj záměr přehodnotit. V takovém případě bych se s přednášením dostal na dobré tři hodiny, přičemž na přednášku bylo vyhrazeno pouze minut devadesát. Přednáška se tedy zaměřuje na základy testování a bude pro Vás nejzajímavější tehdy, pokud s testováním teprve začínáte. S Tomášem Kozlem (garant za UHK) jsme se tedy předběžně dohodli na "pokračovací" přednášce na podzim tohoto roku, kde bychom se soustředili pouze na tato pokročilejší témata. Pokud tedy vše půjde dobře, dočká se tento "podcast" druhé části za několik málo měsíců.

Tento článek vyšel na našem firemním intranetu. Jelikož je jeho obsah velmi přínosný ve své jednoduchosti a agregace poznatků z řady roztříštěných zdrojů po internetu, požádal jsem autora Michala France o svolení k jeho zveřejnění. Jak to dopadlo, můžete vytušit už sami. Výsledkem je že se s Vámi mohu podělit o zkušenosti s (vy)řešením problémů OutOfMemory v oblasti PermGenSpace při redeploy našich aplikací v aplikačních kontejnerech. Před aplikací těchto znalostí jsme vcelku pravidelně po dvou "redeployích" restartovali celý server, protože docházela PermGenSpace. V současném stavu aplikační server žije i po několika desítkách redeployů.

Rád bych vás touto cestou pozval na přednášku, kterou pořádá Univerzita Hradec Králové ve spolupráci s naší firmou při příležitosti vyhlášení vítězů soutěže Best Programmer. Na zmíněné přednášce budu rozebírat zkušenosti s automatickým testováním při vývoji web aplikací. Přednáška bude zaměřena především na vývojáře s malou zkušeností s automatickými testy, ale rád bych se dostal i k pokročilejším tématům jako jsou:

• Základy a obecný úvod do TDD
• Rozdíly mezi 3.x a 4.x řadou jUnitu
• Pozitivní a negativní dopady na proces vývoje
• Techniky testování (patterns, antipatterns, code smell)
• Business layer
• Data layer
• User interface layer
• řešení problémových oblastí (SMTP, java.util.Date)
• Nástroje
• IntelliJ Idea, NetBeans
• TeamCity
• Reporting
• Ant, Maven

Kde: Univerzita Hradec Králové - Fakulta informatiky a managementu

Místnost: B9
Kdy: 21. dubna 2008, od 10:00 do 11:30

Garant: Tomáš Kozel (UHK)
Přednášející: Jan Novotný (FG Forrest)

V tomto příspěvku se nechci věnovat popisu zprovoznění jCaptchy v bezpečnostní frameworku Acegi Security, jelikož toto je velmi dobře popsáno již v existujícím článku na MoroSystems weblogu. Spíš se chci zaobírat způsobem, jakým se k integraci do Acegi frameworku autoři postavili. Tento způsob mi přijde totiž přinejmenším neobvyklý. Zachovává sice zavedené principy Acegi, ale ten neodpovídá mým (ale řekl bych vcelku přirozeným) představám o tom, jak by měla captcha ve web strákách fungovat.

Po delší době jsem měl zase čas podívat se na zoubek v mém TODO listu. Tentokrát jsem si vzal na paškál poměrně malou knihovnu s názvem Joda Time. Cílem této knihovny je reimplementace Java API pro práci s datumy a časem. Každý z nás, kdo pracuje s Javou nějaký ten čas, se tu a tam potýká s tímto těžkopádným API. Joda Time přinesl poměrně hodně nových myšlenek a stal se základem pro JSR 310, které by mělo být součástí nové Javy 7. Často na toto téma naráží i pánové z Java Posse. Co je tedy na knihovně tak úžasného? Čtěte dál ...

Common introduction to AJAX in Stripes

Stripes framework offers basic but sufficient support for AJAX that is covered with article at official web site. Article recommends using commonly known PrototypeJS AJAX client side library. On the server side, request is processed by Stripes themselves by standard population and execution as any other http request (that means that data from client to server are sent as a standard URL encoded parameters). What you get is correctly populated and validated action bean - and until now you haven't even recognize, that request is made by JavaScript on the client side not even you have to care of it. You can access session, exchange cookies and so on.

Řada z vás si určitě řekne, co to ten Fura vytahuje za prehistorická témata. V době, kdy se už živě diskutuje o tom, co bude v Javě 1.7, rozebírá přechod z verze 1.4 na verzi 1.5. Možná vás to překvapí, ale v našem prostředí (server web aplikace), provozujeme ještě řadu instalací na verzi 1.4 a možnosti upgradu v nedohlednu. Proto je pro nás stále aktuální udržovat / vytvářet sdílené knihovny i pro 1.4 verzi Javy. Hledali jsme a zkoušeli tedy nějakou co nejméně bolestivou cestu, jak využít možností vyšších verzí se zachováním zpětné přenositelnosti. A naším (mým :-) ) favoritem se stal Retrotranslator. Více o jeho použití se dočtete v tomto článku.

Nedávno mě při poslechu JavaPosse zaujala zmínka o Google Collections. Jedná se o knihovnu doplňující funkcionalitu třídy Collections ze standardní Javy. Knihovna obsahuje řadu utility tříd, které zpříjemňují život s generikami v kolekcích, vytváření kolekcí v kolekcích a další manipulaci dat v kolekcích. Jelikož mě knihovna zaujala hned na první pohled, rozhodl jsem se podívat se jí na zoubek a podělit se s vámi o své zkušenosti.

Zkrácení zápisu pro vytvoření nových kolekcí s generikami

Jedná se možná o drobnost, ale natolik častou, že i drobné vylepšení přinese celkové zpřehlednění zápisu a zrychlení práce. V klasickém Java 1.5 kódu při vytváření generické kolekce typicky píšete např.:

Ve chvíli, kdy začnete používat při vývoji masivněji Spring Framework a začnete vytvářet znovupoužitelné knihovny postavené nad tímto frameworkem, začnete řešit jak z těchto knihoven co nejlépe složit výslednou aplikaci. První myšlenky povedou pravděpodobně těmito cestami:

1. konfigurační soubory jednotlivých knihoven sloučit v jednom velkém aplikačním kontextu
2. držet jednotlivé knihovny odděleně - nechat jim jejich vlastní aplikační kontexty a k těmto kontextům se dostávat programovým způsobem

Obě cesty však mají svá úskalí.

Pokud mi někdo řekne, že moje aplikace má běžet v aplikačním serveru OC4J naskočí mi husí kůže. Tento reflex se mi už dostal do podvědomí kvůli řadě bezesných nocí řešením řady chyb ukrytých v kódu, ke kterým člověk nemá zdrojové kódy. Nedá se ovšem nic dělat, náš zákazník, náš pán. Opět jsem se tedy musel ponořit do zakalených vod bažiny OC4J.

Pozn.: Tento příspěvek byl psán ve velké depresi. Kdo nemáte rádi pesimistické články před víkendem, radši ani nepokračujte ;-) .

Integrační testy spočívají v testování konkrétní kódu spolu s okolními částmi, se kterými spolupracuje. Cílem je snaha otestovat kód ve stavu, který se blíží reálnému nasazení. Obvykle takto testujeme datovou vrstvu aplikace (jelikož tam klasické jednotkové testy ztrácejí smysl - chceme přeci otestovat správné dotazování databáze, tudíž databázi k testu potřebujeme) a v řadě případů se nám nevyplatí mockovat ani na úrovni business vrstvy. Dokonce i Rod Johnson ve své prezentaci (kterou byl inspirován tento článek) zdůrazňuje důležitost integračních testů.

Jsou chyby malé, velké, závažné i triviální, úsměvné, spletité i velmi hloupé. Z celého pokolení chyb je tahle velmi, velmi stará a také dost hloupá. A vypadá to, že z úcty k jejímu věku, ji nechá M$ už pokojně dožít spolu s chatrčí zvanou Internet Explorer.

Na chybu narazíte tehdy, když coby Java programátor napíšete servlet, který vrací binární data přes protokol HTTPS (např. vygenerovaný MS Excel jako já, nebo třeba PDF atd.). Aniž byste to explicitně nastavili do HttpResponse, bude vrácená odpověď (pravděpodobně) obsahovat v hlavičce tyto údaje:

Spring framework má "od přírody" k dispozici implementaci Observer patternu. To není nic jiného než mechanismus "listenerů" tak, jak jej známe například ze Swingu. Základní a defaultní implementace je velmi jednoduchá, kdekoliv v managovaných beanách můžete přes tzv. Publisher (což je typicky aplikační kontext, kterým je daná beana vytvořena) vyslat informaci o události. Tuto událost pak může zpracovat jakákoliv třída implementující ApplicationListener rozhraní, a která je správně zaregistrovaná do fronty listenerů. Registrace se provádí velmi jednoduše - pouze deklarací beany v context.xml. AbstractApplicationContext (předchůdce všech specifických implementací aplikačního kontextu) při své inicializaci všechny beany implementující zmíněné rozhraní zaregistruje.