Archivo de la categoría: Development

Servicios de almacenamiento en Microsoft Azure: Colas

Muchos son los servicios de Microsoft Azure tanto para PAAS, SAAS cómo para IAAS. En este post me voy a centrar en una pequeña parte de PAAS cómo son los servicios de almacenamiento en esta paltaforma.

Este servicio proporciona varias soluciones,

Blobs: Almacenamiento de grandes bloques de texto o ficheros de gran tamaño; texto, vídeos, audio e imágenes accesible fácilmente mediante una API REST.

Tablas: Almacenamiento NOSQL para datos preparado para que se puede escalar automáticamente y dar cabida a una enorme cantidad de datos. Los datos son accesibles mediante cualquier lenguaje de programación .net, java, node.js, python, rest…

Colas: No son mas que un sistema de almacenamiento FIFO (First In First Out) donde podemos guardar mensajes que debe ser procesadas en segundo plano o en un momento concreto y diferente del proceso principal.

Cabe destacar que todos los servicios de almacenamiento de Azure nos permiten tener una redundancia de datos local (varias réplicas en la misma región), redundancia de datos geográfica (varias réplicas en diferentes regiones)  para dar más eficiencia en la trasferencia de datos y su durabilidad.

Cómo toda interacción con Azure, es sencillo su uso aunque debemos tener en cuenta varios aspectos. Lo primero que haremos será conectar y crear un cliente para conectar con nuestra cola de Azure,

CloudStorageAccount storageAccount = CloudStorageAccount.Parse(CloudConfigurationManager.GetSetting("StorageConnectionString"));
CloudQueueClient queueClient = storageAccount.CreateCloudQueueClient();
CloudQueue queue = queueClient.GetQueueReference("nombredelacola");

Estas líneas anteriores nos permiten tener conexión con nuestra cuenta de Storage de Azure, tener un cliente para la conexión con ella y un cliente para manejar la cola. Para manejar la inserción de datos en ella debemos tener en cuenta algunos campos,

Dequeue Count: Número de veces que el mensaje ha sido leído de la cola.
Expiration Time: Momento en el que el mensaje expirará y será eliminado automáticamente por Azure.
Next Visible Time: Momento en el que el mensaje dejará de ser invisible y volverá a poder ser leído al obtener el siguiente mensaje de la cola.
Message: El mensaje con su contenido dentro de la cola.

CloudQueueMessage msg = new CloudQueueMessage("RowKey: 1, RowValue: 55, Action: Send");
queue.AddMessage(msg);

El mensaje es totalmente personalizado, es decir, el Message que hemos creado con “RowKey: 1, RowValue: 55, Action: Send” es porqué el lector de la cola sabrá interpretar este mensaje y podría ser totalmente otro formato y de mayor tamaño, por ejemplo, “PK:1#Value:55#Accion:S” u cualquier otro. Además el Message puede ser texto o byte[] por lo que podréis decidir que almacenar en él.

Si no se especifica parámetros en el Expritation Time ni en el Next Visible Time estos son el de 60 minutos para el primero y un DateTime.Now para el segundo.

Para obtener los mensajes de la cola únicamente es necesario hacer un GetMessage,

CloudQueueMessage msg = queue.GetMessage();

El GetMessage permite pasar cómo parámetro un TimeStamp que es el tiempo que va aparecer oculto el mensaje en la cola y nadie podrá leerlo, si no se especifica ningún tiempo el mensaje leído permanece 3 segundos oculto de la cola.

Tenemos que gestionar un aspecto muy importante, la visibilidad del mensaje.  La lectura de un mensaje no destruye el mensaje y puede ser leído desde diferentes sitios u otra vez por el mismo desencolado y puede ser un problema. Esto es debido a que un mensaje al ser leído es ocultado pero no eliminado por si sucede algún error en la lectura de ese mensaje, en caso de error, el mensaje volvería aparecer en la cola para ser procesado otra vez.

Por eso, es muy importante gestionar el tiempo de ejecución de las tareas y tener en cuenta el tiempo en que es invisible una tarea (un mensaje). Un mensaje debe ser eliminado de la cola únicamente cuando esta se ha procesado correctamente o cuando su Dequeue Count sea de un valor especificado, es decir, lo hemos leído demasiadas veces.

