Un bel ricordo del TechEd EMEA 2007

La sessione di chiusura dello scorso TechEd EMEA 2007 è stata sicuramete una delle più belle sessioni a cui abbia mai assistito. Il titolo era "The Irresistible Forces Meet the Movable Objects".
Se siete curiosi di capire come sarà il futuro per noi "software guys" non perdetevela!
Qui il video.

Gli {eroi} del semaforo

Per chi è stato in questi giorni al lancio dei nuovi prodotti Microsoft sicuramente avrà già visto questi due strani tizi(da sx Emanuele ed Andrea). Se ancora non sapete a cosa serve il semaforo non vi resta che leggere qui.

 semaforo

IronRuby news

Da un’annuncio di lavoro MS segnalo 2 punti interessanti relativi al progetto IronRuby:

· Our goal this year is to get Ruby on Rails working in IronRuby

· We also want to provide IronRuby support in the Visual Studio IDE

Technorati tags: , ,

UgiAlt.net (mini)conference - 23 Febbraio 2008

Come scritto da Ema qualche tempo fa, come ugialt.net stiamo organizzando una giornata di conferenza. Dopo il sondaggio fatto sulla lista è emerso che il giorno preferito è 23 Febbraio 2008.

La conferenza si svolgerà presso la sede di ABSistemi che gentilmente ci supporta in questa iniziativa. Abbiamo già alcune proposte che a breve metteremo ai voti per capire quali siano più interessanti e quindi meritano essere i primi temi di discussione. La partecipazione è completamente gratuita! Il formato delle sessioni sarà di tipo open space, quindi chi propone gli argomenti non ha il ruolo dello "speaker classico" ma ha lo scopo di dare avvio alla discussione con codice, qualche slide o semplicemente introducendo l'argomento e di lasciare poi che le cose vadano. In pratica sarà una tavola rotonda sui temi scelti in cui ognuno può prendere la parola (o la tastiera) e proporre soluzioni o sottoporre nuove domande.

Maggiori informazioni sul sito e sulla mailing list.

Technorati tags:

Callbacks hook come RubyOnRails in C#

In questi giorni di calma apparente mi sto guardando un po' di RubyOnRails. In questo framework ho trovato cose interessanti. Una tra le tante è la possibilità di definire nel Model dei metodi in modo tale che vengano invocati prima e dopo una determinata azione. Es. è possibile indicare un metodo come azione before_save in modo che venga eseguito prima del metodo save. 
Sono presenti parecchie possibilità tra cui:

Maggiori info a riguardo le trovate qui.

Ora mi sono chiesto come è possibile avere una funzionalità simile in C#. Ho aperto VisualStudio è sono giusto a questa soluzione. E' solo una prima bozza, sicuramente si può fare di meglio!
Partiamo per esempio da un piccolo pezzo di codice che salva un oggetto Task così:

   1: Task task = new Task(1, DateTime.Today, "Demo task");
   2: IModel model = new TaskModel();
   3: model.Save(task);

ora quello che vorrei ottenere è la possibilità di eseguire un metodo prima ed uno metodo dopo il Save. La prima soluzione sfrutta una mia classe Hook in cui ho definito un metodo che accetta come parametri il metodo da invocare, il parametro per questo metodo e successivamente 2 delegate ai metodi che voglio eseguire come before_save e after_save:

   1: public class Hook
   2: {
   3:     public delegate void Action<A>(A a);
   4:  
   5:     public static void Do<A>(Action<A> action, A a, Action beforeAction, Action afterAction)
   6:     {
   7:         beforeAction();
   8:         action(a);
   9:         afterAction();
  10:     }
  11: }

Poi viene usata così:

   1: Task task = new Task(1, DateTime.Today, "Demo task");
   2: IModel model = new TaskModel();
   3: Hook.Do(model.Save, task, model.ActionsBeforeSave, model.ActionsAfterSave);

Partendo da questa prima soluzione ho cercato di sfruttare l'uso deglil attributi in modo tale da rendere il mio codice più semplice e leggibile. La seconda soluzione sfrutta quindi oltre ai delegate anche gli attributi da me creati Before e After con cui viene decorato il metodo Save

   1: public class TaskModel
   2: {
   3:     readonly Storage _storage;
   4:     public TaskModel()
   5:     {
   6:         _storage = new Storage();
   7:     }
   8:     [Before("ActionsBeforeSave"), After("ActionsAfterSave")]
   9:     public void Save(Task task)
  10:     {
  11:         _storage.SaveOrUpdate(task);
  12:     }
  13:     public void ActionsBeforeSave()
  14:     {
  15:         //_storage.Connect();
  16:         Console.WriteLine("Action before save....");
  17:     }
  18:     public void ActionsAfterSave()
  19:     {
  20:         //_storage.Disconnect();
  21:         Console.WriteLine("Action after save....");
  22:     }
  23: }

