Todos los artículos
-
¿Tras cuántos rebotes suaves, y en qué período, debería quien envía dejar de enviar correo a una dirección?
Pregunta abierta: los códigos de estado ampliados separan los fallos permanentes (5.X.X) de los fallos transitorios persistentes (4.X.X), pero el estándar deja el caso transitorio a la política de quien envía; ¿qué umbrales se han usado en la práctica y qué ocurrió con las tasas de recuperación y con la reputación?
-
Tiempo transcurrido en Go: la serialización pierde el componente de reloj monótono
Mantener separada la medición local de duración de las marcas de tiempo persistidas y de las políticas de plazos entre procesos.
-
Nomenclatura y capitalización consistentes de los campos JSON
Elegir una única convención de capitalización para los nombres de propiedad y aplicarla en todas partes: la guía de estilo JSON de Google y ProtoJSON usan lowerCamelCase, mientras que muchas APIs usan snake_case. Más allá de la capitalización, conviene mantener nombres con significado, los enums como cadenas, las marcas de tiempo como cadenas RFC 3339 y los enteros de 64 bits como cadenas.
-
Generar, criticar, revisar: cuándo un bucle de autoverificación compensa su coste
Un bucle en el que el modelo critica y revisa su propia salida mejora los resultados cuando la crítica dispone de una señal externa (tests, un validador, una fuente) y de una rúbrica fija; sin ella, los resultados publicados muestran que puede degradar las respuestas, y cada ronda añade al menos dos llamadas cuya entrada crece con el borrador.
-
La especificación Standard Webhooks frente a la cabecera HMAC de Shopify y al token de secreto compartido de GitLab
La especificación Standard Webhooks define las cabeceras webhook-id, webhook-timestamp y webhook-signature, un secreto en base64 con prefijo whsec_ cuyos bytes decodificados son la clave HMAC y una firma v1,<base64> sobre "{id}.{timestamp}.{payload}"; los tokens de firma de GitLab (GitLab 19.0, disponibilidad general en 19.1) la implementan tal cual. Shopify, en cambio, envía en X-Shopify-Hmac-SHA256 un HMAC en base64 del cuerpo sin procesar, y el antiguo X-Gitlab-Token de GitLab es un simple secreto compartido, no un HMAC en absoluto.
-
Plantilla de hipótesis
Un esquema para una hipótesis explícita y verificable, no un hecho establecido.
-
Convertir el alcance autorizado de una evaluación en condiciones de parada ejecutables
Ayudar a un agente de evaluación a detenerse en el límite acordado incluso cuando su siguiente acción sugerida parezca técnicamente conveniente. El método traduce el alcance aprobado por el operador en decisiones verificables antes de cualquier interacción con el objetivo.
-
Unity Addressables: diseñar ciclos de vida explícitos de carga y liberación
Asigna a cada carga asíncrona un propietario claro, conserva su handle durante todo el periodo de uso y define la limpieza para cuando las solicitudes fallen o queden obsoletas.
-
Almacenar datos derivados en PostgreSQL: columnas generadas frente a vistas materializadas
Una columna generada deriva un valor por fila a partir únicamente de esa fila, ya sea de forma virtual (calculada en la lectura) o almacenada (calculada en la escritura), y solo puede usar expresiones inmutables; una vista materializada almacena el resultado de cualquier consulta y está tan actualizada como su último REFRESH. Conviene usar columnas generadas almacenadas para la normalización por fila que deba indexarse, vistas materializadas para agregados costosos que puedan quedar desactualizados, y una tabla de resumen mantenida al día cuando ninguna de las dos encaja.
-
Probar que las actualizaciones de perfil no pueden asignar campos privilegiados de la cuenta
Crear una regresión acotada para las actualizaciones que aceptan datos de perfil ordinarios junto con campos que quien llama no debe poder controlar. El método propone una titularidad explícita de los campos en lugar de una lista de verificación genérica de validación de entradas.
-
Almacenamiento en el navegador: comparativa entre cookies, Web Storage e IndexedDB
Las cookies viajan con cada solicitud y son pequeñas por especificación; localStorage y sessionStorage son almacenes síncronos de cadenas con pocos MiB por origen; IndexedDB es asíncrono, transaccional y comparte la cuota amplia del origen. Todo el almacenamiento del navegador es best-effort a menos que se conceda persistencia, y está delimitado por origen.
-
Campos packed en Rust: evitar crear una referencia no alineada antes de convertirla a un puntero crudo
Entender por qué una referencia temporal puede violar ya los requisitos de alineación, y preferir la decodificación explícita de bytes siempre que sea posible.
-
Escribir una prueba unitaria en JUnit 5 y xUnit.net: anotaciones, ciclo de vida y casos parametrizados en paralelo
JUnit Jupiter marca las pruebas con @Test, ejecuta @BeforeEach y @AfterEach alrededor de cada una sobre una instancia nueva de forma predeterminada, y conduce los casos basados en datos con @ParameterizedTest más una anotación de fuente; xUnit.net usa [Fact], el constructor e IDisposable para la configuración por prueba sobre una instancia nueva, [Theory] con [InlineData] para los casos, y fixtures para el contexto costoso compartido. Escribir pruebas con la misma forma en ambos mantiene alineadas las convenciones de un equipo políglota.
-
Verificar la manipulación de paquetes RPM instalados con rpm -V
rpm -V compara los archivos instalados con las sumas de comprobación, permisos y propiedad registrados en el momento de instalar el paquete, y sus códigos de salida de una sola letra indican exactamente qué cambió. Esta metodología cubre cómo leer esa salida y sus límites como comprobación de integridad.
-
La política del mismo origen: qué es un origen y qué aísla
Un origen es el esquema, el host y el puerto de una URL. Un script puede leer y modificar documentos, almacenamiento y respuestas del mismo origen; las lecturas entre orígenes se bloquean de forma predeterminada, mientras que las escrituras entre orígenes, como los envíos de formularios, y la incrustación, como imágenes y scripts, suelen estar permitidas. CORS relaja las lecturas; aun así siguen siendo necesarias las defensas contra CSRF.
-
VACUUM, autovacuum y la hinchazón de las tablas
El control de concurrencia multiversión (MVCC) de PostgreSQL deja versiones de filas muertas tras las actualizaciones y las eliminaciones; VACUUM las recupera y mantiene las estadísticas y la protección contra el desbordamiento del identificador de transacción. El autovacuum debe permanecer activado y ajustarse para las tablas con mucha actividad.
-
Qué garantiza un clúster Raft: mayorías, un solo líder y lecturas linealizables
Los sistemas de consenso como etcd (Raft) permiten que una mayoría de servidores acuerde un registro ordenado; permanecen correctos ante cualquier número de fallos, pero solo avanzan mientras una mayoría sea alcanzable. Las lecturas linealizables pasan por el consenso y cuestan latencia; las lecturas serializables se sirven localmente y pueden estar desactualizadas.
-
Hacer que un sitio web sea legible para agentes: robots.txt, sitemaps y llms.txt
Los agentes y rastreadores encuentran contenido a través de un pequeño conjunto de convenciones: robots.txt para las reglas de acceso y la ubicación del sitemap, un sitemap XML con fechas de modificación reales, y llms.txt como guía breve y curada; ninguna de ellas sustituye a la autenticación.
-
Tras la llegada de un informe de vulnerabilidad: acusar recibo, evaluar, corregir en privado, divulgar
Una vez que un informe llega al contacto de seguridad del proyecto, el trabajo es una secuencia con fechas: acusar recibo con rapidez, clasificar (funciona como se espera, error, solicitud de función, vulnerabilidad), acordar un embargo con quien reporta, desarrollar la corrección en privado, obtener un identificador CVE y luego publicar y difundir un aviso que nombre las versiones afectadas y corregidas y reconozca a quien reportó. La guía para mantenedores de la OpenSSF y las indicaciones de divulgación de GitHub describen este proceso; este artículo lo resume para un proyecto con entre uno y cinco mantenedores.
-
Las actas de reunión con una sección de decisiones separada reducen las decisiones reabiertas
Hipótesis: los equipos cuyas actas de reunión enumeran cada decisión por separado (enunciado, opciones rechazadas, responsable, fecha) y la copian en un registro de decisiones duradero reabren con menos frecuencia cuestiones ya zanjadas que los equipos con actas narrativas, porque una decisión que puede encontrarse y citarse tiene menos probabilidad de discutirse de nuevo desde cero.
Legible por máquina: JSON