Forem: Weverton Timoteo

Defining active menu item in Phoenix Framework through Short-circuit Evaluation

Weverton Timoteo — Sat, 30 Dec 2023 01:50:00 +0000

Ler versão em pt-BR

When developing web applications, marking menu items, tabs, or other parts of the user interface as active is a common need. In the Phoenix Framework, doing this quickly might lead you to something like this:

<.link
  href={~p"/stores/#{@store}/products"}
  class={"tab" <> if @active == :products, do: " tab-active", else: ""}
>
  Products
</.link>

In this approach, we use ternary expressions and string concatenation to conditionally define CSS classes. It works, but as conditional logic increases, it can become challenging to read and maintain.

Introducing Short-circuit Evaluation

In Elixir, lazy evaluation and short-circuit evaluation are often used interchangeably. However, there's a slight difference. Lazy evaluation is usually associated with more complex data structures, while short-circuit is more common in boolean expressions. And that's what we're going to use.

Let's look at some examples using iex:

list = ["plataformatec", nil, "sourcelevel", false, "dashbit"]
#=> ["plataformatec", nil, "sourcelevel", false, "dashbit"]

# Using short-circuit evaluation on the list
list = ["plataformatec", nil && "sourcelevel", false && "dashbit"]
#=> ["plataformatec", nil, false]

In the second definition of the list, we are using a short-circuit operation, where the last value of the expression prevails when the previous one is true; otherwise, the previous value is retained.

In simple terms, it's like telling Elixir: "stop thinking as soon as you know the answer."

Applying Short-circuit to the CSS Class List

In a Phoenix Framework issue #276, an approach using lazy evaluation for the class syntax was discussed. In this comment, it was clarified that if the list item is false or nil, it will be removed. We can apply this solution to our example:

<.link
  href={~p"/stores/#{@store}/products"}
  class={["tab", @active == :products && "tab-active"]}
>
  Products
</.link>

If @active is :products, the string "tab-active" will be added to the list (resulting in tab tab-active), otherwise, it will be omitted (resulting in just tab). This approach is cleaner, more readable, and efficient:

Code Conciseness: The lazy evaluation syntax is more concise, resulting in cleaner code.
Efficiency: Lazy evaluation halts evaluation as soon as the result is known, avoiding unnecessary evaluations.
Readability: The class list is easy to understand and maintain, improving code readability.
Ease of Maintenance: The simplified syntax makes code maintenance easier over time.

When developing applications in Elixir, it's not just about using the functional paradigm, but also about writing concise and easily understandable code. This approach not only simplifies our code but also makes maintenance more straightforward and direct. 😎✨

Definindo item ativo no menu no Phoenix Framework usando Short-circuit Evaluation

Weverton Timoteo — Sat, 30 Dec 2023 01:32:00 +0000

Read en-US version

Ao desenvolver aplicações web, muitas vezes precisamos marcar itens de menu, abas ou outras partes da interface do usuário como ativos. No Phoenix Framework, fazendo isso de forma rápida, pode ser que você chegue nesse resultado:

<.link
  href={~p"/lojas/#{@store}/produtos"}
  class={"tab" <> if @active == :products, do: " tab-active", else: ""}
>
  Produtos
</.link>

Nessa abordagem, usamos expressões ternárias e concatenação de strings para definir classes do CSS condicionalmente. Funciona, mas conforme a lógica condicional aumenta, isso pode ficar difícil de ler e manter.

Apresentando o Short-circuit Evaluation

No Elixir, lazy evaluation e short-circuit evaluation muitas vezes são usadas de forma intercambiável. No entanto, há uma pequena diferença. A lazy evaluation geralmente é associada a estruturas de dados mais complexas, enquanto o short-circuit é mais comum em expressões booleanas. E é isso que iremos usar.

Vamos dar uma olhada em alguns exemplos usando o iex:

list = ["plataformatec", nil, "sourcelevel", false, "dashbit"]
#=> ["plataformatec", nil, "sourcelevel", false, "dashbit"]

# Utilizando o short-circuit evaluation na lista
list = ["plataformatec", nil && "sourcelevel", false && "dashbit"]
#=> ["plataformatec", nil, false]

Na segunda definição da lista, estamos usando uma operação de short-circuit, onde o último valor da expressão prevalece quando o anterior é verdadeiro; caso contrário, o valor anterior é mantido.

Em termos simples, é como dizer ao Elixir: "pare de pensar assim que souber a resposta".

Aplicando short-circuit na lista de classes do CSS

Numa issue do Phoenix Framework #276, foi discutida uma abordagem usando a lazy evaluation para a sintaxe das classes. Nesse comentário, ficou claro que, se o item da lista for false ou nil, ele será removido. Podemos aplicar essa solução ao nosso exemplo:

<.link
  href={~p"/lojas/#{@store}/produtos"}
  class={["tab", @active == :products && "tab-active"]}
>
  Produtos
</.link>

Se @active for :products, a string "tab-active" será adicionada à lista (ficando tab tab-active), caso contrário, ela será excluída (ficando apenas tab). Essa abordagem é mais limpa, legível e eficiente:

Concisão de Código: A sintaxe da lazy evaluation é mais concisa, resultando em código mais limpo.
Eficiência: A lazy evaluation interrompe a avaliação assim que o resultado é conhecido, evitando avaliações desnecessárias.
Legibilidade: A lista de classes é fácil de entender e manter, melhorando a legibilidade do código.
Facilidade de Manutenção: A sintaxe simplificada facilita a manutenção do código ao longo do tempo.

Ao desenvolver aplicações em Elixir, não basta usar o paradigma funcional, mas também escrever código conciso e fácil de entender. Essa abordagem não apenas simplifica nosso código, mas também torna a manutenção mais fácil e direta. 😎✨

Cleaning your working directory in Git (including untracked files) 😎

Weverton Timoteo — Fri, 03 Nov 2023 20:08:49 +0000

Have you ever found yourself in a Git repo mess with unwanted files and changes piling up? Don't sweat it; we've got your back! Let's roll up our sleeves and learn how to clean things up and get back to coding in style. Plus, we'll show you some cool Git tricks along the way! 😄

Step 1: Clear Out the Clutter 🧹

Git's clean command is like your personal repo janitor. It sweeps away all those pesky untracked files and directories. Open your terminal and head to your Git playground. Then, hit it with this command:

git clean -f -d

Here's the lowdown on the command:

