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.

Refactor: Blog

Fri, 10 Jul 2026 00:00:00 +0000

Análise do repositório `notion-blog`

Meu blog pessoal estava cheio de bugs pois eu só não fiz a devida manutenção que precisava ao longo do período desde que criei — talvez 2 anos. Agora a ideia é corrigir bugs e funcionalidades que eu gostaria de adicionar.

Paginação com erros, demora no carregamento, conteúdo centralizado em ferramenta.

O que gostaria de melhorar: descentralizar o conteúdo, organizar o backup rotineiro (por versão), fazer o deploy em dev (não somente em main).

1. Visão geral

É um blog estático em Next.js que usa o Notion como CMS/backend. É um fork do template original de ijjk/notion-blog, personalizado por mim. O conteúdo dos posts vive em uma tabela do Notion e o site é gerado via SSG (Static Site Generation) com revalidação incremental, hospedado na Vercel.

Deploy atual: https://notion-blog-lake-two.vercel.app/
Branch atual: claude/repository-analysis-ieglo6 (idêntica a develop — sem diferenças)
Licença: presente (license)

2. Stack e dependências

Camada	Tecnologia
Framework	Next.js `^11.1.2` (Pages Router)
UI	React `17`, CSS Modules
Linguagem	TypeScript `5.8` (com `strict: false`)
Conteúdo	API privada não-oficial do Notion (`www.notion.so/api/v3`)
Extras	`katex` (equações), `prismjs` (syntax highlight), `@zeit/react-jsx-parser`, `async-sema` (rate limit), `github-slugger`
Qualidade	Prettier + lint-staged + pre-commit
Deploy	Vercel

3. Estrutura

src/
├── pages/
│ ├── index.tsx # Home
│ ├── contact.tsx # Contato (GitHub/LinkedIn)
│ ├── blog/index.tsx # Lista de posts (getStaticProps)
│ ├── blog/[slug].tsx # Renderiza 1 post (getStaticProps/Paths + fallback)
│ └── api/ # asset.ts, preview.ts, preview-post.ts, clear-preview.ts
├── lib/notion/ # Integração com o Notion (rpc, getBlogIndex, getPageData…)
├── lib/build-rss.ts # Gera feed Atom em /public/atom no build
├── components/ # Header, Footer, Code, Equation, Counter, SVGs, SpotifyPlayer…
└── styles/ # CSS Modules + global.css
scripts/create-table.js # Cria a tabela-modelo no Notion via API privada

4. Como funciona (fluxo de dados)

rpc.ts faz POST autenticado no endpoint privado do Notion usando o cookie token_v2=$NOTION_TOKEN.
getBlogIndex carrega a tabela (BLOG_INDEX_ID), monta o mapa de posts via getTableData (que interpreta o schema da collection do Notion) e busca previews dos 10 posts mais recentes com concorrência limitada a 3 (async-sema). Usa cache em disco (.blog_index_data*) durante o build (USE_CACHE).
blog/index.tsx filtra rascunhos em produção (Published === 'Yes') e lista os posts.
blog/[slug].tsx busca o conteúdo do post (getPageData → loadPageChunk paginado), resolve embeds de tweets, e faz um switch gigante convertendo cada tipo de bloco do Notion (text, header, image, code, quote, callout, equation, bookmark, tweet…) em JSX.
api/asset.ts funciona como proxy: pega a URL assinada do arquivo no Notion (getSignedFileUrls) e redireciona (307) para servir imagens/vídeos.
build-rss.ts roda no build e gera o feed Atom em public/atom.
Preview mode: api/preview.ts e preview-post.ts habilitam o modo rascunho do Next.

5. Pontos fortes

Arquitetura enxuta e bem separada (lib/pages/components).
Uso correto de SSG + revalidate (ISR) e fallback: true.
Rate-limiting no fetch de previews e cache de build.
Suporte rico a blocos do Notion (equações KaTeX, código com Prism, callouts, bookmarks, vídeo, tweets).
Ferramentas de formatação já configuradas (Prettier/lint-staged).

6. Problemas e riscos que encontrei

Segurança / prático

NOTION_TOKEN usado como senha de preview: preview.ts e preview-post.ts comparam req.query.token === process.env.NOTION_TOKEN. Isso coloca o token secreto do Notion na URL (fica em logs, histórico, referrers). Deveria ser um segredo separado (NEXT_PREVIEW_SECRET).
API privada do Notion (token_v2 + /api/v3): não é oficial, pode quebrar a qualquer momento e o token é a sua sessão pessoal. O ideal moderno é migrar para a API oficial do Notion (@notionhq/client).
api/asset.ts é um proxy aberto (Access-Control-Allow-Origin: *) que assina URLs para qualquer assetUrl/blockId recebido — vale restringir.

Dependências não declaradas

node-fetch, @next/env e shell-quote são importados mas não constam no package.json (funcionam só por dependência transitiva/hoisting). Isso é frágil e pode quebrar o build com um lockfile limpo. Devem ser adicionados como dependências explícitas.

Restos do template original (branding inconsistente)

header.tsx: link “Source Code” e OG image apontam para ijjk/notion-blog e notion-blog.now.sh (domínio now.sh desativado), twitter @_ijjk.
footer.tsx: link para o repo do ijjk.
index.tsx: ainda usa a imagem/branding “Vercel + Notion”.
Metadados/<title> genéricos (“My Notion Blog”, “An example Next.js site…”).
Idiomas misturados (PT + EN) na interface.

Código potencialmente quebrado/frágil

Embed de tweets usa api.twitter.com/1/statuses/oembed.json (API v1, descontinuada) — provavelmente já não funciona.
[slug].tsx usa unstable_revalidate (API antiga, ignorada no Next 11) junto com revalidate.
equation.tsx: render() pode retornar undefined se o erro não for ParseError (a variável result nunca é atribuída).
getPageData remove blocos de tabela com splice(0, 3) fixo — quebradiço.
Incoerência de versão de Node: o readme pede Node >=18, mas getBlogIndex.ts usa Array.prototype.toSorted() que exige Node 20+. Já vercel.json força -openssl-legacy-provider (workaround de build antigo). Recomendo fixar Node 20 explicitamente.

Qualidade / manutenção

