Ali Baba programuje

Trochu teorie kolem DSL

2009-03-16T18:49:00.049+01:00

Doufám, že vás v mém posledním postu moc nevystrašilo slovní spojení "Domain-Specific Language". Je to jen další buzzword: zní to sofistikovaně, ale ve skutečnosti to není nic nového. Laskavý čtenář, kterému rostou víc vousy než vlasy, si možná vzpomene na minijazyky v unixu, což není nic jiného než DSL - malý jazyk vymyšlený pro konkrétní účel.

Dnes se DSL nejčastěji objevují ve formě konfiguračních souborů. Například *.hbm.xml soubory v NHibernate jsou zapsány jazykem speciálně vytvořeným pro problémovou oblast (=doménu), kterou je v tomto případě mapování mezi databází a objekty. Nebo obyčejný web.config v asp.net aplikaci: To je jazyk specifický pro konfiguraci .NET website, kde je nutné určit které moduly a handlery budou pro který typ souboru použity:-) Takže s nějakým DSL se setkal každý programátor, jen o tom možná neuvažoval jako o DSL.

Doporučuju vám tuto prezentaci, kde Martin Fowler vysvětluje, co si představuje pod pojmem DSL. Všimněte si, že říká že hranice co už je DSL a co ještě není je neostrá. Dokonce i C# nebo java kód může být chápán jako DSL, kde forma zápisu je shodná s programovacím prostředím. V takovém případě se jedná o interní DSL, který lze přímo spustit.

Oproti tomu externí DSL jazyky mají svůj vlastní způsob zápisu, nezávislý na existujících programovacích jazycích. To přináší větší svobodu v definici syntaxe jazyka, na druhou stranu musíme kód nějak parsovat a interpretovat sami. To je natolik složité, že ve většině případů by komplexita parseru a generátoru převážila nad zisky z používání DSL jazyka, což je mimochodem důvod, proč mají tvůrci dnešních DSL tak rádi XML, XSD a XSLT. Další nemalé úsilí by bylo zapotřebí k tomu, aby se "user experience" při používání DSL jazyka přiblížila moderním IDE: Kdo jednou zkusil intellisense ve Visual Studiu a průběžnou analýzu kódu s ReSharperem, těžko se bude chtít vracet k plaintextu.

Když už máme náš nový jazyk definovaný a umíme ho parsovat, je nutné se rozhodnout jak ho budeme interpretovat. Můžeme z DSL jazyka generovat zdrojové kódy v jiných (existujících) jazycích, kompilovat je a distribuovat náš program jako binární knihovny. Druhou variantou je napsat "framework", který bude náš DSL kód interpretovat za běhu a distribuovat tento framework s výchozí podobou DSL kódů, které si koncový klient může upravit podle svého. Typickým příkladem prvního přístupu jsou programy pro modelování v UML, v druhém případě pak konfigurační soubory nebo skriptovací jazyky.

Generování kódu nám jako autorům programu dává do rukou mocnou techniku: Možnost následných úprav vygenerovaného kódu v místě různých "extension points", jako jsou partial třídy nebo double-derived pattern (vygenerujeme base třídu s virtuálními metodami a vlastnostmi a prázdného partial potomka). Díky tomu náš DSL jazyk nemusí řešit všechny krajní varianty. Když to obrátíme můžeme říct, že pokud se rozhodnete váš DSL interpretovat až za běhu, musíte vaše řešení zcela popsat pomocí DSL - včetně všech výjimek a minoritních úkazů. Dostáváte se tak do "customizační pasti", kdy musíte napsat kompletní framework dřív, než budete moci váš DSL použít. Generovat kód je jednodušší, protože se stačí zaměřit na bežné jevy a speciální případy ošetřit v C# nebo jiném vhodném jazyce. Postupně můžeme přidávat počet situací, které jsou v našem DSL řešeny, nebo dokonce můžeme časem implementovat framework pro interpretaci za běhu, ale nebrání nám to začít v malém.

A nyní, milé děti, můžeme plně ocenit sílu language workbenches jako je DSL Tools pro Visual Studio: Jsou to externí jazyky, kde máme syntaxi plně pod kontrolou, máme k disposici parser a generátor, prvotřídní integraci do vývojového prostředí, a navíc grafický editor s předpřipraveným systémem validace modelu, který můžeme upravovat dle libosti. Programátorský Eden. Jediné co chybí je standardní způsob slučování více modelů do jednoho, ale to lze poměrně jednoduše obejít. O tom ale jindy.

Model Driven Development v praxi

2009-03-14T23:26:00.020+01:00

Přeskočit přímo na video

Kolem modelování v software už byla napsána a řečena spousta vznešených slov (třeba zde). Podívejme se proto na jednoduchý způsob, jak ho implementovat v praxi.

Příklad

Máme webovou aplikaci (např. online shop), která ukládá data do databáze. Aplikační logika je implementována jako domain model, takže pro každou "entitu" v reálném světě (klient, produkt, objednávka atd.) existuje v aplikační vrstvě třída. Objekty jsou do databáze mapovány pomocí NHibernate.

A nyní si představte, že do objednávky budete chtít přidat další údaj, kontaktní telefon. Maximální počet znaků je 9. Musíte editovat webovou stránku s formulářem objednávky, musíte přidat javascriptový validátor, přidat property Phone do třídy Order a rozšířit její validační metodu, do mapovacího souboru Order.hbm.xml doplnit <property name="Phone" type="string" length="9" not-null="true" /> a do databázové tabulky tblOrder přidat sloupec Phone NVARCHAR(20) NOT NULL. Dost práce, navíc spousta duplicity, že? A po týdnu zjistíte, že telefon se do 9-ti znaků nevejde (národní předvolby) a rozhodnete se zvětšit délku údaje na 20 znaků. Budete opět muset upravit všechna zmíněná místa, na žádné nezapomenout a neudělat překlep.

Model

Přitom se stále jedná o jeden logický koncept: Objednávka má pole telefon s délkou 20 znaků. Daleko rozumnější by proto bylo udržovat tyto definice na jednom místě ("model" naší aplikace) a ostatní "artefakty" (části kódu) generovat automaticky. Vymyslíme tedy způsob zápisu, jak model definovat, vytvoříme model naší aplikace a pak ho budeme nějak parsovat a podle nějakých šablon generovat artefakty kódu. Způsob zápisu modelu je náš doménově-specifický jazyk (DSL), který umožňuje zachycovat entity z domain modelu aplikace.

