Forem: Rafael Coelho

RabbitMQ: o que ele faz de verdade (e por que muita gente usa errado)

Rafael Coelho — Tue, 27 Jan 2026 13:44:53 +0000

RabbitMQ é uma daquelas coisas que muita gente usa, mas pouca gente entende o que tá acontecendo ali no meio.

A maioria aprende assim:

“é só um lugar que você manda uma mensagem
e outro sistema consome depois”

E pronto.

O problema é que, quando você não entende o modelo mental do RabbitMQ (e o problema que ele resolve), você começa a usar errado.
Ou pior: usa quando nem precisava.

O problema real que o RabbitMQ resolve

Imagina uma loja.

O usuário faz um pedido e o sistema precisa:

registrar o pedido
processar pagamento (externo)
emitir nota fiscal (externo)
atualizar estoque
enviar e-mail (externo)

Se você fizer isso em sequência via HTTP… o usuário fica preso esperando tudo e seu sistema vira um monólito distribuído.

Fluxo típico ruim com HTTP em cadeia

HTTP acopla tempo: um serviço espera o outro.
Se um cair, trava geral. Se um ficar lento, todo mundo sofre.

Onde o RabbitMQ entra

Com mensageria, você responde rápido pro usuário e joga o resto pro “tempo do sistema”.

Fluxo com RabbitMQ (desacoplado)

RabbitMQ não é “substituto de HTTP”.
Ele existe pra tirar trabalho pesado do caminho do usuário.

Modelo mental do RabbitMQ (o principal)

O RabbitMQ segue isso aqui:

Producer → Exchange → Queue → Consumer

E isso é o que quase ninguém guarda:

👉 Producer nunca manda direto pra fila.
Ele manda pra uma Exchange, e a Exchange decide pra onde vai.

Visão geral do fluxo

A fila não pensa.
Quem pensa é a Exchange.

Producer, Exchange, Queue, Consumer

Producer: quem publica (sua API, um worker, um serviço).
Exchange: roteia a mensagem.
Queue: só armazena (FIFO).
Consumer: processa.

Tipos de Exchange no RabbitMQ

1) Direct Exchange (match exato)

Se a routing key bate, a mensagem vai.

2) Fanout Exchange (broadcast)

Ignora routing key.
Chegou? Espalhou pra todo mundo conectado.

3) Topic Exchange (padrões com `*` e `#`)

Aqui você começa a tratar como evento de verdade:

order.created
order.paid
order.error

E consumidores podem usar padrões:

order.* (uma palavra depois)
order.# (zero ou mais palavras depois)

Quando você começa a usar Topic bem, seu sistema tende a ficar mais organizado e escalável.

4) Headers Exchange (roteamento por cabeçalho)

Em vez de routing key, decide pelo header:

country=BR
locale=pt-BR
region=south

ACK: por que a mensagem “volta” (e isso é bom)

Aqui separa quem usa RabbitMQ direito de quem perde mensagem em produção.

Consumiu e deu ACK → remove da fila.
Consumiu e caiu antes do ACK → volta pra fila.

ACK vs crash

Muita gente acha que isso é bug.
Não é. É garantia.

RabbitMQ vs Kafka (não confunde)

RabbitMQ:

tarefa
garante processamento
remove mensagem depois do consumo

Kafka:

stream de eventos
mantém histórico
lê quando e quantas vezes quiser

Comparação visual (mental model)

RabbitMQ é tarefa.
Kafka é stream.
Usar um no lugar do outro é pedir pra sofrer.

Quando usar RabbitMQ (e quando não usar)

Use RabbitMQ quando:

precisa desacoplar sistemas
precisa background / processamento assíncrono
precisa lidar com falha e retry

Não use quando:

precisa resposta imediata
o fluxo é simples
HTTP resolve

Fechando

RabbitMQ não é complicado.

O que complica é usar sem entender o modelo.

Se você entendeu Producer → Exchange → Queue → Consumer,
você já entende RabbitMQ melhor do que muita gente que usa em produção.

Links:

Simulador RMQ

Veja também o vídeo sobre esse tema

O usuário é teu chefe e você precisa deixar ele feliz!

Rafael Coelho — Thu, 30 Oct 2025 21:54:58 +0000

É estranho dizer isso, mas é só você pensar um pouco que você vai entender o que eu quero dizer.

Quando você baixa um aplicativo ou se cadastra numa plataforma, tudo o que você fizer vai ser pra ver se aquele aplicativo te atende ou simplesmente se você acha a interface bonitinha.

Aí se a usabilidade for ruim ou não funcionar do jeito que você queria, você vai simplesmente largar e testar outro, não é?

Agora, vamos pensar que estamos falando do seu sistema:

se você soubesse que o usuário tá pensando em trocar de app por falta de uma funcionalidade ou por alguma coisa que estava simples demais… o que você faria?

Se você tiver qualquer tipo de carinho pelo seu app (ou vontade de ganhar dinheiro), você com certeza iria tentar melhorar a experiência dele.

E pra te ajudar com isso, tem duas coisas que PRECISAM estar sempre no seu processo de criação:

Analisar a experiência do usuário e o “Fator UAU”.

Experiência de Usuário (UX)

Muitas empresas tem uma pessoa responsável por isso, mas não deveria ser só papel dela: é uma coisa que tem que ser pensada desde o começo de qualquer funcionalidade.

E podem ter muitos UX que vão me xingar por dizer isso, mas pensar em UX não é tão difícil quanto parece (pelo menos do lado dos devs e arquitetos).

A intenção é fazer a vida do usuário mais fácil dentro do seu sistema.

Não tô falando só de como o seu produto vai resolver os problemas dele, mas como vai ser fácil dele entender e conseguir fazer isso.

E pra atingir uma boa experiência, tem umas perguntas que precisam ser respondidas, como:

“Esse texto explica o que esse botão faz?”
“Com quantos cliques o usuário consegue fazer isso?”
“Esse formulário está longo demais?”
“Dá pra saber bem o que tá acontecendo no sistema o tempo todo?”

E são o tipo de pergunta que fazem você pensar como usuário e ver o que parece chato de fazer ou mesmo o que te deixaria confuso.

Se for difícil pensar assim, aqui vão umas regrinhas:

Toda ação precisa de um feedback

O usuário precisa saber que algo aconteceu.

Se ele clicou num botão e nada mudou, ele vai clicar de novo — e de novo.
Os comportamentos invisíveis precisam ser informados

Se algo está processando, mostre um loading.

Se algo foi salvo, mostre uma confirmação.

Se os itens da página não carregaram ainda, mostre um Skeleton.
Os erros precisam ser claros e dar um direcionamento

“Erro 500” não significa nada pro usuário.

Diga o que deu errado e o que o usuário pode fazer pra resolver.
Botões precisam dizer o que fazem

Evite ícones aleatórios, labels genéricas (“ver”, “abrir”) ou abreviações internas (“CAD”, “ALT”).

Use texto direto e que o usuário entenda!
Evite surpresas

Se um botão “Excluir” não pede confirmação, você está pedindo pro usuário cometer erros.

O usuário precisa saber quando algo é irreversível e precisa ser protegido de cliques em querer.
Mantenha os assuntos em seus lugares

Não misture os assuntos pela tela.

Mantenha todos os botoes e links de pedidos no bloco de pedidos e só!

Organização visual também é usabilidade.
Mantenha consistência entre telas.

Se o botão de salvar é verde em uma tela, não o coloque vermelho em outra.

O cérebro do usuário cria padrões — não bagunce isso!
Use padrões conhecidos

Não tente reinventar o botão de fechar ou o ícone de busca.

UX boa é previsível — e isso é uma virtude.

E não esqueça: VERDE é sucesso, AMARELO é alerta e VERMELHO é erro!
Evite “camadas de cliques”

Quanto mais cliques o usuário precisar, maior a chance dele desistir.

Simplifique o caminho.
Os textos também fazem parte da interface

“Campo inválido” é diferente de “Ops, o e-mail precisa ter @”.

UX também é comunicação.
Tudo que parece clicável deve ser clicável

E o que não for clicável, não deve parecer que é (Essa é clássica, mas muita gente ainda erra).
Mostre progresso em ações demoradas

Upload, importação, geração de relatório… tudo precisa ser mostrado.

Barra de progresso vai evitar ansiedade.
Dê saídas seguras

Sempre deixo o usuário cancelar, voltar, desfazer ou confirmar durante processos irreversíveis.
Priorize o que é mais usado

O botão mais importante não pode estar escondido, tem que ser fácil de ver e de clicar.

Mas ainda podem haver informações que você não vai conseguir só testando ou se perguntando, então você precisa ouvir o que ele tem a dizer.

E você nem precisa perguntar diretamente pra ter a resposta… você pode monitorar o seu sistema.

Ver qual dos menus o usuário usa, o fluxo que ele segue sempre que quer criar um novo pedido…

E ainda pode usar testes A/B: que é quando você coloca 2+ versões da mesma funcionalidade, botão ou texto e observa para descobrir qual converte ou chama mais atenção.

Assim, você consegue perceber quais são as dores do usuário, quais são os caminhos que ele tá preferindo, qual tá sendo mais difícil de usar e até quais formulários ele tá abandonando no meio do caminho.

Fator “UAU”

Depois de garantir que o usuário não vai ter uma experiência ruim, tá na hora de garantir que ele vai ter uma experiência boa usando “O fator UAU”.

Pensa assim: enquanto pensar na “UX básica” garante que ele não vai largar seu app, o “Fator UAU” vai garantir que ele vai se apaixonar por ele!

A ideia é simples: você tem que fazer o uso da sua aplicação ser satisfatório.

Lembra no Super Mario?

Quando você pega a moedinha, ela não só sumia: ela brilhava e soltava aquele barulhinho — o que deixava pegar moedas uma coisa bem mais satisfatória.

E você pode fazer a mesma coisa…

E não tô falando de colocar um efeito sonoro ou efeito especial em tudo.

E sim em dar “recompensas” para o usuário enquanto ele faz tarefas simples e humanizar um sistema que o usuário precisa pra resolver os problemas dele.

E isso pode ser feito com coisas simples:

Animações que interagem com o usuário

Como é exemplo da página de login do NPM ou da MetaMask, que o avatar acompanha enquanto você digita, mas tampa os olhos quando você vai digitar a senha.
Textos humanos e “personalizados”

Colocar mensagens que pareçam específicas para aquela pessoa e, quem sabe, levando em consideração coisas como horário, comportamento do usuário, a página de onde ele veio ou até a localização dele.
Micro-animações em botões finais

Pode ser uma animação simples que vai mostrar um ✅, um confete saindo do botão ou um alerta sonoro simples.
Animação de carregamento contextual

Em vez do spinner genérico, mostrar algo relacionado à ação.

Ex.: um ícone de avião decolando enquanto o app envia um pedido de viagem.
Feedback sonoro ou tátil discreto

Um toque sutil no celular ao concluir algo com sucesso, ou um som curto quando uma tarefa termina.

O cérebro entende que deu certo sem nem precisar olhar.

Pode parecer trabalhoso, mas é isso que vai ser a diferença entre um sistema “Ok” e um sistema “UAU”.

Porque no fim, é isso que faz o usuário perceber que alguém realmente pensou nele.

