Programación SOLIDa

Horas en la oficina vs ideas y conocimiento aportado (by Javier Garzás)

2016-12-15T15:16:00.001-03:00

En esta oportunidad, quería compartirles un post que he leido y con el que estoy plenamente de acuerdo:

“Mi padre, Burt Scott, que trabajó para Henry Ford durante muchos años, me contó una historia acerca de aquel encuentro. En la planta de Ford situada en River Rouge tenían problemas técnicos con un nuevo generador de gran tamaño.
Los ingenieros eléctricos de la factoría eran incapaces de encontrar dónde se hallaba el problema, por lo que Henry Ford solicitó la ayuda de Setinmetz [nota de jgarzas: que fue un grandísimo genio, de esos hoy tan desconocidos]. Cuando el “pequeño gigante” [nota de jgarzas: sufría de enanismo] llegó a la fábrica, se negó a recibir cualquier tipo de ayuda, sólo solicitó una libreta, un lapicero y un camastro.

Durante dos interminables días, y noches, Steinmetz se dedicó a escuchar el sonido del generador y a realizar incontables cálculos.
Entonces, pidió una escalera, cinta métrica y una tiza. Subió con esfuerzo a lo alto del generador y midió con sumo cuidado, colocando una precisa marca de tiza en una parte de la enorme máquina.
Hecho esto, descendió por la escalera y comentó a los escépticos presentes que era necesario desmontar una placa del lateral del generador y eliminar 16 vueltas de la bobina a partir del punto en que había realizado la marca de tiza.
Los ingenieros introdujeron más tarde las correcciones sugeridas por Steinmetz y el generador comenzó a partir de entonces a funcionar perfectamente.
Al poco le llegó a Ford una factura por 10.000 dólares firmada por Steinmetz desde General Electric. Ford devolvió la factura, agradeciendo el buen trabajo realizado por Steinmetz, pero solicitando respetuosamente una factura detallada. Steinmetz respondió enviando de nuevo la factura a Ford con el siguiente detalle:
Marca de tiza en el generador: 1 dólar [trabajo físico, nota de jgarzas].
Saber dónde hacer la marca: 9.999 dólares [idea y conocimiento, nota de jgarzas]
Total a pagar: 10.000 dólares”
—
La anterior historia se puede encontrar en multitud de fuentes por la Web, desconozco la fuente original (si alguien la conoce que me la pase y la cito como fuente).
En la era del conocimiento, seguir valorando el trabajo de un profesional en función de las horas que pasa sentado en la oficina, es otra de esas malas prácticas que nos ha tocado, y tocará, vivir durante muchos años, demasiados. Otra herencia envenenada que nos deja la era industrial.
En los trabajos industriales, en los trabajos de obrero, en las cadenas de montaje, en las construcciones de carreteras, puentes, etc., es hasta cierto punto lógico pensar que a “más horas de trabajo más avance del proyecto”. Pero en los trabajos del conocimiento (como por ejemplo es el desarrollo software) ¿de verdad crees que horas equivale a trabajo?
Llevo muchos años viendo y sufriendo esta extraña manera de valorar el trabajo basado en el conocimiento, sólo por horas.
Ya desde mis primeros años, cuando trabajaba para una consultora grande en modo “body shopping”, si había algo que te hacían aprender rápido era que el mejor, el “más comprometido” le decían, era el que salía más tarde.
Daba igual que estuvieras 12 horas pensando en como organizar la fiesta del próximo fin de semana, lo importante no era tanto tu mente… era tu cuerpo sentado en una silla.
Posteriormente, incluso he visto muchos lugares que continuaban esa idea instalando sistemas de fichar que contaban las horas desde que entrabas hasta que salías (aunque mucha gente pasase la mitad de esas horas charlando frene a la máquina de café que había dentro de la oficina). Como si por tener a alguien más horas dentro de una oficina fuese a tener más ideas.
En los trabajos del conocimiento una buena idea que se explica en 5 min. puede ahorrar a una empresa, o aun equipo, meses o años, 5 min. pueden hacer ganar muchos proyectos.
Y las buenas ideas, la elaboración de muy buenos trabajos intelectuales, no sale sólo con horas… sale del conocimiento y la motivación.
Es algo que se nos ha inculcado desde nuestra educación, esfuerzo = horas sentado = éxito. Clavar los codos. Que sin esfuerzo no hay éxito es una realidad, que el esfuerzo no garantiza el éxito es otra, que el esfuerzo no es solo estar en la oficina es otra, esfuerzo también es estrujarse el cerebro en el coche, paseando, hasta por las noches.
Aún hoy yo intento quitarme esas ideas tradicionales industriales de la cabeza, en ocasiones sin éxito. Sé que muchas veces dando un paseo podría generar ideas geniales pero hay alguna neurona por ahí llamada remordimiento de conciencia que tiene grabado a fuego que pasear = no horas sentado = no estás trabajando.
Y lo peor, es que en gran parte del mundo tecnológico no se toma en serio que las ideas que se generan muchas veces fuera de la oficina, momentos que para mí, paradójicamente, son los más me han generado grandes ideas.
Aún hoy me encuentro proyectos que solo valoran “las horas” que ven a alguien trabajando, a los que parece importarles nada el conocimiento que acumulado durante años y que se puede aportar en 30 min., conocimiento que supone años. Parece importar poco que pienses en el proyecto cuando vas en el coche, te duchas o te lavas los dientes. Importan las horas en la oficina.
Sé que el mundo aún no está preparado para valorar el trabajo de otra manera, valorar el rendimiento según la motivación, el conocimiento aportado, las ideas generadas, la felicidad aportada, la garra, la valentía para sacar algo a toda costa, la entrega, etc.
Sé que ni siquiera los negocios y modelos de facturación en los trabajos del conocimiento están preparados para ello, la mayoría de los proyectos se facturan “por horas”.
Pero déjame que me atreva a decir que los próximos años aquellas empresas que aprendan a gestionar el rendimiento como “conocimiento aportado”, más allá de “horas sentado”, abrirán una brecha sin igual con las tradicionales, las que gestionan ideas de manera similar a la gestión del trabajo en una cadena de montaje de coches.
Yo espero rodearme de las primeras.
Llegado lo cual, ojo, ello no sería el paraíso, sería un cambio de modelo, en vez de valorar las horas se valoraría el conocimiento y las ideas aportadas, más horas y no buen trabajo intelectual sería un trabajo mal realizado. Pocas horas de trabajo y ningún aporte sería un muy mal trabajo.
Para terminar, permíteme que te diga que si estás pensando que lo ideal es gente trabajando 12 horas, soltando ideas y mucho conocimiento cada hora… es que no has entendido este post.
—
“Puedo decirle a un obrero que a las 7 de la mañana sea productivo. Pero ¿puedo decirle a un ingeniero que tenga una buena idea a las 7 de la mañana?” Akio Morita (fundador de Sony)
“Contar el rendimiento de un profesional del conocimiento en base a las horas que pasa sentado en una silla tiene el mismo sentido que contar el avance de un proyecto software en función del número de líneas de código, ninguno.” Yo

