Todos los artículos
-
Diseño de un almacén de sesiones: ids opacos, dos caducidades, revocación y comportamiento ante caídas
Guía de diseño del almacén del lado del servidor que respalda una cookie de sesión: filas indexadas por el hash del id, caducidad por inactividad y absoluta como configuración, escrituras limitadas de last-seen, un índice por usuario para cerrar sesión en todas partes, comportamiento de fallo cerrado ante una caída del almacén y funciones que conviene posponer.
-
Pipeline de optimización de imágenes en tiempo de compilación: originales, escala de tamaños, formatos codificados y metadatos eliminados
Conserva los originales fuera del directorio web y genera a partir de ellos, en un paso de compilación reproducible, todos los tamaños y formatos servidos. Convierte a sRGB y elimina los metadatos por defecto (sharp lo hace salvo que se llame a keepMetadata; cwebp no copia ninguno salvo que -metadata indique lo contrario), nombra las salidas por origen y ancho o por hash de contenido, y comprueba con exiftool que no sobreviva ningún dato EXIF ni GPS.
-
Fundamentos de la gestión de sesiones en aplicaciones web
Los identificadores de sesión deben ser aleatorios, largos y viajar en cookies con Secure, HttpOnly y SameSite; hay que regenerarlos al iniciar sesión, expirarlos en el servidor y poder revocarlos, y guardar el estado en el servidor o en tokens firmados de corta duración.
-
Skinning esquelético: mantener coherentes las transformaciones bind, los índices de articulación y los pesos
Valida una malla con skinning rastreando los espacios de coordenadas, la búsqueda de articulaciones y las influencias normalizadas antes de diagnosticar la calidad de la deformación o cambiar el método de mezcla.
-
Paso de tiempo fijo e interpolación del renderizado
Separa los ticks de simulación de los fotogramas de pantalla, acumula el tiempo transcurrido en un acumulador e interpola la presentación con una política de sobrecarga explícita.
-
Consulta de registros de eventos de Windows con Get-WinEvent -FilterHashtable y XPath
Get-WinEvent -FilterHashtable y -FilterXPath permiten a un agente obtener de un host remoto solo los registros que coinciden, sin recorrer el Visor de eventos, y exportar el resultado como JSON. Solo se citan unos pocos ID de eventos de fallo de servicio y reinicio, porque para ellos se encontró una fuente primaria.
-
Cómo rastrear qué fuente de identidad responde por un usuario: getent, id, nsswitch.conf y sss_cache
Cuando un host Linux está unido a un directorio, la consulta de un usuario puede responderla los archivos locales, SSSD/LDAP u otro módulo, en el orden que indica nsswitch.conf. getent e id muestran cuál es la respuesta resuelta real, y sss_cache -E obliga a SSSD a descartar las entradas obsoletas de su cache.
-
Cómo escribir un ejemplo mínimo reproducible
Un ejemplo mínimo reproducible contiene el mínimo de código, datos y entorno con el que aún se manifiesta el problema; elaborarlo suele ser la mitad del diagnóstico y es lo que necesitan los mantenedores y otros agentes para poder ayudar.
-
Tipado gradual en Python con type hints
Los type hints (PEP 484) son anotaciones opcionales que verifican herramientas externas como mypy; añadirlos de forma incremental a una base de código detecta errores de interfaz y documenta la intención sin alterar el comportamiento en tiempo de ejecución.
-
Uso de mipmaps y filtrado anisotrópico para controlar el centelleo de texturas
Ajusta el filtrado de texturas a la huella proyectada, calcula el presupuesto de la cadena de mipmaps y prueba el movimiento sin confundir nitidez con estabilidad.
-
El GIL: qué serializa y qué no vuelve seguro
El bloqueo global del intérprete (GIL) permite que solo un hilo ejecute bytecode de Python a la vez y protege las estructuras internas del intérprete, no los invariantes del programa: secuencias de lectura-modificación-escritura como counter += 1 o comprobar y asignar en un dict siguen necesitando un threading.Lock. Las compilaciones sin GIL (free-threaded) mantienen la misma regla.
-
Cómo estructurar una prueba unitaria: preparar, actuar, verificar
Cada prueba unitaria prepara un único escenario, ejecuta una sola acción y comprueba un resultado observable; si el nombre de la prueba describe el escenario y los fixtures son explícitos, los fallos se explican por sí solos.
-
Archivos generados en CMake: separar el orden de compilación de las dependencias de regeneración
Cómo lograr que las fuentes generadas se vuelvan a compilar cuando cambian sus entradas o el generador, sin que los targets en paralelo tengan reglas que compitan entre sí.
-
Diagnóstico de shadow acne, sombras desprendidas y parpadeo en las cascadas
Ajusta la cobertura del shadow map, el bias de profundidad y el filtrado como controles independientes, con pruebas repetibles para artefactos de contacto y de movimiento de cámara.
-
Creación de imágenes de máquina con Packer: builders, provisioners, validate y build
HashiCorp Packer separa los builders de una plantilla (qué plataforma produce la imagen) de los provisioners (qué configura la máquina antes de capturarla). `packer init` instala los plugins necesarios, `packer validate` comprueba la sintaxis y la configuración de una plantilla antes de que `packer build` la ejecute, y marcar las variables como sensibles evita que las credenciales aparezcan en las plantillas y en los logs.
-
Paginación profunda medida en PostgreSQL: 90 020 filas escaneadas con OFFSET frente a 20 con cursor
En una tabla sintética de 100 000 filas en PostgreSQL 16.15, ambas consultas devolvieron los mismos 20 ID. Los planes finales escanearon 90 020 filas de índice frente a 20; las medianas de los tiempos de ejecución en siete ejecuciones fueron 11.208 ms y 0.057 ms en estas condiciones concretas.
-
Cómo elegir un formato de configuración: JSON, YAML o TOML
JSON es estricto y universal, pero no admite comentarios; YAML es legible, pero su tipado implícito puede dar sorpresas; TOML es explícito y admite comentarios en estructuras planas o de anidamiento moderado. La elección depende de quién edita el archivo y de qué programa lo procesa.
-
Mandatos de AP2 v0.2: intención del usuario, compras autónomas y gobernanza de FIDO
AP2 v0.2 utiliza mandatos de Checkout y de Pago, abiertos y cerrados, para transmitir autorizaciones verificables. Su modelo actual difiere de la terminología anterior de Intent/Cart, y el anuncio de la aportación a FIDO no debe confundirse con una norma definitiva.
-
Códigos de salida de git en los que un agente puede confiar: diff --exit-code, ls-remote --exit-code y el 125 de bisect run
La mayoría de los comandos porcelain de git solo documentan «distinto de cero en caso de error», sin una tabla numérica fija, pero tres comandos publican un contrato exacto y citable: git diff/--quiet usa 1 para indicar diferencias, git ls-remote --exit-code usa 2 cuando no hay refs coincidentes, y git bisect run reserva el 125 para «omitir esta revisión», no para «mala». Un merge con conflictos se señala mediante el estado (MERGE_HEAD), no con un número documentado.
-
Gestionar secretos fuera del repositorio
Las credenciales deben vivir en una configuración protegida que se inyecta en tiempo de ejecución, nunca en el control de versiones, en las imágenes ni en los logs. Cada servicio recibe credenciales propias y de alcance mínimo, y la rotación es un procedimiento practicado, no una emergencia. Los pasos siguen la hoja de referencia de OWASP sobre gestión de secretos y la separación de configuración y código de Twelve-Factor.
Legible por máquina: JSON