finc weblog

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? :)

Rozhodl jsem se sepsat pár poznatků, které jsem při studiu Javy zatím získal. Jelikož z mého postoje je jasné, že PHP se pro mě stalo spíše zlem, hledal jsem jiný směr programování a oblíbil si právě zmiňovanou Javu. Důvody proč, jsem psal minule, dnes se spíše zaměřím na samotnou Javu a PHP nechám již pomalu odumírat :)

Vezmu to od začátku, jak se PHPčkář může postupně dostat k pochopení platformy jako je Java, aniž by trávil měsíce bádáním či vyhazoval tisíce za různá školení.

Prvním předpokladem k úspěšnému začátku je znalost OOP programování. Není zrovna snadná věc, přejít z procedurálního vývoje na objektový a přitom změnit jak logiku myšlení, tak pozměnit způsob programování. Zde osobně doporučuji podívat se právě na Javu či jiné čisté OOP jazyky jako C++ či C#. Jistě se Vám lépe bude učit na něčem, co je v oblasti OOP vývoje osvědčené. Všechny získané znalosti jdou víceméně použít i v PHP, takže se vývojář nemusí obávat, že bude muset ukončit vývoj v PHP. Já osobně volil knížku od Rudolfa Pecinovského: myslíme objektově v jazyku Java 5.0. Musím přiznat, že jsem zejména pochytil dobré návyky při návrhu tříd a pochopil oč v oblasti OOP vůbec jde. Tyto znalosti jdou pak aplikovat ve větší míře i na PHP (samozřejmě, že např. polymorfismu si v PHP moc neužijeme :)).

Druhým krokem je praxe v OOP a tvorba tříd podle design patterns „návrhové vzory“, což jsou doporučení, které by měl programátor znát a pokud je to jen možné, držet se jich. Díky design patterns jsem mohl skutečně efektivně aplikovat OOP do praxe.

Tyto dva kroky mi zabrali 1 rok. Někomu se může zdát taková doba přehnaně dlouhá, avšak, pracující člověk, od kterého se očekávají výsledky, si nemůže dovolit jen tak trávit celé dny učením. Navíc ta praxe je zde dost důležitá a osobně si myslím, že během jednoho či dvou měsíců, by si dobré návyky v oblasti OOP vývoje, mohl osvojit jen génius.

Pak jsem přešel k něčemu složitějšímu a to byla knížka Java programujeme profesionálně od Bretta Spella. Kniha má přibližně 1000 stran a je to publikace určená vývojářům swingových aplikací. Samozřejmě, se swingem v Javě si hrál každý a tak i já jsem si hrál se základními komponenty jako jTable, jTree, apod. Samotné nasazení je pro mě však nemyslitelné, protože umět programovat front-end aplikace, ještě neznačí úspěch.

Přesměroval jsem se tedy zpět na web development. Zde je situace dost drsná, názvy frameworků, různá řešení, apod. jsou jen dobrým základem, jak si v této oblasti udělat v hlavě guláš :)

Po vyzkoušení různých tutoriálů na netbeans.org (vytvoření CRUD aplikace a základní tutoriály na JPA či JSF) jsem hledal něco obsáhlejšího. Naštěstí se na internetu dá nalézt spoustu knih ve formátu PDF, které stojí za to, si přečíst. Zde bych jen upozornil na skutečnost, že v češtině si toho moc nepřečtete.

Takže jsem začal s PDFkama…

Takže první věc, kterou je dobré vědět, je, že web development má několik částí. Nejsou to jen JSP stránky, ale také servlety či další objekty, které mají tu či onu vlastnost. Než začít psát čisté JSP-servlety, všude jsem se dočetl o doporučení, použít nějaký ten framework, používající MVC pattern. O tom, co je MVC jsem už něco věděl, ale co se týče výčtu frameworků (Struts, JSF, Seam, Spring, Struts 2, Tapestry, atd. atd.), nevěděl jsem po čem sáhnout. Nakonec jsem si vybral JSF, opět na doporučení. Jedná se komponentově orientovaný framework a na rozdíl od Tapestry je vyvíjen přímo Sunem, což mu dodává určitou standardizaci.

JSF má vlastní tagy, pomocí kterých lze definovat JSP stránku. Tyto tagy mají spoustu vlastností a je možné libovolně vytvářet nové a nové. Hodnoty či atributy těchto tagů se definují backend beany. Jsou to třídy, které mají definované atributy třídy a k nim setry a getry. Kromě těchto základních atributů existuje ještě možnost definovat metody s parametry ActionEvent, které pracují na základě uživatelských akcí. Celá problematika je samozřejmě mnohem rozsáhlejší. Existuje zde vlastnost jako je navigation, která určuje navigaci stránek podle aktuálního stavu modelu, apod. celá tato problematika je krásně popsaná v knize JSF in Action, u které jsem vlastně nyní i já (cca. 150 stránka z 1076 :)).

Uvidíme, kam se moje znalosti dostanou, zatím kromě pár tutoriálů a vlastních zkoušek s JPA či JSF, jsem získal nadhled nad základním rozdělením webového vývoje v Javě.

Tímto článkem jsem chtěl jen ukázat to, že zkoušení nových věci by se neměl bát nikdo, kdo to s programováním myslí vážně. Tento obor je dost progresivní a tak se musíme chovat i my vývojáři. Spoustu lidí dělá chyby, ale tou nejzásadnější je, zkoprnět a přestat se snažit získávat nové znalosti.