Myšlenky dne otce Fura

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.

Přímočarým řešením je vytvoření nějaké info stránky se seznamem knihoven / modulů a jejich verzí, které jsou použity v aplikaci, která by vám umožnila všechny potřebné informace zjistit během vteřiny. V tu chvíli už se ale dostáváte k druhému problému - jak zajistit (nelépe automatické) verzování knihoven, aby bylo zajistěno, že se knihovny budou pravidelně verzovat, a že u všech knihoven bude tato informace jednoduše přístupná (a opět nejlépe jednotným způsobem, aby info stránka neměla s vyhledáváním této informace problém).

Problém se zdá možná jednoduchý, ale můžete narazit na celou řadu nepříjemností jako se to stalo třeba nám. Řešení může být ale opravdu velmi prosté …

(pokračování …)

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

(pokračování …)

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.

(pokračování …)

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

(pokračování …)

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

A nyní slíbený článek

Každého programátora to jednou čeká. Jeho aplikace začne padat na OutOfMemoryError. Dá se krčit rameny se slovy “já vážně nevím čím to je”, nebo s tím něco udělat.

(pokračování …)

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)

Vzhledem k tomu, že přednáška je především určena studentům UHK a tudíž bude již část místnosti obsazená studenty, rád bych vás požádal, abyste mi, pokud plánujete na přednášku přijít, napsali jen krátce počet osob na můj email ‘novotnaci[zavináč]gmail.com’.

Přednášku bych rád zaznamenal a zveřejnil na blogu jako podcast. Nicméně plánuji i živá dema, která ve formě audia nebudou příliš srozumitelná. Navíc jsem doposud nesehnal rozumnější nahrávací zařízení než je můj Ericson, takže výsledná kvalita může být poměrně špatná. Slyšet přednášku na živo je prostě jistota.

Update k 9.5.2008 : Na blogu byl zveřejněn audio záznam z této přednášky.

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.

Princip práce s captchou v Acegi je podobný principu standardního přihlašování. Acegi při přístupu na “chráněné url” kontroluje ověření uživatele v SecurityContextu a pokud uživatel není ověřen, přesměruje tok aplikace na přihlašovací formulář nebo v případě captchy na formulář obsahující obrázek a textové pole pro vepsání rozpoznané captchy. Pokud řešíme přihlašování, je tento způsob přirozený - v případě captchy však očekávám, že captcha bude rovnou součástí formuláře, který je “hlídán”. Tak ale integrace jCaptchy v Acegi ve svém základu nefunguje.

Pokud Vám tento způsob připadne taky trochu podivný a zajímá Vás, jak si s tím poradit, čtěte dál.

(pokračování …)

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 …

(pokračování …)

Though most of articles at this blog are written in my native language - Czech, this one will be different. I have chosen an English to address wider community of Stripes developers - I think there would’nt be enough readers in our beautiful small country. So, please, excuse possible errors and mistakes in the article, I will try my best .

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.

(pokračování …)

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

(pokračování …)