É o tipo de detalhe que transforma o uso de um sistema em algo prazeroso — e faz ele querer voltar.

No fim das contas, é simples:

O usuário é teu chefe.

Mas se você fizer ele sorrir, ele vai virar teu fã.

O que são Observers

Rafael Coelho — Tue, 05 Nov 2024 20:08:55 +0000

O Observer é um Design Pattern de comportamento que te cria um mecanismo de "notificação" para diversos objetos sobre qualquer evento que aconteça no objeto observado.

Se você já usou Angular ou RxJS, já viu os Observables da lib do ngrx que são basicamente uma implementação de um Observer.

Com o Observer, você cria uma estrutura onde se pode adicionar observadores que vão ser notificados à cada atualização que nem no fluxo abaixo.

Exemplo prático

Vamos imaginar o seguinte cenário:

Em um jogo, o jogador pode receber dano, e, ao ocorrer esse evento, diferentes sistemas precisam ser notificados, como a barra de vida, um sistema de áudio para tocar sons de dor, e um sistema de log para registrar o evento.

Exemplo de Código

Imagine que estamos desenvolvendo esse sistema em JavaScript, onde o Jogador é o Observable e cada componente que precisa ser notificado (barra de vida, áudio, log de eventos) é um Observador.

Observable (Jogador)

class Jogador {
  constructor() {
    this.observadores = [];
    this.vida = 100; // vida inicial do jogador
  }

  // Adicionar um observador
  adicionarObservador(observador) {
    this.observadores.push(observador);
  }

  // Remover um observador
  removerObservador(observador) {
    this.observadores = this.observadores.filter(obs => obs !== observador);
  }

  // Notificar todos os observadores
  notificar() {
    this.observadores.forEach(observador => observador.atualizar(this.vida));
  }

  // Reduzir a vida e notificar observadores se o jogador sofre dano
  receberDano(dano) {
    this.vida -= dano;
    console.log(`😨 Jogador recebeu ${dano} de dano. Vida atual: ${this.vida}`);
    this.notificar();
  }
}

Observadores

Cada observador representa uma reação específica ao evento de dano e implementa o método atualizar.

Observador da Barra de Vida:

class BarraDeVida {
  atualizar(vida) {
    console.log(`📉 Atualizando barra de vida: ${vida} de vida restante.`);
  }
}

Observador de Áudio:

class SistemaDeAudio {
  atualizar(vida) {
    console.log(`🔊 Tocando som de dano. Vida atual do jogador: ${vida}`);
  }
}

Observador de Log de Eventos:

class LogDeEventos {
  atualizar(vida) {
    console.log(`📜 Registrando no log: jogador sofreu dano. Vida restante: ${vida}`);
  }
}

Uso do Sistema

Agora, vamos criar o Jogador e adicionar observadores para simular as notificações.

// Instanciar o jogador
const jogador = new Jogador();

// Criar observadores
const barraDeVida = new BarraDeVida();
const sistemaDeAudio = new SistemaDeAudio();
const logDeEventos = new LogDeEventos();

// Adicionar observadores ao jogador
jogador.adicionarObservador(barraDeVida);
jogador.adicionarObservador(sistemaDeAudio);
jogador.adicionarObservador(logDeEventos);

// Simular o jogador recebendo dano
jogador.receberDano(20); // Reduz a vida e notifica observadores
jogador.receberDano(30); // Reduz ainda mais e notifica novamente

A saída será:

😨 Jogador recebeu 20 de dano. Vida atual: 80
📉 Atualizando barra de vida: 80 de vida restante.
🔊 Tocando som de dano. Vida atual do jogador: 80
📜 Registrando no log: jogador sofreu dano. Vida restante: 80

😨 Jogador recebeu 30 de dano. Vida atual: 50
📉 Atualizando barra de vida: 50 de vida restante.
🔊 Tocando som de dano. Vida atual do jogador: 50
📜 Registrando no log: jogador sofreu dano. Vida restante: 50

Neste exemplo, o padrão Observer permite que diferentes partes do sistema de jogo reajam automaticamente ao evento de dano, mantendo o código organizado e facilitando a adição de novos comportamentos.

Conclusão

Para encerrar, o padrão Observer é uma ótima escolha quando você precisa de um sistema que se adapte e responda a eventos em tempo real, permitindo que diferentes componentes reajam a mudanças sem que o código do sujeito principal precise ser alterado.

Em cenários de jogos, aplicativos de monitoramento e até em redes sociais, o Observer ajuda a criar arquiteturas flexíveis e modulares, facilitando tanto a manutenção quanto a expansão do sistema.

Esse padrão é amplamente aplicável, seja em interfaces reativas, notificações de eventos ou outros tipos de resposta a mudanças. Ele permite adicionar e remover observadores com facilidade, garantindo que o sistema se mantenha desacoplado e escalável.

Como funciona a internet (Parte 2) - O Protocolo HTTP

Rafael Coelho — Mon, 20 May 2024 15:19:23 +0000

Esse post é a continuação da série "Como funciona a internet" onde vamos começar falando do HTTP: A lingagem da WEB

Parte 1: O Modelo TCP/IP: A Fundação da Internet
Parte 2: O Protocolo HTTP
Parte 3: Segurança na Internet: Protegendo os Dados (Em breve)
Parte 4: DNS e Roteamento: Os Nomes da Internet (Em breve)

No post anterior, falamos do TCP como o protocolo mais seguro e confiável para comunicações via sockets de rede.
E nesse post, falaremos do HTTP que é uma implementação do protocolo TCP.

O que é o protocolo HTTP

O Protocolo HTTP (Hypertext Transfer Protocol) é uma implementação do protocolo TCP para ser usado numa estrutura Server-Client: tendo um servidor que proveria as informações que seriam solicitadas pelo cliente.

Além das propriedades, ele possui uma estrutura de regras de comunicação para que o servidor e o cliente saibam o que está acontecendo e então poder tomar decisões baseadas nisso.

Um exemplo clássico disso é o seu navegador agora:

Ele enviou uma requisição para o servidor que possui esse site e em seguida recebeu uma resposta que continha o HTML dessa página para então renderizá-la.

O Formato HTTP

Para ser mais simples: lembre-se que o HTTP é um programa que é executado para "ouvir" uma porta de rede através do protocolo TCP.

Entendido isso, vamos falar sobre o formato.

O que o HTTP espera receber é uma sequência de texto que precisa seguir o padrão abaixo:

Método: O método HTTP serve pra explicar o tipo de ação que vai ser feito.
Caminho: O caminho é a expecificação de qual recurso você está buscando. Por exemplo, em https://racoelho.com.br/posts, o caminho é: /posts .
Versão HTTP: A versão do protocolo HTTP sendo usada para a requisição ou resposta. Hoje em dia, estamos mais familiarizados com o HTTP/2 com o HTTPS, mas nesse post estaremos usando o HTTP/1.1.
Cabeçalhos: Os cabeçalhos passam informações adicionais sobre a requisição ou resposta. Eles seguem o formato "Nome: Valor". Alguns exemplos comuns de cabeçalhos incluem "Host", que especifica o domínio alvo da requisição, e "Content-Type", que especifica o tipo de mídia do corpo da mensagem.

E depois da requisição finalizada, o servidor vai reponder no formato abaixo:

Uma resposta HTTP é composta por três partes principais: a linha de status, os cabeçalhos e o corpo da mensagem.

Linha de Status: Esta é a primeira linha de qualquer resposta HTTP e contém três partes:
- A versão do protocolo HTTP.
- Código Status de Resposta: É um código que vau de 100 à 599 e serve pra informar o client o resultado da requisição.
- Mensagem do Status: A descrição do Status de Resposta.
Cabeçalhos: Os cabeçalhos fornecem informações adicionais sobre a resposta. É a mesma ideia da requisição: Eles seguem o formato "Nome: Valor" e cada cabeçalho é separado por uma nova linha. No exemplo, temos os seguintes cabeçalhos:
- Access-Control-Allow-Origin: é um cabeçalho de CORS, ou Cross Origin Resource Sharing, e define quem pode acessar aquele recurso.
- Date: indica a data e a hora em que a mensagem foi enviada.
- Connection: Indica o status da conecção que foi iniciada.
- Content-Type: Informa qual é o tipo de conteúdo que será retornado no corpo da resposta.
Corpo da Mensagem: Esta é a última parte de uma resposta HTTP e contém os dados reais sendo enviados. No exemplo, o corpo da mensagem é um documento HTML.

Métodos HTTP

HTTP utiliza diferentes métodos de solicitação para especificar a ação desejada. Aqui estão os métodos mais comuns:

GET: Recupera dados do servidor. Usado para obter páginas web.
POST: Envia dados ao servidor. Comumente usado em formulários.
PUT: Atualiza recursos existentes no servidor.
DELETE: Remove recursos no servidor.

Códigos de Status

Informativas (100 – 199)
Sucesso (200 – 299)
Redirecionamento (300 – 399)
Erro de Requisição (400 – 499)
Erro de Servidor (500 – 599)

Para ver uma lista completa, veja esse artigo.

HTTP/2 e HTTP/3

Com o avanço contínuo da web, os protocolos de comunicação também evoluíram para atender às crescentes demandas de desempenho e eficiência. E isso trouxe as melhorias introduzidas pelo HTTP/2 e as inovações do HTTP/3.

HTTP/2

HTTP/2, lançado em 2015, foi projetado para melhorar significativamente o desempenho da web em comparação com seu predecessor, HTTP/1.1. Aqui estão algumas das principais melhorias introduzidas pelo HTTP/2:

Multiplexação: No HTTP/1.1, cada requisição requer uma nova conexão TCP, o que pode causar lentidão devido à limitação do número de conexões simultâneas. Com HTTP/2, múltiplas requisições podem ser enviadas simultaneamente pela mesma conexão TCP, eliminando o bloqueio de cabeçalho de linha (head-of-line blocking) e melhorando a eficiência.
Compressão de Cabeçalhos: HTTP/2 utiliza um algoritmo chamado HPACK para comprimir os cabeçalhos das requisições. Como muitos cabeçalhos HTTP se repetem em várias requisições, a compressão reduz significativamente o tamanho dos dados transmitidos, resultando em menor latência e uso de banda.
Prioritização de Requisições: HTTP/2 permite que os clientes atribuam prioridades às requisições. Isso significa que recursos críticos, como arquivos CSS e JavaScript, podem ser carregados primeiro, melhorando a renderização inicial da página e a experiência do usuário.
Server Push: Com o Server Push, um servidor HTTP/2 pode enviar recursos adicionais ao cliente antes mesmo que ele os solicite. Por exemplo, ao solicitar uma página HTML, o servidor pode enviar automaticamente os arquivos CSS e JavaScript necessários, reduzindo o tempo de carregamento da página.

Essas melhorias afetam positivamente a performance da web, permitindo tempos de carregamento mais rápidos e uma navegação mais suave para os usuários.

HTTP/3

HTTP/3 é a próxima evolução do protocolo HTTP, introduzindo o uso do protocolo QUIC (Quick UDP Internet Connections).
QUIC foi desenvolvido pelo Google e posteriormente adotado pelo IETF (Internet Engineering Task Force) como base para HTTP/3.
Aqui estão algumas das vantagens de HTTP/3 sobre HTTP/2:

