Forem: Adriano P. Araujo

HTML para Devs Backend: Ou Como Aprender que Nem Tudo é uma Div

Adriano P. Araujo — Thu, 04 Dec 2025 12:12:43 +0000

"Ah, HTML? Isso é fácil. É só um monte de tags. Coloca um div aqui, um div ali, um div em cima de outro div... pronto, frontend feito."

Se você já ouviu (ou disse) algo assim, este artigo é para você.
Vamos falar de umas verdades que ninguém te conta quando você sai do backend para mexer no front.

Você manda bem em Go, Node.js, Python, Java. Domina bancos de dados, otimiza queries, cria APIs RESTful que escalam, lida com autenticação, criptografia e concorrência. Pode debugar um problema de race condition em produção enquanto toma um café.

Aí surge aquele projeto interno, aquele MVP, ou pior, a única pessoa do frontend da equipe pede demissão. Você pensa: "Tranquilo, é só HTML e CSS. Vou resolver em uma tarde."

Spoiler: Você vai descobrir que HTML é um dos negócios mais subestimados da programação. E não, a resposta nunca é "mais uma <div>".

O meme da `<div>` que vira pesadelo real

<!-- O "estilo backend" de estruturar uma página -->
<div class="container">
  <div class="header">
    <div class="logo">Logo</div>
    <div class="nav">
      <div class="nav-item">Home</div>
      <div class="nav-item">About</div>
      <div class="nav-item">Contact</div>
    </div>
  </div>
  <div class="content">
    <div class="post">
      <div class="post-title">Meu Primeiro Post</div>
      <div class="post-body">Conteúdo aqui</div>
    </div>
  </div>
  <div class="footer">
    <div class="footer-content">© 2025</div>
  </div>
</div>

Funciona? Tecnicamente, sim. O navegador engole qualquer coisa. Parece aceitável? Provavelmente. Mas aí você tenta usar o teclado para navegar e nada acontece. Um colega cego tenta acessar com leitor de tela e ouve uma sopa de "grupo, grupo, grupo". O Google tenta indexar seu conteúdo e não consegue distinguir o menu do artigo.

Acessibilidade? Inexistente.
SEO? Comprometido.
Manutenção daqui a 6 meses? "Que diabos esse monte de div fazia mesmo?"

HTML não é sobre aparência, é sobre significado

A mentalidade que salva vidas (ou pelo menos projetos) é esta: HTML é uma linguagem de marcação, não de estilização. Sua função principal é comunicar significado e estrutura.

Quando você usa <header>, <nav>, <main>, <article>, <footer>, você não está só organizando visualmente. Você está passando informação crucial:

Para o navegador: "Aqui começa a navegação principal, destaca isso para navegação por teclado."
Para o leitor de tela: "Este é o conteúdo principal da página, vá direto para ele."
Para o Google: "Este bloco é um artigo independente, este outro é um menu."

<!-- O mesmo layout, agora comunicando significado -->
<header>
    <a href="/" class="logo">Logo</a>
    <nav aria-label="Principal">
        <ul>
            <li><a href="/">Home</a></li>
            <li><a href="/sobre">Sobre</a></li>
            <li><a href="/contato">Contato</a></li>
        </ul>
    </nav>
</header>

<main>
    <article>
        <h1>Meu Primeiro Post</h1>
        <p>Conteúdo significativo aqui.</p>
    </article>
</main>

<footer>
    <p>&copy; 2025</p>
</footer>

Percebe a diferença? É a diferença entre um monte de tijolos soltos e uma casa com portas, janelas e cômodos identificados.

Os 5 elementos que você está usando errado (e como consertar)

1. `<button>` vs. a tragédia do `<div onclick="">`

<!-- ❌ O clássico erro -->
<div class="btn" onclick="submitForm()">Enviar Formulário</div>

<!-- ✅ O caminho correto -->
<button type="button" onclick="submitForm()">Enviar Formulário</button>

Por quê? Um <button> é, por padrão:

Focável: Você chega nele pressionando Tab.
Acionável: Você o ativa com Enter ou Espaço.
Semântico: Leitores de tela anunciam "botão".
Estados nativos: Tem :hover, :focus, :active e :disabled de graça.

A <div> não é nada disso. Transformá-la em botão é como usar um parafuso como martelo: funciona até você precisar de um martelo de verdade.

2. A conexão perdida: `<label>` e `<input>`

<!-- ❌ O que todo mundo faz no começo -->
<div>
    <span>Email:</span>
    <input type="email" id="userEmail">
</div>

<!-- ✅ A maneira que funciona para todos -->
<label for="userEmail">Email:</label>
<input type="email" id="userEmail">

A mágica do <label>: Clicar no texto "Email:" foca automaticamente no campo. Isso é um superpoder para usabilidade em telas touch e para pessoas com dificuldades motoras. Além disso, leitores de tela leem o label quando o input recebe foco, dando contexto.

3. `<form>`: não é um container qualquer

<!-- ❌ A reinvenção da roda (com JavaScript extra) -->
<div id="formContainer">
    <input type="text" id="nome">
    <input type="email" id="email">
    <div class="btn" onclick="enviarDados()">Cadastrar</div>
</div>

<!-- ✅ Usando a ferramenta certa para o trabalho -->
<form onsubmit="return handleSubmit(event)">
    <label for="nome">Nome:</label>
    <input type="text" id="nome" name="nome" required>

    <label for="email">Email:</label>
    <input type="email" id="email" name="email" required>

    <button type="submit">Cadastrar</button>
</form>

O poder nativo do <form>:

Pressionar Enter em qualquer campo submete o formulário.
Validação básica (required, type="email") funciona antes do JavaScript carregar.
O estado :invalid do CSS te ajuda a mostrar erros.
É o jeito universal e esperado de coletar dados.

4. `<img alt="">`: o atributo mais negligenciado do mundo

<!-- ❌ O padrão (infeliz) -->
<img src="grafico-vendas-q1.png">

<!-- ✅ O mínimo do profissionalismo -->
<img src="grafico-vendas-q1.png" alt="Gráfico de linhas mostrando crescimento de 15% nas vendas no primeiro trimestre">

O alt não é um campo opcional para "deficientes visuais". Ele é:

O texto de fallback quando a imagem não carrega.
A descrição que o Google usa para entender seu conteúdo.
A informação que um leitor de tela lê em voz alta.
Contexto para qualquer pessoa em uma conexão lenta que desabilitou imagens.

Escreva como se estivesse descrevendo a imagem para alguém por telefone.

5. `<a href="">` vs. `<button>`: a separação das coisas

Essa é simples, mas crucial:

Use <a href="/pagina"> para navegação. Leva o usuário para outro lugar (página, seção, site externo).
Use <button> para ações que acontecem na página atual (abrir modal, filtrar lista, adicionar ao carrinho).

Por quê? Um link pode ser aberto em nova aba (Ctrl+Click), pode ser favoritado e tem um comportamento de navegação padrão. Um botão não. Misturar os dois é confundir o usuário e ferir princípios básicos da web.

Atributos que são superpoderes secretos

`aria-*`: o manual de instruções para leitores de tela

Quando você precisa usar uma <div> para fazer algo customizado (um botão de fechar personalizado, um widget complexo), os atributos ARIA entram em cena para consertar a semântica.

<!-- Um "X" estilizado que precisa ser um botão funcional -->
<div class="btn-fechar"
     role="button"           <!-- "Eu me comporto como um botão" -->
     aria-label="Fechar modal" <!-- O texto que o leitor de tela vai ler -->
     tabindex="0"            <!-- "Eu posso receber foco pelo teclado" -->
     onclick="fecharModal()">
    &times;
</div>

<!-- Mas sério, na maioria das vezes, só use: -->
<button class="btn-fechar" aria-label="Fechar modal" onclick="fecharModal()">
    &times;
</button>

`input type=""`: muito mais que validação

Cada type aciona comportamentos específicos e otimiza a experiência, principalmente em dispositivos móveis.

<input type="email"> <!-- Mostra teclado com @ em mobiles -->
<input type="tel">   <!-- Mostra teclado numérico -->
<input type="date">  <!-- Abre um date picker nativo -->
<input type="search"> <!-- Aparece com estilo de busca e botão de limpar -->

`data-*`: a ponte segura entre HTML e JavaScript

É a forma padrão de embutir dados no HTML sem bagunçar classes ou IDs.

<div class="produto"
     data-id="789"
     data-preco="29.90"
     data-categoria="eletronicos">
    Fones de Ouvido
</div>

// No seu JS, acesse de forma limpa
const produto = document.querySelector('.produto');
console.log(produto.dataset.id); // "789"
// Facilita passar dados para event handlers

A verdade que dói

HTML é fácil de escrever, mas difícil de dominar.