Fuente: http://www.javiergarzas.com/2014/03/horas-vs-conocimiento.html

Switch para un enum vs Func delegate

2015-12-01T20:00:00.000-03:00

La relación entre los enum y la cláusula switch es una de las más comunes. Tanto es así que muchas veces cuesta pensar en separarlos para encarar otra manera de usar un enum como diferenciador de categorías.

Pues bueno, la intención de este post es, al menos para este ejemplo de situación, romper con esta relación y apuntar a un diseño más orientado a objetos y menos al viejo desarrollo estructurado.

Nota: Antes que nada, deseo aclarar que el ejemplo que deseo plantear, quizás resulte algo largo pero quiero dejar plasmado como puede ir evolucionando el comportamiento de una clase según los requerimientos van evolucionando. Espero sepan disculpar la monotonía en pro de una explicación más clara.

Manos a la obra

Supongamos que se posee una clase simple que devuelve distintas carpetas:


public sealed class Folder
{
    private const string APP = "MyApp";
    private const string COMPANY = "MyCompany";
    private const string LOGS = "logs";

    public string GetLogFolder()
    {
        return LOGS;
    }

    public string GetApplicationFolder()
    {
        return APP;
    }

    public string GetCompanyFolder()
    {
        return COMPANY;
    }
}

Ahora se requiere que antes de retornar la ruta solicitada se agregue un control para validar que la ruta a retornar exista. Es decir, que si la ruta a devolver no existe, se la cree.

Un primer intento podría ser agregar a todos los métodos el control mencionado, pero nos causaría una repetición de código innecesaria. Para evitar eso, crearemos un enum que nos permita saber qué carpeta se nos solicita.


public enum FolderType
{
    Company,
    Application,
    Log
}

public sealed class Folder
{
    private const string APP = "MyApp";
    private const string COMPANY = "MyCompany";
    private const string LOGS = "logs";

    public Folder()
    {
    }

    public string GetFolder(FolderType folderType)
    {
        var folder = string.Empty;

        switch (folderType)
        {
            case FolderType.Company:
                folder = this.GetCompanyFolder();
                break;
            case FolderType.Application:
                folder = this.GetApplicationFolder();
                break;
            case FolderType.Log:
                folder = this.GetLogFolder();
                break;
        }

        if (!System.IO.Directory.Exists(folder))
            System.IO.Directory.CreateDirectory(folder);

        return folder;
    }

    private string GetLogFolder()
    {
        return LOGS;
    }

    private string GetApplicationFolder()
    {
        return APP;
    }

    private string GetCompanyFolder()
    {
        return COMPANY;
    }
}

Como se puede apreciar en este nuevo ejemplo, ahora agregamos un nuevo método que recibe como argumento un enum (el tipo de carpeta que deseamos obtener) y en base a este enum, tomamos la decisión que método ejecutar para obtener la carpeta solicitada para luego controlar que exista (y crearla en caso de inexistencia) para finalmente devolverla. Y además, se cambió el scope de las funciones para que ya no puedan ser llamadas individualmente.

Pues bien. Hemos llegado finalmente al motivo de este post: cómo reemplazar este switch y ejecutar el método que se desea:


public enum FolderType
{
    Company,
    Application,
    Log
}

public sealed class Folder
{
    private const string APP = "HSLifeSynchro";
    private const string COMPANY = "Hasar Sistemas";
    private const string LOGS = "logs";

    private Dictionary> functions = new Dictionary>();

    private Folder()
    {
        this.functions.Add(FolderType.Application, this.GetApplicationFolder);
        this.functions.Add(FolderType.Company, this.GetCompanyFolder);
        this.functions.Add(FolderType.Log, this.GetLogFolder);
    }

    public string Get(FolderType folderType)
    {
     // Se remplazó el switch por la ejecución del método correcto vía Dictionary.
        var directory = this.functions[folderType]();

        if (!Directory.Exists(directory))
            Directory.CreateDirectory(directory);

        return directory;
    }

    private string GetLogFolder()
    {
        return LOGS;
    }

    private string GetApplicationFolder()
    {
        return APP;
    }

    private string GetCompanyFolder()
    {
        return COMPANY;
    }
}

Para resolver este reemplazo, nos vamos a valer de un diccionario que utiliza como clave los tipos declarados en el enum y como elemento, en este caso, un Func<string> (una función que retorna string y no recibe parámetros como es nuestro caso. Aunque se podría utilizar otras firmas de métodos, cabe aclarar que todas las funciones deben cumplir como requerimiento con la misma firma entre ellas: retorno, cantidad y tipos de argumentos).

En el constructor de la clase Folder agregamos los tres elementos posibles al diccionario. De esta manera queda declarada implícitamente la decisión a ser tomada: qué método debe ejecutarse según el tipo de carpeta solicitado. Una mejor aproximación sería recibir esta lista como argumento del constructor y no crearla para cumplir con IoC y el principio de Single Responsability, pero como ya hice largo el ejemplo, no quería complicarlo aun más.

En el método Get (el que contenía al switch) ahora simplemente ejecuta una línea antes del control de existencia del directorio solicitado.

