Ospitalità…

Lemma: ospitalità
Sillabazione/Fonetica: [o-spi-ta-li-tà]
Etimologia: Dal lat. hospitalita¯te(m), deriv. di hospita¯lis 'ospitale'
Definizione: s. f.
1 l'essere ospitale; cortesia, affabilità verso chi è ospite, chi è forestiero: l'ospitalità di una famiglia, di una città
2 l'ospitare, l'essere ospitato: offrire, concedere, negare ospitalità; chiedere, trovare, accettare ospitalità; i doveri dell'ospitalità.
poi c’è quella di amici che ti conoscono appena ma che non si fanno alcun problema ad ospitarti a casa loro e accoglierti come se ti conoscessero da sempre.
Semplicemente grazie.
.m

TechEd 2008 - Tristezza

ok, direi che scherzare a suon di “braccine” abbiamo scherzato abbastanza, io e Raff siamo appena arrivati in una delle sale da pranzo e ci siamo trovati davanti all’incredibile sorpresa dei sacchetti per il pranzo esattamente come lunedì. Io sinceramente non ho parole se fossi un attendee che ha pagato fior di quattrini per venire ad un TechEd sarei incazzato come una bestia, io mi limito ad essere deluso per la figura pietosa che l’organizzazione sta facendo con le 3200 persone presenti, si stanno perdendo per strada…
Non so che altro dire, ritengo che questa rincorsa al ripsarmio sia solo controproducente, ritengo che il dire a “gente” che viene anche a lavorare che non ha diritto (cit: you have no rights) ai gadget perchè fa parte dell’ATE sia semplicemente triste e anche un po’ offensivo, ritengo che vedere corridoi in cui fino all’anno scorso campeggiavano distese di frutta notevoli, forse troppo è vero, siano ridotti a 3 mele acerbe in croce sia veramente pietoso, ritengo che vedere il personale che alle 18 si adopra per sigillare i frigoriferi per evitare che tu a conference chiusa possa avere una bottiglietta d’acqua non sia accettabile, ritengo che non dare connettività WiFi all’interno delle sale sia stupido, ritengo che non darti da mangiare alle 13.32 perchè la magiatoia delle bestie chiude alle 13.30 quando hai lavorto all’HOL fino alle 13.30 non abbia giustificazioni… basta mi fermo qui che è meglio per tutti.
Cosa può succedere d’altro? immagino che ci possano dare una tessera a scalare, naturalmente a pagamento, per l’uso della corrente, di wifi, o delle scalemobili, le vuoi? pagale.
.m

TechEd 2008 – Day 3: Building a Linq Provider

Un sessione di livello 400 di quelle che ti lasciano con la bocca aperta… di quelle da cui esci un po’ frastornato e ti chiedi ma perchè non esiste il livello 500 e il 600 e il… :-D
L’ex MVP Bart de Smet, adesso dipendente Microsoft, ci ha intrattenuto con una splendida sessione sulla semplicissma interfaccia IQueryble. L’argomento è decisamente tosto, bart ha cercato di affrontarlo gradualmente facendo un discreta introduzione sul funzionamento interno di linq, sui vari concetti che girano intorno alla lambda e alla Expression per poi darci la stoccata finale con un bel deep dive sull’implementazione di un visitor per un expression tree…
.m

TechEd – Day2: wrap up…

Post cumulativo molto lazy :-D
Ieri prima sessione di ATE conclusasi con una piacevolissima chiaccherata con il mio collega di ATE Pieter Joost van de Sande e con niente popò di meno che Mr. T AKA Mads Torgersen.
Oggi startup con David Chapell che ci ha dilettato parlando di WF4.0, Dublin e Oslo argomenti di cui sapevo poco e nulla e devo dire che lo spaecker è stato semplicemente perfetto, veramente un grande.
Segue una interessante, anche se un po’ zoppicante, sessione sul Sync Framework 2.0 che ha avuto il pregio di darmi una panoramica abbastanza buona sulle possibilità e le problematiche che il tool è in grado di risolvere.
pranzo, decente oggi (diamo a Cesare quel che è di Cesare), e una lunga sessione di cazzeggio con Igor a chiaccherare di Inversion Of Control, sviluppo in generale, Architettura e chi pià ne ha più ne metta…
infine nuovamente il mito: Pat Helland – Buildng on the quicksand.
Oggi 67 slide densissime di contenuti e condensate come non mai riguardo alle problematiche di gestione di quantità di dati enormi e distributiti, riguardo alla preoblematiche legate alla loro sincroizzazione e alle problematiche legata alla necessità di far “scalare orizzontalmente” una base dati.
Non ho altre parole che amazing, difficile e piena zeppa di spunti che potrebbero farci parlare per giorni interi, ma decisamente affascinante.
Poi si è anche scusato per tutto quello di male che ha fatto negli anni passati :-D
Infine cena in cui abbiamo avuto, imho, la dimostrazione che tutto il mondo è paese… 43,00€ a cranio per un antipasto, un secondo (che non ho maangiato) e un dolce (che non ho potuto mangiare) mi sembrano decisamente troppi.
Ma la compagnia come al solito è stata impagabile ;-)
.m

