Proyectos

14/10/2022

/ , , , ,

Compra y paga en cómodos plazos

¿Qué es un préstamo al consumo?

Si eres de los que prefiere pagar cualquier bien de mayor importe en varias cuotas, seguro que has solicitado alguna vez un crédito al consumo.

Este tipo de préstamos  surgen de la necesidad de la población de poder sufragar algunos bienes no indispensables. Dejando de lado las hipotecas o la financiación para la compra de un vehículo, los préstamos de consumo permiten conseguir determinados productos o servicios gracias a su pago en cuotas.

La financiación cada vez es más común para la compra de todo tipo de bienes. Aunque hace años parecía casi exclusiva para la adquisición de una vivienda y era común ahorrar durante mucho tiempo para pagar los productos al contado, en las últimas décadas los pagos a plazos han aumentado exponencialmente para todo tipo de bienes y servicios.

Santander Consumer Finance es la unidad especializada en financiación al consumo del Grupo Santander que opera en 16 países europeos, China y Canadá.

Un producto sencillo, unos sistemas complejos

Aunque este producto bancario parece sencillo por la facilidad de acceso a estos préstamos de cantidades económicas reducidas, el ciclo de vida del préstamo es similar a cualquier otro de mayor cuantía: análisis de riesgo, cálculo de cuotas, pago de tasas, impagos, amortizaciones, liquidaciones, etc.

Desde ITERIAM ayudamos al banco mediante un servicio de mantenimiento correctivo y evolutivo de las aplicaciones globales destinadas a la concesión de créditos al consumo. El servicio incluye la monitorización de las aplicaciones para garantizar su disponibilidad teniendo en cuenta que las mismas dan servicio multipaís y multicliente.

En ese ámbito se enmarcan las aplicaciones que tienen los comercios para financiar sus compras en las que se introducen los datos del cliente y datos de solvencia y se realizan las consultas a CIRBE, ASNEF, RAI, etc. para finalmente aprobar o denegar la operación.

Las tecnologías que utilizamos en este proyecto se basan en .NET con Entity Framework 4.0, integración de front y back mediante servicios web y bases de datos Oracle.

Proyectos

14/10/2022

/ , , ,

Digitalización de la acción social

Cáritas Internationalis es una organización perteneciente a la Iglesia católica que agrupa 165 organizaciones nacionales de asistencia, desarrollo y servicio social y que promueve la acción social, la economía solidaria, la cooperación internacional y está presente en situaciones de emergencia.

En las entidades de acción caritativa y social hay muchas oportunidades de transformación digital, desde proyectos de modernización de sus aplicaciones hasta implantación de plataformas basadas en blockchain (como Alice) para dotar de transparencia todo el sistema de financiación y donaciones de estas entidades.

ITERIAM colabora con Cáritas en el desarrollo y soporte de aplicaciones dentro del área de acción social dentro de la estrategia de la organización de ir digitalizando los servicios que ofrece.

El primer proyecto en el que participamos fue la modernización del front-end de la aplicación de Ayudas Parroquiales, que es el instrumento que los más de 400 voluntarios de la organización para gestionar y tramitar todas las ayudas a las familias. Era una aplicación de escritorio que estaba realizada con Webforms y el objetivo del proyecto era actualizar la solución a una versión web responsiva utilizando la tecnología VUE.

Posteriormente, se añadió la funcionalidad de MODA-RE, que es un sistema de gestión de ropa de segunda mano, que se ofrece también como ayuda a las familias.

Recientemente hemos comenzado el desarrollo de una nueva aplicación para la creación y gestión de los planes anuales de actuación. Estos planes sirven para programar la actividad de Cáritas en las distintas acciones solidarias, pudiendo extraer datos en función de diferentes PKIs definidos en la aplicación. Para esta solución utilizaremos tecnología .NET Framework 6 y Angular en su última versión.

Proyectos

13/10/2022

/ , , , , , ,

Gestión documental de plantas solares en la nube

Contexto

Trina Solar es una multinacional líder en el sector fotovoltaico con presencia en Asia, Europa y América y con más de 19.000 empleados. Fundada en 1.997, su rápido crecimiento le ha valido para estar entre las 100 empresas de la lista de Fortune con un crecimiento más rápido, y desde 2.006 aparece en la Bolsa de Nueva York (NYSE).

Esta rápida expansión requería de una gestión documental homogeneizada que permitiera la gestión de los proyectos a nivel multinacional, cubriendo todo el ciclo de vida de desarrollo de proyectos solares, desde su diseño hasta la operación y mantenimiento.

