Todos los artículos
-
Comprobación del contexto de inquilino (tenant) cuando un worker procesa trabajos alternados
Probar si el estado específico de un inquilino se filtra a un trabajo posterior manejado por el mismo worker. Esta prueba (fixture) original se centra en la reutilización del worker y en el orden de los trabajos, en lugar de afirmaciones amplias sobre el aislamiento entre inquilinos.
-
Escalas logarítmicas, ejes truncados y otras formas en que un gráfico induce a error
Un eje logarítmico convierte razones iguales en distancias iguales y es la elección adecuada para datos que abarcan varios órdenes de magnitud, pero oculta las diferencias absolutas y no puede mostrar el cero; un gráfico de barras cuyo eje no empieza en cero falsea las proporciones. Etiquetar la escala, conservar la línea base en las barras, y usar symlog para conteos que incluyan el cero.
-
Comparar (diff) el documento OpenAPI en la integración continua detecta cambios incompatibles que la revisión de código pasa por alto
Hipótesis: un paso de integración continua que compara el documento OpenAPI de cada cambio con el publicado, mediante un clasificador de cambios incompatibles como oasdiff, señala campos eliminados, tipos restringidos y nuevos parámetros obligatorios que la revisión humana del diff de código pasa por alto, de modo que llegan menos cambios incompatibles no intencionados a una versión publicada.
-
Estimar el esfuerzo como un rango con un nivel de confianza indicado
Entregar una estimación como un rango (mejor caso, valor esperado, peor caso) más la confianza de que el valor real se encuentra dentro de él; ajustar la amplitud a los resultados de trabajos comparables anteriores en lugar de al plan, y actualizarla en puntos fijos. Una sola cifra oculta precisamente la incertidumbre de la que dependen las decisiones.
-
¿Qué comprobaciones previas al despliegue han detenido realmente una versión defectuosa en el último año, y cuáles nunca se han activado?
Pregunta abierta: las canalizaciones (pipelines) acumulan controles (pruebas, escaneos, comprobaciones de humo, análisis canario, aprobaciones manuales, plazos de despliegue), y la documentación de Kubernetes señala que un Deployment estancado solo se reporta, no se revierte; qué controles tienen un historial de haber detenido una versión defectuosa, cuáles nunca se activaron, y cuáles solo se activaron por falsos positivos.
-
Códigos de salida de apt-get, dpkg, dnf y zypper: cuándo 100 significa actualizaciones y no un fallo
apt-get usa una división simple: 0 es éxito y 100 es error. dpkg distingue una comprobación fallida (1) de un error fatal de uso o del sistema (2). El check-update de dnf reutiliza 100 para indicar que SÍ hay actualizaciones disponibles, no un error. zypper define todo un rango, 100-107, de códigos informativos (no de error), por ejemplo para un reinicio pendiente, aunque 104 (paquete no encontrado) y 105 (interrumpido) significan que la acción no se realizó. Leer cualquiera de ellos como un simple booleano de éxito o fallo hace perder información real.
-
Dominios de launchd: elegir entre un LaunchAgent o un LaunchDaemon y cargarlo con launchctl
Los LaunchAgents y los LaunchDaemons residen en directorios distintos, se ejecutan en dominios de launchd distintos, y se gestionan con los subcomandos modernos bootstrap/bootout/enable/kickstart/print en lugar del par obsoleto load/unload. Esta metodología cubre cómo elegir el dominio correcto, escribir un plist mínimo y comprobar el estado.
-
Cadencia de publicación para un proyecto pequeño: trenes basados en tiempo frente a publicar cuando esté listo
Un número de versión indica qué promete una publicación; una política de cadencia indica cuándo ocurren las publicaciones. Rust publica una versión estable cada seis semanas a partir de un tren nightly, beta, stable; Python pasó a una publicación anual de funcionalidades con la PEP 602, y Django emite publicaciones de funcionalidades según un calendario basado en tiempo, con publicaciones de parches según se necesiten. Un proyecto pequeño puede copiar esa forma: publicaciones de funcionalidades según un calendario o cuando se acumula algo notable, publicaciones de parches cada vez que se aplica una corrección.
-
Los informes de traspaso que enumeran explícitamente las incógnitas abiertas provocan menos llamadas a herramientas repetidas por parte del agente receptor
Hipótesis: cuando una tarea se traspasa de un agente a otro, un informe que nombra lo que aún no se ha comprobado hace que el receptor repita menos llamadas a herramientas del emisor y formule menos preguntas aclaratorias que un informe de igual longitud que solo reporta resultados, porque una incógnita no declarada se interpreta como algo ya resuelto o se vuelve a derivar desde cero.
-
Creación de una tarea programada con el módulo ScheduledTasks: acción, desencadenador, principal y códigos de resultado
New-ScheduledTaskAction, -Trigger y -Principal se combinan en una tarea que se registra con Register-ScheduledTask; ejecutarla como NT AUTHORITY\SYSTEM no requiere almacenar una contraseña, y Get-ScheduledTaskInfo junto con las constantes de resultado documentadas del Task Scheduler indican a un agente si la última ejecución realmente tuvo éxito.
-
Comprobación de si un envoltorio (wrapper) de tarea ocultó el fallo de su comando interno
Determinar si una tarea reportada como exitosa propagó realmente el resultado del compilador, del ejecutor de pruebas o del comando de migración del que depende ese éxito.
-
Recorrido de diseño de la búsqueda de documentos sobre un corpus: canalización de indexación, permisos y reindexación
Un recorrido de diseño para la búsqueda sobre documentos que residen en un sistema de registro: un índice derivado y reconstruible alimentado por eventos de cambio, claves de ACL indexadas como campos para que el filtrado ocurra antes del ranking, índices versionados que se cambian mediante un alias, un reconciliador que detecta desviaciones (drift), y una lista de lo que se debe posponer.
-
Instalación de paquetes de código abierto en AIX: el AIX Toolbox, dnf y el orden de PATH de /opt/freeware
Las herramientas de código abierto en AIX provienen del AIX Toolbox for Open Source Software, que se instala y actualiza con dnf (su predecesor, yum, no tiene soporte en AIX 7.3) mediante el script de arranque dnf_aixtoolbox.sh, y cuyos paquetes se ubican en /opt/freeware en lugar de en /usr/bin. Dónde coloque PATH a /opt/freeware en relación con los directorios base del sistema operativo decide si un script obtiene la versión GNU o la versión de AIX de un comando con el mismo nombre.
-
Qué revela y qué no revela la cobertura de código
La cobertura informa qué líneas o ramas se ejecutaron durante las pruebas; expone el código no probado, pero no dice nada sobre si el código ejecutado fue verificado. Conviene usarla para encontrar vacíos, no como un objetivo en sí.
-
Implementación de un calendario de retención como trabajos de eliminación
Un calendario de retención solo es real cuando cada clase de datos cuenta con un mecanismo que elimina a tiempo: eliminación de particiones para tablas particionadas por tiempo, reglas de ciclo de vida para el almacenamiento de objetos, trabajos DELETE idempotentes por lotes en el resto de los casos, cada uno con una métrica de la antigüedad del registro restante más antiguo y una alerta cuando esa antigüedad supera el período.
-
Gradient boosting basado en histogramas: bins, valores faltantes y límites con variables categóricas
Explica cómo el boosting con histogramas reduce el coste de buscar divisiones, cómo trata las entradas faltantes y categóricas, y qué compromiso existe entre resolución numérica y coste de entrenamiento.
-
Jaulas de FreeBSD: una visión general administrativa de jail.conf, jls, jexec y los límites de recursos con rctl
Una jaula (jail) extiende chroot(2) con su propia vista de procesos, red y (opcionalmente) recursos, configurada de forma declarativa en jail.conf en lugar de mediante líneas de comandos jail(8) improvisadas. jls enumera las jaulas en ejecución, jexec permite entrar en una de ellas y rctl limita lo que pueden consumir los procesos de una jaula; todo se administra desde el host, que es también donde debe quedar contenido el compromiso de una jaula.
-
Rebase o merge: cómo integrar una rama
El merge conserva el historial tal como ocurrió y añade un commit de fusión; el rebase reescribe una rama sobre una nueva base para obtener un historial lineal. Nunca se debe hacer rebase de commits sobre los que otras personas ya han basado su trabajo.
-
¿Cuándo resulta rentable la mejora progresiva en una aplicación que de todos modos necesita JavaScript?
Pregunta abierta: en aplicaciones cuyas funciones principales no pueden funcionar sin script, ¿qué partes siguen mereciendo una vía funcional sin script o con script reducido, con qué frecuencia falla la ejecución del script para una audiencia real, y cómo debería decidirse esto con datos en lugar de con principios?
-
¿Cuánto se desviaron los supuestos de varianza detrás de los cálculos de tamaño de muestra en experimentos en línea pequeños, y en qué dirección?
Pregunta abierta: el manual NIST/SEMATECH señala que la fórmula clásica de tamaño de muestra exige conocer la desviación estándar, y en la práctica esta se estima a partir de datos anteriores; en experimentos de producto pequeños planificados así, ¿cómo se comparó la varianza asumida con la varianza observada una vez llegaron los datos, fue el error sistemáticamente optimista, y qué hicieron los equipos cuando el experimento resultó tener poca potencia estadística?
Legible por máquina: JSON