rarouš.weblog

Tento týden byla spuštěna do veřejného beta provozu nová studnice znalostí pro vývojáře s romantickým názvem Stack Overflow.

Tento web se veze na sociální vlně. Je to kombinace FAQ, Wiki a Diggu. Umožňuje hlasování o relevantnosti odpovědí, tagování, gravatary, komentáře, prostě všechny tydlety cool 2.0 věci. Zatímto zajímavám počinem pro vývojáře stojí dvě docela známé a uznávané osobnosti v blogosféře a to Jeff Atwood (Coding Horror) a Joel Spolsky (Joel on Software).

Tak honem šup šup se na něco zeptat nebo odpovědět, úspěch této aplikace závisí pouze na dostatečně relevantích přispěvatelích.

PS. technická poznámka, celé je to postaveno pomocí ASP.NET MVC frameworku.

Na začátku vývoje každého produktu bychom si měli připravit vhodnou infrastrukturu. Základem je verzovací systém – pokud pracujete sám, je značnou výhodou, v teamu nezbytností. Další důležitou součásti je systém pro vedení úkolů a bugů. Dále je vhodná wiki a taky nějaký buildserver.

Proč je to tak důležité?

Verzovací systém je vhodný na jakýkoli projekt, nemusí to nutně být ani projekt softwarový – my ho třeba s Borkem používáme na přípravu přednášky. Je to ochrana před ztrátou dat, občas pomůže se podívat do historie, dnešní systémy umějí mergovat změny z více zdrojů a jsou snadno zařaditelné do automatizovaného procesu.

Úkolník je dobrý z mnoha důvodů, vidíte, co máte dělat, jakou to má prioritu, kolik už máte hotovo. Slouží i jako váš výkaz, že se jen neflákáte. ;)

Build server je už jen třešničkou na dortu, která za vás dělá rutinu – špinavou a nudnou práci.

Jak to bylo v Atlase

Když jsem nastupoval do vývoje Atlas.cz, fungoval tam jen Visual SourceSafe, stagovalo se přes FTP. Vše bylo dost závislé na správném připravení verze do produkčního prostředí, to připravoval člověk a snadno mohlo dojít k chybě. :) Za nějaký čas jsme se rozhodovali jak to celé zautomatizovat a usnadnit. Nakonec jsme přešli na PureCM, Atlas.Build a Atlas.Autowebsite.

PureCM je verzovací systém s integrovaným úkolníkem a s možností skriptování v pythonu a dotnetím API. Má systém repository, které mají streamy a ty lze vzájemně mergovat v rámci hierarchie. Také k nim lze dopsat tzv. Custom action. Ta u nás nebyla nic jiného než spoušť události. Služba Atlas.Build tuto událost zachytila, provedla checkout, pročistila projekt a podle jednoduchého build skriptu (zjednodušený NAnt) připravila verzi buďto na dev servery nebo na staging, kterou pak nahrála na příslušný server pod danou verzí (názvem streamu).

Vývojář pak zadal do prohlížeče adresu, třeba http://katalog.3.6.0.dev2.atlas.cz, kde na něj čekal Autowebsite, který se zeptal jakou verzi frameworku použít a pak v IIS metabázi založil nový web.

Bylo za tím spousta magie a bylo celkem jednoduché a efektní a taky ušité na míru našim potřebám.

Jak to máme v Twaregu

Když jsme přišli do Twaregu, bylo opět potřeba připravit infrastrukturu. Po týdnu zkoušení a rozhodování jsme nakonec zvolili kombinaci Subversion (SVN), Trac, TeamCity.

SVN je celkem osvědčený verzovací sytém, je zdarma a multiplatformní, existuje pro něj dostatek nástrojů, včetně integrace do Visual Studia a je podporován všemi testovanými buildservery.

Trac je wiki a systém pro vedení úkolů s pěkným webovým prohlížečem repository. S SVN je spjat pupeční šňůrou a dá se dobře automatizovat tvorba nových projektů. Navíc je to OpenSource a je zdarma.

