Programming Languages Hacks

Importanti regole per linguaggi di programmazione rilevanti come Java, C, C++, C#…

  • Subscribe

  • Lettori

    I miei lettori abituali

  • Twitter

Convert Event-Based Asynchronous to Task

Posted by Ricibald on 29th November 2015

Convert Event-Based Asynchronous to Task

The following example shows how to expose an arbitrary sequence of Event-Based Asynchronous Pattern (EAP) operations as one task by using a TaskCompletionSource<TResult>.

The example also shows how to use a CancellationToken to invoke the built-in cancellation methods.

When to use it:

  • you have a mix of Events and Tasks and you need to uniform them
  • you have an Event that needs to be treated using your already-done Task background processing
  • you have a complex flow of Events and you need to simplify the code readability

This extension method do the work:

public static class TaskExt
{
    public static async Task<TEventArgs> FromEvent<TEventArgs>(
        Action<EventHandler<TEventArgs>> registerEvent,
        Action action,
        Action<EventHandler<TEventArgs>> unregisterEvent,
        CancellationToken token)
    {
        var tcs = new TaskCompletionSource<TEventArgs>();
        EventHandler<TEventArgs> handler = (sender, args) => tcs.TrySetResult(args);
        registerEvent(handler);

        try 
        {
            using (token.Register(() => tcs.SetCanceled()))
            {
                action();
                return await tcs.Task;
            }
        }
        finally
        {
            unregisterEvent(handler);
        }   
    }
}

So if you have this class with this event:

public class LdapProvider {
    public event EventHandler<string> Authenticated;
    public void Authenticate(string username, string password) {
        // show the browser...
    }
    //... called back from the browser
    public void AuthenticateCallback(string token) {
        if(Autenticated != null)
            Authenticated(token);
    }
}

You can call this class using events in this way:

// save Token from ldapProvider when the event Autenticate fires
var ldapProvider = new LdapProvider();
ldapProvider.Authenticate("username", "password");
ldapProvider.Authenticated += (sender, token) => this.Token = ldapProvider.Token;
// wait for event be fired...

It can be converted in this way:

public static class LdapProviderExtensions {
    public static async Task<string> AuthenticateAsync(this LdapProvider ldapProvider, string username, string password) { 
        await TaskEx.FromEvent<string> (
            handler => ldapProvider.Authenticated += new EventHandler<string> (handler), 
            () => ldapProvider.Authenticate("username", "password"),
            handler => ldapProvider.Authenticated -= new EventHandler<string> (handler),
            CancellationToken.None);
    }
}


And used in this simple way:

// save Token from ldapProvider when the event Autenticate fires
var ldapProvider = new LdapProvider();
var token = await ldapProvider.AuthenticateAsync("username", "password");
// you have the token without saving it in a property...

Posted in .net | 1 Comment »

Quick Debug a Value (Chaining)

Posted by Ricibald on 24th January 2014

This code fails on method Pay:

Customer customer = repository.GetCustomer(id);
customer.GetOpenOrders().GetLatestOrderItem().Pay();

You have to debug the result value of the method GetOpenOrders. To accomplish this you have to add one row to split the statement:

Customer customer = repository.GetCustomer(id);
IEnumerable<Order> openOrders = customer.GetOpenOrders();   // BREAKPOINT HERE
openOrders.GetLatestOrderItem().Pay();

Having one more row we can now add a breakpoint on row 2. This approach requires to rewrite the statement.
Just adding this extension method we can now debug every value:

[System.Diagnostics.DebuggerStepThrough]
public static T Break<T>(this T t) {
    Debugger.Break();
    return t;
}

Just use in this way:

Customer customer = repository.GetCustomer(id);
customer.GetOpenOrders().Break().GetLatestOrderItem().Pay();

No new rows, just chaining :-)!!

Posted in .net | No Comments »

Automapper: Ignore All Not Mapped Properties

Posted by Ricibald on 19th July 2013

Normally in automapper you’ll write something like this:

Mapper.CreateMap<MoveEntity, MoveEntityDto>()
       .ForMember(dest => dest.PrimaryOriginTransferee, opt => opt.Ignore())
       .ForMember(dest => dest.PrimaryDestinationTransferee, opt => opt.Ignore())
       .ForMember(dest => dest.Customer, opt => opt.Ignore())
       .ForMember(dest => dest.DestinationAddress, opt => opt.Ignore())
       .ForMember(dest => dest.OriginAddress, opt => opt.Ignore())
       .ForMember(dest => dest.Order, opt => opt.Ignore())
       .ForMember(dest => dest.Shipment, opt => opt.Ignore())
       .ForMember(dest => dest.SourceSystemName, opt => opt.Ignore());

To ignore all not-mapped properties just use this extension method:

Mapper.CreateMap<MoveEntity, MoveEntityDto>()
       .IgnoreAllNonExisting();

Here the source code:

    public static IMappingExpression<TSource, TDestination> IgnoreAllNonExisting<TSource, TDestination>(this IMappingExpression<TSource, TDestination> expression)
    {
        var sourceType = typeof(TSource);
        var destinationType = typeof(TDestination);
        var existingMaps = Mapper.GetAllTypeMaps().First(x => x.SourceType.Equals(sourceType) && x.DestinationType.Equals(destinationType));
        foreach (var property in existingMaps.GetUnmappedPropertyNames())
        {
            expression.ForMember(property, opt => opt.Ignore());
        }
        return expression;
    }

Posted in .net | 2 Comments »

Riuso o Automazione – come ottenere un riuso al 100% personalizzabile

Posted by Ricibald on 26th June 2013

Riuso con libertà assoluta di customizzazione… Connubio possibile?

Ricordiamo la metafora per i design pattern:

a * b + a * d = a * (b + d)

Significa che l’essenza dei design pattern e della buona programmazione sta nel riuso: più si riesce a centralizzare maggiore è la consistenza e l’efficienza che si ottiene.
L’efficienza è ovvia: centralizzando riusciamo a non riscrivere codice e quindi a ottimizzare il nostro lavoro. Centralizzare significa ottenere consistenza: se check di errori o log esiste nel metodo centralizzato, sarà propagata ovunque tra i chiamanti.

Esistono però ambiti dove il riuso è necessario ma molto arduo a causa delle esigenze specifiche del contesto. Un esempio tipico sono le UI (User Interface).

Immaginiamo un modello complesso da visualizzare, con 100 proprietà di tipi diversi. Nella visualizzazione o edit del modello dobbiamo visualizzare o modificare in modo consistente tutte le proprietà per conferire un look & feel autorevole. D’altra parte la visualizzazione non può nemmeno essere troppo rigida poiché si perderebbe quella flessibilità per visualizzare o modificare in modo speciale particolari proprietà. Il discorso potrebbe non essere limitato alle singole proprietà ma anche al layout stesso: potrebbe richiedere raggruppamenti speciali opzionalmente collassabili, funzionalità di drag & drop, autocompletamento, dialog ajax, popup di conferma, validazione ajax, …

Come ottenere il riuso con la giusta flessibilità?

