29. ledna 2009

Jaké dynamické jazyky využíváte? - výsledky

Opět skončila další minianketka, tentokrát mě zajímalo využití dynamických jazyků. Zde jsou výsledky:

  1. Žádné (41%)
  2. Něco jiného (25%)
  3. Groovy (20%)
  4. Jython (12%)
  5. jRuby (2%)
  6. Scala (2%)
  7. Rhino (1%)
Hlasovalo celkem 62 lidí.

Co k tomu říci? Výsledky mě nepřekvapily, jen by mě zajímalo, jaké dynamické jazyky se skrývají pod položkou "Něco jiného". Když jsem vybíral jazyky do ankety, tak jsem vycházel z tohoto seznamu a snažil jsem se vybrat ty nejpopulárnější, ale asi se mi to moc nepodařilo.

Asi před rokem jsem o dynamických jazycích psal a od té doby se můj váhavý postoj nijak nezměnil. Pořád jsem na tom stejně - pořád nevím, kde bych je mohl sám využít, kde mi přinesou tu tíženou výhodu při vývoji aplikací oproti standardní Javě.

Asi je nebudu využívat přímo, ale přes nějaký aplikační framework jako jsou třeba Grails nebo ZK framework. Jsem hodně zvědavý s čím novým přijde Spring ve spojení s Groovy, když nedávno koupili firmu G2One, které stojí za frameworkem Grails a jazykem Groovy.

S uvedených jazyků jsem používal pouze Groovy a to ve spojení s nástrojem SoapUI. Díky Groovy jsem si mohl napsat vlastní testovací případy a to se mi líbilo.

Také jsem skeptický na větší využití dynamických jazyků s ohledem na většinu (dle mého názoru ano, na většinu) programátorů, kteří se vlastně ani nic nového učit nechtějí - naučí se Javu a pár věcí okolo a myslí si, že jim to bude stačit. Znám to - stačí abych přišel s nějakou myšlenkou využití nové knihovny (natož s použitím nějakého dynamického jazyka) a už vidím tu nutnost přemlouvání, vysvětlování apod.

21. ledna 2009

Spring AOP: Dynamic Proxies vs. CGLib proxies

Pokud jste se někdy více ponořily do AOP resp. vytváření AOP proxy objektů ve Springu, tak jste určitě museli řešit, jaký přístup vlastně zvolit - zda vytvářet proxy objekty pomocí knihovny cglib nebo pomocí JDK.

Oba přístupy mají svoje specifika resp. výhody nebo nevýhody - zde je odkaz na článek, který to celé pěkně shrnuje.


Pokud všechny objekty inicializuje Spring kontejner, tak pak je vytváření AOP proxy objektů zcela automatické (např. pro řízení transakcí) a programátor se víceméně nemusí o nic starat. Někdy je ale potřeba mít vytvořené AOP proxy kolem objektů, které Spring nemá pod kontrolou, např. doménové objekty, které vytváří ORM knihovna nebo nějaké vlastní struktury, kde používáte new.

Spring nabízí následující dvě možnosti řešení:

Více o obou možnostech je uvedeno v dokumentaci ke Springu - Programmatic creation of @AspectJ Proxies a Using AspectJ to dependency inject domain objects with Spring.

8. ledna 2009

Spring certifikace

Mám to! :)

Tento týden jsem napsal testy a získal certifikaci "SpringSource Certified Professional".

Rád bych se s vámi podělil o nějaké mé postřehy či zkušenosti z přípravy a samotného testu.

Člověk musí nejdříve získat "povolení", aby vůbec mohl dělat testy. Povolení lze získat buď tím, že budete absolvovat jejich kurzy na Core Spring a nebo, že prokážete vaší zkušenost se Springem. Já jsem se vydal tou druhou cestou - přišel mi ze SpringSource formulář k vyplnění, na jehož základě mi pak poslali číslo kupónu, které jsem následně použil u certifikační agentury. V dotazníku se mě například ptali na mé dosavadní zkušenosti se Springem na projektech (musel jsem uvést nějaké referenční osoby jak z mé firmy, tak od zákazníka, pro jakého zákazníka to bylo, jaké části Springu jsem využil, jaké jiné open-source knihovny jsem použil), zda nějak přispívám do Spring komunity, zda nějak pomáhám v osvětě Springu apod. Celkově jsem z toho měl pocit, že si tak nějak dělají přehled o tom, na co se vlastně Spring používá, pro jak velké zákazníky a kdo vlastně žádá o tu certifikaci. Nemám žádnou zpětnou vazbu, že by byl někdo z mnou uvedených lidí kontaktován za účelem ověření informací. Doposud jsem dělal pouze certifikace u Sunu, proto mě toto celkem zaskočilo, nicméně jsem prošel a mohl jsem na zkoušku.

