DEV Community: Daniel Wildt

Canônico

Daniel Wildt — Fri, 03 Apr 2026 20:30:58 +0000

Aqui pensando em gramática e jeito de escrever o que fazemos em software.

Em desenvolvimento de software escrever com padrão sempre foi algo importante e diria que quase obrigatório para uma equipe com pensamento de longo prazo.

Em diferentes aspectos, não só na formatação do código fonte, mas também como nomear variáveis e diferentes estruturas nomeadas em um código, como testes automatizados e também de modelo de dados.

Em desenvolvimento de software nos dias atuais, pensar em como fazemos descoberta de um determinado problema e como fazemos construção. No caso de descoberta o que existe de entrada? Documentações, reuniões com clientes (transcrições e desenhos), algum tipo de manual de apoio, relatórios e outras regras de negócio que podem ser usadas como base. E no caso de entrega, todos os padrões que podemos estabelecer para fazer um código fácil de ler, testável e fácil de dar manutenção.

O canônico neste contexto falo sobre construção que acontece conforme normas mais habituais de uma gramática. Tipo existe um jeito fácil de operar e ser. Existem convenções onde tudo flui. Podemos fazer diferente, mas vai gerar mais trabalho.

Manutenção, testabilidade e documentação se tornam informações importantes para atuar com agentes de inteligência artificial. A forma de construção de software vai ser executada conforme padrões já definidos e testados anteriormente.

Estamos em um momento que posso remover o código criado e recriar a partir de uma especificação, sabendo que padrões e que ferramentas serão empregadas para resolver o problema. Se der errado, melhoro a especificação de agentes ou de padrões a serem usados, e construímos novamente.

O jogo mudou. E existe um jeito fluído de fazer acontecer. Ainda existem muitas opções e formas de criar esta padronização. E isso vai depender de equipe, estrutura de trabalho e padrões que desejamos ter.

-- Daniel Wildt

Template para mensagens de commit

Daniel Wildt — Sun, 16 Nov 2025 03:49:49 +0000

Tenho buscado algum tipo de padrão em projetos que tenho criado, mas ao mesmo tempo passo por situações onde estou brincando em projetos diferentes e por vezes testando abordagens diferentes. E não lembro do padrão de mensagem a ser usado.

Em parte estou sempre buscando usar os "conventional commits" mas pensando em diferentes opções. Ter continuidade é um grande problema.

Uma coisa que estou adicionando nos meus repositórios é um template de mensagem de commit.

Exemplo, tenho o arquivo ".gitmessage" no meu repositório, com um conteúdo tipo esse:

# <tipo>: <descrição curta em português>
# |<----  Máximo 72 caracteres  ---->|

# Corpo da mensagem (opcional)
# |<----   Quebre em 72 caracteres   ---->|

# Rodapé (opcional)
# Ex: Relacionado a #123
# Ex: BREAKING CHANGE: descrição da mudança incompatível


# --- TIPOS DE COMMIT ---
# feat:     Nova funcionalidade
# fix:      Correção de bug
# docs:     Documentação
# test:     Adicionar ou modificar testes
# ci:       Integração contínua
# ui:       Interface do usuário
# perf:     Melhoria de performance
#
# --- REGRAS ---
# ✅ Usar verbo no infinitivo (adicionar, corrigir, atualizar)
# ✅ Primeira linha com até 72 caracteres
# ✅ Ser claro e descritivo
#
# ❌ NÃO usar verbos conjugados (adicionado, corrigido)
# ❌ NÃO terminar com ponto final
# ❌ NÃO ser vago ("fix: ajustes")
#
# --- EXEMPLOS ---
# feat: adicionar cálculo de juros compostos
# fix: corrigir validação de campos numéricos
# docs: atualizar README com instruções de instalação

# --- BREAKING CHANGES ---
# Para mudanças incompatíveis, use ! após o tipo:
# feat!: alterar estrutura de retorno da API
#
# E adicione no rodapé:
# BREAKING CHANGE: descrição detalhada da mudança incompatível

Aí faço a configuração para que na mensagem de commit este template seja usado:
git config commit.template .gitmessage

Isso para fazer com que esta mensagem padrão (.gitmessage) seja usada neste repositório em questão.

E aí meu fluxo de trabalho fica assim:

