StrangeLog - Il blog di Andrea Saltarello

ROTFL

Negli ultimi mesi, complice anche la querelle "PI or not" portata alla luce da "vorrei ma non posso (ancora)" Entity Framework, ho ulteriormente riflettuto sul valore di un Domain Model agnostico alla persistenza ed ho concluso che PI non basta. Quello che "voglio" è un DM agnostico alla infrastruttura: non voglio PI, non mi basta. Voglio POCO, ma sembra che sia... Troppo <g> (interessante gioco di parole)

Detta "seriamente", vorrei poter modellare un DM concentrandomi sulla soddisfazione dei requisiti "business" (DDD anyone?), ed avere uno stack tecnologico in grado di "appiccicare" in qualche modo il codice necessario alla infrastruttura. Tanto per fare un esempio pratico, vorrei poter evitare di *sporcare* il mio DM implementando INotifyPropertyChanged "solo" perchè così alcuni scenari diventano + comodi da implementare. Un approccio già praticabile sarebbe quello basato sulla generazione dinamica dei proxy unita all'uso dei mixin (a proposito, perchè MS non ne parla più?). Per intenderci, con Castle.DinamicProxy2 si potrebbe impostare così:

ProxyGenerator gen = new ProxyGenerator();
ProxyGenerationOptions options = new ProxyGenerationOptions();
options.AddMixinInstance((INotifyPropertyChanged) new INotifyPropertyChangedImplementation());

Product proxy = (Product)gen.CreateClassProxy(typeof(Product), new Type[] {typeof(INotifyPropertyChanged)}, options, new InvokeInterceptor());
return proxy;

In questo scenario, INotifyPropertyChangedImplementation potrebbe usare una hashtable/dictionary per implementare una strategia genericamente valida. Una implementazione di questo tipo, pur soffrendo dell'overhead necessario alla generazione dei proxy, sarebbe sufficiente nella maggior parte dei casi. Un'altra opzione che sto indagando si basa invece sulla code generation a compile time: probabilmente basterebbe una "custom action" per msbuild, e se fossi MS indagherei seriamente in tal senso.

Ciò di cui sono sicuro è che l'esigenza di un DM "infrastructre agnostic" sia fondamentale: su Linq 2 SQL pende una spada di Damocle e Entity Framework è, negli interessi di MS, il perno della propria strategia MDD. Già sappiamo che le entità gestite da EF saranno recepite (per esempio) dai Reporting Services di SQL Server, quindi è importante evitare sin da subito di avere un DM all'interno del quale ogni framework/sottosistema infili il proprio "ciarpame": il DM è "business", e tale dovrebbe rimanere.

Premessa: questo post è esplicitamente diretto ad un "pubblico" dark e/o indie: astenersi perditempo e alternativi :-)

Loro sono i modenesi FATA ed hanno pubblicato un singolo d'esordio che è troppo bello per essere vero, solo che poi li ascolti live e capisci che è.... "Davvero vero". Una "sindrome da primo ascolto" paragonabile a quella causata da Lights degli Editors, per intenderci. Come dice il famoso proverbio: Ascoltatore avvisato, mezzo album "La percezione del nero" comprato <g>

Capisco che era il bancone delle "offerte speciali", ma in ogni caso vedere nello stesso scaffale Opel di Syd Barrett e l'album dei 30 Seconds to Mars mi perplime.

Raffaeu mi porge un (gradito) complimento, che è però anche un interessante spunto per una riflessione. BTW, niente di nuovo all'orizzonte, perchè è una riflessione che ho già ampiamente esposto durante il tutorial dei Community Days, ma ritengo comunque interessante estenderla.

Un moderno emulo di Gian Battista Vico non esiterebbe ad includere il seguente scenario tra i "corsi e ricorsi storici": quando un dev entra in contatto con i [design|architecture|refactoring|vattelapesca] pattern la reazione è, tipicamente, una delle seguenti:

1. Il dev diventa un "pattern fanatic": parla continuamente di pattern e li infila dappertutto (un divertente "asse cronologico"" di questo scenario 1 è disponibile in [Nilsson, ADDD.NET])
2. Il dev li rifiuta in quanto (scegliere il proprio "best pick"): inutili, "acquacaldosi", eccessivamente astratti, ...

Ma i pattern rappresentano (o aggiungono) davvero un valore? Parliamone :-)

Partendo dal presupposto che la soluzione sia basata sul FX .NET o comunque implementata utilizzando un linguaggio che aderisca al paradigma object oriented, quando "progettiamo" ("to design" in inglese) un sistema dovremmo farlo tenendo *bene* in mente i requisiti e i princìpi di progettazione OO; i requisiti rappresentano ciò che il sistema deve fare e per un architetto sono "sacri ed inviolabili" giacchè:

• Se funzionali, sono di competenza di un analista che ha *sicuramente* una comprensione del dominio  superiore alla nostra
• Se non funzionali, sono frutto di qualche accordo "contrattuale" (es: SLA)

Ergo, non è certo inclusa nella "carta dei diritti" di un architetto la possibilità di modificarli a propria volontà. Per quanto riguarda i requisiti, inoltre, la norma ISO9126 svolge un ottimo lavoro di categorizzazione e rende evidente la natura di requisito di "topic" (troppo) spesso trascurati quali (a puro titolo di esempio ed in rigoroso ordine alfabetico): interoperability, security e testability.

Affrontato il "cosa", dedichiamoci al "come": un buon architetto è un uomo (o donna) di... Sani princìpi :-) Dal primordiale "...you must find pertinent objects..." ai vari DIP/LSP/OCP/SRP/... essi sono il "razionale" che ci deve guidare nelle nostre scelte progettuali a qualunque livello di dettaglio. Se anche i pattern non esistessero, questi principi ci permetterebbero in ogni caso di scrivere del "buon codice". Ma i pattern esistono, quindi... Che fare? Semplicemente, non vivere "inseguendoli" (i pattern). Non "snobbiamoli/ignoriamoli", ma impariamo ad evere un approccio rilassato nei loro confronti. Affrontiamo un problema alla volta e, se avessimo l'evidenza che quello che stiamo affrontando sia risolto da un pattern, usiamolo senza remore: nessuno oggi si inventa una tecnica risolutiva per il problema "gestione di un documento strutturato" quando esiste Composite.

Spesso però confondiamo una congettura con una evidenza, e dovremmo invece migliorare la nostra capacità di riconoscere le congetture. Di fronte ad una congettura, trasformiamoci in Pollicino ed usiamo requisiti e principi come "traccia" per affrontare lo scenario: facendolo sistematicamente realizzeremo comunque una soluzione strutturalmente simile a "qualche" pattern, nel qual caso valuteremo se un "refactoring to quel pattern" possa portare del valore aggiunto, altrimenti... Squadra che vince non si cambia :-)

In (estrema e quindi approssimativa) sintesi: i pattern possono essere un "fine" (refactoring to pattern) od un "mezzo" (abbiamo un problema *chiaramente* risolto da un pattern in modo ottimale), e a volte "il fine giustifica i mezzi". Di certo non "sono" un valore, anche se "hanno" valore, giacchè sono "soluzioni *dimostrate* funzionanti a problemi ricorrenti".

Ho migrato NSK alla versione refresh4 del framework ASP.NET MVC rilasciata ieri, "fondendo" la web app con il sample project standard in modo da avere "gratis" l'implementazione della login: poichè è basata sul SqlMembershipProvider, è necessario creare il "solito" aspnetdb.mdf in App_Data.

Non ho sperimentato alcun problema particolare, se non un "bisticcio" con la custom controller factory che ho implementato per iniettare nei controller l'istanza del data context: sono incappato in un comportamento quanto meno "particolare" di Unity ed ho piazzato un piccolo hack workaround in Application_OnStart per risolverlo.