Retos

A la hora de implantar una solución adecuada había que tener en cuenta diversos factores muy importantes para la compañía. Por un lado, la gestión debía adaptarse por completo al ciclo de vida de los proyectos del sector, e incluir dentro del ciclo de vida de la gestión documental, no solo al personal de Trina Solar, sino también a los clientes y proveedores de cada proyecto.

Además, la herramienta debía adaptarse al idioma local de cada oficina, incluyendo idiomas como el chino o el árabe.

Por otro lado, el proyecto incluía el reto de migrar más de 1 TB de documentación correspondiente a proyectos en curso o ya ejecutados, y que se gestionaba a través de directorios compartidos, lo que dificultaba aún más el control de la seguridad de acceso por parte de IT.

La solución

Muchas de empresas apuestan por soluciones comerciales especializadas en el tipo de proyectos del sector que, si bien se adaptan al ciclo de vida de sus proyectos, conllevan un alto coste en licencias, parametrización y mantenimiento.

ITERIAM plantea una plataforma de gestión documental completamente adaptada a la gestión de proyectos del sector fotovoltaico basada en las herramientas de Microsoft 365 en la nube.

Esto permite un importante ahorro de costes, ya que se aprovechan las licencias de Microsoft 365 ya adquiridas por Trina Solar para toda la compañía, en lugar de la adquisición de otra herramienta de coste más elevado.

Esta plataforma permite aprovechar la potencia de Microsoft 365 en distintos ámbitos para la gestión documental:

  • Acceso global garantizado, y seguridad de acceso centralizada en Azure Active Directory, incluyendo la gestión de usuarios externos como clientes (proveedores y clientes).
  • Políticas de seguridad y cumplimiento en relación a la visualización y descarga de archivos.
  • Capacidad de almacenamiento disponible, gestión de backups y recuperación de datos.
  • Disponibilidad de las aplicaciones en todos los idiomas, en función de la localización del usuario.
  • Implementación de flujos automatizados y tareas pendientes sobre Power Automate.
  • Interfaz web sobre SharePoint, haciendo uso de Hubs, sitios de proyecto, taxonomías, y componentes SPFx.

ITERIAM desarrolla una solución parametrizable mediante ficheros de configuración que permiten la configuración de cada proyecto en función de sus particularidades: grupos de seguridad, anexo J, usuarios internos y externos, estructura documental, flujos de aprobación disponibles, matriz de aprobación por tipo documental y carpeta, etc.

Para evitar un mantenimiento continuo, se desarrolla una máquina de estados sobre Power Automate, que se encarga de la gestión de estados de los flujos de aprobación de los documentos, en función del flujo configurado para tipo documental y los grupos de usuarios que participan en cada una de las etapas de aprobación.

A partir de un flujo único de aprobación, y en función de la matriz de aprobación definida en el proyecto, se gestiona el ciclo de vida de todo documento, pudiendo configurar una aprobación solidaria o conjunta, el envío del Transmittal y la copia del documento final a una nueva ubicación al ser aprobado. Además, permite incluir a proveedores y clientes en cualquier etapa del flujo de aprobación.

Por último, se automatizan tareas como la creación de nuevos sitios de proyecto con la estructura y configuración adecuada, la carga de documentación ya existente, y la gestión y restauración de la seguridad a través de grupos, lo que permite devolver el control del sistema a IT.

Resultados

En primer lugar, Trina Solar dispone en poco tiempo de un sistema de gestión documental homogéneo, flexible a las particularidades de cada proyecto y adaptado a todos los idiomas de la compañía, sin ningún coste adicional de licencias y mantenimiento.

Además, simplifica la gestión por IT, no solo a nivel de seguridad y la automatización de procesos documentales, sino también en cuanto a gestión y mantenimiento de la infraestructura y hardware asociado.

Por último, la solución planteada no requiere de mantenimientos posteriores si se desean realizar posibles modificaciones en los flujos o estructura de proyectos, lo que permite a los gestores documentales adaptarse a las necesidades locales de cada país, sin necesidad de nuevos desarrollos ni la intervención de IT.

Proyectos

12/10/2022

/ , , , , ,

Implantación de Microsoft 365

Contexto

La Mutualidad de la Abogacía es una entidad sin ánimo de lucro que ofrece a los profesionales del mundo del Derecho a sus familias soluciones para cubrir todas sus necesidades de previsión, ahorro e inversión.

