Array bound check: operazione onerosa ?

Questa è una domanda che mi sono posto anch’io parecchie volte: il controllo dei limiti inferiore e superiore di un array che il compilatore JIT opera durante l’esecuzione di una tipica applicazione .NET è una operazione onerosa o no, e se si di quanto ? Ci si può fare una idea abbastanza significativa leggendo questo post di Rico Mariani, il quale ha effettuato dei test comparati su una applicazione .NET che utilizza il compilatore JIT tradizionale e la stessa applicazione che invece utilizza un compilatore JIT da lui stesso modificato, e precisamente senza il controllo dei limiti degli array (mscorjit.dll). Dal post si evince che il controllo sui limiti di un array non introduce un overhead significativo, anche se ritengo che la valutazione dipende dal tipo di applicazione. Comunque, aggiungo, se si programma in C# è possibile costruirsi routine di codice unsafe che permettono, tra le altre cose, di gestire array ad alte prestazioni memorizzate sullo stack e non sull’heap gestito, i cui membri sono acceduti sfruttando la semplice aritmetica dei puntatori,  senza alcun controllo di nessun tipo. Questo argomento è stato da me già trattato (spero esaurientemente :)) in un articolo pubblicato sul sito xplayn.org.

Una risorsa fondamentale per il mio lavoro

Di questo link ne faccio un post nel mio blog per tenerlo sempre a portata di….mouse!. Trattasi di una raccolta di link di Scott Gu, uno dei maggiori esperti mondiali di ASP .NET e di .NET in generale, riguardanti tips & tricks, approfondimenti e veri e propri tutorial per chi sviluppa applicazioni web di livello enterprise. Il livello di dettaglio e la chiarezza espositiva di Scott Gu è davvero superlativa, e attraverso il suo blog si entra in possesso di “conoscenza” che forse nemmeno i libri di livello avanzato o i workshop tecnici più spinti riescono a fornire. Ho avuto la fortuna di assistere ad un evento tecnico tenutosi a Roma un paio di anni fa, in cui Scott parlò del suo argomento preferito, ovvero ASP.NET, e posso affermare con assoluta certezza che Scott Gu è davvero un grande e che le sue conferenze meritano sempre di essere ascoltate con attenzione.

Web deployment project, la mia esperienza

Il nuovo modello di compilazione-deployment di ASP .NET 2.0 non è certamente facile da usare e nemmeno intuitivo, soprattutto per chi proviene da ASP .NET 1.0/1.1. 

Non a caso Microsoft ha rilasciato un add-in, il Web deployment Project, praticamente in concomitanza con l’uscita di Visual Studio 2005, che permette di utilizzare il modello di compilazione di ASP.NET 2.0, pur garantendo un alto grado di flessibilità; infatti è possibile compilare una applicazione web  in un singolo assembly, oppure in un assembly separato per ogni sua directory, oppure ancora in un assembly separato per ogni pagina/controllo.

In aggiunta, poco tempo dopo è stato rilasciato un’altro add-in, il Web Application Project, di cui magari parlerò in in post a parte. Per il momento mi limito a dire che ambedue questi add-in non sono supportati da Visual Studio in versione Visual Web Developer.

Se si prova ad lanciare in esecuzione una applicazione ASP .NET 2.0, ogni pagina è compilata “al volo” su richiesta (comportamento di default), e per ogni pagina richiesta viene generato un singolo assembly a cui viene attribuito un nome “non user-friendly”. Questo provoca pochissimi vantaggi, anzi, a mio avviso uno solo, e gravi svantaggi. A questa conclusione ci sono arrivato dopo parecchi mesi di utilizzo di Visual Studio 2005, praticamente dalle versioni beta, a dispetto di un iniziale entusiasmo per il nuovo modello di compilazione. Infatti, in apparenza basta far puntare VS ad una directory del file system che contiene una web application e lanciarla in esecuzione per vederla nel browser senza una sua preventiva compilazione. Non solo, è anche possibile modificare il sorgente della pagina mentre la stessa è in esecuzione, salvare la pagina per vedersi applicate immediatamente le modifiche al codice sorgente senza una ricompilazione (questo piccolo apparente “miracolo” è dovuto al fatto che ogni pagina è compilata in un assembly separato, quindi è possibile scaricare dalla memoria il singolo assembly e ricaricarlo ad ogni modifica della pagina; questo è l’unico vantaggio di cui parlavo prima) . A prima vista tutto ciò può sembrare favoloso, in realtà questo comportamento nasconde parecchie insidie. Prima di tutto affinchè questo modello funzioni è necessario copiare sulla macchina di deployment anche i sorgenti della propria applicazione, praticamente occorre replicare il contenuto dell’applicazione presente sulla propria macchina di sviluppo. Questa è, a mio avviso,una condizione inaccettabile su applicazioni pubbliche che manipolano dati sensibili o che effettuano transazioni economiche; forse è appena appena accettabile su applicazioni funzionanti in intranet che non trattano dati personali.

