středa 22. prosince 2004

Re: Žádný strach z Mozilly

Se zájmem jsem si přečetl článek Pavla Housera Žádný strach z Mozilly. To nejdůležitější, kolem čeho se samotný článek točí, najdeme hned v prvním odstavci.

Uvedení první finální verze webového prohlížeče Firefox bylo prezentováno téměř jako doklad přicházejícího rozkladu Gatesovy říše. Pozice Microsoftu však není existencí open-source webového prohlížeče ve skutečnosti nijak ohrožena. Webový prohlížeč už totiž dávno není klíčová aplikace.

V podstatě souhlasím s tím, že Microsoft nebyl a nebude nijak ohrožen vydáním další verze prohlížeče Firefox. Microsoft nebude ohrožen ani jakýmkoliv jiným prohlížečem. Prohlížeč není nijak spjat s konkrétní platformou do té míry, že vždy máme možnost se svobodně rozhodnout, jaký prohlížeč budeme používat. Zásadně nesouhlasím s tvrzením, že Webový prohlížeč už totiž dávno není klíčová aplikace..

Webový prohlížeč je klíčovou součástí širokého spektra webových aplikací a potažmo třívrstvé architektury. Webový prohlížeč, v kontextu vícevrstvé architektury označován jako super tenký klient, tvoří nebo chcete-li realizuje prezentační vrstvu. Samozřejmě tu máme známé problémy dnešních prohlížečů v podobě nedostatečných možností (HTML, CSS) v oblasti tvorby UI aplikace a komunikace se serverem.

Prohlížeč bude hrát klíčovou roli i během následujících let, bude na něm vybudován základ pro RIA (Rich internet Application). První nesmělé krůčky udělala platforma Flex (Macromedia), máme tu XAML (Microsoft) nebo možnosti XUL (prohlížeče postavené na jádru Gecko). Nenechme se zmást, prohlížeč bude plnit roli jedné z klíčových aplikací.

Na druhou stranu je třeba poznamenat, že pro neaplikační část, jsou dnešní možnosti prohlížečů dostatečné. Na postoj k vývoji/nevývoji prohlížeče Internet Exploreru můžeme nahlížet tak, že Microsoft neměl důvod cokoliv zásadně měnit.

Základní možnosti IE, posílené o technologii ActiveX, byly a ještě nějaký pátek budou pro současné aplikace dostačující, a to je myslím ten důvod proč neměl Microsoft zájem do současného prohlížeče více investovat. Microsoft mohl místo toho upřít investice k operačnímu systému Longhorn, který bude spadat do časového horizontu masivnějšího nástupu RIA.

Související články

pátek 17. prosince 2004

Lze založit business na open source?

Ano, open source produkty nabízí ideální prostor. Mezi jeden ze základních mýtů, které se o open source šíří, patří variace na Programátoři se kódu nenajedí, potřebují peníze ... nebo Zadarmo ani kuře nehrabe .... Ano, existuje plno open source projektů, na nichž by si člověk nevydělal ani na slanou vodu, ale existuje široké spektrum open source projektů, které poskytují zlatý důl pro business.

K tomuto zamyšlení mě vyprovokoval, v dobrém slova smyslu, spot JBoss na vzestupu Pavla Kolesnikova. JBoss je právě jedním z oněch projektů, který ukazuje, jak úspěšně lze založit business na open source. Dovolil bych si odcitovat závěr spotu Pavla Kolesnikova

Pravda, zatím v Čechách ani žádný subjekt aktivně nepůsobí v roli JBoss partnera, ale co není, brzy může být.

Svtá pravda, a nabízí se otázka, proč ještě nikdo nevyužil potenciál, který JBoss nabízí? Opravdu to nechápu, JBoss, alespoň jak to vidím já, se těší velké oblibě vývojářů a určitě se najde skupina, která by profesionální služby (školení, konzultace či jiná forma supportu) zaplatila.

Stejným případem jako JBoss jsou projekty Eclipse, Hibernate, Spring a další, stačí najít vhodný způsob, jak tyto projekty využít pro vlastní business. Nemusím chodit daleko pro příklad, právě pracuji na komerčním projektu, který je postaven na platformě Eclipse. Ať se ve výsledku jedná o řešení postavené na open source a nebo služby poskytované k open source produktu, business potenciál open source je obrovský.

čtvrtek 16. prosince 2004

Návrh projektu - adresářová struktura

Právě se chystám na přepracování adresářové struktury jednoho z našich projektů. Po důkladné přípravě proběhne obrovský refactoring stávající projektové struktury, která již nevyhovuje potřebám projektu. Změna adresářové struktury projektu je pokaždé velice bolestivou operací, a to z několika důvodů.

  • Musí být provedena změna v struktuře source repository např. CVS
  • Musí být provedena synchronizace s touto změnou
  • Změna se musí otestovat na patřičné úrovni (Unit testy na úrovni kódu, validita na úrovni build scriptu atd.)

Veskrze se jedná o ne nepodstatné důvody, které kladou důraz na chirurgické provedení. Někdy se bohužel jedná o tak radikální řez, že musíme skalpel vyměnit za sekáč. Proto je lepší těmto problémům předcházet na začátku projektu. Na základě zkušeností s několika rozsáhlejšími (alespoň z mého pohledu) projekty, jsem stanovil několik kroků pro vytvoření stabilní adresářové struktury projektu.

Návrh strukturu projektu před prvním commitem

Adresářová struktura většiny projektů vychází z určitých zkušeností a zvyklostí. Pro získání zkušeností nám může posloužit předešlý projekt, prototyp projektu a nebo úplně jiný projekt, jehož struktura nás inspiruje. V kostce máme hrubou představu o tom, jak bude adresářová struktura vypadat. Nejhorším možný přístup představuje okamžitá synchronizace (akce kulový blesk) našich představ se source repository.

Doporučuji strukturu zdokumentovat, doplnit o detailnější komentáře a vytvořit její prototyp.

Zdokumentování struktury
\root directory
	|
	|-db
	|
	|-doc
	|	|-javadoc
	|	|-project
	|    	
	|-config	
	|	|-hibernate
	|     	| 	|-app    	
	|	|		|*.hbm.xml 
Seznam adresářů s popisem
Název Popis
root directory Kořenový adresář projektu
doc Adresář pro dokumentaci
javadoc Adresář pro dokumentaci k API
project Adresář pro dokumentaci k projektu
config Adresář pro konfiguraci použitých frameworku
Hibernate Adresář pro O/R mapovací soubory Hibernate. Mapovací soubory jsou dále členěny v rámci aplikace.
app Konkrétní aplikační adresář pro mapovací soubory Hibernate
*.hbm.xml Mapovací soubor Hibernatu ctí syntaxi *.hbm.xml

Jak je vidět, k propojeni struktury a komentářů nám stačí HTML. Takto zdokumentovaná struktura je základ, na kterém se dá úspěšně stavět. Navrhovaná struktura by měla odpovídat source repository, na druhou stranu je možné dokumentovat i adresáře, které nejsou přímo součástí source repository, ale k projektu se přímo vztahují. Například se může jednat o adresář pro výsledky unit testů nebo o build adresář.

Validace struktury

Vyberte si úzkou skupinu lidí (3 až 4) a předložte jí návrh struktury. Cílem je podchytit případné boty v struktuře a strukturu dále rozšířit, ne vždy totiž dokážete určit všechna specifika. Všechny změny zadokumentujte a vytvořte obraz této struktury. Nyní máte první bod, na kterém se dá stavět. Nezapomínejte, že dokument popisující adresářovou strukturu by měl být součástí projektové dokumentace resp. její část pro vývojáře.

Stanovte pravidla a určete správce

Určete jednoho člena projektu (správce projektové struktury), který bude zodpovědný za změny v projektové struktuře. Nastavte hranice, podle kterých se určí odpovědnost správce, například strukturu na hlavní úrovni může měnit pouze správce projektové struktury. Nastavit tyto hranice je většinou obtížné, můžeme si pomoci pravidlem, že všechny sub změny musí být posvěceny správcem. Sub změna je taková změna, která neovlivňuje další části projektu (build skripty, API apod.). Správce má za úkol, o všech změnách informovat všechny členy projektu, změny provádět a dokumentovat. Přes správce jdou také všechny požadavky na změny.

Oživte strukturu

Připravený obraz vytvoří správce projektové struktury v source repository a vývoj se může rozběhnout. Samozřejmě, že během vývoje narazíte na potřeby rozšíření nebo drobnější úpravy stávající struktury, ale prostředí je nastaveno tak, aby změny neměly tolik bolestivý dopad.

čtvrtek 9. prosince 2004

Eclipse - znáte hot code replace?

Je to již nějaký pátek, co vývojové prostředí Eclipse integruje podporu HotSwap. Java Platform Debugger Architecture (JPDA) definuje rozhraní, které musí poskytovat VM (Virtual Machine). Toto rozhraní slouží pro komunikaci debuggeru a VM, pro zajímavost, debugger a VM spolu komunikuji přes Java Debug Wire Protocol. Java 1.4 představila rozšíření v podobě funkce HotSwap. HotSwap umožňuje debuggeru runtime aktualizaci bytecode. Eclipse resp. debugger v Eclipse tuto funkci využívá.

Co to znamená pro normálního smrtelníka a jaké výhody mu to může přinést? Možná jste si položili jednu z těchto otázek. HotSwap totiž umožňuje realizovat jeden z následujících scénářů. Spustíte aplikaci v debug módu a zjistíte, že jste opomněli opravit část kódu. V normálním případě by bylo potřeba, aplikaci vypnout, kód opravit a znovu nastartovat aplikaci.

Restartování aplikace je činnost nejen nudná, ale někdy i zdlouhavá, viz start aplikačního serveru. Diky HotSwapu restartovat nemusíte, prostě jenom inkriminovaný kousek kódu opravíte, uložíte a Eclipse se postará o zbývající práci. Práce s HotSwap se v Eclipse ukrývá za vlastností Hot code Replace. Samozřejmě Hot Code Replace má své limity, takže půlku aplikační logiky na jeden zátah VM nezměníte.

Druhý scénář opět vychází z úpravy kódu za běhu a jeho pronesení do runtime. Představte si, že krokujete metodu a odhalíte chybu, co uděláte? Chybu opravíte, restartujete aplikaci a počkáte až bude program na daném breakpointu. Jenže to nemusíte, Hot Code Replace při opravě chyby nejen pronese vaše změny, ale i znovu provolá danou metodu, ve které jste změnili kód. Hot Code Replace se tak dá využít, např. při ladění, k opakovanému volání metody.

Pokud se vám Hot Code Replace zalíbil a chcete jej vyzkoušet, tak mějte na paměti, že musíte aplikaci spouštět v debug modu.