En la continua búsqueda de ofrecer más y mejores servicios tanto a los mutualistas como a sus propios empleados, la Mutualidad desea abordar un proyecto de mejora de su infraestructura tecnológica que le permita mejorar la comunicación tanto a nivel de compañía como entre sus empleados, mejorando la gestión del conocimiento y fomentando la colaboración entre los empleados.

Debido a la necesidad de cambios y el crecimiento dentro del grupo en los próximos años, se ve en la necesidad de implantar una intranet corporativa y un ecosistema de aplicaciones que les facilite la comunicación, la gestión del conocimiento y automatizar los procedimientos internos de la compañía.

Retos

Este proyecto plantea retos tecnológicos y humanos. Tecnológicamente se plantea el reto de la migración de la infraestructura técnica inicial, basada en repositorios de archivos descentralizados y correo on premise, a una infraestructura en la nube sin pérdida de datos ni de servicio.

Desde el punto de vista humano, se plantean los retos de adopción de las nuevas herramientas y la capacitación de los responsables de su administración. Esto hace necesaria una colaboración estrecha con los departamentos de IT, Comunicación y RRHH de la Mutualidad.

La solución

ITERIAM realiza la conceptualización, diseño y desarrollo de la intranet corporativa y gestión documental, mejorando la comunicación corporativa e interdepartamental y fomentando el trabajo colaborativo.

Esta intranet se implementa haciendo uso de diferentes soluciones de Microsoft 365, principalmente:

  • SharePoint Online para el desarrollo del sitio de la intranet y los subsitios correspondientes a las distintas áreas departamentales.
  • Power Automate, para la creación de flujos de aprobación de los distintos repositorios documentales.
  • Power BI, para la implementación de cuadros de mando para la Dirección que faciliten la toma de decisiones de negocio.
  • Microsoft Teams, para la creación de grupos de trabajo y espacios colaborativos integrados en la propia intranet.

El proyecto se divide en varias fases:

  • Una primera fase para la construcción una intranet unidireccional, con contenidos orientados a la comunicación corporativa, el acceso a las aplicaciones y los repositorios documentales centralizados.
  • Una segunda fase en la que se implementaron los distintos flujos de aprobación en base a los tipos documentales y procesos definidos por el área de Calidad.
  • Una tercera fase en la que se incorporaron todas las opciones colaborativas y de gestión de equipos.

Esta división de fases permitirá a la Mutualidad de la Abogacía ir evolucionado su intranet hacia una red social corporativa según vayan adoptando los usuarios las diferentes herramientas y nuevas formas de trabajo, y se vayan incluyendo diferentes piezas de la solución Microsoft 365.

Resultados

La Mutualidad de la Abogacía dispone en la actualidad de una intranet muy visual, flexible y fácil de administrar, lo que les permite ser completamente autónomos y sin mantenimiento de desarrollo. Además, ha mejorado la comunicación corporativa, la colaboración interdepartamental y la gestión metodológica y documental, mejorando la productividad y el sentimiento de pertenencia de sus empleados.

Proyectos

12/10/2022

/ , , , , ,

Servicio gestionado de canales online

La Mutualidad de la Abogacía es una entidad sin ánimo de lucro que ofrece a los profesionales del mundo del Derecho a sus familias soluciones para cubrir todas sus necesidades de previsión, ahorro e inversión.

En ITERIAM llevamos colaborando con ellos más de tres años para la evolución continua de sus Canales Online a través de un modelo de Servicio Gestionado. A través de este servicio nos responsabilizamos del desarrollo evolutivo y los mantenimientos correctivo, preventivo y perfectivo de todos los servicios del área de canales online.

Estos servicios son principalmente el área privada de los mutualistas y su aplicación móvil, la plataforma de onboarding digital y el portal privado de la Fundación.

En coordinación con la PMO de la Mutualidad, se define la estrategia digital, coordinando, planificando y priorizando el porfolio de proyectos y evolutivos relacionados con los canales online para clientes, en función de la carga de trabajo del equipo base multidisciplinar asignado. Esto permite un desarrollo y evolución continua de los diferentes canales, adaptándolos a las necesidades tecnológicas y de negocio de forma ágil.

El equipo, en colaboración con las áreas de Arquitectura y Sistemas de la Mutualidad, es responsable también del despliegue y monitorización de los distintos servicios dentro de canales online, incluidas las app en los diferentes stores.

