Tema: tooling
-
Elegir una herramienta o skill con un modelo de decisión: Choice para ordenar, Noul para abstenerse
Por qué un Choice sobre las herramientas candidatas responde a una pregunta relativa (cuál candidato encaja mejor) mientras que un Noul por candidato responde a una pregunta absoluta (si este turno necesita una herramienta en absoluto), y cómo el cookbook de sugerencia de skills de TypeSafe combina ambos sobre un catálogo de 182 skills: una solicitud las ordena todas, una segunda lee las tres mejores y puede rechazarlas todas.
-
Datos semilla y fixtures para bases de datos locales: pequeños, idempotentes y versionados junto con el esquema
Separar los datos de referencia (necesarios en todas partes), los datos de ejemplo (para desarrollo y demostraciones) y los datos de prueba (creados por los propios tests); escribir la siembra como código idempotente con upserts sobre claves naturales, mantener el conjunto de ejemplo pequeño y nombrado, ejecutarla después de las migraciones tanto en el script de configuración como en la integración continua, y no sembrar nunca las máquinas de desarrollo con datos de producción sin anonimizar.
-
Diseñar un pipeline de integración continua
Un pipeline de CI debería ser rápido, autocomprobable e idéntico para cada cambio: compilar desde un checkout limpio, ejecutar linters y pruebas por etapas, fallar con claridad, y mantener el tiempo total lo bastante corto para que se espere a que termine.
-
Mantener idénticas las comprobaciones locales y las de CI: un único punto de entrada, herramientas fijadas, el mismo contenedor
Una comprobación que pasa localmente debería pasar en CI y viceversa: definir cada comprobación una sola vez como una tarea con nombre, fijar la cadena de herramientas en un manifiesto versionado del que instalen tanto el arranque como el pipeline, ejecutar CI en la misma imagen de contenedor que el entorno de desarrollo, fijar la configuración regional y la zona horaria, y tratar cualquier fallo exclusivo de CI como un defecto de paridad que eliminar antes de corregir el síntoma.
-
El formateo y el linting automatizados como contrato de equipo
Delegar el formato en un formateador y las comprobaciones mecánicas en un linter elimina los debates de estilo de la revisión; EditorConfig, PEP 8 y herramientas como Ruff muestran cómo puede codificarse el contrato en el repositorio.
-
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.
-
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.
-
Un script de configuración para el primer día que se verifica a sí mismo: bootstrap, doctor y smoke test
Un único comando tras clonar el repositorio produce un entorno funcional o una lista precisa de lo que falta y cómo corregirlo: un script doctor de solo lectura comprueba cada requisito, un bootstrap idempotente instala solo lo que las comprobaciones señalan como ausente y un smoke test determina el código de salida. La CI lo ejecuta desde una máquina limpia para que no se deteriore entre una incorporación y otra.
-
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.
-
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.
-
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.
-
Entornos virtuales: un estado del intérprete por proyecto
Un entorno virtual es un site-packages privado asociado a un intérprete; crear uno por proyecto evita conflictos de versiones y hace que el conjunto de dependencias sea reproducible y desechable.
-
Dev containers: devcontainer.json como entorno de desarrollo reproducible
Un archivo devcontainer.json describe el contenedor que un editor, un espacio de trabajo en la nube o un ejecutor de CI debe construir para un repositorio: imagen o Dockerfile, features, puertos reenviados, comandos de ciclo de vida y personalizaciones del editor. La especificación abierta de containers.dev permite usar el mismo archivo en local, en espacios de trabajo alojados y en pipelines, de modo que la toolchain queda fijada junto al código en lugar de depender de cada host.
-
¿Qué hooks de pre-commit siguen en uso tras un año en un repositorio de equipo y cuáles se eliminan o se omiten de forma habitual?
Pregunta abierta: el hook pre-commit de Git se puede omitir con --no-verify, así que un hook local solo sirve mientras los colaboradores lo mantengan. ¿Qué tipos de hook (formateadores, linters, escáneres de secretos, subconjuntos de pruebas) siguen en uso al cabo de un año o más en repositorios de equipo, cuáles se eliminaron o pasaron a CI y con qué frecuencia se omitieron?
-
Git hooks para comprobaciones locales rápidas
Los hooks del lado del cliente, como pre-commit, ejecutan formateadores y linters rápidos antes de que exista el commit. Ahorran tiempo de revisión, pero deben ser rápidos, no pueden ser la única barrera de control y Git no los versiona por sí mismo.
-
Ejecutores de tareas más allá de make: just, npm scripts e Invoke para los comandos de un proyecto
Un ejecutor de tareas reúne en un solo lugar los comandos de un proyecto, de modo que personas, agentes y CI invocan los mismos nombres. just guarda recetas en un justfile con sintaxis parecida a make y sin lógica de marcas de tiempo; los npm scripts viven en package.json con hooks pre y post; Invoke convierte las funciones @task de un tasks.py en una línea de comandos. Conviene elegir el que no requiera herramientas adicionales, mantener las recetas cortas y dejar que CI las llame.
Legible por máquina: JSON