Como se puede ver, ahora el código ha quedado mucho más limpio, mejorada la orientación a objetos y sin código repetido.

Espero que les resulte útil.

Código repetido? Func<T> al rescate

2014-11-11T16:59:00.000-03:00

Un problema muy común que nos podemos llegar a topar al desarrollar, es encontrarnos con métodos sumamente parecidos. En ellos podemos notar que su comportamiento son muy similares y que podrían diferenciarse por muy poco.

Paar graficar un poco mejor las cosas, imaginemos un caso muy sencillo en el tenemos un Wrapper de un WebService:


namespace EjemploSimple
{
 public class WrapperMyWebService
 {
  private MyWebService webService;

  public WrapperMyWebService(MyWebService webService)
  {
   this.webService = webService;
  }

  public string GetWebServiceStatus()
  {
   return this.webService.GetStatus();
  }

  public string GetSomeValue( int key )
  {
   return this.webService.GetSomeValue( key );
  }
 }
}

Hasta aquí, la clase tiene dos métodos con comportamientos diferentes. Cada uno posee una única línea de código que se encarga de llamar a métodos diferentes del objeto al cual envuelven. Pero qué sucede si se le cambia el comportamiento a ambos métodos:


namespace EjemploSimple
{
 public class WrapperMyWebService
 {
  private MyWebService webService;

  public WrapperMyWebService(MyWebService webService)
  {
   this.webService = webService;
  }

  public string GetWebServiceStatus()
  {
   string ret = "";
   try
   {
    ret = this.webService.GetStatus();   
   }
   catch( Exception e )
   {
    ret = string.Concat( "ERROR: ",  e.Message );
   }

   return ret;
  }

  public string GetSomeValue( int key )
  {
   string ret = "";
   try
   {
    ret = this.webService.GetSomeValue( key );   
   }
   catch( Exception e )
   {
    ret = string.Concat( "ERROR: ",  e.Message );
   }

   return ret;
  }
 }
}

En esta nueva versión de la clase, podemos notar que ahora la mayor parte del código está repetido. En ambos casos se desea atrapar una excepción y en ambos casos se desea devolver el mensaje de error. Imaginemos ahora que debemos agregar más métodos con el mismo comportamiento y que luego, ese mismo comportamiento quiere ser modificado para todos los métodos. Se debe escribir esa modificación tantas veces como métodos con el mismo comportamiento hubiera.

Aquí es donde viene en nuestra ayuda "Generics". Generics posee varias herramientas. Una de ellas se puede aplicar para solucionar este problema: Func<T>.

Primero y principal, debemos determinar la lógica repetida:


  public string MethodName()
  {
   string ret = "";
   try
   {
    //Invoke Web Service method.
   }
   catch( Exception e )
   {
    ret = string.Concat( "ERROR: ",  e.Message );
   }

   return ret;
  }

Como podemos apreciar, sólo la invocación al método del web service es lo que diferencia a ambos métodos. Func<T> nos permite poder pasar como argumento a otro método un "puntero" a una función para que se invocada. Para nuestro ejemplo, el método genérico quedaría así:


namespace EjemploSimple
{
 public class WrapperMyWebService
 {
  private MyWebService webService;

  public WrapperMyWebService(MyWebService webService)
  {
   this.webService = webService;
  }

  public string GetWebServiceStatus()
  {
   return this.GenericGetter( () => this.webService.GetStatus() );
  }

  public string GetSomeValue( int key )
  {
   return this.GenericGetter( () => this.webService.GetSomeValue( key ) );
  }

  public string GenericGetter( Func<T> fetch )
  {
   string ret = "";
   try
   {
    ret = fetch;
   }
   catch( Exception e )
   {
    ret = string.Concat( "ERROR: ",  e.Message );
   }

   return ret;
  }
 }
}

En este último ejemplo, podemos notar que el método que poseía el comportamiento repetido queda escrito una sola vez y los métodos que tenían dicho comportamiento, pasan a ejecutar esta nueva función pasándole como argumento el puntero a la función del Web Service que se desea invocar.

Simple Injector: Framework para IoC

2014-02-04T09:00:00.000-03:00

Hace ya un tiempo habíamos visto en otro post de este blog un framework para realizar Inversion of Control o Dependency inversion principle (soliD), En aquella oportunidad vimos Autofac. Si bien es un framework muy bueno, lamentablemente no funciona al 100% en Mono.

Simple injector nos trae esa solución sin perder lo bueno que ya teníamos con el framework anterior. Además de Mono, soporta las plataformas: MVC 4.0 y superior, Silverlight 4.0 y superior, Windows phone 8 y Windows phone application.

Podemos descargarlo por NuGet y es muy simple de usar. Provee una fácil implementación con características cuidadosamente escogidas dentro de la librería. Sólo se requiere que la configuración de la librería se ejecute al inicio de la aplicación. Inclusive, a partir de la versión 2 se incluye la habilidad de advertir pérdidas de configuración mientras se ejecuta la aplicación en modo debug.

La idea general detrás de Simple Injector (o de la Inversión de Control en general) es que el diseño de la aplicación tengan un nivel bajo de acoplamiento entre sus componentes utilizando, como ya dijimos, el patrón de inversión de dependencias. Tomemos como ejemplo la siguiente clase, UserController, en el contexto de una aplicación ASP.Net MVC.


public class UserController : Controller {
    private readonly IUserRepository repository;
    private readonly ILogger logger;

    // Use constructor injection for the dependencies
    public UserController(IUserRepository repository, ILogger logger) {
        this.repository = repository;
        this.logger = logger;
    }

    // implement UserController methods here:
    public ActionResult Index() {
        this.logger.Log("Index called");
        return View(this.repository.GetAll());
    } 
}

La clase UserController depende de las interfaces IUserRepository y ILogger. Al no depender de una clase concreta, podemos realizar pruebas de la clase UserController de manera aislada. Y eso es sólo la punta del iceberg de las bondades de la inversión de control.
Usando Simple Injector, la configuración de la aplicación podría verse mas o menos así:


protected void Application_Start(object sender, EventArgs e) {
    // 1. Create a new Simple Injector container
    var container = new Container();

    // 2. Configure the container (register)
    container.Register<IUserRepository, SqlUserRepository>();

    container.RegisterSingle<ILogger>(() => new CompositeLogger(
        container.GetInstance<DatabaseLogger>(),
        container.GetInstance<MailLogger>()
    ));

    // 3. Optionally verify the container's configuration.
    container.Verify();

    // 4. Register the container as MVC3 IDependencyResolver.
    DependencyResolver.SetResolver(new SimpleInjectorDependencyResolver(container));
}

Esta configuración muestra la registración de las implementaciones para las interfaces IUserRepository y ILogger. Este código también muestra un par de cosas interesantes. Primero que nada, se pueden asociar instancias concretas (como SqlUserRepository) a interfaces o tipos base. En el ejemplo anterior, cada vez que se solicita al contenedor de Simple Injector un IUserRepository, éste va a crear una nueva instancia de la clase SqlUserRepository.
La registración de ILogger es un poco más compleja. Se registra un delegado que conoce cómo crear una nueva implementación de ILogger, en este caso CompositeLogger (que resulta ser una implementación de ILogger). El mismo delegado es llamado dentro del contenedor de Simple Injector y crea una instancia concreta de la clase DatabaseLogger y MailLogger para inyectarlo dentro de CompositeLogger. Mientras el tipo de registración que hemos visto para IUserRepository es la más común, el uso de delegados permite muchos escenarios interesantes.

Nota: no se ha registrado la clase UserController. Esto se debe a que es una clase concreta. Simple Injector puede implícitamente crearla (siempre y cuando pueda resolver sus dependencias).

Esto es todo lo que se necesita para usar Simple Injector. Diseñar las clases basados en el principio de inversión de dependencias y configurar la librería al inicio de la aplicación. Algunos frameworks (tales como ASP.NET MVC) hacen el resto, mientras que otros (como ASP.NET Web forms) necesitan una vuelta más de trabajo para dejarlo hecho. Ver la guía de integración para consultar otros ejemplos de otros frameworks.

Refactoring aplicando patrones

2014-01-28T09:00:00.000-03:00

En otro post de este blog, habíamos visto la posibilidad de reescribir código que a nuestro juicio no estaba orientado a objetos. En esta ocasión, volvemos con un caso similar. Se trata de un anidamiento de sentencias condicionales IF basadas en configuraciones.

La idea principal es reemplazar todo este árbol de condiciones con una estructura orientada a objetos que permita poder introducir modificaciones de una manera mucho más simple.

Este caso en particular presentaba un método que buscaba un código GTIN y luego, según la parametrización del sistema debía validar el resultado obtenido.

No es la idea de este post explicar exactamente lo que significa un código GTIN. Bastará con explicar que dadas las legislaciones vigentes a la fecha en Argentina, es necesario obtener dicho código para poder realizar un comprobante de venta de manera electrónica. Tampoco es el interés de este post entrar en detalle sobre la arquitectura de la clase en la cual se halla implantado este método, sino, simplemente, el código hallado en él.

El método en cuestión es el siguiente:

public class ComprobanteDeVentas
{
    private ComprobanteDetalle comprobanteDetalle;
    private BuscadorCodigosGTIN BuscadorCodigosGTIN;

    private void AsignarCodigoGTIN()
    {
        this.comprobanteDetalle.Item.CodigoGTIN = this.BuscadorCodigosGTIN.Obtener( this.comprobanteDetalle.Item );
        if ( Parametros.TipoDeWebServiceparafacturacionelectronicanacional == 2 )
            if ( !string.IsNullOrEmpty(this.comprobanteDetalle.Item.Articulo_PK ) && string.IsNullOrEmpty( this.comprobanteDetalle.Item.CodigoGTIN ) && Parametros.AvisarSiNoExisteCodigo )
                if ( Parametros.PermiteContinuar == 1)
                    Mensajes.Advertir( "No se encontró codigo GTIN para los datos ingresados" );
                else
                    throw new Exception( "No se encontró codigo GTIN para los datos ingresados" );
    }
}

Como se puede apreciar, no sólo hay una cuestión técnica de arquitectura, sino también una cuestión de difícil entendimiento del código debido a la aglutinación de condiciones y lo compleja de cada una de ellas.

Yendo al análisis arquitectónico de este código, se puede determinar que la validación de la obtención de un código GTIN vacío es un comportamiento que no debe ser responsabilidad del comprobante de ventas, sino de un componente y que además, dicho componente tiene tres claras validaciones dependiendo de los parámetros del sistema:

No validar nada.
Que se muestre un mensaje de advertencia pero que permita continuar.
Que se lance una excepción y corte el flujo del programa.

Teniendo esto en cuenta, se procedió a la creación de tres clases nuevas para contener estos tres comportamientos (las cuales implementan una misma interfaz) y así aplicar el patrón Null object que resulta ser una derivación del patrón Strategy:

public interface IValidadorGTIN
{
    void Validar( Item item );
}

public class ValidadorGTINNoHaceNada : IValidadorGTIN
{
    public void Validar( Item item )
    {
        //No se lleva a cabo ninguna acción.
    }
}

public class ValidadorGTINAvisarSiEstaVacio : IValidadorGTIN
{
    public void Validar(Item item)
    {
        if (!string.IsNullOrEmpty(item.Articulo_PK) && string.IsNullOrEmpty( item.CodigoGTIN ) )
            Mensajes.Advertir("No se encontró codigo GTIN para los datos ingresados");
    }
}

public class ValidadorGTINNoDejaSeguirSiEstaVacio : IValidadorGTIN
{
    public void Validar(Item item)
    {
        if (!string.IsNullOrEmpty( item.Articulo_PK ) && string.IsNullOrEmpty( item.CodigoGTIN ) )
            throw new Exception("No se encontró codigo GTIN para los datos ingresados");
    }
}

Vemos que cada una de las clases tiene el método validar y que a su vez tienen una sola responsabilidad cada una. Todas tienen implementan la misma interfaz: un método llamado Validar que recibe un objeto Item a validar pero cada una la implementa de una manera diferente. La primer clase no hace nada. La segunda envía un mensaje a través del componente Mensajes. La tercera lanza una excepción.

