Tendencias Archives - Software Evolutivo

Apache ActiveMQ Artemis

Bryan Diaz — Wed, 17 Jul 2024 04:28:25 +0000

En este artículo vamos a hablar sobre una herramienta muy popular para la comunicación entre aplicaciones llamada Apache ActiveMQ Artemis, además revisaremos un ejemplo de cómo implementar su funcionamiento utilizando dos microservicios implementados con Spring Boot y Java.

A menudo, nos encontramos con eventos que suceden en nuestros sistemas y necesitamos que otros sistemas se enteren de ellos. Notificar estos eventos de manera síncrona puede generar problemas de rendimiento y disponibilidad, ya que los sistemas dependen de la respuesta inmediata de otros sistemas. En cambio, hacerlo de manera asíncrona presenta varias ventajas, como la reducción de la dependencia y el acoplamiento entre sistemas, mejorando la eficiencia y la escalabilidad de nuestras aplicaciones.

A veces, incluso tenemos procesos manuales que requieren la intervención de una persona para realizar acciones en respuesta a un evento. Con la ayuda de Apache ActiveMQ Artemis, podemos conectar nuestras aplicaciones de manera más eficiente y eliminar estos procesos manuales que no generan valor a nuestros negocios. Este tipo de productos, conocidos como MOM (Message Oriented Middleware), nos permiten implementar el asincronismo, facilitando la comunicación entre sistemas de una manera más flexible y robusta.

Artemis

Comenzamos hablando sobre qué es ActiveMQ Artemis.

En términos oficiales, Apache ActiveMQ Artemis es un intermediario que facilita la comunicación entre diferentes sistemas o aplicaciones. Es de código abierto, muy popular y multiprotocolo, basado en Java. Artemis permite integrar aplicaciones multiplataforma utilizando diversos protocolos, como AMQP (Advanced Message Queuing Protocol – Protocolo Avanzado de Cola de Mensajes), JMS, MQTT, STOMP, OpenWire, entre otros. Gracias a esta variedad de protocolos, Artemis es una excelente opción para tener comunicación entre dos aplicaciones y poder pasar información de un sistema a otro cuando ocurre un evento.

Arquitectura

La estructura utilizada es un Middleware Orientado a Mensajes (MOM), el cual permite la comunicación a través del intercambio de mensajes de forma asíncrona. Esto significa que las operaciones se llevan a cabo sin requerir que todas las partes involucradas en la comunicación estén disponibles al mismo tiempo que ocurre el envío de eventos, permitiendo así que los procesos continúen su ejecución sin esperar una respuesta inmediata.

En Artemis contamos con dos tipos de envío de mensajes: los mensajes que se envían a colas de tipo anycast y los de tipo multicast.

Anycast: Conocido como punto a punto (Point-to-Point), en este tipo de cola, varios consumidores están a la escucha de la misma cola y van leyendo los mensajes a medida que llegan. Sin embargo, no todos los consumidores pueden leer el mismo mensaje al mismo tiempo.

Multicast: Es un modo de distribución de tipo publicación-suscripción (pub/sub). Cada mensaje que se envía a una dirección de tipo multicast se replica a las colas que contienen cada sistema que esté a la escucha de los mismos. Como se muestra en la gráfica, aquí tenemos dos consumidores y ambos se enterarán del mismo mensaje al mismo tiempo.

Para el desarrollo de este blog, se trabajará con colas de tipo anycast.

La versión que utilizaremos de ActiveMQ Artemis será la última hasta la fecha de este blog, que es la 2.35. Podemos buscarla en DockerHub como se puede observar en la imagen.

Spring Boot

Para este blog vamos a trabajar con microservicios de Spring Boot, utilizaremos Maven y el lenguaje Java. La última versión de Spring Boot hasta la fecha de este blog es 3.3.1, y la versión de Java es 21. Agregaremos ActiveMQ Artemis a los proyectos. Los proyectos tienen el nombre de “producer” y “consumer”. El producer es el encargado de enviar el mensaje a Artemis y crear la cola en Artemis, y el consumer es el encargado de suscribirse a esa cola y leer los mensajes que envíe el producer.

Escenario a Resolver

En un hospital, hay dos sistemas involucrados en la gestión de camas que funcionan de la siguiente forma:

El Sistema A, encargado de registrar la disponibilidad de camas cuando un paciente abandona la sala de emergencias.
El Sistema B, monitorea la ocupación de camas en todo el hospital.
Actualmente, cuando el Sistema A registra que una cama está disponible, una enfermera debe ingresar manualmente esta información en el Sistema B.
Se busca una mejora para sincronizar automáticamente estos sistemas, de modo que cualquier actualización en el Sistema A se refleje instantáneamente en el Sistema B, eliminando la necesidad de registros manuales.

Para desarrollar este requerimiento, los proyectos que creamos en Spring Boot serán: el producer como nuestro Sistema A y el consumer como nuestro Sistema B.

En el proyecto que creamos en Spring, al agregar la dependencia de Docker y ActiveMQ Artemis, se genera un archivo compose.yaml. Utilizaremos este archivo para levantar nuestro contenedor de Artemis. En el proyecto producer, como es el que va a generar el evento, editaremos el archivo compose.yaml, añadiendo la siguiente información:

Para levantar el contenedor de Artemis con las modificaciones realizadas al archivo compose.yaml, en este blog se ejecutará con Podman porque la práctica se está realizando en un sistema operativo Fedora, que ya lo incluye. Pero si cuentan con Docker también pueden utilizarlo, no habría problema. Ejecutamos nuestro archivo desde la ubicación donde se encuentra nuestro archivo compose.yaml y ejecutamos:

podman-compose -f compose.yaml up

o con Docker:

docker compose -f compose.yaml up

Esto comenzará a descargar la imagen de Artemis.

Una vez que en los logs salga un mensaje como el siguiente: AMQ241004: Artemis Console available at link, podemos ingresar a un navegador y acceder a la URL localhost:8161 para acceder a la pantalla de Artemis.

Las credenciales serán las que configuramos en nuestro archivo compose.yaml, en este caso artemis como username y artemis como password.

Una vez dentro de la consola, podemos observar las versiones de Artemis y navegar por el mismo.

Se debe deshabilitar el Docker Compose de los proyectos Spring Boot, en el archivo de propiedades application.properties colocar:

spring.docker.compose.enabled=false

Para que no se levante Artemis cada que se ejecute el proyecto, sino que se levante una única vez cuando nosotros lo necesitemos.

Para poder enviar el evento desde el Sistema A al Sistema B, necesitamos un método que nos ayude con el envío. En este caso, hemos creado el método pushRequestPaymentOrder (puedes darle cualquier nombre). Primero, creamos nuestro DTO que contendrá la información que necesita el Sistema B. Para nuestro caso planteado, vamos a enviar un mensaje que indique que la cama está disponible y el ID de la cama correspondiente.

Utilizamos el atributo de clase que inyectamos de JmsTemplate, una clase de Spring que facilita el envío y recepción de mensajes a través de JMS. Utilizamos el método convertAndSend, que convierte el objeto DTO en un mensaje en formato JSON y lo envía a TopicDemo, que es el nombre de la cola a la que se envía el mensaje.

El método pushRequestPaymentOrder se llama desde la lógica de negocio en el sistema cuando se necesita encolar información. Por ejemplo, cuando se detecta que una cama está disponible, se invoca este método para enviar la información al Sistema B.

Para que podamos observar la información de ese mensaje en Artemis, debemos tener en nuestro producer lo siguiente:

El convertidor se utiliza tanto en el productor como en el consumidor para manejar la transformación del DTO. En el Sistema A, el convertidor transforma el DTO de un objeto Java a JSON antes de enviarlo a Artemis. Luego, cuando consumimos el evento en el Sistema B, el convertidor transforma el JSON almacenado en Artemis de vuelta a un objeto Java. Esto asegura que los datos se mantengan consistentes y fácilmente manejables a lo largo del proceso de comunicación entre sistemas.

