25. prosince 2007

Co (mi) přinesl letošní rok?

Je závěr roku a kdekdo se snaží shrnout, co se NEJ stalo v tomto roce. Já budu také jeden z nich, ale můj pohled bude malinkato jiný - rád bych uvedl věci, které mě jako programátora resp. architekta tento rok nejvíce pomohli v mé každodenní práci. Nebude to přehled nějakých významných objevů či událostí, které se v tomto roce ve světě Javy staly, ale spíše věci, které mi pomohly a pomáhají lépe a rychleji vytvářet aplikace, nebo které mě nějakým způsobem v mé práci ovlivnily.

Rozšiřování Spring portfólia

Já mám rád Spring, já ho rád používám a jsem plně ztotožněn s filosofií, která stála u zrodu Springu, a která platí až doposud. Proto tak oceňuji, že Spring resp. Spring portfólio se rozšiřuje o nové projekty, že čím dále více projektů třetích stran nabízí přímou a snadnou Spring-integraci, že Spring používá čím dál více lidí a tím pádem se objevuje více informací na internetu a více příspěvků v diskuzích.

Zvýšení povědomí o Springu

Tento bod velice souvisí s předchozím bodem, ale je o trochu něčem jiném. Je o tom, že Spring již dneska není považován za nějaký dočasný open-source projektík, ale za vyspělé propracované řešení, které se nebojí využívat ani velcí hráči jako jsou banky, pojišťovny, vládní instituce apod. To je v konečném důsledku super hlavně pro nás vývojáře, že můžeme jít s dobou a nemusíme pořád i dnes vyvíjet v prostředí Javy 1.3 nebo Struts.

Vyspělejší prezentační technologie

Myslím si, že Java oproti jiným jazykům (hlavně C#) nejvíce ztrácí v efektivitě vytváření "ksichtu" aplikací. Je sice hezké mít super robustní jádro aplikace, ale pokud uživatel neuvidí pěknou, moderní, uživatelsky přívětivou aplikaci, tak moc spokojený nebude. Proto jsem rád, že vznikl Seam, který ukázal v tomto ohledu zajímavý způsob řešení, že nastal posun v JSF specifikaci, že vzniká čím dál více použitelných AJAXových frameworků.

J2EE 6

Dle článků na internetu se dá tušit, že specifikace J2EE verze 6 se vyvíjí tím správným směrem. Uvidíme, jak to nakonec ale dopadne - jaké dílčí specifikace budou součástí finální J2EE specifikace, jak moc se podaří prosadit lidem okolo Springu jejich představy.

Nedostatek pracovních sil

Sice tento bod přímo nesouvisí s tím, jak každý den řeším programátorské problémy, ale nepřímo to celkem mojí práci ovlivňuje. Na jedné straně tím, že se nemusím bát o svoji práci, že si mohu vybírat a částečně určovat podmínky já sám. Na druhé straně jako nevýhodu vidím v tom, že máme problémy sehnat nové kolegy (schválně jsem vynechal slovíčko kvalitní, protože to je dneska spíše nedostižný ideál) a tedy spoustu věcí třeba ani řešit nemůžeme.

21. prosince 2007

Skriptovací jazyky v Javě - co s nimi?

Tento článek jsem nezačal psát jako jiné články s tím, že bych rád něco sdělil, ale spíše, že bych se rád něco dozvěděl. Před chvílí jsem dočetl článek o skriptovacích jazycích v Javě a pořád si nějak nemohu správně odpovědět na otázku - K čemu mi jsou v Javě ty skriptovací jazyky vlastně dobrý?

Musím se přiznat, že obecně skriptovací jazyky neovládám a spíše jen pasivně sleduji dění okolo, něco hodně málo jsem napsal v Groovy. Když si čtu články o skriptovacích jazycích v Javě, tak se často objevují tyto výhody vzájemného propojení:

  • skriptovací jazyky jsou jednodušší, lehčí, názornější, intuitivnější. To je z velké části dáno tím, že se jedná většinou o jazyky dynamické a slabě typované (obecně řečeno, protože např. Python je typově silný jazyk).

  • Java nabízí celou řadu věcí, které nejsou dostupné v samostatných skriptovacích jazycích, např. transakční management nebo vzdálená volání. Kromě toho lze pomocí Javy využít obrovské množství knihoven třetích stran, které lze ve skriptech využít.

  • výběr skriptovacích jazyků pro Javu je dneska opravdu veliký

  • díky spojení s Javou se neztrácejí hlavní přednosti Javy - možnost vytváření velkých, robustních a škálovatelných aplikací.


Kromě výhod to má samozřejmě i nějaké nevýhody:
  • často se uvádí slabší výkonnost skriptovacího enginu s JVM oproti nativnímu enginu samotnému. Je to dáno tím, že je potřeba provádět řadu kontrol a konverzí mezi oběma světy. Toto např. neplatí úplně pro Groovy, což je jen taková jiná Java.

  • skripty napsané s pomocí JVM samozřejmě pak nelze spouštět v nativním enginu

  • někdy jsou světy Javy a skriptovacího jazyka natolik rozdílné, že to nelze v některých jazycích vůbec implementovat nebo za cenu ne úplně ideálního kódu. Myslím například anotace v Javě.

  • větší nároky spojené s údržbou aplikací. Dříve stačilo umět jen Javu, ale teď k tomu potřebuji znát ještě minimálně další jazyk.

  • podpora přímo na úrovni JVM od verze 6 - JSR 223


Takže k čemu já to jen využiji? I když si dokážu představit, že určité části aplikace napíši rychleji např. pomocí Groovy, tak jsem asi moc konzervativní, ale mě to zase taková výhoda nepřijde. Já mám svoji Javu rád :), takže si všechno napíšu v ní. Když to nebudu brát jen z mého osobního pohledu, tak přeci jen otázka údržby aplikace je hodně významná a s použitím více jazyků a technologií se tento problém stává těžší a komplikovanější (a tedy nákladnější). A když už budu psát část aplikace pomocí skriptovacích jazyků, tak proč už to pak nenapíšu celé jen pomocí skriptovacího jazyka?