git clean: The cleanup wizard.
-f: The "force" flag. It means we're going all-in on the cleanup without asking too many questions.
-d: The "directories" flag. This tells Git to clean up directories along with files, so you get a squeaky-clean workspace.

Step 2: Say Goodbye to Local Changes ✌️

With the clutter gone, you might still have some local changes you want to ditch. We're gonna use the checkout command to give those changes a one-way ticket out of your repo:

git checkout .

This command throws away local changes and brings your repo back to the way it was when you last committed. Fresh start, anyone? 🚀

Bonus: Get Interactive! 💡

Now, for the cherry on top: Git's interactive mode. It's like a toolbox full of magic wands for precise cleaning. Let's break it out and see the sparks fly:

git clean -i

🔮 Poof! You're in Git's interactive menu. This menu is where the real fun begins. It gives you the power to choose which untracked files or changes stay and which ones go. It's like cleaning with a fine-toothed comb.

And there you have it! Your Git repo is looking sharp and ready for more epic coding adventures. Just remember to keep your valuable changes safe before you unleash Git's cleanup magic.

Cleaning up your Git repo doesn't have to be a chore. With Git's clean and checkout commands, along with the bonus interactive mode, you're in control. Keep your repo organized and fresh, and you'll be coding like a pro in no time! 💻🚀

Anotando: Plugins da comunidade que utilizo no Obsidian

Weverton Timoteo — Mon, 09 Oct 2023 15:23:25 +0000

Na postagem passada, eu mostrei quais plugins embutidos do Obsidian eu deixo ligado e porquê. Agora é a hora de começar a montar o restante do fluxo de anotações utilizando os plugins da comunidade.
Todos que eu vou mostrar nessa lista estão disponíveis no GitHub. Para instalar qualquer um deles, basta abrir as preferências do Obsidian (Cmd + ,) > Community Plugins e clicar no botão Browse.
Você também pode utilizar essa página para descobrir alternativas aos que eu vou mostrar aqui.

Advanced tables

Adiciona diversas melhorias para navegar e manipular tabelas. É possível criar tabelas em Markdown utilizando a seguinte estrutura:

| Nome     | Descrição  |
| -------- | ---------- |
| Weverton | Autor      |
| Fulano   | Leitor     |

Como você pode perceber, é muito comum aparecer um valor com um texto mais longo que alguma célula existente, se isso acontecer, todas as colunas precisariam ser ajustadas (o mesmo aconteceria se alguma coluna precisasse ser adicionada ou renomeada).
Com esse plugin é possível:

formatar alinhamento do texto
mover células (cima, baixo, direita e esquerda)
adicionar linhas ou colunas
ordenar por ordem alfabética ou uma função personalizada
exportar para CSV

Exemplo de uso:

Por mim, só de não precisar ficar editando manualmente esses espaços, já vale o uso da extensão!

Advanced URI

Permite você controlar várias funcionalidades do Obsidian apenas abrindo algumas URIs, como tudo é texto você não precisa ficar utilizando o mouse ou atalhos de teclado.
Acho ótimo para automatizar o workflow, como:

abrir, editar ou criar arquivos
abrir workspaces
navegar para títulos dentro do arquivo (como um sumário ou uma página index para determinada categoria) A lista completa de ações está disponível aqui.

cMenu

Algumas vezes você só quer selecionar o texto e formatar de maneira rápida, mas, para quem está começando com o Markdown, pode ser desafiador memorizar todos os marcadores de formatação. Eu mesmo, dificilmente, vou lembrar como fazer algo como 2² no dia-a-dia.
Só de utilizar a barra de ferramentas do plugin consigo ver que se trata de um 2<sup>2</sup>, por exemplo.

Dataview

Uso para organizar algumas notas como se fosse um "banco de dados", por exemplo, para listar todas as notas de determinada pasta para formar minha página "Wishlist do Nintendo Switch".
É ótimo para organizar também tasks e notas com algumas tags específicas, no README do projeto existem diversos exemplos com diversas aplicações.

Find orphaned files and broken links

Eu sou do tipo de pessoa que gosta de linkar tudo. Assim consigo ter um backlink super completo das notas que eu visito. Então, sempre que sobra um tempinho ou quando revisito uma nota antiga, acabo dando uma olhada se não existe nenhum arquivo vazio ou sem link para ele.

Highlightr

Utilizando a técnica que eu descrevi no primeiro blog post dessa série, quando eu compilo alguma leitura ou algum texto que preciso sintetizar, utilizo o negrito para as partes mais importantes e utilizo esse plugin para marcar com uma espécie de marca texto o destaque do destaque. Assim consigo obter aquele ideal de abrir uma nota e em até 30 segundos extrair toda info necessária dela (via dica do livro Criando um Segundo Cérebro).

Icon Folder

Apenas para dar uma melhorada na aparência da minha sidebar, com esse plugin consigo adicionar ícones para os ítens do topo da árvore de diretórios. Não utilizo para subitems para evitar que eu gere muita poluição visual ao navegar pelas subpastas e me perder na semântica de cada uma delas.

Image Toolkit

Infelizmente, ao abrir ou linkar uma imagem no Obsidian, não é possível dar zoom nela. Esse plugin não só adiciona um lightbox para toda imagem linkada, como também dá a opção de redimensionar, editar, aplicar filtros e até girar a imagem. Recomendo seu uso, principalmente se você adiciona muitas imagens e excedem a largura do que é considerado legível, assim você redimensiona a imagem e se precisar ver mais detalhes basta clicar nela.
Para diminuir o tamanho de uma imagem no Markdown, você pode utilizar essa sintaxe:

![|500](link_para_imagem.jpg)

O |500 dentro da "descrição" da imagem, indica para o Markdown, limitar a imagem para 500px de largura.

Obsidian Memos

Esse plugin cobriu muito bem a função de Journaling para mim. Acho muito prático para já adicionar timestamps nas minhas anotações daquele dia sem precisar abrir o dia atual e fazê-lo manualmente.
Além disso, sou incentivado a anotar na estrutura de bullet points, parecido com o Logseq. Acho bacana porque de brinde acabo ganhando a feature de azulejos verdes do GitHub:

Obsidian TODOs | Text-based GTD

Indo na contramão da recomendação, tenho alguns "TODOs" no meu sistema de notas, mas geralmente esses TODOs são coisas que eu gostaria de fazer um dia e que não me impactam caso eu não os faça. Como, por exemplo, ideias de blog posts para escrever.
O plugin permite ter um rastreamento de todos os TODOs que eu possuo no meu sistema de notas. O que é bacana porque eu também ganho uma área na sidebar da direita para visualizar todas as tarefas que citei na nota que eu estou editando/visualizando.