Inoltre, il nome dell’assemby contenente la pagina compilata è generato a run-time ed univoco, anche se viene ricompilata la stessa pagina compilata precedentemente. Questo significa che è impossibile per una pagina X mantenere un riferimento alla pagina Y, perchè la classe di quest’ultima ed il suo assembly saranno “nominati” solo a run-time con un nome non prevedibile. Questo è davvero un grande problema per coloro che usano web control caricati dinamicamente a run-time, perchè significa che non è possibile ottenere un riferimento “strongly typed” ad un web control caricato dinamicamente, ma solo un riferimento generico “UserControl”, a meno di non utilizzare il tag @Register sulla pagina (il quale forza l’assembly della pagina che contiene il tag a mantenere un riferimento all’assembly che contiene lo user control), oppure, se l’applicazione è compilata in assembly separati per ogni sua directory, occorre che la pagina che referenzia lo user control e quest’ultimo risiedano nello stesso assembly, quindi nella stessa directory fisica.

L’add-in Web Deployment Project permette di “precompilare” l’intero sito in uno o più assembly, e di assegnare a quest’ultimi nomi statici, quindi ripetibili, che permettono alla classe che contiene il codice per una data pagina di essere referenziata senza problemi da un assembly/classe esterna in quanto il suo nome non cambia ad ogni ricompilazione. Utilizzo questo add-in praticamente da sempre e sinceramente, ma è solo un parere personale su cui mi piacerebbe ascoltare esperienze di altri sviluppatori, non riesco ad immaginare una web application che non ne faccia uso, chiaramente intendo applicazioni line of business ad alta disponibilità che girano su server pubblici con un alto indice di richieste.

ADO .NET vNext

E’ disponibile per il download la prima CTP (Agosto 2006) di ADO .NET vNext, comprendente l’entity framework che supporta l’Object Relational Mapping, ovvero l’entity data model per effettuare query sulle entità stile sql (LINQ)

Non esiste solo l’informatica

In questi giorni di vacanze forzate a casa per via di qualche ‘problemuccio’ di salute (per fortuna é passato tutto :)) ho riassaporato 2 tra le mie passioni più grandi: la musica e la lettura. Ho letto altri libri nel frattempo usciti della saga di Carlos Castaneda, scrittore e antropologo peruviano scomparso da qualche anno, e delle sue esperienze con don Juan, un indios Yaqui del Messico. Si tratta di una delle storie più affascinanti che abbia mai letto circa culture e filosofie completamente diverse dalla nostra, che mettono in risalto quanto i nostri sogni, le nostre ansie, paure, il ns. egocentrismo siano nulla di fronte all’immensità che ci circonda. E’ una lunghissima storia che tenta di dare un significato a ciò che la scienza, la ns. cultura, religione cataloga da sempre come ‘inspiegabile’. Il blues è l’altra mia passione, parlo di quella musica nata nei pressi del delta del Mississipi river per opera di gente di colore, molto povera, che lavorava nelle piantagioni della zona, e che attraverso la musica blues esprimeva le ansie, il disagio, le sofferenze di una vita fatta di stenti, ma anche le proprie gioie fugaci, i sentimenti, i sogni, la speranza che un giorno le loro condizioni di vita potessero essere migliori. Tra gli esponenti di spicco del blues di quella zona d’America e tra i miei bluesman preferiti in assoluto menziono Muddy Waters e John Lee Hooker, due artisti il cui connubio voce-chitarra elettrica è di quelli che fanno venire la pelle d’oca a chi li ascolta.

P.S. Scrivo questo post mentre sono in ferie, quindi senza PC (volutamente) e naturalmente senza connessione a lnternet. Ma già mi mancano i blogs, quindi sto usando le note del mio cellulare per poi sincronizzare!! 🙂

So, damn right i’ve got the blues, from my head down to my shoes (B.G.)

NDOC 2.0 ? No, Sandcastle

La versione di NDOC per il Framework 2.0 sembra che non vedrà mai la luce, almeno leggendo le ultimissime notizie. Peccato, ho usato NDOC su parecchi progetti e devo dire che sono sempre stato soddisfatto dei risultati raggiunti con l’utilizzo di questo tool, soprattutto quando manca il tempo per documentare un progetto usando classiche soluzioni alternative. Però potremo produrre docuntazione “MSDN like” usando Sandcastle, il tool usato internamente da Microsoft per la documentazione tecnica dei progetti che la stessa ha deciso di rendere disponibile al download. Si tratta di un tool che via reflection ottiene le informazioni sui vari assembly integrandole con la eventuale documentazione inserita direttamente nel codice sorgente, producendo un contenuto che, manipolato via XSL, permette di ottenere la classica documentazione style MSDN che siamo abituati a vedere ogni giorno.