Continuamos explorando innovación en IA, software personalizado y trucos para optimizar procesos de desarrollo. Inspiración y conocimiento para profesionales y empresas.

Bienvenido a mi boletín donde comparto aprendizajes, reflexiones y exploraciones en el mundo tecnológico. Soy Sumonta Saha Mridul, Associate Software Engineer en Cefalo, y regularmente publico en LinkedIn, Dev.to y Medium. Además gestiono un pequeño canal de YouTube con contenido útil para desarrolladores. Ahora quiero ampliar esta visión con la experiencia de Q2BSTUDIO, una empresa dedicada al desarrollo de software a medida y soluciones tecnológicas avanzadas.

Día 6 – Garantizando el Orden de Mensajes en Azure Service Bus

En sistemas distribuidos el orden importa. Imagina un sistema bancario donde una retirada se procesa antes que el ingreso o un sistema de pedidos donde Estado Enviado aparece antes que Pedido Creado. Sin un orden correcto la lógica de negocio puede romperse y aparecerán errores difíciles de depurar.

El reto por defecto Azure Service Bus no garantiza un orden estricto entre todos los consumidores. Varios consumidores procesan mensajes en paralelo y eso puede provocar ejecuciones fuera de secuencia. ¿Cómo forzar FIFO First In First Out cuando realmente importa?

Solución Mensajes con SessionId Azure Service Bus ofrece Message Sessions para el procesamiento ordenado. Los mensajes se agrupan mediante un SessionId. Service Bus garantiza que todos los mensajes dentro de una sesión se entregan en orden y que solo un receptor procesa una sesión dada a la vez, evitando condiciones de carrera y pérdida de consistencia.

Ejemplo práctico Ecommerce Procesamiento de pedidos Todas las notificaciones relacionadas con Pedido123 Creado Empacado Enviado Entregado comparten el mismo SessionId. Con las sesiones, los eventos se consumen en la secuencia correcta y el flujo de negocio permanece coherente.

Beneficios clave - Asegura procesamiento FIFO dentro de una sesión - Mantiene juntos los mensajes relacionados - Evita lógica compleja de reordenado personalizada

Buenas prácticas - Usa SessionId para agrupar mensajes lógicamente relacionados - Para alto rendimiento distribuye la carga entre múltiples sesiones - Monitoriza sesiones de larga duración que puedan bloquear el procesamiento

En Q2BSTUDIO somos una empresa de desarrollo de software y aplicaciones a medida especializada en soluciones end to end. Ofrecemos software a medida, aplicaciones a medida, inteligencia artificial, servicios de ciberseguridad y mucho más. Podemos ayudarte a diseñar colas y sesiones eficientes en Azure e integrar esas soluciones con tus procesos de negocio y herramientas de analítica.

Tuve que resolver un reto de CSS que puede parecer sencillo pero tiene truco: hay una lista de enlaces y quiero aplicar un estilo cuando un enlace está en estado hover o focus. Si ninguno está hover o focus, quiero que el primero de la lista tenga ese estilo por defecto.

El marcado HTML básico se puede representar así como texto: <ul><li><a href=#>One</a></li><li><a href=#>Two</a></li><li><a href=#>Three</a></li><li><a href=#>Four</a></li><li><a href=#>Five</a></li><li><a href=#>Six</a></li></ul>

Estilado para hover y focus: li a:hover, li a:focus { background-color: pink; }

La parte complicada es aplicar el estilo al primer elemento solo cuando no hay ningún enlace en hover o focus. Una solución moderna de solo CSS aprovecha el pseudo selector :has junto con :not para detectar si la lista contiene un enlace en hover o focus. Por ejemplo: ul:not(:has(li a:hover)):not(:has(li a:focus)) li:first-of-type a { background-color: pink; } Esto significa que el primer enlace se pinta de rosa únicamente cuando la lista no tiene ningún enlace en hover o focus.

