标签：#spanish

Durante más de cuatro décadas, hablar de servidores era prácticamente sinónimo de hablar de arquitectura x86 . Desde los primeros servidores empresariales hasta la mayoría de los centros de datos modernos, Intel y AMD han dominado la infraestructura sobre la que funcionan nuestras aplicaciones. Sin embargo, algo está cambiando. De forma silenciosa, los principales proveedores de nube como Microsoft Azure están incorporando cada vez más procesadores ARM para ejecutar cargas de trabajo modernas. ¿La razón? No es únicamente el rendimiento. Es la eficiencia energética. El problema de los centros de datos modernos Cada vez que desplegamos una máquina virtual o un clúster de Kubernetes en Azure, detrás existe un servidor físico consumiendo energía. Ahora imaginemos un centro de datos con cientos de miles de servidores. Incluso una pequeña reducción en el consumo eléctrico por servidor representa un ahorro enorme cuando se multiplica por toda la infraestructura. Y no solo hablamos de electricidad. Menos energía implica: menos calor generado menor necesidad de refrigeración menores costos operativos menor huella de carbono Por eso la eficiencia energética se ha convertido en un factor estratégico para los hyperscalers (gigantes tecnológicos que poseen y administran infraestructuras de centros de datos masivas a nivel global). ¿Qué diferencia a ARM de x86? A grandes rasgos: x86 utiliza una arquitectura CISC (Complex Instruction Set Computing) , con un conjunto amplio de instrucciones complejas. ARM utiliza una arquitectura RISC (Reduced Instruction Set Computing) , basada en instrucciones más simples y optimizadas. Esto no significa automáticamente que ARM sea “más rápido”. Lo que sí significa es que puede realizar muchas cargas de trabajo consumiendo considerablemente menos energía. En otras palabras: ARM no busca ganar por fuerza bruta. Busca hacer más con menos. ¿Por qué ahora? Hace unos años, ARM estaba asociado principalmente a teléfonos móviles. Hoy la situación es muy

Corro varios agentes respaldados por Bedrock en producción: análisis de documentos, emparejamiento de contenido, búsqueda en registros, búsqueda semántica. Esta es una pasada honesta sobre el OWASP Top 10 para aplicaciones LLM desde el lado de la implementación : el código de verdad que defiende cada riesgo y, igual de importante, las categorías donde mi respuesta es "parcial" o "todavía no". Primero el modelo de amenazas Un flujo de agentes es un pipeline: entrada no confiable → prompt → modelo → parseo → actuar. Cada flecha es una superficie de ataque. Antes de cualquier control, la pregunta más útil que me hice fue esta: ¿qué puede HACER de verdad un agente si el modelo está completamente manipulado? Mi respuesta dio forma a todo lo de abajo. Los agentes son mayormente-de-lectura : llaman a un modelo, leen filas acotadas de la base de datos, y escriben resultados de análisis con llave del usuario que pide. Sin shell, sin SQL arbitrario, sin llamada a herramientas. El radio de impacto es chico por construcción, que es el control más barato que existe. TL;DR, estatus honesto OWASP LLM Mi estatus El control LLM10 Consumo sin límite Fuerte Límite de tasa + cortacircuitos de costo mensual + topes de tokens por modelo LLM06 Agencia excesiva Fuerte (por diseño) Sin llamada a herramientas; mayormente-de-lectura; escrituras acotadas a quien llama LLM01 Inyección de prompt Parcial Contenido del usuario enmarcado como DATOS (delimitadores + preámbulo anti-inyección) LLM02 Divulgación de info sensible Parcial Limpieza de PII por regex antes del modelo; exclusiones auditadas LLM05 Manejo inadecuado de salida Parcial Validación de esquema + chequeos de fundamentación + sanear-antes-de-renderizar LLM07 Fuga del system prompt Parcial Registro versionado de prompts + regla anti-eco LLM08 Vector/Embedding N/A (todavía no construido) (nada) AuthN/Z + interruptor de apagado Fuerte Llave interna, gateo por cuota/gama, deshabilitado por agente LLM10 Consumo sin límite: empieza aquí, e

