miércoles, 22 de julio de 2015

9. Patrones (II) - Decorator

El código salvaje crece de una manera incontrolada, esto hace que en muchos casos se pierda el control del mismo, y en casos extremos se tengan que hacer completos proyectos que si bien en su fase de diseño fueron muy buenos, con una arquitectura estable, conforme se van agregando nuevas funcionalidades y más desarrolladores modifican el código, estos se convierten en verdaderos monstros de Frankenstein.

Muchas piezas de código operando para crear nuevas funcionalidades, y en ciertas ocasiones por no conocer el sistema, estas hacen que el sistema sea inestable.

El tiempo de desarrollo se incrementa, la calidad baja, y de la misma forma baja la satisfacción del cliente.

Pero, ¿Hay alguna forma de modificar funcionalidad que sea no tan dolorosa?

Vamos a platicar de un patrón de diseño que es para esto, su nombre es Decorator, y se emplea para añadir de manera dinámica funcionalidad a un objeto, de esta forma podemos incrementar las características del objeto, sin que esto nos represente un cambio doloroso.

Eso si hay que cambiar un poco nuestra mentalidad para usarlo, y pensar más en términos del patrón
Su principal característica, es que nos permite agregar de manera incremental responsabilidades, el patrón lo aplicamos como si fueran capas y las capas nos brindan nuevas características, imaginemos que es una perla que se está creando y cada capa es una aplicación del patrón.

Este es un patrón estructural y lo podemos usar durante el diseño, mantenimiento o extensión de funcionalidad.

Podemos representar el patrón de la siguiente forma


Sin embargo creo que esto lo podemos ilustrar mejor con un poco de código.

Imaginemos esto somos una fábrica de carros, y vamos y vamos a ponerle el radio a uno de nuestros carros, así que crearemos una interfaz en la cual se encontrara el método encender radio

namespace decorator01
{
    public interface ICarro
    {
        void EncenderRadio();
    }
}

El radio lo vamos a implementar en nuestro modelo básico

public class CarroEstandar : ICarro
    {
        public void EncenderRadio()
        {
            Console.WriteLine("Radio FM - Mono");
        }
    }

Como se puede ver el modelo básico cuenta con un Radio FM con sonido mono aural, bueno viene un nuevo modelo, en el cual se requieren mejoras a este radio, así que tomamos el modelo básico y lo mejoramos

  public class CarroMejorado : ICarro
    {
        ICarro CarroBase;

        public CarroMejorado (ICarro I)
        {
            CarroBase = I;
        }
   
        public void EncenderRadio()
        {
            CarroBase.EncenderRadio();
            Console.WriteLine("Radio Satelital");
        }
}

Ahora el radio cuenta con una nueva función, sin perder la primera, si tuviéramos otro modelo, podemos crearlo ahora partiendo de cualquiera de los modelos anteriores.

public class CarroBlindado : ICarro
    {
        ICarro CarroBase;

        public Boolean DobleBlindado { get; set; }

        public CarroBlindado(ICarro I)
        {
            CarroBase = I;
        }

        public void EncenderRadio()
        {
            CarroBase.EncenderRadio();
            if (DobleBlindado == true)
            {
                Console.WriteLine("Audio Alta calidad");
            }
            else
            {
                Console.WriteLine("Audio Especial");
            }
        }
    }

Construyamos ahora nuestros carros:

class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Construyendo carro estandar");
            CarroEstandar cr1 = new CarroEstandar();
            cr1.EncenderRadio();

            Console.WriteLine("Construyendo carro Mejorado");
            CarroMejorado cr2 = new CarroMejorado(cr1);
            cr2.EncenderRadio();

            Console.WriteLine("Construyendo carro blindado");
            CarroBlindado cr3 = new CarroBlindado(cr2);
            cr3.DobleBlindado = true;
            cr3.EncenderRadio();

            Console.ReadLine();
        }

Al iniciar la producción vemos lo siguiente



Como podemos observar se puede agregar funcionalidad de manera dinámica de una forma mucho más libre que empleando la herencia


Di no al código salvaje

martes, 21 de julio de 2015

8. Base de datos

Yo siempre lo he dicho el desarrollo va mucho más allá de hacer un ABC (Alta, Baja, Cambios), pese a que estamos en una época en la que la información existe disponible para todos, el desarrollo va más allá de eso.

Pero eso no quiere decir que un desarrollador debe ignorar la base de dato, o que debe saber lo mínimo de ella.

Si bien la administración de la misma pasa a manos de un DBA ,y quizás por orden exista un responsable de la base a nivel de desarrollo, todos los desarrolladores deben conocerla, ya que es parte de del todo que es la aplicación en la que están trabajando.