Una vez confirmado que nuestro evento llegó con normalidad a Artemis y podemos observar su información, lo siguiente es levantar nuestro Sistema B, que en este caso sería nuestro consumidor. Debemos configurarlo para que esté a la escucha de los eventos que lleguen a una cola específica para poder leerlos y acceder a su información.

Eso lo realizamos de la siguiente manera:

Creamos nuestro método que tiene la etiqueta @JmsListener, que indica que está a la escucha de lo que llegue a esa dirección de cola, llamada TopicDemo, que es el nombre de la cola donde el producer envió el evento. Pero como se mencionó anteriormente, al momento de leer el evento, está leyendo un valor tipo JSON, por lo que queremos que lo transforme al objeto que necesitamos. Para ello, aquí también utilizamos el método jacksonJmsMessageConverter.

Como podemos ver en los logs, al levantar este microservicio se hará el consumo del mensaje que representa el evento. Ya tenemos que la cama está disponible, y lo siguiente sería actualizar en el Sistema B, en base de datos, que ahora la cama con el ID que acabamos de leer está disponible.

Resumen

En resumen, teníamos un Sistema A que contaba con una información, pero esa información necesitaba saberla el Sistema B. Para que el Sistema B se enterara, era necesario contar con una persona que analizara los cambios en el Sistema A y luego actualizara el Sistema B. Pero, ¿Qué ocurre si durante el almuerzo hay cambios o si la persona encargada de actualizar se distrae? No contaremos con la información actualizada en tiempo real.

Para eso, presentamos la solución planteada en este Blog: ahora no se requiere de una persona para hacer estas actualizaciones, sino que el Sistema A será un producer que envía eventos a Artemis cuando se desocupe alguna cama. Luego, el Sistema B será un consumer que esta a la escucha de esos eventos en Artemis para leerlos y actualizar automáticamente en sus registros que ahora la cama está disponible, asegurando así información actualizada en todo momento.

Esto fue un ejemplo con el uso de colas de tipo anycast. Próximamente se hará un blog con un escenario para colas de tipo multicast.

Si tienes alguna pregunta o comentario sobre este tema, no dudes en dejarlos abajo. Nos encantaría saber tu opinión y ayudarte con cualquier duda que puedas tener. ¡Gracias por leer!

Link de los proyectos:

https://github.com/softwareevolutivo/artemis

Referencia:

https://activemq.apache.org/components/artemis/documentation/2.0.0/address-model.html

Taller en Youtube – Apache ActiveMQ Artemis ▶ ¿Qué es y para qué sirve?

https://www.youtube.com/watch?v=Sn4TyzmtLxU

¿Quieres mejorar tus procesos de integración?

Descubre nuestros servicios y agenda una demo.

Ver Demo

The post Apache ActiveMQ Artemis appeared first on Software Evolutivo.

Lego Scrum en Software Evolutivo: ¿Realmente la rutina mata el amor por Agile?

Gissella Trujillo — Fri, 14 Jun 2024 23:50:43 +0000

¡Software Evolutivo es una empresa ágil! ¿O tal vez no? Durante el Team Building trimestral de Software Evolutivo, nos sumergimos en una experiencia única que combinó la diversión de LEGO con los principios ágiles de Scrum.

Cuando te introduces en el mundo de la agilidad, es habitual encontrar muchas fotografías o referencias de equipos que parecen divertirse “jugando” con Legos de colores. Siendo formadores, coaches o líderes de proyecto, enseguida nos planteamos si este “juego” también podría ser útil para nosotros.

En este blog, explicaremos cómo Lego Scrum nos permitió descubrir aspectos que podrían haber pasado desapercibidos durante la rutina del día a día y fortalecer la colaboración entre nuestros equipos Comercial y de Desarrollo. A través de las metodologías ágiles, buscamos transmitir y asentar mejor los conocimientos en nuestros equipos. Acompáñanos para conocer más sobre esta experiencia.

Índice:

1. El Desarrollo del Lego Scrum: Personas y proyectos

2. Planeación y Estimación

3. Sprint y Construcción

4. Revisión y Retrospectiva

5. Lecciones Aprendidas

6. Conclusiones

1. El Desarrollo del Lego Scrum: Personas y proyectos

Durante el evento, dividimos a nuestro equipo en grupos multidisciplinarios, es decir, mezclamos a personal del área comercial con el equipo de Desarrollo, e incluso incluimos a nuestro jefe Jorge. Una vez que todos estábamos bien integrados y mezclados, cada equipo recibió uno de estos desafíos:

💬 Cada proyecto Lego tenía sus propias historias de usuario y desafíos únicos, lo que les ofreció oportunidades para enfrentar situaciones distintas y demostrar toda su creatividad y habilidades.

Reglas de Lego Scrum (las mismas que Scrum, pero ajustadas):

– Los equipos deben usar solo los materiales proporcionados.
– Cada historia de usuario debe completarse antes de pasar a la siguiente.
– Se alienta la comunicación y colaboración dentro de los equipos.
– Cada Sprint debe resultar en un producto o mejora tangible que se pueda revisar.
– ¿Y el Product Owner? Compartimos uno para los dos grupos.
– ¿Y el Scrum Master? Cada equipo se encargó de nombrar uno.

2. Planeación y Estimación

Comenzamos con una sesión de planificación, donde cada equipo seleccionó el proyecto a construir y estimó el tiempo necesario para completarlo.

– El equipo “Transporte Espacial Lego” 🚀 utilizó la técnica de Planning Poker, para llegar a un consenso sobre la complejidad de cada historia de usuario. ¡Muy bien, estaban liderando con esa organización!

– Lamentablemente nuestro equipo “Ciudad Lego” 🏙️ no empezó con estimación (a algunos agilistas no les gusta estimar) y durante el primer sprint no lograron entregar todo el valor.

Desde la perspectiva de los participantes, se consideró la falta de realizar una incepción para poder entender mejor el producto como una limitación significativa en el proceso de desarrollo.

💬 ¡Recuerda! Siempre realiza una reunión de incepción y planificación, y estima tus historias para asegurar que todos los miembros del equipo tengan una comprensión clara de las tareas, prioricen adecuadamente y establezcan expectativas realistas sobre lo que se puede lograr en cada sprint. Esto también ayuda a identificar posibles obstáculos con anticipación y facilita la comunicación y la colaboración eficaz dentro del equipo.

3. Sprint y Construcción

Con el plan en su lugar, cada equipo se embarcó en su primer Sprint de construcción. Durante este tiempo, los grupos aplicaron los principios de Scrum, realizando reuniones “diarias” de stand-up para compartir el progreso, identificar obstáculos y ajustar el plan según fuera necesario.

¿Y el Product Owner? Bueno, indicamos que la comunicación con el PO se realizaría On Demand.

– El grupo “Transporte Espacial Lego” 🚀 utilizó muy bien sus tiempos y preguntaron todos los posibles obstáculos con anticipación, ¡Muy bien, seguían liderando con esa gestión de riesgos!
– Lamentablemente nuestro equipo “Ciudad Lego” 🏙️ no empezó con estimación y casi pero casi no lograron entregar todo el valor comprometido para el final del Sprint.

Imagen: Equipos en Sprint de Construcción

Imagen: Product Owner Disponible On Demand

Imagen: Equipo "Transporte Espacial Lego" en Acción

Imagen: Equipo "Ciudad Lego" en el Sprint Final

4. Revisión y Retrospectiva

Al final de 3 sprints, y con algunos sobresaltos mientras se apagaban los incendios, cada equipo presentó su proyecto terminado. Con cada revisión se pudo mejorar el producto y con cada retroalimentación mejoraron el proceso. Ambos equipos aprendieron de sus errores iniciales y al final de todo…