Poi sulla classe Hook ho aggiunto un overload di Do che sfrutta l'uso dei gli attributi

   1: public class Hook
   2: {
   3:     public delegate void Action<A>(A a);
   4:  
   5:     public static void Do<A>(Action<A> action, A a)
   6:     {
   7:         Invoke(action, typeof(BeforeAttribute));
   8:         action(a);
   9:         Invoke(action, typeof(AfterAttribute));
  10:     }
  11:  
  12:     private static void Invoke(Delegate action, Type type)
  13:     {
  14:         object[] attributes = action.Method.GetCustomAttributes(type, true);
  15:         ActionAttribute attribute = (ActionAttribute)attributes[0];
  16:         MethodInfo method = action.Target.GetType().GetMethod(attribute.Action);
  17:         method.Invoke(action.Target, null);
  18:     }
  19: }

che poi nel viene usata così:

   1: Task task = new Task(1, DateTime.Today, "Demo task");
   2: IModel model = new TaskModel();
   3: Hook.Do(model.Save, task);

Per concludere l'utilizzo del metodo Do della classe Hook è un pò primitivo, andrebbe migliorato in modo che si possa invocare direttamente il metodo Save del model (come l'esempio all'iniziale) senza dove esplicitamente usare Hook.Do(...) . Non dovrebbe essere difficile, magari usando un Decorator, potrer migliorare anche questo aspetto, ma questo è un'altro post...

Technorati tags: , , ,

L'importanza delle persone nello sviluppo software

Stasera mentre leggevo un post sulla mailing-list extremeprogramming-it ho letto un passaggio che condivido pienamente e che quindi mi permetto di riportare qui:

.... per una società che si occupa di sviluppo software l'attività con il maggior ritorno economico è la selezione del personale e la crescita delle persone al suo interno, quindi su questo dovrebbero aversi i maggiori investimenti e a questo dovrebbero essere assegnate le persone più affidabili.
Là dove una fabbrica di automobili da per scontato un grosso investimento per acquisire la tecnologia e il macchinario necessari, una software-house deve dare per scontato un grosso sforzo ed esborso
nell'acquisizione delle persone.

In futuro sarà la prima frase che suggerirò a chi mi chiede consiglio su come cercare un nuovo membro per il proprio team di sviluppo.

Technorati tags:

Reflection & MbUnit

Oggi, facendo alcune prove suggerite da questo post di Antonio, ho notato che nell'assembly MbUnit.Framework.2.0 è disponibile la classe Reflector che serve per controllare lo stato di un oggetto tramite reflection in maniera molto semplice.

Per esempio:

[Test]
public void Ctor_Always_SetFieldName()
{
    Foo foo = new Foo("claudio");
    Assert.AreEqual("claudio", Reflector.GetField(foo, "_name"));
}

serve per controllare che il costruttore imposti correttamente il valore della variabile di classe che si chiama _name. Ovvero che Foo sia così:

public class Foo
{
    private readonly string _name;

    public Foo(string name)
    {
        _name = name;
    }
}

Anche se generalmente un test non controlla lo stato interno di un'oggetto ci sono scenari in cui una funzionalità di MbUnit può tornare sicuramente utile.

Nomi per i metodi di test

Solitamente quando scrivo un metodo di test cerco di dargli un nome che sia riassuntivo per il codice che sto andando a testare di modo che un domani quando ci ritornerò per qualsiasi motivo mi basterà leggerne il nome per capire che test viene eseguito al suo interno. Guardando in giro vedo che sul web più o meno questo è quello che fanno tutti gli "adepti" dello unit-test.

Quest'anno al TechEd, Roy Osherove ha suggerito questo pattern per dare un nome ai metodi di test:

        NomeMetodo_Condizione_Comportamento

visto che mi sembrava cosa buone e giusta, ho aggiornato il mio template di Resharper "test" così:

[Test]
public void $MethodName$_$Condition$_$Behaviour$()
{
    $END$
}

che applicato ad un caso reale diventa: la proprietà DataAvailable, se non ci sono files, deve essere falsa.

[Test]
public void DataAvailable_NoFilesAvailable_IsFalse()
{
    using (_mock.Record())
    {
        //some expectations here
    }
    using (_mock.Playback())
    {
        IModel model = new Model(_fileSystem);
        Assert.IsFalse(model.DataAvailable);
    }
}

Ho notato che anche alcuni colleghi hanno deciso di utilizzare lo stesso template. Spero che il suggerimento sia gradito anche ad altri.

Chat UGIALT.NET: 10 Dicembre 2007 ore 21.00

Dopo gli esperimenti realizzati l'inverno scorso e le positive discussioni che hanno seguito l'open space di quest'anno all'agileday  abbiamo deciso di dare il via ad una serie di chat "tecnologiche".

Dal sondaggio effettuato sulla lista risulta che la data preferita è 10 Dicembre. Quindi è confermato che ci troviamo online su GTalk alle 21.00 .

I temi che tratteremo saranno:

L'iniziativa è aperta a tutti, e tutti potranno parlare ed esprimere opinioni, consigli, esperienze, portare amici, ecc... quindi se qualcuno ha voglia di partecipare non deve far altro che contattarmi tramite il blog inviandomi il suo indirizzo GTalk.

Vi aspettiamo!

Technorati tags:

Roy Osherove: cantante al TechEd 2007

Sicuramente come cantante non avrà mai successo ma come speaker bisogna riconoscere che ci sa proprio fare!

Technorati tags: