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

Trabajaba en un proyecto de hackathon un asistente de IA que te permite conversar con tu infraestructura usando RAG y MCP, como si mantuvieras un diálogo en tiempo real con todo tu entorno cloud.

Implementamos compatibilidad con múltiples proveedores de LLM como Gemini, Watsonx y Ollama. La lógica de cambio de proveedor existía, pero estaba muy incrustada en el código del proyecto.

Introducción: en esta guía aprenderás a convertir páginas de un PDF en imágenes JPEG usando C# y la biblioteca Spire.PDF. Este proceso es ideal cuando trabajas con APIs de modelos de lenguaje que aceptan imágenes en Base64, ya que tras la exportación podrás codificar cada JPEG a una cadena Base64 de forma sencilla. Con unas pocas líneas tendrás un flujo compatible con entornos .NET perfecto para automatización documental, integraciones con APIs y más.

Paso 1 instalación del paquete necesario

Ejecuta en tu proyecto dotnet add package Spire.PDF Este paquete permite cargar archivos PDF y convertir cada página a imagen.

Paso 2 crea la clase auxiliar PdfHelper

Define una clase reutilizable que reciba la ruta del PDF y el directorio de salida. Lógica sugerida 1 crear PdfDocument y cargarlo con pdf.LoadFromFile 2 asegurarte de que el directorio de salida exista con Directory.Exists y Directory.CreateDirectory 3 iterar por cada página con un bucle for 4 para cada índice i obtener un Stream con pdf.SaveAsImage i 5 convertir el Stream a Image con Image.FromStream 6 construir la ruta de salida con Path.Combine y un nombre tipo Page i+1 .jpg 7 guardar la imagen con Image.Save usando ImageFormat.Jpeg 8 cerrar el documento con pdf.Close

Paso 3 usa el helper en tu aplicación

Invoca el método estático ToJPEG indicando la ruta del PDF de entrada y el directorio donde guardar las imágenes. Ejemplo conceptual PdfHelper.ToJPEG pdfPath, outputDirectory Donde pdfPath apunta al archivo PDF y outputDirectory es la carpeta destino.

Paso 4 ejecuta y verifica los resultados

Compila y ejecuta dotnet run Revisa el directorio de salida y encontrarás archivos Page-1.jpg Page-2.jpg y así sucesivamente. Abre cualquier JPEG con tu visor de imágenes para verificar la calidad de la conversión.

Por qué este helper es útil

Si tu integración con modelos de lenguaje requiere imágenes en Base64, tras convertir PDF a JPEG podrás codificar con Convert.ToBase64String File.ReadAllBytes ruta_imagen_jpg Este flujo simplifica la inyección de contenido de PDFs en tus prompts y endpoints, agilizando escenarios de aplicaciones a medida, software a medida y automatización.

Consejos de calidad y rendimiento

Para documentos con muchas páginas ejecuta el proceso en trabajos por lotes o tareas asíncronas. Si necesitas menos peso, ajusta la calidad del JPEG y el tamaño de la imagen antes de guardar. Para almacenamiento y entrega a escala evalúa usar servicios cloud aws y azure con CDN.

Resumen

Has visto cómo convertir PDFs a JPEG con C# y Spire.PDF, encapsularlo en una clase auxiliar reutilizable y preparar las imágenes para su uso en APIs de inteligencia artificial mediante Base64.

Cómo te ayuda Q2BSTUDIO

Si eres estudiante y estás entrando en el mundo del código, las startups o el desarrollo de software, hay una herramienta que puede darte una ventaja real desde el primer día: el GitHub Education Student Pack. Imagina un cofre con herramientas y recursos premium que los profesionales pagan mes a mes, y ahora imagina obtenerlo todo gratis. Suena genial, y eso es exactamente lo que ofrece el GitHub Student Pack.

Por qué importa y cómo aprovecharlo al máximo. Como estudiante, acceder a herramientas profesionales suele requerir suscripciones de pago, justo cuando más necesitas experimentar. GitHub entendió ese reto y se unió a grandes compañías tecnológicas para crear un paquete que te permite aprender haciendo, sin coste, mientras construyes tu portfolio y amplías tus oportunidades de prácticas y empleo.

