pondělí 29. prosince 2008

Apache Wicket - Znovupoužitelné komponenty

Tvorba vlastních komponent je u komponentově orientovaného web frameworku, důležitá vlastnost. Jen težko bych hledal projekt, který by si vystačil s existujícími vlastnostmi a komponenty daného rámce a nesnažil se o vlastní tvorbu.

Pokud bych Wicket srovnával s JSF na této úrovni, musel bych více podrobněji znát tvorbu komponent v JSF. Ať jsem se snažil sebevíc, nikdy jsem úplně neodhalil výhody vlastních komponent v JSF. Ten postup mi přišel natolik složitý a nesmyslný, že v tomto případě jsem vždy sáhnul po něčem existujícím (RichFaces, Tomahawk, atd.). V JSF mám v tomto ohledu jen teoretickou znalost, která mi ovšem stačí k tomu, abych se do nečeho takového, jako je tvorba vlastních komponent, vůbec nepouštěl.

Ve Wicketu je situace naprosto rozdílná. Samotný framework mě v podstatě nutí rozsekávat danou prezentaci do několika menších celků, které se později dají znovu použít. Navíc je situace o to snažší, že není potřeba se učit či používat nové věci. Bohatě stačí znalost základních komponent a jejich využití. Vše ostatní vyplyne samo.

Pro tvorbu nové komponenty je nejčastěji používán "org.apache.wicket.markup.html.panel.Panel", od kterého má vlastní komponenta dědí. Díky tomu získám základní vlastnosti, které bych musel jinak znovu tvořit. Podobnost lze najít u Swingu, kde vlastní komponenty nejčastěji dědí od JPanelu.

Na malém příkladu ukážu, jak vytvořit komponenu, která bude obsahovat základní informace o zaměstnanci. Tuto komponentu poté budu moci využít např. při kliknutí na detail zaměstnance, při výpisu zaměstnanců, apod. Všude, kde budu chtít znát základní informace o daném zaměstnanci.

Nejprve doménový model:
public class Zamestnanec { 
private String idCislo;
private String prijmeni;
private String jmeno;
// set, get
}

Nyní vytvořím wicket komponentu:
<wicket:panel>
<span wicket:id="prijmeni"></span> <span wicket:id="jmeno"></span> (<span wicket:id="idCislo"></span>)
</wicket:panel>

A k danému HTML i Java kod:
public class ZamestnanecPanel extends Panel {
  public ZamestnanecPanel(String id, Zamestnanec z) {
  super(id);
  add(new Label("prijmeni", z.getPrijmeni());
  add(new Label("jmeno", z.getJmeno());
add(new Label("idCislo", z.getIdCislo());
  }
}

Tím mám vlastní komponentu hotovou.

Nyní ji stačí využít. Například při zobrazení detailu zaměstnance:
... hlavicka html stranky ....
<div class="detail">
<span wicket:id="zakladni"></span>
.... další vlasnosti
</div>
... paticka html stranky.....

K danému HTML i Java kod:
public class DetailPage extends WebPage {
  public DetailPage(String idCislo) {
  super();
  add(new ZamestnanecPanel("zakladni", service.findById(idCislo)));
  // dalsi vlastnosti
  }
}

I když je daný příklad triviální, jasně znázorňuje to, že tvorba vlastních komponent je v Apache Wicket velice jednoduchá a hlavně dobře použitelná. Způsob jak navrhovat takové komponenty je stejný jako v případě tvorby objektově orientovaného kódu. Třídy jsou malé a obsahují jen jednu jasně specifikovanou funkcionalitu. Stejné je to i zde.
*Myslím, že tohle je ta nejzásadnější věc, která dělá z Apache Wicketu dobrý framework, ve kterém je radost něco psát. Vytvořit komponenty a pak je skládat jako lego :)*

úterý 23. prosince 2008

JPA 2.0

Nedávno zveřejněná specifikace JPA 2.0 obsahuje asi nejzásadnější posun v možnosti psaní Criteria API. Pokud někdo očekává okopírované Criteria API z Hibernate bude možná trošku zklamán (či potěšen).

Nový způsob je totiž více postaven na "objektovosti" daných entit. Dobrý zdroj a ukázku lze najít na blogu Gavina Kinga.

Osobně toto považuji za správný krok. Samotné JPA (EntityManager) umí pouze JPQL dotazy, které jsou napsané jako jeden String řetězec. To sebou přináší hromadu nevýhod a v mnoha případech nutí, aby si vývojář napsal nějaký ten vlastní "JPQL String Parser". Z tohoto důvodu jsem osobně JPA degradoval na "pouhé" ORM mapovaní, kde mi jasně specifikovaný standard umožňuje být více nezavislý na použitém "provideru pro persistenci". EntityManager jsem vyměnil za "Hibernate Session" a vesele si psal svá Criteria API.

Hibernate Criteria API ovšem nejsou všespásná. V některých případech je tento způsob nepoužitelný. Občas člověk narazí na nějaký ten bug či extrémní složitost psaní dotazu. Jakmile vznikne požadavek na "subquery", je Hibernate Criteria API velká loterie. Samotná podpora poddotazů je totiž žalostná. Podle toho, co jsem zatím viděl, si myslím, že způsob zápisu v JPA 2.0 bude v tomto více přizpůsobivější a umožní plně nahradit jakýkoli JPQL dotaz.

Další věcí je **návratová hodnota dotazu**. Asi nikdo nepředpokládá, že lze pomocí namapovaných entit vše vyřešit. V takových chvílích nastupují DTO objekty, které se časem začnou množit. Způsob, jak výsledek převádět do vlastních objektů, je v JPA 1.0 dost špatně navržen. Psát "new cela.pakaz.az.k.ZakaznikDTO(a, zde, hromada, parametru)" je otřesné. Když k tomu ještě připočítám nutnost tvorby konstruktorů, tak jak jsou tvořeny v JPQL, dostanete se do situace, kdy Vám Java jako staticky typovaný jazyk přestane pomáhat. Budete se muset spoléhat na správnost daných JPQL dotazů i v případech refactoringu (samozřejmě testy mohou pomoci :)).

Proto i zde jsem zvolil Hibernate Criteria API, jelikož způsob návratové hodnoty lze mnohem lépe zapsat pomocí "Hibernate Projections".

Bohužel i tato volba není úplně ideální a opět obsahuje "mouchy". První z nich je asi to, že nelze vytvořit DTO objekt, který bude obsahovat referenci na jiný objekt než ten, který zná Hibernate nad JDBC (String, Integer, atd.). Zde se jaksi ztrácí ono magické OOP a nastupuje hromada primitivních DTO objektů, které mezi sebou nelze propojit jako v případě mapovaných entit. Jediné propojení lze samotřejmě provést pouze na úrovni vlastního Java kódu.

I když jsem novou specifikaci nečetl řádek po řádku, nenalezl jsem v této oblasti žádný posun. Je pravdou, že i "select statement" byl z části vylepšen, ale nikoli tak, aby umožňoval tvorbu vzájemně propojených DTO objektů.

Ale i přesto musím říct, že nové Criteria Query API se mi v JPA dost zamlouvají. Snad bude tento nový způsob zápisu alespoň schopen nahradit Hibernate Criteria API.

*Specifikace pro JPA je dosti rozsáhlá a myslím, že jako čtivo na dlouhé zimní večery bude jistě dobrou volbou :)*