When you have too much data… Mr. Pat Helland

si iniza alla grande già l’agenda è un “programma” di quelli che meritano.
E’ talmente tanta la mole di informazioni che sta dando che non so neanche da che parte cominciare. La prospettiva è quella dei dati in un mondo in cui non esiste più il “now” ma siccome esistono i concetti di “dati esterni” e “dati interni” è necessario introdurre il concetto di “past”. In soldoni in un mondo SOA una volta che il messaggio è partito il ricevente non ha nessun controllo sulla consistenza del messaggio con il mondo da cui è partito quindi il ricevente sta vendendo il passato (past).
Il mondo non è più “piatto” ed è colpa di SOA ;-)
Un altra bella magagna in un mondo distributo, e caratterizzato dalla possibilità di avere in mano il passato, è la consistenza dello schema o addirittura l’assenza o la comprensione parziale dello stesso… si potrebbe parlare per ore se pensassimo a tutte le implicazioni possibili.
Altro problema di quelli tosti: in un mondo in cui i dati sono distribuiti, disconnessi e soprattutto r/w ovunque quali sono le implicazioni della riconciliazioone di questi dati? dobbiamo anche ricordarci di tenere in considerazione il fattore temporale non solo chi ha fatto cosa e dove ma anche quando.
Non dimentichiamoci poi delle nuove necessità ben inquadrate dal concetto di “streaming data”.
Una cosa che dobbiamo metterci in testa è che quando si parla di enormi quantità di dati uno scotto da pagare è la perdità di accuratezza dei dati stessi.
Molto filosofico ma decisamente interessante, insomma Pat Helland è una garanzia.
Mi rendo conto che il post possa essere decisamente criptico, ma l’uomo ha condensato 50 e passa slide in 70 minuti e vi garantisco che ognuna dele slide era un condensato notevole di nozioni e di spunti per approfondimenti, domani c’è una sessione che seguirò con interesse che riguarda la riconciliazione dei dati e siccome lo speaker è sempre “lui” so già che sarà un’altra vagonata di informazioni.
.m

Deploy ‘n’ Versioning: Application Life Cycle Best Practices

finalmente si inizia, prima sessione.
Introduzione sulle novità (Client Profile) introdotte con l’SP1 per il deploy del framework sulle macchine client, per ridurre il il traffico e il tempo impegnato durante i setup per l’installzazone di qualcosa che probabilmente non verrà usato dall’applicazione.
La sessione non introduce nulla di nuovo ma vuole essere una tip-library di esperienze fatte dallo speaker durante la sua carriera e come usare gli strumenti, il solo Viusal Studio senza dover dipendere da altri prodotti di terze parti.
Sta facendo vedere come usare i progetti di setup di Visual Studio, nulla di nuovo anzi, e mi vien da pensare che se qualcuno in sala osa meravigliarsi delle possibilità meglio che cambi lavoro… :-D
Aggiungo: taccio che è meglio… mamma mia here I go again… short arms :-S
Una cosa interessante che è stata detta, l’unica…, del SP1 del fx 3.5: Assembly Strong Name Check Bypass.
.m

Succede anche questo :-D

l’ho dato ai greci perchè mi danno più soddisfazioni <cit.>
ma tu dimmi se si può… :-D
.m

[TechEd08 – Day1] Ooops, I did it again <cit.>