Con este pack podrás aprender y practicar con herramientas de nivel profesional, crear proyectos reales sin gastar un centavo y fortalecer tu currículum demostrando dominio de tecnologías usadas por equipos de primer nivel. Es el puente perfecto entre aprender y construir.

Qué incluye el GitHub Student Pack. Es un conjunto con más de cien ofertas gratuitas de socios de GitHub que se actualizan con frecuencia. Entre los destacados encontrarás herramientas de desarrollo como GitHub Pro para repositorios privados, revisiones de código avanzadas y gestión de proyectos, además de editores y extensiones como Atom y Visual Studio Code para llevar tu productividad al siguiente nivel.

En servicios en la nube tendrás créditos para desplegar y probar aplicaciones en DigitalOcean y Heroku, además de recursos de aprendizaje con AWS Educate para que practiques computación en la nube tal y como lo hacen los profesionales.

Para diseño y productividad encontrarás Canva Pro para crear presentaciones, gráficos y contenido social de alto impacto, y Figma para prototipado de interfaces y experiencias de usuario.

En formación continua destacan plataformas como DataCamp para ciencia de datos, Python y machine learning de forma práctica, y Educative con rutas de estudio y preparación de entrevistas técnicas.

Otros beneficios útiles incluyen Namecheap para registrar un dominio y publicar tu portfolio, así como GitKraken, una interfaz gráfica de Git que hace el control de versiones increíblemente cómodo. Y hay mucho más, ya que el pack se renueva de forma periódica con nuevas ofertas.

Aralez reverse proxy y service mesh sobre Cloudflare Pingora

Aralez significa guardián y sanador de héroes en la mitología armenia, un espíritu canino alado que baja del cielo para lamer las heridas de los caídos y devolverles la vida. Ese es el espíritu del proyecto: resiliencia, protección y rendimiento para tus servicios.

Construido en Rust y potenciado por el motor Pingora de Cloudflare, Aralez ofrece rendimiento de clase mundial, seguridad avanzada y escalabilidad desde el primer minuto. Ideal como reverse proxy de alto rendimiento, service mesh ligero y puerta de enlace para microservicios, APIs, WebSockets y gRPC.

Características clave

• Recarga dinámica de configuración sin reinicios mediante API o archivo supervisado • Terminación TLS con OpenSSL y carga automática de certificados desde una carpeta • Detección automática de TLS en upstreams para conexiones internas seguras • Limitador de peticiones integrado por vhost, global y por ruta con prioridad por ruta • Autenticación integrada con Basic, API Key mediante cabecera x-api-key y JWT con emisión de tokens en el endpoint interno jwt • Balanceo de carga round robin, failover con health checks y sesiones pegajosas mediante cookie • Puerto unificado para HTTP y WebSocket, soporte gRPC transparente y HTTP2 listo • Inyección de cabeceras globales y por ruta • File server embebido para ficheros estáticos como upstream • Métricas Prometheus integradas • Seguridad de memoria al estar escrito íntegramente en Rust • Alto rendimiento con Pingora y Tokio para I O asíncrona

Aspectos destacados

• Proveedores de upstreams tipo file con mapeos declarados y consul para descubrimiento dinámico • Hot reload de upstreams al guardar el archivo, sin cortes • WebSocket y gRPC automáticos sin configuración adicional • Sticky sessions activables globalmente • Salud de upstreams con métodos plugin HEAD GET POST • Push remoto de configuración ligero mediante API HTTP para integraciones CI CD

Estructura de archivos típica

• main.yaml configuración principal al arranque • upstreams.yaml mapeos de upstreams en caliente • etc server.crt y key.pem para TLS del proxy o de la API segura

Resumen de configuración main.yaml

