Desarrollo de Software Archives - Software Evolutivo

GitHub Flow, una forma ligera y eficaz para gestionar tu Software

Fernando Paz — Wed, 24 Jul 2024 20:38:09 +0000

En el mundo del desarrollo de software y la gestión de productos digitales, mantener un flujo de trabajo eficiente y colaborativo es crucial. Se presenta aquí a GitHub Flow, una forma ligera y eficaz para gestionar tu Software. Exploraremos qué es GitHub Flow, cómo funciona, y por qué podría ser la estrategia perfecta para tu equipo de TI.

¿Qué es GitHub Flow?

GitHub Flow es un modelo de flujo de trabajo ligero y basado en ramas que facilita la experimentación y colaboración en equipos de desarrollo. Diseñado para ser simple y efectivo, este flujo se centra en la integración continua (CI) y la entrega frecuente de código.

El proceso de GitHub Flow

El siguiente diagrama muestra cómo el workflow propuesto de GitHub Flow para la gestión de los fuentes:

Crear una rama: Todo comienza con la creación de una nueva rama desde ‘main’ (la rama por defecto), para trabajar en una nueva característica o corrección.
Realizar cambios: En esta nueva rama, haces commits con tus cambios, iterando sobre tu trabajo.
Abrir un Pull Request: Cuando estés listo para el feedback, abre un Pull Request (o un Merge Request si estás en GitLab). Esto inicia la conversación sobre tus cambios.
Discusión y revisión: Tus colaboradores revisan el código, sugieren mejoras y discuten los cambios propuestos.
Implementar cambios: Basado en el feedback, puedes seguir haciendo commits en tu rama para mejorar tu propuesta.
Fusionar en main: Una vez que los cambios son aprobados, se fusionan en la rama principal (main).
Desplegar: Con los cambios en main, puedes desplegar inmediatamente.

La rama defecto es main, lo que significa que es la rama fuente para ambientes de producción y no tenemos ramas por versiones, tan solo las identificamos por tags, por ejemplo.

Casos de uso sugeridos

Desarrollo de nuevas características: Ideal para trabajar en nuevas funcionalidades sin afectar el código en producción.
Corrección de errores: Permite aislar y resolver problemas rápidamente.
Experimentación: Perfecto para probar nuevas ideas sin comprometer la estabilidad del proyecto.
Revisión de código: Facilita la revisión y discusión de cambios antes de integrarlos.
Releases continuas: Permite una entrega más frecuente y controlada de nuevas versiones.

Beneficios de adoptar GitHub Flow

Se presentan los siguientes como los principales beneficios:

Simplicidad: Un flujo fácil de entender y seguir para todos los miembros del equipo.
Flexibilidad: Se adapta a diferentes tamaños de equipos y tipos de proyectos.
Rápida iteración: Permite ciclos de desarrollo más cortos y ágiles.
Mejor colaboración: Fomenta la discusión y revisión de código entre el equipo.
Calidad mejorada: La revisión constante ayuda a mantener un alto estándar de código.
Despliegue continuo (CD): Facilita la implementación de prácticas de CI/CD.
Transparencia: Todos pueden ver y contribuir al progreso del proyecto.

Consideraciones y desafíos

Aunque GitHub Flow ofrece numerosos beneficios, es importante considerar también sus limitaciones:

Dificultad con versiones múltiples: GitHub Flow está diseñado principalmente para mantener una versión principal del software. Si tu producto requiere mantener y dar soporte a múltiples versiones simultáneamente (por ejemplo, para diferentes clientes o plataformas), este flujo puede resultar complicado de gestionar.
Complejidad en proyectos grandes: En proyectos muy extensos o con un gran número de colaboradores, el flujo puede volverse caótico si no se gestiona cuidadosamente. La cantidad de ramas y pull requests puede ser abrumadora sin una organización adecuada.
Dependencia de CI/CD: GitHub Flow funciona mejor cuando se implementa junto con prácticas robustas de Integración Continua y Despliegue Continuo (CI/CD). Establecer y mantener esta infraestructura puede ser un desafío para equipos más pequeños o con recursos limitados.

Conclusiones

GitHub Flow ofrece un enfoque ágil y efectivo para la gestión de versiones en productos digitales.
Su simplicidad lo hace accesible, mientras que su potencia lo hace escalable para proyectos de cualquier tamaño.
Al adoptar GitHub Flow, los equipos de TI pueden mejorar su colaboración, aumentar la calidad del código y acelerar el ciclo de desarrollo, llevando sus productos digitales al siguiente nivel.
Por supuesto hay otras propuestas para la gestión del versionamiento , como GitFlow o GitLab Flow, que pueden aplicar en escenarios donde necesitamos más control o tenemos que dar mantenimiento a versiones específicas.

The post GitHub Flow, una forma ligera y eficaz para gestionar tu Software appeared first on 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.

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.

¿Qué opciones tiene mi empresa ante los cambios tecnológicos y del mercado?

Gissella Trujillo — Wed, 11 Jan 2023 16:25:55 +0000

El éxito de las empresas es directamente proporcional a su habilidad de adoptar modelos comerciales basados en software, como parte de su estrategia y su interacción con el cliente.Fig.1

En diferentes industrias, las empresas posicionadas se ven amenazadas por empresas basadas en software; por lo que se ven forzadas a adaptarse a nuevos esquemas comerciales.

¿Qué pueden hacer las empresas para hacer frente a la realidad cambiante del mercado actual?

Integrar la tecnología en todas las áreas de la empresa, cambiando la manera en que opera y entrega valor a los clientes, esto implica:

Cambios culturales.
Procesos Ágiles.
Arquitectura de la siguiente generación.

El proceso de transformación para cada empresa es diferente, por lo que depende de sus necesidades específicas. Por ejemplo:

¿Cómo responder ante la amenaza de un nuevo competidor?

