Proyectos

13/10/2022

/ , , , , ,

Arquitectura software de un banco 100% digital

El banco no banco

El proyecto internacional Model Bank (MB) está desarrollando una plataforma unificada y escalable para los clientes de retail del banco en diferentes países: España, Italia, Francia, la República Checa y Austria.

MB es un programa estratégico que tiene como objetivo que ING ofrezca una plataforma que ofrezca a todos los clientes una experiencia de usuario similar, independientemente del país en el que se encuentren o del dispositivo que utilicen para conectarse. Aportará un alto nivel de estandarización y centralización a los sistemas, procesos, datos y flujo de trabajo, alineados con otras iniciativas estratégicas de ING.

Dicha plataforma aportará componentes tecnológicos verticales a todo el negocio: desde el un back-end orientado a una arquitectura de microservicios hasta el front-end que deberá dar soporte a los canales online del banco.

Escalamos el equipo de arquitectos

La contratación de talentos en el sector de las nuevas tecnologías es una de las tareas más complejas para una empresa.

En ITERIAM ayudamos a acelerar este proceso aumentando la capacidad interna de nuestros clientes con el mejor talento, trabajando de forma colaborativa para alcanzar resultados exitosos y de la manera más rentable. En este caso incorporamos perfiles de alto nivel técnico y funcional para escalar el equipo de arquitectura:

  • Arquitectos de Dominio
  • Arquitectos de Plataforma
  • Arquitectos del Dato

El proyecto se desarrolla en un entorno Agile con metodología Scrum y aplicando soluciones y tecnologías de referencia como:

  • Frameworks Java y JavaScript como Spring, Akka, BackboneJS y/o Polymer 2.
  • Programación funcional
  • Diseño y gestión de APIs. WSO2
  • Arquitecturas orientadas a servicios. SOAP, REST
  • Micorservicios
  • Sistemas de mensajeria: Kafka
  • Desarrollo Continuo e Integración continua (CD/CI). Infraestructura basada en Git, GitLab, Ansible, Jenkins, y/o SonarQube
  • Bases de datos Oracle, Hadoop, Casandra

Proyectos

06/10/2022

/ , , , , , ,

Consultoría para la implantación de un nuevo gestor de contenidos corporativo

Contexto

La Seguridad Social es el sistema de protección del Gobierno de España garantiza a los ciudadanos la subsistencia ante situaciones de necesidad.

Este sistema se divide en entidades gestoras, entidades colaboradoras, servicios comunes todos dependientes del Ministerio de Inclusión, Seguridad Social y Migraciones.

La gestión y administración de las tecnologías de la información y las comunicaciones en el sistema de Seguridad Social es responsabilidad de uno de sus servicios comunes, la Gerencia de Informática de la Seguridad Social (GISS)  

Para el desarrollo de los diferentes sitios web de la Seguridad Social, tanto internos como externos, la GISS pone a disposición de las entidades gestoras y de ella misma de varios productos.

Utilizar diferentes soluciones y plataformas para su estrategia de canal online supone problemas en cuanto a la homogenización de estándares, reutilización de código y buenas prácticas, así como el incremento de costes asociado al mantenimiento de diferentes sistemas.

Retos

La Administración Pública tiene la obligación de ofrecer nuevos servicios digitales y mejorar los ya disponibles, en un continuo proceso de modernización todos sus sistemas.

La GISS necesita encontrar una plataforma única, flexible y escalable que le permita abordar el desarrollo de nuevos canales digitales y la evolución y mantenimiento de los actuales, tanto sitos webs como aplicaciones móviles.

La solución debe permitir mejorar los costes de licenciamiento y de servicios profesionales necesarios para el desarrollo y mantenimiento de los sistemas para poder optimizar los presupuestos disponibles, ajustar el “time-to-market” de los proyectos a las necesidades de las entidades gestoras que forman la Seguridad Social, cumplir con los requisitos de accesibilidad establecidos para los portales públicos, compatibilidad con la arquitectura corporativa…

La solución

ITERIAM lidera un equipo de consultoría para analizar la mejor herramienta que se adapte a los requisitos de la GISS en el entorno de gestión de contenidos.

Como parte del análisis realizado de las alternativas existentes en el mercado, se va a abordar el diseño, desarrollo e implantación de una serie de portales que sirvan como piloto para analizar en profundidad las capacidades del gestor de contenidos seleccionado.

Estos portales identificados como parte del piloto presentan varios casos de uso estándar de la organización, y junto a un trabajo de consultoría de implantación y despliegue de infraestructura, deberá dar como resultado si la herramienta puede convertirse en la solución corporativa en el entorno de la Seguridad Social para todo el canal online.

Después de las entrevistas con los equipos de Desarrollo y Producción de la GISS se toma la decisión de evaluar Liferay como solución corporativa de gestión de contenidos.

Resultados

Como primer resultado de la consultoría se presenta una arquitectura de la solución on-premise que pueda dar servicio en alta disponibilidad a los portales que se van a utilizar como piloto para la evaluación de la herramienta.

Abordamos los desarrollos de los portales ejemplo sobre la versión Liferay DXP 7.2.

Se desarrollan dos nuevos portales públicos informativos sobre propuesta de gráfica y de funcionalidades facilitada por la propia GISS; y por otra parte, se realiza una propuesta gráfica de las diferentes revistas digitales existentes (Activa, Mar, Portal de la Seguridad Social Digital) y se desarrolla un sitio web con componentes comunes para poder implementar ese tipo de sitios. En base a esa plataforma se implementa también al completo un sitio web interno incluyendo la migración de contenidos desde WordPress a Liferay.

Propuesta gráfica para la Revista de la Seguridad Social

Como desarrollo adicional, se realiza un piloto con los componentes disponibles de Liferay como suite de herramientas colaborativas para su evaluación por la dirección de la GISS.

Finalmente, y con el equipo de producción, se realiza una migración de la versión 7.2 a la última versión disponible del producto 7.3.

A parte de los proyectos desarrollados, se entrega un manual de buenas prácticas que permita a las entidades gestoras desarrollar y mantener proyectos con Liferay.

Tecnológicamente están involucrados en el proyecto:

  • Liferay DXP 7.2 y 7.3.
  • Integración con sistemas corporativos mediante servicios web
  • Desarrollo Continuo e Integración continua (CD/CI) con una infraestructura basada en Git, GitLab, Jenkins y SonarQube
  • Bases de datos Oracle

Proyectos

02/10/2022

/ , , , , , ,

Escalamos el equipo de desarrollo de canales digitales

Contexto

La contratación de talentos en el sector de las nuevas tecnologías es una de las tareas más complejas para una empresa.

En ITERIAM ayudamos a acelerar este proceso aumentando la capacidad interna de nuestros clientes con el mejor talento, trabajando de forma colaborativa para alcanzar resultados exitosos y de la manera más rentable.

Con más de 30 años de historia, RSI proporciona a través de pago por servicio soluciones bancarias a más de 15 entidades financieras de primer nivel, con más de 8 millones de clientes que realizan una media de 5.000 millones de transacciones al año.

RSI tiene la necesidad de ir gestionando la demanda de desarrollo de aplicaciones para sus clientes, y en particular, la solución de eBanking cobra vital importancia para la compañía para competir ofreciendo soluciones tanto web como app que ofrezcan una experiencia de usuario memorable, facilidad de uso y rapidez en todas las operaciones sin necesidad de desplazarse a una oficina.

Enfoque de la colaboración

ITERIAM monta una célula de desarrollo front-end dentro de nuestro Centro de Desarrollo Especializado, ofreciendo un servicio ágil, flexible y personalizado para RSI asumiendo la demanda cambiante de trabajo según las necesidades de las diferentes entidades financieras.

Los principales beneficios de esta colaboración son:

  • Sinergias. Proporcionamos talento cualificado que se adapta e integra rápidamente en la estructura operativa del cliente, compartiendo una cultura similar, aportando nuestra experiencia en otros ámbitos y hablando el mismo idioma.
  • Escalabilidad. Los equipos de TI del cliente pueden crecer rápidamente en su negocio sin el coste adicional de contratación, manteniendo el control de los equipos y de sus proyectos.
  • Control. RSI se mantiene enfocado en la gestión de su negocio y nosotros nos encargamos de proveer el talento adecuado con las habilidades técnicas y la experiencia que necesita en cada momento.
  • Flexibilidad. Existe la posibilidad de aumentar o disminuir el tamaño del equipo según las necesidades y la duración del proyecto.
  • Rentabilidad. Reducción de costes operativos y gastos directos de contratación. Nosotros proveemos talento con las habilidades necesarias que formaran parte del equipo el tiempo que cada proyecto lo demande.

En este caso particular el equipo de conforma con especialistas en desarrollo de soluciones web y aplicaciones móviles con VueJS.

Proyectos

02/10/2022

/ , , , , , ,

La mejor app para gestionar tu salud

Punto de acceso único a todos los servicios

Sanitas como empresa puntera en el ramo de salud con una cuota superior al 20% y referente en innovación en el sector evoluciona de forma continua su proyecto MiSanitas, canal de acceso para los asegurados a todos sus servicios digitales.

En 2021 el 12% de las consultas fueron digitales hasta alcanzar 782.000, con picos que superan las 4.200 diarias. Y todas esas consultas se realizan a través de MiSanitas.

Los asegurados tienen la posibilidad de realizar de forma sencilla y desde un punto único todas sus gestiones:

  • Pedir citas médicas, gestionarlas, reprogramarlas y cancelarlas
  • Buscar médicos, hospitales, centros médicos o clínicas dentales
  • Encontrar el centro de urgencia y especialista más cercano
  • Consultar el histórico de visitas al médico y las citas pendientes
  • Guardar médicos favoritos
  • Consultar informes médicos, analíticas, radiografías, etc.
  • Subir informes de otros centros para tener toda la información de salud en un solo lugar
  • Acceder a la tarjeta de salud digital (y de los hijos)
  • Hacer gestiones de la póliza, como solicitar reembolsos y autorizaciones
  • Ver los recibos y copagos en tiempo real
  • Consultar, modificar y personalizar el perfil de cada beneficiario
  • Cambiar la cuenta bancaria y periodicidad
  • Acceder a la biblioteca de consejos de salud

Escalamos los equipos de desarrollo

ITERIAM lleva cuatro años participando en este proyecto escalando el equipo del área de Digital de Sanitas mediante la conformación de squads ágiles siguiendo metodologías como Lean Startup o Scrum. Aportamos diferentes perfiles técnicos (product owners, scrum masters, líderes técnicos, UX, desarrolladores front-end, desarrolladores back-end, testers, maquetadores, etc.) y adecuamos la gestión de la demanda con un trato cercano, transparente y comprometido para cumplir con los objetivos de negocio.

La solución técnica se implementa tanto para web como app, realizando integraciones con todos los servicios digitales de la aseguradora mediante una arquitectura de microservicios y ofreciendo una magnífica experiencia de usuario al cliente.

Actualidad

06/09/2022

/ , , , , ,

Arquitecturas CSS

Introducción

Normalmente cuando queremos empezar el desarrollo de una aplicación, solemos pensar en el lenguaje de programación que vamos a usar tanto en la parte de front-end como en la parte de back-end. Una vez elegidos, continuamos pensando en la arquitectura que van a tener ambas partes.

Centrándonos en la parte de front, además de pensar en la arquitectura del lenguaje de programación elegido, tendremos que plantearnos la arquitectura de nuestro código CSS y que nos va a permitir agilizar todo el desarrollo.

Eso sí, no hay que confundir arquitectura con metodología en CSS. Mientras que la arquitectura se va a encargar de organizar las carpetas del proyecto, la metodología se va a encargar de especificar en cómo se va a nombrar las clases.

Teniendo claro esto, he indagado en las diferentes arquitecturas CSS que existen y de las cuales he seleccionado dos para analizar en este artículo: la arquitectura SMACSS y la arquitectura ITCSS. Estas dos arquitecturas se centran en organizar el CSS dependiendo de su función en una categoría o capa.

Arquitectura SMACSS

SMACSS (Scalabre and Modilar Architecture for CSS) nos va a permitir que el código CSS que desarrollemos sea escalable y modular como indica su «imaginativo» nombre. Para conseguirlo, empezamos observando los patrones que caracteriza a cada una de las categorías. Esto se hace, ya que cuando comencemos el desarrollo, sepamos en que categoría agruparlo. Las categorías son las siguientes:

Base

Son aquellos estilos que aplican directamente a los propios elementos HTML y que vamos a usar para establecer los estilos por defecto en nuestra aplicación. También se incluyen aquellos estilos que nos van a permitir eliminar o restablecer las bases a aplicar en todos los navegadores. Esto último hay que planteárselo bien, ya que, si se va a restablecer de nuevo algún valor por defecto en los elementos reseteados, no tiene sentido que se restablezca en primer lugar.

Layout

Son aquellos estilos que tienen por objecto aplicarse sobre los componentes de estructura de nuestra aplicación. Por ejemplo, el header o el footer. Para aplicarle los estilos, se hace mediante el uso del selector ID. Sin embargo, hay veces en que el layout tiene que adaptarse a las preferencias del usuario, para ello se usará una clase con el prefijo ‘l-’. Para el caso de los IDs, se nombran con precisión y sin usar un espacio en la nomenclatura. Esto ayuda a identificar fácilmente la categoría de estos estilos y a separarlos de las categorías module y state.

Module

Son aquellos estilos que aplican sobre los diferentes componentes de nuestra aplicación. Por ejemplo, la barra de navegación y el carrusel de imágenes. Estos se ubican normalmente dentro de los componentes layout aunque también pueden ubicarse dentro de otros componentes module. Para garantizar la flexibilidad, los componentes modules deben de estar diseñados para existir como componentes independientes. Para aplicarles los estilos, se hace mediante nombres de clase y hay que evitar usar IDs y selectores de elementos.

State

Son aquellos estilos que modifican los estilos de un componente cuando se da una condición. Por ejemplo, una sección de un acordeón puede estar oculta o desplegada. Hay bastantes similitudes entre un estilo aplicado a un sub-module y a un state. Ambos modifican el aspecto de un componente, pero se diferencia en lo siguiente:

  • Las reglas de state se pueden aplicar tanto a las reglas layout como a las reglas module.
  • Las reglas de state indican una dependencia con Javascript.

Las reglas de state se aplican mediante el uso de las clases. También está permitido el uso del ‘!important’, pero sólo cuando sea estrictamente necesario y evitando usarse para todas las demás reglas.

Theme

Son aquellos estilos que definen los colores y las imágenes que le dan su apariencia a nuestra aplicación. Se debe separar cada tema en su propio conjunto de estilos. Esta categoría puede afectar a las demás y se aplica mediante el uso de clases. Debe tener un nombre que especifique el tema que es y se recomienda tener un archivo por cada tema.

Arquitectura ITCSS

ITCSS (Inverted Triangle architecture for CSS) es una arquitectura CSS que nos va a permitir que el código CSS que desarrollemos sea escalable y manejable. Esto se consigue mediante la organización de los ficheros CSS de tal manera que nos permita manejar la especificidad de estos. Según su especificidad, se separa el código CSS en varias capas que se pueden representar como las secciones de un triángulo invertido. Estas capas son las siguientes:

Settings

Se utiliza con preprocesadores y es donde colocaremos el código de declaración de variables. Por ejemplo, las fuentes y las definiciones de colores.

Tools

Se utiliza con preprocesadores y es donde colocaremos los mixins y las funciones de uso global. En esta capa y en la anterior es importante no generar ningún código CSS.

Generic

Se utiliza para reiniciar y/o normalizar los estilos de los elementos HTML de nuestra aplicación. A partir de esta capa, empezaremos a generar código CSS.

Elements

Se utiliza para establecer los estilos de los elementos HTML de nuestra aplicación. A diferencia de la anterior capa, esta no tiene por objecto convertir los elementos HTML en lienzos en blanco, sino busca darle los valores por defecto a los mismos elementos HTML orientándolo a la propia aplicación.

Objects

Se utiliza para establecer los estilos de los componentes de estructura de nuestra aplicación. Por ejemplo, el header, el grid, el container y el wrap. La capa objects se aplica mediante el uso de las clases con el prefijo ‘o-’.

Components

Se utiliza para establecer los estilos de los componentes de la interfaz de usuario. Por ejemplo, la barra de búsqueda o el botón de una red social. La capa components se aplica mediante el uso de las clases con el prefijo ‘c-’.

Utilities

Se utiliza para sobrescribir o anular los estilos establecidos anteriormente en las demás capas. Es la única capa en la que está permitido el uso del ‘!important’. La capa utilities se aplica mediante el uso de las clases con el prefijo ‘u-’.

Actualidad

16/01/2022

/ , , , , ,

Cómo usar videos en una web correctamente

Introducción

Corría el  año 1895 cuando unos hermanos apellidados Lumiere desataron un fenómeno mundial que revolucionó la forma de ver la vida y de llevar mensajes a cualquier parte. Cuando hablamos de “video” englobamos todas las artes en que se transforma (cine, televisión, series, etc.) y una enorme lista de recursos en las que por medio de imágenes a gran velocidad conseguimos transmitir un mensaje.

En los últimos años el video ha evolucionado de tal forma que actualmente. Según el CISCO el 80% del trafico de la red es video. Puede resultar un dato impresionante pero si te digo nombro a Netflix, Zoom, Youtube, Tiktok, Facebook, PrimeVideo… ya entiendes que el video es el recurso preferido para comunicarse en el medio preferido por los usuarios: internet.

En este artículo vamos a hablar del video y de la importancia de saber configurarlo correctamente en tu proyecto web. Verás que hay muchas cosas que no sabías y estabas pasándolas por alto. Conocer bien el producto te hará tratarlo con más confianza.

Primeros pasos, lo más importantes

Como no podía ser de otra manera el primer paso es que pienses detenidamente en el destino del video que vas a usar. Es evidente que cada video es un mundo y por tanto cada video, o listado de videos tienes que estudiarlos. El resultado es que en producción ver estos vídeos sea un paseo en barca donde disfrutas de su contenido. Pero sabemos que en ocasiones no es así y esta mala planificación provoca que el usuario no obtenga una buena experiencia en tu sitio web.

A continuación veremos los aspectos más importantes a tener en cuenta a la hora de planificar un proyecto web que incluya vídeos.

Poster

Cuando ponemos un vídeo en una web no siempre queremos que se reproduzca.

Hay videos cortos que se reproducen en bucle y asumen un papel de background, pero si se trata de un video que quieres que se vea porque su contenido es importante has de configurarle un poster . Se trata de esta etiqueta:

<video src="videofile.ogg" autoplay poster="posterimage.jpg"></video>

Obtenemos dos ventajas al establecerse como un poster:

  • La pantalla de portada será más atractiva. Probablemente tu video tenga el primer frame en negro, así que si no configuras un poster, tu cuadro de video será una pantalla negra vacía.
  • Este poster carga al instante y puede que el vídeo, si es muy pesado, tarde un poco en cargar. Conseguimos enmascarar esa carga en segundo plano. Si tienes muchos vídeos en una misma URL que cargan a la vez es un proceso lento así que  puedes hacer que cargue al reproducirlo. Esto lo conseguimos con la etiqueta preload:
<video src="videofile.ogg" autoplay preload="none"></video>

Está de más decir que el poster ha de tener las mismas dimensiones en px que el video y una resolución de 72ppx. Y por supuesto ha de ser atractivo si quieres que vean el video.

Resoluciones

La palabra resolución, cuando hablamos de video, sufre un mal uso constante. La resolución de un video no es mas que la cantidad de píxeles de alto por ancho. No podemos llamar resolución a .H264 o a 16:9. Por tanto, aclarado lo que es la resolución, veamos cuales son los estándares más usados:

  • FHD, 1920x1080px. La más usada, aunque el 4k empieza a comer terreno.
  • HD, 1280x720px. Era la más usada pero la desbancó en poco tiempo FHD.
  • 4k, 3840 x 2160px. Aún en crecimiento porque precisa una gran tasa de datos y una pantalla con mucha densidad de pixeles.

La resolución es junto con el formato quien marcará el peso del vídeo por segundo.

Aquí es donde hemos de tener un gran tacto pues un video muy pesado puede afectar gravemente la usabilidad de la web. En este caso y al igual que pasará con la relación de aspecto, necesitamos una resolución diferente para cada dispositivo. Pero cuidado en este tema porque las pantallas están cambiando y cada vez tienen mayor densidad de píxeles. Por ejemplo, una pantalla de un desktop estándar podríamos decir que está en FHD. ¿Y una pantalla mobile? Pues aquí se ha desatado la locura y por ejemplo IPhone12 tiene 2340×1080 así que menos de FHD sería un error.

Lo aconsejable es hacer un desarrollo donde detectemos la resolución en ancho de la pantalla y en función de eso carguemos los vídeos con las resoluciones óptimas a ese dispositivo. Un código similar a este sería lo aconsejable:

<video id="video">

   <source src="movie.webm" type="video/webm;">

   <source src="movie.mp4" type="video/mp4;"/>

   <source src="movie.ogv" type="video/ogg;"/>

</video>

<script type="text/javascript">

   var srcRes = null;

   if (screen.width > 1920){

       srcRes = "_4k.";

   } else if (screen.width > 1280) {

       srcRes = "_FHD.";

   } else {

       srcRes = "_HD.";

   }

   document.querySelectorAll('source').forEach(el => el.src = el.src.replace(".", srcRes));

 </script>

Este código detecta el ancho de la pantalla del dispositivo, no la ventana del navegador. Para que funcione el código simplemente has de tener tu video en diferentes resoluciones y con un nombre igual para todos pero con la matiz de la resolución: _HD, _FHD o _4K.

Formatos

Este es uno de los temas más conflictivos a la hora de cargar un vídeo. Con el resto de ajustes el video se verá mejor o peor, tardará más en cargar o menos, pero por el formato del vídeo puede pasar que se vea o no el video dependiendo del dispositivo o navegador que uses. El formato hace referencia únicamente al tipo de archivo que exportamos.

Del formato podemos diferenciar la extensión y el códec. La extensión es el paquete que engloba ese formato (.mov, .mp4, .avi, etc.) y el códec es el leguaje de compresión que se usa para hacer que el video pese menos (MPEG2, H264, WebM, etc.).

En este caso la etiqueta video cuenta con una sub-etiqueta source y en su atributo src se puede colocar el formato de video. Así para una etiqueta de video, tenemos varios src y cada uno aporta el video en diferente formato.

<video>

  <source src="movie.webm" type="video/webm;"/>

  <source src="movie.mp4" type="video/mp4;" />

  <source src="movie.ogv" type="video/ogg; " />

<video>

Relaciones de aspecto

La relación de aspecto es la relación proporcional entre el ancho y el alto del frame. En esencia, es la forma del video. Hay multitud de estándares para configurar esta relación de aspecto entre los que vamos a destacar los más usados:

  • 16:9. Se trata del estándar más usado actualmente tanto en web como en dispositivos. Su resolución más usada sería FHD 1920x1080px.
  • 4:3. Es una relación que está perdiendo popularidad pues nos ofrece un frame muy cuadrado y el vídeo se aprecia más atractivo en formatos panorámicos. Su resolución mas usada sería 1280x960px, aunque el origen de esta relación proviene del sistema PAL que todos hemos tenido en casa, 720x576px.

Aunque lo normal es usar un estándar hay ocasiones en que el proyecto precisa unas relaciones de aspecto diferentes en cada dispositivo. Por ejemplo un banner en desktop con un video de fondo puede tener una relación de aspecto muy panorámica. Sin embargo en mobile su relación de aspecto será cuadrada o vertical. Aquí es donde entra en juego CSS y sus ajustes para background.

Veamos el siguiente ejemplo:

En este caso el video de fondo lo hemos configurado con la posición absoluta y en cada dispositivo jugamos con top, bottom, right, left y márgenes automáticos. En ocasiones hay que tener videos demasiado versátiles para que la perdida de información que se da de un dispositivo a otro sea asumible.

Reproductor

Por último veamos el modo en que queremos que el usuario interactúe con el video que le presentamos. Como hemos hablado anteriormente, si el video es un background, no tiene sentido que tenga botones, y si no quieres que salgan corriendo de tu página, tampoco debería tener sonido. Por eso vamos a hablar de los vídeos con los que el usuario debe interactuar. La etiqueta video nos ofrece estos atributos:

  • Autoplay: Booleano para que el video se reproduzca automáticamente tras cargarse.
  • Controls: Booleano para mostrar o no el panel de control del video de tu explorador.
  • Muted: Booleano para iniciar el vídeo sin sonido.
  • Loop: Booleano para indicar la reproducción en bucle del vídeo.

Hay casos en los que hay que desarrollar un estilo personalizado de reproductor. Para ello basta con no poner el atributo controls y configurarlos tu mismo con js y css. Os muestro un pequeño ejemplo:

<div class="container-video">

  <video id="video" src="movie.mp4"></video>

  <button onclick="reproducir()">Reproducir</button>

  <button onclick="pausar()">Parar</button>

</div>

<script type="text/javascript">

  window.reproducir = function() {

      document.getElementById("video").play();

  };

  window.pausar = function() {

      document.getElementById("video").pause();

  };

</script>

Conclusión

El vídeo es un elemento complejo al que prestar mucha atención porque configurarlo bien nos devolverá una experiencia positiva de nuestro desarrollo.

Por supuesto hay muchos temas que no hemos hablado en este video relativos al video como los fps (fotogramas por segundo), la tasa de bits de video o los campos (i o p), pero quizás esos temas sean parte del diseño del propio video y no de la implementación.

Para terminar me gustaría dejar ese fragmento del que empecé hablando porque como dicen es importante saber de dónde vienes para saber quién eres:

Actualidad

18/11/2021

/ , , , ,

Primeros pasos con SVELTE

Introducción

Svelte  (o SvelteJS) es un framework para desarrollar aplicaciones JavaScript por Rich Harris y basado en componentes para crear aplicaciones reactivas.

A diferencia de otros frameworks como Angular, Vue o React, el código es compilado previamente para que el navegador pueda entenderlo.

Si visitamos la web principal de Svelte podemos desatacar sus tres características principales:

  • Write Less Code. Una de las principales características es que podemos crear componentes con menos líneas de código, que por ejemplo React, donde su creador asegura que si comparamos componentes iguales, estamos ahorrando hasta un 40% de código. Svelte utiliza el principio de Single File Component en el cual, en un mismo archivo tendremos el HTML, Javascript y Css. Esto te puede resultar familiar si has utilizado Vue.
  • No virtual DOM. Lo más interesante de Svelte es, que como hemos comentado, es precompilado. No hace uso del Virtual DOM para realizar cambios en nuestra aplicación, sino que se aprovecha de la previa compilación para realizar los cambios de estados y propiedades.
  • Truly reactive. La programación reactiva es la base de cualquier framework de javascript, donde simplemente es que la interfaz del usuario va cambiando según se vayan modificando los datos de éste.

Vamos a ver paso a paso cómo empezar con un proyecto utilizando Svelte 3.

Instalación

Vamos a ver como crear un proyecto sencillo en Svelte y para ello, seguiremos los pasos que nos indican en la web oficial.

Arrancamos una terminal y ejecutamos el siguiente comando:

npx degit sveltejs/template proyecto-svelte

Con este comando lo que estamos haciendo es hacer una copia del repositorio de Github de sveltejs, pero sin la carpeta .git.

El siguiente paso será situarnos dentro de nuestro proyecto: cd proyecto-svelte y hacer un: npm install para instalar las dependencias del proyecto.

Una vez instaladas todas las dependencias podemos ver los distintos ficheros que nos ha creado.

Estructura del proyecto

Si abrimos nuestro proyecto con un editor, nos encontraremos con la siguiente estructura:

Uno de los ficheros a destacar es rollup.config.js , el cual es una herramienta que lo que hace es compilar todo nuestro código en un solo fichero, más grande y complejo (lo que se llama Bundle) como puede ser Webpack o Parcel.

Seguimos analizando nuestro proyecto y vemos el  fichero package.json . Como podemos ver, tiene una configuración bastante sencilla con pocas dependencias y los diferentes scripts que podemos ejecutar:

Creación de una sencilla aplicación:

Vamos a crear una pequeña aplicación para ver alguna de las características más importantes de este framework:

Empezamos analizando el fichero main.js, el cual es el fichero de entrada de nuestra aplicación. En él, estamos creado una prop que pasaremos a nuestro componente App.svelte.

En el siguiente ejemplo crearemos un pequeño componente donde habrá un contador y en el que veremos algunas de las características de este framework:

Lo primero que haremos es exportar la propname’, donde estamos indicando que es un parámetro del componente. Después crearemos una propiedad llamada contador, y un botón el cual llamará a una función para que cada vez que se haga click en él, el contador se incremente. En este botón hemos añadido la directiva on:click, que será el evento que se lance cada vez que pulsemos sobre él.

Aquí lo interesante que tiene Svelte, es que como tiene un paso previo de compilación, está deduciendo que la variable ‘contador’ es un estado, y cada vez que el valor cambie, vuelve a renderizar el componente.

En la siguiente imagen vemos como traduce Svelte nuestro código:

Arrancar el proyecto

Arrancaremos nuestro proyecto y lo ejecutaremos en modo ‘dev’. Para ello ejecutamos el comando: npm run dev y se nos indicará una dirección localhost con el puerto 5000, el cual no llevará a nuestro entorno de desarrollo.

Así se vería nuestro proyecto en el navegador:

Conclusión

Hasta aquí hemos podido ver como configurar nuestro entorno para trabajar con Svelte y algunas de las ventajas que tiene como son la simplicidad de su código, reactividad y que tiene una curva de aprendizaje muy baja.

Podemos ver ejemplos concretos en su misma página, analizarlos y comprobar la potencia que puede llegar a darnos este framework en el desarrollo de nuevas aplicaciones.

Actualidad

24/05/2021

/ , , , ,

Me encanta que los planes (de usabilidad) salgan bien

Cuando nos enfrentamos a cualquier proyecto podemos hacerlo de muchas formas, pero el resultado siempre queremos que sea satisfactorio.


Muchas generaciones recordamos la famosa frase de John Hannibal Smith de la serie “El equipo A” que titula este artículo. Podría haber usado otras series míticas como MacGyver como hilo conductor, pero necesitaba algo más potente. Me tentó también Michael Knight que encajaba bien como ejemplo de tecnología, pero improvisaba mucho.

Por eso el equipo A para lo que os quiero contar me pareció perfecto. ¿Os imagináis a Hannibal sin pensar una forma imaginativa para resolver las aventuras de cada episodio? ¿Sin definir un plan con sus compañeros de equipo? ¿Sin apoyarse en su experiencia previa como miembro de los cuerpos de élite del ejército?

Cuando abordamos un proyecto de usabilidad y experiencia de usuario cometemos errores básicos y simples, producto casi siempre de una insuficiente planificación y de repetir lo que vemos en otros proyectos. Planear bien las cosas tiene un montón de ventajas como evitar el retrabajo, acortar los tiempos de ejecución, asegurar la calidad del resultado, etc.

Os facilito en este artículo algunos ejemplos de buenas prácticas y recomendaciones, para que veáis que con poco que le deis al coco… ¡los planes siempre salen bien!


Mobile First, tatúatelo

Mobile First ha dejado de ser una tendencia y actualmente es un patrón obligatorio para diseñar un proyecto web.

Haz como MA Barracus y tatúatelo. El modo en que los usuarios actuales asumen ver los contenidos está basado en experiencias móviles. Estas experiencias se basan en pantallas sencillas con scroll vertical.

Mr. T
«Mr. T» by gameraboy is licensed under CC BY-NC 2.0

La mayoría de los proyectos ya son responsive, pero no podemos confundir ese término con Mobile First.

Hay un gran error de usabilidad que se sigue cometiendo y es el contenido en las pantallas. Se sigue haciendo contenido para pantalla de escritorio y se desarrollan responsive. El resultado será un sitio web que se verá bien en otros dispositivos, pero tendrá un exceso de contenido en una única pantalla y elementos poco accesibles para operar con una mano.

Por ello hay que recalcar que Mobile First denota también que las pantallas han de ser sencillas, concisas y fáciles de usar desde cualquier dispositivo.


El Header, nuestro vehículo en una web

¿Qué pensaríais si la furgoneta del equipo A se pareciese a ésta?

Es importante hacer un buen estudio del Header ya que es el primer elemento que tocar y se repite en todo el sitio web que estéis diseñando.

Hay varios errores que se repiten y son tan fáciles de corregir con el objetivo de simplificar tus propuestas y centrarte en lo esencial. Estos son algunos de los consejos para crear un Header que funcione:

  • Entre 5 y 10 items en el header. Muchos botones restan.
  • Que su altura no sea mayor de 150px. El header es importante, pero se va a repetir en toda la website y por lo tanto ha de ser ligero.
  • Que contrasten el fondo con las letras y si tu menú permanecerá fijado en la parte superior de la ventana, que contraste muy bien en todo el scroll vertical.
  • Ordenar por importancia los ítems en el header. No sigas tendencias, si lo importante son tus productos, no pongas en primer lugar “Mi compañía”. O si prevés que la búsqueda será el fuerte del sitio, no la dejes escondida al final con un icono de lupa.
  • El uso excesivo de iconos en el Nav resta. Más de 4 items con iconos es uso excesivo que despista al usuario.
  • La distribución más usada y que me mejor funciona es logo izquierda y Nav derecha. Centrar el logo y poner el nav partido o en una segunda fila hace que el header sea excesivamente alto.
  • Cuidado con los navs desplegables que no dejan de desplegar. Trabaja mucho las categorías que mostrar ya que en mobile es incómodo un Nav que sobrepasa en largo la pantalla.


Espacio libre, ¿un lujo?

Sigo utilizando ejemplos gráficos para avanzar en mis recomendaciones. ¿Te imaginas al Equipo A con un R5 en vez de la furgoneta molona que usaban?