Pero no es solo conocerla, sino hay que conocer las reglas de la misma, es un error dar 2 pesos diferentes a la codificación de una aplicación y a una codificación en base de datos un store procedure, ambos tienen el mismo peso, ambos forman parte de la aplicación, si unoestá mal, es incorrecto, es lento el todo que es la aplicación fallara.

El desarrollador debe conocer las relaciones, los índices las restricciones, y aplicarlas, esto garantiza que se tenga una correcta funcionalidad, debe ver los planes de ejecución, analizarlos para que aquello que entregue sea un desarrollo de calidad.

El hecho de que un desarrollador no conozca su base de datos o diga que no requiere conocimientos sobre la misma, hace que su producto por tenga graves deficiencias ya que creara cuellos de botella, y problemas que en muchas ocasiones no serán visibles de primeraintención, lo mejor es tener desarrolladores completos, con el conocimiento para entrar en varias áreas y ver el sistema como lo que es.

Un todo.

Reiterando nuevamente no todo en la vida es un ABC

Hasta pronto

lunes, 20 de julio de 2015

7. Programar en paralelo (I)

A partir de .Net 4.0 llego a su madures la programación en paralelo por .net, la posibilidad de efectuar múltiples operaciones en forma simultánea con la finalidad de reducir tiempos, y emplear mejor los recursos de sistema.

El nuevo modelo nos permite emplear de forma simultanea los núcleos del procesador, anteriormente se requería un manejo a un nivel más bajo para lograr que las tareas se distribuyeran en forma paralela, hoy esto no es necesario.

Pero antes de considerar el uso de las funciones de .Net para programar en paralelo tenemos que hacer unas consideraciones.

¿Cuáles serán los recursos en los que se empleara la programación en paralelo?

Al emplear este tipo de programación se debe considerar que si el recurso no soporta cierta cantidad de peticiones, el rendimiento en vez de incrementarse puede verse afectado, esto es por ejemplo mandar un gran número de peticiones a una base de datos, o escritura a un disco.

¿Realmente será perceptible el cambio?

Si la cantidad de peticiones es tal que al emplear este tipo de programación se vea un cambio perceptible en el rendimiento, hay que usarla, pero si el cambio no es perceptible, no es conveniente incrementar la complejidad del código.

Bueno y como se emplea, el modelo más sencillo de programación en paralelo es la invocación de más de una función en el mismo instante de tiempo.

Para ello emplearemos Task Parallel Library, esta se encuentra dentro del espacio de nombres System.Threading.Tasks.
 
Y su invocación es tan sencilla como:
 
Parallel.Invoke(() => Tarea1(), () => Tarea2());
 
Lo mas interesante de esto es que podemos enviar la cantidad de tareas en paralelo que deseemos
 
Parallel.Invoke(() => Tarea1(), () => Tarea2(), ()=> … TareaN());
 
Sin embrago siempre estamos limitados por los recursos del equipo, un gran número de proceso paralelos puede tener como consecuencia que el sistema baje su rendimiento.

Otro punto muy importante, por lo regular los equipos productivos tienen una potencia mucho mayor que los equipos de desarrollo, por tal motivo cuando se construye un proceso en paralelo se debe tener esto en mente.


Hasta la próxima semana.

jueves, 9 de julio de 2015

6. Pensamiento Mágico, ayuda divina

Una actividad interesante, que debería desaparecer de nuestra mente, es emplear el pensamiento mágico de que solo se va a arreglar algo, si se arregla solo es que hay algo mal, algo esta tan inestable que el solo volverlo a hacer hace que funcione.

¿A qué se debe ese pensamiento mágico?, podríamos adjudicarlo a muchas cosas desde la inseguridad de que los pasos que se efectuaron son los correctos o la falta de conocimiento sobre cómo opera una aplicación.

Qué caso tiene hacer 100 veces la misma operación esperando que por pura casualidad en la 97 funcione, la computadora sigue una serie de pasos, específicos que no debería cambiar por ejecutar nuevamente una operación.

Pero, ¿Qué pasa si esto ocurre?, entonces no es que el programa se arreglara por sí solo, lo más probable es que exista un problema en la inicialización de algún objeto.

Ahora me dirán, es que la primera vez fallo, pero luego continuo, en este caso puede ser algún archivo temporal que sea necesario para que opere su programa.

Es común que digan reinicia y funciona, y esto en muchos de los casos es cierto, pero si esto ocurre realmente de lo que hablamos es de una inestabilidad del sistema operativo.

Es importante entender que nada se soluciona por arte de magia y menos en un mundo en el que todo se reduce a bits, a unos y ceros, en donde sí a la computadora se le dice enciende, esta enciende, 

Cuando un sistema esta inestable se debe hacer un análisis completo, de que estamos haciendo, cual es el flujo que sigue, esto nos ayudara a tener una mayor calidad en nuestros programas.

Hay que ser curiosos y no confiar en la solución mágica.


Hasta pronto

viernes, 3 de julio de 2015