ok, primo giorno… si inizia il pomeriggio con la key note, mattinata dedicata al cazzeggio e ad un po’ di shopping, ma non doveva durare 4gg?
Arriviamo all CCIB verso le 12 e ci dirigiamo verso quel della sala pranzo… e ci danno un bel sacchettino con il lunch… una schifezza mai vista, neanche nel peggior autogrill italiano, alle 3 di notte dopo qualche settiaman di sciopero riesci a trovare cose di questa bassezza.
Tirste, decisamente triste.


Vediamo se sono in grado di riprendersi, ma l’inizio gli garantisce un feedback complessivo che difficilmente potrà andare oltre il 3.
.m

[TechEd08 - Day0] Braccine…

ci siamo! finalmente siamo tutti insieme a Barcellona per il TechEd Developers 2008, come al solito la città è stupenda, il clima è decisamente invidiabile e la tranquillità che questo ambiente ti infonde è decisamente inimitabile.
Ma non è tutto oro quel che luccica e le “braccine” stanno diventando di casa anche in MS, oggi ci siamo presentati al banco delle registrazioni abbiamo fatto tutta la trafila ci hanno dato la solita borsa con i gadget e la maglietta… ma ne uno ne l’altro c’erano, la borsa era semplicemente vuota… a seguito delle nostre domande (rimostranze) la signorina del dek informazioni ci ha risposto che quelli he fanno l’ATE non hanno diritto ai gadget… stendiamo un velo pietoso.
Ci stiamo attrezzando per lavare i piatti della mensa dei prossimi giorni :-D…
Per il resto non ci si può lamentare serata piacevole e ingorda di pesce alla consueta cena MCT preceduta da un piacevolissima passeggiata in quel di barceloneta nel pomeriggio… causa acquisti compulsivi :-D
Welcome the new Dixan MVPs :-D
.m

[OT] …io mi sono un po’ stufato

Lo SPAM è reato.
Oggi arrivo a casa e nella casella della posta, quella fisica, trovo il solito ciarpame di volantini pubblicitari, il parrucchiere tal dei tali, il supermercato tedesco tal altri, il supermercato italiano tal lo sa lui… e mi chiedo: ma questo non è SPAM? per me queste comunicazioni, in nessun modo richieste ne autorizzate sono un costo, il ciarpame lo smaltisco io e loro non mi fanno mica lo sconto sulla tassa dei rifiuti…
Qualcuno sa se si può fare qualcosa?
Yes we can? :-D
.m

TFS Dispettoso :-D

ho passato l’ultima mezz’ora a litigare con TFS perchè non riuscivo a “bindare” una solution…
Antefatto: la solution stava su un TFS che non esiste più, è morto tempo fa, oggi mi serviva rimetterla sotto source control.

• Apro VS;
• apro la solution aspetto che vada in timeout e arrivi la notifica del lavoro off-line;
• rimuovo i binding al TFS “andato”;
• chiudo la solution salvando tute le modifiche ai vari csproj e sln;
• riapro a faccio un bel add to source control…, …, …, …, …, …, unable to connect to remote server…, e ce credo un ce sta…;
• *^@!$$%&^^

Litigo per un bel po’… scrivo a San Lorenzo… su suo consiglio provo il tool SccRemover ma nulla… alla fine illuminazione: la cache del team explorer… ctrl+A –> shift+canc :-D
.m

Maledetto ticketone :-S

lo odio, ma proprio con tutto me stesso… è mai possibile:

non un messaggio di errore, nulla di nulla… già sono degli strozzini legalizzati e si permettono pure di fare il bello e cattivo tempo…
.m

Mamma Mia!

…ho iniziato a dare il primo sguardo serio a WPF e coadiuvato da un paio di mail scambiate con Corrado sto realizzando un piccolo, veramente piccolo, concept.
Per ora ho scalfito la superficie del motore di binding e dei template, ci sono rimasto male. Sto facendo cose che se penso di fare con Windows Forms… meglio che non lo dica :-D
.m

CodeContract.Requires( you.PayAttention() );