Adiciono os arquivos que vão fazer parte do commit usando git add <arquivo>
Na a hora de adicionar a mensagem, eu simplesmente chamo um "git commit" e vai ser aberto um vim para eu poder editar a mensagem, já tendo a mensagem template para mim.
Faço o push, agora garantindo que a mensagem de commit está de acordo.

-- Daniel Wildt

Mensagem de commit?

Daniel Wildt — Sat, 25 Oct 2025 21:40:43 +0000

Para quem trabalha com Trunk Based Development, pode ser interessante poder olhar a listagem de commits e ter uma visão rápida do que está sendo atualizado na base de código.

Confesso que nos projetos que acompanho, minha lógica é: explique da forma mais objetiva possível o que é este commit. E claro, no contexto que busco trabalhar, sugiro commits pequenos. E frequentes.

Se fosse fazer uma decisão rápida, iria para três prefixos nas mensagens de commit: fix, feat e docs. Fix, olhando defeitos sendo corrigidos. Feat, no olhar de novas funcionalidades ou no caso de partes de novas funcionalidades. E docs, na atualização ou construção de documentação.

Se fosse poder escolher mais duas? Iria de test e ci. Test para indicar melhorias em testes, seja unitários, funcionais ou desempenho. E ci indicando tudo que poderia ser relacionado com melhoria do ciclo de deploy, validações, ferramentas de auditoria, build e deploy.

Agora, dá para ir bem mais longe. Antes de trazer mais exemplos de prefixos da indústria, deixo um exemplo de uma mensagem que poderia ser usada em um commit. Nos projetos pessoais, tenho usado esta:

feat: descrição rápida da funcionalidade closes #2

O meu próximo movimento é adicionar o módulo, pois os projetos vão ficar maiores. Assim consigo posicionar em que parte do código estou evoluindo.

feat(modulo): descrição rápida da funcionalidade closes #2

Agora, dependendo do que você prefere usar, dá para ir mais longe nas mensagens, exemplo:

feat(modulo): descrição rápida da funcionalidade

descrição mais completa da funcionalidade que foi desenvolvida.

closes #2

Nesta estrutura foca o cabeçalho com o tipo, módulo e descrição rápida. O corpo com a mensagem complementar. E o rodapé com a informação de fechamento de uma issue. Poderia também usar no rodapé "BREAKING CHANGE: explicação".

Para entender as opções de tipos de commits, a sugestão é usar como base os conventional commmits. Estas convenções são diretamente inspiradas nas convenções de contribuição do projeto Angular. Lá vão aparecer outras estruturas mais específicas, como build, perf e refactor.

Nos tipos de commit ainda dá para usar o "!" para indicar que está acontecendo uma "breaking change". Uma mudança que normalmente pode impactar o processo de atualização de sistemas. Como tenho preferido usar as mensagens mais curtas, vou pensar no uso de "!".

Que padrões fazem sentido nos seus projetos?

-- Daniel Wildt

P.S.: se você usa ferramentas para apoiar em ações de código, você pode ensinar estas ferramentas sobre os padrões a serem usados. E para padronizar nas equipes, se pode construir gatilhos para validar se a mensagem sendo usada na mensagem de commit segue o padrão esperado.

Copiar só parte de um repositório

Daniel Wildt — Tue, 02 Sep 2025 13:13:42 +0000

Estava fazendo umas provas de conceito e queria iniciar um novo projeto a partir de uma parte de um repositório.

Copiar a pasta simplesmente vai trazer histórico e arquivos de controle git que eu não tenho interesse em trazer.

Temos algumas opções. Uma manual e outra usando o mesmo comando via terminal. Estou usando como exemplo um repositório que tenho para estudar algumas coisas de golang.

Meu objetivo é pegar um conteúdo de um dos testes, chamado "vibe-certificados" e criar um repositório novo só para este projeto.

Vamos aos caminhos possíveis.

Manual

Em qualquer repositório no github a gente consegue fazer download do conteúdo.

Com isso, depois eu vou descompactar o arquivo zip e copio o que preciso para dentro do novo repositório git e estou pronto para seguir.

Git Archive

Existe um comando via terminal (git archive) que podemos fazer para justamente realizar a mesma operação em um repositório git. Aí a forma de conectar depende se seu projeto usa https ou ssh.

