Já bych všechny ty internety zakázala

Ve dnech 15. – 18. října 2009 jsem navštívil konferenci WebExpo 2009 a chtěl bych se s vámi podělit o své zážitky. Sepsal jsem tedy krátké shrnutí popisující nejedno dobrodružství, strach, radost a euforii. Jelikož byla konference rozšířena ze dvou na čtyři dny, bylo letos oproti loňskému ročníku zážitků o něco víc.

Čtvrtek

Logo konference WebExpo 2009

Logo konference WebExpo 2009

Říkal jsem si při cestě na nádraží, proč vlastně zahřívací party? Když jsem se dozvěděl, že můj vlak bude asi o 15 minut opožděn a já se nalezeným spojem do Prahy nedostanu, vyběhl jsem na autobusové nádraží, abych byl v Praze přece jen včas. Pěkně jsem se zahřál. Na Dejvické jsem se setkal s Tomášem Jukinem a Markem Lenárdem. Vyrazili jsme do míst, ve kterých se občas pořádá mistrovství světa v orbě. Našli jsme naší kolej a ubytovali jsme se. Hned poté se razilo na již zmíněnou zahřívací party do centra Prahy. Zasedli jsme ke stolu Nettistů a začali jsme se seznamovat a řešit věci spojené s vývojem webových aplikací. Jsem strašně rád, že jsem se dal do rozhovoru s Vlastou Vávrů. Probrali jsme problém a obecné zavrhování doménových objektů ve webových aplikacích. Vlasta je totiž jediný člověk, který tuto problematiku aktivně řešil již s příchodem webových frameworků pro PHP. Následně jsme ještě vyslechli krátkou přednášku na téma Vliv psychotropních látek na kvalitu vývojáře od Davida Grudla a Jirky Knesla. Líbilo se mi, jak zvládli provázat teorii s praxí! Pak už se ale razilo domů.

Pátek

Molly E. Holzschlag

Molly E. Holzschlag

V pátek ráno jsme s Markem vyrazili do centra dění. Po registraci jsme se usídlili v aule. Zjistil jsem, že existuje prototypování webů a že to vlastně občas taky dělám, ale pouze na papír a možná také v EA. Následovala horlivá diskuze o tom, zda mají mít tabulky hlavičku s typem sloupečku nebo ne. Kéž bych měl takové problémy ;-) . Určitě to má něco do sebe, zkoumat dojem uživatele, ale od toho jsou tu naštěstí jiní. Formát XML je prostě sám od sebe nezábavný, ale Jiří Kosek o něm dokázal vyprávět celkem zábavně. Teprve pak to ale začalo. Konečně přednáška, co měla koule. Molly Holzschlag je opravdu velmi hyperaktivní a vtipná. Kolik času dáme příchodu HTML5? Podle mě nejde o nutnost. Neodsuzuji přístup k otevřeným standardům, ale když ono to už všechno stejně šlape… Když potom otevřené standardy bojují proti technologiím, jakými jsou Silverlight, Flash nebo JavaFX, jde do tuhého. Zástupci zmíněných technologií se představili a mimo jiné nabídli posluchačům editory určené pro jednotlivé technologie. Molly pravila: „To my máme v HTML textový editor.“Tahle hláška mě opravdu dostala. Šili do sebe s nadhledem a na závěr si zástupci technologií Silverlight a Flash vyměnili tričko před celým sálem. Panelová diskuze mi přišla jako povedené zakončení série přednášek pátečního dne.

Večer následoval raut v hospodě Na Farmě, na kterém měl každý návštěvník jediný cíl – ukořistit něco k jídlu a najít místo k sezení. Bylo to obtížné. Řešila se především vrstva UI a frameworky jako takové. Zajímavé byly rozhovory se Zendaři, a že jich tam nebylo málo. Ve večerních hodinách jsme si s Tomášem uvědomili, že ještě nemáme hotovou prezentaci na náš sobotní workshop. A tak jsme vyrazili na kolej o něco dříve, abychom prezentaci dodělali. Nastal problém. Zjistili jsme, že nám chybí internet. Naší prezentaci bylo možné upravovat pouze online, protože byla rozdělána v nástroji, který vytváří vysoce interaktivní prezentace, pro jejichž prohlížení se doporučuje, vzít si kinedryl. Rozhodli jsme se tedy, že prezentaci doděláme v sobotu v ranních hodinách. Šli jsme spát. Asi o půlnoci dorazil Martin Štěpař a začal se tetelit k Tomášovi na zem. Chvíli se prali o jeden spacák a pak už vše utichlo.

