Tema: tooling
-
Selecionar uma ferramenta ou skill com um modelo de decisão: Choice para ordenar, Noul para se abster
Por que um Choice sobre ferramentas candidatas responde a uma pergunta relativa (qual candidata serve melhor), enquanto um Noul por candidata responde a uma pergunta absoluta (este turno precisa mesmo de uma ferramenta), e como o cookbook de sugestão de skills da TypeSafe combina os dois sobre um catálogo de 182 skills: um pedido ordena todas, e um segundo lê as três primeiras e pode rejeitá-las todas.
-
Dados de seed e fixtures para bancos de dados locais: pequenos, idempotentes e versionados junto com o esquema
Separe dados de referência (necessários em todo lugar), dados de exemplo (desenvolvimento e demos) e dados de teste (criados pelos próprios testes). Escreva o seed como código idempotente com upserts em chaves naturais, mantenha o conjunto de exemplo pequeno e nomeado, execute-o após as migrations no script de setup e no CI, e nunca popule máquinas de desenvolvimento com dados brutos de produção.
-
Como projetar um pipeline de integração contínua
Um pipeline de CI deve ser rápido, testar a si mesmo e ser idêntico para toda mudança: compilar a partir de um checkout limpo, executar linters e testes em etapas, falhar de forma visível e manter o tempo total curto o bastante para que as pessoas esperem pelo resultado.
-
Manter verificações locais e de CI idênticas: um único ponto de entrada, ferramentas fixadas e o mesmo contêiner
Uma verificação que passa localmente deve passar no CI e vice-versa: defina cada verificação uma só vez como uma tarefa nomeada, fixe a toolchain num manifesto versionado do qual o bootstrap e o pipeline instalam, execute o CI na mesma imagem de contêiner do ambiente de desenvolvimento, fixe locale e fuso horário, e trate qualquer falha exclusiva do CI como um bug de paridade a eliminar antes de corrigir o sintoma.
-
Formatação e linting automatizados como contrato da equipe
Delegar o layout a um formatador e as verificações mecânicas a um linter tira as discussões de estilo do code review; EditorConfig, PEP 8 e ferramentas como o Ruff mostram como codificar esse contrato no repositório.
-
Como escolher um formato de configuração: JSON, YAML ou TOML
JSON (RFC 8259) é estrito e legível em qualquer lugar, mas não admite comentários; YAML é fácil de ler, porém valores sem aspas têm o tipo inferido com base em padrões; TOML foi projetado para configuração, com comentários, tipos explícitos e tabelas. Quem edita o arquivo e o que o lê determinam a escolha, e todo formato precisa de validação contra um esquema após o parsing.
-
Como verificar se um wrapper de tarefa escondeu a falha do comando interno
Permite determinar se uma tarefa reportada como bem-sucedida realmente propagou o resultado do compilador, do executor de testes ou do comando de migração de que o sucesso depende.
-
Script de configuração do primeiro dia que se verifica sozinho: bootstrap, doctor e smoke test
Um único comando após o clone produz um ambiente funcional ou uma lista precisa do que falta e de como corrigir: um script doctor somente leitura verifica cada requisito, um bootstrap idempotente instala apenas o que as verificações apontam como ausente e um smoke test define o status de saída. O CI executa tudo a partir de uma máquina limpa, para que o script não se deteriore entre um recém-chegado e outro.
-
Tipagem gradual em Python com type hints
Type hints (PEP 484) são anotações opcionais verificadas por ferramentas externas, como o mypy. Adicioná-las aos poucos a uma base de código detecta erros de interface e documenta a intenção, sem alterar o comportamento em tempo de execução.
-
Como escolher um formato de configuração: JSON, YAML ou TOML
JSON é estrito e universal, mas não permite comentários; YAML é legível, porém tem uma tipagem implícita que surpreende; TOML é explícito e aceita comentários, adequado a estruturas planas ou moderadamente aninhadas. A escolha depende de quem edita o arquivo e do que o interpreta.
-
EditorConfig e configurações de editor versionadas: pequenas convenções que evitam diffs de espaços em branco
Um arquivo .editorconfig define indentação, fim de linha, charset e quebra de linha final por tipo de arquivo em diferentes editores, antes de qualquer formatador rodar; as configurações de workspace do editor versionadas junto dele devem registrar decisões do projeto, como formatar ao salvar, e não preferências pessoais.
-
Ambientes virtuais: um estado de interpretador por projeto
Um ambiente virtual é um site-packages privado associado a um interpretador; criar um por projeto evita conflitos de versão e torna o conjunto de dependências reproduzível e descartável.
-
Dev containers: o devcontainer.json como ambiente de desenvolvimento reproduzível
Um devcontainer.json descreve o contêiner que um editor, um workspace na nuvem ou um runner de CI deve construir para um repositório: imagem ou Dockerfile, features, portas encaminhadas, comandos de ciclo de vida e personalizações do editor. A especificação aberta em containers.dev permite usar o mesmo arquivo localmente, em workspaces hospedados e em pipelines, de modo que o toolchain fica fixado junto com o código em vez de depender de cada máquina.
-
Quais hooks de pre-commit duram um ano em um repositório de equipe, e quais são removidos ou rotineiramente ignorados?
Pergunta em aberto: o hook pre-commit do Git pode ser ignorado com --no-verify, então um hook local só ajuda enquanto os contribuidores o mantêm; quais tipos (formatadores, linters, scanners de segredos, subconjuntos de testes) permaneceram em uso por um ano ou mais em repositórios de equipe, quais foram removidos ou movidos para o CI, e com que frequência foram ignorados?
-
Git hooks para verificações locais rápidas
Hooks do lado do cliente, como o pre-commit, executam formatadores e linters rápidos antes de o commit existir; poupam tempo de revisão, mas precisam ser rápidos, não podem ser a única barreira e não são versionados pelo próprio Git.
-
Task runners além do make: just, npm scripts e Invoke para comandos de projeto
Um task runner reúne os comandos de um projeto em um só lugar, para que pessoas, agentes e CI executem os mesmos nomes. O just guarda receitas em um justfile com sintaxe parecida com a do make e sem lógica de timestamps, os npm scripts ficam no package.json com hooks pre e post, e o Invoke transforma funções @task de um tasks.py em linha de comando. Escolha o que não exige toolchain extra, mantenha as receitas curtas e deixe o CI chamá-las.
Legível por máquina: JSON