Nabízí se tři řešení, jak to udělat: Vlastní implementace, univerzální CASE nástroj, nebo použít existující "language workbench".

Vlastní implementace vypadá jednoduše: Uděláme nějaký "texťák" (céčkař) nebo "iks-em-elko" (dotneťák) a napíšeme si jednoduchou utilitku, která ho přečte a na stanovená místa vyplivne kód, v lepším případě pomocí nějakých šablon (např. XSLT). Jenže model bude mít velmi mnoho vlastností a mezi prvky modelu budou vztahy které nelze definovat jinak než pomocí nějakých "ídéček". Ze začátku jednoduché jak facka, ale až model naroste, bude velmi nepřehledný a udržovat ho bude dost pracné. Takže se uchýlíte k tomu, že ve svém volném čase budete psát další utilitky pro kontrolu modelu, prohlížení modelu s navigací po vztazích mezi entitami, editor se zvýrazňováním syntaxe atd. To vám zabírá čas který by jste měli věnovat učení se novým technologiím. Výsledek nestojí za to, veřte mi, zkusil jsem to:-) Navíc ztrácíte podporu internetové komunity, čímž se okrádáte o nejrychlejší způsob řešení problémů - gůglení.

Velmi svůdné řešení je použít nějaký CASE nástroj, nejspíš na bázi UML. Jejich nevýhoda ale je, že jsou příliš univerzální, takže 90% jejich fíčur vůbec nepoužijete, a naopak když budete potřebovat něco trochu jiného než program umožňuje, budete vymýšlet nejrůznější hacky jak to udělat, což opět znepřehledňuje model. Výsledkem je velmi vratký rovnák na vohejbák (věřte mi, také jsem se o to pokoušel). Dále se připravte na to, že tyto nástroje mají obvykle strmou učící křivku (zná někdo lepší překlad "steep learning curve"?), že budete muset zjistit jak to integrovat s vaším IDE a že každý vývojář bude potřebovat placenou kopii nástroje.

"Language workbench" je Fowlerův termín pro sadu nástrojů, které usnadňují tvorbu vlastních DSL jazyků. Plurál je na místě, pro každý účel můžete vytvořit speciální jazyk přesně na míru problému, daleko vhodnější než různě přiohnuté UML. Tyto nástroje zahrnují tvorbu jazyka, práci s modelem, generování artefaktů z modelu a integrace do IDE. Je to nejlepší z obou světů: Snadno vytvoříme jazyk přímo pro konkrétní účel včetně generování artefaktů, a přitom máme k disposici nástroje a internetovou komunitu. Navíc můžeme jazyk tvořit inkrementálně, začít skromě a postupně přidávat funkčnost podle potřeby, tam kde se ukáže že je to možné a přínosné. Tak si v našem příkladě můžeme vytvořit doménový jazyk pro definici entit a jejich vlastností, a později přidat "constraints", např. minimální a maximální hodnoty vlastnosti, a upravit šablony aby generovaly validační kód na všechny vrstvy kde je potřeba.

Osobně vím o dvou takových "workbenchích", jedna je Meta Programming System od JetBrains (stále ještě v beta), druhá DSL Tools od Microsoftu, součást Visual Studio SDK. První jsem nezkusil, ale pokud programujete v javě a používáte IDEA, asi by to stálo za pokus. Druhou používáme v praxi pro definování aplikačního domain modelu a generování SQL, HBM, domain tříd, Repository, Query a DTO tříd. Podle constraints definovaných v modelu jsme schopni nagenerovat i základní klientské validátory v javascriptu.

DSL Tools

Po zdlouhavém úvodu se konečně dostáváme k věci. Protože je na českém internetu velmi málo zdrojů o DSL Tools, pokusil jsem se natočit vlastní screencast pro začátečníky. Má vás přenést přes vstupní bariéru a předvést základní kroky, které jsou nutné k vytvoření jednoduchého DSL jazyka. Sám jsem na začátku dost tápal, tak doufám že vám to ulehčí start. Je to můj první screencast, tak buďte prosím shovívaví (ano, dělám si alibi:-). DSL Tools jsou součástí Visual Studio SDK a k vytváření jazyků je potřeba Professional edice. Pak je možné vytvořit add-in package do Visual Studia a k běžné práci s modelem by měla stačit Standard edice bez nutnosti instalovat SDK (modelovací runtime je od verze 2008 součástí Visual Studia). Zásahů do jazyka je potřeba poměrně málo, protože většinu problémů vyřešíte pouhou změnou tt šablony.

Ve videu uvidíte, jak se nejdřív definuje DSL jazyk, a jak se vyzkouší v nové instanci Visual Studia. Kód se generuje pomocí T4 a zvýraznění syntaxe poskytuje Clarius T4 Editor (plugin do Visual Studia).

Jakmile překonáte vstupní bariéru, vše půjde hladce. Na netu jsou dostupná další videa v angličtině, doporučuju také blog Olega Sycha který se věnuje generování artefaktů pomocí T4 šablon a zná spoustu fíglů. Pokud to s DSL myslíte vážně, kupte si knížku Domain-Specific Development with Visual Studio DSL Tools, to je asi nejlepší existující dokumentace.

A co mám na DSL Tools nejradši? Že prostředí, ve kterém vytváříte váš DSL jazyk, je samo doménově-specifickým jazykem pro modelování DSL jazyků:-) Jinými slovy, meta-modelování a modelování používá totožný modelovací runtime. To co vytváříte v DSL projektu v souboru DslDefinition.dsl, je model vašeho jazyka, který je následně transformován pomocí tt šablon na C# kód, přeložen, nainstalován do experimental hive Visual Studia. Stejně pak funguje váš jazyk: Umožňuje vytvořit model, transformovat na kód, zkompilovat a spustit. Znamená to také, že váš DSL jazyk můžete lehce customizovat pomocí partial a double derived tříd. Není to žádný trik, ale starý dobrý C#. Dál to taky znamená, že vše co vidíte v DslDefinition.dsl (vzhled a layout diagramu, editory vlastností, validace modelu atd.) můžete použít i ve svém jazyku. Můžete si být jistí proto, že váš model poběží na stejném runtime jako designer DSL jazyka.

Solution vytvořené ve videu: SampleDsl.zip

O čem bych chtěl psát ale nemám na to čas

2009-02-07T14:55:00.004+01:00