• threads hilos del demonio • user y group para soltar privilegios tras arrancar como root • daemon ejecución en segundo plano • upstream_keepalive_pool_size tamaño del pool de conexiones keepalive a upstreams • pid_file error_log y upgrade_sock rutas de pid log y socket de upgrade • config_address y config_tls_address direcciones del API de configuración • config_tls_certificate y config_tls_key_file ficheros TLS del API si usas https • proxy_tls_grade high medium unsafe nivel de cifrados TLS • proxy_address_http y proxy_address_tls direcciones de escucha del proxy • proxy_certificates carpeta con certificados y claves en formato NAME.crt y NAME.key con carga automática • upstreams_conf ruta al archivo de upstreams • log_level info warn error debug trace off • hc_method hc_interval método e intervalo de health check • master_key clave maestra para API y secreto de JWT • file_server_folder y file_server_address servidor de ficheros embebido • config_api_enabled habilita el push remoto de configuración

Resumen de upstreams.yaml

• provider file o consul • definición de hostnames y paths con sus backends balanceados • cabeceras por upstream y cabeceras globales para todas las respuestas • autenticación opcional basic apikey jwt • to_https para redirecciones 301 selectivas • rate_limit global por vhost y por ruta con prioridad por ruta

Instalación

Descarga el binario para tu arquitectura desde las releases del repositorio en GitHub, dale permisos de ejecución y lánzalo con el archivo de configuración. Hay builds glibc de alto rendimiento con dependencias de sistema comunes y builds musl estáticas 100 por cien portables. También existe imagen Docker basada en Debian slim para despliegues rápidos.

Rendimiento glibc vs musl

Los binarios glibc muestran mayor rendimiento en pruebas intensivas con aproximadamente 129 mil peticiones por segundo frente a unos 124 mil en builds musl, a cambio de depender de bibliotecas estándar presentes en prácticamente cualquier distribución Linux.

Ejecución y systemd

Inicia Aralez apuntando a tu main.yaml o intégralo como servicio systemd con PIDFile y recarga mediante la opción de upgrade en caliente para modificaciones sin tiempo de inactividad.

Ejemplo conceptual de enrutamiento

• provider file • sticky_sessions false • rate_limit global 10 y por ruta 20 en la raíz de un dominio • to_https configurable global y por ruta con 301 • upstreams múltiples por ruta con balanceo • detección automática de TLS en upstreams incluyendo certificados autofirmados aceptados de forma silenciosa • cabeceras CORS globales y cabeceras adicionales por ruta • autenticación JWT con validación mediante secreto derivado de master_key

Hot reload

Los cambios en upstreams.yaml se aplican al instante. Con provider consul los upstreams se refrescan periódicamente desde la API del clúster.

Soporte TLS

Activa proxy_address_tls y proporciona certificados y clave. Se soporta OpenSSL para terminación y control del nivel de cifrados con proxy_tls_grade. Los certificados del proxy pueden cargarse automáticamente desde una carpeta, sin reinicio.

API remota de configuración

Publica un nuevo upstreams.yaml a la dirección config_address con el parámetro key igual a la master_key configurada. Ideal para pipelines CI CD y despliegues GitOps.

Autenticación integrada

• basic mediante cabecera estándar • apikey usando cabecera x-api-key • jwt mediante cabecera Authorization Bearer o parámetro de URL araleztoken • emisión de tokens JWT en el endpoint interno jwt aportando master_key owner y tiempo de validez en minutos

Licencia

Licencia Apache 2.0.

Notas y compatibilidad

• Basado en Pingora para eficiencia y flexibilidad • Pensado para edge proxying enrutamiento interno y escenarios híbridos en la nube • Upgrade WebSocket automático y proxy gRPC transparente • Sticky sessions mediante cookie • HTTP2 listo para producción

Comparativa en pocas palabras

Aralez ofrece recarga en caliente real por API y archivo, autenticación JWT nativa, detección automática de TLS en upstreams, soporte gRPC y WebSocket sin configuración y métricas Prometheus integradas, superando la necesidad de módulos externos o configuraciones complejas en alternativas tradicionales como Nginx HAProxy o Traefik.

Benchmark sintético con Oha

Con 3 upstreams Rust asíncronos sobre red 1 Gbps, 300 conexiones simultáneas durante 10 minutos, los binarios glibc alcanzaron alrededor de 129 mil solicitudes por segundo con latencias medias del orden de milisegundos, mientras que los binarios musl rondaron 124 mil, confirmando el foco de Aralez en rendimiento y eficiencia.

Cómo puede ayudarte Q2BSTUDIO

