El Nuevo Estilo de la Oficina de Microsoft en Madrid

El pasado 29 de Marzo tuve la oportunidad de visitar las oficinas de Microsoft en Madrid para el evento Global Windows Azure Bootcamp 2014, donde pudimos trabajar y conocer de primera mano las últimas novedades sobre las tecnologías de Microsoft en la nube.

También era la primera vez que entraba desde la reforma y cambio de imagen, y debo decir que las nuevas oficinas son espectaculares. Combinan estilos, colores, luces y formas que otorgan un dinamismo estético muy agradable y acogedor. Durante el evento del Global Windows Azure Bootcamp, todos los participantes nos sentimos muy cómodos.

Una de las particularidades del nuevo estilo de las oficinas, son los pequeños jardines visibles desde dentro y la luminosidad de sus amplios espacios, transmiten positivismo.

En un post anterior, ya comentaba como describen el trabajo en Microsoft Ibérica. Aquí os dejo un nuevo video, donde diferentes personalidades de la compañía describen en sus propias palabras la nueva imagen de sus instalaciones:

Anuncios

Así es el trabajo de un Technology Evangelist en Microsoft

Para todo el que me conoce, sabe que ninguna ocupación puede superar la profesión de ser un Technology Evangelist (o evangelista tecnológico). Como profesional especializado en tecnologías Microsoft, sobre todo la plataforma .NET y sus tecnologías asociadas, no existe un rol que más me guste ejecutar con las empresas y clientes con los cuales colaboro.

La razón principal por la cual me gusta, es porque me permite expresar libremente la pasión que siento por el Software, por como cambia y mejora la vida y el día a día de las personas que lo utilizan. Me encanta ver en mis clientes y compañeros la satisfacción y esa media sonrisa que llega sola al alcanzar un objetivo o lograr una pieza de código que fue casi imposible y que ahora vive frente a sus ojos y que potencia sus aplicativos y su profesionalismo.

Expresar y liberar esta pasión es muy importante, y cuando lo haces de forma auténtica y genuina descubres lo contagiosa que puede llegar a ser. Es algo que podemos ver claramente en el siguiente video, en el cual Alice Pang (@alicerp), una joven Technology Evangelist de Microsoft nos cuenta como puede llegar a ser un día cualquiera, si es que algo así puede existir, en los días de un Microsoft Evangelist:

El reto más grande es ayudar a otros profesionales a darse cuenta del potencial y la calidad de su trabajo, y de como las herramientas que existen en el mercado, tanto las oficiales de Microsoft como aquellas desarrolladas por la inmensa comunidad que a surgido entorno a estas, puede ofrecernos niveles de creación increíbles.

Como Evangelista, eres un usuario más de los productos de los que hablas. Recorres el camino tanto de sus bondades como de sus carencias, y vives en carne propia la experiencia mística de su uso, de los límites que tiene y de como romper dichos límites para alcanzar el éxito. Esas experiencias, esas historias tangibles, hacen del Evangelista un profesional de alta credibilidad, que no sólo convence con su discurso apasionado y lleno de sensaciones, sino con hechos medibles que efectivamente apoyan la productividad y las cualidades de los equipos con los cuales trabaja.

Ayudar a los que tienen retos y obstáculos en su código, darles a conocer las últimas tecnologías, como usarlas, sus oportunidades, sus pitfalls, las tendencias que establecen, de dónde vienen y hacia dónde van son sólo una parte del discurso que como evangelista tengo para con mis compañeros, amigos y clientes.

Y aunque no trabajo en Microsoft, espero algún día tener la oportunidad de pertenecer al maravilloso grupo de profesionales que conforman las diferentes divisiones de Evangelistas Tecnológicos.

_________
Referencias: Blog MSDN de Alice Pang (tiene interesantes recursos de Windows Phone).

Como Validar el DNI o el RUC de Perú en C#

En estos días me ha tocado trabajar en un proyecto que, como tantos otros hoy día, está pensado para un entorno empresarial globalizado.

Parte de las reglas de negocio del proyecto exige, como también es común en tantos otros proyectos, validar el documento de identidad correspondiente al cliente para el país al cual éste pertenece. Para el caso de países como España o Brasil existe amplia documentación y recursos referentes al algoritmo empleado para validar sus respectivos documentos de identidad.

Pero lamentablemente para Perú, uno de los países que tengo que gestionar, la cantidad y la calidad de la información disponible es decepcionante.

DNI Electrónico Peruano

Por otro lado, al hablar de documentos de identidad en Perú, debemos distinguir entre el DNI (Documento Único de Identidad) y el RUC (Registro Único de Contribuyente). El primero aplica a los ciudadanos en general y cuenta con un identificador conocido como CUI (Cédula Única de Identidad), mientras que el segundo aplica a empresas y comercios.

El siguiente algoritmo permite validar documentos de identidad peruanos (tanto DNI como RUC). Para el caso del DNI, es independiente que el CUI tenga como término de verificación un número o una letra.

public static bool ValidateIdentificationDocumentPeru(string identificationDocument)
{
    if (!string.IsNullOrEmpty(identificationDocument))
    {
        int addition = 0;
        int[] hash = { 5, 4, 3, 2, 7, 6, 5, 4, 3, 2 };
        int identificationDocumentLength = identificationDocument.Length;

        string identificationComponent = identificationDocument.Substring(0, identificationDocumentLength - 1);

        int identificationComponentLength = identificationComponent.Length;

        int diff = hash.Length - identificationComponentLength;

        for (int i = identificationComponentLength - 1; i >= 0; i--)
        {
            addition += (identificationComponent[i] - '0') * hash[i + diff];
        }

        addition = 11 - (addition % 11);

        if (addition == 11)
        {
            addition = 0;
        }

        char last = char.ToUpperInvariant(identificationDocument[identificationDocumentLength - 1]);

        if (identificationDocumentLength == 11)
        {
            // The identification document corresponds to a RUC.
            return addition.Equals(last - '0');
        }
        else if (char.IsDigit(last))
        {
            // The identification document corresponds to a DNI with a number as verification digit.
            char[] hashNumbers = { '6', '7', '8', '9', '0', '1', '1', '2', '3', '4', '5' };
            return last.Equals(hashNumbers[addition]);
        }
        else if (char.IsLetter(last))
        {
            // The identification document corresponds to a DNI with a letter as verification digit.
            char[] hashLetters = { 'K', 'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I', 'J' };
            return last.Equals(hashLetters[addition]);
        }
    }

    return false;
}

