Ideas, casos de uso y guías sobre IA, programación avanzada y software a medida para optimizar tu negocio.

Qué ocurrió en SeaTunnel

Una sola línea de código en Apache SeaTunnel versión 2.3.9 provocó un consumo de memoria descontrolado al usar el conector de Kafka, hasta agotar 12 GB en menos de 5 minutos. Al ejecutar un job de streaming Kafka a HDFS en un clúster SeaTunnel Engine de 8 núcleos y 12G de RAM, y aun con la limitación read_limit.rows_per_second=1 configurada, la memoria subió de 200 MB a 5 GB en 5 minutos, no se liberó al detener el job y al reanudar siguió creciendo hasta generar OOM y reinicios de los workers.

Causa raíz

La revisión de código identificó el problema en el método createReader de la clase KafkaSource donde elementsQueue se inicializaba como una cola sin límite utilizando LinkedBlockingQueue sin capacidad establecida. Esto generó dos fallos críticos: una cola ilimitada que podía crecer indefinidamente si el productor superaba al consumidor y una limitación de lectura inefectiva porque read_limit.rows_per_second se aplicaba al procesamiento aguas abajo y no al consumo desde Kafka, provocando acumulación de mensajes en memoria.

La solución aplicada

La comunidad resolvió el problema mediante la PR#9041 introduciendo una cola acotada y configurable. Las mejoras principales fueron reemplazar LinkedBlockingQueue por ArrayBlockingQueue con tamaño fijo, añadir el parámetro de configuración queue.size y establecer un valor por defecto seguro DEFAULT_QUEUE_SIZE igual a 1000. Con ello se limita la retención en memoria y se evita que un pico de entrada agote los recursos del nodo.

Buenas prácticas y recomendaciones

Actualizar versión Actualice SeaTunnel a la versión que incluye la corrección para evitar el riesgo de fuga de memoria. Configurar correctamente Ajuste queue.size según las necesidades de negocio y las características del flujo de datos. Monitorizar memoria Aunque la cola sea acotada, vigile el uso de memoria del sistema y dimensione buffers y workers. Entender la limitación de tasa Tenga en cuenta que read_limit.rows_per_second regula el procesamiento en la canalización, no el ritmo de consumo directo desde Kafka.

Impacto y beneficios

La corrección no solo mitigó el riesgo de OOM sino que mejoró la estabilidad y la capacidad de configuración del conector Kafka. Al introducir colas acotadas y parámetros ajustables, los equipos pueden gestionar mejor los recursos y prevenir acumulaciones de datos que provoquen fallos en producción.

Cómo podemos ayudar desde Q2BSTUDIO

En Q2BSTUDIO, empresa de desarrollo de software y aplicaciones a medida, somos especialistas en soluciones escalables que incluyen software a medida, inteligencia artificial e integración con plataformas cloud. Si su proyecto requiere optimización de pipelines, arquitecturas de streaming seguras o auditorías de rendimiento, nuestro equipo puede asesorarle y aplicar soluciones personalizadas. Ofrecemos servicios en ciberseguridad y pentesting para garantizar la resiliencia de sus infraestructuras, así como servicios cloud AWS y Azure para desplegar sistemas robustos y escalables. Para proyectos de inteligencia de negocio y visualización recomendamos nuestras soluciones de Power BI y servicios inteligencia de negocio que facilitan la toma de decisiones basada en datos.

Recuerdo mi primer contacto con monorepos fue con Lerna; en ese momento parecía un cambio radical. Más adelante migré una base de código grande a un monorepo con Lerna, pero el ecosistema evolucionó muy rápido y hoy contamos con herramientas como Nx, Turborepo y npm workspaces que mejoran continuamente la experiencia de desarrollo y el rendimiento de compilación.

Cada herramienta aporta ventajas distintas. Lerna fue pionera y sigue siendo útil para gestionar paquetes, pero carece de algunas optimizaciones modernas. Turborepo destaca por su enfoque en el caching de builds y la velocidad en monorepos orientados a frontend y fullstack. Nx ofrece una plataforma más completa con generadores, análisis de dependencias, y soporte empresarial para proyectos a gran escala. npm workspaces es ideal si se busca simplicidad y aprovechar el propio gestor de paquetes sin añadir otra capa de herramientas.

