finc weblog

Když jsem poprvé začal používat plnohodnotné IDE, nejvíce jsem si zamiloval NetBeans. Důvodem bylo zejména to, že pro začátečníka byl tento nástroj asi nejsnáze pochopitelný. Postupem času si člověk vytvoří určité návyky a jen težko je schopen přejít na jiné prostředí.

NetBeans jsem používal posledních 5 let. Což už je dost dlouhá doba na to, abych věděl co od tohoto nástroje můžu očekávat. Nicméně v poslední době se mi zdá, že více než na práci se vývoj tohoto nástroje soustředí na to, jak vytvořit demo aplikaci. Ta je poté slavnostně prezentována ve formě videotutoriálu na stránkách netbeans.org. Ovšem při práci na větším projektu se často dostávám do potíží se samotnou stabilitou tohoto prostředí. Proto jsem se rozhodl vyzkoušet IntelliJ IDEu, kterou všichni její  uživatelé tak slavně opěvují.

Při prvním spuštění je jasné, že i když oba nástroje použiji na tu stejnou věc (programování Java, PHP), tak přesto jsou dost rozdílné, abych hned věděl kde začít.

Projekty a moduly

První velký zádrhel je mezi porovnání projektů a modulů. v NetBeans vytvořím nový projekt a rovnou můžu pracovat. Onen projekt můžu například zabalit do EAR projektu a přidávat další a další. IDEA na to jde jinak. Projektem je zde spíše něco jako skupina, do které vlkádám dané projekty (ehm, tedy moduly). Modulem je tedy onen projekt a projekt je spíše celé okno IntelliJ IDEy. Trošku zmatek, nicméně se mi podařilo tímto prokousat a pochopit logiku tohoto nástroje. :)

PHP Projekt (nebo modul?)

Projekty a moduly pro Javu jsem vcelku pochopil. Horší je to ovšem s PHP. IntelliJ IDEA má slušnou podporu PHP a proto jsem chtěl vyzkoušet i tu. Problém ovšem je, že neexistuje nabídka jak vytvořit čistě PHP modul. Jediný způsob je vytvořit „projekt ze zdroje“ a poté do něj java modul bez vytvoření src adresáře. Tento způsob je přímo popisovaný i v nápovědě tohoto nástroje. Asi nemá příliš cenu komentovat, proč tento způsob vývojáři trošku neupraví. Nicméně, chceš-li pracovat s PHP, vytvoř Java Modul :)

Přenos projektu z NetBeans do IntelliJ IDEy

Po menším prozkoumání tohoto nástroje jsem hledal způsob, jak rozumně převést projekt z NetBeans do IDEy. Jelikož jsem v NetBeans projekt sestavoval pomocí Antu (ano, vím, že už to není moderní :)) nenašel jsem jednoduchý způsob, jak projekt převést. Nezbývalo tedy nic jiného, než použít Maven. Po dvoudenním trápení se mi podařilo sestavovat celý projekt pomocí Mavenu. Kromě toho, že jsem toto měl provést již dávno, tak přenos projektu byl více než snadný. Nyní stačilo otevřít IntelliJ IDEu a pouze projekt „otevřít“. Vše začalo fungovat bez problémů.

Nevýhody IDEy

Nemá smysl psát o výhodách tohoto nástroje. Je totiž vážně slušně propracován a navíc splňuje téměř vše, co ke své práci potřebuji. Ovšem i přesto existují určité věci, které stále nejsem schopen překousnout a nutí mě přemýšlet, zda mám tento nástroj skutečně koupit a začít používat.

Logování Glassfish

Při deploy (debugování) aplikace na Glassfish je problém s tím, že nefunguje zobrazování logování v okně. Toto bylo u NetBeans skutečně na mnohem lepší úrovni. Nakonec jsem zjistil, že i když je v nastavení tohoto aplikačního serveru nastavena log console, musím přidat vlastní. Poté základní logování funguje. Ovšem pouze do doby, než se provede „rotate“ log, tedy provede se záloha log souboru a vytvoří se nový glassfish log soubor. IDEA ovšem není schopná pokračovat ve výpisu tohoto logu z čistého souboru.

Podpora Mavenu

NetBeans má podporu Mavenu na lepší úrovni. U knihoven je přímo vidět zda se jedná o závislost na jiné, v jaké je „scope“, atd. Toto jsem u IDEy opět nenašel v rozumné formě.

Závěrem

Je zde spousta dalších drobností, které potřebuji vyřešit, ale ty považuji spíše za „porodní bolesti“ (jako například rozumné formátování kódu, jelikož přes Ctrl+Alt+L se mi formátování provede jen „někdy“). Nicméně dost reálně uvažuji o koupi tohoto IDE. Přeci jen, cena za nástroj, který používám více jak 8 hodin denně je zanedbatelná vůči produktivitě, kterou mi může přinést.