Od mého posledního ublognutí uplynulo mnoho LOC. Není to tím že bych neměl o čem psát, ale nějak se mi nedostává času. Tak alespoň ve stručnosti, na čem pracuju a o čem bych si v budoucnu chtěl ublognout:

Codename Ginger: Aplikační framework pro tvorbu distribuovaných (nejen) webových aplikací. Řeší architektonický základ takové aplikace: rozdělení do vrstev a vrstev (v češtině se dost špatně rozlišuje layer a tier), jazyk pro modelování domény vytvořený pomocí DSL Tools, generování různých artefaktů jako skriptů pro vytvoření databáze, mapovacích souborů, doménových a DTO objektů přímo z modelu pomocí T4. Není to žádná chiméra, máme reálně fungující a solidně protestovanou verzi a vyvíjíme v tom komerční aplikace. Na webové vrstvě používáme ASP.NET MVC, na datové NHibernate a trochu jsme to okořenili Spring.Net (ale jen s citem). Velkou inspirací pro nás je NServiceBus a pak samozřejmě bible enterprise aplikací Patterns of EAA od Martina Fowlera.

WPF: Celkem dlouho jsem tuto technologii ignoroval, protože jsem někde četl že v ní není DataGrid. Hrozná chyba! Příliš mnoho času jsem strávil ve Windows Forms, takže jsem si nedokázal představit, jak flexibilní může být UI framework. Teď si to vynahrazuju. Jsem nadšen ze stylování, data bindingu a content modelu. Kromě toho, že v tom nejdou kloudně zobrazovat bitmapy, je to naprosté programátorské blaho.

Scrum: Snažím se v práci prosadit, abychom v příští verzi našeho produktu nasadili tuto metodologii. Máme trochu problém s plánováním, termíny a komunikací, a od Scrumu si slibuju, že budeme mít přesnější představu jak na tom jsme, zpřesníme plánování, díky projektovým tymům usnadníme komunikaci, vývojáři se budou moct lépe soustředit na výsledek a díky tomu také zvedneme kvalitu našeho kódu. Nehledě na to, že nás to bude víc bavit:-) Teorie je na webu dost, ale našel jsem super knížku, která se věnuje praktické realizaci. Je zdarma, tak neváhejte a stahujte, je opravdu dobrá. Doufám že to vyjde a že budu moct časem ublognout jak nám to jde.

Tak to je ve zkratce všechno, mám v hlavě sice daleko víc nápadů, ale den má jen 24 hodin:-)

Jak programovat bez ega

2008-08-28T22:34:00.005+02:00

Přestože mnozí věří, že programování je exaktní věda, ve skutečnosti má blíž k literatuře. Program se nedá vypočítat, program se musí napsat. Programátor musí, stejně jako spisovatel, psát jazykem kterému rozumí ostatní programátoři a dodržovat určitá stylistická pravidla. Počítačové jazyky totiž existují kvůli lidem a ne kvůli počítačům, ty by se spokojily s nulami a jedničkami. Větší pozornost je sice nutné věnovat kritickým (napínavým) úsekům, ale pokud autor ztratí ze zřetele soudržnost celku, výsledkem bude škvár, který sice možná bude sdělovat příběh, ale prokousat se jím bude peklo.

Na rozdíl od spisovatelů jsou však programátoři nuceni pracovat v týmech. Mají tak problémy, kteří spisovatelé vůbec neznají. Některé jsou technického rázu a jdou celkem uspokojivě vyřešit, např. jak spojovat kusy napsané různými autory do jednoho celku (VCS). Horší vznikají tím, že programátoři jsou lidi. Lidská interakce je nesmírně složitá a ke strojové přesnosti a neutrálnosti má na hony daleko. Představte si to, kvůli mezilidským vztahům dokonce vzniklo několik vědních oborů (sociologie, psychologie, psychiatrie, politologie, ekonomie atd.)! Manažeři programátorů se navíc často domnívají, že se pohybují ve výhradně technické oblasti, a tak mohou problémy druhého typu v klidu nepovšimnuty bujet a stávat se patologickými. Ale to je jiná kapitola.

Dnes se chci věnovat jedné vlastnosti, kterou mají programátoři se spisovateli společnou. Každý autor, ať už píše cokoliv, se se svým dílkem ztotožňuje. Je to naprosto přirozené: Trávíte s ním spoustu času, stojí vás mnoho úsilí a chcete aby se mu dařilo co nejlépe. Když pak přijde kritika, ať už oprávněná nebo ne, je těžké ji přijmout s chladnou hlavou. U spisovatelů to vede k úsměvným historkám ve společenských časopisech, u programátorů k frustraci a nepřátelství. A protože se programátoři potkávají v práci každý den, je to pro ně daleko horší problém než pro spisovatele. Pak je ale těžké napsat dobrý program.

Jak tedy programovat bez ega? V první řadě musí člověk přijmout fakt, že se může mýlit. Vždy se najde někdo, kdo o daném problému ví víc než vy. Zvlášť když strávíte se svým produktem delší dobu, je těžké najít odstup a snadno pak přehlédnete i očividné chyby. Pravdu naopak mohou mít i lidé, od nichž by to člověk vůbec nečekal. A tak nezbývá než věnovat pozornost každé výtce, ať už pochází z jakéhokoliv zdroje.

A opačně, pokud kritizujeme, snažme se nedotknout se osobnosti autora kódu. Kritizujte kód, ne jeho autora. Snažte se navrhovat, jakým způsobem lze kód vylepšit. Pokud je to možné, opřete se o fakta (standardy, měření, literatura, články na webu, dohodnuté konvence atd.). Destruktivní kritika typu "seš snad úplně blbej" nebo "všechno stojí za hovno" nikam nevede, jen šíří pocity zoufalství. Zkuste odhadnout, kolik toho ten druhý "skousne" a buďte hodní na kolegy, kteří nemají takové sebevědomí. To, že má někdo méně zkušeností nebo znalostí neznamená, že je horší než vy. Navíc za rok může být situace klidně opačná. Pokud tým funguje, jeho členové jsou schopni se navzájem učit a mají ze spolupráce dobrý pocit.

Aby se programátoři nestyděli zeptat se kolegy o radu, musí v týmu panovat přesvědčení, že mýlit se je lidské a že víc hlav víc ví. Každý má občas špatný den a jediné co se s tím dá dělat, je umožnit, aby se na chyby přišlo co nejdříve. Dobrou pomůckou mohou být techniky z extrémního programování, jako párové programování, code review, kolektivní vlastnictví kódu a stand-up meetingy (také známé jako scrum). Mám ale obavu, že prvotní je dobrý výběr lidí; nehledět při náboru pouze na technické znalosti, ale i na to, zda je přijímaný člověk týmový hráč. Pokud máte tým složený ze samých "hyper-senzitivních code-machines", žádné metodologie vám asi nepomůžou.