El siguiente paso fue crear la lógica para que el ComprobanteDeVentas pueda recibir la instancia del validador que corresponde según el caso. Para ello tratamos de usar el patrón Factory Method para encapsular la lógica encargada de la inyección del componente correcto.

public class ValidadorGTINFactory
{
    public static IValidadorGTIN ObtenerInstancia()
    {
        IValidadorGTIN validador = new ValidadorGTINNoHaceNada();
        bool avisarSiVacio = Parametros.AvisarSiNoExisteCodigo;
        int permiteContinuar = Parametros.PermiteContinuar;

        if ( avisarSiVacio && permiteContinuar == 1 )
            validador = new ValidadorGTINAvisarSiEstaVacio();
        if ( avisarSiVacio && permiteContinuar == 0 )
            validador = new ValidadorGTINNoDejaSeguirSiEstaVacio();

        return validador;
    }
}

Por medio del uso del patrón Factory Method, se lleva a cabo la instanciación del objeto validador correspondiente para la parametrización del momento. Por defecto, se devuelve el componente que no hace nada. Luego, dependiendo de la parametrización del sistema, se instancia cualquiera de las otras clases. En el caso que llegare a surgir un nuevo caso o comportamiento, bastará con agregar el caso a esta clase e instanciar la clase correspondiente al nuevo caso de validación sin la necesidad de modificar la clase ComprobanteDeVentas, respetando así uno de los principios de SOLID donde cada clase debe tener una y sólo una responsabilidad (Single responsability principle).

Finalmente, realizamos los cambios necesarios en la clase ComprobanteDeVentas para que utilice las clases creadas. Para ello, creamos una variable de clase para contener al componente validador. El mismo es inyectado en la clase vía su constructor (*).


public class ComprobanteDeVentas
{
    private ComprobanteDetalle comprobanteDetalle;
    private BuscadorCodigosGTIN BuscadorCodigosGTIN;
    private IValidadorGTIN validador;

    public ComprobanteDeVentas( IValidadorGTIN validador )
    {
        this.validador = validador;
    }

    private void AsignarCodigoGTIN()
    {
        this.comprobanteDetalle.Item.CodigoGTIN = this.BuscadorCodigosGTIN.Obtener( this.comprobanteDetalle.Item );
        //Con esta línea de código se ve reemplazado el árbol de condiciones preexistentes.
        this.validador.Validar( this.comprobanteDetalle.Item );
    }
}

De esta manera, la lógica de validación del código GTIN obtenido, queda separada de la clase ComprobanteDeVentas y totalmente reutilizable para otros comprobantes. A este beneficio se suma la posibilidad de poder realizar tests individuales (TDD) de cada clase sin la necesidad de instanciar un comprobante de ventas o incluso poder generar mocks o fakes de las clases del componente validador en un test de la clase ComprobanteDeVentas.

(*) El Factory Method del validador, debe ser invocado desde el Factory Method que instancia la clase ComprobanteDeVentas

Esperando el fin de semana

2014-01-17T09:00:00.000-03:00

Verano... Enero... Vacaciones... Viernes... Casi se pueden tomar como sinónimos!!!! A disfrutarlo resolviendo un acertijo y así entrenamos las neuronas.

"Bien, María", dijo el granjero Jones a su esposa, "si vendemos setenta y cinco pollos, como propongo, nuestra reserva de alimento duraría veinte días más, en tanto que si compramos cien pollos más, como tú dices, nos quedaremos sin alimento para pollos quince días antes."
"Veamos, Josiah", replicó ella, "¿cuántos pollos tenemos?"
Ese es el problema. ¿Cuántos pollos tenían?

Respuesta del acertijo de la semana anterior:

Problema 1.13. Almacén de ramos generales del libro "Los nuevos acertijos" de San Loyd"
Los valores para cada letra son: A=3, B=6, C=4, E=2, H=5, L=7, O=8, P=1, S=0, W=9.

Esperando el fin de semana

2014-01-10T09:00:00.000-03:00

Un nuevo acertijo para activar las neuronas o al menos aquellas que no se encuentren pensado en el fin de semana.

El dueño de un almacén de ramos generales, que es aficionado a los acertijos, ha puesto una pizarra para ver si alguno de sus amigos matemáticos puede traducirlo correctamente. Cada una de las distintas letras representa a un dígito diferente. Las palabras que están por encima de la línea horizontal representan números que, sumados, dan el total "All Wool". El problema consiste en reemplazar las letras por los dígitos correctos.

Respuesta del acertijo de la semana pasada:

Cuarenta años atrás Biddy tenía 18 años, lo que hace que ahora tenga 58.

Esperando el fin de semana

2014-01-03T09:00:00.000-03:00

Primer viernes del 2014. Primer acertijo del 2014. Qué estamos esperando para resolverlo?

Biddy era muy sensible con la cuestión de su edad. Durante las dos últimas veintenas de años, respondía a las preguntas acerca de su edad, recitando siempre el siguiente versito:

Cinco veces siete y siete veces tres

Suma a mi edad y obtendrás

Un número que excede a seis nueves y cuatro

Tanto como el doble de mi edad pasa de veinte.

El verso fue acertado la primera vez que Biddy lo recitó, pero, ¿puede usted decirme la edad actual de Biddy?

Respuesta del acertijo de la semana pasada:

Hank tenía 11 animales. Jim 7 y Duke 21, lo que da un total de 39 animales.

Feliz 2014

2013-12-31T09:00:00.000-03:00

Un nuevo año finaliza y desde este blog quiero alzar mi copa junto a ustedes y desearles un feliz y próspero año nuevo.

Esperando el fin de semana

2013-12-27T09:00:00.000-03:00

ULTIMO VIERNES DE AÑO!!!!

No nos lo podemos perder... Un acertijo para despedir el año como se lo merece: estrujando la neurona...

Tres vaqueros tejanos se encontraron en la ruta y sostuvieron la siguiente conversación:

Hank le dice a Jim: 'le doy seis cerdos a cambio de un caballo; así tendrás en tu manada el doble de animales de los que quedarán en la mía".