Ukázkové testy jsem nenašel žádné (ani na černém trhu :) ) a musel jsem si vlastně vystačit jen s dokumentací od Springu - JavaDoc a referenční dokumentace. SpringSource nabízí přehled oblastí k certifikaci a nějaké ukázkové otázky z testu - sice tam nejsou stejné odpovědi jako v reálném testu, ale otázky tak nějak sedí, bohužel jen tak ze třech oblastí. Ještě jsem našel nějaké podklady zde, ale to je spíše přehled nějakých základních termínů.

Samotný test má 50 otázek, je na to 90 minut. Každá oblast má pět otázek, což aspoň pro mě nebylo zrovna příjemné, protože o Spring Core nebo o Spring MVC toho vím hodně, ale takové JMX nebo JMS jsem nikdy moc (bohužel) nepoužíval. Vše ale mělo stejnou váhu. Také jsem se dost bál všech těch názvů tříd a rozhraní, které Spring má. Teď již vím, že jsem se spoustu věcí učil zbytečně, je opravdu potřeba znát jen ty hlavní, jako např. JdbcTemplate, HibernateDaoSupport, JmsTemplate atd. Otázky byly hodně zaměřeny na obecné znalosti spojení Springu a dané technologie (např. v čem všem mi může pomoci Spring ORM modul při práci s Hibernate), na často používané termíny (např. definice advice nebo aspektu) a někdy i na samotné technologie (např. jaké komunikační protokoly jsou definovány ve specifikaci JSR-160 pro JMX?). Je pravda, že někdy jsem se musel podívat i do jiné dokumentace než od Springu.

Kdo už někdy psal nějaké podobné testy, tak ví, že je potřeba si dát pozor na každé slovíčko, jak v otázce, tak v odpovědích. Každá otázka měla žádnou, jednu nebo všechny správné odpovědi.


PS: Někde jsem našel, že letos přibudou ještě další certifikáty:

  • SpringSource Web Technologies Professional
  • SpringSource Advanced Methodologies Professional
  • SpringSource Integration Professional
  • SpringSource Application Management Professional

29. prosince 2008

JSF: zkušenosti s NetAdvantage

O NetAdvantage komponentách jsem již několikrát psal (1, 2, 3) a rád bych napsal ještě jednou a tím to uzavřel. Již jsem se dříve snažil o nějaké zhodnocení a na to bych rád dnes navázal. Pokud se od té doby něco změnilo nebo jsou určité věci jinak než dříve, tak to nyní uvedu, jinak platí to co jsem již napsal.

S NetAdvantage komponentami jsme dělali přibližně půl roku, z toho tři měsíce celkem intenzivně. Projekt jsme zdárně stihli, takže (snad) všechny problémy, které jsme s komponentami měli, jsme dokázali nějak vyřešit. O použitých technologiích jsem psal v tomto příspěvku.

Ještě uvedu, že se budu vyjadřovat k verzi 8.2.20082.1003 - od té doby byly vydány dva nové hotfixy, takže něco může být lehce jinak.

Výhody

Seznam výhod nebudu rozšiřovat, stále platí co jsem již napsal. U podpory prohlížečů jsme narazili pouze na jeden problém a to v nastavení modality okénka (ig:dialogWindow) v IE 6 - v této verzi IE se nám prostě modální okénka nepodařilo rozchodit.

Obecně bych jako největší výhody NetAdvantage označil vzhled a AJAX. Komponenty vypadají hned "v základu" moc hezky, vše je možné skinovat. AJAX funguje bez problémů, člověk ho může používat, aniž by o něm něco věděl.

Nevýhody