Ante la amenaza de un nuevo competidor disruptivo, con un nuevo software avanzado, la mejor opción para una empresa consolidada es lograr primero que sus operaciones actuales sean más eficientes.

La Estrategia de respuesta ante un mercado cambiante y nuevos competidores, abarca más que solo tecnología, implica preparar a sus personas y procesos; para las empresas consolidadas, un socio con experiencia en adopción de nuevas tecnologías puede agregar valor y ayudar en su proceso de mejora continua.

¿Por qué es fundamental contar con una estrategia tecnológica?

Históricamente, las empresas han cambiado constantemente, a la par de los hábitos de consumo, y con el avance de la tecnología, este proceso de mejora continua no se ha detenido desde el inicio del comercio, la diferencia con nuestra realidad actual es la velocidad con la que las cosas cambian y la tecnología avanza.

Este proceso de mejora continua, que no se detiene y acelera cada día es la razón principal para cuestionar nuestra estrategia tecnológica o la carencia de ella. Otras razones importantes incluyen:

Adopción y uso de la tecnología en todas las industrias: las empresas deben cambiar para adaptarse a los avances tecnológicos y su uso que aumenta rápidamente.
Competidores que son más veloces y eficientes con sus recursos, entienden mejor a sus clientes y dan un valor diferenciado: Las empresas deben actualizarse y realizar cambios iterativos y continuos para seguir siendo competitivas.
El comportamiento, las demandas y las expectativas cada vez más altas de los clientes: Las empresas que no logran aprovechar las tecnologías digitales corren el riesgo de perder cuota del mercado.
Rápida innovación e invención: La transformación digital está cambiando la manera en que usamos la tecnología y creando nuevos competidores y nuevos modelos empresariales en todas las industrias.

¿Qué pueden hacer las empresas ante el cambio constante?

Como se ha mencionado anteriormente, el proceso de adopción de nuevas tecnologías es diferente para cada empresa, dependiendo en la etapa que se encuentre, se pueden diferenciar 3 grandes enfoques para arrancar la estrategia y poner en marcha el camino de transformación:

Surgir: Adoptar una tecnología nueva para la transformación.
Transformar: Agilizar la transformación para convertirse en líder.
Liderar: Innovar constantemente para seguir siendo un líder.

Podemos concluir entonces que para cubrir las necesidades del mercado cambiante, haciendo frente a las tecnologías disruptivas de la competencia y a las cada vez más altas expectativas de los clientes en un mundo interconectado, es importante colocar en el mercado nuevos productos y servicios antes que nuestra competencia lo haga y eso implica que la organización pueda responder más rápido y que las áreas internas como TI tengan la capacidad de apoyar a las áreas de negocio con las nuevas iniciativas.con escalabilidad y disponibilidad, lo cual implica crecimiento.

Anteriormente, un sistema central Mainframe gestiona todas las cargas de trabajo asociadas con las aplicaciones y cuando la carga de trabajo aumentaba, la solución habitual era escalar verticalmente con más servidores (hardware). Sin embargo, por ser más demandantes, las cargas de trabajo en la actualidad se escalan horizontalmente.

¿Qué es la escalabilidad horizontal?

La escalabilidad es la capacidad del software para adaptarse a las necesidades de rendimiento a medida que el número de usuarios crece, las transacciones aumentan y por ende la base de datos y otros componentes de las aplicaciones empiezan a sufrir degradamiento del rendimiento por las cargas crecientes.

Cloud Computing habilita el escalamiento horizontal de los servicios TI. En lugar de adquirir y mantener hardware y software de manera local, los usuarios pueden acceder a aplicaciones y recursos informáticos a través de Internet.

El Cloud Computing, sin embargo, no es algo nuevo.

La mayoría de las empresas utilizan al menos un servicio comercial proporcionado a través de Internet. En total, las empresas gastaron casi $230 mil millones a nivel mundial en 2019 en servicios de la nube, según Gartner, una firma de investigación, y podrían gastar hasta $355 mil millones en 2023.

Existen tres proveedores líderes del mercado: Amazon Web Services (AWS), Microsoft Azure y Google Cloud Platform (GCP).

¿Por qué las empresas buscan la nube?

Para competir en el mercado con una estrategia tecnológica se requiere:

Entregas de aplicaciones a mayor velocidad
Reducción de costos
Escalabilidad adaptable

¿Qué es software nativo en la nube?

El desarrollo nativo de la nube (Cloud Native Development) es un enfoque para el desarrollo de aplicaciones en la nube que se centra en aprovechar al máximo las características y capacidades de la nube.

En lugar de intentar adaptar aplicaciones existentes a la nube, el desarrollo nativo de la nube implica diseñar aplicaciones desde cero para ejecutarse en la nube.

Beneficios del desarrollo de software nativo en la nube

El software nativo en la nube permite crear, desplegar y administrar aplicaciones modernas en entornos de computación en la nube. Las empresas modernas buscan crear aplicaciones altamente escalables, flexibles y resistentes que se puedan actualizar de manera rápida para satisfacer las necesidades de los clientes, utilizando herramientas y técnicas que promueven el desarrollo de aplicaciones en la infraestructura en la nube.

Estas tecnologías nativas en la nube permiten hacer cambios frecuentes y rápidos en las aplicaciones sin interrumpir el servicio, lo que proporciona a los usuarios una ventaja competitiva y de innovación.

Entre los principales beneficios tenemos:

– Más desarrollo de aplicaciones.
– Mayor velocidad de entrega.
– Más flexibilidad de implementación.
– Mayor calidad en el software.
– Menores riesgos de implementación.
– Acceso desde cualquier lugar
– Escalabilidad

Conclusiones

Para competir en la realidad actual, las empresas necesitan responder con un nuevo enfoque que brinda mayor velocidad y eficiencia a su modelo operativo.