Elicitación en MCP: acortando la brecha entre humanos y agentes IA

La evolución de la inteligencia artificial no solo consiste en crear sistemas autónomos capaces de acceder a datos y ejecutar tareas con mínima intervención humana. También requiere mecanismos claros para detenerse en puntos críticos, pedir aclaraciones y confirmar acciones. El Model Context Protocol MCP ha sido clave al estandarizar la comunicación entre modelos de lenguaje LLM y herramientas externas, actuando como una especie de API universal. Sin embargo, no todos los flujos deben estar totalmente automatizados. Justo ahí entra Elicitation, una nueva capacidad del borrador de la especificación MCP que introduce el humano en el circuito de forma nativa, segura y estructurada.

Qué es Elicitation en MCP

Elicitation aporta un mecanismo dinámico para que un servidor MCP solicite entradas estructuradas al usuario a través del cliente MCP. A diferencia de los enfoques tradicionales en los que todos los parámetros se definen de antemano, esta comunicación bidireccional permite flujos interactivos y seguros: desde confirmar una transacción financiera hasta aclarar una solicitud ambigua. El servidor emite una petición de elicitación con un esquema bien definido y el cliente la presenta mediante cualquier interfaz: consola, cuadro de diálogo, o mensajería corporativa. Una vez recibida la respuesta del usuario, el flujo continúa con el nuevo contexto.

El problema del contexto estático y por qué surge Elicitation

Antes de Elicitation, un cliente pedía al servidor MCP ejecutar una herramienta y devolver un resultado. En escenarios con aprobación humana por ejemplo gestión de gastos, el diseño se volvía engorroso: la herramienta debía programarse para esperar y la interacción con el usuario se resolvía con lógica ad hoc fuera del protocolo. No existía una forma estandarizada de representar esa intervención humana dentro del propio flujo MCP. Elicitation lo soluciona al estandarizar la solicitud de datos al usuario con un mensaje estructurado, manteniendo la coherencia del protocolo sin importar la interfaz del cliente. Con ello, MCP deja de ser una simple invocación de herramientas para convertirse en un marco capaz de gestionar flujos complejos, interactivos y multiturno.

Streamable HTTP: la base técnica que lo hace posible

Para entender Elicitation conviene conocer Streamable HTTP, uno de los dos transportes estándar en MCP junto con stdio. A diferencia de las APIs REST clásicas y sin estado, Streamable HTTP habilita comunicación bidireccional y con estado, permitiendo que el servidor envíe eventos en tiempo real al cliente. Esta es la piedra angular que posibilita notificaciones como las solicitudes de elicitación.

Flujo de comunicación con Streamable HTTP

Inicio de sesión: el cliente inicia una sesión con un POST y el servidor responde con un MCP-Session-Id que identifica toda la conversación.

Canal de notificaciones: el cliente inicializa un canal adicional para notificaciones.

Canal de eventos: el cliente abre una petición GET de larga duración al endpoint MCP con Content-Type text/event-stream para establecer Server Sent Events SSE y recibir mensajes de forma continua sin sondeo.

Descubrimiento de herramientas: el cliente solicita el catálogo de herramientas disponibles.

Invocación de herramientas: el cliente, asistido por un LLM, decide qué herramienta llamar y la invoca con el contexto adecuado.

Evento de Elicitation: cuando una herramienta necesita datos del usuario, el servidor empuja un evento JSON estructurado por el canal SSE. El cliente lo recibe y activa su manejador registrado para presentar la pregunta al usuario y recopilar la entrada.

Respuesta y continuación: el cliente envía la información capturada al servidor, este la procesa y el LLM completa la tarea con el nuevo contexto.

Cierre de sesión: el cliente finaliza con un DELETE, liberando recursos en el servidor.

Cómo funciona por dentro

En el servidor, el desarrollador define una herramienta capaz de solicitar información al usuario. Para ello, declara el esquema de la respuesta esperada por ejemplo un objeto con campos nombre y edad y, cuando la herramienta se ejecuta, emite una solicitud de elicitación al cliente con un mensaje y el esquema. La lógica del servidor queda en pausa de forma natural y se reanuda cuando llega la respuesta estructurada del cliente.