Il framework 4.0 “is on the way”, c’è ancora molta strada da fare ma se non altro la via è stata imboccata; cominciano a girare un po’ di documenti sulle novità che verranno introdotte con il nuovo runtime e i cominciano anche a sprecarsi i post su “dynamic”, sui valori di default per i parametri etc… evito che è meglio ;-)
E’ ovvio che rivoluzioni come Linq si vedono una volta nella vita quindi secondo me non ha senso lamentarsi dell’apparente veste poco rivoluzionaria del nuovo framework, se però scaviamo a fondo, sotto sotto ci sono tante belle cose…
Una delle cose che mi attraggono e che verranno incluse nel nuovo runtime sono i Code Contracts, che sono già “utilizzabili” ora anche con VS2008, utilizzabili tra virgolette perchè l’attuale licenza permette solo sperimentazioni e nulla di più.
Vediamo di approfondire un po’ la questione:

class OrderProcessor
{
    public void Process( Order order )
    {
        
    }
}

ipotizziamo una situazione elementare come quella esposta, quello di cui dobbiamo preoccuparci è l’inevitabile e tedioso controllo della validità dei parametri in ingresso, classicamente quello che possiamo fare è:

class OrderProcessor
{
    public void Process( Order order )
    {
        if( order == null )
        {
            throw new ArgumentNullException();
        }
    }
}

se usiamo un pizzico di AOP possiamo scrivere una cosa decisamente più smart:

class OrderProcessor
{
    public void Process( [NotNull]Order order )
    {
        
    }
}

e otteniamo lo stesso identico comportamento. Ma non è tutto oro quel che luccica, purtroppo ;-), e quello che ci manca, e che a me piacerebbe molto è la possibilità di avere questo controllo direttamente a compile time, del resto quella non è logica di business ma è un constraint “punto”.
Vediamo cosa possiamo fare con i “Code Contracts”, una volta scaricato e installato il tutto quando creiamo un nuovo progetto di Visual Studio ci troviamo qualcosa in più, nella pagina delle proprietà c’è infatti una nuova tab:

se quindi aggiungiamo una reference all’assembly “Microsoft.Contracts” e riproviamo a compilare il codice del primissimo esempio, quello senza nessun controllo sui parametri, succede questo:

toghissimo!, Visual Studio al termine della compilazione invoca un nuovo tool (cccheck.exe) che fa analisi statica del codice e stabilisce che li c’è un potenziale problema. Già questo, a mio modo di vedere sarebbe, o meglio sarà, una vera manna dal cielo.
Ma non è finita, per eliminare il warning è sufficiente fare in modo che il codice sia safe quindi ad esempio rimettere il check sui parametri:

class OrderProcessor
{
    public void Process( Order order )
    {
        if( order == null )
        {
            throw new ArgumentNullException();
        }
    }
}

a questo punto Visual Studio compila felice come una pasqua, ma non è detto che questo ci basti, se questo è una condizione sufficiente a proteggerci a runtime rimane sempre la fastidiosa situazione che il tutto avviene a runtime mentre se avvenisse a compile time saremmo molto più felici.
Come fare in modo che Visual Studio si lamenti se trova una situazione come questa:

OrderProcessor op = new OrderProcessor();
op.Process( null );

Con Code Contracts è decisamente semplice:

public void Process( Order order )
{
    CodeContract.Requires( null != order );
}

aggiungendo questa dichiarazione e ricompilando quello che otteniamo è:

dove il primo warning con un doppio click ci porta al punto nel codice in cui c’è la condizione, mentre il secondo ci porta al punto in cui la condizione viene violata. La cosa fighissima è che funziona anche se il codice che “recupera” l’istanza di Order è decisamente complesso.
Faccio notare che Visual Studio genera degli Warning e, secondo me, è giusto così del resto il codice dal punto di vista del compilatore è corretto l’IDE ci informa solo dei potenziali problemi a cui potremmo andare incontro.
In questo esempio, quindi, per far si che il controllo statico a compile time passi senza warning è sufficiente soddisfare il contratto:

class Program
{
    static void Main( string[] args )
    {
        Order o = Compless.GetOrder();
        if( o != null )
        {
            OrderProcessor op = new OrderProcessor();
            op.Process( o );
        }
    }
}

E’ quindi il chiamante che deve assicurarsi di effettuare i controlli di rito. Avendo soddisfatto il contratto succede un’altra cosa molto interessante, se spulciamo con il fido Reflector il codice generato scopriamo che non vi è traccia alcuna:

Questo porta all’indubbio vantaggio che le performance ne giovano perchè i controlli sulla coerenza dei parametri in ingresso vengono fatti solo ed esclusivamente dove hanno senso, notiamo infatti che un’eventuale chiamata del tipo:

op.Process( new Order( 100 ) );

viene perfettamente digerita.
Ci sono però delle casistiche in cui potremmo volere che il controllo venga effettuato anche a runtime, un “classico” esempio potrebbe essere quello della Class Library, noi scriviamo la libreria e altri la usano, tutto ciò è possibilissimo, basta cambiare la dichiarazione:

public void Process( Order order )
{
    CodeContract.RequiresAlways( null != order );
}

e il fido Reflector conferma:

Garantendoci un’exception a runtime se il contratto non fosse rispettato.
Ma andiamo oltre, è si non è finita :-D…
Supponiamo di trovarci nella casistica appena esposta, il nostro ruolo è quello di developer di framework e non conosciamo chi saranno i nostri utilizzatori ma non vogliamo neanche il potenziale impoverimento delle perfromance che il controllo a runtime potrebbe comportare: si può fare
Condizione necessaria è abilitare sul/i progetto/i class library la generazione di un assembly per i contratti, quello che succede a questo punto quando compiliamo è che vengono generati 2 assembly/progetto: uno con la class library vera e prorpia e uno con i soli contratti. Sempre dal fido Reflector scopriamo che se il codice che compiliamo è questo:

public void Process( Order order )
{
    CodeContract.Requires( null != order );

    Int32 qty = order.ItemQty;
}

il prodotto sarà nella class library:

mentre nell’assembly dei contratti:

sulla macchina dell’utilizzatore il motore di analisi statica del codice sarà nuovamente in grado di fare tutti i suoi ragionamenti e verificare il codice che accede alla class library notificando i potenziali problemi, garantendo anche all’utilizzatore che il contratto sia stao rispettato.
Quello che abbiamo visto è solo una piccola parte di quello che si può fare, le varie “assert” possibili con Code Contracts sono veramente tante, la documentazione fortunatamente, anche se ridotta ad un semplice pdf, è esaustiva.
Una cosa di cui non ho parlato, ma che è decisamente potente, è che c’è anche la possibilità di esprimere contratti sulle interfacce, eccezziuuunale veramente
Attenzione: è una cosa in divenire… e come tale va presa con le pinze. Quello che sappiamo è che:

• ci sarà nella RTM del fx 4.0;
• i nomi cambieranno: CodeContract –> Contract;
• molto probabilmente non sarà più un assembly Microsoft.Contracts e quindi non sarà più necessario aggiungere la reference a mano, con il CLR v4.0 il namespace System.Diagnostics.Contract sarà definito in mscorlib.dll;

Se mettiamo insieme i 3 mondi TDD/UnitTesting + Code Contracts + PEX abbiamo in mano la possibilità di avere controllo quasi totale su quello che sta succedendo per il resto c’è il fidato e inseparabile debugger… come cosa è PEX?!?!?!: http://research.microsoft.com/pex/ …prossimo post… abbiate fede :-D
Che dire a me piace un sacco… CodeContract.Requires( ( Mauro as IHappyDeveloper ).BeginUsing() );
.m

Quando le “cose” ti complicano la vita

Disclaimer:

• non voglio parlare del mondo Open Source in generale;
• racconto semplicemente i fatti che mi sono accaduti;
• Non accetto che questo post scateni una polemica sterile sulla diatriba Open Source/Closed Source/Sw Commerciale in generale;
• accetto solo commenti in topic;

---

Ieri ho parlato della necessità di recuperare dal repository ufficiale di Castle la “latest version” del framework e di compilarla. Bene, non è stata un’esperienza user friendly.
Vediamo cosa ho fatto e cosa secondo me non è andato per il verso giusto:

• Il primo tentativo è stato quello di collegarmi al build server di Castle e recuperare direttamente da li l’ultima successfull build:
  1. il link all’ultima build funzionante punta alla build 196 mentre al momento della scrittura c’è anche la 980… 980-196?;
  2. qualsiasi build funzionante si scelga puntando al file zip si ottiene un bel Http404;
