Lady{de}bug – Lady{de}bug

Linux Básico

Mon, 01 Dec 2025 00:00:00 +0000

Minhas anotações sobre o básicos do Linux

Configurando o SonarQube Localmente

Sat, 20 Sep 2025 00:00:00 +0000

Isso não é um tutorial, é mais para o entendimento e estudo sobre a ferramenta e como aplicar ela em projetos pequenos, até médio porte, em repositórios fechados (código privado). Bom, como eu já tinha o SonarQube instalado na minha máquina, abaixo segue como configurar o Docker.

Opção 1: Remover o container existente

Para um trabalho de Pós-graduação eu tinha configurado para um projeto de estudo de análise de código, neste caso foi reconfigurar para outro projeto (depois eu configuro novamente correto para o projeto de estudo de análise de código).

docker rm sonarqube

Agora posso executar o comando para subir um novo container:

docker run -d --name sonarqube -p 9000:9000 sonarqube:lts-community

Sim, a versão é gratuíta, para aprendizado antes de sair pagando algo que não sabe usar.

Opção 2: Substituir o container automaticamente

Se quiser forçar a substituição, use o parâmetro –rm (remove ao parar) ou –replace (caso use Podman). No Docker, geralmente removemos manualmente como acima.

Opção 3: Verificar o status do container

docker start sonarqube

Para encerrar use o comando:

docker stop sonarqube

Executar o SonarQube localmente

Agora a parte que interessa é configurar localmente o SonarQube, e fazer um escaneamento básico.

Primeiro um setup de configuração (acho que vale adicionar isso no script de desenvolvimento).

1. Pré-requisitos

Java 11 ou superior instalado na máquina (SonarQube precisa do Java para rodar).
Docker (opcional, mas facilita a execução do SonarQube — realmente).

2. Baixando e rodando o SonarQube

Link de download: https://www.sonarsource.com/open-source-editions/sonarqube-community-edition/

Aqui a primeira parte de ajustar o docker então precisa se atentar a deixar ele executando, corretamente, sem problemas.

docker run -d --name sonarqube -p 9000:9000 sonarqube:lts-community

Pronto! SonarQube rodando localmente.

Ajuste as configurações de senha e segue para a página:

Configuração do SonarQube

Acesse http://localhost:9000
Login padrão:
- Usuário: admin
- Senha: admin

Agora vamos configurar para fazer um escaneamento do projeto

Gerando um Token de autenticação

No menu superior direito, clique no seu usuário > My Account > Security.
Em “Generate Tokens”, crie um novo token (ex: nome-projeto-token).
Guarde esse token (será usado no scanner).

Instalando o SonarScanner

O SonarScanner é o CLI para enviar seu código ao SonarQube. Ou seja, localmente via terminal vamos falar para ele ler o projeto e então temos a análise.

Instalação via NPM (para projetos Node):

npm install -g sonarqube-scanner

Para referências de cada projeto segue: https://docs.sonarsource.com/sonarqube-server/analyzing-source-code/scanners/sonarscanner

Configurando o SonarScanner no Projeto

Na raiz do projeto, crie um arquivo chamado sonar-project.properties:

Exemplo:

sonar.projectKey=nome-projeto
sonar.projectName=Nome-projeto
sonar.projectVersion=1.0
sonar.sources=.
sonar.language=js,php
sonar.sourceEncoding=UTF-8
sonar.host.url=http://localhost:9000
sonar.login=SEU_TOKEN_AQUI

Problemas encontrados

ERROR: You’re not authorized to run analysis. Please contact the project administrator.

O que significa esse erro?

O SonarScanner está tentando enviar os resultados da análise para o SonarQube, mas o usuário (ou token) configurado não tem permissão para realizar essa operação no projeto configurado no SonarQube.

Perfeito! Vamos ver o que fiz de errado: o nome do projeto no arquivo sonar-project.properties não estava igual ao que eu configurei no SonarQube local.

Agora pronto: quando executar o comando sonar-scanner vai executar o escaneamento no projeto e seguida mostrar em tela os resultados.

Bot Planner - Projeto para acompanhamento do desenvolvimento pessoal

Mon, 06 Jul 2026 00:00:00 +0000

