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.
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.
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).
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 ...
The reason was that the data created by the first part of test was not cleared by rollback at the end of the test.
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).
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.
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 -> .
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.
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 "
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.
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.
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.
Ř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.
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.
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:
konfigurační soubory jednotlivých knihoven sloučit v jednom velkém aplikačním kontextu 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.
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ů.