5. Herramientas - Mi propio NuGet



Divide y vencerás es una frase muy común en muchos de los entornos en los que nos desarrollamos, y en el software es algo que tiene una gran verdad, el hecho de que yo trabaje con componentes altamente especializados me ayuda a erradicar rápidamente errores y nos permite que el código sea altamente reutilizable.

Uno de los grandes problemas que ha existido a través del tiempo es como organizo mis versiones de código, para que de una manera sencilla los cambios en estos módulos especializados puedan llegar a los proyectos de mayor tamaño.

Bueno ante esto podemos hacer uso de la herramienta de administración de Paquetes llamada NuGet, NuGet es un administrador de paquetes de código abierto que trabaja sobre Visual Studio a partir de la versión 2010.

¿Qué tipos de archivos podemos poner en nuestra solución?

Prácticamente cualquier tipo de archivo, incluso en diferentes versiones de Framework dándole la posibilidad de emplear la dll en múltiples proyectos.

NuGet me permite que yo publique en la red mis dll pero también las puedo publicar en una red local, dentro de una carpeta compartida y que las consuman dentro de mi organización.
Para ello tengo que hacer lo siguiente:

1.       Descargar el NuGet Package Explorer desde la siguiente ruta:  https://npe.codeplex.com/, esta herramienta me permite generar los packetes de NuGet

2.       Al abrirlo me muestra esta pantalla:


3.       Se selecciona Create a new package

4.       Esto nos muestra la siguiente pantalla



5.       Se debe seleccionar el botón edición para editar las características del paquete


6.       Agrega la o las dll al proyecto



7.       Selecciona guardar como… y guarda este módulo en la carpeta que en que se creara tu NuGet personal.




8.       Ahora es necesario que visual studio conozca la ruta, inicia Visual Studio

Ve a Herramientas -> Administración de paquetes NuGet -> Configuración del administrador de paquetes.




9.       Y una vez dentro se selecciona la ruta en donde se encuentra nuestro paquete.



10.   Cuando buscamos el paquete este ya lo podemos usar en todos nuestros proyectos, es muy importante que se maneje el número de versión cada vez que se tengan nuevos dll ya que de esta manera NuGet tendrá la forma de asignar la nueva versión




Nos leemos pronto

miércoles, 1 de julio de 2015

4. Patrones de diseño

Un código bien diseñado, puede ser reusado con facilidad en otros proyectos,  adaptado para necesidades futuras y este operara de una manera correcta.

Pero que pasa en la programación salvaje, muchos códigos se diseñan para cumplir con un cliente específico, se tiene miedo a reutilizarlos porque se teme a que en algún momento se modifiquen y se pierda la funcionalidad original, el componente pertenece a otro más grande y reutilizarlo llega a ser complicado por el nivel de acoplamiento entre clases.

La gran cantidad de programadores que modifican un código y la poca o nula capacitación hace que cada uno de ellos implemente en sus proyectos funciones que anteriormente ya se implementaron.

Y bueno si supero esos obstáculos ¿Cómo logro hacer un código flexible que pueda emplear en múltiples proyectos y que realmente cumpla con la característica de ser reutilizable?

Un método para lograr esto es la implementación de patrones, por desgracia en .net existe muy poca gente que hace uso de ellos, a veces por tiempo, otras por desconocimiento, o porque en su organización no existen reglas para ello.

Un patrón de diseño es una solución que ya ha sido probada y que cuenta con una efectividad probada.

Así pues desde 1990 se han creado un conjunto de patrones de diseño, que permiten hacer software de mejor calidad.

En ese 1990 se recogieron 23 patrones de diseño estos fueron agrupados en la literatura por Erich Gamma, Richard Helm, Ralph Johnson,y John Vlissides, hoy son el conjunto básico de patrones que deberíamos conocer todos los desarrolladores, estos 23 patrones se dividieron en 3 grupos creacionales, estructurales y de comportamiento.

Existen 7 patrones estructurales que son:


  • ·         Decorator
  • ·         Proxy
  • ·         Bridge
  • ·         Composite
  • ·         Flyweight
  • ·         Adapter
  • ·         Facade

Existen 5 patrones creacionales


  • ·         Prototype
  • ·         Factory Method
  • ·         Singleton
  • ·         Abstract Factory
  • ·         Builder

Y existen 11 patrones de comportamiento


  • ·         Strategy
  • ·         State
  • ·         Template Method
  • ·         Chain of Responsibility
  • ·         Command
  • ·         Iterator
  • ·         Mediator
  • ·         Observer
  • ·         Visitor
  • ·         Interpreter
  • ·         Memento

La calidad que se obtiene en un código de programación mejora cuando el desarrollador ocupa dichos patrones, ya que con esto se logra una verdadera estandarización en la codificación, y con ello acabaremos con esa programación salvaje.