¿Como viajar con todo el equipo a las diferentes misiones? ¿Como disparar esas metralletas?

El espacio, ya sea en un sitio web, en una misión del equipo A o en tu vida, es muy importante. El espacio libre es eso que una persona usa, sin ser consciente, para sentirse a gusto en dicho espacio.

Para que una web sea cómoda y se use a gusto ha de tener mucho espacio libre y estas son algunas de las pautas a seguir:

  • Planifica muy muy, pero que muy bien tus secciones y el contenido de cada una. Lo adecuado es que una sección no supere el tamaño de una pantalla (excluimos los listados de este consejo).
  • Si usas fondos o imágenes a sangre, es decir, full-width, no uses el texto en esa configuración.
  • Deja márgenes amplios entre secciones o contenido. Si lo empastas todo te pasa como con la plastilina, el resultado es una masa marrón.
  • No abuses del color, el video o la imagen. El blanco da paz y nunca falla.


Anuncios, banners, ventanas modales, políticas de cookies… ¡Que locuraaaa!

Se ha podido demostrar que el “Loco Murdock” no era un personaje ficticio si no que sus trastornos estaban causados por consumir sitios web como el que veis en la siguiente imagen:

Cuando hablamos de obtener una buena experiencia en el uso de una plataforma el tema de las promociones y publicidad pueden tirar por tierra todo lo que hayas trabajado en el Header, en el contenido o en la navegación.

El uso muy moderado de estos recursos de publicidad – bien propia o ajena – resta a tu diseño, pero si te dejan llegar a tu destino debes pensar en si te interesa el impacto que provocan. El uso desmesurado de dichos recursos no es que resten, te anulan. Hacen inservible tu sitio web.

Otros dos factores para destacar que salen de esa publicidad son los logins o suscripciones y las políticas de cookies. El login siempre ha de estar accesible pero no debes atosigar al usuario para que se registre: deja que te conozca y sugiérelo sutilmente. Haz lo mismo con la newsletter.

En cuanto a las políticas de cookies, todos nos hemos subido a ese tren, pero que esa legislación no nos impida ver tu página. No llenes toda la página con ese mensaje porque puedes conseguir que ya no la quieran ver. Un mensaje discreto es lo que mejor funciona.


Botones de redes sociales

Un error muy simple se da cuando alguien decide presumir de sus redes en su página web. Los hay que te las ponen en el Nav y que merecen ser castigados. Otros en el Footer, tienen mi clemencia. Y otros, almas cándidas, por todas partes. Pues compañeros, mal plan.

El sentido de esos botones es que conozcas esas redes, pero vamos a poner a funcionar nuestra materia gris: ¿dónde está expuesto el grueso de nuestro negocio? ¿en las redes sociales? ¿en el sitio web? Debería estar en el sitio web mientras que las redes sociales son canales que usas para que la gente llegue a dicho sitio web.

Os voy a poner un ejemplo. Entráis a una tienda a comprar y delante de cada producto hay otras tres puertas: una puerta que te lleva a la empresa que hace la publicidad de la tienda, otra que te remite a un cartel de la carretera y la otra de nuevo te lleva al escaparate. ¿No tiene sentido verdad? Lo suyo es que ese escaparate, esa publicidad y ese cartel sean los que te llevan a la tienda a consumir tus productos.

Pues en muchos sitios web se ha instaurado esa tendencia y es un gran error. Si al entrar lo primero que ves son las redes sociales estás invitando al usuario a que lo primero que haga es salir de tu página e irse a una red social, donde sí, estás tú, pero también otros cuantos millones de empresas como tú.

Cabe destacar que no podemos confundir el botón de redes sociales del Nav o Footer con los botones en blogs que sirven para compartir dicho post dentro de una red social. Estos si tienen un gran sentido ayudando al SEO de dicha empresa.

El mal uso de los botones que te llevan a redes sociales es algo muy instaurado y es un mal hábito para la usabilidad de cualquier proyecto. Si te hago salir justo cuando entras… ¡no creo que los planes salgan bien!

Actualidad

10/12/2020

/ , , , ,

Mejorando TDD con la premisa de la prioridad de transformación

¿Qué es la Premisa de la Prioridad de Transformación?

La mayoría de los programadores que han utilizado la práctica de desarrollo de software TDD (Rojo/Verde/Refactorización) en su ciclo de trabajo, deben estar ya acostumbrados a introducir pequeños cambios en el código en cada una de sus fases, y principalmente deben conocer los cambios asociados a las refactorizaciones que realizamos durante la última fase de TDD.

La refactorización, tal como fue definida por Martin Fowler en su libro Refactoring: Improving the Design of Existing Code (1999), “es el proceso de cambiar un sistema de software, de forma tal que no se altere el comportamiento externo del mismo pero que se mejore su estructura interna. Con el objetivo de hacerlo más sencillo de entender y barato de mantener, permitiendo que el diseño del programa mejore luego de haber sido escrito”.

Al igual que con la fase de Refactorización, durante la fase Verde también se realizan alteraciones en el código, mediante las cuales intentamos hacer que el software supere la prueba que se encuentra fallando, empleando el menor cambio posible. A estas operaciones Robert C. Martin (tío Bob) las denominó transformaciones.

Podemos pensar en estas transformaciones como la contraparte de las refactorizaciones, debido a que consisten en pequeñas variaciones en el código que permiten modificar el comportamiento externo del software pero que conservan significativamente su estructura interna. Dicho en otras palabras, las transformaciones generalizan el comportamiento del sistema sin cambiar su estructura.

Pensando en estas transformaciones, el tío Bob definió la “Premisa de Prioridad de Transformación” (sus siglas TPP del inglés Transformation Priority Premise) la cual afirma que las transformaciones poseen un orden inherente fundamental, y que al ser aplicadas en correcto orden se conduce a mejores algoritmos y se evitan interrupciones del ciclo de TDD.

Él describe esta premisa en algunas de sus charlas mediante un ejemplo de desarrollo de un algoritmo de ordenamiento, y hace notar que al violar dicho orden se conduce a un algoritmo de ordenamiento de burbuja, mientras que empleando un orden preestablecido se alcanza un algoritmo de ordenamiento rápido, el cual es mucho más eficiente que el anterior.

Basándose en sus experiencias y evaluando publicaciones de otras personas, el tío Bob llegó a la siguiente lista ordenada de transformaciones:

01{}–>nullDe no tener código alguno a código que retorna Null
02null->constantDe código que retorna Null a devolver un valor literal simple
03constant->constant+De un valor literal simple a un valor literal complejo
04constant->scalarDe un valor literal a una variable
05statement->statementsAgregar más sentencias
06unconditional->ifDividir el flujo de ejecución mediante condicionales
07scalar->arrayDe una variable a una colección
08array->containerDe una colección a un contenedor
09statement->tail-recursionDe una sentencia a recursión de cola
10if->whileDe un condicional a un bucle while
11statement->non-tail-recursionDe una sentencia a una iteración
12expression->functionDe una expresión a una función
13variable->assignmentReemplazar el valor de una variable
14case/elseAñadir una bifurcación a un condicional existente
Tabla 1. Orden de Transformaciones según su Prioridad


