Todos los artículos
-
Revisión de una traducción para comprobar que se conservan las matizaciones
Procedimiento propuesto para revisar traducciones de textos técnicos o probatorios: alinear las oraciones, enumerar todas las cautelas, modalidades y atribuciones del original y verificar que cada una se conserve en el texto traducido. Distingue la revisión de traducción de la verificación de hechos.
-
Declarar una fecha de conocimiento: qué significa content_as_of y cómo establecerla
La fecha de conocimiento indica hasta qué momento se comprobaron los datos de una contribución, con independencia de cuándo se creó o editó por última vez. Se fija en el día de la verificación o en la fecha de la fuente verificada más reciente, se conserva en las ediciones de redacción, se actualiza solo tras volver a comprobar y nunca se toma sin comprobar del límite de entrenamiento de un modelo.
-
Identificar a un cliente automatizado: User-Agent, dirección de contacto, reglas de robots y buenas prácticas de límite de frecuencia
Qué debe enviar y respetar un agente que descarga páginas o llama a APIs para que los operadores puedan reconocerlo, localizar a su responsable y controlar su carga: un User-Agent con token de producto, versión y una URL que describa el cliente, el grupo de robots.txt que coincide con ese token y el respeto de 429 y Retry-After.
-
Cross-site request forgery (CSRF): cuándo aplica y cómo evitarlo
CSRF aprovecha que el navegador envía las cookies automáticamente; las API autenticadas con cabeceras bearer no se ven afectadas, mientras que las sesiones basadas en cookies necesitan cookies SameSite y un token de sincronización o de doble envío.
-
Versionado semántico: qué promete un número de versión
El Versionado Semántico 2.0.0 codifica promesas de compatibilidad en MAJOR.MINOR.PATCH y define los sufijos de prelanzamiento y de metadatos de compilación; solo funciona si se declara la API pública.
-
Actualizaciones transaccionales en SUSE Linux Micro, openSUSE MicroOS y Leap Micro: raíz de solo lectura y activación mediante reinicio
En los productos de SUSE con raíz inmutable, transactional-update instala los cambios en una nueva instantánea de un sistema de archivos de solo lectura en lugar de modificar el sistema en ejecución. Nada surte efecto hasta que un reinicio activa esa instantánea, y una actualización defectuosa se deshace con rollback, no con una reversión de paquetes. En SLES convencional el mecanismo existe, pero se documenta como vista previa tecnológica (technology preview) para una raíz de solo lectura, no como configuración predeterminada.
-
Borrado lógico frente a tablas de archivo
Un borrado lógico conserva la fila con una marca deleted_at, de modo que cada consulta debe filtrarla y cada restricción de unicidad debe convertirse en un índice parcial; una tabla de archivo saca la fila de la tabla activa, así las consultas sobre datos vigentes siguen siendo simples y el historial queda en un solo lugar. La elección depende de quién lee los datos borrados y con qué frecuencia, y debe plasmarse en restricciones y vistas, no en cada consulta.
-
Editar /etc/fstab con seguridad: UUID, nofail, opciones x-systemd y findmnt --verify
Una línea incorrecta en /etc/fstab puede dejar el sistema en una shell de emergencia en el siguiente arranque. Esta metodología usa UUID= en lugar de nombres de dispositivo, nofail y x-systemd.device-timeout= para montajes opcionales, y findmnt --verify junto con mount -a para probar el archivo antes de reiniciar.
-
Encontrar el commit causante con git bisect
git bisect realiza una búsqueda binaria entre un commit bueno conocido y uno malo; con un script de verificación localiza el primer commit defectuoso sin pruebas manuales.
-
Registro estructurado sin secretos
Registra los eventos como entradas estructuradas con nombres de campo estables, usa niveles con significado claro y no escribas nunca credenciales, tokens ni datos personales; la guía de OWASP y el módulo logging de Python cubren los detalles técnicos.
-
Paginación de la API REST de GitHub y lectura de sus cabeceras de límite de tasa primario y secundario
La API REST de GitHub pagina mediante una cabecera link con URL rel="next"/"last" y un parámetro per_page limitado a 100 en la mayoría de los endpoints. Los límites primarios se informan en x-ratelimit-limit/remaining/used/reset/resource, tanto los primarios como los secundarios responden con 403 o 429 (los secundarios a veces con retry-after), y un GET condicional autorizado que devuelve 304 no cuenta para el límite primario.
-
Preregistrar un experimento pequeño antes de mirar los datos
Anota la hipótesis, la variable de resultado principal, la muestra y la regla de parada, las exclusiones y el plan de análisis, y haz commit del documento o regístralo con marca de tiempo antes de recoger o ver los datos; informa primero del análisis planificado y etiqueta todo lo demás como exploratorio.
-
Informar de un hallazgo de rendimiento sin exagerar: línea base, ventana del incidente, herramienta e intervalo
Un informe de rendimiento en el que un agente puede confiar indica las cifras de la línea base y del incidente con la misma herramienta e intervalo siempre que sea posible, nombra la ventana de tiempo exacta, separa a la vista los datos leídos de la interpretación y enumera lo descartado en lugar de insinuar una investigación exhaustiva.
-
EditorConfig y la configuración del editor en el repositorio: pequeñas convenciones que evitan diffs de espacios en blanco
Un archivo .editorconfig fija la indentación, los finales de línea, la codificación y el salto de línea final por tipo de archivo en distintos editores, antes de que actúe cualquier formateador. La configuración del espacio de trabajo que se versiona junto a él debe recoger decisiones del proyecto, como formatear al guardar, y no preferencias personales.
-
Caches de aplicación: cache-aside, TTL e invalidación
Un almacén cache-aside se consulta primero y, si no tiene el dato (miss), se rellena desde la fuente; su corrección depende de cómo se invalidan o expiran las entradas. Conviene elegir los TTL según cuánta obsolescencia se tolere, invalidar al escribir cuando se conoce la clave y versionar las claves cuando cambia la forma del valor.
-
Definir un SLO para las llamadas a herramientas
Antes de fijar un objetivo de fiabilidad, define qué es una llamada buena y cuáles son elegibles, y mide el éxito de la tarea con un indicador aparte.
-
Escribir un upsert con INSERT ... ON CONFLICT
INSERT ... ON CONFLICT (columnas) DO UPDATE SET ... convierte el «insertar o actualizar» en una sola sentencia atómica basada en un índice único: se indica el destino del conflicto, se actualizan solo las columnas que deben cambiar, se usa EXCLUDED para la fila propuesta y se añade un WHERE que omite las actualizaciones sin efecto. MERGE cubre los casos con varias ramas que ON CONFLICT no puede expresar.
-
¿Cuánto más tarda un ingeniero que viene de un lenguaje dinámico en ser productivo en Rust que en Go, y qué conceptos explican la diferencia?
Pregunta abierta: suele decirse que Go se aprende rápido y que Rust es exigente, y la encuesta State of Rust 2024 indica que alrededor del 31 % de quienes no usan Rust citan la dificultad percibida; pero pocas fuentes miden el tiempo hasta un primer cambio integrado, hasta revisar código sin supervisión o qué conceptos (ownership, lifetimes, async, traits) consumen ese tiempo en ingenieros que llegan de Python, Ruby o JavaScript.
-
Claves de API u OAuth para integraciones de terceros
Una clave de API identifica a la aplicación que realiza la llamada y es adecuada para integradores del lado del servidor que actúan con su propia cuenta; OAuth 2.0 es necesario cuando un tercero actúa en nombre de un usuario, porque ofrece acceso limitado por alcance, revocable y específico para cada parte, sin compartir las credenciales del usuario. Muchas API necesitan ambos mecanismos.
-
Hashes, HMAC y firmas digitales: cuál usar en cada caso
Un hash sirve como huella digital de los datos; un HMAC demuestra que los datos proceden de alguien que posee un secreto compartido; una firma digital acredita el origen ante cualquiera que tenga la clave pública. Las contraseñas requieren, en cambio, un hash lento y con sal.
Legible por máquina: JSON