Forem: Isac Canedo

Pare de usar isEmpty() e isBlank() em seus Controllers Spring Boot

Isac Canedo — Fri, 13 Mar 2026 13:21:20 +0000

É comum encontrarmos em projetos Spring Boot validações como isEmpty(), != null ou isBlank() aplicadas diretamente nos métodos dos Controllers. Embora pareça uma solução rápida, essa prática é um code smell que compromete a escalabilidade e a manutenção do software.

Neste artigo, vamos entender por que você deve evitar essa abordagem e quais são as alternativas alinhadas às boas práticas de engenharia de software.

O problema da lógica no Controller

O papel fundamental de um Controller, seguindo princípios de Clean Architecture e MVC, é a orquestração: receber a requisição, realizar o unmarshalling dos dados e delegar a execução para a camada de serviço ou domínio.

Quando inserimos verificações manuais de strings ou nulidade no Controller, ferimos diversos princípios:

1 - Violação do SRP (Single Responsibility Principle): O Controller passa a acumular responsabilidades de validação e decisão que não lhe pertencem.
2 - Acoplamento e Repetição: Validações feitas no Controller não são reaproveitáveis por outros pontos de entrada (como jobs batch ou consumidores de mensageria).
3 - Dificuldade em Testes de Unidade: Testar a lógica de negócio exige subir o contexto do Spring MVC ou mockar objetos de requisição desnecessariamente.

Melhores Práticas e Alternativas

1. Bean Validation (JSR 380)
A forma mais elegante de lidar com validações de entrada no Spring é através das annotations do hibernate-validator. Isso mantém o código limpo e declarativo.

Annotations comuns: @NotBlank, @NotNull, @Size, @Min, @Email.

2. Validação Customizada
Para regras que dependem de condições específicas, prefira criar Validators customizados ou utilizar a camada de Service.

Exemplo Prático
❌ Abordagem Incorreta (Anti-pattern)
Neste cenário, o Controller está "poluído" com verificações manuais de estado.
@GetMapping("/{id}") public ResponseEntity<?> get(@PathVariable String id) { if (id == null || id.isBlank()) { return ResponseEntity.badRequest().body("ID inválido"); } return ResponseEntity.ok(service.findById(id)); }

✅ Abordagem Recomendada
Utilizando as facilidades do ecossistema Spring para manter o método enxuto e focado.

@GetMapping("/{id}") public ResponseEntity<?> get(@PathVariable @NotBlank(message = "O ID é obrigatório") String id) { return ResponseEntity.ok(service.findById(id)); }

Nota: Para que as annotations funcionem em parâmetros de @PathVariable ou @RequestParam, lembre-se de adicionar a anotação @Validated no nível da classe Controller.

Conclusão
Tratar o Controller como uma camada de passagem e delegar as validações para os locais corretos (DTOs com Bean Validation ou Service Layer para regras complexas) resulta em um código:

Mais legível;
Fácil de testar;
Alinhado aos padrões de mercado (Clean Code).

E você, como tem estruturado as validações nos seus projetos Spring? Deixe seu comentário abaixo!

java #springboot #backend #cleancode #architecture

🔐 Por que a AWS exige chmod 400 ao usar sua chave .pem?

Isac Canedo — Thu, 12 Mar 2026 23:47:05 +0000

⚠️ Esqueceu o chmod 400? Sua conexão SSH pode estar em risco!

Se você já criou uma instância EC2 na AWS e fez o download da chave privada (.pem), com certeza se deparou com a orientação:

bash
[ chmod 400 sua-chave.pem ]

🤔 Mas afinal, por que isso é tão importante? O que o chmod 400 faz?

Esse comando define as permissões da chave .pem para que somente o dono do arquivo possa lê-lo. Ou seja, impede que outras pessoas ou processos do sistema tenham qualquer acesso.

📌 Detalhadamente:
4 = Permissão de leitura para o dono
0 = Nenhuma permissão para grupo ou outros usuários