Možná by stálo za to osvětlit, proč jsem se o HotSwap rozepsal. Filemon mi dnes básnil o možnostech AOP frameworku AspectWerkz (AW) a mimo jiné argumentoval změnou bytecode v runtime. Samozřejmě, že má první reakce byla, To Eclipse zvládá levou zadní hafo jarů. Nejsem si ovšem jist, jestli AW (online mód) využívá HotSwap. Spíše si myslím, že nikoliv, neboť mu jde o trochu něco jiného, ale to bychom se dostali k point cuts a to je opravdu na jiný šálek kávy.

db4o - databáze a persistence framework v jednom

Nedávno jsem se s Arnym bavil o možnostech zavedení persistence frameworku do jednoho z našich projektů. Zrovna jsme používali na jiném projektu Hibernate, a tak jsem byl nadšen jeho možnostmi, bohužel nasazeni Hibernate bránily dva důvody. Provázání stávajícího relačního modelu na domain model a relativní složitost Hibernate. Myšlenka ORM a persistence frameworku byla zadupána do země a dál jsme to neřešili.

Slovo Embedded se stalo přívlastkem už pro velké množství nástrojů. Pracoval jsem již s embedded servlet kontejnerem Jetty, embedded databázemi Hypersonic či SQLite. Když jsem narazil na článek Jim Paterson Simple Object Persistence with the db4o Object Database, vůbec jsem netušil, že i persistence framework s databází, může být embedded. db4Objects vypadá opravdu zajímavě.

Seznam zajímavých funkcí uvedených v článku

  • No impedance mismatch–objects are stored as they are
  • Automatic management of the database schema
  • No changes to classes to make them storable
  • Seamless Java (or .NET) language binding
  • Automated data bindings
  • Installation by adding a single 250Kb library file (Java jar or .NET DLL)
  • A single database file
  • Automatic schema versioning
  • Query-By-Example
  • S.O.D.A. (Simple Object Database Access),an open source query API

Pokud potřebujete jednoduchou databázi s persistence frameworkem, představuje db4Objects zajímavou možnost. Samozřejmě je třeba uvážit všechna pro a proti embedded řešení, ale minimálně za prozkoumání db4Objects stojí.

úterý 7. prosince 2004

Pojmy, dojmy a promo akce ve znamení J2EE vs .NET

Začne-li se někdo "umně" ohánět studií Comparing Microsoft .NET and IBM WebSphere/J2EE, stoupne mi krev v žilách. Poprvé jsem se ozval, když o této studii informovaly některé blogy na vývojáři. Nebyla to žádná přestřelka, jenom jsem ujasnil některé faktické poznámky k J2EE. Minulý pátek mi přistál v poště dopis Visual Studio .net s podtitulem Mimořádná nabídka pro vývojáře.

Dopis jsem koutkem oka shlédnul a poslal do koše, jediné co mi utkvělo v paměti, byl odstavec nadepsaný Přečtěte si praktické porovnání technologií Microsoft.NET a J2EE.Nějak jsem tomu nevěnoval pozornost, ale pak jsme si uvědomil, že v tom odstavci byla zmíňka o Comparing Microsoft .NET and IBM WebSphere/J2EE. Resuscitoval jsem dopis z koše a radši jsem si to přečetl ještě jednou a pozorně.

Nemám to Microsoftu za zlé, že se snaží touto studií ohánět, ale jasně to ukazuje jak slovíčkaření a překrucování formulací může vytvořit zkreslené informace.

Jak porovnat neporovnatelné

Každá studie, která se honosí podtitulem J2EE vs .NET, je mírně řečeno podezřelá a dopadá na jednu nohu. Je potřeba si uvědomit, že J2EE tvoří množina specifikací a nástrojů. J2EE si jako takové nikde nestáhnete, můžete si stáhnout například Servlet specifikaci, která je součástí J2EE, ale pořád budete mít pouze specifikaci. Ke každé specifikaci existuje minimálně referenční implementace a množina dalších implementací.

Referenční implementací Servletu je Tomcat a mezi další implementace této specifikace patří např. Jetty firmy Mortbay. Tento model si můžeme aplikovat na jakoukoliv součást J2EE, JMS začínaje a EJB konče. DOT.NET je oproti tomu konkrétní produkt firmy Microsoft.

Porovnávat specifikaci s produktem je nesmysl. Zmíněná studie je proto porovnáním produktů .NET a IBM WebSphere. IBM WebSphere je jednou z komplexnějších implementací J2EE a nutno dodat, že podle vyjádření několika nezávislých zdrojů, implementací nijak zvlášť povedenou (jak jsem koupil, tak prodávám).

čtvrtek 2. prosince 2004

Jsem okouzlen - Google Desktop Search a Skype

Google Desktop Search

Když jsem kdysi dávno, v dubnu roku 2004, psal příspěvek Topfive software, webové aplikace, neměl jsem ani potuchy, že by se měl objevit vyhledávač pracující nad soubory pevného disku. Zlom přinesl Google a jeho Google Desktop Search. Moje poštovní schránka praská ve švech, letmým součtem přes 40 000 emailů, to samé platí o složce s dokumentací.

Vyhledávání v poště, přes poštovního klienta, je v takové záplavě emailu kouskem vhodným pro člověka obrněného neskutečnou trpělivostí. Vyhledávání v dokumentaci uložené na lokálním disku, hraničí se sadomasochismem a on-line vyhledávání neřeší problém neveřejných dokumentů. Jedním slovem katastrofa.

Naštěstí existuje Google Desktop Search, který alespoň částečně tyto problémy řeší. Google Desktop Search indexuje omezenou skupinu souborů, AOL Instant Messengeru, emaily Outlooku + Outlooku Express, soubory Office (soubory Excelu, Wordu, PowerPointu), jakékoliv textové soubory (html, zdrojáky, xml …) a historii shlédnutých stránek. Mě osobně chybí ke štěstí indexace PDF souborů, ale i tak se jedná o obrovsky užitečný nástroj.

Napsali o Google Desktop Search

Skype - internetová telofonie

Na veřejnou internetovou telefonii Skype mě přivedl Filemon. V podstatě Vám stačí připojení k internetu a klientský prográmek Skype (registrace s vytvořením konta je součástí). Nic víc a nic míň. V rámci registrovaných uživatelů voláte zdarma, volání na pevnou linku je za pakatel. Skype umožňuje konferenční volání až čtyřech uživatelů a instant messaging. V českých luzích a hájích fungují komunitní servery Skype.cz a Skyper.

Napsali o Skype

středa 1. prosince 2004

Vývoj plug-inu: jak si povodit Eclipse

Pokud se rozhodnete pro vývoj vlastního plug-inu pro Eclipse, bez kvalitního zázemí v podobě dokumentace a vývojového nástroje se neobejdete. Než se rozhodnete investovat čas do hledání dokumentace, doporučuji použít integrovanou dokumentaci přímo v Eclipse. Kromě toho, že obsahuje příručky Plaform Plug-in Developer Guide, JDT Plug-in Developer Guide nebo PDE Guide, umožňuje klasické vyhledávání podle klíčových slov. Další výhodou integrované nápovědy, představuje napojení na API dokumentaci (JavaDoc) runtime komponent. Velkou nápovědou je Official Eclipse 3.0 FAQs (special thnx to ienik).

V čem jiném vyvíjet plug-iny pro Eclipse, než v samotném Eclipse. Eclipse má pro vývoj plug-inu speciální sadu nástrojů sdruženou pod Plug-in Development Environment (PDE). Díky PDE můžete celkem snadno,alespoň pro mě to platilo, proniknou do tajů vývoje vlastních rozšíření. Takže vzhůru, PDE Does Plug-ins. Každý pořádný eclipse vývojář by neměl minout Eclipse Corner Articles.

neděle 28. listopadu 2004

Články na víkend

Dávat tipy na články pro víkend, který právě končí, je trochu matoucí, ale význam této rubriky se posunul do nadčasového charakteru. Kromě toho, že jsem si na konci týdne plácnul s partičkou kolem Filemona, mě zaujalo několik zajímavých článků. Především další díl seriálu Hříchy pro šíleného korektora s podtitulem autentizace, autentikace nebo autentifikace?, mi udělal radost.

Společnost Google považuji já osobně, podle informací, které občas prosáknou na veřejnost, za nejpokrokovější softwarovou firmu. Kromě geniálního tahu s uvolněním 20% pracovního času pro mimoprojektové aktivity, přišel se zavedením vnitro firemního systému B.I.G (Blogger in Google) pro blogování.

Na první pohled to je určitě geniální tah, jak vylepšit infrastrukturu intranetu. Určitě není Google první firmou, která se rozhodla využít blogy ve vnitřní infrastruktuře, ale je pravděpodobně první velkou firmou, ve které se to podařilo masivněji realizovat.

čtvrtek 25. listopadu 2004

Sun Java Plug-in Vulnerability

No a pak, že nerostou. iDEFENSE oznámili novou zranitelnost Java plug-inu (via Actinet Sun Java Plug-in pro www prohlížeče, spuštění kódu), který je součástí JRE. Technologie Java plug-in se používá k propojení Javy a internetových prohlížečů především k běhu Java Appletu. Bezpečnostní díra byla detekována na Java 2 Platform, Standard Edition (J2SE) 1.4.2_01 a 1.4.2_04 from Sun Microsystems. Předpokládá se, že i předešlé verze mohou být postiženy touto chybou.

Díky této chybě mohou být kompromitovány všechny prohlížeče používající tuto technologii, namátkou Internet Explorer, Mozilla, Firefox a to bez ohledu na operační systém. Chyba byla opravena v J2SE v 1.4.2_06.

středa 24. listopadu 2004

Ant a malá "zrada" kompilace

Tento příspěvek mám v hlavě již delší dobu, jenom nebyl čas se podělit o zajímavou true story. Bylo nebylo, Hloupý Honza vyrazil na instalaci aplikačního serveru spolu s nejnovější verzí softwaru společnosti Pohádka s.r.o. Jelikož byl Honza hloupý a nikoliv líný vše si pečlivě připravil. Úhledně připravený distribuční balíček, byl vytvořen z posledního stavu v CVS, pomocí mravenečka jménem Ant.

Posílen buchtami od maminky, vyrazil na cestu do království za sedmero řekami a horami. Honzův úkol v podobě nainstalování se povedl na výbornou. Drak na obloze objevil se při testování funkčnosti. Marně sváděl udatný bojovník souboj s Drakem, ostrý meč v podobě aktuálních zdrojů jenž platil na cvičišti nepomáhal. S nepořízenou se domů Honzík vrátil. Zrada se ukázala druhý den, ten mrzký sluha Ant byl vinen, on zradil pána svého.