pondělí 13. října 2008

Apache Wicket - IBehavior, Tabulky

Minule jsem psal o možnosti spojení Wicketu s EJB3 a o Wicket Security. Dnes se podívám na další vlastnosti a možnosti tohoto webového frameworku.

IBehavior

Jedná se o interface, který je označován jako druh pluginu wicket komponent. Já jsem dané řešení využil například pro statistiku návštěvnosti či pro zjistění, jak dlouho trvalo vyrendrování wicket stránky.

Příklad, pro zjištění doby trvání vyrendrování wicket stránky:
public class TimeBehavior extends AbstractBehavior {
private long start;

@Override
public void beforeRender(Component component) {
start = System.currentTimeMillis();
}

@Override
public void onRendered(Component component) {
super.onRendered(component);
long dobaBehu = System.currentTimeMillis() - start;
// dalsi zpracovani
}
}


Třída je potomkem AbstractBehavior, což je adaptér pro interface IBehavior. Tuto implementaci stačí poté přiřadit v "BasePage" (základní Wicket Page, která je předkem všech Page). Samozřejmě, pro Wicket je Page komponenta stejně jako např. TextField. Proto je možné daný plugin přiřazovat i daným komponentám uvnitř Page, Panel, atd.

Možností, jak využít toto rozšíření pro komponenty je mnoho. Pomocí této vlastnosti se například dá z klasického input fieldu vytvořit zadávací políčko s kalendářem pro datum, atd. Stačí implementovat metodu "onComponentTag" a tu patřičně upravit. Tato funkcionalita s kalendářem je již přímo implementována (viz. wicket-datetime: DatePicker).

Tabulky

Každý webový intranetový systém se z velké části točí okolo poskytování dat v jasně specifikované formě. Nebo chcete-li: "hromada tabulek s vlastní filtrací". K tomuto účelu poskytuje Wicket přímo vlastní komponenty, viz: repeater example.

Do nedávné doby existoval web: inmethod.com, který danou funkcionalitu rozšiřoval o vlastní druh tabulek. Tato implementace byla zatím asi to nejlepší, co jsem v oblasti webu a webových frameworků viděl.

Tabulky mají statické sloupce a posuvný obsah (ala excel), možnost řazení sloupců, přesun sloupců, změnu velikosti sloupců, atd.

Příliš nechápu proč, byl tento projekt ukončen (zřejmě jako ostatní: nedostatek volného času). Naštěstí je ale možné si přes svn stáhnout zdrojové kódy, které lze použít. Je k dispozicii živá ukázka.

Daný projekt je psán vůči verzi 1.2. Pro verzi 1.3.x není k dispozici alternativa. Osobně danou knihovnu pro verzi 1.3.3 využívám, ovšem s tím, že jsem dané zdrojové kódy musel částečně upravit. Pokud by měl někdo zájem, mohu mu upravenou knihovnu zaslat.

Danou implementaci lze samozřejmě dále rozšiřovat. Stačí se například podívat jak je definována třída: "com.inmethod.grid.column.PropertyColumn".

Příště ukáži, jak lze snadno tvořit znovupoužitelné komponenty v Apache Wicket.

pátek 19. září 2008

Trocha dávky Apache Wicket

Od posledního příspěvku na tomto blogu již uplynula nějaká ta doba. Nebudu tvrdit, že jsem neměl čas. Důvodem byla spíše chuť něco nového napsat. To je ovšem pryč, takže se vrátím zpět ke svému psaní :)

Apache Wicket je zajímavý hned z několika důvodů. Některé z nich jsem prezentoval minule a proto dnes přidám snad jediný důvod: baví mě v něm psát aplikace.

Každý, kdo má alespoň obecnou znalost tohoto frameworku, musí si daný způsob ihned spojit s psaním aplikací ve swingu. Asi bych to vyjádřil slovy: piš to jako ve swingu a přidej k dané třídě html soubor.

Wicket a EJB3

Dají se tyto dvě technologie jednoduše spojit? Repektive dá se snadno zařídit závislost wicket komponenty na EJB servisní beaně? Ano dá. Stačí stáhnout wicket-contrib-javaee.

Pro schopnost provést jednoduché DI (dependency injection) přes anotaci @EJB je třeba definovat referenci ve web.xml.
<ejb-local-ref>
  <ejb-ref-name>cz.irminsul.javaee.ejb3.ServiceLocal</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<local>cz.irminsul.javaee.ejb3.ServiceLocal</local>
</ejb-local-ref>

Při definici ejb-ref-name používám celý název daného rozhraní. Důvod je ten, že poté nění třeba při definici DI uvádět @EJB(name="reference"). Výsledné DI vypadá následovně:
public class MyPage extends Page {
 @EJB
 private ServiceLocal service;
 ....
}




Wicket a Security

Existuje několik možností, jak definovat security. Já osobně jsem zvolil WASP. Toto řešení je postaveno na rolích (i když spíše záleží na způsobu implementace). Je zde několik důležitých kroků k uspěšnému nasazení.

1. Definovat vlastní .hive soubor

2. Base page musí být potomkem SecureWebPage

3. Wicket Session musí být potomkem WaspSession

4. Application class musí být částečně upravena (viz příklady na daném WASP webu)

5. Musí se definovat vlastní LoginContext a Principal

Nebudu zde rozepisovat jednotlivé kroky. Dané příklady lze najít na odkazovaném webu pro WASP. Uvedu jen to zajímavé:

Definice oprávnění lze použít jak na celou page, tak na danou akci, tak na daný model. Z toho lze usoudit, že daný způsob by měl být dostačující k danému použití v jakémkoli scénáři. Celá tato definice je uvedena v .hive souboru, který je poté nastaven v Application class. Samozřejmě daných .hive souborů může existovat klidně více.

