Začátkem roku jsem si začal psát vlastní PHP framework, vycházející ze vzoru Page Controller.

Pak jsem si napsal i vlastní testovací nástroj. Na Simpletestu i PHPUnit mi z několika důvodů vadilo, že se testy spouští postupně v jednom vlákně. Tak jsem si ubastlil takový ošklivý skript, který ajaxem posílal kupu požadavků na provedení jednotlivých testů.

Bylo to o něco rychlejší, testy byly lépe izolované a navíc jsem tím měl i trochu ošetřenou thread safety: Kdyby nějaký kód nebyl thread safe, tak by se to pravděpodobně projevilo ještě při testech.

Na jaře jsem se zasekl, protože se mi začaly hromadit duplicity mezi Modelem a View a nevěděl jsem, co s tím. Pořád nevím…

Do toho jsem začátkem srpna přešel od PHP k Javě. Tím jsem veškeré dosavadní výtvory zahodil (tak moc toho zas nebylo  ).

Koncem srpna jsem přešel od Javy k .NET, protože na malé webové projekty se Java nehodí.

Od té doby se tak trochu plácám. ASP.NET se dá do vysoké míry přizpůsobit, ale ne vždy je snadné přijít na to, jak.

Hodně času jsem třeba strávil tím, že jsem chtěl testovat instance stránek. Představoval jsem si testy, které by probíhaly přibližně takto:

• Vytvořit instanci stránky "~/default.aspx".
• Provést request.
• Ověřit, jestli vlastnosti určitých controlů nabývají správných hodnot.

To se mi do jisté míry podařilo, ale byl to porod a pořád ještě nevím, jak nasimulovat třeba POST request. Navíc po proběhnutí testu občas vylétá jakási výjimka. (Viz ASP.NET fórum.)

A takhle je to se vším. Jakmile se rozhodnu dělat něco jenom trošku jinak než je obvyklé, tak narazím…

Čím dál častěji různě narážím na zmínky buďto o xUnit.org, nebo o testech zabudovaných v týmové edici Visual Studia (MSTest). Na stránkách k xUnit.org jsem našel přehlednou srovnávací tabulku, kterou lze shrnout asi takhle:

• NUnit, MbUnit, MSTest: Třikrát to samé, pouze drobné rozdíly v zápisu ([Test] vs. [TestMethod] apod.).
• xUnit.net: Některé věci dělá jinak, než je obvyklé. Především:
  • Pro každý test se vytváří nová instance testovací třídy. Z toho vyplývá:
    • Testy jsou lépe izolované.
    • Žádné SetUp/TearDown metody. Testy lze inicializovat v konstruktoru a uklidit případně v IDisposable.Dispose.
  • Testovací metodě se říká „fact“.
  • Testovací třída nemusí být nijak označená. Stačí, že jsou označené testovací metody.

xUnit.net je dost zajímavý kousek softwaru. Co mu podle mě hodně schází, je Assert.That. Tedy možnost například místo staromódního zápisu:

Assert.AreEqual(expected, actual);

Používat jiný zápis:

Assert.That(actual, Is.EqualTo(expected));

Tento zápis se víc blíží přirozenému jazyku (Věta „assert that actual is equal to expected“ docela dává smysl, ne?) a je docela návykový. Podle mě je otázkou času, kdy ho adoptuje i xUnit.net.

Související: Raroušův článek o xUnit.net

Také předpokládám, že chápete, že to je špatný přístup. Alternativně je možné ViewState ukládat do session, což je ještě horší…

Pro mě jediným přijatelným řešením je vůbec nepoužívat ViewState.

Především nepoužívat controly, které na ViewState závisí. To se týká dost controlů, které jsou součástí .NET, ale taky ne všech. Například datové zdroje (SqlDataSource, EntityDataSource apod.) se bez ViewState obejdou.

Jak se zbavit toho formuláře

Jednoduše smáznutím tagu <form runat="server"></form> ze zdrojáku stránky. ASP.NET jako takové na něm netrvá.

Vestavěné formulářové controly (TextBox, Button apod.) si jeho přítomnost vynucují, ale ty jsem stejnak už zavrhl kvůli jejich závislosti na ViewState.

Design View

Velkou nepřímou výhodou ASP.NET je design view ve Visual Studiu. Že stránku můžete upravovat ve WYSIWYG editoru, controly si tam přetahovat z toolboxu a hned máte představu, jak to bude vypadat.

Zatímco s PHP nebo ASP.NET MVC upravujete zdroják a dokud to nespustíte v prohlížeči, tak si jen v hlavě představujete, jak to asi bude vypadat a jestli to bude přehledné (design view nic jako <%= Html.TextBox("username") %> nezobrazí).

