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í …)

Nedávno jsem poslouchal záznam z přednášky, kterou měla Kathy Sierra na konferenci OOPSLA v roce 2007. Kathy Sierru pravděpodobně budete znát podle její práce - je
spoluautorkou řady knih o Javě ze série Head First. Myslím, že mezi Javisty nechodí mnoho těch, kteří by o Head First nikdy neslyšeli a mnoho z nás se podle nich připravovalo na rozličné certifikace. To co je na sérii Head First výjimečné je přístup k prezentaci informací - jistě mi dáte za pravdu, když řeknu, že tato forma je, byť zpočátku vypadá tak trochu dětinsky, velmi přitažlivá a velmi dobře se z ní učí.

Dohaduji se, že zmíněná přednáška byla jedna z posledních, které Kathy uskutečnila, jelikož posléze jí bylo na jejím vlastním blogu vyhrožováno smrtí. Po této odsouzeníhodné záležitosti se Kathy stáhla do soukromí a přestala vydávat nové příspěvky. Je to velká škoda pro komunitu, ale přesto za sebou zanechala plno článků, knih a myšlenek, ze který lze čerpat i dnes.

(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í …)

V odkazech na sledované blogy se mi objevil Blog v pavučině, který píše můj kolega z web designerského oddělení Forrestu. Blog je zaměřen na JavaScript a webdesign, což je oblast, kterou možná jako Javisti orientovaní na web nemáme úplně rádi, ale je pro naši práci nezbytně potřeba (i když s nástupem jQuery se můj pohled na JavaScript radikálně změnil ). Vypíchnu jen pár jeho článků a názor si udělejte sami:

• Seriál o regulárních výrazech v JavaScriptu - vyšlo také na www.interval.cz
• Loading… animace na pár kliknutí - rozřešení záhady, kde se neustále berou nové verze “loading” animací
• jQuery: AJAX load a cache - IE a cache, kapitola sama pro sebe
• Textarea de Luxe - luxusní TextArey pro editaci zdrojového kódu
• Alternativní scrollIntoView() pro IE
• Rozlišení CSS stylů pro různé verze Internet Exploreru

Přeji příjemné čtení.

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.

Tento týden jsem řešil problém s nedostatkem paměti při spouštění testů jednoho projektu. Pro běh testů nestačilo výchozích 64MB paměti Javy na heapu, což mi připadlo v porovnání s velikostí projektu podezřelé. Začal jsem profilovat a jelikož mne výsledky poněkud překvapily, chci se s Vámi o ně v tomto článku podělit.

Hned na úvod řeknu, že jádrem problému byla třída AspectJExpressionPointcut. Tato třída je ve Spring dokumentaci zmiňována hned několikrát, velmi jednoduše se používá a ze všech dostupných materiálů jsem dospěl k názoru, že se jedná o doporučovaný a běžně používaný standard.

(pokračování …)

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í …)