Často se uvádí jako vhodné využití prototypování aplikací. Zde si to dovedu celkem představit jako přínosné, ale moje zkušenost mi říká, že spousta takto vytvořených prototypů se použije pro následný vývoj celé aplikace. Raději bych to tedy od začátku psal pořádně v Javě.

Můj osobní stav je nyní takový, že pořád moc nevím, kde a jak bych mohl efektivně využít skriptovací jazyky z pohledu vývoje v Javě. Budu moc rád, když přispějete formou diskuse a vysvětlíte mi, že se v určitých ohledech pletu nebo jsem jen špatně resp. málo informovaný.

17. prosince 2007

Novinky ze Springu

Moc často nekomentuji různé události, ale teď mi to nedá. Právě se koná konference The Spring Experience, což jsou spolu s konferencí SpringOne dvě nejvýznamnější konference věnované přímo Springu.
Právě na této konferenci se objevily velice zajímavé novinky z dílny firmy SpringSource (dříve Interface21):

  • doplnění Spring portfólia o Spring Integration, o část, která by měla pomoci při vývoji servisně-orientovaných aplikací. Podle mého názoru je dneska skoro nezbytností mít něco podobného v portfóliu, v době, kdy se každý ohání slovíčkami jako SOA, webové služby, integrace apod. V brzké době by projekt měl být publikován a někdy ve druhém čtvrtletí roku 2008 by měla být verze 1.0. Více si můžete přečíst na Team blogu SpringSourcu.

  • SpringSource Application Management Suite - podle dostupných informací, které se mi podařilo najít, by to měla být taková nádstavba nad Springem, která bude zobrazovat běhové informace o aplikaci jako např. kolik proběhlo transakcí, kolik zpráv se zpracovalo, kolik aktivních beanů je v aplikaci apod. Já osobně to chápu tak, že místo abychom museli vytvářet MBeany pro přístup k velmi často potřebných informacím, tak budeme moci použít tento Application Management Suite, který nám bude automaticky nabízet standardní sestavu pro každou aplikaci.

  • SpringSource Certification Program - toto je velice zajímá informace, o které se již tak trochu mluvilo na konferenci SpringOne v letošním roce. Na certifikace jsou různé názory, ale určitě lze říci, že je to krok správným směrem, pokud chceme aby se Spring čím dál více prosazoval a používal mezi velkými hráči jako jsou například banky. Je ale otázka, kdy se to dostane až k nám do Čech - v USA to začne na konci ledna.

Více si můžete přečíst v tomto článku.

14. prosince 2007

Hudson - děkuji, rád

V poslední době se mi zdá, že se více než kdy před tím řeší, který že build server je ten nejlepší. Možná je to jen můj subjektivní pohled nebo možná je to také tím, že čím dál tím více lidí má povědomí o "postupné integraci" (continuous integration) a znají nesporné výhody tohoto přístupu.

