Articoli

Creare un programma estensibile tramite plugins - Parte 2

Alkampfer — Mon, 29 Jan 2007 00:37:00 GMT

Di: Ricci Gian Maria

La tecnologia .NET consente di iniettare codice in maniera dinamica in un processo, rendendolo di fatto estendibile mediante unità di codice chiamate plugin.

Attributi alla riscossa

Nel precedente articolo sono state esaminate le basi per gestire l’Inversion of Control tramite plugin, in questo articolo si cercherà di dare più dignità alla classe PluginManager in modo da renderla un po’ più robusta. Il problema principale del codice del precedente esempio è che i plugin vengono individuati in base all’interfaccia implementata, generando di fatto due problemi: il primo è che l’esposizione di un plugin all’esterno della dll viene fatta in maniera implicita ed il secondo è che non si hanno informazioni dettagliate da mostrare all’utente. Per risolvere entrambi i problemi è necessario agire su due punti: dare la possibilità di decidere in maniera programmatica quali classi verranno esportate e fornire nel contempo un set di informazioni standard da mostrare all’utente o da utilizzare per gestire il plugin in maniera meno implicita.

Da questa mini analisi si evince subito che un attributo custom è probabilmente la soluzione ottimale dato che consente di aggiungere informazioni ad una classe sotto forma di metadati compilati nell’assembly e può essere utilizzato anche per marcare esplicitamente tutte le classi che dovranno essere gestite come plugin.

Creare un attributo custom per i plugin

Il primo passo è creare l’attributo per identificare i plugin come mostrato dalla classe PluginAttribute presente nell’esempio accluso. La creazione di un attributo custom esula da questo articolo, ma si può comunque notare che è sufficiente ereditare dalla classe Attribute e decorare la classe con l’attributo AttributeUsage che consente di specificare come deve essere gestito l’attributo stesso.

In questo caso si è specificato che il nostro attributo può essere utilizzato solamente con le classi e che non può essere ereditato. La classe attributo deve poi contenere le proprietà che identificano il plugin ed esporre un costruttore di convenienza per rendere più semplice l’utilizzo dell’attributo stesso. Nel caso in esame sono state scelte quattro proprietà distintive per il plugin: il nome, una sigla che indica il creatore, la versione ed infine una descrizione testuale che permette di specificare dettagliatamente cosa fa il plugin in questione.

Per completare la classe viene anche fatto l’override del metodo virtuale ToString() per dare una descrizione più user friendly dell’attributo.

Un istanza di un PluginAttribute è quindi a tutti gli effetti una descrizione completa di un plugin che può essere sia mostrata all’utilizzatore a titolo informativo, sia utilizzata internamente dal gestore per la catalogazione di tutti i plugin caricati.

Le altre classi di supporto

Prima di esaminare il codice del nuovo gestore è necessario creare altre classi ausiliarie necessarie per una gestione efficente. Prima di tutto si deve creare un altro attributo custom chiamato PluginInterfaceAttribute il cui scopo è specificare in maniera esplicita le interfacce implementate da una classe plugin.

In questo caso la proprietà AllowMultiple è pari a true dato che una singola classe può implementare se vuole più interfacce di plugin e quindi presentare un’istanza di questo attributo per ognuna di esse. Con questa tecnica abbiamo del tutto eliminato il caricamento implicito dato che ogni classe che vuole essere caricata dinamicamente deve essere decorata in maniera esplicita con una serie di attributi che ne identificano l’utilizzo.

L’ultima classe da esaminare si chiama PluginInfo ed il suo scopo è contenere tutte le informazioni su di un plugin caricato in modo da permetterne la gestione. Il costruttore accetta come parametro il tipo di dato da gestire ed internamente inserisce in una collection tutte le interfacce implementate recuperando tramite reflection.

Come si può notare le interfacce implementate vengono individuate semplicemente esaminando la la lista di attributi PluginInterface definiti sul tipo. La classe PluginInfo al suo interno tiene inoltre un riferimento al tipo di oggetto e fornisce un metodo ImplementInterface() che restituisce un boolean che indica se il tipo implementa una particolare interfaccia.

Il nuovo gestore di plugin

Il nuovo gestore internamente mantiene la lista di tutti i plugin caricati in un dictionary la cui chiave è un’istanza della classe PluginAttribute e il valore è un PluginInfo; due clausole using rendono più leggibile il codice dichiarando due alias di convenienza

Come per la versione precedente la classe PluginManager accetta nel costruttore il nome della cartella che internamente contiene i plugin da caricare e chiama la funzione AnalyzeAssemblyFile() su tutti i file .dll che trova nella cartella specificata.

Questa nuova versione è se possibile anche più semplice rispetto alla precedente, in particolare la scansione degli assembly è ora desicamente più lineare. Come nella versione precedente si esaminano tutti i tipi definiti nell’assembly e per sapere se il tipo esaminato deve essere caricato è sufficiente utilizzare il metodo IsDefined() della classe Type che permette di controllare se il tipo è stato decorato con un particolare attributo. Per identificare i plugin basta quindi cercare un attributo di tipo PluginAttribute e in caso positivo inserirlo nell’apposito dictionary creando il corrispondente PluginInfo().

Il gestore fornisce due soli metodi per interagire con l’esterno, GetPluginListForInterface() restituisce una lista di PluginAttribute contenente tutti i plugin che implementano una determinata interfaccia, mentre CreateInstance<T>() permette di creare un’istanza di plugin passando il corrispondente PluginAttribute.

Come si può vedere la creazione di nuove istanze viene fatta utilizzando l’oggetto Activator che chiama il costruttore di default dell’oggetto, come si può vedere l’implementazione è decisamente semplice e facile da gestire.

Cosa cambia lato client

Questi cambiamenti non complicano assolutamente il codice lato client. Il programma di esempio è costituito infatti dalla solita combobox con cui si seleziona il plugin da utilizzare e in aggiunta viene inserito un controllo PropertyGrid che permette di visualizzare tutti i dati dei plugin caricati.

Nell’evento FormLoad viene creata l’istanza del gestore passando la cartella contenente i plugin. Un client più efficace dovrebbe tenere una singola istanza del gestore con un pattern di tipo singleton, ma questo esercizio è lasciato al lettore. La creazione di un PluginManager è infatti piuttosto onerosa dato che internamente si utilizzano numerosi metodi di reflection.

Per visualizzare la lista dei plugin è sufficiente impostare il DataSource della ComboBox che automaticamente chiama il metodo ToString() per ogni oggetto della lista, mostrando di fatto la descrizione dell’attributo. Tramite la gestione dell’evento SelectedIndexChanged viene invece aggiornata la visualizzazione sulla PropertyGrid.

Infine la pressione del bottone crea un’istanza del plugin ed invoca il suo unico metodo Greet(). Anche in questo caso l’interfaccia generica consente di scrivere codice senza cast ed inoltre, dato che il metodo CreateInstance accetta un PluginAttribute, è sufficiente passare il parametro comboBox1.SelectedValue.

Come si può notare utilizzare il gestore è veramente immediato ed efficace e richiede poche linee di codice.

Implementare un plugin

L’ultimo cambiamento rispetto all’esempio precedente riguarda i plugin, che per poter essere caricati debbono ora essere compilati con gli appositi attributi, ecco ad esempio l’implementazione dell’EducatedGreeter.

Come si può vedere sono presenti due attributi, il primo imposta le informazioni base sul plugin ed il secondo indica l’interfaccia implementata.

Biografia: http://dotnetmarche.org/user/Profile.aspx?UserID=2105

Personalizzare i log di ELMAH

Alkampfer — Tue, 16 Jan 2007 08:42:00 GMT

Di: Ricci Gian Maria

ELMAH è un prodotto open source e completamente freeware per gestire il log automatico degli errori nelle proprie applicazioni ASP.Net. Grazie a questo tool è possibile individuare e correggere tempestivamente gli errori delle proprie applicazioni web una volta in produzione.

ELMAH

Il modulo di gestione delle eccezioni ELMAH ha il grande vantaggio di essere sia un buon prodotto, sia di essere open source e quindi liberamente utilizzabile ed estendibile per le proprie necessità. Essenzialmente è un modulo di log degli errori composto da un HttpModule che intercetta ogni errore non gestito e crea un log pieno di informazioni il quale viene poi passato ad uno o più oggetti dispatcher che spostano le informazioni nelle destinazioni scelte. Attualmente ci sono due implementazioni: una salva su un normale database SqlServer, l’altra invia l’errore per posta per avere la massima rapidità di risposta.

