Evangelism 2.0: riflessioni sul business del software da un punto di vista privilegiato! : .NET General

Ricerca di Nucleus su Patterns & Practices

scoriani — Fri, 16 Jan 2009 14:47:44 GMT

Seguo molto attentamente l’evoluzione del programma Patterns & Practices che i colleghi di MS Corporation hanno iniziato ormai tanti anni fa, praticamente con la nascita del .NET Framework, e lo considero una risorsa importantissima sia per le librerie di codice disponibili che per le interessantissime guide. Mi era sfuggita però questa ricerca di Nucleus che presenta esperienze reali vissute da clienti e partner nell’adozione di questi strumenti insieme con suggerimenti e linee guida per introdurli nella propria organizzazione.

Ho sperimentato personalmente il contenuto di questo paragrafo:

“Prepare for adoption resistance

Because patterns and practices introduces standardization and its benefits increase with the rate of reuse, the more broadly Microsoft patterns and practices is adopted, the greater will be the returns. However, changes to development practices typically encounter cultural issues, and Microsoft patterns and practices is no exception. Developers sometimes resist adoption because of its emphasis on
reuse, since developers typically prefer to create their own work rather than customize someone else’s.”

e credo che effettivamente sia lo scoglio più grande da superare per convincere le persone ad utilizzare le componenti di codice riutilizzabile disponibile. In ogni caso, con tutti le dovute cautele, il riutilizzo di tali componenti può portare vantaggi misurabili nello sviluppo di soluzioni di qualsiasi tipologia.

Anche in questo caso, una letta è sicuramente utile…

Team Foundation Server Branching Guide 2.0

scoriani — Mon, 22 Dec 2008 03:51:01 GMT

Nella mia vita professionale ho lavorato, più o meno a stretto contatto, con diverse tipologie di aziende che si occupano di sviluppo software. Da quelle che lavorano più “a progetto”, dove ogni commessa è (quasi) diversa da un’altra, a chi invece si è dedicato alla creazione ed evoluzione di una o più linee di prodotto. Qualunque fosse la modalità con la quale queste aziende si presentavano sul mercato, il problema di gestire il ciclo di vita delle soluzioni software è sempre stato vitale, anche se poi nella realtà gli approcci adottati erano troppo approssimativi e poco efficaci.

Qualche giorno fa è stata rilasciata su Codeplex la guida al branching con TFS, sviluppata da un gruppo di colleghi dei Servizi di Microsoft, chiamati VSTS Rangers, insieme con alcuni contributi esterni, che vuole essere uno strumento utile e interessante per dare uno spunto a chi, nei diversi scenari affrontati, ha proprio la necessità di capire quale strategia di branching è più adeguata alle sue esigenze.

La guida, pur essendo stata pensata per TFS, può in realtà dare degli spunti utili anche per chi utilizza altri strumenti di gestione del codice sorgente e del processo di sviluppo.

Secondo me una occhiata la merita.

Riflessioni su Entity Framework v1 e vNext #2

scoriani — Mon, 20 Oct 2008 19:22:55 GMT

EntityClient

Entity Framework != O/RM