Beneficios generales de usar monorepo para proyectos nuevos incluyen reutilización de librerías y utilidades, mejor colaboración entre equipos, herramientas y configuraciones coherentes, y refactorizaciones transversales más sencillas. Además, características como cache local y remoto, ejecución distribuida de tareas y análisis estático facilitan escalar equipos y productos.

Si emprendiera un proyecto nuevo hoy elegiría según el contexto: para un producto empresarial con muchos equipos y requisitos de consistencia y extensibilidad optaría por Nx; para iniciativas donde la velocidad de desarrollo y builds rápidos son críticos consideraría Turborepo; para proyectos pequeños o con la intención de reducir dependencias externas npm workspaces puede ser suficiente. Lerna sigue siendo válido en ciertos escenarios históricos, pero ya no es la primera opción para nuevas implementaciones.

En este artículo explico una técnica avanzada de OpenRewrite orientada a lógicas complejas basada en el uso de mensajes entre visitantes del árbol sintáctico abstracto AST. Si necesitas una introducción básica a OpenRewrite puedes revisar documentación previa, pero aquí nos centraremos en cómo coordinar acciones que requieren información situada en distintos niveles del AST.

La idea central es que algunas transformaciones no pueden resolverse mirando un único nodo: por ejemplo identificar una invocación de método para actuar sobre la declaración de la propia función que la contiene. OpenRewrite usa el patrón visitante para recorrer el AST y ofrece un mecanismo de mensajería que permite marcar información en el visitante que procesa invocaciones para que sea leída posteriormente por el visitante que procesa declaraciones de métodos.

Caso de uso ilustrativo: imagina una librería que instrumenta métodos con llamadas manuales a un temporizador mediante logStart y logEnd alrededor de la ejecución. Queremos transformar ese código de la siguiente forma cuando detectemos esta instrumentación

1. Eliminar la invocación de inicio del temporizador logStart.

2. Eliminar la invocación de fin del temporizador logEnd si existe.

3. Añadir la anotación Timed sobre la declaración del método, utilizando la anotación proporcionada por micrometer io.micrometer.core.annotation.Timed.

Para implementar esto en OpenRewrite se utilizan tres utilidades clave: un MethodMatcher para identificar con precisión las invocaciones de logStart y logEnd, un AnnotationMatcher para comprobar si la anotación Timed ya está presente en la declaración, y un JavaTemplate para insertar la anotación y gestionar las importaciones necesarias. El flujo general es el siguiente

a) Un visitante que recorre invocaciones de método detecta logStart o logEnd y, además de eliminar el nodo de invocación devolviendo null, coloca un mensaje en el primer nodo contenedor de tipo MethodDeclaration indicando que debe añadirse la anotación.

b ) El mensaje se coloca de forma localizada usando putMessageOnFirstEnclosing con el alcance de MethodDeclaration, de modo que solo la declaración del método que contiene la invocación podrá leerlo y actuar en consecuencia.

c ) Un visitante que recorre declaraciones de método lee ese mensaje. Si existe y la anotación Timed no está ya presente, utiliza JavaTemplate para añadir la anotación y añade la importación correspondiente. De este modo se coordina la lógica entre dos niveles diferentes del AST sin contaminar todo el contexto global.

Este patrón es muy útil en refactorizaciones complejas: puedes eliminar código redundante, centralizar comportamientos en anotaciones o adaptadores y garantizar que las transformaciones se aplican solo cuando se detecta el patrón completo. Además, al limitar el alcance del mensaje se evita que cambios en otras partes del mismo fichero activen anotaciones por error.

En cuanto a implementación práctica conviene recordar algunos puntos:

• Usar MethodMatcher cuando necesites identificar invocaciones por tipo y firma.

• Usar AnnotationMatcher para evitar duplicar anotaciones o romper contratos existentes.

• Emplear putMessageOnFirstEnclosing para pasar información desde un visitante de nodos hijos al visitante del contenedor relevante, y preferir mensajes con alcance lo más limitado posible.

• Utilizar JavaTemplate tanto para insertar código como para gestionar imports de forma limpia y portable entre distintos entornos Java.