Seznam nevýhod resp. nedostatků musím celkem rozšířit. Nejdříve bych ale doplnil informace uvedené v předchozím shrnutí:
  • dokumentace - úroveň uvedené dokumentace (JavaDoc a příručka programátora) jsou pořád na stejné úrovni, jen navíc přibyly nové stránky s ukázkami a příklady. Tyto stránky jsou moc pěkně udělány a navíc obsahují hodně vychytávek, které nikde jinde v dokumentaci uvedeny vůbec nejsou.

  • AJAX a MyFaces Orchestra spolu moc nefungují (neplatí) - toto již neplatí, chyba na straně Apache Orchestra (pozn. ona to úplně nebyla chyba, protože nikde není přesně popsáno jak má fungovat JSF a AJAX dohromady) byla opravena.

  • podpora pouze JSF 1.1 (neplatí) - jak jsem již psal, tak je možné již používat JSF 1.2.


Nyní bych rozšířil seznam nedostatků, na které jsme narazili v průběhu vývoje:
  • JSF chybové zprávy - v konfiguraci JSF jsme nastavili odkaz na vlastní properties soubor s chybovými hláškami. Správně se používají u standardních JSF komponent, ovšem s NetAdvantage komponentami (konkrétně např. ig:dateChoose) se pořád používají chybové hlášky z myfaces.jar.

  • nemožnost používat čisté HTML - i když samotné facelets umožňují libovolné používání "čistého" HTML včetně EL bez nějakých tagů (kdekoliv na stránce mohu použít #{data}), tak bohužel toto neplatí pro NetAdvantage komponenty. Uvnitř těchto komponent (my jsme to raději používali všude) je nutné EL volat pomocí h:outputText a čisté HTML tagy (konkrétné DIV) nahrazovat tagy z Tomahawku (t:div).

  • komponenta ig:dropDownList nefunguje s konvertery - o této chybě jsem již psal, zde uvádím znovu jen kvůli úplnosti

  • ig:link nemá onClick() - NetAdvantage náhrada za h:commandLink má navíc hlavně vestavěnou podporu pro AJAX, ale bohužel nemá metodu onClick. To je například problém, když máte tabulku s možností smazání libovolného řádku s tím, že vlastní smazání musí být ještě potvrzeno. Pokud chci AJAX, tak nemám možnost toto udělat, museli jsme použít normální h:commandLink a oželet v tomto případě AJAX.

  • ig:dateChooser ignoruje locale

  • problémy s ig:dialogWindow - ig:dialogWindow vytváří modální/nemodální okénko (ne pop-up okénko). Zde máme občas problémy s tím, že modalita není dodržena (při více aktivních okénkách na stránce) nebo si uživatel občas může všimnout problikávání při načítání stránky. Ale toto jsou pouze "kosmetické" věci, které bohužel uživatel připomínkuje nejčastěji.

  • předávání parametrů do komponent - vytvářeli jsme si Facelets komponenty pro různé tabulky (ig:gridView), protože jednou se tabulka použije v detailu, podruhé v editaci atd. Naše komponenty měly vždy alespoň jeden parametr a to dataSource pro načtení dat do tabulky. Bohužel předávání proměnné datového zdroje jako parametr naší Facelets komponenty nefungoval.

  • rekurzivní vytváření stromu - komponenta ig:tree umožňuje vytvářet stromy. Jednou z možností načtení dat do stromu je rekurzivní přístup, který nám bohužel nefungoval.

  • předávání objektu řádky tabulky pomocí f:setPropertyActionListener - NetAdvantage komponenta pro tabulku ig:gridView nabízí objekt #{DATA_ROW}, který představuje aktuální objekt pro určitou řádku tabulky. Bohužel není možné tento objekt nasetovat pomocí f:setPropertyActionListener.

  • ...


Závěr

Nakonec jsem vypsal jen ty nejdůležitější nedostatky, protože jich je mnohem více. Většina z nich je reportována výrobci jako chyba a většina z reportovaných chyb je označena statusem "In Development", tak snad budou někdy opravené.

Pokud nás během vývoje něco brzdilo, tak to byly NetAdvantage komponenty, protože vždy nějakou dobu trvalo, než jsme našli tu správnou cestičku. Musím hned ale dodat, že absolutní většinu všech nedostatků se nám podařilo vyřešit, obejít. Také je otázka, zda by to bylo výrazně jiné s jinými JSF komponentami? Pro nás to byl první větší projekt s JSF, takže jsme se učili spoustu věcí za běhu. Během vývoje jsme se několikrát ptali sami sebe, zda nezkusit jiné komponenty, ale dobře jsme udělali, že jsme vydrželi.

Závěrečná otázka asi bude "Použít či nepoužít"? Vzhledem k tomu, že již znám "cestičku", kudy jít při vývoji s NetAdvantage komponentami, tak bych se nebál je použít i na dalším projektu. Zvláště pokud by byla možnost do projektu zasahovat již v době návrhu, tak aby se již v této fázi eliminovaly "neprůjezdné cestičky". U nového projektu nevím. Pokud by to mělo být jen pro jeden projekt a nic dále, tak bych do toho nešel, ale pokud je to s vidinou toho, že to budete využívat i na dalších projektech, tak se pak ten čas navíc (u našeho projektu cca 20% času vývoje) celkem vrátí.

23. prosince 2008

Druhý rok Javičky

K napsání tohoto příspěvku mě inspiroval Otec Fura :). Sice (bohužel) nemám takové výsledky jako on, ale i přesto si myslím, že špatné to úplně není. Jedna věc jsou statistiky a druhá věc je vlastní naplnění, tedy že to vůbec dává nějaký smysl psát blog. Na úplném začátku psaní tohoto blogu jsem měl určité představy a musím říct, že se my všechny tyto představy naplnily. Proto asi pořád ještě píšu :).