Po této pohádkové vložce se přesuneme k problému. Máme třídu Foo a třídu Constant. Třída Constant obsahuje pouze konstanty, které využivá třída Foo.

 
public class Constant {
    public static final String SOMETHING_FISHY = "Something fishy";
}

public class Foo {
    public static void main(String args[]){
        System.out.println(Constant.SOMETHING_FISHY);
    }
}
 

Pro kompilaci máme antovský task.

 
<target name="build">
        <mkdir dir="${build.dir}"/>    	
        <javac 	destdir="${build.dir}" 
        		target="1.4" 
        		debug="true" 
        		deprecation="false" 
        		optimize="false" 
        		failonerror="true"
        >
            <src path="${src.dir}"/>            
        </javac>   	
</target>
 

Build task pustíme a necháme si zdrojové kódy zkompilovat. Zkompilovaný prográmek pustíme

 
java Foo

Something fishy
 

Výsledek zcela očekávaný. Uděláme malou úpravu zdrojového kódu a hodnotu konstanty SOMETHING_FISHY změníme.

 
public class Constant {
    public static final String SOMETHING_FISHY = "Kim Philby";
}
 

Znovu pustíme build task a zkompilovaný prográmek.

 
java Foo

Something fishy
 

Místo očekávaného Kima Philbyho máme na výstupu Something fishy, kde je chyba? Bohužel to není chyba, ale je to vlastnost. Ant se rozhodne třídu zkompilovat pokud nemá odpovídající class soubor a nebo pokud je class soubor starší než třída resp. zdrojový soubor. To v našem případě sice platí, ale kompilátor z důvodu optimalizace přikompiluje obsah konstanty do třídy Foo. O tom se můžeme přesvědčit dekompilací.

 
// Decompiled by DJ v3.5.5.77 
// Copyright 2003 Atanas Neshkov  Date: 24.11.2004 8:22:41
// Home Page : http://members.fortunecity.com/neshkov/dj.html  
// - Check often for new version!
// Decompiler options: packimports(3) 
// Source File Name:   Foo.java

import java.io.PrintStream;

public class Foo
{

    public Foo()
    {
    }

    public static void main(String args[])
    {
        System.out.println("Something fishy");
    }
}
  

Spásou by mohl být antovský depend task, žel bohu na konci jeho popisu najdeme v sekci Limitations následující odstaveček

The most obvious example of these limitations is that the task can't tell which classes to recompile when a constant primitive data type exported by other classes is changed. For example, a change in the definition of something like

 
public final class Constants {
  public final static boolean DEBUG=false;
}
 

will not be picked up by other classes.

Co dodat závěrem kromě toho, že mě alias Hloupého Honzu to pěkně vypeklo? Snad jen radu, přidejte si na první místo build war tasku smazání cílového adresáře pro classes. Pokud si chcete ověřit chování, zdrojové kódy jsou k dispozici.

úterý 23. listopadu 2004

Jetspeed 2 pod lupou

Pod křídly Apache Software Foundation (ASF) roste plno nadějných open source projektů. ASF rozšířila svojí pozornost na oblast portálů díky projektu Jetspped. Jetspeed představoval první open source implementaci java based portalu. Vzrůstající boom kolem portálů nechal vzniknout globálnějšímu Apache Portals Project.

Na základech Jetspeedu a JSR 168 (Java Portlet Standard)byl vybudován Jetspeed-2. Seznam novinek, současný stav Jetspeedu-2 a další informace přinesl Navaneeth Krishnan v rozhovoru What's Happening with Jetspeed-2? s Davidem Taylorem (Jetspeed vývojář,člen JSR 168).

Jetspeed 2 - Seznam novinek

  • Fully compliant with the Java Portlet API standard
  • Separation of portlet applications from portal
  • Live deployment model for portlet applications and portal layouts
  • Component-based architecture based on Spring
  • Multi-threaded portlet aggregation engine
  • Scalable cluster architecture
  • Pipeline-based request processing
  • JAAS security components
  • Apache Portal bridges (Jakarta Struts, Java Server Faces, PHP, Perl integration, Jakarta Velocity)
  • CMS-based site navigation
  • SSO component
  • Web content component
  • Web services component

Související články Dagblog

pátek 19. listopadu 2004

Články na víkend

Tento týden mě překvapilo několik událostí. Protože si připravuji pro kolegy povídání o groupware GForge, zaujaly mě zmínky o projektu Coefficient postaveném na Jave/J2EE. Přes Coefficient jsem se dostal na issue tracker JIRA. K vazbě JIRA-Coefficient se váže zajímavé obvinění, která padlo na TheServerSide.

Někteří z diskutující obvinili vývojáře Coefficientu, že si vypůjčili (ukradli) grafiku z projektu JIRA. Celá záležitost došla tak daleko, že TSS se oficiálně distancovalo. Dohra tohoto případu pak vyústila v oficiální stažení domovské stránky projektu Coefficient, která byla nahrazena následujícím prohlášením.

Site temporarily down

The coefficient demo site is currently undergoing maintenance, and is temporarily unavailable.

Some of the presentation elements for the issue tracker were borrowed (without permission) from jira. These are currently being replaced with original artwork and html. The site will be available again as soon as this task is complete.

Ještě jedna roztržka proběhla, staří kohouti JBoss Group a Apache Software Foundation, se do sebe opět pustili. Mezi zprávy, které mě potěšily patří Language Oriented Programming a Domain Specific Languages, o kterých se blogovalo u nás doma.

středa 17. listopadu 2004

Happiness na druhou

Filemon se pustil do meditace na téma IT business, peníze, práce a zábava.

Programovani mam rad a myslim, ze bych programoval nebo se minimalne zajimal o IT, i kdyby nebylo zrovna kurzu. Ale uz vim, ze kdyby nebylo tak dobre placeno, tak bych si vybral jine zamestnani. Jo asi jsem ten bonvivan. Radsi bych se treba vrtal v autech, cetl blogy, studoval historii, paril profesionalne hry, delal hudbu nebo se proste jen bavil s lidma. IT se venuju, protoze mi dava dostatecne prostredky pro me mimopracovni aktivitky.

Jakákoliv forma IT businessu je pro mě osobně především zábava. Nevím jestli slovo zábava vystihuje přesně ten postoj, asi by bylo na místě použít slovo koníček. Vůbec si nedovedu představit, že bych dělal jakoukoliv práci aniž by pro mě nebyla svým způsobem zábavou. Nepopiratelný fakt je ten, že se jedná o relativně dobře placenou zábavu. Finance pro mě osobně hrají důležitou roli, ale dělat nějakou práci jenom pro peníze bych nerad.

Pracovní stereotyp, o kterém se Filemon zmiňuje, představuje pro mě osobně velký problém a frustraci. I když mám určité výhrady k procesům ve firmě kde jsem zaměstnán, tak mi nadřízení dávají velký prostor k vlastní seberealizaci a i patřičnou volnost, což je pro mě osobně důležitý faktor. Podstatnou roli pro mě hraje i pracovní kolektiv jehož jsem součástí.

Práce jako koníček nenese pouze ovoce, tedy alespoň pro mě nikoliv. Člověk nepracuje jenom tradičních deset hodin v zaměstnání, ale přijde domu a tam opět zapíná počítač. Někdy je to celkem unavující vstávat ráno v šest hodin a chodit spát kolem půlnoci, aby člověk stihnul všechny aktivity.

IT business má pro mě ještě sociální specifikum, říkám tomu hospodský syndrom. Zkuste si s kamarády jiného povolání popovídat, třeba u piva, o práci. Jakákoliv iniciativa z vaší strany skončí z 90% nepochopením. Na druhou stranu, moje oblíbená skupina Chinaski zpívá v písničce Kutil Má práce je moje hobby, šťastnej kdo to tak má ... a já jsem štastnej.

Eclipse a drobné maličkosti - podpora JUnit

Vývojové prostředí Eclipse integruje přímou podporu unit test frameworku JUnit. K dispozici máme několik užitečných funkcí, které usnadňují unit testy vytvářet, spouštět a vyhodnocovat.

Vytvoření testovacího objektu

Eclipse usnadňuje práci při vytváření testovacích objektů pomocí jednoduchého wizarda. Nad objektem, pro který chceme vytvořit testovací objekt, klikneme pravým tlačítkem a přes New >> Junit Test Case vyvoláme wizarda.

Vyvolání wizardu

Vyvolání wizard okna

Pokud v nabídce New chybí položka JUnit Test Case, můžeme ji aktivovat přes Window >> Customize Perspective >> záložka Shortcuts >> Submenus New >> rozbalit volbu Java a zatrhnout JUnit.

Wizard

První okno wizardu nabízí základní volby vycházející z možností JUnit. Můžeme si například nechat vygenerovat metody setUp, tearDown nebo nastavit test runner.

Prvni wizard obrazovka

Tlačítko Next nás přenese na další okno, kde je možné zvolit metody, ktere si přejeme na objektu testovat. Pro tyto metody budou vygenerovány jejich testovací skořápky.

Druhá wizard obrazovka

Vytvoření Test Suite

Stejně jako pro vytvoření testovacího objektu, tak pro vytvoření Test Suite nabízí Eclipse pomoc. Wizard pro Test Suite se vyvolá obdobným způsobem jako pro testovací objekt. New >> Junit Test Suite . Do Test Suite jsou automaticky zařazeny všechny testovací objekty v rámci package.

Test suite wizard

JUnit view

JUnit view je pohled, který poskytuje grafické rozhraní s jehož pomocí sledujeme výsledky testů a můžeme prohlížet chyby. Pokud nemáte JUnit view v perspektivě, aktivujte jej přes nabídku Window >> Show view >> Other >> Java >> Junit

JUnit view

Spuštění testů

Rozhraní pro spouštení testů je další funkce, která usnadňuje práci s testy. Test lze spustit kliknutím pravým tlačítkem na testovací objekt a přes nabídku Run >> JUnit Test. Další možností je nabídka Run >> Run As >> JUnit Test. Graficky je průběh testu zobrazen v JUnit view.

Související články

úterý 16. listopadu 2004

Meditace o benchmarku webových serveru

Existují tři druhy lží - lži, úplné lži a benchmarky

Také jste narazili na kampaň Get the facts firmy Microsoft? Kampaň je také cílena na propagaci studie, v rámci které byl porovnán výkon webových serveru Windows 2003 Server/IIS a Red Hat 8.0/Apache. Na tuto studii připravil pohled z druhé strany Michal Kára v článku Fakta o faktech Microsoftu.

pondělí 15. listopadu 2004

Nepoužívám antivir, jsem exot?