U definice oprávnění v .hive souboru lze nastavit, zda se bude daná definice týkat i potomků daných page tříd. Zda je k nějaké page přístup globální, či pro danou roli, atd.

Daný způsob implementace se mi vcelku zamlouvá. Jediné, co bych danému řešení vytkl je to, že dokumentace je téměř nulová. Jediný zdroj informací jsou proto jen příklady, které si lze stáhnout a poté prozkoumat jejich kód.

Tak to by bylo asi vše. Příště ukáži jak lze využít IBehavior či jak je na tom Wicket s nenáviděnými html tabulkami.

středa 16. července 2008

Serial port v Jave aneb RXTX

Jakožto spokojený uživatel linuxu jsem dost odstíněn od windows. Bohužel to sebou přináší i určité problémy, kdy potřebuji portovat aplikaci na windows.

Ano, java je multiplatformní, jenže pouze do chvíle, kdy potřebujete přistupovat k sériovému portu a číst z něj data. K tomuto účelu existuje několik možností, které ovšem v jave znamenají implementovat funkčnost pouze pro daný OS.

Nic není tak černé, a proto existuje možnost, jak donutit vaši aplikaci, aby uměla komunikovat se sériovým portem na více OS. To vše bez nutnosti měnit stávající kód.

Ta možnost je přes RXTX. Kromě klasického COMx umí i LPT či USB.

Samotná implementace je víceméně jednoduchá:

  • nakopírují se příslušné knihovny (u linuxu do usr/lib/ a u windows do jre/bin).

  • přes JNI se zavolají příslušné metody z knihoven daných OS

  • otevře se port, zaregistruje listener a již mohu číst či zapisovat.


Jelikož na notebooku používám redukci mezi USB a sériovým portem, trochu jsem se bál samotného zprovoznění. Opak je pravdou. Přes identifikaci zařízení "/dev/ttyUSB0" jsem byl schopen se spojit stejně jako přes COM1 na windows.

Pro testovací účely jsem si napsal malý prográmek, který se snaží dohledat všechny porty. Podle identifikace je poté možné port otevřít a čekat, zda z portu přijdou nějaká data.

Ke stažení: Testovací program pro poslouchání portů

středa 18. června 2008

Je čas na Apache Wicket?

Záznam diskuze:
L: Ahoj Franto, mám menší problém.
F: Jaký Lumíre?
L: Nevím, který webový framework pro javu je nejlepší.
F: No to je jednoduché. Vyzkoušej těch 40 nejznámenjších a pak se rozhodni.
L: Hmm... :(
Konec.

Ať již člověk navštíví jakoukoli homepage webového frameworku, dočte se, že zvolil dobře. Nejlepší možné řešení, vše jednoduché, perfektně rozšířitelné a v porovnání s ostatními je proste "Number ONE".

Sám jsem již dávno rezignoval na hledání zlaté žíly v podobě nejlepšího řešení. Volbu by mělo ovlivňovat to, jakou architekturu dané aplikace plánuji či jakým backendem aplikce disponuji. I když jsou snad všechny možné kombinace možné (Seam + Spring, Seam + EJB, Wicket + Spring, ...., ne vždy je volba zrovna šťasná. Pokud do hry vložím další možnosti jako volání část aplikace jiným způsobem (např. remote EJB), dostávám již užší skupinu možností.

Z této skupiny, která se vyznačuje volnou vazbou na business logiku, snadnou rozšířitelností a možností souběžného běhu s jiným web kontextem mi zatím nejlépe vychází Apache Wicket.

Ano já vím, stále existuje lepší .... nebo ještě lepší .... a vlastně úplně nejlepší ...... Ale já nemám čas ani náladu zkoumat další desítku možností. Stačí mi ta první desítka :)

Proč Apache Wicket?

  • volná vazba na business logiku

  • žádné xml

  • žádné anotace, které z POJOs dělají komponenty použitelné pouze v daném kontextu

  • téměř čisté html

  • vše je psané v jave, takže refactoring je mnohem snažší záležitost

  • dané komponenty si pamatují předchozí stav, takže tlačítko zpět již nemusí být noční můrou

  • menší zátěž pro server oproti JSF či Seamu

  • psaní aplikace je velmi blízké psaní swingových aplikací

  • dostatek komponent + snadné psaní znovupoužitelných komponent

  • při psaní se skutečně využívá objektově orientovaných principů

  • pro běh není třeba žádného speciálního kontextu (běží stejne v Tomcatu jako v AS)

  • daná aplikace je snadno přenositelná na jakýkoli jiný web kontejner


Asi bych mohl pokračovat dalšími body. Nicméně to, co jsem zde vypsal jsou vlastnosti, které mě přesvědčují o správné volbě.

Co se týče záporů, ty si budu muset nechat na pozdější dobu. Zatím jsem jen nezávislým pozorovatelem daného web frameworku. Každopádně jsem pevně rozhodnut toto řešení použít i za cenu složitejší spolupráce s EJB modulem a částí aplikace napsané v Seamu.

Takže mám 2 favority. Seam a Apache Wicket. Každý z nich přistupuje k cíli jiným způsobem a každý z nich se rozhodně hodí pro jiný typ aplikací. Až si Apache Wicket více osahám pokusím se obě řešení více porovnat a přesněji zjistit, pro jaký typ aplikací se dané frameworky hodí.

sobota 24. května 2008

Testování EJB komponent

Všeobecně známý fakt, že se EJB komponenty špatně testují, je postaven zejména na tom, že neexistuje žádný standardní způsob, jak při psaní testů postupovat. Pokusím se sepsat způsoby, jak tento palčivý problém vyřešit.

O tom, že je testování důležitá část vývoje, nemá smysl polemizovat. V poslední době se na české scéně objevilo několik článků: "proč je testování důležité". Osobně zastávám názor, že bez testů nemohu kód považovat za funkční a jeho nasazení je velký risk, který se násobí následným refaktoringem či řozšiřováním stávajícího kódu.

V následujících odstavcích se budu zabývat jen EJB 3.0.

Způsoby testování bych rozdělil na 2 typy: testování uvnitř aplikačního serveru a mimo něj.

Testování uvnitř aplikačního serveru

Tento způsob má tu výhodu, že dané testy se mohou začít psát bez jakékoli další pomůcky pro inicializaci EJB kontejneru a služeb v něm. Ohromnou nevýhodou je ovšem to, že samotné psaní a spouštění testů je přímo závislé na nastartování a nahrání celé aplikace na server. Tato činnost může při větších projektech trvat řádově i několik minut. V takové chvíli může vývojář získat naprostý odpor k testování.

Způsob, jak testovat EJB komponenty uvnitř AS, je použití vzdáleného volání EJB komponent. Nevýhodou je ovšem to, že při návrhu musíte definovat "remote" rozhraní.

Druhým způsobem je testování přímo v EJB komponentě, kde mohu pomocí DI (dependency injection) získanou EJB komponentu otestovat. Nevýhodou je zde to, že tento způsob již překračuje základní způsoby testování. JUnit či jemu podobný framework je v takovém případě nepoužitelný.

Testování mimo aplikační server

První velkou nevýhodou tohoto řešení je samotný fakt, že nějak musíte nahradit EJB kontejner. Asi nejznámějším řešením je použití Embedded JBoss.Tento způsob vyžaduje, aby vaše aplikace byla schopná běžet pod JBoss AS, a abyste použili JVM 1.5 (na novejších verzích bohužel embedded JBoss nespustíte). Pokud aplikaci vyvíjíte pod jiným aplikačním serverem, budete s tímto mít asi problémy. Například už jen z důvodu samotné nestandardizace JNDI či použitých nekompatibilních vlastností pro Java EE 5.

Druhým způsobem, jak umožnit testování EJB komponent mimo aplikační server je, že použijete framework typu Ejb3unit, který na základě vaší definice EJB komponent sám provede dependency injection a další vlastnosti typické EJB kontejneru. Nevýhoda tohoto řešení spočívá v tom, že má příliš mnoho omezení, která poté mohou zbytečně ovlivňovat návrh business vrstvy. Na stránkách je možné se dočíst, že brzy vyjde verze 2.0, která snad přinese slibované vlastnosti.

Posledním způsobem, jak vyřešit testování, je použití vlastního řešení. Jelikož používám jako aplikační server Glassfish, byl pro mne JBoss Embedded tabu. Jelikož mám i uvnitř EJB komponent občas složitejší architekturu (dělené vrstvy), tak Ejb3unit byl nepoužitelný.

Můj vlastní způsob spočívá v tom, že testuji EJB komponenty, které obsahují vazby na další EJB pomocí anotací @EJB či vstřikují pomocí @PersistenceContext EntityManager (+ občasné delegování na Hibernate Session).

Jinými slovy, řídím EJB pomocí anotací, což mi umožňilo napsat si i vlastní řešení na testování. Moje řešení totiž využívá Java reflection API, přes které provádím jak dependency injection dalších EJB komponent, tak samotné DI EntityManageru a dalších zdrojů, které zrovna potřebuji.

Test poté vypadá jednoduše: "při inicializaci pošlu testovanou EJB komponentu do metody, která mi vrátí instanci samotné EJB komponenty i s inicializací potřebných závislostí".

Zatím jsem nenalezl lepší řešení. Pravdou je, že v této oblasti jsou EJB komponenty nechány napospas vývojářům, což s sebou přináší jen nekompatibilní způsoby testování jednotlivých částí aplikace.

Doufám, že Glassfish V3 přinese slibovanou možnost být "embeddable" v plném rozsahu či někoho v SUNu napadne s tímto problémem něco udělat. Zatím mi přijde, že každý si napíše vlastní řešení, protože kromě JBoss Embeddable jsem nenašel nic, co by alespoň trošku splňovalo mé požadavky.

Pokud má někdo zkušenosti i s dalšími možnostmi testování EJB komponent, nechť se o ně podělí v komentáři, děkuji.

neděle 4. května 2008

NetBeans 6.1 a Facelets plugin

O tom, že vyšly Netbeans 6.1 se nemá smysl zmiňovat. Ovšem výhodou této verze je zejména její rychlost, na kterou se údajně vývojáři nejvíce zaměřili.

Jedna věc mi ovšem zde chyběla. A to opět plugin pro facelets :)

Naštěstí existuje řešení, jak daný plugin dostat do této verze.

Následující text je spíše dočasný, tzn., že  až vyjde oficiální podpora, jistě bude lepší použít přímo ji.

Na stránce https://nbfaceletssupport.dev.java.net/ je k dispozici cvs repozitář. Z daného repozitáře stačí provést checkout projektu a daný projekt "nbfaceletssuite" otevřít v NetBeans 6.1. Dané pluginy poté zbuildovat a provést create nbm. Tyto pluginy jsou poté schopny pracovat ve verzi 6.1.

Pak již stačí pluginy nainstalovat a máte k dispozici starou dobrou (i když ne zrovna plnou)  code completion v xhtml souborech :)

Glassfish V3 bude embeddable

Minulý týden mi v rss čtečce přistál článek od Kohsuke Kawaguchi, že Glassfish V3 bude "embeddable".

Osobně jsem si přesně toto pro Glassfish přál. Představte si, že budete mít EJB projekt, který budete moci spouštět např. v Tomcatu. Že budete moci testovat EJB, aniž by bylo potřeba provádět deploy na server či používat remote call EJB či používat "nepoužitelné" frameworky jako je EJBUnit (i když uvidíme jak dopadne verze 2.0). Vše co obsahuje specifikace Java EE 5 a vše co implementuje Glassfish je tedy možné provozovat aniž by někde musel běžet daný server.

V současné době se touto možností může chlubit JBoss AS či Jetty, nyní již stačí počkat pár měsíců (možná týdnů do testovací fáze) a bude možné to samé dělat s GlassFish.

Díky modularitě tohoto AS je ovšem možné startovat server v řádech několika milisekund, což narozdíl od JBoss AS je podstatný rozdíl :)

Před nějakým časem jsem chtel Glassfish opustit a jít cestou JBoss, ale asi ještě chvíli počkám, je vidět, že konkurenční prostředí je prostě ideální stav.

Teď nezbývá, než držet palce, ať se dané featury dotáhnou do úspěšného konce.

pondělí 21. dubna 2008

Informace o WebBeans

O víkendu jsem shlédl video, ve kterém Gavin King přednášel o WebBeans. Z daného videa mám vcelku dobrý pocit a pokusím se zjednodušeně sepsat, co v přednášce bylo a jak asi bude vypadat psaní takových Web Beans.