El camino hacia una transformación guiada por una estrategia tecnológica, entonces, no es el mismo para cada empresa, pero ante la versatilidad de las nuevas tecnologías disruptivas que ganan su cuota mercado, la primera opción para empresas consolidadas es modernizar sus aplicaciones para obtener un nuevo valor de las inversiones en TI existentes.

Una solución de desarrollo de software nativo en la nube permitirá ir más allá, permitiendo sacar partido de una variedad de herramientas, frameworks, arquitecturas, etc, para:

Aprovechar al máximo los recursos con tecnologías innovadoras como Contenedores y Microservicios
Mejorar sus operaciones habilitando prácticas pensadas para la realidad del mercado cambiante (Agile, DevOps, CI/CD)

Estos términos que no se mencionan previamente en el blog (Contenedores, Microservicios, DevOps, CI/CD), se estarán abordando más adelante. Este es el primero de una serie de blogs sobre estrategia tecnológica, lo invitamos a leer la siguiente entrega para profundizar en el Desarrollo nativo en la nube. Si le gustaría saber más sobre un tema en particular o tiene una pregunta, lo atenderemos en la sección de comentarios.

Enlaces:

https://www.redhat.com/es/engage/devops-forrester-openinnovation-s-201902250310

https://www.gartner.com/en/doc/8-steps-playbook-to-optimize-software-and-saas-negotiations-2022

https://aws.amazon.com/es/what-is/cloud-native/#:~:text=El%20desarrollo%20nativo%20en%20la,para%20crear%20aplicaciones%20escalables%20r%C3%A1pidamente.

https://www.stormforge.io/wp-content/uploads/2020/11/451_cloud-container-kubernetes-economics-wp.pdf

https://www.economist.com/business/2020/03/14/how-corporate-it-is-entering-the-multi-cloud

The post ¿Qué opciones tiene mi empresa ante los cambios tecnológicos y del mercado? 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.

UX: Experiencia de Usuario una Prioridad en el Desarrollo de Sistemas Organizacionales

Bryan Diaz — Thu, 27 Oct 2022 21:07:21 +0000

Actualmente, la compra o alquiler de sistemas dentro de las organizaciones a través de plataformas virtuales presenta un mayor índice de demanda, de modo que, gracias a la pandemia del COVID-19, los usuarios son más flexibles en sus acciones o tareas a la hora de buscar productos o servicios que deseen adquirir. Razón por la cual, para efectuar una buena negociación y una venta exitosa, se necesita brindarle a sus compradores una herramienta innovadora y una experiencia de usuario rápida, instantánea, y simple para cualquier tipo de dispositivo.

Si bien es cierto, al momento de desarrollar un sistema, tenemos en cuenta todos los lineamientos necesarios para que éste cumpla con los requerimientos del cliente; no obstante, nos hacemos preguntas como: ¿Qué tan difícil será su manejo?, ¿Será agradable para los usuarios? o ¿Estará clara la información plasmada o presentada?, en fin… un sinnúmero de preguntas que en la mayoría de los casos no consideramos de gran importancia al momento de desarrollar nuestro producto.

Es por ello que, a partir de esta iniciativa resulta de vital importancia considerar al UX como punto de partida indispensable en el desarrollo de un producto, de manera que, dicho término aparte de que se usa muy a menudo en el mundo tecnológico; es una prioridad en el desarrollo de sistemas, ya que gracias a ello los diseñadores ahora son más consciente de cómo su trabajo impacta al usuario y cuales son sus necesidades.Hay que destacar que, el trabajo del diseño de UX se centra en encontrar un equilibrio entre las necesidades del usuario, las necesidades comerciales y las capacidades técnicas, de manera que hallar el balance perfecto crea una experiencia de usuario beneficiosa y le permite al negocio alcanzar sus objetivos.

¿Qué es UX o Experiencia de Usuario?

Nielsen Norman Group, empresa estadounidense de consultoría en interfaz de usuario (UI) y experiencia de usuario define a UX como una de las experiencias de usuario más completas que coexisten a nivel global, puesto que que incluye todos los aspectos de la interacción del usuario final con la empresa, con sus servicios y con sus productos. Por ello, su término se menciona con mayor frecuencia en áreas relacionadas con tecnología, tales como teléfonos inteligentes, computadoras, software o sitios web. Se debe tener presente que, la experiencia del usuario no es solo un campo bastante nuevo, sino también un área volátil, ya que, cambia rápidamente debido a los avances tecnológicos, los nuevos tipos de interacción y las preferencias del usuario.

Dicho de otra manera, el UX no es nada más que la experiencia innovadora que obtiene un usuario en los distintos escenarios al momento de utilizar un producto, de manera que, dicha acción les brinda una respuesta/solución a sus preguntas o problemas. Según Yudica (2016), esto suscita porque los diseñadores se encargan de proporcionarle al internauta una variabilidad de soluciones frente a los diversos aspectos comunicativos que puede presentar el mismo con un determinado producto o servicio (incluida la usabilidad, accesibilidad, y capacidad de encontrar/aprender/recordar); por ende, su principal función no es otra cosa que hacer que el producto sea amigable, satisfactorio, accesible y útil para el usuario.

Prototipos UX

Ayudan a capturar visualmente los objetivos comerciales y alinearlos con las expectativas o necesidades de los usuarios, para así, tener conocimiento del grado de satisfacción que exhiben los mismo con el producto creado. Hay que tener en cuenta que el coste de modificar un prototipo es inferior al coste de cambiar un producto digital subido a producción, por lo que supone una ventaja de ahorro de costes durante el desarrollo.

El diseño de UX no solo prioriza las necesidades del usuario, sino también las capacidades metodológicas y ausencias de un negocio, ya que no todos los individuos poseen las mismas competencias técnicas para brindar una solución ideal a cada problemática; ni todas las empresas poseen el suficiente recurso monetario para invertir constantemente en los formación técnica/profesional de todos sus colaboradores.