Safra, kde mám to číslo správce sítě? ÁÁÁÁ tady je 222236987, telefon zvoní.

  • : Dobrý den, mám problém s mailovou schránkou. Bohužel se mi nedaří stáhnout poštu. Je velice zajímavé, že odesílat mohu v pořádku.
  • Správce: hmm ... a nebude problém v účtu, máte dobře přihlašovací jméno a heslo?
  • : Zcela určitě, zkoušel jsem se přihlásit přes webové rozhraní a stejné jméno a heslo mám i v poštovním klientu.
  • Správce: Co antivir, máte ho aktualizovaný?
  • : Antivir? Tím to být nemůže.
  • Správce: Jak to můžete vědět? Restartoval jste počítač?
  • : Ne, to obvykle nedělám. Naposledy asi před měsícem
  • Správce:krátká odmlka, co ten antivir, je aktualizovaný?
  • : Antivir? Tím to být nemůže.
  • Správce:Jak to můžete vědět?
  • : Vím to! Antivir jsem asi před rokem odinstaloval.
  • Správce:Cože, proč?(udiveně)
  • : Nefungoval podle mých představ
  • Správce:Jak to, že nemáte na počítači antivir? Jak je to možné?
  • : Zpět k problému, nefunguje mi ta pošta a antivirem to není
  • Správce: Máte na počítači vir, musíte si okamžitě nainstalovat antivir!
  • : Podle čeho soudíte, že mám na počítači vir? (zřejmě podle toho, že nemám antivir)
  • Správce: Chování, které popisujete je typické pro vir. Musíte si okamžitě nainstalovat antivir!
  • : To myslíte vážně? Chcete mi naznačit, že vir se chová tak, že neumožňuje stáhnout poštu?
  • Správce: Ano to myslím vážně, takto se chovají viry!
  • : Dobrá, zkusím si s tím poradit. Děkuji za váš čas(rezignovaně)
  • Po pár minutách se ukázalo, že problém byl na straně poštovního serveru.

Jsem asi exot, ale zatím mě žádný vir nepřinutil ani k pohrávání si s myšlenkou, že bych svůj počítač devastoval něčím tak ohavným jako je antivir. Přes tři roky jsem víceméně spokojený uživatel operačního systému Windows 2000 (práce) a Windows XP (domov). Za tu dobu jsem se reálně setkal s virovou nákazou počítačové charakteru pouze prostřednictvím kolegova počítače diky nezáplatovanému Outlook Expressu. Jinak o virových pandemiích slyším především prostřednictvím médií.

Moje letité zkušenosti s viry mě, a to i přes katastrofické scénáře prezentované formou pravidelného virového sloupku Pavla Baudise (ALWIL software) v časopise Chip, nechávají v klidu. Antivir se hodí tam kde nákaza proběhla, používat antivir jako prevenci mi přijde stejné jako používat zimní pneumatiky a věřit, že nedostanu smyk.

Obojí je samozřejmě nesmysl. Opravte mě pokud se mýlím, ale ještě jsem neslyšel o antiviru, který by účinně předešel virové nákaze před novým typem virem. Antivirové programy resp. jejich updaty jsou k dispozici vždy s pověstným křížkem po funuse. Antivirové společnosti jsou si, těchto "kosmetických" nedostatků vědomi a proto implantují antivir hluboko pod kůži operačního systému.

Z mého pohledu jsou dnešní viry pouze slabými odvarky stavícími na základech sociálního inženýrství. K aktivaci takového viru je potřeba notná dávka uživatelova, promiňte za ten výraz, idiotismu. Objevilo se pouze pár kousků bez nutnosti interakci uživatele. Pokud pomineme tuto menší skupinu, kterou odfiltruje firewall a bezpečnostní záplaty, zůstane nám antivir pouze jako módní doplněk.

Nesnažím se zlehčovat dnešní situaci v oblasti bezpečnostní problematiky ba naopak. Používám k plné spokojenosti firewall a poštu si chráním řádně vytrénovaným spam filtrem, který všechny pseudoviry posílá do věčných lovišť. Snažím si vybírat a také dbát o software jenž používám a k této rutině patří pravidelná bezpečnostní aktualizace.

Antivir nepoužívám a používat nebudu, dokud mě reálný případ nepřesvědčí o jeho užitečnosti v oblasti prevence proti virové nákaze, které by šlo předejít jinak běžnými prostředky. Do té doby budu považovat antivir za nepotřebný kus softwaru.

čtvrtek 11. listopadu 2004

Programátorská hádanka

Dnešní programátorská hádanka je spíše dětským lechtadlem. Mějme následující kód.


	int array [] = new int[10];	
	for(int i = 0; i < array.length; i++){
		.
		.
           }

Na jaký počet příkazů, a to bez použití modula, nejefektivněji naplníte pole, tak aby se pravidelně střídala jednička s nulou tj. ve výsledku 1010101010.

Třívrstvá architektura v kostce I.

Úvod

Ač vědomě či nevědomě se s produkty postavenými podle moderního scénáře business aplikací, též nazývaného třívrstvá architektura, setkáváme na každém kroku. Nevěříte, tak si položte otázky, jestli jste někdy používali online shop, eleketronickou rezervaci hotelu, letenky či ubytování nebo jste využili servis některého zpravodajského portálu. Pokud je vaše odpověď ano, pak jste s pravděpodobností hraničící s jistotou, narazili na třívrstvou, někdy též nazývanou vícevrstvou, architekturu.

Proč tři a ne dvě?

Model třívrstvé architektury je přímou evolucí, z dnešního pohledu již koncepčně zastaralé, dvouvrstvé architektury. Dvouvrstvá architektura vychází z vrstvy klientské a vrstvy datové, jak ukazuje následující obrázek.

Obrázek ukazuje dvě vrstvy, vrstvu klientskou a datovou

Klient obsahuje většinu aplikační logiky, se kterou pracuje přímo nad datovým zdrojem. V mnoha scénářích je zdroj dat reprezentován relační databází a klient využívá jazyk SQL pro práci s daty. Mezi další typy datového zdroje patří soubory a nebo jiné aplikace např. informační systémy.

Nevýhody tohoto modelu se ukázaly při vzrůstající komplexností klientských aplikací. Se složitostí aplikací vzrůstaly výkonové nároky na klientské počítače což byl jeden faktor. Další faktory přímo vyplynuly z masivního rozšíření aplikací, softwárové firmy byly nuceny pružně reagovat na poptávku a tím pádem se snažit operativně plnit přání zákazníků. Z těchto business procesů byly definovány požadavky na budoucí aplikace. Například nutnost sdílení zdrojů, omezení datového přenosu atd., diky kterým se začalo uvažovat o architektuře, která by tyto požadavky pokryla.

Řešení se našlo v podobě přidání třetí - střední vrstvy (middle tier). Samozřejmě se nejednalo pouze o přidání vrstvy, bylo nutno specifikovat jednotlivé vrstvy resp. jejich role v architektuře. Třívrstvou architekturu znázorňuje následující obrázek.

Obrázek ukazuje tři vrstvy, vrstvu klientskou, 

aplikační a datovou

Staronový význam jednotlivých vrstev

S přechodem na třívrstvou architekturu se posunul i význam jednotlivých vrstev, nejmarkantněji se to projevilo u vrstvy klientské. Díky nově definované aplikační vrstvě bylo možné aplikační logiku, která do té doby ležela na klientu, přesunout na aplikační server. Díky tomuto tahu se klientům značně ulevilo neboť veškerý výpočetní výkon byl přesunut na výkonné servery.

Diky přesunutí aplikační logiky na jedno místo bylo možné dosáhnout jejího sdílení a lepší správy a dostupnosti. Aplikační vrstva prezentovaná aplikačním serverem mohl a nabídnout služby v podobě rozložení zátěže (load balancing) či výpadku (fail over). Významnou měrou se podařilo redukovat datový přenos, jehož těžiště se přesunulo na trasu mezi aplikačním serverem a datovým zdrojem. Spojení aplikačního serveru a datového zdroje bylo možno realizovat vhodným přenosovým připojením. Snížení datového přenosu přímo ovlivnilo rychlost odezvy klientů a umožnilo jejich připojení na linkách s omezenou přenosovou rychlostí .

Tenký a Tlustý klient

Takto "očesaní" klienti možná zavdali příčinu k jejich pojmenování na tenké klienty (thin client) . Obecně byla ovšem klientská vrstva definována jako vrstva, která je určena pouze k prezentaci dat uživateli. Tenký klient je proto takový klient, který neobsahuje žádnou aplikační logiku. Aplikační logiku mu zprostředkuje aplikační server, ke kterému tenký klient přistupuje. Naopak tlustý klient, v dvouvrstvém modelu pouze klient, obsahuje většinu aplikační logiky. Ve skutečnosti i tenký klient musí nějakou aplikační logiku obsahovat, ale oproti tlustému klientu je to naprosto zanedbatelná část.

A co webový prohlížeč?

Webový prohlížeč, v rámci předchozí definice, spadá do skupiny tenkého klienta. Já osobně rozlišuji mezi prohlížečem a tenkým klientem. Prohlížeč postavený na standardech webu používá pro popis grafického uživatelského rozhraní (GUI) jazyk HTML a CSS. Jazyk HTML v kombinaci s CSS nenabízí takové možnosti oproti tenkým klientům, aby bylo možné popsat složitější rozhraní. Další nevýhodou prohlížeče je svázání s modelem žádost/odpověď (request/response) nastaveným HTTP protokolem.

Tyto odlišnosti mě vedou k rozlišování pojmu webový prohlížeč a tenký klient v kontextu třívrstvé architektury. Mezi častý omyl patří rozlišování tenkých a tlustých klientů podle toho jestli se jedná o webový prohlížeč. K tomuto bych rád podotknul, že klíčovým faktorem není to jestli se jedná ve výsledku o prohlížeč či nikoliv, ale rozložení aplikační logiky.

Datová vrstva

U datové vrstvy též nazývané backend nedošlo v třívrstvém modelu k žádnému posunu. Tato vrstva slouží jako datová základna a lhostejno jestli je v pozadí relační databáze, souborový systém, webová služba či jiná aplikace.

Aplikační vrstva

Jak již bylo vzpomenuto o pár odstavců výše, aplikační vrstva v podstatě tvoří skořápku pro aplikační logiku. Tato vrstva resp. aplikační logika zajišťuje přístup k datům, práci s daty a z jejich vystavení ve vhodném formátu (XML, HTML) pro klient vrstvu. Z pohledů doby zaznamenala aplikační vrstva právě nejbouřlivější vývoj. Jako nejjednodušší realizaci aplikační vrstvy můžeme považovat webový server s CGI rozhraním, jehož pomocí se volaly výkone rutiny prezentované spustitelnými soubory a později serverovými skripty.