Ventaja de esta aproximacion es que evitamos tener que anular estilos de los hermanos cuando uno recibe hover o focus. Inconveniente: :has no esta soportado en todos los navegadores antiguos, por lo que si necesitas compatibilidad amplia puedes implementar una pequena alternativa con JavaScript que añada o quite una clase en el contenedor segun los eventos mouseenter, mouseleave, focus y blur.

Ejemplo final de codigo como texto: <!-- HTML --> <ul><li><a href=#>One</a></li><li><a href=#>Two</a></li></ul> <!-- CSS --> li a:hover, li a:focus { background-color: pink; } ul:not(:has(li a:hover)):not(:has(li a:focus)) li:first-of-type a { background-color: pink; }

¿React Native está muriendo? En 2024 la pregunta flota en muchas conversaciones técnicas, pero la respuesta corta es no. React Native sigue siendo una opción válida para muchas empresas y proyectos, aunque su posición ya no es la de elección automática frente a alternativas como Flutter, Kotlin Multiplatform o las mejoras de SwiftUI. Este artículo repasa el estado actual, rendimiento, arquitectura, casos de uso recomendados y cómo encaja en la oferta de Q2BSTUDIO, empresa especializada en desarrollo de software a medida, aplicaciones a medida, inteligencia artificial, ciberseguridad y servicios cloud aws y azure.

Estado actual de React Native en 2024: React Native ha madurado. La adopción de la Nueva Arquitectura, con TurboModules, Fabric y Codegen, ha reducido muchas fricciones históricas. El soporte de TypeScript está más integrado, el motor Hermes mejora tiempos de arranque y consumo de memoria, y Expo ha evolucionado para facilitar workflows puros en JavaScript sin renunciar al acceso a código nativo cuando hace falta. Aun así persisten desafíos: para funciones nativas complejas suele requerirse código nativo adicional, las animaciones muy exigentes siguen favoreciendo a implementaciones nativas o a Flutter, y el ecosistema puede sentirse fragmentado entre usar Expo o RN puro.

Rendimiento y comparativa práctica: En pruebas reales típicas con tres tipos de app se observan tendencias claras. En una galería de imágenes intensiva Flutter suele ofrecer el render y la fluidez más consistentes, alcanzando tasas de frames superiores en escenarios gráficos. En una app CRUD sencilla React Native destaca por velocidad de desarrollo y menor tiempo hasta un MVP funcional. En aplicaciones de chat en tiempo real o con uso intensivo de hilos y multimedia, Kotlin Multiplatform y soluciones nativas pueden manejar mejor ciertas cargas. Resumen rápido de observaciones: Flutter lidera en animaciones y frames por segundo, React Native brilla en rapidez de desarrollo y ecosistema web/javascript, Kotlin Multiplatform aporta un camino prometedor para compartir lógica de negocio entre plataformas con código nativo en UI.

La Nueva Arquitectura de React Native: La migración a TurboModules y Fabric cambia la forma en que JS se comunica con la capa nativa, reduciendo el coste de la serialización y permitiendo renderizado concurrente y bindings más seguros mediante Codegen. El resultado es menor latencia en llamadas nativas, mejor manejo de memoria y mayor mantenibilidad de proyectos grandes. Todo esto hace que React Native sea una opción madura para productos empresariales cuando el equipo tiene experiencia en JavaScript o TypeScript.

Ejemplos y experiencia de desarrollo: Para equipos que ya dominan React y buscan iteración veloz, la combinación de Expo, Hermes y TypeScript reduce considerablemente el tiempo al mercado. Para proyectos que requieren rendimiento extremo en animaciones o procesamiento nativo intenso, recomendamos evaluar Flutter o una implementación nativa. En Q2BSTUDIO solemos definir la arquitectura óptima tras un análisis de requisitos, coste y roadmap, y proponemos la tecnología que maximice retorno y mantenibilidad.

