pondělí 19. března 2007

PHP & Java: SHA-1

Při vývoji javovské aplikace jsem narazil na problém autentifikace uživatelů. Problém spočíval v tom, že mám tabulku uživatelů, která obsahuje hash hesla, který je hashován pomocí PHP.

echo sha1(sha1("heslo"));


Čekal jsem, že v Java API naleznu podobnou metodu na hash Stringu, bohužel jsem hledal marně :)

Jelikož jsem si nevěděl rady, poprosil jsem na konferenci na java.cz o malou pomoc. Po odpovědi obsahující link, na tvorbu hashe ze Stringu, jsem moc moudrý nebyl :(
Potom jsem dostal ovšem odpověď v podobě třídy, kterou jsem nakonec po své úpravě byl schopen aplikovat.

package org.dostal.dochazka.crypt;

import java.security.MessageDigest;
/**
* Statické metody pro výpočet hash
*
* @author Ales Dostal;
*/
public class HashUtil {

public static final String HASH_TYPE = "SHA-1";

/**
* konstruktor
*/
private HashUtil() {}

/**
* vypocita SHA-1 hashovaci klic z byte[] a vrati jej jako HEXa retezec
*
* @param pass heslo ve String
* @return HEXa řetězec
*/
public static String SHA1AsString(String pass) {
return SHA1AsString(pass.getBytes());
}

/**
* vypocita SHA-1 hashovaci klic z byte[] a vrati jej jako HEXa retezec
*
* @param pass heslo v byte[]
* @return HEXa retezec
*/
public static String SHA1AsString(byte[] pass) {
return hex(SHA1(pass));
}

/**
* vypocita SHA-1 hashovaci klic z char[] a vrati jej jako HEXa retezec
*
* @param pass heslo v char[]
* @return HEXa retezec
*/
public static String SHA1AsString(char[] pass) {
return SHA1AsString(String.valueOf(pass));
}

/**
* Vypočte SHA-1 hashovací klíč z řetězce
*
* @param secret pomocný klíč
* @return pole bytů
*/
private static byte[] SHA1(byte[] pass) {
byte[] mac = new byte[20];
try {
MessageDigest sha = MessageDigest.getInstance(HASH_TYPE);
sha.update(pass);
mac = sha.digest();
} catch (Exception e) {
e.printStackTrace();
}
return mac;
}

/**
* Převede pole bytů na HEXa řetězec.
*
* @param data pole bytů
*/
private static String hex(byte[] data) {
StringBuilder sb = new StringBuilder();
for (byte b : data) {
sb.append(Character.forDigit((b & 240) >> 4, 16));
sb.append(Character.forDigit((b & 15), 16));
}
return sb.toString();
}

}


Nyní jsem schopen přistupovat k porovnání hashe jak z PHP, tak z Javy. Sice je to taková maličkost, ale občas dost důležitá :)

echo sha1("heslo");

System.out.println(HashUtil.SHA1AsString("heslo"));

úterý 6. března 2007

OOP v PHP 5 - teorie dědičnosti a ORM

Když se vrátím na začátek, kde jsem tvrdil, že objekty jsou jakýsi obal nad procedurálním kódem, tak se musím zamyslet nad tím, jak umožnit, abych nemusel stále dokola zabalovat jednu a tu samou věc. Třídy bych měl vždy navrhovat tak, aby obsahovali jen to nejnutnější a nebyly zbytečně vázany na jiné třídy. Navíc třídy by něměli obsahovat pevnou vazbu na třídy, které jsou navrženy v jiných úrovních.

Příklad:
Do třídy pro zobrazení stromové struktury nebudu cpát třídu, která mi vrací data stromu. Raději ve třídě stromu napíši metodu, která bude umět přijmout data a zobrazit je. Na získání dat vytvořím jinou třídu.
Když budu později potřebovat zobrazit strom s jinými daty, prostě použiji již hotovou třídu stromu, která přijímá data.


Tím dokážu vytvořit znovupoužitelný kód. K tomu, abych mohl takto tvořit třídy, ale musím znát všechny možnosti objektů. Nyní se vratím k další možnosti objektů a tou je dědičnost.

Dědičnost je vlastnost, která mi umožňuje rozšířit třídu a pozměnit její chování. Nic víc, nic míň.

Na začátku jsem napsal, že třídy by měli být co nejořezanější, neměli by obsahovat věci, které by ji svázali natolik, že by obsahovala zbytečné a nevyužitelné vazby. Pokud ovšem v projektu potřebuji danou třídu rozšířít a to tak, že dané rozšíření budu využívat vícekrát, prostě napíši si novou vlastní třídu, která bude dědit vlastnosti z minulé třídy.