Este listado sugiere un grado de complejidad incremental en nuestras transformaciones a medida que avanzamos en él, de forma que es más sencillo cambiar una constante a una variable que el añadir una sentencia condicional. Debido a esto, se sustenta la idea de dar prioridad en su uso a las transformaciones más simples por encima de aquellas más complejas.

Como una guía para nuestro uso durante el ciclo de TDD se puede representar dicho listado con el siguiente diagrama:

Figura 2. Diagrama de la Premisa de Prioridad de las Transformaciones


Para propiciar el uso de las transformaciones más simples, cuando diseñamos una prueba, primero debemos pensar en desarrollar aquellos casos de uso que nos permitan emplear transformaciones más simples en vez de las transformaciones más complejas. Debido a que a mayor complejidad de la prueba, mayor será el riesgo que tomemos para lograr hacer que nuestra prueba pase.

Encontrarnos en una situación donde no sabemos cómo hacer que una prueba pase, es un problema que muchos hemos observado mientras realizamos TDD. Algunas veces, la causa de este tipo de impasses recae en nuestro proceso de toma de decisiones durante el ciclo de desarrollo de TDD.

La transformación más simple suele ser la mejor opción que incurrirá en el menor riesgo para crear una situación de bloqueo. Debido a que mientras mayor sea el cambio en el código, más tiempo nos tomará antes de que nuestra prueba vuelva a pasar, por lo que se produce un riesgo mayor de romper el ciclo de TDD.

Por todo lo antes expuesto, el tío Bob plantea como premisa que si se eligen las pruebas e implementaciones que empleen transformaciones que están más arriba en la lista, se podrán evitar las situaciones de impasse o interrupciones prolongadas en el ciclo rojo / verde / refactorización.

Aplicando la TPP al Kata de los Números Primos

Aplicando la TPP al Kata de los Números Primos

Podemos practicar y dominar estos conceptos aplicando esta premisa de la prioridad de las transformaciones en un problema conocido como lo es la kata de los números primos.

El objetivo de esta kata es determinar el listado de factores primos un número. Un número primo sólo puede ser dividido exactamente por sí mismo y por 1.

A continuación, realizaremos la kata de los factores primos:

1. Añadimos un Test Fallido para 1 (Caso más simple)

Nos detenemos al fallar la compilación de la prueba

1.1 Transformando para Compilar

La forma más fácil de tener éxito (compilar ahora) es crear un método con valor de retorno nulo. Esta es la primera transformación o transformación nula ({} -> null).

1.1 Transformando para Pasar el Test

Esta prueba falla porque el método primeFactorsOf devuelve null, y no una lista vacía. Para que esta prueba sea exitosa, transformaremos el valor nulo en una lista vacía.

Nuestra segunda transformación es null -> constant.

¿Acaso null no es una constante? Null también es una constante, pero Null es una constante muy especial. Es una constante sin tipo definido y sin valor. Por lo tanto, es diferente de una constante que tiene un tipo y un valor.

La transformación realizada con null -> constant hace que el código sea más general. Null es un caso muy especial, inmutable, pero una lista vacía tiene el potencial de ser general. Ser general significa que puede manejar una variedad más amplia de casos.

2. Añadimos un Test Fallido para 2

Como segunda prueba, agregamos:

assertThat(primeFactorsOf(2), is(Arrays.asList(2)));

Con lo que esta nueva prueba fallará.

2.1 Transformación – Constante a Variable

Para que esta prueba sea exitosa, generalizamos la constante new ArrayList()

Para hacer esto, transformamos la constante en una variable llamada factors. La tercera transformación es constant -> variable.

Lo que hemos hecho es una refactorización (extracción de una variable), con la cual no hemos cambiado el comportamiento en un sentido estricto. Debido a que reemplazar una constante por una variable con su valor original no altera el comportamiento del sistema. Sin embargo, nos abre la posibilidad de poder cambiar ese comportamiento. En otras palabras, cambiar una constante por una variable no es una transformación independiente, pero es una parte necesaria del proceso de transformación.

2.2 Transformación – Flujo Dividido

Una transformación que modifica una constante en una variable permite que realicemos una cuarta transformación llamada división de flujo. En la transformación de flujo dividido, una sentencia if es empleada para dividir el flujo de control del programa. Esta transformación fue habilitada por la transformación anterior. La sentencia if hizo de nuestro código algo más específico. Por lo que nos toca ahora generalizarlo.

2.2 Refactorización – Generalizando

La condición if(number == 2) fue un caso muy específico (coincidiendo con la intención de la prueba). Debemos refactorizar para manejar casos más generales.

if(number > 1) es más general debido a que está abierto a posibilidades.

3. Añadimos un Test Fallido para 3

Al incluir la tercera prueba assertThat(primeFactorsOf(3), isListOf(3)); dicha prueba fallará.

3.1 Transformación – Constante a Variable

Para lograr hacer pasar la prueba con la transformación más simple, aplicamos la transformación constant -> variable en la cual modificaremos el 2 que añadimos a la lista de factores por la variable de entrada number.

4. Añadimos un Test Fallido para 4

Para la cuarta prueba incluimos la siguiente sentencia:

assertThat(primeFactorsOf(4), is(Arrays.asList(2,2)));

4.1 Transformación – Flujo Dividido

De forma que logremos pasar esta prueba, debemos volver a hacer una división en el flujo, dependiendo si la entrada number es divisible por 2.

4.2 Transformación – Flujo Dividido Nuevamente

Aún con este cambio, otra de nuestras pruebas continúa fallando. Esto se debe a que el caso de los factores primos de 4 es exitoso, pero el caso de los factores primos de 2 debe incluir a un solo valor y no dos. Por lo que tendremos que dividir el flujo nuevamente para evitarlo.

Y con esto podremos pasar todas las pruebas.

4.3 Refactorización

En el caso de number > 1, la división es realizada dos veces. No debemos preocuparnos de ello en este momento debido a que pronto desaparecerá. No generamos ningún inconveniente si movemos la parte del segundo condicional number > 1 fuera de la primera cláusula condicional.

4.4 Refactorización

Al igual que con el código productivo, el código que compone nuestras pruebas también debe ser mantenido. Por lo que podemos refactorizar para mejorar su legibilidad al eliminar duplicación en el código.

5. Añadimos más pruebas

En los casos de 5, 6 y 7, estas pruebas funcionan correctamente si son incluidas debido a que su comportamiento se encuentra incluido en nuestro algoritmo.

6. Añadimos prueba fallida para el 8

assertThat(primeFactorsOf(8), isListOf(2, 2, 2));

La cual falla.

6.1 Transformación – If a While

Podemos aplicar la transformación If -> while de forma que pasemos la nueva prueba.