Používám také Google Analytics, ale začal jsem ho používat až v polovině května, takže mé statistiky nejsou za celý rok. Sice od začátku používám službu Navrcholu, ale ta pro neplatícího uživatele mnoho nenabízí.

Mě se dosud v tomto roce podařilo napsat 35 článků. Aspoň pro mě je to celkem velké číslo, protože roční holčička bere čím dál více času a práce je také celkem dost. Podle rozvržení jednotlivých článků v průběhu roku je hezky vidět, kdy jsem měl napilno (to jsem moc nepsal, protože člověk je rád, že u toho počítače nemusí pořád sedět) a kdy jsem něco navrhoval nebo zkoušel (to jsem psal nejvíce, protože člověk má nejvíce nových podnětů a rád se s nimi podělí).

Souhrnné statistiky za rok 2008

  • Počet příspěvků: 35
  • Počet unikátních návštěvníků: 8,419 (max. 1,517 září 2008)
  • Počet unikátních návštěv: 15,166 (max. 2,344 září 2008)
  • Počet zobrazení: 22,275 (max. 3,447 září 2008)

Nejčtenější příspěvky (počet přístupů)

  1. Máte čas na unit testy? (1,135, 5.10%)
  2. Srozumitelnost zdrojového kódu (1,020, 4.58%)
  3. JSF - sestava sedmi statečných (957, 4.30%)
  4. Hibernate - práce s kolekcemi, ManyToMany vazba (912, 4.09%)
  5. Jakou databázi používáte? - výsledky (810, 3.64%)
  6. OSGi: Použít nebo nepoužít? (763, 3.43%)
  7. Nástroje SoapUI a JMeter (753, 3.38%)
  8. JSF zase nejsou tak špatný ... (751, 3.37%)
  9. Jaký webový framework používáte - výsledky (716, 3.21%)
  10. JSF s NetAdvantage (713, 3.20%)
  11. Komentovat? Určitě ano. (668, 3.00%)
  12. Open-source ESBs (667, 2.99%)
  13. Verzování entit - JBoss Envers (662, 2.97%)
  14. Přechod z Acegi na Spring security (614, 2.76%)
  15. JSF - FacesTrace a MyFaces Orchestra (596, 2.68%)
  16. NTLM a Spring security (486, 2.18%)
  17. Výhody a nevýhody EJB (398, 1.79%)
  18. JSF a Spring - postup o krok dále (353, 1.58%)
  19. Proč nemám rád Seam (347, 1.56%)
  20. Ukázka konfigurace Acegi security (347, 1.56%)

Zdroje přístupu (počet přístupů)

  1. java.cz (7,057, 46.51%)
  2. google (3,491, 23.01%)
  3. přímý přístup (1,768, 11.65%)
  4. root.cz (649, 4.28%)
  5. seznam.cz (613, 4.04%)

Lokace návštěvníků (počet návštěvníků)

  1. Česká Republika (12,211)
  2. Slovensko (1,628)
  3. Německo (350)
  4. Finsko (206)
  5. Velká Británie (180)

Rozvržení prohlížečů (počet návštěvníků)

  1. Firefox (10,470, 69.04%)
  2. Opera (1,912, 12.61%)
  3. Internet Explorer (1,874, 12.36%)

Rozvržení operačních systémů (počet návštěvníků)

  1. MS Windows (12,004, 79.15%)
  2. Linux (2,774, 18.29%)
  3. MacOS (318, 2.10%)