Por este motivo, el trabajo del diseño de UX se centra en encontrar un equilibrio entre las necesidades del usuario, las necesidades comerciales y las capacidades técnicas, de manera que hallar el balance perfecto crea una experiencia de usuario beneficiosa (satisface sus necesidades) y le permite al negocio alcanzar sus objetivos, siempre y cuando esta se encuentre dentro de las capacidades técnicas de la empresa.

Se debe tener en cuenta que el diseño UX, es un proceso que inicia con la comprensión de los usuarios, luego con el diseño de interfaces, y, finalmente con la prueba para ver si el mismo logra satisfacer las necesidades de los usuarios; de modo que aquello representa una parte integral del proceso de desarrollo del producto.

A su vez, para crear un diseño fácil de usar, los diseñadores de UX deben participar en el proceso de principio a fin. Por ende, es conveniente realizar investigaciones sobre cómo los usuarios buscan un producto, navegan por las páginas, buscan detalle de los productos, e interactúan con el sistema; ya que tras la investigación y el análisis exhaustivo de los datos y registros obtenidos, deberemos de ser capaces de generar diseños y experiencias que satisfagan las necesidades de los usuarios.

Para ofrecer buenos resultados en el proceso de desarrollo de un producto se debe considerar lo siguiente:

Relación Esfuerzo – Beneficio en UX

Cuando diseñamos tomando en consideración los principios de usabilidad, lo que buscamos es reducir al mínimo las barreras de interacción, y por lo tanto el esfuerzo del usuario para completar tareas interactivas, ya que, el principal objetivo es evitar la frustración del usuario. En la mayoría de los casos el producto ideal es el que se adapta al usuario; no obstante, en ocasiones es imprescindible que sea el usuario quien se adapte al producto, de manera que se pretende reducir el tiempo de dedicación y esfuerzo para aprender cómo usarlo. Debido a aquello, es posible analizar la experiencia de usuario únicamente en términos de facilidad de uso sin tener en consideración cuál es el beneficio o valor de uso, puesto que, la calidad e idoneidad de un diseño viene determinada por la relación esfuerzo-beneficio y es sólo cuando el beneficio o valor percibido supere el esfuerzo requerido, podremos hablar de experiencias de usuario satisfactorias.

UX es igual a resolver problemas

Es importante pensar en el usuario en cada parte del proceso de realización de un producto, ya que, ponernos en el lugar del usuario al momento de utilizar dicho producto para conocer la forma en la que va a interactuar con el mismo, mejora de una manera temprana los posibles problemas que se puedan generar en el usuario con el producto terminado.Y es ahí, donde parte la importancia para UX, de llevar un proceso e involucrar al usuario en cada etapa del procedimiento, y no simplemente tener la idea de pensar en el usuario.

Diseño de experiencia no solamente se basa en satisfacer al usuario sino también a cumplir con los objetivos del negocio, el diseñador de experiencia hace de puente entre el usuario y el cliente que nos contrata.

Conclusión

UX resulta ser de gran prioridad para las organizaciones, ya que se obtiene sistemas amigables-fáciles de usar, garantiza la fluidez-eficiencia en el diseño, y exhibe una gran demanda dentro del mercado laboral, ya que actualmente los clientes buscan constantemente satisfacer sus necesidades y solucionar sus problemas de forma breve y simple. Por ello, se caracteriza por ser una experiencia innovadora que obtiene un usuario en los distintos escenarios al momento de utilizar un sistema, de manera que, dicha acción les brinda una respuesta/solución a sus preguntas o problemas. Cabe recalcar que, aquello suscita porque los diseñadores se encargan de proporcionarle al internauta una variabilidad de soluciones frente a los diversos aspectos comunicativos que puede presentar el mismo con un determinado producto o servicio (incluida la usabilidad, accesibilidad, y capacidad de encontrar/aprender/recordar); por ende, su principal función no es otra cosa que hacer que el producto sea amigable, satisfactorio, accesible y útil para el usuario

Por su parte, la implementación del UX se enfoca en las acciones que realiza el usuario delante de la pantalla, de manera que al tener en cuenta su uso, nivel de afectación y grado de aceptación; no solo genera beneficios para los usuarios, sino que también para las empresas u organizaciones, puesto que, el examinar los diferentes escenarios a los que puede estar expuesto el usuario y el brindar solución cada uno de ellos, les genera buena reputación en el mercado laboral. Teniendo presente que el diseño de experiencia no solamente se basa en satisfacer al usuario sino también a cumplir con los objetivos del negocio.

Referencia

The post UX: Experiencia de Usuario una Prioridad en el Desarrollo de Sistemas Organizacionales appeared first on Software Evolutivo.

JBoss EAP: Configuración de la memoria

Jorge Aguilar — Thu, 13 Oct 2022 20:41:50 +0000

Una de las tareas de afinamiento más comunes luego de comenzar a operar un servidor de aplicaciones Java suele ser el ajuste de la memoria que utiliza el Java Virtual Machine (JVM). Por defecto, cierta cantidad de memoria es asignada al momento de iniciar el JVM, esta memoria es utilizada para alojar los objetos creados por las aplicaciones y para mantener otra información creada durante la ejecución de las mismas. El valor inicial suele ser suficiente para iniciar a operar pero ciertas aplicaciones necesitarán una mayor cantidad de recursos ya sea de entrada o con el tiempo para cubrir una mayor demanda por parte de los usuarios.

Si la cantidad de memoria asignada es insuficiente para la demanda inicial de las aplicaciones o para soportar la carga que reciban éstas, entonces eventualmente se podría experimentar lentitud o la cancelación de las peticiones, llegando a la temida excepción de Java: java.lang.OutOfMemoryError, que se presenta cuando el JVM es incapaz de crear un objeto en memoria y en este punto será necesario reiniciar el servidor, con la correspondiente afectación a los usuarios conectado o nuevos que estén por llegar.