Si procesamos un mensaje y este no se ha podido procesar o no es su momento; imaginar una cola que debe ejecutar el mensaje en un momento determinado y al procesar su verificación determina que precisa un minuto más. Lo que debemos hacer es actualizar el mensaje,

queue.UpdateMessage(msg, TimeSpan.FromSeconds(60), MessageUpdateFields.Visibility);

Esta actualización lo que hace es realizar una actualización en el mensaje y le indicamos que queremos que durante un minuto más ese mensaje no sea visible y por lo tanto, hasta pasado ese tiempo no se podrá obtener y su Dequeue Count augmentará en una unidad. Esta también lo hara por cada GetMessage.

Como veis el último parámetro es una enumeración que es Visbility o bien Content dónde indicamos si estamos cambiando el contenido del mensaje o bien la visibilidad. En este caso la visibilidad.

Cuando el mensaje sea procesado y la tarea ejecutada correctamente, debemos eliminar ese mensaje de la cola para que no vuelva a ser procesado,

queue.DeleteMessage(msg);

Bien, con esta explicación, podemos gestionar de forma muy fácil, sencilla y rápida nuestra cola mediante un WebRol con una tarea en segundo plano que gestione la cola en de Microsoft Azure.

Este sistema es altamente recomendable en sistemas con muchas usuarios dónde necesitamos procesar tareas en segundo plano, que tengan una complejidad de procesamiento alta o bien necesitemos que esas sean procesadas y escalables rápidamente y de forma seguro.

Happy enqueue & dequeue! :)

El uso de Data Transfer Objects (DTO’s)

En muchas de nuestras aplicaciones, estamos usando ORM cómo Entity Framework. Los objetos (clases) de nuestra modelo E/R (DB) son mapeados mediante un modelo orientado objeto que representa sus relaciones físicas en formato lógico.

Estos objetos, que se pueden abstraer cómo entidades POCO de este ORM, pueden llegar a contener muchas relaciones entre los diferentes objetos dependiendo de la complejidad de nuestro modelo E/R.

En las tecnologías visibles para nuestros usuarios, es decir, las interfaces de usuario (UI) cómo puede ser ASP.NET MVC, Aplicaciones móviles… entre otros, necesitamos dar una experiencia rica, ágil y rápida teniendo en cuenta que en muchas ocasiones nuestro modelo de datos es complejo y la interfaz del usuario es sencilla.

Justo en este momento es dónde entran en contexto los Objeto de transferencia de datos (DTO con sus siglas en inglés) dónde nace (no es nuevo, este concepto lleva años con nosotros pero gana peso en las aplicaciones actuales :)) con el objetivo de minimizar el coste de la comunicación entre procesos y por lo tanto, la transferencia de datos entre estos en cada una de sus llamadas cliente – servidor minimizando así su tiempo de respuesta y transportando únicamente los datos necesarios para la operación destino.

La diferencia entre los objetos DTO y los objetos de negocio es que los primeros únicamente tienen el comportamiento de transformar los datos desde el origen y entregar los datos a su destino. Estos objetos son simples y sin lógica de negocio, es decir, son objetos que no están contenidos en nuestro dominio si no que se nutren de su resultado.

A la conclusión que podemos llegar es que si usamos las entidades POCO cómo DTO nos saltamos justo la S (SPR) de los principios SOLID que os explicava en un anterior post y le damos 2 responsabilidades diferentes a nuestro objeto: sirve de entidad del ORM y por otro de transferencia de datos.

Además darle dos responsabilidades a un objeto, obligas a que los procesos envíen gran parte la información que almacenas en la base de datos, y quizá solo hace falta una parte de esa información. Y con eso estarás enviando demasiada o poca información creando procesos muy poco eficientes.

¿Cuándo se debe usar DTO?
– Cuándo debamos reducir el nombre de llamadas al servidor.
– Cuándo debamos considerar el rendimiento y la latencia de las comunicaciones de la red.
– Cuándo debamos minimizar la transferéncia de datos.