– “Transporte Espacial Lego” 🚀 y el equipo “Ciudad Lego” 🏙️ ¡culminaron exitosamente sus proyectos! 🏁

💬 Entonces, ¿Software Evolutivo es ágil? No lo sabremos sin antes tener una sesión de retroalimentación donde discutimos los resultados y compartimos feedback constructivo.

Aunque en los equipos más jerárquicos y tradicionales, el proceso de feedback puede verse con temor por el miedo a un ataque personal o una mala interpretación de las observaciones, en Software Evolutivo practicamos una comunicación asertiva para identificar: áreas de mejora, reconocer los logros del equipo y fomentar un ambiente de aprendizaje continuo.

5. Lecciones aprendidas

Aunque trabajamos juntos día a día, cuando se encendió el cronómetro, nos encontramos resolviendo problemas urgentes, y tal vez olvidamos algunas cosas importantes, la experiencia del Lego Scrum fue reveladora en varios aspectos:

– La colaboración entre los equipos comerciales y de desarrollo se fortaleció significativamente mientras trabajaban juntos para completar las historias de usuario. Cuanta más cohesión tengamos en el equipo, más resultados exponenciales obtenemos.
– Estima tus historias para tener una visión clara del esfuerzo necesario para completarlas.
– La negociación con el Product Owner es clave para entregar valor al cliente, ya que ayuda a establecer expectativas realistas y a alinear las prioridades con las necesidades del cliente.
– Si no estamos seguros de alcanzar a entregar todo lo que nos pide el cliente, podemos aplicar la regla de Pareto y entregar primero lo que es más importante, maximizando así el valor entregado en el tiempo disponible.
– Además, recuerda que en equipos pequeños el Scrum Master también puede formar parte del Scrum Development Team, lo que facilita una colaboración más estrecha y una mayor comprensión de los desafíos y oportunidades del proyecto.

💬 Recuerda: Al realizar una retrospectiva del evento Lego Scrum en general, lo que estamos buscando es la mejora de la ejecución del evento como tal y como eso nos ayuda a replicar y mejorar las actividades para obtener mejores resultados en el futuro. También en este caso, el facilitador y el Product Owner recibieron feedback por parte de los desarrolladores y el equipo comercial.

6. Conclusión

El Lego Scrum fue mucho más que una actividad de Team Building; fue una experiencia transformadora que fortaleció nuestra colaboración y mejoró nuestra capacidad para entregar valor al cliente. Si estás buscando una forma innovadora de fortalecer la colaboración en tu organización y maximizar la entrega de valor al cliente mediante enfoques ágiles, ¡considera el Lego Scrum como una opción! En nuestro próximo Blog se realizará la guía paso a paso para replicar Lego Scrum con tu equipo.

¿QUIERES SER ÁGIL?

¡Descubre cómo los frameworks agile maximizan la entrega de valor al cliente!

Contáctanos para obtener más información sobre cómo podemos ayudarte a implementar estas prácticas en tu organización.

Conoce más

💬 Nos encantaría conocer tu opinión sobre cómo las metodologías ágiles han impactado en tu equipo y en la entrega de valor al cliente. ¡Déjanos tus comentarios y comparte tus experiencias!

The post Lego Scrum en Software Evolutivo: ¿Realmente la rutina mata el amor por Agile? appeared first on Software Evolutivo.

Descubriendo a Quarkus: ¿Que es, Características y por qué utilizarlo?

Bryan Diaz — Thu, 23 Mar 2023 15:43:36 +0000

Descubriendo a Quarkus: ¿Que es, Características y por qué utilizarlo?

En la actualidad, Quarkus representa la pila tecnológica de Java Nativa de Kubernetes (una colección de herramientas, marcos, lenguajes de programación y bibliotecas) diseñada para GraalVM y OpenJDK HotSpot (Máquinas Virtuales de Java).

Los desarrolladores pueden crear aplicaciones con el mismo Stack (Estructura de Datos) y microservicios más ligeros, rápidos y escalables gracias a las mejores bibliotecas y estándares de Java utilizados en su creación. Esta herramienta permite a los desarrolladores escribir código en Java/Kotlin mientras proporciona funciones de gestión de memoria y escalabilidad. Por lo tanto, “Quarkus” ayuda a los desarrolladores a trabajar de manera proactiva y eficiente si buscan una forma eficiente de desarrollar una determinada aplicación o microservicio Java, ya que es una de las mejores opciones disponibles.

Quarkus es más que un proyecto de código abierto presentado por Red Hat (Que conquistó a la comunidad Java y el primer release fué presentado en el 2019), por el hecho de que combina la productividad y la alegría del desarrollador (similar a Node.js), con la velocidad y rendimiento de GO, puesto que aquello le permite a los desarrolladores Java crear soluciones tecnológicas y arquitecturas modernas futuristas.

Turețchi (2022) muestra que Quarkus es una pila de Java nativa para la nube, basada en contenedores y diseñada para mejorar la productividad de los desarrolladores, reducir la huella de memoria de las aplicaciones y microservicios Java. Esta herramienta brinda a los desarrolladores una experiencia de tiempo de ejecución unificada y liviana mediante el uso de GraalVM, HotSpot y otros lenguajes como Kotlin, lo que permite el desarrollo eficiente de aplicaciones modernas nativas de la nube, con un enfoque en la escalabilidad y la gestión de la memoria. En consecuencia, Quarkus, como parte de un conjunto de herramientas tecnológicas, facilita la creación rápida de servicios modernos nativos en la nube.

Aplicaciones de Quarkus y por qué es actualmente el marco más popular

Quarkus es uno de los marcos de desarrollo nativos en la nube más populares en la industria tecnológica debido a sus características notables. Ofrece un tiempo de arranque rápido, una pequeña huella de memoria y una gestión escalable de la memoria. Por esta razón, el marco Quarkus con Kotlin es ampliamente utilizado en la industria. Su capacidad para reducir los tiempos de desarrollo también ayuda a mantener un alto rendimiento con servidores y redes de baja gama.

Cabe recalcar que, todos estos elementos claves, inciden en la creación de aplicaciones con un alto grado de rapidez/eficiencia, ya que se pueden implementar y escalar fácilmente en varias arquitecturas de la nube.

Con las capacidades de Quarkus, las organizaciones ahora pueden desarrollar servicios modernos con mayor velocidad y eficiencia que nunca, y usando Java o Kotlin proporciona una experiencia de desarrollo fluida con un modelo de programación reactivo moderno.

Arquitectura Empresarial Tradicional vs. Arquitectura Contenerizada.

En Quarkus, puedes desarrollar aplicaciones Java y ejecutarlas directamente en el sistema operativo subyacente sin necesidad de una máquina virtual de Java intermedia. Esto reduce significativamente el tiempo de ejecución, el consumo de memoria y otros recursos, lo que se traduce en una ejecución más eficiente y rápida de la aplicación. Quarkus lleva poco más de tres años en el mercado y ofrece una propuesta de valor para la creación de aplicaciones Java de última generación. Además, proporciona arquitecturas escalables para ejecutar aplicaciones Java y Serverless en la nube.

Arquitectura Tradicional

En la arquitectura tradicional, el primer nivel consta del hardware esencial para ejecutar el segundo nivel, que es el sistema operativo, como por ejemplo una Mac OS o Linux. En el tercer nivel, se requería la instalación de la popular Máquina Virtual de Java (JVM), mientras que en el último nivel, comúnmente utilizado en entornos empresariales, se instalaba un servidor de aplicaciones. Para ello, era necesario contar con una máquina virtual de Java capaz de comunicarse con el sistema operativo subyacente y traducir toda la aplicación al sistema operativo. Esta arquitectura era común en empresas, pero con el tiempo ha dejado de ser una buena práctica debido a sus implicaciones en el desarrollo, la agilidad y la complejidad en su mantenimiento. Actualmente, existen otras arquitecturas que ofrecen soluciones más ligeras y eficientes.