Cuándo elegir React Native en 2024: Use React Native si su equipo conoce React, si prioriza rapidez de desarrollo y prototipado, si necesita compartir lógica de negocio entre iOS y Android y si su app no depende de animaciones extremadamente complejas o procesado nativo intensivo. Considere Flutter o Kotlin Multiplatform si la experiencia de usuario requiere animaciones nativas excepcionales o si dispone de especialistas móviles internos.

Servicios y competencias de Q2BSTUDIO: En Q2BSTUDIO diseñamos y desarrollamos aplicaciones a medida y software a medida, integrando inteligencia artificial aplicada, agentes IA y soluciones de power bi para visualización y análisis. También ofrecemos auditorías y servicios de ciberseguridad, pentesting y hardening para proteger aplicaciones móviles y APIs. Si su proyecto necesita infraestructura escalable y segura, trabajamos con servicios cloud aws y azure para desplegar soluciones resilientes y optimizadas. Para proyectos que buscan incorporar IA de forma estratégica, podemos diseñar pipelines de datos, modelos y agentes IA personalizados. Con un enfoque full stack entregamos tanto el desarrollo de la app multiplataforma como la integración con servicios de inteligencia de negocio y automatización.

RapidRelief IA 2025: Evaluación de Daños 5x Más Rápida y Guía de Rescate es una solución multimodal diseñada para acelerar la toma de decisiones en situaciones de emergencia y reducir el tiempo de respuesta de forma significativa.

En Q2BSTUDIO somos una empresa de desarrollo de software y aplicaciones a medida con especialización en inteligencia artificial, ciberseguridad y servicios cloud. Nuestro objetivo con RapidRelief IA 2025 es convertir un teléfono en una herramienta de evaluación inmediata que combine análisis de imágenes, texto y audio para ofrecer una valoración de daños clara, priorizada y accionable.

La aplicación permite subir fotografías y descripciones breves para obtener en segundos una clasificación de la gravedad del incidente, recomendaciones de seguridad priorizadas y un informe descargable listo para compartir con equipos de rescate o aseguradoras. Entre las funcionalidades destacadas están la detección automática de grietas estructurales, zonas inundadas y señales de incendio, la generación de visualizaciones antes y después y un asistente conversacional que guía al usuario paso a paso.

Todos hemos sentido ese pequeño escalofrío antes de ejecutar un git reset --hard. Para el hackathon creé una herramienta que apaga ese miedo para siempre. La llamo Git Sensei, un guardián potenciado por inteligencia artificial para la línea de comandos. Es una herramienta diseñada para hacer Git seguro, sencillo y más inteligente. Actúa como una red de seguridad ante comandos peligrosos, traduce instrucciones en lenguaje natural a comandos Git y, lo más importante, entiende el contexto del repositorio para ofrecer el comando correcto en el momento adecuado.

El reto era clásico: cómo construir algo a la vez fiable y creativo. Las funciones de seguridad tenían que ser perfectas: planificación previa, arquitectura clara y un enfoque riguroso guiado por especificaciones. Las funciones basadas en IA necesitaban ser experimentales: iteración rápida, prompting conversacional y libertad para innovar. Intentar hacer ambas cosas simultáneamente suele acabar en un compromiso imperfecto.

La solución fue un modelo de desarrollo híbrido. Primero establecí una base sólida mediante spec to code: definí requisitos, diseño y tareas y generé un fundamento robusto y testeable. Con la base segura pasé a la parte experimental: codificación por vibración y prompt engineering para enseñar al modelo a ser consciente del contexto. La plataforma que utilicé permitió separar la arquitectura estable de la exploración creativa, acelerando el desarrollo sin sacrificar seguridad.

En la demo llegó el momento wow. Creé un archivo nuevo no rastreado y ordené a Git Sensei que guardara mi trabajo. Un traductor habitual fallaría, pero el sistema consciente del contexto detectó el archivo no rastreado y sugirió correctamente git add feature.txt. No solo tradujo mis palabras, entendió mi intención y el estado del repositorio.

