Forem: Erick Takeshi

Ruby, Rails, Multi-threading e Puma: Como tudo isso se conecta?

Erick Takeshi — Wed, 12 Feb 2025 00:44:52 +0000

No desenvolvimento de aplicações Rails modernas, entender o funcionamento interno do Ruby, threads e servidores web tornou-se cada vez mais crucial. Seja você está construindo uma API de alto desempenho, processando jobs em background, ou otimizando a performance de uma aplicação existente, o conhecimento profundo desses conceitos pode fazer a diferença entre uma aplicação que escala bem e uma que falha sob carga.

Nos meus últimos 9 anos de carreira, raramente precisei mergulhar tão fundo nesses conceitos. No entanto, em meu trabalho atual, desenvolvemos soluções que demandam um entendimento mais profundo de como o Rails e o Puma funcionam. Este artigo é um compilado desses aprendizados, visando ajudar outros desenvolvedores que precisam otimizar suas aplicações Rails para melhor concorrência e performance.

TL;DR: Este artigo explora como o Ruby gerencia threads, como garantir thread safety em suas aplicações, e como configurar o Puma para máxima performance em diferentes cenários.

Disclaimer: O foco do post é sobre o interpretador MRI do Ruby (CRuby), que é o mais comumente utilizado em ambientes de produção.

Como o Ruby trabalha com threads?

Meu objetivo aqui não é ensinar a sintaxe para criar threads, sincroniza-las ou utilizar mutexes. Em vez disso, quero fornecer uma visão geral sobre como as threads funcionam no Ruby e como tirar o maior proveito delas.

Para entender threads no Ruby, o primeiro conceito essencial é o GVL (Global VM Lock) ou GIL (Global Interpreter Lock).

Global Vm Lock ou Global Interpreter Lock

┌────────────────────────────────────┐
│            Processo Ruby           │
│                                    │
│    ┌──────────┐     ┌──────────┐   │
│    │ Thread 1 │     │ Thread 2 │   │
│    └──────────┘     └──────────┘   │
│           │             │          │
│           └─────┬───────┘          │
│                 ▼                  │
│         ┌──────────────┐           │
│         │     GVL      │           │
│         └──────────────┘           │
│                 │                  │
│         ┌──────────────┐           │
│         │ Interpretador│           │
│         └──────────────┘           │
└────────────────────────────────────┘

O GVL é um mecanismo presente nas versões MRI do Ruby que impede que duas threads rodem código Ruby ao mesmo tempo. Isso significa que não há paralelismo real quando se trata de execução de código Ruby puro. No entanto, o processo Ruby pode executar qualquer outra operação que não envolva código Ruby em paralelo, como operações de I/O.

Qual a vantagem de se utilizar threads?

Como descrito no parágrafo anterior, é possível executar I/O (leituras do disco, requests HTTP, acesso ao banco de dados) em paralelo a código Ruby, então, quando dividimos o programa em várias threads, enquanto uma thread espera o resultado de alguma chamada I/O, outra thread pode ir executando código em paralelo, oferecendo assim a possibilidade de tirarmos maior vantagem de processadores multi-cores.

Quando analisamos a distribuição de recursos em uma aplicação web (Olá Rails), podemos perceber que a maior parte do processamento é gasto com operações I/O, principalmente escrever / ler algo de algum banco de dados, então faz sentido que sua aplicação esteja preparada pra trabalhar em um contexto multi-threaded, e por sorte, neste contexto, o GIL não será um problema e aplicações Ruby podem se tornar muito eficientes!

Thread safety

A origem de todo mal quando se trata de ambientes multi-threaded é o estado compartilhado, ou seja, quando diferentes threads acessam a mesma região de memória simultaneamente. No contexto do Ruby e do sistema operacional, as threads compartilham o mesmo espaço de memória, o que significa que variáveis podem ser acessadas simultaneamente, levando a comportamentos imprevisíveis e difíceis de depurar—o que chamamos de problemas de concorrência.

Ilustrando problemas de concorrência

Embora problemas de concorrência sejam amplamente conhecidos e discutidos, muitas vezes são difíceis de visualizar sem um exemplo concreto.
PROBLEMAS DE CONCORRÊNCIA SÃO INERENTEMENTE DIFÍCEIS!

Imagine que temos a seguinte classe:

class S3Uploader
    def initialize(files)
        @files = files
    end

    def call
        threads = []

        @files.each do |file|
            threads << Thread.new {
                result = send_to_s3(file.name, file.blob)
                upload_results << result
            }
        end

        threads.each(&:join)
    end

    def upload_results
        @results ||= Queue.new
    end

    def send_to_s3(filename, blob)
        # IO
    end
end

A lógica parece correta à primeira vista:

Criamos uma thread para cada operação de I/O, aproveitando melhor o tempo de CPU.
Os resultados do upload são armazenados na fila @results.

Porém, ao executar o código, percebemos que ele não é determinístico! Ou seja, rodando o mesmo código várias vezes, obtemos resultados diferentes. Em um cenário com dois arquivos, às vezes @results contém dois elementos (como esperado), mas em outras execuções contém apenas um.

Pior: esse único resultado pode pertencer a qualquer um dos arquivos!

E de onde vem esse problema?

O problema surge por conta do operador ||= , que em ruby é um check and assign, mas pra entendermos de fato precisamos nos aprofundar aqui.

Estamos acostumados a olhar pra execução de código de maneira procedural, ou seja, cada linha é executada de cima pra baixo, uma por vez, então temos uma certa linearidade na execução do programa. O problema surge quando criamos e utilizamos outras threads, nesse caso, múltiplas linhas do nosso programa podem ser executadas ao mesmo tempo (ou não) e em ordens totalmente aleatórias!
Vamos a um exemplo prático de execução deste programa:

foi chamado o método call da classe
é criado e inicializado o array vazio threads
Iteração sobre a variável de instancia @files
em cada iteração é criada uma thread nova para cada file, dando um append no array threads
1. thread faz o upload para o S3 (chamada http, I/O)
2. da um append na queue @results com o retorno da chamada http
thread principal aguarda a finalização das outras threads instanciadas

Num contexto multi-threaded, os passos 4a e 4b podem ser executados tanto em paralelo (ao mesmo tempo) quanto em ordens totalmente aleatórias, isso é um comportamento inerente de como o sistema operacional distribui os recursos computacionais da sua máquina, caso queira saber mais sobre o assunto procure sobre task / thread scheduler.

Como não temos controle sobre essa distribuição, diversos cenários podem ser problemáticos nesse caso, gerando as famosas race conditions.

Execução passo a passo de uma race condition

Vamos a um exemplo peculiar onde uma race condition acontece e faz com que o valor da variável @results seja computada de maneira errada (OBS: lembrando que o valor esperado seria o @results ter 2 valores de respostas das chamadas ao S3):

