1. prosince 2008

Jakou databázi používáte? - výsledky

Druhá minianketka je u konce s těmito výsledky:

  1. MySQL (51%)
  2. Oracle (47%)
  3. PostgreSQL (36%)
  4. MSSQL (12%)
  5. Apache Derby (Java DB) (10%)
  6. Jiná embedded (9%)
  7. DB2 (5%)
  8. Jiná standalone (5%)
  9. InterSystems Caché (0%)
Hlasovalo celkem 121 lidí.

Co k tomu říci? Umístění volně dostupných databází MySQL a PostgreSQL není asi žádným překvapením. MySQL je velice rychlá databáze (sice trochu na úkor funkcionality, ale ta není vždy potřeba) s množstvím administračních nástrojů. Já osobně dávám spíše přednost PostgreSQL, protože jednak toho umí opravdu hodně a v případě potřeby je možné bez větších problémů přejít na databázi Oracle.

Odhaduji, že spousta z vás dělá na velkých projektech, protože jinak by nemohla databáze Oracle být na druhém místě :).

Já jsem svůj největší projekt dělal nad MSSQL databází a byl jsem s ní hodně spokojený. Databáze byla určena již zákazníkem před realizací projektu a já jsem se k tomu stavěl trochu skepticky, ale nebylo třeba. Asi hlavní důvod byl ten, že já jsem přeci jen "klikací" uživatel, a proto se mi moc líbila administrace v této databázi - vše velice intuitivní.

Zajímalo by mě vaše využití embedded databází? Já jsem je používal pouze ve spojení s desktopovými aplikacemi, kdy jsem potřeboval ukládat data mezi jednotlivými spouštěními aplikace.

Co mě možná trochu překvapilo je to, že se nenašel nikdo, kdo by používal objektovou databázi Cache. Je to možná tak dva roky, co byla celkem masivní kampaň na používání a výhody Cache a asi se nikdo nechytil. Já osobně nemám žádnou zkušenost, takže nemohu soudit, ale relační databáze tu již jsou hodně dlouho a je to mnohdy jediná věc v IT oddělení firem, která se po léta nemění.

17. listopadu 2008

JSF - sestava sedmi statečných

V předchozím článku jsem zmínil naší sestavu sedmi frameworků resp. knihoven, které používáme pro vývoj s JSF. Některé knihovny byly dané již od začátku, některé se ukázaly jako nezbytné až v průběhu samotného vývoje.

  • Apache MyFaces - úplně na začátku jsme začali se SUNovskou implementací JSF, ale asi po měsíci jsme přešli k MyFaces. Jednak jsme měli pár problémů s NetAdvantage komponentama, které se přechodem vyřešily a jednak jsme dostali pocit, že MyFaces implementace "více" žije, že je lepší bug-fixing apod. Ale toto může být subjektivní. Používáme JSF verze 1.2.

  • NetAdvantage komponenty - o těchto komponentách jsem již něco napsal (1, 2). Snad jen dodám, že někdy v září vyšla nová verze podporující JSF 1.2, která zejména ve spojení s Facelets obsahuje celkem dost chyb. Hodně jsme přemýšleli, zda pokračovat nebo zkusit nějaké jiné komponenty a rozhodli jsme se pokračovat - reportovali jsme hodně chyb a teď víceméně čekáme na nový hotfix. Verze 1.1 a bez Facelets (platí pro obě verze) je mnohem více odladěná.

  • Tomahawk komponenty - primárně využíváme NetAdvantage komponenty, ale sem tam potřebujeme něco jiného nebo něco více. Například tagy t:htmlTag a t:div používáme celkem dost, protože NetAdvantage nedovolují používat čisté HTML ve svých tagách (i když používáme Facelets). Zkoušeli jsme také Trinidad, hlavně kvůli komponentě na výběr barvy, ale od toho jsme nakonec ustoupili - jednak je tato knihovna celkem invazivní (vyžaduje použití vlastního ViewHandleru) a jednak už jsme začali cítit, že těch knihoven máme v projektu nějak moc.

  • Spring framework - bez Springu si už nedovedu představit snad žádnou aplikaci, takže zde nebylo co řešit. Velkou výhodu to přineslo díky MyFaces Orchestra, která implementuje nové konverzační rozsahy pro Spring beany. Používáme Spring EL resolver, takže nemusíme skoro nic definovat přímo v JSF. O bezpečnost aplikace se nám stará Spring security.

  • MyFaces Orchestra - s pomocí Springu implementuje nové konverzační rozsahy, více v tomto článku.

  • Facelets - když už JSF, tak jedině s Facelets. Díky Facelets je JSF mnohem více stravitelnější, je to výborný šablonový systém. Při použití JSF s JSP resp. JSTL si je potřeba dát pozor na spoustu možných problémů (popsáno v tomto článku), které s Facelets odpadají.

  • URL rewriter - díky URL rewriteru jsme byli schopni vyřešit asi největší nedostatky JSF - nemožnost bookmarkovat stránky, nemožnost efektivního zabezpečení stránek pomocí Spring security a problém s "opožděnými" URL (uživatel vidí v prohlížeči URL, které odpovídá předchozí stránce). Také jsme tím mohli zcela vynechat konfiguraci navigace v JSF a nadefinovat jí (dle mého názoru efektivněji) pomocí URL rewriteru.

14. listopadu 2008

JSF zase nejsou tak špatný ...