ITERIAM establece un modelo de gestión que permite realizar un ajuste proporcionado y flexible ante cambios de la demanda de la Mutualidad, ampliando o reduciendo el equipo base en función de la demanda.

Desde el punto de vista tecnológico, trabajamos en este cliente con:

  • Web y App
    • ReactJS, Javascript y webpack
    • IONIC, Angular, Cordova
  • Back-end
    • .Net Core, Azure DevOps, CI/CD, Identity Server
    • .NET, Web API, MVC, despliegues en IIS
    • Azure Service Bus
  • SalesForce
  • Control de versiones y desarrollo de software colaborativo: TFS, Gitlab

Desde el punto de vista metodológico, utilizamos metodologías Agile como Scrum y Kanban.

Proyectos

19/09/2022

/ , , , , ,

Modernización de aplicaciones de gestión interna

Contexto

IKEA es probablemente la tienda de muebles más conocida a nivel mundial.

Desde el punto de tecnologías de información, al igual que otras grandes multinacionales, existen tanto sistemas corporativos como soluciones locales a cada país que posteriormente tendrán que consolidar información con los primeros.

IKEA Ibérica disponía de un parque de aplicaciones de escritorio que daban servicios de contabilidad, facturación e impuestos de forma local e independiente de los sistemas corporativos del grupo. Como directriz corporativa, se debía adaptar tecnológicamente ese conjunto de aplicaciones – denominadas internamente como “Service Office” – adecuando la solución tecnológica a los requisitos establecidos por la organización.

Los retos

Como bien sabemos en ITERIAM, la actualización tecnológica de un sistema no solo depende de la tecnología y es muy importante la metodología de trabajo en un proyecto de migración de entornos obsoletos a entornos actualizados.

En muchos casos no existe documentación suficiente y el conocimiento de los aplicativos se encuentra en las personas.

Adicionalmente, en este caso se añadía la complejidad del tiempo, ya que las nuevas aplicaciones deberían estar listas para el inicio del año fiscal, 1 de enero de 2019.

La solución

Aunque inicialmente el proyecto debía ser una actualización tecnológica, desde ITERIAM se planteó un proyecto más ambicioso que incluyese también una redefinición funcional de todas esas aplicaciones aprovechando las ventajas que nos ofrecerían las nuevas tecnologías.

Para llevar a cabo una modernización exitosa de estas aplicaciones debíamos hacer un acercamiento mixto. Por un lado, colaborar activamente con los responsables de las aplicaciones para conocer todo el alcance funcional, recoger los nuevos requisitos y definir correctamente todas las integraciones entre ellas y con los sistemas corporativos. Por otro lado, analizar en profundidad el código fuente de las aplicaciones mediante el uso de herramientas.

Con este acercamiento podemos tener un conocimiento completo de las aplicaciones.

A partir de aquí, y para cumplir el exigente “time-to-market” trazado por el cliente, organizamos varios equipos ágiles de desarrollo, uno por cada aplicación. El equipo técnico iba balanceando entre aplicaciones para compartir experiencias, reutilizar recursos y cumplir la planificación establecida.

Tecnológicamente, las aplicaciones se migran a un desarrollo web con tecnologías .NET, utilizando Entity Framework, Linq, tratamiento de ficheros planos, XML e importación de ETL, diseño de consultas y procedimientos almacenados en SQLServer y Oracle. Toda la solución está soportada sobre Azure.

Los resultados

En un periodo aproximado de 5 meses, se aborda una modernización de aplicaciones de escritorio obsoletas hasta aplicaciones web basadas en arquitecturas de última generación alineadas con los requisitos corporativos de IKEA.

La involucración de los usuarios desde el primer momento del proyecto permite dar valor a las inversiones pasadas y aumenta la motivación de todas las partes para conseguir los objetivos del proyecto: se consigue formar a los usuarios y desplegar las aplicaciones durante un complicado mes de diciembre, que están operativas desde el 1 de enero de 2019 hasta el día de hoy.

Un proyecto de este tipo ejecutado por personal técnico cualificado permite la reutilización real de código, mejora de la mantenibilidad de las aplicaciones y otros aspectos como la accesibilidad, usabilidad, simplicidad y seguridad de las nuevas aplicaciones.

Desde entonces ITERIAM ofrece a IKEA un servicio de mantenimiento correctivo y evolutivo de estas aplicaciones.

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

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

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.

Actualidad

04/08/2020

/ , , , ,

La evolución de las aplicaciones: camino a los microservicios