La lección principal es que ya no hay que elegir entre planificación rígida e innovación caótica. Con las herramientas de IA modernas se puede aplicar la metodología adecuada a cada parte del problema, obteniendo un proceso más estratégico, flexible y potente.

¿Alguna vez miraste un codebase y pensaste necesito un mapa, una brújula y tal vez un terapeuta? Todos hemos estado ahí. Cuando un UserController llega a 500 líneas, maneja autenticación, envía correos de cumpleaños y te hace dudar de tus decisiones profesionales, es hora de cambiar de enfoque. DDD y CQRS no son solo siglas bonitas, son herramientas para convertir ese espagueti en una sinfonía ordenada.

Imagina la aplicación como una casa bien organizada. Cada planta tiene su propósito y nadie lava la ropa en la cocina. Arquitectura propuesta en cuatro capas: dominio, aplicación, infraestructura y presentación, cada una con responsabilidades claras para mantener el código comprensible y adaptable.

La Capa Dominio es el corazón de la aplicación, aquí vive la lógica de negocio pura y sin contaminación por frameworks. Un agregado User puede definirse mediante constructores controlados y value objects que garantizan invariantes. Por ejemplo un Password que valida longitud mínima y ofrece un método hash, o un Email que valida formato. Así los errores se evitan antes de ejecutar la lógica y el dominio no conoce nada sobre bases de datos ni HTTP.

Value objects actúan como porteros de los tipos de datos. Si intentas crear un usuario pasando una cadena en lugar de un Email, el diseño te lo impide. Esto reduce bugs y mejora la autocompletación del IDE.

La Capa Aplicación orquesta los escenarios de negocio con Commands y Handlers. Un RegisterUserCommand expresa intención: nombre, email, password, rol. El Handler lee como una historia: verificar si el email existe, crear el usuario con la lógica del dominio, persistirlo y disparar eventos. Así las reglas de negocio quedan centralizadas y testables.

La Capa Infraestructura realiza el trabajo sucio: persistencia, APIs externas, mensajería. Su truco es ser reemplazable. Un repositorio Eloquent es solo una implementación de una interfaz de repositorio. Si mañana migras a MongoDB, escribes otro repositorio y la capa dominio queda intacta.

La Capa Presentación habla HTTP, traduce requests a commands y devuelve respuestas JSON. Un controlador debe ser delgado y honesto: validar, construir el command, invocar al handler y mapear el resultado a la respuesta. Esa simpleza facilita mantenimiento y seguridad.

Beneficios palpables: pruebas más sencillas al poder mockear repositorios y probar handlers sin tocar la base de datos; independencia de framework porque la lógica de negocio no depende de Laravel o Symfony; seguridad de tipos y validaciones tempranas con value objects; manejo de errores claro mediante excepciones específicas; y eventos que permiten reaccionar a sucesos sin acoplar funcionalidades como envíos de correo o analítica.

Usar este enfoque tiene sentido cuando la complejidad del negocio supera lo trivial, cuando el equipo es mayor a tres desarrolladores, cuando el proyecto vive más de unos meses o cuando valoras la sostenibilidad. No es necesario para un CRUD mínimo o un hackathon de fin de semana.

Introducción: Creé un flujo de trabajo en GitHub Actions que realiza copias de seguridad automáticas de repositorios de GitHub hacia un bucket S3 de AWS. La idea surge de la necesidad de no depender únicamente de plataformas externas y de contar con copias completas y accesibles en la nube para recuperación y auditoría. En Q2BSTUDIO como empresa de desarrollo de software y aplicaciones a medida ofrecemos soluciones que incluyen automatización de procesos, integración con servicios cloud y arquitecturas seguras para proteger el código fuente y los activos digitales.