Baseado em QUIC: Diferente de HTTP/2, que utiliza TCP, HTTP/3 é construído sobre o protocolo QUIC, que é baseado em UDP. QUIC foi projetado para fornecer conexões mais rápidas e reduzir a latência, especialmente em redes instáveis ou de alta latência.
Redução da Latência de Conexão: QUIC elimina o processo de handshake de três vias do TCP e combina a negociação de TLS em uma única etapa, permitindo que as conexões sejam estabelecidas muito mais rapidamente. Isso é particularmente benéfico em dispositivos móveis e redes com altas latências.
Multiplexação Sem Bloqueio: Como HTTP/2, HTTP/3 suporta multiplexação de múltiplas requisições em uma única conexão. No entanto, devido à natureza de UDP, HTTP/3 evita o bloqueio de cabeçalho de linha a nível de transporte, garantindo que a perda de pacotes em uma requisição não afete outras requisições na mesma conexão.
Resiliência a Mudanças de Rede: QUIC foi projetado para ser resiliente a mudanças de rede, como a transição entre Wi-Fi e redes móveis. Isso é alcançado através da identificação de conexões por IDs de conexão em vez de endereços IP e portas, permitindo que as conexões permaneçam ativas durante a mudança de rede.

O Uso Atual do HTTP

Hoje em dia, a maioria dos sites utiliza HTTP/2 porque ele traz muitas melhorias em relação ao antigo HTTP/1.1. Essas melhorias, como a capacidade de carregar várias requisições ao mesmo tempo e a compressão de dados, ajudam a tornar os sites mais rápidos. Navegadores e servidores modernos suportam HTTP/2, então muitos desenvolvedores adotaram essa versão sem precisar fazer grandes mudanças no código dos seus sites.

O HTTP/3 é uma novidade que está ganhando espaço rapidamente. Grandes empresas como Google e Facebook já começaram a usar HTTP/3 para tornar a entrega de conteúdo ainda mais rápida e estável. Com o suporte crescente de navegadores e servidores, é provável que HTTP/3 se torne o padrão nos próximos anos, melhorando a velocidade e a estabilidade da internet, especialmente em redes móveis e conexões mais lentas.

Conclusão

Com a adoção crescente de HTTP/2 e HTTP/3, a internet está se tornando cada vez mais rápida e eficiente, melhorando a experiência dos usuários em todo o mundo. Essas novas versões do protocolo HTTP trazem avanços significativos em termos de performance e estabilidade, especialmente em redes móveis e conexões mais lentas. No entanto, junto com a velocidade e a eficiência, a segurança continua sendo uma preocupação crucial.

À medida que a internet evolui, garantir a segurança dos dados transmitidos se torna mais importante do que nunca. No próximo post da série "Como funciona a internet", vamos explorar "Segurança na Internet: Protegendo os Dados". Vamos mergulhar nas principais práticas e tecnologias usadas para manter suas informações seguras online, incluindo HTTPS, criptografia, autenticação e as melhores práticas para proteger sua privacidade. Descubra como essas medidas de segurança são implementadas e por que elas são essenciais para uma navegação segura na web. Fique ligado para aprender como proteger seus dados na era digital e garantir que suas interações online sejam sempre seguras e protegidas!

Como funciona a internet (Parte 1): O Modelo TCP/IP: A Fundação da Internet

Rafael Coelho — Mon, 13 May 2024 15:33:03 +0000

Esse será o primeiro post sobre um assunto de extrema importância para todos que querem se aperfeiçoar no desenvolvimento de aplicações para a Web.
Segue a lista das postagens:

Parte 1: O Modelo TCP/IP: A Fundação da Internet
Parte 2: HTTP: A Linguagem da WEB
Parte 3: Segurança na Internet: Protegendo os Dados (Em breve)
Parte 4: DNS e Roteamento: Os Nomes da Internet (Em breve)

Para responder a pergunta "Como funciona a internet?", é importante que você saiba o que ela é.
O que chamamos de internet é uma conexão entre multiplos dispositivos de comunicação, seja por cabo ou não.

Mas para que eles possam se comunicar, todos precisam "falar a mesma lingua".
Por isso, alguns protocolos de comunicação foram criados como o UDP e o que vamos falar hoje: O Protocolo TCP.

Protocolos e Pacotes

Antes de mergulharmos no TCP, é importante entender o que são protocolos e pacotes, dois conceitos fundamentais na comunicação pela internet.

Um protocolo é em resumo, um conjunto de regras que vai definir como os dados são transmitidos e recebidos.
É tipo a gramática: ele dita formatos e estruturas de informação para que todos os envolvidos se entendam.

E quando uma mensagem vai ser enviada de um dispositivo para o outro, ela é dividida em pacotes que serão remontados quando chegarem ao destino.

Tenha isso em mente para poder entender o próximo tópico.

O TCP

TCP, que significa Transmission Control Protocol (Protocolo de Controle de Transmissão), é um dos principais protocolos de comunicação na Internet por sua segurança de comunicação
E isso é porque ele trabalha com garantias.

Antes de enviar qualquer informação, ele estabelece a conexão com o destino e aguarda uma resposta.
Esse passo, nós chamamos de "handshake", ou em bom português: "Aperto de mão".

Uma vez que a conexão foi garantida, ele começa o envio dos pacotes de maneira ordenada recebendo uma confirmação para cada pacote recebido.

E o mais importante: caso o dispositivo não receba a confirmação de recebimento, ele vai reenviar aquele mesmo pacote, garantindo que todos os dados cheguem intactos e na ordem correta.

O UDP

UDP, que significa User Datagram Protocol (Protocolo de Datagrama do Usuário), é outro protocolo que é conhecido por sua eficiência e velocidade.

Diferente do TCP, o UDP não estabelece uma conexão antes de enviar informações.
Ele simplesmente envia os pacotes de dados sem sequer saber se vai ser recebido ou não.
Esse processo é conhecido como "fire and forget", ou "dispare e esqueça".

Sem o processo de confirmações, o UDP consegue enviar pacotes de dados muito mais rapido do que o TCP.

Mas com isso, não existe nenhuma garantia de que todos os pacotes foram recebido ou mesmo que foram ordenados na sequencia correta.

Apesar disso, o UDP é ideal para situações em que a velocidade é mais importante do que a confiabilidade, como transmissões de vídeo ao vivo ou jogos online.

Conclusão sobre TCP e a transição para HTTP

Entendendo as funções do TCP e do UDP, fica claro porque o TCP é tão importante para garantir uma comunicação segura e eficiente na internet.

Através de desse processo burocrático de "handshake" e confirmações, o TCP garante que cada pacote de informação alcance seu destino em perfeita ordem.

Mas a história não acaba aqui.

Ainda precisamos falar sobre como esses dados são apresentados e interagem em um ambiente web.
E é aí que o HTTP (Hypertext Transfer Protocol) entra em cena.

Ele molda a forma como as informações são trocadas e compreendidas entre os navegadores e servidores.

No próximo post vamos falar sobre ele: HTTP: A Linguagem da WEB.

Vamos explorar como esse protocolo permite que as páginas da web sejam entregues de um servidor para seu navegador, fazendo a internet ser o que ela é hoje.

GitHub Actions e a Magia dos Triggers: Automatizando Tarefas com C#

Rafael Coelho — Thu, 09 May 2024 00:14:28 +0000

A Ideia

Um dia desses eu estava criando um processo de deploy com Github Actions e me lembrei de um sistema de ITSM que trabalhei que permitia a execução de arquivos de scripts baseado em triggers do sistema.

E seguindo essa lógica de alteração em sistemas de arquivo que o Github Actions tem, comecei a pensar em algumas possibilidades:

Automatizar backups em horários específicos.
Realizar upload automáticos de arquivos em determinada pasta
Limpeza Automática de Disco
Etc.

Então, abri meu Visual Studio e comecei a criação desse um mini projeto: O JobExecutor (criativo, né?)

A ideia, na verdade é bem simples: teria um arquivo onde nós armazenariamos as triggers ligadas ao script a ser executado.

Por enquanto, como é apenas uma prova de conceito, decidi usar somente dois tipos de trigger:

CronExpression: Que é uma forma de você informar periodicidades e é definido por uma string que tem esse formato: * * * * *
FileWatcher: Para que seja executado assim que algum arquivo ou pasta sejam alterados.

Para armazenar esses dados, escolhi o JSON e ficou nesse formato aqui:

{
  "triggers": [
    {

      "type": "FileWatcher",
      "scriptFileName": "PATH\\TO\\FILE.ps1",
      "watchedPath": "PATH\\TO\\WATCHED\\FILES"
    },
    {
      "type": "CronExpression",
      "scriptFileName": "PATH\\TO\\FILE.ps1",
      "CronExpression": "0 2 * * *" // Vai rodar todos os dias às 2hrs da manhã
    }
  ]
}

Se você é atento, percebeu que nos dois scriptFileName eu estou colocando arquivos ps1 que são arquivos de código Poweshell.
Isso é porque pretendo enviar parâmetros para que o usuário possa ter mais detalhes sobre a ação e tomar decisões sobre elas e os scrips de Powershell são completos e simples de se usar.

As estruturas de código

Para esse projeto estou usando C#, e como ele é fortemente tipado, encontrar estruturas diferentes dentro do mesmo array seria um problema para ele.
E como não podemos também esperar que o usuário coloque todos os parâmetros que ele não vai precisar, não podemos simplesmente converter de JSON pra objeto diretamente.

Então, criei quatro classes:

A primeira tem a inteção de ser a classe "pai", contendo o que todas terão:

public class Trigger
{
    public string ScriptFileName { get; set; }
    public string Type { get; set; }
}

A CronJobTrigger é uma implementação da Trigger.cs e vai adicionar somente o CronExpression:

public class CronJobTrigger : Trigger
{
    public string CronExpression { get; set; }
}

A FileWatcherJobTrigger será também uma implementação da Trigger.cs, e vai ter o caminho que vai ser vigiado.

public class FileWatcherJobTrigger : Trigger
{
    public string WatchedPath { get; set; }
}

E por fim, a que vai representar o JSON como um todo:

public class TriggerConfig
{
    public Trigger[] Triggers { get; set; }
}

Convertendo os diferente tipos de Trigger

Como o FileWatcher e o CronExpression tem parâmetros diferentes, não posso simplemente convertê-los diretamente, já que o conversor vai usar só o tipo Trigger e ignorar os outros campos.

Então precisei criar um conversor.

Estamos usando o conversor do Newtonsoft

// TriggerConverter.cs
using Newtonsoft.Json.Converters;
using Newtonsoft.Json.Linq;
using Newtonsoft.Json;

namespace JobExecutor.Structs;

public class TriggerConverter : CustomCreationConverter<Trigger>
{
    public override object ReadJson(JsonReader reader, Type objectType, object existingValue, JsonSerializer serializer)
    {
        var jsonObject = JObject.Load(reader);
        Trigger trigger;

        if (jsonObject["CronExpression"] != null)
        {
            trigger = new CronJobTrigger();
        }
        else if (jsonObject["WatchedPath"] != null)
        {
            trigger = new FileWatcherJobTrigger();
        }
        else
        {
            throw new JsonSerializationException("Unknown trigger type");
        }

        serializer.Populate(jsonObject.CreateReader(), trigger);
        return trigger;
    }
}