La evolución de las aplicaciones siempre ha estado estrechamente relacionada con la evolución tecnológica y las necesidades de los usuarios y las empresas.

Del mismo modo que las organizaciones empresariales evolucionan en la forma de hacer las cosas, las aplicaciones informáticas deben seguir el mismo camino para lograr su único objetivo, satisfacer dichas necesidades y servir al usuario de la forma más eficiente. Es como un ciclo que se retroalimenta constantemente:

Esta evolución ha obligado a un cambio en los sistemas, adaptando las infraestructuras que ofrecen la disponibilidad de dichos servicios y aplicaciones, de tal forma que los usuarios que los consumen lo puedan hacer de una forma más eficiente, segura y además en remoto, es decir, disponible en internet.

Un ejemplo sencillo para mostrar que adaptarse en esta evolución es obligatorio, sería una aplicación de mensajería que tiene un éxito inesperado. Es cierto que el aumento de demanda no es sino el principio del éxito, pero también puede ser el principio del fracaso si la infraestructura que soporta dicha aplicación de mensajería no está preparada para soportar tanta demanda. En este caso, la aplicación está condenada al fracaso.


Aplicación monolítica

La característica principal de estas aplicaciones es que hacen uso de una base de código única para sus servicios y funcionalidades. Es decir, la aplicación es «responsable» de todas las tareas necesarias para realizar una determinada función.

Este tipo de aplicaciones se destacan por combinar la interfaz del usuario y la capa de acceso a los datos en el mismo programa y alojarlos en la misma máquina (o nodo).

Una de las características para tener en cuenta es el llamado escalado vertical. Si el servidor que aloja la aplicación recibe un aumento en las peticiones de usuario, es posible que los recursos existentes en la máquina sean insuficientes. La única posibilidad es aumentar los recursos en dicha máquina (RAM, espacio en disco, etc.) dentro de sus límites.

Goza de una arquitectura sencilla, puesto que toda la aplicación se aloja en el mismo nodo, donde las comunicaciones entre las distintas partes de la aplicación siempre son de forma local.

Debido a su arquitectura, las interferencias entre los componentes de la aplicación son más delicadas, y un fallo en una de sus partes puede poner en evidencia toda la aplicación.

Otra desventaja, la tenemos en la complejidad de las actualizaciones, que pueden afectar a la disponibilidad de todo el sistema durante un período de tiempo durante su despliegue.

Por el simple hecho de tener una infraestructura estática y fija por años, el mantenimiento es más costoso y es más difícil evolucionar de forma eficiente a las nuevas necesidades del mercado.

En definitiva, aunque son fáciles de desarrollar, una aplicación que aglutina toda su funcionalidad no es la mejor opción si queremos aspiraciones crecimiento complejas, más usuarios, más desarrolladores, etc.


Aplicación distribuida

Su principal cometido es tener la aplicación disgregada en múltiples nodos, dando la posibilidad de que en cada nodo exista un componente de la aplicación o un mismo componente replicado en varios nodos.

Esta arquitectura es bastante más compleja y difícil de gestionar y administrar que una aplicación monolítica. De hecho, se deben utilizar numerosas herramientas que antes no eran en absoluto necesarias. Pero esta idea de tener la aplicación distribuida en varios nodos fue un punto de inflexión, que dio lugar a conceptos muy importantes y ha favorecido de forma incuestionable la existencia de aplicaciones mucho más robustas, escalables, eficientes y seguras.

Uno de los grandes conceptos que introduce este tipo de aplicaciones es el escalado horizontal. Es decir, cuando por cuestiones de demanda los recursos actuales ya no son suficientes, en vez de aumentar los recursos de un nodo (escalado vertical), lo que se hace es incrementar el número de nodos dedicados al procesamiento de ese componente demandado. Esto es una gran ventaja ya que el límite de recursos ya no será el soportado por un nodo, sino el soportado por tantos nodos como tengamos en nuestra arquitectura.

Otro gran concepto que surge, aunque todavía no de forma automática y madura, es la llamada elasticidad. Es decir, al igual que se aumentan el número de nodos dedicados para soportar un aumento de demanda, se pueden reducir si la demanda disminuye y dejarlos disponibles para otros procesos. Este concepto contribuye a un reparto de recursos más eficiente.

La seguridad y la robustez mejoran notablemente, ya que es más probable que los problemas de seguridad de un nodo sean cercados en ese nodo, no poniendo en riesgo toda la aplicación si alguno de ellos se pone en evidencia.