TeamCity je skvělý buildserver podporující Javu i dotnet (nejen tyto), umí se připojit do SVN a zvládá i vzdálené předtestované commity, což je killer feature. Pokud se dokážete smířit s omezením na 3 build agenty, 20 uživatelů a 20 konfigurací, pak je zdarma. Má pěknou integraci do Visual Studia a má API pro rozšiřování.

První měsíc v Twaregu jsem (nejen) připravoval infrastrukturu. Napsal jsem službu, která zakládá nové repository, připraví do nich základní adresářovou strukturu a založí projekt v tracku. Automatizované zakládání pro TeamCity zatím není a ještě nevím, jestli je potřeba. Jednotlivé konfigurace je lepší projít ručně a nastavit dle požadavků daného projektu. Na projektu většinou máme dvě konfigurace, jednu, která je pro vzdálený předtestovaný commit do vývojového branche a druhou, která se spouští při commitu do trunku. Provede se kompletní build, spustí se testy, pokud je vše ok, vytvoří se dokumentace a nahraje na intranet, provede se deploy knihoven do společného úložiště a vytvoří se weby, pokud nějaké v projektu jsou.

Co se všechno má udělat je řízeno MSBuild skriptem, pro který jsem připravil několik tasků. Upravil jsem xUnit.net task, aby se posílaly zprávy do TeamCity a přibalily výsledky testů do sumáře o buildu.

Je fakt, že tady máme build skripty mnohem ukecanější něž v Atlasu, ale jsou mnohem flexibilnější – vzhledem k heterogennímu prostředí je to potřeba.

Závěr

Investujete-li na začátku nějaký čas na vybudování infrastruktury, jistě se vám to vrátí později v podobě nevytrhaných vlasů a neokousaných nehtů, když někdo někomu omylem přemázne celodenní práci nebo vydeployuje nefunkční verzi. Nemít verzovací systém je vyložený hazard, nemít úkolník je přinejmenším nepohodlné a bez build serveru se dá žít…

A jakou infrastrukturu/sys­tém používáte vy?

Projekty, které se rozhodnu vypustit ven, většinou hostuju na CodePlexu. Jeho UI mi přijde mnohem rychlejší než konkurenční SourceForge a přehlednější než Google Code. Nevadí mi, že za tímto hostingem stojí velký zlý Microsoft, naopak to vítám. Tento projekt byl jedním z prvních krůčků na podporu OpenSource ze strany Microsoftu a navíc je místem, kde samotný Microsoft uveřejňuje spoustu zajímavých projektů. Například budoucí části ASP.NET.

Ale zpět k tématu. Tento hosting je postaven na Team Foundation Serveru (TFS), který je centrem pro týmovou práci, verzovacím systémem a v neposlední řadě i systémem pro vedení požadavků a úkolů. Tím se odlišuje od konkurence, která většinou používá tradiční SVN, což je po léta de-facto standard pro verzování OpenSource projektů. Komunita dlouho volala po tom, že chtějí SVN i CodePlexu. V MS nakonec udělali kompromis.

SVN Bridge

SVN Bridge byl první krok. Je to taková malá utilitka, kterou si spustíte na vašem počítači a ona překládá vaše SVN požadavky do řeči, které rozumí TFS. Můžete s ní pak používat oblíbené nástroje jako TortoiseSVN nebo VisualSVN. Ale pořád je tu nutnost donahrát si utilitu a ani URL repository ve tvaru http://localhost:8081/<tfs.server.name>/<projectname> nejsou nějak úchvatná.

Tento měsíc však došlo k zásadní změně. Na Codeplexu byl nasazen serverový SVN bridge, takže už nemusím pouštět lokální verzi, ale rovnou můžu pro snadný přístup přes SVN nástroje používat adresy následující:

1. pro NForms https://nforms.svn.codeplex.com/svn
2. pro Texy.net https://texynet.svn.codeplex.com/svn

No a vy také ;)

Pokud se rozhodnete pro vaše AJAXové aplikace požívat RESTové služby ADO.NET Data Services, jistě se dostanete do situace, kdy máte komplexní typ a potřebujete vytvořit novou entitu s odkazem na již existující objekt.