O comando recebe um dos remotes, o branch que quero usar, um caminho e já indica que na saída, quero gerar um arquivo tar (compactado).

https:
git archive --remote=https://github.com/dwildt/gosandbox.git main vibe-certificados | tar -x

ssh:
git archive --remote=git@github.com:dwildt/gosandbox.git main vibe-certificados | tar -x

Via curl

curl -L https://github.com/dwildt/gosandbox/archive/main.tar.gz | tar -xz --strip-components=1 gosandbox-main/vibe-certificados

Como o repositório está público, esse comando vai funcionar tranquilamente. E dependendo do que se quer fazer, pode ser mais simples mesmo.

Estou em alguns casos criando alguns templates. Seja de arquivos de configuração ou templates de projetos para iniciar algo de forma mais rápida.

-- Daniel Wildt

Cada equipe tem a sua história e seu caminho. Onde possível, compartilhe.

Daniel Wildt — Fri, 20 Jun 2025 04:09:17 +0000

Quais práticas estão padronizadas na sua equipe? Quais práticas são compartilhadas entre todas equipes? Quais problemas existem hoje na estrutura da equipe? Quais serão as próximas práticas a serem adotadas?

Cada equipe minimamente deve saber falar sobre três itens:

reabastecimento
sincronia
melhoria

O reabastecimento fala sobre priorização e o olhar de conexão de negócio e evoluções técnicas internas. A sincronia envolve alinhamento, das pessoas saberem onde estão e o que está “pegando” com a equipe. Pode ser uma reunião online, atualizações em algum canal de comunicação, como a equipe resolver se organizar. E também melhoria, com alguma cerimônia onde a equipe reflete sobre como está trabalhando e sobre como pode melhorar, seja em questões técnicas ou em processos de trabalho.

A partir disso, as equipes devem entender como vão tratar as diferentes partes do fluxo: priorização de trabalho, análise de negócios pensando em artefatos e técnicas de fatiamento de trabalho e cadências, estratégias de arquitetura e design, estratégias de automação de testes e pipelines de entrega, formas de validação e revisão do trabalho realizado e além disso a liberação de funcionalidades (deploy é diferente de release) para clientes além de entender como o trabalho realizado deve ser medido.

Aí entram ferramentas de apoio para medição de desempenho, carga e outras variáveis de negócio que podem entender sobre a saúde do sistema e do trabalho entregue. Fora isso, ainda existem as preocupações de como a equipe faz para trabalhar com feedbacks e processos de escuta, além das estratégias de aprendizagem.

Entender o funcionamento de uma equipe, independente do tamanho, é algo que pode ser complicado, mas pode ter padrões e expectativas. E o principal: pode ser desafiado, melhorado e aperfeiçoado.

Existe algo que seja comum para todas as equipes? A necessidade de entregar valor, de entregar com frequência, de entregar com qualidade. É uma tarefa de equipe, de responsabilidade individual e coletiva. A equipe deve se importar com o trabalho em andamento e com o trabalho que precisa ser terminado. Lembrar que terminar o que está em andamento é mais importante que iniciar novo trabalho. Ainda mais considerando que o que está em andamento é o trabalho priorizado.

— Daniel Wildt

P.S.: Esse texto faz parte de um handbook que venho documentando faz alguns meses, sobre o que aconteceu na equipe da uMovme desde 2009. Aprendendo e refletindo sobre os diferentes caminhos que a equipe já percorreu, e trazendo aquilo que emerge e persiste no funcionamento das equipes. Esse handbook está se tornando um conjunto de princípios e práticas que a equipe reconhece e desafia no seu trabalho diário.

P.S.2: Foto do artigo, Paths, de Simon Clayson (via Flickr, licença Creative Commons).

Crescimento profissional e a cultura de aprendizagem.

Daniel Wildt — Fri, 12 Jul 2024 17:09:06 +0000

Contexto: texto escrito em 2022

Em 2009 eu inicio uma nova jornada. Apoiar na transformação de uma empresa baseada em projetos e diversos nichos, para uma empresa de produto, construindo um produto (que virou uma plataforma) para embarcar estes nichos.