Duke le dice a Hank: 'le doy catorce ovejas a cambio de un caballo, así tendrás el triple de animales que yo".

Jim le dice a Duke: "Te daré cuatro vacas a cambio de un caballo; así tendrás seis veces más animales que yo".

A partir de estos datos, ¿puede usted decirme cuántos animales había en cada una de las tres manadas?

Respuesta del acertijo de la semana pasada:
La manera más barata de hacer una cadena con las seis piezas de cinco eslabones es abrir los cinco eslabones de una pieza y después utilizarlos Para unir las cinco piezas restantes. El costo seria de $1,30 lo que resulta 20 centavos más barato que el costo de una cadena nueva.

Esperando el fin de semana

2013-12-23T09:00:00.000-03:00

Ya que el último fin de semana no hubo acertijo (ni el anterior) por falta de gente que se anime a responder (debo buscar mejores incentivos), publicamos uno hoy, para hacer la previa a la navidad...

Un granjero tenía seis pedazos de cadena de cinco eslabones cada uno, y deseaba convertirlos en una cadena de treinta eslabones.
Si cuesta ocho centavos abrir un eslabón y dieciocho centavos volver a soldarlo, y si una cadena nueva cuesta un 1 dólar y medio, preguntamos:
¿Cuánto dinero se ahorraría gracias al plan más económico?

Respuesta del acertijo de la semana pasada:
Cada uno de los profesionales cobra:
Empapelador $ 200
Pintor $ 900
Plomero $ 800
Electricista $ 300
Carpintero $3.000
Albañil $2.300

Esperando el fin de semana

2013-11-29T09:00:00.000-03:00

Tras un lapsus sin acertijos, volvemos nuevamente a la carga!

Un contratista abocado a la construcción de una casa descubrió que debía pagar:
$ 1.100 al empapelador y al pintor,
$ 1.700 al pintor y al plomero,
$ 1.100 al plomero y al electricista,
$ 3.300 al electricista y al carpintero,
$ 5.300 al carpintero y al albañil,
$ 2.500 al albañil y al empapelador.
¿Cuánto cobra por sus servicios cada uno de ellos?

Respuesta del acertijo del 8 de noviembre:
Como el avaro podía dividir cada tipo de moneda de manera pareja en cuatro, cinco y seis partes, debe haber tenido por lo menos sesenta monedas de cada clase, haciendo un total de $ 2.100.

Esperando el fin de semana

2013-11-08T09:00:00.000-03:00

Otro viernes gris en Buenos Aires. A ponerle garra y levantarlo resolviendo el acertijo de hoy!!!!

Un avaro, antes de morirse de hambre, acumuló una cantidad de monedas de oro de cinco, diez y veinte dólares. Las guardaba en cinco bolsas que eran exactamente iguales en cuanto a que todas contenían la misma cantidad de monedas de cinco dólares, el mismo número de
monedas de diez dólares y el mismo número de monedas de veinte dólares.
El avaro contaba su tesoro poniendo todas las monedas sobre la mesa y dividiéndolas luego en cuatro pilas que también contenían la misma cantidad de cada tipo de monedas. Su último paso era tomar dos cualesquiera de estas pilas, reunir las monedas y distribuidas luego en tres pilas que eran exactamente iguales en el sentido ya explicado.
¿Cuál es la menor cantidad de dinero que debe haber poseído este pobre anciano?

Respuesta del acertijo de la semana pasada:
Los siete fósforos se disponen de modo de formar las letras de la palabra mil, y los cinco se disponen para formar un uno y un cero (10).

Esperando el fin de semana

2013-11-01T09:00:00.000-03:00

Llueve en Buenos Aires y aledaños, pero no nos va a amargar el día. Es viernes y el fin de semana está sólo a un paso!!! Levanta este día gris resolviendo el acertijo de hoy.

Harry ha dado a su hermana siete fósforos, desafiándola a que los disponga de manera que parezcan mil. Ella, a su vez, le ha dado a él cinco fósforos, instándolo a que los disponga de tal manera que parezcan diez.

Respuesta del acertijo de la semana pasada:
Mary tiene 27 años y 6 meses.

Esperando el fin de semana

2013-10-25T09:00:00.000-03:00

Un nuevo viernes llegó y un nuevo acertijo llegó con él. Lo puedes resolver?

"Ya ves" - comentó el abuelo- "las edades de Ann y Mary suman cuarenta y cuatro años, y Mary tiene el doble de la edad que tenía Ann cuando Mary tenía la mitad de la edad que Ann tendrá cuando Ann tenga tres veces la edad que Mary tenía cuando su edad era tres veces la de Ann."
¿Cuántos años tiene Mary?

Solución del acertijo de la semana pasada:
Los cuatro hombres llevaban al quinto en un ataúd. por este motivo éste no se había mojado.

Esperando el fin de semana

2013-10-18T09:00:00.000-03:00

Semana corta en Argentina, pero no por eso el viernes pierde su natural alegría. Vamos con nuestro acertijo semanal!!!

Cinco hombres iba juntos por un camino en el campo. Comienza a llover. Cuatro de los hombres apuran el paso.
El quinto no hace ningún esfuerzo por darse prisa. Sin embargo, se mantiene seco mientras que los otros cuatro se mojan.
Los cinco llegan a su destino juntos. NOTA: Para trasladarse sólo contaban con los pies y ninguno llevaba paraguas o similar.
¿Cómo pudo ser?

Respuesta del acertijo bis de la semana pasada:
Los niños Jones vendieron 220 periódicos más que los niños Smith.

MVC, Datetime y la localización regional

2013-10-16T09:00:00.000-03:00

Descubrí hace poco que existe un tema muy frecuente y poco esperable por parte de MVC y las localizaciones. Para los que manejamos las fechas con un formato diferente del de Estados Unidos, nos suele aparecer el error "The field [date] has format invalid" cuando ingresamos un día del mes superior a 12 y se desea .
Esto se debe a un problema del model binder que tiene por defecto MVC y se debe reemplazar por uno personalizado para que se pueda tener en cuenta el formato de la hora correspondiente.
Veamos un ejemplo que he probado y funciona. Incluso hace uso del atributo [DisplayFormat] para poder utilizar el formato de fecha que más nos convenga.