Você pode passar uma carreira inteira escrevendo HTML "funcional" sem nunca escrever HTML bom. A diferença entre um e outro não é só tecnológica, é filosófica. É a diferença entre pensar em "páginas" e pensar em "experiências"; entre pensar em "usuários" e pensar em "pessoas".

No backend, um endpoint mal feito afeta uma aplicação. No frontend, um HTML mal feito pode excluir uma pessoa.

Conclusão: Pare de tratar HTML como um detalhe

O HTML é a fundação sobre a qual toda a web é construída. Você pode ser um arquiteto de microsserviços, um mestre dos algoritmos ou um engenheiro de foguetes, mas se o HTML da sua página é uma pilha de <div> sem significado, a experiência do usuário vai ranger na base.

A próxima vez que você for tocar no frontend, lembre-se: sua missão não é fazer "aparecer na tela". Sua missão é construir uma interface que comunique, que incluza e que funcione para todos.

É um trabalho mais desafiador do que parece.

Bônus: Para onde ir agora ?

Se o artigo não foi suficiente, abaixo tem algumas fontes legais para consultar:

MDN Web Docs (HTML): O clássico
WebAIM: O guia definitivo para acessibilidade na web. Comece pelo Checklist de Acessibilidade.
HTML - Living Standard: A especificação oficial. É densa, mas é a fonte da verdade quando há dúvidas profundas.
The A11Y Project: Recursos, artigos e patterns de acessibilidade em um formato mais digerível.

Just Build It Right.

[Boost]

Adriano P. Araujo — Tue, 02 Dec 2025 21:36:15 +0000

Segurança em Smart Contracts (2025): A Evolução dos Ataques e a Nova Fronteira da Defesa

Adriano P. Araujo ・ Dec 2

Segurança em Smart Contracts (2025): A Evolução dos Ataques e a Nova Fronteira da Defesa

Adriano P. Araujo — Tue, 02 Dec 2025 13:09:59 +0000

"Erros em smart contracts não são mais apenas bugs de código; são portas abertas em um cofre digital, e os ladrões estão cada vez mais especializados."

Perdas de mais de US $3,1 bilhões apenas no primeiro semestre de 2025. Deixa isso afundar.

Um bug em um smart contract ainda pode custar milhões. O ataque de reentrância no The DAO em 2016? US$50 milhões. Hoje isso seria apenas uma fração dos US$953,2 milhões perdidos em 2024 por falhas em um único vetor: controle de acesso.

Mas tem mais. Os desenvolvedores agora enfrentam um novo adversário: a Inteligência Artificial. Em 2025, agentes de IA demonstraram capacidade de encontrar e explorar vulnerabilidades de forma autônoma, extraindo milhões em simuladores antes que humanos percebessem.

Bem-vindo a 2025. Vamos explorar as vulnerabilidades mais críticas e como não virar notícia ruim.

⚡ A Evolução da Ameaça: Os Novos Vetores Dominantes

O mapa de riscos foi reorganizado. Com base em 149 incidentes que totalizaram US$1,42 bilhão, o OWASP publicou o Top 10 de 2025. A lista reflete ataques mais complexos e combinados.

Ranking OWASP 2025	O Que É	O Estrago
SC01 - Controle de Acesso	Falhas na atribuição de permissões em funções críticas (mint, ownership)	US$953,2 milhões em 2024 — A principal causa de perdas
SC02 - Manipulação de Oracles	Ataques que manipulam fontes de preços externas	US$8,8 milhões em 2024 — Frequentemente combinado com Flash Loans
SC03 - Erros de Lógica	Bugs sutis na lógica de negócio (recompensas, taxas, empréstimos)	US$63,8 milhões em 2024 — Subiu para 3º lugar
SC05 - Reentrância	Exploração de chamadas externas não sincronizadas	US$35,7 milhões em 2024 — Agora com variantes cross-contract
SC07 - Flash Loans	Empréstimos sem colateral explorados em uma transação	US$33,8 milhões em 2024 — Não é um bug, é um mecanismo explorado
SC08 - Overflow/Underflow	Operações aritméticas que extrapolam limites	Reduzido desde Solidity 0.8+, mas atenção a código legado

🧠 A Nova Fronteira: IA Como Atacante (e Defensor)

Aqui está o que mantém devs de Web3 acordados à noite:

Modelos como Claude Opus 4.5 e GPT-5 desenvolveram exploits para contratos vulneráveis com valor potencial de US$4,6 milhões. Pior: em um experimento com 2.849 contratos recentes, essas IAs encontraram dois "zero-days" (vulnerabilidades inéditas).

A IA pode vasculhar milhares de contratos automaticamente, encontrando padrões que humanos demoram semanas para perceber.

Mas tem um lado bom: a mesma IA que ataca pode defender. Mais sobre isso depois.

🔧 Estratégias de Defesa Modernas (2025)

"Codificar e implantar" é coisa do passado. Segurança agora é um ciclo contínuo.

1. Padrão de Codificação e Ferramentas

Use Solidity 0.8.22+

Verificações aritméticas automáticas
Especifique a versão de forma fixa: pragma solidity 0.8.22; (não use ^)
Garante reprodutibilidade

Bibliotecas Blindadas

OpenZeppelin Contracts — Implementações seguras de padrões ERC
UUPS (ERC1967Proxy) — Proxy seguro para contratos upgradeable (mais eficiente em gas)

Stack de Ferramentas 2025

Slither: Análise estática com novo motor de taint analysis
Echidna: Fuzzing para testar invariantes em estados complexos
Manticore: Análise simbólica para exploração aprofundada
Aderyn (VS Code Extension): Auditoria em tempo real direto no seu editor — detecta vulnerabilidades enquanto você escreve

Integração Contínua (CI)
Crie um pipeline automático que combine essas ferramentas. Bloqueia vulnerabilidades antes de cada merge.

2. Padrões de Projeto Seguros

Controle de Acesso Robusto

Nunca confie apenas em onlyOwner
Use OpenZeppelin AccessControl para RBAC (Role-Based Access Control)
Proteja funções administrativas com multisig (ex: Safe) + timelocks (mínimo 24h)

Padrão Checks-Effects-Interactions (CEI)

Mais crucial que nunca
Atenção: Modificadores que fazem chamadas externas violam o CEI
Use modificadores apenas para checagens simples

Validação de Entrada Exaustiva

Não valide apenas endereços zero
Verifique se são contratos (use extcodesize no constructor)
Defina limites para parâmetros
Use require() com mensagens claras ou erros customizados (mais barato em gas)

3. Auditoria e Governance Pós-Deploy

Auditoria profissional deixou de ser luxo. É requisito mínimo.

Quase metade dos contratos exploráveis é atacada em até 30 dias após o deploy.

Auditoria Híbrida

Revisão interna por pares em cada PR
Auditorias externas trimestrais ou antes de grandes mudanças

Monitoramento em Tempo Real

Use OpenZeppelin Defender Sentinel para alertas de eventos suspeitos
Mudança de owner? Grandes saques? Você fica sabendo

Plano de Resposta a Incidentes

Tenha propostas de governance de emergência pré-escritas
Teste-as. Sério.

Proteção Proativa com IA

Se IA pode atacar, também pode defender
Use ferramentas de auditoria assistida por IA
Faça "testes de estresse" buscando padrões que modelos ofensivos explorariam

🧪 Caso Prático: Um Contrato Vulnerável Real

Aqui está um exemplo inspirado em vulnerabilidades reais encontradas por IA:

❌ Contrato Vulnerável

contract RewardToken {
    mapping(address => uint256) private _balances;
    mapping(address => uint256) public rewards;

    // Faltou o modificador 'view'! ⚠️
    function calculateRewards(address user) public returns (uint256) {
        uint256 reward = _balances[user] * 0.01;
        rewards[user] += reward;  // Estado modificado inadvertidamente!
        return reward;
    }

    function claimRewards() external {
        uint256 amount = rewards[msg.sender];
        require(amount > 0, "No rewards");
        rewards[msg.sender] = 0;
        (bool success, ) = msg.sender.call{value: amount}("");
        require(success, "Transfer failed");
    }
}

✅ Contrato Corrigido

contract RewardTokenSecure {
    mapping(address => uint256) private _balances;
    mapping(address => uint256) public rewards;

    // 1. Marcado como 'view' — não modifica estado
    function calculateRewards(address user) public view returns (uint256) {
        return _balances[user] * 0.01;
    }

    // 2. Nova função para ATUALIZAR recompensas, com controle de acesso
    function updateUserRewards(address user) external {
        require(msg.sender == user || hasRole(REWARD_UPDATER_ROLE, msg.sender), "Unauthorized");
        uint256 reward = calculateRewards(user);
        rewards[user] += reward;
    }

    // 3. Padrão CEI aplicado
    function claimRewards() external nonReentrant {
        // CHECK
        uint256 amount = rewards[msg.sender];
        require(amount > 0, "No rewards");

        // EFFECT
        rewards[msg.sender] = 0;

        // INTERACTION
        (bool success, ) = msg.sender.call{value: amount}("");
        require(success, "Transfer failed");
    }

    // 4. RBAC com OpenZeppelin
    bytes32 public constant REWARD_UPDATER_ROLE = keccak256("REWARD_UPDATER_ROLE");
}