Já sám osobně mám pocit, že už dokážu obstojně snášet kritiku kódu, který jsem napsal. Kritizovat kód kolegů mně ale stále nejde tak, jak bych si představoval. Je těžké vybrat správná slova, aby druhý pochopil, že ho nechci urazit ani snížit jeho zásluhy. Někdy mě zradí jazyk, někdy se moc rozohním, někdy toho mám prostě dost a někdy zafunguje ponorková nemoc, protože pracuju ve firmě, kde jsou trvalé týmy - roky sedíte v kanceláři se stejnými lidmi. Tímto se proto omlouvám každému, koho jsem kdy mohl urazit a chci aby jste věděli, že kašlu na to kdo je autorem, zajímá mě pouze kód a aby byl dobrý.

Ještě poznámka na závěr: Zajímavá je souvislost s jiným principem efektivního programování: Ukazuje se totiž, že programovat bez ega znamená napsat pouze tolik, kolik situace vyžaduje - ne méně a ne více. Nemá prostě cenu vymýšlet všechny varianty, které by po nás mohl uživatel teoreticky chtít, a potom napsat nějaké úžasně univerzální über-řešení; lepší je napsat program, který řeší pouze aktuální problém, a pokud bude potřeba, bude se průběžně doplňovat a zesložiťovat. Je to staré pravidlo YAGNI (You Ain't Gonna Need It), které jinými slovy říká, že i když jste bůhvíjak dobří programátoři, nesmíte se bát obyčejných jednoduchých řešení - není to ostuda.

Egoless Programming
Ten Commandments of Egoless Programming

Ornament a kód

2008-07-26T00:20:00.005+02:00

Ornament je zločin, vytanula mi na mysl slova Adolfa Loose, když jsem brousil starou olouhovanou skříň. Má totiž několik ozdobných vlnek, které bylo potřeba pracně ručně obrušovat každou zvlášť. A pak mě napadlo, že to vlastně platí víc v programování než v architektuře.

Nejdřív mi dovolte stručné vysvětlení úvodního citátu (čtenáři s humanitním vzděláním laskavě prominou):

Moderní architekti prohlásili dům za stroj na bydlení (*1). Architektura podle nich není umění, ale věda o bydlení, která má upravit hmotné prostředí potřebám lidského živočicha. Nenávist k ornamentu je logickým důsledkem tohoto názoru - vždyť k čemu jsou lidem propracované ozdobičky, když vše co potřebují je čerstvý vzduch, dostatek slunce, teplo a bydlení v obytné zóně bez továren? "Less is more" (Mies van der Rohe) se stalo heslem několika generací architektů. Le Corbusier řekl: „Dekorace je smyslné a primitivní povahy, stejně jako barva, a hodí se toliko pro nižší třídy, sedláky a divochy.“

copyright Jeffery Howe

Adolf Loos i Le Corbusier sice zapomněli že lidé v domech nejen bydlí, ale také chodí kolem, přesto však udělali se svým názorem díru do světa. Podařilo se jim přesvědčit ostatní o své pravdě a nadlouho ovlivnili myšlení architektů a urbanistů na celém světě. Důsledky známe i u nás v podobě uniformních panelových sídlišť, které přímo vycházejí z jejich ideálů - i když s jejich provedením by asi Le Corbusier nesouhlasil. Konec dominance funkcionalistické architektury znamenal až nástup postmoderny v šedesátých letech a "less is more" nahradil Robert Venturi heslem "less is bore".

copyright tato grasso

A jak to souvisí s programováním? Každý, kdo někdy četl cizí kód, si hned všimne nezvyklých konstrukcí a způsobu formátování kódu. Někdy zaujme precizní tabulární formátování, někdy tvrdošíjná maďarská notace, jindy zas poznámky ve kterých vede programátor dialog sám se sebou. To vše odvádí pozornost čtenáře od funkce k formě. Nejsou to snad ornamenty?

Zdálo by se že tu ornamenty hájím, protože vnášejí krásu do všednosti, vítané potěšení znavenému duchu. Jenže mezi programováním a architekturou je jeden podstatný rozdíl. Architekt musí počítat s tím, že kolem jeho děl budou chodit i laici, kteří o zločinnosti ornamentu nemají nejmenšího tušení. Architekt by měl prostředí ušít na míru všem, nejen kolegům z branže a odborné kritice. Vhodně zvolený ornament pak může sloužit jako vodítko i (z architektova hlediska) nevzdělanému tupci, který by jinak jeho střízlivý obytný dům mohl považovat za vězení.

Kolem vašeho kódu ale laici chodit nebudou. Váš kód se dostane do ruky úzké skupině lidí s (někdy až příliš) specializovaným výcvikem, kteří budou mít za úkol se v něm zorientovat a provést potřebné změny. Pro ně je jakýkoliv ornament zdržením. Nejčitelnější kód je takový, který se striktně drží stanovených konvencí. Kód by měl vypadat tak, jako kdyby ho napsal jeden programátor během jednoho sezení.

Ornament v kódu je jakékoliv porušení stanovených konvencí. Napíšete-li kus kódu jinak, než je ve vašem týmu obvyklé, nutíte kolegy aby při čtení této části kódu přemýšleli ne o tom, co kód dělá, ale o jeho formátování - proč je zapsán tímto neobvyklým způsobem? Je za tím nějaká myšlenka, která mi uniká? Něco na co chtěl autor upozornit? Bohužel, většinou se jedná jen o neznalost konvencí, okamžitý nápad jak kód napsat "lépe" (v lepším případě), nebo o přesvědčení autora že jeho konvence jsou lepší a ostatní by je měli přijmout.

Jak mají vypadat konvence psaní kódu je sice sporná věc, ale jakmile se na nějakých shodnete, je nutné je dodržovat. Osobně preferuju držet se výchozích nastavení Visual Studia a ReSharperu. Proč pracně přenastavovat něco, co používají tisíce programátorů na celém světě? Tím odpadne mnoho diskusí ohledně formátování závorek a mezer kolem operátorů. Mnoho dalších věcí za vás nástroje nevyřeší (jmenné konvence, pořadí prvků atd.), ale na internetu je spoustu zdrojů a vzorových "code conventions" dokumentů i pro váš programovací jazyk.

Kód odpovídá strukturálním a technickým stránkám budovy. Je to nosný systém, vodotěsné zastřešení, rozvody energie a vody, výtahy. Pokud chcete postavit dobrý dům, je bezpodmínečně nutné udělat tyto základní věci dobře a umožnit údržbářům snadný přístup ke všem důležitým bodům. Na stavbě si nemůžete vymyslet svůj vlastní a zcela nový systém elektrických rozvodů a pojistek, nedělejte to ani v kódu. Na Grand Prix Obce architektů to sice nestačí, ale bez dobrého základu nepostavíte ani kůlnu. Dodržování konvencí zdaleka není všechno, ale usnadní život vašim kolegům (a také vám, až se budete za rok divit proč jste to tenkrát takhle napsali). Nechte si ornamenty do uživatelského rozhraní, ve stylistické úpravě kódu platí "bore is more".

*1 Le Corbusier ([1923] 1952): Towards a New Architecture. London
*2 http://cs.wikipedia.org/wiki/Funkcionalismus

UPDATED: 2008-07-26 Přidány citáty Mies van der Rohe a Roberta Venturiho.

Přednáška o CruiseControl.Net a MSBuild

2008-07-09T22:31:00.002+02:00

Dneska jsem dělal interní přednášku pro kolegy ve firmě o průběžné integraci s pomocí CruiseControl.Net a MSBuild, a o našem build systému postaveném na těchto technologiích. PowerPointovou prezentaci si díky laskavému svolení mého zaměstnavatele můžete stáhnout zde.

Jediné co nám chybí k dokonalému build systému je Big Visible Cruise nebo The Orb. Ale až budu mít trochu času, chtěl bych nějakou takovou hračku pořídit;)

