Maurizio's blog 3.0

Scripting dei dati di una tabella di Sql Server 2005 mediante generazione automatica di istruzioni di insert. Questa funzionalità avrebbero a mio avviso dovuto includerla almeno già da un paio di versioni poichè in alcuni casi risulta davvero utile. Anzi, ricordo che durante consulenze passate qualche collega particolarmente devoto a Oracle trovava motivo di denigrare il dbengine di Microsoft a favore di Oracle solo perchè questa funzionalità era assente. Da quell’immenso repository di codice e documentazione che va sotto il nome di Code Project è possibile scaricare questo add-in per Sql Server 2005 Management Studio, che mette a disposizione una nuova voce di menù contestuale sull’item di una qualsiasi tabella permettendo di generare automaticamente le istruzioni di insert per tutte le righe o per un sottoinsieme di esse. L’add-in è  un assembly .NET 2.0 che si registra come componente COM e come add-in per SSMS. E’ disponibile al download sia la versione binaria che quella con i sorgenti (C#). Quest’ultima torna utile soprattutto come modello per creare altri add-in per SSMS.

Questo è un evento da non perdersi assolutamente, farò tutto il possibile per essere a Milano, Centro Congressi Microsoft, il prossimo 27 settembre, semprecchè il mio lavoro di consulente mi lasci il tempo per parteciparvi (sembra strano che un consulente non abbia la possibilità di organizzare il proprio tempo, ma spesso è proprio così).
L’evento è organizzato dal team di Devleap, e questo è certamente una garanzia di qualità.
L’argomento sarà Visual Studio Team System visto molto dal punto di vista pratico; è il mio strumento quotidiano di lavoro non solo per scrivere codice, ma anche per per effettuare UnitTest, WebTest, LoadTest, Code Analyzer, Application Designer ecc. ecc., i quali vengono spesso interpretati come strumenti utili ma troppo onerosi dal punto di vista del tempo – in altre parole – come un rallentamento della normale attività di sviluppo dove normalmente l’improvvisazione e la fretta di consegnare regnano sovrane, ma questo è un altro discorso, che magari sarà oggetto di un post a parte. Chiunque abbia voglia di condividere idee, esperienze, ecc può contattarmi a: maurizio_AT_xplayn.org

La start page di Visual Studio 2005 presenta la lista dei recents projects, contenente progetti e soluzioni aperti di recente. Questa lista può diventare presto inutile per coloro che aprono/creano un progetto/soluzione “una tantum” solo per motivi di test, e magari dopo aver verificato il funzionamento il progetto viene addirittura cancellato dal disco.  Infatti la lista non è modificabile in alcun modo tramite GUI, ma da registry sì.

Posizionandosi su questa chiave

HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\8.0\ProjectMRUList è possibile cancellare le voci non più valide e “ripulire” quindi la lista dei recents projects.

Ai tempi in cui utilizzavo Visual Studio 6.0 (tanto tempo fa, ma anche adesso, ogni tanto…:)),  una delle funzionalità dell’IDE che più mi tornava utile era la possibilità di compilare ed eseguire porzioni di codice senza doverli necessariamente salvare sul disco in progetti e soluzioni (allora si parlava di progetto e gruppi di progetto). In Visual Studio 2002/2003 questa funzionalità è assente, con la conseguenza di veder proliferare sul proprio hard disk progetti e soluzioni che non hanno alcuna utilità ma sono solo il risultato di prove di qualche “snippet code”. A dir la verità ho anche utilizzato un tool freeware chiamato Snippet Compiler, molto valido, che, come dice il suo stesso nome, è in grado di compilare ed eseguire al volo snippet code ed opzionalmente salvarli su disco, con tanto di presenza dell’intellisense, anche se a mio avviso non impeccabile. In Visual Studio 2005 questa funzionalità è riapparsa sotto il nome di “Zero Impact Projects” (ZIPs). Infatti, posizionandosi in Tools\Options\Project and Solutions\General, è accessibile il check “Save new projects when created” il cui valore di default è “checked”. Disattivandolo, ogni nuovo progetto creato non sarà più salvato su disco se non su esplicita richiesta, permettendo il test “al volo” di un blocco di codice. Tuttavia, creando uno Zero Impacts Projects viene creata comunque una directory con lo stesso nome del progetto sotto il path “Visual Studio 2005” presente nella directory del profilo utente correntemente loggato. Questa directory, anche se vuota, resta presente su disco anche se si opta per non salvare i files del progetto, creando, di fatto, cartelle indesiderate anche se con un impatto molto minore rispetto a Visual Studio 2002/2003.