Sobota

Vstali jsme v 5 hodin a vyrazili k aule, na lavičce se připojili na internet a začali prezentaci dodělávat. Můžu potvrdit, že to bylo velmi veselé. Odnesl jsem si dvě ponaučení – dělat věci včas a nešlapat ve tmě do záhonů! Vrátili jsme se na kolej a psychicky se připravovali na náš workshop.

Kromě započaté hospodové evangelizace Unified Processu jsem neměl se školením žádné zkušenosti. Ale na to, že to byl můj první workshop v životě, si myslím, že se nám celkem vyvedl. Měli jsme k dispozici parádní konferenční místnost s dvěma projektory. Děkuji Vaškovi Stoupovi za obstarání slídování cheatsheetů. Za tři a půl hodiny se toho nedá moc stihnout, s tím jsme s Tomášem Jukinem počítali. Přesto jsme většinu informací povědět stihli. Když se za workshopem ohlédnu zpět, tak mě mrzí, že jsme účastníky skoro vůbec nezapojili do dění. Složité pro nás bylo také to, že účastníci byli na různých úrovních znalosti probírané problematiky. Za vaší zpětnou reakci v jakékoli podobě budeme velmi rádi. Materiály, použité na workshopu, uveřejníme na stránkách Objektově.cz.

František Fuka drží v ruce nanopodložku

František Fuka drží v ruce nanopodložku

Po obědě jsem si uvědomil, že se náš workshop kryl s přednáškou o GTD, což mě velmi naštvalo. Vyrazil jsem na přednášku o frameworcích Symphony a Doctrine. Myslel jsem, že to bude jediná přednáška, na které nebudu nikoho znát. Potkal jsem ale Michalise Katapodise a společně jsme zhlédli psaní aplikace z příkazové řádky. Termíny jako doménové třídy a aplikační logika byly zaměněny s třídou reprezentující databázovou tabulku. Přesunul jsem se na setkání agilních vývojářů, abych se dozvěděl informace o jiném přístupu k vývoji softwarových systémů. Následovala přednáška Davida Grudla o ajaxových novinkách v Nette Frameworku, které byly přidány během našeho workshopu, na který byl David Grudl pozván! Jako vždy David obohatil přednášku vtipnými hláškami a jako vždy spotřeboval dvakrát víc času. Právě proto se celý Community Meeting PHP skládal pouze z jediného dotazu na přání pro PHP6. Krásný závěr pátečních přednášek završil František Fuka a diskuze na téma Můj život s počítači. Pověděl nám o jeho programátorských zkušenostech, osobním životě, využívání Google aplikací, překládání titulků a mimo jiné také fakt, že má delší penis než Radek Hulán. Musím přiznat, že má zábavné a romantické psi. :-D Překvapil mě Martin Hassman, který se na diskuzi velmi dobře připravil.

Náš stůl na UX party

Náš stůl na UX party

Večer ale nekončil, následovala UX party v místním podniku. Osobně bych raději přivítal UP nebo UML party. Řešili jsme UX hospody. Návštěvník si musel dojít k baru pro pivo, zaplatit zálohu za sklenici a probrat se mezi stovky pizz zpátky ke stolu. Pořád to ale nemá na dveře od koleje nebo na Tomášem zmíněné balení salámu. Sešli jsme se u velkého stolu a mimo jiné s politologem Honzou Martínkem jsme řešili věci týkající se IT. Jako velmi dobrý nápad mi přišlo rapování o jednotlivých internetových stránkách. Mezi nejlepší večerní tweet bych zařadil: „Jsem zavřený v aule. Prosím, pusťte mě ven.:-D Chtěli jsme s Honzou odejít včas, ale půl hodiny jsme se loučili s Davidem Grudlem a další půl hodiny s Jirkou Kneslem. Odešli jsme tedy až teprve, když zavírali.