Remotely-save

Citei esse plugin no primeiro blog post também: com ele você consegue sincronizar suas notas utilizando o S3, Dropbox, OneDrive e etc. É uma ótima alternativa se você não quer pagar pelo serviço Obsidian Sync.
Algumas pessoas relataram que utilizam Git para armazenar suas notas em algum repo, acho bem vantajoso pelo controle que conseguimos ter no versionamento das notas. Não tomei esse caminho porque não gostaria de adicionar um overhead para manter meu sistema de notas precisando fazer um commit para cada anotação que eu faço. Caso contrário, perderia a praticidade de simplesmente anotar e deixar o sync acontecer tanto no Desktop quanto no mobile.

Super Simple Time Tracker

Para algumas tarefas, consigo ter mais foco quando coloco um timer, ter isso no sistema de notas, não só documenta no que eu trabalhei no dia (bem útil para freelancers) como também me permite gerir melhor as pausas, caso eu queira utilizar alguma técnica como o Pomodoro.
Recomendo utilizar esse plugin caso você precise desse tipo de rastreamento nas atividades durante o dia, costumo usar combinado com o plugin Obsidian memos porque consigo manter os timers dentro das notas diárias onde fiz aquela tarefa.

Próximos passos

Existem duas iniciativas da comunidade do Obsidian, voltadas para criação/divulgação de plugins, uma delas é o Plugin Stats, que permite visualizar os plugins em trending, mais baixados, com tags específicas e etc.
E existe o vault (que é um dos cofres de notas) chamado Obsidian Hub, voltado para listar os plugins por categoria.
Um outro caminho para encontrar novos plugins, é explorar o Browse da aba Community plugins na janela de configurações do Obsidian (que eu citei no início do post).

Anotando: Plugins embutidos que utilizo no Obsidian

Weverton Timoteo — Sun, 24 Sep 2023 06:05:04 +0000

Na postagem passada eu expliquei como iniciei minha jornada em tomar notas, mas não falei muito do app (Obsidian) e quais minhas configurações e plugins.

Vamos começar falando sobre os plugins embutidos nele (conhecidos como Core plugins na seção de configurações).

Audio recorder

Sem dúvida, uma das funcionalidades mais amadas pelos brasileiros: um WhatsApp nas suas notas! :D só que aqui você salva os seus áudios para você mesmo ouvir! Quero ver se você vai continuar gravando um podcast para cada áudio que envia para um contato depois dessa experiência.

Aqui a ideia é guardar a informação de forma rápida para depois usar alguma ferramenta de transcrição ou simplesmente sintetizar os pontos mais importantes do texto.

O formato utilizado é .webm, que garante uma ótima qualidade de gravação com uma boa troca pelo tamanho do arquivo. A única desvantagem é que se você apagar a ocorrência de onde você linkou o áudio gravado, o Obsidian não vai te perguntar se quer também remover o anexo. Mapear esses anexos que nunca foram mencionados acaba sendo um tanto trabalhoso, então fica por sua conta.

Se fosse comparar o formato .webm com outros populares, seria mais ou menos isso:

Critério	.webm	.mp3	.ogg	.opus
Bitrate (kbps)	Variável, 256-320	Variável, 320	Variável, 192-500	Variável, 6-510
Tamanho Médio (10s)	Aproximadamente 320 KB	Aproximadamente 400 KB	Aproximadamente 250 KB	Aproximadamente 80 KB
Aplicativos	Obsidian	Músicas	Telegram	WhatsApp

Backlinks

É uma das principais funcionalidades que me motivou a utilizar Obsidian, mandatória para seu sistema de notas. Ela vai indicar onde aquela nota foi linkada/citada.

Assim, se você mencionar aquela função ou snippet, ao acessar a nota da linguagem da programação, você vai conseguir ver onde ela foi citada, como se fosse um agregador de ocorrências.

Command Palette

O famoso Cmd + Shift + P do Visual Studio Code, porém no Obsidian é só Cmd + P, esse comando vai te mostrar todas as funções existentes no app, desde esconder as sidebars da esquerda ou da direita, como uma opção para mudar temas, apagar o arquivo, renomear e etc.

Daily Notes

Esse plugin é opcional, se você não utiliza a funcionalidade de Journal (Diário), você pode pular essa. Com ela você consegue derivar notas diárias em um determinado diretório, eu uso _Journal. Vale ressaltar que o sistema PARA, que eu mencionei no blog post anterior, não menciona nada sobre melhor organização para esse tipo de notas. Se você não quer colocar em uma pasta raiz, caberia muito bem no 3 Resources.

Dicas:

Utilize o formato de data YYYY-MM-DD, não é tão intuitivo para nós por não estarmos acostumados, mas é o melhor para ordenação das notas. Dessa maneira você não terá uma bagunça na ordenação por ordem alfabética, como 01-10-2022 e depois um 01-10-2023.
Selecione um template para gerar suas notas diárias com um pouco mais de metadados, eu utilizo as seguintes properties:

---
created at: {{date:DD/MM/YYYY}} {{time:HH:mm}}
weekday: {{date:dddd}}
tags:
---

Com isso você saberá qual dia da semana gerou aquela nota e em qual data no formato mais convencional de leitura.

Eu utilizo campo tags para especificar quais as atividades daquele dia que anotei, exemplo: utilizo #ffxiv quando quero anotar algo do Final Fantasy XIV e #sourcelevel quando tem algo do trabalho para lembrar.

Ressaltando que não adianta nada ter anotado algo se você não consegue encontrar depois.

Note composer

Algumas vezes você começa uma seção de aprendizado sobre determinada ferramenta e quando vai ver já escreveu muitos detalhes sobre algo muito específico dela, por exemplo, como a cobrança funciona.

Nesse caso o plugin Note composer ajuda demais porque basta selecionar o texto específico e utilizar a opção no Command palette: Note composer: Extract current selection.... Esse comando irá criar uma nova nota com a seleção e linkar a nota criada na nota anterior que você estava editando.

Assim você garante um sistema de notas mais organizado e sem aquele monte de ruído que, muitas vezes, não te interessa quando está lendo as notas gerais.

Linkando notas

Vale lembrar que, para linkar uma nota, utilize a sintaxe [[Nome da nota]], mesmo que seja para caminhos mais complexos como [[3 Resources/Caminho/para/Nota]]. Se você quiser usar um atalho/alias de exibição, basta utilizar pipe (|) no final do link: [3 Resources/Caminho/muito/longo/Como escrever melhor|Como escrever melhor]].

Caso você precise referenciar essa nota várias vezes, basta utilizar a property aliases. Com ela você consegue dar "apelidos" para mencionar a nota, então ao abrir os colchetes duplos, o próprio Obsidian já vai autocompletar os apelidos disponíveis.

Outline

Muito útil para entender a estrutura da nota e incentiva você a escrever os headings (h1, h2, h3 e assim em diante) nas suas notas. Essa visualização fica presente na sidebar da direita ao abrir uma nota e facilita demais na navegação, edição e na leitura.

Page preview

Essa é bacana quando você não quer acessar a nota que foi mencionada na nota que está editando, basta segurar Ctrl/Cmd e passar o mouse sob a menção (hover), um prompt será exibido com o preview da nota.

Properties preview

Sem dúvida uma das funcionalidades que fizeram alguns usuários de outros apps de notas migrarem para o Obsidian. Foi lançada recentemente na versão v1.4, do final de Agosto, 2023, ela exibe uma interface mais atrativa para usuários menos técnicos visualizarem e editarem as propriedades de uma nota:

Quick switcher

Seguindo com a analogia com o VSCode, seria o equivalente ao Ctrl + P, uma busca "fuzzy" (que significa algo embaçado ou não muito nítido) das suas notas. Essa é uma maneira inteligente de pesquisar algo, mesmo quando você não lembra muito bem o nome, só digita algumas letras e ali está o que você estava procurando.

Através do Quick switcher também é possível criar novas notas, só fique atento que se você incluir caracteres especiais, como : no título da nota, o mesmo falhará e se você estava pensando em um título para o blog post (como eu para esse), será perdido! Então coloque um nome rápido e depois renomeie a nota, utilizando o plugin apenas para criar no local correto.

Ela não funciona muito bem para criar novas notas em estruturas de diretórios aninhadas, por exemplo: 3 Resources/Ideias/Postagens/Minha ideia de blog post, você teria que digitar pasta por pasta. O que deixa você suscetível a erro, mas espero que o time do Obsidian resolva isso logo ou mesmo a própria comunidade - como última saída, também posso esperar essa dor aumentar para eu mesmo resolvê-la um dia! :)

Tags view

Uma das extensões bem bacanas para você avaliar o estado geral das suas notas, serve mais para curiosidade que para algo de fato "útil". Com ela é possível ver todas as tags (etiquetas) que utilizou em todo seu sistema.

Vale ressaltar que é possível criar tags aninhadas, seguindo exemplo do FFXIV, se eu quero anotar relacionado a jardinagem no jogo, não vou utilizar apenas #gardening e sim #ffxiv/gardening. Dicas:

utilize hífens para separar palavras, não vá acabar com um #codequality, use #code-quality
só utilize tags aninhadas para desambiguação das tags (como o exemplo da jardinagem acima)

Word count

Muito útil para quem escreve conteúdo, com esse plugin você sabe quantas palavras foram utilizadas e com isso pode escrever um conteúdo com uma chance melhor de engajamento.

Algo que aprendi na SourceLevel ao escrever postagens com maior frequência foi que, segundo um estudo de 2019 do pessoal da Backlinko (uma das referências em SEO, conteúdo e marketing), o "sweet spot" para maximizar os shares nas redes sociais, como Facebook, Twitter, Reddit e Pinterest, é algo em torno de 1.000 - 2.000 palavras.

Blog posts nesse intervalo de conteúdo tem, em média, 56.1% mais compartilhamentos que conteúdos com menos de 1.000 palavras.

E como esse blog post já está com ~1.400 até aqui, acho que é hora de parar e deixar o detalhamento sobre plugins da comunidade para uma nova postagem. Espero ter colaborado em como "tunar" seu Obsidian ou a selecionar configurações equivalentes para usar no seu sistema de notas atual.

Tomando notas como desenvolvedor de software

Weverton Timoteo — Sat, 23 Sep 2023 13:43:36 +0000

Me arrependo profundamente de não tomar notas mais cedo. As notas até existiam, mas geralmente eram coisas pontuais para executar uma tarefa ou algo interessante que encontrei que meses depois eram só anotações "sem utilidade".
Fico pensando se eu tivesse um mapa de tudo que eu aprendi e experienciei na vida transcrito de uma maneira organizada que eu possa consumir para gerar novas ideias e, finalmente, eu tenho.

Recentemente li o livro Criando um Segundo Cérebro do Tiago Forte e me ajudou bastante a tirar essa ideia de organização perfeita e simplesmente começar a anotar. Meu processo de tomar notas para valer se deu depois de resolver as seguintes dúvidas:

Qual melhor app/software para tomar notas?
O que anotar?
Como organizar minhas notas?
Como anotar rápido?

Só depois que "resolvi" esses pontos que senti que estava pronto para escrever para valer e aí a coisa começou a andar.

Qual o melhor app/software para tomar notas?

Como tudo: depende. E depende para cada pessoa. Cada solução terão vantagens e desvantagens, antes precisei escrever o que era mais importante para mim para poder decidir, eu queria:

Um app leve (não necessariamente nativo, um electron resolveria)
Suporte a Backlinks (lista de menções da nota que estou visualizando)
Queria estrutura de pastas (para organização que eu estava pensando fazia sentido)
De graça (não queria pagar para algo que iria manter para vida toda)
Os arquivos são meus (não estão em uma cloud privada ou requere alguma funcionalidade de exportação para arquivos para eu manipulá-los)
Possibilidade de estender e customizar (caso eu quisesse desenvolver um plugin para atender um fluxo específico meu)
Arquivos de anexos centralizados (não queria guardar em uma cloud à parte)
Não tinha necessidade de colaborar (editar a nota ao mesmo tempo que alguém)

Notion

Requisito de estar sempre conectado
Fácil de se tornar algo mais complexo com funcionalidades de tabelas, banco de dados, fórmulas
Não possui suporte para backlinks
Acho o sistema de anexos muito lento para renderizar arquivos estáticos
Tenho a sensação do app ser muito pesado o que dificultava minha navegação

Logseq

App super leve
Open Source (esse item pesa bastante)
Tudo é um bullet point (uma <li> dentro de uma <ul> para desenvolvedores web)
Não existe organização por diretórios, apenas um "All notes"
Bem fácil para anotar no formato diário (Journaling)

Roam

App/Serviço Pago
Porém existe localização de preço para brasileiros (é necessário entrar em contato)

Obsidian

Comunidade bem forte
Diversos plugins
App leve
Fácil de customizar e extender
Fácil de gerir arquivos estáticos (attachments/anexos)
Visão de grafo é interessante mas não muito útil

Dentre esses acabei optando pelo Obsidian, inclusive esse blog post está sendo escrito nele. Gosto bastante de como é possível configurá-lo para ficar no fluxo de edição mais favorável ao que estou acostumado, inclusive com Vi keys para quem curte o editor Vim (e para quem não conhece, vá direto para o Neovim caso queira testar).

O que anotar?

Como você deve ter imaginado, esse é um dos pontos críticos: o risco de anotar tudo que sua nota tem tanto ruído e detalhe que se torna irrelevante para ser consultada. Eu recomendaria:

algo que seja importante
anote de uma maneira que você entenda o contexto rapidamente
a nota tem que ter alguma utilidade para você
- se anotar quantos PRs (Pull Requests) você abriu no dia é importante e tem alguma utilidade no futuro, anote! - mas é melhor usar a SourceLevel para isso :)

Falando da rotina de uma pessoa desenvolvedora de software eu gosto de anotar:

Reuniões

É muito comum, durante a daily diversas pessoas citarem ferramentas, tecnologias, nomes e/ou empresas que você nunca ouviu falar. Não precisa ser algo bem preciso, principalmente se for uma reunião presencial, mas é legal transcrever pontos importantes daquela reunião para depois você saber de onde conheceu uma determinada tecnologia ou uma empresa.

Acho também interessante para reuniões de 1:1s ou de Performance, para saber o que já foi dito em reuniões passadas e até para fazer o follow up da sugestão e até dos elogios.

Sessão de Debugging

Durante um debugging eu gosto de transcrever o problema que estou tendo e já não estou conseguindo resolver, como por exemplo, uma exception. Então sempre que eu tenho um problema, verifico primeiro no meu sistema de notas.

Esses dias precisei adicionar uma variável ambiente em um cluster Kubernetes. Eu não lembrava qual subcomando do CLI kubectl deveria utilizar, mas bastou uma busca rápida no meu sistema de notas e ali estava um tutorial de como fazer isso. Para quem ficou interessado o comando é kubectl set env deployment/<seu-deployment> MY_ENV_CONFIG=<valor da config>.

Esse tipo de coisa, não só cataloga os problemas que estou tendo, mas pode ajudar um colega de time quando passa por algo parecido. Bastaria copiar o Markdown e colar o conteúdo para a pessoa. Outro ponto interessante é que fica fácil escrever um blog post, só pegando partes das minhas notas.

Discovery/Aprendizado

Comecei recentemente a estudar o Pulumi como alternativa ao Terraform, então fui detalhando tudo que descobri em poucos itens de forma resumida. Como, por exemplo, formatos disponíveis para descrever a infraestrutura (NodeJS, Python, etc), precificação e funcionamento do modelo de créditos.

Esse tipo de nota me permite ajudar também outras pessoas que estão na etapa de aprendizado e até para conversar em uma reunião sobre determinada ferramenta e ir levantando potenciais dúvidas para serem resolvidas.

Consumo de conteúdo

Agora quando eu leio algum blog post, cadastro no sistema de notas e transcrevo algumas partes importantes dele. Com a leitura do livro Criando um Segundo Cérebro, que citei no início do texto, aprendi a utilizar bold/negrito nos textos e também dar highlight no resumo do resumo. Isso também se aplica aos vídeos do YouTube, você pode clicar nas reticências (...) -> Mostrar transcrição. Tudo bem que é uma transcrição gerada, mas já ajuda a salvar trechos do vídeo para serem buscados no futuro.

Como organizar as notas?

Primeira coisa que aprendi para destravar essa pergunta foi: não existe organização de diretórios e tags perfeitos. Sendo assim, pensei em como reduzir o meu estrago, para isso acabei adotando o sistema proposto pelo Tiago Forte, chamado PARA:

Projetos: Algo que você está trabalhando no momento, existe início e uma data de fim
Áreas: Algo que você está trabalhando continuamente, por exemplo, um cuidado de uma doença genética ou um almoço com um familiar que você tem o planejamento de sempre conhecer um lugar diferente
Recursos: Aqui vai todo o restante, eu penso nele como um "banco de dados" das minhas notas e ultimamente ela tem virado meio que uma Wiki pessoal. Lá consigo ter listagem de jogos que já joguei, séries que já assisti, etc.
Arquivo: Tudo que teve um término (independente do que era originalmente), se foi encerrado, ele vem para esse diretório.

Se você utilizar Logseq, recomendo dar uma olhada na extensão que o George Guimarães desenvolveu que utiliza o sistema PARA.

O Tiago Forte recomenda inclusive enumerar cada um deles para facilitar o mention e acesso. Então ficaria:

Projetos
Áreas
Recursos
Arquivo

Se você não tem uma organização em mente, recomendo fortemente utilizar essa e depois deixar seu sistema de gestão de conhecimento pessoal tomar forma organicamente e te direcionar para melhor estruturação.

Como anotar rápido?

Pense em não perder as ideias, não tem problema ter algum erro de digitação ou não ter muito detalhamento enquanto você está anotando algo (por exemplo, durante uma reunião). O importante é você não perder essa informação e poder revisitar suas notas depois da reunião para organizar com etiquetas (tags), linkar notas existentes (como pessoas que participaram da reunião ou lugar que a mesma ocorreu).

Eu gosto bastante do sistema de diário (criando uma entrada do dia e anotando tudo lá). O Obsidian não trabalha muito dessa maneira, comparado ao Logseq, mas utilizando o Cmd + P -> Daily notes: Open today's daily note, resolve isso de maneira muito rápida. É interessante adicionar algumas properties também, para isso, no início de cada nota basta utilizar o seguinte trecho:

---
tags: health cooking
url: https://minha.receita/almoco
----

Você pode customizar as propriedades da nota com o que o você achar relevante, eu tenho linkado notas existentes nas propriedades diretamente (de forma experimental).

Depois de achar um formato para cada tipo de nota, você pode transformá-los em Templates, então assim que abrir a nota, você pode utilizar Cmd + T (no Obsidian) para selecionar qual template utilizar, inclusive é possível aplicar vários templates na mesma nota.