Ci sono diverse possibilità in questo caso per ottenere il riuso con la flessibilità desiderata:

  • copia e incolla: più che di riuso si parla di “riciclo”. È una soluzione svantaggiosa? Da moltissimi punti di vista sì, ma la replicazione del codice ha anche vantaggi come la diminuzione del rischio globale (se fallisce una libreria base non fallisce tutto) e libertà assoluta di customizzazione. Ovviamente avremo bassissima consistenza ed efficienza
  • micro funzionalità fornite tramite helper: che siano classi di check, design pattern complessi, risorse (css/js), user control, html helper, aspetti, interceptor o extension method tali componenti di appoggio consentono di scrivere codice di più alto livello disinteressandoci di dettagli tecnici come log, caching, verifica errori, generazione html, transazionalità, undo metodi, … Passando opportuni parametri o implementazioni specifiche (Pattern Strategy) possiamo personalizzarne il comportamento (es. se loggare o meno) rendendole scelte comunque flessibili. Normalmente agiscono però a un basso livello: l’orchestrazione dobbiamo sempre implementarla
  • intera funzionalità autogenerata: ci troviamo nel caso più estremo, rendendo il tutto molto più consistente ma anche molto più rigido. Utilizzando metadati (da file, attributi, reflection, convenzioni, codice tramite model specializzati…) o generando codice che abilita il pattern Template Method (es. partial method) possiamo avere dei gradi di customizzazione sulle singole micro funzionalità e sull’orchestrazione stessa. Questa tecnica funziona bene e ha differenti gradi di libertà ma richiede lo sforzo di costruire un framework la cui definizione di metadati potrebbe essere non banale per ottenere il comportamento “ipotizzato” (il risultato finale potrebbe essere difficile da prevedere e non immediato). Infine, la generazione ha comunque un costo computazionale a ogni pagina generata da valutare.
  • intera funzionalità pregenerata: sembra lo stesso caso precedente, in realtà è una generazione su file che sfrutta internamente gli helper. È come se avessimo scritto noi il codice “a mano” ma in realtà è stato generato su file basandosi su metadati. Lo scopo è quello di ricondursi al secondo caso nella lista, in cui costruiamo ogni micro funzionalità tramite helper, ma risparmiando l’onere di riscrivere l’intera orchestrazione. Questo consente che l’orchestrazione sia liberamente editabile: non si otterrà la consistenza nell’orchestrazione (le modifiche in un flusso condiviso devono essere propagate a mano) ma si guadagna in efficienza. Inoltre non inficia in tempi di calcolo. Le tecniche possono essere applicazioni standalone o integrate nell’IDE come i Text Template (T4) che consentono di definire MVC Template.
  • intera funzionalità pregenerata solo su richiesta, altrimenti autogenerata: è un ibrido tra le due. Di base viene autogenerata la funzionalità magari ottimizzandone i tempi tramite un precaching e solo in caso di esigenze particolari di customizzazione si richiede esplicitamente di creare la funzionalità pregenerata su file su cui si avrà completa libertà di azione, ma partendo da uno scheletro già completamente funzionante. Un ottimo esempio in questo senso è ASP.NET Dynamic Data

Il concetto in questo post è stato generalizzato (guarda caso…) ma si può leggere “funzionalità” come “proprietà da visualizzare in input (html)” e “orchestrazione” come “layout della pagina web”: i principi si applicano quindi tranquillamente anche in un contesto web.

Non esiste solo il riuso classico…

Questo post voleva evidenziare i diversi livelli per generalizzare e abilitare il riuso: spesso ci si basa solo sulla seconda soluzione vedendo il riuso solo come la costruzione di componenti e l’utilizzo sapiente di design pattern. In realtà esiste un livello spesso non esplorato: quello della generazione automatica del codice, che elimina gran parte del lavoro pur conservando una libertà assoluta di customizzazione (come nell’ultimo caso).

Arrivare alla generazione automatica del codice ha un costo e non è detto che paghi sempre. Questi i contesti dove secondo me la generazione automatica paga:

  • UI che gestiscono varie entità in modo per lo più omogeneo
  • workflow che gestiscono varie entità in modo per lo più omogeneo
  • mapping tra entità (invece di utilizzare automapper)
  • codice collante strutturale (flusso application-domain-repository per una certa entity)
  • unit test che seguono un certo standard e certi input limite noti
  • entità e metodi derivati da sorgenti esterne (database, wsdl, xsd, api REST)
  • documentazione dei metodi per soddisfare determinati standard
  • refactoring complessi automatizzabili

Altri casi sono facilmente individuabili: ogni qualvolta ci troviamo a lavorare “come macchine” dovremmo far fare il lavoro “alle macchine” per lasciare a noi i lavori più interessanti.