Aqui, quando o conversor for passar de item por item ele vai verificar se o campo CronExpression está preenchido, e caso sim, vai definir o registro como do tipo CronJobTrigger.

O mesmo se aplica para o FileWatcherJobTrigger e o campo WatchedPath.

Caso nenhum dos dois seja verdade, dispara uma Exception.

O Programa

Pra começar, precisamos capturar o arquivo de triggers e ler o conteúdo dele:

class Program
{
    private static List<Trigger> triggers;
    private static string configPath = "PATH\\TO\\triggers.json";

    static void Main(string[] args)
    {
        LoadTriggers();
        Console.ReadLine();
    }

    private static void LoadTriggers()
    {
        triggers = ReadTriggerConfig().Triggers.ToList();
    }

    private static TriggerConfig ReadTriggerConfig()
    {

        var settings = new JsonSerializerSettings
        {
            // Adicionamos o nosso conversor aqui
            Converters = new List<JsonConverter> { new TriggerConverter() }
        };

        // Aqui, lemos o arquivo com um stream
        using var stream = new StreamReader(configPath);
        var json = stream.ReadToEnd();

        return JsonConvert.DeserializeObject<TriggerConfig>(json, settings);
    }
}

Com as triggers armazenadas na propriedade triggers, podemos criar o método que vai processar as triggers e executá-las.

private static void InitializeTriggers()
{
    foreach (var trigger in triggers)
    {
        switch (trigger.Type)
        {
            case "CronExpression":
                SetupCronJob(trigger as CronJobTrigger);
                break;
            case "FileWatcher":
                SetupFileWatcher(trigger as FileWatcherJobTrigger);
                break;
            default:
                throw new NotImplementedException($"Trigger type {trigger.Type} is not implemented.");
        }
    }
}

Depois disso, vamos implementar o SetupCronJob.

Criando o Setup do CronExpression

A expressão Cron é umna string que funciona assim:

Com 5 caracteres:

* * * * *
- - - - -
| | | | |
| | | | +----- Dia da Semana(0 - 6)
| | | +------- Mês (1 - 12)
| | +--------- Dia do Mês (1 - 31)
| +----------- Hora (0 - 23)
+------------- Minuto (0 - 59)

Com 6 Catacteres

* * * * * *
- - - - - -
| | | | | |
| | | | | +--- Dia da Semana (0 - 6) 
| | | | +----- Mês (1 - 12)
| | | +------- Dia do Mês (1 - 31)
| | +--------- Hora (0 - 23)
| +----------- Minuto (0 - 59)
+------------- Segundo (0 - 59)

Com ele você pode dizer "qualquer valor" com um *, usar uma , pra definir vários valores ou até um range de valores com um -.
Exemplos:

- "0 12 * * *" # Todos os dias às 12:00
- "5 0 * 8 *" # Às 00:05, todos os dias de Agosto
- "15 14 1 * *" # Todo dia 1º às 14:15
- "*/5 * * * * *" # À cada 5 segundos

Sabendo disso, precisamos converter isso em um agendamento no nosso código.
Pra isso, vamos usar a lib NCrontab,

Vamos usar o método Parse do CrontabSchedule e em seguida armazenar a próxima execução.
Vai ficar assim:

var schedule = CrontabSchedule.Parse(trigger.CronExpression, new CrontabSchedule.ParseOptions() { IncludingSeconds = true });
var nextRun = schedule.GetNextOccurrence(DateTime.Now);

E depois, vamos criar um System.Threading.Timer para agendar a execução do método que irá rodar o script e então reagendar o job novamente.

O método completo fica assim:

private static void SetupCronJob(CronJobTrigger trigger)
{
    var schedule = CrontabSchedule.Parse(trigger.CronExpression, new CrontabSchedule.ParseOptions() { IncludingSeconds = true });
    var nextRun = schedule.GetNextOccurrence(DateTime.Now);
    var timer = new Timer(
        (e) => {
            // Executa o arquivo
            ExecuteScript(trigger);

            // Reagenda o job
            SetupCronJob(trigger);
        }, 
        null,
        (long)(nextRun - DateTime.Now).TotalMilliseconds,
        Timeout.Infinite);
 }

Criando o Setup do FileWatcher

Para verificar as alterações no caminho indicado, nós vamos usar o FileSystemWatcher.

var watcher = new FileSystemWatcher
{
    Path = trigger.WatchedPath, // Caminho do arquivo pego na trigger
    Filter = "*", // Monitoraremos todos os arquivos
    IncludeSubdirectories = true, // Incluiremos o monitoramento de subdiretórios
    EnableRaisingEvents = true, // Permitiremos a execução de eventos
};

// Define os eventos que devem ser notificados
watcher.NotifyFilter = NotifyFilters.LastWrite
        | NotifyFilters.FileName
        | NotifyFilters.DirectoryName
        | NotifyFilters.Attributes;

Agora, vamos criar o método que vai executar o script e adicioná-lo aos métodos watcher.Changed, watcher.Created, watcher.Deleted e watcher.Renamed do Watcher.

O Evento de edição pode (e vai) disparar mais de um evento Changed então, vamos criar um cache para isso.

private static Dictionary<string, DateTime> scriptExecutionCache = new Dictionary<string, DateTime>();


private static void SetupFileWatcher(FileWatcherJobTrigger trigger)
{
    var watcher = new FileSystemWatcher
    {
        Path = trigger.WatchedPath,
        Filter = "*",
        IncludeSubdirectories = true, // Incluiremos o monitoramento de subdiretórios
        EnableRaisingEvents = true, // Permitiremos a execução de eventos
    };

    watcher.NotifyFilter = NotifyFilters.LastWrite
            | NotifyFilters.FileName
            | NotifyFilters.DirectoryName
            | NotifyFilters.Attributes;

    void OnChange(object sender, FileSystemEventArgs e)
    {
        // Verifica se pode executar
        if (ScriptCanBeRunned(e.FullPath))
        {
            return;
        }

        // Executa o Script
        ExecuteScript(trigger);

        // Registra a ultima execução
        CacheScriptExecution(e.FullPath);
    }

    watcher.Changed += OnChange;
    watcher.Created += OnChange;
    watcher.Deleted += OnChange;
    watcher.Renamed += OnChange;
}


private static void CacheScriptExecution(string path)
{
    scriptExecutionCache[path] = DateTime.Now;
}

private static bool ScriptCanBeRunned(string path)
{
    if (!scriptExecutionCache.ContainsKey(path))
    {
        return false;
    }

    var lastExecution = scriptExecutionCache[path];

    // Caso tenha executado há mais de 1 segundo, retorna `true`
    return lastExecution.AddSeconds(1) > DateTime.Now;
}

O método ExecuteScript

Ele, na verdade, é bem simples.

Só vai verificar a existência e extensão do arquivo e executálo usando o Process.

private static void ExecuteScript(Trigger trigger)
{
    if (!File.Exists(trigger.ScriptFileName))
    {
        Console.WriteLine($"File not found: {trigger.ScriptFileName}");
        return;
    }

    if (!trigger.ScriptFileName.EndsWith(".ps1"))
    {
        throw new NotImplementedException($"Script type {trigger.ScriptFileName} is not implemented.");

    }

    var startInfo = new ProcessStartInfo()
    {
        FileName = "powershell.exe",
        Arguments = $"-ExecutionPolicy Bypass -File \"{trigger.ScriptFileName}\""
    };

    Process.Start(startInfo);
}

Depois disso, você só precisará criar o seu script e criar uma trigger para ele.

Caso não saiba fazer scripts com Powershell, leia esse artigo: about_Scripts.

Nesse exemplo, vou criar uma trigger que vai rodar à cada 5 segundos e executar um script que mostra o horário atual.

A trigger

{
  "Triggers": [
    {
      "ScriptFileName": "PATH\\TO\\script.ps1",
      "Type": "CronExpression",
      "CronExpression": "*/5 * * * * *"
    }
  ]
}

O script:

Add-Type -AssemblyName System.Windows.Forms
$now = Get-Date

Resultado:

Melhorias

Uma coisa interessante que pode ser feita é: passar parâmetros para o script.

Ex: Quando um arquivo for adicionado em uma pasta em específica, enviamos para o script o nome do evento e o nome do arquivo.

Passando argumentos

Pra isso, vamos alterar o ExecuteScript pra receber esses parâmetros:

// Recebe os parâmetros como uma lista de strings
private static void ExecuteScript(Trigger trigger, params string[] parameters)
{
    if (!File.Exists(trigger.ScriptFileName))
    {
        Console.WriteLine($"File not found: {trigger.ScriptFileName}");
        return;
    }

    if (!trigger.ScriptFileName.EndsWith(".ps1"))
    {
        throw new NotImplementedException($"Script type {trigger.ScriptFileName} is not implemented.");
    }

    var startInfo = new ProcessStartInfo()
    {
        FileName = "powershell.exe",
        // Adiciona os parametros no final dos argumentos
        Arguments = $"-ExecutionPolicy Bypass -File \"{trigger.ScriptFileName}\" {string.Join(' ', parameters)}",  
    };

    Process.Start(startInfo);
}

OnChange:
Nele, nós passamos os parâmetros nomeados nesse formado : -{KEY} "{VALUE}" cmo abaixo

void OnChange(object sender, FileSystemEventArgs e)
{
    Console.WriteLine($"File {e.Name} {e.ChangeType}");
    if (ScriptCanBeRunned(e.FullPath))
    {
        return;
    }

    ExecuteScript(
        trigger, 
        $"-EventType \"{e.ChangeType}\"", 
        $"-Name \"{e.Name}\"", 
        $"-FullPath \"{e.FullPath}\"");

    CacheScriptExecution(e.FullPath);
}

E no script, nós receberemos assim:

param (
    [string]$EventType,
    [string]$Name,
    [string]$FullPath
)

Add-Type -AssemblyName System.Windows.Forms

[System.Windows.Forms.MessageBox]::Show("EventType: $EventType`nName: $Name`nFullPath: $FullPath")

Resultado:

Conclusão

Ainda há muito que pode ser melhorado nesse projeto como:

[x] Criar o arquivo triggers.json caso ele não exista.
[x] Adicionar um FileSystemWatcher no arquivo triggers.json para atualizar as triggers.
[ ] Capturar o estado da máquina para poder passar em argumentos para os scripts (Ex: "MemoryUsage" ou "BatteryCharge")
[ ] Implementar Argumentos para os Jobs de CronExpression
[ ] Implementar novos tipos de trigger como baseadas em Eventos do Windows, Emails e etc.
[ ] Transformar em serviço
[ ] Adicionar sistema de logs
[ ] Criar interface para adicionar triggers e scripts

E se você se sentir à vontade, pode me ajudar com a implementação.
Ele já está lá no Github:

Link do repositório

Introdução ao desenvolvimento Mobile: Guia para Iniciantes

Rafael Coelho — Sun, 28 Apr 2024 19:31:17 +0000

O desenvolvimento mobile é um campo em constante evolução que oferece oportunidades de carreira emocionantes e desafiadoras para desenvolvedores de software. Com o aumento do uso de smartphones e tablets, a demanda por aplicativos móveis está crescendo rapidamente. O desenvolvimento móvel envolve a criação de aplicativos para dispositivos móveis, como smartphones e tablets, usando linguagens de programação específicas para dispositivos móveis.