Plugins?

Eu utilizo vários, porém não recomendo sair pegando os plugins que alguém utiliza e instalar tudo de uma vez. Deixe a necessidade surgir! No futuro pretendo compilar os que uso e por qual motivo, o único que faço questão de mencionar agora é o remotely-save, para sincronizar as notas do Obsidian no S3 (ou compatível), Google Drive ou Dropbox. Permitindo assim você acessá-las no iOS ou Android.

Anotou?

Nesse blog post já deve ter surgido várias coisas bacanas para você copiar e usar depois, se você ainda não começou a anotar: agora é o momento!

Não deixe para depois e não espere o momento perfeito para anotar. Imagine a quantidade de coisas interessantes e de possibilidades que você poderia estar desenvolvendo há tanto tempo se já tivesse essas anotações desde o início da sua carreira?

Mastering Git: The lesser-known commands you could be using (or not)

Weverton Timoteo — Wed, 16 Aug 2023 12:52:38 +0000

Navigating the vast landscape of Git commands can sometimes feel like venturing into a bustling marketplace where everyone seems to know the most popular stalls: pull, commit, push, rebase, stash, and checkout. These commands are the cornerstone of everyday version control tasks, often forming the basis of a developer's Git journey. But amidst this bustling crowd of common commands, have you ever paused to wonder, "What else can Git do?" Have you ever caught yourself in the quiet moments, pondering the existence of lesser-known Git commands that could potentially transform your workflow?

Join us as we navigate through these unexplored corners of Git, revealing commands that may have eluded your attention but can significantly enhance your mastery of version control.

`git switch`: a fresh approach to branch management

While git checkout remains a versatile command for various purposes, it also comes with the potential to inadvertently discard changes or create confusion. Enter git switch, introduced in Git version 2.23 as a dedicated tool for branch management.

Unlike the all-encompassing nature of git checkout, git switch focuses solely on simplifying branch-related operations. Its purpose is straightforward: to provide a clearer and safer way to switch branches, reducing the risk of errors and data loss.

Why Consider Using git switch?

If you've ever felt the unease of accidentally losing your work while using git checkout, git switch offers a more reassuring alternative. This command offers explicit error messages and is designed to minimize the chances of unintentional changes.

Here are some examples of how you can use git switch effectively:

Create and switch to a new branch with git switch -c my-new-branch, using the current commit as its base.
Swiftly switch to the main branch using git switch main
Return to the previous branch by employing git switch -

`git bisect`: tracking bugs down

In software development, locating a bug can be akin to finding a needle in a haystack. But fear not – the git bisect command is here to help. It's like a guided missile for tracking down the elusive bug.

Here's how it works:

Identify Known States: First, you need to identify a "good" commit (when the code worked) and a "bad" commit (when the bug surfaced).
Start Bisecting: Begin the process with:
```
git bisect start
```

Mark Known Commits: Tag the known "good" and "bad" commits:

git bisect good <good-commit>
git bisect bad <bad-commit>

Navigate Commits: Git will automatically guide you to a commit between the two states. You test your code there. To see which commit you're at:
```
git log -n 1 --oneline
```
Continue the Hunt: Based on your test, you mark the commit as "good" or "bad":
```
git bisect good  # or git bisect bad
```
Repeat Until Found: Git will automatically move to the next commit within the narrowed range. You repeat the process until you've pinpointed the bug's source.
End the Hunt: When you've found the problematic commit:
```
git bisect reset
```

This concludes the process and takes you back to the clean state and the previous HEAD before you started the bisect process.

`git notes`: Enhancing Commit Context

Git notes provide a versatile way to attach supplementary information to a commit without altering the commit itself.

Imagine you and your team found yourselves in a Git repository with less-than-ideal commit messages. Often, commits lack the necessary clarity to explain their purpose effectively. This feature allows you to enrich commits with essential context without the need to modify or rewrite commit SHA1.

How to Utilize Git Notes

Stored locally within .git/refs/notes, Git notes remain separate from the main commit data. By default, they are not pushed to the remote repository. However, this can be changed by pushing them in a manner similar to git tag:

git push origin refs/notes/commits

To retrieve existing notes from a remote repository:

git fetch origin refs/notes/commits:refs/notes/commits

Adding Notes to Commits

You can easily add notes to existing commits using the git notes add command:

git notes add -m "Introduce irreversible migrations at this point" <commit-sha1>

The m option is optional. If omitted, your default text editor will open, allowing for a more detailed explanation.
If you skip providing <commit-sha1>, the HEAD commit will be assumed.

Removing Notes

Removing notes is straightforward:

git notes remove <commit-SHA1>

Listing and Viewing Notes

To list all existing notes:

git notes list

For more in-depth insight into a specific note:

git notes show <commit-SHA1>

Unfortunately, GitHub no longer displays git notes in its UI. This adjustment, in my opinion, reflects the limited usage of these commands. By making this change, GitHub appears to be fostering a culture of encouraging developers to consistently produce improved commits without the temptation to revisit or dwell on the details of previous commits.

Sharing Diffs: `git diff` + `git apply`

Consider a common scenario: a pair programming session happens to address a specific problem. During this interaction, the most experienced developer takes the lead, demonstrating a viable solution by implementing essential changes.

As the collaborative session unfolds, these changes become crucial building blocks for the solution. To facilitate the smooth continuation of this collaborative effort, Git provides two essential commands: git diff and git apply.

Once the demonstration is complete, and the necessary changes are in place, you can encapsulate these modifications within a concise patch file:

git diff > ~/Downloads/pair_programming_session.patch

The other developer can then seamlessly incorporate these modifications into their local codebase using:

git apply pair_programming_session.patch

In this manner, Git offers an efficient mechanism for transferring insights and progress gained from collaborative coding sessions, ensuring that developmental strides are effectively communicated.

Embrace Unfamiliar Commands

I understand that consistently learning new tools and programming languages can be challenging. However, it's important to recognize that git serves as a tool for delivering your work. Thus, make it a practice to regularly peruse the official documentation and keep your git CLI updated to fully leverage its capabilities and embrace new features.

Have you ever considered integrating these commands into your workflow? I hope you've found something useful or at least identified a command to avoid using.

The Perfect Git Commit Quest

Weverton Timoteo — Mon, 07 Aug 2023 19:16:44 +0000