I visualizers sono una utilissima feature del debugger Visual Studio .NET 2005. Questi componenti agiscono in fase di debug di una applicazione per visualizzare una interfaccia utente creata ad hoc contenente i valori di variabili o di interi oggetti. Un visualizer riflette il particolare tipo di oggetto in fase di debug e visualizza le sue informazioni con l’interfaccia utente appropriata rispetto all’oggetto.

Ad es., il visualizer per il Dataset, già previsto in Visual Studio insieme a quelli per testo, xml e html, visualizza le informazioni di ogni singola tabella in esso contenuta attraverso una visione tabellare delle informazioni.

Un visualizer può funzionare in entrambe le direzioni, vale a dire che l’interfaccia grafica può sia visualizzare le informazioni che modificarle, reinviandole al debugger

Si possono creare custom visualizer ed utilizzarli in fase di debugging. Questo utilissimo visualizer, segnalato anche da MSDN Magazine come uno dei 10 tools che ogni sviluppatore dovrebbe avere installato, permette di visualizzare le informazioni sugli oggetti inseriti nella cache di ASP .NET, comprendenti scadenza, dipendenze da file, da chiave o da tabella.

Premessa:
ho iniziato a programmare seriamente (per lavoro) utilizzando il linguaggio Visual Basic; ho utilizzato questo linguaggio per parecchi anni nelle varie versioni che via via si sono succedute (3.0, 4.0, 5.0, 6.0). Su questo linguaggio ho investito parecchio tempo sia per apprenderlo che per approfondirlo, ricevendo un enorme aiuto dalle community quali Visual Basic Tips & Tricks, solo per citarne una. Ho anche investito del denaro, in quanto i primi esami di certificazione Microsoft che ho passato riguardavano VB6 Desktop & Enterprise, comprandomi libri sull’argomento e pagandomi i test di tasca mia.
Ho scritto parecchie linee di codice in VB6, e le soddisfazioni professionali non sono mancate; ho considerato questo linguaggio altamente produttivo e facile da imparare, ma, confesso, alcune volte mi sono scontrato con problemi non facili da superare dovuti essenzialmente alla intrinseca facilità del linguaggio che tende a mascherare dettagli importanti della programmazione a beneficio della velocità di scrittura del codice.

Con l’avvento di .NET  ho utilizzato da subito il linguaggio Visual Basic .NET, soprattutto perchè provenivo dal VB6 e mi è sembrato naturale continuare ad utilizzare la stessa sintassi, conscio però del fatto che la semantica era completamente diversa. Ho approfondito parecchio la conoscenza del .NET Framework, e questa conoscenza mi ha agevolato tantissimo quando ho dovuto per forza di cose programmare in C#; infatti questo linguaggio l’ho appreso nel giro di pochi giorni poichè il tutto si limita all’apprendimento della sintassi tipica dello stesso, e questo grazie all’indipendenza del Framework .NET dal linguaggio utilizzato.

Adesso uso i due linguaggi in modo intercambiabile, ma la mia preferenza è senza ombra di dubbio per il C#, poichè, a mio avviso, nonostante il VB .NET sia completamente diverso dal suo predecessore, sia finalmente un vero linguaggio ad oggetti e fornisca la stessa potenza del C#, soffre ancora di qualche retaggio del suo passato di linguaggio “facile” ed alla portata di tutti.
 
Sono sicuro che se dovessi aver bisogno di programmare in un altro linguaggio .NET compliant, l’apprendimento dello stesso non durerebbe più di qualche giorno,e questo non per merito mio ma del framework .NET.

Questa lunga premessa mi è saltata in mente leggendo queto interessantissimo post di Diego Cattaruzza in risposta a questo articolo dove si pone in risalto il fatto che Microsoft “costringerebbe” i programmatori VB6 a passare forzatamente a Visual Basic .NET poichè il supporto per VB6 terminerà a Marzo del 2008.