Introdução ao Desenvolvimento Mobile é um curso que oferece uma introdução abrangente ao desenvolvimento de aplicativos móveis. O curso aborda os conceitos básicos de desenvolvimento de aplicativos móveis, como plataformas de desenvolvimento, linguagens de programação, arquitetura de aplicativos e design de interface do usuário. Além disso, o curso também abrange tópicos avançados, como desenvolvimento nativo e híbrido, segurança de aplicativos móveis e estratégias de lançamento de aplicativos.

Plataformas de Desenvolvimento Mobile

É importante escolher a plataforma de desenvolvimento que melhor atenda às necessidades do projeto. Nesta seção, serão apresentadas as três principais plataformas de desenvolvimento mobile: iOS, Android e Cross-platform.

iOS

O iOS é o sistema operacional móvel da Apple e é utilizado nos dispositivos iPhone e iPad. Para desenvolver aplicativos para iOS, é necessário utilizar a linguagem de programação Swift, que foi desenvolvida pela Apple. Além disso, é possível utilizar o Objective-C, que é uma linguagem mais antiga, mas ainda é suportada pela plataforma.

Uma das vantagens de desenvolver para iOS é que a plataforma é conhecida por ter usuários mais engajados e dispostos a gastar dinheiro com aplicativos. Além disso, a Apple tem um processo de aprovação rigoroso para os aplicativos que são disponibilizados na App Store, o que garante uma certa qualidade para os usuários.

Android

O Android é o sistema operacional móvel da Google e é utilizado em uma grande variedade de dispositivos de diferentes fabricantes. Para desenvolver aplicativos para Android, é possível utilizar diversas linguagens de programação, como Java, Kotlin e C++.

Uma das vantagens de desenvolver para Android é a grande quantidade de dispositivos que utilizam a plataforma. Isso significa que há um grande potencial de alcance para os aplicativos desenvolvidos. Além disso, a Google Play Store é conhecida por ter um processo de aprovação mais simples do que a App Store, o que pode facilitar a disponibilização dos aplicativos.

Cross-platform

As plataformas de desenvolvimento cross-platform permitem que os desenvolvedores criem aplicativos que possam ser executados em diferentes sistemas operacionais móveis, como iOS e Android. Algumas das principais plataformas de desenvolvimento cross-platform são o Xamarin, o React Native e o Flutter.

Uma das vantagens de desenvolver para cross-platform é a possibilidade de economizar tempo e recursos, já que é possível desenvolver um único aplicativo que possa ser executado em diferentes plataformas. Além disso, as plataformas de desenvolvimento cross-platform estão em constante evolução e oferecem cada vez mais recursos e funcionalidades para os desenvolvedores.

Linguagens de Programação

Swift

Swift é uma linguagem de programação criada pela Apple, lançada em 2014. Ela é utilizada principalmente para desenvolvimento de aplicativos para iOS, macOS, watchOS e tvOS. Swift é uma linguagem de programação moderna, rápida e segura, com uma sintaxe clara e concisa. É uma opção popular para desenvolvedores que desejam criar aplicativos para o ecossistema da Apple.

Kotlin

Kotlin é uma linguagem de programação criada pela JetBrains, lançada em 2011. Ela é utilizada principalmente para desenvolvimento de aplicativos para Android. Kotlin é uma linguagem moderna, segura e concisa, que se integra perfeitamente com o Java. Ela é uma opção popular para desenvolvedores que desejam criar aplicativos para a plataforma Android.

JavaScript

JavaScript é uma linguagem de programação que é amplamente utilizada em desenvolvimento web e, mais recentemente, em desenvolvimento de aplicativos móveis. Ela é uma linguagem de programação dinâmica, orientada a objetos e baseada em protótipos. JavaScript é uma opção popular para desenvolvedores que desejam criar aplicativos móveis multiplataforma.

Dart

Dart é uma linguagem de programação criada pela Google, lançada em 2011. Ela é utilizada principalmente para desenvolvimento de aplicativos para o Flutter, um framework de desenvolvimento de aplicativos móveis. Dart é uma linguagem moderna, rápida e segura, com uma sintaxe clara e concisa. Ela é uma opção popular para desenvolvedores que desejam criar aplicativos móveis para iOS e Android com o Flutter.

Ferramentas de Desenvolvimento

Ao desenvolver aplicativos móveis, é essencial ter as ferramentas de desenvolvimento adequadas para garantir um processo suave e eficiente. Nesta seção, serão apresentadas algumas das principais ferramentas de desenvolvimento utilizadas pelos desenvolvedores de aplicativos móveis.

Xcode

O Xcode é uma ferramenta de desenvolvimento de aplicativos móveis exclusiva para dispositivos iOS e macOS. É um ambiente de desenvolvimento integrado (IDE) que inclui um editor de código, depurador, simulador de dispositivos e outras ferramentas úteis. O Xcode é amplamente utilizado por desenvolvedores de aplicativos iOS devido à sua facilidade de uso e à grande quantidade de recursos disponíveis. Além disso, o Xcode é atualizado regularmente pela Apple para garantir que os desenvolvedores tenham acesso às mais recentes tecnologias e recursos.

Android Studio

O Android Studio é a principal ferramenta de desenvolvimento de aplicativos móveis para dispositivos Android. É um IDE baseado no IntelliJ IDEA que inclui um editor de código, depurador, emulador de dispositivos e outras ferramentas. O Android Studio é amplamente utilizado por desenvolvedores de aplicativos Android devido à sua facilidade de uso e à grande quantidade de recursos disponíveis. Além disso, o Android Studio é atualizado regularmente pelo Google para garantir que os desenvolvedores tenham acesso às mais recentes tecnologias e recursos.

Visual Studio Code

O Visual Studio Code é um editor de código-fonte gratuito e de código aberto desenvolvido pela Microsoft. Embora não seja uma ferramenta de desenvolvimento exclusiva para aplicativos móveis, é amplamente utilizado por desenvolvedores de aplicativos móveis devido à sua velocidade e facilidade de uso. O Visual Studio Code também oferece suporte a uma ampla variedade de extensões e plugins que podem ser usados para melhorar a produtividade do desenvolvedor.

Flutter

Flutter é um SDK de desenvolvimento de aplicativos móveis de código aberto criado pelo Google. Ele permite que os desenvolvedores criem aplicativos móveis nativos para iOS e Android usando uma única base de código. O Flutter inclui um conjunto completo de widgets personalizados e permite que os desenvolvedores criem interfaces de usuário atraentes e responsivas. Além disso, o Flutter é atualizado regularmente pelo Google para garantir que os desenvolvedores tenham acesso às mais recentes tecnologias e recursos.

Essas são algumas das principais ferramentas de desenvolvimento de aplicativos móveis utilizadas pelos desenvolvedores. Cada ferramenta tem suas próprias vantagens e desvantagens, e a escolha da ferramenta certa dependerá das necessidades e preferências do desenvolvedor.

Design de Interface

O design de interface é uma parte fundamental do desenvolvimento mobile, pois é a primeira impressão que o usuário terá do aplicativo. Uma boa interface deve ser intuitiva, fácil de usar e agradável visualmente.

Material Design

O Material Design é um conjunto de diretrizes de design criado pela Google. Ele é baseado em um design limpo e moderno, com ênfase em tipografia, cores e imagens. O objetivo é criar uma interface que pareça física, com camadas e sombras. Isso ajuda o usuário a entender a hierarquia das informações na tela.

Algumas das principais características do Material Design incluem:

Tipografia clara e legível
Uso de cores vibrantes e saturadas
Uso de ícones simples e claros
Uso de animações sutis para indicar mudanças na interface

Human Interface Guidelines

As Human Interface Guidelines (HIG) são um conjunto de diretrizes de design criado pela Apple. Elas são baseadas em um design limpo e minimalista, com ênfase na usabilidade e na consistência. O objetivo é criar uma interface que seja fácil de usar e que pareça familiar para os usuários do iOS.

Algumas das principais características das HIG incluem:

Uso de tipografia clara e legível
Uso de cores suaves e pastéis
Uso de ícones simples e claros
Uso de animações sutis para indicar mudanças na interface

Ao desenvolver um aplicativo, é importante escolher um conjunto de diretrizes de design que se adapte à plataforma escolhida. Isso ajudará a criar uma interface consistente e fácil de usar para os usuários.

Desenvolvimento Front-end

O desenvolvimento front-end é uma parte essencial do desenvolvimento mobile. Ele é responsável por criar a interface do usuário, tornando-a agradável e fácil de usar. É através do front-end que o usuário interage com o aplicativo, por isso é importante que ele seja bem projetado e desenvolvido.

Uma das principais ferramentas usadas no desenvolvimento front-end é o HTML, que é a linguagem usada para criar a estrutura do aplicativo. O CSS é usado para estilizar a interface do usuário, tornando-a visualmente atraente e fácil de usar. O JavaScript é usado para adicionar interatividade à interface do usuário, tornando-a mais dinâmica.

Além disso, o desenvolvedor front-end deve estar ciente das melhores práticas de design e usabilidade para garantir que o aplicativo seja fácil de usar e agradável aos olhos do usuário. Ele também deve estar ciente das últimas tendências em design de aplicativos móveis para garantir que o aplicativo seja moderno e atualizado.

Em resumo, o desenvolvimento front-end é uma parte crucial do desenvolvimento mobile. Ele é responsável por criar a interface do usuário, tornando-a agradável e fácil de usar. Para ter sucesso no desenvolvimento front-end, o desenvolvedor deve estar ciente das melhores práticas de design e usabilidade, além de estar atualizado com as últimas tendências em design de aplicativos móveis.

Desenvolvimento Back-end

O desenvolvimento back-end é a parte do desenvolvimento mobile responsável pelo gerenciamento de dados e lógica de negócios. É a parte do aplicativo que lida com os servidores, bancos de dados e APIs.

Para o desenvolvimento back-end, é importante escolher a linguagem de programação adequada. Algumas das linguagens de programação mais populares para o desenvolvimento back-end incluem Java, PHP, Python e Ruby. Cada linguagem tem suas próprias vantagens e desvantagens, por isso é importante escolher a que melhor se adequa às necessidades do projeto.

Além da escolha da linguagem de programação, também é importante escolher o banco de dados adequado. Alguns dos bancos de dados mais populares para o desenvolvimento back-end incluem MySQL, PostgreSQL e MongoDB. Cada banco de dados tem suas próprias vantagens e desvantagens, e a escolha deve ser feita com base nas necessidades do projeto.

O desenvolvimento back-end é uma parte crítica do desenvolvimento mobile, pois é responsável pelo gerenciamento de dados e lógica de negócios. Uma boa estratégia de desenvolvimento back-end pode garantir que o aplicativo funcione de forma eficiente e confiável.

Integração com APIs

A integração com APIs é uma parte crucial do desenvolvimento mobile. APIs, ou Application Programming Interfaces, são conjuntos de rotinas e padrões de programação que permitem que diferentes softwares se comuniquem entre si. No contexto do desenvolvimento mobile, as APIs são usadas para acessar serviços externos, como bancos de dados, sistemas de pagamento e redes sociais.