Bohužel s přetahováním z toolboxu je jistá potíž: Pokud ve stránce není žádný formulář, Visual Studio ho pro vás laskavě vytvoří kdykoli, kdy přetáhnete nějaký server control v design view. S tím nic nezmůžu (ani nikdo na fóru). Je zajímavé, že když control přetahuju do source view, tak to tuhle nasrávku nedělá.

Z toho plyne, že pokud se chci opravdu zbavit formuláře, mám tyto možnosti:

1. Nepoužívat design view.
2. Pokaždé to ručně mazat.
3. Použít nějaký preprocessing.
4. Využít adaptivní rendering, vytvořit si control adapter pro HtmlForm a tvářit se, že tam žádný server form není.

Kompromisem by mohl být split view, že bych sice psal kód, ale zároveň viděl výsledek. Něco podobného jsem viděl už v několika HTML editorech a nikdy mi to nesedlo. Pochybuju, že si na to zvyknu teď.

Control adapter by vyřešil ten největší problém, kterým je zbytečný formulář v HTML výstupu. Ale nějak se mi to nelíbí, přijde mi to jako hodně ošklivý workaround.

Zatím nejsem zděšen.

C# a Visual Basic

Úplně ze začátku jsem se jazyk neučil vůbec, vystačil jsem si v podstatě se znalostmi Javy. Postupně mi došlo, že rozdíly nejsou jenom v syntaxi a vyhledal jsem nejdřív C# for Java Developers a potom C# Programming Guide.

Mohl jsem si vybrat i jiný .NET jazyk, včetně takových úletů jako je PHP nebo Fortran, ale za rozumnou volbu pro začátečníka lze považovat pouze C# nebo VB.

Visual Basic mi připadá jako C# s méně přehlednou syntaxí a se spoustou zbytečností navíc (například XML Literals), díky kterým připomíná eintopf pejka a kočičky…

Nástroje

Zatím mi stačí Visual Web Developer, jedna z bezplatných verzí Visual Studia. Bez něj by to nešlo.

Kdysi jsem ze zvědavosti pokukoval po PRADO frameworku pro PHP. Dost mě odrazoval zápis, spousta XML, spousta souborů, spousta konfigurace. PRADO to všechno odkoukalo právě od ASP.NET, jenže tady se to používá strašně pohodlně, díky skvělému IDE…

Kromě VWD už používám jenom NUnit na testy jednotek, jiné nástroje jsem zatím nepotřeboval. Až budu mít co dokumentovat a verzovat, tak přibude ještě Sandcastle a Subversion. Víc mě nenapadá.

ASP.NET MVC

Jak mi bylo poraděno, podíval jsem se na ASP.NET MVC. Některé věci mě vysloveně nadchly, ale nebudu se opakovat. Zkrátka je to hodně povedený framework.

Jednu věc ale stále nechápu: Proč se v šablonách místo controlů používají hloupé helpery. To nikdo nepoužívá design mód? Kdybych se pro ASP.NET MVC rozhodl, tak bych určitě začal vytvořením nějaké sady controlů.

Nicméně, ač se mi ASP.NET MVC hodně líbí provedením, nelíbí se mi koncepcí. Zkrátka mi nesedí ten RoR přístup k MVC.

ASP.NET built-in page controller

Mnohem víc mi sedí to, čemu se prý říká Page Controller. To je přístup, při kterém si programátor může webové UI představit jako soustavu stránek.

To nabízí ASP.NET v základní výbavě. V současné verzi je dokonce možné i pro tento přístup použít routing, tedy přizpůsobitelné mapování URL na stránku.

Bohužel některé věci v ASP.NET nejsou uspokojivě vyřešeny. Hlavní problémy vidím zatím tři:

• Předávání stavu aplikace.
• Generování ClientID.
• Automatické testování.

Trochu to rozvedu.

Předávání stavu aplikace

Stránku si lze představit jako strom komponent, z nichž některé můžou měnit svůj stav na základě uživatelských akcí. Problém je, jak tento stav předávat mezi jednotlivými HTTP požadavky.

ASP.NET pro to nabízí ViewState. To je taková kolekce, do které si každá komponenta může uložit data, která jí při příštím požadavku pomůžou obnovit svůj stav. ASP.NET nabízí dva způsoby, jak tuto kolekci přenášet mezi požadavky:

1. Skryté pole. Stránka se obalí formulářem, do něj se dá skryté pole a do něj serializovaný ViewState. Požadavky je pak nutné provádět odesláním tohoto formuláře – tlačítkem nebo javascriptem.
2. Session. Viewstate se uloží do session, na klienta se přenáší pouze session ID.

Hlavní nevýhody obou možností jsou zřejmé:

• Nelze používat bookmarky, nelze odkazovat.
• Neprojdou roboty vyhledávačů.
• Ve druhém případě navíc hrozí expirace session.

Výhodou je, že do ViewState lze uložit jakýkoli serializovatelný objekt, ale ty nevýhody to stejně nevyváží.

Jak jinak lze předávat stav uživatelského rozhranní? Přece v URL, jako každá slušná webová aplikace. Bohužel, pro toto paradigma ASP.NET žádné usnadnění nenabízí. Tady si budu muset ASP.NET trochu přiohnout.

Generování ClientID

Pokud se server control vykresluje do HTML a má mít nějaké ID, je potřeba zajistit, aby bylo v rámci HTML stránky jedinečné. ASP.NET pro to má řešení, ale takové hloupé.

Zatím mě to moc nepálí, ale přemýšlím, že u svých vlastních controlů umožním klientské ID nastavit napevno:

private string _clientID;

public override string ClientID
{
    get
    {
        if (_clientID == null)
        {
            _clientID = base.ClientID;
        }
        return _clientID;
    }
}

public string CustomClientID
{
    set
    {
        _clientID = value;
    }
}

Automatické testování

Podle toho, co jsem četl, je prý obtížné vytvořit instanci stránky jinak, než requestem na server. Velký problém v tom nevidím – na samotných stránkách by k white-box testování beztak nic moc být nemělo. Ale ještě se na to podívám.

GimPhoto

GimPhoto je vpodstatě úplně normální Gimp, akorát má trochu jinak členěná menu a má oproti holému Gimpu navíc pár plug-inů, štětců apod. Autor této úpravy se snaží všechny funkce dát pokud možno tam, kde jsou k nalezení ve Photoshopu.

To je samo o sobě užitečné, ale pořád je to na první pohled Gimp: Pořád plýtvá hlavními okny a šíleně tím znepřehledňuje taskbar.

GimPad

Tohle je bomba! Je to jakási obálka pro GimPhoto, aby používal pouze jedno hlavní okno (jako Photoshop pro Windows). Pokud má toto hlavní okno focus, tak jsou Gimpovské panely vždy navrchu (překrývají okna obrázků):

Tím to ale nekončí. Panely lze přetáhnout pryč z okna (třeba na jiný monitor) a i potom zůstávají navrchu, dokud má GimPad focus. Přepnete na jinou aplikaci a panely zmizí, přepnete zpět na GimPad, panely se objeví.

Na druhém monitoru mi obvykle běží přehrávač hudby a nemám rád, když mi ho zbytečně něco překrývá. Nástroje Gimpu mi ho díky GimPadu překrývají jenom po dobu, kdy v něm něco dělám, to je ideální.

Autor obou programů

Jmenuje se Ek kian a je to vysokoškolský učitel z Indonésie. V práci si zvykl na Photoshop, ale na doma si ho nemohl dovolit. A tak si svůj vytoužený program prostě vyrobil. Má můj obdiv.

Dokumentační blok

Docbloky se v C# dělají trochu odlišně od Javy nebo PHP. Skládají se z řádkových komentářů, které mají o lomítko víc a jednotlivé části se uzavírají do jakoby-XML značek:

/// <summary>
/// Stručný popis třídy Foo.
/// </summary>
public class Foo
{
    /// <summary>
    /// Popis metody Bar.
    /// </summary>
    /// <param name="abc">Popis parametru abc.</param>
    /// <returns>Metoda vrátí 123.</returns>
    public int Bar(string abc)
    {
        return 123;
    }
}