La mia opinione è che Microsoft abbia fatto tantissimo per agevolare questo passaggio, in ordine sparso:

• Eventi gratuiti dove si cerca di fornire una risposta agli interrogativi di chi ha codice VB6 da migrare;
• Rilascio di Visual Basic .NET 2005 Express, versione gratuita dell’ambiente di sviluppo che, seppure con qualche limitazione, permette quantomeno di provare in prima persona la nuova tecnologia;
• Disponibilità gratuita di blocchi di codice (Application blocks) già pronti all’uso per fornire immediatamente le funzionalità comuni di ogni applicazione (log, configurazione, accesso ai dati,ecc)
• il termine della fine del supporto per VB6, inizialmente fissato a Marzo 2005, è stato spostato a Marzo 2008, anche grazie alla famosa petizione internazionale sottoscritta da oltre 10000 programmatori;

Inoltre, come sottolinea chiaramente e giustamente lo stesso Cattaruzza, la vecchia infrastruttura basata sull’accoppiata Win32/COM+ è assolutamente inadeguata a sostenere l’evolversi dei sistemi di comunicazione attuali; la nuova infrastruttura è basata sul .NET Framework e quindi non ha assolutamente senso continuare a supportare un linguaggio basato su una piattaforma ormai superata.

Questo discorso resta valido anche per il cosiddetto “programmatore hobbysta”, perchè se cambia l’infrastruttura sottostante lo sviluppo di software basato su Win32 e COM+ perde di significato.

Infine, un parere personale che ritengo di fondamentale importanza: l’evoluzione tecnologica per un informatico deve essere un aspetto da non mettere mai in discussione; è errato pensare che solo perchè si è speso tempo e denaro per essere padroni di una tecnologia non ci si possa rimettere in discussione spendendo altro tempo per impararne un’altra, più evoluta della precedente che permette di essere più produttivi e di scrivere software più efficiente. Questo lo afferma una persona che ha speso tantissimo tempo e denaro su VB6, ma cha ha fatto altrettanto quando l’evolversi della tecnologia lo ha messo di fronte a strumenti più evoluti.
Se si pensa che aver fatto sacrifici per impadronirsi di una tecnologia basta per mantenersi a galla nel mondo informatico sempre in continua evoluzione si commette un grave errore che può riflettersi negativamente sul proprio futuro professionale.

 

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.

Nella versione 1.1 del .NET Framework accedere alla porta seriale per poter leggere/scrivere dei dati richiede l’uso delle API di Windows preposte allo scopo. Pertanto è necessario creare una classe wrapper che incapsula l’accesso alle API e fornisce i metodi pubblici necessari alla gestione della porta ed all’invio/ricezione delle informazioni. Nel .NET Framework 2.0 questa classe wrapper è già presente e ne viene fornito un esempio di utilizzo attraverso uno snippet code presente nell’elenco degli snippet code di Visual Studio 2005.

Pertanto, questa operazione, prima non certamente banale, è diventata di una semplicità disarmante nel Framework .NET 2.

Con l’uscita della versione 2.0 del Framework .NET molte applicazioni ASP .NET migreranno alla nuova versione, che assicura una compatibilità al 100% all’indietro e una migliore compatibilità verso gli standard Web (vedi XHTML). Questa migrazione avverrà certamente per gradi, e ci troveremo sicuramente in situazioni in cui sullo stesso server saranno installate applicazioni ASP .NET compilate con differenti versioni del Framework. Questo non è affatto un problema grazie alla cosiddetta esecuzione side by side del codice gestito, mediante la quale differenti versioni del Framework .NET possono essere installate sullo stesse ambiente di esecuzione; quindi saranno comuni i casi in cui sulla stessa macchina gireranno applicazioni ASP .NET compilate con differenti versioni del Framework, le quali conviveranno in modo pacifico.

Ma c’è una eccezione a questa regola e riguarda le applicazioni ASP .NET che, come sappiamo, possono essere eseguite all’interno di processi distinti attraverso la creazione di uno o più application pool, configurabili attraverso il pannello di controllo di IIS.