Řešení tohoto problému jsem hledal dost dlouho, nakonec bylo celkem jednoduché.

Problém

AJAXově vytvářím entitu, která má vlastnost User, což je reference na uživatele, který danou entitu vytvořil – kterému patří.

Cesta k řešení

Nejprve jsem zkoušel využít něco podobného, jako je u entit, které jsou vráceny pomocí metody GET. Tedy odkaz na jinou entitu je vyjádřen pomocí vlastnosi __deffered a ta má atribut uri, který odkazuje na již existující entitu pomocí jejího URL. Bohužel, to nefungovalo, protože __deffered je metodou POST ignorováno. Kód vypadal asi následujícně:

User: { __deffered: { uri: "/Users(13)" } }

Pak jsem tedy zkusil druhý zoufalý krok. Zkusil jsem použít atribut ID, který je vlastně jediný důležitý pro správné persistování do databáze. Kód následující:

User: { Id: 13 }

Jenže ani to není správná cesta, navíc si tak můžete Usera poškodit.

Konečné řešení

Konečné funkční řešení se od toho původního pokusu skoro neliší, ano byl jsem hodně blízko a vzal to oklikou a až důkladné čtení dokumentace mi otevřelo oči. Vlastnost __metadata byla aktuálně tou správkou, která se měla použít! Takže správný kód vypadá takto:

User: { __metadata: { uri: "/Users(13)" } }

Závěr

Já vím, není to žádná super extra informace, ale já k jejímu získání spotřeboval celkem dost času. Možná to někomu ušetří starosti a hledání… Pokud vás zajímají ADO.NET Data Services – což je velice zajímavá technologie – můžete se přijít podívat na naši přednášku o ASP.NET, kde o nich bude utroušeno několik slov a předvedena pěkná ukázka ve spojení s AJAXem a k databázi budeme přistupovat přes NHibernate místo Entity Frameworku.

Tagy: DataServices, AJAX

První vlašťovkou z hnízda MVC frameworku, která se objevila v produkční verzi .net frameworku, je knihovna System.Web.Routing. Objevila se s příchodem SP1 verze 3.5 a to proto, že jí využívají ASP.NET Dynamic Data, které jsou taktéž novinkou service packu. No a protože routing je důležitou součástí ASP.NET MVC a jeho výhod lze využít i v klasickém ASP.NET, pojďme se na něj podívat trochu blíž.

Jak to funguje

Základem routingu je HttpModul, který vezme URL adresu požadavku a snaží se ho napárovat na některou z rout, které se registrují při startu aplikace. Pokud najde, získá z adresy požadované parametry a předá zpracování patřičnému RouteHandleru, který má za úkol vytvořit HttpHandler a předat mu získaná data. V případě MVC se vytvoří MvcHttpHandler a data se přidávají kontextu, v klasickém ASP.NET je to jen na vás.

Routovací handler pro WebForms může vypadat třeba následovně:

public class WebFormRouteHandler<T> : IRouteHandler where T : IHttpHandler, new() {
  public string VirtualPath { get; set; }

  public WebFormRouteHandler(string virtualPath) {
    VirtualPath = virtualPath;
  }
  public IHttpHandler GetHttpHandler( RequestContext requestContext ) {
    foreach (var value in requestContext.RouteData.Values) {
      requestContext.HttpContext.Items[value.Key] = value.Value;
    }

    return (VirtualPath != null)
      ? (IHttpHandler)BuildManager.CreateInstanceFromVirtualPath(VirtualPath, typeof(T))
      : new T();
  }
}

Routovací handler projde kolekci dat získaných z aktuální URL požadavku, nacpe je do kontextu a nakonec vytvoří a vrátí IHttpHandler.

Routovací tabulky

Pro naše aplikace je asi nejdůležitější nadefinovat routovací tabulky. Definice tabulky se vytváří při startu aplikace, tudíž využijeme události Application_Start v Global.asax nebo vlastním HttpModulu.

public class MvcApplication : System.Web.HttpApplication {
  public static void RegisterRoutes(RouteCollection routes) {
    routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
    routes.MapRoute(
        "Default",                                              // Route name
        "{controller}/{action}/{id}",                           // URL with parameters
        new { controller = "Home", action = "Index", id = "" }  // Parameter defaults
    );
  }
  protected void Application_Start() {
    RegisterRoutes(RouteTable.Routes);
  }
}

Ukázka tvorby routovací tabulky při startu webové aplikace. Metoda MapRoute je extension metodou z MVC frameworku, která za nás vytvoří MvcHttpHandler, který bude požadavek zpracovávat. Získané parametry z routy jsou: název řadiče, který přebere řízení, jeho akce, která požadavek zpracuje a dále pak parametr id.

U WebForms by routovací tabulka např. pro můj blog mohla vypadat následovně:

public class Global : System.Web.HttpApplication {
  public static void RegisterRoutes(RouteCollection routes) {
    var routeHandler = new WebFormRouteHandler<Page>("~/Weblog/Article.aspx");
    var route = new Route("weblog/{id}-{url}.aspx", routeHandler) {
      Constraints = new RouteValueDictionary {
       {"id", "\d{1-3}"}
     }
    };
    routes.Add(route);
  }
  protected void Application_Start(object sender, EventArgs e) {
    RegisterRoutes(RouteTable.Routes);
  }
}

Zaregistroval jsem do tabulky routu, která bere URL ve tvaru weblog/{id}-{url}.aspx a ověřuje se, že id je jedno až tříciferné číslo.

Shrnutí

„Pane Aloisi, když dovolíte, já bych si to v závěru celé shrnul.“

„Tak, jestli vám to udělá dobře, tak si to celý schrntě.“

Tak tedy, tento spotík se snažil nastínit jak funguje routing v ASP.NET, jak si zaregistrovat routy a jak z nich získávat data. Mohlo by se zdát, že to je vše čeho jsme schopní dosáhnout, ale není tomu tak. Routing je v ASP.NET dvoucestný, ale cestu zpět si ukážeme zas někdy příště… Třeba na WebExpu!

Tagy: ASP.NET, ASP.NET MVC, Routing

Je to už pár měsíců, co mě oslovil Vašek Stoupa, zda bych nechtěl přednášet na WebExpu o ASP.NET MVC. Zprvu jsem váhal, protože nemám žádné prezentační zkušenosti a tak jsem to chtěl celé hodit na Borka. Jenže pak jsem si vzpomněl na skvělé přednášky z MIXu, kde nebyl pouze jeden přednášející, ale tandem.

Slovo dalo slovo, Vašek i Borek souhlasili a my jsme zapsaní v programu konference. :) Protože ASP.NET MVC ještě není ve stabilní formě API (ta by měla být více méně stabilní v betafázi, která se blíží), domluvili jsme se na tom, že probereme více věcí.

Doufám, že se Borek nebude zlobit, když prozradím naši předběžnou osnovu. Můžete se k ní vyjádřit v komentářích a my ji můžete případně vylepšit. :)

Osnova

1. WebForms – povídání o tom, kde je vhodné použít klasické WebForms a novinkách ve verzi 3.5
2. AJAX – povíme si, jak je integrována podpora AJAXu v ASP.NET
3. ADO.NET Data Service – bližší seznámení s REST službami postavenými nad ADO.NET a ukázka ve spojení s AJAXem
4. Dynamic Data – povídání a ukázka dynamicky vytvářených administračních rozhraní ze schématu databáze.
5. MVC – povídání a ukázka MVC frameworku, jak se liší od WebForms a možná i spojení s Dynamic Data, to jak zbyde čas.

Pokud vás tato témata zajímají, přijďte se na nás podívat, pokud nezajímají, přijďte se podívat na koktajícího rarouše… ;) Každopádně tam bude spousta jiných zajímavých přednášek, třeba Davidův evergreen o Nette Frameworku.