Ricapitoliamo:

• MS ammette pubblicamente che la PI è un punto fondamentale per un O/RM
• Per evitare di soffrire ulteriormente di problemi di eiaculazione precoce, MS ha allestito un focus group dedicato alla v2 di Entity Framework coinvolgendo *finalmente* gente esperta di queste tematiche: Eric Evans, Jimmy Nilsson, Martin Fowler, Pavel Hruby, ...
• Per supportare *seriamente* PI c'è bisogno di poter "proxare al volo" il DM
• Per "proxare" al volo senza eccessive penalizzazioni in performance serve Reflection.Emit
• Reflection.Emit è incapsulato egregiamente da DynamicProxy, un "pezzo" del Castle Project
• Unity (il container IoC di Enterprise Library 4.0) paga pegno se confrontato a Windsor: no proxy, no supporto *serio* ad AOP, ...
• Microsoft ha assunto Hamilton Verissimo, il papà di Castle Project

Di ottimismo non se ne parla, visto che stiamo parlando dell'azienda che è riuscita a far fuggire Ward Cunningham e che ha sistematicamente ignorato quello che "pirla" quali il sottoscritto le dicono da anni nei focus group; però, si trattasse di una partita di tennis, direi che hanno recuperato 2 set di svantaggio ed effettuato un break al 5°: in queste condizioni, se perdi la partita sei un pirla. La bellezza del framework MVC e l'avvento di Unity sono comunque degli *ottimi* segnali. Continuo a pensare che il match point lo si possa conquistare assumendo Gavin King.

UPDATE: si, lo so che Hamilton non lavorerà nè su EF nè sul FX blah blah blah... Diciamo che mi accontento di una reprise della soap opera avvenuta ai tempi di James Newkirk, l'autore di NUnit che fu ufficialmente assunto da MS per lavorare alle P&P anche se, guarda caso, poco dopo nacque MSTest *integrato* in Visual Studio ed era *uguale* ad NUnit. <g> Diano ad Hamilton anche il ruolo ufficiale di "Coffeemachine Manager", purchè "casualmente" poi EF2 sia un buon O/RM e che la BCL disponga di un container IoC con funzionalità di proxying ed interception <bg>

Poichè Igor ha avuto la malsana idea di taggarmi, non posso esimermi dal partecipare al meme ed eccomi qui a parlare della cause della mia sciagura scelta di "essere un dev".

How old were you when you started programming?
A quale età hai cominciato a programmare?

Più o meno, ho iniziato a provarci all'eta di 8 anni. Per maggiori dettagli... C'è la risposta successiva :-)

How did you get started in programming?
Come hai cominciato a programmare?

Beh, una sera mio zio si presentò a casa nostra con un Commodore VIC-20 acquistato presso lo spaccio aziendale, tentando di convincere mio padre (riottoso nei confronti di ogni forma tecnologica successiva alla televisione) ad acquistarlo a sua volta per non meglio precisati "scopi professionali". Ben sapendo che mio padre non lo avrebbe mai utilizzato, insistetti come solo un figlio rompiballe determinato sa fare e attesi che mio padre, entrato in possesso dell'oggetto misterioso, lo lasciasse in soffitta per 3 mesi prima di far valere la mia personale versione dell'usucapione. <g> In poche parole, se oggi passo notti insonni davanti al monitor è per colpa di mio zio, che infatti è stato duramente punito per la sua colpa, giacchè lavora come sistemista <g>

What was your first language?
Qual’è stato il tuo primo linguaggio di programmazione?

CBM Basic V2, il glorioso interprete disponibile sul "mio" VIC-20.

What was the first real program you wrote?
Qual’è stato il primo programma vero che hai scritto?