📈 O Futuro: Automação, Regulação e Responsabilidade

Com o aumento da adoção institucional, a negligência previsível em segurança está virando risco legal para fundadores e auditores.

Automação da Defesa

Fuzzing já é padrão
Auditoria contínua por IA será integrada ao pipeline de desenvolvimento

Transparência e Comunidade

Auditoria de código aberto
Bug bounties via Immunefi

Resiliência Pós-Deploy

Capacidade de responder, pausar, atualizar (via proxies seguros)
Compensar usuários em caso de incidente
Tão importante quanto evitar o bug inicial

Conclusão: A Imutabilidade é uma Espada de Dois Gumes

A promessa dos smart contracts — código autoexecutável e imutável — continua sendo sua maior força e seu maior perigo.

A diferença entre 2016 e 2025:

→ Mapas detalhados dos campos minados (OWASP Top 10)
→ Ferramentas de detecção avançadas (Slither, Echidna, IA)
→ Padrões de defesa comprovados (CEI, AccessControl, UUPS)

O desafio atual não é apenas conhecer as vulnerabilidades clássicas, mas entender como elas evoluem, se combinam em ecossistemas DeFi complexos, e como novas ameaças (exploração autônoma por IA) redefinem o conceito de "tempo de resposta".

Para o desenvolvedor de 2025, escrever um smart contract seguro significa admitir que nenhum código é perfeito. Significa construir dentro de uma estrutura que assume a falha, que monitora constantemente, que pode ser corrigida de forma ordenada, e que usa a tecnologia mais avançada disponível — tanto para atacar seus próprios contratos em simulação quanto para defendê-los em produção.

Just Code It Securely.

Fontes de Referência:

5 Técnicas Para Melhorar a Performance no seu App Angular

Adriano P. Araujo — Thu, 27 Nov 2025 13:20:32 +0000

O Problema

Lembra daquele app que começou rápido e depois foi ficando mais lento conforme adicionávamos features? Pois é, o culpado quase sempre é o mesmo: change detection.

O Angular, por padrão, é um pouco paranóico. A cada evento (scroll, clique, timer), ele verifica TODA a árvore de componentes pra ver se algo mudou.

Traduzindo: se você tem 100 componentes e 100 eventos por segundo, são 10.000 verificações por segundo. Não tem CPU que aguente!

Para resolver, listei abaixo 5 técnicas para melhorar a performance do seu app Angular. Algumas delas, mesmo sendo velhas conhecidas, ainda hoje costumam ser ignoradas.

1. OnPush - A Estratégia Mais Importante

Compatibilidade: Angular 2+
Impacto: Reduz change detection em ~90%

Essa aqui muda o jogo. O OnPush faz o Angular ser mais inteligente - ele só verifica mudanças quando realmente precisa.

@Component({
  selector: 'app-user-card',
  template: `<div>{{ user.name }}</div>`,
  changeDetection: ChangeDetectionStrategy.OnPush  // 👈 Essa mágica aqui
})
export class UserCardComponent {
  @Input() user: User;
}

A pegadinha: Com OnPush, você precisa parar de mutar objetos:

// ❌ Isso quebra tudo (o Angular não detecta)
this.user.name = 'João';

// ✅ Isso funciona perfeitamente
this.user = { ...this.user, name: 'João' };

Recomendação: Todo componente novo já deveria nascer com OnPush. Só remove quando realmente não tem jeito (e isso é raro).

2. Signals - O Futuro Que Já Chegou

Compatibilidade: Angular 17+
Impacto: Mais eficiente que RxJS

Signals são mais simples que RxJS e mais eficientes. Depois de testá-las, viram a primeira escolha para muitos devs.

@Component({
  selector: 'app-counter',
  template: `
    <div>Count: {{ count() }}</div>    <!-- Note os () -->
    <div>Doubled: {{ doubled() }}</div>
  `
})
export class CounterComponent {
  count = signal(0);           // 👈 Declaração simples
  doubled = computed(() => this.count() * 2);  // 👈 Computed elegante
}

Por que Signals sobre RxJS:

// ❌ RxJS (funciona, mas é mais verboso)
count$ = new BehaviorSubject(0);
doubled$ = this.count$.pipe(map(c => c * 2));

// ✅ Signals (mais simples e eficiente)
count = signal(0);
doubled = computed(() => this.count() * 2);

A grande vantagem: com Signals, só os componentes que usam aquele signal específico são verificados. É muito mais granular.

Nota pra quem está em Angular 12-16: RxJS + OnPush funciona muito bem também!

3. Lazy Loading - Dividir para Conquistar

Compatibilidade: Angular 14+
Impacto: Isola componentes pesados

Componentes pesados ou telas menos acessadas devem ser lazy-loaded:

const routes: Routes = [
  {
    path: 'dashboard',
    loadComponent: () => import('./dashboard/dashboard.component')
      .then(m => m.DashboardComponent)  // 👈 Só carrega quando acessado
  }
];

Resultado: O app principal fica leve e rápido. O dashboard só carrega quando o usuário realmente precisa.

4. Unsubscribe - Evitando Vazamentos

Padrão recomendado (Clássico): takeUntil com Subject
Padrão moderno (Angular 16+): takeUntilDestroyed
Problema que resolve: Memory leaks e change detection desnecessário

Abordagem Clássica (Angular 2+)

export class DataComponent implements OnInit, OnDestroy {
  private destroy$ = new Subject<void>();  // 👈 Subject de limpeza

  ngOnInit() {
    this.dataService.getData()
      .pipe(
        takeUntil(this.destroy$)  // 👈 Limpa automaticamente
      )
      .subscribe(data => {
        this.data = data;
      });
  }

  ngOnDestroy() {
    this.destroy$.next();
    this.destroy$.complete();
  }
}

Abordagem Moderna (Angular 16+)

import { takeUntilDestroyed } from '@angular/core/rxjs-interop';

@Component({
  selector: 'app-data',
  template: `<div>{{ data }}</div>`
})
export class DataComponent implements OnInit {
  private destroyRef = inject(DestroyRef);
  data: any;

  constructor(private dataService: DataService) {}

  ngOnInit() {
    this.dataService.getData()
      .pipe(
        takeUntilDestroyed(this.destroyRef)  // 👈 Muito mais simples!
      )
      .subscribe(data => {
        this.data = data;
      });
  }
}

Por que funciona: Observables que continuam emitindo depois que o componente foi destruído são uma fonte comum de problemas. Esse padrão elimina o problema.

Qual usar? Se você está em Angular 16+, use takeUntilDestroyed. É mais limpo e não precisa implementar OnDestroy.

5. trackBy - O Segredo das Listas Rápidas

Compatibilidade: Angular 2+
Quando usar: Sempre em *ngFor com listas dinâmicas
Melhoria: Listas com 1000+ itens ficam fluidas

Abordagem Clássica (Angular 2+)

@Component({
  template: `
    <div *ngFor="let user of users; trackBy: trackByFn">
      {{ user.name }}
    </div>`
})
export class UserListComponent {
  users: User[] = [];

  // 👈 Essa função simples faz mágica
  trackByFn(index: number, item: User) {
    return item.id;  // O Angular usa isso pra saber o que mudou
  }
}

Abordagem Moderna com Control Flow (Angular 17+)

@Component({
  template: `
    @for (user of users; track user.id) {
      <div>{{ user.name }}</div>
    }
  `
})
export class UserListComponent {
  users: User[] = [];
  // 👈 Não precisa de trackByFn! O 'track' é obrigatório
}

Antes: A lista inteira era re-renderizada a cada mudança
Depois: Só os itens que realmente mudaram são atualizados

Nota importante: No Angular 17+, o track é obrigatório na nova sintaxe de control flow (@for). Isso força boas práticas de performance desde o início.

Checklist de Performance

Antes de entregar qualquer feature, é legal verificar:

Todos componentes usando OnPush?
Signals implementados (se Angular 17+)?
Componentes pesados em lazy loading?
Observables com takeUntil ou takeUntilDestroyed?
O trackBy em todas as listas (ou @for com track)?
Testei no Performance Profiler?

Conclusão Prática

Comece com OnPush em tudo. Depois adote Signals onde possível (Angular 17+). Finalmente, mantenha um processo consistente de lazy loading + unsubscribe + trackBy.

Se você está em Angular 17+, aproveite as novas features: takeUntilDestroyed e control flow com @for. Elas tornam o código mais limpo e forçam boas práticas de performance.

Os resultados? Apps que mantêm a performance não importa quantas features adicionemos.