En el cliente, se registra un manejador de elicitación. Ese manejador recibe el mensaje y el esquema, presenta una interfaz adecuada por ejemplo un formulario o un prompt en consola, valida los datos según el esquema y envía un objeto estructurado de vuelta. Esta arquitectura desacopla el qué de la interacción del cómo: el servidor solo define qué datos necesita, mientras el cliente elige la mejor experiencia de captura sin romper la compatibilidad con el protocolo.

Ventajas y consideraciones clave

Elicitation posiciona a MCP como una plataforma para crear aplicaciones agenticas en las que humanos y agentes IA colaboran de forma segura y gobernada. Es ideal para casos de uso empresariales donde se requieren aprobaciones, verificaciones o decisiones supervisadas. No obstante, hay consideraciones importantes: la seguridad es prioritaria. Elicitation no debe utilizarse para capturar información extremadamente sensible como contraseñas o identificadores personales si no se aplican controles adicionales. Se recomienda integrar autenticación y autorización modernas y aprovechar las guías de seguridad del transporte Streamable HTTP junto con estándares como OAuth, además de cifrado de extremo a extremo y controles de acceso robustos.

Desde la perspectiva de experiencia de usuario, los esquemas dinámicos son poderosos, pero exigen que el cliente pueda renderizar formularios y validaciones de manera flexible. Pasar de una entrada por consola a una interfaz de producción implica contemplar estados, validaciones, accesibilidad y trazabilidad, especialmente en sectores regulados.

Qué viene después

El futuro apunta a elicitaciones multiturno, tipos de datos más ricos y validaciones contextuales, permitiendo flujos guiados aún más granulares como formularios asistidos y resolución de incidencias paso a paso. Combinado con agentes IA y herramientas externas, MCP se perfila como la capa de orquestación ideal para aplicaciones a medida y software a medida centradas en resultados.

Cómo te ayuda Q2BSTUDIO

En Q2BSTUDIO diseñamos e implantamos soluciones con inteligencia artificial e ia para empresas que integran MCP, Elicitation y agentes IA en entornos reales, alineados con tus procesos, cumplimiento normativo y objetivos de negocio. Creamos aplicaciones a medida y software a medida con analítica avanzada, ciberseguridad de nivel empresarial, servicios cloud aws y azure, y servicios inteligencia de negocio con power bi. Si buscas acelerar la automatización sin perder el control humano, podemos ayudarte a diseñar flujos híbridos humano IA y a industrializar su operación.

Q2BSTUDIO impulsa la transformación digital de tu organización con aplicaciones a medida y software a medida, combinando inteligencia artificial, ciberseguridad, servicios cloud aws y azure y servicios inteligencia de negocio para crear soluciones escalables, seguras y listas para crecer.

PASOS

# 1. Instalar Composer

# Descargar el script de Composer

$ curl -sS https://getcomposer.org/installer -o composer-setup.php

# Instalar Composer en el directorio bin del sistema

$ sudo php composer-setup.php --install-dir=/usr/local/bin --filename=composer

# Verificar que la instalación fue correcta

$ composer --version

# Añadir el bin de Composer al PATH del usuario

$ echo export PATH=$PATH:$HOME/.composer/vendor/bin >> ~/.zshrc && source ~/.zshrc

# 2. Instalar Laravel Sail

$ composer require laravel/sail --dev

$ php artisan sail:install --devcontainer

$ sail up

$ sail down

$ sail up -d --force-recreate

Añade lo siguiente a tu archivo .env para definir el puerto de la aplicación en Sail

# APP_PORT={TU_APP_PORT}

# por ejemplo uso 8888 para el puerto de Sail

APP_PORT=8888

Este cambio se aplicará al reconstruir el contenedor de Sail utilizando sail build --no-cache o sail up -d --force-recreate.

En Q2BSTUDIO te ayudamos a poner en marcha entornos de desarrollo y despliegue Docker con Laravel, optimizando pipelines y seguridad desde el primer día. Somos una empresa de desarrollo con foco en aplicaciones a medida y software a medida, especialistas en inteligencia artificial, ciberseguridad, servicios cloud aws y azure, servicios inteligencia de negocio y power bi, además de soluciones de ia para empresas como agentes IA y automatización de procesos.