Figura 1: Arquitectura Java Tradicional

Arquitectura Contenerizadas.

En la actualidad, la arquitectura contenerizada se ha vuelto cada vez más popular gracias a la presencia de nuevas tecnologías en el mercado. Entre ellas, la tecnología Docker (Si te interesa, en un artículo anterior compartimos los Primeros pasos en Docker.) ha tomado un gran protagonismo en la mayoría de las empresas. Docker nos permite construir y empaquetar aplicaciones de forma portable, lo que significa que pueden ejecutarse en diferentes sistemas operativos y entornos sin necesidad de compilar la aplicación para un sistema operativo en particular. En esencia, Docker realiza una tarea similar a la que la máquina virtual de Java realizaba, pero aplicable a cualquier tipo de aplicación.

En la arquitectura contenerizada, el primer nivel es el hardware, seguido por el sistema operativo, que puede ser cualquiera que tenga la capacidad de ejecutar contenedores. En el siguiente nivel, se debe instalar Docker para poder colocar nuestras aplicaciones en contenedores y ejecutarlas. Gracias a esta arquitectura, podemos tener diferentes versiones de aplicaciones sin que esto suponga un problema, ya que cada una se ejecuta en un contenedor independiente. Esto nos brinda una ventaja significativa en términos de mantenimiento y evita conflictos entre versiones de aplicativos.

Figura 2: Arquitectura Contenerizadas

Quarkus representa una mejora significativa en la arquitectura contenerizada al eliminar la necesidad de tener una JVM en cada contenedor para la ejecución de nuestras aplicaciones. Esto permite un despliegue más rápido y una menor utilización de recursos, lo que se traduce en una mayor eficiencia y ahorro de costos.

Superpoderes de Quarkus: Gestión de Memoria y Escalabilidad

Los desarrolladores pueden utilizar Quarkus, un marco Java que les brinda las herramientas necesarias para administrar la memoria de manera efectiva y escalar sus aplicaciones. Quarkus cuenta con una variedad de herramientas de optimización de memoria, como administración de memoria dinámica, recolección de elementos no utilizados y dimensionamiento de almacenamiento dinámico. Además, Quarkus proporciona soluciones de escalabilidad para aplicaciones que necesitan escalar rápidamente hacia arriba o hacia abajo, a través de herramientas de escalabilidad como orquestación de contenedores, escalado automático y equilibrio de carga. Estas características permiten a los desarrolladores asegurarse de que sus aplicaciones puedan manejar grandes cantidades de tráfico sin problemas de rendimiento. Con la administración de memoria dinámica de Quarkus, los desarrolladores pueden realizar cambios en sus aplicaciones sobre la marcha sin necesidad de reiniciar la aplicación, lo que les permite probar rápidamente los cambios y optimizar el uso de la memoria. Es importante destacar que la variedad de herramientas de escalabilidad permite la escalabilidad horizontal, lo que permite a las aplicaciones manejar fácilmente una mayor carga de usuarios.

Características y ventajas de Quarkus sobre los marcos tradicionales de Java

Quarkus es un marco independiente del tiempo de ejecución diseñado para proporcionar una forma eficiente y rentable de desarrollar aplicaciones nativas de la nube. Ofrece una gestión inteligente de la memoria y herramientas que facilitan a los desarrolladores la creación de aplicaciones con menos recursos y tiempo de arranque más rápidos que los marcos de Java tradicionales, lo que permite que las aplicaciones sean escalables de forma rápida y eficiente. Además, Quarkus tiene ventajas sobre los marcos de Java tradicionales en cuanto a la gestión inteligente de la memoria, la escalabilidad y el rendimiento mejorado, y brinda a los desarrolladores la capacidad de escribir código en cualquier idioma que elijan e implementarlo como una aplicación en contenedores, lo que lo convierte en una excelente opción para aquellos que buscan aprovechar los beneficios de la computación en la nube manteniendo el control sobre sus aplicaciones.

Desventajas de Quarkus sobre los marcos tradicionales de Java

Aunque Quarkus tiene muchas ventajas para el desarrollo de aplicaciones en la nube, también tiene algunas desventajas a tener en cuenta. Una de ellas es que, al ser un marco relativamente nuevo, puede haber una curva de aprendizaje para los desarrolladores que no estén familiarizados con él. Además, debido a que Quarkus utiliza tecnologías de vanguardia, puede haber algunos problemas de compatibilidad con bibliotecas y frameworks más antiguos. Por último, aunque Quarkus es altamente escalable, puede ser menos adecuado para aplicaciones que no necesiten escalabilidad horizontal, ya que esta característica puede agregar complejidad y costo al desarrollo y la implementación.

El tamaño de la imagen nativa de Quarkus puede ser una desventaja para algunos usuarios, por el hecho de que puede resultar más grande que el tamaño de la imagen de una aplicación Java tradicional. Esto se debe a que la imagen nativa incluye todo lo necesario para que la aplicación se ejecute sin depender de una máquina virtual, lo que aumenta su tamaño. Sin embargo, es importante tener en cuenta que esta desventaja puede ser mitigada mediante la optimización de la imagen y la eliminación de componentes innecesarios. Además, el tamaño de la imagen puede ser compensado por las ventajas en cuanto a rendimiento y eficiencia que ofrece Quarkus.

Conclusiones

En resumen, Quarkus es un nuevo marco de desarrollo de Java de alto rendimiento que permite a los desarrolladores crear aplicaciones empresariales de manera fácil y rápida. Con sus características únicas como la eficiencia del tiempo de ejecución, el soporte de Java y la integración con tecnologías empresariales, Quarkus es una opción atractiva para los desarrolladores que buscan crear aplicaciones rápidas y escalables. Por esa razón, vale la pena explorar Quarkus como una opción para su próximo plan de desarrollo de aplicaciones.

Referencias

https://quarkus.io/
Gascó Compte, A. (2022). Sistema de ayuda a las pruebas de fragilidad. Obtenido de: https://repositori.uji.es/xmlui/handle/10234/200566
Turețchi, G., & Cerbu, O. (2022). Aplicarea frameworkului Quarkus în cadrul arhitecturii bazate pe microservicii. In Conferinţa tehnico-ştiinţifică a studenţilor, masteranzilor şi doctoranzilor (Vol. 1, pp. 56-59).

The post Descubriendo a Quarkus: ¿Que es, Características y por qué utilizarlo? appeared first on Software Evolutivo.

Cucumber + Spring boot 2 + Junit 5

Johannes Caranqui — Thu, 24 Nov 2022 15:15:28 +0000

Cuando no se realiza un buen testing el costo de arreglar un error en producción es elevado, por lo cual aplicar una buena técnica de testing nos ayuda a dormir mejor en las noches, para ello, poder incluir al equipo de desarrollo y negocio en las pruebas automatizadas será un gran avance para mantener el código y los requerimientos bajo control, aquí nace las pruebas de aceptación y BDD, una buena implementación y planteamiento de requerimientos es fundamental en esta etapa de desarrollo.

Como antecedente, comprendamos que Cucumber es un software de testing TDD que nos permitirá elaborar pruebas automáticas a partir de criterios de aceptación fácilmente entendibles por los intervinientes en el proceso, el cual vamos a implementar en éste tutorial, así como Spring Boot y JUnit.

Para iniciar, necesitamos un proyecto básico con Spring Boot 2, en esta oportunidad lo crearemos con Spring Initializer, un API que permite la generación de proyectos con sus dependencias permitiendo simplificar esta etapa de arranque, aunque también se puede utilizar el plugin de Spring Boot de IntelliJ o Visual Studio Code.

Usaremos la siguiente configuración:

Configuración inicial con Spring Boot Initializer

Configuración de Cucumber y Junit 5