🚨 E se você não fizer isso?
Se a sua chave .pem estiver com permissões mais amplas (por exemplo, leitura para todos), o OpenSSH recusa a conexão por considerar a chave insegura.

Resultado:
❌ “Permissions are too open”
❌ “Unprotected private key file”

Isso acontece porque a segurança da conexão SSH depende da exclusividade do acesso à chave privada.

Permissões incorretas representam uma ameaça real à integridade do seu ambiente de nuvem.

🛡️ Segurança não é detalhe

Esse pequeno comando protege você contra:
✔️ Acesso não autorizado
✔️ Vazamentos acidentais
✔️ Configurações inseguras

💡 Dica para quem usa Windows + WSL ou Git Bash:
Você pode precisar navegar até o diretório da chave e rodar:
bash
[ chmod 400 caminho/sua-chave.pem ]

Ou, no Windows, configurar as permissões de leitura via interface gráfica clicando com o botão direito > Propriedades > Segurança.

🔁 Automatize boas práticas de segurança desde o primeiro provisionamento.

🧠 Lembre-se: a segurança começa nos detalhes e o [ chmod 400 ] é um deles!

Clean Architecture: criando sistemas robustos, flexíveis e testáveis

Isac Canedo — Thu, 12 Mar 2026 23:35:09 +0000

A Clean Architecture, ou Arquitetura Limpa, é uma abordagem de design de software que busca criar sistemas independentes de frameworks, bancos de dados, interfaces de usuário e detalhes de infraestrutura.

👉 Popularizada por Robert C. Martin (Uncle Bob), essa arquitetura protege a lógica de negócio das mudanças externas, seguindo a Regra da Dependência:

🔁 as dependências do código devem sempre apontar para o centro da arquitetura.

Camadas da Clean Architecture (representadas por círculos concêntricos):

1️⃣ Entidades (Entities)
🔹 Camada mais interna, responsável pelas regras de negócio da empresa.
🔹 Exemplo: uma classe Pedido com métodos como calcularValorTotal() ou adicionarItem().

2️⃣ Casos de Uso (Use Cases)
🔹Define o fluxo da aplicação e orquestra entidades.
🔹 Exemplo: CriarPedidoUseCase que valida dados, instancia um pedido e salva no repositório.

3️⃣ Adaptadores de Interface (Interface Adapters) - Faz a ponte entre camadas internas e externas.
Inclui:
🔹Controladores (ex: REST controllers)
🔹Apresentadores (ex: formatadores para UI)
🔹Gateways (ex: repositórios para banco de dados)

4️⃣ Frameworks e Drivers
Camada mais externa, contendo:
🔹Frameworks Web (Spring, .NET)
🔹Bancos de dados (PostgreSQL, MongoDB)
🔹Interfaces de usuário (Angular, React)
Essa camada pode ser substituída sem afetar a lógica central.

Benefícios da Clean Architecture:

✅ Independência
Troque banco de dados, framework ou UI sem reescrever regras de negócio.

✅ Testabilidade
Teste regras isoladamente, sem necessidade de banco real ou interface gráfica.

✅ Manutenibilidade
Código mais limpo, organizado e fácil de evoluir.

✅ Flexibilidade
Mudanças de requisitos têm impacto mínimo no core do sistema.

📌 A Clean Architecture não é só uma moda. É uma forma sólida e disciplinada de construir software duradouro, escalável e com foco no domínio do negócio.

🚀 Ideal para projetos complexos que precisam sobreviver ao tempo e à mudança.

"Ownership" é um conceito que vai além da posse legal...

Isac Canedo — Thu, 12 Mar 2026 23:32:53 +0000

"Ownership" é um conceito que vai além da posse legal e refere-se principalmente ao "sentimento de dono" ou "mentalidade de dono".

Muitos profissionais são responsáveis, mas poucos demonstram a verdadeira hashtag#AtitudeDeDono. E é justamente nessa lacuna que a hashtag#Liderança e o crescimento de carreira acontecem.