Tagy: WebExpo, Asp.Net, ASP.NET MVC

Často se v diskusích/flamech o vývoji v Atlasu dočítám, že jsme byli blbý klikači, co se neobejdou bez wizárdů a podobných věcí. Jak je to tedy?

Pravdou je, že jsem velice poholdný až líný a nemám rád zbytečnej oser s příkazovou řádkou. Ne že bych jí nepoužíval, hodně úkolů se dá rychle zvládnout právě z ní, ale přece jen kompilace z Visual Studia na dvě kliknutí nebo spouštění build scriptu z příkazovky je dost o něčem jiném.

Nejen že na dvě kliknutí provedu build ale provedou se mi unit testy nebo vzdálený předtestovaný build a případě úspěchu i commit do repository. Upřímně písmenkáři, kdo z vás to má?

PS. Vím, že jde buildit i na jedno kliknutí nebo přes klávesovou zkratku, ale já mám rád kontextovou nabídku ;)

Pokud se dostanete do stádia, kdy potřebujete takovou architekturu, kde je potřeba používat plug-iny třetí strany, kde je potřeba snadno vyměnit komponentu za jinou, přichází ke slovu nějaký druh konfigurace.

Velice často se můžeme setkat s konfigurací komponent v XML. Ať už je to Provider pattern známý z ASP.NET, či vlastní konfigurační sekce, nebo konfigurace Windsor kontejneru, pořád tu máme XML. Jeho ohromnou výhodou je, že se dají systémové komponenty snadno překonfigurovat bez nutnosti celý systém překompilovat. Stačí pouhý restart aplikace. Navíc nástrojů na editaci a validaci XML máme nepočítaně, takže změnu konfigurace zvládne téměř každý.

Velkou nevýhodou XML, je jeho omezené výrazivo. Špatně se v něm píše foreach nebo if. Prostě na složitější konstrukce je potřeba programovací jazyk. A nebo skriptovací!

Boo na scénu

Boo je staticky typovaný objektový jazyk nad CLI (dot net) inspirovaný syntaxí Pythonu. Jeho hlavní silou je metaprogramování. Na úrovni kompilátoru se snadno dají psát makra. Takových maker lze využít k tvorbě přehledných DSL a jednou z takových je i Binsor.

Windsor + Boo = Binsor

Windsor je IoC kontejner na platformě dot net a je součástí opensource projektu Castle. Windsor má v základu dvě možnosti jak konfigurovat komponenty.

1. Programově na úrovni mikrokernelu.
2. XML konfigurací.

XML konfigurace je nejčastěji užívanou možností, kvůli výše popsaným výhodám. V trunku se nedávnou objevila i konfigurace pomocí DSL na principu fluent interface přímo v C#. Taková konfigurace je velice pěkná, ale je tu pořád nutnost při každé změně znova celý projekt kompilovat. Proto je tu Binsor, který si bere sílu programovacího jazyka, efektnost XML konfigurace a navíc jednoduchost a přímočarost syntaxe.

Konfigurace komponent

Nejčastější aktivitou s Binsorem nejspíš bude registrace komponent. :)

component 'my_component', IServiceContract, ServiceImplementation:
    # nastavime parametr konstruktoru
    constructorParameter = 10
    # nastavime vlastnost sluzby
    SomeProperty = "Hello Word!"

Kód je v celku jednoduchý. Na prvním řádku začínamé klíčovým slovem component, které říká, že registrujeme komponentu. Prvním parametrem je název komponenty, přes který se na ní můžeme odkazovat. Druhý parametr je rozhranní služby a třetí je konkrétní implementace, která bude při rozpoznání kontejnerem vrácena, např. IoC.Container.Resolve<IServiceContract>(). Za dvojtečkou pokračuje výčet nastavovaných vlastností a parametrů. Můžeme takto nastavovat i speciální vlastnost ovlivňující životnost objektu.

component HttpRequest:
    lifestyle Singleton