En Q2BSTUDIO aplicamos este tipo de técnicas avanzadas de refactorización automatizada en proyectos de software complejo donde la consistencia y la calidad del código son críticas. Somos una empresa especializada en desarrollo de aplicaciones a medida y software a medida, con experiencia en inteligencia artificial, ciberseguridad y servicios cloud. Si necesitas modernizar o automatizar refactorizaciones en tu base de código podemos ayudarte a diseñar recetas OpenRewrite a medida integradas en tus pipelines.

Shipaton Do0ne Diario de Construcción #3 - Do0ne 1.0 estable Hoy cerré la fase inicial de correcciones y mejoras de interfaz trabajando desde casa. Con este esfuerzo la primera versión estable de Do0ne ya está completa y las funciones centrales operan según lo previsto.

En esta guía práctica para crear y configurar psplash en OK3588-C Linux embebido describimos paso a paso cómo reemplazar el logo por defecto, integrar barras de progreso y compilar de forma limpia usando herramientas de código fuente. psplash es una utilidad ligera para mostrar una pantalla de arranque gráfica durante las primeras fases del inicio del sistema, ideal para placas Rockchip RK3588 y variantes como OK3588-C.

Requisitos previos y preparación: asegúrate de disponer del toolchain cruzado para ARM correspondiente a tu rootfs, paquetes de compilación como make gcc git libpng-dev y las utilidades de imagen convert. Conecta tu OK3588-C o prepara la imagen del sistema donde incluir psplash. Si trabajas con Yocto o Buildroot el proceso se integra en la receta o en el overlay del filesystem.

Paso 1 obtener el código fuente: clona el repositorio oficial de psplash o descarga la versión que prefieras. Paso 2 preparar la imagen: crea un PNG con las dimensiones exactas del framebuffer de tu placa; opciones comunes son 1280x720 o 1024x600 según pantalla. Optimiza el PNG para reducir tamaño y paleta si buscas tiempos de carga más rápidos.

Paso 3 convertir la imagen para psplash: utiliza la herramienta psplash-image si está disponible o convierte el PNG a un formato soportado y genera el array C que se incluye en el binario. Alternativamente puedes compilar psplash para buscar la imagen en disco en tiempo de arranque si tu initramfs lo permite.

Paso 4 modificar código si quieres barras de progreso: edita psplash.c o los módulos pertinentes para dibujar barras en función de eventos del init. Un enfoque típico es exponer puntos de control en los scripts de arranque que envíen comandos a psplash mediante su socket o FIFO para actualizar el progreso.

Paso 5 compilación cruzada y limpieza: configura el entorno CROSS_COMPILE a tu toolchain por ejemplo CROSS_COMPILE=arm-linux-gnueabihf- make clean; make CFLAGS=-O2; verifica que el binario resultante sea compatible con tu rootfs. Instala el ejecutable en usr/bin o libexec según convenga y crea la unidad systemd o el script init que lance psplash muy temprano en el arranque.

Integración final: si usas initramfs añade psplash al initramfs para mostrar la animación desde el primer momento. Si prefieres systemd, crea un servicio que se ejecute Before=multi-user.target y que cierre cuando pase el control al sistema gráfico. Prueba arrancando con salida por consola serie para ver mensajes de debug y ajusta tiempos y rutas de recursos.

Consejos de personalización: incluye varios fotogramas para simular animación, ajusta la paleta para reducir memoria, y añade mensajes dinámicos para estado de red o montaje de dispositivos. Para entornos industriales como los que maneja OK3588-C recomendamos pruebas de resistencia y validar con herramientas de monitoreo.

En este artículo práctico explicamos cómo crear y configurar psplash en la placa OK3588-C basada en Rockchip RK3588. Aprenderás a reemplazar el logo por defecto, añadir barras de progreso e integrar la animación de arranque en un sistema Linux embebido, además de compilar todo de forma limpia con herramientas de código fuente y cadenas de compilación cruzada.

Introducción y requisitos Si trabajas con RK3588 necesitarás un entorno de compilación aarch64, el código fuente de psplash, y acceso al sistema de arranque de tu imagen rootfs o initramfs. Herramientas habituales: aarch64-linux-gnu-gcc o la toolchain específica del BSP, make, git y utilidades como xxd para convertir imágenes a arrays C si decides incrustar el bitmap en el binario.