El bucle while es simplemente una forma generalizada del condicional if, por lo que if es una forma especial de la estructura while.

6.2 Refactorización

Se mejora la legibilidad del código al refactorizar el bucle while a un bucle for como se muestra a continuación.

7. Añadimos un Test Fallido para 9

Añadimos la prueba assertThat(primeFactorsOf(9), isListOf(3, 3));

7.1 Hacemos pasar con Duplicación

Añadimos la condición de división por 3 como se muestra a continuación para hacer que nuestra prueba pase.

7.2 Transformación para remover la duplicidad – Bucle más general

Hemos introducido una duplicidad en nuestro código. Podemos incurrir en estas mientras estemos trabajando en un ciclo de TDD, pero las mismas no deben registrarse en el repositorio de origen como código repetido. Esta redundancia no es una transformación, debido a que nada ha sido generalizado. Simplemente es un experimento que nos permite imaginar como debe ser la solución general.

Nuestra tarea ahora es aplicar un ciclo más generalizado para eliminar la duplicación. El código duplicado siempre es inusual y específico.

7.3 Refactorización

Mejoramos nuevamente la legibilidad al refactorizar el bucle while por un bucle for y eliminamos el condicional restante, para obtener el resultado final compuesto por dos bucles for fáciles de entender.

Conclusión

Las siguientes transformaciones fueron observadas en este ejercicio de ejemplo:

  • {} -> null (1)
  • null -> constant (2)
  • constant -> variable (4)
  • split flow (6)
  • if -> while (10)

Pudimos ver mediante la kata de ejemplo una ilustración del proceso descrito por el tío Bob, y ver que al aplicar las transformaciones que propone TPP conseguimos garantizar:

  • Menor tiempo en rojo (evitar el impasse)
  • Descubrimiento de los puntos principales del problema
  • Desarrollo de una solución genérica y con menos duplicación

La Premisa de la Prioridad de Transformación (TPP) es una de las herramientas con las que contamos para garantizar el cumplimiento de las reglas del desarrollo guiado por tests. Este listado de transformaciones no implica reglas inalterables, sino una guía para evitar los bloqueos en el ciclo de TDD, especialmente al hacer el cambio de rojo a verde.

Si te interesa conocer más sobre TPP puedes buscar el siguiente material:

Actualidad

26/10/2020

/ , , , ,

Diferencias entre DDD, Event Sourcing y CQRS

Hace unas semanas mi compañero Gustavo Caro hacía un repaso de cómo han ido evolucionando las arquitecturas de aplicaciones y en este artículo voy a intentar resolver algunas dudas que surgen cuando nos enfrentamos a arquitecturas orientadas a eventos.

Las arquitecturas orientadas a eventos han crecido en popularidad en los últimos años, y aunque no son un concepto nuevo ya que existen referencias a la programación dirigida por eventos que se remontan a los 70s, sí que están ganando importancia debido a las últimas tendencias en ingeniería del software.

Empecemos por el principio, una arquitectura orientada a eventos (EDA del inglés Event-Driven Architecture) es un patrón distribuido de arquitectura donde diferentes actores se comunican mediante eventos en base a roles: productores y consumidores.

Utilizando este tipo de arquitecturas, las empresas implementan sistemas flexibles que se pueden adaptar a toma decisiones y cambios en tiempo real. Los eventos se capturan a medida que ocurren y permite que productores y consumidores de eventos compartan información sobre el estado y la respuesta en tiempo real.

Los componentes en este tipo de arquitectura están altamente desacoplados lo que facilita escalar horizontalmente. También hay que remarcar el hecho de que añadir nuevos consumidores es sencillo, ya que las integraciones no son punto a punto. En la parte negativa está el hecho de que, debido a la propia naturaleza desacoplada de la arquitectura, hay que ser cuidadoso con los componentes que formen parte y las dependencias entre ellos.

Existen múltiples conceptos alrededor de este tipo de arquitecturas que a simple vista pueden parecer similares, pero te das cuenta de que no lo son cuando indagas un poco más: eventos de dominio, Event Sourcing, CQRS…

En este artículo voy a intentar aclarar las diferencias entre esos conceptos. ¡Empecemos!

Eventos de dominio

En DDD (del inglés Domain-Driven Design), los eventos de dominio se usan para describir hechos de negocio que ocurren dentro del dominio. Estos eventos son relevantes dentro del bounded context pero también para otros bounded context, permitiendo integración entre diferentes dominios.

Una importante característica de estos eventos es que deben contener un alto valor semántico expresado en el lenguaje que hablen los expertos de dominio.

Si quieres profundizar en DDD te recomiendo el siguiente artículo.

Event Sourcing

Event Sourcing hace referencia a sistemas donde el estado de la aplicación completa es almacenado como una secuencia de eventos. Aquí, el termino evento se refiere al “cambio de estado”, no es solamente una “notificación”.

Las aplicaciones persisten los eventos en un Event Store, que es una base de datos de eventos. En lugar de almacenar el estado actual de la aplicación directamente campos de una tabla en la base de datos, los eventos son almacenados cronológicamente y pueden ser usados para reconstruir el estado actual en memoria si fuera necesario.

Como ya nos decía Martin Fowler en un post original del año 2005: “Event Sourcing ensures that all changes to application state are stored as a sequence of events”

CQRS

Command Query Responsability Segregation (CQRS) es un patrón por el cual se tienen estructuras de datos separadas para leer y escribir información. CQRS no tiene que ver estrictamente con eventos, ya que se puede implementar sin hacer uso de ellos, pero es bastante común que se combine CQRS con Event Sourcing.

CQRS Diagram by Martin Fowler

La justificación de usar CQRS es que, en dominios complejos, un modelo único de lectura y escritura puede resultar muy complicado y se puede simplificar separando los modelos. Este hecho puede resultar determinante si los patrones de accesos difieren de manera considerable, como por ejemplo muchas lecturas y muy pocas escrituras.

Conclusiones

Como hemos revisado en este artículo , las arquitecturas orientadas a eventos ofrecen numerosas ventajas, pero en contrapartida los patrones a seguir son algo más complejos que en otras arquitecturas y por tanto hay que pensar bien cuándo conviene hacer uso.

Una herramienta que nos puede ser de gran ayuda en este tipo de arquitecturas es un catálogo de eventos. A medida que la aplicación crece y el número de componentes es mayor, el flujo entre los componentes se hace más difícil de seguir, así como sus interacciones. En este punto es donde un catálogo de eventos cobra importancia.

En relación al tipo de eventos (domino / event sourcing), es importante tener una idea clara del propósito y semántica que cada uno lleva, y aunque no son exclusivos y en algún punto pueden tener la misma información, es una buena practica mantenerlos separados.

En general este tipo de arquitectura puede resultar muy útil y aunque quizás sea complicado implementarlo en un sistema completo, sí que su uso en partes específicas del sistema puede ofrecernos la flexibilidad y desacoplamiento que podemos necesitar.