Тема: tooling
-
Выбор инструмента или навыка моделью решений: Choice для ранжирования, Noul для отказа от выбора
Почему Choice по кандидатам-инструментам отвечает на относительный вопрос «какой подходит лучше всего», а Noul для каждого кандидата — на абсолютный «нужен ли вообще инструмент на этом ходе», и как руководство TypeSafe по предложению навыков сочетает оба типа для каталога из 182 навыков: первый запрос ранжирует все, второй читает трёх лидеров и может отвергнуть их всех.
-
Начальные данные и фикстуры локальных баз: небольшой объём, идемпотентность и версионирование со схемой
Разделяйте справочные данные, нужные везде, примеры для разработки и демонстраций и тестовые данные, создаваемые тестами. Пишите идемпотентное заполнение с upsert по естественным ключам, сохраняйте набор примеров небольшим и именованным, запускайте его после миграций в настройке и CI и никогда не используйте сырые производственные данные на машинах разработчиков.
-
Проектирование конвейера непрерывной интеграции
Конвейер CI должен быть быстрым, выполнять самопроверку и быть одинаковым для каждого изменения: собирайте проект из чистой рабочей копии, поэтапно запускайте линтеры и тесты, явно сообщайте о сбоях и удерживайте общее время достаточно коротким, чтобы люди дожидались результата.
-
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.
-
Автоматическое форматирование и линтинг как командное соглашение
Передача оформления форматтеру, а механических проверок линтеру убирает споры о стиле из ревью; EditorConfig, PEP 8 и инструменты вроде Ruff показывают, как закрепить соглашение в репозитории.
-
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.
-
Самопроверяющийся скрипт первого запуска: bootstrap, doctor и smoke-тест
Одна команда после клонирования даёт рабочую среду либо точный список недостающего и способов исправления: скрипт doctor без изменений проверяет все требования, идемпотентный bootstrap устанавливает только то, чего не хватает по проверкам, а smoke-тест определяет код завершения. CI запускает это с чистой машины, чтобы настройка не устаревала между приходами новичков.
-
Постепенное внедрение типизации в Python с аннотациями типов
Аннотации типов (PEP 484) необязательны и проверяются внешними инструментами, например mypy; их постепенное добавление в код выявляет ошибки интерфейсов и документирует замысел, не меняя поведения во время выполнения.
-
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.
-
Контейнеры разработки: devcontainer.json как воспроизводимая рабочая среда
devcontainer.json описывает контейнер, который редактору, облачному рабочему пространству или исполнителю CI следует собрать для репозитория: образ или Dockerfile, features, перенаправляемые порты, команды жизненного цикла и настройки редактора. Открытая спецификация containers.dev позволяет использовать один файл локально, в размещённых рабочих пространствах и конвейерах, закрепляя инструментарий вместе с кодом, а не на каждом хосте.
-
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.
Машиночитаемо: JSON