Maurizio's blog 3.0

Con grande piacere mio e degli amici di xplan.org siamo tra gli sponsor della DevLeap Conference 2006, un evento annuale organizzato da DevLeap e dedicato agli approfondimenti delle nuove tecnologie legate al mondo degli sviluppatori.

Ho sempre apprezzato DevLeap per i contenuti tecnici di altissimo livello che è possibile consultare attraverso il loro sito, pieno zeppo di articoli tecnici di approfondimento, adatti quindi a lettori in possesso di una certa esperienza della tecnologia e non già alle prime armi.

Circa 2 anni fa ho avuto la fortuna di conoscere personalmente Marco Russo, a Bari per una conferenza Microsoft sulla sicurezza della piattaforma .NET, e di partecipare ad una cena post-evento organizzata dall’amico Gianluca Cannalire.

Non mi lasciai sfuggire l’occasione di parlare con Marco degli argomenti più svariati, non ultimo le certificazioni Microsoft visto che lui ne possiede “qualcuna”.

Sinceramente rimasi sbalordito dalla vastità delle sue conoscenze informatiche, che spaziavano dallo sviluppo puro del codice all’architettura Win32, alla Business Intelligence ed a molto altro Già durante la conferenza Marco aveva dato prova della sua abilità mostrando, ricordo, alcune tecniche di “code injection” effettuate con una semplicità disarmante da un programmino C++ di poche righe.

Da allora, anzi da prima ancora, il suo blog (ma anche quello delle altre persone di DevLeap, come Paolo Pialorsi e Roberto Brunetti) è oggetto di quotidiana lettura da parte mia, dove è possibile leggere riflessioni molto interessanti sulla programmazione e sulla Business Intelligence.

Ho partecipato e partecipo tutt’ora ad un sacco di eventi per sviluppatori, ma ricordo ancora l’evento di Bari e soprattutto l’incontro con Marco con molto piacere.

Creare pagine web conformi agli standard di accessibilità e XHTML è oggigiorno fondamentale per garantirsi la corretta interpretazione delle varie pagine da parte di tutti i browser utilizzati. Questo articolo di MSDN mostra come costruire pagine web conformi a tali standard in ASP .NET 2.0

Una tra le feature più innovative di ASP .NET 2.0 è il cosiddetto Virtual Path Provider. Devo dire però che, dopo aver approfondito l’argomento grazie a questo post di Dino Esposito e da lì al link relativo all’articolo su MSDN, non riesco ancora a trovare un campo di applicazione “logico” per questa nuova funzionalità, almeno in ambienti di produzione ad alta disponibilità. Attraverso questa feature si avrà la possibilità di astrarre la risorsa fisica (file, directory) che viene inglobata nella richiesta di una pagina ASP. NET. Questa risorsa fisica in ASP .NET 1.1 deve obbligatoriamente trovarsi sul file system e da nessun’altra parte. In ASP .NET 2.0 questo non è più vero, nel senso che ogni risorsa fisica si troverà di default sul file system, a meno che non venga implementato un Virtual Path Provider personalizzato che a fronte di una richiesta di risorsa effettui un mapping della stessa su un diverso repository, es. database, file ZIP. ecc.

Insomma, potremo creare un intero sito web senza alcun file aspx presente su disco (a parte il global.asax). Sono curioso di capire quanto questa innovazione potrà davvero essere utile in scenari già di per sè complessi, quanto potrà incidere sulle prestazioni in generale e che impatto avrà su attività comuni quali il deployment e l’aggiornamento di un sito web.

Sono graditi eventuali feedback di coloro che avessero già avuto modo di implementare questa funzionalità in ambiente di produzione.

E’ disponibile per il download la versione 4.0 di .NET Pet Shop, una applicazione “benchmark” di esempio per confrontare le prestazioni di una applicazione ASP .NET di classe enterprise con una equivalente applicazione J2EE. La versione 4.0 è focalizzata su ASP .NET 2.0 e mostra come ottenere una applicazione robusta riducendo il numero di righe di codice sorgente necessarie.