The Importance of Writing a Good Commit Message

When it comes to Git commits, a well-crafted message is more than just a technical necessity. It serves as documentation, providing essential context for future reference. During a git show, a descriptive commit message offers valuable insights into the changes made, aiding comprehension and troubleshooting.

Furthermore, communicating with accessible peers about implementation and modifications opens doors for constructive collaboration and alternative perspectives. Tech leads can also better understand your approach, enabling them to offer valuable advice on advancing the solution using alternate methods.

Commit Title/Header/Subject

The commit header should be concise, with a maximum length of 72 characters in GitHub, to avoid truncation with ellipsis. Ending the title with a period is unnecessary, as every character counts. Starting with an imperative mood verb, such as Add, Fix, Remove, or Refactor, sets a clear and actionable tone for the commit.

Using Conventional Commits

To provide even more context, consider following the Conventional Commits specification, which builds on the Angular Commit Guidelines. Prefix the title with specific keywords like fix, feature/feat, refactor, deploy, chore, docs, or test. Each prefix highlights the nature of the changes made.

fix: Represents a bug fix for your application.
feature / feat: Adds a new feature to your application or library.
refactor: A code change that neither fixes a bug nor adds a feature.
deploy: Changes related to the deployment process.
chore: Upgrades libraries and/or performs maintenance tasks.
docs: Documentation-only changes.
test: Adding missing tests or correcting existing tests.

Here's an example:

feature(shopping-cart): Add remove button

User can now remove the item entirely from shopping cart.

On clicking the button an animation transition will be
displayed.

https://linear.app/<workspace>/issue/A-123/add-ability-to-remove-item-from-shopping-cart

Commit Body

Adding a line break between the header and the body helps organize information clearly. You can mention the files affected by the changes and explain the purpose and accomplishments of the commit. Keeping individual lines within 100 characters enhances readability.

Add a linebreak between Header and the body
You can mention which files are included in these changes
Explain why and what was accomplished in this commit
Many tools recommends that any line cannot be longer than 100 characters, making each one more readable

Commit message conventions (Annotations)

`Co-authored-by`

Marking your pairs during commits is essential for effective collaboration, especially in pair programming (eXtreme Programming). When the author accepts the suggestions block made during a Pull Request review, GitHub doesn’t use Suggested-by convention, instead it uses Co-authored-by.

While there are more conventions to follow, in common workflows, using Co-authored-by is strongly recommended.

When to Commit?

Committing early and often throughout development is highly recommended. Delaying commits until the end of the process can create challenges in organizing atomic commits, crafting a coherent narrative, and receiving timely feedback during the Code Review process. By committing regularly, you can easily create a Draft Pull/Merge Request to seek immediate peer input.

Staging the Changes

Simplify your commit process with tools like LazyGit, tig, GitHub Desktop, Git Tower, or GitKraken. When making changes, think of each commit as a "package" that should be "revertable" through git revert without breaking the build or test suite. Run tests right after creating a commit to ensure changes do not disrupt the suite. To temporarily remove existing changes, use git stash --include-untracked, then remember to git stash pop and continue the commit process.

Forgot Something in the Previous Commit?