Otra gran ventaja con respecto a las aplicaciones monolíticas es que las actualizaciones no conllevan desplegar toda la aplicación ya que, en este caso el despliegue será a nivel de nodo. El mantenimiento es mucho más fácil y la durabilidad de la aplicación será mayor por la facilidad de adaptación a los cambios.

Todas estas características hacen que las aplicaciones distribuidas sean ideales cuando adecuar los recursos que se deben utilizar en función de la demanda sea clave.


Arquitectura SOA

Esta arquitectura fue la que insistió en la utilización de aplicaciones distribuidas y orientadas a servicios.

La idea fue hacer que esos servicios fueran independientes, y las interacciones entre ellos se hicieran bajo ciertos protocolos estandarizados de comunicación, como WSDL y SOAP.

Esta independencia hacía posible que servicios desarrollados por diferentes tecnologías, pudiesen comunicarse entre sí, sin ningún problema.

Debido a que los servicios son más independientes, cambios en ciertos componentes de la aplicación no alteraban al resto, simplemente debían seguir cumpliendo los criterios de comunicación establecidos.


Cloud Native (Cloud Computing)

La arquitectura SOA está más enfocada a la arquitectura de la aplicación. Cloud Native se enfoca más en la arquitectura del sistema que alberga, distribuye y ofrece las aplicaciones.

Este punto de vista, lo que ofrece es básicamente el uso de recursos en la nube bajo demanda automatizada. Es decir, va a existir una elasticidad gestionada de forma automática por el sistema en la infraestructura dedicada a cada una de las aplicaciones que distribuyen. Consiguiendo que el uso de los recursos sea lo más eficiente posible.

Estas infraestructuras dinámicas dedicadas hacen posible que las aplicaciones sean resilientes antes situaciones adversas, por ejemplo, por demanda extrema, errores hardware, etc.


Arquitectura de microservicios

No existe una definición formal pero básicamente es una evolución de SOA y está orientada al trabajo con servicios muy pequeños e independientes.

El objetivo es aislar los distintos componentes de una aplicación con el fin de que cada uno sea una aplicación por sí misma.

Otra de las diferencias con SOA es la comunicación entre los servicios; Ya no sería con servicios web WSDL o SOAP, sino vía HTTP con API-REST.

Muchos beneficios suelen asociarse a los Microservicios, pero tres de los más importantes son: una entrega más rápida, escalabilidad mejorada y una mayor autonomía.

Los microservicios son el facilitador de una mayor agilidad en términos de adaptación a los cambios del mercado. Su filosofía es compatible y está directamente relacionada con procesos ágiles de desarrollo: entrega continua. Es decir, el mantenimiento de la aplicación conlleva modificaciones en los microservicios, pudiendo llevar a cabo muchas subidas a producción en un corto período de tiempo de forma independiente (continuous deliverydeploymentimprovement).

Esto aumenta la agilidad del software porque cada microservicio se convierte en una unidad independiente de desarrollo, implementación, operaciones, versiones, y escalamiento.

En realidad, aquí el término escalabilidad es algo ambiguo. Podría referirse, por ejemplo, a la escalabilidad del tiempo de ejecución del sistema, a su adaptabilidad (a un costo razonable), o a los cambios en el número de usuarios que acceden a él. O también podría referirse a poder aumentar el número de microservicios sin interferencias con los otros o a la capacidad del proceso de desarrollo para acomodar a muchos desarrolladores trabajando en paralelo.

Lo que está claro es que, con los microservicios la unidad a escalar es el servicio. Por tanto, cada uno de ellos son una unidad autónoma que pueden ser desarrollados, desplegados y operados por un equipo diferente. Por eso, suelen implementarse sobre contenedores: un microservicio en un nodo.

En estos casos, es de máxima importancia sincronizar una responsabilidad compartida entre el desarrollador y el sistema que lo alberga. Esta es la base de la filosofía DevOps.

La antigua filosofía introducida hace décadas por el principio «Divide y vencerás» ha sido puesta en práctica en innumerables ocasiones: en los algoritmos informáticos, en el envío de pequeños paquetes de datos en el protocolo IP, en la agrupación de las tareas en 7 capas en la arquitectura de red OSI, etc.

Es curioso como la misma filosofía se sigue adoptando en las infraestructuras tecnológicas actuales. Divide and win my friend 🙂



Nota. Los diagramas de las arquitecturas monolítica y de microservicios pertenecen al blog de Chris Richardson. Te animo a que lo visites para leer sus interesantes artículos.