makka

Gli {eroi} del semaforo

Claudio Maccari — Fri, 07 Mar 2008 11:31:55 GMT

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.

IronRuby news

Claudio Maccari — Thu, 21 Feb 2008 09:38:55 GMT

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: Ruby on Rails, IronRuby, Ruby

UgiAlt.net (mini)conference - 23 Febbraio 2008

Claudio Maccari — Sat, 12 Jan 2008 13:46:48 GMT

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: ugiatl.net

Callbacks hook come RubyOnRails in C#

Claudio Maccari — Sat, 05 Jan 2008 14:45:29 GMT

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: C#, callbacks, hooks, Ruby on Rails

L'importanza delle persone nello sviluppo software

Claudio Maccari — Mon, 10 Dec 2007 23:55:39 GMT

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: agile

Reflection & MbUnit

Claudio Maccari — Sun, 09 Dec 2007 13:26:59 GMT

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.

Technorati tags: TDD, test driven development, MbUnit

Nomi per i metodi di test

Claudio Maccari — Sun, 09 Dec 2007 13:04:12 GMT

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

Claudio Maccari — Mon, 03 Dec 2007 21:10:46 GMT

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:

cos'è ALT.NET
quali strumenti e quali metodologie usiamo
progetti del gruppo? (incontri veri a gennaio e progetto open source)

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: ugiatl.net

Roy Osherove: cantante al TechEd 2007

Claudio Maccari — Mon, 26 Nov 2007 20:22:55 GMT

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

Technorati tags: Tech Ed

User stories applied [cap.7] : altri suggerimenti

Claudio Maccari — Mon, 19 Nov 2007 20:13:11 GMT

Di seguito alcune linee guida addizionali per scrivere buone storie:

Per identificare le storie considerare lo scopo di ogni ruolo utente del sistema.
Quando si divide una storia cercare di avere storie che attraversano tutti gli strati dell'applicazione.
Scrivere storie di una dimensione tale per cui lo sviluppatore, dopo averla conclusa, si senta giustificato nel prendere un caffè.
Completare le storie con ogni tipo di documentazione ci sembra utile per comprendere meglio il dominio applicativo.
Creare storie anche per le costanti applicative, esporle in modo che siano sempre ben visibili e scrivere dei test che che ne controllano inviolabilità.
Scrivere storie piccole per le funzionalità che il team implementerà a breve e storie "di alto livello" per le funzionalità che verrano in futuro.
Evitare di inserire riferimenti all'interfaccia utente nelle storie.
Inserire un riferimento al ruolo utente all'interno di una storia se ne aumenta la chiarezza.
Scrivere storie per singoli utenti.
Far scrivere le storie al cliente invece che agli sviluppatori
Scrivere storie corte: il loro scopo e ricordare la conversazione in cui abbiamo parlato dei dettagli.
Non numerare le storie.

Technorati tags: user stories, agile