V poslední době se dost rozrůstá názor, že aplikace by měly být psány tak, aby byly co nejvíce nezávislé na použitém DBMS. Osobně tento názor zastávám i já.

• aplikace se může natolik rozsrůst, že stávající DBMS může být nevyhovující
• vývoj v oblasti databází jde stále vpřed a s tím souvisí i změny v SQL jazyku
• samotný model struktury dat by měl být definován v aplikaci, kde by měl být odstíněn od nějakého SQL
• zdroje mohou být různé (databáze, soubory, vzdálená volání, …)
• aplikace může být vyvíjena bez použití databáze, která může přijít v pozdější fázi

Jak už to tak bývá, tak úspěch projektu je závislý od prvotní analýzy. Nechtějme tedy vše řešit hned od počátku. Jistě je bezpečnější si nechat otevřená zadní vrátka pro dané změny, které by mohly mít fatální následky.

Kompromis

Bohužel, nežijeme v ideálním světě, kde by vše bylo nalinkované tak, jak bychom si přáli. Uvedu jeden příklad, který mě přesvědčil o tom, že vytvořit aplikaci, která by byla skutečně nezávislá na DBMS je nemožné. Pro načítání dat z jiných zdrojů, jsem použil Timer metody z EJB3, které mají tu vlastnost, že jsem schopný vytvořit si vlastní plánování plnění. Na persistenci jsem použil JPA. Když jsem zjistil, že JPA má možnost přiřadit listener na danou entitu, hned jsem si tuto vlastnost spojil s tím, že nebudu muset psát žádné triggery a hezky půjdu touto cestou.
To jsem si ovšem neuvědomil, že při dávkovém zpracování je JPA a EntityManager natolik náročný způsob, že jsem byl nucen přejít na nízkoúrovňové JDBC. Výhodou samozřejmě bylo extrémní zrychlení, ale nevýhodou, že daný Listener je v podstatě k ničemu. Ve finále jsem byl nucen napsat trigger a tím utnout možnost, že aplikační logika se postará o vše potřebné.

Vše není tak černé

I když jsem opustil snadnou přenostitelnost, stále mi zůstává možnost psát tu aplikaci tak, aby byl doménový model to hlavní a já byl co nejvíce odstíněn od DBMS. Přece jen, toho dávkového spracování zase není tolik, aby se to nedalo kdykoli změnit.
Používám 2 základní zdroje: MySQL a Oracle. Při klasickém přístupu jsou si obě databáze velice podobné. Je zde ovšem několik rozdílů, které jsou dost zásadní. Opět uvedu příklad, který toto vystihuje: Chci nějaký základní reportovací nástroj, který bude pracovat tak, že uživatel napíše SQL dotaz, systém ho zpracuje a vrátí tabulku. Tabulku, která bude obsahovat možnost stránkování. A zde je ten problém, stránkování. U MySQL bych šel klasicky, přes: SELECT … LIMIT x,y. Bohužel Oracle nic takového jako LIMIT nemá. Co teď? Parsovat SQL dotaz podle použitého DBMS? Ano. Ale s tím, že někdo něco takového již napsal. Samotný EntityManager obsahuje metody „setMaxResults(int arg)“ a „setFirstResult(int arg)“. Takže o jednu starost méně :)

Občas mi to přijde jako věčný boj. Každý druhý (v PHP) si píše vlastní databázové layery, tvrdí jak vše funguje, ale jen do doby, než přijde první požadavek, který nebyl očekáván podle specifikace používaného frameworku.

Doufám, že jednou bude svět natolik ideální, že skutečná nezávislost bude brána jako stadard pro psaní aplikací pro DBMS.

Jako každý správný programátor jsem i já velice líný člověk. Ano, přehnanou pílí z Vás programátor nikdy nebude. Důvodem není to, že by programování byla jednoduchá věc, kterou se stačí naučit a pak jen aplikovat, ale proto, že hledáte stále lepší a lepší řešení, které by Vám usnadnilo další vývoj.

Když to převedu do praxe:
Představte si, že vedle sebe posadíte 10 lidí (kteří mají základní znalosti s prací na PC) a dáte jim za úkol napsat v Excelu čísla od 1 do 30. První skupina lidí si sedne a začne psát čísla od 1 do 30. Možná budou i rychlejší, jelikož nemusí nad ničím přemýšlet. Druhá skupina lidí si řekne, že je to moc práce a začne hledat způsob, jak si práci usnadnit. I když zadaný úkol nestihnou v časovém limitu, budou jistě produktivnější. Jen si představte, že byste po těch pracovitých lidech chtěli, aby Vám napsali čísla od 5 do 1000. Kdo myslíte, že poté zvítězí? :)