Questo tool è particolarmente utile perché nel caso di web application quando si genera un errore non è possibile contattare il navigatore che lo ha generato per chiedergli informazioni ed è necessario quindi sia tracciare l’errore, sia effettuare il log di quante più informazioni possiamo per poter diagnosticare il problema.

Il setup di questo tool è minimale, basta refenziare la dll ed aggiungere alcune opzioni nel web.config, nel progetto di esempio è tra l’altro accluso un web.config dimostrativo che mostra le voci da inserire. La cosa che attira di più è che è comunque possibile aggiungere informazioni a quelle standard, opzione utilissima se si necessita di memorizzare informazioni critiche pertinenti solo al proprio applicativo web.

Per aiutare nelle operazioni di personalizzazione qui di seguito verrà fatta una breve panoramica su come aggiungere alle informazioni standard anche un dump completo delle variabili di sessione. L’esempio non contiene codice perché preferisco che scarichiate il prodotto sul sito originale per correttezza verso l’autore. Le modifiche verranno presentate indicando in che punti della libreria agire e sono di così facile comprensione che la mancanza del codice di esempio non influisce sulla comprensione.

Aggiungere informazioni sulla sessione

Uno dei maggiori pregi di elmah è che è molto facile aggiungere informazioni a quelle di base che vengono memorizzate per ogni eccezione intercettata. Nel database infatti esiste un campo xml dove il modulo va a inserire tutti i dati dell’errore, in questo modo la struttura del database non deve essere modificata se vogliamo aggiungere informazioni addizionali che vanno invece inserite nel campo XML dell’errore stesso. In questo piccolo articolo si mostrerà dove agire per aggiungere alle informazioni anche un dump completo delle variabili di sessione, opzione che non è stata inserita tra le funzionalità base di Elmah e che io ritengo invece molto importante.

Ogni informazione aggiuntiva per un log deve essere mantenuta dentro un oggetto di tipo NameValueCollection e tutte le modifiche al codice da fare riguardano solamente il file Error.cs, rendendo la customizzazione un operazione veramente banale. La prima cosa da fare è aggiungere una variabile di tipo NameValueCollection per ogni gruppo di informazioni aggiuntive che si desidera memorizzare. Il posto più corretto dove impostare questi dati è in calce alla dichiarazione dei gruppi già presenti.

Una volta che il contenitore è stato creato basta inserire i dati richiesti nel costruttore della classe Error, per correttezza sempre nello stesso punto dove la libreria imposta le informazioni base.

Naturalmente la funzione CopyCollection non accetta una sessione come argomento, per questa ragione è necessario scrivere una propria implementazione che inserisca tutte le informazioni necessarie, nel nostro caso il timeout della sessione, il suo Id e di seguito tutte le variabili.

A questo punto è necessario intervenire anche su altre funzioni affinché elmah sia in grado di serializzare da e nell’xml il contenuto delle informazioni aggiuntive, il primo passo è aggiungere alla WriteInnerXml() la serializzazione delle informazioni appena aggiunte

Per quanto riguarda la deserializzazione è necessario invece modificare la routine ReadInnerXml() al cui interno si trova un’istruzione switch che in base al nome del nodo ripristina l’oggetto NameValueCollection corretto.

Tutto il contenuto della collection session è ora presente nel log e viene salvato correttamente nel database.

A questo punto è naturalmente necessario modificare anche il codice che genera la pagina di visualizzazione in modo che mostri anche le nuove informazioni memorizzate. In questo caso il file da modificare è ErrorDetailPage.cs e precisamente deve essere editato alla fine della funzione RenderError() che nella versione base di ELMAH mostra solamente le informazioni aggiuntive delle variabili di applicazione. Se si vuole mostrare ogni info aggiuntiva basta aggiungere il seguente codice

Come si può vedere la funzione RenderCollection() si occupa della generazione dell’html e quindi è particolarmente facile visualizzare le informazioni aggiuntive.

Con poche righe di codice è possibile quindi estendere la struttura base di ELMAH in modo da tracciare informazioni personalizzate che possono aiutare ad individuare più rapidamente la causa dell’errore.

Biografia: http://dotnetmarche.org/user/Profile.aspx?UserID=2105

Alcune considerazioni sul cache di pagina

Alkampfer — Mon, 13 Nov 2006 23:24:00 GMT

Di: Ricci Gian Maria

Un adeguato caching permette di aumentare le prestazioni di un sito Asp.NET in maniera considerevole, in particolare la cache di pagina è la tecnica che dà i maggiori risultati, ma se non la si conosce a fondo si potrebbe rimanere sorpresi da alcuni comportamenti.

Cache di pagina

La cache di pagina viene impostata con la direttiva di pagina OutputCache ed è particolarmente efficiente, perché permette al motore Asp.NET di riutilizzare l’html generato da una richiesta precedente senza eseguire nemmeno una riga di codice. Questa tecnica non è però priva di effetti collaterali, che debbono essere accuratamente esaminati per capire se effettivamente si può applicare alle proprie pagine e/o controlli. Si prenda ad esempio la pagina page1.aspx contenuta nel codice accluso che contiene una semplice gridView collegata alla tabella customer del database northwind. L’unica particolarità è la presenza di una colonna template che contiene un bottone il cui scopo è cancellare un cliente dal database.

Nell’esempio accluso la routine non effettua veramente la cancellazione ma indica semplicemente in una label l’id cliente che sarebbe stato cancellato, in questo modo non si alterano i dati nel database e l’esempio non perde di validità.

La pagina ha quindi un funzionamento molto semplice, vediamo ora cosa succede se si abilita la cache.

Abilitare la cache di pagina

Sempre nell’esempio accluso, la pagina page2.aspx contiene lo stesso codice visto in precedenza, con la semplice aggiunta della direttiva di abilitazione della cache

Se si esegue la pagina si nota però che alla prima pressione del bottone il comportamento è quello corretto e viene indicata la richiesta di cancellazione, ma alle pressioni successive non accade nulla e se si mette un breakpoint in modalità debug si può verificare che la routine GridView1_RowCommand viene chiamata solamente la prima volta.

Chi conosce bene la cache di pagina non rimarrà sorpreso da questo comportamento, ma analizziamo comunque in dettaglio cosa succede per avere un quadro della situazione.

Alla prima richiesta il server non ha la pagina in cache, viene quindi generata la pagina in modo normale e l’html risultante viene salvato nella cache. Alla prima pressione di un bottone la richiesta arriva al server, anche questa volta viene controllata la cache di pagina e nuovamente si ha un cache miss perché questa volta la richiesta è in POST mentre precedentemente era in get. Alle successive pressioni del tasto la pagina viene trovata in cache, viene quindi restituito al chiamante l’html contenuto nella cache e nessun evento viene generato perché non viene nemmeno creata un’istanza della classe che gestisce la pagina

Questo tipo di cache può quindi aumentare di molto le prestazioni di un’applicazione Asp.NET perché evita completamente l’esecuzione di codice. Si consideri inoltre che la cache è abilitabile anche per i singoli controlli utente e quindi è possibile effettuare cache parziale del contenuto di una pagina.

Purtroppo nel caso in cui si richieda un comportamento dinamico, come nell’esempio appena mostrato, questa tecnica non è apparentemente utilizzabile perché purtroppo elimina la chiamata dei metodi lato server che eseguono logica di business.

Forzare l’esecuzione della pagina indipendentemente dalla cache

Supponiamo che la pagina precedente venga utilizzata per il 99.99% delle volte in modalità sola lettura e solo in rarissimi casi venga richiesta una cancellazione. In questo scenario il cache di pagina è legittimo, bisogna solamente trovare il modo di forzare un cache miss alla pressione di un bottone. Naturalmente per pagine fortemente interattive questa tecnica non è assolutamente efficiente, perché si genererebbero troppe versioni nella cache e sarebbe quindi consigliabile adottare altre strategie di caching.

La direttiva OutputCache permette di indicare come viene indicizzata la cache tramite vari attributi come varyByParam, varyByControl etc, ed è proprio su questi che si deve agire per forzare un cache miss in maniera programmatica. In particolare il varyByParam permette di specificare come chiavi di indicizzazione nomi di parametri in GET o in POST. Supponiamo quindi di aggiungere la linea

