Di .NET e di altre amenita'

March 2006 Blog Posts

VS2005: Creare un CustomTool per Visual Studio 2005

Scommetto che tutti voi almeno una volta vi siete chiesti come funziona il meccanismo di Visual Studio 2005 che genera i file di codice per le risorse e per i file di configurazione in WindowsForms ma anche i DataSet. Vi confesso che a me ha sempre stuzzicato e spesso e volentieri ho immaginato i vantaggi che ne avrei potuto trarre se fossi riuscito a creare un generatore analogo.

La mia ricerca perciò è partita da quello che appariva essere la sorgente di questi file. Se aprite le proprietà di un qualsiasi file in Visual Studio (tutti tranne quelli di un progetto web...) vi renderete conto che c'è una voce sempre presente. Mi riferisco a "Custom Tool". Tale voce, nel caso dei file da cui viene generato un file sorgente contiene una stringa che a prima vista può apparire in qualche modo legata a .NET. Purtroppo dopo una ricerca approfondita con reflector non si riesce a trovare nulla che possa essere in qualche modo correlato. A questo punto la mia ricerca ha preso la via di Google e in breve sono riuscito a trovare che su gotdotnet esiste un esempio, riferito alle precedenti versioni di Visual Studio .NET 2002/2003. Questo esempio va sotto il nome di BaseCodeGeneratorWithSite. Si tratta di uno zip, che contiene i progetti per le due versioni di VS.NET.

Dovete sapere infatti che questa caratteristica è presente fin dalla prima versione dell'IDE. Addirittura nella versione 2002 le classi che si possono scaricare da gotdotnet erano dichiarate pubbliche negli assembly di Visual Studio ma poi sono state rese private nella versione successiva. Ecco il motivo per cui esse sono state pubblicate sotto forma di file sorgente nelle pagine di gotdotnet. Venendo alla versione 2005, dalle ricerche che ho effettuato ho scoperto che alcune delle interfacce presenti nel progetto di gotdotnet sono nuovamente esposte pubblicamente e si possono trovare nell'assembly Microsoft.VisualStudio.Shell.Interop.dll, che si trova nella GAC.

Tuttavia, il progetto scaricato da gotdotnet, nella versione 2003, e compilato con Visual Studio 2005 fa perfettamente il proprio dovere a testimonianza che il meccanismo di generazione non è affatto cambiato dalle versioni precedenti. Tale meccanismo è decisamente banale e piuttosto "grezzo" se mi passate il termine. Credo infatti che con un minimo di impegno se ne potrebbero trarre delle grandi soddisfazioni, ma attualmente si tratta di un sistema un po' limitato. Ma non è il caso di demoralizzarsi. Anche così com'è si riesce a combinare qualcosa di buono. Se vi scaricate lo zip che ho allegato troverete un Custom Tool, che poi vi spiegherò come installare, che consente qualora specificato su un file xml di generare le classi che operano la sua serializzazione/deserializzazione, alla stessa stregua di quello che si fa con xsd.exe.

Un Custom Tool, altro non è che un componente COM che implementa l'interfaccia IVsSingleFileGenerator, e in quanto tale può benissimo essere realizzato scrivendo un po' di codice in .NET; Questa interfaccia attualmente è esposta appunto dall'assembly che prima citavo, ma è indubbiamente molto più comodo utilizzare le classi BaseCodeGenerator e BaseCodeGeneratorWithSite. Alla fine realizzare un custom tool, a parte il codice necessario per convertire il file in ciò che vogliamo, si limita alle seguenti poche righe di codice:

[Guid("CE1B4057-D10A-4cd6-8E13-29B4699ACEAD")]
public class XmlSerializationCSharpGenerator : BaseCodeGenerator
{
    
public override string GetDefaultExtension()
    {
        
return ".cs";
    }

    
protected override byte[] GenerateCode(string inputFileName, string inputFileContent)
    {
        
// TODO: convertire il file qui
    
}
}