Existem várias maneiras de integrar APIs em um aplicativo mobile. Uma das abordagens mais comuns é o uso de bibliotecas de terceiros, que fornecem funcionalidades prontas para uso. As bibliotecas podem ser encontradas em repositórios como o GitHub e o CocoaPods, e geralmente são bem documentadas e testadas.

Outra opção é criar uma API personalizada para o aplicativo. Isso pode ser feito usando frameworks como o Laravel ou o Express, que permitem criar APIs RESTful de forma fácil e rápida. Uma API personalizada tem a vantagem de ser mais flexível e adaptável às necessidades específicas do aplicativo.

Independentemente da abordagem escolhida, é importante garantir que a integração com a API seja segura e confiável. Isso pode ser feito usando autenticação e autorização adequadas, validação de entrada de dados e criptografia de dados sensíveis.

Em resumo, a integração com APIs é uma parte fundamental do desenvolvimento mobile, e existem várias maneiras de implementá-la. Ao escolher uma abordagem, é importante considerar a flexibilidade, a segurança e a confiabilidade da solução.

Testes e Qualidade de Software

A qualidade do software é essencial para o desenvolvimento mobile. Para garantir que o aplicativo funcione corretamente, é necessário realizar uma série de testes. Os testes são responsáveis por identificar possíveis falhas e garantir que o aplicativo atenda às expectativas do usuário.

Testes Unitários

Os testes unitários são responsáveis por testar individualmente cada componente do aplicativo. Esse tipo de teste é importante para garantir que o código esteja funcionando corretamente e que não haja erros. Além disso, os testes unitários ajudam a identificar possíveis problemas no código antes mesmo de o aplicativo ser lançado.

Testes de Integração

Os testes de integração são responsáveis por testar a interação entre os diferentes componentes do aplicativo. Esse tipo de teste é importante para garantir que o aplicativo esteja funcionando corretamente como um todo. Os testes de integração ajudam a identificar possíveis problemas na integração dos diferentes componentes do aplicativo.

Testes de Interface

Os testes de interface são responsáveis por testar a interface do usuário. Esse tipo de teste é importante para garantir que a interface do usuário esteja funcionando corretamente e que o usuário possa interagir com o aplicativo de forma intuitiva. Os testes de interface ajudam a identificar possíveis problemas na usabilidade do aplicativo.

Para garantir a qualidade do software, é importante realizar testes em todas as etapas do desenvolvimento. Isso ajuda a identificar possíveis problemas antes mesmo de o aplicativo ser lançado. Além disso, é importante que os testes sejam realizados de forma sistemática e que os resultados sejam documentados para futuras referências.

Publicação e Distribuição

Ao concluir o desenvolvimento de um aplicativo móvel, é hora de publicá-lo e distribuí-lo para que os usuários possam baixá-lo e utilizá-lo. Existem duas principais plataformas de distribuição de aplicativos móveis, a App Store e o Google Play.

App Store

A App Store é a loja de aplicativos da Apple, disponível apenas para dispositivos iOS. Para publicar um aplicativo na App Store, é necessário criar uma conta de desenvolvedor da Apple e pagar uma taxa anual. Além disso, o aplicativo deve atender aos padrões de qualidade e segurança da Apple e passar por uma revisão antes de ser aprovado para a publicação.

Google Play

O Google Play é a loja de aplicativos do Google, disponível para dispositivos Android. Para publicar um aplicativo na Google Play, é necessário criar uma conta de desenvolvedor do Google e pagar uma taxa única. O aplicativo deve atender às políticas de desenvolvimento do Google e passar por uma revisão antes de ser publicado.

Ambas as plataformas oferecem ferramentas para gerenciar as atualizações e o desempenho do aplicativo, além de permitir que os desenvolvedores vejam as estatísticas de download e uso. É importante lembrar que a publicação e distribuição de um aplicativo móvel não garante o sucesso, mas é um passo importante para torná-lo disponível para os usuários.

Manutenção e Atualizações

Manter um aplicativo móvel atualizado é essencial para garantir que ele funcione corretamente e atenda às necessidades dos usuários. A manutenção e atualização do aplicativo podem incluir correção de bugs, melhorias de desempenho e segurança, além de adição de novos recursos.

Uma das principais razões para manter um aplicativo atualizado é a correção de bugs. Bugs podem causar problemas como falhas no aplicativo, erros de exibição ou problemas de desempenho. Corrigir esses bugs é importante para garantir que o aplicativo funcione corretamente e proporcione uma boa experiência ao usuário.

Além disso, a manutenção e atualização do aplicativo podem incluir melhorias de desempenho, como otimização de velocidade e redução de consumo de bateria. Isso é importante para garantir que o aplicativo funcione sem problemas em diferentes dispositivos e sistemas operacionais.

A segurança também é uma consideração importante na manutenção e atualização do aplicativo. As atualizações podem incluir correções de segurança para garantir que o aplicativo esteja protegido contra ameaças externas, como hackers e malware.

Por fim, a adição de novos recursos é uma maneira de manter o aplicativo relevante e atraente para os usuários. Os novos recursos podem incluir melhorias de usabilidade, novas funcionalidades ou integrações com outras plataformas.

Em resumo, a manutenção e atualização do aplicativo móvel são essenciais para garantir que ele funcione corretamente, seja seguro e ofereça uma boa experiência ao usuário.

Sorteio de Amigo Secreto: Sem API, Só Hash

Rafael Coelho — Thu, 15 Feb 2024 04:03:07 +0000

No final do ano de 2023 eu topei participar de um Amigo Secreto da minha familia que, como cada um mora distante do outro, foi sorteado online.
A organizadora nos enviou links onde vimos os nomes de quem tiramos.

E algo me chamou muita atenção...

O site pareceu uma aplicação tão simples: Uma plataforma onde você informa uma lista de nomes que terão pares sorteados e links individuais para exibição dos nomes.

E eis o que me chamou a atenção: a elegância de uma solução simples.

Então, decidi recriar a mesma aplicação...

A ideia

Sempre que penso na construção de uma aplicação, uma das primeiras coisas que penso é: como vou estruturar e armazenar os dados?

E a resposta para a geração desses links é: não vou!

O sorteado não precisa de muito mais do que o nome da pessoa que ele sorteou, certo? Então, é só o que vamos mandar para ele!

E quanto ao dono do sorteio?

Bem... ele talvez precise ver novamente alguma informação daquele Amigo Secreto. Então, podemos persistir de uma forma que só ele veja, assim, não precisando de nenhuma centralização de dados.

O projeto

A aplicação teria 4 telas

Inicial: onde o usuário veria a lista de seus sorteios já criados.
Formulário de Criação do Amigo Secreto.
Tela de visualização: Onde o usuário veria cada nome atrelado a um botão de "Enviar Link".
Tela de revelação: onde o sorteado veria o nome da pessoa que sorteou.

Escolhi usar NextJS e usar o IndexedDB para persistência local.

1 - Formulário de Criação

Sim, vamos começar com ele.

Pensei um pouco sobre como seria para adicionar multiplos nomes e fiquei dividido entre um input baseado em Tags usando algum separador:

E entre multiplos inputs seguidos por um botão de "adicionar outro" como abaixo:

E no fim acabei optando pela segunda opção.

E agora, após o usuário apertar para enviar, a aplicação precisa gerar o sorteio e gerar os hashs para o link.

Então, precisamos de um método que que sorteie e outro que gere os hashs.
Esse foi o resultado:

type Pair = {
  name: string;
  hash: string;
}

// Método chamado no onSubmit
const sortPairs = (names: string[]): Pair[] => {
  const _pairs: Pair[] = [];
  const _names = [...names];

  // Reordena aleatoriamente
  _names.sort(() => Math.random() - 0.5);


  for (let i = 0; i < _names.length; i++) {
      const name = _names[i].trim();

      // Monta o par com a próxima index
      const nextIndex = (i != _names.length - 1) ? i + 1 : 0;
      const pair = _names[nextIndex].trim();

      // Chama o método de encriptação
      const hash = encryptNamePair(name, pair);
      _pairs.push({
          name,
          hash
      });
  }

  return _pairs;
};

E o encryptNamePair, que recebe dois nomes, só precisa concatená-los e converter e base64.

O formato antes da conversão ficaria mais ou menos assim: "Nome1-Nome2", para que a gente saiba a quem pertence o link.

const encryptNamePair = (n1: string, n2: string) => {
    const namesJoint = `${n1.replace(/ /g, '+').trim()}-${n2.replace(/ /g, '+').trim()}`;
    return btoa(unescape(encodeURIComponent(namesJoint)));
}

E quanto a persistência local, decidi usar o IndexedDB do próprio navegador.

Pra isso, criei uma classe IndexedDBManager para gerenciar as chamadas.
Não vou perder muito tempo explicando, porque é tudo muito padrão aqui.
Mas o código ficou assim:

// IndexedDBManager.ts
export class IndexedDBManager {
  // Informações do banco local
  private dbName: string = "RcSecretSantaDB";
  private dbVersion: number = 1;
  private db: IDBDatabase | null = null;
  private readonly tableName: string = "secretSantas";

  constructor() { }

  // Método de conexão
  public async connect (): Promise<void> {
    return new Promise((resolve, reject) => {
      const request = indexedDB.open(this.dbName, this.dbVersion);

      request.onerror = () => {
        reject(new Error("Erro ao abrir o banco de dados."));
      };

      request.onsuccess = (event) => {
        this.db = (event.target as IDBOpenDBRequest).result;
        resolve();
      };

      request.onupgradeneeded = (event) => {
        const db = (event.target as IDBOpenDBRequest).result;
        if (!db.objectStoreNames.contains(this.tableName)) {
          db.createObjectStore(this.tableName, { keyPath: "id" });
        }
      };
    });
  }

  // Método de inserção
  public async addEditItem (item: any): Promise<void> {
    return new Promise((resolve, reject) => {
      this.connect().then(() => {
        if (!this.db) {
          reject(new Error("Banco de dados não conectado."));
          return;
        }

        const transaction = this.db.transaction([this.tableName], "readwrite");
        const objectStore = transaction.objectStore(this.tableName);

        const request = objectStore.put(item);

        request.onsuccess = () => {
          resolve();
        };

        request.onerror = () => {
          reject(new Error("Erro ao adicionar/editar item no banco de dados."));
        };
      })
    });
  }
}

Então, no método onSumbit do formulário eu só preciso chamar assim:

const dbManager = new IndexedDBManager();
await dbManager.addEditItem({ id: uuidv4(), title, pairs });

E pronto. Nossos Amigos Secretos já podem ser salvos!

2 - Home - Listagem de Amigos Secretos

Ela só precisa de três coisas:

Uma lista dos Amigos Secretos
Um botão para excluir um item
Um link para visualizar um item em específico

Para buscar os dados do IndexedDB só é necessário o método abaixo:

// IndexedDBManager.ts
public async getItems (): Promise<any[]> {
  return new Promise((resolve, reject) => {
    this.connect().then(() => {
      if (!this.db) {
        reject(new Error("Banco de dados não conectado."));
        return;
      }

      const transaction = this.db.transaction([this.tableName], "readonly");
      const objectStore = transaction.objectStore(this.tableName);

      const request = objectStore.getAll();

      request.onsuccess = (event) => {
        const result = (event.target as IDBRequest).result;
        resolve(result || []);
      };

      request.onerror = () => {
        reject(new Error("Erro ao obter itens do banco de dados."));
      };
    });
  });
}