Just Code It!

[Boost]

Adriano P. Araujo — Tue, 25 Nov 2025 23:08:05 +0000

Adriano P. Araujo

Nov 25 '25

Concorrência em Go: Goroutines e Channels Easy

#go #backend #tutorial #goroutines

Comments

7 min read

Concorrência em Go: Goroutines e Channels Easy

Adriano P. Araujo — Tue, 25 Nov 2025 20:16:24 +0000

Antes de Começar: Concorrência vs Paralelismo vs Assíncrono

Essas três palavrinhas são frequentemente confundidas, especialmente se você vem do JavaScript. Vamos descomplicar:

Concorrência é quando você ORGANIZA seu programa para lidar com várias tarefas. Não significa que rodam ao mesmo tempo, mas que o programa sabe alternar entre elas. É sobre ORQUESTRAÇÃO.

Paralelismo é quando várias tarefas REALMENTE rodam ao mesmo tempo, em processadores diferentes. É sobre EXECUÇÃO SIMULTÂNEA.

Código assíncrono (como no JavaScript) é quando você escreve código que não bloqueia. Você chama uma função, ela retorna uma Promise, e você continua fazendo outras coisas enquanto espera. Mas na prática, tudo roda em uma ÚNICA thread.

A diferença prática?

Em JavaScript (Node.js), quando você faz:

await fetch('api1')
await fetch('api2')
await fetch('api3')

Você está sendo assíncrono, mas não paralelo. As requisições não rodam simultaneamente - o event loop vai alternando entre elas.

Em Go, quando você faz:

go buscarAPI1()
go buscarAPI2()
go buscarAPI3()

Você está sendo concorrente. E a mágica é: dependendo do seu processador, essas goroutines podem rodar em paralelo (simultaneamente em diferentes núcleos) ou o Go pode simplesmente alternar entre elas.

O melhor de tudo? Você não precisa se preocupar com isso. O runtime do Go cuida de tudo pra você!

O Problema Real

Quando você começa com Go, logo bate aquela dúvida: "Como faço para executar várias tarefas ao mesmo tempo sem criar uma zona?"

Em linguagens como Python ou Node.js, você pode se perder em callbacks, Promises ou async/await. Em Go, a resposta é elegantemente simples: goroutines e channels.

Mas antes do código, vamos entender o problema que essas ferramentas resolvem.

Imagine que você está construindo um sistema que precisa buscar dados de várias APIs ao mesmo tempo. Sem concorrência, seria assim:

// Sequencial - muito lento
resultado1 := buscarDadosAPI1()  // 2 segundos
resultado2 := buscarDadosAPI2()  // 2 segundos  
resultado3 := buscarDadosAPI3()  // 2 segundos
// Total: 6 segundos 😴

Com concorrência, você pode fazer tudo simultaneamente. Vou mostrar o código real agora:

// Concorrente - muito mais rápido!
resultado := make(chan string, 3)

go func() { resultado <- buscarDadosAPI1() }()
go func() { resultado <- buscarDadosAPI2() }() 
go func() { resultado <- buscarDadosAPI3() }()

// Todas as APIs são chamadas ao mesmo tempo
res1 := <-resultado  // ~2 segundos
res2 := <-resultado  // ~2 segundos
res3 := <-resultado  // ~2 segundos
// Total: ~2 segundos! 🚀

Essa é a mágica que vamos desvendar!

O que é uma Goroutine?

Uma goroutine é basicamente uma função que executa de forma independente das outras. É super leve, eficiente e gerenciada pelo próprio Go.

A sintaxe é tão simples que chega a ser engraçada:

go minhaFuncao()

É só colocar go na frente da chamada da função. Pronto! Ela vai rodar em paralelo.

Mas aí vem a pergunta: como você sabe quando a goroutine terminou? Como pega o resultado dela?

É aí que entram os channels!

Channels: A Comunicação Entre Goroutines

Um channel é como um tubo de comunicação entre goroutines. Uma goroutine coloca dados dentro, outra goroutine pega dados de fora. É seguro, sincronizado e evita aqueles bugs malucos de concorrência.

À partir daqui os exemplos dados são baseados no uso de Data-feeds da chainlink, então se você não sabe o que é isso ou quiser ter mais contexto, eu explico aqui 😉

Vamos criar um exemplo prático:

package main

import (
    "context"
    "fmt"
    "log"
    "math/big"
    "time"

    "github.com/ethereum/go-ethereum/common"
    "github.com/ethereum/go-ethereum/ethclient"
    "github.com/smartcontractkit/chainlink/v2/core/gethwrappers/generated/aggregator_v3_interface"
)

// TokenConfig guarda as informações de cada token que queremos monitorar
type TokenConfig struct {
    Symbol  string
    Address common.Address
}

// FormattedPrice armazena o preço formatado e outras infos úteis
type FormattedPrice struct {
    Symbol    string
    Price     *big.Float
    Timestamp uint64
    Decimals  uint8
}

Agora vamos para a função main. Aqui nos conectamos à rede Ethereum e definimos quais tokens queremos monitorar. Sinta-se à vontade para adicionar ou remover tokens!

func main() {
    // Conectando a um nó da Ethereum
    client, err := ethclient.Dial("https://ethereum-rpc.publicnode.com")
    if err != nil {
        log.Fatalf("Ops! Deu ruim ao conectar na Ethereum: %v", err)
    }
    defer client.Close()

    // Nossa lista de tokens para monitorar! Adicione os que quiser aqui.
    tokens := []TokenConfig{
        {Symbol: "ETH", Address: common.HexToAddress("0x5f4eC3Df9cbd43714FE2740f5E3616155c5b8419")},
        {Symbol: "BTC", Address: common.HexToAddress("0xF4030086522a5bEEa4988F8cA5B36dbC97BeE88c")},
        {Symbol: "LINK", Address: common.HexToAddress("0x2c1d072e956AFFC0D435Cb7AC38EF18d24d9127c")},
    }

    // Este canal vai receber os preços conforme forem sendo encontrados
    pricesChan := make(chan FormattedPrice, len(tokens))

    // Um contexto com timeout para não ficarmos esperando eternamente
    ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
    defer cancel()

    // Lança uma goroutine para cada token - todas rodam ao mesmo tempo!
    for _, token := range tokens {
        go fetchTokenPrice(ctx, client, token, pricesChan)
    }

    // Agora é só coletar os resultados que forem chegando
    fmt.Println("🎯 Buscando preços em paralelo...")
    for i := 0; i < len(tokens); i++ {
        select {
        case price := <-pricesChan:
            fmt.Printf("✅ %s: $%.2f (Atualizado: %d)\n", 
                price.Symbol, price.Price, price.Timestamp)
        case <-ctx.Done():
            log.Fatalf("⏰ Timeout! Demorou demais: %v", ctx.Err())
        }
    }
    fmt.Println("🎉 Todos os preços foram coletados!")
}

A função fetchTokenPrice é onde a mágica acontece - ela interage com o contrato na blockchain:

// fetchTokenPrice é nossa trabalhadora: busca o preço de um token específico
func fetchTokenPrice(ctx context.Context, client *ethclient.Client, token TokenConfig, pricesChan chan<- FormattedPrice) {
    // Cria uma instância do contrato para podermos conversar com ele
    aggregator, err := aggregator_v3_interface.NewAggregatorV3Interface(token.Address, client)
    if err != nil {
        log.Printf("❌ Erro no contrato do %s: %v", token.Symbol, err)
        return
    }

    // Pega os dados mais recentes do oráculo
    roundData, err := aggregator.LatestRoundData(nil)
    if err != nil {
        log.Printf("❌ Erro buscando dados do %s: %v", token.Symbol, err)
        return
    }

    // Descobre quantas casas decimais o preço tem
    decimals, err := aggregator.Decimals(nil)
    if err != nil {
        log.Printf("❌ Erro nas casas decimais do %s: %v", token.Symbol, err)
        return
    }

    // Converte o preço para um formato que a gente entende
    price := new(big.Float).SetInt(roundData.Answer)
    divisor := new(big.Float).SetInt(new(big.Int).Exp(big.NewInt(10), big.NewInt(int64(decimals)), nil))
    price.Quo(price, divisor)

    // Manda o resultado pelo canal
    pricesChan <- FormattedPrice{
        Symbol:    token.Symbol,
        Price:     price,
        Timestamp: roundData.UpdatedAt.Uint64(),
        Decimals:  decimals,
    }
}

O que está rolando aqui?

Criamos um channel chamado pricesChan
Lançamos várias goroutines, cada uma busca um token diferente
Cada goroutine manda seu resultado pelo channel
Na main, vamos coletando os resultados conforme chegam

A parte <-pricesChan espera até chegar um valor no channel. Assim o programa não termina antes de todas as goroutines terminarem.

Padrão Prático: Timeout com Context