A jornada nunca é simples quando estamos mudando o foco de serviço para produto. A cobrança não é mais baseada em simplesmente horas de serviço e suporte ao que é entregue. Não é mais simplesmente crescer em clientes, com novos projetos. Trabalhar com produtos envolve encontrar o tal encaixe ("fit") entre produto e mercado. Ganhamos a oportunidade de pensar em algumas coisas com mais força. Exemplo, aprender como posicionar o produto no mercado. E não aceitar mais simplesmente "tirar pedidos" ou "fritar pastéis" para adequar a necessidade de clientes com o projeto contratado.

Eu entendi na época que eu precisava construir um perfil de produto, já que meu foco dos 13 anos anteriores era focado em serviços e projetos e consultoria. Também entendi que não teria chance de fazer isso, se não tivesse uma equipe em aprendizado constante.

Construir projetos baseados no puro interesse de um cliente ainda exige pensamento de priorização e entendimento de como fatiar entregas, mas quem define o alvo está dentro do projeto. Não é o caso do pensamento quando estamos atuando com produto. Vamos descobrir ao longo do tempo clientes importantes, que podemos entrevistar e aprender mais e mais sobre o mercado que eles vivem. Clientes que nos inspiram no jogo de entrega de valor. Só que no final do dia, a atividade de aprendizagem sobre o que fazemos e sobre o que queremos melhorar é nossa responsabilidade.

No caso do pensamento de produto, a construção do futuro do produto precisa de aprendizagem. Viveremos constantemente um pensamento entre certezas, suposições e dúvidas, que serão constantemente desafiadas e atuam na nossa convivência com a incerteza. Precisa de uma equipe constantemente questionando como pode fazer o que faz melhor. Envolve entender este processo tanto tecnicamente como em processos para evolução do produto. Isso conecta com foco de mercado, entendimento de negócios.

Pensei em listar aqui atividades que considerei importante ao longo de 2009 até 2022 nesse pensamento de construção de culturas de aprendizagem, que eu considero como sendo uma das minhas habilidades. E também indicando práticas ligadas com o pensamento de evolução e aprendizado técnico, importante neste jogo de produto.

Em abril/2009 DevOps e Lean Startup estavam nascendo

Eu sabia que falhar o mais rápido possível e aprender mais rápido ainda era uma das únicas oportunidades que tinha neste processo de evoluir equipes e produtos. Criar uma estrutura de apoio para a melhoria, com retrospectivas, espaços técnicos para a equipe se desafiar, também.

Já tinha aprendido também com o meu aprendizado sobre eXtreme Programming, que automação de testes ajudaria a equipe a conseguir evoluir constantemente garantindo a tal coragem necessária para modificar código e saber que ele vai quebrar se algo não estiver ok.

Pelo pensamento Lean, eu sabia que precisava melhorar, encontrar maneiras mais fáceis de produzir software e garantir que uma equipe conseguiria dar manutenção e ensinar pessoas novas a fazer o mesmo.

Também sabia que atuar no desperdício da espera era o meu grande trunfo. Se eu melhorar os tempos de repasse de trabalho nas equipes, consigo aumentar o desempenho delas em muitas vezes.

Em abril de 2009, Eric Ries já tinha cunhado o termo Lean Startup, unindo Lean Thinking + eXtreme Programming + Customer Discovery/Customer Development.

Em 2009 uma palestra chama muita atenção, de uma empresa que eu acompanhava desde o ano anterior. O Flickr tinha uma estrutura no blog de código onde avisavam o que estava acontecendo com relação a updates de código e quem estava fazendo isso.

Eu já era fã fazia tempo e mantinha umas imagens desta época (confesso que elas estavam em uma pasta esquecida, mas eu não tinha esquecido)

Essa palestra, apresentada em junho no Velocity 2009, trouxe uma visão para o mainstream do desenvolvimento de software sobre a nossa capacidade de poder entregar software em produção de forma frequente.

Acho interessante que muitas revoluções relacionadas com a engenharia de software aconteceram em empresas que tiveram reviravoltas com o sucesso. O Flickr passou por diversas jornadas, desde aquisição do Yahoo e depois passando por dificuldades e demissões, até hoje em dia ser um produto em busca de significado. Particularmente gosto do serviço e sou assinante faz algum tempo.

Estes movimentos inspiraram diversas empresas e aqui no Brasil posso dizer que fui bastante influenciado por este tipo de movimento. Deploy contínuo era algo impossível de ser alcançado.