Buon riuso! Anzi, buon riuso+automazione…!

Posted in pattern | No Comments »

Evoluzione dei test – Debugger, TDD, BDD, LINQPad

Posted by Ricibald on 24th June 2013

Uno strumento fondamentale per sviluppare in .NET si sta sempre più rilevando LINQPad.

Nonostante sia nato per analizzare le query prodotte da LINQ, di fatto lo strumento è molto di più: consente infatti di testare al volo porzioni di codice .NET.

Facciamo subito un esempio pratico. Immaginiamo di avere un codice 3-layer con diversi componenti remoti che interagiscono tra di loro mediante protocolli più o meno complessi. Uno di questi componenti deve validare l’indirizzo mail che arriva in input da uno degli altri componenti. Il codice che validerà la mail è il seguente:

Regex.Match(emailAddress, @"^([\w\.\-]+)@([\w\-]+)((\.(\w){2,3})+)$");

Immaginiamo di voler testare questo codice. Come faresti?

Come verifichiamo il nostro codice? Vecchio stile…

In uno sviluppo classico (errato) si procede in questo modo:

  1. si scrive il codice fino a ottenere l’elaborato finale
  2. si testa il codice facendo girare tutti i vari componenti e incrociando le dita… se va tutto bene, bene… sennò si collega il debugger di VS e si passa per giorni e giorni di debugging…

Questo approccio ha tanti limiti tra cui: dipendenza da componenti esterni, tempi tecnici lunghi, non ripetibilità automatica del test.

In uno sviluppo più evoluto (TDD) si farebbe uso di unit test come segue:

  1. si scrive prima il metodo di test che verifica che a fronte di mail corrette non abbiamo errori e che viceversa a fronte di mail errate avremo eccezioni
    • il test dovrà essere isolato e atomico iniettando mock o, meglio, stub
  2. si scrive il minimo codice possibile per far compilare il codice
  3. si esegue il test, che deve fallire (il comportamento non è ancora implementato)
  4. si scrive l’implementazione vera e propria del test
  5. si riesegue il test, che stavolta dovrà andare bene

Questo approccio corregge i limiti sopra esposti consentendo una ripetibilità dei test e un isolamento dei componenti.

Gli unit test sono la risposta allora… Quale è il problema?

Gli unit test sono il modo di procedere corretto ma richiede una competenza di alto livello:

  • bisogna conoscere framework di dependency injection, unit test, mocking
  • bisogna conoscere bene i confini di un test: non bisogna testare né troppo né poco
  • gli input dei test devono essere significativi per verificare i “casi limite”
  • richiedono molto rigore: a ogni bug rilevato bisognerebbe creare il test corrispondente e fixarlo
  • bisogna saper isolare molto bene i test e rifattorizzarli nei punti variabili per evitare che una modifica nel codice comporti una modifica a cascata di tutti i test collegati

Oltre alle competenze richieste, i test di fatto aumentano comunque il lavoro complessivo:

  • bisogna scrivere test e mock per tutti gli input significativi
  • bisogna rifattorizzare i test e mantenerli nel tempo a fronte di cambiamenti anche strutturali

Non sto dicendo non bisogna fare unit test, anzi. Il problema è che una competenza simile è difficile trovarla ed è complicato trovare un progetto con un contesto culturale favorevole a un approccio di questo tipo.

Gli unit test sono troppo complessi…? Allora testiamo solo gli use case…

Allora era giusto il precedente approccio? Torniamo al debbugger con VS? Non credo sia corretto tornare nella propria zona di comfort, l’ideale sarebbe crearsi la competenza per perseguire gli unit test “puri”. Ma una via di mezzo potrebbe comunque esistere.

Si può semplificare e non scrivere 100 test in isolamento arrivando a una copertura del 100% del codice testato, bensì scrivere solo test “integrati” che vadano a verificare end-to-end il comportamento del codice integrato. Questo assomiglia più al BDD (Behavior-driven development) e presenta i seguenti vantaggi:

  • si verificano le porzioni di codice che effettivamente verranno eseguite nei vari casi d’uso
  • non richiede un’infrastruttura di stub/mock: si possono anche non conoscere framework di dependency injection e mocking

