Di .NET e di altre amenita'

Ho letto il post di Lanny stamattina e ho deciso che probabilmente era il caso di postare un esempietto su come sia preferibile lavorare con la reflection per evitare i problemi più comuni. L'esempio di Lanny funziona ed è utile per capire come funziona la reflection, ma dovendo lavorare con essa è opportuno fare affidamento su una serie di classi belle e pronte che il framework mette a disposizione. Oltre a snellire il lavoro eliminando la necessità di riscrivere del codice che è già perfettamente funzionane, consentono soprattutto di avere un modo affidabile di operare conversioni di tipo senza incorrere nei comuni errori dovuti alla globalization. Ecco uno spezzone di codice commentato che mostra come creare un tipo, settarne le proprietà e operare delle conversioni da stringa a data utilizzando le comodissime TypeDescriptor e TypeConverter:

using System;
using System.Collections.Generic;
using System.Text;
using System.ComponentModel;
using System.Globalization;

namespace TestTipi
{
    class Program
    {
        static void Main(string[] args)
        {
            // ottengo il riferimento al tipo da istanziare
            Type personType = 
                Type.GetType("TestTipi.Person, TestTipi");
            
            // creo una istanza del tipo
            object p = 
                TypeDescriptor.CreateInstance(null, personType, null, null);
            
            // ottengo una collection delle property dell'istanzaa
            PropertyDescriptorCollection personProperties = 
                TypeDescriptor.GetProperties(p);
            
            // setto FirstName
            PropertyDescriptor firstName = 
                personProperties.Find("FirstName", false);
            firstName.SetValue(p, "Andrea");

            // setto LastName
            PropertyDescriptor lastName = 
                personProperties.Find("LastName", false);
            lastName.SetValue(p, "Boschin");

            // setto Birthday
            PropertyDescriptor birthDay = 
                personProperties.Find("Birthday", false);
            TypeConverter converterToDate = 
                TypeDescriptor.GetConverter(birthDay.PropertyType);
            birthDay.SetValue(
                p,
                converterToDate.ConvertFromString(
                    null, 
                    CultureInfo.CreateSpecificCulture("en-US"), 
                    "10/27/1968"));

            // dump sulla console
            Console.WriteLine(p);
            Console.ReadLine();
        }
    }

    /// <summary>
    /// classina di test
    /// </summary>
    class Person
    {
        private string firstName;
        private string lastName;
        private DateTime birthday;

        public string FirstName
        {
            get { return firstName; }
            set { firstName = value; }
        }

        public string LastName
        {
            get { return lastName; }
            set { lastName = value; }
        }

        public DateTime Birthday
        {
            get { return birthday; }
            set { birthday = value; }
        }

        public override string ToString()
        {
            return string.Format(
                "{0} {1} ({2})", 
                this.FirstName, 
                this.LastName, 
                DateTime.Now.Year - this.Birthday.Year);
        }
    }
}

Due note rapide sull'esempio: per creare l'istanza di un tipo è opportuno evitare l'uso di Assemply.LoadFrom() ovunque possibile. piuttosto è preferibile usare come nell'esempio la Type.GetType() passando il nome completo del tipo includendo anche version, culture e publickeytoken qualora l'assembly si trovi in GAC o sia firmato. Usare il riferimento al nome del file non è una buona politica perchè così facendo si esclude tutto il meccanismo di ricerca di fusion. La Type.GetType() è in grado di lavorare perfettamente anche con gli assembly autogenerati a patto che vengano messi in una directory che si trova nell'ambito del probing di fusion.

Secondo: convertire da stringa a qualsiasi tipo e viceversa è un'attività insidiosa tanto che nel framework ci sono svariati errori proprio su questo argomento. Meglio perciò usare la TypeConverter che per inciso è un grado di fare conversioni anche su tipi particolari come ad esempio le Unit. TypeDescriptor ha un bellissimo metodo GetConverter() che è in grado di istanziare l'opportuno convertitore semplicemente passandogli il tipo di destinazione. Okkio quindi che la Culture va passata SEMPRE!

Ok, lo ammetto, sono stato preso in contropiede dall'uscita del nuovo e sfavillante Live Writer che - non ci vuole molto ad ammetterlo - surclassa e "seppellisce" definitivamente il mio IMHO 1.3. La domanda mi gira in testa da un po' di giorni ormai ma finalmente ho trovato il tempo di esprimerla su queste righe.

Continuo IMHO?

Ne ho parlato con parecchie persone in questi giorni, e i pareri sono molto discordi. Da chi mi dice chiaramente, "lascia perdere, non ha futuro" a chi invece invece mi incoraggia ad andare avanti e provarci lo stesso, probabilmente per affetto o magari perchè realmente crede che io ce la possa fare.

E' evidente che non abbiamo alcuna speranza di fare concorrenza a live writer, non fosse altro perchè non abbiamo un team di 20 programmatori. Le uniche speranze sono quelle di trovare una nicchia, in cui collocare Imho 2.0 oppure, quella che mi alletta di più di dare delle feature talmente innovative da superare le leccornie di live writer...

Il problema è che live writer è un prodotto nuovo che ha alle sue spalle la potenza di sviluppo e marketing di una azienda colossale, che in questo momento lo vede come uno strumento eccezionale per contrastare il suo diretto concorrente (Google). Per questo motivo, anche dovessi davvero inventare il ghiaccio bollente non ci vorrà molto per essere nuovamente superato.