Antes da primeira linha de código, tenha princípios!

Desde cedo eu tinha consciência de alguns princípios que precisava colocar em funcionamento. Alguns relacionados a evolução de código fonte para produção e organização de como podemos gerar valor para clientes.

Eu não tinha dinheiro para contratar uma equipe altamente experiente. Eu precisava compor a equipe existente, aprender novas linguagens de programação ou expandir o uso das linguagens existentes. O mesmo com as práticas de engenharia de software. Sabia o que não queria, no caso de construir um produto no estilo plataforma. E somava nisso todos aprendizados que tive no meu passado mantendo códigos de 10+ anos nos dias atuais.

Testes automatizados, e para quem conseguir, desenvolvimento orientado a testes. Desde muito cedo comecei a trabalhar sessões de Coding Dojo, trazendo para as equipes o ritmo de codificar, evoluir e aprender sobre como modelar cenários de teste.
Trunk Based Development, que muito rapidamente envolve permitir que uma base de código possa ser levada para produção quando for de interesse da equipe. E para que isso possa acontecer precisamos garantir que o código "acordado" esteja com testes passando e o código "dormindo" esteja configurado de forma adequada para não afetar o comportamento de produção. Pensa que nesta época ainda não usávamos sistemas como Git, mas mesmo sendo git eu sigo operando no modelo TBD.
O sistema vai cair. Então como organizamos para que saibamos o que precisa funcionar e como podemos colocar para funcionar.
O sistema pode evoluir sem depender do banco de dados. Muito cedo começamos a aplicar Database refactoring, para garantir que eu poderia evoluir o modelo de dados sem depender da sincronia de instalação de código novo. O mesmo valeria para uma necessidade de rollback de um módulo.
O rollback precisava ser rápido, muito mais rápido que o tempo de instalação. Rollback é só mais uma instalação (deploy).
Uma instalação de código não é igual features novas para clientes. Importante ter uma estrutura de toggles, para habilitar que um cliente tivesse acesso a uma determinada funcionalidade antes de outros clientes, para fins de testes.
O cliente não tem acesso a um ambiente de testes. O teste é em produção. Assim como a bateria de testes chegava em um ambiente de produção, os clientes validavam uma funcionalidade também em produção, no seu próprio ambiente.

Alguns destes princípios levaram bons anos para entrar no fluxo da equipe. Mesmo hoje em 2022 ainda preciso explicar os benefícios de trabalhar com TBD para uma equipe que quer avançar e evoluir código. Assim como preciso ainda explicar os valores do manifesto ágil, sobre a importância de comunicação, de entregar software, de adaptar e manter contato próximo com quem demanda novas evoluções de um produto de software. Sempre lembrando que a coisa mais importante é maximizar o trabalho que não precisa ser feito, a tal simplicidade.

O caminho para a cultura de aprendizagem?

Momentos de aprendizagem, por todos os lados. O aprendizado "on the job", na prática, também. Isso vai desde o processo seletivo até o dia a dia evoluindo alguma funcionalidade de produto.

Se for resumir a base deste processo, é poder operar em dois materiais importantíssimos de Nonaka e Takeuchi:

Transformar conhecimento tácito em conhecimento explícito.
Entender o novo jogo para desenvolvimento de produtos.

Relaciono aqui alguns destes momentos que considero importantes e relevantes para este processo de construção de conhecimento.

Coding Dojo.
Treinamentos internos, palestras e rodas de conversa.
Ambiente de infraestrutura não adequado.
Automação de infra e escala.
Espaços de aprendizagem, criando eventos.
Processo seletivo com toda a equipe.
Operar de forma multimídia, com textos, áudio (podcast na época da trevisan), vídeo

O que mudou nisso tudo em 2022?

Muita coisa. Isso falando no problema de formação de pessoas. Vivemos em um mundo cada vez mais desigual. Se queremos um mundo diferente, precisamos ser intencionais.

Isso inclui remover barreiras para conhecer pessoas. Muitas empresas ainda falam sobre suas estratégias para contratar pessoas somente de melhores universidades do Brasil, pessoas em universidades e esquecem da infinidade de pessoas excelentes em cursos técnicos e pessoas que estão na prática mas não participam de processos de educação formal.