Komplexnost aplikační vrstvy vedla k jejímu dalšímu rozdělení na vrstvy. Toto rozčlenění pomohlo definovat odpovědnosti jednotlivých vrstev v rámci aplikační vrstvy. Vrstvy jsou definovány jako prezentační (presentation), aplikační (business) a datová (persistence). Na pomezí těchto vrstev leží například MVC (Model View Controller), ORM atd., ale o tom v příštím díle. Samozřejmě pokud bude zájem.

úterý 9. listopadu 2004

Proč trpíme za standardní dialogy lokalizovaných Windows aneb to snad nemyslíte vážně pane úředníku

Vždycky když slyším nějakou povedenou historku o uživatelích, tak připočtu nějaké to procento vtipnosti na vrub vypravěče. To bych neměl dělat! Dneska jsme obdrželi oficiální připomínky k webové aplikaci. Součástí aplikace je stažení souboru s výsledky, dialog pro stažení samozřejmě obhospodařuje internetový prohlížeč.

Když jsem četl připomínky k těmto dialogovým oknům tak jsem nevěřil vlastním očím, no posuďte sami (přikládám autentické obrázky včetně komentáře). Zdroj jsem z etických důvodů zamazal.

1.Vložit mezeru mezi slovy „Přenosová rychlost:“ a veličinou přenosové rychlosti:

2.Opravit chybu ve větě: „Před otevřením souboru thoto typu vždy zobrazit tento dotaz“.

Nejdříve mě to velice pobavilo a říkal jsem si o uživateli, no jak to říci kulantně, prostě něco o jeho inteligenci. Pak mě napadlo, že uživatel vůbec netuší nic o architektuře aplikace a tudíž nemůže vědět, že tyto hlášky padají na vrub lokalizovaným Windows resp. Internet Exploreru. Kdyby záleželo na mě, odkázal bych onoho připomínkovače nejdříve na jednu tiskovou zprávu a potom přímo na Microsoft.

neděle 7. listopadu 2004

Více konfigurátorem než programátorem

Pokud jste se dostali do křížku s nějakou novou technologií, byli jste s velkou pravděpodobností vystaveni nějaké formě konfigurace. Nikoho asi nepřekvapí, že pro konfiguraci se široce zakořenilo XML. XML má pro tento účel plno výhod, z těch základních namátkou, kontrola validity, snadná editace, lidsky čitelná forma.

Většina javovských produktů si vzala výhody xml konfigurace k srdci a tak málokdy narazíte na jinou formu. V tomto směru existují tři váhové kategorie co do rozsahu konfigurace. Do první kategorie, kterou označuji za muší váha, patří rádoby jednoduché utilitky s konfigurací do 30 řádků např. Log4J (framework pro logování) nebo Proxool (database connection pool).

Druhou kategorii, střední váha, tvoří konfigurace do 250 řádků. Mezi klasické zástupce patří servlet konfigurace resp. konfigurace webové aplikace. Do této rodiny patří i konfigurace, v uvozovkách jednodušších nástrojů, jako je Tomcat nebo Jetty (HTTP server a Servlet kontejner).

Třetí kategorii, bez váhové omezení, tvoří takové nástroje, kde konfigurace musí být rozdělena do více souboru, aby byla vůbec nějakým rozumným způsobem udržitelná. Jedná se například o Model-View-Controller frameworky (Struts), IoC kontejnery (Spring, Pico) apod.

Určitě si každý dokáže dosadit do těchto třech kategorií dosadit i produkty, které konfiguroval na vlastní kůži. Samozřejmě ne vždy mnou uvedení zástupci spadají do té či oné kategorie, mohu se pohybovat oběma směry,záleží na rozsahu projektu.

Dalším důležitým faktorem je kumulace jednotlivých konfigurací. Pro webovou aplikace budete potřebovat minimálně servlet a pak MVC konfiguraci. Vaše webová aplikace potřebuje logovat a protože spolupracuje s databází potřebuje i connection pool. Suma sumárum minimálně čtyři konfigurační soubory.

Absolutní extrém tvoří například IoC kontejner Spring, kde konfigurací spojujete jednotlivé vrstvy aplikace. Mezi ty další bych zařadil například konfiguraci deploy adresáře J2EE serveru JBoss, ostatně EJB je v tomto taktéž extrémem. Když to přeženu, jeden aby se ze všech těch konfigurací zbláznil, angličtina má pro to výstižný výraz Metadata hell.

XML konfigurace má z aplikačního hlediska obrovskou výhodu v tom, že vás nenutí svazovat, pěkně česky zadrátovat, jednotlivé komponenty systému na úrovni kódu. Dnes existuje velké množství nástrojů jako Ant či XDoclet, které mohou být velice nápomocny a konfigurační práci usnadnit.

Pokud zvážím všechna pro a proti, tak z mého pohledu se jeví výhodnější přístup pomocí XML konfigurací a to i za cenu, že jsem někdy více konfigurátorem než programátorem.

pátek 5. listopadu 2004

Články na víkend

Tento týden vydal na pěknou úrodu zajímavých článků. Velice mě potěšily nové články Petra Lazeckého, které rozšířily seriál Bezpečnostní toulky. Slibně se rozrůstá seriál o technologii WebML Petra Zelenky. WebML (Web Modeling Language) mě na první pohled zaujala - uvidíme, vyzkoušíme a dáme vědět.

A pokud se budete nudit, můžete vyzkoušet předfinálovku Firefoxe 1.0 RC2 viz Vyšel český i anglický Firefox 1.0 RC2

Gavin King nejen o Hibernate 3

Pokud jste se alespoň trochu zajímaly o problematiku ORM (object to relation mapping) frameworku, pak jste jistě narazily na stálici jménem Hibernate, toho času pod křídly JBoss. Ne nadarmo bývá Hibernate označován de facto za ORM standard.

Na stránkách Javafree.com.br vyšel rozhovor s Gavinem Kingem. Pokud Vám toto jméno nic neříká, pak vězte, že se jedná o duchovního otce a vývojáře Hibernate, a v neposlední řadě člena skupiny pracující na JSR-220 (specifikace EJB 3.0).

Z rozhovoru lze vyčíst některé signifikantní kroky, kterými se bude ubírat Hibernate. Ze skupiny odpovědí lze vyčíst, že Hibernate bude výrazně ovlivněn právě specifikací EJB 3.0, kterou by Sun rád viděl i mimo klasické j2EE kontejnery. Gavin přímo mluví o tom, že Hibernate bude tuto specifikaci implementovat.

Další výrazný posun se týká ve využití rysů Javy 5.0, kde by měly práci resp. mapování usnadnit anotace. Ještě bych zmínil malé pošťouchnutí specifikace JDO, pro kterou nevidí po nástupu EJB 3.0 místo. Diskusi k článku je možno najít na TSS Interview with Gavin King on Hibernate 3.

Související články

úterý 2. listopadu 2004

Eclipse a drobné maličkosti - uživatelské šablony

Nejsem typ uživatele, který by s železnou pravidelnosti hraničící se sadomasochismem, prozkoumával všechny vlastnosti IDE Eclipse, a to je možná škoda. Asi málokdo neocení podporu vestavěných templates (šablon) v Eclipse a já nejsem výjimka. Přiznám se rovnou, že jsem používal pouze ty jednodušší např. sysout => System.out.println().

Eclipse umožňuje velice snadno vytvářet vlastní templaty. Tuto vlastnost jsem naplno ocenil při včerejším rozjímání nad usnadněním psaní testovacích metod, které jsou společné všem objektům. Specielně se mi jednalo o testovací metody pro equals a hashCode.

Všechny šablony, jak předdefinované tak uživatelské se nalézají v okně Templates viz Window >> Preferences >> Java >> Editor >> Templates.

Zobrazení okna pro definici a úpravu šablon

Krom předpřipravených šablon, si můžeme nadefinovat vlastní a to pro javovský kód i Javadoc. Přes magické tlačítko New se pustíme do nové šablony.

Zobrazení okna pro definici nové šablony

Name
Jméno šablony, pod kterým bude dostupná. Doporučuji něco krátkého a smysluplného.
Description
Textový popis šablony.
Context
Výběr kontextu šablony, která může být použita pro javovský kód a nebo pro Javadoc.
Pattern
Vlastní obsah šablony.

Při psaní šablony by se vám mohly hodit předdefinované proměnné, které se nalézají pod tlačítkem Insert variable. Tímto jsme se dostali pomalu k proměnným, které představují motor šablon. V rámci šablony si můžete definovat libovolné množství proměnných, ale jejich síla se ukáže při opakovaném použití.

Využití proměnných

 
${objectUnderTest} o = new ${objectUnderTest}();
try{
    o.hashCode();
}catch(NullPointerException n){
    fail();
}

${objectUnderTest} o1 = new ${objectUnderTest}(${objectKey});
${objectUnderTest} o2 = new ${objectUnderTest}(${objectKey});

assertTrue(o1.hashCode() == o2.hashCode());
 

Tato šablona vytváří kód pro testování metody hashCode pro POJO objekty. Proměnné jsou uvozeny znakem $ a jejich název je uzavřen v složených závorkách. V této šabloně jsou definovány proměnné objectUnderTest a objectKey. Při použití šablony se definování hodnoty proměnné pronese do všech deklarací, bude vidět opodál.

Aktivace šablony

Pokud máme šablonu připravenou k použití, nic nám nebrání v jejím vyvolání v editoru kódu. Šablona se vyvolá zápisem jejího jména a stisknutím klávesové kombinace pro doplnění (ctrl + space).

Zobrazení vyvolání kontextové nabídky pro výběr šablony dle jejího jména.

Po vyvolání šablony se kolem proměnných vytvoří editovatelné boxy a přiřazení hodnoty do proměnné se pronese na všechna místa jejího užití, jak ukazuje následující obrázek (editována je proměnná objectUnderTest) .

Ukázka přiřazení hodnoty do proměnné a jejího pronesení.

pondělí 25. října 2004

GForge 4.0 venku

Timothy Perdue oznámil uvolnění verze 4.0 open source CDE (Collaborative Development Environment) GForge. Verze 4.0 představila několik významných změn a novinek.

  • Role-based access controls
  • cvs-GForge integration
  • Reporting
  • WebDAV
  • Web Services
  • SCM Refactoring

Novinek a změn je více, ale mě osobně se nejvíce libí změna řízení přístupu, kdy lze definovat jednotlivé role v rámci systému. Díky tomu bude možné efektivně spravovat jednotlivé skupiny vývojového týmu. Pokud jste o GForge neslyšeli, může vám posloužit můj starší spot Gforge - správa softwarových projektů.

pátek 22. října 2004

Programátorská hádanka