Web Beans jsou novou specifikací, která se objeví v Java EE 6. Mezi hlavní účel patří zjednodušení vývoje webových aplikací. Samotné Web Beans jsou inspirovány (kopie) webového frameworku Seam. Jelikož je autorem jeden a tentýž člověk (Gavin King), je vcelku jasné, že lidé, kteří znají Seam budou na Web Beans přecházet stejně jednoduše jako třeba v případě Hibernate -> JPA.

Takže, co například Web Beans poskytují a nabízejí:

  • možnost psát komponenty jako Stateful EJB, které se anotací vystaví jako Web Beans se všemi vlastnostmi Stateful EJB

  • dependency injection, jednoduché vstříknutí do JSF stránek; tak jako v Seamu

  • konverzace

  • ovládání persistence context, která může např. řešit lazy loading

  • integrace s JSF, Servlety či JPA

  • JSF backing beana může být vystavena jako Web Beana

  • atd.


Nikoho asi nepřekvapí, že samotné Web Beans jsou řízeny pomocí anotací. Samozřejmě opět existuje možnost používat xml, ale myslím, že tato volba bude zřídkakdy využívána a nejsem si jist, že všechny možnosti budou v xml obsaženy.

Jak tedy takové Web Beans vypadají? Příkladem může být jednoduchá komponenta:
@Component
public class Komponenta {
public String pozdrav(String jmeno) {
return "Ahoj " + jmeno;
}
}

Samotnou anotací @Component označujeme, že se jedná o Web Bean komponentu. Kontejner nám takovouto třídu inicializuje jako Web Beanu. Nic převratného.


Dependency Injection

Při psaní definování závislosti mezi jednotlivými komponenty můžeme použít několik možností:
@Component
public class Printer {
@Current Komponenta komponenta;

public void pozdrav() {
System.out.println(komponenta.pozdrav("Ales"));
}
}

Další možností, jak definovat závislost je např:
@Component
public class Printer {
private Komponenta komponenta;

public Printer(Komponenta komponenta) {
this.komponenta = komponenta;
}

public void pozdrav() {
System.out.println(komponenta.pozdrav("Ales"));
}
}

Gavin tento způsob názývá "constructor injection" :)

Aby toho nebylo málo, máme zde další možnost nazvanou "initializer injection":
@Component
public class Printer {
private Komponenta komponenta;

@Initializer
initKomponent(Komponenta komponenta) {
this.komponenta = komponenta;
}
}


A nyní jednoduché vstříknutí do JSF stránky:


Další věcí, která stojí za zmínku je definování "binding type". Jde o to, že mohu vzít komponentu, tu podědit a při stríknutí závislosti chtít podědenou komponentu. No raději to předvedu :)

Definice vlastniho "binding type":
@BindingType
@Retention(RUNTIME)
@Target({TYPE, METHOD, FIELD, PARAMETER}}
public @interface Casual{}

Nyní již stači napsat vlastní komponentu dědicí moji "komponenta".
@Casual
@Component
public class Cau extends Komponenta {
public String pozdrav(String jmeno) {
return "cau " + jmeno;
}
}


A nyní již vstříknu vlastní komponentu do Printeru.
@Component
public class Printer {
@Casual Komponenta komponenta;

public void pozdrav() {
System.out.println(komponenta.pozdrav("Ales"));
}
}

Výsledkem bude: "Cau Ales".


Věcí, které Gavin King představil je opravdu hodně. Já zde ukážu poslední věc, která je jistě neméně zajímavá.

Nazval bych to "zástupnými anotacemi". Jak jsem na začátku psal, Web Beans jsou řízeny pomocí anotací, což ovšem může vyvolat určité rozpaky ve chvílích, kdy samotná Web Beana bude obsahovat hromadu anotací, které se často opakují.

Představme si, že máme takovouto Web Beanu:
@Component
@Transactional
@Production
@Secure
public class Komponenta {}

Výčet anotací může být i delší, což mě trochu děsí :)

Je však možné použít následující:
@Secure
@Transactional
@Named
@Production
@Stereotype
@Retention(RUNTIME)
@Target(TYPE)
public @interface Action {}

A nyní již použít:
@Action
public class Komponenta {}



Alespoň že tak :)

Všem, kteří se alespoň trochu zajímají o nové specifikace v oblasti J2EE by si měli dané video prohlédnout.
Já osobně jsem si alespoň udělal lepší obrázek o tom, jak vlastně WebBeans budou vypadat.

Zatím musím uznat, že jsem nadmíru spokojen. Pokud bude vše tak, jak Gavin King ukazuje, asi pošlu jeho Seam do věčných lovisť :) Nenarazil jsem v podstatě na nic podstatného, co by Seam měl a WebBeans nikoli. Zatím to vypadá na pravý opak.

neděle 20. dubna 2008

Richfaces pro JSF

Komponentový framework jakým je JSF, má několik kladů, mezi kterými také nalezneme možnost rozšíření o vlastní komponenty. I když psaní vlastních komponent pod JSF není zrovna triviální záležitost.

JSF ve verzi 1.2. nabízí základní komponenty, které mohou být i rozšířitelné, ovšem ne vždy nám vyhovují.  Existence různorodých komponent za nás řeší knihovny třetích stran, které nabízejí zajímavé možnosti. Mezi nejčastějšími požadavky na komponenty jsou různé formulářové objekty, modální panely, stromy, menu, tabulky, atd. Navíc je očekávána podpora AJAXu. Jinými slovy, komponenty, které se svou vizuální a funkční podobou blíží desktop aplikacím.

Pro srovnání různých komponentových knihoven můžeme použít např. AJAX JSF Matrix. Možnost výběru je skutečně obrovský a to nepočítám další, které vznikají téměř každý den.

Samotná volba není zrovna jednoduchá. Já jsem prošel asi 3 různé knihovny z nichž jsem si vybral jasného favorita: RichFaces.

RichFaces

RichFaces má v současné době v  rukou JBoss. Jedná se klasickou JSF komponentovou knihovnu, která ovšem navíc obsahuje i přímou vazbu a podporu A4J (Ajax4JSF). A4J, jak už její název vypovídá se zaměřuje čistě na AJAX a snaží se naučit JSF komponenty asynchroní práci. Jelikož je RichFaces společně s A4J dodávaná jako jedna knihovna (projekt), může nás těšit fakt, že máme jednu z nejlepších kombinaci mezi AJAX-JSF-Komponenta.

V současné době je RichFaces ve verzi 3.2.0, která vyšla vcelku nedávno. Mezi jejími novinkami můžeme najít věci jako: vlastní combo box, progress bar, file upload, atd.