Neděle

Neděli bych označil jako dojezd. Dorazil jsem na TDD od Jirky Knesla. On kupodivu dorazil také. Musím uznat, že přístup, o kterém povídal, je zajímavý, ale úplně kompletně se liší od toho mého. Posadil jsem se na Community Meeting Agile Development. Dozvěděl jsem se spoustu užitečných informací, které lze bohužel reálně uplatnit až v praxi. Možná jsem postrádal nějaké oficiální zakončení konference. Pokračovalo se na oběd do pizzerky a tím bylo WebExpo 2009 v mých očích zakončeno.

Shrnutí

  • nadšení, radost
  • dík za umožnění šíření správného objektového přístupu mezi vývojáře
  • přednášky nedělají konferenci, konferenci dělají after party
  • jídlo a pití zdarma (naštvaly mě neplněné croissanty!)
  • organizace byla vydařená
  • rozšíření obzoru
  • stále nová dobrodružství!
  • k čemu slouží ta oranžová nanopodložka?

Buďme rádi, že nám tenkrát ta paní všechny ty internety a počítače nezakázala. Nesetkali bychom se. Těším se na vás na dalším ročníku!

štítky: ,

S objekty do světa

Musím se přiznat, že jsem na prvním ročníku konference WebExpo postrádal přednášku o pravém objektovém programování webové aplikace. Smutnil jsem, že se žádná významná osoba touto problematikou nezajímala. Postupem času jsem si začal uvědomovat zatemnění především začínajících vývojářů při neúplném pochopení architektury MVC a především zanedbávání modelu, který byl často nahrazován databázovými dotazy přímo v controllerech. Pořekadla jako Model je funkční základ aplikace.“ nebo Na model lze napasovat několik různých UI.“ se řadili pouze mezi teoretické poučky.

Podobný problém zaznamenal i Tomáš Jukin a tak jsme se rozhodli vyrazit s objekty mezi lidi. Na letošním WebExpu si v rámci našeho workshopu Vývoj objektových webových aplikací v PHP metodikou USDP pomocí UML povíme, že vývoj webových aplikací na základě bezhlavého psaní kódu už dnes neletí. Vysvětlíme si, jak efektivně modelovat webové aplikace pomocí objektové metodiky Unified Software Development Process a jako jednotný dorozumívací jazyk v rámci vývojového týmu (popř. přímo s klienty) používat UML. Nad obyčejný podřadný kód posadíme abstraktní rovinu, která nám pomůže udělat si obrázek o systému mnohem rychleji než marné orientování v kódu. Značnou výhodou hotové aplikace bude její velmi dobrá upravitelnost a rozšiřitelnost.

Náš 3,5 hodinový workshop se koná v sobotu 17.10.2009 časně zrána. Workshop bude rozdělen do dvou částí. Nejprve si povíme něco málo nezábavného o teorii modelování informačních systémů, metodice Unified Software Development Process a notačním jazyku UML. V druhé části vás provedeme řízením reálného projektu na základě metodiky USDP. Budeme si hrát na vývojový tým a společnými silami vyvineme použitelnou objektovou webovou aplikaci. Účastníci si v rámci workshopu vyzkouší CASE nástroj Enterprise Architect, získají teoretické základy metodiky USDP a jazyka UML a pochopí jak správně nakládat s modelem z architektury MVC na reálném příkladu založeném na technologiích Nette Framework a Doctrine. Pište správné objektové webové aplikace a bude se vám lépe usínat!

Abstrakce použití webové aplikace

Jak se používají dnešní webové aplikace? Mnozí uživatelé asi odpoví, že se do aplikace nejprve registrují, přihlásí se a pak v aplikaci naleznou příslušnou stránku, na které vyplní formulář a odešlou ho na webový server. Tuto činnost provádějí tak dlouho, dokud neukojí svých potřeb. Samozřejmě, každý vývojář se s podobnou výpovědí setkal a zná ji ze své praxe. Představí si ji asi tak, že aplikace bude disponovat

  • registračním formulářem na stránce s registrací,
  • přihlašovacím formulářem na hlavní stránce,
  • a stránkami s jinými formuláři na jiných stránkách.