Ovlivněn sérií programátorských hádanek Reného Steina jsem si usmyselel, že až narazim na nějakou vypečenost resp. chybu podělím se oni. Naneštěstí jsem nemusel čekat dlouho. V business logice aplikačního serveru mam následující kód.

 
public class CisRozpKapService implements ICisRozpKapService {    
    
    private volatile int maxSkupId = 0;
    .
    .
    . 
	
    public int saveSkupina(int kapitola, String nazev) {
        CisRozpKap kap = rozpKapDao.load(kapitola);
        CisRozpKapSkup skup = new CisRozpKapSkup();
        skup.setCisRozpKap(kap);
        skup.setNazev(nazev);
        synchronized(this){
            maxSkupId++;            
        }
        skup.setSkupina(maxSkupId);           
        rozpKapSkupDao.save(skup);        
        return skup.getSkupina().intValue();
    }
    
    .
    .
    .
}
 

Pro upřesnění dodávám,že maxSkupId musí být pro každý ukládáný objekt jedinečné.... Najdete a odtsranité chybu?

pondělí 18. října 2004

Kontraproduktivní blokování vyskakovacích oken

Microsoft a jeho nepovedené dítko Internet Explorer se v posledním záchvěvu bezpečnostní mánie SP2 rozhodl k ultimátnímu blokování vyskakovacích oken. Nic proti tomu, ale jak se takové vyskakovací okno identifikuje?

V našich webových aplikacích používáme otevírání nových oken pomocí klientského skriptu zcela běžně, jedná se například o výběry typu číselník. Chtěl jsem tedy říci používali, po aplikaci service packu, jsou otevíraná okna blokována což je pro nás problém.

Vysvětlete koncovému uživateli, že si má nějakou takovou funkčnost vypnout u sebe v nastavení. Samozřejmě, že by na takovýto zásah neměl mít vůbec oprávnění. Naštěstí údajně existuje cesta jak nastavit cosi magického na doménovém serveru (oficiální rada z technické podpory společnosti Microsoft), co by mělo přetlačit nastavení lokálních stanic v síti.

Nesetkal se někdo s podobným problémem? Neexistuje cesta jak omezení blokování oken omezit pouze na internet? Takhle mi totiž přijde, že pokud nebude existovat cesta rozumného nastavení, bude blokování oken spíše kontraproduktivní.

pátek 15. října 2004

Články na víkend

Nepravidelná rubrika s tipy na články, které mě za týden zaujaly. Pro tenhle týden převládají odkazy na české bloggery, kteří se pilně činili. Máme tu trochu extrémismu v programování, typologii českých vývojářů a nebo prohledávání lokálního disku velkým Googlem.

středa 13. října 2004

Závidím českým dotneťákům Microsoft

Nevěřím, že by byla technologie .NET o tolik lepší nebo jednodušší a nebo levnější o proti Jave. Na to kolik se .NETu věnuje českých článků a bloggu (především na vyvojar.cz), mi přijde že nám trochu javistům ujel vlak. Vlastně nesejde na tom, jestli je jedna technologie v určitém aspektu horší nebo lepší, limitujícím faktorem je komunita kolem ní.

Pokud je komunita dostatečně velká, existuje celkem slušná pravděpodobnost, že ve svém středu najde jedince - skupinu jedinců, kteří ji budou obohacovat. Na komunitu působí externí vlivy, které mohou komunitu výrazně posilňovat a ve svém důsledku komunitu rozšiřovat.

Vždycky když jsem přemýšlel o tom proč Java "mediálně" zaostává za .NETem, tak mě napadali ve skrze dva důvody. Nás javovských vývojářů je výrazně méně, tedy naše komunita není tak veliká, aby produkovala dostatečné množství jedinců, kteří by ji obohacovali. Nebo na naši komunitu působí výrazně menší vnější vlivy než na komunitu kolem technologie .NET.

Pokud není javovská komunita co do počtu vývojářů větší, o čemž jsem přesvědčen, tak je minimálně srovnatelná s .NET komunitou. Vylučovací metodou mi tedy zůstaly externí vlivy. Externí vlivy za .NET komunitou asi není těžké pojmenovat, stojí za nimi samotný Microsoft resp. u nás jeho česká pobočka.

To co je pro .NET Microsoft, pro nás javisty představuje a nebo by alespoň měl Sun. resp. opět jeho česká pobočka. Je mi smutno, když si vzpomenu na vzletná prohlášení o podpoře komunity vývojářů, která zazněla během Sun Tech Days, mimochodem jediné větší akce, která se konala zhruba před rokem.

Opravte mě pokud se mýlím, ale Sun CZ neudělal pro nás vývojáře takřka nic. Nabízí sice školení a certifikace, ale lokalizovaný materiál o Jave, aby jeden pohledal. Škoda, kdyby projevil větší snahu, mohla se naše komunita ke svému vlastnímu prospěchu a potažmo prospěchu Sunu rozšířit. Takhle mi nezbývá než českým dotneťákům zavidět Microsoft CZ.

Související reakce

Domácí úkol z vláken: filozofové

V nedávném spotu ABC synchronizace pro mírně pokročilé jsem mimo jiné upozorňoval na domácí úkol, který se k článku vztahoval. Jak mi později prozradil Tomáš, problém pěti filozofů patří do kategorie cvičebnicových příkladů.

Zadání (angl. originál)

Five philosophers sit around a circular table. Each philosopher alternates between thinking and eating rice. In front of each philosopher is a bowl of rice that is constantly replenished by a dedicated waiter. Exactly five chopsticks are on the table, with one chopstick between each adjacent pair of philosophers. Each philosopher must pick up both chopsticks adjacent to his/her plate simultaneously before that philosopher can eat.

Create a Java application that simulates this behavior. Avoid deadlock and the problem of indefinite postponement, where one of more philosophers soon starve because philosophers adjacent to the starving philosophers are always eating. Make sure that mutual exclusion is enforced, so that two adjacent philosophers do not use the same chopstick at the same time.

Postup

Abych přiznal barvu, tak musím říci, že mě ten problém zaujal a nechtěl jsem jej opustit, než naprogramuji řešení. Moje řešení je založeno poolu hůlek.

Pokud chce filozof jíst "požádá" stůl o hůlky, stůl pak deleguje žádost na pool. Pokud v poolu hůlky nejsou, je vlákno (filozof) zastaveno a zařazeno do fronty. V případě, že filozof vrátí hůlky, jsou čekající vlákna vzbuzena. Pokud je vlákno zároveň na začátku fronty a jeho hůlky jsou volné, pak jsou mu hůlky vráceny. Program vypisuje jednotlivé kroky do konsole.

pátek 8. října 2004

Jak správně bastlit software

Tento spot nemusíte brát vážně, ale berte na vědomí, že vychází z mé frustrace nad vývojem software v jedné..., ale to je jedno.

Analýza

První a základní předpoklad je nemít v ruce žádnou a nebo chabou analýzu problému. Analýzu musíme zásadně posuzovat podle počtu stránek a počtu cizích slov nebo odstavců či kapitol, kterým nerozumíme. Úplně nejlepší je vytvořit analýzu bez klienta neboť mi sami nejlépe víme co si klient představuje. Takto připravenou analýzu je potřeba během vývojového procesu nejméně dvakrát až třikrát pozměnit.

Datový model

Rozhodně nenavrhovat domain model a nemodelovat vztah jednotlivých entit, začít se přece musí od databáze. Takže podle první verze analýzy, databázové tabulky a sloupečky můžeme přece dropnout, takzvaně "nastřelíme". Slovo nastřelíme společně se slovem překlopíme si zařaďte do vývojářského slovníku, budete jej často slyšet. Takto připravený datový model je potřeba s každou změnou analýzy upravit, chtěl jsem říci nastřelit.

Domain model

Domain model je třeba přišít na datový model tj. vytvořte domain objekty přesně podle datového modelu. Pokud datový model neobsahuje velké množství složených klíčů je to špatně. Surrogate klíčů se vyvarujte neb hlásat tuto viru rovná se kacířství. Vytvořte pro všechny domain objekty testy, jejichž úprava ruku v ruce se změnami datového modelu bude milým zpestřením vašich desetihodinových šicht.

Protože jdete ruku v ruce s moderními technologiemi použijte nějaký, pro vás neokoukaný, persistence framework. Nebojte, všemi zaludnotsmi mapování domain modelu na databázový, si dvakrát až třikrát projdete společně se změnou analýzy.

Service a DAO vrstva

Připravte rozhraní service a DAO vrstvy podle nejlepšího svědomí a vědomí, jeho změnu společně s implementací si ještě několikrát vyzkoušíte. Nastřelte si pro tyto vrstvy testovací objekty.

Co dodat závěrem?Vítejte v éře bastlení software, kde jakákoliv koncepce postrádá smysl. Má cenu se snažit o progresivní metody vývoje softwaru? Ne nemá, jediné co by nepostrádalo smysl, je zvážení další participace na neoddalitelného harakiri chlebodárného software house.

ABC synchronizace pro mírně pokročilé

Problematika vláken resp. synchronizace v Jave patří k mým oblíbeným tématům, o kterých si rád něco přečtu. Článek Java Tech: The ABCs of Synchronization, Part 2 Jeffa Friesena je psán tak, že není třeba dokonalá znalost problematiky a díky tomu je možné pochopit i složitější problémy.

Článek nás obeznámí s wait a notify mechanismem, předvede ukázkový příklad typu producent-odběratel, nastíní problém s lokálními kopiemi hodnot a k dobru přidá krátký popis nových tříd z package java.util.concurrent (J2SE 5.0). Na konci článku je navíc domácí cvičení, mimochodem velice zajímavé, které by mělo prověřit nabyté znalosti.

úterý 5. října 2004

Migrace na Javu 5.0, realita nebo utopie?

Asi nejsem sám komu se na disku hřeje nově vypuštěná Java 5.0. Otázkou těchto a příštích dnů je jestli na ni má cenu přejít. Nejde ani tak o Javu samotnou, ale o její podporu. Můžeme si dovolit přejít na verzi 5.0 a co nám to přinese?

Podle mého názoru bychom měli rozlišovat dva odlišné pohledy. První pohled je zaměřen na vlastní vývojovou stránku procesu. Máme v rukou nástroje, které dokáží využít potenciál nových vlastností platformy? Mám na mysli v první řadě vývojová prostředí.

Nebudu dalek od pravdy, když prohlásím, že většina IDE nepodporuje plně všechny novinky, které představila verze 5.0. Mnou používány Eclipse je toho důkazem. Z release notes verzí 3.1 M2 a 3.1 M2 lze přímo vyčíst, že příprava na plnou podporu je na začátku. Trochu lépe na tomu bude zřejmě IDE NetBeans resp verze 4.0 Beta 2. Komerční prostředí jako JBuilder a IntelliJ IDEA se sice chlubí plnou podporou, ale otázkou zůstává jestli to tak opravdu je?