Alla direttiva OutputCache. In questo caso se la pagina viene chiamata con page2.aspx?param=1 il motore di asp.net indicizzerà l’output nella cache con il valore param=1. Se una successiva richiesta viene fatta ad esempio con page2.aspx?param=2 il risultato è un cache miss e l’output viene inserito a fianco del precedente, indicizzato con il valore param=2. In questo scenario è importante capire che per ogni differente combinazione dei parametri indicati viene mantenuta nel server una versione della pagina in cache.

Il nostro problema è comunque differente, quello che si desidera è abilitare la cache, ma far si che alla pressione di determinati bottoni si abbia sempre un cache miss, perché siamo interessati all’esecuzione del codice lato server associato al bottone stesso. Almeno apparentemente non esiste però una direttiva varyByXxx che permetta di indicare ad asp.NET uno o più bottoni che invalidano la cache, ma il problema può essere aggirato in maniera molto semplice.

La soluzione è contenuta nella page3.aspx, se la si manda in esecuzione si può vedere come sia stata aggiunta una label che riporta l’ora di generazione della pagina, necessaria per verificare che effettivamente le pagine siano nuovamente rigenerate e non prese dalla cache. Aprendo un secondo browser e navigando allo stesso indirizzo si può notare come l’ora restituita sia quella del primo caricamento, questo banale esperimento ci mostra che la cache è effettivamente funzionante. La differenza è che questa volta i bottoni funzionano correttamente ed il codice dell’handler viene eseguito ad ogni click.

Il trucco è veramente banale, prima di tutto è stato inserito un HiddenField di nome forcePostBack il cui valore iniziale è un guid, e poi la cache è stata impostata in modo da variare sulla base del contenuto di questo controllo. Se si vuole che alla pressione di un bottone sia sempre eseguito il codice del corrispettivo handler è sufficiente cambiare il contenuto dell’hiddenField con un altro valore prima di effettuare il postback, assicurandosi chiaramente che questo valore sia univoco. Per ottenere un nuovo guid ad ogni pressione di un bottone è indubbiamente vantaggioso generare direttamente lato server il codice javascript associato all’evento OnClientClick di ogni bottone. Ecco ad esempio come vengono creati i bottoni della gridView.

Nello snippet è stato evidenziato come l’unica aggiunta sia l’attributo OnClientClick il cui contenuto è impostato da una funzione lato server chiamata ForcePostbackJs().

Come si può vedere ad ogni evento load la pagina genera un nuovo guid e alla pressione del bottone si associa un javascript che imposta il contenuto dell’hiddenfield al nuovo guid generato. In questo modo si ha la sicurezza che ad ogni pressione di un bottone il nuovo valore dell’hidden field sia univoco e generi sempre un cache miss.

Il quadro non è però ancora completo, se si inserisce la vera logica di cancellazione, dopo la pressione del bottone alle successive richieste della pagina verrebbe comunque restituita la versione contenuta nella in cache, in cui è ancora presente l’elemento cancellato. In generale infatti se la pressione di un bottone provoca l’esecuzione di logica di business che modifica i dati sulla base dei quali è generata la pagina, tutte le precedenti versioni in cache non sono più valide. La soluzione è quindi invalidare la cache di pagina in maniera programmatica, inserendo l’istruzione seguente nell’handler del bottone

In questo modo ogni volta che viene eseguita logica di business tutta la cache della pagina Page3.aspx viene invalidata e le successive richieste visualizzeranno dati corretti.

Conclusioni

La cache di pagina è una tecnica che permette di ottenere grandi incrementi di prestazioni per pagine statiche o che contengono piccole porzioni dinamiche, purtroppo è necessario ricorrere a piccoli “trucchi” se si vuole che la logica lato server risponda sempre agli eventi utente. In generale comunque la possibilità di abilitare questa forma di caching anche per i singoli controlli la rende indubbiamente una tecnica di grande efficacia per le proprie applicazioni Asp.NET.

Creare un programma estendibile mediante plugin - Parte 1

Alkampfer — Mon, 30 Oct 2006 04:29:00 GMT

Di: Ricci Gian Maria

La tecnologia .NET consente di iniettare codice in maniera dinamica in un processo, rendendolo di fatto estendibile mediante unità di codice chiamate plugin.

Minimizzare le dipendenze

Negli ultimi anni si è molto studiato su come minimizzare le dipendenze tra gli oggetti, in modo da rendere le applicazioni molto più flessibili ed estendibili. Questo studio ha portato alla creazione di pattern particolari come quelli di Dependency Injection o Inversion of control, di cui il lettore può trovare abbondanza di informazioni semplicemente tramite google. In questo articolo si vuole invece esaminare una tecnica particolare che permette non solo di minimizzare la dipendenza tra gli oggetti, ma anche di estendere un’applicazione senza ricompilare.

Si consideri un semplicissimo esempio di un applicativo minimale che deve solamente salutare l’utente, sulla base del classico hello world. Il programma è costituito da una semplice classe chiamata standardGreeter ed una form che esegue un semplice saluto alla pressione di un bottone

Il codice è veramente banale, ma è già sufficiente per individuare una forte dipendenza con la classe StandardGreeter. Se ad esempio il nostro programma deve evolvere permettendo di eseguire un saluto più formale rispetto ad un semplice hello!! si potrebbe semplicemente realizzare un’ulteriore versione della classe chiamata FormalGreeter modificando contemporaneamente il codice dell’handler del bottone.

Questo approccio ha un enorme punto debole, il codice eseguito alla pressione del bottone deve conosce il tipo concreto di classe da istanziare per chiamare il suo metodo Greet() e quindi dipende dal tipo di oggetto utilizzato. Per risolvere elegantemente questo tipo di problematiche si può utilizzare un pattern di Abstract Factory, oppure utilizzare librerie come la Spring.NET per l’Inversion of control, o contenitori come il picocontainer, etc etc. In questo articolo la soluzione proposta è invece basata su plugin, una tecnica particolare per caricare dinamicamente il codice implementando così un pattern di Inversion of Control.

Caricamento dinamico di codice

Un plugin non è altro che un blocco di codice che viene caricato a runtime dal programma per estendere il funzionamento base. Il primo requisito per poter creare un plugin è definire la sua interfaccia, il programma host infatti non può caricare arbitrarie parti di codice se poi non sa come utilizzarle e dunque il primo passo per poter gestire un plugin è definirne l’interfaccia, proprio come se si stesse per realizzare una classica implementazione di Abstract Factory. Nell’esempio accluso è stata definita a questo proposito l’interfaccia IGreeter che comprende un’unica funzione e individua il contratto che deve essere implementato da un oggetto in grado di restituire un saluto.

La particolarità è che l’interfaccia viene definita in un progetto esterno a quello principale. La ragione è semplice dato che chi implementa un plugin deve avere un riferimento al progetto che contiene il contratto e quindi è più logico che tutte le interfacce che possono essere implementate da plugin esterni si trovino in un assembly dedicato che può essere così referenziato da chiunque voglia scrivere un plugin.

Nella solution di esempio si trovano infatti due implementazioni dell’interfaccia IGreeter, ognuna implementata in un differente assembly. Il progetto più interessante è comunque il PluginManager che contiene il codice per gestire il caricamento dinamico del codice. Dal punto di vista del programma principale un plugin è una classe che implementa un interfaccia riconosciuta e contenuto in un assembly esterno sconosciuto in fase di compilazione. Durante l’esecuzione è compito del PluginHandler scandire una particolare cartella in cui sono contenuti tutti i plugin al fine di identificare al suo interno tutti i tipi che implementano l’interfaccia richiesta ed occuparsi poi della creazione delle specifiche istanze. Il codice che effettua la scansione è veramente semplice

Come si può vedere al costruttore dell’oggetto PluginManager viene semplicemente passata la cartella da esaminare e il nome dell’interfaccia cercata. La funzione che effettua tutto il lavoro si chiama ScanDirectory() e itera semplicemente tra tutti i file con estensione dll presenti nella cartella invocando per ognuno di essi la funzione AnalyzeAssemblyFile(), la quale non fa altro che tentare di caricare l’assembly in memoria, iterare in tutti i tipi contenuti e cercare con la funzione GetInterface() i tipi che implementano l’interfaccia richiesta. Per ogni plugin trovato viene creato un nuovo oggetto PluginInfo che viene poi inserito in un dizionario indicizzato con il nome del tipo stesso. L’oggetto PluginInfo mantiene infatti al suo interno tutte le informazioni sul plugin caricato; internamente la classe PluginInfo ha due sole proprietà: il nome del plugin ed un riferimento al tipo di oggetto che lo implementa. Durante la creazione di un oggetto PluginInfo viene inoltre recuperato un riferimento al costruttore di default, utilizzato successivamente per creare nuove istanze.

Come si può notare il codice per gestire il plugin è veramente minimale. Il programma chiamante è anch’esso diverso dalla versione precedente, la form contiene infatti una combo in cui vengono listati tutti i plugin disponibili ed alla pressione del bottone viene utilizzato il greeter scelto dall’utente. Nel progetto incluso sono state inoltre aggiunte delle post build action ai due progetti in modo che, ad ogni compilazione, le dll con i plugin vengano inserite automaticamente nella sottocartella Plugins del programma principale.

Per capire il vantaggio di questa tecnica si cancelli il file EducatedGreeter.dll dalla cartella plugins e si esegua il programma; nella combo ora appare solamente lo StandardGreeter. A questo punto basta copiare nuovamente il file EducatedGreeter.dll nella cartella dei plugin, riavviare il programma e verificare che è nuovamente possibile utilizzare entrambi i greeter, senza dover ricompilare nulla. Se in futuro sorgerà la necessità di un ulteriore Greeter non si deve fare altro che implementare un nuovo plugin e copiarlo nella cartella apposita.

Conclusioni

L’utilizzo del caricamento dinamico di assembly e della reflection permette di implementare con veramente poche righe di codice una libreria che permette di gestire l’Inversion of Control con un ottica basata su caricamento dinamico di codice. Il programma finale è infatti in grado di utilizzare i nuovi plugin senza necessità di dover ricompilare l’applicativo o modificare file di configurazione, è sufficiente infatti copiare le nuove dll nella apposita cartella e “l’iniezione” del nuovo codice è completamente automatica.

Biografia: http://dotnetmarche.org/user/Profile.aspx?UserID=2105

Alcune considerazioni sull'Atlas.UpdatePanel

Alkampfer — Thu, 21 Sep 2006 01:09:00 GMT

Di: Ricci Gian Maria

Il nuovo framework AJAX per ASP.NET 2.0 nonostante sia ancora in beta è indubbiamente un prodotto molto interessante. In questo articolo verranno esposte alcune particolarità interessanti del controllo UpdatePanel che presenta comportamenti anomali in alcune situazioni.

Creare un controllo che fa uso di UpdatePanel

L’UpdatePanel è senza dubbio uno dei controlli più utili di Atlas, purtroppo però ci sono alcune particolarità che è bene conoscere, per evitare di incappare in spiacevoli inconvenienti.

Spesso l’UpdatePanel viene inserito all’interno di controlli utente. Nell’esempio accluso si può infatti vedere che il Controllo1.ascx, ha due semplici combo per effettuare una selezione a cascata racchiuse da un UpdatePanel, il cui scopo è essenzialmente quello di impedire che ad ogni selezione tutta la pagina venga nuovamente renderizzata.

Naturalmente la pagina ospitante (Page1.aspx) deve contenere un controllo ScriptManager ed abilitare il PartialRendering affinché tutto funzioni correttamente. Purtroppo come si può vedere eseguendo la Page2.aspx se il controllo utente viene utilizzato all’interno di un controllo Wizard si generano errori javascript quando si effettua il postback della pagina. Spendendo un po’ di tempo debuggando il javascript dell’Atlas si scopre che l’errore è dovuto al fatto che il controllo Wizard renderizza nella pagina solamente i controlli del tab corrente. Purtroppo Atlas esaminando il codice sorgente della pagina nota che sono presenti due istanze del Controllo1.ascx ed quindi nella pagina sono effettivamente presenti due controlli UpdatePanel. Questo fa si che durante il postback il codice javascript si aspetta che la pagina contenga entrambi gli UpdatePanel, purtroppo però quello relativo al tab non attivo del Wizard non è in realtà presente nel DOM della pagina ed ecco la sorgente dell’errore.

Risolvere il problema del wizard

La soluzione è nel Controllo2.ascx e consiste semplicemente nell’utilizzo corretti dei trigger degli UpdatePanel, in modo da indicare al motore javascript di Atlas di aggiornare l’UpdatePanel solamente quando la prima combo genera l’evento di cambio indice. In questo a runtime durante il postback causato da un controllo Atlas cerca di aggiornare solamente l’UpdatePanel per cui il trigger è stato attivato, ignorando quindi gli UpdatePanel che non sono effettivamente presenti nella pagina.

Purtroppo i problemi non sono finiti. Nella pagina Page4.aspx un altro bug si genera quando si tenta di creare dinamicamente da codice un’istanza del Controllo2.ascx.

Purtroppo anche in questo caso a runtime Atlas va in errore, questa volta però non si genera un errore javascript, ma viene mostrata un educata messagebox in cui l’utente è avvertito del fatto che il nome del controllo utilizzato per il trigger non è valido. Per capire l’origine di questo altro problema bisogna confrontare ciò che viene renderizzato nel caso di controllo incluso a design time (page1.aspx) con il DOM della pagina dinamica. Nel caso di inclusione a design time in particolare ecco come viene renderizzata la prima dropDownList del controllo utente.

Mentre ecco quello che appare nella pagina che include dinamicamente il controllo.

In questo caso molto probabilmente il motore javascript di Atlas quando esamina la struttura della pagina genera il javascript corrispondente considerando che i nomi dei controlli nel DOM vengano generati sempre con lo stesso criterio. Purtroppo per i controlli dinamici il nome del controllo segue una regola di denominazione differente e da qui l’errore, perché si cerca nel DOM il nome di un controllo inesistente.

Generare trigger dinamicamente

Il problema precedente è derivato dal trigger e se il ragionamento fatto in precedenza è corretto la soluzione è semplicemente generare dinamicamente tutti i trigger nell’evento PreRender del controllo utente. Questa accortezza permette di indicare in modo corretto l’id del controllo.

Se si esegue un run della pagina in modalità debug si può notare che il vero id del controllo è MyId_DropDownList1 e dato che questa volta siamo direttamente noi da codice che lo indichiamo per il trigger, il problema viene aggirato.

Un ulteriore considerazione

Talvolta accade che abilitando il partial rendering si generino errori javascript in linee che non esistono tipo 8.329.456 e che non è possibile debuggare. Questi errori sono quasi sempre generati da javascript incluso in modo non corretto nella pagina. Così come Microsoft stessa spiega nel punto 9 del documento Building Asp.NET2.0 web sites Using Web Standards non è possibile includere codice javascript nella pagina XHTML senza particolari accortezze, perché potrebbe alterare la struttura del documento. In sostanza la pagina html deve essere un documento XML valido, ma se nel javascript si utilizzano segni come < e > la validità del documento XML cade. A questo punto, dato che è impossibile utilizzare le sequenze di escape < & perché altrimenti il codice javascript non funzionerebbe, la soluzione è includere tutto in una sezione CDATA. In sostanza Microsoft consiglia di inserire uno script in questo modo

Talvolta nemmeno questo funziona e gli errori javascript continuano a presentarsi, un approccio più conservativo è invece il seguente

Includendo tutti gli script della pagina in apposite sezioni CDATA si è certi che la struttura XML del documento verrà preservata e ATLAS non genererà strani errori durante il PartialRendering.

Conclusioni

Atlas è sicuramente uno dei prodotti più interessanti per ASP.NET 2.0; è gratuito, è Microsoft e promette grandi funzionalità. Nonostante questo non bisogna mai dimenticare che è ancora un prodotto in beta ed è quindi inevitabile incontrare nello sviluppo qualche piccolo ostacolo, che però può sempre essere superato con un po’ di pazienza e una buona sessione di debugging.

Bibliografia

Sito ufficiale dell’Atlas

Biografia: http://dotnetmarche.org/user/Profile.aspx?UserID=2105

Appunti su Community Server

admin — Thu, 06 Jul 2006 11:26:00 GMT

Installazione
Fare riferimento alla documentazione riportata su http://docs.communityserver.org/

Siti con tips e articoli
http://soup.co.za/weblog/archive/category/1002.aspx
http://richmercer.com/archive/2006/05/27/94.aspx (aggiunta di campi custom)

Riduzione grandezza css
In alcuni css (Themes/default/style/Common.css e Themes/default/style/common_print.css) ci sono, alla fine del file, molte righe vuote, che contribuiscono per circa metà della grandezza dei file (da 80k a 40k ognuno circa). E' bene eliminare queste righe vuote.

Gestione cache
Di default è attiva la cache, a causa della quale le modifiche ai contenuti e al layout del sito non vengono visualizzate immediatamente.
Per disabilitare la cache si deve impostare cacheFactor="0" nel file communityserver.config.
Per decidere se tenere la cache abilitata o meno, bisogna fare delle prove: a causa di file delle impostazioni (config, css, ...) piuttosto corposi, probabilmente può essere conveniente lasciare la cache attiva.

Aggiunta di voci al menù principale
Aggiungere nel file SiteUrl.config (nell’apposita sezione contentente anche gli alti elementi del menù, contraddistinti dal tag xml 'link') una voce del tipo

<link name="<NOME_LINK>" navigateUrl="<URL_DI_DESTINAZIONE>" text="<LABEL_MENU>" roles="Everyone" />

