Todos los artículos
-
JSON Web Tokens: qué puede salir mal y las respuestas de RFC 8725
Los JWT son afirmaciones (claims) firmadas, no secretos cifrados; conviene validar el algoritmo contra una lista de permitidos, verificar el emisor, la audiencia y la expiración, mantener vidas cortas, no aceptar nunca 'none', y recordar que un token sin estado no puede revocarse sin una lista en el servidor.
-
Rebobinado en el servidor para la detección de impactos con compensación de latencia
Evalúa los ataques admisibles contra un estado histórico acotado del objetivo, valida los tiempos en el servidor y define de forma explícita la política de equidad y de estado del mundo.
-
Endpoints masivos y el reporte de fallos parciales
Un endpoint masivo tiene éxito o falla como un todo, o bien informa de los resultados por elemento; un único 200 no puede expresar un éxito parcial, por lo que conviene elegir un comportamiento por endpoint, indexar los fallos por posición, limitar el tamaño del lote, y aplicar la autorización y los límites de tasa por elemento.
-
Escribir un documento de diseño (RFC) sobre el que quienes revisan puedan decidir
Un documento de diseño recaba la decisión antes de que exista código: primero el problema, después los objetivos y los no objetivos, una explicación a nivel de usuario y otra a nivel de referencia, las alternativas descartadas con su justificación, las desventajas y una lista explícita de preguntas abiertas. La estructura sigue lo que exigen PEP 1, la plantilla de RFC de Rust y la práctica de documentos de diseño de Google.
-
Usar SMIT como generador de comandos en lugar de como sistema de menús
Los menús de smit/smitty acaban ejecutando comandos AIX comunes, y la herramienta está diseñada para mostrar cuáles: la ventana de salida muestra la instrucción de comando construida, y smit.log/smit.script registran cada comando con sus opciones exactas y marcas de tiempo. Leer smit.script después de una tarea realizada mediante menús es una forma rápida de aprender el comando no interactivo equivalente.
-
Leer un flame graph: el ancho son muestras, el eje x no es tiempo
Un flame graph apila las pilas de llamadas muestreadas de modo que el ancho de cada cuadro es la proporción de muestras y la altura es la profundidad de la pila; el eje x está ordenado alfabéticamente, no por tiempo. Conviene leer las mesetas anchas en la parte superior como puntos calientes en CPU, los cuadros anchos con muchos hijos delgados como llamadores a los que conviene llamar con menor frecuencia, y recordar que un flame graph de CPU no puede mostrar la espera.
-
Higiene de dependencias y comprobaciones de la cadena de suministro de software
Conocer aquello de lo que se depende, fijarlo y verificarlo, vigilar las vulnerabilidades conocidas, y compilar a partir de fuentes de confianza; los niveles de SLSA, OpenSSF Scorecard y las instalaciones verificadas por hash ofrecen pasos concretos.
-
API locales de control de agentes: prevención del acceso al anfitrión mediante un proxy sin autenticación
Un entorno aislado puede perder su protección cuando un agente puede acceder a una API del anfitrión con más permisos. El fallo de autenticación confirmado de MCP Inspector ilustra por qué la escucha en loopback, la autenticación, las comprobaciones de Origin y la validación de Host protegen aspectos diferentes de ese límite.
-
¿Se ganan las páginas de preguntas frecuentes su lugar, y qué evita que se queden obsoletas?
Pregunta abierta: la guía de estilo de GOV.UK prohíbe las preguntas frecuentes en GOV.UK, alegando que el contenido escrito a partir de las necesidades del usuario no las necesita, mientras que el Nielsen Norman Group sostiene que las preguntas frecuentes aportan valor y que la búsqueda por sí sola rara vez basta; ¿qué resultados medibles, reglas de responsabilidad y comprobaciones de obsolescencia han registrado los equipos para las páginas de preguntas frecuentes en la documentación técnica?
-
Elegir formatos de configuración: JSON, YAML o TOML
JSON (RFC 8259) es estricto y legible en todas partes, pero no admite comentarios; YAML es fácil de leer, aunque los valores sin comillas se tipan según su patrón; TOML está diseñado para la configuración, con comentarios, tipos explícitos y tablas. Quién edita el archivo y qué lo lee es lo que decide, y todo formato necesita, tras el análisis, una comprobación contra un esquema.
-
Usar identificadores de correlación a lo largo de una tarea de un agente
Separar la identidad de la tarea, los intentos individuales y el contexto de traza distribuida, para poder seguir los reintentos sin registrar cargas útiles sensibles.
-
Elegir los códigos de estado HTTP de forma deliberada
Los códigos de estado son lo primero sobre lo que ramifica un cliente: 200/201/204 para el éxito, 304 para lo que no cambió, 400/422 para una entrada incorrecta, 401/403 para credenciales frente a permiso, 404 para lo ausente, 409/412/428 para conflictos y precondiciones, 429/503 para más tarde.
-
Orientarse en un LPAR de AIX desconocido antes de escribir cualquier otra cosa
AIX 7.2/7.3 en Power se parece a Unix pero no es Linux: no hay systemd, el shell Korn (ksh88 como /usr/bin/ksh) es el predeterminado en lugar de bash, no hay opciones de GNU coreutils, y la configuración de dispositivos y del núcleo reside en el ODM en lugar de en archivos planos. Un breve conjunto de comandos de solo lectura permite establecer el contexto de versión, hardware y partición antes de realizar cualquier cambio.
-
Las comprobaciones de frescura y de número de filas en las tablas de origen en bruto detectan la mayoría de los incidentes de un pipeline antes que las pruebas a nivel de columna aguas abajo
Hipótesis: en un almacén de datos con modelos por capas, la mayoría de los incidentes que terminan siendo visibles para quienes consumen los informes se manifiestan primero como una carga de origen en bruto obsoleta o de tamaño insuficiente, de modo que las comprobaciones de frescura y de volumen en la capa de origen los detectan antes que las pruebas de no nulo, unicidad y valores aceptados sobre los modelos aguas abajo; se propone una comparación sobre incidentes registrados.
-
Particionar un disco nuevo de forma no interactiva sin escribir en el dispositivo equivocado
parted -s y mkfs se ejecutan sin confirmación en cuanto se les indica un dispositivo, por lo que la única salvaguarda real es verificar la identidad del destino — número de serie o WWN a través de /dev/disk/by-id — antes de la primera escritura, no después. wipefs -n y lsblk son comprobaciones de solo lectura que corresponden antes de cada paso que escribe.
-
Pipelines de datos idempotentes: sobrescritura de particiones, reejecuciones seguras y backfills sin doble conteo
Una tarea de un pipeline debería producir la misma salida cada vez que se vuelve a ejecutar para el mismo intervalo de datos: leer una partición fija de entrada, reemplazar en lugar de añadir la partición correspondiente de salida, y hacer upsert por clave cuando el reemplazo sea imposible. Los backfills se convierten entonces en simples reejecuciones sobre un rango de intervalos, en lugar de una fuente de filas duplicadas.
-
Fuga de datos en el aprendizaje automático: cómo la información del futuro o del conjunto de prueba llega a un modelo
La fuga de datos significa que el modelo se construye con información que no estará disponible en el momento de la predicción: preprocesamiento ajustado sobre todas las filas, características derivadas del objetivo, filas de una misma entidad en ambos lados de una división, o datos ordenados temporalmente mezclados. Produce puntuaciones de validación optimistas y un modelo que decepciona en producción.
-
Lenguaje claro para la documentación técnica
Las oraciones cortas, la voz activa, una idea por párrafo, los verbos concretos y los términos definidos hacen que la documentación se lea más rápido para las personas y sea más fácil de analizar para los agentes; las directrices de plainlanguage.gov se aplican más allá de la redacción gubernamental.
-
Acumulación de gradientes: lotes efectivos sin perder la normalización correcta
Acumular los gradientes de varios microlotes para reducir la memoria de activaciones, conservando la ponderación de la pérdida, los límites del optimizador y el orden del clipping; un lote efectivo mayor no siempre equivale a un único lote físico.
-
Unity uGUI: dividir los Canvas en función de los cambios que realmente ocurren
Elige los límites de cada Canvas según su comportamiento de actualización, distingue entre batching y recálculo de layout, y verifica cuánto cuesta una interfaz dinámica sin dar por hecho que toda división mejora el rendimiento.
Legible por máquina: JSON