En este paso agregaremos las dependencias de maven (librerías que se necesita para el funcionamiento correcto de Cucumber con Spring y Junit).

1.1 Dependencias de Maven (pom.xml)

1.1.1 Cucumber JVM

<groupId>io.cucumbergroupId>

<artifactId>cucumber-javaartifactId>

<version>7.8.1version>

<scope>testscope>

dependency>

Podemos encontrar el listado de versiones aquí.

1.1.2 Junit y Cucumber

<groupId>io.cucumbergroupId>

<artifactId>cucumber-junit-platform-engineartifactId>

<version>7.8.1version>

<scope>testscope>

dependency>

Podemos encontrar el listado de versiones aquí.

1.1.3 Junit platform suite (ya que la opción @Cucumber de Junit4 quedó obsoleta)

<groupId>org.junit.platformgroupId>

<artifactId>junit-platform-suiteartifactId>

<version>1.9.0version>

<scope>testscope>

dependency>

Podemos encontrar el listado de versiones aquí.

1.1.4 Finalmente Spring y Cucumber

<groupId>io.cucumbergroupId>

<artifactId>cucumber-springartifactId>

<version>7.8.1version>

<scope>testscope>

dependency>

Podemos encontrar el listado de versiones aquí.

Definición e implementación de “Features”

Para esta definición, lo más usual es utilizar Gherkin; al ser de alto nivel, no es tan técnico, por lo que, es posible involucrar al personal de negocio.

Creamos el archivo demo.feature en src/test/java//cucumber/features con el siguiente contenido:

Feature: the hello endpoint can be retrieved

Scenario: client makes call to GET greeting endpoint

Given client wants to write username

When client calls greeting endpoint

Then client receives hello text and username

El contenido no debe contener muchas definiciones técnicas, recordemos que el objetivo es que todo el equipo se involucre.

Definición de pasos:

Given: Dada una situación en la que configuramos el test.

When: Acción que se realiza o un evento llega.

Then: Espero que suceda algo o puedo comprobarlo.

Configuración de puntos de entrada

La siguiente clase nos sirve como punto de entrada de Cucumber para ejecutar los tests, la podemos llamar de cualquier forma pero siempre tomando en cuenta las convenciones.

Creamos la clase CucumberTest.java en src/test/java//cucumber con el siguiente contenido:

@Suite

@IncludeEngines(“cucumber”)

@SelectClasspathResource(“com/sevolutivo/demo/cucumber/features”)

@ConfigurationParameter(key = GLUE_PROPERTY_NAME, value = “com.sevolutivo.demo.cucumber.stepDefs”)

public class CucumberTest {

}

@Suite y @IncludeEngines(“cucumber”) son el equivalente a la antigua @Cucumber, pero que con la versión 7 de Cucumber quedó obsoleta.

En JUnit 5, podemos definir las opciones de cucumber en el fichero junit-platform.properties, en la carpeta resources de tests.

@SelectClasspathResource(“/cucumber/features”) nos dice dentro de la carpeta resources donde tenemos los ficheros .feature

@ConfigurationParameter(key = GLUE_PROPERTY_NAME, value = “.cucumber.stepDefs”) le decimos donde están las clases de pegamento, es decir, los steps.

Configuración opcional adicional (junit-platform.properties)

Creamos el archivo junit-platform.properties en src/test/resources con el siguiente contenido:

cucumber.publish.quiet=true

cucumber.publish.enabled=false

cucumber.plugin=pretty, html:target/cucumber-reports/Cucumber.html, json:target/cucumber-reports/Cucumber.json,junit:target/cucumber-reports/Cucumber.xml

En el ejemplo anterior, estamos quitando el banner que aparece al ejecutar cucumber y le decimos que no publique los resultados en su servicio de la nube. También estamos generando los informes localmente en formato html, json y xml en el directorio target/cucumber-reports.

Configuración de Spring

Vamos a configurar Cucumber para que pueda hacer uso del contexto de Spring con la notación @SpringBootTest, vamos a inyectar también TestRestTemplate para hacer llamadas Rest.

Creamos el archivo CucumberSpringConfiguration.java en src/test/java//cucumber:

@SpringBootTest(webEnvironment=SpringBootTest.WebEnvironment.RANDOM_PORT)

public class CucumberSpringConfiguration {

@Autowired

protected TestRestTemplate testRestTemplate;

}

Para comprobar el correcto funcionamiento ejecutamos ./mvnw clean verify en consola y el resultado debería ser similar a lo siguiente:

Podemos comprobar que no encuentra la definición de pasos y nos sugiere implementarlos de acuerdo a sus recomendaciones.

Implementación de pasos (steps ó glue code)

Los pasos o steps es el mapeo de cada paso del escenario definido en el archivo .feature, ésta clase tiene la notación @CucumberContextConfiguration que hace que Cucumber la use como configuración de contexto de Spring.

Creamos el archivo DemoSteps.java en src/test//cucumber/stepDefs:

@CucumberContextConfiguration