As empresas precisam conectar com comunidades de tecnologia e apoiar onde puderem, patrocinando eventos para unir as pessoas, criando espaços, oferecendo tempo das suas pessoas para palestras e mentorias. As oportunidades são diversas.

E não tente ser a melhor ou a única iniciativa.

Não importa quantas iniciativas sejam criadas sobre aprendizagem e formação de pessoas. Nenhuma delas vai ser suficiente.

Em 2010 o problema já era grande. Em 2022 o problema aumentou de tamanho. E agora está afetando empresas que nem pensavam que esse seria um problema lá em 2010.

O que eu ainda considero que pode nos ajudar, como indústria de tecnologia Brasileira, é operar em uma cultura de aprendizagem, para dentro e para fora das empresas, chegando em instituições de ensino, comunidades e outras empresas.

-- Daniel Wildt

Responsible Services

Daniel Wildt — Sun, 19 May 2024 15:51:59 +0000

I don’t like to use the word accountable when I’m talking in Portuguese. I try to make the word responsible do that work. But… in system and software design I see the word accountable important to make a point.

Usually every system starts with a big giant module that serves webrequests and delivers pages and APIs.

When we are growing, there are parts of the system that will need to respond faster and would need more characteristics of resilience.

Thinking of that, the first split I would run into a system already in production would be that. I split and then I can scale a specific part.

When doing that, the number of requests may also ask for asynchronous communication in some of the operations. We are going to understand the cost of some components. We are going to need a readonly data store. Or a cache system. That will help us to serve information, even knowing it can be a little bit outdated.

If you are building a system that works like a workflow, map it as a workflow, and you can use queues for producer/consumer structures to make sure you are doing the correct handoff.

If you break because of a non functional requirement, you will be fine. You have the data, you have the understanding of why you split a service in the first place. We are going to talk about requests per second, concurrent active users and metrics that will make us think about split, cache, async, background processing and things like that.

That’s just our systems growing and at the same time, we thinking about ways to not spend a lot of money (because that’s always an option if the money is not yours 🫠).

What we don’t want:

If you are modeling a system, think about how people will be able to maintain all those modules and think about structures that will enable troubleshooting when needed:

Logs (make sure you have an unique ID where you can follow an item through your workflow)
Audit (who changed what and when and where) so you can understand policies break or even some sort of fraud. And all those items I added up are sort of a journey, a process. Most systems are lacking some part of it, or need enhancements. That’s ok. The important thing is to understand that something is missing.

-- Daniel Wildt

P.S.: There are structures like 12 factor apps. There are performance and load tests, that will help you understand fragile parts of your system. Make use of them. Prepare for the worst. Understand when you are going to focus on some part of your system (considering you are a normal human + copilot team where you don’t have all the time you need).

Consider to follow, engage and sponsor my writing journey. Check my project at patreon.com/dwildt and become part of my special audience!

How To Feel Safe While Modifying Code?

Daniel Wildt — Wed, 08 May 2024 02:08:05 +0000

Every time someone is updating a codebase, there’s this old saying from eXtreme Programming that we are doing it with value of courage.

But that’s not just guts to do something.

And by the way, the safe way of modifying code is finding ways to not modify the code. 🫠

If that’s not the case, let’s continue.

The courage comes from safety. The understanding that we have a set of automated tests that works as a safety net.

I modify existing code adding a new scenario that will fail when I run it against the codebase. If it gets red, I’m free to change the behavior. When I do it correctly, I will get a green with tests passing again. Now I’m free to refactor and change structure, without changing the behavior.

It’s pure Test Driven Development (TDD) red-green-refactor cycle.

This is also a cycle that gives me courage to keep going, if I need to add new business rules to the current code.

But, what if there’s no automated tests in place?

We can create a “thin ice” like set of tests, just to help us in the process. We can also look for a pair programming session with someone who knows about the codebase.

Maybe an exploratory test session can help us understand how the addition will affect other parts of the system, since we only have a small part of the system covered with automated tests.

Make sure you are also adding lints and other code audit tools to help you understand about code health. Tools like drTools or Sokrates can help us a lot, depending on the programming language in use.

-- Daniel Wildt

xcrun: Error: Invalid Active Developer Path?

Daniel Wildt — Fri, 26 Apr 2024 01:32:41 +0000