Sice se zpožděním, ale rád bych reagoval na nedávno vydané články o JSF (1, 2). Možná bych spíše měl napsat doplnil místo reagoval, protože se vším co bylo napsáno souhlasím - na komponentovou technologii JSF jsem přešel teprve letos na jaře a přechod to byl celkem bolestivý. U mě to bylo ještě umocněný tím, že jsme si vybraly NetAdvantage komponenty, které mají celkem dost chyb, takže nebylo výjimkou, že jsem hodiny zkoumal proč něco jednoduchého nefunguje. Teď už si naše JSF sestava (MyFaces, NetAdvantage a Tomahawk komponenty, Spring framework, MyFaces Orchestra, Facelets, URL rewriter) sedla a už to celkem jde.

Chtěl bych uvést pár pozitiv, které jsem u JSF spatřil (nutno dodat, že výhody jsou zejména oproti request-driven řešením, než oproti jiným komponentovým technologiím).

  • JSF je J2EE standard - to má svoje velké nevýhody, ale i svoje výhody - technologie má zaručenou určitou životnost (velice důležité z pohledu investic), lépe se budou hledat programátoři na projekty, existuje určitá konkurence mezi dodavateli JSF komponent.

  • vzhled prodává - ať si každý říká co chce, ale vzhled je velice důležitá věc u většiny aplikací. I když NetAdvantage mají velké množství chyb a nedostatků, tak jedno se jim nedá upřít - jejich komponenty jsou pěkné. Komponenty jsou standardně nabízeny v asi deseti různých odstínech, stačí si jen vybrat nebo si upravit podle svého přání již existující.

  • rychlost vývoje - počátky vývoje aplikace byly hodně pomalé, ale od té doby, co jsme "prokopli" základní struktury stránek (detail, editace, výběr s modálním oknem apod.), tak jde vývoj velice rychle. Již v době návrhu obrazovek a výsledné podoby aplikace jsme věděli, že budeme používat NetAdvantage komponenty a podle toho jsme se to již snažili navrhovat. Teď navíc víme co funguje, co ne, takže jsme schopni navrhnout celkem rychle jakoukoliv stránku s tím, že ji také celkem rychle poskládáme a uděláme.

Nejsem určitě ten, kdo má rád JSF technologii, ale je prostě pár věcí, které s nimi celkem fungují.

3. listopadu 2008

Stromová data v relační databázi

Řešil jsem nyní na projektu uložení a práci se stromovou strukturou dat.



Každého asi napadne řešení, kdy objekt si bude držet referenci na svého předka. Toto řešení je funkční, ale má jednu velkou nevýhodu a tou je pomalost načítání stromu. To je dáno rekurzivním algoritmem a tedy velkým množstvím dotazů do databáze. Na druhou stranu je velice jednoduché přidávat nové objekty nebo je přesouvat. Tento model se označuje jako The Adjacency List Model.

Já jsem ale potřeboval "opačné řešení" - co nejrychlejší načítání stromu i za cenu toho, že při správě stromu si uživatel chvíli počká. Pro tento případ je ideální tzv. Modified Preorder Tree Traversal algoritmus. Ten si kromě odkazu na svého předchůdce eviduje další dvě pomocné hodnoty, tak aby sestavení stromu bylo co nejrychlejší. Naopak změny v hierarchii stromu mohou vést k nutnosti přepočítat pomocné hodnoty u všech objektů.


Více informací k uvedené problematice lze nalézt zde:

19. října 2008

Jaký webový framework používáte - výsledky

První minianketka je u konce s těmito výsledky:

  1. Spring MVC (36%)
  2. JSF (34%)
  3. Struts (16%)
  4. Něco jiného (14%)
  5. Samotné JSP a JSTL (8%)
  6. JBoss Seam (8%)
  7. Apache Wicket (6%)
  8. Spring Web Flow (6%)
  9. Tapestry (4%)

Hlasovalo celkem 61 lidí, takže se zrovna o velký vzorek lidí nejedná :(. Nechci z toho vyvozovat nějaké velké závěry, ale pár myšlenek si dovolím.

Pro mě osobně je Spring MVC a JSF volbou číslo jedna v současné době. Pokud potřebuji mít vše pod kontrolou, potřebuji mít rychlý web s velkou návštěvností, tak budu volit Spring MVC. Pokud si mohu dovolit JSF, tak volím JSF - tedy zejména pro intranetové aplikace, složité stránky a formuláře. Jedna volba nevylučuje druhou - JSF použiji třeba pro administrátorskou část aplikace, Spring MVC pro část prezentující data.

Struts mají silnou pozici z minulosti, takže na tom poběží pořád hodně projektů. Moc ale nepředpokládám, že by se toto řešení v nějaké větší míře používalo ještě dnes u nových projektů. Když už, tak aspoň Struts 2.

Tapestry jsou celkem staré (dnes je již beta verze páté verze) a ve své době měly několik revolučních věcí (např. provázání HTML a komponent přes speciální atribut, komponentový přístup), které ovšem v současné době jiné frameworky, které se nechaly inspirovat, řeší lépe (např. JSF Facelets, Apache Wicket). Musím se přiznat, že mě osobně nikdy moc Tapestry nezaujali.

Hodně by mě zajímalo, co se schovává pod "Něco jiného" u lidí, kteří tuto volbu zaškrtli. Možná Shale, WebWork, něco proprietárního, nevím...