Pokud bychom nechali stranou vývojová prostředí, zůstanou nám další nástroje a frameworky, které používáme. Na scéně se již začínají objevovat první vlaštovky, které se hrdě hlásí k verzi 5.0, například Tomcat 5.5. Na druhou stranu jsou to opravdu výjimky, které můžeme zanedbat.

Druhý pohled je zaměřen na vlastní nasazení produktů na verzi 5.0. Prozatím nejsou známy výsledky výkonových testů a porovnání verze 5.0 proti řadě 1.4.x případně 1.3.x. Důležitým faktorem je spolehlivost a bezpečnost, uběhlo málo času na to, aby byla verze 5.0 lépe řečeno JRE řádně otestováno mimo laboratoře Sunu.

Verze 5.0 je přelomová a prosadí se, ale z mého pohledu by byla migrace z pohledu vývoje tak i nasazení předčasná. Asi nemá cenu střílet od boku nějaká čísla a bylo by to zbytečné, ale já osobně bych počkal minimálně na první aktualizaci 5.0 update 1 a pak bych se rozhodoval podle aktuální situace.

Související články

čtvrtek 30. září 2004

Java 5.0: Tiger vypuštěn

Po několika alfa verzích a release candidates tu máme toužebně očekávanou finální Javu 5.0(podle dřívějšího číslování 1.5) s kódovým označením Tiger. Sun dodržel harmonogram a připravil nám pětkovou verzi na podzim... a houfné stahování může začít.

Související články

středa 29. září 2004

Standardní persistence vrstva pro Javu

Není to tak dávno co jsem psal o trvalých problémech trvalé vrstvy, kde jsem narážel na střet technologií JDO a EJB resp. JDO 2.0 (JSR 243)a EJB 3.0 (JSR 220), které rozdělovaly javovskou komunitu. Vedoucí těchto specifikačních požadavků Linda DeMichiel a Craig Russell napsali otevřený dopis, ve kterém vyzývají k vytvoření jednotné persistentní vrstvy a obecného POJO (Plain Old Java Objects) modelu pro J2SE a J2EE.

Máme tu plno skvostných technologií mimo EJB a JDO jako například Hibernate, které se mohou stát základem pro tvorbu jednotného modelu. Pokud mohu soudit, tak reakce jsou celkem příznivé viz související články.

Související články

Jetty 5.0.0 - další generace na obzoru

Tento spot by se mohl klidně týkat pouze krátké zmíňky o uvolnění servletového kontejneru a http serveru Jetty ve verzi 5.0.0 (implementace Servlet specifikace 2.4), ale netýká. Mám k tomu dva důvody, Jettyho využíváme k běhu našich aplikací, takže k němu mám docela srdečný vztah a zadruhé, duchovní otec Jettyho Greg Wilkins rozumí problematice Servletu jako nikdo jiný.

Když Greg Wilkins publikoval v souvislosti s oznámením verze 5.0.0 příspěvek Next Generation Jetty and Servlets zpozorněl jsem. Greg se pustil do vysvětlení problémů s pull-push API servletů, které by mělo dle jeho soudu prodělat malou revoluci a nikoliv evoluci.

V této souvislosti založil v CVS novou větev JettyExperimental(JE), která je určena právě k otestování vlastností a přístupů, které by mohly zlepšit práci se servlety. Pokud se o technologii Servletu alespoň trochu zajímáte pak vám vřele doporučuji si ten spot přečíst.

pondělí 27. září 2004

Eclipse: 3.0.1 a Visual Editor 1.0

Samé dobré zprávy dorazily z projektu Eclipse. Nejdříve spatřila světlo světa verze 3.0.1, která opravuje chyby jenž se nahromadily ve verzi 3.0. Více informací o verzi 3.0.1 nabízí Eclipse Project Release Notes. Druhou potěšitelnou zprávou je oficiální uvolnění Visual Editoru 1.0 patřícího do Visual Editor Project zkráceně VEP.

Visual Editor slibuje následující funkčnost

  • Podpora SWT a Swingu
  • Design manager
  • Oddělení editace kódu a visuálního návrhu

čtvrtek 23. září 2004

Krátké ohlédnutí aneb co týden dal

Tento v pořadí již 39 týden přinesl mnoho zajímavých událostí, které vydaly na toto malé ohlédnutí. Malou namátkou uvolnění J2EE AS JBoss a JFox, IBM J2EE / .NET Study, porovnání vývojových IDE atd.

O uvolnění Tomcatu 5.5 již řeč byla, ale pro příznivce tohoto velni populárního servletového kontejneru, přidávám k dobru interview Dallying with Tomcat 5.5. Když už jsme u toho Tomcatu, tak nemůžu nezmínit pondělní uvolnění open source J2EE Serveru JBoss 4.0.

Krátkou notickou o JBosuu jsem si udělal oslí můstek pro volný přechod na J2EE oblast. Krom vypuštění JBosse tu máme ještě J2EE server JFox z dílen China Enterprise Open Source Community. Jíná a mnohem početnější komunita se bouří pod příspěvkem TMC Completes Massive IBM J2EE / .NET Study, který vyšel na serveru TheServerSide.COM. Slovy klasika, bylo to jako škrtnout zápalkou nad kanistrem benzinu.

Aby nebylo těch konfrontací málo narazil jsem na materiály k přednášce Java Technology IDE Shootout. Cílem této přednášky bylo najít výhody a nevýhody vývojových prostředí IntelliJ, Eclipse, NetBeans, Emacs a JBuilder.

úterý 21. září 2004

JBoss 4.0 venku

Uděláno, hotovo a spakováno. Aplikační server JBoss ve verzi 4.0 spatřil oficiálně světlo světa. Jakožto první open source server dosáhl JBoss J2EE 1.4 certifikace.

Související odkazy

pondělí 20. září 2004

Základy kolekcí v Jave

S rodinou kolekcí (java.util.Collection) se setkáváme při programování v Jave takřka na každém kroku. Některé zásady a záludnosti mohou být skryty za JavaDocem, který nemusí (bohužel) každý číst nebo mu úplně rozumět. Mezi klasické "špeky", které by měly být dostatečně známé patří hashCode, kapacita, load factor, kolize.

Všechny vlastnosti se týkají obou množin implementací mapy a seznamu a proto se vyplatí mít o nich všeobecný přehled. Dobře srozumitelnou pomůckou může být článek Jacka Shiraziho An Introduction to Java Map Collection Classes

Související články

úterý 14. září 2004

Porovnání: Eclipse vs. Netbeans, IntelliJ IDEA, JBuilder

Mezi hojně diskutovaná témata patří bezesporu porovnávání vlastností jednotlivých vývojových IDE. Na platformě Java patří k těm nejrozšířenějším čtveřice Eclipse, Netbeans, IntelliJ IDEA a JBuilder. Zastánci jednotlivých prostředí Vám budou tvrdit, že právě to jejich má funkčnost, kterou ostatní nemají.

IBM jakožto zakládající člen konsorcia Eclipse a dá se říci i největší investor do tohoto IDE připravil seriál Migrating to Eclipse: A developer's guide to evaluating Eclipse. Cílem seriálu je usnadnit přechod z Netbeans, IntelliJ IDEA, JBuilder na Eclipse. Jednotlivé díly jsou věnovány vždy konkrétnímu IDE a porovnání rozdílů oproti Eclipse.

Související články

pondělí 13. září 2004

JDOM 1.0 venku

Dlouhou dobu používáme na práci s XML v Jave open source balíček JDOM. JDOM není implementací specifikace DOM, jak by se mohlo zdát. Nabízí vlastní API, které je z programového hlediska mnohem pružnější než příliš volný DOM.

JDOM se stal pro hodně vývojářů po čtyřech rocích života velice oblíbeným nástrojem pro práci s XML. O jeho úspěšnosti nebo popularitě, každý nechť si přebere po svém, svědčí vznik specifikačního požadavku (JSR:Java Specification Request) JSR 102: JDOM 1.0.

Minulý čtvrtek (09.09.2004) oznámil hlavní vývojář Jason Hunter vypuštění verze 1.0. Nenechte se zaskočit trochu zvláštním číslováním verzí, verze 1.0 je opravdu novější než JDOM 9, další verze by měly být číslovány již tradičně 1.1, 2.0 atd.

JDOM umožňuje spoluprácí s tradičními API jako SAX a DOM. Zároveň má hodně dalších funkcí, při pročítání change logu jsem narazil například na podporu jazyku XPath. Autoři JDOMu dělali vše proto, aby bylo jeho používání na práci s XML co nejpříjemnější. Dřívější živelný vývoj JDOmu měl resp. má do verze 1.0 včetně, neblahý vliv na neustále změny API.

JDOM 1.0 není zpětně kompatibilní s verzí JDOM 9 (verzi 10 jsem netestoval). Na druhou stranu tvůrci slibují, že budoucí změny API budou zpětně kompatibilní.

Související články

čtvrtek 9. září 2004

Hádanka o třech vypínačích

Mam tu další velice pěkně vypečenou hádanku.

Máme místnost, uvnitř místnosti je žárovka. Před místností jsou tři vypínače, ale pouze jeden rozsvěcuje žárovku. Místnost nemá žádná okna a není do ní z venku vidět. Úkolem je najít řešení, které umožní najít vypínač rozsvěcující žárovku. S vypínači je možno manipulovat jak je libo, ale do místnosti se můžeme podívat pouze jednou a pak určit vypínač.

Další hádanky

Konference Java vs .NET

Ač chvilku před termínem konání, nedá mi to, abych zde nezmínil jednodenní konferenci Java vs .NET. Konference se bude konat 14. září 2004 v Kongresovém centru Praha. Program vypadá opravdu zajímavě, dobrou známkou jsou partneři konference (Sun, IBM, Microsoft ...). Cena registrace je 800 kč. Pokud jde o mě, rád bych se zúčastnil. A co vy, půjdete?

středa 8. září 2004

Já a manuály

Možná by se tenhle spot měl jmenovat já a zdroje informací, ale název jsem volil vzhledem k velice povedenému článku Viléma Málka Manuály aneb Jak jsem se naučil nedělat si starosti a mít rád internet.

Velice dobře si vzpomínám na svůj první počítač. Z dobré vůle rodičů jsem se stal vlastníkem osmibitového počítače Didaktik M. Součástí tohoto počítače byla i manuál nebo jak to nazvat. Za pár měsíců jsem dostal knihu o programování v BASICu, která byla ještě v specificky tvrdých deskách. Moje zkušenosti ze těmi všemi manuály, referenčními příručkami, knihami, HOWTO brožurami jsou velice bohaté.