It’s xcrun not scrum… but some people will say both are not good things to come across in life. 😛

Well, after you update your Mac OS this error may show up when you try to use git:

xcrun: error: invalid active developer path (/Library/Developer/CommandLineTools), missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrun

The way to solve this problem is to run the command to install command line tools:

xcode-select --install

-- Daniel Wildt

Filters to never forget on github (using dates)

Daniel Wildt — Tue, 12 Mar 2024 13:45:07 +0000

When I'm working on github, sometimes I'm analyzing issues and looking for specific dates.

And I keep going back to then documentation to remember how to run filters, or I use some saved URLs I have on my computer. But last time I needed this I was not in my computer and well, that's the trigger to create a blog post so I can't forget how to make date filters using github.

To see issues created on March 1st, 2024:
created:2024-03-01

To see issues created after March 1st, 2024:
created:>=2024-03-01

We can use >, <, <=, >=.

I then, I got a problem. I've wanted to see issues created during February 2024. We can use .. to set a "between":
created:2024-02-01..2024-02-29

I'm using created, but I can also use other parameters like updated and closed where it's possible to filter issue dates.

In the example I'm running now, if I need open issues from February, this is the filter:
is:issue is:open created:2024-02-01..2024-02-29

Remember that this can also go to the URL:
https://github.com/<ORG>/<REPO>/issues?q=is:issue is:open created:2024-02-01..2024-02-29

Let's go!

-- Daniel Wildt

Articles to read - Week 34/2023

Daniel Wildt — Thu, 24 Aug 2023 20:16:48 +0000

Here are some of the articles I've read and want to keep track.

You have logs, I guess. How can you understand what's happening? Read every error. You can't read every error -- Matt Basta
Have you ever heard about RBAC x ABAC? I was trying to understand how to play with different roles or access level when building information systems. Do you use any framework that helps when configuring or building this in your systems? Please share!
You are a software developer like me, right? Do you develop products and maintain and keep all happening with security standards? I was reading more about CISO e security topics. The CISO’s Guide to Data Loss Prevention: DLP Strategy Tips, Quick Wins, and Myths to Avoid.
How can we move to a place where we are able to evolve as we are learning from our practice and our principles and values? Prescriptive Agile / Stuck in Shu.

-- Daniel Wildt

P.S.: If you would like to suggest articles for me, please feel free to do it!

Oooops... errei no git.

Daniel Wildt — Mon, 07 Dec 2020 16:05:54 +0000

Por vezes a gente erra operando os comandos do git. Aqui relaciono algumas situações que passei e estou documentando aqui para eu me lembrar sobre o que fazer quando errar novamente. :P

Errei a mensagem do commit!

É o uso do amend. Imagina que você fez um commit e deixou um typo na mensagem. Neste caso a gente manda um novo commit indicando --amend e indicando a nova mensagem usando -m. Estrutura do comando:

git commit --amend -m "nova mensagem"

Adicionei arquivos errados!

Aqui imaginando que você fez git add mas acabou adicionando arquivos que não deveria ter adicionado e se ligou só depois de fazer o commit. Você consegue desfazer este commit e deixar os arquivos modificados usando:

git reset --soft HEAD~1

Este --soft é muito importante. Ele que indica que os arquivos ficam localmente modificados.

DICA/CUIDADO 1: se você usar --hard você não só desfaz o commit como ainda volta os arquivos para o estado original. Este tipo de comando eu utilizo quando estou brincando com baby steps game em um coding dojo, e depois de passar o tempo do ciclo, todo código que não foi feito push precisa voltar para o estado original do início do ciclo.

DICA/CUIDADO 2: se ao invés de indicar HEAD~1 você identificar um ID de commit, exemplo "Commit1", o git vai voltar para este commit no seu tempo e todos os commits a frente (Commit2 e Commit3) vão se perder. Então exige bastante cuidado (e um bom motivo :P) estas voltas na linha do tempo:

Commit1 -> Commit2 -> Commit3 | main/HEAD

Quais comandos você já precisou para salvar o seu dia por aí? :P

-- Daniel Wildt

P.S.: querendo uma dica de FAQ de git? Olha por exemplo o git tower. Se tiver outros, sugere aí!

P.S.2: imagem do post disponível no flickr.