Al momento sono molto dubbioso, nonostante stiamo lavorando alacremente sulla versione 2.0 che ha superato già le prime fasi del porting a nhibernate e che si avvia verso una prima release alpha a passi svelti. Avrei molte altre idee su cui investire, altri progetti che mi girano in testa, ma vi confesso che l'affetto che ho per questo progetto mi impedisce di chiuderlo definitivamente e repentinamente. Al momento perciò IMHO rimane vivo, nella speranza che altri vogliano aggregarsi al nostro team per dare il proprio contributo e che, il supporto che ho avuto in questi anni, non sia del tutto svanito.

Ho appena rilasciato sul sito di NHibernate una patch che consente l'utilizzo di NHibernate 1.2 Alpha 1 in collaborazione con Sql Server Everywhere. Il problema che ho riscontrato è che i dialetti definiti per SqlServer 2005 e per SqlServer 2000 fanno uso della funzione SCOPE_IDENTITY() per ottenere il valore della identity dell'ultimo record inserito. In Sql Server Everywhere invece questo valore deve essere ottenuto mediante l'uso della variabile @@IDENTITY. Inoltre, il database embedded, a differenza dei fratelli maggiori, non supporta l'esecuzione di più statement SQL nello stesso comando per cui la classica accoppiata insert + select non è valida. La patch che ho inviato al team di NHibernate a questo indirizzo risolve questi problemi, nella speranza che non ce ne siano altri.

http://jira.nhibernate.org/browse/NH-691

Alcuni post orsono ho accennato alla lettura che mi ha occupato le assolate giornate di spiaggia. Si tratta di Getting Things Done, lo stupendo libro di David Allen che mi ha aperto gli occhi su quello che probabilmente sbaglio nell'organizzare il mio lavoro. GTD, questa l'abbreviazione del metodo perfezionato da David Allen in molti anni di pratica ha uno spirito davvero pragmatico e coerente con la realtà che ci circonda. Personalmente mi sono ripromesso di provarci, e attualmente mi sto organizzando al megli per reperire uno strumento che mi consenta di permeare tutta la mia vita, e non solo il lavoro di questo metodo. L'autore infatti parte da un presupposto che ai più potrebbe apparire esagerato, ma che a mio parere è solo la logica conseguenza di una corretta organizzazione. In effetti se tentiamo di introdurre il metodo di Allen solo in una parte della nostra vita, probabilmente sul lavoro ne deriverà uno sbilanciamento tale che in breve ci costringerà a lasciar perdere. Invece mi pare del tutto logico comprenetrare la vita lavorativa e la cosidetta "vita privata", di cui la prima è un aspetto rilevante, ma non necessariamente l'unico e più importante. Allen consiglia di pensare alle attività che vogliamo compiere come a progetto, ognuno dei quali composto da delle "azioni", necessarie a portarlo a termine. Nostro unico onere è quello di trovare la Next Action, per ognuno di essi, cioè l'azione immediatamente necessaria e fattibile perchè esso venga portato di un passo verso il compimento. Così, di passo in passo, le ferie con la famiglia, il traguardo personale, o il progetto di lavoro, ognuno con la giusta dose di analisi arriveranno naturalmente ad un traguardo che invece non sempre è così alla portata di mano. Forse sto un po' estremizzando. D'altronde sono fresco di lettura e non l'ho ancora provato, ma quello che mi ha più colpito di questo libro è un'affermazione talmente ovvia che ai più può apparire scontata, ma che invece ognuno di noi sa che spesso è disattesa. L'autore dice semplicemente: "prima di fare qualsiasi cosa occorre pensare". Banale vero? Ma voi lo fate sempre?

E nei primi freddi di Agosto (?) e' giunto il momento che metta al corrente tutti delle novità che riguardano il mio progetto IMHO, che oramai molti potrebbero considerare quasi-defunto dato che da tempo non se ne sa più nulla. IMHO invece è ancora vivo, perlomeno respira, ma dopo un periodo di congelamento dovuto allo scarso tempo a disposizione sta per riprendere il via. Questo grazie soprattutto al fatto che da alcune settimane si è unito a me nello sviluppo Mauro Servienti, che ha risposto all'appello che qualche tempo fa ho lanciato sul mio blog. IMHO perciò non sarà più solo il mio progetto.

Attualmente ci stiamo allineando su quello che già esiste, e abbiamo abbozzato una divisione dei compiti che dovrebbe vedere Mauro occuparsi della parte client e io della parte server. Non siamo ancora in grado di prevedere una data di rilascio dato che non abbiamo nemmeno provato a quantificare il lavoro, ma sono fiducioso che ora la spinta di due persone possa portarlo avanti molto rapidamente, almeno nella versione che abbiamo definito "Personal". IMHO, soffre attualmente di alcuni problemi che dovremmo affrontare per primi in modo da rimetterlo in carreggiata. Primo fra essi l'adozione di NHibernate come motore di Mapping, in sostituzione di iBatis che è un po' troppo "macchinoso". L'adozione di NHibernate sarà resa possibile dal cambio della base dati che passerà da Access, probabilmente a SQL Everywhere, per la versione base. Infine, ma questo sarà un problema che dovrà affrontare soprattutto Mauro, ci dovremmo scontrare con la prossima "sparizione" del controllo DHTML Edit, che era il cuore del precedente software. Infatti pare che da Internet Explorer 7.0, per motivi legati alla sicurezza questo controllo non sarà più disponibile e saremo costretti a trovarne un valido sostituto.