En esta entrada se va a considerar los pasos a seguir para modificar la cantidad de memoria que es asignada al JVM del servidor de aplicaciones JBoss Enterprise Application Platform (EAP) en su versión 7 en modo Standalone y utilizando Java 11, aunque para Java 8 los pasos son similares.

El punto de partida será que contamos con servidor JBoss EAP instalado y aplicada su configuración básica. Para llegar a este punto se puede tomar como referencia la entrega inicial de esta serie de artículos: JBoss EAP: Instalación y configuración básica

Algunos conceptos básicos

Tipos de memoria

En Java 11 existen dos tipos principales de memoria del JVM:

Heap

Corresponde al espacio donde se alojarán los objetos y arreglos que son utilizados por las aplicaciones. El tamaño del Heap varía mientras se ejecutan las aplicaciones.

Existen dos parámetros que podemos utilizar para modificar el espacio utilizado por el Heap, éstos son:

-Xms: Valor inicial

-Xmx: Valor máximo que podría tomar
Non-heap

El espacio más relevante dentro de lo que no sea Heap se lo conoce como Metaspace y es donde se almacena la metadata, estructura de las clases, constantes, valores de los String, entre otros.

Desde la versión 8 de Java encontramos los siguientes parámetros para lo que se conoce como Metaspace:

-XX:MetaspaceSize: Valor inicial para almacenar los elementos del Non-heap

-XX:MaxMetaspaceSize: Valor máximo que podría tomar el espacio de Non-heap

Nota: Antes de Java 8, se lo conoce como Permanent Gen y los parámetros eran -XX:PermSize y -XX:MaxPermSize, equivalentes a los antes mencionados.

Gestión de la memoria

Es bien conocido que como desarrolladores no tenemos que liberar de manera explícita la memoria que ya no estemos utilizando, a diferencia de otros lenguajes de programación como C++. Y ésto es debido a que Java dispone del Garbage Collector, un componente del JVM que es el encargado de monitorear y liberar el espacio de memoria que ya no está en uso.

Procedimiento de ajuste de la memoria

Heap

Cuando encontremos la excepción java.lang.OutOfMemoryError en el archivo de log ($EAP_HOME/standalone/server.log) de JBoss EAP podremos tener la certeza de que se va a requerir un incremento en la memoria Heap.

Para el modo Standalone de JBoss EAP simplemente se deberá cambiar el archivo standalone.conf, el cuál está ubicado en el directorio $EAP_HOME/bin/

Según el archivo del ejemplo, se puede ver que en línea 53 están los valores correspondientes para -Xms y -Xmx, en este caso ambos establecidos en 1303 MB.

NOTA: Para ambientes productivos se recomienda establecer -Xms y -Xmx con el mismo valor, así no se tiene que gestionar el incremento hasta el valor máximo sino que ya está establecido de antemano.

Metaspace

Usualmente no existe la necesidad de especificar un tamaño máximo para Metaspace a menos que se esté presentando una pérdida de memoria (memory leak), que resulta de la falta de liberación de la misma una vez que ya no se la necesita, afectando al rendimiento del servidor.

Conclusiones

Dentro de los ajustes que podemos hacer a un servidor de aplicaciones, como JBoss EAP, el espacio Heap es el principal ya que es el más dependiente de la dinámica de nuestras aplicaciones y de la exigencia que reciba por parte de sus clientes.

La modificación del tamaño del espacio Heap es una tarea sencilla pero requiere el reinicio del servidor de aplicaciones, y como pudimos evidenciar son instrucciones que recibe el JVM al momento de iniciar el mismo. Estos parámetros son los mismo que aplican para cualquier servidor de aplicaciones que se ejecute sobre la máquina virtual de Java (JVM).

Otras modificaciones, como el cambio del Metaspace no son tan habituales, sin embargo podría ser necesarias cuando las aplicaciones mantienen un número extenso de clases o gestionan muchos valores del tipo String.

Te hacemos una cordial invitación ya que en próximas entradas del blog habrá más contenido sobre esta temática. Hasta pronto.

The post JBoss EAP: Configuración de la memoria appeared first on Software Evolutivo.

¿La Agilidad puede ayudar a mi organización?

Gissella Trujillo — Thu, 04 Aug 2022 19:29:07 +0000

El desafío de cambiar la cultura y la forma de pensar a nivel de individuos y equipos es bien conocido para quienes ya conocen de Agilidad y para las empresas que están en este camino.

Muchas veces los esfuerzos y decisiones para lograr un cambio se ven poco claras o insatisfactorias, como en una conversación acerca del clima; todos parecemos tener algo que decir al respecto pero nadie puede cambiarlo.

A continuación se presenta un ejercicio que nos ayudará a enfocarnos en las cosas que sí podemos mejorar. Este ejercicio es parte de una clase del PROFESSIONAL AGILE LEADERSHIP ESSENTIALS™ TRAINING, creado por Kurt Bittner del equipo de Scrum.org. Para ayudar a los líderes del cambio a comprender mejor dónde encaja la agilidad y dónde puede ayudar a tu organización.

Antes de empezar, recordamos que la agilidad no tiene un único enfoque en su adopción ya que depende del contexto empresarial. Por lo tanto cada esfuerzo realizado por la organización en este sentido es susceptible de ajustes de acuerdo a su realidad.

Modelo de la afinidad Ágil

Por agilidad, hablamos del enfoque empírico para entregar valor al negocio de manera incremental, medir el efecto de esa entrega, inspeccionar los resultados y adaptarse basado en el aprendizaje de esta inspección.

Este modelo de Afinidad Ágil considera 5 dimensiones ( Figura 1 ) que influyen en la atracción o resistencia al empirismo dentro de la organización.

Figura 1. Modelo de la afinidad Ágil

Estas 5 dimensiones expresan diferentes fuerzas internas y externas que afectan a las creencias y valores de una organización.