Taková představa je ovšem trochu urychlená, protože se váže na implementační detaily a především na návrh uživatelského rozhraní. V takovém znění by měla zajímat spíše koncového uživatele. V základních fázích vývoje webové aplikace nás vývojáře nebude zajímat rozvržení jednotlivých stránek ani jaké zvolit prvky do formulářů. Takové rozhodovaní odložíme na později. Zkusme se na to podívat z jiného úhlu a pojďme se nyní zamyslet nad vhodnou abstrakcí použití naší aplikace koncovým uživatelem.

Uživatel přistupuje k aplikaci vždy s nějakým záměrem, tzn. že chce, aby vykonala něco v jeho zájmu. Interakci uživatele s webovou aplikací za určitým cílem budeme označovat jako případ užití (anglicky use case). Případy užití můžou být podmíněny rolí uživatele (např. jen administrátor může měnit zásadní nastavení) nebo jinou výchozí podmínkou (např. zákazník musí mít v košíku nějaké zboží, aby mohl potvrdit objednávku) a často jsou variabilní (např. aby mohl uživatel změnit počet konkrétního zboží v košíku, musí být zboží dostupné na skladě). Důležitým faktem je, že webová aplikace disponuje konečným počtem případů užití.

„Referenční příručka jazyka UML definuje případ užití jako specifikaci posloupností činností, včetně proměnných posloupností a chybových posloupností, které systém, podsystém nebo třída může vykonat prostřednictvím interakce s vnějšími aktéry.“ [USDP, strana 95]

Metodika Unified Software Development Process zaznamenává případy užití pomocí diagramů případu užití notačního jazyka UML. Ačkoli jazyk UML nepředepisuje konkrétní způsob textové specifikace, je ustálen zápis pomocí šablony [USDP, strana 99]. Na úrovni lidské řeči (pseudokódu, chcete-li) jsou zaznamenány veškeré možné použití aplikace koncovým uživatelem. Ptáte se k čemu to je dobré? Stačí prý naházet do šablon několik formulářů, provázat je controllery a nějak to napojit na databázi? Ten pravý důvod na nás stále čeká!

Webovou aplikaci lze zjednodušeně definovat jako model a uživatelské rozhraní postavené nad modelem, které koncovému uživateli umožňuje s modelem komunikovat a manipulovat a tím realizovat případy užití. Velmi často je ve webových aplikacích externí uživatel v rámci modelu reprezentován a jako interní entita komunikuje se zbylou částí modelu.

Návrh případů užití spočívá v transformaci modelu na úrovni lidské řeči (požadavků na webovou aplikaci) do modelu na úrovni komunikace objektů našeho modelu z MVC. V UML lze tuto komunikaci zachytit pomocí sekvenčních diagramů (je možné využít i další diagramy). Tím docílíme popsání úplné funkčnosti modelu.

V rámci otázky implementace nás bude držet při zemi databáze jakožto úložiště dat. Naštěstí je možné postavit model na nějakém ORM a částečně se s nástrahami vypořádat. Teď, když už máme čistě objektový perzistentní funkční základ webové aplikace, který je schopný obstarat všechny případy užití externích uživatelů, je teprve čas na natlačení uživatelského rozhraní do controllerů, šablon a formulářů!

[USDP]Jim Arlow, Ila Neustat: UML 2 a unifikovaný proces vývoje aplikací, Computer Press, 2007

štítky: , ,

K něčemu malému s velkou myšlenkou

Byl jsem zendařem. Už je tomu asi rok a půl zpátky. Hledal jsem vhodný PHP framework, který by mi ulehčil práci při psaní webových aplikací. Tenkrát jsem se rozhodl pro Zend Framework hlavně z toho důvodu, že ho vyvíjeli autoři PHP. Říkal jsem si, že asi bude psán kvalitně. Výběru napomohla také skutečnost, že frameworků tenkrát ještě moc nebylo, nebo o nich aspoň nebylo tolik slyšet. To až v poslední době se s nimi roztrhl pytel. Pamatuji si, byla to verze 1.5, kterou jsem začal studovat. Naivně jsem si vytiskl celou dokumentaci. To se ještě vešla na pouhých 670 stránek. K tomu jsem si koupil knihu, která se vázala k verzi 1.5, a začal jsem se vzdělávat.