I když je pravda, že s každou novou verzí můžeme nalézt v bugtraceru hromadu opravených a hromadu nový bugů, přesto je tato knihovna použitelná v produkčním nasazení.

Mě nezbývá, než tuto knihovnu doporučit všem, kteří nemají svého favorita a hledají nejakou slušnou podporu pro JSF komponenty. Psát modální okna, kontextová menu či rozbalovací stromy už nemusí být jen výsadou programátoru desktop aplikací.

Pro zběžný přehled doporučuji samotné demo, které je plně přístupné po zaregistrování na RedHat stránkách, kde si jednotlivé vlastnosti můžete ihned vyzkoušet.

úterý 11. března 2008

Seam - tipy a triky (EJB)

Seam je dobře použitelný s EJB, kde jsou jednotlivé EJB vystaveny jako Seam komponenty a navíc obsahují všechny služby, které EJB kontejner nabízí.

Jsou ovšem chvíle, kdy bych potřeboval obyčejnou Seam komponentu a do ní nějakým způsobem vstříknout EJB beanu. Co se týče implementaci pro glassfish, není situace tak jednoduchá, jak by se mohlo zdát.

Takže, mějme příklad, kdy potřebuji vytvořit Seam komponentu, která bude míti jednu metodu, která bude vracet seznam hodnot z nějaké entity.

Klasický přístup by mohl vypadat následovně:
@Name("testList")
public class TestList {
  @Unwrap
  public List<Entita> lookup() {
  return entityManager.createQuery("from Entita e").getResultList();
  }
}

Použití ve facelets stránce by poté vypadalo následovně:

 

Pravdou je, že použití samotné anotace @Unwrap může mít hezké uplatnění.

Jenže, osobně se mi nelibí možnost, že musím uvnitř samotného "testListu" volat entity manager a navíc psát nějaké OQL. Mám již definovanou DAO vrstvu pomocí EJB a chci lookupnout samotnou EJB jako Seam komponentu.

K tomtuto účelu jsem si vytvořil jednoduchou lookup službu, která vypadá následnovně:
@Stateless
@Name("lookup")
@Scope(ScopeType.APPLICATION)
@Interceptors(value = {SeamInterceptor.class})
public class LookupBean implements LookupLocal {

@Resource
private EJBContext context;

@EJB
  private SessionLookupLocal sess;

public Object ejb(String bean) {
  return context.lookup(bean);
  }

public EntityManager getEntityManager() {
  return sess.getEntityManager();
  }

public Session getSession() {
  return sess.getSession();
  }

}

Takže lookup služba slouží k získaní jak EJB beany tak entity manageru popřípadě Hibernate Session. Dá se sice namítnout, že Seam umí přímo injectnout EntityManager (dokonce se to dá hackem zprovoznit i v glassfish), ale já si raději vsrtvy odděluji, proto injectuji daný "persistence provider" jen v nejnutnějších chvílích. Druhou věcí je fakt, že daný provider pro persistenci přenáší jiná EJB beana. Důvodem je fakt, že při inicializaci a vytvoření Seam komponenty ještě není znám provider pro entity manager, proto ho musím získat z jiné EJB.

Ale zpět. K tomu, aby daná lookup služba (která je jak Seam komponentou tak EJB komponentou) byla schopná lookupovat EJB, musí být navíc definovana reference na dané EJB beany v ejb.jar.xml, nebo pomocí anotací. Já jsem zde raději přistoupil k možnosti pomocí XML, jelikož se jedná o speciální požadavek, který se v průběhu života může změnit.
    
 
  LookupBean
  cz.irminsul.seam.app.LookupBean
 
  NejakaDAOBean
  cz.irminsul.NejakaDAOLocal
  NejakaDAOBean
 

 

 

Díky této definici reference mám možnost uvnitř lookupBean získávat ejb dynamicky, tedy přes initialContext.

Konečné použití uvnitř Seam komponenty, která není EJB beanou, může vypadat následovně:
@Name("testList")
public class TestList {

@In(value = "#{lookup.ejb('NejakaBean')}")
  private NejakaLocal bean;

private List<Entita> data;

@Unwrap
  public List<Entita> lookup() {
  if (data == null) {
  data = bean.metodaLokalnihoInterface();
  }
  return data;
  }

}

Samozřejmě je možné získat i Entity Manager či Hibernate Session. Použití je v podstatě jasné:
@In("#{lookup.entityMananger}")
private EntityManager em;

Daný návod je funkční v Seam 2.0, EJB 3 a Glassfish V2.

pondělí 18. února 2008

DTO a ORM

Pojem DTO jistě není třeba představovat. Jedná se o objekt reprezentující data, které je třeba přenést z jedné strany na druhou. Asi nejčastějším využitím jest výsledek dotazu z persistentní vrstvy.

Při použití ORM frameworku, jako je např. Hibernate, definuji data v DB pomocí objektů (entit). Tyto entity poté mohou být i výsledkem, tedy mohou představovat jak doménový model aplikace, tak i dané DTO. Jsou ovšem chvíle, kdy takové DTO je nepoužitelné či jeho použití může znamenat výrazný pokles výkonnosti aplikace.

Prvním příkladem, kde entita nemůže (neměla by) být reprezentována jako DTO:
"Vytvoř seznam zaměstnanců s celkovým počtem odpracovaných hodin."
V takovém případě je třeba výsledek z OQL přemapovat do vlastního objektu (DTO), který bude obsahovat číslo, jméno, příjmení, celkový počet hodin. Sice by někdo mohl namítnout, že daná hodnota (odpracované hodiny) se dá do entity, jako @Transient, přidat. Ale doménový model bych se neměl "špinit" vlastnostmi, které reprezentují pouze výsledek nějakého dotazu.

Druhým příkladem je distribuovaná Java. Jinými slovy řečeno, ve chvíli, kdy vzdáleně volám remote EJB, by výsledkem mělo být pouze to, co skutečně potřebuji. Nikoli anotovaná entita, která obsahuje mapované kolekce a dalších X vlastností, které mě v té chvíli nezajímají. Dodržení této zásady bude mít pozitivní vliv na výkon aplikace.

Důvody, proč je někdy lepší použit DTO namísto entity, jsem uvedl. Nyní ovšem přichází otázka, jak takové DTO přemapovávat z OQL dotazů a jak si co nejvíce ušetřit nudného psaní kódu.

První možností je použití klauzule new z JPA. Takové OQL by mohlo vypadat následovně:
public List getList() {
String oql = "SELECT new ZamPocetHodin(z.cislo, z.prijmeni, z.jmeno, x.vypocetHodin) FROM Zamestnanci z .....";
return entityManager.createQuery(oql).getResultList();
}