Il primo metodo comunica a VisualStudio l'estensione che dovrà essere usata per il file generato. Tale file avrà lo stesso nome di quello sorgente, salvo che l'estensione sarà cambiata e apparirà come nidificato all'interno del file sorgente stesso. Il secondo metodo invece, ricevuti in input il nome del file e il suo contenuto, si occupa di generare il codice e di restituirlo sotto forma di un array di bytes che Visual Studio si occuperà di salvare nella posizione opportuna. Ecco cosa intendo per "limitato". in effetti con questo meccanismo è possibile creare solo un file per ogni sorgente, e lo si può fare avendo in input esclusivamente il file sorgente. Se si volessero passare dei parametri per customizzare l'output ad esempio, questa possibilità ci sarà negata.

L'ultima cosa da notare nel sorgente che ho riportato è la presenza di un GUID generato casualmente con l'apposito strumento di Visual Studio. Tale GUID è quello che poi dovremmo utilizzare per registrare il Custom Tool nell'IDE di VS2005. Ecco di seguito come operare per l'installazione:

1) innanzitutto occorre compilare il progetto in versione release, ricordando di firmare tutti gli assembly con sn.exe altrimenti non saremmo in grado di registrarlo.

2) ora occorre copiare  gli assembly generati nella posizione in cui desideriamo tenerli. In seguito accederemo a questa directory mediante il prompt di Visual Studio 2005 e lanceremo il seguente comando:

regasm /codebase Elite.VisualStudio.CustomTools.dll

In questo modo avremo registrato i componenti dichiarati nell'assembly in questione che per inciso sono due; Uno per CSharp e uno per vb.net

3) a questo punto occorre aprire regedit e raggiungere questo nodo:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0\Generators\{FAE04EC1-301F-11d3-BF4B-00C04F79EFBC}

4) All'interno di questo nodo occorrerà inserire una chiave il cui nome sarà quello da utilizzare nell'apposita proprietà di un file per applicarvi il nostro Custom Tool.

5) Concludiamo creando i seguenti due valori:

CLSID (String) in cui specificare i guid dei due componenti racchiusi tra graffe

{CE1B4057-D10A-4cd6-8E13-29B4699ACEAD} per XmlSerializationCSharpGenerator
{7CDAAE56-B3A5-4514-9B0E-8BC1E80B1C68} per XmlSerializationVBGenerator

GeneratesDesignTimeSource (DWORD) contenete il valore "1".

A questo punto, senza nemmeno dover chiudere Visual Studio se nel frattempo lo avete lasciato aperto, specificando una delle due stringhe otterrete immediatamente il file cs o vb contenente il codice generato. Per ulteriore chiarimento dovete sapere che la generazione del codice avviene utilizzando lo stesso meccanismo di cui fa uso xsd.exe, con i limiti conosciuti cui bisogna stare attenti. A tali classi vengono aggiunti alcuni metodi statici per facilitare la deserializazione.

Giusto per darvi un'idea delle possibilità che questo strumento mette a disposizione sappiate che nell'esempio allegato ho semplicemente scaricato con ie il feed rss del mio weblog. Poi ho aggiunto questo file ad un progetto e impostato il custom tool mi sono ritrovato tutte le classi necessarie per deserializzarlo e visualizzarli in una piccola applicazione windowsform.

Download: Elite.VisualStudio.CustomTools.zip (301 KB) 

powered by IMHO 1.3


per leggere il post originale o inviare un commento visita il seguente indirizzo: VS2005: Creare un CustomTool per Visual Studio 2005

.NET 2.0: Un CacheManager trasparente

Chi come me sviluppa in ambiente web, è abituato a fare uso, talvolta anche abuso della Cache che il runtime http integra nel framework ASP.NET. Non tutti sanno però che questa cache, può essere abbastanza facilmente essere usata anche in applicazioni Windows Forms. In soldoni è sufficiente creare un runtime http fittizio che supporti adeguatamente la cache e il gioco è fatto.

In realtà si tratta di un trucco abbastanza vecchio e conosciuto, ma quest'oggi ho finalmente deciso di risolvere con problema in modo definitivo. Il fatto è che spesso è utile incapsulare il caching all'interno di classi che poi possono trovare utilità indifferentemente  in applicazioni WebForms o WindowsForms. Perciò sarebbe utile avere una cache che si adegui al contesto in cui viene istanziata in modo trasparente. Vi propongo perciò in allegato a questo post il codice che ho realizzato, accompagnato da uno schema tratto dal class diagram di Visual Studio 2005 per esporvi la soluzione.

Le tre classi che potete vedere a fianco pur nella loro semplicità fanno uso di due Design Pattern. Il CacheManager si comporta da un lato come una Abstract Factory, consentendo di istanziare con il metodo statico Create() un'istanza concreta dedicata all'ambiente in cui il processo è in esecuzione. Il test è molto semplice: se è presente un HttpContext verrà istanziato l'HttpCacheManager, in caso contrario la scelta ricaderà sul WinFormsCacheManager. La classe CacheManager inoltre è un Singleton. Essa espone una proprietà Current la quale rende disponibile il CacheManager corretto istanziato per mezzo di Create(). Questa organizzazione consente di avere accesso alla cache adatta al contesto per mezzo di una sola riga di codice:

object cached = CacheManager.Current["cachedObject"];

La classe concreta che implementa il CacheManager espone una serie di proprietà e metodi molto comodi. Add() che consente di aggiungere un item in cache, e IsCached che data una chiave verifica se essa è già presenti in cache. Quest'ultimo metodo permete di scrivere qualcosa del genere:

public List<Product> GetProduct(int sku)
{
    
if (!CacheManager.Current.IsCached(sku))
        CacheManager.Current.Add(
            sku, 
            GetProductFromDB(sku), 
            TimeSpan.FromSeconds(20));

    
return CacheManager.Current[sku] as Product;
}

Download: Elite.Utilities.Caching.zip (42 KB)

powered by IMHO 1.3


per leggere il post originale o inviare un commento visita il seguente indirizzo: .NET 2.0: Un CacheManager trasparente

Il terrorismo della TV...

Ho appena terminato di ascoltare un intervento di un Maresciallo della finanza, a "l'incudine", che pur essendo puntuale e dettagliato dal punto di vista formale, per un profano della rete è un vero e proprio attentato alla rete stessa. Questo tale ha brutamente elencato ed enfatizzato, nello spazio di 60 secondi tutto il "male" che viene dalla rete, senza dare la pur minima possibilità di spiegazione, e senza attenuare minimamente le proprie parole. Si è trattato di un intervento a senso unico, che si è tenuto ben lontano dagli immensi vantaggi che si possono trarre dall'uso di Internet, in favore di una demonizzazione piuttosto stantia della rete, ma che in un paese arretrato come il nostro purtroppo trova sempre terreno fertile.

Forse una informazione più corretta e cauta potrebbe al tempo stesso combattere gli indubbi pericoli della rete, ma incoraggiare le persone ad usarla per trarne tutto il possibile vantaggio in termini di informazione, e di conoscenza. In fin dei conti, noi che in rete viviamo sappiamo bene che un virus informatico non è dannoso per la nostra salute, ma vallo a spiegare a una persona normale, già timorosa dell'influenza avicola, che al massimo gli può danneggiare qualche dato sul computer.

powered by IMHO 1.3


per leggere il post originale o inviare un commento visita il seguente indirizzo: Il terrorismo della TV...

XEDOTNET: Siamo membri di INETA

Ho appena finito di postare nel sito della community, di mandare una newsletter agli iscritti, e di apportare le necessarie modifiche al sito web. Sì, infatti oggi è finalmente arrivata l'attesa email che mi comunica che XE.NET è ufficialmente diventato membro di INETA, l'associazione internazionale che riunisce gli usergroup su .NET. I ringraziamenti non sono mai inutili, perciò permettetemi di farli giungere a chi in questo periodo mi/ci ha supportato e naturalmente allo staff di INETA che ha esaminato la nostra attività, giudicandola positivamente.