Paso 1 Preparar el entorno Instala la toolchain cruzada y las dependencias. Clona el repositorio de psplash o descarga la versión incluida en tu BSP. Configura variables de entorno CROSS_COMPILE apuntando a la cadena de herramientas adecuada para RK3588 antes de compilar.

Paso 2 Reemplazar el logo por defecto Crea una imagen con las dimensiones adecuadas para tu pantalla y formato soportado. Puedes convertir una imagen PNG a un array C con xxd -i imagen.png imagen.c o compilar psplash para cargar imágenes externas desde /usr/share/psplash o desde el initramfs. Modifica el código fuente o los recursos incluidos para apuntar al nuevo asset y recompila.

Paso 3 Integrar barras de progreso Psplash soporta actualizaciones de estado mediante su API simple. Actualiza tus scripts de arranque, systemd services o init scripts para enviar mensajes al socket de psplash indicando porcentaje o etapas de arranque. De esta forma tu animación mostrará barras de progreso sincronizadas con la carga del sistema.

Paso 4 Compilación limpia Ejecuta make clean y compila con CROSS_COMPILE adecuado. Si integras psplash en initramfs, asegúrate de regenerar la imagen cpio y empaquetarla en la imagen de arranque. Para placas RK3588 revisa las integraciones con U Boot y el init system del BSP para garantizar que psplash se ejecute lo antes posible en el arranque.

Consejos prácticos Mantén los assets optimizados para reducir el tiempo de carga. Si quieres compatibilidad con múltiples resoluciones, implementa detección de framebuffer al inicio. Para debugging, redirige mensajes desde tus scripts para confirmar que psplash recibe los eventos de progreso.

Como alguien que quería entrar en el mundo DevOps, me perdía entre tutoriales teóricos y vídeos desactualizados hasta que encontré el curso DevOps con AWS de Technogeeks y noté una diferencia real en mi aprendizaje.

El curso explica cómo usar las herramientas de AWS para automatizar, desplegar y gestionar aplicaciones de forma más eficiente. Aprendí a automatizar despliegues con AWS CodePipeline y CodeDeploy, conceptos básicos de Docker y Kubernetes, a configurar infraestructura con Terraform y a monitorizar con CloudWatch. También incluyó apoyo para entrevistas, creación de currículum y un certificado que añadí a mi perfil LinkedIn.

En mi experiencia lo que marcó la diferencia fue el enfoque práctico: proyectos reales guiados por formadores con certificaciones AWS y ejercicios orientados a casos de empleo. Si te interesa dar el salto, es un curso ideal para principiantes y desarrolladores que quieren dominar herramientas de la nube.

En Q2BSTUDIO, empresa especializada en desarrollo de software y aplicaciones a medida, aprovechamos estas mismas buenas prácticas DevOps para entregar soluciones robustas y seguras. Ofrecemos servicios de creación de aplicaciones a medida y software a medida, integración con servicios cloud y despliegues automáticos para acelerar el time to market.

Giti: Confianza y Popularidad Global

En un mercado mundial saturado de opciones, Giti Tires se ha consolidado como una marca en crecimiento que inspira confianza entre conductores particulares, flotas y profesionales del sector automotriz. Fundada en 1951, Giti ha pasado de proveedor regional a fabricante global con presencia en más de 130 paí­ses y plantas de producción en China, Indonesia y Estados Unidos. Su gama incluye neumáticos para turismos, camiones y autobuses, SUV y 4x4, así como compuestos y diseños orientados a la competición, lo que explica su atractivo para audiencias diversas.

Rendimiento demostrado gracias a I+D: Giti invierte en centros de I+D en Estados Unidos, Alemania, China y Reino Unido, adaptando modelos para distintos climas y condiciones de carretera. Sus logros incluyen pruebas en lluvia, nieve y desierto, diseños que favorecen la eficiencia de combustible y el uso de simulación avanzada para mejorar agarre y durabilidad. Todo ello se traduce en neumáticos que se comportan bien en evaluaciones tanto de usuario como profesionales.

Asociaciones OEM: La presencia como equipo original en vehículos de marcas globales certifica la calidad del fabricante y su cumplimiento de exigentes estándares de seguridad y resistencia.