Se intendiamo il primo programma dotato di funzionalità "interessanti", lo scrissi in terza media insieme ad alcuni compagni di classe: era una simulazione molto "approssimativa" del movimento degli elettroni di un atomo intorno al nucleo ed era parte di un progetto che avremmo presentato presso una mostra organizzata per "festeggiare" la fine dell'anno. La mia prima impresa solitaria, invece, fu costituita da un piccolo software che disegnava diagrammi di Bode e Nyquist che scrissi durante la frequentazione dell'ITIS Feltrinelli e che venne allegato al libro di informatica scritto da uno dei miei professori.

What languages have you used since you started programming?
Quali linguaggi hai usato da quando hai cominciato a programmare?

In rigoroso ordine alfabetico: assembly Z80, assembly ARM, ANSI C, BASIC (Amigabasic, AMOS, CBM V2, Borland Turbo Basic, Visual Basic dalla v3.0 alla 6.0, VBS, Visual Basic .NET), Delphi 1.0 e 2.0, C++, C#, Java

What was your first professional programming gig?
Quando è stato il tuo primo vero lavoro da programmatore?

Durante i miei scarsi trascorsi univesitari, venni arruolato da uno dei miei professori che possedeva una piccola software house ben "agganciata" al mercato grazie ai suoi "contatti". Mi ritrovai a lavorare sul software di colorazione utilizzato per colorare le tavole delle edizioni italiane dei fumetti di Marvel Comics, scritto in linguaggio assembly ARM (per intenderci, è la stessa famiglia di CPU tutt'oggi usata sulla maggior parte dei device Windows Mobile) su workstation RISC Acorn Archimedes. Per intenderci, col "mio" software coloravano le tavole dell'Uomo Ragno. Una volta mi portarono presso la tipografia dove vidi le tavole "uscire colorate": tornai a casa camminando ad un metro da terra. Figata.

If you knew then what you know now, would you have started programming?
Con il senno di poi, rifaresti lo stesso il programmatore? Ricominceresti a programmare?

Tutta-la-vita.

If there is one thing you learned along the way that you would tell new developers, what would it be?
Se ci fosse una cosa che hai imparato nella tua carriera e che vorresti dire ai giovani programmatori, cosa diresti?

Spaccate tutto, ma senza esagerare. E non abbiate fretta di "arrivare". Ma soprattutto scordatevi di avere orari "normali"

What's the most fun you've ever had ... programming?
Qual’è la cosa più divertente che hai programmato?

Beh... UomoRagnoUomoRagnoUomoRagnoUomoRagno <g>

Now, let’s tag someone else...
Adesso è l’ora di taggare qualcun’altro...

• The Carucci bros
• Il mitttico Ughetto
• SuperGab
• "El Janky", che così magari ci degna di una "apparizione" <g>
• Alessandro a.k.a. "Il Duca di Bentivoglio"
• Semplicemente... Lawrence
• Massi "JitMan" Mantione

ScottGu comunica che è imminente il rilascio della preview 4 di ASP.NET MVC: continuo a pensare che (come sostenni nel corso di un focus group a Redmond 1 anno addietro) scegliere MVP sarebbe stato preferibile, ma in ogni caso questo toolkit si fa sempre più interessante. Nello specifico, la nuova drop includerà feature appetitose quali il supporto out of the box alla cache di ASP.NET ed alla role-based security mediante i membership provider.

Durante la (ancora una volta ho scoperto piacevolmente che può funzionare) Q&A finale ho capito che il plurale del termine Community non è Communities ma Community...solo più grossa. Esattamente come due stormi formano...uno stormo. Da queste piccole riflessioni possono nascere grandi cose.

E' una affermazione che esprime fedelmente il mio pensiero, e che IMVHO richiede una profonda sensibilità per essere pensata e formulata. Non mi stupisce che l'autore sia Omar

Da parte mia... Grazie a tutti: erano anni che non provavo una emozione simile, e questa volta non ho nemmeno dovuto vestirmi come "una trottola" :-)