• Fallito il primo tentativo… ho scaricato e installato TortoiseSVN: tutto perfetto;
• Ho configurato il client per accedere alla trunk: http://svn.castleproject.org:8080/svn/castle/trunk/, anche qui senza problemi di sorta;
• ho fatto il download della latest version:
  1. siccome tra l’immensità (immensità non è una critica ma una semplice constatazione sulle dimensioni del progetto) di cose che sono venute giù ci sono delle solution di Visual Studio 2008 la prima cosa che ho fatto è stata aprire la solution e cercare di compilare… nisba, niente da fare;
  2. allora apro il bel “readme”, sono un po’ allergico alle istruzioni… :-D e leggo che:
     1. per poter usare Visual Studio è necessario prima portare a termine una compilazione non NAnt: e qui sinceramente non ne capisco i motivi, meglio tecnicamentge so perchè ma non vedo il nesso;
     2. il readme dice anche che con la versione 0.85 di NAnt tutto dovrebbe andare via lisco;
     3. sempre nel readme c’è una postilla che dice che se voglio supporto per il fx 3.5 devo usare la 0.68b: dico… se la 0.85 dovrebbe fare tutto bene non vedo perchè usarne una più vecchia…;
  3. Scarico e installo NAnt 0.85;
  4. Anticipo gli avvenimenti e scarico e installo NUnit ;-)
  5. leggo sempre dal readme che basta da prompt lanciare un bel “nant” e il gioco è fatto…:
     1. mica vero :-D
     2. per semplificare le cose bisogna mettere nei path il percorso dove si trova NAnt;
     3. per semplificare le cose bisogna mettere nei path il percorso dove si trova NUnit;
     4. a questo punto la compilazione parte… e fallisce pure :-S, ma come… il readme diceva che…
     5. l’errore è quanto meno criptico e si riferisce alla mancanza di csc.exe e del framework sdk!?!?! in realtà si scopre poi che non è vero è solo l’errore che la dice sbagliata ;-) non che quelli di MS siano sempre migliori in questo campo sia chiaro :-D;
• iniziano i problemi e il readme non serve più a nulla :-D, l’ho detto io che le istruzioni non servono…;
• San Google porta ad alcune possibili soluzioni per problemi però diversi… ma una è illuminante:
  • se avete installato “solo” Visual Studio 2008 + Windows SDK i path sono un po’ diversi da quelli che si aspetta NAnt;
  • la fatidica versione 0.68b di cui parla il readme in realtà è la beta 1 della 0.86… “semplice errore” di digitazione…
• Scarica e installa la 0.86b;
• Riconfigura i path
• lancia nuovamente NAnt e finalmente osserva l’EeePC che compila alla grande :-D;

Considerazione personale: ma perchè? secondo me bastava aprire la solution e compilare… perchè non è stato possibile? il giochetto mi è costato un buon paio d’ore sottratte alla mia colazione e ginnastica mattutina… secondo me troppo.
Cosa non mi è piaciuto:

• il progetto Castle Windsor è in 1.0RC1 dal settembre 2007 ma sul repository siamo mostruosamente più avanti;
• troppo complesso per portare a termine un task semplicissimo: fare una build;
• necessità di usare versioni “beta” per dei semplici path diversi del fx3.5 + Windows SDK che è in RTM da una bel po’ ormai;
• in generale non ritengo che la cosa sia alla portata di un utente medio… non che non ne abbia le capacità ma non è detto che abbia la testardaggine/voglia di risolvere il problema, e questo va sicuramente a ridurre l’adoption, in questo caso di Castle Windsor;

.m

BASTA!

è ufficiale e quindi posso dirlo :-D, faccio parte degli speaker della prima edizione di Basta! Italia che si terrà a Roma a marzo dell’anno prossimo.
Ho una sessione a me abbastanza familiare:  Inversion Of Control: anatomia di una soluzione.
Sono decisamente elettrizzato e contento.
.m

Per quelli che Vista…

…è un catorcio succhia risorse.
Possiedo un EeePC 904HD così configurato:

• Intel Celeron 900;
• 2Gb RAM;
• HD 160Gb;
• Scheda Video Intel qualcosa integrata;

Con installato:

• Windows Vista Ultimate;
• Visual Studio Team Suite 2008;
• Sql Server 2005;
• Office 2007 Ultimate;

Va…, non solo va…, ma va più che dignitosamente tanto che durante i viaggi sta diventando la mia macchina di produzione.
Stamattina ci ho pure messo TortoiseSVN, NAnt e NUnit e ci ho compilato e testato l’intera trunk di Castle Windsor in tempi più che dignitosi. E nei giorni scorsi ci ho fatto pure girare la VM di VS2010 CTP2… su Virtual PC… si ok questo non ci riprovo :-D
my 2 cents ;-)
.m