Finalmente, el gobierno de Perú pone a disposición la siguiente herramienta para verificar documentos de identidad; y esta otra herramienta para validar RUC.

Espero que les sea de utilidad.

Un Framework para Programación Orientada a Aspectos (AOP) en C#    Parte 3: Un aspecto para manejo de excepciones

Esta publicación es la cuarta parte (aunque diga parte tres) de una serie de cuatro publicaciones que estaré realizando sobre programación orientada a aspectos en .NET empleando el lenguaje de programación C#.

A parte del registro de eventos, otro elemento muy común en la programación orientada a objetos y en los lenguajes actuales (como Java o C#) es la gestión de excepciones.

El otro típico infierno al que se enfrenta un arquitecto o líder técnico a la hora de establecer la política de gestión de errores y excepciones en su diseño es la gobernabilidad de dicho diseño, y la monitorización de su cumplimiento por parte del equipo de desarrollo, cosa que se torna excesivamente complicada por la creatividad de algunos miembros del equipo que rompe la homogeneidad del mecanismo elegido como parte del modelo. Hasta aquí, este párrafo es prácticamente igual al de la segunda parte de esta serie de artículos.

Y es que el diseño y la gobernabilidad del mecanismo de gestión y manejo de excepciones adoloce de los mismos problemas y retos que que podemos encontrar con el registro de eventos.

Particularmente se encuentra que los dos (2) aspectos más difíciles de gestionar son el acto de capturar y apropiadamente manejar la excepción, seguidamente de la política a aplicar sobre ésta. Muchas veces podemos encontrarnos con aplicativos web que cuando una excepción ocurre nos muestra la temida pantalla amarilla de ASP.NET o directamente nos expone todo el stack trace de la excepción (con información de base de datos y todo), lo cual fácilmente podría usar un potencial atacante para literalmente destruir el aplicativo.

ASP.NET Yellow Page of Death

A través del enfoque de AOP, es posible interceptar las llamadas a los métodos y determinar cuando estos han generado una excepción para posteriormente aplicar la política de manejo más apropiada. Estas políticas puede ser parte del propio aspecto de gestión de excepciones. Como en el caso del registro de eventos, la implementación de este aspecto buscará reducir su implementación (y aplicación) a un atributo que decore el método cuyas posibles excepciones se quieren gestionar.

Un Apropiado Soporte

Al crear un mecanismo de gestión y manejo de excepciones, no deberíamos partir desde cero, ya que existe un montón de excelentes productos y frameworks que nos simplificarían esta tarea. Para este caso, emplearé los Microsoft Libraries, en particular el Exception Handling Application Block; sin embargo el enfoque de AOP y de este framework que he venido presentado permite emplear cualquier otra librería.

Implementación

Es importante que si no han leido las primeras partes de esta serie de artículos, aprovechen este momento para hacerlo, sobre todo la parte 1. A partir de este momento mis explicaciones considerarán que el conocimiento y los detalles técnicos explicados en esa parte ya son conocidos.

El primer paso es crear el atributo (Attribute) que decorará las clases/interfaces para capturar su ejecución e inyectar el código de manejo de excepciones. Nuestro atributo se llamará ExceptionHandlingAttribute y extiende de InterceptableAttribute, la clase base en el framework de AOP que sirve para definir atributos de intercepción.

    /// <summary>
    /// A custom attribute for exception handling purposes under an Aspect Oriented Programming paradigm.
    /// </summary>
    /// <remarks>
    /// It applies only to methods.
    /// </remarks>
    [AttributeUsage(AttributeTargets.Method, AllowMultiple = false, Inherited = true)]
    public sealed class ExceptionHandlingAttribute : InterceptableAttribute
    {
        /// <summary>
        /// Represents the exception handling politic to apply while intercepting with this concern.
        /// </summary>
        private ExceptionHandlingPolitic politic;

        /// <summary>
        /// Initializes a new instance of the <see cref="ExceptionHandlingAttribute" /> class.
        /// </summary>
        /// <param name="politic">The exception handling politic to follow.</param>
        public ExceptionHandlingAttribute(ExceptionHandlingPolitic politic)
        {
            this.politic = politic;
            this.Processor = Activator.CreateInstance(typeof(ExceptionHandlingProcessor)) as IProcessor;
        }

        /// <summary>
        /// Gets the specified exception handling politic.
        /// </summary>
        /// <value>
        /// Returns the politic to use when handling exceptions represented as a <see cref="ExceptionHandlingPolitic"/>.
        /// </value>
        public ExceptionHandlingPolitic Politic { get { return this.politic; } }
    }

Este atributo tiene una (1) propiedad muy importantes llamada Politic la cual permite establecer la política con la que se gestionará la excepción.

En el tema de políticas de manejo de excepciones hay muchas opiniones, controversias y religiones. En lo personal, dependen mucho de las características del sistema y del entorno donde se desplegará, pero habitalmente me decanto por las siguientes tres (3) políticas:

  • Encapsular: o encapsulate en inglés, es la política más habitualmente aplicada en la gestión de excepciones. Consiste en retornar una excepción nueva más significativa al llamador, pero agregando o anexando (encapsular) la excepción original en la nueva excepción. Esta política preserva el stack trace.
  • Reemplazar: o repace en inglés, consiste en retornar una nueva excepción más significativa al llamador del método, pero si agregar o anexar la excepción original; incluso pudiéndose cambiar el mensaje de la excepción. En esta política el stack trace no se preserva.
  • Propagar: o propagate en inglés, se refiere al acto de pasar la excepción al llamador del método. Esto no quiere decir que no se gestione la excepción per se, sino que no se transformará o encapsulará esta. El stack trace no sufre modificación alguna.

Utilizo estas políticas, porque la mayoría de mis diseños de software siguen un enfoque de capas, donde las excepciones que ocurren dentro de una misma capa son propagadas, cuando se pasa de una capa inferior a una capa superior se encapsulan, y cuando se tienen que llevar a la capa de UI o presentar la excepción al usuario, entonces se reemplaza (para evitar mostrar datos e información sensible a un potencial atacante). Otros enfoques arquitectónicos como el MVC o el MVVC muy probablemente empleen políticas totalmente diferentes.

Así, la propiedad Politic del atributo ExceptionHandlingAttribute admite valores del siguiente enumerado que representa las políticas antes mencionadas:

    /// <summary>
    /// Defines the exception handling politics to use.
    /// </summary>
    public enum ExceptionHandlingPolitic
    {
        /// <summary>
        /// Represents the propagation politic. 
        /// This politic specifies that every exception will be passed to the caller without any transformation.
        /// </summary>
        Propagate,

        /// <summary>
        /// Represents the wrap politic. 
        /// This politic specifies that every exception will be wrapped inside another exception and then passed to the caller.
        /// </summary>
        Wrap,

        /// <summary>
        /// Represents the replacement politic. 
        /// This politic specifies that every exception will be replaced for another exception; then the new exception will be passed to the caller.
        /// </summary>
        /// <remarks>
        /// The original exception will be lost.
        /// </remarks>
        Replace
    }

Una vez establecido el atributo de intercepción, procedemos a crear el Processor que se encargará de manejar la inyección de código antes y después de la ejecución de los métodos interceptados. Para esto crearemos la clase ExceptionHandlingProcessor que implementará la interfaz IProcessor del framework.

Esta clase es la que dependiento del valor de la propiedad Politic y basado en el Microsoft Enterprise Library Exception Handling Application Block procederá a manejar la excepción interceptada acorde a la configuración del mencionado Application Block.

La parte interesante es que para el caso de la gestión de excepciones no se necesitará el método ProcessCallMessage, ya que las excepciones como tal sólo ocurren como un retorno de método, con lo cual toda la acción ocurrirá en el método ProcessReturnMessage.

    /// <summary>
    /// Intercep processor for the calling and returning messages of the methods decorated as interceptable by this component.
    /// </summary>
    internal class ExceptionHandlingProcessor : IProcessor
    {
        /// <summary>
        /// Constant that identifies the exception handling policy of propagation.
        /// </summary>
        private const string PROPAGATE = @"PROPAGATE";

        /// <summary>
        /// Constant that identifies the exception handling policy of replacement.
        /// </summary>
        private const string REPLACE = @"REPLACE";

        /// <summary>
        /// Constant that identifies the exception handling policy of wrap.
        /// </summary>
        private const string WRAP = @"WRAP";

        /// <summary>
        /// Processes the call message, which happens before the execution of the body of the interceptable or processable method.
        /// </summary>
        /// <remarks>
        /// <para>
        /// Since the exception handling only occurs after the execution of the body of the interceptable or processable method, this
        /// method does nothing.
        /// </para>
        /// <para>
        /// This is because the exception type is contained in the <c>Method Return Message</c>.
        /// </para>
        /// </remarks>
        /// <param name="callMessage">The <c>Method Call Message</c> to process.</param>
        /// <param name="processable">The processable decorated object to process.</param>
        public void ProcessCallMessage(IMethodCallMessage callMessage, InterceptableAttribute processable)
        {
            // Do Nothing.
        }

        /// <summary>
        /// Processes the return message, which happens after the execution of the body of the interceptable or processable method.
        /// </summary>
        /// <remarks>
        /// <para>
        /// Since the <c>Method Return Message</c> contains the exception type, this method processes such message to retrieve the exception
        /// information.
        /// </para>
        /// <para>
        /// This method leverages the Microsoft Enterprise Library Exception Handling Application Block.
        /// </para>
        /// </remarks>
        /// <param name="returnMessage">The <c>Method Return Message</c> to process.</param>
        /// <param name="processable">The processable or interceptable object.</param>
        public void ProcessReturnMessage(IMethodReturnMessage returnMessage, InterceptableAttribute processable)
        {
            if (returnMessage != null && returnMessage.Exception != null)
            {
                string policyName = null;

                switch (((ExceptionHandlingAttribute)processable).Politic)
                {
                    case ExceptionHandlingPolitic.Propagate:
                        policyName = PROPAGATE;
                        break;

                    case ExceptionHandlingPolitic.Replace:
                        policyName = REPLACE;
                        break;

                    case ExceptionHandlingPolitic.Wrap:
                        policyName = WRAP;
                        break;

                    default:
                        throw new InvalidOperationException(@"Invalid or not defined exception handling politic.");
                }

                // Call to the static main entrance of the Microsoft Enterprise Library Exception Application Block.
                if (ExceptionPolicy.HandleException(returnMessage.Exception, policyName))
                {
                    throw returnMessage.Exception;
                }
            }
        }
    }

Como puede apreciarse en el método ProcessReturnMessage lo primero es saber si el método interceptado a retornado una excepción, lo cual se puede determinar fácilmente si la priedad Exception de la interfaz IMethodReturnMessage (a la cual pertenece el parámetro returnMessage) no es nula (null).

De haber una excepción, basta con recuperar el valor de la propiedad Politic del atributo para saber que política aplicar a la excepción interceptada. La configuración de estas políticas están delegadas al archivo de configuración del Exception Handling Application Block, y su aplicación se realiza en la línea 79.

Como en artículos anteriores, aquí tienen el código de este aspecto para estudiarlo. Espero que les sea de utilidad.

Un Framework para Programación Orientada a Aspectos (AOP) en C#    Parte 2: Un aspecto para registro de eventos

Esta publicación es la tercera parte (aunque diga parte dos) de una serie de cuatro publicaciones que estaré realizando sobre programación orientada a aspectos en .NET empleando el lenguaje de programación C#.

El que es quizás sea el ejemplo más sencillo de un aspecto es el registro de eventos de un sistema o aplicación. Así mismo, resulta ser el más significativo también.

El típico infierno al que se enfrenta un arquitecto o líder técnico a la hora de establecer la política de registro de eventos en su diseño es la gobernabilidad de dicho diseño, y la monitorización de su cumplimiento por parte del equipo de desarrollo, cosa que se torna excesivamente complicada por la creatividad de algunos miembros del equipo que rompe la homogeneidad de los mensajes que se ha establecido como parte del modelo de eventos.

Otro típico incidente es que los desarrolladores, muchas veces culpando a las restricciones de tiempo del proyecto o a la urgencia de la solicitud en la implementación de un determinado requerimiento, omiten agregar las líneas de código que generan el registro de eventos, lo cual a veces puede resultar incluso difícil de detectar en revisiones de código (a través de prácticas como los peer reviews.

A través del enfoque de AOP, es posible esconder el mensaje del evento y reducir su implementación a colocar un atributo que decore el método que se desea loggear, lo cual permitirá establacer el formato del mensaje e impedir que los miembros del equipo lo modifiquen, reforzando la arquitectura y la gobernabilidad del proyecto, a la vez que se simplifica el proceso de desarrollo y de verificación del código.

Un Apropiado Soporte

Al crear un sistema de registro de eventos, no deberíamos partir desde cero, ya que existe un montón de excelentes productos y frameworks que nos simplificarían esta tarea. Para este caso, emplearé los Microsoft Libraries, en particular el Logging Application Block; sin embargo el enfoque de AOP y de este framework que he venido presentado permite emplear cualquier otra librería como log4net o NLog.

Implementación

Es importante que si no han leido las primeras partes de esta serie de artículos, aprovechen este momento para hacerlo, sobre todo la parte 1. A partir de este momento mis explicaciones considerarán que el conocimiento y los detalles técnicos explicados en esa parte ya son conocidos.

El primer paso es crear el atributo (Attribute) que decorará las clases/interfaces para capturar su ejecución e inyectar el código de registro de eventos. Nuestro atributo se llamará LogAttribute y extiende de InterceptableAttribute, la clase base en el framework de AOP que sirve para definir atributos de intercepción.

    /// <summary>
    /// A custom attribute for logging purposes under an Aspect Oriented Programming paradigm.
    /// </summary>
    /// <remarks>
    /// It applies only to methods.
    /// </remarks>
    [AttributeUsage(AttributeTargets.Method, AllowMultiple = false, Inherited = true)]
    public sealed class LogAttribute : InterceptableAttribute
    {
        /// <summary>
        /// A stopwatch to use then the verbority level is set to its highest value, in order to
        /// log the amount of time consumed by methods calls.
        /// </summary>
        private Stopwatch timer;

        /// <summary>
        /// The verbosity level to log.
        /// </summary>
        private VerbosityLevel verbosity;

        /// <summary>
        /// Initializes a new instance of the <see cref="LogAttribute" /> class.
        /// </summary>
        /// <param name="verbosity">The verbosity level to log.</param>        
        public LogAttribute(VerbosityLevel verbosity)
        {
            this.verbosity = verbosity;
            this.Processor = Activator.CreateInstance(typeof(LogProcessor)) as IProcessor;

            if (verbosity.Equals(VerbosityLevel.Full))
            {
                this.timer = new Stopwatch();
                this.timer.Reset();
            }
        }

        /// <summary>
        /// Gets the verbosity level to log.
        /// </summary>
        /// <value>The verbosity level of the log trace as defined in <see cref="VerbosityLevel"/>.</value>
        public VerbosityLevel Verbosity { get { return this.verbosity; } }

        /// <summary>
        /// Gets the this log timer.
        /// </summary>
        /// <remarks>
        /// If the <c>Verbosity</c> is different than <see cref="VerbosityLevel.Full"/> then this property will return <c>null</c>.
        /// </remarks>
        /// <value>
        /// An instance of a <see cref="Stopwatch"/> to retrieve execution time when logging with <see cref="VerbosityLevel.Full"/>.
        /// </value>
        /// <see cref="Stopwatch"/>
        /// <see cref="AOPLoggingApplicationBlock.VerbosityLevel"/>
        public Stopwatch Timer { get { return this.timer; } }
    }

Este atributo tiene dos (2) propiedades muy importantes. La primera, llamada VerbosityLevel permite establecer que tanta información se generará/almacenará cuando se registre eventos con cada intercepción. En principio para este ejemplo he definido cuatro (4) niveles de verbosidad:

  1. None: no se registrarán eventos.
  2. Light: una mínima, pero significativa cantidad de información será generada.
  3. Medium: una cantidad moderada de significante información será generada.
  4. Full: mucha información será generada, no necesariamente todoa ella significativa, pero sí útil.

La segunda propiedad se llama Timer no es más que un Stopwatch y que para el caso de VerbosityLevel.Full nos medirá cuanto ha tardado en ejecutarse un método interceptado (con lo cual podríamos identificar cuellos de botella en tiempos de producción por ejemplo).

Una vez establecido el atributo de intercepción, procedemos a crear el Processor que se encargará de manejar la inyección de código antes y después de la ejecución de los métodos interceptados. Para esto crearemos la clase LogProcessor que implementará la interfaz IProcessor del framework.

Esta clase es la que dependiento del VerbosityLevel y basado en el Microsoft Enterprise Library Logging Application Block procederá a escribir registros acorde a la configuración del mencionado Application Block. Los métodos ProcessCallMessage y ProcessReturnMessage se encargarán de crear el mensaje del evento de una manera estandard y pre-establecida (evitando que los desarrolladores decidan el mensaje y rompan con la gobernabilidad).

Lamentablemente la implementación de la clase LogProcessor es un tanto extensa como para ponerla en esta publicación, sin embargo está disponible para descargarse (y estudiarse) justo aquí.

Como cambiar el navegador por defecto en el Visual Studio… sin perder la cabeza!

Los profesionales que trabajamos con el ecosistema de Microsoft y la plataforma .NET solemos estar más que confirmes con el Internet Explorer (excepto el nefasto Internet Explorer 6); sin embargo la mayoría de las veces cuando trabajamos en proyectos web, nuestros clientes nos exigen soportar más de un navegador.

Parte del proceso de soportar más navegadores que el Internet Explorer es que se necesita probar cada página para garantizar su correcto funcionamiento (a nivel de JavaScript) y apropiado renderizado gráfico (a nivel de imágenes, diagramación, estilos y CSS). Lo ideal sería poder probar las páginas directamente desde el Visual Studio, pero cambiar el navegador por defecto que se ejecuta con cada depuración puede llegar a ser algo… laborioso.

En realidad, cambiar el navegador por defecto en el Visual Studio no es difícil, pero tener que hacerlo cada vez que se quiera probar una página o funcionalidad con tres o cuatro navegadores diferentes, entonces empieza a ser un verdadero dolor en… la cabeza.

Algunas personas encontraron mecanismos para automatizar el proceso a través del Windows PowerShell como por ejemplo Scott Hanselman (@shanselman) en este artículo de su blog.

Fue gracias al trabajo de Scott que la gente de Clarius Consulting creó un add-on para el Visual Studio que agrega una nueva barra al menú con botones que permiten cambiar de forma rápida y sencilla el navegador por defecto con el cual queremos trabajar. Esta barra soporta los más nuevos y usados navegadores a parte de Internet Explorer, como por ejemplo: Opera, Safari, Chrome y Firefox.

Este add-on está disponible aquí. Cabe destacar que este add-on es sólo para el Visual Studio 2005, 2008 y 2010, ya que el nuevo Visual Studio 2012 ya incluye esta maravillosa funcionalidad built-in (incluso siendo capaz de levantar y trabajar con más de un navegador a la vez).

Cuando el reto es soportar más de una versión del Internet Explorer, el tema cambia debido a la limitación que tiene Windows de no permitir que diferentes versiones de su navegador convivan en una misma instancia del sistema operativo. Para esos casos en que tenemos que probar contra diversas versiones del IE, no nos queda otra que emplear máquinas virtuales. La parte positiva es que Microsoft sabe de estos escenarios y pone a disposición de la comunidad de desarrolladores y diseñadores web de forma gratuita máquinas virtuales de Virtual-PC con diferentes configuraciones de sistemas operativos y del navegador Internet Explorer. Estas imágenes están disponibles aquí.

Actualización 02-Agosto-2013

Resulta que Microsoft ha movido el tema de las imágenes de máquinas virtuales a un sitio web especializado en el tema de la creación y gestión de aplicaciones web que sean soportadas por varios navegadores. Las imágenes están disponibles en dicho sitio web: http://www.modern.ie/.

Probando el Visual Studio 2012 Release Candidate

Visual Studio 2012

En estos días salió disponible al público adicto al desarrollo en la plataforma .NET la nueva version del Visual Studio 2012, la cual se puede descargar desde aquí. Esta versión ya no está marcada como Beta, sino como Release Candidate; lo cual significa que los próximos releases no tendrán tantos cambios notables como veremos entre esta versión y la anterior Visual Studio 2011 (o quizás me equivoque).

Lo que me gusto…

Cuando estaba en el colegio, para graduarme tenía que presentar una tesis de grado de tópico científico sobre un tema que me apacionara. Ya desde jóven me atraía la computación/informática, así que con mi amigo Juan Carlos Araujo (@JC_Araujo_S) nos dispusimos a crear una aplicación en Visual Basic 6.0 (que estaba recién salido del horno) para crear un sistema que facilitara a los profesores realizar sus actividades del día a día. Una de las características del sistema que diseñamos era emplear un código de colores que a través de su caracter cognitivo permitirera identificar rápidamente en que estado se encontraba el usuario dentro de la aplicación.

Con Visual Studio 2012 vemos justamente ese enfoque de emplear colores para que se pueda identificar rápidamente (casi subconcientemente) en que estado nos encontramos.

En el mismo tono, me encantó que la gente de Microsoft escuchara a la comunidad de desarrolladores, ya que la versión Beta de 2011 era demasiado opaca, plana, de poco contraste y demasiado monocroma. Con la versión 2012 vemos que la iconografía tiene mejor contraste y mayor colorido, sin romper en mi opinión con la filosofía de METRO UI.

El debugger está muy mejorado, sobre todo para trabajar con JavaScript; cosa que asumo es un esfuerzo por parte de Microsoft de ofrecer un IDE para el desarrollo de METRO Apps que son muy basadas en HTML5 y JavaScript. La ventana de “Callstack” para depurar aplicaciones web está muy mejorada, lo cual se agradece.

Otra cosa que me gusta es que la ventana de “Solution Explorer” ahora ofrece más información sobre las características de los archivos y clases, como sus métodos, propiedades y atributos. Sin embargo creo que necesita trabajarse un poco más antes de la versión final.

Lo que no me gusto…

Una de las cosas que me han chocado es la UX. Como desarrollador, trato de maximizar lo más posible el espacio disponible para el código fuente, lo que significa que la mayoría de las ventanas como el “Toolbox”, “Output”, el “Team Explorer” o el “Solution Explorer” las tengo escondidas (que en VS2010 por ejemplo se ven como pestañas) pero disponibles siempre que pase el mouse por encima. Con esta versión, estas ventanas no se ven como pestañas sino como botones planos, y siempre que quiera ver alguna tengo que hacer click sobre estos; lo que significa que tengo que hacer “más” clicks para ser “productivo”.

Estéticamente me sigue pareciendo muy plano. Está mejor que la versión 2011, sin embargo sigue siendo demasiado homogeneo y siento que eso hace que sea confuso o relentizante encontrar la opción funcional que se busca.

Haz click para ver la imagen más grande.

Otra cosa que me chocó es que los menús están en mayúsculas. Aunque es un enfoque que busca acercar más la UI a la filosofía de METRO UI, creo que no es la mejor desición.

Finalizando…

Esta es una versión de Visual Studio que no podemos perdernos. Una versión histórica que nos mostrará que tan lejos puede llegar un IDE dentro de un nuevo mundo Post-PC, para desarrollar aplicaciones móviles y de tablets bajo los nuevos paradigmas táctiles.

Sin embargo creo que la UI y la UX siguen necesitando una mano más de pintura, un poco más de arte y menos de futurism y color plano.

Mi mejor recomendación, es instalarlo en un Windows 8, que casualmente también tiene una nueva versión de pruebas disponible para descargar aquí, y desde el cual he escrito esta publicación.

Finalmente, la gente de Microsoft nos ha dejado una entrada en sus blogs con un completo listado y descripción de los cambios que encontraremos en esta nueva versión.

Un Framework para Programación Orientada a Aspectos (AOP) en C#    Parte 0: Introducción

Este es el primero de una serie de cuatro publicaciones que estaré realizando sobre programación orientada a aspectos en .NET empleando el lenguaje de programación C#.
Mi intención inicial era que la primera parte incluyese una apropiada introducción teórica a la programación orientada a aspectos, adicional a los detalles propios de diseño e implementación de un framework. Sin embargo, la longitud que estaba adquiriendo esta primera publicación me ha obligado a dividirla en dos partes: una parte cero o introductoria con los conceptos y elementos teóricos, y una futura parte uno con el correspondiente detalle técnico de implementación.

Acorde a la Wikipedia la programación orientada a aspectos, o AOP por sus siglas en inglés, es un paradigma de programación cuya intención es permitir una adecuada modularización de las aplicaciones y posibilitar una mejor separación de incumbencias; encapsulando de forma efectiva los diferentes conceptos que componen una aplicación en entidades bien definidas, eliminando las dependencias entre cada uno de ellas.

El principal objetivo de AOP es la separación de las funcionalidades dentro del sistema:

  • Por un lado funcionalidades comunes utilizadas a lo largo de la aplicación.
  • Por otro lado, las funcionalidades propias de cada módulo.

Cada funcionalidad común se encapsulará en una entidad.

Origen y Razón de Ser

La idea de la programación orientada a aspectos surge directamente del paradigma de la programación orientada a objectos (o OOP por sus sigas en inglés), en la cual muchas veces al estar implementando funcionalidades de un aplicativo de tamaño considerable empiezan a aparecer retos y problemas que no son solventables a través de las formas o técnicas habituales. Algunos de estos problemas son:

  • Scattered Code: o código disperso, no es más que líneas de código que están distribuidas por toda o gran parte del aplicativo, y que incrementan de forma considerable la dificultad de las tareas de mantenimiento y desarrollo.
  • Tangled Code: o código enmarañado, es un problema que puede aparecer cuando una misma pieza de código (como un módulo) implementa múltiples comportamientos o aspectos diferentes del sistema de forma simultánea, empleando cláusulas de tipo switch ó if-then-else anidadas.
  • Loss Uniformity: o pérdida de uniformidad, es más un problema de forma y gobernabilidad del desarrollo, que de diseño o implementación. Se basa en que aún cuando el arquitecto de software o el líder técnico haya sentado de manera formal los estándares y convenios de implementación en temas como nomenclatura o mensajes, estos se pierden a lo largo del ciclo de vida del desarrollo del aplicativo. El caso más común son los mensajes de la aplicación para casos como por ejemplo registro de evetos o excepciones, donde por más que exista un lineamiento formal, cada desarrollador puede acabar escribiendo el mensaje acorde a su mejor sentido común. Este fenómeno se encuentra mucho en equipos de desarrollo de alta rotación, en proyectos de duración muy prolongada (superior a dos años) o que son mantenidos por equipos de desarrollo diferentes.

Al final del día, la razón de ser de una AOP es buscar minimizar (o solventar) el desorden que puede aparecer en la arquitectura de un aplicativo desarrollado mediante OOP. Este desorden aparece cuando algo que el sistema tiene que hacer requiere la participación de muchos y variados objetos diferentes, lo cual suele ocurrir por la abstracción de los requerimientos en objetos que realiza el diseñador, quien a menudo pierde de vista el hecho de que en última instancia, dichos objetos van interactuar unos con otros con el fin de cumplir con tales requerimientos.

Lo anterior ocurre con facilidad y de forma subconscientemente, porque la forma fundamental en que interactúan los requerimientos es muchas veces diferente de la forma en que interactúan los objetos.

Los conceptos descritos en los patrones de diseño son un intento de entender formalmente los temas de la interacción de objetos y para proporcionar al diseñador de algunos medios bien comprendidos para resolver este problema de interdependencia. Más aún, la mayoría de las implementaciones de un AOP se apoyan fuertemente en el patrón de diseño observador (u Observer en inglés).

Así, podemos decir a modo de resumen que AOP surge como un paradigma de programación dentro del mismo paradigma de OOP, que no busca sustituir a éste, sino más bien mitigar algunas de sus limitaciones al modularizar todo aquel código de índole transversal en un sistema de software.

Por supuesto que AOP no es la panacea o un hito utópico en la implantación de arquitecturas y en el desarrollo de aplicativos en OOP. Siempre se necesitará de la participación de equipos ágiles de desarrollo, con credenciales, entrenamiento y formación apropiada, experiencia adecuada y un liderazgo eficaz para llevar con éxito un proyecto de desarrollo de software, con o sin el seguimiento de una AOP.

Terminología

Los siguientes son los conceptos que se suelen manejarse en una AOP (según han sido tomados desde la Wikipedia):

  • Aspect (Aspecto) es una funcionalidad transversal (cross-cutting) que se va a implementar de forma modular y separada del resto del sistema, y que en una OOP tradicional, es el causante habitual de código repetido, disperso o enmarañado. El ejemplo más común y simple de un aspecto es el registro de eventos (event logging) dentro del sistema, ya que necesariamente afecta a todas las partes que generan un suceso.
  • Join point (Punto de Cruce o de Unión) es un punto de ejecución dentro del sistema donde un aspecto puede ser introducido, como la invocación o retorno de un método, la ocurrencia de una excepción o la modificación de un campo. El código del aspecto será inyectado en el flujo de ejecución de la aplicación para añadir su funcionalidad.
  • Advice (Consejo) es la implementación del aspecto, es decir, contiene el código que implementa la nueva funcionalidad. Se insertan en la aplicación en los Puntos de Cruce.
  • Pointcut (Puntos de Corte) define los Consejos que se aplicarán a cada Punto de Cruce. Se especifica mediante Expresiones Regulares o mediante patrones de nombres (de clases, métodos o campos), e incluso dinámicamente en tiempo de ejecución según el valor de ciertos parámetros.
  • Introduction (Introducción) permite añadir métodos o atributos a clases ya existentes. Un ejemplo en el que resultaría útil es la creación de un Consejo de Auditoría que mantenga la fecha de la última modificación de un objeto, mediante una variable y un método apropiado a la tarea, que podrían ser introducidos en todas las clases (o sólo en algunas) para proporcionarles esta nueva funcionalidad. Este concepto también es conocido como inyección de código, o injection por su término en inglés.
  • Target (Destinatario) es la clase aconsejada, la clase que es objeto de un consejo. Sin AOP, esta clase debería contener su lógica, además de la lógica del aspecto.
  • Proxy (Resultante) es el objeto creado después de aplicar el Consejo al Objeto Destinatario. El resto de la aplicación únicamente tendrá que soportar al Objeto Destinatario (pre-AOP) y no al Objeto Resultante (post-AOP).
  • Weaving (Tejido) es el proceso de aplicar Aspectos a los Objetos Destinatarios para crear los nuevos Objetos Resultantes en los especificados Puntos de Cruce. Este proceso puede ocurrir a lo largo del ciclo de vida del Objeto Destinatario y del desarrollo del aplicativo:
    • Aspectos en Tiempo de Compilación, que necesita un compilador especial.
    • Aspectos en Tiempo de Carga, los Aspectos se implementan cuando el Objeto Destinatario es cargado a memoria. Requiere un ClassLoader especial.
    • Aspectos en Tiempo de Ejecución.

Contextos en .NET

Cuando entramos en el mundo de .NET y de AOP es necesario explicar un concepto adicional: el de Contextos. En .NET, un contexto es un conjunto de propiedades o reglas de uso que definen un entorno en el que una colección de objetos reside. Las reglas se aplican cuando los objetos entran o salen de un contexto.

Los contextos se crean durante la activación de un objeto. Un nuevo objeto se coloca en un contexto existente o en un nuevo contexto creado con los atributos incluidos en la metadata del tipo que corresponde al objeto activado.

Desde el punto de vista del CLR (Common Lenguage Runtime), un contexto no es más que una de las muchas subdivisiones que puede llegar a tener un app domain. Más aún, cuando un app domain es creado, tiene un contexto por defecto (que justamente se llama default context).

Un contexto funciona básicamente a través de mensajes (objetos que implementan la interfaz IMessage), que se definen como un conjunto de propiedades tales como el nombre del método que se está invocando, sus parámetros (tanto de entrada como de salida) así como cualquier otra característica propia que defina a la invocación. Estos mensajes son recibidos por sumideros (o sinks en inglés, y que son objetos que implementan la interfaz IMessageSink) y encargadas de procesar los mensajes para ejecutar acciones a través de los datos que estos portan.

La idea de contexto es fundamental para desarrollar una AOP en .NET empleado el lenguage C#, ya que es gracias a las clases que permiten decorar objectos como objetos de contexto (tal como ContextBoundObject) que se podrá intervenir en la ejecución de la lógica de éstos para inyectar la funcionalidad de los aspectos que se implementen a través de los mensajes.

Cuando se ejecuta un sistema desde la óptica de la clase ContextBoundObject ocurre lo siguiente:

  1. La invocación a un método se convierte en una instancia de IMessage.
  2. El mensaje pasa a través de una serie de sumideros (objetos del tipo IMessageSink), que son enlazados para formar una cadena (chain) conceptual.
  3. Cada sumidero es capaz de analizar el mensaje y sus características, ejecutando una lógica específica.
  4. De ser necesario, un sumidero puede modificar el mensaje.
  5. Cuando un sumidero finaliza de procesar el mensaje, lo pasa al siguiente sumidero en la cadena conceptual.
  6. Eventualmente la cadena es totalmente ejecutada y el método invocado se ejecuta.
  7. Si el método retorna algún valor (o genera una excepción) la cadena de sumideros se ejecuta nuevamente en sentido revertido.

Un Framework para .NET

Si realizamos una búsqueda en Internet sobre frameworks en .NET para realizar AOP, encontramos muchos productos que ofrecen toda una gama de posibilidades para inyectar contextos dentro del código durante el tiempo de diseño/codificación del sistema, durante su compilación o después de ésta directamente en el MSIL.

Entonces… ¿por qué crear un framework para AOP habiendo tantos productos disponibles?

Pues porque como Arquitecto de Soluciones de Software encuentro siempre reconfortante el poder crear mis propios frameworks sobre los cuales puedo tener un control más fino y delicado, y en los que puedo poner toda mi confianza en que estoy entregando a clientes y compañeros de trabajo productos de calidad que pueden utilizar y extender fácilmente.

Por otra parte, simplemente ocurre que no me convencen los productos que hay actualmente para hacer AOP; no porque sean malos… sino simplemente porque no siguen una aproximación con la que me sienta cómodo, sobre todo porque estos productos suelen ser muy mastodónticos y complejos. De ahí esta iniciativa de crear un framework lo suficientemente minimalista como para ser confortable de emplear y extender, universal para que cada aspecto pueda implementarse independientemente con el apoyo de la tecnología que el desarrollador encuentre más apropiada a sus gustos y necesidades (que en mi caso suele ser apoyarme en los Microsoft Enterprise Libraries).

En la próxima parte de esta serie de publicaciones mostraré los detalles técnicos de diseño e implementación de este custom framework.

Referencias

Así trabajan en… Microsoft Ibérica

Pues navegando por la red me encontré este video de la gente de Silicon News muy interesante y altamente recomendable, realizado por Net Media Europe, y donde la directora de RR.HH. de Microsoft Ibérica cuenta al expectador la filosofía de la empresa respecto a la flexibilidad y características del ambiente de trabajo.

De las imágenes veo muchos elementos que me recuerdan las empresas norteamericanas para las cuales trabajé durante un tiempo, y que ciertamente creo deberían aplicar las empresas en España, sobre todo las de corte tecnológico.

Referencias

Minify JavaScript and CSS files when publishing Web Applications from Visual Studio

One of the best practices to speed up a web site or web application is to minify JavaScript and CSS files; which as a secondary effect, not only reduces the size of those files but also makes them harder to read (something helpful to prevent the stealing of your ideas and efforts).

Intro

You may think that actually this is not very helpful since using external JavaScript and CSS files in the real world generally produces faster pages because they will be cached by the browser. However, if their size is big, you may improve the first request load time by reducing their size.

Minification is the practice of removing unnecessary characters from code to reduce its size thereby improving load times. When code is minified all comments are removed, as well as unneeded white space characters (like newlines or tabs). This improves response time performance because the size of the downloaded file is reduced.

There are many tools to minify JavaScript and CSS files, like for example:

I’m a Microsoft .NET professional, so in this and future post, I will going to focus only on Microsoft’s Ajax Minifier tool.

The proper time to minify

It is not advisable to minify your web application’s JavaScript and CSS files during developing time; it should be done on deployment or publish (for testing or any other purpose) time.

But then, how to minify those files without affecting the original source code in the solution when deploying it?

The answer is quite easy: we must use MSBuild in the web application project file to configure the Microsoft Ajax Minifier to be executed as a task when publishing in ‘Release’ mode.

The steps to minify

The first step is to unload the web application project by right-clicking on it and choose the option ‘Unload Project’. Once unloaded, right-click it again and choose the ‘Edit <web_app_project_name>.csproj’ option, which will open the XML editor of the Visual Studio with the project’s configuration.

What I usually do, is to go to the end of the file and then add the following line just before the closing Project tag:

<UsingTask TaskName="AjaxMin" AssemblyFile="$(SolutionDir)Lib\AjaxMinTask.dll" />
<PropertyGroup>
    <ResGenDependsOn>
        CompressJsAndCss;
        $(ResGenDependsOn)
    </ResGenDependsOn>
</PropertyGroup>

Please note the PropertyGroup tag. It describes the property activity to perform and its dependency with the generation of resources. This is very important to specify.

I prefer the UsingTask tag instead of the Import tag because I work with a lot of people who may have installed the Microsoft Ajax Minifier in different versions or locations that me (or not having it installed at all). So we distribute the solution’s dlls inside a Lib subfolder, that is also under source control. With this mechanism, every body uses the same dlls in the same version and referenced from the same location.

It is very important to take into account that you will need to have the AjaxMinTask.dll and also the AjaxMin.dll in the same location.

The next step is to create a custom target with the following lines:


<Target Name="CompressJsAndCss" AfterTargets="CopyAllFilesToSingleFolderForPackage" Condition="'$(Configuration)'=='Release'">
...
</Target>

The new target is called CompressJsAndCss and will be executed when publishing a web application just after the CopyAllFilesToSingleFolderForPackage target, which is responsible of copying (or materialize in-memory files) the project files into your obj folder (specifically the folder specified by _PackageTempDir) in preparation for a publish.

Next, we need to gather the files suitable to be minified, in this case, JavaScript and CSS files. To do so, just add the following lines to the custom target:


<ItemGroup>
      <JS Include="$(_PackageTempDir)\**\*.js" Exclude="$(_PackageTempDir)\**\*.min.js" />
      <CSS Include="$(_PackageTempDir)\**\*.css" Exclude="$(_PackageTempDir)\**\*.min.css" />
</ItemGroup>

As you can see, we’re creating a set of all available JavaScript and CSS files in the _PackageTempDir folder (where the CopyAllFilesToSingleFolderForPackage put the files for the publication) but excluding those with extension .min.js or .min.css which are already minified (usually jQuery files).

Finally, we must call the Microsoft Ajax Minifier task in order to minify the gathered files with the following lines:


 <AjaxMin JsKnownGlobalNames="jQuery,$" JsSourceFiles="@(JS)" JsSourceExtensionPattern="\.js$" JsTargetExtension=".js"
          CssSourceFiles="@(CSS)" CssSourceExtensionPattern="\.css$" CssTargetExtension=".css"/>

Note that we’re informing the Microsoft Ajax Minifier to respect the ‘jQuery’ and ‘$’ literals on the JavaScript files since they are well know global names that must not be modified in the minify process.

At the end, we should have the following added configuration:


<!-- Minify all JavaScript and CSS files that are present on this web application when publish in release. -->
  <UsingTask TaskName="AjaxMin" AssemblyFile="$(SolutionDir)Lib\AjaxMinTask.dll" />

  <!-- This target will run after the files are copied to PackageTmp folder (usually 'obj\Release\Package\PackageTmp') -->
  <Target Name="CompressJsAndCss" AfterTargets="CopyAllFilesToSingleFolderForPackage" Condition="'$(Configuration)'=='Release'">
    <ItemGroup>
      <JS Include="$(_PackageTempDir)\**\*.js" Exclude="$(_PackageTempDir)\**\*.min.js" />
      <CSS Include="$(_PackageTempDir)\**\*.css" Exclude="$(_PackageTempDir)\**\*.min.css" />
    </ItemGroup>
    <Message Text="Compressing JavaScript and CSS files..." Importance="high" />
    <AjaxMin JsKnownGlobalNames="jQuery,$" JsSourceFiles="@(JS)" JsSourceExtensionPattern="\.js$" JsTargetExtension=".js"
             CssSourceFiles="@(CSS)" CssSourceExtensionPattern="\.css$" CssTargetExtension=".css"/>
  </Target>

So what is left to do is to save the csproj file, close it and right-click on it from the Solution Explorer and choose the ‘Reload Project’ option in order to load it again in the solution.

Now when we go to publish the web application (and in ‘Release’ mode) our custom target will be evaluated just after the CopyAllFilesToSingleFolderForPackage target, and all JavaScript and CSS files will be minified without affecting the original ones.

References