¿Cómo se usan los DTO?
Los DTO no son mas que clases sencillas con propiedades get y set. Estas clases son llenadas en desde la capa de aplicación que estas obtienen los datos desde el repositorio a través de una llamada a nuestra DB.

Los DTO deben ser definidos en una librería a parte dentro de nuestro dominio pero sin formar parte de él pues carecen de comportamiento y en una capa superior, dónde recibimos la respuesta de la aplicación, debemos realizar la conversión de nuestra respuesta de entidad POCO a nuestro DTO.

Para ello podemos usar diferentes métodos pero en .NET y con las últimas versiones podemos usar dos formas de hacer esta conversión,
– La primera de ellas es mediante Automapper que es una librería que es capaz de convertir un objeto a otro mediante un mapeo (Lo podéis instalar mediante Nugget). Si en ambos objetos, las propiedades get y set tienen el mismo nombre, el mapeo es muy sencillo pero si no, nos permite manejar esa conversión de forma muy sencilla.

public static ContactDto Binding(Contact contact)
{
  ContactDto contactDto = new ContactDto();
  Mapper.CreateMap<Contact, ContactDto>()
        .ForMember(c => c.Name, dto => dto.MapFrom(co => co.Person.Name))
        .ForMember(c => c.FirstName, dto => dto.MapFrom(co => co.Person.FirstName))
        .ForMember(c => c.LastName, dto => dto.MapFrom(co => co.Person.LastName))
        .ForMember(c => c.Gender, dto => dto.MapFrom(co => co.Person.Gender))
        .ForMember(c => c.IdPerson, dto => dto.MapFrom(co => co.Person.IdPerson))
        .IgnoreAllNonExisting();
  Mapper.AssertConfigurationIsValid();
  contactDto = Mapper.Map<Contact, ContactDto>(contact);
  return contactDto;
}

A grandes rasgos, lo que nos permite hacer el objeto Mapper es crear un mapeo entre dos clases (Contact y ContactDto), le indicamos mediante .ForMember cómo debe ser la conversión (solo es necesario si es diferente) y le indicamos que IgnoreAllNonExisting, es decir, que no mapea lo que no exista. Finalmente hacemos un AssertConfigurationIsValid  que nos devuelve una excepción si no puede hacer la conversión.

Para terminar, hacemos el Map y obtenemos nuestro DTO con los datos que vamos a usar o representar y descartamos el resto.
En otro post, explicaré cómo usar Automapper a fondo pues da para escribir más de un post.

– La segunda de ellas, es mediante una consulta Linq to Objects y escojer que queremos devolver y que no.

var report = await _ourLayerApplication
.Contact
.Where(cnt => cnt.SequenceNumber == contactCode)
.Select(cnt => new ContactDTO
{
  Name = cnt.Person.Name,
  FirstName = cnt.Person.FirstName,
  LastName = cnt.Person.LastName,
  Gender = cnt.Person.Gender,
  IdPerson = cnt.Person.IdPerson
}).SingleOrDefaultAsync();

¿Cuál usar?
Personalmente, ambas formas nos proporcionan la misma potencia aunque al estar contextualizado en el entorno de EF y .NET la segunda forma no necesita del uso de librerías de terceros y la primera, debemos usar una librería externa y que a nivel de rendimiento, no nos oferecerá el mismo rendimiento que una consulta Linq to objects nativa de .NET.

En todo caso y resumiendo, lo que no debemos hacer es devolver los objetos obtenidos mediante consultas a la DB si usamos ORM cómo EF pues contienen sus relaciones y estas, pueden ser complejas, pesadas y transmitir datos que no son necesarios para nuestra aplicación, sobretodo, si su destino son entornos que deben ser fluidos cómo la web, el cloud y las app.

A desarrollar :)
Saludos!

Principios ‘SOLID’

En mi anterior entrada dónde hablaba de la importancia de tener una buena arquitectura de nuestra solución hacía hincapié en que escojamos lo que escojamos debe ser solida y robusta capaz de responder a evoluciones y a una facilidad en el momento de su mantenimiento.
Todo ello se resume con un desacoplamiento (separación, disgregación) entre nuestras capas de la solución.

Este desacoplamiento entre nuestras capas debe tener presente una serie de principios de diseño fundamentales que nos ayudaran a crear una arquitectura que se ajuste a prácticas demostradas que minimizan el mantenimiento y maximizan su evolución. Estos son los principios de diseño ‘SOLID’.

Single Responsability Principale (Principio de responsabilidad única)
Open Close Principale (Principio de abierto – cerrado)
Liskov Substitution Principale (Principio de subsitución de Liskov)
Interface Segregation Principale (Principio de segregación de Interface)
Dependency Inversión Principale (Principio de Inversión de dependencia)

Todo ello, nos proporcionará un bajo acoplamiento, alta cohesión y una alta encapsulación de nuestras capas.
Vamos a sintetizar, conceptualmente, cada uno de ellos y en otro post veremos un ejemplo de cada uno de los principios,

Principio de responsabilidad única (SRP) se basa en que una clase sólo debe tener una única responsabilidad o caraterística para cambiar.

Principio de Abierto – Cerrado (OCP) nos dice que las clases deben ser extensibles sin requerir modificación en la implementación de sus métodos internos. Esto se consigue mediante la abstracción.

Principio de sustitución de Liskov (LSP) nos indica que una clase que implemente una interfaz o herede de una clase base debe poder ser reemplazable por su clase base.

Principio de segregación de la interface (ISP) nos dice que los consumidores de nuestras clases no deben estar forzados a implementar interfaces que no utilizan. Las interfaces demasiado grandes deben dividirse en varias para que cada una de ellas sea implementada por distintos tipos de clientes.

Principio de Inversión de dependencias (DIP) se enfoca en darnos a entender que las dependencias directas entre módulos deben ser reemplazadas por interfaces (abstracciones) y estas no deben depender de los detalles.

En resumen, estos cinco principios conceptuales resumidos con este acrónimo introducido por Robert C. Martin, representa unos principios básicos de la programación orientada a objetos.
Si los aplicamos, es más probable que nuestro sistema sea fácil de mantener y ampliar a lo largo del tiempo con un código limpio evitando la refactorización de nuestro código fuente.

En los siguientes post voy a dedicar ejemplos concretos con cada uno de ellos.
Happy architect! :)

Novedades de Visual Studio 2013 (II)

En mi anterior entrada ya explique algunas de las novedades del nuevo IDE de Microsoft. Con este IDE, tenemos la incorporación de .NET Framework 4.5.1 que incorpora mejoras relacionadas con el trabajo del código fuente y que veremos detalladas a continuación,

Editar y continuar: anteriormente ya podíamos editar el código fuente de nuestro software mientras hacíamos debug y ver que pasaba según la modificación realizada. Con la evolución de los ordenadores a 64 bits y siendo la gran mayoría de ellos de 64 bits, esta opción la mayoría no la pudo ni probar debido a que únicamente estaba habilitado para 32 bits desde el 2005.
En esta versión, por demanda popular con más de 2600 votos, esto funciona para 32 bits y 64 bits para WPF, Windows Phone, aplicaciones de la tienda y ASP.NET.
De esta forma podemos modificar el código fuente sin detener el debug y ver que sucede después.

Devolución de valores en los métodos: Para ver el valor retornado de un método anteriormente debíamos declarar una variable del tipo devuelto y poner un punto de interrupción para ver que sucedía. Ahora esto no es necesario gracias a que desde la ventana de inmediato y de autos podemos ver el valor devuelto de nuestro método mediante $ReturnValue.

ReturnValue

Async debugging: Depurar tareas asíncronas, hilos… siempre ha sido complicado debido a que todo era asíncrono y los hilos principales seguían su ejecución. Los hilos en background podían producir excepciones complicadas de detectar o de trazar.
En esta versión, tal y cómo nos muestra la imagen comparativa, nos es mucho mas fácil de debugar las tareas asíncronas con las nuevas herramientas del IDE. Nos permite ver al completo la Stack de trazas síncronas y asíncronas además de un panel especifico para las tareas en background.

AsyncDebug

Y esto es todo de momento para esta entrada 😉
Un saludo y happy IDE!!