Dimensiones externas (Amenaza Competitiva y Potencial de Crecimiento del Mercado): Comúnmente atraen a las organizaciones hacia la agilidad.
Dimensiones internas (Voluntad de Experimentar, Incertidumbre de la Solución y Descentralización de Decisiones): Casi siempre retrasan a la organización para volverse más Ágil.

¿Por qué estas dimensiones?

Estas dimensiones capturan la esencia de los desafíos a los que se enfrentan las organizaciones y proporcionan una forma útil de conocer mejor las actividades y tener debates sobre lo que las personas podrían hacer para cambiar las creencias que frenan su Agilidad.

Cada una de estas dimensiones se describen a continuación:

Amenaza competitiva

Expresa el grado en que el producto o servicio está desafiado por la competencia.

Indicadores
Bajo	Elevado
Tenemos alta cuota de mercado	Tenemos baja cuota de mercado
Existe poca competencia	Tenemos mucha competencia
El cliente tiene alta dependencia a nuestro producto / servicio	Poca dependencia del cliente hacia nuestro producto / servicio

Voluntad de experimentar

Expresa el grado en que la organización se siente cómoda con la incertidumbre.

Indicadores
Bajo	Elevado
Incrementamos detalles del plan cuando aumenta la incertidumbre.	Formulamos hipótesis y se ejecutamos experimentos para probar suposiciones cuando aumenta la incertidumbre.
Agregamos hitos y revisiones cuando aumenta la incertidumbre.	Planificamos en pequeños incrementos, medimos, inspeccionamos y adaptamos los planes.
Consideramos como un resultado negativo cualquier desviación en el plan.	Las desviaciones de los planes se consideran como información nueva.

Incertidumbre de la solución

Es el grado en que la organización está segura de saber lo que el mercado y los clientes necesitan de nuestro producto o servicio.

Indicadores
Bajo	Elevado
Las solicitudes de cambio en nuestro producto / servicio se consideran resultados negativos	Realizamos focus group o otro tipo de investigación de forma frecuente para evaluar diferentes alternativas y necesidades del cliente
Tenemos pocos datos disponibles sobre el uso real del usuario sobre nuestro producto / servicio.	Preparamos nuestras aplicaciones para obtener información de uso real del usuario con nuestro producto / servicio
Planificamos los lanzamientos y actualizaciones siguiendo en gran medida roadmaps del producto / servicio.	Ejecutamos pruebas A / B para probar y validar alternativas o nuevas características a nuestros productos / servicios.
Basamos los releases de nuevas características en roadmaps detallados que han sido planificados con mucha anticipación.	No tenemos roadmaps de productos a largo plazo, los roadmaps del producto cambian con el tiempo.

Descentralización de decisiones

Expresa el grado en que la autoridad para la toma de decisiones está dispersa en la organización, en el que ciertas decisiones específicas pueden ser tomadas por individuos o equipos sin tener que buscar la aprobación de mandos superiores.

Indicadores
Bajo	Elevado
Todas las decisiones de gasto deben pasar por un gerente con la autoridad presupuestaria adecuada.	Permitimos que los equipos sean responsables de un presupuesto que pueden usar para ayudarlos a cumplir sus objetivos.
Todas las decisiones de contratación y despido las toman los mandos superiores.	Permitimos que los equipos se involucren, participen o tomen decisiones de contratación / despido.
Todas las decisiones de productos las toman los mandos superiores.	Permitimos tomar decisiones sobre el producto a los equipos (incluido Product Owner)

Potencial de crecimiento

Expresa el grado en que el producto tiene potencial de crecimiento en el mercado, es decir el grado en el que puede aumentar significativamente los ingresos.

Indicadores
Bajo	Elevado
El producto está en un mercado que se está contrayendo.	El producto está en un mercado en rápida expansión.
La cuota de mercado del producto se está reduciendo	Los competidores dominantes en el mercado se debilitan y pierden cuota de mercado.
El producto proporciona un ingreso o ganancia constante, ha alcanzado una gran participación de mercado.	Es posible aumentar los ingresos del producto aumentando el número absoluto de clientes o aumentando la participación de mercado.

Aplicando el modelo en tu equipo de trabajo

Objetivos:

Sacar a la superficie supuestos tácitos pero muy importantes.
Lograr que el equipo piense en el entorno en el que se va a introducir un enfoque ágil o empírico.

Antes de empezar, recuerda:

¿Cómo empezar?:

Organizar idealmente en equipos de menos de 5 personas para cada producto.
Cada equipo marca las dimensiones para el producto / equipo en el que trabaja.
Si hay personas de diferentes productos en el mismo equipo, pídeles que marquen las dimensiones de cada producto.
Dibujar las líneas entre puntuaciones. Tendrá un resultado similar a este (Figura 2) , donde cada color representa un producto diferente.

Figura 2. Resultado Modelo de Afinidad Ágil

Cada equipo revisa sus puntuaciones y explica sus porqué mientras los demás equipos solo pueden escuchar y hacer preguntas aclaratorias
Después de la presentación se ayuda a los grupos a sacar algunas conclusiones.

Interpretación de los resultados

Recuerde: No existen respuestas correctas y el valor del ejercicio es estimular la conversación sobre los desafíos que cada organización enfrenta al adoptar un enfoque Ágil.

Algunos puntos de discusión comunes

Baja amenaza de la competencia/ Potencial de crecimiento del mercado

En este caso es importante distinguir si este producto realmente se beneficia del empirismo. Sin mucha amenaza y pocas oportunidades, la organización puede enfocar esfuerzos en productos con mayor necesidad.

Ágil no es la forma de ejecutar todo y necesitamos ser reflexivos sobre ello. Debido a que la organización sólo puede respaldar cierta cantidad de cambios y forzar un cambio sin gran beneficio puede privar a otro equipo de la ayuda necesaria.

Alta amenaza de la competencia/ Potencial de crecimiento del mercado