If you missed including a change, you can easily remedy the situation with git add followed by git commit --amend. The --amend command picks up your previous commit message (don't forget to update the details about the inclusion) before pushing it with git push.

Note that if you already pushed the commit, you'll need to use git push -f to replace the existing commit with the regenerated SHA1 commit from the amendment. If you're collaborating with others in the same branch, remind your peers to pull the changes, though no impact is expected if they haven't started working in this branch yet.

The Art of Summarize: Drafting/Opening a Pull Request

When working on a project for 2-5 days, summarizing your work in a Pull Request can be challenging. Leverage your well-crafted commit messages to read the story and provide concise summaries to your reviewers. Doing so not only streamlines the review process but also serves as documentation for future reference.

Tuning Your `git` Command

Ensure your $EDITOR is set to your favorite editor for git commit execution:

export EDITOR=nvim

You can also configure core.editor to open any git command in your preferred editor (Visual Studio Code in this example):

git config --global core.editor code --wait

Use Templates for Commit Messages

Simplify the git commit message structure by using templates:

$ git config --global commit.template ~/.gitmessage.txt
$ git commit

Not sure how to start? Use this one:

# Replace this title (<- imperative), <= 50 chars, no period

# Keep this blankline above but replace this line and below
# by your body explaining *what* and *whay* (not *how*) no
# more than 100 chars.

# Here is a footer, include the Git Conventions annotations
# you prefer, such as: 
# Co-authored-by: name <user@users.noreply.github.com>

The Journey to Better Commits: Level Up! Quest Completed!

In the journey of perfecting your Git commits, you've unlocked the art of crafting informative and context-rich messages that enhance your development process. Embracing Conventional Commits, staging your changes, and committing early and often, you've laid the foundation for collaborative and efficient code reviews.

Before marking your Pull Request as “Ready for review”, check this blog post: '10 Items to Check Before Assigning a Pull Request to Someone.' Should your team seek more opportunities for reviews, venture into the realm of 'Creating Code Review Opportunities' for valuable insights. Continue your quest for better commits and conquer new challenges, kupo!

Creating Code Reviews opportunities

Weverton Timoteo — Mon, 31 Jul 2023 18:40:52 +0000

Picture this: Your team is working on a project, and Pull/Merge Requests are piling up without any reviews. Code Reviews are not just a formality; they are an incredible opportunity to learn, grow, motivate, mentor, debate, and share knowledge. So, how can you turn this situation around and make the most out of Code Reviews to enhance your development process?

Finding Time Slots - Optimizing Your Review Routine

Reviewing code shouldn't be an added burden to your team's daily tasks. Instead, seamlessly integrate it into your workflow by using available time slots. Take advantage of moments like coffee breaks, filling your water bottle, grabbing a coffee, or just before lunchtime and wrapping up the day. By incorporating these review moments into your daily rhythm, you ensure consistent Code Reviews without disrupting your workflow, promoting a culture of continuous improvement.

Using Interruptions to Your Advantage

Interruptions are unavoidable, but they can also be opportunities for the Code Review process. When interrupted, use the time to review code. Seamlessly integrate Code Reviews into various workflow transitions, such as finishing user stories, pulling new user stories, opening pull requests, merging pull requests, and ending pair programming sessions.

Dedicate specific time slots for reviews to ensure a focused approach. Avoid rushing reviews under time pressure; communicate time constraints and plan for thorough reviews. Prioritize quality over quantity; thoroughly review a few Pull Requests rather than performing hasty, superficial reviews.

Maximizing Collaboration: Pair Programming's Hidden Gem - Code Reviews

Pair programming fosters collaboration and knowledge sharing. At the end of a session, leverage this opportunity for collaborative Code Reviews. Engage in open discussions, share feedback, document decisions, and celebrate successes, boosting collaboration, code quality, and a culture of continuous learning and growth.

Empowering Psychological Safety in Code Review Discussions

Prioritize psychological safety to enhance team collaboration and code quality. Encourage openness and embrace diverse perspectives during reviews. Deliver feedback respectfully and focus on the code, not the developer. Lead by example, treat mistakes as learning opportunities, and provide guidance to support less experienced team members. Welcome questions and set clear expectations for Code Reviews.

Empowering psychological safety encourages questions and fosters a welcoming environment for other reviewers to participate and interact. Your team can foster a culture of trust, continuous improvement, and code excellence.

Optimizing Code Reviews with Available Tools

Streamline the Code Review process and avoid overlooking reviews by using available tools. GitHub Reminders, integrated with Slack, improve communication and collaboration. Assigned "Reviewers" receive direct messages, ensuring timely notifications. Configure a Slack channel to receive daily reminders, helping the team stay informed and address reviews promptly.

Fostering Accountability through Code Reviews

Code Reviews promote accountability within your team. As "Reviewers," team members take ownership of the codebase, ensuring it meets the team's standards. A culture of mutual support and continuous improvement emerges, enhancing overall productivity and code quality.

Embrace a Strong Code Review Culture

Before assigning a Pull Request to someone, consider taking a moment to review it yourself. By ensuring your PR is well-prepared and clear, you set the stage for efficient and effective feedback sessions. To optimize your Code Review process and discover essential tips for preparing Pull Requests, explore our blog post here.

With a proactive approach to Code Reviews and a commitment to continuous learning, your team will thrive in a collaborative and supportive environment.

Request Changes: você usa com frequência?

Weverton Timoteo — Fri, 01 Jul 2022 14:21:06 +0000

Ao revisar Pull Requests podemos bloquear o merge de acontecer, ao utilizar a opção Request Changes (solicitar mudanças). Mas é uma boa prática utilizá-lo?

A boa prática de uso do Request Changes é quando você encontra alguma modificação que, por alguma razão, não foi encontrada na suite de testes porém se aquele PR for mergeado, irá quebrar a aplicação no ambiente de produção.

Cuidado com o poder

Request Changes também é uma forma de poder, pense que ao utilizá-la você está bloqueando o Pull Request da(s) pessoa(s) que trabalharam nele.

Antes de chegar nesse tipo de prática eu recomendo refletir se as pessoas autoras envolvidas costumam atender aos comentários realizados em PRs de suas autorias.

Caso atender aos comentários seja uma prática do time, não necessariamente resolver (respondendo de alguma maneira), talvez apenas fazer um review sem conceder a aprovação seja suficiente. ✅

É tudo sobre comunicação

Caso você não tenha outra maneira de se comunicar com seu time e precise recorrer ao Request Changes com frequência, você deve trabalhar em melhorar a comunicação.

💬 Ter uma boa comunicação é essencial para a colaboração acontecer de maneira efetiva!

Tempo para o 1º Engajamento nos Pull Requests

Weverton Timoteo — Thu, 30 Jun 2022 16:45:32 +0000

Essa é uma métrica valiosíssima para times grandes. Geralmente utilizamos para medir quanto tempo se passou para a primeira interação com o Pull Request acontecer.

Você pode medir isso tanto para Pull Requests que estão em aberto, para servir de termômetro, ou para os que já foram fechados/mergeados, para ter uma ideia como o time tem trabalhado.

Sabe aquele Pull Request que você solicita revisão e fica horas sem ninguém comentar ou revisar?

O contrário também é um problema: em menos de 1 minuto você já recebe uma aprovação sem comentário algum.

Para times com esse problema do tempo longo de revisão recomendo os revisores utilizarem pequenas janelas de tempo da rotina de trabalho para revisar: pausa para o café, intervalos entre tarefas/User Stories, antes e depois do almoço e/ou antes/depois de reuniões.

Para times que revisam o Pull Request muito rápido é interessante pensar na causa: as pessoas estão apressadas porque existe uma pressão para entregar algo? Ou simplesmente não veem valor na revisão de código?

O ambiente é seguro?

Algumas vezes, a causa da falta ou demora de engajamento é porque as pessoas não se sentem à vontade para revisar um Pull Request de uma pessoa com mais experiência. Fique atento para essas situações, caso aconteça tente criar um ambiente com maior Segurança Psicológica.

Um ambiente seguro para errar é o melhor dos ambientes para promover uma cultura de aprendizado e colaboração. Trabalhando para isso, com certeza vai refletir na prática de revisão de código.

Guia rápido: Comunicação não-ofensiva na revisão de Pull/Merge Requests

Weverton Timoteo — Wed, 29 Jun 2022 17:52:13 +0000

Quer melhorar a comunicação com seu time e a qualidade das interações?

Pare de comentar emojis ofensivos ou negativos, como 🤢, 🤮, 😵, 😱, 💩,🙈

Comece a explicar porque aquilo pode ser ruim e/ou prejudicial para base de código.

Pare de fazer comentários com um único emoji como ✂ ou 🔫

Comece a explicar porque algo deve ser removido, além de só utilizar emojis e esperar que a pessoa que abriu o PR entenda o que você quis dizer.

Pare de pedir para refatorar trechos de código sem dar exemplos

Comece a utilizar o bloco suggestion que mostra uma pré-visualização do que você está propondo (além da possibilidade de fazer um commit com Co-authored-by direto pela interface do GitHub).

Pare de ignorar refatorações ou melhorias realizadas pela pessoa que trabalhou no código

Comece a parabenizar ou comemorar quando alguém consegue fazer esse tipo de melhoria no contexto de modificações que a pessoa está trabalhando.

Pare de apenas comentar no PR e não voltar para responder quando acontece alguma interação com seu comentário

Comece a configurar e utilizar as Notificações para ser avisado quando alguém interagir com seu comentário.

#protip mencione o nome de usuário para quem você quer que seja notificado ao responder comentários.

✅ 🎉 ! Você tem alguma dica para melhorar as interações nos Pull/Merge Requests?