Model:

public class MyViewModel
{
    [DisplayName("date of birth")]
    [DataType(DataType.Date)]
    [DisplayFormat(DataFormatString = "{0:dd/MM/yyyy}", ApplyFormatInEditMode = true)]
    public DateTime? Birth { get; set; }
}

Controller:

public class HomeController : Controller
{
    public ActionResult Index()
    {
        return View(new MyViewModel
        {
            Birth = DateTime.Now
        });
    }

    [HttpPost]
    public ActionResult Index(MyViewModel model)
    {
        return View(model);
    }
}

View:

@model MyViewModel

@using (Html.BeginForm())
{
    @Html.LabelFor(x => x.Birth)
    @Html.EditorFor(x => x.Birth)
    @Html.ValidationMessageFor(x => x.Birth)
    <button type="submit">OK</button>
}

Model Binder personalizado:

Hasta aquí sólo hemos hecho lo de costumbre en MVC. Para poder resolver nuestro problema, deberemos escribir nuestro propio Model Binder y así reemplazar el que utiliza MVC por defecto.

public class MyDateTimeModelBinder : DefaultModelBinder
{
    public override object BindModel(ControllerContext controllerContext, ModelBindingContext bindingContext)
    {
        var displayFormat = bindingContext.ModelMetadata.DisplayFormatString;
        var value = bindingContext.ValueProvider.GetValue(bindingContext.ModelName);

        if (!string.IsNullOrEmpty(displayFormat) && value != null)
        {
            DateTime date;
            displayFormat = displayFormat.Replace("{0:", string.Empty).Replace("}", string.Empty);
            // use the format specified in the DisplayFormat attribute to parse the date
            if (DateTime.TryParseExact(value.AttemptedValue, displayFormat, CultureInfo.InvariantCulture, DateTimeStyles.None, out date))
            {
                return date;
            }
            else
            {
                bindingContext.ModelState.AddModelError(
                    bindingContext.ModelName,
                    string.Format("{0} is an invalid date format", value.AttemptedValue)
                );
            }
        }

        return base.BindModel(controllerContext, bindingContext);
    }
}

Registración del Model Binder:

Para que MVC utilice nuestro Model Binder, debemos registrarlo. Para ello, agregaremos la siguiente línea en el método Application_Start.

ModelBinders.Binders.Add(typeof(DateTime?), new MyDateTimeModelBinder());

Ya no importa la cultura en la que se encuentre el servidor o el cliente, se utilizará el formato especificado en el atributo DisplayFormat para parsear la fecha.
La solución hasta aquí propuesta fue hallada en StackOverflow.

Bonus:

Hasta aquí, esta solución resuelve el problema para los navegadores: Firefox, Opera e Internet Explorer. Pero persiste para Chrome y Safari, ya que estos no usan la localización regional para instanciar el objeto Datetime de jQuery, lo que ocasiona el mismo error pero del lado del cliente.
Para solucionar este último escollo, también es necesario modificar el archivo jQuery.validate.js.
La función debe quedar así:

// http://docs.jquery.com/Plugins/Validation/Methods/date
date: function(value, element) {
   return this.optional(element) || !/Invalid|NaN/.test(new Date($.browser.webkit ? d[1] + "/" + d[0] + "/" + d[2] : value));
},

Y no se debe olvidar modificar el archivo minificado tabién (jQuery.validate.min.js):

date:function(a,b){return this.optional(b)||!/Invalid|NaN/.test(new Date($.browser.webkit?d[1]+"/"+d[0]+"/"+d[2]:a))}

Esperando el fin de semana (bis)

2013-10-11T12:00:00.000-03:00

Viendo que el acertijo de hoy ha sido resuelto tan pronto y a pedido del público, hoy hay bis!!!!

Cinco jóvenes y listos diarieros se asociaron e hicieron lo siguiente: Tom Smith vendió un periódico más que un cuarto del total, Billy Jones vendió un periódico más que un cuarto de lo que quedaba, Ned Smith vendió uno más que uno más que un cuarto del resto, y Charley Jones vendió la cuarta parte del sobrante, más uno. En este punto, los chicos Smith, juntos, habían vendido cien periódicos más que los chicos Jones, en conjunto. El pequeño Jimmy Jones, el más joven del grupo, vendió entonces los periódicos que aún quedaban.
Los tres chicos Jones vendieron más periódicos que los dos chicos Smith, pero ¿cuántos más?

Respuesta del acertijo anterior:
El pendiente cayó sobre una taza de café... en grano.

Esperando el fin de semana

2013-10-11T09:00:00.000-03:00

Vamos que ya es viernes!!! Solo un rato más y el fin de semana se hará presente. Usa este acertijo para pasar el tiempo. Anímense a dejar un comentario con la respuesta y firmen su comentario, no sean tímidos :)

Esta mañana a Mariana se le cayó un pendiente en el café. Y aunque la taza estaba llena, el pendiente no se mojó. ¿Cómo fue eso posible?

Respuesta del acertijo de la semana pasada:
Se trataba de un muchacho con su padre y su abuelo paterno.

Esperando el fin de semana

2013-10-04T09:00:00.000-03:00

Tras un lapsus, volvemos con todo. Un acertijo corto y simple para esperar este nuevo fin de semana!!!

Dos padres y dos hijos fueron a pescar, tres peces pescaron y a cada uno le tocó un pez.
¿Cómo pudo ser?

Respuesta del acertijo de la semana pasada:

Cuando a José le tocó pasar delante de la caja de las bolas, metió la mano y tomó una de las bolas y, sin mostrarla a nadie, se la metió en la boca y se la tragó. Inmediatamente – tan pronto pudo respirar bien – dijo: “yo he sacado la bola blanca, pues solo quedan en la caja las nueve bolas negras”. Todos miraron dentro de la caja. Era verdad. El alcalde no pudo negarse a dejarlo libre. O bien, el preso José pasa al final de los que van a sacar la bola, no la saca y dice “salieron ya las 9 bolas negras, la sobrante es la blanca”, (no se plantea que cada bola que sacan se regrese a la caja)