Na vida real, você não quer que seu programa fique esperando eternamente. Quer um tempo limite. É aí que o context salva:

package main

import (
    "context"
    "fmt"
    "time"
)

func buscarDado(ctx context.Context, id int, resultado chan string) {
    // Simula um trabalho que demora
    time.Sleep(3 * time.Second)

    select {
    case resultado <- fmt.Sprintf("Dado %d pronto!", id):
        // Tudo certo, mandamos o resultado
    case <-ctx.Done():
        // Opa, o contexto foi cancelado! Melhor abortar.
        fmt.Printf("✂️ Goroutine %d foi cancelada\n", id)
    }
}

func main() {
    resultado := make(chan string)

    // Contexto com timeout de 2 segundos (bem curto pra forçar o cancelamento)
    ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
    defer cancel()

    // Lança algumas goroutines
    for i := 1; i <= 3; i++ {
        go buscarDado(ctx, i, resultado)
    }

    // Tenta coletar os resultados
    for i := 0; i < 3; i++ {
        select {
        case res := <-resultado:
            fmt.Println(res)
        case <-ctx.Done():
            fmt.Println("⏰ Timeout! Chega de esperar...")
            return
        }
    }
}

Aqui, se as goroutines demorarem mais de 2 segundos, o contexto cancela e a gente para de esperar.

Buffered Channels: Quando Você Quer Mais Flexibilidade 🤸‍♂️

Até agora usamos channels "normais". Isso significa que a goroutine que envia fica esperando até alguém receber.

Mas às vezes você quer que a goroutine envie e já continue trabalhando. Para isso, usamos buffered channels:

// Channel com buffer para 3 valores
resultado := make(chan string, 3)

// Agora você pode enviar 3 valores sem ficar esperando
resultado <- "valor 1"
resultado <- "valor 2" 
resultado <- "valor 3"

// Só vai travar na 4ª tentativa (quando o buffer estiver cheio)

Padrão Real: Agregando Dados de Várias Fontes

Vamos juntar tudo em um exemplo mais próximo da realidade. Imagine buscando preços de criptomoedas:

package main

import (
    "context"
    "fmt"
    "time"
)

type Preco struct {
    Moeda string
    Valor float64
}

func buscarPreco(ctx context.Context, moeda string, resultado chan Preco) {
    // Simula uma chamada de API que demora 1 segundo
    time.Sleep(1 * time.Second)

    // Preços fictícios para exemplo
    precos := map[string]float64{
        "BTC": 45000.50,
        "ETH": 3200.75, 
        "LINK": 18.25,
    }

    select {
    case resultado <- Preco{Moeda: moeda, Valor: precos[moeda]}:
        fmt.Printf("✅ Preço do %s buscado com sucesso\n", moeda)
    case <-ctx.Done():
        fmt.Printf("❌ Busca do %s cancelada\n", moeda)
    }
}

func main() {
    moedas := []string{"BTC", "ETH", "LINK"}
    resultado := make(chan Preco, len(moedas))

    ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
    defer cancel()

    // Dispara uma goroutine para cada moeda
    for _, moeda := range moedas {
        go buscarPreco(ctx, moeda, resultado)
    }

    // Coleta os resultados
    fmt.Println("📊 Coletando preços...")
    for i := 0; i < len(moedas); i++ {
        preco := <-resultado
        fmt.Printf("💰 %s: $%.2f\n", preco.Moeda, preco.Valor)
    }
    fmt.Println("🎉 Todos os preços coletados!")
}

Por Que Go é Tão Bom Nisso?

Go brilha em concorrência porque:

Goroutines são super leves: você pode ter milhares sem pesar no sistema
Channels são seguros: sem aqueles bugs malucos de acesso simultâneo
Sintaxe é simples: não tem callback hell ou Promises complexas
O runtime cuida de tudo: você só manda e o Go gerencia

Conclusão

Embora concorrência em Go seja algo complexo para quem não está acostumado, ele é um modelo bem pensado onde goroutines trabalham independentemente e channels as mantêm sincronizadas.

Comece simples: uma goroutine, um channel, um resultado. Depois evolua para timeouts, buffered channels e agregação de dados.

O legal é que mesmo em cenários complexos, o código em Go continua legível e direto ao ponto. 💙

Just Code It! 🚀

A Usabilidade no Back-End

Adriano P. Araujo — Thu, 23 Oct 2025 13:18:48 +0000

A Usabilidade para além do Front-end

Quando falamos em "usabilidade", é quase automático pensarmos em interfaces bonitas, botões no lugar certo e telas que respondem rapidamente. Em resumo: a experiência do usuário final.

Mas e se eu disser que a usabilidade é um conceito que deveria ser aplicado muito antes do front-end? Que ela começa no coração do sistema: o back-end.

Um back-end com boa usabilidade não é sobre ter uma "interface gráfica bonita" (afinal, o "usuário" aqui é, na maioria das vezes, outro desenvolvedor ou sistema). É sobre criar uma experiência fluida, intuitiva e eficiente para quem vai consumir, manter e expandir o seu código.

Pense no back-end como a cozinha de um restaurante. O cliente (o Front-end) só vê o prato lindo e saboroso. Mas se a cozinha (Back-end) for bagunçada, com facas cegas e panelas queimadas, o prato vai demorar, sair errado ou, pior, o restaurante vai fechar as portas.

O que é "Usabilidade no Back-End"?

Chamamos isso de Developer Experience (DX) ou "Experiência do Desenvolvedor". É a usabilidade aplicada à API, ao código, à arquitetura. É o que permite que a gente, devs, consiga programar mais e gastar menos tempo perguntando "como funciona isso?" ou tentando agendar uma call para entender como determinado payload deve ser .

Um back-end com boa DX possui três pilares que precisam ser impecáveis:

1. O Contrato Sagrado: Uma API Intuitiva e Bem Documentada

Na minha jornada com Solidity (sempre falando de web3 neh? relaxa que é rapidão), e integrando serviços como os Chainlink Data Feeds, aprendi que um contrato mal feito é o caos.

Na Web3, o ABI (Application Binary Interface) de um contrato inteligente é o seu contrato. Ele define como o mundo se comunica com seu código on-chain. Na arquitetura tradicional, sua API REST/GraphQL é exatamente isso: o seu contrato sagrado.

URLs e Endpoints Claros:
- GET /users/{id} é intuitivo.
- GET /getUserDataById.php?uid=123 não é .

Seu cliente, seja o front-end em Angular ou um serviço em Go, não deveria ficar perdendo tempo tentando adivinhar o endpoint correto 🫠.

Respostas Consistentes: Sempre retorne JSON no mesmo formato.
Inclua códigos de status HTTP significativos (200, 201, 400, 404, 500). Nada é pior do que um 200 OK que te devolve um erro 👀 (quem nunca).
Documentação Viva (OpenAPI/Swagger): A documentação deve ser o seu single source of truth. Não pode ser um PDF estático de três meses atrás. A DX exige que a documentação acompanhe o código.

2. Mensagens de Erro que Ajudam de Verdade

Mensagens de erro no back-end são um ponto de contato direto com o desenvolvedor que está consumindo a API. Elas são a forma mais rápida de sabotar ou acelerar a DX.

Compare:

Inútil (e frustrante): "Error: Null Exception"
Útil (economiza horas): "Erro ao criar usuário. O campo 'email' é obrigatório e não pode ser nulo. Veja a documentação em /docs/users#create."

Dev Front-end ao receber receber mensagem de erro humanamente ilegível

Mensagens de erro claras economizam horas de debug e tornam a integração com o front-end muito mais rápida. Elas transformam um obstáculo em um caminho. 🧘🏻‍♂️𓅓

3. Código Limpo, Arquitetura Sólida (E a Mão do Gemini)

A verdadeira usabilidade no back-end mora na estrutura interna. Com minha experiência migrando aplicações e atuando em ambientes de missão crítica, percebi que o custo de um código desorganizado é altíssimo. É aí que a filosofia SOLID e a busca por baixo acoplamento entram:

SOLID e Simplicidade: É possível trocar um banco de dados de MySQL para PostgreSQL no seu projeto? Se não for, a usabilidade arquitetural é baixa. Linguagens como Go nos forçam a pensar em simplicidade e concorrência, o que naturalmente eleva a DX.
Código Legível e Componentizado: No Front-end (com Angular), aprendemos o valor de componentes reutilizáveis. No Back-end, isso se traduz em classes e funções de responsabilidade única.
Consistência é uma Ferramenta de DX: Um código só é usável se ele for consistente. Para garantir isso, a automação é essencial. É por isso que uso ferramentas como o Gemini Code Assist e padrões como o styleguide.md. O robô vira o fiscal do padrão e garante que a qualidade (aquela que buscamos com Jest e SonarQube) seja mantida em todas as layers.