thread A é spawnada e começa a chamada http (I/O)
GIL é liberado
thread B é spawnada e começa a chamada http (I/O)
thread B finaliza a chamada http e faz a verificação da variável @results (ao chamar o método upload_results
thread B enxergar a variável como nil e instancia uma nova queue
thread B para de executar por conta do thread scheduler
thread A volta a executar
thread A completa o request
thread A enxergar a variável como nil e instancia uma nova queue (por conta do operador ||=
thread A salva o resultado do request na variável @results
thread B volta a executar e salva na variável results uma nova instância de Queue
thread B salva o resultado do request na variável @results

Percebem o problema que surgiu no passo 11? A thread B, voltou a sua execução em um momento totalmente inoportuno, após fazer a checagem e antes de ter sido feito o assignment, dando chance para que a thread A fizesse o assignment novamente!

Todo o problema surge por conta do operador ||= , ele não é um operador atômico, na prática significa que ele não faz sua tarefa em uma única operação, no caso específico deste operador, é como se ele tivesse a seguinte implementação*:*

def ||=(variable, value)
    if variable.nil?
        variable = value
    else
        variable
    end
end

Percebam que existem duas etapas nessa operação:

checar se a variável está nil
fazer o assignment ou devolver o valor

No contexto de múltiplas threads, essas etapas podem ser interrompidas no meio, resultando em um comportamento imprevisível, portante é recomendado evitá-lo num contexto multi-threaded.

Como garantir que meu código é thread safe?

Diante do problema apresentado, como garantir que nosso código não sofra com race conditions ou inconsistências? Basicamente, temos duas opções:

Evitar estado compartilhado: Essa é a abordagem mais simples, pois elimina completamente os riscos de concorrência. No entanto, em aplicações reais, é praticamente impossível evitar estado compartilhado em 100% dos casos.
Controlar o acesso ao estado compartilhado: Aqui entra o conceito de thread safety, que consiste em permitir acesso concorrente ao estado da aplicação sem comprometer sua integridade.

A opção 1 é a mais simples, porém, qualquer aplicação real que faça algo útil, vai depender de estado, em 99,9% dos casos. A opção 2 é onde o thread safety entra.

Thread safety é a garantia de que um código pode ser executado por múltiplas threads simultaneamente sem corromper dados, introduzir comportamentos imprevisíveis ou gerar condições de corrida. Para isso, existem diversas técnicas, como locks, mutexes, semáforos, filas concorrentes e outras estruturas de sincronização.

Este artigo não pretende cobrir todas essas técnicas, mas aqui estão algumas diretrizes gerais:

Verifique se as bibliotecas que você usa são thread-safe
- no caso de gems, provavelmente no README vai ter algum lugar alegando que a gem é thread safe, caso contrário, busque nas issues do repositório do projeto
Use estruturas de dados thread-safe
- existe uma gem chamada concurrent ruby (que por sinal já vem como dependência default do Rails), ela implementa diversos padrões e estruturas de dados thread safe, é sempre o primeiro lugar que eu olho quando preciso de algo, 99% dos casos já tem algo pronto ali que possa ser utilizado
Evite estado mutável e global sempre que possível
- evite, quando possível, estado mutável e global, estou falando aqui de constantes, métodos e variáveis de classe, variáveis globais e a AST. O lugar de estado global compartilhado, normalmente, é algum banco de dados, como Postgres, Redis, etc.
Cuidado com metaprogramação e multi-threading
- A AST é um caso excepcional, mas como Ruby é uma linguagem extremamente dinâmica (cheia de meta programming), imagine o risco de diferentes threads rodando com versões diferentes do código ao mesmo tempo! Se precisar usar metaprogramação, entenda os impactos na concorrência.

Rails, Puma e Multi-threading

Aqui é a parte que vamos conectar a teoria das seções anteriores com a prática.

O Puma é o servidor default do Rails (faz um tempinho já). O Puma é um servidor multi-threaded. Existe no próprio repositório do Puma um arquivo detalhando sua arquitetura e seu funcionamento, vale muito a leitura para qualquer dev Rails.

O Puma possui basicamente dois modos de trabalho, o cluster e o single. Em termos de multi-threading não faz muita diferença, pois em ambos os modos o Puma irá trabalhar com threads, porém no cluster mode, ele irá fazer um fork e criar outros processos, que servirão requests em paralelo também.

Como o Puma gerencia requests?

Agora chegamos na parte principal, como o Puma trabalha com threads.

De forma simplificada:

Existe um thread pool (conjunto de threads previamente alocadas).
Cada request entra em uma fila (todo set).
À medida que threads ficam disponíveis, elas processam os requests na ordem de chegada.

O mais importante aqui é entender que cada request roda em uma thread separada. Isso significa que enquanto um request está bloqueado esperando uma operação de I/O (como uma consulta no banco), outras threads continuam processando outros requests.

O que isso significa para o Rails?

O Rails foi projetado para ser thread-safe. Todo o código dos controllers é instanciado e escopado por request, o que garante que o próprio Rails não introduz condições de corrida.

No entanto, essa segurança pode ser comprometida quando adicionamos nossas próprias abstrações dentro do controller. Para evitar problemas:

Sempre prefira instanciar objetos dentro do escopo do request, em vez de depender de métodos de classe ou variáveis globais.
Se precisar compartilhar estado entre requests, use um armazenamento externo como Redis ou um banco de dados relacional.

Se fugir dessas práticas for necessário, tenha certeza de que está garantindo sincronização adequada para evitar concorrência insegura.

O poder da concorrência e paralelismo

Agora que entendemos como o Ruby, Rails e o Puma funcionam, podemos enxergar melhor os benefícios do modelo concorrente.

Na maioria das aplicações web, o maior gargalo é I/O—seja acessando um banco de dados, chamando APIs externas ou lendo arquivos. Como o Puma é multi-threaded, ele permite que outras threads processem novos requests enquanto uma thread aguarda uma operação de I/O ser concluída.

Esse modelo é altamente eficiente, pois maximiza a utilização dos recursos computacionais, evitando que a aplicação fique ociosa.

O ponto de virada: otimizando o número de threads

Nem tudo são flores. Aumentar indiscriminadamente o número de threads não melhora indefinidamente o desempenho.

Cada aplicação tem um ponto ótimo de configuração, e aumentar demais o número de threads pode, na verdade, reduzir o throughput e aumentar a latência. Isso acontece porque:

Mais threads significa mais concorrência por CPU, memória e acesso a recursos.
Em cenários extremos, pode ocorrer starvation, onde algumas threads ficam bloqueadas por longos períodos esperando sua vez.

A configuração RAILS_MAX_THREADS no Puma define quantas threads podem ser usadas por processo. Para encontrar o melhor valor:

Teste diferentes configurações e use benchmarking para medir o impacto.
Lembre-se: o número ótimo depende da carga da sua aplicação e dos recursos do servidor, então simule em ambiente mais próximo possível a produção.

Existem diversos artigos detalhando sobre benchmarking de diferentes combinações de números de processos e threads no Puma, porém, lembre-se que isso é específico de cada aplicação, teste e descubra o número ótimo para o seu caso!

Concluindo

O Rails é thread-safe por padrão, mas seu código precisa seguir boas práticas para manter essa segurança.
O Puma permite concorrência eficiente, maximizando o uso dos recursos disponíveis.
Evitar estado compartilhado na memória da aplicação entre requests elimina grande parte dos riscos de concorrência.
Ajustar corretamente o número de threads é essencial para garantir um bom desempenho sem sobrecarregar o servidor.

Entender esses conceitos não apenas evita bugs difíceis de depurar, mas também permite extrair o máximo de desempenho da aplicação, garantindo escalabilidade e eficiência.

Promoção no trabalho começa aqui: Como a dopamina pode impulsionar seu sucesso

Erick Takeshi — Thu, 21 Nov 2024 21:22:30 +0000

Imagine que seu cérebro é como um carro esportivo potente, mas que está rodando com combustível de baixa qualidade (aquela gasolina comum safada).

Você tenta acelerar rumo aos seus objetivos — como estudar para aprender uma nova linguagem de programação ou se preparar para uma promoção ou uma transição para uma empresa dos sonhos —, mas o motor simplesmente não responde.

Esse “combustível” é a dopamina, o neurotransmissor que impulsiona nossa motivação e desejo por recompensas. O problema é que, quando nossos receptores estão saturados pelas recompensas fáceis do dia a dia — como redes sociais, vídeos curtos ou horas intermináveis jogando —, nossa capacidade de buscar metas mais significativas acaba comprometida.

Neste texto, quero te explicar como a dopamina funciona no cérebro e, mais importante, como você pode dar início ao processo de retomar o controle e alcançar seus objetivos. A ideia é transformar sua dopamina na gasolina podium que seu “motor” precisa para liberar todo o potencial e te levar mais longe.

O que é dopamina?

A dopamina é um neurotransmissor — ou seja, uma substância química responsável por transmitir sinais entre os neurônios no cérebro. Ela desempenha um papel crucial no sistema de recompensa, sendo liberada sempre que notamos que precisaremos realizar um esforço para garantir algo que o cérebro interpreta como positivo ou prazeroso. Em outras palavras, a dopamina é como o "empurrão" químico que nos faz agir em direção aos nossos objetivos, grandes ou pequenos. Sem ela, ficamos paralisados, incapazes de iniciar o esforço necessário.

Um estudo realizado com macacos ajudou a revelar o papel fundamental da dopamina no esforço em busca de objetivos. Os macacos eram colocados em uma sala com três elementos: uma luz, um botão e uma mamadeira com suco. Eles foram ensinados que, ao verem a luz acender, precisariam apertar o botão 10 vezes para ter acesso ao suco.

O que os pesquisadores descobriram foi fascinante: o pico de dopamina no cérebro do macaco ocorria não quando ele recebia o suco, mas sim quando a luz acendia. Ou seja, a dopamina era liberada no momento em que o macaco reconhecia o estímulo (a luz) que iniciava o esforço. Isso mostrou que a dopamina é essencial para nos mover em direção aos nossos objetivos. Ela não recompensa o fim do caminho, mas, sobretudo, nos dá energia para começar.

A importância de conhecermos nossas luzes, botões e sucos

No estudo, o macaco só apertava o botão quando via a luz acender. Ele não apertava o botão de forma aleatória ou sem motivo. A luz, nesse contexto, era o estímulo que o motivava a agir.

Agora pense na sua vida: qual é a sua “luz”? O que te motiva a iniciar o esforço necessário para alcançar seus objetivos? A motivação pode vir de diferentes fontes: um amigo que está estudando junto com você, um colega que conquistou algo que você também almeja, ou até mesmo a visualização clara dos benefícios que determinada meta pode trazer à sua vida. Identificar suas “luzes” é fundamental porque, apesar do que muitos dizem, não é só disciplina que nos faz avançar — a motivação desempenha um papel essencial.

Depois de identificar suas luzes, é hora de conhecer o “botão”. Assim como o macaco sabia que apertar o botão 10 vezes garantiria o suco, você precisa entender claramente qual esforço é necessário para atingir seu objetivo. Esforço sem recompensa é frustrante, e a falta de resultados pode desmotivar, reduzindo ainda mais os níveis de dopamina.

E, finalmente, precisamos entender nosso “suco”. Qual é o objetivo que você quer alcançar? Quais benefícios ele trará para sua vida?

Ter clareza sobre o que você realmente deseja é crucial, mas aqui vai uma dica importante: alinhe suas expectativas com a realidade. Não idealize um “suco de várias frutas polivitamínico com multiminerais” se, no final, o suco é apenas de laranja. Conheça seus objetivos e saiba exatamente o que esperar deles, isso evita frustrações e ajuda você a manter o foco no que realmente importa.

Conclusão

Entender como a dopamina funciona e sua relação com esforço, motivação e recompensa é o primeiro passo para assumir o controle do processo de alcançar seus objetivos. Assim como no experimento do macaco, é fundamental identificar suas luzes (os estímulos que te motivam), seus botões (os esforços necessários) e seus sucos (os objetivos que você quer alcançar).

Lembre-se: a jornada é tão importante quanto o destino. Ao reequilibrar seus hábitos e aprender a usar a dopamina a seu favor, você estará transformando seu cérebro em um carro esportivo realmente preparado para alcançar qualquer objetivo — com gasolina podium no tanque e o motor a todo vapor.

Por fim, é importante destacar que as informações deste texto foram inspiradas nas aulas do Eslen Delanogare, especialista em neurociência. Caso você queira se aprofundar no tema, recomendo fortemente acompanhar o conteúdo dele para explorar ainda mais esse universo fascinante.

Então, qual é o seu suco?

Back of the envelope estimations, começando a entrevista de system design

Erick Takeshi — Wed, 21 Aug 2024 21:35:34 +0000

Uma etapa muito comum em processos seletivos para engenheiros de software, especialmente nessa era pós pandemia, é a entrevista de system design. Se você é um profissional de nível sênior ou superior, é quase certo que enfrentará um desafio desse tipo, e dada a sua importância, gostaria de compartilhar algumas dicas sobre um dos primeiros passos cruciais, para essas entrevistas: back of the envelope estimations!

OBS: Caso não faça ideia do que seja system design, deixo aqui indicação de dois sites muito legais para estudar mais / entender sobre o assunto:

O que é back of the envelope estimations?

Segundo Jeff Dean, Google Senior Fellow, em tradução livre: "back-of-the-envelope estimations são estimativas que você cria usando uma combinação de hipóteses suas e números de performance comuns para ter uma boa noção de quais designs atenderão aos seus requisitos”.

Basicamente, antes de iniciarmos a construção / arquitetura do sistema, é ideal estimarmos alguns requisitos de capacidade e performance. Isso nos permite tomar decisões mais acertadas e adequadas para o cenário em questão. A essas estimativas damos o nome informal de "back of the envelope estimations".

Potência de 2

No mundo da computação trabalhamos com bits, isso é o básico. Quando estamos estimando algo como armazenamento de dados, precisamos trabalhar com potência de 2, pois estamos lidando com sequências de bits (normalmente sequências de bytes, que são 8 bits). Ter uma tabela de potências de 2 na ponta da língua pode ajudar muito:

Potência	Valor aproximado	Nome completo	Abreviação
10	1 mil	1 Kilobyte	1 KB
20	1 milhão	1 Megabyte	1 MB
30	1 bilhão	1 Gigabyte	1 GB
40	1 trilhão	1 Terabyte	1 TB
50	1 quadrilhão	1 Petabyte	1 PB

Além dessa tabela, é útil ter em mente os tamanhos dos tipos de dados elementares para estimar requisitos de armazenamento:

Tipo de dado	Tamanho (byte)
int	4
float	8
boolean	1
UTF-8 character	1
UNIX timestamp	4

Números de latência que todo programador deveria saber

No mundo da computação, latência geralmente se refere ao tempo que uma determinada ação leva para ser executada, ou seja, num contexto de rede, latência pode se referir ao tempo que um pacote demora pra ir de um nó A até o nó B, no contexto de armazenamento, latência pode ser referir ao tempo que o disco demora para gravar uma informação X ou ler a mesma informação. No contexto de banco de dados, latência pode ser referir ao tempo que uma query demora pra ser executada e retornar seu resultado, e por ai vai.

Dentro deste contexto de latência, o Dr. Jeff Dean lista alguns números importantes pra termos na cabeça:

Nome da operação	Latência
L1 cache reference	0.5 ns
Branch mispredict	5 ns
L2 cache reference	7 ns
Mutex lock/unlock	100 ns
Main memory reference	100 ns
Compress 1K bytes with Zippy	10,000 ns = 10 µs
Send 2K bytes over 1 Gbps network	20,000 ns = 20 µs
Read 1 MB sequentially from memory	250,000 ns = 250 µs
Round trip within the same datacenter	500,000 ns = 500 µs
Disk seek	10,000,000 ns = 10 ms
Read 1 MB sequentially from the network	10,000,000 ns = 10 ms
Read 1 MB sequentially from disk	30,000,000 ns = 30 ms
Send packet CA (California) ->Netherlands->CA	150,000,000 ns = 150 ms

Um primeiro disclaimer sobre esta tabela é que os números definitivamente estão obsoletos, uma vez que os computadores evoluem e se tornam mais rápidos e poderosos constantemente, porém, não temos nenhum ônus em utilizarmos esta tabela para back of the envelope estimations, pois estamos trabalhando com estimativas, bem rudimentares e aproximadas, que serão utilizadas em entrevistas de system design.

A ideia é termos noção de ordem de grandeza e não de números exatos.

Interpretações dos números

A partir desses dados, podemos tirar algumas conclusões valiosas para nossos designs:

Há uma diferença de magnitude significativa entre diferentes operações (exemplo ler um dado da rede / disco vs ler um dado da memória)
Datacenters costumam estar localizados muito longe um dos outros, tornando custoso o tráfego de dados entre eles.
Utilizando um algoritmo simples de compressão conseguimos economizar muito em largura de banda no tráfego de rede
Escritas são 40x mais lentas do que leituras
Dados globais compartilhados são caros, isto é uma limitação fundamental de sistemas distribuídos, a contenção de locks em objetos que são muito escritos acaba matando a performance do sistema, uma vez que precisamos executar transações seriais (uma de cada vez)
Desenhe sua arquitetura para escalar escritas, pois são as operações mais custosas
Otimize seu sistema para minimizar locks de escrita, garantindo que dados possam ser escritos simultaneamente sem um lock
Otimize seu sistema para paralelismo, ou seja, garanta que escritas possam ser executadas de maneira paralela sempre que possível

Números de disponibilidade

Disponibilidade é a medida que indica o tempo em que um sistema está online e responsivo dentro de um determinado período. Normalmente, disponibilidade é expressa em porcentagem, onde 100% significa que o sistema esteve disponível todo o tempo analisado. A maioria dos sistemas considera aceitável uma disponibilidade entre 99% e 100%.

Um termo frequentemente usado no contexto de disponibilidade é SLA (Service Level Agreement), que é um valor acordado em contrato sobre a disponibilidade de um serviço. SLAs são frequentemente expressos em "números de 9", que indicam a quantidade de 9s após a vírgula (decimais).

A tabela a seguir expressa os valores aproximados de SLA para diferentes períodos de tempo:

Disponibilidade %	Downtime por dia	Downtime por semana	Downtime por mês	Downtime por ano
99%	14.40 minutos	1.68 horas	7.31 horas	3.65 dias
99.99%	8.64 segundos	1.01 minutos	4.38 minutos	52.60 minutos
99.999%	864.00 milissegundos	6.05 segundos	26.30 segundos	5.26 minutos
99.9999%	86.40 milissegundos	604.80 milissegundos	2.63 segundos	31.56 segundos

Exemplo prático de análise

Imagine que você precisa gerar uma página de resultados de uma busca com 30 thumbnails (imagens), como seria a análise de performance deste requisito?

Proposta 1 - Design Serial

Nesta proposta iremos ler as imagens do disco sequencialmente (uma após a outra).

A conta de performance seria:

30 X ( 10 ms / leitura de disco + ( 0,256 MB * 30 ms / MB ) ) = 530 ms

Explicando a conta:

Como são 30 thumbnails, multiplicamos por 30 a quantidade de tempo de leitura de cada thumbnail.

Cada thumbnail gasta o tempo da leitura em disco mais o tempo necessário para transferir esses dados do disco pra memória, ambos os valores estão nas tabelas acima, mas pra referência seriam 10 ms / leitura de disco e 30 ms / MB transferido.

Além dos números da tabela, estimamos que cada thumbnail tenha 256 KB de tamanho (ou 0.256 MB).

Resolvendo a equação, chegamos ao número de 530 ms como estimativa para gerar a página, levando em conta apenas a leitura dos thumbnails.

Proposta 2 - Design Paralelo

Nesta proposta, as leituras em disco seriam feitas em paralelo, usando, por exemplo, diferentes threads para ler simultaneamente do disco.

A conta ficaria:

10 ms / leitura de disco + 0,256 MB * 30 ms / MB = 18 ms

Explicando a conta:

Aqui, a conta é similar à do design sequencial, mas não multiplicamos o resultado por 30, já que as leituras são feitas em paralelo.

Para tornar o cenário mais realista, podemos adicionar alguns milissegundos para sincronização de threads e variação nas leituras de disco, onde teríamos algo entre 30 e 60 ms, ainda assim muito mais rápido que o design serial, mostrando o poder do paralelismo!

Analisando as propostas

Qual cenário é melhor?

A resposta pra essa pergunta vai depender de cada caso e de seus requisitos, entretanto, tendo as estimativas de cada design, podemos compara-los de maneira mais assertiva e optar por aquele que entrega melhor performance e garante que os requisitos estejam sendo satisfeitos.

O importante é que agora você tem uma base sólida para comparação, permitindo responder de forma mais precisa a perguntas que possam surgir durante uma reunião de whiteboarding ou uma entrevista de system design, usando números concretos para embasar suas decisões.

Concluindo

Back-of-the-envelope estimations é uma técnica que ajuda a termos uma visão mais holística e baseada em números de diferentes designs e soluções, sendo uma ferramenta importante pra quando estamos tentando desenhar algum sistema.

Tenha em mãos números básicos de performance e armazenamento de partes relevantes utilizadas em seus sistemas, saber de antemão estes números, antes das reuniões de whiteboarding / entrevistas de system design, ajuda a fazer estimativas mais precisas, uma vez que é impossível estimar corretamente sem uma base de informações.

Além disso, monitorar e medir periodicamente seus sistemas garante que essas estimativas se tornem cada vez mais precisas, pois você estará utilizando dados reais e específicos dos componentes do seu sistema. Isso não só melhora a qualidade das estimativas, mas também fortalece a sua capacidade de tomar decisões informadas e eficazes.

heap & stack, Reduzindo o fardo do garbage collector em Go

Erick Takeshi — Wed, 24 Jul 2024 20:47:26 +0000

No nosso dia a dia de programação, raramente precisamos nos preocupar com a performance ou a alocação de memória, afinal de contas as ferramentas do Go como runtime, garbage collector, compilador, são bem eficientes em seu trabalho, nos blindando da carga cognitiva nestas áreas. Porém. nas vezes em que performance é uma preocupação e temos que descer um nível abaixo no código, saber como essas ferramentas funcionam por debaixo dos panos e saber como você pode otimizar seu código é essencial.

No post de hoje quero discutir um pouco sobre alocação de memória e o garbage collector, além de deixar umas dicas de como diminuir o trabalho do garbage collector.

heap e stack

Para as pessoas com um background mais de Ciência / Engenharia da Computação, esses termos devem despertar alguma memória (seja ela dolorosa ou não hehe) das aulas de sistemas operacionais, arquitetura de computadores, etc. Para nivelar o entendimento, vou introduzir brevemente alguns conceitos que julgo serem importantes para continuarmos com a discussão do garbage collector.

heap e stack são duas áreas distintas de um memory layout de algum processo do sistema operacional, ou seja, dando um resumo bem por cima e bem impreciso (como diria os disclaimers do mestre Akita rsrs), são duas “áreas” diferentes da memória do seu computador, onde cada uma tem uma função específica e armazena um tipo diferente de dado.

Assim como processos do SO possuem memory layout e áreas da memória reservada somente para eles, as threads desses processos também o tem, e, no caso do Go, como não lidamos diretamente com threads do SO, as goroutines também possuem seu próprio memory layout, com stack, heap, etc, gerenciadas pelo próprio runtime do Go (essa é uma grande vantagem das goroutines quando comparadas com threads comuns do SO, mas isso é tema para outro post).

Como funcionam a stack e a heap?

stack

A stack (velha conhecida dos amantes de leetcode) é basicamente um bloco consecutivo de memória. Cada chamada de função dentro de uma thread em execução compartilha a mesma stack (AHA moment, dai o termo stack overflow, quando tentamos usar mais memória do que a alocada para aquela stack especifica), logo, alocar memória na stack é rápido e simples.

Uma “variável” (mais precisamente um endereço especifico de memória) guarda o stack pointer. O stack pointer serve para rastrearmos o endereço de memória da última alocação do stack.

A cada chamada de função estamos adicionando um stack frame na stack, que nada mais é que uma área delimitada na stack somente para aquela função, nessa carregamos as variáveis da função e seus argumentos, variáveis criadas dentro da função são guardadas na stack também. Assim que a função retorna, recalculamos o stack pointer e é desalocado a memória que aquela função estava ocupando, seguindo assim consecutivamente para todas as chamadas de funções.

heap

O heap é uma área da memória que é dedicada a alocação de dados dinâmicos e é administrada pelo garbage collector. Outro ponto importante do heap é que ele é um espaço compartilhado entre threads / goroutines. Em termos de implementação, o heap é muito mais complexo, além de estar focado em dados de mais longo prazo, ou seja, enquanto tivermos um ponteiro apontado pra aquele dado ele vai continuar existindo no heap. É aqui que devemos ajudar o garbage collector também, seja não mandando muitos dados para ca, seja otimizando o que é mandado, quando necessário.

Para um detalhamento mais baixo nível, tanto de heap quanto outras áreas de memória administradas pelo runtime do Go, indico este post.

Beneficiando-se da stack e heap para performance

Em termos de performance, queremos usar a stack o máximo possível, por ser mais eficiente e não onerar o garbage collector, quando utilizarmos o heap, queremos também utilizar de maneira mínima e inteligente, como por exemplo, utilizando buffers.

Para alocar algo na stack, o compilador do Go precisa saber o tamanho exato do dado em tempo de compilação, quando olhamos para os tipos de valores em Go (primitivos, arrays e structs) todos eles tem uma coisa em comum: Sabemos exatamente quanto de memória é necessário para armazena-los (este é um dos motivos do porque o tamanho de um array em Go é considerado parte do seu tipo). Devemos abusar desses tipos para melhorar a performance. Um adendo é que ponteiros também são alocados na stack, porém os dados para os quais eles apontam podem estar na heap, então não se enquadram nesse grupo anterior.

Já no caso do heap, ele é administrado pelo garbage collector. Quando um dado não tem mais um ponteiro apontando para ele, se torna “garbage” e pode ser desalocado na próxima varredura do garbage collector.

Porque é ruim utilizarmos o heap quando o assunto é performance?

Primeiramente, o garbage collector precisa de um tempo precioso de CPU para ser executado, então paramos a execução do nosso programa temporariamente para que o garbage collector possa rodar. Este processo do garbage collector não é trivial, diversos algoritmos foram desenvolvidos ao longo do tempo, alguns focados em maior throughput (achar o maior número de garbage possível, desalocando o máximo de memória), outros em menor latência (acabar o processo de garbage collection o mais rápido possível, ao custo de ser menos eficiente em cada varredura). No caso específico do Go, seu garbage collector favorece mais latência baixa, então cada sweep (varredura) tende a rodar bem rápido, porém, se seu programa gera muito garbage, obviamente o garbage collector vai levar alguns sweeps para conseguir desalocar toda a memória ocupada por garbage, sendo assim bem menos eficiente. Para quem se interessar em saber mais desse processo do garbage collector, deixo aqui esse post do blog do Go contando a historia do desenvolvimento do mesmo.

O segundo problema tem mais a ver com detalhes de implementação do hardware, a RAM (random access memory) foi arquitetada para suportar acessos randômicos de áreas de memória, porém, a maneira mais rápida de acessar seus dados ainda é o sequencial. Um slice de inteiros possui todos os seus dados sequencias (um do lado do outro), tornando rápido a sua leitura, já um slice de ponteiros tem seus dados todos espalhados por toda a RAM, o que torna seu acesso bem mais devagar.

E como reduzimos o fardo do garbage collector?

Com base nos conceitos apresentados anteriormente, podemos deduzir que devemos usar ponteiros com cuidado, uma vez que seus dados são armazenados no heap e ficarão espalhados na RAM de maneira randômica, então use ponteiros só quando for extremamente necessário, quando o foco for performance.

Além do uso consciente de ponteiros, devemos focar ao máximo utilizar a stack, abuse de dados primitivos (números, booleanos, strings e runes), alocando assim o mínimo possível no heap, quanto menos garbage for pro heap mais eficiente os sweeps do garbage collector serão, diminuindo assim o seu fardo.

BONUS TIP: Ferramentas para identificar o uso do heap

A primeira ferramenta é o próprio build do compilador do Go. Ao passarmos as gcflags -m e -l conseguimos fazer a escape analysis do nosso código. Quando rodamos o build com essas flags teremos um output do compilador dando dicas de quando ele moveu algo pro heap, como no exemplo abaixo:

./main.go:10:2: **moved to heap: res**

Uma outra ferramenta que ajuda muito é o benchmark. Quando um programa está bem otimizado (não utilizando nada do heap), teremos o seguinte output:

$ go test -bench . -benchmem
BenchmarkStackIt-8  680439016  1.52 ns/op  0 B/op  0 allocs/op

A coluna interessante é a de 0 allocs/op que indica que nenhuma alocação no heap foi executada. Se parar pra ler os benchmarks das libs famosas em Go vai começar a perceber que diversas delas possuem esse stat de 0 allocs (o que é bem impressionante 🤯🤯🤯).

Conclusão

Entender a diferença entre heap e stack, assim como a maneira que o Go gerencia a memória, é crucial para otimizar a performance de suas aplicações. Utilizar a stack sempre que possível e ser cuidadoso com o uso de ponteiros pode reduzir significativamente a carga do garbage collector, resultando em programas mais eficientes e rápidos. Ferramentas como escape analysis e benchmarks ajudam a identificar e solucionar problemas de alocação de memória. Com essas práticas, você pode aproveitar ao máximo o desempenho que o Go tem a oferecer, criando aplicações robustas e eficientes. Lembre-se, pequenas otimizações no gerenciamento de memória podem fazer uma grande diferença na performance geral do seu sistema.

OAuth em aplicações SPA / Mobile (PKCE extension)

Erick Takeshi — Mon, 08 Jul 2024 03:25:46 +0000

Em diversas implementações OAuth / OpenID Connect nos deparamos com o uso de clientes confidenciais (clientes registrados que possuem um par client_id e client_secret), porém, em aplicações client-side, como SPAs e apps mobile, é impossível garantir a confidencialidade do client_secret. Portanto, torna-se necessário um meio seguro para obter o access token através de algum fluxo do OAuth.

Para resolver esse problema de clientes públicos, entra em ação a RFC 7636 Proof Key for Code Exchange by OAuth Public Clients, que adiciona uma extensão ao fluxo do authorization code, tornando a comunicação mais segura. É dessa RFC que quero aprofundar um pouco neste post.

Qual problema o PKCE tenta mitigar?

Primeiramente, lê-se piquici (pixy), a sigla PKCE, haha.

O PKCE mitiga um conhecido ataque do tipo man in the midle , aplicado principalmente em aplicações mobile, segue um diagrama abaixo demostrando esse tipo de ataque.

Explicando brevemente:

A aplicação cliente inicia o fluxo authorization code utilizando um browser
Browser faz o request para o endpoint /authorize do authorization server
Browser recebe de volta a resposta do servidor com o authorization code (code)
Um app malicioso instalado no dispositivo cliente intercepta essa resposta que seria encaminhada do browser para a aplicação cliente (normalmente utilizando um custom URI scheme)
O app malicioso, em posse do authorization code , completa o fluxo trocando o code pelo access token e tendo acesso aos recursos protegidos autorizados pelo usuário.

Desta forma, um app malicioso que tenha infectado o dispositivo do cliente pode obter acesso a um access token interceptando code da resposta do request para o endpoint /authorize.

Um ponto importante a se destacar é que devido a natureza dos clientes públicos de não conseguirem guardar de maneira segura suas credenciais, o fluxo do authorization code permite que estes obtenham o access token somente através da posse do code e do cliente_id da aplicação cliente. Este tipo de ataque se tornaria bem menos eficaz caso fosse possível autenticar a aplicação cliente através de seu client_secret.

OBS sobre custom URI schemes

Para quem não é da área mobile ou front-end, custom URI schemes é uma forma de criar um protocolo custom para sua aplicação, assim como http:// ou https://, algo como myapp://.

Assim, quando um usuário clicar ou for redirecionado para uma URL que utilize este protocolo, sua aplicação será inicializada com os parâmetros associados a URL.

Para saber mais sobre indico este ótimo e breve artigo, Launching Applications from the Web: The Power of Custom URL Schemes.

Como o PKCE mitiga este tipo de ataque?

O PKCE mitiga este tipo de ataque introduzindo alguns parâmetros adicional nos requests envolvidos no fluxo do authorization code.

No diagrama abaixo ilustramos essa nova dinâmica:

Explicando o novo fluxo:

Aplicação cliente cria um code_verifier, uma string aleatória de alta entropia criptográfica
Aplicação cliente deriva o code_challenge do code_verifier aplicando algum algoritmo como SHA256, sendo este algoritmo denomiado code_challenge_method
Aplicação cliente encaminha o code_challenge e o code_challenge_method , junto dos demais parâmetros, no request para o /authorize
O authorization server guarda o code_challenge e o code_challenge_method, associando-os ao authorization code emitido na resposta do /authorize
No request para o /token a aplicação cliente envia junto do code o code_verifier gerado no passo 1, além dos demais parâmetros necessários
Authorization server vai aplicar as transformações no code_verifier baseado no code_challenge e code_challenge_method associados com o authorization code recebido
Caso a verificação seja bem sucedida, o authorization server retorna o access code para a aplicação cliente

Então, com a introdução destes novos parâmetros, mesmo que algum app malicioso seja capaz de interceptar o authorization code, este não será capaz de trocar o code por um access token no endpoint /token por não saber o code_verifier e o code_challenge_method utilizado na comunicação com o authorization server.

Considerações de segurança

A extensão do PKCE parte do princípio que o code verifier pode ser mantido em segredo do atacante (app malicioso) e que é praticamente impossível de ser adivinhado ou derivado pelo atacante.

Para que o code verifier atinja o requisito satisfatório de aleatoriedade criptográfica, sugere-se utilizar pelo menos 256 bits de entropia.

Pessoalmente, sugiro que utilize bibliotecas open-source confiáveis para gerar o code_challege e verifier, uma vez que são padrões conhecidos. Recorrer a experiência e poder do open-source é sempre bem vindo.

Concluindo

O PKCE resolve o problema de clientes públicos, como SPAs e Mobile apps, em obter de maneira segura o access token, usufruindo assim dos benefícios do OAuth sem precisar comprometer sua segurança, então lembre-se sempre de utilizar essa extensão ao implementar clientes OAuth públicos.

Para saber mais sobre OAuth e OpenID Connect, deixo aqui a minha coletânea de posts sobre o tema.

Implementando seu próprio link tree

Erick Takeshi — Sun, 09 Jun 2024 01:06:30 +0000

Os tempos mudaram. Antigamente, bastava ter um perfil atualizado no LinkedIn para receber várias propostas de emprego como desenvolvedor de software. Nosso mercado mudou da água pro vinho pós colapso da pandemia. As empresas estão muito mais exigentes com relação aos seus candidatos e a concorrência está cada vez mais intensa.

Não quero assustar ninguém, mas sim ressaltar a importância da presença online, não só como “marketing” pessoal, mas também como portfólio mesmo. Ter algo para mostrar, como um blog, um site próprio, repositórios profissionais, é quase que requerimento, não um diferencial.

Com isso em mente, decidi criar uma página pessoal no formato link tree para aprender um pouco sobre serviços de CDN, deploy contínuo (CI/CD) e também permissionamento cross plataforma (OAuth, OIDC), e é sobre esse projetinho que quero conversar um pouco.

Arquitetura e stack

O projeto em si é simples, pois o foco era aprender mais sobre certas tecnologias, mas mesmo assim vale destacar um pouco cada caixinha do diagrama acima.

Componentes

Hospedagem de arquivos estáticos no AWS S3
Repositório público no Github (https://github.com/erick-tmr/link-in-bio-self-profile)
Github Actions como pipeline de deploy
Cloudflare para CDN / Proxy Reverso
Autenticação via OIDC com tokens short lived para uso no AWS CLI
Gravatar como CMS

Sobre o código

Utilizei como base este template, que é open source e já possui uma integração interessante de CMS (Gravatar). Do template, acabei não mudando muitas coisas, a mudança mais notável foi na utilização de modules e import maps, uma funcionalidade nativa de navegadores modernos, que acabou englobando uma fatia dos bundlers como Webpack, praticamente tornando dispensável sua utilização em projetos mais simples, como este.

Quem der uma olhada no repositório deste projeto vai ver que utilizei uma lib externa para fazer o MD5 de uma string, tudo com import maps, direto do CDN da NPM.

Pra quem ainda não experimentou, diria que é uma inovação bem legal e que vale a pena dar uma olhada, link para as docs da MDN.

CI / CD e automação de deploy

Para o CI / CD, optei pelo Github Actions, por ser gratuito para projetos open source e ser bem prático.

O pipeline é simples, utilizando uma action da própria AWS para fazer a autenticação, é gerado um token de curta duração para assumir uma Role do IAM já pré configurada com as permissões necessárias para poder fazer o sync com um bucket do S3.

Trabalho no time de segurança da empresa onde estou atualmente, lidando diariamente com mTLS, OAuth, OpenID Connect, etc. Acabei testando essa solução mais por questões de benchmark, mas foi um aprendizado bem interessante, particularmente acho bem legal poder trabalhar num business context que, de certa forma, é agnóstico da empresa que você está no momento.

Hospedagem S3

Como o site é simples e consiste somente de alguns arquivos estáticos, optei pelo S3 para armazenar e distribuir os arquivos. Para quem não conhece, o S3 possui uma funcionalidade nativa para transformar determinado bucket em um site estático, expondo assim uma URL pública para que as pessoas tenham acesso ao bucket, tendo também um free tier bem legal.

Um adendo aqui foi a parte de permissionamento, sofri um pouco para conseguir configurar as policies necessárias para que o bucket se tornasse publico de fato, devido a querer restringir o acesso ao S3 somente a Cloudflare, que foi o serviço de CDN escolhido, mas depois de bater a cabeça um pouco acabou dando certo.

CDN / Proxy Reverso

Aqui eu utilizei a Cloudflare mais por conta de querer experimentar algumas features que eu iria utilizar no meu trampo mesmo, mas talvez se não tivesse esse requisito, eu teria utilizado o próprio CloudFront da AWS.

Poderia simplesmente não utilizar nenhum CDN e apontar meu DNS diretamente para a URL pública do meu bucket, porém, existe uma restrição do S3 em que não é possível utilizar TLS / HTTPS, sendo assim, pra ter uma proteção mais legal, o uso de algum CDN na frente se torna indispensável.

A Cloudflare proporciona não só o serviço de CDN como proteção a ataques DDoS, certificados SSL, cache inteligente e mais, tudo no plano gratuito, o que é algo bem legal. A feature que eu gostaria de testar mesmo, o mTLS, acabou não rolando, o avoado que vôs fala não verificou antes que esta feature está presente somente em planos enterprise.

Concluindo

Sobre o projeto, é isso! No futuro, pretendo escrever um post mais detalhado, com cara de tutorial, ensinando passo a passo cada etapa desse processo. Se você ficou interessado e quer ver essa parte dois, deixe um comentário ou mande um sinal de fumaça haha.

Instruction Set Architecture, a linguagem das máquinas

Erick Takeshi — Wed, 29 May 2024 22:09:36 +0000

Para se comunicar com um computador precisamos falar a sua língua, ao vocabulário desta “linguagem” é conhecido como Instruction Set. Para **os programadores de plantão, podemos dizer que a ISA de um hardware é a interface deste para com o software, ou, simplificando, sua API.

Já abordei um pouco sobre como computadores funcionam e como ocorre a comunicação entre a nossa linguagem de programação e o hardware em um post anterior, mas vou recapitular brevemente.

Como ifs, fors e vars viram binários que o computador entende?

Como dito anteriormente, o computador entende somente instructions, ou seja, precisamos utilizar a ISA para operar um computador. As instructions são constituídas por sequencias de números binários que possuem significado para o computador.

Utilizar números binários direto para se comunicar com o computador é uma tarefa complexa e tediosa, ou seja, um prato cheio para que um programador torne esta tarefa mais simples, então, foi criado um programa que ajuda a programar, os chamados assemblers, que traduziam linguagem escrita e entendida por seres humanos em linguagem de máquina (instructions).

Apesar do assembly já ser uma simplificação absurda em comparação com as instructions cruas, ainda era muito semelhante a forma de pensar e agir da máquina e não do ser humano, sendo assim foram criadas as linguagens de programação de mais alto nível, como C, C++, Java e afins.

As primeiras linguagens funcionavam como uma abstração acima da camada do assembly, onde você tinha um programa que transformava os comandos da linguagem em comandos assembly , esse programa é chamado de compilador.

O compilador torna acessível a comunicação com o computador, fazendo com que consigamos modelar de maneira mais próxima ao nosso pensamento o que gostaríamos que a máquina executasse.

// o seguinte programa em C só é possível de ser interpretado por conta dos compiladores

swap(size_t v[], size_t k) {
    size_t temp;
    temp = v[k];
    v[k] = v[k+1];
    v[k+1] = temp;
}

// traduzido para assembly pelo compilador
swap:
    slli x6, x11, 3
    add  x6, x10, x6
    lw   x5, 0(x6)
    lw   x7, 4(x6)
    sw   x7, 0(x6)
    sw   x5, 4(x6)
    jalr x0, 0(x1)

// traduzido para binários
00000000001101011001001100010011
00000000011001010000001100110011
00000000000000110011001010000011
00000000100000110011001110000011
00000000011100110011000000100011
00000000010100110011010000100011
00000000000000001000000001100111

Operações aritméticas

Qualquer computador precisa saber trabalhar com operações aritméticas, sendo assim, as instruções aritméticas formam a base de qualquer ISA.

Analisando a arquitetura RISC-V e sua linguagem assembly, temos 3 instruções aritméticas:

Add (Soma, utiliza 3 registradores)
Subtract (Subtração, utiliza 3 registradores)
Add immediate (Soma com constantes, utiliza 2 registradores)

Operações aritméticas em hardware acontecem somente em lugares específicos, esses lugares são chamados de registradores.

Continuando com a arquitetura RISC-V, ela possui 32 registradores de 32 bits de tamanho, esse agrupamento de 32 bits acontece com tanta frequência que chamamos de word.

Operações de memória

Como vimos, a arquitetura RISC-V possui 32 registradores de 32 bits cada, porém sabemos das linguagens de programação que podemos ter tipos de tamanho variável, ou até tipos compostos como arrays. Dada essa necessidade precisamos de instruções que consigam mover dados dos registradores para a memória do computador, e vice versa.

As instruções que movem dados entre registradores e memória damos o nome de data transfer instructions.

Em RISC-V temos duas instruções de transferência de dados:

Load (Copia um word de um certo endereço da memória para um registrador)
Store (Copia um word de um registrador para um certo endereço da memória)

A memória do computador nada mais é do que um grande array, onde os índices são os seus endereços. Em RISC-V, como trabalhamos primariamente com words (agrupamentos de 32 bits ou 4 bytes), o endereço de um word coincide com o endereço de um de seus bytes, words que são vizinhos estão separados por 4 endereços, consequentemente.

Computadores são divididos entre aqueles que usam o endereço do byte mais à esquerda ("big-endian") e aqueles que usam o endereço do byte mais à direita ("little-endian"), a esse conceito damos o nome de endiannes. RISC-V utiliza o “liitle-endian”, ou seja, o endereço de um word equivale ao endereço do seu byte mais a direita.

Representando instruções no computador

Instruções da ISA são mantidas no hardware através de uma série de sinais eletrônicos de baixa e alta voltagem, esses sinais podem ser representados em números, como 0 e 1, ou seja, bits.

Cada componente de uma instrução pode ser considerada como um número individual, agrupando esses números lado a lado temos a representação da instrução. A essa forma de agrupamento de bits damos o nome de “instruction format”.

Dando como exemplo uma instrução de soma do RISC-V:

add x9, x20, x21

Representação decimal:
0  21  20  0  9  51

Cada segmento é chamado de "field"
Os segmentos 1, 4 e 6 (contendo os números 0, 0 e 51) coletivamente dizem para 
o computador RISC-V que essa é uma instrução de soma.
O segmento 2 diz qual é o ultimo registrador da operação de soma (um dos "somandos")
O segmento 3 diz o outro registrador envolvido na soma
O segmento 5 contém o registrador que vai receber o resultado da operação

Representação binária:
|  0000000  |  10101  |  10100  |  000  |  01001  |  0110011  |
   7 bits     5 bits    5 bits   3 bits   5 bits     7 bits

Para distinguir a representação numérica da linguagem assembly, chamamos ela de machine language, uma sequência de instruções é chamada de machine code.

Finalizando

Ao explorar como instruções simples, como operações aritméticas e transferências de dados, são representadas em binário e executadas pelo hardware, podemos apreciar a complexidade e a elegância dos sistemas computacionais. Essa compreensão não só melhora nossas habilidades como programadores, mas também nos permite otimizar e depurar nosso código de maneira mais eficiente.

A evolução das linguagens de programação, desde o assembly até as linguagens de alto nível, reflete o constante esforço da comunidade de tecnologia em tornar a interação com computadores mais acessível e intuitiva. No entanto, a base de toda essa evolução permanece na ISA, que continua a ser o alicerce sobre o qual construímos nossas aplicações.

Apesar de tudo isso, não se sinta pressionado a dominar esses conceitos profundamente. Nós, programadores, trabalhamos diretamente com as linguagens de programação, que foram criadas para abstrair essa complexidade e nos ajudar a ser mais produtivos. Conheço vários ótimos programadores que não dominam esses conceitos e estão se saindo muito bem em suas carreiras. Aprofundar-se em ISA é uma escolha que pode enriquecer sua compreensão e habilidade técnica, mas não é um requisito para ser um excelente programador.

Estrutura de projetos Go

Erick Takeshi — Fri, 17 May 2024 23:16:47 +0000

Quando estamos iniciando um novo projeto em uma nova linguagem, surgem algumas perguntas essenciais:

"Qual estrutura devo utilizar para este projeto?"
"Existe alguma convenção própria da linguagem?"
"Há um padrão amplamente aceito pela comunidade?"

Este artigo busca responder a essas perguntas no contexto da linguagem Go.

A seguir, compilei as práticas mais comuns adotadas pela comunidade, incluindo padrões reforçados pelo compilador da linguagem.

/cmd

Dentro deste diretório devemos criar subdiretórios que representaram cada executável do nosso projeto.

Uma conversão é de não colocarmos muito código dentro deste diretórios ou no arquivo principal. É comum ter uma pequena função main que importa e executa código dos outros diretórios como internal e pkg .

Exemplo de uso no Kubernetes.

/internal

Diretório utilizado para código privado, que não é feito para ser utilizado por outros projetos. Esse padrão é aplicado pelo próprio compilador do Go.

Um adendo é que não estamos limitados somente ao top-level /internal, podemos ter quantos /internal quisermos em qualquer nível de camada da árvore do projeto.

A estrutura dentro do /internal é livre, podemos adicionar o que quisermos.

/pkg

Diretório utilizado para código que pode ser compartilhado com outros projetos, podendo considerar código nesse diretório como público. É uma forma explícita de comunicar que o código aqui dentro é seguro de ser utilizado por terceiros.

Embora seja um padrão popular em diversos projetos (containerd, istio, grafana, etc), ele não é um padrão universalmente aceito, e alguns membros da comunidade Go até não o recomendam, como podemos ver na seguinte discussão sobre o tema.

/vendor

Diretório dedicado a dependências da aplicação, normalmente é administrado por ferramentas como o go mod . O comando go mod vendor vai gerar este diretório automaticamente.

Uma observação importante é a de que não devemos commitar este diretório em nosso repositório Git, por exemplo, principalmente se estivermos desenvolvendo uma biblioteca pública.

Outras divisões relevantes

/api

Guardar specs OpenAPI, json schema, protocol buffers defs, etc

/web ou /ui

Guardar arquivos estáticos da web, como arquivos HTML, CSS e JS, templates SSR (server side rendered) e SPAs.

/deployments ou /deploy

Arquivos de orquestração de containers, configuração de IaaS ou PaaS, etc (docker compose, kubernetes, terraform)

/test

Arquivos para teste automatizado e dados para testes.

Adendo final

É importante ressaltar que esta estrutura não é exclui a aplicação de qualquer arquitetura que seja, como uma Layered baseada em DDD ou Clean Arch, ou Event Driven.

A organização de pastas de um projeto é agnóstica à arquitetura implementada, embora muitas vezes possa refletir a mesma.

Com estas sugestões de organização, você pode iniciar seu projeto Go de maneira mais estruturada e em conformidade com as práticas aceitas pela comunidade.

Como um computador funciona?

Erick Takeshi — Thu, 21 Mar 2024 21:17:20 +0000

Você, programador, sabe como um computador funciona?

Dizer que é uma máquina que sabe interpretar números binários está até que relativamente correto, porém você sabe elaborar mais um pouco sobre isto? Tudo bem não saber a resposta pra esta pergunta, mesmo que num alto nível, afinal, no nosso dia a dia como desenvolvedores estamos trabalhando em uma camada muito acima, na hierarquia do computador, ou seja, extremamente distantes do “metal”.

Eu mesmo tinha uma noção, por ter feito faculdade de engenharia elétrica com ênfase em computação, porém, só fui me aprofundar no tópico mais recentemente, quando me interessei em aprender mais sobre emuladores.

Um último disclaimer é que, não se sinta pressionado em saber essa resposta também! Afinal, posso afirmar com certeza que você pode ser um ótimo desenvolvedor sem fazer o mínimo de noção de como uma computador está organizado, tendo uma noção de conceitos mais alto nível como memória, CPU, threads, I/O e etc. Nosso papel como desenvolvedores é o de nos especializarmos em algoritmos, concorrência e paralelismo e otimização do uso de I/O, podendo abstrair hoje 100% da parte do “metal”, principalmente na era da cloud.

Abstrações e magias que conseguimos com software

De uma perspectiva mais simplista, podemos dividir a organização de um computador da seguinte forma:

Sendo a camada mais externa, o software que nós programadores escrevemos, usando linguagens de programação como C, C++, Java, Ruby, Go, etc.

A camada intermediária seria a interface entre nosso software com o hardware de fato, sendo dois grandes exemplos de software de interface os compiladores e os sistemas operacionais.

O papel do sistema operacional normalmente é o de prover diversas APIs ao hardware assim como mandar funções de supervisionamento.

Alguns exemplos de funções importantes do OS (operating system, ou sistema operacional):

Lidar com I/O
Alocação de memória e armazenamento (disco)
Prover uma interface segura para que diferentes aplicações possam utilizar os recursos do computador de maneira simultânea e harmoniosa

Compiladores executam uma tarefa vital também para o funcionamento dos programas, eles “traduzem” programas escritos em linguagens mais alto nível (como C ou Java) em instruções que o hardware consegue executar, chamadas de machine language (ou linguagem de máquina). Alguns compiladores conseguem executar uma tradução direta, outros utilizam um passo intermediário, onde transformam o código alto nível em um de mais baixo nível chamado de assembly, que nada mais é do que uma linguagem que abstrai um pouco a linguagem de máquina (bits) em instruções mais fáceis de um humano entender, porém estando bem mais próximo do jeito que computadores de fato funcionam. O software que consegue converter assembly em linguagem de máquina é normalmente chamado de assembler.

Olhando embaixo do capô

Após analisar um pouquinho como as camadas de software interagem e compunham nossos programas, vamos abaixar um degrau e olhar como a parte de hardware funciona.

Existem 5 principais categorias de componentes de um computador, qualquer componente, seja ele antigo ou moderno, pode ser categorizado sob essas cinco categorias. Elas são input (entrada), output (saída), memória, datapath (caminho de dados) e controle, sendo datapath e controle normalmente agrupados como processadores.

I / O

Dispositivos de I/O são os dispositivos que geram dados de entrada e saída no computador, normalmente são os que estamos mais familiarizados, exemplos de dispositivos de I/O são monitores, teclados, mouses, placas de rede, bluetooth, câmeras, microfones, etc.

Não entraremos tanto em detalhes pois cada dispositivo diferente de I/O tem seu propósito específico, além disso, já estamos mais familiarizados com seus funcionamentos.

Memória

Memória é basicamente o componente responsável por guardar instruções de programas e dados do computador.
Existem algumas categorias de memórias, sendo a mais comumente conhecida a DRAM (dynamic random access memory). RAM (random access memory) é um termo utilizado para denominar unidades de armazenamento que levam o mesmo tempo para acessar qualquer parte desta unidade, ou seja, não importa em qual parte o dado se encontra, fisicamente, ele pode ser acessado no mesmo intervalo de tempo.

Dentro do processador encontramos um outro tipo de memória chamada de Cache, uma memória extremamente rápida, que é utilizada como um buffer da DRAM (um buffer nada mais é do que um espaço onde dados que são mais frequentemente utilizados são guardados, sendo este um local de maior performance, economizado outros recursos e tornando o computador mais eficiente como um todo). A tecnologia utilizada para construir um Cache do processador é chamada de SRAM (static random access memory), uma tecnologia muito mais rápida do que a DRAM, porém mais cara.

Tanto a DRAM quanto a SRAM são tecnologias de memória voláteis, ou seja, assim que a energia do computador é cortada elas são completamente apagadas. Tendo esta característica em mente, surgiu a necessidade de termos um espaço diferente no computador para armazenarmos dados persistentes, assim surgiram os discos magnéticos, uma tecnologia de armazenamento de longo prazo, onde os dados ficam gravados mesmo quando não há energia no computador. Posteriormente, principalmente com o advento de dispositivos mobiles, um segundo tipo de tecnologia de armazenamento de local prazo surgiu como alternativa, o flash memory, sendo bem utilizado por conta de seu tamanho físico e custo por bits.

Na hierarquia de memória, chamamos DRAM / SRAM de memória primária, enquanto flash memory e discos magnéticos são categorizados como memória secundária.

Processador

O processador ou CPU é um componente complexo dos computadores, formado por diversas sub-máquinas, ele é responsável por buscar instruções da memória, decodificá-las, executar as operações (contas aritméticas, acesso a memória ou controlar outras parts do sistema) e escrever os resultados de volta, seja na memória ou em seus registradores. Todos essas passos são executados em um loop ininterrupto.

Alguns componentes notórios da CPU são seus registradores, a ALU (arithmetic logic unit) e suas unidades de controle.

Registradores são unidades de memória do processador, totalmente separadas da RAM, onde são guardadas dados intermediários, frutos de algum processo de cálculo, registradores de inputs, que guardam dados da RAM e de outputs, que enviam resultados de volta pra RAM (normalmente como buffers).

ALU é a unidade lógica aritmética, nada mais é do que um conjunto de maquinas simples que tem o papel de executar operações aritméticas, cada uma especializada em um tipo de operação.

A unidade de controle é responsável por ler instruções de um programa da RAM, decodificá-las e passa-las para a ALU ou pra outro lugar para serem executadas (como gravar algo em disco ou executar algo em I / O). Após este passo, ela atualiza o ponteiro do programa (PC, program counter), que mantém guardado a informação da localização da próxima instrução a ser executada. As instruções são lidas sequencialmente ou executando pulos (ou seja, indo para um lugar não sequencial baseado em alguma instrução prévia).

A interface entre hardware e o software

Um dos princípios fundamentais da arquitetura de computadores é que abstrações simplificam o design. Isso significa que ao utilizar abstrações, programadores e arquitetos podem se comunicar de forma mais eficaz. Um dos avanços significativos na área da computação foi ocultar os detalhes de implementação do hardware, expondo apenas um modelo simples e padronizado para que os programadores pudessem escrever seus programas.

Uma das mais importantes abstrações é a interface entre hardware e software, que chamamos de instruction set architecture (ISA). A ISA é formada por uma série de instruções que o computador é capaz de executar, como operações aritméticas, I / O e etc.

Tipicamente, temos o sistema operacional que encapsula detalhes de como fazer I / O, alocar memória e outras funções mais baixo nível, para que programadores não tenham que se preocupar com isto. A combinação de instruções básicas e a API fornecida pelo sistema operacional é chamada de application binary interface.

Qual a relação entre ISA e assembly?

A ISA caracteriza o que um hardware pode fazer, ou seja, inclui todas as instruções que uma CPU pode executar, endereço de seus registradores, o modelo de memória utilizado, como instruções são decodificadas, etc. A linguagem assembly é uma linguagem de programação que corresponde muito proximamente as instruções da ISA (Lembrando que as instruções da ISA normalmente são codificadas como um binário que representa determinada instrução específica).

A relação entre a ISA e o assembly é que o assembly proporciona uma representação passível de compreensão por humanos da ISA de determinado hardware.

Conclusão

Em resumo, podemos dizer que a arquitetura de computadores é um campo fascinante que abrange desde os conceitos mais abstratos, como a forma como os programas são escritos e interpretados pelos computadores, até os detalhes mais concretos, como o funcionamento interno dos componentes de hardware. Embora muitos programadores possam trabalhar sem a necessidade de entender profundamente esses detalhes, ter uma compreensão básica de como um computador funciona pode ser extremamente útil para compreender melhor o funcionamento dos programas que escrevemos e para tomar decisões de design mais informadas.

Referências
Imagens tiradas do livro Computer Organization and Design

Injeção de dependência em Go

Erick Takeshi — Wed, 28 Feb 2024 01:37:29 +0000

Software é uma arte em constante mudança e evolução.

Como programadores, sabemos que certamente seremos requisitados a mudarmos nosso código, seja implementando uma feature nova, corrigindo um bug ou rodando em um ambiente novo. Tendo isso em mente, uma das maiores características que devemos mirar para que nosso código tenha é a de ser fácil de modificar.

Engenheiros de software estão sempre repetindo palavras como desacoplamento, que significa que diferentes partes do software podem ser modificadas sem que afetem outras partes.

Uma das técnicas mais famosas, quando se trata de alcançar desacoplamento, é a injeção de dependência. A injeção de dependência é um conceito que dita que seu código deve ser explícito ao declarar suas dependências, sendo este conceito cunhado pela lenda Uncle Bob (Robert Martin), no seu famigerado artigo “The Dependency Inversion Principle”, datado de 1996.

Implementando em Go

Em Go, temos duas construções importantes, sendo structs (para definir objetos, ou seja, agrupamentos de dados correlacionados) e interfaces (para definir comportamentos dos objetos). Interfaces em Go usam um mecanismo de resolução implícito, ou seja, não é necessário declarar explicitamente que algum tipo implementa uma interface específica, isso é feito de maneira implícita, algo análogo a duck typing em outras linguagens. Interfaces implícitas em Go fazem com que injeção de dependência seja implementada de maneira simples.

Algumas técnicas simples de implementar de injeção de dependência em Go são:

Injeção por constructor
Injeção por propriedades (setter methods)

Injeção por constructor

Em injeção por constructor, normalmente, temos uma função factory (construtora) que vai retornar uma instância de uma struct com suas dependências já associadas.

Abaixo um exemplo de código em Go.

type Repository interface{
    // repo methods
}
type AppLogger interface{
    Log(message string)
}

type UseCase struct {
    logger     AppLogger
    repository Repository
}

func NewUseCase(logger AppLogger, repository Repository) *UserCase {
    return &UseCase{
        logger: logger,
        repository: repository
    }
}

func (u *UseCase) Call(ctx context.Context) error {
    // do some stuff

    return nil
}

// injetando as dependências
func main() {
    // instancias concretas
    logger := MyLogger{}
    repo := MyRepository{}

    useCase := NewUseCase(logger, repo)

    useCase.Call()
    // ... do something
}

Um ponto importante a se destacas é que com injeção por constructor estamos fixando as dependências em tempo de compilação, ou seja, não podemos trocas elas dinamicamente conforme alguma condição. Existem vantagens e desvantagens nesse método.

Injeção por propriedades

Na injeção por propriedades utilizamos um método setter para alocar a dependência correta, assim sendo mais flexível, podendo trocar a dependência em tempo de runtime.

Segue o exemplo para ilustrar:

type UseCase struct {
    logger     AppLogger
    repository Repository
}

func (u *UseCase) SetLogger(logger AppLogger) {
    u.logger = logger
}

func (u *UseCase) SetRepository(repo Repository) {
    u.repository = repo
} 

// injetando as dependências
func main() {
    // instancias concretas
    logger := MyLogger{}
    repo := MyRepo{}

    useCase := UseCase{}
    useCase.SetLogger(logger)
    useCase.SetRepository(repo)

    useCase.Call()
    // ... do something
}

Injeção manual vs via framework

No exemplos apresentados estamos utilizando a técnica de injeção manual, ou seja, estamos utilizando ferramentas nativas da linguagem, sem utilizar nenhuma dependência externa, como libs ou frameworks.

Existem alguns frameworks muito utilizados em Go, como o Wire do Google ou o Dig da Uber.

Cada framework possui suas vantagens e desvantagens, além disso, cabe ainda ponderar se faz sentido o uso de um framework ou não.

Injeção Manual:

Prós:

Controle completo de como as dependências são injetadas
Nenhuma dependência externa
Muito mais simples de entender e não requer nenhum conhecimento extra, como DSL própria

Contras:

Requer escrita de mais código boilerplate
Pode ser muito passivo de erro humano, principalmente quando as dependências começam a ficar mais complexas, conforme o projeto cresce
Acaba sendo muito complexo de manter grafos complexos de dependências

Framework

Prós:

Reduz boilerplate provendo um mecanismo automático
Ajuda a promover melhores práticas e padrões de design para orquestrar dependências
Pode ajudar a simplificar testes, ao facilitar o uso de mock objects

Contras:

Adiciona uma dependência externa ao projeto
Requer o aprendizado de um framework novo, que envolve conceitos, configurações e um DSL
Pode não ser apropriado para todos os projetos, as vezes pode adicionar problemas de uso de memória ou performance que são cruciais para alguns projetos.

Em linhas gerais, injeção manual ajuda a termos mais controle sobre o processo, porém requer mais código e pode ser mais suscetível a erros, enquanto que um framework automatiza muito desse processo e promove melhores práticas, ao custo de aumentar curva de aprendizado, adicionar uma dependência externa e talvez sacrificar um pouco de performance (como alguns frameworks utilizam de Reflection).

A escolha vai depender de diversos fatores, como a complexidade do projeto, a familiaridade do time com conceitos de injeção de dependência e os trade-offs entre controle vs conveniência.

tl;dr

Go é uma linguagem poderosa que nos permite implementar injeção de dependência de maneira simples, sem a necessidade de frameworks, como frequentemente exigido em linguagens como Java. No entanto, também temos à disposição frameworks em Go, como o Wire da Google, que automatizam parte desse processo.
A decisão de utilizar um framework ou não deve ser cuidadosamente considerada, avaliando as necessidades específicas de cada projeto e os trade-offs entre simplicidade e controle.

Meus aprendizados com a Rinha de Backend 2023 Q3

Erick Takeshi — Thu, 22 Feb 2024 18:03:42 +0000

A rinha de backend foi um evento incrível, e mesmo não acompanhando em real time, pude revisar os vídeos e tweets recentemente e fiquei muito impressionado com o que vi. Decidi compilar aqui os principais aprendizados que retirei desta competição.

Docker

Docker sempre foi uma ferramenta que eu meio que negligenciei pra falar a verdade :)

Embora na maioria das empresas não tenhamos muito contato direto com a infraestrutura como desenvolvedores, acredito que valha a pena entender pelo menos o básico

Indo direto ao ponto, a técnica que realmente fez diferença pra rinha:

network_mode: host

Basicamente, com Docker, podemos escolher alguns modos diferente para trabalharmos com rede. O modo padrão é o bridge, onde o Docker utiliza uma rede interna e privada (ao host) e os containers podem se comunicar uns com os outros através dos seus container names (que são utilizados como hostname), além de poderem se comunicar com a rede externa através de NAT.

Outro modo é o host, onde os containers terão acesso direto as network interfaces do seu host, o que aumenta a performance. No entanto, é necessário ter cuidado para evitar conflitos, já que as portas reais são usadas.

Como a rinha em si não dizia nada a respeito de restrições de network no docker-compose, poderíamos aproveitar do modo host e ganhar uma performance maior.

Porquê o network_mode host é mais rápido?

O modo bridge na verdade que é mais lento, isso porque ele introduz uma camada extra sobre a rede do próprio host, um DNS interno, no qual o Docker precisa traduzir um container name para um endereço IP da rede.

Lembrando que os ganhos desse modo só são mais perceptíveis quando estamos falando de containers rodando no mesmo host.

Post de ref com alguns benchmarks.

Banco de dados

Monitoramento e benchmarks

Aqui temos uns aprendizados bem interessantes.

Bancos de dados, especialmente os relacionais, costumam ser ferramentas familiares para os desenvolvedores, porém, são poucos os que possuem conhecimento em benchmarks, otimização e performance.

Na rinha, ficou claro que o banco de dados em si não era o gargalo, mas sim a configuração correta do mesmo. Para atingir o máximo desempenho nos testes da rinha, era necessário alocar os recursos adequadamente entre a aplicações, load balancer e o banco de dados.

Em um ambiente aberto e com restrições mais alto nível (algo como a EC2 “crua” da AWS), podemos rodar serviços na mesma máquina, dividindo recursos entre os diferentes serviços, assim como era o cenário da rinha.

Para mensurar e distribuir corretamente esses recursos, é necessário usar ferramentas de monitoramento nos serviços. Para o banco de dados, temos ferramentas como pgAdmin ou o MySQL Workbench, ajudando a enxergar e tunar o uso de CPU, memória e número de conexões.

Em resumo, o aprendizado que fica é: não assuma nada, sempre meça e tire suas conclusões. Em alguns casos, estamos restritos por outros fatores, o que facilita o calculo dos recursos necessários ou número de conexões, mas em casos mais abertos, medir e chegar no número ideal é a melhor abordagem.

Queries em campos de texto

Um aprendizado mais específico, nem sempre precisamos lidar com buscas desse tipo, mas é interessante termos essa técnica nosso “cinto de utilidades”.

Queries com ILIKE tendem a ser lentas e não conseguimos usar índices de forma convencional. O Postgres tem acesso nativo a index do tipo GIST que servem pra indexar campos de texto e otimizar queries deste tipo. No entanto, mesmo com esse índice, ainda teríamos que executar o OR em 3 campos diferentes e juntar os resultados, o que ainda tornaria a query lenta.

A solução inteligente neste caso é unir os 3 campos em um só e indexar via GIST este campo, assim conseguimos atingir máxima performance para este tipo de query especifica.

Vale ressaltar que utilizar o EXPLAIN é uma ferramenta valiosa pra nos ajudar a identificar o planejamento da query pelo banco e, assim, traçar estratégias, como essa mencionada, para otimizar queries.

Um último adendo é que embora o Postgres, ou outros bancos com suporte a full text search, consigam lidar bem com muitos casos, é importante estar atento se no nosso caso e escala específica já não estamos em um cenário em que ferramentas extremamente especializadas começam a fazer sentido, como o Elasticsearch. Precisamos sempre balancear os tradeoffs e ver quando estamos atingindo o limite da tecnologia que temos no momento e, ai sim, migrar pra outra que atenda nossos requisitos.

Conclusão

Foram muitos aprendizados bacanas com a rinha e eu acho que esse é o tipo de competição saudável que ajuda demais a comunidade, deixo aqui meus agradecimentos ao Zan Franceschi, organizador e idealizador da rinha e ao Akita e o MrPowerGamerBR, pelos ótimos videos explicativos sobre a rinha.

Estou ansioso pra acompanhar o que vai rolar nessa rinha de 2024, além de estar planejando e executando minha solução aqui ;)

makefile para projetos em Go

Erick Takeshi — Mon, 19 Feb 2024 20:51:04 +0000

make é uma ferramenta de sistemas Unix utilizada para buildar programas desde 1976.

Embora seja muito utilizada em, e frequentemente associada a, desenvolvimento de programas em C ou C++, o make também foi a ferramenta adotada pela comunidade Go para automatizar tarefas relacionadas a projetos.

Para utilizar o make precisamos de um arquivo, que por convenção é chamado de Makefile, que contem as instruções de como buildar um determinado projeto.

Abaixo segue exemplo de um Makefile qualquer para um programa em Go:


# variaveis
GOCMD = go
GOLINT = golint

# declaracao da instrucao default
.DEFAULT_GOAL := build

# rules
fmt:
    $(GOCMD) fmt ./...
.PHONY: fmt

lint: fmt
    $(GOLINT) ./...
.PHONY: lint

vet: fmt
    $(GOCMD) vet ./...
.PHONY: vet

build: vet
    $(GOCMD) build
.PHONY:build

Passando por cada aspecto rapidamente:
Nas primeiras linhas do arquivo vemos a declaração de algumas variáveis que serão uteis para nos ajudar a chamar o comando nas regras definidas (rules). A variável GOCMD é especialmente interessante pois podemos deixar nosso Makefile agnóstico de versões do Go, uma vez que, com o suporte built-in da linguagem, deverias ter algo como go1.15.2 quando quisermos utilizar uma versão específica.

Na linha seguinte temos a declaração do .DEFAULT_GOAL que atribui qual vai ser a regra a ser rodada quando não passarmos nenhum argumento pro executável do make, ou seja, invocando somente make no diretório do projeto vai executar a regra “build”.

Nas próximas linhas temos as declarações de regras (rules), essas regras são os nomes que damos a sequencias de instruções shell que deverão ser executadas, alem disso, temos a declaração do .PHONY, uma instrução que dita que aquela regra em específico não produz um arquivo como output.

A estrutura de uma regra é a seguinte:

nome_da_regra: dep1 dep2
    intructions
    instruction2

dep1: ...

Um importante aspecto que precisamos nos atentar é que o make é bem “chato” quando se trata de espaçamento antes das instruções shell, precisamos sempre usar tab ante de cada instrução, não podemos usar espaços (como usamos por padrão em alguns editores de texto, é bom verificar).

OBS sobre o Makefile de exemplo

Em projetos de produção você vai querer utilizar o golangci-lint, linter que faz o uso de diversos linter por debaixo dos panos, de maneira otimizada.

Utilizamos linters e formatters de maneira separada em cada rule para poder exemplificar como ficaria um Makefile um pouco mais complexo.

tl;dr

Em resumo, o uso do Makefile para projetos em Go representa uma abordagem eficaz e padronizada para automatizar tarefas relacionadas ao desenvolvimento, proporcionando uma estrutura organizada para execução de comandos essenciais. A flexibilidade oferecida pelo Makefile permite que desenvolvedores configurem regras específicas, como formatação, linting e compilação, de forma concisa e fácil de manter.