Desglosemos la diferencia entre Target Servers y Target Endpoints en Apigee con ejemplos claros y en términos prácticos.

Diferencia central: abstracción frente a implementación. Un Target Server es un objeto de configuración reutilizable y con nombre que define dónde está tu servicio backend, es decir host, puerto y ajustes TLS, se centra en el destino. Un Target Endpoint es un bloque XML dentro del API proxy que define cómo llamar al backend, se centra en la operación, en el flujo de solicitud y respuesta, y normalmente utiliza un Target Server para saber adónde enviar la petición.

Aunque puedes alcanzar el mismo resultado sin Target Servers poniendo la URL del backend directamente en el Target Endpoint, los Target Servers añaden una capa de abstracción que aporta ventajas operativas importantes.

Target Endpoint, el cómo. Es un componente básico del proxy en Apigee. Se define dentro del bundle y representa la conexión saliente hacia el backend. Es específico del proxy y describe la interacción HTTP, incluyendo lógica de preprocesado con PreFlow, postprocesado con PostFlow, reglas de fallo y el elemento HTTPTargetConnection que señala el destino real.

Ejemplo sin Target Server. El Target Endpoint puede contener una URL directa, por ejemplo https://api.my-internal-service.com/v1/orders, lo que se suele llamar pass through o destino directo. En este caso, la URL queda acoplada al proxy y cualquier cambio exige redeploy.

Ejemplo con Target Server. El Target Endpoint no conoce la URL exacta; solo referencia por nombre a un Target Server, por ejemplo target-server-orders, y puede añadir un Path como v1/orders. Opcionalmente puede incluir una estrategia de balanceo en la propia definición del Target Endpoint, mientras que los miembros del pool se definen como Target Servers en el entorno.

Target Server, el dónde. Es una entidad específica del entorno, creada fuera de los proxies, reutilizable por muchos proxies. Define detalles de conexión de bajo nivel: host, puerto y configuración SSL o TLS. Permite balanceo de carga al crear varios Target Servers con el mismo nombre que apuntan a hosts distintos, formando un grupo que Apigee balancea automáticamente.

Cómo se crea un Target Server. Puedes hacerlo desde la interfaz de Apigee en la administración de entornos o vía Management API. En desarrollo, por ejemplo, podrías crear uno con nombre target-server-orders, host orders-service.dev.mycompany.net y puerto 443 con TLS habilitado. En producción, crearías dos o más con el mismo nombre y hosts distintos, como orders-service-prod-1.mycompany.com y orders-service-prod-2.mycompany.com, logrando balanceo de carga sin tocar los proxies.

Comparación práctica. Alcance: el Target Endpoint vive dentro del proxy, el Target Server vive en el entorno y es reutilizable. Propósito: el Target Endpoint define el cómo, la orquestación de la petición y la respuesta, mientras que el Target Server define el dónde, es decir host, puerto y parámetros TLS. Configuración: el Target Endpoint está en XML del bundle, el Target Server se gestiona por UI o API de administración. Contenido: el Target Endpoint contiene PreFlow, PostFlow, reglas de fallo y HTTPTargetConnection; el Target Server contiene Host, Port y SSLInfo. Balanceo: el Target Endpoint define la estrategia, el Target Server aporta los miembros del pool. Ejemplo de uso: el Target Endpoint añade cabeceras, transforma solicitudes y maneja errores; el Target Server encapsula las URLs de backend por entorno.

Cuándo usar cada uno. Usa un Target Endpoint con URL directa cuando prototipas rápido, la URL es simple y estable, y el proxy está fuertemente acoplado a un backend único. Usa Target Endpoint con Target Server cuando tienes distintos backends por entorno de test, stage y prod, cuando buscas reutilización entre proxies, necesitas balanceo de carga o deseas desacoplar operaciones para cambiar host o puerto sin redeploy.

Resumen. El Target Endpoint define qué hacer cuando llamas al backend y cómo orquestarlo. El Target Server define dónde se ejecuta esa llamada. Combinarlos ofrece separación de responsabilidades, portabilidad y una administración más sencilla de tus proxies entre entornos.