Escrevi um artigo sobre o Gemini Code Assist aqui, talvez seja útil.

4. Zero Burocracia no Setup

A primeira interação de um novo desenvolvedor com seu projeto é o setup. Se ele passar um dia inteiro configurando variáveis de ambiente e banco de dados, a DX já começou com o pé esquerdo.

"Dockerize" é Mandatório: Um simples docker-compose up deve ser suficiente para levantar todo o ambiente de desenvolvimento. Esse é um padrão que a formação Full Cycle reforça e que todo projeto moderno precisa.
Health Checks e Logs: Crie endpoints simples como /health ou /status que mostram se o sistema e suas dependências estão saudáveis. Se uma requisição está lenta, os logs devem dizer o porquê: "Query no banco demorou 2000ms para o usuário ID: 456". Performance que não é um segredo é boa usabilidade!

Por Que Se Importar com Isso?

A usabilidade no back-end é um investimento que paga dividendos enormes ao longo do ciclo de vida do software:

Velocidade na Equipe: O Front-end consegue integrar com o Back-end sem ficar gritando "como funciona essa API?!"
Manutenção Mais Barata: Código legível e bem estruturado é mais fácil (e mais barato) de manter e escalar.
Atração e Retenção de Talentos: Desenvolvedores amam trabalhar em projetos bem estruturados. Um bom back-end é o seu cartão de visitas mais valioso (Mais sobre isso na listinha de leitura abaixo 😊)

Algumas Leituras Que Podem Ajudar

Concluindo:

A usabilidade no back-end é uma mudança de mentalidade: parar de pensar no código como uma "caixa preta" e começar a vê-lo como um produto cujo cliente é outro desenvolvedor.

No final das contas, um sistema só é verdadeiramente usável quando é usável em todas as suas camadas. E a Developer Experience é a métrica que garante o sucesso de todos nós.

Just Code It!

Consultando Preços de Criptomoedas com Chainlink e Golang

Adriano P. Araujo — Tue, 23 Sep 2025 18:09:02 +0000

Desenvolvedores que atuam no ecossistema blockchain frequentemente enfrentam um desafio comum: como obter dados do mundo real, como preços de ativos, de forma segura e confiável dentro de uma aplicação descentralizada.

A dependência de serviços centralizados pode criar um ponto de falha, e as limitações de planos gratuitos podem ser um obstáculo.

A Chainlink Data Feeds surge como uma solução robusta para esse problema, oferecendo dados descentralizados e auditáveis diretamente on-chain.

Neste guia, construiremos uma aplicação em Golang para consultar os preços de múltiplos tokens de forma concorrente e eficiente, utilizando a infraestrutura da Chainlink.

Entendendo a Chainlink e o "Problema do Oráculo"

Por padrão, blockchains são sistemas isolados; elas não conseguem acessar dados de sistemas externos (off-chain). Essa limitação é conhecida como o "problema do oráculo". Como um contrato inteligente pode saber o preço do Ethereum em dólar se ele não pode "olhar" para fora da blockchain?

A Chainlink resolve exatamente isso. Ela é uma rede de oráculos descentralizada que atua como uma ponte segura entre as blockchains (on-chain) e fontes de dados do mundo real (off-chain). Ela permite que contratos inteligentes reajam a dados, eventos e pagamentos externos de forma confiável e à prova de adulteração.

Os Data Feeds são um dos serviços mais populares da Chainlink. Eles são redes de oráculos descentralizadas que fornecem informações de preços de ativos para contratos inteligentes, agregando dados de múltiplas fontes (e é totalmente free).

Agora vamos deixar de papinho e vamos ao código!

⚙️ Pré-requisitos

Antes de iniciarmos, certifique-se de que seu ambiente de desenvolvimento atende aos seguintes requisitos:

Go instalado (versão 1.21 ou superior).
Um provedor de RPC Ethereum. Utilizaremos um endpoint público para este guia, mas para aplicações em produção, recomenda-se serviços dedicados como Infura ou Alchemy.
Os endereços dos contratos dos Data Feeds. Consulte a página oficial de endereços para obter os contratos corretos para a rede desejada (ex: Ethereum Mainnet, Sepolia).
Conhecimento básico de Golang e da interação com contratos inteligentes.

1. Configuração do Projeto

Inicie criando um diretório para o projeto e inicializando um módulo Go.

mkdir chainlink-price-feed
cd chainlink-price-feed
go mod init chainlink-price-feed

2. Instalação das Dependências

Precisamos das bibliotecas go-ethereum para interagir com a blockchain e do pacote da Chainlink que contém as interfaces dos contratos.

go get github.com/ethereum/go-ethereum
go get github.com/ethereum/go-ethereum/ethclient
go get github.com/smartcontractkit/chainlink/core/gethwrappers/generated/aggregator_v3_interface

3. Estruturando o Código

Vamos construir nosso arquivo main.go aos poucos. Assim, você entende o propósito de cada trecho antes de ver o monstro completo.

Primeiro, vamos definir as estruturas que organizarão nossos dados. Uma (TokenConfig) para guardar o nome e o endereço de cada token e outra (PreçoFormatado) para armazenar o resultado bonitinho que receberemos.

package main

import (
    "context"
    "fmt"
    "log"
    "math/big"
    "time"

    "github.com/ethereum/go-ethereum/common"
    "github.com/ethereum/go-ethereum/ethclient"
    "github.com/smartcontractkit/chainlink/v2/core/gethwrappers/generated/aggregator_v3_interface"
)

// TokenConfig armazena a configuração de cada token que desejamos monitorar.
type TokenConfig struct {
    Symbol  string
    Address common.Address
}

// FormattedPrice guarda o preço final e outras informações úteis.
type FormattedPrice struct {
    Symbol    string
    Price     *big.Float
    Timestamp uint64
    Decimals  uint8
}

Agora, vamos começar a função main. Aqui, nós nos conectamos à rede Ethereum e definimos quais tokens queremos monitorar. Sinta-se à vontade para adicionar ou remover tokens desta lista!

func main() {
    // Conectando a um nó da Ethereum. Este endpoint público é ótimo para      começar.
    client, err := ethclient.Dial("https://ethereum-rpc.publicnode.com")
    if err != nil {
        log.Fatalf("Ops! Deu ruim ao conectar no Ethereum: %v", err)
    }
    defer client.Close()

    // Nossa lista de alvos! Adicione quantos tokens quiser aqui.
    // Esses endereços são endereços da MAINNET.
    tokens := []TokenConfig{
        {Symbol: "ETH", Address: common.HexToAddress("0x5f4eC3Df9cbd43714FE2740f5E3616155c5b8419")},
        {Symbol: "BTC", Address: common.HexToAddress("0xF4030086522a5bEEa4988F8cA5B36dbC97BeE88c")},
        {Symbol: "LINK", Address: common.HexToAddress("0x2c1d072e956AFFC0D435Cb7AC38EF18d24d9127c")},
    }

Para buscar os preços de forma eficiente, vamos usar a mágica da concorrência em Go. Lançaremos uma busca para cada token ao mesmo tempo (goroutine). Para receber os resultados de volta de forma organizada e segura, usaremos um canal (channel).

Também adicionamos um context com timeout, uma espécie de cronômetro de segurança para garantir que nosso programa não fique esperando para sempre se a rede estiver lenta.

    // ... continuando dentro da função main()
    // Este canal vai receber os preços assim que eles foremencontrados.
    pricesChan := make(chan FormattedPrice, len(tokens))

    // Um contexto com timeout para não ficarmos presos esperando para   sempre. :p
    ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
    defer cancel()

    // Lança uma "missão" para buscar o preço de cada token, tudo ao mesmo tempo.
    for _, token := range tokens {
        go fetchTokenPrice(ctx, client, token, pricesChan)
    }

    // Agora, a gente espera e coleta os resultados que chegam pelo canal.
    fmt.Println("Buscando preços...")
    for i := 0; i < len(tokens); i++ {
        select {
        case price := <-pricesChan:
            fmt.Printf("✅ Preço do %s: %.2f USD (Atualizado em: %d)\n",
                price.Symbol, price.Price, price.Timestamp)
        case <-ctx.Done():
            log.Fatalf("Demorou demais! O timeout foi atingido: ", ctx.Err())
        }
    }
}

A função fetchTokenPrice contém a lógica de interação com o contrato. Ela instancia o contrato, chama a função latestRoundData e formata o valor retornado.