E para o caso de o usuário querer excluir:

// IndexedDBManager.ts
public async deleteItem (id: string): Promise<void> {
  return new Promise((resolve, reject) => {
    this.connect().then(() => {
      if (!this.db) {
        reject(new Error('Banco de dados não conectado.'));
        return;
      }

      const transaction = this.db.transaction([this.tableName], 'readwrite');
      const objectStore = transaction.objectStore(this.tableName);

      const request = objectStore.delete(id);

      request.onsuccess = () => {
        resolve();
      };

      request.onerror = () => {
        reject(new Error('Erro ao excluir item do banco de dados.'));
      };
    });
  });
}

3 - Visualização de Amigo Secreto

Essa é a minha favorita.

Ela precisa capturar o dado do IndexedDB e apresentar os nomes dos participantes atrelados à um link.

A minha ideia foi criar um botão de compartilhamento onde haveria uma mensagem explicando basicamente o contexto da mensagem e fornecendo o link.

Vamos lá... Primeiramente, precisamos recuperar o item.
A tela recebe a ID gerada pela tela de criação e envia para o método getItemById que vai retornar o Objeto de SecretSanta.

// IndexedDBManager.ts
public async getItemById <T>(id: string): Promise<T | null> {
  return new Promise((resolve, reject) => {
    this.connect().then(() => {
      if (!this.db) {
        reject(new Error('Banco de dados não conectado.'));
        return;
      }

      const transaction = this.db.transaction([this.tableName], 'readonly');
      const objectStore = transaction.objectStore(this.tableName);
      const request = objectStore.get(id);

      request.onsuccess = (event) => {
        const result = (event.target as IDBRequest).result;
        resolve(result || null);
      };

      request.onerror = () => {
        reject(new Error('Erro ao obter item do banco de dados.'));
      };
    });
  });
}

Depois disso, adicionei a listagem dos nomes e criei um componente SharedButton que é bem simples:

// ShareButton.tsx
interface IShareButtonProps {
  title: string;
  text: string;
  className?: string;
}

const ShareButton = ({ title, text, className }: IShareButtonProps) => {
  const handleShare = () => {
    if (navigator.share) {
      navigator.share({
        title,
        text
      });
    } else {
      console.error('Web Share API não é suportada neste navegador.');
    }
  };

  return (
    <button className={className} onClick={handleShare}>{title}</button>
  );
};

E o adicionei no [id].tsx assim:


const View = () => {
  const [data, setData] = useState<SecretSanta>();
  const hostLink = window.location.origin;
  // ...

  return (
    <>
      {
        data.pairs.map((pair) => (
          // ....
          <ShareButton
              title="Enviar"
              text={
                `Você foi adicionado ao Amigo Secreto: "${data.title}"!\nE aqui está o seu link:\n${hostLink}}/${pair.hash}`
              }
          />
        ))
      }
    </>
  );
};

O que fica mais ou menos assim:

4 - A tela de revelação

Ela é a mais simples de todas.
Como o link contem o hash, só precisamos recuperá-lo, desencriptar e então separar os nomes.

E fazemos isso com o método abaixo:

const decryptNamePair = (encodedStr: string) => {
    const decodedString = decodeURIComponent(escape(atob(encodedStr)));
    if (!/(.*)-(.*)/.test(decodedString)) {
        return null;
    }

    return decodedString.replace(/\+/g, " ").split("-");
};

// [hash].tsx
const [name1, name2] = decryptNamePair(hash);

Após receber os nomes, tudo o que precisamos é exibi-los na tela de uma forma amigável.
E eu escolhi fazer assim:

Conclusão

Esse foi um projeto rápido que me deixou bem satisfeito por tamanha simplicidade.
Projetos assim, me provam que nem tudo precisa ser complexo ou mega elaborado.

O melhor sistema é o que funciona! Não se esqueça disso!

Depois de completo, eu ainda gastei um tempinho refinando e adicionando tradução, mas acho que não tem muito mais o que mexer nele.

Fique à vontade para olhar usar ou ver o código fonte:

Acesse - Amigo Secreto

Código Fonte

Jabá:

Veja esse e outros posts no meu blog:

Blog Racoelho

De 35 à 3 segundos: Melhorando a Performance de um Relatório

Rafael Coelho — Wed, 14 Feb 2024 15:17:58 +0000

Um belo dia, recebo um ticket que reclamava de algo:
Relatório está demorando demais

Contexto

Estou em um projeto de um SaaS onde se coleta centenas de sinais por minuto para serem inseridos no database do BigQuery e que, eventualmente, são processados para geração de relatórios.

No caso desse post, os relatório em questão busca os dados das viagens geradas por um motorista em um determinado intervalo de tempo e compara seu desempenho com o restante da frota.

Disclaimer

Este sistema ainda está em desenvolvimento e homologação, então, muitas decisões foram tomadas sem o mesmo volume de dados ou criados às pressas para melhorias futuras.

O Problema

Com o aumento do uso, o volume de dados aumentou e eventualmente algumas lentidões foram notadas:
O relatório, quando buscado num intervalo de 7 dias, tomava cerca de 30 segundos para devolver a resposta.

E com este ticket foi traçada uma meta: resposta em 3 segundos.

Solucionando

Com isso dito, comecei a analisar o código para procurar os pontos mais lentos.
Usando um Stopwatch, metrifiquei cada etapa do relatório para descobrir que dos 35 segundos da minha request, metade ocorria em 2 buscas ao banco que aconteciam no inicio do processo da Service.

Em resumo, a função recebia um StartDateTime e um EndDateTime e um identificador do veículo e realizava uma lógica parecida com a abaixo:

# Service.cs
// Busca todas as viagens da frota
IEnumerable<VehicleTrip> fleetTrips = await facade.GetTripsAsync(startTime, endTime);

// Filtra as viagens daquele veículo em específico
IEnumerable<VehicleTrip> vehicleTrips = fleetTrips.Where(x => x.VehicleId == vehicleId).ToList();

foreach(var trip in vehicleTrips) {
  // Busca uma lista de eventos para ocorridos na viagem
  trip.Events = await facade.GetEventsAsync(...);
}

// Instancia o objeto de retorno onde é processada a média dos dados
var reportResult = new ReportExample(vehicleTrips);

if(fleetTrips.Any()) {
  // Realizava a comparação de desempenho individual com o da frota inteira
  reportResult.CalculatePercentageDifferenceToTheFleet(fleetTrips);
}

return reportResult;

Se você deu uma boa olhada, já deve ter conseguido encontrar onde estão pelo menos dois dos gaps.

Então, vamos para o primeiro:

Alterando o facade.GetTripsAsync()

Como pode perceber, esse método captura todos os dados de todos os veículos da frota e só os usaria no final do processo, o que me pareceu um esforço desnecessário.

Claro, até havia caching. Assim, nos momentos em que era necessário buscar a quantidade de eventos críticos ou mesmo realizar alguma filtragem, os dados já estavam lá.

Mas mesmo assim, as informações que não seriam exclusivamente do veículo não pareciam ser necessárias em outro momento além daquele método CalculatePercentageDifferenceToTheFleet onde seriam comparadas as médias de desempenho entre o Veículo e a Frota para informações como:

"O veículo está consumindo, em média, X% a mais do que a frota"
"O veículo está andando, em média, X% a mais rápido do que a frota"

E não há necessidade de calcular a média da frota no código, uma vez que podemos buscá-la diretamente no banco.

Então essas foram as primeiras alterações:

O método foi atualizado para buscar unicamente os dados do veículo ;
Criação do método facade.GetFleetStats() para retornar as médias de toda a frota sem a necessidade de listar os dados;
Adaptação do método CalculatePercentageDifferenceToTheFleet para receber o objeto retornado do facade.GetFleetStats ao invés da listagem de trips;

# Service.cs
// Busca todas as viagens do veículo
var vehicleTrips = await facade.GetVehicleTripsAsync(startTime, endTime, vehicleId);

foreach(var trip in vehicleTrips) {
  // Busca uma lista de eventos para ocorridos na viagem
  trip.Events = await facade.GetEventsAsync(...);
}

// Executa o calculo das médias de sinais da Frota
FleetStats fleetStats = await facade.GetFleetStatsAsync(startTime, endTime);

// Instancia o objeto de retorno onde é processada a média dos dados
var reportResult = new ReportExample(vehicleTrips);

if(fleetStats != null) {
  // Método alterado para receber FleetStats ao invés de IEnumerable<VehicleTrip>
  reportResult.CalculatePercentageDifferenceToTheFleet(fleetStats);
}

return reportResult;

E o resultado foi: resposta média da API em 18 segundos.
Bom? Eu não achei.

O que me levou para a segunda alteração.

Removendo multiplas chamadas ao facade.GetEventsAsync()

Para cada uma das viagens, a aplicação precisa buscar os eventos gerados dentro do intervalo dela.
E como já deve ter pensado por conta própria, realizar uma chamada assíncrona para cada uma das trips não era a melhor solução... então a alteração foi bem intuitiva e rápida:

Este código:

var vehicleTrips = await facade.GetVehicleTripsAsync(startTime, endTime, vehicleId);

foreach(var trip in vehicleTrips) {
  trip.Events = await facade.GetEventsAsync(trip.StartDateTime, trip.EndDateTime, trip.VehicleId);
}

Foi substituido por este:

var events = await facade.GetEventsAsync(startTime, endTime);
var vehicleTrips = await facade.GetVehicleTripsAsync(startTime, endTime, vehicleId)
    .Select(trip =>
    {
      trip.Events = events
        .Where(x => x.DateTimeUTC >= trip.StartDateTime && 
                    x.DateTimeUTC <= trip.EndDateTime)
        .ToList();
        return trip;
    });

E o resultado?
Resposta media de: 14 segundos.
Ainda não chegamos na meta, mas estávamos à caminho.

Ajustando a busca no banco

Neste momento, eu fiz dezenas de alterações em queries tentando diminuir os dados processados e conversões.
O que só deve ter reduzido uma média de 2 segundos.

E onde estavam os gaps????? Nos MESMOS lugares: nas comunicações com o BigQuery.
Seria isso um problema de performance do mecanismo?

Eu tinha certeza que não, mas o Stopwatch me dizia claramente: nenhuma outra operação leva sequer 1s enquanto as comunicações com o BigQuery levam em média 6s.

Então, fui olhar a implementação da classe de conexão.

Aqui vai uma pequena explicação:

A classe BigQuery.cs que vou mostrar faz parte dos building blocks da aplicação e precisa ser genérico ao ponto de converter os dados nos formatos corretos das propriedades.

O código que encontrei foi parecido com esse:

# BigQuery.cs
public async Task<List<T>> GetQueryResultsAsync<T>(string query)
{
  using var bigQueryClient = bqClientFactory.Create();
  var job = await bigQueryClient.CreateQueryJobAsync(query);

  // Lista de retorno
  var list = new List<T>();

  var bigQueryRows = await bigQueryClient.GetQueryResultsAsync(job.Reference);
  if ((bigQueryRows.SafeTotalRows ?? 0) > 0)
  {
    // Para cada linha retornada do banco...
    foreach (BigQueryRow row in bigQueryRows)
    {
      T data = default;

      // Converte a linha para o objeto T chamando o método de ParseRow.
      data = ParseRow<T>(row);

      // Adiciona na lista que será retornada
      list.Add(data);
    }
  }

  return list;
}