La regola è questa: non è possibile far girare applicazioni ASP .NET compilate con differenti versioni del .NET Framework all’interno di uno stesso processo (worker process), pena un errore a run-time documentato chiaramente nell’application log. In casi del genere occorre creare differenti application pool (almeno 2, uno per il framework 2.0 e l’altro per la versione 1.1) ed associare ad ognuno le applicazioni compilate con la stessa versione.

Un’altra soluzione può essere quella di creare application pool distinti per ogni applicazione ASP .NET funzionante 

Se si ospitano più applicazioni web ASP .NET in application pool distinti su macchine multiprocessore dotati di SO Windows 2003 si potrebbe andare incontro ad un lento degrado delle prestazioni fino ad ottenere:

a) OutOfMemoryException

b) Classico messaggio d’errore “Server Application Unavailable”

Questo comportamento è causato dal funzionamento del meccanismo del garbage collector su sistemi multiprocessore. Su tali sistemi il GC è attivo in modalità Server; questa modalità permette di aumentare le sue prestazioni attraverso la creazione di un heap distinto per ogni processore presente, caratteristica che in presenza di vari worker process porta ad un consumo eccessivo di memoria e da qui ai messaggi di errore menzionati. Questo indesiderato comportamento delle applicazioni ASP .NET è indipendente dalla versione del .NET Framework utilizzata, e si verifica su tutte le versioni di Windows 2003 con IIS 6.0 in modalità nativa con multiple appication pool configurate.

Per ovviare a tale inconveniente occorre forzare l’utilizzo della modalità di funzionamernto “Workstation” del GC, modalità che crea sempre un solo heap e quindi non causa un eccessivo consumo di memoria anche in presenza di application pool distinti.

Per abilitare questa modalità occorre modificare il file aspnet.config, raggiungibile nella directory della specifica versione del Framework che si sta utilizzando nel percorso WIndows\Microsoft.NET\Framework, aggiungendo la seguente riga:

<gcServer enabled=”false”/>

al nodo configuration\runtime.

Questa anomalia è documentata qui

Erika Ehrli mostra in questo articolo come implementare un add-in per Visio 2003, utilizzando Visual Studio .NET 2003, per effettuare una query LDAP sugli utenti in Active Directory e creare un diagramma in Visio suddiviso per dipartimento. Nonostante non sia un sistemista ma uno sviluppatore, penso che un add-in come questo mi tornerà utilissimo; in passato mi sono sempre chiesto se Visio non avesse tra i propri diagrammi qualcosa del genere. Davvero un ottimo ed utile esempio di Office Development da provare al più presto

Finalmente ha visto la luce la versione 2.0 della famosissima Enterprise Library, completamente rivista e ridisegnata in funzione della versione 2.0 del .NET Framework. Coloro che come me hanno utilizzato la versione disegnata per il .NET Framework 1.1 avranno certamente apprezzato la flessibilità e facilità di utilizzo che questi componenti forniscono allo sviluppatore e, caratteristica molto importante, la capacità di integrarsi in modo estremamente rapido in applicazioni reali

Visto che ogni inizio anno è tempo di promesse e buoni propositi, non sarò certo io a tirarmi indietro.

In ordine sparso ecco la mia lista di previsioni/speranze/promesse per l’anno appena iniziato:

• Concludere in tempi ragionevolmente brevi il nuovo percorso di certificazione Microsoft MCPD
• Partecipare allo sviluppo di un software open-source (di quelli non banali)
• Imparare un nuovo linguaggio di programmazione  (mi piacerebbe il C++, ma la vedo molto dura)
• Guadagnare di più
• [ ……personale …..]
• [ ……personale……]
• Aver finalmente dato una dimora fissa al mio blog
• Curare di più il mio nuovo sito xplayn.org e questo blog
• Conoscere altri amici informatici grazie alle community e/o blogs
• Che il mio amico di avventura Francesco possa accrescere le proprie soddisfazioni professionali (ed i propri guadagni), perchè se lo merita

Mi auguro che tutto questo si avveri, e auguro a tutti i lettori occasionali e non di questo blog di esaudire i proprio desideri per questo anno appena iniziato.