Recentemente estive a desenvolver alguns projetos de estudos com IA, e estava precisando me organizar, de, quanto tempo estive a desenvolver — tempo corrido —

também ao esta desenvolvendo algo geralmente eu costumo ler a documentação da lingagem para leitura de algumas práticas, links de documentos, docs que eu estou escrevendo para determinada característica do projeto. Criar tarefas que me lembrei no ato que estava a desenvolver, e verifiquei que pode ser terminada logo após a tarefa que estou a fazer. Além de comentários do que foi realizado, esse acompanhamento de forma geral.

Com base nesse problema, pensei em algo prático que eu possa fazer enquanto estou desenvolvendo. Ou seja comando /inicio quando inicio a atividade, /link para adicionar documentações entre outros importantes. /nota quando eu quiser adicionar notas comentários, task para quando quiser criar uma tarefas, fim quando finalizar tudo. Após isso gere um Release notes com o que foi feito e quais as tarefas ficaram pendentes.

Então lendo uma postagem em um blog e pensei em criar o bot com gestão pessoal para auxiliar no ciclo de desenvolvimento pessoal sem fricção e que gere um report notes no fim do trabalho.

Podendo também aplicar para compartilhar caso queira com alguém do time (desenvolvimento orientado com metodologia XP).

Criei o repositório no github https://github.com/kellen-xavier/ladydebug-bot-planner ~~inicialmente privado mas irei liberar em seguida~~, open-source — estou a corrigir algumas questões de segurança — e primeiro criar o bot, inicialmente interação é via Discord, mas vai abranger multicanal de comunicação (pensei em slack e dicord principal) as demais particularmente não me interessei muito.

Primeira Fase do desenvolvimento

Nos testes iniciais, ficou bem poluído os comandos no chat unificado, então pensei em criar um segundo “canal de texto”, para que o release-notes separado para acompanhar no dia seguinte, tendo essa visão limpa entre “comandos” e “release notes”.

Organização do Bot

Para configurar o bot é simples, deve-se seguir a documentação oficial neste link: Building your first Discord Bot

Para estes estudo de caso | Como configurar o Bot:

Vá no Developer Portal do Discord.
Abrir o app ladydebug-bot-planner.
Vá em Bot.
Clique em Reset Token.
Copie o token novo.
Atualize DISCORD_TOKEN no .env.

Rode de novo:

set -a; source .env; set +a
python -m daily.main

Configuração Mínima Local

Seu .env local deve ter pelo menos:

DISCORD_TOKEN=token_do_bot DISCORD_GUILD_ID=807481361916100628 DB_PATH=daily.db

Plano de Testes Bot Planner

Visão geral

Checklist:

Todos

[•] Mapear módulos e funcionalidades existentes em src/daily [ ] Mapear testes existentes por funcionalidade [ ] Executar testes/cobertura disponível [ ] Consolidar lacunas de cobertura e recomendações

Funcionalidades Com Testes

Criei o report em docs/TEST_COVERAGE_REPORT.md aqui ele documenta o seguinte:

Estado atual da suíte: 79 passed.
Diretrizes para evitar testes enviesados/falso positivo.
Lacunas restantes por prioridade.
Cenários exatos que precisam ser implementados.
Critérios de aceite para novas rodadas.
Recomendação para adicionar pytest-cov.
Ordem sugerida de execução.

Principais áreas priorizadas no report:

CommandRouter
SqliteStorage
SimpleFetcher
VCS adapters
Report de fim de dia
Discord adapter callbacks
Models/DTOs
Métrica objetiva com coverage

Erros encontrado:

python -m daily.main
2026-07-09 09:32:45 INFO discord.client logging in using static token
2026-07-09 09:32:47 INFO discord.gateway Shard ID None has connected to Gateway (Session ID: b25a5b78274ede64c286f2fc11e8c2e3).
Bot online como ladydebug-bot-planner#3088
2026-07-09 09:51:05 ERROR discord.app_commands.tree Ignoring exception in command 'inicio'
Traceback (most recent call last):
 File "/home/kellen/Documents/Projetos github/ladydebug-bot-planner/.venv/lib/python3.14/site-packages/discord/app_commands/commands.py", line 859, in _do_call
 return await self._callback(interaction, **params) # type: ignore
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 File "/home/kellen/Documents/Projetos github/ladydebug-bot-planner/src/daily/adapters/discord_bot.py", line 90, in inicio
 msg = router.inicio(str(interaction.user.id), str(interaction.channel_id))
 File "/home/kellen/Documents/Projetos github/ladydebug-bot-planner/src/daily/command_router.py", line 32, in inicio
 s = self._day.start_day(user_id, channel_id)
 File "/home/kellen/Documents/Projetos github/ladydebug-bot-planner/src/daily/core/day_service.py", line 32, in start_day
 raise DayAlreadyOpen("Já existe um dia aberto para este usuário.")