Ovviamente su roles andranno specificati i ruoli abilitati a vedere la voce del menù.
L'url di destinazione, a causa di qualche sclero di Communty Server, è bene specificarlo in modo assoluto e non relativo, altrimenti funzionerà correttamente solo quando ci si trova nell'homepage (quando si è dentro un'altra pagina, CS aggiunge una parte al path relativo, rendendolo incorretto)

Link ad un articolo
Quando si crea un articolo, CS permette automaticamente di indirizzarlo tramite il path (relativo) content/<NOME_ARTICOLO>.aspx. Se, ad esempio, l'articolo si chiama FAQ, il path sarà content/FAQ.aspx.
Fare attenzione a non utilizzare, se possibile, gli articoli, sostituendoli con il blog, in quanto non vengono indicizzati per le ricerche.

Gestione poll
I poll possono essere creati direttamente da un post del forum. Occorre però avere i permessi adeguati per poterlo fare, altrimenti la tab 'Poll' non sarà visibile (esiste un'apposita voce nelle impostazioni generali del forum, accessibile dal pannello di amministrazione).
L'unica pecca è che permettono la gestione di poll a sola scelta singola.
Se ci fosse l'esigenza, si può integrare una libreria esterna (tipo http://www.nsurvey.org/netpolls/)

Fuso orario
L'orario che si trova nelle impostazioni generali non deve essere impostato a quello in cui ci si trova, ma a quello in cui si trova il server che ospita il sito.
Non è invece necessario impostare nulla sul file web.config (sul forum di community server si fa riferimento ad una voce dbTimeZoneOffset da aggiungere, ma probabilmente si riferiva alla versione precedente di CS).

FCKEditor
Vedi file allegato "FCK Editor.zip" e relativo file Readme.txt (contenuto all'interno)

WIKI
Se qualcuno volesse indagare, qua c’è un thread interessante (anche se un po’ vecchio)
http://communityserver.org/forums/thread/495747.aspx

con qualcosa da scaricare all’indirizzo
http://www.webdynamix.biz/products/wiki_build_0_1.zip

(e + aggiornato all’indirizzo http://www.webdynamix.biz/products/wiki_build_0_2.zip)

Si tratterebbe (credo) di integrare FlexWiki in CS.

[ABOUT US]

admin — Thu, 06 Jul 2006 11:25:00 GMT

DotNetMarche è il primo, e per ora unico, .NET Users Group nato nelle Marche, e rappresenta un'aggregazione di utenti, prevalentemente professionisti del settore IT, accomunati dall’utilizzo del Microsoft .NET Framework e dalla passione per la programmazione...(read more)

[FAQ]

admin — Thu, 06 Jul 2006 11:24:00 GMT

1. CHI SIETE ?

Siamo un gruppo di persone che di mestiere (e per passione) fanno i programmatori e che dedicano molto del loro tempo allo studio ed allo sviluppo di tecnologie. Come molte altre persone di questo settore ci piace l'idea di confrontarci e condividere esperienze ed idee.

2. CHE COS'È UNO USERS GROUP ?

Uno Users Group è costituito da un gruppo di persone che condividono una passione nel suo complesso, e desiderano sostenerla, diffonderla e tutelarla. Le modalità di associazione, ritrovo ed organizzazione sono diverse per ogni singolo Users Group, ma il loro scopo è comune: condividere e diffondere la propria passione, creando un punto d'appoggio volontario, dove ognuno può dare il proprio contributo.

3. COME È NATA L'IDEA DELLO USERS GROUP ?

Durante una cena, conclusa con dei digestivi che qualcuno ha definito "criminali" ! :)

In realtà l'idea nasce in parte, dall'esigenza di fondare un gruppo di utenti interessati alla programmazione in ambiente .NET con una zona di riferimento piuttosto limitata (la regione Marche), ed in parte sulla scia di quelle che sono le più conosciute realtà nazionali (vedi UGIdotNET).

I motivi sono diversi: la presenza di un gruppo locale, ci offre la possibilità di incontrarci molto più facilmente, senza dover affrontare lunghi viaggi per assistere a delle conferenze.
Anche se ormai esistono moltissimi mezzi per rimanere costantemente in contatto, i benefici (ed il piacere) che si possono ottenere da incontri "dal vivo", non sono a nostro avviso paragonabili.

4. E' GIÀ STATO FONDATO LO USERS GROUP ?

Si, ed il suo nome, DotNetMarche, è stato scelto tramite un democratico sondaggio!

5. PERCHÈ UN ALTRO USERS GROUP ?

Nella nostra zona non esisteva ancora un gruppo di utenti appassionati di programmazione in .NET, per cui vorremmo sopperire alle esigenze già espresse nella domanda "Come è nata l'idea dello users group ?".
Inoltre vorremmo sottolineare il fatto che non ci proponiamo come alternativa ad altre realtà ben più strutturate ed organizzate della nostra, ma semmai come una loro naturale trasposizione sul territorio.

6. QUALI SONO LE ATTIVITÀ DI UNO USERS GROUP ?

Se l’obiettivo principale dello users group è quello di condividere ed accrescere le proprie competenze e fare nuove conoscenze, le attività principali sono tutte quelle che in qualche modo ci danno la possibilità di perseguire questi scopi.

Quindi largo spazio a tutte le attività di community (forum, blog, ecc..), ai workshop, magari allo sviluppo di piccoli progetti software, e perché no, anche qualche cena.
Naturalmente alcune attività potrebbero nascere in seno allo users group, mentre in altri casi ci si limiterà a promuovere iniziative di realtà complementari, come gli users group “nazionali”.

7. MA SI PARLERÀ SOLAMENTE DI .NET ?

Non necessariamente. Lo sviluppo in .NET ed il Framework in genere, coinvolge una miriade di argomenti più o meno complessi: c’è la parte sistemistica, i tools di sviluppo, i linguaggi di programmazione e via dicendo.
Si possono fare confronti con tecnologie concorrenti, o sbirciare le tecnologie future.
Tutto dipenderà dalle proposte, dalla voglia di partecipare e contribuire.

8. CHIUNQUE PUÒ PARTECIPARE ?

Chiunque sia interessato alla programmazione con il .NET Framework ed a tutto quello che gli ruota attorno, e si trovi nelle Marche o dintorni.
Alle attività svolte on-line tramite il sito, come lo sviluppo di progetti open-source, possono partecipare anche persone al di fuori delle Marche.

9. MA VOI SIETE DEGLI "ESPERTI" ?

Assolutamente no, non siamo dei guru che si occupano di consulenze o formazione a tempo pieno, ma dei programmatori che hanno imparato quello che sanno dall'esperienza sviluppata in anni di studio e lavoro.
Nelle nostre intenzioni, c’è la voglia di creare un gruppo, non di fare una gara per stabilire chi sono i più bravi, e se qualcuno se la sentirà di affrontare un argomento per quello che la propria esperienza gli ha insegnato, questo sarà il benvenuto.
Se capiterà di dover rispondere “non lo so” a qualche domanda, questo non costituirà un problema, ma anzi un punto d’incontro su cui crescere e migliorare.

10. PERCHÈ ORGANIZZARE O PARTECIPARE ALLE ATTIVITÀ DI UNO USERS GROUP QUANDO CON GOOGLE HO GIÀ TUTTO QUELLO CHE MI SERVE ?

Perché su Google o su internet le persone le incontri solo virtualmente, mentre noi vorremmo
poterci incontrare nel vero senso della parola. Che Google sia uno strumento ormai fondamentale per molti, questo è fuori di ogni dubbio, ma questo soprattutto grazie a coloro che hanno dedicato del tempo prezioso a pubblicare nuovi contenuti o dare una mano ad altri, come magari in precedenza qualcun altro aveva già fatto con loro.

Uno users group deve essere un "mezzo" per avere la possibilità di crescere INSIEME, imparando dagli altri e condividendo al tempo stesso le proprie conoscenze. Anche se non sei un esperto questo non significa che tu non abbia nulla di interessante da condividere, ed in ogni caso questa rimane una buona occasione per conoscere cose nuove.

11. DEVO PAGARE QUALCOSA PER PARTECIPARE ?

Lo users group è una realtà no-profit, e non sono contemplate (almeno per ora) quote associative o cose del genere. L’idea è quella di rimanere sul gratuito, se poi ci saranno spese amministrative o altro vedremo in seguito.

[COMMUNITY RULES]

admin — Thu, 06 Jul 2006 11:23:00 GMT

Gli obiettivi della community DotNetMarche sono essenzialmente la promozione di incontri e attività tra i suoi membri: sono quindi interesse prioritario di DotNetMarche l'organizzazione di workshop e la creazione di progetti software realizzati in modalità collaborativa, tramite i quali approfondire le tematiche dello sviluppo software in ambiente .NET.

Il sito DotNetMarche permette di gestire in modo organizzato le attività della community: le forme principali di aggregazione sono i forum di discussione sugli eventi in programma e sulle attività di sviluppo intraprese dal gruppo, la mailing list attraverso la quale i membri vengono avvisati riguardo gli avvenimenti più importanti e le news.

Data la tipologia dello user group, le attività svolte al suo interno saranno gestite in modo tale da sfruttare ampiamente la sua presenza locale nel territorio, cosa che permette di avere una conoscenza più "stretta" degli altri membri, nonché la possibilità di incontrarsi periodicamente di persona, cosa fondamentale per avere quel feeling e quella praticità che le tecnologie moderne di comunicazione, per quanto avanzate, non riescono ancora a dare.

Non sarà invece questo il luogo ideale per altri tipi di attività per le quali hanno più senso organizzazioni a livello nazionale ed internazionale già esistenti (come UgiDotNet o i newsgroup ufficiali Microsoft), che offrono una maggiore disponibilità di risorse ed una visibilità ben superiore nel caso si vogliano, ad esempio, pubblicare dei contenuti. In questo modo evitiamo di frammentare le risorse che troverebbero una collocazione ideale in altri luoghi, e che senz’altro potrebbero interessare un bacino di utenza molto più vasto.

Seguono una serie di linee guida a riguardo.

Blog personali: attualmente non viene offerta la possibilità agli utenti del gruppo di pubblicare dei blog personali, al fine di incoraggiarne la gestione su siti che offrono questo servizio con portata nazionale o internazionale come UGIdotNET, DevLeap, DotNetHell o altri: questo scelta, da una parte evita la duplicazione dei post da parte degli utenti che già gestiscono un proprio blog su altri .NET user group, dall'altra favorisce la promozione dell'attività del gruppo e consolida il rapporto con le altre comunità già esistenti.
Pubblicazione di articoli: DotNetMarche promuove e pubblica tutti gli articoli in qualche modo legati alle esperienze concrete di sviluppo sui progetti e attività del gruppo stesso, come ad esempio tutorial sulla configurazione ed uso dei Microsoft Applications Block, oppure recensioni dei tools di sviluppo come TestDriven.NET; particolare riguardo sarà riservato inoltre agli articoli introduttivi verso argomenti di livello basilare, ma spesso trascurati, come ad esempio i Design Patterns (in particolare se con un'ottica rivolta verso l'applicazione pratica di questi strumenti e metodologie, e non solo teorica).

I membri della community che invece desiderano scrivere articoli non collegati direttamente alle attività della community, sono incoraggiati a valutare la possibilità di pubblicare il loro lavoro in siti più idonei, dove potranno godere di una maggiore risonanza e visibilità. I membri dello user-group che in precedenza hanno già avuto modo di scrivere articoli per siti istituzionali (vedi UgiDotNet) o per riviste specializzate, offrono il loro supporto e sostegno al fine di agevolarne la redazione e la pubblicazione.

Forum: il suo scopo principale è quello di affrontare quei temi che toccano in qualche maniera le attività dello user-group. Questioni specifiche di programmazione possono essere risolte, con altissima probabilità, utilizzando strumenti più idonei, come i motori di ricerca, i newsgroup ufficiali Microsoft o Google Groups, che offrono una knowledge-base vastissima (ad esempio molti dei problemi sull'utilizzo del framework, in genere sono già stati affrontati e risolti). Inoltre queste risorse raggiungono molte più persone (tra cui vari MVP) disponibili a rispondere alle domande, permettendo di risolvere i problemi più rapidamente e con un minor margine di errore.

Il forum, quindi, ha senso se utilizzato principalmente per discutere delle attività portate avanti dalla community; saranno in ogni caso bene accette discussioni sulle problematiche di programmazione generale che non hanno trovato una risposta altrove, oppure che possono risultare più idonee da affrontare tra "amici", i quali potranno "dirottarvi" verso altre risorse su internet o rispondere in base alla propria esperienza.

L’invito è di utilizzare gli strumenti di discussione offerti dal sito DotNetMarche per un’attiva collaborazione e discussione tra gli utenti del gruppo, e leggere la sezione [HOW TO] per capire come ottimizzare le risorse offerte dal sito (e convivere meglio con gli altri membri), ed in quali casi focalizzare la propria attenzione altrove.

[HOW TO]

admin — Thu, 06 Jul 2006 11:22:00 GMT

Gestione Profilo Utente

Ogni membro della community è "caldamente invitato" a compilare il proprio profilo personale: il sito offre una completa sezione dedicata alla gestione del profilo utente, in cui è possibile (doveroso, direi...) specificare contatti email/instant messenging. In particolare sarebbe opportuno firmare i post sul forum, specificando ad esempio il link al proprio sito o blog personale, eventuali certificazioni e riconoscimenti o qualunque altro riferimento che permetta di facilitare il contatto tra gli utenti.

La community considererà il profilo “completo”, solo se personalizzato con un avatar ed una piccola biografia: il campo bio del profilo utente, anche se a prima vista non sembra, consente di inserire alcuni tag HTML a supporto della scrittura del testo. Sono sufficienti poche righe, purché utili ad identificare le proprie competenze e\o esperienze.

La DotNetiquette prescrive che tutti gli utenti che entro un mese dalla registrazione al sito non avranno provveduto a compilare la propria biografia, saranno ritenuti in debito rispetto agli altri membri della community... il fio da pagare per espiare la colpa sarà stabilito collegialmente in una delle prossime sedute :).

Gestione Forum, Newsgroup e Google Groups

Strumenti a disposizione: come specificato nella sezione [COMMUNITY RULES], per risolvere i problemi quotidiani relativi al .NET Framework ed alla programmazione in genere, ci sono degli strumenti più adatti rispetto al forum presente nel sito. É auspicabile dunque utilizzare queste risorse, prima di porre delle domande che non siano pertinenti le attività dello user group; la community rimane comunque a disposizione nel caso il problema non si presenti di facile risoluzione, e comunque in tutti quei casi in cui per difficoltà di formulazione o per approfondimenti la scelta prediliga comunque il forum.

Segue una breve lista di risorse consultabili in rete che permettono una risoluzione veloce e precisa dei problemi di programmazione più comuni:

Motori di ricerca (es. Google): i search engine indicizzano miliardi di pagine, tra cui forum, articoli e blog presenti in tantissime community nazionali ed internazionali; è molto probabile che tra di esse siano già contenute soluzioni e chiarimenti ai problemi ricercati. Particolare attenzione deve essere dedicata all’impostazione dei criteri di ricerca: più saranno precisi e limitati tanto più il motore fornirà risposte pertinenti. Per favorire la ricerca i motori mettono a disposizione degli algoritmi in grado di interpretare le più comuni espressioni del linguaggio parlato, ma se utilizzati con operatori di algebra booleana (AND, OR, ecc..) i risualti forniti saranno senz’altro più precisi. Una guida all’utilizzo di Google può essere a questo indirizzo.

Newsgroup: concettualmente simili ai forum (si può porre una domanda e attendere che qualcuno dia delle risposte), hanno il vantaggio di essere gestiti con un protocollo dedicato (NNTP) che, similmente a quanto avviene per gli RSS, ci permette di aggregare e sincronizzare i post attraverso dei software più o meno dedicati, come Outlook Express. Per questi motivo, i newsgroup sono probabilmente molto più usati - e pratici da utilizzare - rispetto ai forum, anche se con l’avvento di RSS molti forum si sono adeguati ed hanno esteso il supporto a questo standard rendono di fatto questi due strumenti molto simili.

Tra le moltissime presenti, esiste una gerarchia di newsgroup ufficiali Microsoft divisi per tematiche (es. microsoft.public.it.dotnet.csharp e microsoft.public.it.dotnet.vb sono i gruppi italiani per C# e VB.Net) in cui porre domande alle quali, probabilmente, verrà data una risposta da persone competenti e disponibili a chiarimenti.

Per configurare i newsgroup Microsoft in Outlook Express seguire le seguenti istruzioni:

Andare su Tools -> Accounts -> Tab News -> Pulsante Add -> News.

Inserire nome ed indirizzo e-mail (va bene anche un nome fittizio se si vuole mantenere l’anonimato, ma non è una pratica consigliata visto che dall’altra parte ci sono persone disposte a dare un aiuto incondizionato).

Inserire l’indirizzo del server NNTP (ad es. news.microsoft.com).

Nel treeview con le varie cartelle verrà aggiunta una voce (es. news.microsoft.com): esplorare la gerarchia per ricercare e selezionare i gruppi di proprio interesse.

A questo punto è possibile porre nuove domande (New Post) o rispondere a quelle di altri (Reply), contribuendo così alla community.

Oltre ad Outlook Express sono disponibili ovviamente una vasta gamma di software (aggregatori) per gestire i newsgroup, tra i più noti RSS Bandit e NewzCrawler.

Un elenco dei principali indirizzi dei server NNTP è fornito da Google. A questo indirizzo è possibile trovare tutti i newsgroup ufficiali Microsoft.

Alcuni newsgroup (ad es. UgiDotNet) richiedono un autenticazione costituita da username e password che generalmente vengono fornite dagli amministratori del sito. In questo caso, è possibile impostare questi dati nell'account creato in Outlook Express.

Google Groups: questo strumento unisce la potenza di ricerca di Google al vastissimo repository di post creati nei newsgroup in più di 20 anni di storia. Una delle principali limitazioni dei newsgroup, ma sarebbe meglio dire del protocollo NNTP, è la possibilità di effettuare ricerche all'interno del corpo dei messaggi e di conseguenza nell'archivio dei post.

Google ha sopperito a questa mancanza attraverso Google Groups: una sezione del sito Google che indicizza e ricerca esclusivamente all'interno dei newsgroup (a differenza della sezione principale del sito, che non opera una ricerca completa in questi archivi). Tra le altre cose, Google ha acquisito il repository di post di Usenet, dove è possibile trovare annunci che hanno fatto la storia dell'informatica!

La potenza di questo strumento deve essere unita al buon senso di coloro che lo utilizzano, facendo in modo che prima di porre qualsiasi quesito, ne sia verificata un’eventuale presenza e le relative soluzioni.

L'utilizzo di Google Groups è molto semplice, e l’impostazione dei criteri di ricerca è analoga a quello del motore principale. E’ possibile inoltre sfruttare la ricerca avanzata per filtrare i messaggi di determinati gruppi o utenti (ad es. si può specificare microsoft.public.it.dotnet.csharp come nome del gruppo su cui cercare, oppure microsoft.public.it.dotnet.* per filtrare tra tutti i messaggi relativi ai gruppi italiani su .NET).

Utilizzo del forum di DotNetMarche

Segue una serie di tip utili ad una migliore gestione ed utilizzo del forum.

Ricezione notifiche via e-mail: al fine di evitare un controllo sistematico dell’aggiornamento del forum, è possibile abilitare la notifica via e-mail. Le opzioni a disposizione permettono di decidere se ricevere tutti i post o solamente quelli di apertura di nuovi thread (ma non le relative risposte).

Di default le notifiche sono disabilitate per non intasare senza preavviso la casella di posta elettronica. Per attivarle è sufficiente entrare nella sezione di modifica del profilo personale, selezionare la scheda ‘E-Mail’ e impostare su ‘Yes’ la voce ‘Enable Email Notifications of forum/thread subscriptions and replies to my posts’. Successivamente, per selezionare la notifica sui forum, andare nel link 'Forum Subscriptions' che si trova nel pannello 'Shortcuts', e porre la spunta alla voce 'Subscribe' sui forum di maggior interesse. In questo modo, verrà abilitata la notifica di ogni post, anche quelli di riposta. Bisogna prestare attenzione nel caso in cui vengano creati nuovi forum: in questo caso infatti è necessario ripetere l’operazione.

In alternativa, è possibile configurare singolarmente ciascun forum direttamente dal pulsante "Forum Options" presente in fondo alla pagina. In questa maniera si può ottenere una maggiore flessibilità di configurazione a scapito però del tempo impegato per l’impostazione di tutte le opzioni.

Ricezione notifiche via RSS: il forum dispone anche di un feed rss che permette di aggregare i nuovi thread. Per sottoscrivere il feed, cercare l'icona "RSS Available" in coda all'elenco dei topics, e copiare ed incollare il collegamento associato, nel software utilizzato per aggregare i contenuti (Outlook, Thunderbird, RSS Bandit, ecc… )

Nota bene 1: i feed RSS, a differenza delle notifiche e-mail, emettono nel loro flusso solamente il post di apertura di uno nuovo thread, e non tutte le risposte che seguono.
E’ comunque possibile seguire un thread via RSS attraverso una modalità descritta in seguito.

Nota bene 2: anche se non è evidenziato, esiste un collegamento che permette di sottoscrivere un feed RSS contenente i post di apertura di un nuovo thread di tutti i forum (pubblici ?) presenti nel sito. Il link è il seguente:
http://www.dotnetmarche.org/Forums/aggregaterss.aspx?Mode=2

Ricezione notifiche per un singolo thread: assieme alle notifiche d’apertura di un thread, è possibile in ogni caso abilitare la notifica di tutte le risposte al topic principale aperto sul forum, al fine di avere un controllo continuo della discussione. Le notifiche via e-mail possono essere abilitate attraverso il bottone "Enable email subscription" presente nel topic, mentre in alternativa è possibile sottoscrivere il feed rss del topic copiando ed incollando il link associato all’icona "RSS Available" – sempre all’interno del topic - nel proprio aggregatore di feed.

Apertura di un Blog

In questo momento non è offerta alcuna possibilità di aprire un blog personale in questo sito. Le motivazioni di questa scelta sono state già evidenziate e approfondite nella sezione [COMMUNITY RULES].

Scrittura di articoli e partecipazioni allo sviluppo di progetti

·Presto saranno rese note una serie di risorse - sotto forma di articoli, tutorial, link e quant’altro - su strumenti e regole per portare avanti questo tipo di attività, come chiarito nelle [COMMUNITY RULES]. Nel frattempo tutti coloro che sono interessati a questo tipo di iniziative sono invitati a discuterne sul forum.

[WE WANT YOU]

admin — Thu, 06 Jul 2006 11:21:00 GMT

Appartenere ad una community di utenti, piccola o grande che sia, è sicuramente un impegno, e se, come tanti di noi, hai già un lavoro che ti occupa molte risorse e ti stressa oltremodo, questo onere può risultare in alcuni casi gravoso: di certo quel poco o tanto di tempo che verrà rubato alle tue attività o al tuo relax sarà ampiamente ripagato dal bagaglio di conoscenze personali, professionali, tecniche ed umane che acquisirai. Questo vale in particolare per le comunità legate alla tecnologia e all'informatica, in cui le novità si susseguono vorticosamente ed è difficile, per non dire impossibile, rimanere aggiornato su tutte le novità.

Essere membro di una comunità di sviluppatori ti permetterà di discutere ed imparare dagli altri utenti le novità del software e dell'hardware, le nuove metodologie di sviluppo, le nuove tecnologie all'orizzonte... in un ambiente lavorativo come il nostro in cui "chi si ferma è perduto" tutto questo ha un'importanza capitale, e, fidati, vale almeno un pò dell'impegno che ti si richiede per partecipare.

Avere un blog oramai sembra una moda, tutti ce l'hanno e ci scrivono di tutto, quindi magari ti chiedi perchè dovresti aprirne uno pure te, tanto più che come membro di DotNetMarche non ne hai i privilegi... ebbene, dovresti invece aprirlo, magari utilizzando gli strumenti delle community nazionali UGIdotNET, DevLeap, DotNetHell o altre!

Per chi fa il nostro lavoro, avere un blog aiuta enormente a condividere le proprie problematiche, e serve a far "circolare le idee": lavorando quotidianamente nella programmazione .NET, sarai sicuramente incappato in alcuni problemi che poi avrai risolto tramite un misto di bravura-fortuna o dopo qualche minuto di ricerca su google, oppure avrai scritto un particolare algoritmo di dieci righe per sostituire un precedente algoritmo da 500 righe, scritto magari da un tuo collega o amico che non conosceva il framework .NET così bene come te... ebbene, postare la tua esperienza su un blog permetterà a chiunque di imparare dal tuo operato, in puro spirito "community" secondo cui la condivisione dell'informazione è il bene più prezioso.

Se ritieni di non avere le capacità o l'esperienza necessarie per scrivere contenuti interessanti, beh, è il momento di ripensarci! Ricorda, "nessuno nasce imparato", e anche una scoperta che ritieni banale, per altri può essere causa di notti insonni...

Ecco un pò di risorse per guidarti all'apertura di un blog di successo e alla gestione corretta dei contenuti.

Ultime, ma non per importanza, un paio di regole generali:

Una community esiste se e solo se "esistono" i suoi membri, e vive dell'entusiasmo e della voglia di fare di chi si impegna per farla funzionare: nessuno prende uno stipendio o benefit di sorta per le attività di DotNetMarche, anzi spesso paga di tasca propria i costi di esercizio; ci aspettiamo dai membri della community voglia di fare e di partecipare, entusiasmo nel discutere e nel condividere e, perche nò, pure un pò di incoscienza e di "spirito di avventura" nel lanciarsi nelle attività del gruppo!

Se ritieni che l'attività del gruppo sia in qualche modo meritoria, e meritevole di pubblicità, beh, allora pubblicizzala!Puoi inserire un banner in fondo ai post del tuo blog (hai aperto un blog, vero?), puoi vantare la tua appartenenza a DotNetMarche nella firma della tua email o nei post nei newsgroup/forum, puoi "spargere la voce" tra i tuoi colleghi di lavoro o tra gli amici programmatori... ogni nuovo membro del gruppo spinge tutti gli altri a impegnarsi perchè DotNetMarche cresca anche nella qualità dei suoi contenuti!
Se ritieni al contrario che l'attività del gruppo non sia poi così tanto valida da meritare la tua pubblicità, beh, è il momento che ti impegni in prima persona per far cambiare le cose!

[SONDAGGIO PROFILO]

admin — Thu, 06 Jul 2006 11:20:00 GMT

Durante la prima cena del gruppo (25 Maggio 2006) sono stati fatti compilare dei questionari per tracciare un profilo dei partecipanti.
Questi sono i risultati dei 14 moduli pervenuti:

Quale è la tua attuale occupazione?

Lavoratore	93,0%
Studente	7,0%
Disoccupato	0,0%

Se sei lavoratore, che ruolo\i ricopri?

Titolare / Amministratore delegato      28,6%
Amministratore di rete                   7,1%
Project / Product Manager               14,3%
Amministratore di database              14,3%
Architetto                              50,0%
Sviluppatore                            57,1%
Web designer                             0,0%
Altro (specificare)                      0,0%

Quali tecnologie\linguaggi utilizzi abitualmente?

C#                              85,7%
Java                             7,1%
VB.Net                          50,0%
SQL                             92,9%
ASP.NET                         64,3%
VB6                             35,7%
COM / Win32                     28,6%
ASP / VBScript / VBA            21,4%
.NET Framework                  78,6%
Delphi                           0,0%
XML Web Services / SOAP / WSE   50,0%
C / C++                         28,6%
Remoting / DCOM / MSMQ          28,6%
Enterprise Services (COM+)      28,6%
Compact Framework               64,3%
HTML / CSS / Javascript         71,4%
Altro (specificare)              0,0%

Quali sono le tue aree di maggior interesse e quali ti piacerebbe approfondire?

Object oriented design & patterns     71,4%
Sviluppo mobile                       50,0%
Sviluppo web                          71,4%
Project management                    28,6%
Sviluppo windows forms                42,9%
Business intelligence                 50,0%
Tecnologie per l'accesso ai dati      57,1%
Applicazioni distribuite              35,7%
Developer tools                       42,9%
WinFx                                 28,6%
Common Language Runtime               28,6%
Computer graphics                     14,3%
Altro (specificare)                    7,1% (Accessibilità)

Quali iniziative ti piacerebbe fossero intraprese dallo user group?

Workshop tecnici                                             			78,6%
Community web (blog, forum, ecc..)                           			57,1%
Organizzazione trasferte eventi (eventi microsoft, ecc..)    			57,1%
Sviluppo applicazioni open source, o comunque in  ambiente collaborativo	2,9%
Cene e riunioni informali                                    			71,4%
Altro (specificare)                                       			0,0%

Ti piacerebbe partecipare agli incontri del DotNetMarche?

Si          100,0%
No            0,0%
Ci penserò    0,0%

Se hai risposto no o sei indeciso, ci sono particolari motivi?

Non mi interessa    0,0%
Mancanza di tempo   0,0%
Altro               0,0%

Saresti interessato a fare degli interventi tecnici durante gli incontri?

Si                  43,0%
No                   7,0%
Forse               50,0

Se si, su quali tematiche?

Object oriented design & patterns         28,6%
Sviluppo mobile                            7,1%
Sviluppo web                              28,6%
Project management                        21,4%
Sviluppo windows forms                    14,3%
Business intelligence                      7,1%
Tecnologie per l'accesso ai dati           7,1%
Applicazioni distribuite                  14,3%
Developer tools                            7,1%
WinFx                                     14,3%
Common Language Runtime                   28,6%
Computer graphics                          0,0%
Altro (specificare)                       21,4% (Sicurezza,Accessibilità,Collaboration)

Con che frequenza vorresti venissero fatti degli incontri?

30gg              14,3%
45gg              21,4%
60gg              35,7%
75gg              14,3%
90gg               7,1%
Non è rilevante    7,1%

Preferisci degli incontri serali o diurni?
```
Serali		93,0%
Diurni		7,0%
```

Di quale durata?

1-2 ore       21,4%
2-4 ore       71,4%
6-8 ore        7,1%

Saresti disposto a partecipare anche il sabato?

Si          57,1%
No          28,6%
Forse       14,3%

Hai problemi a spostarti?

No                                        64,3%
Dipende dalla frequenza degli incontri    28,6%
Massimo 50 Km                              0,0%
Massimo 100 Km                             0,0%
Massimo 20 Km                              0,0%
Si sempre                                  7,1%

Ti piacerebbe partecipare allo sviluppo di applicazioni all'interno dello users group, o comunque in un ambiente condiviso, per approfondire certe tecnologie e/o tools di sviluppo?
```
Si        50,0%
No         0,0%
Forse     50,0%
```

Sei soddisfatto dell'incontro di oggi?

Per niente          0,0%
Poco                0,0%
Abbastanza         14,3%
Molto              57,1%
Meglio di così     28,6%

Hai delle proposte, questioni o suggerimenti da sottoporre all'attenzione degli organizzatori e dei partecipanti?

Fare degli incontri di taglio tecnico, sviluppo o sistemistico, in cui le persone possano rapidamente identificarsi

[CONTATTI]

admin — Thu, 06 Jul 2006 11:18:00 GMT

Sito web: www.dotnetmarche.org
e-mail: staff@dotnetmarche.org

Puoi contattarci anche tramite il forum presente in questo sito, qualcuno sicuramente risponderà!