O primeiro problema a ser explorado:

O uso do List<T>.

Se você não sabe como o List funciona, aqui vai uma breve explicação...

Para a criação de um array você precisa fornecer o tamanho dele, ou seja, quantos itens ele poderá guardar e este tamanho será imutável!

Ex.:

var arr = new int[8];
Console.WriteLine("Tamanho do arr: {0}", arr.Length);
// Tamanho do arr: 8

var arr2 = new int[] { 0, 1, 2, 3, 4, 5, 6, 7 };
Console.WriteLine("Tamanho do arr2: {0}", arr2.Length);
// Tamanho do arr2: 8

Mas porque não precisamos informar um tamanho para o List?
Quando você gera um List, ele cria um array de tamanho 0 e quando você adiciona itens dentro dele com o .Add() ele gera um NOVO array com tamanho 4, vai atribuir o valor do array anterior ao novo e descartar o velho.

"E se eu rodar o .Add() 5 vezes?"

Ele criará um novo array de tamanho 8 e assim seguirá: todas as vezes que exceder o tamanho, um novo array será criado com o DOBRO do tamanho que vai receber o valor do antigo que será descartado.

Ex.:

var list = new List<int>();
Console.WriteLine("Itens: {0}, Capacidade: {1}", list.Count, list.Capacity);
// Itens: 0, Capacidade: 0

list.Add(0);
Console.WriteLine("Itens: {0}, Capacidade: {1}", list.Count, list.Capacity);
// Itens: 1, Capacidade: 4

list.Add(1);
list.Add(2);
list.Add(3);
list.Add(4);
Console.WriteLine("Itens: {0}, Capacidade: {1}", list.Count, list.Capacity);
// Itens: 5, Capacidade: 8

Já entendeu o problema?
Então, haverão vários cenários em que teremos dados duplicados em dois arrays diferentes.
E quanto maior a lista tratada, maior o tempo de processamento e a memória alocada.

Então, a alteração foi a seguinte:

A remoção do List<T>
A substituição do foreach por um .Select() com conversão direta

O que deixou o metódo mais ou menos assim:

#BigQuery
public async Task<List<T>> GetQueryResultsAsync<T>(string query)
{
  using var bigQueryClient = bqClientFactory.Create();
  var job = await bigQueryClient.CreateQueryJobAsync(query);

  return (bigQueryRows.SafeTotalRows ?? 0) > 0
      ? bigQueryRows.Select(ParseRow<T>).ToList()
      : new List<T>();
}

E qual foi o resultado disso?????????
Uma resposta média de 6 segundos!!!!!!

Nesse momento eu olhei pra trás, e vendo que a versão anterior ainda conseguia levar até 40 segundos, eu quase me senti satisfeito com o resultado....

Quase.

Isso porque o ticket dizia "3 segundos".
O que me levou a analizar o método ParseRow que é chamado pelo método que acabamos de alterar.

Analisando o ParseRow

Ele tem uma função bem simples:
Ao receber a linha, ele deve instanciar o genério T e iterar sobre cada uma das colunas da row e buscá-la nas propriedades de T.
Veja:

#BigQuery
private T ParseRow<T>(BigQueryRow row)
{
  // Criação de instância do genérico
  T result = Activator.CreateInstance<T>();
  // Armazena todas as propriedades do objeto
  var typeProperties = typeof(T).GetProperties();

  // Loop para iterar cada coluna...
  for (int i = 0; i < row.Schema.Fields.Count; i++)
  {
    // Armazena nome e valor do campo
    var field = row.Schema.Fields[i];
    var value = row.RawRow.F[i].V?.ToString();

    // Confere se a coluna atual existe no objeto
    var matchingProperty = typeProperties.FirstOrDefault(x => x.Name.ToLower() == field.Name.ToLower());

    // Caso não encontre ou não tenha valor... skip.
    if (matchingProperty == null || string.IsNullOrWhiteSpace(value))
      continue;

    // Converte e atribui dados conforme o tipo da propriedade 
    // ...
  }

  return result;
}

E a pergunta principal foi "O que dá pra melhorar?" e a resposta estava na variável typeProperties.

Ela armazena cada uma das propriedades do objeto T, mas isso acontece para cada uma das linhas retornadas do banco... o que quer dizer que se houver um resultado de 1800 linhas para um objeto de 12 propriedades.... bem, você entendeu.

Então, a melhor solução é fazer a aplicação buscar uma única vez e reutilizar a informação coletada.

E como o método GetQueryResultsAsync é chamado algumas vezes durante o processo e durante todo o ciclo de vida da aplicação, melhor do que armazenar numa unica variável seria criar uma tabela como caching.

O que deixou o código mais ou menos assim:

#BigQuery.cs

private static readonly ConcurrentDictionary<Type, PropertyInfo[]> _typePropertiesCache = new ConcurrentDictionary<Type, PropertyInfo[]>();

private T ParseRow<T>(BigQueryRow row)
{
  T result = Activator.CreateInstance<T>();
  var typeProperties = typeof(T).GetProperties();
  var typeProperties = _typePropertiesCache.GetOrAdd(typeof(T), t => t.GetProperties());
  /*
      [...]
  */

  return result;
}

Com isso, a aplicação armazenaria uma única vez as informações de um objeto e nunca mais o consultaria, poupando armazenamento e tempo de processamento.

E agora, meus amigos...
Com isso, chegamos a marca média dos........................................

3.2 segundos

Mas ainda faltava algo...

Threading

Depois de tudo isso, ainda havia uma coisa que poderia ser alterada lá na Service.

Das 3 chamadas ao facade, somente uma delas precisava da resposta de outra.

Então, não havia a necessidade de esperar chamada por chamada para montar o resultado desde que eu garanta que todas foram executadas.

E com isso em mente, nosso código da service foi atualizado para algo assim:

# Service.cs
// Declaração das chamadas
var eventsTask = facade.GetEventsAsync(startTime, endTime);
var vehicleTripsTask = facade.GetVehicleTripsAsync(startTime, endTime, vehicleId);
var fleetStatsTask = facade.GetFleetStatsAsync(startTime, endTime);

// Aguardando a execução de todas simultâneamente
await Task.WhenAll(eventsTask, vehicleTripsTask, fleetStatsTask);

// Aplicando o "await" da task que já está completa
var events = await eventsTask;

// Aplicando o "await" da task que já está completa
var vehicleTrips = (await vehicleTripsTask)
    .Select(trip =>
    {
      trip.Events = events
        .Where(x => x.DateTimeUTC >= trip.StartDateTime && 
                    x.DateTimeUTC <= trip.EndDateTime)
        .ToList();
        return trip;
    });

// Aplicando o "await" da task que já está completa
FleetStats fleetStats = await fleetStatsTask;

var reportResult = new ReportExample(vehicleTrips);
if(fleetStats != null) {
  reportResult.CalculatePercentageDifferenceToTheFleet(fleetStats);
}

return reportResult;

Conclusão

Com isso, eu decidi rodar mais uma vez a versão existente e compará-la com a minha.

E esses foram os resultados:

A versão antes da mudança:

A versão atualizada:

Jabá

Veja esse e outros posts no meu blog pessoal:
racoelho.com.br/blog

Construí um jogo de Jokenpô com WebSockets

Rafael Coelho — Sun, 03 Dec 2023 20:52:05 +0000

Esses dias, postei naquela rede que as pessoas inventam cargos e termos um teste que eu fiz com WebSockets: Um jogo de Jokenpô.

Projeto bobo? Sim, mas se é de pequenas doses de dopamina que os viciados em Tiktok se movem, eu também posso.

A ideia era só brincar com WS mesmo, mas eu cheguei a me empolgar tanto que quando percebi, estava fazendo protótipos para um app mobile que eu tenho CERTEZA que eu nunca iria fazer.

Então, decidi largar de mão e só fiz uma UI simples com html que só tem 3 botões e um quadro para ver o placar e a opção selecionada pelo oponente.

A parte que mais gostei de fazer nele foi o Criador de Partidas:
Quando você se conecta, ele te coloca numa fila aguardando outro jogador para poder montar uma "sala" onde vai começar uma partida de Melhor de Três.

Queria dar uma evoluída nele eventualmente, mas tô sentindo que não vou 😅 (pelo menos, não tão cedo).

Bem, sintam-se livres a dar uma olhada e contribuir, se quiserem:
https://github.com/rafa-coelho/jokenpo

Eu hospedei ele no render também (pode demorar pra startar o pod deles):
https://jokenpo.racoelho.com.br/

Segue uns prints dele:

Forem: Rafael Coelho

RabbitMQ: o que ele faz de verdade (e por que muita gente usa errado)

O problema real que o RabbitMQ resolve

Fluxo típico ruim com HTTP em cadeia

Onde o RabbitMQ entra

Fluxo com RabbitMQ (desacoplado)

Modelo mental do RabbitMQ (o principal)

Visão geral do fluxo

Producer, Exchange, Queue, Consumer

Tipos de Exchange no RabbitMQ

1) Direct Exchange (match exato)

2) Fanout Exchange (broadcast)

3) Topic Exchange (padrões com * e #)

4) Headers Exchange (roteamento por cabeçalho)

ACK: por que a mensagem “volta” (e isso é bom)

ACK vs crash

RabbitMQ vs Kafka (não confunde)

Comparação visual (mental model)

Quando usar RabbitMQ (e quando não usar)

Fechando

Links:

O usuário é teu chefe e você precisa deixar ele feliz!

Experiência de Usuário (UX)

Fator “UAU”

O que são Observers

Exemplo prático

Exemplo de Código

Conclusão

Como funciona a internet (Parte 2) - O Protocolo HTTP

O que é o protocolo HTTP

O Formato HTTP

Métodos HTTP

Códigos de Status

HTTP/2 e HTTP/3

HTTP/2

HTTP/3

O Uso Atual do HTTP

Conclusão

Como funciona a internet (Parte 1): O Modelo TCP/IP: A Fundação da Internet

Protocolos e Pacotes

O TCP

O UDP

Conclusão sobre TCP e a transição para HTTP

GitHub Actions e a Magia dos Triggers: Automatizando Tarefas com C#

A Ideia

As estruturas de código

Convertendo os diferente tipos de Trigger

O Programa

Criando o Setup do CronExpression

Criando o Setup do FileWatcher

O método ExecuteScript

Melhorias

Passando argumentos

Conclusão

Introdução ao desenvolvimento Mobile: Guia para Iniciantes

Plataformas de Desenvolvimento Mobile

iOS

Android

Cross-platform

Linguagens de Programação

Swift

Kotlin

JavaScript

Dart

Ferramentas de Desenvolvimento

Xcode

Android Studio

Visual Studio Code

Flutter

Design de Interface

Material Design

Human Interface Guidelines

Desenvolvimento Front-end

Desenvolvimento Back-end

Integração com APIs

Testes e Qualidade de Software

Testes Unitários

Testes de Integração

Testes de Interface

Publicação e Distribuição

3) Topic Exchange (padrões com `*` e `#`)