Sappiamo tutti che il buon vecchio pattern in un ADO.NET Data Provider è Connection/Command/Reader, dove attraverso una connessione fisica ad una base dati inviamo un comando in SQL nativo per quella particolare base dati per interagire con il modello logico che rappresenta la struttura fisica dei dati in un particolare database, ed eventualmente riceviamo uno stream di dati ai quali accediamo attraverso un approccio cursor-based in sola lettura. Per interagire con l’EDM, l’Entity Framework ci mette a disposizione un particolare Data Provider ADO.NET chiamato EntityClient. Quest’ultimo presenta l’identico pattern di utilizzo, ma invece di interagire con delle righe e delle colonne ci permette di interagire con delle entità. Accetta quindi un comando che, invece di essere in SQL nativo, ha una nuova sintassi orientata alle entità chiamata Entity SQL (o eSQL), indipendente dal dialetto SQL utilizzato dalla base dati sottostante e dalla struttura logica del database. Questo eSQL “capisce” invece quanto definito nell’EDM (meglio dire nei metadati generati a partire dall’EDM) in termini di relazioni, navigabilità tra le entità e quant’altro. Quando un comando eSQL viene passato all’EntityClient Provider questo lo traduce in un albero di comandi chiamato CCT (o Canonical Command Tree) che viene a sua volta girato all’ADO.NET Data Provider sottostante. Infatti, perchè quest’ultimo sia utilizzabile con EF ha come requisito fondamentale la capacità di ricevere un CCT e di tradurlo nel dialetto SQL che la base dati utilizzata è in grado di risolvere. In seguito all’esecuzione di questo comando l’ADO.NET Data Provider potrà restituire un DataReader all’EntityClient che, in accordo con quanto definito nei metadati generati a partire dall’EDM, prenderà i dati restituiti con un certo formato dalla base dati e li “manipolerà” restituendoli al chiamante con la “forma” delle entità richieste dalla query eSQL. A livello di mapping, i metadati contengono le informazioni legate all’area concettuale (CSpace, l’EDM vero e proprio), all’area di storage (SSpace, tutto ciò che è legato al modello logico dello spazio di storage, tabelle tipicamente ma potrebbe essere altro) e al mapping tra questi due “spazi” di rappresentazione delle informazioni. Questi metadati vengono generati a partire dai tre “asset” chiamati CSDL, MSL e SSDL, oggi conosciuti come schema XML, eventualmente embedded negli assembly della nostra applicazione ma domani chissà… :)

Fino a qui, nulla di tutto questo ha a che fare direttamente con le funzionalità di un O/RM, mentre ha molto a che fare con una sorta di “azionabilità” o utilizzabilità dell’EDM da parte di altre tecnologie che necessitano di un modello concettuale di astrazione rispetto a diverse rappresentazione logiche di dati di natura diversa.

Entity Framework e O/RM

Dove EF inizia a sovrapporsi a tecnologie di Object/Relational Mapping è con l’entrata in campo degli Object Services, componente che abbandona il pattern Connection/Command/Reader per abbracciare concetti quali ObjectContext, DataClasses e ObjectQuery<T>. Gli Object Services possono ancora ricevere comandi in termini di eSQL, come l’Entity Client, ma invece di ritornare un Reader il risultato di una query è una enumerazione di qualche tipo (IEnumerable<T>), la materializzazione di oggetti sulla base delle informazioni restituite dai layer inferiori e delle informazioni relative al modello a oggetti (OSpace) e al mapping (OCSpace) contenute nei metadati. I servizi offerti sono relativi, per esempio, alla materializzazione degli oggetti secondo quanto richiesto dai comandi eseguiti al tracking dello stato delle istanze degli oggetti materializzati e alla persistenza delle modifiche nella base dati sottostante.

Essendo ObjectQuery<T> una implementazione di IQueryable<T>, diventa naturale intuire che gli Object Services di EF sono naturalmente un provider LINQ e consentono quindi anche questa ulteriore modalità, oltre a eSQL di interagire con lo stack sottostante.

Sicuramente in un confronto 1:1 con un tool O/RM esistente come NHibernate (POCO, Lazy Loading, ecc.) o altri, quanto messo a disposizione da EF in questo campo ha dei limiti (come ammesso anche da Tim, PM del prodotto) che la v2 sembra in grado di ridurre rapidamente (qui e qui trovate già alcune implementazioni fatte da persone del team per testare gli scenari per la v2), ma l’obiettivo non è esattamente questo, quanto piuttosto una visione di più ampio respiro che spero queste mie riflessioni abbiano in qualche modo iniziato a spiegare.

More to come…

Storie di successo con NHibernate

scoriani — Sat, 18 Oct 2008 03:40:40 GMT

Forza ragazzi!! Ditemi che sapete fare meglio di così… :)

E’ un feedback che inizio a sentire spesso: tutti ne parlano, certo, fa molto fighetto in questo momento, insieme ovviamente alle solite riflessioni architetturali, che nel 90% dei casi non sono nemmeno adatte agli scenari o ai requisiti del cliente, ma visto che:

Fa fighetto, di nuovo
Tipicamente vi pagano a giornate no? Se ho un cliente al quale riesco a “vendere” i mirabolanti benefici di un approccio di un certo tipo, sono fatture che volano…

Pochi lo conoscono bene, e questo significa che molti andranno a tentoni, utlizzando uno strumento e un approccio che equivale spesso a “sparare con un cannone ad una zanzara”.

