Programování

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

Tento článek mám ve WordPressu rozepsaný snad už rok. Jeho původní název zněl "ResourceBundle - stačí Javě beze změny?". Plno věcí, které jsme původně jako Java vývojáři dělali my, postupně uzpůsobujeme tak, aby je mohli dělat web designeři. Na prezentační vrstvu zcela jistě patří lokalizované texty a zprávy, pro které standardně používáme ResourceBundly Javy, které se načítají z property souborů. Ideální model pro web developery je iterace: navrhnu stránku, vložím text do property bundlu, uložím, reloadnu stránku a kouknu jak to vypadá. V tomhle jednoduchém scénáři jsme však narazili hned na několik problémů.

Toto školení vám ukáže, jak co nejlépe využít různých pomůcek vývojového nástroje Eclipse IDE pro urychlení vývoje SW. Není zaměřeno na žádné pluginy pro Eclipse, veškeré tipy využijete v základní instalaci.

V minulém článku, ve kterém jsem se zabýval JavaScript Closures, jsem se zmiňoval o tom, že mě k jejich studiu donutilo používání efektů z knihovny jQuery. Také jsem sliboval, že o svých zkušenostech něco málo napíšu v dalším článku. Nuže směle do toho.

jQuery je obecná knihovna obalující odlišné implementace (více než odlišnosti jazyka, míním odlišnosti práce s DOM reprezentací) JavaScriptu v běžně používaných prohlížečích. Efekty jsou pouze její minoritní částí, kterou možná většina vývojářů pracujících s jQuery ani nevyužívá. Jelikož jsem hračička, koketoval jsem s efekty už od první chvíle, kdy jsem s jQuery začal. Z globálního pohledu musím říct, že mě překvapuje, že tyto efekty fungují velmi dobře skrze všechny podporované prohlížeče a kupodivu jsou poměrně svižné i na pomalejších počítačích (pomalejšími mám na mysli, průměrný počítač koupený před 3-4 lety). Základní použití je velmi jednoduché a zvládne ho i člověk, který s JavaScriptem a jQuery teprve začíná. Kromě základních efektů dodávaných přímo jako součást jQuery Core (show, hide, toggle, fadeIn, fadeOut, animate), je k dispozici ještě oficiální dodatečná knihovna s widgety a dalšími effekty známá jako jQuery UI (zde najdete řadu dalších pěkných efektů, které byly kdysi součástí js knihovny interface.js).

Předevčírem se v mé RSS síti zachytila zajímavá zpráva, která dobře zapadá do katalogu řešení pro automatické testování. Jedná se o MockFtpServer, který se velmi podobá přístupu SubEtha SMTP Serveru, se kterým mám velmi pozitivní zkušenosti.

Princip je skutečně analogický zmiňovanému SubEtha SMTP Serveru, se kterým lze jednoduše ověřovat správné rozesílání emailů. Jednoduše nakonfigurujeme "virtuální" FTP server a nastartujeme jej na konkrétním portu. V testech pak můžeme ověřovat kód, který komunikuje s FTP serverem, aniž bychom museli vytvářet vlastní stub nebo mock objekty:

V polovině listopadu jsem měl na Univerzitě Hradec Králové přednášku o automatickém testování v Javě, ve které jsem zabrousil už trošku do větší hloubky než v té, která proběhla na jaře tohoto roku. Přestože jsem především závěr přednášky nemohl probrat do takových podrobností, jak bych rád, doufám, že se mi většinu nasbíraných zkušeností nějakým způsobem podařilo předat. Pokud vás tedy opakovaně trápí některé problémy při psaní unit a integračních testů, možná při poslechu zjistíte, že i já jsem řešil podobný problém a můžu vám nabídnout nějaký tip co s daným problémem udělat, popř. čeho se vyvarovat.

Díky mému špatnému odhadu, kolik je možné probrat za hodinu a půl jsem se na minulé přednášce nestihnul dotknout žádného z pokročilejších témat souvisejících s automatickým testováním, se kterými se při douhodobém vývoji s použitím testů zcela jistě setkáte. Proto jsem se s Tomášem Kozlem z Univerzity Hradec Králové dohodl na druhé přednášce, která by se věnovala už jen pouze těmto záludnějším věcem a také rozkryla podporu pro testování ve Spring Frameworku.

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.

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

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

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.

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

Po necelých třech letech v Irsku se zpět do Čech vrací můj kamarád Pavel Jetenský a tak jsem se chopil příležitosti a vyzpovídal jsem ho z jeho zážitků. Z našeho rozhovoru vznikl podcast, ve kterém se dozvíte něco málo o přestěhování se do Irska, hledání práce tam, cestování, technologiích, kontraktování a tak podobně.

Pokud vás budou zajímat podrobnosti o některých věcech, které se v podcastu probírají, napište dotazy do diskuse pod příspěvkem. Pavel bude na vznesené dotazy odpovídat a z vaších dotazů a jeho odpovědí tak budou mít něco i ti ostatní. Pokud byste měli zájem o soukromý kontakt na Pavla, pište mu na adresu kontraktyjetensky.net.

Nedávno jsem se zamýšlel, co v mém případě činilo rozdíl mezi tím, kdy mě bavilo co jsem dělal a tím, kdy jsem pouze docházel do "práce". Co dělá člověka kreativním a co naopak pasivním. Uvědomil jsem si, že je v mém nejlepším zájmu přičinit se o to, aby v práci vzniklo kreativní prostředí, protože jenom tak budu mít pocit, že práce, kterou dělám má smysl. K tomu, aby bylo možné tento stav ovlivňovat, je však nutné rozlišit faktory, které na něj působí a na jejich základě zjistit, zda s těmito faktory dokážeme ze své pozice hnout, nebo nikoliv.

Na přání svých současných kolegů ve firmě FMC jsem připravil seminář zaobírající se základy analýzy v UML.

1. popisem životního cyklu
2. cíle analýzy a návrhu
3. behaviorální diagramy
4. strukturální diagramy
5. diagramy vztahů
6. odhadování časové náročnosti
7. tipy a triky

Obávám se, že jsem v některých částech nebyl úplně přesný, na mnoha místech jsem mohl řadu věcí popsat podrobněji a někde jsem nebyl schopný nalézt ty správné výrazy a obraty. Celou dobu jsem mluvil nespisovně a častokrát ani nedodržel shodu přísudku s podnětem. Pokud se vám zdají některé mé myšlenky zavádějící nebo obtížně pochopitelné, neváhejte a napište mi reakci - pokusím se nejasnosti vysvětlit zde.