Jak udělat espresso

2008-06-24T17:43:00.002+02:00

Protože mně Nikdo předal štafetu, tady je moje oblíbené video: Jak správně na espresso. Mimochodem, mají tam nádhernou mašinku. Jednou bych chtěl takovou doma:-)

Kafe které tam používají (Ethiopia Sidamo) se dá sehnat i u nás, např. já ho kupuju v Mama Coffee kde ho mají v super kvalitě a za rozumnou cenu.

Když Já není Já

2008-06-20T08:13:00.004+02:00

Nebojte, nebudu tu rozebírat schizofrenní poruchy vyvolané dlouhodobým zíráním do monitoru. Jde o klíčové slovo this v C# a o jeden zajímavý případ, kdy this není this, nebo alespoň není to this, které jsme si mysleli že bude.

Pro začátek si představte, že máte dva objekty, mezi kterými je obousměrná vazba 1-N. Například User a Task, tedy uživatel a jeho úkoly, kde úkol může být přidělen nejvýše jednomu uživateli:


public class User 
{
 IList _tasks;
 public IList Tasks
 {
  get { return _tasks; }
  set { _tasks = value; }
 }
}

public class Task
{
 User _holder;
 public User Holder
 {
  get { return _holder; }
  set { _holder = value; }
 }

 ... etc ...
}

Protože nepracujeme ve státním sektoru, Tasků je hodně a je nutné, aby si naše aplikace pamatovala úkoly uživatelů i zítra. Použijeme tedy nějakou databázi; tím myslím existující databázový systém, který si stáhneme z internetu (MS SQL Express, MySQL apod.). Nezačneme tedy implementací vlastního RDMS, ani nebudeme simulovat databázi pomocí mnoha XML souborů uložených kdesi na disku (asi se divíte proč se s tím tak rozepisuju, ale nevěřili by jste, kolik lidí nemá rádo databáze, co si sami nenapsali).

A protože jsme vychytralí, použijeme nějaký O/RM nástroj pro mapování objektů do databáze. A jelikož nejsme bohatí, bude to NHibernate, který je zdarma, a podporuje víc databází než LINQ to SQL (navíc jsme chudí takže stále pracujeme ve Visual Studiu 2005 kde není podpora lambda výrazů).

Když budeme tedy chtít přiřadit Task nějakému uživateli, náš kód bude vypadat nějak takhle:


...
// odněkud vytáhneme volný Task
Task task = TaskRepository.GetNextUnassignedTask();
// najdeme uživatele, který nemá co na práci
User user = UserRepository.GetUserReadingBlogsButNotMine();
// a dáme mu úkol, ať se snaží hošánek (nebo frajerka)
task.Holder = user;
user.Tasks.Add(task); // zachováme obousměrnost vazby, aby se další kód mohl bez problémů odkazovat na user.Tasks
...

Ha. Funguje to. Něco tu ale smrdí. Ano, jsou to ty dva řádky, které nastavují vazbu mezi Userem a Taskem. Nestačil by jeden? Jak známe kolegu X., určitě někde druhý řádek zapomene (nám by se to samozřejmě nestalo), a pak bude od tohoto bodu dále v paměti strašit inkonzistence dat, až do ukončení databázové ISession. Pak může snadno nastat chyba úplně na jiném místě a než na to přijdeme, ujmou se nás psychoterapeuti. Zkusíme tedy, ach my bláhoví, upravit property Holder:


public class Task
{
 User _holder;
 public User Holder
 {
  get { return _holder; }
  set {
   if(_holder!=value)
   {
    if(_holder!=null)
     _holder.Tasks.Remove(this);
    _holder = value; 
    if(_holder!=null)
     _holder.Tasks.Add(this);
   }
  }
 }

 ... etc ...
}

Ponechme teď stranou fakt, že pokud to samé uděláme v User.Tasks.Add(), nastane nekonečná smyčka kterou ukončí až milosrdné přetečení zásobníku nebo jiná populární výjimka (ve skutečnosti budeme chtít z objektu User publikovat pouze read-only wrapper kolekce Tasks, protože to bude inverzní konec asociace, který není ukládán do databáze). Přejděme mlčky i problém inicializace objektu Task při jeho nahrávání z databáze, kdy kolekce _holder.Task ještě nebude inicializovaná a přidáním tasku do ní si připravíme pozdější muka při nahrávání kolekce z databáze (to se dá řešit, viz např. třída PersistentGenericBag<T> a její metoda DelayedAddAll v NHibernate).