tsconfig com strict: false (perde segurança de tipos; muito any).
Sem testes e sem CI (.github/ ausente).
README com pequenos erros (crases ´´´ em vez de ```).

7. Recomendações priorizadas

Trocar o segredo de preview por uma variável dedicada (não reusar NOTION_TOKEN na URL).
Declarar node-fetch, @next/env, shell-quote no package.json.
Atualizar o branding: links, OG image, título e twitter para os meus (remover resíduos do ijjk/now.sh).
Corrigir/remover o embed de tweets (API v1 morta) e o unstable_revalidate.
Alinhar a versão do Node (fixar engines: node >=20) por causa do toSorted().
(Médio prazo) Migrar para a API oficial do Notion e considerar atualizar o Next.js (11 → recente) para segurança e performance.

Correções no Blog

Primeiro foi solicitado para realizar uma análise utilizando o claude.ai, seguindo foi escrito o seguinte script.

📚 claude/repository-analysis-ieglo6? Posso começar pelas de baixo risco e alto impacto (dependências no package.json, branding, segredo de preview e os bugs pequenos). Como esta foi uma tarefa de análise, não fiz nenhuma alteração ainda.

Faça as implementações da seguinte forma.

Corrija os pontos, sempre realizando os testes necessários, não deve implementar sem testar.

Após testes de validação, abra PRs

Quando tiver uma atualização delicada, deve ter atenção aos pontos para não quebrar em produção.

Deve documentar as alterações somente no meu repositório kellen-xavier

Deve criar a pasta /docs para uso de documentação

Não deve compartilhar chaves e dados sensíveis - isso inclui documentações, README.md

Criar um setup .agents no repositório, para adicionar informações persistentes

Deve incluir no setup o arquivo .AGENTS.md

Para cada step dado aqui, tenha atenção e testes.

Etapa	Mudança	Validação
Dependências	Declarei `node-fetch@2.6.1`, `@next/env@11.1.2`, `shell-quote@1.7.2` (dev) e `@types/node-fetch`; adicionei `engines.node >=20` e scripts `typecheck`/`test`	`tsc` verde
Segurança (delicado)	`PREVIEW_TOKEN` dedicado em `src/lib/preview-auth.ts`, com fallback para `NOTION_TOKEN` para não quebrar produção	4 testes (401/404/ok/fallback)
Branding	Removidos resíduos `ijjk`/`now.sh` de header/footer/server-constants	teste de regressão
Bugs	`equation.render` nunca retorna `undefined`; `unstable_revalidate` → `revalidate`; oembed de tweet v1 morto → `publish.twitter.com`	teste do render + build
Docs	`/docs` (SETUP, ARCHITECTURE, SECURITY, CHANGELOG) — só no meu repo	—
Agentes	`AGENTS.md` na raiz + `.agents/` (contexto + convenções persistentes)	—

.AGENTS.md (com ponto): usei a convenção padrão AGENTS.md na raiz (é o nome que as ferramentas de agente reconhecem) + a pasta .agents/ para o setup persistente.
O PR foi aberto contra develop (branch padrão do repo), em 4 commits temáticos.

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

Crush: agente de codificação com (TUI/UI) - Configurações de Ambiente em Windows

Sun, 11 Jan 2026 00:00:00 +0000

Seguindo a saga de estudos em Terminais/TUIs, aqui vamos para o entendimento sobre o CRUSH em uma máquina Windows: como foi que configurei e como está sendo o uso até o momento, realizando um teste com um repositório open source bem simples, voltado à configuração de ambiente de desenvolvimento no Windows.

Objetivo principal

Permitir que desenvolvedores tenham assistência de IA diretamente no terminal, sem precisar alternar para um editor web ou IDE com plugins integrados — ou melhor, mais leve ao executar, por exemplo, do que o VS Code. O que a ferramenta oferece:

Integração com múltiplos provedores de modelos de IA
Sessões com contexto preservado por projeto
Interface TUI (Text User Interface) interativa opcional
CLI tradicional para automação ou uso em scripts
Extensibilidade via padrões como Agent Skills e MCP (Model Context Protocol)

Fonte: github crush

Segue abaixo o primeiro teste em ambiente Windows

A usabilidade em uma máquina com OS Windows

Instalação: via PowerShell optei por seguir o comando

# NPM
npm install -g @charmland/crush

Neste caso, foi tranquilo, para fazer integração com API da OpenAI primeiro precisa criar a chave da API, eu segui o tutorial deles aqui voltado para o windows nesse caso. Então nesse caso, copie a sua chave e reserve em um bloco de Notas. No Windows após instalação do CRUSH, no seguinte caminho: C:\Users\SEU_USER conforme o Windows tudo fica sob esse caminho C:\Users\<SEU_USUARIO>\.config\crush\

Caso ainda não exista essa pasta, então crie: mkdir $HOME\.config\crush então pode seguir, fazendo a integração com uma IA — no caso aqui provedor OpenAI — abaixo os comandos para criar uma variável de ambiente primeiro via terminal PowerShell.

Criar variável de ambiente

setx OPENAI_API_KEY "sua_chave_aqui"

Como de costume, feche sempre o terminal e inicie um novo, verifique com o comando: echo $Env:OPENAI_API_KEY

Segue para verificar se o Crush está funcionando: crush --version e caso mostrada a versão segue para o uso:

crush

O terminal PowerShell irá carregar a UI da ferramenta então pode iniciar o uso. Neste exemplo de testes eu decidi refatorar um projeto de setup para Windows: https://github.com/kellen-xavier/scripts-config-windows — particularmente não muito interessante mas necessário, e também útil quando precisar reinstalar o mesmo — aqui eu primeiro via VS Code baixei o repositório — sim, neste caso utilizei por agora o editor, mas com os demais plugins do charmbracelet pode-se personalizar; o foco aqui não é esse.

Para os usos práticos

Perguntar sobre código do projeto atual: neste caso fui até a pasta do meu projeto

cd meu-projeto
crush

Primeira pergunta pedi para analisar o projeto: de forma mais geral, tipo possíveis bugs. Após ele me responder as respostas.

analyze possible errors

Eu tinha esquecido de criar o arquivo AGENT.md, o próprio CRUSH recomenda isso em tela, mas aí fui lá criar.

# Arquivo de script PowerShell para configuração Windows
Repositório de scripts voltado para Windows: instalar e personalizar via Shell Script. Este repositório foi criado com o intuito de facilitar a instalação de Aplicativos Windows. Criar o arquivo programas-new-apps.ps1

## REGRAS: O script deve conter
- Implementar Testes com Pester
- Usar análise estática de código
- Usar winget como gerenciador principal
- Instale programas com segurança usando winget
- Verificar se o winget está instalado
- Instalar programas de forma idempotente (não reinstalar se já existir)
- Usar parâmetros silenciosos
- Gerar log de execução
- Falhar de forma segura em caso de erro
- Não baixar executáveis diretamente da internet
- Seguir boas práticas de segurança no Windows
- Download e Execução de Script Externo com validação (Win11Debloat)
- Instalar gerenciadores de versão (Instalação de Múltiplas Versões do Java/Node.js)
- Deve conter blocos de help
- Script verifica conectividade antes de tentar downloads
- Adicionar Suporte a -WhatIf e -Confirm
- Transformar scripts em módulo PowerShell com funções reutilizáveis
- Consistência nos Nomes dos Scripts
- Verificação de Código de Saída (uso de $LASTEXITCODE para validar sucesso das operações winget)
- Feedback Visual ao Usuário (uso de Write-Host com cores para indicar status das operações)
- Todos os scripts principais possuem verificação de permissões administrativas no início

Liste exemplos comuns de software

Trabalho uso VPNs

VPN: Netskope Client

Aplicativos

Android Studio, BlueStacks 5, Bitwarden, Cursor, Docker Desktop, DBeaver Community, Discord, Flameshot, Global VPN Cliente, LibreOffice, Powershell, PowerToys Awake, Intellij IDEA Community Edition, ScreenToGif, sqldeveloper, Sublime Text Free, Teams, Insomnia, Obsidian, VS Code, Visual Studio Installer, Logitech G Hub

Navegadores

Google Chrome, Edge, Firefox, Opera

Linguagens Desenvolvimento

JAVA 11, 17, 18+
NodeJS
Python

Documentação README.md

Especifica versão mínima do Windows 10 (requer 1809+ para winget)
Necessidade do App Installer atualizado
Seção de troubleshooting

Registry com Backup

$BackupPath = "$PSScriptRoot\backup\registry-$(Get-Date -Format 'yyyyMMdd-HHmmss').reg"
reg export "HKCU\Software\Microsoft\Windows\CurrentVersion\Themes\Personalize" $BackupPath

PRIORIDADES DE CORREÇÃO PARA OS SCRIPTS EXISTENTES

Prioridade 1 (Segurança): adicionar validação de hash para Win11Debloat, criar backup do registro antes de alterações, implementar Try-Catch em todos os scripts
Prioridade 2 (Funcionalidade): implementar logging persistente, adicionar verificação de pré-requisitos, corrigir comando de navegador padrão
Prioridade 3 (Manutenibilidade): adicionar parâmetros aos scripts, implementar idempotência, adicionar comment-based help

Referências

Tentei por tudo o que entendi ser o correto desta vez para criar o setup, eu tive que ler as referências também para entender as boas práticas em torno disso, importante entender exatamente como vai montar o arquivo do AGENT pois ele fica mais estruturado.

Agora solicitei para executar o arquivo do AGENT: based on the AGENT.md file execute

Com base no primeiro comando ele retornou:

Processando o arquivo AGENT:

No VS Code quis dar uma olhada em como ele estava se comportando:

Executando Lint:

Executando Testes:

Solicitei para fazer um update do README.md:

Estrutura final do projeto:

Cola do BPMN

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

Para quem esta começando a desenhar fluxogramas, segue as opções para os eventos do BPMN.

Start inicia o fluxo, intermediate acontece no meio, boundary fica colado numa atividade para tratá-la, e end encerra o caminho. Regra de ouro: catch = espera algo; throw = dispara algo.

Start events (iniciam o processo)

Start event (none): começa sem condição.
Message start: inicia quando chega uma mensagem (ex.: webhook).
Timer start: agenda/cron (data, atraso, repetição).
Conditional start: começa quando uma expressão fica verdadeira.
Signal start: começa ao receber um “broadcast” (sinal geral).

Intermediate events (no meio do fluxo)

Message intermediate (throw): envia mensagem a outro participante.
Timer intermediate (catch): espera um tempo/data.
Escalation intermediate (throw): avisa/escalona sem tratar como erro.
Conditional intermediate (catch): pausa até a condição ficar verdadeira.
Link (catch/throw): “teletransporte” dentro do mesmo diagrama (conecta pontos).
Compensation intermediate (throw): dispara compensação (desfazer algo).
Signal intermediate (catch/throw): pub/sub (broadcast) – qualquer ouvinte capta.

Boundary events (colados numa tarefa/subprocesso)

Disparam quando ocorre algo durante a atividade.
Interrupting (borda contínua): cancela a atividade e desvia o fluxo.
Non-interrupting (borda tracejada): cria um fluxo alternativo sem cancelar.
Tipos comuns: Timer, Message, Conditional, Signal, Escalation, Compensation.

Especiais

Error boundary: só interruptivo; captura erros do subprocesso. Cancel boundary: só em Transaction subprocess.

As variações (non-interrupting) mantêm a atividade rodando.

End events (encerram o caminho)

Message end: envia mensagem e termina.
Escalation end: notifica o nível acima e termina.
Error end: lança erro; sai do subprocesso até um error boundary capturar.
Cancel end: cancela uma Transaction.
Compensation end: solicita compensações registradas.
Signal end: emite sinal (broadcast) e termina.
Terminate end: mata todas as atividades ativas do processo/subprocesso.

Aprofundamento sobre: Terminal Comandos Git - Parte 1

Tue, 17 Jun 2025 00:00:00 +0000

Esse post começou com a ideia de ser somente sobre alguns “comandos de Git” que são práticos no dia a dia. Porém, eu não tinha nada por escrito que reunisse um compilado de estudos sobre o assunto de terminais também: o que é um terminal, como usar um, onde ler mais sobre terminais, antes de entrar em comandos Git.

Eu sempre comento que é importante saber usar o terminal. Minimamente, precisamos saber usar essas ferramentas; não adianta fugir disso, mesmo que tua IDE seja perfeita e toda visual, pois inevitavelmente vamos ter que lidar com problemas fora da interface visual.

Eu gosto da metáfora de dirigir um carro, por exemplo: eu imagino como se tu estivesses dirigindo um carro, ele para depois de apitar e tu precisas abrir o capô do carro para ver o que aconteceu. Pode ser um BYD totalmente automático, mas esse carro contém logs, uma caixa-preta — chamada EDR (Event Data Recorder). Aqui vou usar o termo “sujar as mãos” e não ter medo de comandos assim; entender como funciona por baixo dos panos traz uma clareza muito mais profunda.

Alguns Conceitos Base Importantes

O que é um terminal

Um terminal é uma interface de texto para interação direta com o sistema operacional. Ele envia comandos ao shell (ex.: Bash, Zsh, PowerShell), que interpreta e executa instruções usando as APIs do sistema.

Fontes sobre Terminais - Lista de leituras e vídeos

Wikipédia [Akitando] #70 - Entendendo GIT | (não é um tutorial!) [Akitando] #71 - Usando Git Direito | Limpando seus Commits!

Sistema de arquivos e navegação

Quando de modo geral, vamos navegar em um terminal, ou seja, entrar e sair de pastas manipular arquivos, é igual como se fosse navegar em uma tela, mas aqui é por comandos. Quando aqui a gente dizer “faça tal coisa no repositório projeto/automação” estamos comentando que é dentro da pasta em questão.

Visualmente temos, uma tela e onde precisa navegar. Quando abri o terminal (exemplo no ambiente Windows) talvez você veja algo como C:\Users\meu.nome\Sua-pasta no exemplo da imagem seria algo como: C:\Users\kellen.xavier\Documents\Estudos\docs-estudos-obsidian aqui minha organização pessoal é por em Documentos, dentro da pasta estudo, então aqui quando me referir a “entre no projeto de estudos obsidian, faça o git pull”.

Exemplo abaixo uma pasta qualquer, aí tenho que ir só que agora via terminal: se por acaso (a grande maioria abrir o terminal) vai ser algo parecido assim:

PS C:\Users\kellen.xavier>

Então vem os comandos para navegar até ele.

Comandos geralmente mais utilizados

Navegação:

pwd # mostra o diretório atual
ls # lista arquivos e pastas
ls -la # lista detalhada (inclui ocultos)
cd pasta # entra na pasta
cd .. # volta um nível
cd ~ # vai para a home

Se clicar aqui na barra conseguimos ver os caminhos a partir de kellen.xavier (meu caso) → eu estou aqui: C:\Users\kellen.xavier\Documents\Estudos\docs-estudos-obsidian então via terminal:

cd Documents\Estudos\docs-estudos-obsidian

Aqui entrei na pasta:

GIT

Segue abaixo uma sequência de comandos para utilizar, quando se (e principalmente) está trabalhando em projetos com mais de uma pessoa atuando. — Não esquecer —

Para fazer um merge da sua branch atual para a branch principal (“main”), você pode seguir esses passos:

git checkout sua-branch
$ git fetch origin # Puxa as últimas informações do repositório remoto
$ git rebase origin/main
# Atualiza sua branch com as alterações da branch main

$ git rebase origin/main # Atualiza sua branch com as alterações da branch main

Depois de ter sua branch (de desenvolvimento) atualizada, execute o comando git checkout para mudar para a branch “develop” (ou main):

git checkout develop

Agora você está na branch “develop”. Realize o merge da sua branch de desenvolvimento usando o seguinte comando:

git merge sua-branch

Brevemente sobre Pull Request

O objetivo de criar um Pull Request (PR) no GitHub (ou em outras plataformas de controle de versão) é propor mudanças em um projeto de forma colaborativa e controlada. Ao criar um Pull Request, você está solicitando que suas alterações em um branch (ramo) específico sejam revisadas e, se aprovadas, incorporadas (mescladas) ao branch principal do projeto, como o main ou develop.

Agora vamos para o seguinte cenário: se caso você precise trabalhar especificamente com uma branch que não é a main, você precisará criar uma nova branch local baseada na branch remota desejada. Suponhamos que você queira trabalhar na branch minha-branch:

Dado isso, segue o comando git:

git checkout -b minha-branch origin/minha-branch-remota-desejada

Isso irá criar uma nova branch local chamada minha-branch baseada na branch remota origin/minha-branch-remota-desejada.

Com esse comando, pode-se trabalhar com a branch localmente, e fazer commits e outras operações como de costume.

Comandos do dia-a-dia:

Antes de tudo, quando for iniciar o desenvolvimento no projeto, atualize seu ambiente local com o seu repositório remoto.

git pull

Ao fazer isso, seu ambiente local se atualiza com as demais alterações feitas pelos colaboradores do projeto em que estão envolvidos.

O comando git pull é usado para buscar (fetch) as alterações mais recentes de um repositório remoto e, em seguida, fazer um merge dessas alterações na branch atual em que você está trabalhando. Em outras palavras, ele combina os passos de git fetch e git merge em um único comando.

Outro exemplo de git pull:

git pull <remote> <branch>

Onde <remote> é o nome do repositório remoto de onde você deseja puxar as alterações (geralmente “origin”) e <branch> é a branch remota da qual você deseja puxar as alterações (por exemplo, “main”, “develop”, etc.).

Alterações feitas

Para enviar suas alterações para o repositório remoto, é preciso adicionar, seguindo de um comentário do que foi feito.

Adicionar alteração:

git add .

⚠️ Cuidado ao utilizar o git add . pois ele vai adicionar todas alterações realizadas. E isso precisa de atenção. Evite usar, recomenda-se utilizar o:

git add nome-do-arquivo-ou-pasta

Após realizar faça o comentário:

git commit -m "padrao-de-commit: minha mensagem"

Leia aqui (por link depois) para saber mais sobre padrões de commits.

Agora, analise o seu terminal, se caso não tiver nenhum erro ou conflito, pode seguir para subir as alterações:

git push

Para mesclar sua branch com a main no repositório, faça:

git merge sua-branch

Sobre git stash

O comando git stash é utilizado para armazenar temporariamente as alterações que você fez no seu diretório de trabalho, permitindo que você volte ao estado anterior do repositório sem precisar fazer commit das alterações. Isso é útil quando você deseja alternar rapidamente entre diferentes tarefas ou branches sem comprometer as alterações que não estão prontas para serem confirmadas.

Aqui estão alguns exemplos de como você pode usar o git stash:

Armazenar Alterações Temporariamente: se você fez algumas alterações no seu diretório de trabalho, mas ainda não deseja commitá-las, você pode usar o seguinte comando para armazená-las temporariamente:

git stash save "Descrição opcional"

A descrição é opcional e pode ajudar a identificar por que você armazenou essas alterações.

Listar Stashes: você pode listar os stashes que você criou usando o seguinte comando:

git stash list

Aplicar Stash: para aplicar o stash mais recente (ou um stash específico), você pode usar:

git stash apply # Aplica o stash mais recente
git stash apply stash@{n} # Aplica um stash específico pelo seu índice

Remover Stash: depois de aplicar um stash, você pode removê-lo:

git stash drop # Remove o stash mais recente
git stash drop stash@{n} # Remove um stash específico pelo seu índice

Criar uma Nova Branch a partir do Stash: se você quiser criar uma nova branch baseada em um stash, pode usar:

git stash branch nova-branch # Cria uma nova branch e aplica o stash nela

Outros pontos importantes:

Atualize sua branch com as últimas alterações da branch principal (“main”). Isso ajudará a evitar conflitos durante o merge. Execute os seguintes comandos:

git fetch origin # Puxa as últimas informações do repositório remoto

git rebase origin/main # Atualiza sua branch com as alterações da branch main

⚠️ Atenção

Não faça git pull nessas situações. Leia novamente o que é git pull.

As práticas ruins que devem ser evitadas em uma automação de testes

Thu, 05 Jun 2025 00:00:00 +0000

Leia isso, imprimir, talvez imprima e cole no computador de uns aí…

1. Definição e Planejamento Inadequados

Falta de Objetivos Claros: não definir claramente o objetivo da automação, os riscos envolvidos, o escopo e as partes interessadas. A automação sem objetivos bem definidos pode levar a esforços desperdiçados e resultados insatisfatórios.

Estratégia de Automação Mal Definida: não ter uma estratégia de automação de teste que seja aplicável, personalizável e mantida atualizada. Uma estratégia mal definida pode resultar em testes ineficientes e difíceis de manter.

Não Considerar Critérios de Investimento: ignorar fatores como custo inicial, fase do SDLC, duração do projeto e custo de manutenção ao decidir sobre a automação. A falta de análise desses fatores pode levar a investimentos inadequados e pouco retorno.

Não priorizar testes: não priorizar as condições de teste mais impactantes do ponto de vista do negócio. É preciso focar nos esforços de automação nos testes que trarão mais valor.

2. Aspectos Técnicos Problemáticos

Má Testabilidade do SUT: automatizar um Sistema em Teste (SUT) que não é facilmente testável, dificultando o acesso às suas interfaces. A testabilidade é essencial para uma automação eficaz.

Arquitetura e Framework de Automação Ruins: não ter uma Arquitetura de Automação de Teste (TAA) clara e um Framework de Automação de Teste (TAF) fácil de usar e manter. Uma má arquitetura e framework podem levar a dificuldades na implementação e manutenção dos testes automatizados.

Relatórios de Teste Deficientes: não gerar relatórios de teste bem definidos, dificultando a solução de problemas e o acompanhamento dos resultados. A falta de relatórios claros impede a tomada de decisões eficazes.

Não ter um plano de implantação e execução: não ter um plano claro de implantação e execução de testes, remoção de testes quando necessário e tratamento eficaz de exceções. Sem esses planos, os testes podem não ser executados corretamente, ou causar problemas na execução.

Não Documentar os Casos de Teste: não documentar adequadamente os casos de teste automatizados, tornando-os difíceis de entender e manter. A documentação clara é crucial para a manutenção e rastreabilidade dos testes.

3. Escolha e Aplicação Inadequadas da Automação

Automatizar Testes Impróprios: escolher casos de teste para automação sem considerar a viabilidade técnica, esforço de codificação, frequência de execução, repetibilidade e facilidade de manutenção. Nem todos os testes são adequados para automação.

Automatizar Testes Difíceis: tentar automatizar condições de teste difíceis, como validações de design, interações humanas complexas e restrições técnicas no nível do sistema operacional. Alguns testes são mais eficazes quando realizados manualmente.

Focar apenas em testes de interface do usuário: criar uma estratégia que dependa principalmente de testes de interface do usuário (UI), que são caros e de difícil manutenção. Uma estratégia de testes equilibrada deve incluir testes de componentes, contrato e API.

Não otimizar a distribuição de testes: não equilibrar a quantidade de testes nos diferentes níveis (componente, serviço e UI), o que pode resultar em testes lentos e caros. É preciso buscar uma distribuição em forma de pirâmide para melhor eficiência.

4. Transição e Manutenção Ineficazes

Não Monitorar os Custos: não acompanhar os custos e o crescimento da suíte de testes durante a transição para testes contínuos. O monitoramento dos custos e do crescimento da suíte de testes é necessário para uma transição eficiente.

Sobreposição Funcional: criar scripts de teste com sobreposição funcional, como incluir as mesmas etapas de login em diferentes casos de teste. Isso dificulta a manutenção e aumenta o esforço necessário.

Compartilhamento de Dados Inadequados: não gerenciar corretamente o compartilhamento de dados entre os testes, levando à duplicação ou introdução de erros. Os dados devem ser armazenados e acessados de uma única fonte.

Não Documentar Pré-Condições: não documentar e automatizar as pré-condições necessárias para a execução dos testes, levando a falhas e inconsistências. É essencial definir e automatizar as pré-condições para garantir a repetibilidade dos testes.

Não Testar os Testes Automatizados: esquecer de que a automação é um software que também precisa ser testado. Os scripts de teste devem ser testados para garantir que funcionem corretamente.

Não Refatorar a Automação: não avaliar e refatorar a solução de automação, levando ao acúmulo de dívida técnica e dificuldades na manutenção. É preciso buscar melhorias contínuas e otimizações.

Não Adaptar a TAS às Mudanças: não adaptar a Solução de Automação de Teste (TAS) às novas versões do SUT. A TAS deve ser flexível e adaptável para acompanhar as mudanças no sistema.

5. Outras Práticas Ruins

Abstração Excessiva: utilizar abstrações excessivas que tornam o código de automação difícil de entender. A abstração deve ser usada com moderação para manter o código compreensível.

Tabelas de Dados Complexas: criar tabelas de dados de teste muito grandes e complexas, dificultando a migração para outros ambientes. Os dados de teste devem ser gerenciados de forma eficiente.

Dependências de Bibliotecas: criar dependências da TAS em bibliotecas ou componentes do sistema operacional que podem não estar disponíveis em todos os ambientes. A TAS deve ser independente e portável entre diferentes ambientes de teste.

Ignorar a Importância da Manutenção: deixar de planejar a manutenção da TAS devido a atualizações no SUT. A manutenção contínua da TAS é essencial para garantir sua eficácia.

Não usar métricas: não acompanhar métricas como taxa de aprovação/reprovação, proporção de falhas e defeitos, tempo de execução da automação, cobertura funcional e de código. Essas métricas ajudam a avaliar e otimizar a TAS.

Não aproveitar os resultados dos testes para melhorar o processo: não analisar os dados gerados nos relatórios de teste para identificar tendências e fazer melhorias no SDLC. Os dados dos testes devem ser usados para tomada de decisões e melhoria contínua.

Feito por: Kellen Xavier | Contato

Passo a Passo para Adicionar o Shift-Left Testing no Processo de Qualidade

Thu, 05 Jun 2025 00:00:00 +0000

Segue um breve resumo de aplicar um mínimo de processo de qualidade em um time.

Objetivo: Adotar o uso de backlog para refinar User Stories para desenvolvimento: criar um backlog de tarefas e atividades relacionadas ao teste desde o início do ciclo de desenvolvimento.

Escrever User Stories com Critérios de Aceitação (Separar Fluxo Completo em Funcionalidades):

Identificar os requisitos de teste para cada funcionalidade através de User Stories. Incluir critérios de aceitação claros e específicos para garantir que cada funcionalidade seja testada adequadamente.

Desenvolver Casos de Teste para cada User Story: escrever casos de teste que abranjam todos os aspectos da funcionalidade descrita na User Story. Incluir casos de teste para cenários de sucesso e cenários de falha, abrangendo diferentes caminhos de uso.

Realizar Testes Estáticos e Análises Antes do Desenvolvimento: realizar revisões de código estáticas e análises de documentos para identificar potenciais problemas antes do início do desenvolvimento. Utilizar ferramentas de análise estática para identificar possíveis vulnerabilidades ou erros no código fonte.

Integrar Testes Automatizados na Esteira de Desenvolvimento: automatizar testes unitários, de integração e de regressão para garantir a estabilidade das funcionalidades desenvolvidas. Integrar os testes automatizados na esteira de desenvolvimento para execução contínua após cada alteração no código.

Implementar Revisões Contínuas e Feedback Iterativo: realizar revisões contínuas de código e funcionalidades em desenvolvimento para identificar e corrigir problemas rapidamente. Fornecer feedback iterativo aos desenvolvedores e equipe de qualidade para melhorar o processo de desenvolvimento.

Documentar e Analisar Métricas de Qualidade e Desempenho: registrar métricas de qualidade, cobertura de testes e desempenho do software para avaliar a eficácia dos testes e identificar áreas de melhoria. Analisar regularmente os resultados dos testes para ajustar estratégias de teste conforme necessário.

Passo a Passo para Dev Teste (Baseado na Pirâmide de Testes)

Thu, 05 Jun 2025 00:00:00 +0000

1. O que é Dev Teste?

Antes de enviar um card para o status QA, o time de desenvolvimento deve validar o código aplicando testes sistemáticos em diferentes camadas (unitário, integração, funcional). Isso reduz retrabalho e melhora a qualidade do software.

2. Estruturando os Testes

A pirâmide de testes sugere:

Leitura das US/Histórias de Usuário - Leitura dos testes que compõem a US e os critérios de aceite.
Testes Unitários (Base da pirâmide): Validam partes isoladas do código (ex.: funções, métodos).
Testes de Integração (Meio da pirâmide): Garantem que diferentes partes do sistema interagem corretamente.
Testes Funcionais/E2E (Topo da pirâmide): Validam o fluxo completo de usuário.

3. Como aplicar no cenário do bug?

Passo 1: Teste Unitário

✅ Criar testes para a query que busca o domínio correto no banco.

Verificar se a query está retornando apenas domínios do tipo blog.
Garantir que não seja selecionado o primeiro domínio indiscriminadamente.

Exemplo de teste unitário (PHPUnit):

public function testBuscaDominioCorreto() {
 $dominio = new DominioRepository();
 $resultado = $dominio->buscarPorTipo('blog');
 $this->assertNotEmpty($resultado);
 $this->assertEquals('blog', $resultado->tipo);
}

Passo 2: Teste de Integração

✅ Validar se o job SaveSessionsUrlAnalyticsJob.php está salvando corretamente os dados na tabela analytics_session_urls.

Simular uma execução do job com diferentes cenários de domínio.
Checar se os dados são gravados corretamente.

Passo 3: Teste Funcional (Opcional, caso necessário)

✅ Executar a funcionalidade completa e validar se os relatórios de RPS exibem os dados esperados.

4. Como seguir no Time?

Antes de abrir um bug, garantir que o código passou pelos testes unitários e de integração.
Adotar um fluxo de Dev Teste: Desenvolvedor faz – Code Review – Dev Teste – QA.
Registrar evidências dos testes, ter PR, evitando repassar códigos sem verificação prévia.

Como adicionar Evidências:

Teste executando em ambiente dev: os testes validados localmente, mesmo utilizando docker, não é válido, pois vários fatores de ambiente e rede não são validados nas conformidades. Gerando um falso positivo. Testes locais se enquadram por exemplo em outros tipos de testes, exemplo citado aqui os unitários.

Ambiente de dev;
Capturas de telas caso for testes do tipo End-to-end;
Ter PRs no card;
Validar os cenários dos testes no card, caso não tenha, avise o QA responsável;

Quando se tem [data-cy="seu-elemento-x"], precisa ainda instalar o Testing Library?

Thu, 05 Jun 2025 00:00:00 +0000

Segue exemplo abaixo de um código que usa o data-cy para capturar elementos nas automação E2E com Cypress.

O uso do Testing Library é interessante quando não temos o elemento definido no E2E, ou seja, sem o data-test/cy. Para que o Testing Library reconheça dentro da automação, precisamos que, não tenha no elemento que vai ser buscado pelo cypress o data-cy e então, o Testing Library o reconhece buscando pelo padrão findByText.('Sua palavra mágica').click();

Opção 1: Configurar no arquivo setup-tests.js (Cypress v10+):

Crie o arquivo setup-tests.js: se você ainda não tem esse arquivo, crie-o na raiz do seu projeto ou em outro local especificado na sua configuração do Cypress (veja a documentação para detalhes).
Configure o atributo testIdAttribute:

// cypress/support/setup-tests.js
import { configure } from '@testing-library/cypress';

configure({ testIdAttribute: 'data-cy' })

Opção 2: Configurar diretamente no teste (Cypress v9 e anteriores): se você estiver usando uma versão mais antiga do Cypress, você pode configurar a biblioteca diretamente no seu arquivo de teste:

// cypress/e2e/seu_teste.cy.js
import { configure } from '@testing-library/cypress';

// ...

describe('Seus testes', () => {
 before(() => {
 configure({ testIdAttribute: 'data-cy' })
 })

 // ... seus testes aqui
})

Opção 3: Criar um novo comando:

Crie um comando personalizado para usar findByTestId sempre com o data-cy:

// cypress/support/commands.js
Cypress.Commands.add('findByCy', (value, options) => {
 cy.findByTestId(value, { ...options, testIdAttribute: 'data-cy'})
})

Referências:

Testing Library

https://github.com/testing-library/cypress-testing-library/blob/97939da7d4707a71049884c0324c0eda56e26fc2/cypress/integration/find.spec.js

Cypress and Testing Library Link

Quais ferramentas que estudamos você já experimentou e quais pretende experimentar para promover a inovação em seu ambiente de desenvolvimento de software?

Thu, 24 Apr 2025 00:00:00 +0000

Eu estou aplicando o estudo com a estúdio de musculação que frequento, aqui na Zona Norte de Porto Alegre. Solicitei permissão ao dono da academia — que está iniciando o negócio desde janeiro de 2025 — para aplicar estes estudos e desenvolver um projeto em um negócio real, baseado em necessidades reais.

O projeto seria: criar uma landing page para o estúdio, aplicando as técnicas de Design Thinking e os estudos vistos em aula de Inovação e Empreendedorismo — Inovação e Empreendedorismo - Web 03.

Início do projeto: acompanhei a abertura do estúdio de musculação desde janeiro de 2025, e, desde então, fui a aluna — junto com outro amigo próximo — a treinar no novo local. Primeira coisa que perguntei ao dono foi: como vai funcionar a academia? Vai ter horários flexíveis? Quem vai treinar no local?

Visando isso, procurei entender melhor, conversando com o dono do negócio — Academia Estúdio de Musculação — e levantei essas perguntas. Outro ponto em destaque é que eu treino lá desde o início — por conhecer o dono, fui a aluna-teste do local 😂 — o que acabou agregando ao projeto, pois tive pessoalmente a visão de alguns pontos importantes.

1. Empatia (entender o problema sob o ponto de vista do usuário)

Como sou usuária da academia, enfrentei alguns problemas, como: quais são os valores? Como funcionam os pacotes com acompanhamento nutricional? Há parceria com lojas de suplementos? Quanto custa o whey protein? Entre outros. Percebi que os alunos que vieram depois também tinham essas dúvidas. Quando fui recomendar a academia, também tive dificuldades para compartilhar o endereço e informar os valores de cabeça — sabia apenas o que utilizava, no caso o TotalPass. Não havia um local centralizado para consultar essas informações.

2. Definição (refinar o problema)

Com base nisso, organizei todas as informações que tinha em mãos e conversei com o dono do negócio para entender e refinar as questões. Utilizando técnicas de design thinking, apliquei o Value Proposition Canvas para não deixar tudo apenas dentro da minha cabeça e também compartilhar com o envolvido — o dono do negócio. Segue abaixo:

Utilizei também o ChatGPT para estruturar de forma detalhada e organizar todas as informações nos devidos lugares, a fim de não perder o foco nos detalhes.

ChatGPT

Abaixo, utilizei como um checklist das informações que já havia mapeado, para manter a organização e não me perder no processo:

Para tornar a entrevista mais clara, resolvi criar um formulário para enviar ao dono do negócio responder; isso corresponde às “Definições” citadas e aplicadas aqui.

3. Ideação

Visto acima no ChatGPT temos o seguinte:

Vou mudar alguns pontos que acho importante reorganizar com base nas necessidades vistas lá no mapeamento com o Value Proposition Canvas.

Brainstorm para soluções da Landing Page: EDITADA

Blocos organizados: Quem somos | Planos Diferenciais | Estrutura | Agendamento - Contato | FAQ
Botão direto para WhatsApp
Fotos do ambiente com qualidade - passando credibilidade
Chamada de Ação: destaque no diferencial do negócio, avaliação gratuita física.
FAQ rápido com as dúvidas levantadas pelos novos usuários (isso vai ser coletado no formulário).

4. Prototipagem

Eu sou péssima com Design 😭 então utilizei a ferramenta do Canva para dar vida a isso, e não deixar isso ser meu impedimento.

OBS: vamos relembrar brevemente da aula ao vivo sobre “legal, vamos lá fazer isso”

EU não sei design

5. O Teste

Criação do protótipo: como citado, este protótipo foi feito no Canva, com o objetivo de tornar visual todo o planejamento do Value Proposition Canvas. Abaixo, segue a sequência das telas:

Incluir parte dos serviços que falta para responder do formulário.

Foi desenvolvido este rascunho inicial do protótipo, com o objetivo de validar as necessidades do proprietário do negócio em relação ao atendimento de seus clientes.

A construção do protótipo possibilitou a identificação de pontos relevantes e, sobretudo, representou um avanço significativo ao transformar ideias em uma versão prática e visual. O processo de desenvolvimento mostrou-se ágil e funcional, permitindo direcionar os próximos passos.

Como continuidade, propõe-se a realização de novos testes com usuários e a execução do site em ambiente real, a fim de avaliar se as funcionalidades implementadas atendem às necessidades previamente mapeadas.

Protótipo Canva: link

Pesquisa em Formulário para melhor análise e entendimento

2. Questionário baseado no Design Thinking

(Para usar na fase Empatia + Definição com o cliente)

Perguntas sobre o Negócio

Como você descreveria a missão e os valores do seu estúdio?
Qual a principal diferença do seu estúdio para outras academias?
Quais serviços ou vantagens você mais gostaria de destacar para novos alunos?
Qual sentimento ou impressão você gostaria que o aluno tivesse ao visitar o estúdio?

Perguntas sobre os Clientes

Quem são seus principais clientes hoje? (idade, perfil, objetivos)
O que seus alunos costumam elogiar mais no seu serviço?
Quais dúvidas ou receios os novos alunos mais demonstram quando entram em contato?
O que já ouviu de feedback positivo ou negativo sobre a experiência na academia?

Perguntas sobre Comunicação

Hoje, quais canais você usa para divulgar seu estúdio? (Instagram, WhatsApp, indicações, etc.)

Perguntas sobre Serviços Extras

Como funciona a parceria com a nutricionista? (valores, agendamento, diferenciais)
Como funciona a parceria com suplementos? (marcas, descontos, vantagens)

Perguntas sobre Experiência

Que tipo de benefícios você gostaria de oferecer para novos alunos? (promoções, aula experimental, desconto na 1ª mensalidade)

Links de Referência

Confira o Protótipo do site: https://site-academia-app.vercel.app/

Pesquisa de Sites | Mercado com foco em Academias - Link

Referências de Estudos:

Link sobre qualidade do produto - Rian Dutra: LinkedIn
Livro: Não me faça pensar - Steve Krug
Livro: O Design do dia a dia - Donald A. Norman
Livro: Value Proposition Design - pág: 142, 228, 232
Pós-graduação Unisinos - Aulas Inovação e Empreendedorismo com a Profª Rosemary Francisco
Ferramentas: Canva, Vercel App para deploy do site
Como identificar e resolver pontos de dor (pain points) do usuário no UX Design
Como usar storytelling no UX Design

Pesquisa de Sites | Mercado com foco em Academias

Thu, 17 Apr 2025 00:00:00 +0000

Estudos e Análise Geral de Sites de Academias de Atividades Físicas

Essa breve pesquisa foi realizada para um protótipo de site no nicho de academias, com o objetivo de divulgar um estúdio de academia, focado em objetivos pessoais, voltado a pessoas que não gostam de academias lotadas e sem atenção de instrutores, priorizando a pessoalidade no atendimento.

1. Padrão dos sites de academias:

Normalmente, sites de academias são construídos com foco em três grandes pilares:

Apresentação de serviços: mostrar os tipos de treinos (musculação, funcional, spinning, pilates, yoga etc.).
Captação de novos alunos: destacar promoções, planos, aulas experimentais e formulários rápidos de contato.
Prova social: exibir fotos reais, depoimentos de alunos e resultados alcançados.

2. Estrutura comum que aparece nesses sites:

Página inicial chamativa: com imagens de pessoas treinando, mensagens motivacionais, e destaque para diferenciais da academia (24h, avaliação física grátis, estacionamento, etc.).
Planos e preços: muita gente procura rapidamente o valor da mensalidade — alguns sites mostram, outros obrigam o usuário a preencher um formulário primeiro (o que pode gerar abandono).
Agenda de aulas coletivas: algumas academias disponibilizam a programação semanal de aulas no próprio site.
Localização: um mapa integrado (Google Maps) é quase obrigatório, já que localização é fator decisivo.
Área do aluno: alguns sites mais modernos oferecem login para alunos acompanharem treinos, pagamentos e evolução física.
Blog ou dicas de saúde: pouco usado, mas quando existe, ajuda no SEO (atrair mais visitantes via Google).
Chat ou WhatsApp direto: muitos sites têm botões flutuantes para contato rápido via WhatsApp.

3. Comportamento de quem procura sites de academias:

Busca por praticidade: as pessoas querem informações rápidas. Sites lentos ou com excesso de formulários perdem usuários.
Comparação: é comum o usuário abrir vários sites de academias próximas para comparar preços, estrutura e diferenciais.
Busca por credibilidade: fotos de qualidade, estrutura física mostrada e depoimentos reais aumentam a confiança.
Interesse em benefícios imediatos: promoções de matrícula grátis, descontos na primeira mensalidade ou aula experimental gratuita costumam ser gatilhos decisivos.

4. SEO e tráfego:

Boa parte das buscas vem de palavras-chave locais, como “academia em [nome da cidade/bairro]” ou “academia perto de mim”.
Sites otimizados para essas buscas locais têm muito mais chances de serem encontrados organicamente (sem precisar pagar anúncios).

5. Design e tendências atuais:

Visual clean e moderno (nada poluído).
Vídeos curtos na homepage mostrando o ambiente.
Integração com redes sociais (principalmente Instagram).

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.

Lady{de}bug – Lady{de}bug

Linux Básico

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

Configurando o SonarQube Localmente

Opção 1: Remover o container existente

Opção 2: Substituir o container automaticamente

Opção 3: Verificar o status do container

Executar o SonarQube localmente

1. Pré-requisitos

2. Baixando e rodando o SonarQube

Configuração do SonarQube

Gerando um Token de autenticação

Instalando o SonarScanner

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

Configurando o SonarScanner no Projeto

Problemas encontrados

O que significa esse erro?

Refactor: Blog

Análise do repositório notion-blog

1. Visão geral

2. Stack e dependências

3. Estrutura

4. Como funciona (fluxo de dados)

5. Pontos fortes

6. Problemas e riscos que encontrei

Segurança / prático

Dependências não declaradas

Restos do template original (branding inconsistente)

Código potencialmente quebrado/frágil

Qualidade / manutenção

7. Recomendações priorizadas

Correções no Blog

Bot Planner - Projeto para acompanhamento do desenvolvimento pessoal

Primeira Fase do desenvolvimento

Organização do Bot

Plano de Testes Bot Planner

Todos

Funcionalidades Com Testes

Comportamento Esperado Após Ajustes

Visão Geral de Testes com Discord

Updates e Melhorias

Fluxo De Produção

Crush: agente de codificação com (TUI/UI) - Configurações de Ambiente em Windows

Objetivo principal

Segue abaixo o primeiro teste em ambiente Windows

A usabilidade em uma máquina com OS Windows

Criar variável de ambiente

Para os usos práticos

Liste exemplos comuns de software

Trabalho uso VPNs

Aplicativos

Navegadores

Linguagens Desenvolvimento

Documentação README.md

Registry com Backup

PRIORIDADES DE CORREÇÃO PARA OS SCRIPTS EXISTENTES

Referências

Cola do BPMN

Start events (iniciam o processo)

Intermediate events (no meio do fluxo)

Boundary events (colados numa tarefa/subprocesso)

Especiais

End events (encerram o caminho)

Aprofundamento sobre: Terminal Comandos Git - Parte 1

Alguns Conceitos Base Importantes

O que é um terminal

Fontes sobre Terminais - Lista de leituras e vídeos

Sistema de arquivos e navegação

Comandos geralmente mais utilizados

GIT

Brevemente sobre Pull Request

Alterações feitas

Sobre git stash

As práticas ruins que devem ser evitadas em uma automação de testes

1. Definição e Planejamento Inadequados

2. Aspectos Técnicos Problemáticos

3. Escolha e Aplicação Inadequadas da Automação

4. Transição e Manutenção Ineficazes

5. Outras Práticas Ruins

Passo a Passo para Adicionar o Shift-Left Testing no Processo de Qualidade

Análise do repositório `notion-blog`