Ricordiamoci che la maggior parte di noi non sta sviluppando solo applicazioni mission critical per andare sulla luna….

Nessuno vuole ancora prendersi la risponsabilità di metterci la sua faccia dietro ad un progetto così. Essendo un progetto non MS, come si fà poi ad incolparla in caso che il lavoro che abbiamo realizzato non funzioni a dovere???

Mah, in ogni caso sui vari blog, forum e quant’altro si leggono delle conversazioni surreali, alcune al limite del ridicolo.

Secondo me importante ricordare che:

Controllo, controllo, controllo
CHI HA DETTO CHE IL DATASET E’ IL MALE ASSOLUTO? Come tutti gli strumenti bisogna vedere come si usa, e spesso viene usato a sproposito, e il problema dovrebbe essere del DataSet? Il primo che dice “è pesante….” dopo che si vedono certi mastodonti poi ne parliamo di persona. E quali sono i difetti e i pregi se lo utilizzo come contenitore generico (o meglio ancora tipizzato) di DTO? Non capisco certi thread che vedo in giro… ma siete tutti impazziti? Non date retta a quei 20 prestigiatori in cerca di autore (e di spettatori….).

Meditare gente, meditare…

P.S: per la serie.. c’è gente che ha tanto tempo da perdere in cose veramente poco utili e obiettive…

Project Velocity: e COM+ IMDB rivive!!

scoriani — Mon, 09 Jun 2008 19:33:22 GMT

Chi si occupava già di sviluppo sulla piattaforma Microsoft verso la fine degli anni '90, ricorderà che una delle ultime feature tagliate dall'ultima Beta prima del lancio di Windows 2000 si chiamava In Memory DataBase ed apparteneva alle tecnologie legate a COM+. La cosa passò abbastanza inosservata visto che allora non erano moltissime le applicazioni in architettura distribuita che avevano veramente bisogno di una tecnologia così avanzata, ma all'epoca le motivazioni date furono relative alla potenziale complessità che una soluzione di questo genere avrebbe potuto generare sulla piattaforma.

Oggi, a quasi 10 anni di distanza viene presentato il legittimo erede di IMDB, ovviamente integrato con il .NET Framework e per ora conosciuto come Project Velocity, attualmente disponibile nella sua prima Community Technology Preview.

L'obiettivo di Velicity è quello di fornire alle applicazioni una cache in memoria altamente scalabile e distribuita, in modo da evitare chiamate non necessarie verso il database server, consentendo un incremento delle prestazioni in scenari di grande carico di lavoro. Ovviamente un obiettivo è quello di non impattare per questo sulla complessità delle applicazioni che andranno a utilizzare questo servizio, supportando anche scenari di concorrenza ottimistica e pessimistica e diverse modalità di configurazione.

Componenti del sistema sono un servizio Windows che si occupa della gestione fisica della cache, di una API che consenta ai programmatori di interagire con i servizi erogati e di una serie di file di configurazione del tutto, il tutto distribuibile all'interno di un "cluster" di nodi logici e fisici sulla rete. Ovviamente pre-requisito indispensabile è la versione 3.5 di Microsoft .NET Framework.

In attesa di ulteriori aggiornamenti vi consiglio di scaricare il tutto e di iniziare a fare qualche test, rigorosamente su una macchina NON di produzione :)

Microsoft Software Licensing and Protection (SLP) Services

scoriani — Mon, 26 May 2008 02:17:55 GMT

Qualunque azienda che abbia fondato il proprio business sulla creazione e vendita di software si è posta almeno una volta la domanda su come fare per proteggere la proprietà intellettuale del prodotto realizzato e di evitarne l'utilizzo illegale. Si calcola che l'industria del software a livello mondiale perda qualcosa come 40B$ tra pirateria e contraffazione dei propri prodotti, e non si parla solamente delle grandi realtà multinazionali, ma anche delle piccole software house o system integrator locali che tanto hanno faticato a sviluppare e mettere a punto un proprio prodotto o una soluzione custom per uno o più clienti. Nel tempo sono nate centinaia di soluzioni a questo problema, qualcuna basata su sistemi artigianali e facilmente eludibili, altre su vere e proprie piattaforma di protezione e di gestione delle licenze d'uso. Microsoft è entrata da qualche tempo anche in questo mercato attraverso una soluzione dedicata a chi sviluppa codice managed (leggi che utilizza Microsoft .NET Framework come ambiente di esecuzione) chiamata appunto Microsoft Software Licensing and Protection Services, in breve SLP.