Všimněte si, že se ani nemusí při registraci uvádět referenční název nebo abstraktní typ. Může se klidně rovnou registrovat typ konkrétní, který se bude v tomto případě chovat jako singleton. Takovéto ukázky jsou fešné, ale nic, co bychom nezvládli pomocí XML. Pojďme trochu dál.

for type in AllTypesBased of Controller("MyApplication.Web"):
    component type

Tento kód zaregistruje všechny controllery (třídy, které jsou potomky třídy Controller) z assembly MyApplication.Web. Krom generické metody AllTypesBased, je tu ještě generická metoda AllTypesWithAttribute a negenerická AllTypes. Všechny mají jako parametr název assembly, jejíž typy procházejí.

Facility

Neméně důležitou součástí konfigurace jsou facility, které dodávají kontejneru nové možnosti a zapouzdřují větší sady komponent do logických jednotek. Pro ukázku konfigurace ActiveRecord komponent pomocí Binsoru:

facility ActiveRecordFacility:
    configuration:
        @isWeb = true, isDebug = true
        assemblies = [ Assembly.Load("MyApplication.Entities") ]
        config(keyvalues, item: add):
            show_sql = true
            command_timeout = 5000
            cache.foo.use_query_cache = false
            dialect = 'NHibernate.Dialect.MsSql2005Dialect'
            connection.provider = 'NHibernate.Connection.DriverConnectionProvider'
            connection.driver_class = 'NHibernate.Driver.SqlClientDriver'
            connection.connection_string = 'connectionString1'

Shrnutí

Osobně se mi možnosti konfigurace přes Binsor velice líbí, ale je celkem možné, že ne každému to může vyhovovat. Pokud ale používáte Windsor a přijde vám XML konfigurace nepřehledná, je toto možná cesta, jak z toho ven. Pokud chcete nějaké lepší příklady, doporučuju si stáhnout SVN repository https://rhino-tools.svn.sourceforge.net/svnroot/rhino-tools/trunk/rhino-commons a projít si testy. Jako editor se mi osvědčil SharpDevelop, který má podporu pro Boo přímo v základu, nebo doinstalovat BooLang Studio do Visual Studia.

Tagy: IoC, Windsor, Binsor, Boo

Na Codeplexu se objevil nový opensource projekt a není to nic menšího než NForms. Zatím jste se o nich mohli jen dočíst u mě na blogu a prakticky vyzkoušet taktéž tady – přidávání komentářů frčí na NForms. Nyní však máte jedinečnou možnost stáhnout si zdrojáky, poučit se z nich, nahlásit chyby nebo diskutovat náměty na vylepšení, zkompilovat, spustit testy a konečně nasadit a používat ve vlastních projektech.

No není to skvělé?

K čemu je to dobré?

NForm jsem napsal jako programátorské cvičení. Líbila se mi Davidova myšlenka, chtěl jsem napsat něco v C# 3.0… Jenže je to taky docela užitečná věc. Daj se pomocí toho snadno vytvářet znovupoužitelné formuláře nezávislé na infrastruktuře. Můžete je používat jak v klasickém ASP.NET modelu (můžete použít více než jeden formulář na stránce), tak v MVC nebo MVP modelu.

Další vývoj

Aktuálně připravuju podrobnější dokumentaci na wiki, ale pro začátek jistě bude stačit pár mých spotíků tady na blogu, příklady užití najdete v Unit Testech, popřípadě další moudra najdete v nedokonalých XML komentářích v samotném kódu.

Při psaní wiki jsem už našel nějaké možnosti pro vylepšení, tak až bude připraveno, hodím je zase na Codeplex. Stay tuned…

Časem bych chtěl přidat podporu validace na straně klienta. Zatím se generují jen některé třídy, na které lze napojit vlastní implementace v JavaScriptu, ale není to nic pro složitější validaci…

Credits

Musím poděkovat Davidovi za inspiraci, NForms jsou značně obšlehnuté od Nette::Forms (dříve známé jako NForms), trochu inspirace jsem pobral i u New Forms z djanga, některé zajímavé nápady, jak využít novinky C# 3.0 pro změnu z ASP.NET MVC. Takže díky!