public class DemoSteps extends CucumberSpringConfiguration {

private String username;

private ResponseEntity response;

@Given(“client wants to write username”)

public void clientWantsToWriteAGreeting(){

username = “user001”;

}

@When(“client calls greeting endpoint”)

public void clientCallsToGreetingEndpoint() {

response = testRestTemplate.getForEntity(“/greeting/” + username, String.class);

}

@Then(“client receives hello text and username”)

public void clientReceivesHelloTextAndGreeting() {

Assertions.assertEquals(“hello “ + username, response.getBody());

}

Implementación de Rest API controller

Creamos una clase controlador DemoController.java con un método GET /greeting en src/main/java//web que retorna una cadena con un saludo:

@RestController

public class DemoController {

@GetMapping(“/greeting/{username}”)

public String greeting(@PathVariable String username){

return “hello “ + username;

}

Ejecución

Una vez listo toda la implementación, ejecutar ./mvnw clean verify y obtendremos lo siguiente:

Si se usa IntelliJ Idea, al ejecutar los test de Cucumber implementados, como resultado se obtendrá algo similar a esto:

Conclusiones

Los tests de aceptación son una herramienta importante si el objetivo es integrar al equipo de negocio y al equipo de desarrollo, mejorando así el planteamiento de los escenarios, requerimientos y casos de análisis.

En éste tutorial hemos planteado un caso básico de implementación y la configuración de Cucumber, Spring Boot y JUnit 5 y así obtener una arquitectura básica o referencial para futuras implementaciones.

El código fuente se puede encontrar en github.com.

The post Cucumber + Spring boot 2 + Junit 5 appeared first on Software Evolutivo.

Consideraciones antes de aceptar un trabajo remoto

Gissella Trujillo — Tue, 04 Oct 2022 17:38:22 +0000

Si en 2019 alguien hubiera predicho que una gran parte o toda la empresa:

Podría hacer la transición al trabajo remoto con solo unos días de anticipación.
Contar con un aumento de la productividad después de un período de ajuste y;
Muchos trabajadores no querrían volver a la oficina.

Seguramente no lo hubiéramos creído, debido a que tradicionalmente el trabajo remoto tenía una mala reputación. Aun así, encuestas realizadas de forma independiente indican que esta es una descripción precisa de la evolución del trabajo remoto para muchas empresas.

Según Forbes, “el trabajo remoto ya no es un privilegio”, y la consultora Fast Company lo considera un esfuerzo más productivo y lucrativo. Con más y más personas buscando oportunidades de trabajo remoto cada año, compartimos lo que implica este estilo de vida, particularmente en comparación con el trabajador de oficina más tradicional .

Para este estudio, Fast Company encuestó a 1004 empleados de tiempo completo en los EE. UU., 505 de los cuales trabajaban de forma remota. Comparando su productividad hasta sus hábitos de gasto e incluso su salud.

Movilización

Viajes largos al trabajo causaron que 1 de cada 4 encuestados dejara un trabajo en algún momento. Sin embargo, para los empleados remotos, el “viaje” puede durar solo lo que se tarda en llegar a la computadora. Y esto tuvo un serio impacto tanto en la billetera como en el tiempo libre de los empleados.

En comparación con los empleados de oficina, los trabajadores remotos ahorraron un promedio anual de $4523 solo en combustible (EE.UU). Esto también equivalía a 408 horas adicionales.

En Ecuador, según el informe de El Comercio, los habitantes de la capital que se desplazan a su trabajo pierden en promedio 173 horas al año por el tráfico, lo que equivale a 7 días de tiempo libre al año.

Actividad Física

Los empleados remotos encuestados eran más saludables en términos de actividad física. En promedio, realizaban dos horas y 44 minutos de ejercicio físico cada semana, lo que representaba 25 minutos más cada semana que los trabajadores de oficina. Tanto la dieta como el ejercicio son importantes para la salud de sus empleados, por lo que cada vez vemos más empresas que ofrecen beneficios de bienestar.

Productividad

Las diferencias en la capacidad para concentrarse o encontrar el enfoque dentro y fuera de la oficina fueron mínimas: al 8 % de los trabajadores remotos les resultó difícil concentrarse, en comparación con el 6 % de los que estaban en la oficina.

Sin embargo, el impacto real se produjo con la microgestión. Si se rastrea el tiempo de pantalla y/o mouse de los empleados, el 39 % de los empleados remotos y el 56 % de los empleados de oficina encontraron formas de evitar trabajar.

Dada la evidencia que muestra que la productividad mejora con el trabajo remoto, sería fácil suponer que una mayor eficiencia simplemente viene con el estilo de vida remoto, sin embargo existen consideraciones: motivación y riesgo de fuga

¿Cómo se mantiene la motivación en trabajo remoto?

El 33% de los empleados remotos insistieron en que tener un horario de trabajo establecido era la forma más efectiva de mantenerse productivo. Otro 25 % se mantuvo productivo al elegir trabajar en el mismo lugar todos los días. Esto empieza a sonar un poco como el trabajo de oficina tradicional, ¿no?. Sin embargo, el método número 1 absoluto que los trabajadores remotos sugirieron para mantenerse productivos fue tomar descansos.

Riesgo de Fuga

El 50% quería ser su propio jefe algún día, en lugar de abrirse camino en la escala corporativa. Otro 21 % ya había empezado su propio negocio, eligiendo mantenerse remoto para mantener la flexibilidad.

Conexión con colegas

Las prioridades, para todos los trabajadores, estaban bien equilibradas. La mayoría (70%) afirmó que el trabajo y las relaciones con los compañeros de trabajo eran igualmente importantes. Sin embargo, pueden ir en detrimento de la productividad, especialmente si trabaja en una oficina.

Los trabajadores de oficina pasaban más de una hora cada día hablando con sus compañeros de trabajo sobre temas no relacionados con el trabajo. Los trabajadores remotos, por otro lado, solo hablaron con sus compañeros de trabajo sobre temas no relacionados con el trabajo durante 29 minutos.

Sin embargo, discutir temas no relacionados con el trabajo puede mejorar sus capacidades relacionadas con el trabajo.

Mantener buenas relaciones personales en el trabajo pueden afectar todo, desde sus niveles de estrés hasta la productividad e incluso la felicidad, por lo que no es necesariamente bueno para una empresa que los empleados hablen exclusivamente de negocios. En cambio, se debe permitir que florezcan las conversaciones amistosas.

Más de 1 de cada 10 millennials estuvo de acuerdo en que las relaciones laborales eran más importantes que su carga de trabajo y priorizaron activamente esos vínculos con sus compañeros de trabajo.

Acto de equilibrio

Sin una oficina o lugar de trabajo tradicional, la línea entre el trabajo y la vida personal evidentemente comienza a desdibujarse. En otras palabras, los empleados remotos tienen un peor equilibrio entre la vida laboral y personal. Mientras que el 29% de los trabajadores remotos lucharon por encontrar un equilibrio adecuado entre el trabajo y la vida personal, solo el 23% de los empleados de oficina sintieron lo mismo. Y empeoró cuando se trataba de millennials remotos: casi 1 de cada 3 participantes en este grupo demográfico tuvo dificultades para mantener su propio equilibrio entre el trabajo y la vida personal.

Trabaja a tu manera

La ansiedad y el estrés también aumentaron al trabajar fuera de la oficina. El 54 % de los empleados remotos dijeron que se habían estresado demasiado durante la jornada laboral y el 45 % experimentó altos niveles de ansiedad, en comparación con el 49 % y el 42 % respectivamente de los empleados de oficina.

Trabajar de forma remota puede sonar como un sueño hecho realidad: causa menos distracciones, elimina el viaje diario y ayuda a ahorrar tiempo y dinero. Ganar-ganar-ganar. Pero antes de dejar tu trabajo o solicitar un horario remoto, recuerda que este estilo de vida no está completamente libre de inconvenientes. La evidencia también muestra que el trabajo remoto se correlaciona con niveles más altos de estrés y semanas laborales más largas.

Al igual que con la mayoría de las opciones de carrera, es importante seguir los caminos que sean mejores para ti.

Fuentes:

What Jobs are Being Done at Home During the COVID-19 Crisis? https://www.hbs.edu/ris/Publication%20Files/20-138_ec6ff0f0-7947-4607-9d54-c5c53044fb95.pdf

COVID-19 AND REMOTE WORK: AN EARLY LOOK AT US DATA

https://adamozimek.com/admin/pdf/covidremote.pdf

https://www.forbes.com/sites/forbesbusinesscouncil/2021/03/19/10-remote-workplace-trends-to-look-out-for-in-2021/?sh=f96dc6d2ffd7

https://www.fastcompany.com/90318974/the-rise-of-remote-working-will-continue

https://www.elcomercio.com/actualidad/quito/pierden-promedio-horas-trafico-conductores.html

https://info.totalwellnesshealth.com/blog/how-your-work-relationships-impact-your-health

https://www.elcomercio.com/tendencias/sociedad/trabajo-remoto-tendencia-laboral-crecimiento.html

The post Consideraciones antes de aceptar un trabajo remoto appeared first on Software Evolutivo.

Docker: Primeros pasos

Ariel Altamirano — Thu, 30 Jun 2022 22:55:58 +0000

Docker fue presentado en marzo de 2013 por Solomon Hykes en PyCon como una herramienta para desarrolladores, la cuál permite empaquetar e implementar fácilmente aplicaciones dentro de un contenedor, pero, ¿Qué es un contenedor?

Hykes describió a los contenedores como: unidades autónomas de software que se pueden entregar y desplegar en cualquier servidor ya que están aisladas a nivel de proceso y tienen su propio sistema de archivos, por ende, no son dependientes de librerías o dependencias externas para ejecutarse.

¿Cómo funciona Docker?

Los contenedores se han presentado como una alternativa a la virtualización que usan las máquinas virtuales (VM) debido a los múltiples beneficios que brindan los contenedores, entre ellos está que los contenedores son mucho más livianos que las VMs. Docker es la opción más común para implementar contenedores, sin embargo, existen más opciones como Podman, LXD, entre otros. En la figura 1, podemos ver que cada máquina virtual tiene su propio Sistema Operativo (SO) invitado por encima del Host, a diferencia de los contenedores que comparten el SO del anfitrión (Host) y es por eso que son más livianos.‎

Figura 1. Funcionamiento de Docker y VMs

El hecho de que los contenedores no usen un SO completo ayuda a que sean más livianos, es decir, reduce de gran manera la carga que soporta la máquina anfitriona, además, el espacio de almacenamiento es menor ya que solamente utiliza lo mínimo para funcionar, y el tiempo que necesita para lanzar una aplicación es considerablemente menor a las máquinas virtuales.

Diferencias entre Contenedores y VMs

Las máquinas virtuales nos permiten crear entornos con sistemas operativos totalmente aislados del sistema operativo host, obteniendo así un control total sobre el sistema operativo invitado, de esta manera se puede mezclar diferentes sistemas operativos entre el host y los invitados.

Por otro lado, los contenedores además de permitirnos desplegar aplicaciones de manera más rápida también ayudan a crear entornos de desarrollo replicables entre los diferentes miembros de un equipo de desarrollo y así asegurar que se ejecutará de la misma manera en todos los equipos, independientemente del sistema operativo cada integrante del equipo tendrá el ambiente funcional.

Docker cada vez es más indispensable entre los desarrolladores.

A continuación, en la tabla 1 se presentan las diferencias entre contenedores y VMs.

Contenedores	Máquinas Virtuales
Despliegue en segundos	Despliegue en minutos
Generalmente son ligeros (KB – MB)	Generalmente son pesadas (Mb – Gb)
Pueden compartir el sistema operativo	Tiene un sistema operativo independiente
Usa menos recursos	Usa más recursos
Se pueden destruir y recrear en cuestión de segundos	Se puede exportar e importar en un nuevo host en cuestión de minutos
Por lo general vienen con un ambiente listo para usarse	Se tiene que prepara el ambiente para ser usadas
Se pueden crear en segundos	Su creación lleva más tiempo que los contenedores
Parametrización de límites para el consumo de recursos de la máquina host	Pre aprovisionamiento de recursos de la máquina host

Tabla 1. Diferencias entre contenedores y máquinas virtuales

Arquitectura de Docker

Docker utiliza la arquitectura cliente servidor, en donde, el cliente de Docker tiene el trabajo de comunicarse con el demonio de Docker para que pueda crear, ejecutar o distribuir los contenedores.

Este demonio de Docker puede ser tanto local como puede ser remoto ya que el cliente y el demonio de Docker se comunican mediante una API REST.

Figura 2. Arquitectura de Docker

En la figura 2 se puede observar 3 grandes divisiones:

Client: se encarga de crear un puente de comunicación para que el usuario pueda interactuar con el demonio de Docker mediante diferentes comandos como: docker run.
Docker Host: dentro de esta división se encuentra los contenedores creados por el usuario (Apagados o encendidos), también las imágenes descargadas que se pueden utilizar para crear contenedores, y, finalmente el demonio Docker que escucha las peticiones de la API REST y el cuál administra tanto contendores, imágenes, redes y volúmenes. El demonio de Docker también se puede comunicar con más demonios para administrar los servicios de Docker.
Registry: Los registros de Docker almacenan imágenes de Docker, Docker Hub es un repositorio público y es el repositorio predeterminado de Docker para buscar imágenes y descargarlas mediante comandos como docker pull.

Por qué usar contenedores

Docker brinda un solo objeto para poder ejecutar con total confianza en cualquier equipo, además de que su sintaxis simple brinda el control absoluto de la implementación y por ende la fácil identificación de problemas ya que se maneja por fases.

Entre los muchos beneficios que ofrece Docker, para los desarrolladores se ha vuelto primordial ya que:

Entrega de software aislado con rapidez

Estandarización de operaciones para mayor control de implementación y despliegue

Manejo de código entre diferentes equipos ya sea locales o remotos

Cuando usarlos

Docker facilita la creación y distribución de microservicios por lo que es usado en aplicaciones con arquitectura de microservicios distribuidos, que mediante CI/CD se puede automatizar el despliegue de los mismos y estandarizando los procesos y entornos. Al ser los contenedores independientes y de fácil distribución, también son muy usados para preparar e instalar un entorno de algún servicio para usuarios sin conocimientos técnicos.

Conclusiones:

Facilitan preparar un nuevo ambiente de trabajo independientemente de la máquina anfitriona.
Permiten arrancar aplicaciones rápidamente aprovechando los recursos de hardware.
Se puede mantener un control de versiones para la infraestructura ya que docker se gestiona mediante archivos de texto plano

Referencias

The post Docker: Primeros pasos appeared first on Software Evolutivo.

Mob Programming, colaboración en equipo

Johannes Caranqui — Thu, 16 Jun 2022 22:36:52 +0000

¿Qué es mob programming?

Popularizado por Woody Zuill, es una estrategia de programación para desarrolladores en grupo en la que trabajan en una única tarea al mismo tiempo, podríamos tomar como referencia a pair programming pero a una escala mayor.

Originalmente fue pensado para sesiones presenciales, pero poco a poco se ha adaptado para sesiones remotas, la idea principal es que un desarrollador sea piloto y sea el encargado de “pilotar” mientras que el resto actuará de “navegadores” brindando mejores prácticas para afrontar la tarea, refactorización de código y reducción de “smells” o malas prácticas de programación.

Para sesiones presenciales, se utilizará un solo ordenador, proyector y todos los desarrolladores en una misma sala, mientras que en sesiones remotas se utiliza varios ordenadores (uno por desarrollador remoto, lo cual puede sonar una desventaja ya que cada máquina debe tener un ambiente listo para desarrollar) y se proyecta su código en cualquier herramienta de videoconferencia como Google Meet, Jitsi, etc, así como manejar un repositorio de versionamiento como Github, Gitlab, entre otros.

Más información en el sitio web oficial.

Principios:

Herramienta para Mob remoto:

Para sesiones remotas se popularizó la herramienta Mob, la cual mejora la agilidad para el versionamiento de código.

Desarrollado por Remote Mob Programming, es una herramienta desarrollada en GO, mantiene las ramas limpias y solo crea “commits” temporales de proceso entre desarrolladores.

El tiempo de versionamiento se reduce considerablemente, lo que permite a los desarrolladores mantener su concentración en el código y no en el versionamiento.

Remote Mob Programming ofrece plugins para los principales IDEs de desarrollo como Visual Studio Code e IntelliJ.

Conclusiones:

Mob se da muy bien para trabajar con historias de usuario grandes y de alto valor de negocio.
Mob facilita el proceso de aprendizaje de los miembros del equipo de negocio y tecnológico.
Cuando las personas se respetan, colaboran y están dispuestas a aprender, Mob funciona muy bien.

The post Mob Programming, colaboración en equipo appeared first on Software Evolutivo.

Agilidad empresarial: Abrazar el cambio o morir en el intento

Gissella Trujillo — Wed, 27 Apr 2022 15:47:27 +0000

Agilidad empresarial

La competencia actual por cambiar en una economía basada en servicios es más fuerte que en la economía de producción que predominó el siglo pasado, por lo que es vital que una organización tenga la capacidad de adaptarse a nuevas condiciones y cambiar su dirección, a esto se lo conoce como Agilidad Empresarial.

El nuevo modelo económico cambiante ha transformado el mercado y se pronostica que la tendencia se mantendrá.

Algunos ejemplos de estos cambios los vemos en:

Expertos pronostican que esto no se limitará a industrias hoteleras, de transporte y entretenimiento, las cuales han hecho que empresas como Airbnb, Uber y Didi tengan tanto éxito en el mercado. Se puede extender a sectores a gran escala como confección, salud, energía, etc.

De igual manera, es probable que aparezcan más modelos de servicio en varias industrias. Como podemos ver en la figura 1, en el año 2020 la tendencia de inversión de las industrias apunta a diferentes formas de innovación.

¿Estamos preparados para estos cambios drásticos en los hábitos de consumo?

En realidad, el panorama no se ve bien para organizaciones con estructuras funcionales, burocráticas, jerárquicas y clásicas.

Una estructura piramidal (Fig. 2) perjudica tanto la velocidad y creatividad debido a la cantidad de niveles y procedimientos. Algunas de las razones:

A diferencia de una organización Ágil, la estructura tradicional hace que la creación de valor se vuelva dependiente, desencadenando una tensión constante entre niveles superiores e inferiores.

Diferencias entre Organizaciones Tradicionales y Ágiles

Una organización Ágil

Significa evolucionar constantemente hacia una estructura de red flexible que cumpla las expectativas del cliente.

Minimizar jerarquía y burocracia.
Creando equipos de trabajo con múltiples competencias ( ventas, marketing, desarrollo de software, etc.) enfocados en un mismo objetivo.
Crear una organización viva y flexible, capaz de responder rápidamente a los cambios del mercado y a las expectativas del cliente.

¿Vale la pena evolucionar hacia una organización Ágil?

Alcanzar la agilidad empresarial no es fácil, lo más importante es empezar a cambiar la cultura y la forma de trabajar.La solución no está en una receta lista, en un framework o metodología que se pueda implementar, sino que deben ser cambios orgánicos, adaptados a la realidad de cada empresa, lo cuál conlleva tiempo y un cambio de mentalidad a nivel organizacional, de equipos y personal. Este cambio tomará tiempo, sin embargo la recompensa se ve reflejada en un futuro inmediato.

El mundo digital favorecerá a las organizaciones que adopten el cambio rápido, brindándoles una ventaja competitiva. Por lo tanto, podemos decir que esta era estará determinada por empresas Ágiles, con un equipo y un negocio listo para responder a nuevos esquemas y mantener una ventaja competitiva en un mercado cada vez más complejo.

Lecturas recomendadas

https://publications.iadb.org/en/industria-40-fabricando-el-futuro
https://www2.deloitte.com/us/en/insights/focus/industry-4-0/industry-4-0-business-models.html
https://www.scrum.org/resources/blog/business-agility
https://www2.deloitte.com/us/en/insights/deloitte-review/issue-22/industry-4-0-technology-manufacturing-revolution.html

The post Agilidad empresarial: Abrazar el cambio o morir en el intento appeared first on Software Evolutivo.

Live – Share, colaboración del equipo en tiempo real

Johannes Caranqui — Thu, 06 Aug 2020 16:41:35 +0000

Live Share es un plugin o extensión de Visual Studio Code que permite a su equipo colaborar rápidamente en la misma base de código sin la necesidad de sincronizar el código o configurar las mismas herramientas de desarrollo, configuraciones o entorno.

Cuando comparte una sesión de colaboración, su compañero de equipo ve el contexto del espacio de trabajo en su editor. Esto significa que su compañero de equipo puede leer el código que compartió sin tener que clonar un repositorio o instalar cualquier dependencia en la que se base su código.

Pueden usar funciones de lenguaje enriquecido para navegar dentro del código; no solo abre otros archivos como texto, sino que usa la navegación basada en análisis semántico como Ir a definición o Peek.

Es necesario previamente contar con el editor de texto Visual Studio Code:

https://code.visualstudio.com/download

Paso 1:

Descargar la extensión

El primer paso es instalarlo como una extensión, en la pestaña extensiones, buscar “Live Share”, clic en instalar y volver a cargar Visual Studio Code cuando finalice la instalación.

Paso 2:

Compartir y unirse a una sesión

Una vez que haya iniciado sesión, estará listo para crear una sesión para compartir con otros. Asegúrese de compartir solo sesiones en vivo con personas de su confianza. Como verá, otorgará a los usuarios cierto acceso que puede ser perjudicial si se usa incorrectamente.

Comience haciendo clic en su nombre de usuario en la barra de estado inferior y elija Iniciar sesión de colaboración entre las opciones disponibles. Alternativamente, puede abrir la Paleta de comandos y escribir “Start Collaboration Session”

Se le notificará que su enlace de invitación se ha copiado en el portapapeles.

Comparta este enlace con alguien para invitarlo a su sesión.

Desde el punto de vista del invitado, para aceptar una invitación, haga clic en su nombre de usuario en la barra de estado inferior y elija unirse a la sesión de colaboración.

Alternativamente, como arriba, puede abrir la Paleta de comandos y escribir “Join Collaborative Session”.

Cuando se le solicite, ingrese el enlace de sesión de colaboración que le envió el anfitrión .

El anfitrión será notificado cuando alguien se una a la sesión.

Por defecto, unirse a una sesión automáticamente hará que el invitado siga al anfitrión mientras navega por el código. Esto sucederá hasta que el invitado haga un movimiento por sí mismo.

A partir de ahí, ambos lados son libres de navegar y editar como mejor les parezca. Además, ambos lados verán un marcador que muestra dónde está el otro editor como se muestra aquí.

También puede seleccionar un fragmento de código para que se resalte en la computadora del otro usuario. Puede usar esto para llamar su atención a una sección de código, por ejemplo.

Paso 3:

Compartir un servidor

Puede ser un desafío compartir con otros cuando se trabaja en una aplicación localmente. Puede verificar el código en GitHub y hacer que la otra persona clone, pero aún así tienen que instalar dependencias e iniciar el servidor ellos mismos. Con Live Share se puede iniciar el servidor localmente y la otra persona puede obtener acceso a la misma aplicación en ejecución.

Como anfitrión , inicie su servidor normalmente. Luego, haga clic en el nombre de usuario en la barra de estado inferior y elija Compartir servidor . Alternativamente, abra la Paleta de comandos y escriba “Share Server”.

Como invitado , puede navegar hasta localhost el puerto adecuado para ver el servidor.

Paso 5:

Compartir una terminal

Puede haber un escenario en el que le gustaría enseñarle a alguien comandos en la terminal, como cómo navegar por el sistema de archivos, trabajar con npm, iniciar su servidor de desarrollo, etc. Al igual que con las características anteriores, esto puede ser complicado de hacer de forma remota. Live Share también incluye una función para compartir terminales para resolver este problema.

Compartir un terminal es similar a compartir su servidor. Similar a las otras funciones, seleccione la opción “Shared Terminal”. Después de eso, elija entre read only o read/write para colaboradores.

Una vez que se haya compartido el terminal, los colaboradores podrán ver (y editar, si corresponde) la terminal.

The post Live – Share, colaboración del equipo en tiempo real appeared first on Software Evolutivo.

Código Limpio: Manual del Arte de Desarrollo Ágil de Software

Fernando Paz — Tue, 14 Jul 2020 21:46:57 +0000

Código Limpio – ¿Le mostrarías el código de programación a tu mamá?

Le puede resultar difícil de entender por la semántica del lenguaje de programación y los conceptos de negocio, pero más allá de estos aspectos, escribir Software es un arte creativo en donde narras la solución de un problema. ¿Estás de acuerdo?

Que tal esto:

var a = (m, t) => {

return m*(i/100) }

A esto:

var impuesto = calcular_impuesto(monto, tasa);

function calcular_impuesto(monto, tasa) {

var tasa_en_decimal = tasa / 100;

var valor_impuesto = monto * tasa_en_decimal;

return valor_impuesto;

}

Esta narración permite contar la solución de forma clara a tus colegas (o a ti mismo en un futuro) pudiendo centrar sus esfuerzos en aportar más a ese producto de Software y le compromete dejar el lugar tan limpio como lo encontraron… ¿Todos cuidan un Ferrari verdad?

Hay mil cuestiones más atrás de crear un código limpio, pero la primera en mi concepción es tu profesionalismo y después algunas más importantes que contaremos en otros post:

mantenibilidad
escalamiento
evolución
deuda técnica
costo

El arte del Software se desarrolla a través de la práctica y la experiencia… pero muchas actividades son útiles para acelerarla en los equipos como el Pair Programming, TDD y CI, de lo cual esperamos hablar en otros posts.

Hoy compartimos la primera parte de una serie de Cheat Sheets acerca del libro, MUST READ, para todos los desarrolladores de Software llamado Clean Code: A Handbook of Agile Software Craftsmanship del autor Robert C. Martin.

The post Código Limpio: Manual del Arte de Desarrollo Ágil de Software appeared first on Software Evolutivo.