El producto tiene oportunidades con las que el empirismo puede ayudar. Si además tenemos una calificación baja en dimensiones internas, éstas representan barreras internas que pueden impedir que funcione el empirismo.

Baja incertidumbre de la solución

Puede parecer algo bueno pero no lo es, podemos estar pensando que sabemos lo que quiere el cliente pero sin una medición sobre la experiencia del cliente ¿Cómo podemos estar seguros? El primer paso es medir la experiencia para saber que creencias son ciertas, caso contrario podríamos estar perdiendo oportunidades de brindar un mejor servicio a los clientes.

Baja disposición a experimentar

Surge de la aversión a cometer errores y de la creencia de que planificar al detalle aumenta la probabilidad de un plan totalmente seguro. Sin embargo, a menudo las suposiciones en las que se basa el plan, resultan no ser realistas.

Hacer pequeños experimentos es menos costoso y dañino que elaborar grandes planes detallados que a menudo salen mal.

e. Baja descentralización de decisión

Refleja falta de confianza entre gerentes y el equipo. Siempre que haya disposición de las partes hay muchos caminos para aumentar la confianza empezando por otorgar gradualmente a los equipos autonomía en la toma de decisiones pequeñas y seguir avanzando a cosas más grandes.

La actividad final del ejercicio, después de crear estas conversaciones valiosas, es preguntarse si como equipo están de acuerdo con su enfoque de trabajo actual, y si no lo están, ¿qué cambiarían?, para que puedan generarse acciones al respecto.

Para recordar

Las organizaciones son diferentes entre sí y dentro de ellas mismas encontramos equipos con objetivos diferentes. Por esta razón al adoptar prácticas ágiles o escalarlas, no existe un único enfoque.

Te invitamos a leer más sobre agilidad empresarial y agilidad desde el punto de vista del negocio en nuestro blog.

Fuentes:

https://www.scrum.org/pathway/product-owner-learning-path

https://www.scrum.org/resources/blog/whats-driving-your-need-agility

https://kenschwaber.wordpress.com/2011/05/03/empiricism-the-act-of-making-decisions-based-on-what-is/

https://www.scrum.org/resources/blog/business-agility

The post ¿La Agilidad puede ayudar a mi organización? appeared first on Software Evolutivo.

Arquitectura de Microservicios: qué es, ventajas y desventajas

Fernando Paz — Thu, 21 Jul 2022 19:57:23 +0000

Existen dos grandes paradigmas a la hora de diseñar Software: la Arquitectura Monolítica y la Arquitectura de Microservicios. En este artículo vamos a revisar qué es la Arquitectura de Microservicios, y cuáles son sus ventajas y desventajas.

Qué es la Arquitectura de Microservicios
Características de los Microservicios
Ventajas de la Arquitectura de Microservicios
Desventajas de la Arquitectura de Microservicios

Qué es la Arquitectura de Microservicios

Antes de hablar de la Arquitectura de Microservicios, vamos a partir identificando a su predecesor que es la Arquitectura Monolítica.

La Arquitectura Monolítica, es un enfoque en donde todos los conceptos y dominios de negocio de un producto de Software se implementan como componentes completamente acoplados, por lo que, tanto las entradas como las salidas de cada componente tienen su razón y especificación en contexto de un único producto de Software que es indivisible.

Iniciando desde la interfaz del usuario (en algunos casos), pasando por una o varias capas de lógica de negocio, la capa de persistencia, y, hasta la base de datos, el producto de Software se construía como un solo concepto, y a menudo se ejecuta como un solo binario o unidad entregable (JAR, WAR, EAR, Folder, etc.).

La Arquitectura de Microservicios es un enfoque para el desarrollo de un producto de Software, en donde cada concepto específico de negocio es construido en una unidad pequeña de código accesible a través de una API liviana y bien definida.

El TODO del producto de Software entonces, constituye la ejecución sincronizada de un conjunto de estos servicios, cada uno con su propia e independiente definición, para el proceso de una transacción padre disparada desde una interfaz de usuario o sistema.

Características de los Microservicios

Aunque parece no existir una especificación única para crear Microservicios, y más depende del caso de negocio y/o planificación; generalmente se sugiere que deban cumplir las siguientes características:

Interfaz Única

Cada Microservicio debe proveer una interfaz ligera y bien definida para consumo, que aísle todos los detalles técnicos, estructura de datos y datos de la capacidad de negocio que maneja, a sus clientes.

Especializado

Cada servicio es diseñado con un conjunto limitado de capacidades que resuelvan uno y solo un problema de negocio, y que incluye su propia estructura de datos persistentes.

Autónomo

Cada servicio puede ser desarrollado, desplegado, operado y escalado sin afectar o depender de otros servicios o sistemas, o, de otros datos fuera de su especialización.

Claramente una Arquitectura de Microservicios es una aplicación del paradigma de Cómputo Distribuido, lo que representa muchas ventajas para el negocio pero también muchos retos en la operación y mantenimiento.

Ventajas de la Arquitectura de Microservicios

Agilidad Este paradigma de desarrollo permite crear equipos pequeños e independientes que se apropian de la especialización de los servicios, acelerando el tiempo de desarrollo, facilitando la auto-organización e incluso el soporte post-producción.	Escalamiento Esta división de funcionalidad hace más fácil la medición y observabilidad de la implementación, permitiendo planificar mejor la disponibilidad y escalabilidad.
Simplificación de Despliegue Una unidad pequeña de implementación, permite ciclos de CI/CD más simples, reduciendo el tiempo de despliegue de la misma y el rollback en caso de fallos. Esto agiliza las operaciones y al mismo tiempo reduce el riesgo de innovación con nuevas características.	Resiliencia A diferencia de una Arquitectura Monolítica, un fallo en una Arquitectura de Microservicios compete a un componente específico, lo que hace más fácil su recuperación y no desestabiliza el producto de Software por completo, sino la capacidad de negocio concreta que le compete.
Independencia Tecnológica El uso de una sola tecnología no es una restricción en la Arquitectura de Microservicios, dado que su interfaz de consumo abstrae los detalles de implementación y habilita a la selección de la mejor herramienta de acuerdo a la especialización del servicio.	Reutilización de Código Evidentemente una vez construido un servicio que atiende una capacidad de negocio, el mismo puede ser utilizado por otros productos de Software de forma que su construcción aproveche la funcionalidad ya implementada.