Precio competitivo sin renunciar a la calidad: Giti ha encontrado un equilibrio entre coste y prestaciones ofreciendo larga duración de dibujo, confort, bajo ruido y tracción fiable, lo que aporta un valor atractivo para quienes buscan soluciones rentables y seguras.

Sostenibilidad: La marca ha implementado iniciativas verdes, reduciendo emisiones en plantas, desarrollando neumáticos con baja resistencia a la rodadura para mejorar eficiencia de combustible y aplicando políticas de reciclado y gestión de residuos.

Certificaciones y seguridad: Giti cuenta con homologaciones internacionales como DOT, ECE e ISO/TS 16949, lo que brinda confianza adicional en mercados exigentes.

Opiniones de clientes: Reseñas independientes y pruebas profesionales destacan su comportamiento en mojado y seco, potencia de frenado, manejo y confort, factores que refuerzan su reputación global.

Por qué elegir Giti hoy: Si conduces en ciudad, en autopista o en condiciones climáticas adversas, Giti ofrece alternativas orientadas al rendimiento y al coste inteligente, con un claro compromiso hacia la innovación y el medio ambiente.

Q2BSTUDIO y la transformación digital en el sector automotriz: En un mundo donde la movilidad y la tecnología convergen, las empresas necesitan socios que integren soluciones digitales completas. Q2BSTUDIO es una empresa de desarrollo de software que diseña aplicaciones a medida y software a medida para optimizar procesos de negocio, gestión de flotas, monitorización predictiva y telemetría. Nuestros servicios abarcan inteligencia artificial, agentes IA e ia para empresas para mejorar mantenimiento predictivo, optimización de rutas y análisis de comportamiento de usuarios y vehículos.

XXE en React.js es una vulnerabilidad de análisis XML en el servidor que puede explotarse cuando una aplicación React permite subir o enviar XML a una API que lo parsea de manera insegura. El ataque aprovecha entidades externas en el XML para leer archivos locales, realizar SSRF o provocar fallos del parser.

Cómo se infiltra XXE en un flujo de trabajo con React: la interfaz acepta XML por carga de archivo o texto, el frontend lo envía al backend, y si el parser en el servidor expande entidades externas como file:// o https:// el atacante puede lograr exfiltración de datos sensibles, acceso a recursos internos o denegación de servicio.

Consejos de UX y validación en el cliente: valide el tipo de archivo y el tamaño en el navegador para mejorar la experiencia de usuario, pero recuerde que la seguridad debe residir en el servidor. Rechace cargas que no sean XML y notifique al usuario si el contenido contiene referencias peligrosas como DOCTYPE. Estas comprobaciones son para usabilidad y retroalimentación rápida, no sustituyen controles del servidor.

Buenas prácticas en el servidor: nunca confiar en las comprobaciones del cliente. Bloquee DOCTYPE y entidades externas en la capa API, limite el tamao de la carga, aplique cabeceras Content-Type estrictas y ejecute los servicios en entornos con salida de red restringida por defecto. Prefiera parsers que no soporten DTD ni resolución de entidades externas.

Patrones vulnerables comunes: usar librerías XML con opciones que permiten expandir entidades y cargar DTD desde la red. Esto puede darse en implementaciones de Node.js u otros entornos cuando se habilitan opciones de sustitución de entidades o carga remota de DTD.

Cómo asegurar el parsing en Node.js y otros stacks: desactive la carga de DTD y la expansión de entidades, habilite nonet o su equivalente para evitar solicitudes de red, limite el tamao de entrada y valide que el cuerpo no contenga DOCTYPE antes de parsear. Como alternativa utilice parsers sin soporte DTD, por ejemplo parsers modernos que no resuelven entidades externas de forma predeterminada.

Lista de verificación para endurecer la canalización de XML: · bloquear DOCTYPE y entidades externas en el servidor · elegir parsers que no admitan DTD o XXE · validar Content-Type y aplicar límites de tamaño · ejecutar APIs en entornos con egress restringido · incluir pruebas XXE en SAST y DAST dentro del CI.

Ejemplo de mitigación rápida: rechazar peticiones con DOCTYPE y usar un parser seguro o una librería que no resuelva entidades externas. Esto reduce el riesgo de exfiltración como la lectura de rutas sensibles en el servidor o la realización de SSRF desde el backend.