(Takhle to vypadá dost nepřehledně, protože zvýrazňovač syntaxe FSHL neumí C#, v IDE to vypadá o něco lépe.)

Je možné používat i /** */ zápis, ale není to obvyklé.

Doporučované značky

Využití

Především tuhle dokumentaci využívá IntelliSense.

Krom toho je možné z toho vygenerovat API dokumentaci nástrojem Sandcastle, postup ale není úplně přímočarý, viz:

• Trupíkův weBlog: Sandcastle – generování dokumentace z XML komentářů (nástupce NDoc)
• Jirka Helmich: Sandcastle – řešení některých problémů

Tabulky se v Texy dělají intuitivně, dokud v nich jsou jednořádková data. Pro víceřádková jsem musel trochu zaexperimentovat, ale přišel jsem na to:

|---------------------------
| Nadpis | Nadpis
|---------------------------
| text   | Jednořádková buňka.
| text   | První odstavec.
|       ^| ^
|       ^| Druhý odstavec. ^
| text   | - První položka.
|       ^| - Druhá položka. ^

Správné nastavení (Zobrazit → Možnosti → Výstup):

Stačilo pouze výstup DirectShow videa nastavit na „výchozí“.

Nevím, proč „výchozí“ nebylo ve výchozím nastavení… MPC jsem nainstaloval spolu s nějakým codec packem, tak možná proto.

Současná Java 6 je jenom taková vylepšená pětka. Java 5 byla přelomová verze, která přinesla generiky a anotace. Díky anotacím už není nutné ke každému projektu udržovat miliony XML souborů a generiky zase odstranily mnoho problémů statického typování.

Taky jsem si trochu ujasnil termíny jako „aplikační server“ nebo „J2EE aplikační server“, resp. „Java EE aplikační server“. Dost mi pomohl článek od Dagiho: Třívrstvá architektura v kostce I.

Zatímco za aplikační server lze považovat klidně i LAMP, tak Java EE aplikační server je takový aplikační server, který splňuje komplet některou Java EE specifikaci. Pro většinu projektů je to čirá zbytečnost, ale velké firmy na to slyší. Když už mají investovat miliony do nějaké technologie, tak pochopitelně raději volí software IBM s certifikací od Sunu, než software od jakési Apache Foundation s licencí „AS-IS, NO WARRANTY“.

Já bych využil jenom několik málo komponent Javy EE, jako základ bych měl Tomcat + pár dalších open source knihoven. Java je ohromná stavebnice, to se mi líbí.

Jenže…

Už jsem rozečetl i jeden tutoriál pro Javu EE, ale poslední tři týdny se skoro nedokážu přimět k tomu sednout. Proč? To o těch hostinzích mě připravilo o iluze a já si pomalu uvědomuju, že hostovat na sdíleném Tomcatu nechci a platit si VPS zatím taky ne.

Zkrátka že Java nemůže konkurovat PHP na poli nízkonákladových webových projektů. Nic pro nás hobbíky.

O návratu k PHP jsem uvažoval jenom krátkou chvíli. Nepouští mě strach z toho, že budu všechno pracně upravovat, až vyjde další minor verze (PHP 5.3) a celé psát odznova, až vyjde další major verze (PHP 6). Vím jenom o dvou aplikacích, které od PHP3 po PHP5 přežily bez kompletního přepsání. Jinak se všechno v PHP píše pořád odznova…

Kontumačně se dostávám k ASP.NET. Moc nadšený z toho zatím nejsem, ale horší než PHP to snad být nemůže. 

Tak nám zase probíhá jedna hra na sport… Dřív jsem měl dost vyhraněný postoj k olympiádě, vadilo mi to pokrytectví: Jak se předstírá, že jde o něco víc, než továrnu na prachy a pěknou show. Kecy o sportu, o oslavě síly těla a ducha apod. Přitom co je nejdůležitější a také nejsledovanější disciplínou? Jednoznačně slavnostní zahájení s ohňostrojem – oslava síly zábavního průmyslu.

Myslím, že se to olympiádě stalo tehdy v roce 1936, do té doby to byla spíše hobbícká akce. Německo ukázalo světu, jaký potenciál se v OH skrývá: Že je to další příležitost pro dokazování, že právě lidé z určité země jsou ostatním nadřazení.

Se studenou válkou se to pak pořádně rozjelo na všech stranách severní polokoule: Provázela to propaganda, tu provázel zájem diváků i sportovců (propaganda funguje), to přilákalo „sponzory“, ti přilákali spotřebitele a to zase další „sponzory“, kolo se roztočilo… Sport už není cílem, ale prostředkem.

Ale… Spousta věcí kolem OH mi sice stále vadí (například náš zákon 60/2000 mi bude pít krev, dokud bude v platnosti), ale už na ni nenahlížím tak černobíle:

1. Pro zúčastněné sportovce to je splnění snu, které jim přeju.
2. Někteří diváci si tím budují vztah ke svému původu, jiné to inspiruje k vlastní sportovní aktivitě (v lepším případě rekreační, ale i vrcholový sport je lepší než žádný), další se třeba „jenom“ pobaví a všichni se shodnou, že show je to velkolepá.
3. Poskytuje témata k diskuzi. Letos například tráva a sport – ano či ne, nebo velká mezinárodní akce v totalitní zemi – ano či ne.
4. Nechá vydělat spoustě lidí – údržbáři sportovišť počínaje, lobbisty jednotlivých měst konče.

Kdyby to byla čistě soukromá akce a kdyby se tolik neschovávala za polomrtvé ideály, mohla by mi být docela sympatická. Jako různá mistrovství ve fotbale, hokeji, golfu, pokeru a podobně.

Tak tohle je zhruba můj současný postoj k olympijským hrám.

To je zatím vše, příští článek snad bude zase o Javě.