Příklad:
Mám třídu na zobrazování filtrace nad daty. Teď je ovšem problém, že v některých případech filtruji přes ty samé položky (př. název). Jednou možností je, pořád do objektu posílat objekt (komponentu) název. Jelikož už vím, co je dědičnost, mohu ji využít. Vytvořím novou třídu, která bude dědit třídu filtrace a navíc bude automaticky vkládat komponentu pro název.


Toto je jedna z možností jak dědičnost využít, přiznávám, že ne moc efektivní, jistě existují i jiné možnosti, ale jako příklad je to postačující.

Asi lepším příkladem je struktura dat v databázi. Dnes jsou nejrozšířenejší relační typy databází. Jistě jsou velmi efektivní, rychlé a snadné na práci, ale pro nás jsou dost nevyhovující, proto existuje ORM (objektově relační mapování), což není nic jiného, než, že tabulku v databázi převedeme na objekt.

CREATE TABLE zamestnanec (
cislo int NOT NULL,
jmeno varchar(100) NOT NULL,
prijmeni varchar(100) NOT NULL,
PRIMARY KEY(cislo)
);



class Zamestnanec {
private $cislo;
private $jmeno;
private $prijmeni;
/* + setry a getry ke vsem atributum */
}


Nyní vytvoříme tabulku "uzivatele". U uživatelů budeme potřebovat navíc heslo, počet přihlášení, poslední přihlášení. V databázi tedy vytvoříme tabulku "uzivatele", která bude mít primární klíč osobní číslo, které bude zároveň cizím klíčem s vazbou do tabulky zaměstnanců na osobní číslo.

Potom pro výpis uživatelů použijeme něco takového:
SELECT u.*, z.jmeno, z.prijmeni
FROM uzivatele u
INNER JOIN zamestnanci z ON u.cislo = z.cislo


To je v pořádku, databázi máme, ale jak to uděláme v našem projektu, kde máme objekty? Velice jednoduše, použijeme dědičnost.

class Uzivatel extends Zamestnanec {
private $heslo;
private $pocetPrihlaseni;
private $posledniPrihlaseni;
/* setry a getry */
}


Nyní jsem vlastně rozšířil zamestnance o další atributy aniž bych musel znovu psát jeho vlastnosti (např. v Jave na toto existují tzv. entity classes, u nich by bylo toto rozdělení více podobné struktuře DB, což v PHP zařídit jen tak nepůjde). Dědičnost se definuje tak, že mám jednoho předka, který obsahuje vlastnosti, které se mi budou hodit i ve třídě, která je dědí. Pokud by se mi stalo to, že budu dědit z třídy, která obsahuje vlastnosti, které nebudu nikdy potřebovat, je dědičnost navržena špatně.

Tento článek berte spíše s nadhledem, opravdu se domnívám, že dědičnost je tak záludná záležitost, že bych se na ni na začátku úplně vykašlal. V pozdějších článcích se k tomto tématu vrátím a ukážu, jak něco takového využít v praxi. Příklady, které jsem zde uvedl nejsou úplně nejtypičtější, ale jistě lepší, než ukázky typu: Matka => Dcera, které postrádají použitelnost v praxi.

Příště už o něčem jednoduchém, viditelnosti a klíčových slovech static, final, apod.

neděle 4. března 2007

Proč jsem tolik nadšený z Javy?

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

pondělí 12. února 2007

OOP v PHP 3 - interface

Interface (rozhranní) je jedna z věcí, která je často přeceňována nebo nedoceňována. Oč vlastně jde?

Představte si, že se dostanete do situace, kdy budete potřebovat určit, že objekt "umí" něco, co se od něj očekává, ale nejsme si jistí, zda to tak je :)

Uvedu příklad:
Mám objekty manželka, děti, papoušek, pes a tchýně. Všechny objekty mohu považovat za součást rodiny. Problém nastává ve chvíli, kdy bych potřeboval vědět, kdo z uvedených rodinných příslušníků umí vařit. Vaření si mohu představit jako metodu, která mi provede danný úkon a vytvoří (vrátí) objekt jídlo.

Toto je klasický příklad, kdy mohu použít (implementovat) interface. Nejdříve si vytvořím vlastní interface, které bude obsahovat metodu uvarJidlo().