In questa versione è possibile vedere all’opera le seguenti caratteristiche della versione 2.0 di ASP .NET e del .NET Framework:

1. Uso del nuovo namespace System.Transaction per la gestione di applicazioni distribuite senza ricorrere a COM+, aumentando le prestazioni
2. Uso dei generics
3. Master Pages, Profile e Memberships
4. Controllo Wizards
5. Elaborazione asincrona attraverso MSMQ e System.Messaging
6. Caching dei contenuti con dipendenza da tabelle SQL 2005

Leggendo questo interessante post di Luca Minudel  voglio dire la mia su un argomento per me di estrema attualità.
Sicuramente l’applicazione del cosiddetto “in pair programming” può dare i suoi benefici e rivelarsi determinante nei contesti opportuni circa la buona riuscita di un progetto; mi riferisco a:

1) Raggiungimento degli obiettivi
2) Rispetto dei tempi previsti (o anche riduzione degli stessi)

Il problema è che questa metodologia non può essere applicata alla cieca. Voglio dire con questo che se le forze in gioco sono complementari ed equilibrate e non manca il giusto spirito di condivisione della conoscenza, l’obiettivo è sicuramente raggiunto, anche con qualche difficoltà oggettiva dovuta agli strumenti che si utilizzano che spesso non sono così efficienti da gestire in modo sicuro il lavoro di due persone sullo stesso argomento.

Se invece le forze in gioco non hanno equilibrio si finisce per sovrapporsi creando inutili perdite di tempo, soprattutto quando la conoscenza è vista come un qualcosa di strettamente personale da non condividere con nessuno.

Una caratteristica che ogni buon software dovrebbe, a mio avviso, avere riguarda la leggibilità del codice sorgente, intesa nel senso letterale del termine. Leggibilità significa che, quando si legge codice scritto da altri, non si dovrebbe faticare più di tanto a leggerlo “a colpo d’occhio”.
Molto spesso però si finisce per fare una gran fatica per comprendere codice magari anche non troppo complesso dal punto di vista della tecnica di programmazione, ma scritto decisamente senza alcuna linea guida.
Tra le linee guida minori che, secondo il mio parere, riveste comunque una certa importanza, è da menzionare la lunghezza delle varie linee di codice. Mi riferisco a quelle linee, es dichiarazioni di metodi, di interfacce, ecc., che superano di gran lunga la larghezza di uno schermo a media risoluzione (es. 1024×768) e che costringono ad un lunghissimo scrolling in orizzontale per leggere tutto il contenuto. L’abitudine a scrivere su una sola riga fisica una istruzione peggiora a mio parere la leggibilità del codice, al pari di scrivere senza conformarsi ad alcuna linea guida.
L’ambiente VS non aiuta certamente, in quanto l’editor di codice sorgente non fornisce una guida, una specie di righello alla Word per intenderci, in modo da rendere immediatamente percebibile al programmatore che la scrittura sta per superare il margine destro della finestra.
Però, attraverso un trick non documentato che comporta una semplice modifica al registro di Windows, è possibile ottenere una linea guida verticale del colore desiderato e posizionata alla colonna desiderata, rendendo la soluzione flessibile alle varie risoluzioni dello schermo.
Basta infatti aprire l’editor del registro ed inserire la chiave “Guides” di tipo stringa
nella posizione:

[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\7.1\Text Editor]

attribuendogli ad es. il valore

“RGB(255,0,0) 120”

Come è facile intuire questa chiave crea un righello del colore specificato (in questo caso rosso)
alla colonna specificata (120),  all’interno dell’editor del codice di Visual Studio.
E’ possibile anche creare più di un righello indicando più posizioni di colonna separate da virgola.
Questa soluzione funziona con VS 2003. Per VS 2005 occorre creare la chiave alla posizione
“…\8.0\Text Editor” invece che 7.1.

Se si modifica il Registry mentre VS è in esecuzione occorre riavviarlo affinchè la modifica abbia effetto.