Ora ci avviamo verso il prossimo meeting, che dovrebbe tenersi verso la seconda metà di Aprile, del quale va deciso l'argomento, e le sessioni. Ci sarà spazio spero per almeno un paio di interventi, non troppo lunghi, che questa volta vogliamo siano sostenuti dai membri della community stessa. Infatti se siamo una community non dobbiamo solo essere ascoltatori, ma iniziare a produrre conoscenza nella speranza di divenire un giorno una fucina di talenti. Perciò fatevi avanti, contattatemi e fatemi sapere di cosa vorreste parlare. Il mio compito sarà quello di unire la domanda e l'offerta... e chissa che non ci scappi anche un mio intervento  ... brrr che fifa!

Grazie a tutti.

powered by IMHO 1.3


per leggere il post originale o inviare un commento visita il seguente indirizzo: XEDOTNET: Siamo membri di INETA

VS2005: Uno snippet per validare i parametri

Forse non sono in molti che gestiscono la validazione dei parametri di input di un metodo, tuttavia considerato che sarebbe una buona cosa farlo, vi propongo uno snippet che mi sono creato che dovrebbe semplificare questa ripetitiva attività. Lo snippet, che nell'esempio è dedicato al caso delle stringhe, compila per noi una sezione di validazione e ci consente di immettere il nome del parametro e il messaggio che vogliamo dare nell'eccezione.

<?xml version="1.0" encoding="utf-8" ?>
<CodeSnippets  
xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
    <CodeSnippet 
Format="1.0.0">
        <Header>
            <
Title>param_str</Title>
            <Shortcut>
param_str</Shortcut>
            <Description>
Code snippet for string parameter validation</Description>
            <Author>
Andrea Boschin</Author>
            <SnippetTypes>
                <SnippetType>
Expansion</SnippetType>
            <
/SnippetTypes>
        <
/Header>
        <Snippet>
            <Declarations>
                <Literal>
                    <
ID>argument</ID>
                    <ToolTip>
Argument name</ToolTip>
                    <Default>
name</Default>
                <
/Literal>
                <Literal>
                    <
ID>messageNull</ID>
                    <ToolTip>
Exception Message for null string</ToolTip>
                    <Default>
Argument cannot be null</Default>
                <
/Literal>
                <Literal>
                    <
ID>messageEmpty</ID>
                    <ToolTip>
Exception Message for empty string</ToolTip>
                    <Default>
Argument cannot be empty</Default>
                <
/Literal>
            <
/Declarations>
            <
Code Language="csharp">
                <![CDATA[if 
($argument$ == null)
                throw new ArgumentNullException("$argument$", "$messageNull$");
                if 
($argument$ == string.Empty)
                throw new ArgumentException("$argument$", "$messageEmpty$");$end$]]>
            <
/Code>
        <
/Snippet>
    <
/CodeSnippet>
<
/CodeSnippets>

Alla vostra fantasia tutte le possibili varianti.

powered by IMHO 1.3

 


per leggere il post originale o inviare un commento visita il seguente indirizzo: VS2005: Uno snippet per validare i parametri

ASP.NET 2.0: Una macro per fare l'attach ad aspnet_wp.exe

Mi sono finalmente deciso ad investire qualche minuto del mio tempo per farmi una macro che mi aiuti a risparmiare le decine di secondi che di solito impiego per fare l'attach al processo di aspnet_wp.exe, per debuggare un website in IIS su XP. Di solito preferisco questo metodo perchè così posso tenere aperto un browser sulla pagina che sto realizzando e non debbo eseguire uno stesso path all'interno del sito per arrivarci ogni volta con il webserver integrato di Visual Studio 2005.

Ecco la macro scritta in puro VB.NET (arrggggggg!!!)

Imports System
Imports EnvDTE
Imports EnvDTE80
Imports System.Diagnostics
Imports System.IO

Public Module AspNetMacros

    
Sub AttachASPNET()

        
Dim aspnet As EnvDTE.Process = 
            FindASPWP(_ApplicationObjects.DTE)

        
If Not aspnet Is Nothing Then

            
aspnet.Attach()

            System.Threading.Thread.Sleep(2000)

        
Else

            MsgBox
("Cannot find aspnet_wp.exe")

        
End If

    End Sub


    Public Function 
FindASPWP(ByRef dte As EnvDTE.DTE) As EnvDTE.Process

        
For Each proc As EnvDTE.Process In dte.Debugger.LocalProcesses
        
            
If (Path.GetFileName(proc.Name) = "aspnet_wp.exe") Then
                Return 