Durante mucho tiempo asocié el desarrollo de software con programar funcionalidades: crear entidades, armar controladores, conectar una base de datos, validar formularios y hacer que una aplicación responda correctamente. Sin embargo, durante el Trabajo Final de la asignatura Desarrollo de Aplicaciones Web , entendí que programar es solo una parte del problema. El verdadero desafío aparece antes de escribir código: decidir qué arquitectura conviene, por qué conviene, cuánto cuesta, qué riesgos resuelve y qué complejidad agrega. El trabajo consistió en diseñar un sistema de gestión clínica que comenzaba como un MVP para una única clínica y evolucionaba progresivamente hacia una plataforma SaaS multi-tenant . Aunque fue un proyecto académico, el ejercicio nos obligó a pensar como si estuviéramos tomando decisiones técnicas en un contexto real: con restricciones de negocio, costos, equipo, seguridad, datos sensibles y crecimiento futuro. La principal enseñanza fue: la mejor arquitectura es la que responde mejor al momento del producto . El primer desafío: no sobrediseñar desde el inicio Cuando empezamos a pensar el sistema, la tentación era ir directamente a una arquitectura compleja: microservicios, eventos, colas, Kubernetes, múltiples bases de datos y despliegues independientes. Pero al analizar el escenario inicial, esa decisión no tenía sentido. El sistema comenzaba para una sola clínica, con un presupuesto reducido y con requisitos todavía en etapa de validación. En ese contexto, arrancar con microservicios hubiera agregado más problemas que beneficios: comunicación entre servicios, contratos, versionado, observabilidad distribuida, debugging más difícil y mayor costo de infraestructura. Por eso, una de las decisiones más importantes fue comenzar con una arquitectura en capas , desplegada como un único proceso. Esta elección permitió separar responsabilidades sin asumir desde el principio la complejidad de un sistema distribuido. La capa de presentación se encarg

Cómo solucionar el error "Text content does not match server-rendered HTML" en Next.js Este error ocurre cuando el HTML generado en el servidor (SSR) no coincide con el árbol de React que se construye durante la hidratación inicial en el navegador. Es un problema crítico que rompe la experiencia de usuario y puede causar comportamientos impredecibles. Causa raíz En tu caso, el error está relacionado con contenido dinámico que varía entre renderizado del servidor y renderizado del cliente , probablemente por: Uso de Date() o new Date() en el renderizado (ej. fechas de eventos como JUN 9 , JUN 11 , etc.) Uso de typeof window !== 'undefined' o APIs del navegador directamente en el render Metaetiquetas o scripts que modifican el DOM antes de la hidratación (como iOS detectando fechas como enlaces) Configuración incorrecta de librerías CSS-in-JS o Edge/CDN que modifiquen el HTML Solución definitiva (pasos) ✅ Paso 1: Aisla el contenido dinámico con suppressHydrationWarning Si el contenido que varía es intencional (como fechas de eventos), envuelve solo el elemento problemático con suppressHydrationWarning={true} : // app/page.tsx o app/events/page.tsx export default function EventsPage () { const events = [ { name : ' NEXT.JS NIGHTS ' , date : new Date ( ' 2024-06-09 ' ) }, { name : ' AMS ' , date : new Date ( ' 2024-06-11 ' ) }, { name : ' LDN ' , date : new Date ( ' 2024-06-18 ' ) }, ]; return ( < div > < h2 > VIEW EVENTS </ h2 > < ul > { events . map (( event , i ) => ( < li key = { i } > < strong > { event . name } </ strong > { /* ✅ Solo este elemento usa suppressHydrationWarning */ } < time dateTime = { event . date . toISOString () } suppressHydrationWarning > { event . date . toLocaleDateString ( ' en-US ' , { month : ' short ' , day : ' numeric ' }) } </ time > </ li > )) } </ ul > </ div > ); } ⚠️ Importante : suppressHydrationWarning solo funciona en el elemento inmediato, no en hijos. Usa span , time , div , etc., no en contenedores grandes. ✅ Paso 2: Evita Da

Tabla de Contenidos Objetivo Restricciones de los Errores Basados en Texto Errores Personalizados en Go Conceptos Clave Implementar e Inspeccionar Errores Casos de Uso Comunes Para no morir en el intento y consejos que no pediste Conclusiones del Tema Objetivo Aprender a diseñar tipos de errores personalizados con metadatos de negocio en Go y a propagarlos correctamente a través del flujo de la aplicación sin perder su tipo ni su información de origen. Restricciones de los Errores Basados en Texto En programas sencillos, el uso de errors.New es perfecto. Sin embargo, en aplicaciones empresariales los errores necesitan transportar datos estructurados. Por ejemplo, si una validación de entrada falla, el frontend no solo quiere saber que "hubo un error", necesita saber qué campo exacto falló (ej. email ) y qué regla se violó (ej. formato inválido ). Si solo devolvemos una cadena de texto, la capa superior de nuestra aplicación tendría que parsear el texto del error con expresiones regulares para extraer los metadatos. Esto es extremadamente ineficiente, propenso a errores de formato y acopla la lógica interna a los mensajes de texto visibles al usuario. Tipos de Errores Comunes en Go Antes de analizar cómo propagar y envolver errores, es fundamental comprender los dos patrones principales que se utilizan en Go: Sentinel Errors : Son variables globales predefinidas que representan un estado de error estático y específico. Se definen a nivel de paquete y se comparan directamente por valor. Ejemplos estándar: io.EOF , sql.ErrNoRows . Creación: Generalmente declarados con errors.New (como var ErrNotFound = errors.New("not found") ). Custom Structs (Errores estructurados personalizados): Son estructuras que implementan la interfaz error y contienen campos adicionales para transportar metadatos dinámicos del fallo en tiempo de ejecución (como códigos de estado o parámetros de entrada). Creación: Un struct personalizado que implementa el método Error() (ej. type ValidationErr