daily.core.day_service.DayAlreadyOpen: Já existe um dia aberto para este usuário.

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
 File "/home/kellen/Documents/Projetos github/ladydebug-bot-planner/.venv/lib/python3.14/site-packages/discord/app_commands/tree.py", line 1302, in _call
 await command._invoke_with_namespace(interaction, namespace)
 File "/home/kellen/Documents/Projetos github/ladydebug-bot-planner/.venv/lib/python3.14/site-packages/discord/app_commands/commands.py", line 884, in _invoke_with_namespace
 return await self._do_call(interaction, transformed_values)
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 File "/home/kellen/Documents/Projetos github/ladydebug-bot-planner/.venv/lib/python3.14/site-packages/discord/app_commands/commands.py", line 877, in _do_call
 raise CommandInvokeError(self, e) from e
discord.app_commands.errors.CommandInvokeError: Command 'inicio' raised an exception: DayAlreadyOpen: Já existe um dia aberto para este usuário.

Motivo:

DayAlreadyOpen: Já existe um dia aberto para este usuário. Isso acontece porque você executou /inicio, o bot abriu uma sessão no daily.db, e depois você chamou /inicio de novo sem antes fechar com /fim.

Explicação:

Causa Técnica O core está correto em impedir dois dias abertos: if self._storage.get_open_session(user_id) is not None: raise DayAlreadyOpen(“Já existe um dia aberto para este usuário.”) O problema é que essa exceção está vazando até o Discord, gerando stack trace. O bot deveria responder algo amigável, como: Já existe um dia aberto para você. Use /fim para fechar antes de iniciar outro.

Correções:

Plano De Ajustes Ainda em modo planejamento, então não vou editar arquivos agora. O ajuste recomendado é:

Tratar DayAlreadyOpen no CommandRouter.inicio.
Tratar NoOpenDay em /nota, /link e /fim.
Evitar que exceções esperadas do core virem erro no Discord.
Melhorar diagnóstico de ambiente Discord com DISCORD_CLIENT_ID.
Documentar configuração local e produção no README.
Adicionar testes para esses casos.

Comportamento Esperado Após Ajustes

Validar /inicio com dia já aberto mas sem terminar atividades: Deve retornar: Mensagem: 🟡 Já existe um dia aberto para você. Use /continuar para seguir o seu dia. Comportamento: ao enviar comando /continue deve seguir inserindo as atividades, do dia. Ou seja;

Cenário: Dado que usuário envia o comando /iniciar no dia 1 E no dia 1 usuário envia o comando /iniciar Quando retornar a mensagem: 🟡 Já existe um dia aberto para você. Use /continuar para seguir o seu dia. Então usuário deve inserir comando /continuar E deve seguir até finalizar o dia

Validar /nota sem dia aberto: Deve retornar: Mensagem: ⚠️ Nenhum dia aberto. Use /inicio primeiro.

Validar /fim sem dia aberto: Deve retornar: Mensagem: ⚠️ Nenhum dia aberto para fechar. Use /inicio para começar.

Validar /link sem dia aberto: Deve retornar: Mensagem: ⚠️ Nenhum dia aberto. Use /inicio primeiro.

Arquivos Que Devem Mudar

src/daily/command_router.py
src/daily/adapters/discord_bot.py
src/daily/main.py
.env.example
README.md
tests/test_ingest_and_report.py
tests/test_discord_bot.py
tests/test_main_config.py

O Que Mudou:

src/daily/command_router.py
/inicio com dia já aberto agora retorna: 🟡 Já existe um dia aberto para você. Use /continuar para seguir o seu dia.
Novo método continuar.
/nota, /link e /fim agora tratam NoOpenDay com mensagens amigáveis.
/link agora verifica dia aberto antes de buscar/resumir URL.
src/daily/adapters/discord_bot.py
Adicionado comando Discord /continuar.
Melhorado diagnóstico quando o bot não vê o servidor.
Se DISCORD_CLIENT_ID estiver configurado, o erro imprime URL de convite correta.
src/daily/main.py
Adicionada validação de ambiente: DISCORD_TOKEN obrigatório. DISCORD_GUILD_ID numérico se informado. DISCORD_CLIENT_ID numérico se informado.
.env.example
Adicionado DISCORD_CLIENT_ID.
README.md
Documentado /continuar.
Documentado ambiente local e produção.
Adicionado troubleshooting do Discord.
Testes adicionados para:
/inicio com dia aberto.
/continuar com e sem dia aberto.
/nota, /link, /fim sem dia aberto.
validação de DISCORD_CLIENT_ID e DISCORD_GUILD_ID.
URL de convite no diagnóstico.

Visão Geral de Testes com Discord

Updates e Melhorias

Foi colocado um segundo canal de texto onde que, com o comando /fim finaliza o report e adiciona no canal que fez a chamada, o release-notes do dia.

Agora foi visto que precisa ser finalizada as atividades criadas no dia. Para isso segue a nova funcionalidade.

Funcionalidade: Dado que o usuário conclua e foi finalizada a “Tarefa” criada, Então deve adicionar o comando /fim-task com a seguinte ação:

Comportamento esperado:

URL: para adicionar o link de uma atividade concluida Titulo Tarefa: Nome da Minha task aqui Tempo da atividade aberta: xx minutos / xx horas / xx dias

Dado que a atividade contém comentário, Quando concluir ação Então release notes deve mostrar comentários adicionada a ação

Fluxo De Produção

Criar canal #release-notes.
Copiar o ID do canal.
Criar app/bot no Discord.
Convidar o bot com bot applications.commands.
Criar projeto Railway conectado ao GitHub.
Configurar secrets no Railway.
Configurar volume persistente.
Start command: python -m daily.main.
Fazer deploy.
Testar no Discord:

/inicio
/nota
/pr url:https://github.com/…/pull/…
/fim

Cypress e Boas Práticas de Automação

Thu, 24 Oct 2024 13:07:00 -0300

Evitando o uso de Falsos Positivos com Cypress. Segue abaixo um exemplo de um código, e um arquivo commands com um simples login na aplicação:

Essa aplicação estava ocorrendo um certo erro ao realizar o login, e foi adicionado o seguinte trecho de código na automação para poder realizar o login com sucesso:

Mas o que esse trecho diz? Serve para suprimir os erros que ocorrem na aplicação durante a execução dos testes do Cypress.

Como assim? Ao usar cy.on('uncaught:exception') e retornar false, está instruindo o Cypress a ignorar qualquer erro que ocorra na sua aplicação. Isso permite que o teste continue mesmo que a página ainda não esteja totalmente carregada, dando tempo para que os elementos sejam renderizados antes que o Cypress tente interagir com eles.

Por que remover cy.on('uncaught:exception') é importante? Nesse caso, como está sendo manipulado o teste, forçando a “ignorar esse erro retornando que ele seja falso” é adicionado um falso positivo no nosso teste. Segue abaixo:

Alternativas e soluções para lidar com o tempo de carregamento e evitar adicionar “falso positivo”

Em vez de suprimir erros, deve-se usar as ferramentas do Cypress para garantir que os elementos estejam presentes e prontos para interação antes de tentar acessá-los. Algumas opções incluem:

cy.wait(): Aguarde um determinado tempo ou até que um elemento ou condição específica seja atendida antes de prosseguir com o teste.

OBS: cuide as más práticas ao usar o comando cy.wait(número) , leia a documentação sobre Anti-Pattern.

Unnecessary Waiting aqui

Em vez disso, use:

cy.intercept('GET', '/users', [{ name: 'Maggy' }, { name: 'Joan' }]).as('getUsers')
cy.get('[data-testid="fetch-users"]').click()
cy.wait('@getUsers') // <--- wait explicitly for this route to finish

cy.get(...).should('exist') ou

cy.get(...).should('be.visible')

Precisa garantir de que o elemento existe e está visível na página antes de tentar interagir com ele.