Castle Windsor: la registrazione dei componenti.

Si sa sono un fun di Castle Windsor e in generale del mondo IoC, una cosa però veramente tediosa, prona ad errori, scomoda e decisamente ingombrante dei framework di Inversion of Control è la gestione del file di configurazione, soprattutto se usate massicciamente i generics. Questo perchè per gestire una situazione, decisamente triviale, come la seguente:

public interface IMyComponent
    where T : IDispatcher
{

}

public interface IDispatcher
{
    void Say( String msg );
}

class MyComponent : IMyComponent<IDispatcher>
{
    public MyComponent( IDispatcher dispatcher )
    {
        dispatcher.Say( "from MyComponent.ctor" );
    }
}

class MyDispatcher : IDispatcher
{

}

il file di configurazione che ne consegue è qualcosa del tipo:

<components>
  <component 
    id="dispatcher" 
    service="Sample.IDispatcher, Sample" 
    type="Sample.IDispatcher, Sample" />
 
  <component 
    id="myComponent" 
    service="Sample.IMyComponent`1[[Sample.IDispatcher, Sample]], Sample" 
    type="Sample.MyComponent, Sample" />

components>

notate come la gestione dei generics in forma di “full type name” non sia proprio “user friendly”, per ovviare a questo problema tempo fa mi ero inventato un tool da command line che fosse in grado di analizzare gli assembly del progetto e sulla base di una serie di atrtributi custom costruire lo scheletro del file di configurazione. la cosa funzionava e funziona tutt’ora molto bene, ma al complicarsi della configurazione il supporto che vi da il tool è sempre minore.
A questo punto mi sono fatto una domanda: ma quale è il vantaggio di avere la configurazione in un file xml esterno?
la prima risposta potrebbe essere quella di avere la possibilità di manipolare la configurazione a caldo… ma è proprio vero che serva? imho neanche lontanamente se non in casi veramente triviali… cioè se stiamo usando un framewrok di IoC in una applicazione corposa prima di mettere mano alla configurazione in produzione ci pensiamo ben più di 2 volte e passiamo da una serie di stage per testare la nuova configurazione ergo a che ci serve la complessità di un file xml? se la pensiamo unita alle possibilità infide di errore assolutamente a nulla.
Perchè allora non pensare di esprimere in una forma diversa la configurazione? perchè non farlo direttamente in C#?

n.d.r.:Attualmente ci sono anche altre possibilità tra cui la più blasonata, ma con tutta una serie di limiti, è sicuramente Binsor un linguaggio per DSL che si integra con il framework.

Si potrebbe cioè pensare di esprimere la configurazione in una sintassi a noi ben nota, typesafe e compile time checked, esprimerla in un assembly separato e caricare quallo a runtime e usarlo per configurare il container. In questo modo per variare la configurazione ci basterebbe ricompilare quel singolo assembly e rifare il deploy solo di quello.
Con al versione attuale di Castle (1.0RC1) è tutto tranne che un’operazione semplice perchè l’API esposta dal Kernel è tutto tranne che semplice ed intuitiva.
Ma… se recupariamo l’ultimissa versione di Castle, la trunk via subversion, ci troviamo di fronte alla possibilità di esprimere la configurazione sopra citata in una maniera decisamente più naturale:

IWindsorContainer container = new WindsorContainer();
IKernel k = container.Kernel;
k.Register( Component
    .For<IMyComponent<IDispatcher>>()
    .Named( "iMyComponent" )
    .ImplementedBy<MyComponent>()
    .LifeStyle.Is( Castle.Core.LifestyleType.Singleton )
    .Parameters( Parameter
        .ForKey( "dispatcher" )
        .Eq( "${iDispatcher}" ) )
        );

k.Register( Component
    .For<IDispatcher>()
    .Named( "iDispatcher" )
    .ImplementedBy<MyDispatcher>() );

utilizzando infatti il supporto per le fluent interfaces possiamo reggiungere lo stesso scopo che raggiungiamo con il file xml e continuare ad usare il motore di IoC come siamo abituati:

IMyComponent<IDispatcher> cmp = container.Resolve<IMyComponent<IDispatcher>>();
cmp.Execute();

non male, decisamente non male.
.m