Il problema è che comunque i test devono essere atomici: l’esito non deve essere influenzato da altri test. Significa che siamo costretti a creare nel db e/o componenti dipendenti tutte le precondizioni che servono per avere una situazione “pulita” da testare.

Il BDD è ottimo per avere test che verifichino il giro completo del codice in modo ripetibile e quindi automatizzabile. Ma il BDD non è efficace per il nostro semplice caso di test di esempio. Se vogliamo solo testare se l’espressione regolare è valida per un’indirizzo email dovremmo porci in troppe precondizioni per poi fare semplici asserzioni.

 Gli use case sono troppo complessi…? Compilo ed eseguo al volo…

Un approccio estremamente più semplice e immediato per verificare il codice potrebbe essere quello di crearsi una Console Application, copiare/incollare il codice e testare il codice dentro la console.

Questo ha però dei tempi tecnici necessari come creare la solution, compilare e andare in debug. Questo comporta una risposta psicologica negativa: il test si fa solo quando serve veramente. Il vantaggio ci sarebbe ma per esperienza, nonostante sia il modo più immediato, nessuno lo fa: ci sarà o no un motivo…?

Un test al volo è troppo macchinoso…? Viene in aiuto LINQPad!

Siamo finalmente arrivati al nostro incredibile “silver bullet”. LINQPad, oltre a verificare le query LINQ generate, consente di ispezionare il risultato di un qualunque snippet di codice .NET compilandolo “al volo” tramite CSharpCodeProvider.

Lo screenshot seguente mostra, nello scenario di test presentato all’inizio, un test “al volo” della validazione della mail in questione:

Expression

Abbiamo quindi “cablato” il test verificando che con email “test@gmail.com” il metodo Regex.Match restituisce Success == true. Possiamo inoltre navigare il risultato: ad esempio possiamo ispezionare la collezione Groups, ottenendo i relativi gruppi in modo molto semplice:
Navigate

Volendo potremmo immergere il test in più input significativi creando una piccola procedura come segue:
Program

Se il codice che stiamo copiando o incollando fa uso di librerie esterne (create da noi o scaricate) possiamo includerle in modo da farle riconoscere dal compilatore.

Nell’esempio precedente si nota l’extension method Dump che consente di mostrare a video il contenuto di una qualunque struttura consentone una semplice navigazione tra strutture complesse. Prendiamo come esempio un Dictionary… in LINQPad tramite Dump lo visualizzereste in questo modo, direi piuttosto comodo, no…??
Dictionary

Uso di LINQPad

LINQPad si presta benissimo ai seguenti usi:

  • test al volo di nostro codice copiato/incollato da VS
  • test al volo di API .NET come LINQ, PLINQ, RX, …
  • test degli stati intermedi del chaining (qui un approfondimento)
  • apprendimento tramite esperimenti di librerie del framework .NET o di terze parti scaricate tramite NuGet
  • ispezione e navigazione di strutture e relazioni
  • navigazione del database senza passare per continue JOIN
  • analisi del database da un più alto livello di astrazione
    • grazie a ORM supportati come EF
    • grazie a provider supportati come MSCRM, Sharepoint, Azure, DataMarket, OData, StreamInsight, …
  • utility di uso comune tramite extension method (qui alcuni extension method di terze parti)
    • query LINQ che generano file CSV
    • query LINQ che generano SQL complessi da inviare via mail

Prossimi passi…??