Přechod na verzi 1.6 byl jediný přechod, který jsem stihl plně pochytit. S přechodem na verzi 1.7 mi toho hodně proklouzlo a další přechody už jsem sledovat nestíhal. Zend Framework byl hodně rozšířen do všech směrů a stalo se z něho obrovské neovladatelné monstrum. Kde zůstala ta základní kostra verze 1.5? S vytisknutou dokumentací a zakoupenou knihou si teď můžu tak akorát tak… Nezastavitelný bezmyšlenkovitý vývoj mě začal na frameworku vadit. To když začínáte s projektem na aktuální verzi frameworku, museli byste projekt před dokončením pořád upravovat na tu novou a novou verzi, abyste jeli pořád na té aktuální. Framework má přece práci ulehčovat, ne ztěžovat. Občas se najdou i celkem zásadní změny jako např. psaní bootstrapového souboru pomocí objektu třídy Zend_Application nebo třeba zavedení URL helperů. Podle mého názoru by takové věci měly být stanoveny před počátkem vývoje frameworku. Jsou to základní kameny, na kterých by se mělo začít stavět. Kromě toho mě odradila rychlost frameworku. Je samozřejmé, že se to nabalování nových vlastností muselo někde projevit. Jednoduše Zend Framework už nesplňuje moji ideologii frameworku. Netuším, proč se vývojáři snaží, aby uměl úplně všechno.

V tomto ohledu se mi zalíbil Nette Framework, který mi byl doporučen Tomášem Jukinem. Má totiž jasně vytyčenou myšlenku, se kterou ho David Grudl píše. Fascinující je, že je framework vyvíjen pouze jediným člověkem, který si dle vlastního uvážení řekne, ano, tohle tam dám nebo ne, tohle si tam dodej sám! Líbí se mi, že se framework nerozrůstá do maximálních rozměrů a zůstává jednoduchý, jasný a srozumitelný. Mimo to využívá rozhraní a kvalitního objektového přístupu. Další plus u mě získal tím, že nemá knihovnu pro práci s databázi a tak si v klídku můžu dodat mnou zvolený ORM nástroj a stavět na něm celý model. I když mám s tímto frameworkem zatím více méně nulové zkušenosti, tak splňuje moji ideologii frameworku a vypadá to, že budeme kamarádi!

Chtěl jsem vám jenom oznámit, že přecházím od něčeho velikého s malou myšlenkou k něčemu malému s velkou myšlenkou, od Zend Frameworku k Nette Frameworku.

Bootstrap file a nekoncepční třída

K tomuto příspěvku mě dotlačilo toto téma na českém ZF fóru, ale především tři noci prosezené u psaní a konečné formulace bootstrap file pro projekt My Town Game, o kterém vám v blízké době povím něco více. Zakrývám si oči pravou rukou, otáčím se a ulehám do kouta. Harvejsi, měl jsem bootstrap tak veliký a nepřehledný, že jsem byl donucen ho přepsat do nekoncepční třídy s originálním názvem Application. Kromě tebou zmiňované přehlednosti má nekoncepční třída bootstrap filu ještě takovou výhodu, že se u každé metody dá napsat pěkný phpDoc komentář, který mi vždy připomene, co že se to teď vlastně louduje. Takže se ti předem omlouvám a nedivím se, proč je kolem vývoje třídy Zend_Application takové vzrůšo. Dovolil bych si tedy tvrdit, že pokud se jedná o větší ZF projekt, jehož bootstrap file by byl v základním znění nepřehledný, je výhodné, naházet to všechno do nekoncepční třídy. Musím tedy přihmouřit své OOoči… ;-)

Ehm, a co že to ta nekoncepční bootstrap třída vlastně je? Představte si, že váš bootstrap file index.php (www/index.php) bude vypadat následovně a že statická metoda s divokým názvem run() se postará o všechno, co je třeba:

1
2
3
4
5
// include class Application
require_once '..' . DIRECTORY_SEPARATOR . 'application' . DIRECTORY_SEPARATOR . 'Application.php';

// execute the application
Application::run();

Přesuneme se dále do třídy Application (application/Application.php), která implementuje návrhový vzor singleton, protože aplikaci přece nebudeme spouštět vícekrát najednou, a to i kdyby měla Sofie S. zůstat sama samotinká. Tato metoda potom ve zkratce zavolá po sobě seřazenou většinu loudovacích metod, které jsou ve třídě dostupné. To je kalibr!

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
/**
 * This method execute the application
 *
 * @return void
 */

public static function run()  {

    self::getInstance()->_setErrorReporting(); // error reporting level
    self::getInstance()->_setDefaultTimezone('Europe/Prague'); // default timezone
    self::getInstance()->_setApplicationDir(); // application directory
    self::getInstance()->_setIncludePath(); // include path
    self::getInstance()->_registerAutoload(); // autoloader
    self::getInstance()->_netteDebug(); // Nette debug
    self::getInstance()->_loadConfig(); // loading configuration
    self::getInstance()->_initCache(); // cache
    self::getInstance()->_doctrineConnect(); // database connection
    self::getInstance()->_initRouter(); // router
    self::getInstance()->_initFrontController(); // front controller
    self::getInstance()->_dispatch(); // dispatch

}

Všechny takto volané metody jsou soukromé a vykonávají část bootstrap funkcionality, která se takto dá velmi jednoduše dokumentovat pomocí phpDoc u každé této metody a samozřejmě také rozšiřovat novými metodami. Třída pak může obsahovat ještě pomocné soukromé metody nebo veřejné metody pro přístup z pluginů nebo z controllerů. Na ukázku ještě detail metody pro připojení do databáze:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
/**
 * Doctrine lazy database connection
 * It creates a connection string by class Tools_Doctrine and it forwards this string
 * to Doctrine manager.
 *
 * @link http://www.doctrine-project.org/Doctrine_Manager/1_0#method_connection
 * @see class Doctrine_Manager
 * @see class Tools_Doctrine
 * @return void
 */

private function _doctrineConnect() {

    $connection = Tools_Doctrine::getConnectionString($this->_config->database);
    Doctrine_Manager::connection($connection);
    $connection = null;

}

No a konečně disponuje nekoncepční bootstrap třída výhodou, že si může všechno zapamatovat ve svých členských proměnných a o použití Zend_Register si můžete nechat během teplých letních nocích jen zdát. Následující kód zobrazuje příklad deklarace členských proměnných.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
/**
 * Single instance of class Application
 *
 * @staticvar Application
 */

private static $_instance = null;

/**
 * Application directory
 *
 * @var string
 */

private $_dir = '';

/**
 * Configuration object
 *
 * @var Zend_Config
 */

private $_config = null;

/**
 * Cache object
 *
 * @var Zend_Cache
 */

private $_cache = null;

/**
 * Router
 *
 * @var Zend_Controller_Router_Rewrite
 */

private $_router = null;

/**
 * Language
 *
 * @var string
 */

private $_language = '';

/**
 * Application locale
 *
 * @var Zend_Locale
 */

private $_locale = null;

/**
 * Translation object
 *
 * @var Zend_Translate
 */

private $_translator = null;

/**
 * Instance of Front Controller
 *
 * @var Zend_Controller_Front
 */

private $_frontController = null;

Vše co je libo je prostě přístupné a tak si ještě nakonec shrneme výhody a nevýhody nekoncepční bootstrap třídy. Mezi výhody patří:

  • přehlednost
  • dokumentovatelnost
  • rozšiřovatelnost
  • přístupnost
  • znovupoužitelnost

A mezi nevýhody patří:

  • nekoncepčnost
  • rychlost (zanedbatelná)

Stejně jako jsem v článku o kategorizaci přístupu k tvorbě PHP projektu neodsuzoval žádný z přístupů, tak ani v tomto případě netvrdím, že některý způsob tvorby bootstrap filu je obecně nejlepší. Proč si myslíte, že to Zend Framework nechává otevřené a předává tuto starost na samotné programátory?