Postupem času a doby, která byla ovlivněna masivním nástupem internetu jako prostředku pro získávání informací, se i pro mě samotného stal internet tím hlavním zdrojem nejen technických informací. Dle mého soudu největší boom nezpůsobil ani samotný fakt, že je dokumentace a informace dostupná v elektronické podobě, ale fulltextové vyhledávače.

Vyhledávače, abych byl konkrétní Google jehož s NkD familiérně nazýváme přítel na telefonu, se pro mě staly klíčovou složkou práce. Absolutně každý manuál, příručka nebo stažený dokument se po čase vytratí z pamětí a zůstane zapomenutý na disku. Naproti tomu je vyhledávač schopen poskytnout ihned bez dlouhého hledání.

I v době moderních technologií se kniha neztratí ba naopak, má to své ale. Z mého pohledu bych knihu volil ve dvou případech. Jsem začátečník, pak potřebuji vstoupit do problematiky a pak jsou tzv. knihy pro začátečníky tím pravým ořechovým. Druhý případ je ten, kdy potřebuji proniknout do hloubky problému, pak jsou specializované knihy velice dobrým pomocníkem.

Nakonec japonec, nakonec jsem si trochu schválně schoval odborná periodika. Odborná periodika mají trochu jiný význam a přikládám jim důležitost při rozšiřování obzorů. Odborná periodika mi také slouží ke konfrontaci vlastních názorů a k utříbení pohledu na danou problematiku.

úterý 7. září 2004

Pořadí událostí v prohlížečích

Rád bych se s Vámi podělil o velmi zajímavou věc. Programuji pro třívrstvou aplikaci prezentační vrstvu webu a narazil jsem na problém s eventami v prohlížečích. Potřeboval jsem vytvořit za pomoci HTML a JS popup kalendář. Chci aby se choval následovně: Na stránce je malý button. Když na něj user klikne zobrazí se absolutně pozicovaný DIV s kalendářem, který je zobrazen dokud je user ukazatelem myši nad kalendářem nebo nad tlačítkem vyvolávajícím kalendář.

To znamená, že na událost onmouseout těchto dvou prvku zavolám JS funkci a ta skryje DIV s kalendářem. Všechno by krásně fungovalo, kdyby ten inkriminovaný DIV neměl v sobě vnořené další elementy (tlačítko pro výběr měsíce, jednotlivé dny....)

Nejlépe to předvedu na příkladu:

        
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
 <head>

  <script language="JavaScript">
    var logID = 0;
    function addLog(message) {
      var log = document.getElementById("console");
      logID++;
      log.value = log.value + logID + " : " + message + "\n"
    }
    function clearLog(){
      var log = document.getElementById("console");
      log.value = "";
      logID = 0;
    }
  </script>

 </head>
 <body style="margin:20px 20px 20px 20px;">
  <div id="outter" align="center" style="border:1px solid black;
     background-color:#AAAAff;width:100px;height:100px"
     onmouseover="addLog('outer DIV - mouse over');"
     onmouseout="addLog('outer DIV - mouse out');">
     
      Outer DIV
      <br /><br />
      <div style="border:1px solid black;
          background-color:#AAFFAA;width:50px;height:50px;margin:auto;"
          onmouseover="addLog('inner DIV - mouse over');"
          onmouseout="addLog('inner DIV - mouse out');">
          
        Inner DIV
      </div>
    </div>
   <br />
   <input onclick="clearLog();" type="button" value="clear LOG" />
   <br />
   <textarea id="console"
       style="width:500px;height:300px;"></textarea>
 </body>
</html>

Ilustrační obrázek

Nyní si projdeme události jak jsou vyvolávány když hýbeme myší podle červené šipky v obrázku:

 
1 : outer DIV - mouse over
2 : outer DIV - mouse out
3 : inner DIV - mouse over
4 : outer DIV - mouse over
 

Překvapivé jsou eventy 2 a 4. Zvláště eventa 2 nám znemožňuje na událost onmouseout outterDivu skrýt outterDiv. Můj původní předpoklad byl, že se eventy chovají tak, že outter mouse over a outter mouse out se vyvolá pouze v případě, že myší najedu a nebo sjedu z tohoto divu avšak jeho "děti/vnořené elementy" nikdy nevyvolají tyto eventy u svého "rodiče/nadřazeného elementu". Nalezl jsem zatím dvě řešení problému.

První řešení

 
//JavaScript  
var mysNadDiv = false;
var delayCallID = 0;
function delayCall(funcCall, delay){
  clearTimeout(delayCallID);
  delayCallID = setTimeout(funcCall,delay);
}
function hideDiv(){
 if (!mysNadDiv) {
  document.getElementById('outter').style.display="none";
 }
}

//do html k outter divu
onmouseover="mysNadDiv=true;"
onmouseout="mysNadDiv=false;delayCall('hideDiv();',200);"

Jde v podstatě o zpožděné zavolání funkce v JS při eventě 2 a než se skutečně zavolá hideDiv tak mezitím eventa 4 znemožní skrytí přes proměnou 'mysNadDiv'. Ve výsledku se outter Div skryje jen když opravdu myš opustí outter Div. clearTimeout je v JS funkci proto, aby se nekumulovalo zbytečně více timerů při rychlém přejíždění myši.

Druhé řešení

Hlídat si pozici myši a vykašlat se na eventy. Outter Div skrýt jen tehdy, když se souřadnice myši dostanou mimo definovanou oblast outer Divem.

Jestli někdo zná lepší řešení, sem s ním. Jen bych rád podotknul, že inner Divů může být klidně 100 a v každém inner Divu můžou být další vnořené elementy a musí Vámi navrhnuté řešení stále fungovat s pokud možno nejméně přidaného kódu.

pondělí 6. září 2004

Spring rozšiřuje podporu aspektově orientovaného programování

Nejdříve krátká svižná pro ty z Vás jenž slyší o AOP (Aspektově orientované programování) poprvé, doporučuji přečíst starší spot Pavla Kolesnikova Co je to Aspect Oriented Programming?. Pokud Vás AOP zaujalo pak je J2EE framework Spring tím pravým místem kde aspecty vyzkoušet. Potěšující zprávou je oznámení rozšíření podpory na AOP framework AspectWerkz.

čtvrtek 2. září 2004

Živá Jakarta: Tomcat 5.5 a Struts 1.2.2 venku

Na Apache Jakarta Project je tento týden velice rušno. Včera byly oficiálně vypuštěny Struts 1.2.2, o kterých informoval Pavel Kolesnikov ve spotu Struts 1.2.2 jsou na světě, neuběhlo ani pár hodin a diky chybám ve verzi 1.2.2 byli nuceni vypustit verzi 1.2.3.

Aby těch novot nebylo dost, byla poprvé uvolněna verze 5.5 populárního servletového kontejneru a web serveru Tomcat. Mezi novinkami rozhodně překvapí fakt, že vývojáři tuto verzi připravovali a ladili pro Javu 5.0 (dříve 1.5). Naštěstí by měla verze 5.5 běžet i na starších verzích Javy.

Z dalších novinek bych vybral přibalený kompilátor ( Eclipse JDT), díky němuž už Tomcatu postačuje prachobyčejné JRE. V diskusi Tomcat 5.5 is on the Prowl je zmíněno vylepšené logování, diagnostika a cluster funkcí.

středa 1. září 2004

Java: reálný dopad vyhození výjimky na rychlost programu

Kdysi dávno jsem četl nebo možná slyšel názor, že výjimky lépe řečeno jejich vyvolání je systémově náročné a zdržuje. Včera jsem našel v nástrojích jednoho našeho projektu třídu, která sloužila k zjištění aktuálního execution kontextu. Tato třída má statickou metodu, která vyvolá výjimku, zpracuje její stacktrace a vrátí jméno třídy a metody, která tuto metodu volala.

Protože se třída pro určení contextu volá docela často napadlo mě onu poučku si ověřit a změřit rychlost vykonávání programu s vyhazováním výjimky.

Jak jsem měřil

Připravil jsem si objekt Dummy, který má statickou metodu, ve které se vyvolá výjimka. Zároveň tato metoda obsahuje výpočet pí, což slouží pouze k simulaci reálné operace.

 
  public class Dummy {	
      public static void doSomethingFishy(boolean withException){
	   if(withException){ 
		try{
		    throw new Exception();             
		}catch(Exception e){
		    //do nothing
		}
	   }
	   double currPi = 0;
           double i = 1;
           do {
               currPi += 4/i - 4/(i+2);
               i+=4;
           } while (Math.abs(Math.PI - currPi) > 1E-7);	
     }
  }
 

Dále jsem si připravil vlákno, které volá statickou metodu doSomethingFishy a cyklus, který vytvoří specifikovaný počet vláken a spustí je.

 
 .
 .
 .
 boolean exception = Boolean.valueOf(args[0]).booleanValue();
 int threadCount = Integer.parseInt(args[1]);
 for(int foo = 0; foo < threadCount; foo++){
    new Thread(new MyThread(exception)).start();
 }
 .
 .
 .

 class MyThread implements Runnable{
    private boolean exception = true;
	    
    public MyThread(boolean exception){
        this.exception = exception;
    }
       
    public void run() {           
        Dummy.doSomethingFishy(exception);
    }
 }	 	
 

Proměnná exception řídí jestli se bude výjimka vyhazovat a threadCount počet spouštěných vláken.

Výsledky měření

Provedl jsem vždy tři měření na 100 vláknech s výjimkou a bez výjimky. Měřenou hodnotou byla doba běhu testu v sekundách, jako časomíra sloužila funkce operačního systému pro vrácení aktuálního času.

S výjimkou (s) Bez výjimky (s)
15,15 15,12
15,16 15,15
15,17 15,23

Z výsledků vyplívá, že vyhození výjimka má nepatrný či spíše žádný vliv na rychlost vykonávání programu. Vzhledem k tomu, že jsem zkoušel proměnlivý počet vláken a výsledky se lišily minimálně, lze prohlásit, že počet vláken má pouze minoritní vliv.

Důležitý dodatek

Cílem tohoto měření bylo prozkoumat reálný dopad vyhození výjimky na rychlost programu, i když se ukázalo, že vliv na rychlost je zanedbatelný, měly by se výjimky používat k signalizaci výjimečných situací. Mezi výjimečné situace rozhodně nepatří řízení běhu programu a nebo zjištění akt. kontextu s každým http požadavkem.

Testovací prográmek obsahuje kromě binárních a zdrojových souborů i spouštěcí dávku pro Windows. Argumenty tvoří true|false - s nebo bez výjimky a počet vláken např. run.bat true 10.