Leč je tu ještě daleko zákeřnější past: this není this které potřebujeme. Jak je to možné? Protože používáme lazy loading našich objektů. Je velmi pravděpodobné, že místo objektu task dostaneme proxy objektu task. Náš milý task proto nebude instance typu Task, ale typu s krásným názvem CProxyTypeTest_BidirectionalTestTaskDomain_NHibernate_ProxyINHibernateProxy1, nebo podobně pojmenovaného. Tento typ je dynamicky vygenerovaný potomek našeho typu Task a slouží jako proxy, která nahraje task z databáze teprve když je to potřeba. Když je proxy třída odvozená z naší třídy, v čem je tedy problém? V tom, že objekt task NENÍ proxy objekt; v programátorštině mezi nimi není referenční identita. Proxy objekt totiž neukládá data do sebe, ale obsahuje referenci na náš objekt a přeposílá mu veškerá volání metod a vlastností (a zpátky předává návratovou hodnotu). Aby to nebylo tak jednoduché, mezi proxy a naším taskem stojí ještě další objekt, tentokrát typu CastleLazyInitializer z NHibernate. Ale to už zabíhám do detailů.

Podívejme se teď znovu na první verzi kódu a přidejme jednu celkem logickou kontrolu výsledku:


...
// odněkud vytáhneme volný Task
Task task = TaskRepository.GetNextUnassignedTask(); // vrací proxy objektu Task
// najdeme uživatele, který nemá co na práci
User user = UserRepository.GetUserReadingBlogsButNotMine();
// a dáme mu úkol, ať se snaží hošánek (nebo frajerka)
task.Holder = user;
user.Tasks.Add(task); // do user.Tasks přidáváme proxy objektu Task
// zkontrolujeme zda je task součást uživatelových úkolů
Assert.IsTrue(user.Tasks.Contains(task)); // OK
...

Protože se NHibernate chová jako správná Identity Map, vrací v rámci jedné session reference konzistentně, tj. pokud se na několika místech budete dotazovat různým způsobem na jeden Task, dostanete vždy odkaz buď na objekt samotný, nebo na stejnou proxy; mezi vrácenými objekty funguje referenční integrita. To znamená, že user.Tasks.Contains(task) bude fungovat a vrátí správně true.

A nyní se podívejme, co se stane když necháme přidání tasku do kolekce na property setteru Holder:


...
// odněkud vytáhneme volný Task
Task task = TaskRepository.GetNextUnassignedTask(); // vrací proxy objektu Task
// najdeme uživatele, který nemá co na práci
User user = UserRepository.GetUserReadingBlogsButNotMine();
// a dáme mu úkol, ať se snaží hošánek (nebo frajerka)
task.Holder = user; // task je proxy, ve skutečnosti zprostředkuje volání property setteru našeho objektu
// zkontrolujeme zda je task součást uživatelových úkolů
Assert.IsTrue(user.Tasks.Contains(task)); // FAIL!!!
...

A zde je jádro pudla: co se ve skutečnosti stane se dá opsat jako task.ProxiedObject.Holder = user;. Uvnitř property setteru Holder proto this ukazuje na náš objekt, ne na proxy. Do kolekce user.Tasks se přidá náš objekt Task, ne proxy v proměnné task. Vypadá to celkem nevinně, protože v tu chvíli už bude náš objekt inicializovaný (přistupujeme na property task.Holder), ale je nutné si uvědomit, že přestává fungovat referenční integrita a tím porušujeme správné fungování Identity Map. Volání metody user.Tasks.Contains(task) na dalším řádku vrátí false, přesto že je náš objekt Task v kolekci a v proměnné task je proxy ukazující na náš objekt. Kolekce user.Tasks prostě obsahuje task.ProxiedObject a ne task.

Zajímavé je podívat se na stack trace v property setteru Task.Holder. Ukazuje, jak se jednoduché volání task.Holder přesměruje přes proxy a interceptor (CastleLazyInitializer):

BidirectionalTest.dll!BidirectionalTest.Task.Holder.set(BidirectionalTest.User value = {BidirectionalTest.User}) Line xxx C#

[Native to Managed Transition]

[Managed to Native Transition]

Castle.DynamicProxy.dll!Castle.DynamicProxy.Invocation.AbstractInvocation.Proceed(object[] args = {Dimensions:[1]}) + 0x76 bytes

NHibernate.dll!NHibernate.Proxy.CastleLazyInitializer.Intercept(Castle.DynamicProxy.IInvocation invocation = {Castle.DynamicProxy.Invocation.SameClassInvocation}, object[] args = {Dimensions:[1]}) + 0xc5 bytes

DynamicAssemblyProxyGen!CProxyTypeTest_BidirectionalTestTaskDomain_NHibernate_ProxyINHibernateProxy1.Holder.set(BidirectionalTest.User value = {BidirectionalTest.User}) + 0xb3 bytes

BidirectionalTest.dll!BidirectionalTest.Bidirectional1NIntegrationTest.Update_ChangesTargetCollection() Line 77 + 0xb bytes C#

A nyní možná trochu překvapivý závěr: Celou tuhle anabázi jsme podstoupili jen proto, že nám nevoněl jeden řádek navíc. Protože se ale synchronizace druhých konců obousměrných asociací (to samé platí i pro many-to-many) ukázala jako plná mnoha problémů, zatím její řešení odsouvám na neurčito. Nemám čas zabývat se problémy, pro které existuje tak jednoduchý workaround. Nejde jen o proxy, ale také o read-only wrappery inverzních konců, rekurzivní smyčky a load time vs. run time, ale také o vlastní typy persistentních kolekcí implementujících IList<T> (místo PersistentGenericBag<T> a spol.), pokud bychom chtěli synchronizovat druhý konec many-to-many asociace při volání Add a Remove (i to je v NHibernate možné, ale je to trochu kostrbaté).

Navíc je tu ještě jedno hledisko, performance. Je třeba si uvědomit, že pokud odebírám prvek z inverzního konce kolekce (nebo přidávám prvek v případě set a idbag), je nutné nejdřív tuto kolekci načíst do paměti, a to většinou zcela zbytečně! Inverzní konce se totiž nijak neukládají. Problém pak ale zůstává, jak chránit další kód ve stejné session proti nekonzistenci dat.

Budu rád pokud zjistím že se pletu a někdo mi napíše jednoduchý způsob jak v NHibernate synchronizaci provést.

NHibernate, lazy proxy třídy a chyba C# kompilátoru

2007-09-14T16:17:00.000+02:00