Jak je na první pohled patrné, je třeba, aby objekt "ZamPocetHodin" obsahoval konstruktor, který obsahuje dané parametry podle daného OQL.
Tento způsob má vesměs samé nevýhody. Osobně mi asi nejvíce vadí samotná absence jakéhokoli refactoringu. Myslím, že v dnešní době neexistuje IDE, které by dokázalo poznat OQL dotazy a validovat je. Dále mi vadí, že parametrem v konstruktoru DTO může být pouze omezený výčet typů. Není možné vracet jiné Entity, či je nějak dále přemapovat. Poslední věc, která se mi nelíbí, je fakt, že píši zbytečně mnoho kódu. Někde definuji DTO a někde ho musím plnit a přitom stále hlídat, zda se mi něco nezměnilo.

Druhou možností je plnění pomoci Hibernate Criteria API:
criteria.setProjection(Projections.sqlProjection(sql + " AS " + alias,
new String[]{alias},
new org.hibernate.type.Type[] {TypeWrapperImpl.getType(/* type */)}));
criteria.setResultTransformer(Transformers.aliasToBean(ZamPocetHodin.class));


Uvedl jsem jen malý kus kódu, který úplně nedpovídá všednímu použití, ale jde o to, že dost často je hodnota v DTO reprezentována nějakým poddotazem, či jiným způsobem, které SQL umožňuje. Je pravda, že v Hibernate Projections si vše mohu dobře nadefinovat, ale výsledkem je poté naprosto šílený kód, který je sice "dynamičtější" a "programovější" než je tomu u JPA, ale za to je složitější.

Jelikož mi nevyhovuje ani jeden z daných způsobů, snažil jsem se nalézt nějaký vhodný způsob, jak se zbavit toho nudného či složitého psaní na přemapování do DTO.
Po pečlivém rozmýšlení jsem se rozhodl, že by nebylo špatné nahlédnout na danou věc stejně jako v případě mé implementace "Irminsul Criteria". O co vlastně šlo, si můžete přečíst zde a zde.
Cílém mého snažení bylo, abych vytvořil DTO objekt, který pomocí anotací nad atributem bude obsahovat dané SQL příkazy, které naplní příslušnou hodnotu. V této chvíli se jedná stále o testování, ale výsledkem mého snažení je již celkem funkční základní část, tedy jednoduché přemapování.

Nyní uvedu malý příklad takového přemapování:
@DTO(entity = EntitaOdkudSeDataZiskavaji.class)
@Aliases(values={
@Alias(associationPath="strediska.provoz", alias="provoz"),
@Alias(associationPath="rj.testPolozky.polozka", alias="polozka"),
.....
})
public class TestDTO implements Serializable {
@ProjectionSQL("(({polozka}.faktura * {vicePraceMena}.aktualni_kurz) * (procento / 100))")
private BigDecimal opravy;

@ProjectionSQL("(({polozkaZakazky}.cena * {mena}.aktualni_kurz) * (procento / 100))")
private BigDecimal cenaVyrobku;

@Projection("pk.cislo")
private String cislo;

// settry, gettry, atd.
}
List result = factory.findForDTO(TestDTO.class);


Jak je z kódu patrné, jde pouze o klasické POJO, které je anotované, aby implementace pochopila, že jde o DTO, které je spouštěne nad danou entitou (@DTO) a obsahuje ty či ony aliasy, které usnadňuj psaní ProjectionSQL.
K tomuto účelu jsem využil implementace Hibernate Projections a ProjectionsSQL, kde podle jasných pravidel převádím dané anotace na projekci, která je již obeznámena s daným typem a tím, co vlastně daný atribut reprezentuje.

Opěvná píseň

Předem musím poznamenat, že toho dané DTO umí více, jednak je to možnost spojit toto DTO i s Filtr objektem, který jsem popisoval ve výše odkazovaných člancích. Výsledkem je pote jednoduche volání:
List result = factory.findByCriteriaDTO(filtr, TestDTO.class);


Již se tedy nemusím zabývat nutností definování filtru a vrácených dat, oba stavy jsou řízeny anotacemi.

Dalšími možnostmi jsou řazení, získaní hodnoty přes alias, či přes vlastní definici, která může být ve formě SQL či OQL zápisu.

Díky tomu odpadá několik věcí:

  • není třeba definovat nějaké metody v DAO

  • nemusí se psát žadné přemapování, stačí jen definice DTO

  • není třeba hledat, jak se dané DTO plní, je to jasné z jeho definice

  • není třeba se bát refactoringu jako v případě implementace přes JPA

  • není třeba určovat vrácený typ jako v případě Hibernate, typ je již jasný z definice atributu třídy DTO



Až bude daná funčnost plně funkční, nabídnu své řešení ke stažení. Zatím bych nerad někde publikoval zabugovaný nedodělek :)

Zajímal by mě Váš názor na takovouto implementaci DTO. Je dost možné, že někdo přijde s lepším nápadem či možností, která již dávno existuje a jen já o ni nevím :)

neděle 17. února 2008

Seam - tipy a triky

Jelikož jsem zastánce tohoto frameworku, z jichž uvedených důvodů, rozhodl jsem se sepsat pár dobrých triků, které mohou pomoci při vývoji s tímto frameworkem. Dnes začnu asi tou nezajímavější a tím je Hot Deploy, nebo-li rychlá aktualizace některých částí aplikace bez nutnosti provádět celé nahrání aplikace na server.

Hot deploy - NetBeans
Netbeans 6.0 má dost slabou, respektive nulovou, podporu pro tento framework. Jednou z dobrých vlastností Seamu je tzv. hot deploy, kde změny na view vrtvě mohou být aplikovány bez nutnosti provádení undeploy-deploy aplikace. Jedná se zejména o změnu facelets stránek. Takže jak něčeho takového dosáhnout v netbeans?

Stačí vytvořit vlastní "ResourceResolver", který se poté zaregistruje v web.xml.
Příklad takového ResourceResolver:
public class FilesystemResourceResolver implements ResourceResolver {
private static final String PATH_TO_DEVELOPMENT = "/home/ales/dev/java/Irminsul/Irminsul-war/web/";
public URL resolveUrl(String s) {
try {
return new URL("file", "", PATH_TO_DEVELOPMENT + s);
} catch (MalformedURLException e) {
e.printStackTrace();
return null;
}
}
}


Poté již stačí uvést registraci do web.xml:


facelets.DEVELOPMENT
true


facelets.REFRESH_PERIOD
0


facelets.RESOURCE_RESOLVER
irminsulweb.FilesystemResourceResolver



Důležitou součástí je to, aby Seam byl spuštěn v debug módu. Toho lze docílit pomocí definice v components.xml:


Díky vlastní definici "ResourceResolver", jsou nyní jednotlivé facelets stránky načítány z cesty, která je uvedena v "PATH_TO_DEVELOPMENT". Pro změnu stačí v NetBeans editovat nějakou facelets stránku, uložit změnu a ve webovém prohlížeči provést refresh.

Tato malá pomůcka je ideální zejména ve chvíli, kdy jednotlivé facelets stránky obsahují různé komponenty (rich faces, ajax4jsf, atd.). Podle toho, co jsem se dočetl v Seam dokumentaci, tak se pracuje i na možnosti provádět hot deploy nad EJB. Otázkou je, jestli tato vlastnost není spíš více ovlivněna aplikačním serverem, než tímto frameworkem.
Takový hot deploy nad EJB se dá sice také provést (v debug modu pro AS), ale jedná se o velice omezené možnosti. Není možné vytvořit novou EJB za běhu, zmenu public metod, atd. Jde tedy čistě o vnitřní implementaci uvnitř business metod. Doufám, že se jednou dočkáme změn i v této oblasti.

sobota 12. ledna 2008

Linux pro javistu

Na svých oblíbených weblozích jsem našel několik příspěvků, které se věnovali linuxu, coby hlavnímu operačnímu systému pro programátora. Psal o tom dagi či ronnie. Jeden je v navážkách, druhý utekl zpět k windows.

Abych nebyl výjimkou, rozhodl jsem se, že ho teda také vyzkouším. Linux jako systém považuji za velice úspěšný na serveru, co se týče osobního desktopu, vždy jsem našel něco, co mě přinutilo vrátit se k windows. Dnes již tomu tak není a já se pokusím sepsat vše, co mě monentálně k tomuto tématu napadá.

Proč práve linux?
Není v tom nic speciálního. Na serveru nám běží bez problémů a já si chtěl vyzkoušet, zda by můj notebook nebyl s tímto systémem "rychlejší" a "efektivnější". Nehledám v tom nic převratného, a ani nechci zkoušet něco, abych jen vybočoval z "řady windowsáků".
Linux tedy zkouším čistě ze zvědavosti s nadějí, že objevím něco "užitečného".

Výběr distribuce a HW
Výběr distribucí linuxu je ohromný. Má volba padla na SuSE, jednak s touto distribucí mám trochu zkušenností a jednak ji mám instalovanou i na domácím PC, který funguje jako server.
Samozřejmě, že v "módě" je dnes Ubuntu, ale abych byl upřímný, samotná komunita, alespoň v ČR, mi tak leze na nervy, že jsem zde zaujal šovinistické stanovisko :)
Distribucí je tedy SuSE 10.3 s GNOME.
Co se týče hardwaru, instaloval jsem jej na notebook Toshiba A100-847. Jedná se o 2 jádrový Core 2 Duo, kde jsem pouze rozšířil RAM z 512MB na 2GB.

Instalace
Po rozdělení disku jsem na menší oddíl (cca asi 36GB) nainstaloval SuSE. Samotná instalace proběhla v pořádku a já si mnul ruce, jak vše dopadlo hladce. Jenže, to byl nebyl linux, aby v něm nebyl zádrhel... :)

První setkání
Při prvním pohledu se zdálo, že je vše v pořádku. Bohužel mi nefungovala WiFi a připojení druhého LCD monitoru. Po jistém vyladění ostatních věcí se mi asi po 6 hodinách povedlo rozchodit bezdrátové připojení. Bohužel u monitoru jsem nepochodil. Ani ruční konfigurace xorg.conf nepomohla a já prozatím musel monitor nahradit dalšími plochami.
Při zpětném porovnání mohu tvrdit, že kromě připojení druhého LCD je vše funkční. Samozřejmě se nevzdávám a až bude více času, pokusím se dořešit i to. Většinou vše má své řešení :)

Práce
Jelikož nepobírám mzdu za hraní si s linuxem, ale za vývoj aplikací, tak jsem se pustil do konečného nastavení. Tedy instalace JDK 1.6, Netbeans a Glassfish.
A zde to přišlo. Důvod, proč mě k windows již nikdo nedostane!
Samotný běh NetBeans je rychlejší, super. Ale co je naprosto nepochopitelné, že build&deploy projektu, který ve windows (se stejným nastavením) trvá minutu - minutu a půl, zde trvá asi 14-16 vteřin. Nevěřil jsem vlastním očím. Říkám si, asi bude někde problém v nastavení na windows. Nikoli. I samotný build projektů je prostě rychlejší a to výrazně. Sice jsem neprováděl žádné měření, ale poznal jsem na vlastní kůži, jak je to s rychlostí.

Alternativy k programům
Zde jsem nemusel nic moc řešit. Za prvé používám Javu, která je multiplatformní a za druhé programy, které jsou i pro linux. Zde jsem udělal jejich částečný výčet:

  • thunderbird - thunderbird

  • opera - opera

  • netbeans - netbeans

  • pidgin - pidgin

  • total commander - midnight commander, gnome commander, muCommander

  • launchy - deskbar applet

  • putty - ssh


Nic víc ke své práci nepotřebuji. Jediný problém je s tím Total Commanderem. Skutečná alternativa neexistuje. Jediné, co mě čeká je, najít si nejpříjemnější alternativu, kterou zatím nemám.



Závěr
Pokud se nevyskytne skutečný problém, tak mě asi od linuxu již nic neodtáhne. Nemíním tvrdit, že windows je špatný, pouze nevyhovující pro určité typy lidí. Stejné je to i naopak. Ve chvíli, kdy jsem si nakonfiguroval klávesové zkratky, přidal přepínání ploch, zjistil jsem, že jsem shopen i efektivněji pracovat. Windows se spíše drží filozofie myš-akce, já mám raději klávesnici, protože je mnohonásobně rychlejší.
Nakonec nabízím pár screenshotů z mého nového systému:









obrazovka-small.pngobrazovka-small.png
obrazovka-small.pngobrazovka-small.png

obrazovka-3-small.png

obrazovka-3.png

obrazovka-2-small.png

obrazovka-2.png

obrazovka-1-small.png

obrazovka-1.png

obrazovka-small.png

obrazovka.png