Questi i prossimi passi per guadagnare la cintura marrone in LINQPad:

  1. Scarica LINQPad
  2. Scrivi il tuo codice normalmente in Visual Studio
  3. Appena terminato un metodo, anche semplice, copialo in LINQPad
    1. Se il tuo metodo fa uso di strutture esterne copiale direttamente o, se troppe, includi la dll
  4. Esegui su un input di esempio e ispeziona tramite Dump che tutto sia ok
    1. Se necessario verifica anche i tempi di esecuzione riportati
    2. Se necessario salva il codice per un futuro uso nella cartella “My Queries
  5. Rendila un’abitudine nel tuo lavoro quotidiano

Se veramente diventa un’abitudine eviterai il 90% degli errori, abbattendo ore noiose e degradanti di debugging…

Questi i passi invece per guadagnare la cintura nera in LINQPad:

  1. nella posizione dove di solito apri SQL Server Management Studio, rimpiazzalo con LINQPad
  2. apri sempre LINQPad al suo posto e fai le query solo utilizzando LINQ
  3. dopo un periodo di iniziale lentezza rispetto a SSMS scoprine i vantaggi
  4. non eseguire più join… limitati a seguire i link
  5. non ripetere più le stesse query… crea extension method riusabili
  6. non ipotizzare le query LINQ prodotte… verifica il SQL e prendine consapevolezza

Sperimenta nuove API con LINQPad. Pronti per lo step??

Posted in .net, test | No Comments »

Ninject: Replace without unbind

Posted by Ricibald on 10th August 2012

In Ninject the method Rebind<T> does the following:

  • Unbind<T>: removes all binding for that types, also named binding!
  • Bind<T>: add the specified binding

This means that using Rebind<T>().To<U>().Named(“X”) you are not just replacing the binding named “X” but you are clearing all existing binding registered with T!

If you want to just replace it just use this:

Bind<T>().To<U>.Named("X").ReplaceExisting();

 

Here the source code to achieve this (works in Ninject 2+):
 

using System.Linq;
using Ninject.Planning.Bindings;
using Ninject.Syntax;

// ReSharper disable CheckNamespace
namespace System
// ReSharper restore CheckNamespace
{
    public static class ExtensionsNinject
    {
        /// <summary>
        /// Replace existing binding.
        /// To replace a binding you should never use rebind becauses unbind all existing
        /// binds and then bind yours.
        /// You should first configure the entire binding using Bind and only as last 
        /// operation you should declare to replace it using this method.
        /// </summary>
        public static void ReplaceExisting<T>(this IBindingInSyntax<T> bindingInSyntax)
        {
            ReplaceExistingImpl<T>(bindingInSyntax);
        }

        /// <summary>
        /// Replace existing binding.
        /// To replace a binding you should never use rebind becauses unbind all existing
        /// binds and then bind yours.
        /// You should first configure the entire binding using Bind and only as last 
        /// operation you should declare to replace it using this method.
        /// </summary>
        public static void ReplaceExisting<T>(this IBindingOnSyntax<T> bindingInSyntax)
        {
            ReplaceExistingImpl<T>(bindingInSyntax);
        }

        /// <summary>
        /// Replace existing binding.
        /// To replace a binding you should never use rebind becauses unbind all existing
        /// binds and then bind yours.
        /// You should first configure the entire binding using Bind and only as last 
        /// operation you should declare to replace it using this method.
        /// </summary>
        public static void ReplaceExisting<T>(this IBindingWhenSyntax<T> bindingInSyntax)
        {
            ReplaceExistingImpl<T>(bindingInSyntax);
        }

        private static void ReplaceExistingImpl<T>(IBindingSyntax bindingInSyntax)
        {
            var kernel = bindingInSyntax.Kernel;
            var bindingsToRemove = kernel.GetBindings(typeof(T)).Where(b => string.Equals(b.Metadata.Name, bindingInSyntax.BindingConfiguration.Metadata.Name, StringComparison.Ordinal));
            foreach (var bindingToRemove in bindingsToRemove)
            {
                kernel.RemoveBinding(bindingToRemove);
            }
            
            var binding = new Binding(typeof(T), bindingInSyntax.BindingConfiguration);
            kernel.AddBinding(binding);
        }
    }
}

Posted in ninject | No Comments »