proc
            
End If
        
        Next

        Return Nothing

    End Function

End Module

Naturalmente potete anche customizzarla per fare l'attache al processo che desiderate. Spero che faccia risparmiare qualche ora di lavoro anche a voi.

powered by IMHO 1.3


per leggere il post originale o inviare un commento visita il seguente indirizzo: ASP.NET 2.0: Una macro per fare l'attach ad aspnet_wp.exe

IMHO 1.3: In uscita un articolo che ne parla

Sul prossimo numero di Aprile di Computer Programming, già citato da Simone, uscirà un articolo dedicato ad IMHO 1.3. Si tratta di un paio di pagine nelle quali oltre ad illustrare alcune delle caratteristiche salienti del software mi dilungo anche sulla mia concezione del weblogging e sulla storia di questo software.

Ho deciso di dedicare questo articolo a XE.NET. In calce all'articolo infatti apparirà il logo della nuova community, nella speranza di stimolare l'interesse dei miei corregionali, e magari anche dei limitrofi.

Buona lettura a tutti.

powered by IMHO 1.3


per leggere il post originale o inviare un commento visita il seguente indirizzo: IMHO 1.3: In uscita un articolo che ne parla

La concezione veneta del pair programming

Cito una battuta di un collega (che preferisce rimanere anonimo ) che illustra bene qual'è la concezione del "pair programming" qui in veneto.

I 'mpiegati dee poste i fa par programming da tanto tempo: "uno eavora e staltro varda!"

Traduzione: Gli impiegati delle poste praticano il "pair programming" da molto tempo: Uno lavora e l'altro guarda

Per inciso qui in veneto non c'è una opinione molto positiva del modo di lavorare dei suddetti impiegati.

Non me ne volere luka... è solo una battuta!

powered by IMHO 1.3


per leggere il post originale o inviare un commento visita il seguente indirizzo: La concezione veneta del pair programming

Url rewriting e sitemap provider, un sodalizio inatteso

Vi segnalo la presenza su ugidotnet del mio ultimo sforzo tecnico-letterario. Si tratta di un breve articolo che illustra come affiancare la Sitemap di ASP.NET 2.0 e un engine di url rewriting che sfrutta le regular expressions. Si tratta di un articolo breve ma denso, che affronta le problematiche di indicizzazione nei motori di ricerca, le tecniche di rewriting, e la personalizzazione della XmlSiteMap.

Buona lettura: Url rewriting e sitemap provider, un sodalizio inatteso

powered by IMHO 1.3


per leggere il post originale o inviare un commento visita il seguente indirizzo: Url rewriting e sitemap provider, un sodalizio inatteso

Scrivere un provider per Monad (MSH) #3: Navigare lo schema

Con questo post si conclude la serie dedicata alla creazione di un provider per Monad. In realtà è molto probabile che torni ulteriormente su Monad che ha su di me un fascino irresistibile, ma per ora mi appresto a concludere la serie che mi ha visto affrontare questo interessante argomento.

Nel precedente post ci siamo soffermati su come fare ad inizializzare il provider per rispondere ad un drive di default, tuttavia devo segnalare che esiste un interessante cmdlet che consente di creare dei "drive virtuali" mappati su un qualsiasi percorso gestito da un provider. Si tratta di new-drive della quale riporto un esempio:

new-drive K FileSystem d:\downloads

Questo semplice comando crea un drive K mappato su una cartella del filesystem. Questa cmdlet è in effetti supportata anche dal provider di cui sto parlando. A mio parere si tratta di una feature interessante e utile che rispetto ai mapped drives di windows ha certamente una marcia in più.

La prima operazione che ci aspetteremo di poter compiere su un provider è quella con la quale siamo tipicamente abituati a navigare all'interno del filesystem. Mi riferisco al comando "cd" che in Monad corrisponde a set-location, che però annovera tra i suoi alias anche lo stesso "cd". Il metodo che corrisponde alla set-location di Monad è ItemExists(), il quale si aspetta di verificare se un percorso specificato esiste oppure no. Il seguente comando ad esempio ha l'effetto di spostare il percorso corrente sul database locale:

set-location "sql:\(local)"

I doppi apici sono necessari in quanto le parentesi sono dei caratteri che per Monad hanno un preciso significato. Questo comando, invocato da console, ha l'effetto di invocare il seguente metodo:

protected override bool ItemExists(string path)
{
    SqlPathInfo pathInfo = 
new SqlPathInfo(path);

    
if (pathInfo.Level == PathLevel.Root)
        
return true;
    
else if (pathInfo.Level == PathLevel.Server)
        
return ServerExists(pathInfo);
    
else if (pathInfo.Level == PathLevel.Database)
        
return ServerExists(pathInfo);
    
else if (pathInfo.Level == PathLevel.DbObject)
        
return DbObjectExists(pathInfo);

    
return false;
}

Si tratta dell'ennesimo overload di un metodo virtuale del provider che stiamo creando. ItemExists(), si distingue da IsValidPath() per lo scopo cui è preposto; esso infatti ha l'obbiettivo di verificare che un path, la cui correttezza formale è stata precedentemente verificata da IsValidPath(), corrisponda ad un elemento che esiste effettivamente. Infatti, il path che passiamo a set-location, pur se formalmente corretto, cioè composto dalla corretta sequenza di caratteri e backslash, potrebbe inviarci ad una risorsa che non è presente. In questo casi ItemExists() deve ritornare false. Il metodo che ho riportato fa uso di una classe appositamente realizzata che dato un path lo scompone nelle sue parti fondamentali usando una regular expression e ne ritorna le informazioni. In particolare ad ogni possibile livello (root>server>database>tabella) corrisponde una verifica di esistenza specifica.

L'altra operazione che a rigor di logica ci aspetteremo di poter compiere nella navigazione è la comunissima "dir", ovvero l'elenco del contenuto di una "cartella". Nel gergo di Monad, questa operazione si chiama get-childitem e risponde al metodo GetChildItems() del provider. Tale metodo è implementato in modo analogo al precedente:

protected override void GetChildItems(string path, bool recurse)
{
    SqlPathInfo pathInfo = 
new SqlPathInfo(path);

    
if (pathInfo.Level == PathLevel.Root)
        GetAvailableServers(pathInfo, path);
    
else if (pathInfo.Level == PathLevel.Server)
        GetServerDatabases(pathInfo, path);
    
else if (pathInfo.Level == PathLevel.Database)
        GetDatabaseTables(pathInfo, path);
    
else if (pathInfo.Level == PathLevel.DbObject)
        GetTableFields(pathInfo, path);
}

Tutta la logica è contenuta nei metodi GetAvailableServers, GetServerDatabases, GetDatabaseTables e GetTableFields che fanno esattamente quello che ci si aspetta a prima vista. Essi interrogano lo schema del database per ottenere la visualizzazione richiesta. Questo vale per tutti tranne che per il primo che invece fa uso di una classe che cerca sulla rete i server sql disponibili.

E'interessante approfondire almeno uno di questi metodi, perchè dimostrano come si debbano restituire le informazioni a Monad. Se ricordate infatti, nel primo post della serie avevo introdotto come i risultati che leggiamo sulla console altro non siano che la rappresentazone testuale di una serie di oggetti .NET per precisi. In questo caso i metodi restituiscono una collection di oggetti che incapsulano queste informazioni e le espongono per mezzo di proprietà.

private void GetAvailableServers(SqlPathInfo pathInfo, string path)
{
    List<SqlServerInfo> servers = 
new List<SqlServerInfo>();

    SQLInfoEnumerator enumerator = 
new SQLInfoEnumerator();
    
    
foreach (string sqlServer in enumerator.EnumerateSQLServers())
        servers.Add(
new SqlServerInfo(sqlServer));

    WriteItemObject(servers, path, 
true);
}