Desventajas de la Arquitectura de Microservicios

Más que desventajas, se puede hablar de retos a la hora de adoptar una Arquitectura de Microservicios, y entre los principales tenemos:

Versionamiento Un Microservicio, al ser autónomo, suele evolucionar independientemente del producto o de los productos de Software a los cuales provee funcionalidad. Esto significa que su interfaz API y la validación del esquema de datos varía continuamente, sin embargo para no afectar la estabilidad de sus clientes antiguos debe mantener un versionamiento de los mismos y obviamente mantenerlos operando. Esto tanto para áreas de operaciones y de desarrollo implica una tarea adicional en su implementación.	Pruebas Si bien un Microservicio por sí solo es más simple de probar, su orquestación con otros servicios (test de integración) y las pruebas integrales (pruebas end to end) son mucho más complejas. Esto resulta a menudo en una cobertura incompleta de escenarios de pruebas y un esfuerzo redoblado en su desarrollo.
Rollback y Sistemas Distribuidos El reto más grande, para mí, es el diseño de sistemas distribuidos, puesto que hay que definir qué sucede en caso de fallos esperados o inesperados en la orquestación de los servicios, analizar patrones de resiliencia y recuperación de transacciones, mirar la atomicidad de operaciones y consistencia de datos, entre otros. Claro está, que para esto nos podemos apoyar en conceptos como “Patrones de Integración Empresarial”, “Mallas de servicios” o similares, pero sin duda estas decisiones son extremadamente relevantes no solo para el desarrollo sino para el soporte post-producción.	Coordinación de equipos Si bien, al desarrollar un Microservicio, paradigmas como la Agilidad y un equipo responsable puede representar una gran ventaja para generar valor e innovación constante en su implementación, al tener decenas o centenas de microservicios con decenas o centenas de equipos responsables, la cooperación y comunicación de estos equipos es un reto, pues el TODO de un Sistema y su evolución se puede poner en riesgo cuando se carece de una acción combinada.
Sobrecarga de infraestructura En la Arquitectura Monolítica un operador a menudo mira un servidor y un Software correspondiente con su archivo log; en un paradigma de Arquitectura de Microservicios puede enfrentarse a escenarios donde un Software tiene 100 servicios y centenas de servidores, con uno o varios balanceadores, muchos archivos de logs y decenas de formatos. Aunque hoy existen esquemas de contenerización como Docker y Kubernetes, la administración sigue siendo un reto y se necesita varias tecnologías complementarias para enfrentarlo.	Tiempo y esfuerzo 1x A este punto del artículo ya hemos descrito muchas actividades adicionales en el diseño, implementación, operación y mantenimiento de la Arquitectura de Microservicios, por su característica de Sistema Distribuido. Por este motivo es importante sopesar el beneficio de este paradigma en contraste con el caso de negocio y los resultados esperados a corto, medio y largo plazo; del mismo modo debemos pensar en el soporte post implementación, en relación al equipo, sus capacidades.
Despliegue ¡Si!, desplegar un solo microservicio es simple, sin embargo desplegar cientos de ellos de forma manual se vuelve imposible. El orden de despliegue, los cambios de base de datos que implica, la estratégia de entrega (Blue-Green, Canary, etc.), entre otros, son cosas a planificar y deben estar automatizadas, con prácticas DevOps entre otras como Integración Continua (CI) y entrega Continua (CD).	Logs y Monitoreo De la misma manera, un producto de Software Monolítico deja un solo log de operación y se puede medir su performance centralizadamente. En una Arquitectura de Microservicios, vamos a tener tantos logs como servicios implementados para el producto de Software y además si estos son redundantes, tendremos logs multiplicados por cada servicio. Debemos planificar una estratégia para rastrear errores, identificar la salud de cada servicio y del sistema como tal.
Debug Encontrar un problema no siempre va a ser posible revisando logs (que al ser tantos ya nos agrega una complejidad), a veces vamos a tener que depurar la implementación y esto en un sistema distribuido no va a ser factible, por lo que se requerirá de otras técnicas y patrones que permitan repetir ciertas ciclos de transacciones.

Pensamientos Finales

A este punto del artículo, puede sonar complejo decidir por microservicios, y la verdad lo es; sin embargo, esta complejidad no se evidencia desde el momento cero de una implementación, sino que irá apareciendo gradualmente mientras vamos creando más microservicios y escalándolos.

Son muchas sus ventajas, y aunque hay retos, en una estratégia digital a largo plazo es sin duda el camino a adoptar, y así mismo, debe venir acompañada de un soporte directivo dado que la estructura organizacional, técnica y de costos va a tener que evolucionar también.

¿Debo usar Microservicios? La realidad es que muchos desarrollos de Software nacen con este enfoque, sin abordar en un primer momento las soluciones a estos desafíos, pero eventualmente lo harán. Les invito a ver una interesante conversación entre Martin Fowler y Sam NewMan sobre cuando usar microservicios y cuando no.

El soporte de este tipo de aplicaciones es complejo, pues detectar un fallo en una Arquitectura de Microservicios requiere de un entrenamiento en el flujo de negocio, en los puntos de integración y en la interpretación de los logs de información. En muchos casos al soporte de primera línea le faltan insumos para responder y el escalamiento de las incidencias es muy rápido al equipo técnico, resultando en una sobrecarga de operación y costo.

The post Arquitectura de Microservicios: qué es, ventajas y desventajas 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.