Kompilátor C# v .NET verze 2.0 obsahuje chybu, díky které při použití where T : class pro omezení typového parametru generické třídy vygeneruje špatný IL kód. Díky tomu se takovou assembly vůbec nepodaří nahrát do paměti, runtime vyhodí výjimku:

System.BadImageFormatException: An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)

Popis naleznete na Microsoftu nebo taky na Ayendeho blogu.

Když používáte NHibernate, a zvlášť pokud jste právě přešli na verzi 1.2, může se tato výjimka objevit i když vůbec where T : class nepoužijete. Jak to? NHibernate vám při načtení objektu může místo vaší třídy vrátit dynamicky generovanou proxy třídu (a ve verzi 1.2 je to default). V ní jsou všechny virtual members nahrazeny proxy metodou, která při prvním přístupu k objektu tento objekt načte z databáze (materializuje). No a když ve vašem objektu použijete virtuální metodu s generickým parametrem, např:


protected virtual T GetProperty<T>(string name)
{
    ...
}

snadno se dopracujete k výše zmíněné výjimce. Je to pravděpodobně (hlouběji jsem to nezkoumal) způsobeno tím, že generátor dynamické proxy třídy (Castle.DynamicProxy.dll) se pokouší emitovat kód, který podmínku where T : class obsahuje, a pokus nahrát tuto třídu do paměti skončí s chybou. Proto používáte-li NHibernate a "lazy" načítání objektů, nepoužívejte virtuální generické metody.

Jak může GridView přijít o ViewState

2007-04-16T11:12:00.000+02:00

Aneb o side-effectech, CompositeDataBoundControl-ech a Watch okně.

Minulý týden jsem řešil zapeklitý problém: GridView občas při postbacku ztratilo řádky, tj. nenačetlo je správně z ViewState. Ovládací prvek, ve kterém bylo GridView použito, přitom na jiných webových stránkách fungoval bez problémů.

Nejdřív jsem pátral po vytváření ViewState a jeho ukládání do stránky a načítání při postbacku. Máme totiž poměrně složitou infrastrukturu odvozenou od třídy Page, která se nechová úplně standardně a občas vyvádí psí kusy. Jenže se to ukázalo jako špatná stopa: ViewState byl normálně uložen a přítomen ve skrytém poli v postbacku. Jeho struktura vypadala dobře, zdálo se, že jej prostě GridView ignoruje.

Trochu jsem se porejpal ve zdrojových kódech .NETu (God Bless The Reflector) a přišel jsem na to, že GridView má dceřinný ovládací prvek typu Table, který při postbacku dostane svůj ViewState a stará se o správnou rekonstrukci řádek tabulky. To znamená, že tento dceřinný prvek musí být vytvořen nejpozději v OnLoad. Jenže na mé stránce měl v události OnLoad můj GridView prázdnou kolekci Controls, ale přitom jeho ChildControlsCreated bylo true. Když neexistuje dceřinný prvek Table, nemá ani co nahrát ViewState.

Zajímavé přitom bylo, že pokud jsem ve Watch okně Visual Studia změnil ChildControlsCreated na false, okamžitě se přepsalo zpět na true a do kolekce Controls se přidal prvek typu Table! Chvíli jsem přemýšlel o woodoo a černé magii, pak jsem si ale prošel seznam ostatních položek ve Watch okně a začal jsem je zkoumat. Na první pohled nic podezdřelého neobsahovalo. Když jsem z něj ale odebral položku Controls.Count, toto podivné chování ustalo a ChildControlsCreated se klidně nechalo nastavit na false.

Vrátil jsem se proto s Reflectorem do kódu a našel jsem zajímavý side effect při přistupování na kolekci Controls, zavedený třídou CompositeDataBoundControl: Před vrácením kolekce se volá EnsureChildControls()! To vysvětluje ono podivné chování ve Watch okně, kde jsem měl kromě jiného i Controls.Count. Když jsem přepsal ChildControlsCreated na false, Visual Studio se pokusilo o refresh všech položek Watch okna, takže přístupem na kolekci Controls spustilo i metodu EnsureChildControls(), která nastavila ChildControlsCreated zpět na true.

A bylo jasno! Pokud přistoupím na kolekci Controls před natažením ViewState (tedy před OnLoad), způsobím volání metody EnsureChildControls(). Ta zavolá CreateChildControls(), ale pouze při prvním spuštění. No a CreateChildControls() nevytvoří žádný ovládací prvek, pokud nemá k disposici ViewState! Takže GridView nemá dceřinný prvek Table který načítá ViewState a ani jej nevytvoří, protože už je označená jako ChildControlsCreated=true.

Z toho, děti, plynou následující poučení:

Používáte-li ViewState, nepřistupujte na kolekci Controls před událostí OnLoad. Platí to pro všechny potomky CompositeDataBoundControl, tedy GridView, FormView a DetailsView.

Dávejte si pozor na to, co máte ve Watch okně, neboť to může mít (blahý i neblahý) efekt na běh kódu.

PS: Poslal jsem to jako bug na Microsoft, jsem zvědavej jak se s tím hoši poperou.
PPS: Nemusej to bejt jen hoši, koukal jsem nedávno na jeden rozhovor na Channel9 s Politou Paulus a má na stole (teda na okně:-) ocenění za návrh architektury DataBoundControls, takže možná je to její práce.

Jak retardovat VS2005

2006-09-19T12:22:00.000+02:00

Visual Studio 2003 blahé paměti, nechť je mu země lehká, automaticky označovalo právě otevřený soubor v Solution Exploreru. Mnoho lidí na to nadávalo, protože stojíc v nějaké složce otevřeli jiný soubor a Solution Explorer uskočil někam hentam onam, takže pak museli pracně hledat původní složku na kterou se dívali.

Softwareový bůh je vyslyšel a v novém Visual Studiu 2005 chování toto zrušil. Ale ajta: našli se mnozí tací, které bylo slyšeti oplakávajíc fíčury ztracené a nadávajíc, že se v Solution Exploreru neorientujavša, neboť neznají lokaci právě otevřeného souboru. Nutno ovšem podotknouti, že struktura projektů a složek kverulantů těchto připomíná často spíše First-In-Never-Out kompostík než pravé vývojářské pískoviště. A zmizlo jim také Output Window, které se dříve dralo na světlo boží při každé kompilaci.

Dlouho, předlouho dumaly týmy expertů a vymýšleli řešení. Po několika desetiletích bloudění a usilovné práce přišli na tento postup:

- Otevř sobě dialog "Tools" - "Options".
- Ukaž rypákem krysy své na "Projects and Solutions" skupinu i stiskni levý čumák její.
- Hřebíkem označ "Track Active Item in Solution Explorer" a "Show Output window when build starts".
- Rypákem krysy své "OK" zamáčkni.

A jak psáno jest tak se také stane.

Jak ladit unit testy s ReSharperem

2006-09-13T09:58:00.000+02:00

Tak jsem si nedávno do svého VS2005 nainstaloval nový zpomalovač ReSharper 2.0.1. Vypadá to moc chytře (někdy až moc - např. intellisense má VS lepší a daleko rychlejší), a v nové verzi je integrované spouštění unit testů. Když otevřete nějakou třídu s testama, vedle metod se objeví zelenožluté puntíky, kterými se dá jednoduše spustit nebo debuggovat unit test. Spouštění zafungovalo samo a bez problémů, jenže ladění ne a ne se rozběhnout. Pořád to místo unit test metody spouštělo celý projekt.

Pokud máte podobný problém, zkuste ho vyřešit takhle:

1. Pokud jste někdy laborovali s TestDriven.Net, zkontrolujte nastavení projektu. Otevřete Properties projektu obsahující test. Přejděte na záložku Debug. Ve skupině "Start Action" musí být vybráno "Start project" (někdy tam může být nastavený TestDriven).

2. V menu "ReSharper – Options…" zobrazte "Unit Testing" (úplně dole) a ve skupině "Debugging Method" vyberte "Use the project being tested". Výchozí hodnota je při instalaci nastavena na "Use the current startup project", což je, dle mého skromného názoru, volovina.

3. Pak už můžete spouštět testy kliknutím na zelenožlutý puntík vlevo od metody s atributem Test.

Také můžete sledovat průběh spouštění testů spolu s podrobným výstupem v okně Unit Test Runner. Pokud nevyskočí samo, otevřete ho z menu "ReSharper - Windows - Unit Test Runner". Takže nepotřebujete NUnit GUI a nemusíte si pořizovat TestDriven.

Jeden háček to ale má. Při každém testování R# změní v nastavení Solution výchozí startup projekt na právě testovaný projekt, takže pokud pak chcete normálně spustit aplikaci, musíte znovu nastavit výchozí projekt.

UPDATE: Pokud máte ReSharper verze 2.5 nebo nižší, nebudete moci debuggovat projekty umístěné v nějaké Solution Folder. Ve verzi 3.0 už to funguje.

Jak rozšířit XPath o vlastní funkce?

2006-08-03T19:17:00.000+02:00

Že jazyky spojené s XML lze rozšiřovat, ví i můj jedenapůlroční synovec. Přidat si do XSLT šablony vlastní funkce je triviální prkotina a na netu existují tisíce návodů jak to udělat. Buď šoupnete funkci přímo do XSLT šablony do <ms:script> elementu, nebo přidáte objekt implementující kýžené funkce do XsltArgumentList objektu metodou AddExtensionObject (což je hezčí neboť to přímo nabádá k reuse). Takový přehled možností je zde. Jenže s XPath je to o něco komplikovanější.

Pokud voláte XPath dotazy nad nějakým XML dokumentem přímo z kódu, musíte na to jít úplně jinak. Zřejmě to není tak obvyklý scénář, protože jsem šťoural internet skrz naskrz a vůbec nebylo lehké přijít na nějakou stránku s návodem jak to udělat. Trvalo celkem dlouho než jsem objevil tohle: HOW TO: Implement and Use Custom Extension Functions When You Execute XPath Queries in Visual C# .NET.

Klíčový trik spočívá ve vytvoření vlastního XSLT kontextu, tedy třídy dědící od XsltContext. V ní předefinujete dvě metody: ResolveFunction a ResolveVariable. Když XPath parser narazí na něco, co vypadá jako funkce nebo proměnná kterou nezná, zavolá jednu z těchto metod a my máme šanci podstrčit mu vlastní implementaci. Řešení je to ale o něco složitější než u XSLT, protože musíte vrátit objekt implementující správné rozhraní - IXsltContextFunction nebo IXsltContextVariable. Ovšem s návodem už je to brnkačka, takže nemá cenu dál rozebírat detaily:-)

Jak zjistit celkovou velikost ViewState?

2006-08-01T09:00:00.000+02:00

Když si zapnete podrobné trasování běhu stránky pomocí elementu <trace> v souboru web.config, ASP.NET vám do stránky vypíše strom ovládacích prvků a informaci o velikosti jejich ViewState a ControlState. Jaká je ale celková velikost dat odesílanýchve skrytém HTML poli __VIEWSTATE?

Na internetu lze nalézt několik návodů, jak přidat informaci o velikosti ViewState do trace logu. Jenže všechny co jsem našel zjišťují velikost podle Request["__VIEWSTATE"], ale to je navrácený ViewState, odeslaný z předchozí stránky! Pokud nás zajímá, kolik dat odesíláme ve ViewState aktuálně zpracovávané stránky, musíme použít daleko špinavější trik.

Výchozí PageStatePersister stránky pro ViewState je HiddenFieldPageStatePersister, který v metodě Save() zkomprimuje ViewState a ControlState a vloží jej do interního textového pole ClientState stránky. Stránka jej pak později narenderuje do jednoho nebo více skrytých polí __VIEWSTATE (záleží na nastavení vlastnosti stránky MaxPageStateFieldLength). No a tak si zjistíme jak je toto pole dlouhé a přidáme to do trace logu:


protected override void Render(HtmlTextWriter writer)
{
#if DEBUG
    System.Reflection.PropertyInfo secretState =
        this.GetType().GetProperty(
            "ClientState",
            System.Reflection.BindingFlags.Instance |
            System.Reflection.BindingFlags.NonPublic
        );
    string viewState = (string)secretState.GetValue(this, null);
    if (viewState != null)
        Trace.Warn("ViewState Size", viewState.Length.ToString());
    else
        Trace.Warn("ViewState Size", "0");
#endif
    base.Render(writer);
}

No a je to. Informace o velikosti ViewState je vidět přímo v trace logu stránky! Dobrý, ne? Reflexe interního pole je ovšem špinavá technika a jsou k ní potřeba určitá práva. Pro ladění stránek a velikosti ViewState je to však príma.

Zkušební post

2006-04-06T09:53:00.000+02:00

Ali Baba programuje!