interface UmiVarit
{
public function uvarJidlo(Jidlo $jidlo);
{
?>


Nyní mám rozhranní, které je potřeba implementovat na ty třídy, které budou moci vařit jídlo.

class Manzelka implements UmiVarit
{
public function uvarJidlo(Jidlo $jidlo)
{
return "manzelka uvarila: ". $jidlo->getNazev();
}
}?>


Takže nyní, když zavolám objekt (rodinného příslušníka), jsem schopen určit, který z nich vařit umí a který nikoli.

$rodina[] = new Manzelka();
$rodina[] = new Tchyne();
$rodina[] = new Pes();
foreach($rodina as $val) {
if($val instanceof UmiVarit) {
echo "umi varit: ". $val->uvarJidlo(new ChlebaVeVajicku());
}
}
?>


Interface můžete chápat jako svou vlastní kontrolu, kde si programátor označuje jednotlivé třídy podle toho, co mají umět. Myslím si, že úplnému pochopení, k čemu vlastně interface mohu využít a jak použít je otázkou praxe. Jak se říká: nic se nemá přehánět. A to platí i zde. Na druhou stranu, ignorace implementování rozhranní vede k chaosu a nižší funkčnosti.

Co se týče pravidel, jsou zde jasně danná specifika:

  • interface může obsahovat konstanty a veřejné metody

  • třída implementující interface musí obsahovat metody podle interface

  • třída může implementovat více rozhranní, které se oddělují čárkou (např. UmiVarit, PrepinaTelevizi)



Samotné PHP obsahuje několik předdefinovaných rozhranní, z nichž nejzajímavější je Iterator.

Tak by bylo k interface vše. Samozřejmě, dalo by se zde napsat spoustu dalších možností a využití, ale stačí, když si budu pamatovat, že Interface usnadňuje a označuje třídy tak, abych byl schopen použít jejich specifické vlastnosti.

Příště již ke zmíněným abstraktním třídám a dědičnosti, která je asi tím nejsložitějším tématem v OOP vůbec.

úterý 30. ledna 2007

OOP v PHP 2 - základy

Minule jsem ukázal základní vlastnosti OO kódu. Dnes se pustím do bližší specifikace, základů psaní OO kódu.

Na začátku je dobré brát v potaz, že OO kód by měl být samodokumentovatelný. To znamená, že kód je srozumitelný nejen pro počítač, ale také pro člověka. Pokud budu vycházet z tohoto základu, tak mi z toho vychází, že budu muset dodržovat základní principy při psaní OO kódu.

Začnu pěkne od začátku:

Třídy:

Název třídy se vždy uvádí velkým písmenem.
Název třídy je podstatné jméno, nikoli sloveso.
Pokud název třídy obsahuje více slov, používá se tzv. VelbloudiNotace.

Další důležitou roli hraje samotný název, který by neměl kolidovat s jiným názvem třídy. Ve skutečných OO jazycích je toto řešeno pomocí např. balíčků (packages) v Javě. Samotný balíček má i další vlastnosti, ale nám by stačilo, kdyby v PHP existoval alespoň v základní úrovni. Uvedu název balíčku, do kterého danná třída spadá a když budu potřebovat někde vytvořit objekt z této třídy, uvedu název třídy i s balíčkem. Název balíčku vlastně odpovídá adresářové struktuře, kde je má třída uložena (např. org.dostal.Zamestnanci by bylo v adresáři /org/dostal/Zamestnanci.class). Krásné, že?

Bohužel PHP nic takového nemá. Proto je třeba volit jiný postup. Budeme vycházet z toho, že třídy vkládáme do vlastní adresářové struktury a tuto strukturu odvodíme pomocí názvu třídy. Jako oddělovač jsem zvolil "_", což asi nejlépe odpovídá tomu, jak identifikovat strukturu, kde mám třídu uloženou.

Příklad:
Vytvořím adresar "Model", do něj vytvořím adresář "Table". Poté vytvořím soubor s názvem "Filtr.php". Nakonec do souboru vytvořím třídu "class Model_Table_Filtr {}". Díky tomu jsem schopný identifikovat, kde třída "Filtr" vlastně leží.

Další zásadou je, že jeden soubor = jedna třída. Nemá smysl o tomto polemizovat, je to způso, který se osvědčil nejenom v PHP.

Atributy tříd:

Atributy tříd by měly být vždy zapouzdřené, jinak řečeno, zvenku by k nim měl existovat pouze přístup přes setry a getry.
Atribut třídy začíná malým písmenem a pokračuje opět velbloudí notací.
Toto do začátku stačí.

Metody:

Název metody začíná vždy malým písmenem.
Opět se využívá velbloudí notace.
Název metody by mělo být sloveso (např. filtruj, zobraz, atd.), samozřejme to neplatí vždy.
Metody začínající na set... jsou setry, nastavující nějakou hodnotu.
Metody začínající na get... jsou getry, vracející nějakou hodnotu.
Metody začínající na add... přidávají k nějaké hodnotě, další hodnotu.
Metody načínající na is.. jsou kontrolní a vracejí Boolean (true, false) hodnotu.
Metoda toString() vrací informaci o třídě.
Existují další metody, tzv. magické metody začínající dvěma podržítkama, které proberu později.
Jsou i jiné specifika, které teď nemá cenu rozebírat, pro začátek toto stačí.

I když jsou tyto informace dost nudné, jsou velice důležité pro další vývoj v objektově orientovaném programování.

Existuje spoustu doporučení a spousty standardů, čeho se držet, ale já vycházím z javovské konvence, která mi osobně přijde nejlepší.

Nyní opět malá ukázka toho, jak by měl vypadat standardní OO kód.

class Auto
{
private $barva;
private $rychlost = 0;

public function __construct() {}

public function setBarva($barva)
{
$this->barva = $barva;
}

public function getBarva()
{
return $this->barva;
}

public function setRychlost($rychlost)
{
$this->rychlost = (int) $rychlost;
}

public function getRychlost()
{
return $this->rychlost;
}

public function isRychlost()
{
return (boolean) $this->rychlost;
}
}
?>


Příště už se pustím do samotného programování a proberu věci jako: typová kontrola, abstraktní třídy nebo interface.

pondělí 29. ledna 2007

OOP v PHP 1.

Spousta lidí tvrdí (stejně jako já), že psát objektově v PHP je šílenost a samotné PHP nemá tak dobrou podporu ani model k objektovému přístupu. Koncepce tohoto skriptovacího jazyka je postavena tak, abych byl schopen co nejrychleji nabastlit kód, který je schopen funkčního nasazení. Přesto je zde možnost psát objektově a od verze 5 dokonce i s vlastnostmi blížícími se objektově orientovaným jazykům typu Java či C++.

Předtím, než mohu začít psát objektově, musím mít elementární znalosti o tom, co jsou objekty, instance, jak funguje dědičnost, apod. Pokusím se zde popsat tyto znalosti tak, abych byl schopen na nich stavět.

Dost častá chyba je, když programátor pochopí OOP jako něco složitého či nereálného k použití. Ještě větší chybou je, když vývojář začne stavět projekt na objektech, aniž by měl dostatek znalostí k tomu, jak efektivně využít všech vlastností (toto byla i má chyba).

Takže o co vlastně jde? Na začátku můžete objekty chápat jako balíčky, které obsahují funkce a promenné, s kterými se dá pracovat v zájmu balíčku (objektu). Jinými slovy řečeno: "Objekty jsou obal nad procedurálním (obýčejným) kódem.".

OOP obsahuje spoustu nového názvosloví, které je potřeba znát, abych byl schopen rozluštit, o čem se dva objektoví programátoři mluví :)

// toto je trida
class Zamestnanec
{
// toto je atribut tridy
private $cislo;

// konstruktor tridy
public function __construct() {}

// metoda tridy
public function setCislo($cislo)
{
$this->cislo = $cislo;
}

// metoda tridy
public function getCislo()
{
return $this->cislo;
}

}
?>


Pokud má třída metody začínající set či get, tak je nazývame jako setry a getry. Tyto setry a getry nastavují a vracejí hodnoty, respektive pracují s atributem třídy, který by se měl vždy definovat jako "private".

Tímto jsem popsal základní názvosloví kolem třídy. V druhém kole popíši, jak třídu použiji.

$z = new Zamestnanec();
$z->setCislo(123);
echo $z->getCislo();


Takže, co je co? :) Promenná $z můžeme nazvat instancí objektu. Instance je jinak řečeno odkaz na objekt. Objekt je "new Zamestnanec()". Někdo by si zde mohl myslet, že objekt poznám tak, že obsahuje "new", ale není toúplně tak pravda. Např. objekt může být vytvářen jako jedináček (Singleton), který může být vytvořen pouze jednou. Takový objekt se vytváří interně a proto ho zvenku nevytvářím pomocí new (o tom, ale až později).

Dále je vidět, že pomocí instance (odkazu na objekt) volám metody set a get. Z vnějšku mohu volat pouze metody, které jsou public (veřejné). Důvody, proč je něco private, něco private a něco public, popíšu později.

To by bylo do začátku asi vše. Byli byste nyní schopni napsat třídu Auto obsahující atribut rychlost a metody na nastavení a vrácení rychlosti? Stejně tak i tuto třídu použít? ;)

středa 3. ledna 2007

Web development v Javě očima PHPčkáře

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.

Když programátor založí a řídí firmu

Jako malý jsem chtěl být popelářem. Ani ne tak proto, že bych měl nějaký zvláštní vztah k odpadkům, ale hrozně se mi líbilo, jak...