Tímto příkladem jsem chtěl jen nastínit, že programování není o velké dřině, ale o neustálém přemýšlení nad tím, jak si svou práci co nejvíce usnadnit a zároveň přizpůsobit natolik, abych při nějaké změně nemusel brečet u šéfa, že je to strááášně složité a v podstatě nemožné :)

Vrátím se ale zpět k tématu tohoto článku. Proč jsem vlastně tak moc nadšený z Javy?

Důvod jsem již popsal, jsem líný člověk a nechci svůj mozek vyčerpávat věcmi, které jsou jednoúčelové. Stále porovnávám Javu s PHP. Vím, že porovnávat tyto dvě odlišné technologie je nesmysl, ale toto srovnání dělám na základě vlastních zkušeností a snažím se porovnat jejich použitelnost pro mou práci.

Po získání základních znalostí o objektech jsem měl v PHP problém je nějakým způsobem aplikovat do praxe. Základní API je celé procedurální a v rozjetém projektu jsem nebyl schopen nasadit žádný PHP framework, který by mi mohl mou práci usnadnit. Vydal jsem se vlastní cestou a napsal si svůj vlastní framework na ORM, DAO, Models, Views. Sice nic extra, ale pro mé účely postačující. Jenže… Co dál můžu v PHP chtít dělat, když jsem vázaný na webový kontejner Apache httpd, který musí být navíc natolik odlišně nakonfigurovaný, že se z aplikace stějně stal nepřenositelný moloch. Navíc další využití v menších projektech bylo téměř nulové. Práce s daty také žádný šlágr. Stálé psaní toho samého. Ani IDE (Eclipse a PDT) neposkytuje takový komfort jako v jiných jazycích.

Objekty jsem se hned od začátku učil na Javě, takže jsem věděl, že je to jazyk, který se drží nějakých zásad a má striktní typovou kontrolu, která mě drží na správné cestě a nevede do slepých uliček. Osobně jsem se ale do vývoje v Javě bál více pustit, protože přece jen nejsem žádný guru v oblasti objektů a programováním se zabývám tak 3 roky. Jenže teď jsem v práci dostal za úkol udělat aplikaci na tištění nějakých kartiček, která by běžela pouze na jednom PC a nebyla přes http.

Tak jsem se teď více vrátil k Javě a dělám Swing aplikaci, kterou mám z větší části hotovou. Když jsem zjistil, že mohu použít JPA i ve standalone aplikaci, byl jsem nadšený. Vím, že pak mohu vzít část tohoto projektu a rozjet ho jako webovou aplikaci. Mohl bych toto udělat v PHP? Asi ano, ale dělat v PHP pod GTK by byla jistě dobrá onanie.

I když nejsem žádný přeborník v Jave a většinu věcí zatím dohledávám po netu či píšu na konferenci na java.cz (za odpovědi ještě jednou děkuji), tak jsem schopen všechny překážky přeskočit (ovládání swing aplikace přes události, tisk, napojení na MySQL, atd. atd.), což mě vede k závěru, že už mi chybí jen zkušenosti, abych byl více produktivní v tomto jazyce.

Nadšený jsem zejména z věcí jako je Java Persistence API, díky čemuž objektově namapuji relační databázi a pak již pracuji s objekty a všemi základními vlastnostmi jako je dědičnost či polymorfismus. Navíc nemusím nic definovat v XML, ale hezky si tvořím anotace. Další věcí budiž Swing pro desktop, který je pomocí NetBeans tak snadno naklikatelný, že se jedná spíše o malý Photoshop :). JSF framework pro web. aplikaci mi zejména po použití navigátoru a různých vlastních komponent přišel jako geniální nástroj pro web. Také celé API Javy je natolik rozsáhlé, že snad všechno je v něm již implementované. Samotné standardní frameworky od Sunu jsou na tolik dobré úrovni, že zatím nepotřebuji nic jiného.

Co se týče vlastních zdrojů, musím zde ještě jednou zmínit portál java.cz a jeho emailovou konferenci. Jsem rád, že jsou zde inteligentní lidé a neřeší se zde věci typu: jak vypsat hello world. Dalším dobrým zdrojem jsou přednášky o Javě, které lze nalézt na http://avc.sh.cvut.cz. Než je člověk schopný začít číst z manuálu, také doporučuji tutoriály na netbeans.org. Ukázkové příklady lze nalézt na http://www.exampledepot.com/egs/index.html.

Zdrojů je vážně spousta, člověk musí jen hledat :)

Dobrým zdrojem informací jsou samozřejmě také knihy. Osobně jich o Javě vlastním pět. Ale o těch zase někdy příště. Tak co? Už jste dopsali čísla od 5 do 1000? :)