Hned na začátku říkám, že mám rád Hudson. Už to bude přibližně rok, kdy jsem vybíral buildovací server do naší firmy a při svém výběru jsem víceméně vycházel z nástrojů uvedených v tomto článku. Hned od začátku to byla "láska na první pohled":

  • velice jednoduchá instalace. Slovíčko instalace je přehnané, protože stačí pouze nahrát soubor hudson.war na aplikační server a už vše funguje. S tím je samozřejmě spojen i bezproblémový upgrade, což se zde celkem využije, protože skoro každý den vzniká nová verze.

  • velice jednoduchá konfigurace všeho potřebného. Konfigurace je intuitivní a přímo obsahuje nápovědu, takže není potřeba žádná dokumentace.

  • Hudson nabízí přesně to, co potřebujeme a nic navíc. Používáme Subversion, nemáme (zatím) žádné složité vazby mezi projekty, v každém buildu chceme mít přístup k JavaDoc dokumentaci, výsledkům testů a k informacím z konzole. Pro sledování výsledků buildů nám stačí RSS nebo Email. Pro ty, kdo používají něco jiného než Subversion nebo mají větší nároky na integraci nástrojů třetích stran, tak budou mít s Hudsonem asi problém.

  • S tou integrací nástrojů třetích stran už to také není tak špatné jako třeba před rokem. Úspěšně jsme teď zaintegrovali nástroje FindBugs a Cobertura. Ostatní nástroje pro detekci chyb či něčeho jiného (Checkstyle, PDM, JDepend) sice používáme, ale zatím bohužel bez přímé integrace s Hudsonem. Detailní výsledky máme možnost vidět pouze z výpisu konzole.




Teď si připadám jak na střední na konci referátu o knížce: Hudson se mi velice libíl a všem bych ho jen doporučil :).

Přehled dalších buildovacích serverů:

13. prosince 2007

Apache Forrest - děkuji, nechci

V poslední době jsem musel malinko oželet programování vlastních aplikací, protože jsem více řešil nasazení a konfiguraci produktů třetích stran. Jedním z nich byl produkt se jménem Apache Forrest.

K čemu je Apache Forrest dobrý? Je dobrý k tomu, když si potřebuji vytvořit webovou prezentaci (a nechci ji vytvářet sám přímo pomocí HTML), když chci mít na webu automaticky řadu zajímavých funkcí jako fulltextové vyhledávání, tisk, export do PDF a hlavně, když mám již spoustu dokumentů (různé obrázky, HTML, PDF atd.), které bych rád znovu využil. Pokud chci vytvářet obsah webu sám, pak mám možnost použít celkem intuitivní pseudo-HTML jazyk. Úvodem je ještě vhodné uvést, že například většina projektů Apache má web vytvořený právě pomocí tohoto nástroje.

Podle toho, co jsem doposud napsal by se mohlo zdát, že je to super mocný nástroj. Bohužel jsem si to na začátku taky myslel, ale teď už moc ne. Ale postupně...

Formáty dokumentů

Apache Forrest umí pracovat na vstupu s různými formáty dokumentů a to díky rozšířením Apache Forrest (tzn. pluginy). Základní konfigurace umožňuje na vstupu použít následující formáty dokumentů (kromě dokumentů zapsaných přímo ve formátu Apache Forrest XML):
  • XML

  • HTML

  • MS Excel (tabulka z MS Excel musí být uložena jako Tabulka XML)

  • OpenOffice (Impress, Writer) verze 1 (přípona .sxw)

U těchto vstupních formátů se dokumenty přímo upraví do jednotného vzhledu a struktury webu. Samozřejmě je možné formou odkazu přímo na dokument připojit dokument v libovolném formátu – ten pak sice nebude zpracován a převeden do HTML, ale bude možné jej stáhnout.
Bohužel není možné přímo integrovat nejrozšířenější dokumenty MS Word. Jde to ale obejít přes OpenOffice – dokument z MS Word načtu v OpenOffice a uložím ve formátu OpenOffice (sxw).

Apache Forrest jsem intenzivně používal přes dva týdny a na základě této zkušenosti mohu uvést následující výhody a nevýhody:

Výhody

  • Vzhled webu lze kompletně upravit pomocí CSS (viz projekty Apache).

  • Velké množství vlastností výsledného webu je možné upravit pouze pomocí konfigurace

  • Žádný srovnatelný nástroj (se stejným zaměřením) se mi nepodařilo najít.

Nevýhody

  • Apache Forrest si moc nerozumí s češtinou - měl jsem problémy s českou diakritikou při exportu do PDF nebo při importu dokumentů z OpenOffice.

  • Nepodařilo se mi vůbec rozchodit fulltextové vyhledávání s Lucene. Varianta s Google fungovala dobře.

  • Apache Forrest je v současné verzi 0.8 a moc to nenasvědčuje tomu, že by se v brzké době objevila nějaká stabilní verze 1.0. Když jsme tento nástroj vybírali do jedné nabídky na konci roku 2006, tak byla verze 0.7.

  • Z uživatelského hlediska se nejedná o zrovna přívětivý nástroj. Vše je ovládané pouze z příkazové řádky.


Po všech uvedených nevýhodách jsme byli nuceni přejít na jiné řešení se jménem Daisy. Sice je to řešení z kategorie CMS a tedy směřované trochu jiným směrem než Apache Forrest, nicméně základ je opět postavený nad nástrojem Apache Cocoon a tedy z hlediska možností práce s dokumenty velice podobné. Všechny nevýhody Apache Forrest jsou v Daisy vyřešeny a řada výhod zůstala.