La collection di oggetti di tipo SqlServerInfo, restituita a Monad fa si che venga creata una tabella le cui colonne sono costituite dalle proprietà pubbliche di questo oggetto. Non solo, se ad esempio nella classe SqlServerInfo implementassimo un metodo Start() che avvia l'istanza in questione saremmo in grado di eseguire questo metodo per ogni istanza di oggetto nella collection e quindi indirettamente potremmo intervenire sullo stato del database.

Tutto questo a mio parere è di una eleganza che non ha pari. Una shell così concepita ha delle potenzialità eccezionali, dato che consente una manipolazione molto sottile dell'ambiente in cui viene eseguita. Se mettete in conto che la shell dispone di molti dei comandi che ci aspetteremo da un linguaggio di programmazione evoluto ecco che diventa subito evidente il perchè riferendosi a Monad si usi a ragione la locuzione "di nuova generazione".

powered by IMHO 1.3


per leggere il post originale o inviare un commento visita il seguente indirizzo: Scrivere un provider per Monad (MSH) #3: Navigare lo schema

E finalmente i serramenti

qualche foto della mia casa

Nel nostro piccolo... un grande incontro!

Ce l'abbiamo fatta, e ora si tirano le somme del meeting che si è appena concluso. Le foto parlano da sole... un grande incontro cui hanno partecipato circa venti persone che spero siano rimaste soddisfatte degli interventi. In effetti, scorrendo rapidamente i moduli di feedback la frase che più si ripete è sempre "continuate così!". E così che continueremo, con degli incontri forse un po' più "familiari" intercalati ad incontri di più alto profilo. I primi preparatori dei secondi, i secondi propedeutici all'ingresso di nuove persone che arricchiscano i primi.

In effetti l'esperienza è stata bella e ora l'appetito di altre occasioni di questo tipo è forte. Ma ora che abbiamo dimostrato cosa sappiamo fare è arrivato il momento di capire se riusciamo a camminare con le nostre gambe. Il forum è aperto sul sito di xedotnet e attende segnalazioni di argomenti che vorremo approfondire. Il mio messenger (scrivetemi e vi mando l'indirizzo) è a vostra disposizione per farmi sapere che ne pensate e per accogliere le proposte di chi desideri provare a cimentarsi in una sessione.

Nel frattempo godetevi la gallery che ho aperto sul sito di XEDOTNET.

http://www.xedotnet.org/photos/332006/default.aspx

Grazie a tutti. Davvero di cuore!

powered by IMHO 1.3

 


per leggere il post originale o inviare un commento visita il seguente indirizzo: Nel nostro piccolo... un grande incontro!

XEDOTNET: Il meeting è alle porte.

Ci siamo quasi. Domani sera finalmente si terrà il primo meeting di XeDotNet. I preparativi oramai sono conclusi, anche se all'ultimo momento abbiamo avuto un brivido dovuto al guasto del proiettore. Per fortuna alla fine siamo riusciti a trovare 4 rimpiazzi...

L'attesa è ancora breve e poi finalmente sapremo quanti effettivamente parteciperanno a questo che a mio parere dovrebbe essere un incontro fondamentale per determinare come dovrà continuare questa esperienza. Domani sera ci conteremo, e vedremo se la scommessa che abbiamo fatto poco più di un mese fa sarà vinta o persa. Io ci conto, le preiscrizioni sono tante e i nomi che aspettiamo sono importanti. Qualcuno ha già detto che arriverà con un po' di ritardo per problemi di lavoro, ma la maggior parte è ancora silente e la vedremo domani sera.

Mi aspetta un breve intervento ad introduzione del meeting nel quale dovrò illustrare i perchè e i "percome" di XeDotNet e per mezzo del quale spero di raccogliere i suggerimenti necessari a determinare che argomenti trattare prossimamente. L'idea è che siano gli interventi nel forum a indicare l'argomento del prossimo meeting (che probabilmente si terrà fra circa un mese) e che nel gruppo emergano una o due persone che si incaricano di approfondirlo e presentarlo, per poi farsi "sbranare" dalle domande dei convenuti durante la successiva Q&A.

Ma per ora guardiamo a domani. Vi aspettiamo numerosi...

powered by IMHO 1.3


per leggere il post originale o inviare un commento visita il seguente indirizzo: XEDOTNET: Il meeting è alle porte.