Se você quer sair da mentalidade de executor e se tornar um agente de impacto, foque nestes 4 Pilares de Ownership que realmente fazem a diferença em equipes de alta performance:

1️⃣ Troque o “Eu fui cobrado” pelo “Eu me antecipei.” O profissional com ownership não espera o alerta vermelho do gestor, ele cria seus próprios dashboards de risco, prevê gargalos e inicia a mitigação antes do problema se tornar crítico. Ele é a fonte da solução, não a vítima da circunstância;
2️⃣ Foque no resultado de negócio, não na task list. Não basta dizer: “A API foi entregue.” Pergunte: “Essa API reduziu a latência para o cliente final? Aumentou a conversão? Economizou recursos da empresa?”
Conecte cada entrega técnica a um valor de negócio tangível;
3️⃣ Não jogue para a cultura do “Não é minha área.” Em sistemas complexos como os de hashtag#Integração ou hashtag#Cloud é fácil apontar o dedo para a dependência vizinha. O engenheiro ou arquiteto com ownership assume a responsabilidade de coordenar a solução ponta a ponta, mesmo que não codifique tudo. Ele resolve o problema, não o repassa;
4️⃣ Trate o orçamento da empresa como o seu próprio.
Isso significa questionar o uso de recursos caros, propor soluções mais eficientes e buscar reuso. Cada decisão técnica da escolha de um serviço em cloud a um padrão de desenvolvimento deve refletir visão de custo-benefício e escalabilidade a longo prazo.

💡 O crescimento de carreira acontece no espaço entre o seu job description e sua hashtag#Ownership.

👉 Qual desses pilares você tem praticado mais ativamente?

Amazon Q: Revolucionando a Produtividade e a Inovação Empresarial

Isac Canedo — Thu, 12 Mar 2026 23:29:46 +0000

O Amazon Q representa uma nova era na integração entre IA generativa e operações corporativas, redefinindo a forma como times técnicos e de negócios interagem com dados, sistemas e processos.

💻 Para Desenvolvedores
O Amazon Q atua como um copiloto técnico completo:
🔹Gera e revisa código em múltiplas linguagens;
🔹Realiza testes automatizados e detecção de vulnerabilidades;
🔹Analisa dependências e propõe otimizações de arquitetura;
🔹Explica erros e aplica correções contextuais diretamente no repositório.
Tudo isso integrado ao ecossistema AWS, acelerando o DevCycle com segurança e consistência.

🧠 Para Usuários de Negócios
Através de linguagem natural, o Amazon Q permite que profissionais não técnicos consultem dados empresariais, criem relatórios e automatizem fluxos de trabalho sem precisar de conhecimento em código.
Imagine um analista pedindo: “Crie um dashboard com as vendas do último trimestre e destaque variações anormais por região” e o Amazon Q entrega a análise pronta em minutos.

🔍 Poder e Contexto Unificados
O Amazon Q conecta-se aos repositórios corporativos (documentação interna, políticas, código-fonte, produtos, entre outros), aplicando indexação semântica e resumo inteligente para fornecer respostas contextualizadas e acionáveis.

🛡️ Segurança e Governança Avançadas
Construído sobre o Amazon Bedrock, o Amazon Q utiliza roteamento inteligente para selecionar o foundation model (FM) ideal para cada tarefa equilibrando custo, desempenho e precisão.
Além disso, herda toda a camada de segurança, controle de acesso e compliance do Bedrock:

➡️ Se o usuário não tem permissão fora do Amazon Q, ele também não terá dentro.

⚙️ Inovação com Escalabilidade
Com o Amazon Q, sua empresa pode desenvolver aplicações generativas sob medida, automatizando funções críticas e liberando tempo das equipes para atividades de maior valor estratégico.

A IA generativa finalmente chega ao ambiente corporativo com governança, privacidade e eficiência em escala.

💬 Como você enxerga o impacto do Amazon Q na sua operação?