Novedades de Visual Studio 2013 (I)

Es público que soy un enamorado del entorno de programación de Microsoft, pero el fruto de esa relación, no ha sido más que una caja de sorpresas productivas desde su primera versión a la actual. Su primera versión fue en 1995 aunque la primera versión que incorporó .NET 1.0 no fue hasta 2002. Por ese entonces, yo aún no usaba estos entornos de desarrollo integrado (IDE) pero fue a mediados de 2002 cuándo por internet conocí esta plataforma de programación.

Desde ese momento, hasta la actualidad, siempre ha venido lleno de sorpresas pero en esta última versión y en mi opinión, es la evolución más buena que ha tenido. Trae muchas novedades, la mayoría para los programadores que mejoran la productividad en el momento en el que escribimos código.

En este post, a parte de una introducción algo nostálgica y primero de la serie de tres, explicaré las novedades que nos han llegado.

IDE Conectado

Tan solo arrancar, nos ofrece la posibilidad de configurar nuestra cuenta Microsoft. Esto nos permite iniciar sesión en nuestro entorno y sincronizar todas las instalaciones de Visual Studio con nuestros settings personalizados. Es decir, que el entorno de trabajo puede ser el mismo que el entorno de casa y también el de la universidad; ¡en todos los ordenadores dónde desarrollemos!

Barra de scroll mejorada

En la ventana de edición de código, se nos ofrecen una magnifica scroll vertical que podemos configurar según nuestra necesidad. En ella podemos ver los puntos de interrupción que tenemos, los niveles de profundidad de nuestro código, errores en las líneas, posición del cursor y además, una pre visualización de nuestro código sin necesidad de navegar hacia él.


 

Buscador integrado

Siempre hemos tenido un buscador en nuestro editor de código, pero esta vez lo tenemos completamente integrado en nuestro editor y lo podemos usar mientras vamos escribiendo nuestro código.

En esta captura que adjunto podemos ver el buscador, la palabra que he buscado y con ayuda de nuestra scroll ver dónde ha encontrado las coincidencias y poder navegar a ellas.

La edición de código

Muchas son las novedades que incorpora esta sección; Peek Definition, Finalización automática de llave, Line Up and Down y Code Lens.

– Peek Definition: Puedes ver la definición de una clase, método o propiedad de forma ágil sin salir de dónde estas. Puedes acceder a ella mediante ALT + F12 o bien con el botón derecho e ir Peek Definition o Ver la definición.

Además, de un primer nivel de profundidad puedes acceder al siguiente y este te va paginando la navegación para poder ver todos los niveles de profundidad y ver las llamadas que se realizan entre clases o capas. Lo que hace es abrir un popup en el editor de código por dónde te puedes mover sin perder el contexto.

– Finalización automática de llave: ¡Nos añade automáticamente caracteres de cierre y apertura de secuencia! Esto significa que al escribir un if automáticamente nos introduce el símbolo “(” y “)” además de “{” y “}” para poder completar más rápidamente nuestro código.

Los símbolos soportados son la llave {, el corchete [, el paréntesis (, la comilla simple ‘ y la comilla doble.

– Subir y bajar líneas de código: Mover hacia abajo o hacia arriba líneas de código dentro o fuera del método dónde están. Solo se debe ubicar el cursor encima de la línea que queremos mover y hacer ALT + Flecha hacía arriba o Flecha hacía abajo.

– Code Lens: Si trabajas en equipo y con un TFS, es la mejor novedad para todo ello. Esta funcionalidad nos da mucha información de cada función; el número de modificaciones, el número de referencias a este método desde nuestro código, el número de test unitarios relacionados y su estado, quien lo ha modificado y además, navegar haca ellos de una forma sencilla pudiendo consultar el histórico de cambios y haciendo una magnifica comparación de ficheros.

No tener TFS no significa que no puedas usar el Code Lens, pero no es lo mismo ^^

Y por hoy esto es todo :)
Esta es la primera entrada y me quedan dos más. Ahora a hacer uso de estas magnificas novedades y, sobretodo, a ser más rápidos escribiendo nuestro código.

Saludos!