Parrot, view-engine que facilita la lectura de HTML para MVC

2013-09-25T09:00:00.000-03:00

Cuando Microsoft decidió mejorar el código escrito en las vista para MVC, fue con la intención de agilizar la escritura de dicho código, pero también para que fuera fácil de escribir.
Lamentablemente, optaron por dejar los tag de HTML tal y como estaban. No está en mí criticar esta decisión, pero aunque razor ha ayudado a hacer más legible el código, cuando se posee una página algo compleja, los tags de HTML pueden llegar a dejar las vistas algo incómodas de leer (Sí, lo sé, también existen las partial view).
En ayuda a esto, surge una librería llamada Parrot que se define a sí misma como un view-engine o motor de vistas.
Es una librería relativamente joven y aunque no cubren el 100% de los casos, tienen una gran cantidad cubierta. La última versión, la 1.0.3, salió en julio de 2013 y prometen seguir haciéndola crecer.
Esta herramienta nos permite ahorrar bastante "código" HTML al momento de escribir las vistas ya que con una muy simple sintaxis, este motor nos renderiza todo lo necesario para agregar los tags y atributos deseados. Pero vayamos a los ejemplos que va a resultar más claro que toda mi palabrería.

Con razor hoy escribiriamos un código más o menos similar al siguiente para llenar una lista con un modelo de tipo List<>:

<ul id="ListOfPeople">
    @foreach (Models.Person p in Model)
    {
        <li>@p.Name - @p.Phone</li>
    }
</ul>

Con esta librería sólo tendríamos que escribir una línea de código:

ul#ListOfPeople(Model) > li | @Name - @Phone

Usa una sintaxis muy simple, parecida a jQuery o CSS. Con la línea anterior dice que tiene que poner un tag ul, cuyo id va a ser ListOfPeople, que dentro debe poner un tag li y usar como texto (lo que viene luego del pipe) @Name - @Phone. Con esa sola línea resuelve lo que normalmente escribiríamos en 6.
Este es el resultado que se obtiene una vez renderizado en el browser (en cualquiera de ambos casos):

<ul id="”ListOfPeople”">
 <li>John Smith – 555-1234</li>
 <li>Mary Smith – 555-1236</li>
 <li>Steve Smith – 555-1236</li>
</ul>

Un ejemplo mucho más simple, es ver cómo se renderizan tags simples:

ul
p
div
span

Parrot tiene también la capacidad de detectar de qué manera puede cerrar los tags de HTML para hacer más liviana la página. Teniendo en cuenta el ejemplo anterior, su renderizado, sería el siguiente:

<ul></ul>
<p />
<div />
<span />

Aquí sólo les presento dos ejemplos de cómo Parrot permite ahorrar mucho espacio en las vistas y cómo éstas se hacen más legibles para el desarrollador.
Esta librería puede encontrarse entre los paquetes de NuGet por lo que resulta aun más fácil su implementación y además cuenta con un sitio para probar el renderizado de código de prueba.
Los invito a visitar su sitio oficial y su sitio de pruebas para que saquen sus propias conclusiones.

Nota publicada en el blog de Triada Software.

Esperando el fin de semana

2013-09-20T09:00:00.000-03:00

Viernes previo a la llegada de la primavera (al menos para los del hemisferio sur) y lo arrancamos a toda máquina con un nuevo acertijo.

El alcalde de una prisión ofrece la libertad inmediata a uno de los diez presos que mantiene entre rejas, elegido al azar. Para ello, prepara una caja con diez bolas: 9 negras y una 1 blanca y les dice que aquel que extraiga la bola blanca será el preso que quede libre. Pero el alcalde, mala persona, coloca, sin que nadie lo sepa, las diez bolas negras, para asegurarse que ninguno de sus 10 presos va a quedar en libertad. El preso José, que tiene fama de listo, se enteró casualmente de la trampa que iba a hacer el alcalde e ideó una estrategia que le dio la libertad. ¿Cómo lo hizo José?.

Respuesta del acertijo de la semana pasada:
Porque era de día.

Esperando el fin de seamana

2013-09-13T09:00:00.000-03:00

VIERNES!!!!!!!!!!! Ya llega el fin de semana y además, nuestro acertijo :)

El martes, Juan consiguió apagar la luz de su dormitorio y meterse en la cama antes de que la habitación quedase a oscuras. Hay tres metros desde la cama al interruptor de la luz. ¿Cómo pudo hacerlo?

Respuesta del acertijo de la semana pasada:
El hombre había saltado desde un avión pero su paracaídas no logró abrirse. Este era el paquete sin abrir.

Esperando el fin de semana

2013-09-06T09:00:00.000-03:00

Un nuevo viernes, un nuevo mes y un nuevo acertijo... A RESOLVERLO!

Un hombre yace muerto en un campo. A su lado hay un paquete sin abrir. No hay nadie más en el campo. ¿Como murió?
Ayuda: Mientras se acercaba el hombre al lugar donde se le encontró muerto, sabía que irremediablemente moriría.

Respuesta del acertijo de la semana pasada:
La botella estaba vacía.

Esperando el fin de semana

2013-08-28T09:00:00.000-03:00

Llegó el fin de semana y junto con él, el final del mes. Despidamos la semana como se lo merece, sacándole punta al ingenio!

En el centro de una mesa, sobre un mantel de 30 cm de diámetro, hay una botella de vino abierta. ¿Cómo quitar el mantel sin derramar el vino y sin tocarla con ningún otro objeto ni con alguna parte del cuerpo?

Respuesta del acertijo de la semana pasada:
El reo dice: “Me van a matar en la silla eléctrica”. Y piensan los verdugos: si es verdad lo que ha dicho, no podemos matarlo en la silla eléctrica, ya que ésta forma de ejecución habíamos quedado en reservarla para el caso de que mintiera. Pero, por otra parte, si lo matamos en la horca, habrá mentido en su afirmación, así que tampoco podemos matarlo en la horca porque esta forma de matarlo la íbamos a utilizar si decía la verdad.