// fetchTokenPrice é o nosso "operário": ele busca o preço de um token específico.
func fetchTokenPrice(ctx context.Context, client *ethclient.Client, token TokenConfig, pricesChan chan<- FormattedPrice) {
    // Cria uma instância do contrato para a gente poder interagir com ele.
    aggregator, err := aggregator_v3_interface.NewAggregatorV3Interface(token.Address, client)
    if err != nil {
        log.Printf("Erro ao instanciar o contrato para %s: %v", token.Symbol, err)
        return
    }

    // Pega os dados mais recentes do oráculo.
    roundData, err := aggregator.LatestRoundData(nil)
    if err != nil {
        log.Printf("Erro ao buscar os dados para %s: %v", token.Symbol, err)
        return
    }

    // Descobre quantas casas decimais o preço tem.
    decimals, err := aggregator.Decimals(nil)
    if err != nil {
        log.Printf("Erro ao buscar as casas decimais para %s: %v", token.Symbol, err)
        return
    }

    // O preço vem como um número inteiro gigante. A gente precisa formatá-lo.
    priceFloat := new(big.Float).SetInt(roundData.Answer)
    divisor := new(big.Float).SetInt(new(big.Int).Exp(big.NewInt(10), big.NewInt(int64(decimals)), nil))
    formattedPrice := new(big.Float).Quo(priceFloat, divisor)

    // Envia o resultado bonitão de volta para a função main através do canal.
    pricesChan <- FormattedPrice{
        Symbol:    token.Symbol,
        Price:     formattedPrice,
        Timestamp: roundData.UpdatedAt.Uint64(),
        Decimals:  decimals,
    }
}

4. Código Completo (`main.go`)

Ufa! Agora que você entendeu cada parte,ou ao menos eu acho que sim
🤔, aqui está o arquivo main.go completo para você copiar e colar (talvez só essa parte te interesse 🥺):

package main

import (
    "context"
    "fmt"
    "log"
    "math/big"
    "time"

    "github.com/ethereum/go-ethereum/common"
    "github.com/ethereum/go-ethereum/ethclient"
    "github.com/smartcontractkit/chainlink/core/gethwrappers/generated/aggregator_v3_interface"
)

// TokenConfig armazena a configuração de cada token que desejamos monitorar.
type TokenConfig struct {
    Symbol  string
    Address common.Address
}

// FormattedPrice guarda o preço final e outras informações úteis.
type FormattedPrice struct {
    Symbol    string
    Price     *big.Float
    Timestamp uint64
    Decimals  uint8
}

func main() {
    // Conectando a um nó da Ethereum. Este endpoint público é ótimo para      começar.
    client, err := ethclient.Dial("https://ethereum-rpc.publicnode.com")
    if err != nil {
        log.Fatalf("Ops! Deu ruim ao conectar no Ethereum: %v", err)
    }
    defer client.Close()

    // Nossa lista de alvos! Adicione quantos tokens quiser aqui.
    // Esses endereços são endereços da MAINNET.
    tokens := []TokenConfig{
        {Symbol: "ETH", Address: common.HexToAddress("0x5f4eC3Df9cbd43714FE2740f5E3616155c5b8419")},
        {Symbol: "BTC", Address: common.HexToAddress("0xF4030086522a5bEEa4988F8cA5B36dbC97BeE88c")},
        {Symbol: "LINK", Address: common.HexToAddress("0x2c1d072e956AFFC0D435Cb7AC38EF18d24d9127c")},
    }

    // Este canal vai receber os preços assim que eles foremencontrados.
    pricesChan := make(chan FormattedPrice, len(tokens))

    // Um contexto com timeout para não ficarmos presos esperando para   sempre. :p
    ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
    defer cancel()

    // Lança uma "missão" para buscar o preço de cada token, tudo ao mesmo tempo.
    for _, token := range tokens {
        go fetchTokenPrice(ctx, client, token, pricesChan)
    }

    // Agora, a gente espera e coleta os resultados que chegam pelo canal.
    fmt.Println("Buscando preços...")
    for i := 0; i < len(tokens); i++ {
        select {
        case price := <-pricesChan:
            fmt.Printf("✅ Preço do %s: %.2f USD (Atualizado em: %d)\n",
                price.Symbol, price.Price, price.Timestamp)
        case <-ctx.Done():
            log.Fatalf("Demorou demais! O timeout foi atingido: ", ctx.Err())
        }
    }
}
func fetchTokenPrice(ctx context.Context, client *ethclient.Client, token TokenConfig, pricesChan chan<- FormattedPrice) {
    // Cria uma instância do contrato para a gente poder interagir com ele.
    aggregator, err := aggregator_v3_interface.NewAggregatorV3Interface(token.Address, client)
    if err != nil {
        log.Printf("Erro ao instanciar o contrato para %s: %v", token.Symbol, err)
        return
    }

    // Pega os dados mais recentes do oráculo.
    roundData, err := aggregator.LatestRoundData(nil)
    if err != nil {
        log.Printf("Erro ao buscar os dados para %s: %v", token.Symbol, err)
        return
    }

    // Descobre quantas casas decimais o preço tem.
    decimals, err := aggregator.Decimals(nil)
    if err != nil {
        log.Printf("Erro ao buscar as casas decimais para %s: %v", token.Symbol, err)
        return
    }

    // O preço vem como um número inteiro gigante. A gente precisa formatá-lo.
    priceFloat := new(big.Float).SetInt(roundData.Answer)
    divisor := new(big.Float).SetInt(new(big.Int).Exp(big.NewInt(10), big.NewInt(int64(decimals)), nil))
    formattedPrice := new(big.Float).Quo(priceFloat, divisor)

    // Envia o resultado bonitão de volta para a função main através do canal.
    pricesChan <- FormattedPrice{
        Symbol:    token.Symbol,
        Price:     formattedPrice,
        Timestamp: roundData.UpdatedAt.Uint64(),
        Decimals:  decimals,
    }
}

5. Execução do Código

Para compilar e executar a aplicação, basta utilizar nosso velho conhecido comando:

go run main.go

Se tudo deu certo (tomara que sim 🙏), a saída esperada será parecida com essa :

Buscando preços...
✅ Preço do ETH: 4170.75 USD (Atualizado em: 1758737807)
✅ Preço do LINK: 21.89 USD (Atualizado em: 1758739211)
✅ Preço do BTC: 113825.78 USD (Atualizado em: 1758736295)

⚠️ Pontos de Atenção

Rede Certa, Endereço Certo: Os endereços dos contratos mudam de uma rede para outra (Mainnet é diferente de Sepolia). Use sempre o endereço correto para a rede à qual você está conectado.
Sem Custos de Gás: Este código apenas lê dados da blockchain, o que é de graça (ainda bem)! Operações de escrita, por outro lado, exigiriam uma carteira com fundos para pagar as taxas (gás).
Latência: Os preços não são atualizados em tempo real, mas sim quando há uma variação mínima ou quando um período de tempo (o tal do heartbeat) passa. Leve isso em conta!

Conclusão

Pronto! Agora você tem uma aplicação em Go eficiente para buscar preços de criptomoedas usando o poder da Chainlink. Esse é um exemplo simples mas com essa base, podemos criar projetos muito mais legais e complexos.
Usamos concorrência para acelerar as coisas e garantimos que o programa não trave com timeouts.

Para mais informações, a documentação oficial da Chainlink é sempre o melhor lugar para procurar.

Agora, é com você. Just Code It!

Revisão Automática de PRs no GitHub com Gemini Code Assist

Adriano P. Araujo — Wed, 17 Sep 2025 17:22:09 +0000

Chega de revisar código sozinho!

A gente sabe como é: revisão de código é vital, mas consome um tempo precioso que você poderia estar usando para codificar.

A boa notícia? Dá para automatizar essa tarefa sem abrir a carteira. O Gemini Code Assist é um app gratuito para o GitHub que atua como um colega de equipe virtual. Ele mergulha nos seus Pull Requests, aponta o que pode ser melhorado e te dá sugestões práticas. É o fim daquela pilha de PRs esperando por uma revisão.

1. Botando as coisas para funcionar

A instalação consiste nos seguintes passos:

Vá até o Marketplace do GitHub.
Clique em "Install"(lá no fim da página) e autorize o acesso. Escolha em quais repositórios o robô vai fuçar (eu liberei todos os meus, mas aí escolha é sua).
Aceite os Termos de Serviço do Google e pronto. O gemini-code-assist[bot] já vai estar na área.

Deixando o robô com a sua cara

Para o Gemini não sair dando palpite genérico e perder tempo com arquivos que não interessam, crie uma pasta .gemini/ na raiz do seu projeto e ajuste as configurações. A pasta deve conter os dois arquivos :

1.styleguide.md: Crie esse arquivo para ditar suas regras. O que ele faz? Dita as regras, ora!

Exemplo do styleguide.md:

# Nossas Regras Sagradas
- Aqui usamos TypeScript. O tipo `any` é proibido e pode causar demissão (do PR).
- Em React, componentes de função são lei.
- Nada de "números mágicos" soltos no código. Crie constantes, pelo amor.

Claro, esse é um style-guide é apenas um exemplo bem-humorado que você não deveria ver em produção(ou deveria?🤔). Você pode incluir coisas mais específicas, como princípios SOLID, Object Calisthenics, boas práticas da sua linguagem, etc.

