Tema: tooling
-
Selecting a tool or skill with a decision model: Choice to rank, Noul to abstain
Why a Choice over candidate tools answers a relative question (which candidate fits best) while a Noul per candidate answers an absolute one (does this turn need a tool at all), and how TypeSafe's skill-suggestion cookbook combines both over a catalogue of 182 skills: one request ranks all, a second reads the top three and may reject all of them.
-
Seed data and fixtures for local databases: small, idempotent and versioned with the schema
Separate reference data (needed everywhere), sample data (development and demos) and test data (created by tests); write the seed as idempotent code with upserts on natural keys, keep the sample set small and named, run it after migrations in both the setup script and CI, and never seed developer machines from raw production data.
-
Designing a continuous integration pipeline
A CI pipeline should be fast, self-testing and identical for every change: build from a clean checkout, run linters and tests in stages, fail loudly, and keep the total time short enough that people wait for it.
-
Keeping CI and local checks identical: one entry point, pinned tools, same container
A check that passes locally should pass in CI and vice versa: define every check once as a named task, pin the toolchain in a committed manifest that both the bootstrap and the pipeline install from, run CI in the same container image as the dev environment, fix locale and timezone, and treat any CI-only failure as a parity bug to eliminate before fixing the symptom.
-
Automated formatting and linting as a team contract
Delegating layout to a formatter and mechanical checks to a linter removes style debates from review; EditorConfig, PEP 8 and tools such as Ruff show how the contract can be encoded in the repository.
-
Konfigurationsformate wählen: JSON, YAML oder TOML
JSON (RFC 8259) ist streng und überall lesbar, kennt aber keine Kommentare; YAML ist gut lesbar, doch unzitierte Werte werden nach Muster typisiert; TOML ist für Konfiguration entworfen, mit Kommentaren, expliziten Typen und Tabellen. Wer die Datei bearbeitet und was sie liest, entscheidet – und jedes Format braucht nach dem Parsen eine Prüfung gegen ein Schema.
-
Checking whether a task wrapper hid the failure of its inner command
Determine whether a reported successful task actually propagated the outcome of the compiler, test runner, or migration command on which success depends.
-
A day-one setup script that verifies itself: bootstrap, doctor, smoke test
One command after cloning either produces a working environment or a precise list of what is missing and how to fix it: a read-only doctor script checks every requirement, an idempotent bootstrap installs only what the checks report missing, and a smoke test decides the exit status; CI runs it from a clean machine so it cannot rot between newcomers.
-
Gradual typing in Python with type hints
Type hints (PEP 484) are optional annotations checked by external tools such as mypy; adding them incrementally to a codebase catches interface mistakes and documents intent without changing runtime behaviour.
-
Choosing a configuration format: JSON, YAML or TOML
JSON is strict and universal but has no comments; YAML is readable but has surprising implicit typing; TOML is explicit and comment-friendly for flat-to-moderate structures. Pick by who edits the file and what parses it.
-
EditorConfig and committed editor settings: the small conventions that stop whitespace diffs
A .editorconfig file fixes indentation, line endings, charset and final newlines per file type across editors, before any formatter runs; editor workspace settings committed next to it should encode project decisions such as format-on-save, not personal preferences.
-
Virtual environments: one interpreter state per project
A virtual environment is a private site-packages tied to an interpreter; creating one per project prevents version conflicts and makes the dependency set reproducible and disposable.
-
Dev containers: devcontainer.json as a reproducible development environment
A devcontainer.json describes the container an editor, cloud workspace or CI runner should build for a repository: image or Dockerfile, features, forwarded ports, lifecycle commands and editor customisations. The open specification at containers.dev makes the same file usable locally, in hosted workspaces and in pipelines, so the toolchain is pinned with the code instead of living on each host.
-
Which pre-commit hooks survive a year in a team repository, and which get removed or routinely bypassed?
Open question: Git's pre-commit hook can be bypassed with --no-verify, so a local hook only helps while contributors keep it; which hook types (formatters, linters, secret scanners, test subsets) have stayed in use for a year or more in team repositories, which were removed or moved to CI, and how often were they bypassed?
-
Git hooks for fast local checks
Client-side hooks such as pre-commit run formatters and quick linters before a commit exists; they save review time but must stay fast, must not be the only gate, and are not versioned by Git itself.
-
Task runners beyond make: just, npm scripts and Invoke for project commands
A task runner gives a project one place for its commands so that people, agents and CI invoke the same names; just stores recipes in a justfile with make-like syntax and no timestamp logic, npm scripts live in package.json with pre and post hooks, and Invoke turns @task functions in a tasks.py into a command line. Pick the one that needs no extra toolchain, keep recipes short, and let CI call them.
Legible por máquina: JSON