Come funziona?

SLP si differenzia dalle tradizionali tecniche di Obfuscation, Encryption o Code Splitting (con l'utilizzo o meno di dispositivi esterni di sicurezza quali Smart Card o Secure Memory Stick), introducendo il concetto di Secure Virtual Machine (SVM) e di Secure Virtual Machine Language, termini assimilabili in qualche modo al concetto di "Virtual CPU" e relativo linguaggio. Al contrario di tecniche di encryption del Microsoft Intermediate Language (MSIL), che deve essere decrittato prima di essere effettivamente eseguito dal Common Language Runtime (CLR) di Microsoft .NET Framework, il SVML viene eseguito direttamente dalla SVM ospitata direttamente nell'applicazione, formando una coppia univoca diversa per ogni chiave generata dal sistema di gestione delle licenze.

In pratica il processo di protezione dell'applicazione aggiunge al ciclo tradizionale di sviluppo una fase nella quale, attraverso uno specifico tool chiamato SLP Code Protector, viene eseguita una attività chiamata Permutation. Le informazioni legate alla erogazione e gestione delle chiavi di licenza sono prodotte attraverso un prodotto chiamato Microsoft SLP Server 2008 o, in piena chiave Software+Services, dai relativi SLP Online Services combinati con gli Activation Packs, ovviamente pacchetti di licenze singole di attivazione.

Non essendoci librerie esterne, chiavi esterne o embedded o altro del genere, diventa praticamente impossibile sia eseguire attività di reverse engineering sia violare i termini di licenza definiti.

L'obiettivo di SLP è anche quello di bilanciare le esigenze di protezione della proprietà intellettuale con quelle legate alle performance in fase di esecuzione di una applicazione protetta, per questo in fase definizione del codice da proteggere è possibile indicare quali sono le funzioni contenente la logica chiave, il core business dell'applicazione ed evitare invece quelle parti di codice non particolarmente significative.

Per intenderci, al termine della trasformazione il nostro codice sorgente potrebbe apparire, a chi tentasse di disassemblarlo, una cosa del genere:

Ovviamente la componente di back-end che si occupa di generare e gestire le licenze e le relative attivazioni fornisce un ricco set di funzionalità che consentono di creare differenti versioni del proprio applicativo (Es. Enterprise, Standard, ecc.) consentendo agli utenti l'accesso al solo livello di funzionalità acquistate, di creare delle versioni Trial o Time Bombed che scadono dopo un certo periodo di tempo o un determinato utilizzo da parte del cliente, controllando le attivazioni eseguite per ciascuna chiave e fornendo una completa reportistica su qualsiasi evento tracciato dal sistema e relativo alle operazioni legate al licensing eseguite dai propri clienti.

A questo punto l'applicazione presenterà all'utilizzatore finale o a chi è deputato alla sua installazione una maschera simile a quella sottostante per l'attiviazione, supportando una moltitudine di modelli di licensing legati all'acquisto, l'utilizzo o l'aggiornamento della propria applicazione.

In pratica Microsoft SLP consente a chiunque faccia business sulla rivendita di software pacchettizzato o su commessa, di proteggere la proprietà intellettuale della propria creazione garantendo un corretto ritorno economico da parte dei propri clienti che utilizzeranno una modalità semplice ed intuitiva per l'attivazione e l'utilizzo del software acquistato.

Sicuramente la scelta di limitare la disponibilità di questa soluzione al solo codice managed farà discutere, ma questa è una ulteriore conferma di come Microsoft posizioni in pole position la piattaforma .NET Framework per lo sviluppo di soluzioni su client, server e dispositivi. Sul mercato esistono comunque diversi partner (per esempio Acresso, i nuovi proprietari di InstallShield, tra gli altri) che forniscono soluzioni simili per chi ancora sviluppa nel mondo del codice nativo.

A questo indirizzo (http://www.microsoft.com/slps/resources.aspx) potete trovare una serie di risorse tecniche per approfondire la conoscenza sul tema.