Motivación: Tras leer sobre la importancia de mantener múltiples copias de seguridad y no confiar solo en GitHub, decidimos diseñar un enfoque serverless y totalmente online que aprovecha los flujos programados de GitHub Actions. Así se evita depender de un PC encendido todo el tiempo y se obtiene una solución gestionada, escalable y fácil de auditar por equipos de desarrollo y operaciones.

Cómo funciona a alto nivel: el workflow se ejecuta en un cron programado por GitHub Actions, clona el repositorio objetivo con git clone --mirror para obtener todo el historial, crea un archivo bundle comprimido y lo sube al bucket S3. Ese proceso permite almacenar historial completo de commits, referencias de ramas y tags, y la configuración remota y refs necesarias para restaurar el repositorio en otro servidor.

Pasos concretos implementados: ejecutar el workflow en horario definido por schedule de GitHub Actions, git clone --mirror del repositorio objetivo, generar un bundle con git bundle create repo.bundle --all o un tar.gz del espejo, y usar la utilidad awscli preinstalada en los runners de GitHub para copiar el bundle a S3 con aws s3 cp repo.bundle s3://mi-bucket/backups/fecha.repo.bundle. Este enfoque es compatible con políticas de ciclo de vida en S3 para optimizar costes y retención.

Qué se respalda: historial completo de commits incluyendo todas las ramas y tags, referencias de branch y tag, configuración remota y refs que permiten una restauración fiel del repositorio. Qué no queda incluido: issues, pull requests, proyectos, discusiones, historial de Actions, wikis o archivos estáticos de GitHub Pages, ni configuraciones avanzadas del repositorio como reglas de protección de ramas. Para capturar issues o PRs sería necesario integrar la API de GitHub y exportar esos objetos por separado.

Lecciones aprendidas: instalación de awscli no fue necesaria en runners alojados por GitHub porque ya viene preinstalado, lo que simplifica el workflow. En autenticación, los Fine grained Personal Access Tokens pueden presentar limitaciones al usar git remoto en algunos casos; un token Classic con el scope repo resultó más fiable para operaciones espejo. GitHub Copilot aportó sugerencias útiles mientras resolví incidencias en las primeras ejecuciones. Documentar y comentar el workflow y manejar logs estructurados facilita la detección de fallos.

Los deepfakes de audio representan una amenaza creciente para la seguridad digital y la confianza en sistemas biométricos y judiciales. Un clon de voz bien entrenado puede autorizar transacciones fraudulentas o introducir pruebas sonoras fabricadas que desestabilizan procesos legales. Sin embargo, muchas herramientas de detección operan dentro de una cámara de eco: son evaluadas con conjuntos de datos pulcros y poco representativos que no reflejan la complejidad del mundo real.

El problema central es que los detectores suelen entrenarse y validarse con muestras cuidadosamente seleccionadas que favorecen ciertos sintetizadores y condiciones acústicas, lo que ofrece una falsa sensación de seguridad. Para romper esa cámara de eco hay que someter a estrés estos sistemas con una mayor diversidad de habla auténtica: ambientes ruidosos, distintos acentos, variantes dialectales, estilos conversacionales o formales, teléfonos de baja calidad, grabaciones en la calle o en salas reverberantes.

Beneficios de una evaluación más amplia incluyen descubrir debilidades ocultas, mejorar la generalización de los modelos, reducir sesgos derivados de datos limitados, aumentar la confianza en sistemas de autenticación y orientar estrategias de entrenamiento adversarial. También permite auditorías de seguridad más realistas y efectivas, esenciales para entornos regulatorios y empresariales.

Un desafío clave es la disponibilidad de conjuntos de datos diversos, etiquetados y de alta calidad; es como buscar oro en un desierto vasto. Recomendaciones prácticas: curar un dataset balanceado que represente distintos grupos demográficos y entornos de grabación, incorporar técnicas de aumento de datos, usar adaptación de dominio y validar continuamente con red teams y pruebas en producción. Además, combinar detección automática con análisis forense humano y sistemas explicables ayuda a mitigar falsos positivos y negativos.