Ah já ia me esquecendo, o styleguide.md dá o contexto da interação do gemini com o seu código, por isso é legal deixar claro a stack utilizada seja ela qual for, Go, Node, React, etc.

2.config.yaml: Aqui você define o comportamento geral do bot, incluindo o que ele deve ignorar.

Exemplo do config.yaml e o que cada propriedade significa :

have_fun: true # Isso aqui não faz nada, só deixa o clima leve.Se você não curtir gracinhas só definir como false
code_review:
  # Aqui você define à partir de que nível de severidade ele apontará as divergências do styleguide.md do seu código, no exemplo abaixo ele começa a apontar à partir de divergências de nível médio
  comment_severity_threshold: MEDIUM # Os níveis são LOW - MEDIUM - HIGH - CRITICAL
  max_review_comments: 10  # O limite de comentários por review
  # Lista de arquivos e pastas que o Gemini deve ignorar na revisão. Funciona como um .gitignore
  ignore_patterns: 
    - frontend/node_modules/** 
    - frontend/dist/** 
    - frontend/**/*.spec.ts     
  pull_request_opened: 
    summary: true  # Se você quiser um resumo das alterações implementadas quando o PR for aberto, vote true
    code_review: true # Para reforçar de que você deseja que ele faça a revisão de código

2. A mágica acontecendo

Assim que um PR é aberto, o Gemini entra em ação. Em cerca de 5 minutos, ele aparece com:

Resumo do PR: Uma sinopse das mudanças, ideal pra quem tá com preguiça de ler tudo e perfeito para documentações.
Análise do Código: Comentários inline nas linhas que ele acha que podem melhorar. Ele classifica a gravidade (de LOW a CRITICAL), explica o motivo e, muitas vezes, já dá a sugestão de correção pronta pra aplicar.

Precisando de uma ajudinha extra?

Use os comandos diretamente nos comentários(isso é muito maneiro), do PR para chamar o bot:

Comando	O que faz
`/gemini review`	“Ô, robô! Dá uma olhada de novo aqui, por favor.”
`/gemini summary`	“Me perdi. Faz um resumo desse PR de novo.”
`@gemini-code-assist`	Permite fazer uma pergunta específica sobre um trecho de código.
`/gemini help`	“Socorro! Quais são os comandos mesmo?”

3. Pontos positivos

Economia de tempo: Você foca em codar; ele foca em revisar. Prático.
Consistência no código: Chega de cada um fazer do seu jeito. O robô vira o fiscal do padrão, e garante a qualidade do código segundo os padrões definidos pelo time.
Aprendizado acelerado: Por essa aqui provavelmente você não esperava, para mim, tem sido uma ferramenta de estudo: tô aprofundando em Go e uso as correções que o Gemini sugere para melhorar e perceber onde estou falhando. Ele aponta erros, sugere formas mais idiomáticas e me faz entender o porquê daquela sugestão. É como ter um professor particular de código. Esse código aqui escrito em Go teve todos os seus PRs revisados pelo Gemini 😲

4. Nem tudo são flores

Não é perfeito: Como está em preview, às vezes ele pode dar uma sugestão meio sem noção. Então assim, nada de confiar cegamente na IA.
Suporte a linguagens: Confere se ele entende a linguagem ou stack do seu projeto.
Conectividade: Não rola em organizações do GitHub com restrições de rede muito específicas.

5. Alguns conselhos

Use como primeiro filtro: Deixe o Gemini pegar os problemas óbvios. Para a lógica de negócio que pode quebrar tudo, chame um humano.
Comece com calma: Use comment_severity_threshold: MEDIUM pra não ser soterrado de notificações logo de cara.
Dê feedback pro robô: Use os emojis 👍 e 👎 nos comentários dele. Isso ajuda a IA a aprender.
Capriche no styleguide.md: Quanto mais claras suas regras, mais certeiras serão as revisões. Dica de ouro: quer que os resumos e sugestões venham em português? Escreva o styleguide.md em português. O mesmo vale para qualquer outro idioma.

Conclusão

A moral da história é simples: o Gemini Code Assist é aquele parceiro de código que faltava, seja para turbinar seu aprendizado solo ou para ajudar sua equipe a manter o padrão de qualidade sem dor de cabeça.

Ele automatiza a parte chata, te ensina a programar melhor e mantém seu projeto nos trilhos.

Instale, teste e deixe o robô trabalhar. Vale a pena a experiência.

Se você chegou até aqui, eu espero enormemente que esse artigo tenha sido útil para você de alguma maneira.

Just Code it!

Forem: Adriano P. Araujo

HTML para Devs Backend: Ou Como Aprender que Nem Tudo é uma Div

O meme da <div> que vira pesadelo real

HTML não é sobre aparência, é sobre significado

Os 5 elementos que você está usando errado (e como consertar)

1. <button> vs. a tragédia do <div onclick="">

2. A conexão perdida: <label> e <input>

3. <form>: não é um container qualquer

4. <img alt="">: o atributo mais negligenciado do mundo

5. <a href=""> vs. <button>: a separação das coisas

Atributos que são superpoderes secretos

aria-*: o manual de instruções para leitores de tela

input type="": muito mais que validação

data-*: a ponte segura entre HTML e JavaScript

A verdade que dói

Conclusão: Pare de tratar HTML como um detalhe

Bônus: Para onde ir agora ?

[Boost]

Segurança em Smart Contracts (2025): A Evolução dos Ataques e a Nova Fronteira da Defesa

Adriano P. Araujo ・ Dec 2

Segurança em Smart Contracts (2025): A Evolução dos Ataques e a Nova Fronteira da Defesa

⚡ A Evolução da Ameaça: Os Novos Vetores Dominantes

🧠 A Nova Fronteira: IA Como Atacante (e Defensor)

🔧 Estratégias de Defesa Modernas (2025)

1. Padrão de Codificação e Ferramentas

2. Padrões de Projeto Seguros

3. Auditoria e Governance Pós-Deploy

🧪 Caso Prático: Um Contrato Vulnerável Real

❌ Contrato Vulnerável

✅ Contrato Corrigido

📈 O Futuro: Automação, Regulação e Responsabilidade

Conclusão: A Imutabilidade é uma Espada de Dois Gumes

Just Code It Securely.

5 Técnicas Para Melhorar a Performance no seu App Angular

O Problema

1. OnPush - A Estratégia Mais Importante

2. Signals - O Futuro Que Já Chegou

3. Lazy Loading - Dividir para Conquistar

4. Unsubscribe - Evitando Vazamentos

Abordagem Clássica (Angular 2+)

Abordagem Moderna (Angular 16+)

5. trackBy - O Segredo das Listas Rápidas

Abordagem Clássica (Angular 2+)

Abordagem Moderna com Control Flow (Angular 17+)

Checklist de Performance

Conclusão Prática

[Boost]

Concorrência em Go: Goroutines e Channels Easy

Concorrência em Go: Goroutines e Channels Easy

Antes de Começar: Concorrência vs Paralelismo vs Assíncrono

O Problema Real

O que é uma Goroutine?

Channels: A Comunicação Entre Goroutines

Padrão Prático: Timeout com Context

Buffered Channels: Quando Você Quer Mais Flexibilidade 🤸‍♂️

Padrão Real: Agregando Dados de Várias Fontes

Por Que Go é Tão Bom Nisso?

Conclusão

A Usabilidade no Back-End

A Usabilidade para além do Front-end

O que é "Usabilidade no Back-End"?

1. O Contrato Sagrado: Uma API Intuitiva e Bem Documentada

2. Mensagens de Erro que Ajudam de Verdade

3. Código Limpo, Arquitetura Sólida (E a Mão do Gemini)

4. Zero Burocracia no Setup

Por Que Se Importar com Isso?

Algumas Leituras Que Podem Ajudar

Concluindo:

Consultando Preços de Criptomoedas com Chainlink e Golang

Entendendo a Chainlink e o "Problema do Oráculo"

⚙️ Pré-requisitos

1. Configuração do Projeto

2. Instalação das Dependências

3. Estruturando o Código

4. Código Completo (main.go)

5. Execução do Código

⚠️ Pontos de Atenção

Conclusão

Revisão Automática de PRs no GitHub com Gemini Code Assist

Chega de revisar código sozinho!

O meme da `<div>` que vira pesadelo real

1. `<button>` vs. a tragédia do `<div onclick="">`

2. A conexão perdida: `<label>` e `<input>`

3. `<form>`: não é um container qualquer

4. `<img alt="">`: o atributo mais negligenciado do mundo

5. `<a href="">` vs. `<button>`: a separação das coisas

`aria-*`: o manual de instruções para leitores de tela

`input type=""`: muito mais que validação

`data-*`: a ponte segura entre HTML e JavaScript

4. Código Completo (`main.go`)