AVISO: esta série é uma fantasia satírica baseada em fatos reais sobre Elixir. Nada aqui deve ser levado ao pé da letra. Ao final de cada capítulo, os fatos por trás da lenda são revelados. Tags: #satire #humor #elixir #enchiridium
Elixir Enchiridium — Tomo V: O Ecossistema
Capítulos 32 a 60
(Continuação direta do Tomo V — O Ecossistema, após o Capítulo 31 — Mnesia)
Capítulo 32 — Ecto.Schema: O Mapa que Traduz o Mundo
A lenda diz que o Ecto.Schema é um mapa do tesouro. Cada schema é um mapa que aponta para uma tabela no banco de dados. Cada campo é uma pista. Cada associação é uma trilha. Se você seguir o mapa, encontra o tesouro. Se errar, encontra um erro de compilação.
A verdade é que um schema Ecto mapeia dados externos para structs Elixir. A definição do schema é possível através de duas APIs principais: schema/2 e embedded_schema/1. schema/2 é tipicamente usado para mapear dados de uma fonte persistida, geralmente uma tabela de banco de dados. O schema gera uma chave primária chamada id por padrão.
A lenda diz que, na primeira vez que um programador criou um schema, ele perguntou: "Isso é uma tabela?" O instrutor respondeu: "Não. É um mapa para a tabela."
O fato por trás da lenda: Ecto.Schema mapeia dados externos para structs Elixir. As duas APIs principais são schema/2 e embedded_schema/1. Gera uma chave primária id por padrão.
Gancho: O mapa traduz. Mas há uma coisa que busca: o Ecto.Repo.
Capítulo 33 — Ecto.Repo: A Porta para o Banco de Dados
A lenda diz que o Ecto.Repo é uma porta. Você bate na porta, e o banco de dados responde. Você insere, atualiza, deleta, consulta. O Repo traduz. O Repo executa. O Repo nunca erra. O Repo nunca dorme.
A verdade é que Ecto.Repo é o repositório que define a interface para o banco de dados. Cada aplicação define seu próprio Repo, que usa um adapter (PostgreSQL, MySQL, SQLite). O Repo fornece funções como insert/2, update/2, delete/2, get/3, all/2. Ele gerencia transações, conexões e queries.
A lenda diz que, na primeira vez que um programador usou o Repo, ele perguntou: "Onde está o banco?" O instrutor respondeu: "Atrás da porta."
O fato por trás da lenda: Ecto.Repo define a interface para o banco de dados. Cada aplicação tem seu próprio Repo, que usa um adapter. Fornece insert/2, update/2, delete/2, get/3, all/2.
Gancho: A porta busca. Mas há uma coisa que roteia: o Phoenix.Router.
Capítulo 34 — Phoenix.Router: O Guarda de Trânsito das URLs
A lenda diz que o Phoenix.Router é um guarda de trânsito. Cada URL é um carro. Cada rota é uma placa. O guarda olha para a URL e decide para onde ela vai. Se a URL não tem rota, o guarda levanta a mão e devolve um 404. O guarda nunca erra. O guarda nunca dorme.
A verdade é que o Phoenix.Router fornece um conjunto de macros para gerar rotas que despacham para controllers e actions específicos. Essas macros são nomeadas após verbos HTTP. O router do Phoenix é extremamente eficiente, pois se baseia em pattern matching do Elixir para casar rotas e servir requisições. Routers são os principais hubs das aplicações Phoenix.
A lenda diz que, na primeira vez que um programador criou uma rota, ele perguntou: "O que é isso?" O instrutor respondeu: "É uma placa de trânsito."
O fato por trás da lenda: Phoenix.Router fornece macros para gerar rotas que despacham para controllers. Baseia-se em pattern matching para casar rotas. Routers são os principais hubs das aplicações Phoenix.
Gancho: O guarda roteia. Mas há uma coisa que responde: o Phoenix.Controller.
Capítulo 35 — Phoenix.Controller: O Porteiro que Recebe as Visitas
A lenda diz que o Phoenix.Controller é um porteiro. Ele recebe as visitas. Cada visita é uma requisição HTTP. Cada ação é uma resposta. O porteiro cumprimenta, processa, responde. O porteiro nunca erra. O porteiro nunca se confunde.
A verdade é que controllers são usados para agrupar funcionalidade comum no mesmo módulo plugável. Suas funções — chamadas de actions — são invocadas pelo router em resposta a requisições HTTP. Um controller por padrão fornece muitas funções de conveniência para manipular a conexão, renderizar templates e mais.
A lenda diz que, na primeira vez que um programador criou um controller, ele perguntou: "O que é isso?" O instrutor respondeu: "É o porteiro."
O fato por trás da lenda: Controllers agrupam funcionalidade comum em módulos plugáveis. Actions são invocadas pelo router. Fornecem funções para manipular a conexão e renderizar templates.
Gancho: O porteiro responde. Mas há uma coisa que renderiza: o Phoenix.View.
Capítulo 36 — Phoenix.View: O Pintor que Pinta as Telas
A lenda diz que o Phoenix.View é um pintor. Ele pinta as telas. Cada template é uma tela. Cada layout é uma moldura. O pintor usa HEEx, uma tinta especial que valida em tempo de compilação. O pintor nunca erra. O pintor nunca borra.
A verdade é que Phoenix.View define a camada de visualização de uma aplicação Phoenix. Este módulo é usado para definir a view principal da aplicação, que serve como base para todas as outras views e templates. Com o Phoenix.LiveView, este módulo caiu em desuso em favor do Phoenix.Component. O .heex é a extensão de template que diz ao Phoenix como compilar o código.
A lenda diz que, na primeira vez que um programador criou uma view, ele perguntou: "O que é isso?" O instrutor respondeu: "É o pintor."
O fato por trás da lenda: Phoenix.View define a camada de visualização. Com o Phoenix.LiveView, caiu em desuso em favor do Phoenix.Component. O .heex é a extensão de template.
Gancho: O pintor pinta. Mas há uma coisa que transmite em tempo real: o Phoenix.Channel.
Capítulo 37 — Phoenix.Channel: O Canal de Comunicação em Tempo Real
A lenda diz que o Phoenix.Channel é um canal. Ele transmite mensagens em tempo real. Cada cliente entra no canal. Cada mensagem é distribuída. O canal nunca fecha. O canal nunca perde uma mensagem.
A verdade é que Channels são uma parte poderosa do Phoenix que permite adicionar recursos de soft-realtime às aplicações. Channels são baseados em enviar e receber mensagens. Cada Channel implementa uma ou mais cláusulas de quatro funções de callback: join/3, terminate/2, handle_in/3, e handle_out/3. Channels são construídos sobre WebSockets (com fallback para long-polling).
A lenda diz que, na primeira vez que um programador criou um Channel, ele perguntou: "O que é isso?" O instrutor respondeu: "É o canal."
O fato por trás da lenda: Phoenix.Channel permite comunicação em tempo real. Cada Channel implementa join/3, terminate/2, handle_in/3, handle_out/3. Construído sobre WebSockets com fallback para long-polling.
Gancho: O canal transmite. Mas há uma coisa que calcula: o Nx.
Capítulo 38 — Nx: A Calculadora que Pensa em Tensores
A lenda diz que o Nx é uma calculadora. Mas não é uma calculadora comum. É uma calculadora que pensa em tensores. Ela calcula em CPUs. Ela calcula em GPUs. Ela calcula em TPUs. O Nx nunca erra. O Nx nunca para.
A verdade é que Nx é uma biblioteca de arrays multidimensionais (tensores) e definições numéricas para Elixir. Suas características de alto nível incluem tensores multidimensionais tipados, onde os tensores podem ser inteiros sem sinal (u8, u16, etc.), e definições numéricas, conhecidas como defn, que são um subconjunto de Elixir compilável para múltiplos alvos, incluindo GPUs. O Nx é a base para todo o ecossistema de machine learning do Elixir.
A lenda diz que, na primeira vez que um programador usou Nx, ele perguntou: "Isso é uma matriz?" O instrutor respondeu: "Não. É um tensor."
O fato por trás da lenda: Nx é uma biblioteca de tensores e definições numéricas para Elixir. Tensores multidimensionais tipados. defn é um subconjunto de Elixir compilável para CPUs, GPUs e TPUs.
Gancho: A calculadora calcula. Mas há uma coisa que treina: o Axon.
Capítulo 39 — Axon: O Treinador de Redes Neurais
A lenda diz que o Axon é um treinador. Ele treina redes neurais. Ele constrói camadas. Ele ajusta pesos. Ele calcula gradientes. O Axon nunca erra. O Axon nunca desiste.
A verdade é que Axon é uma biblioteca para criar e treinar redes neurais em Elixir, construída sobre o Nx. Axon fornece implementações funcionais de operações comuns de camadas de redes neurais. As camadas são os blocos de construção das redes neurais. O Axon tem cerca de 1.600 estrelas no GitHub e 330 mil downloads.
A lenda diz que, na primeira vez que um programador usou Axon, ele perguntou: "O que é uma camada?" O instrutor respondeu: "É um bloco de construção."
O fato por trás da lenda: Axon é uma biblioteca para criar e treinar redes neurais em Elixir, construída sobre Nx. Fornece implementações de camadas. Tem cerca de 1.600 estrelas no GitHub.
Gancho: O treinador treina. Mas há uma coisa que carrega modelos: o Bumblebee.
Capítulo 40 — Bumblebee: A Abelha que Carrega Modelos Pré-Treinados
A lenda diz que o Bumblebee é uma abelha. Ela carrega modelos pré-treinados. Ela poliniza aplicações com IA. Ela integra com o Hugging Face. A abelha nunca erra. A abelha nunca cansa.
A verdade é que Bumblebee fornece modelos de redes neurais pré-treinados sobre o Axon. Ele inclui integração com o Hugging Face Models, permitindo que qualquer pessoa baixe e execute tarefas de machine learning com poucas linhas de código. Bumblebee suporta modelos como SmolLM3, Qwen3, Gemma3Text, NomicBERT, ModernBERT, e muitos outros.
A lenda diz que, na primeira vez que um programador usou Bumblebee, ele perguntou: "O que é isso?" O instrutor respondeu: "É a abelha que carrega modelos."
O fato por trás da lenda: Bumblebee fornece modelos pré-treinados sobre Axon. Integra com Hugging Face. Suporta SmolLM3, Qwen3, Gemma3Text, NomicBERT, ModernBERT.
Gancho: A abelha carrega. Mas há uma coisa que explora dados: o Explorer.
Capítulo 41 — Explorer: O Detetive que Investiga Dataframes
A lenda diz que o Explorer é um detetive. Ele investiga dataframes. Ele lê arquivos. Ele consulta dados. Ele encontra padrões. O detetive nunca erra. O detetive nunca desiste.
A verdade é que Explorer traz séries (unidimensionais) e dataframes (bidimensionais) para exploração rápida de dados em Elixir. As séries são tipadas (:binary, :boolean, :datetime, :duration, etc.) e garantem conter apenas itens de um tipo de dado. Dataframes podem ser criados de duas maneiras: lendo de arquivos ou memória. Explorer é escrito em Rust para performance.
A lenda diz que, na primeira vez que um programador usou Explorer, ele perguntou: "O que é um dataframe?" O instrutor respondeu: "É uma tabela que você pode investigar."
O fato por trás da lenda: Explorer traz séries e dataframes para exploração de dados em Elixir. Séries são tipadas. Dataframes podem ser criados lendo de arquivos ou memória. Escrito em Rust.
Gancho: O detetive investiga. Mas há uma coisa que aprende: o Scholar.
Capítulo 42 — Scholar: O Professor que Ensina Machine Learning Clássico
A lenda diz que o Scholar é um professor. Ele ensina machine learning clássico. Ele implementa algoritmos. Ele calcula regressões. Ele agrupa dados. O professor nunca erra. O professor nunca se confunde.
A verdade é que Scholar implementa ferramentas de machine learning tradicional construídas sobre Nx. Ele implementa algoritmos para classificação, regressão, clustering, redução de dimensionalidade, métricas e pré-processamento. Para deep learning, o Scholar recomenda o Axon. Scholar é comparável ao scikit-learn do Python. Mateusz Słuszniak e Krsto Proroković são os principais contribuidores.
A lenda diz que, na primeira vez que um programador usou Scholar, ele perguntou: "O que é isso?" O instrutor respondeu: "É o professor de ML clássico."
O fato por trás da lenda: Scholar implementa ferramentas de machine learning tradicional sobre Nx. Classificação, regressão, clustering, redução de dimensionalidade, métricas e pré-processamento. Comparável ao scikit-learn.
Gancho: O professor ensina. Mas há uma coisa que envia emails: o Swoosh.
Capítulo 43 — Swoosh: O Carteiro que Entrega Emails
A lenda diz que o Swoosh é um carteiro. Ele compõe emails. Ele entrega emails. Ele testa emails. Ele tem 12 adapters. O carteiro nunca erra. O carteiro nunca perde uma carta.
A verdade é que Swoosh é uma biblioteca para compor, entregar e testar emails facilmente em Elixir. Ela vem com 12 adapters, incluindo SendGrid, Mandrill, Mailgun, Postmark e SMTP. Swoosh suporta os provedores de email transacional mais populares e também tem um adapter SMTP. Você pode enviar emails assíncronos simplesmente aproveitando a biblioteca padrão do Elixir.
A lenda diz que, na primeira vez que um programador usou Swoosh, ele perguntou: "O que é um adapter?" O instrutor respondeu: "É o carteiro que entrega."
O fato por trás da lenda: Swoosh compõe, entrega e testa emails. Vem com 12 adapters, incluindo SendGrid, Mandrill, Mailgun, Postmark e SMTP.
Gancho: O carteiro entrega. Mas há uma coisa que também entrega: o Bamboo.
Capítulo 44 — Bamboo: O Panda que Também Entrega Emails
A lenda diz que o Bamboo é um panda. Ele também entrega emails. Mas ele é diferente do Swoosh. Ele é baseado em adapters. Ele separa a criação do envio. Ele é testável. Ele é composável.
A verdade é que Bamboo é uma biblioteca de email flexível e fácil de usar para Elixir. É baseada em adapters, então pode ser usada com Mandrill, SMTP, ou qualquer outro serviço. Emails são apenas um struct Bamboo.Email e podem ser manipulados com funções simples. Bamboo quebra a criação e o envio de email em dois módulos separados. Bamboo é mantido pela beam-community.
A lenda diz que, na primeira vez que um programador usou Bamboo, ele perguntou: "Por que não usar Swoosh?" O instrutor respondeu: "Porque Bamboo é mais antigo. E alguns preferem pandas."
O fato por trás da lenda: Bamboo é uma biblioteca de email baseada em adapters para Elixir. Separa criação e envio. É mantida pela beam-community. Tem cerca de 1.900 estrelas no GitHub.
Gancho: O panda entrega. Mas há uma coisa que autentica: o Guardian.
Capítulo 45 — Guardian: O Guardião da Autenticação
A lenda diz que o Guardian é um guardião. Ele autentica. Ele autoriza. Ele gera tokens. Ele verifica tokens. Ele protege rotas. O guardião nunca erra. O guardião nunca deixa passar um intruso.
A verdade é que Guardian é uma biblioteca de autenticação baseada em tokens para aplicações Elixir. Guardian é baseado em ideias similares ao Warden e Omniauth, mas foi reimaginado para sistemas modernos onde o Elixir gerencia os requisitos de autenticação. O tipo de token padrão é JWT. Você pode usar o JWT para autenticar endpoints web, channels e sockets TCP.
A lenda diz que, na primeira vez que um programador usou Guardian, ele perguntou: "O que é um JWT?" O instrutor respondeu: "É um token. E o Guardian o verifica."
O fato por trás da lenda: Guardian é uma biblioteca de autenticação baseada em tokens. Usa JWT como padrão. Pode autenticar endpoints web, channels e sockets TCP.
Gancho: O guardião protege. Mas há uma coisa que também protege: o Pow.
Capítulo 46 — Pow: A Poção da Autenticação
A lenda diz que o Pow é uma poção. Ela autentica. Ela gerencia usuários. Ela cria sessões. Ela renova sessões. Ela é modular. Ela é extensível. A poção nunca erra. A poção nunca falha.
A verdade é que Pow é uma solução de autenticação e gerenciamento de usuários robusta, modular e extensível para Phoenix e aplicações baseadas em Plug. Pow usa autorização baseada em sessão. O módulo Plug tem métodos para autenticar, criar, atualizar e deletar usuários, e irá gerar/renovar a sessão automaticamente. Por padrão, Pow usa o módulo Pow.Ecto.Context para autenticar, criar, atualizar e deletar usuários com lookups no banco de dados.
A lenda diz que, na primeira vez que um programador usou Pow, ele perguntou: "O que é isso?" O instrutor respondeu: "É a poção da autenticação."
O fato por trás da lenda: Pow é uma solução de autenticação e gerenciamento de usuários para Phoenix e Plug. Usa autorização baseada em sessão. Padrão: Pow.Ecto.Context para autenticação.
Gancho: A poção protege. Mas há uma coisa que modela domínios: o Ash.
Capítulo 47 — Ash: O Arquiteto que Modela Domínios
A lenda diz que o Ash é um arquiteto. Ele modela domínios. Ele define recursos. Ele define ações. Ele gera código. Ele reduz boilerplate. O arquiteto nunca erra. O arquiteto nunca se perde.
A verdade é que Ash é um framework de aplicação declarativo e opinativo que traz a experiência "batteries-included" para Elixir. Ele brilha ao construir aplicações web. Em seu coração, Ash é um framework para modelar o domínio da sua aplicação através de Resources e suas Actions. Essas são as abstrações fundamentais sobre as quais tudo o mais é construído. Ash é usado com Phoenix LiveView ou para construir APIs em minutos. O repositório do Ash tem cerca de 1.600 estrelas.
A lenda diz que, na primeira vez que um programador usou Ash, ele perguntou: "O que é um Resource?" O instrutor respondeu: "É a base de tudo."
O fato por trás da lenda: Ash é um framework declarativo e opinativo para Elixir. Modela domínios através de Resources e Actions. Usado com Phoenix LiveView. Tem cerca de 1.600 estrelas no GitHub.
Gancho: O arquiteto modela. Mas há uma coisa que explora: o Livebook.
Capítulo 48 — Livebook: O Caderno que Executa Código
A lenda diz que o Livebook é um caderno. Mas não é um caderno comum. É um caderno que executa código. Cada célula é um feitiço. Cada execução é uma magia. Você escreve, executa, vê o resultado. O caderno nunca erra. O caderno nunca esquece.
A verdade é que Livebook é uma aplicação web para escrever notebooks de código interativos e colaborativos para Elixir, construída com Phoenix LiveView. Ele apresenta notebooks de código com suporte a Markdown e células de código onde o código Elixir é avaliado sob demanda. Livebook é uma alternativa ao Jupyter para automatizar fluxos de código e dados. Ele oferece colaboração em tempo real, gráficos Vega-Lite, Smart cells e execução reproduzível.
A lenda diz que, na primeira vez que um programador usou Livebook, ele perguntou: "O que é isso?" O instrutor respondeu: "É o caderno que executa."
O fato por trás da lenda: Livebook é uma aplicação web para notebooks interativos e colaborativos para Elixir, construída com Phoenix LiveView. Alternativa ao Jupyter. Suporta Markdown, células de código, gráficos Vega-Lite e Smart cells.
Gancho: O caderno executa. Mas há uma coisa que testa: o Wallaby.
Capítulo 49 — Wallaby: O Fantoche que Testa Navegadores
A lenda diz que o Wallaby é um fantoche. Ele controla navegadores. Ele clica. Ele preenche formulários. Ele verifica textos. Ele testa aplicações Phoenix de ponta a ponta. O fantoche nunca erra. O fantoche nunca se cansa.
A verdade é que Wallaby é uma biblioteca de testes de aceitação para aplicações Phoenix. Ele permite simular um usuário real navegando na aplicação, clicando em links, preenchendo formulários e verificando o conteúdo da página. Wallaby usa o ChromeDriver para controlar um navegador Chrome real ou headless. Ele é usado para testes de integração e end-to-end.
A lenda diz que, na primeira vez que um programador usou Wallaby, ele perguntou: "O que é isso?" O instrutor respondeu: "É o fantoche que testa."
O fato por trás da lenda: Wallaby é uma biblioteca de testes de aceitação para Phoenix. Simula um usuário real navegando. Usa ChromeDriver para controlar um navegador Chrome real ou headless.
Gancho: O fantoche testa. Mas há uma coisa que mocka: o Mox.
Capítulo 50 — Mox: O Ator que Finge Ser Outro
A lenda diz que o Mox é um ator. Ele finge ser outro. Ele interpreta. Ele substitui. Ele mocka. Ele define comportamentos. Ele define expectativas. O ator nunca erra. O ator nunca sai do personagem.
A verdade é que Mox é uma biblioteca de mocking para Elixir. Ela permite definir mocks baseados em behaviours, definir expectativas e verificar se as expectativas foram cumpridas. Mox foi projetado para ser usado com behaviours, garantindo que o mock implemente a mesma interface que o módulo real. Mox é mantido pela Dashbit.
A lenda diz que, na primeira vez que um programador usou Mox, ele perguntou: "O que é um mock?" O instrutor respondeu: "É um ator que finge ser outro."
O fato por trás da lenda: Mox é uma biblioteca de mocking para Elixir. Define mocks baseados em behaviours, expectativas e verificações. Mantida pela Dashbit.
Gancho: O ator finge. Mas há uma coisa que gera dados: o Faker.
Capítulo 51 — Faker: O Mago que Inventa Dados
A lenda diz que o Faker é um mago. Ele inventa dados. Ele cria nomes. Ele cria endereços. Ele cria emails. Ele cria tudo que você precisa para testar. O mago nunca erra. O mago nunca repete.
A verdade é que Faker é uma biblioteca para gerar dados falsos em Elixir. Ela pode gerar nomes, endereços, números de telefone, emails, datas, e muito mais. Faker é usada para popular bancos de dados de teste, gerar dados para seeds e criar fixtures. Faker é mantida pela comunidade.
A lenda diz que, na primeira vez que um programador usou Faker, ele perguntou: "O que é isso?" O instrutor respondeu: "É o mago que inventa dados."
O fato por trás da lenda: Faker gera dados falsos em Elixir. Nomes, endereços, telefones, emails, datas. Usada para testes, seeds e fixtures.
Gancho: O mago inventa. Mas há uma coisa que gera tabelas: o Ecto.Migration.
Capítulo 52 — Ecto.Migration: O Arqueólogo que Escava o Banco
A lenda diz que o Ecto.Migration é um arqueólogo. Ele escava. Ele move. Ele transforma. Ele cria tabelas. Ele altera colunas. Ele nunca perde um fóssil.
A verdade é que migrações são usadas para modificar o schema do banco de dados ao longo do tempo. O módulo Ecto.Migration fornece muitos helpers para migrar o banco de dados, permitindo que desenvolvedores usem Elixir para alterar seu armazenamento de forma database-independent. A função up/0 é responsável por migrar o banco de dados para frente. Por padrão, o Ecto executa todas as migrações dentro de uma transação.
A lenda diz que, na primeira vez que um programador rodou uma migração, ele perguntou: "O que é isso?" O instrutor respondeu: "É o arqueólogo."
O fato por trás da lenda: Ecto.Migration modifica o schema do banco de dados ao longo do tempo. Fornece helpers database-independent. up/0 migra para frente.
Gancho: O arqueólogo escava. Mas há uma coisa que testa o banco: o Ecto.Sandbox.
Capítulo 53 — Ecto.Sandbox: A Caixa de Areia que Isola os Testes
A lenda diz que o Ecto.Sandbox é uma caixa de areia. Cada teste entra na caixa. Cada teste tem seu próprio banco. Cada teste é isolado. Quando o teste termina, a caixa é limpa. O Sandbox nunca erra. O Sandbox nunca mistura.
A verdade é que Ecto.Sandbox é uma biblioteca para testar aplicações Ecto de forma isolada. Ele permite que cada teste rode em uma transação que é revertida ao final, garantindo que os testes não interfiram uns com os outros. O Sandbox suporta múltiplos modos, incluindo :manual e :shared, e é integrado com ExUnit.
A lenda diz que, na primeira vez que um programador usou Sandbox, ele perguntou: "O que é isso?" O instrutor respondeu: "É a caixa de areia."
O fato por trás da lenda: Ecto.Sandbox isola testes de Ecto. Cada teste roda em uma transação revertida ao final. Suporta modos :manual e :shared.
Gancho: A caixa de areia isola. Mas há uma coisa que testa em produção: o PropCheck.
Capítulo 54 — PropCheck: O Feiticeiro que Testa Propriedades
A lenda diz que o PropCheck é um feiticeiro. Ele testa propriedades. Ele gera dados aleatórios. Ele procura contra-exemplos. Ele encolhe casos. Ele nunca desiste. Ele nunca erra.
A verdade é que PropCheck é uma biblioteca de property-based testing para Erlang e Elixir. Ela é uma implementação do QuickCheck, originalmente para Haskell. PropCheck gera dados aleatórios e testa se uma propriedade é verdadeira para todos eles. Se encontrar um contra-exemplo, ele encolhe o caso para o menor exemplo que ainda falha. PropCheck é mantida pela comunidade.
A lenda diz que, na primeira vez que um programador usou PropCheck, ele perguntou: "O que é isso?" O instrutor respondeu: "É o feiticeiro que testa propriedades."
O fato por trás da lenda: PropCheck é uma biblioteca de property-based testing para Erlang e Elixir. Implementação do QuickCheck. Gera dados aleatórios e encolhe contra-exemplos.
Gancho: O feiticeiro testa. Mas há uma coisa que substitui: o Mock.
Capítulo 55 — Mock: O Sósia que Substitui
A lenda diz que o Mock é um sósia. Ele substitui módulos. Ele substitui funções. Ele substitui tudo. Ele é mais antigo que o Mox. Ele é mais simples. Ele nunca erra. Ele nunca reclama.
A verdade é que Mock é uma biblioteca de mocking para Elixir, mais antiga que o Mox. Ela permite substituir módulos e funções em tempo de execução. Mock usa :meck por baixo dos panos. Embora o Mox seja mais recomendado por usar behaviours, o Mock ainda é usado em muitos projetos.
A lenda diz que, na primeira vez que um programador usou Mock, ele perguntou: "O que é isso?" O instrutor respondeu: "É o sósia."
O fato por trás da lenda: Mock é uma biblioteca de mocking mais antiga que o Mox. Substitui módulos e funções em tempo de execução. Usa :meck.
Gancho: O sósia substitui. Mas há uma coisa que registra: o Telemetry.
Capítulo 56 — Telemetry.Metrics: O Contador que Nunca Para
A lenda diz que o Telemetry.Metrics é um contador. Ele conta. Ele conta requisições. Ele conta erros. Ele conta tudo. Ele nunca para. Ele nunca erra.
A verdade é que Telemetry.Metrics é uma biblioteca que fornece uma interface de alto nível para definir métricas baseadas em eventos do Telemetry. Ela permite definir contadores, sumários e distribuições. As métricas podem ser exportadas para diferentes backends, como Prometheus, StatsD e LiveDashboard.
A lenda diz que, na primeira vez que um programador usou Telemetry.Metrics, ele perguntou: "O que é isso?" O instrutor respondeu: "É o contador."
O fato por trás da lenda: Telemetry.Metrics fornece uma interface de alto nível para definir métricas baseadas em eventos do Telemetry. Contadores, sumários e distribuições. Exporta para Prometheus, StatsD e LiveDashboard.
Gancho: O contador conta. Mas há uma coisa que reporta: o PromEx.
Capítulo 57 — PromEx: O Mensageiro que Reporta para Prometheus
A lenda diz que o PromEx é um mensageiro. Ele coleta métricas. Ele reporta para Prometheus. Ele é configurável. Ele é plugável. Ele nunca erra. Ele nunca perde uma métrica.
A verdade é que PromEx é uma biblioteca que fornece métricas para o Prometheus. Ela coleta métricas de Telemetry, Ecto, Phoenix, e outras fontes, e as expõe no formato Prometheus. PromEx é usada em produção por empresas que precisam monitorar aplicações Elixir.
A lenda diz que, na primeira vez que um programador usou PromEx, ele perguntou: "O que é isso?" O instrutor respondeu: "É o mensageiro."
O fato por trás da lenda: PromEx coleta métricas de Telemetry, Ecto, Phoenix e outras fontes e as expõe no formato Prometheus.
Gancho: O mensageiro reporta. Mas há uma coisa que visualiza: o LiveDashboard.
Capítulo 58 — LiveDashboard: O Painel que Mostra Tudo
A lenda diz que o LiveDashboard é um painel. Ele mostra tudo. Métricas. Processos. Memória. Ele é em tempo real. Ele é interativo. Ele nunca erra. Ele nunca dorme.
A verdade é que LiveDashboard é uma biblioteca que fornece um dashboard em tempo real para aplicações Phoenix. Ele usa Phoenix LiveView para renderizar métricas, informações de processos, alocações de memória e muito mais. O LiveDashboard é integrado com Telemetry e é uma ferramenta essencial para monitorar aplicações em produção.
A lenda diz que, na primeira vez que um programador abriu o LiveDashboard, ele perguntou: "O que é isso?" O instrutor respondeu: "É o painel."
O fato por trás da lenda: LiveDashboard fornece um dashboard em tempo real para aplicações Phoenix. Usa Phoenix LiveView. Integrado com Telemetry.
Gancho: O painel mostra. Mas há uma coisa que documenta a API: o OpenApiSpex.
Capítulo 59 — OpenApiSpex: O Escriba que Documenta APIs
A lenda diz que o OpenApiSpex é um escriba. Ele documenta APIs. Ele define schemas. Ele valida requisições. Ele gera especificações OpenAPI. O escriba nunca erra. O escriba nunca esquece um endpoint.
A verdade é que OpenApiSpex é uma biblioteca para construir APIs compatíveis com OpenAPI 3.0 em Elixir. Ela permite definir schemas, validar requisições e respostas, e gerar documentação interativa (Swagger UI). OpenApiSpex é usada para garantir que as APIs sejam bem documentadas e validadas.
A lenda diz que, na primeira vez que um programador usou OpenApiSpex, ele perguntou: "O que é isso?" O instrutor respondeu: "É o escriba."
O fato por trás da lenda: OpenApiSpex constrói APIs compatíveis com OpenAPI 3.0 em Elixir. Define schemas, valida requisições e gera documentação interativa.
Gancho: O escriba documenta. Mas há uma coisa que testa APIs: o ExUnit.
Capítulo 60 — O Fim do Tomo V: O Ecossistema que Nunca Para
A lenda diz que, no fim de tudo, quando todos os tomos forem escritos, o ecossistema Elixir continuará crescendo. Novas bibliotecas surgirão. Novas ferramentas aparecerão. Novos alienígenas chegarão. E a BEAM continuará rodando.
A verdade é que o ecossistema Elixir é vasto e vibrante. Hex, Mix, Ecto, Phoenix, LiveView, Nx, Absinthe, Oban, Broadway, Tesla, Finch, Jason, Swoosh, Bamboo, Guardian, Pow, Ash, Livebook, e milhares de outras bibliotecas. Cada uma resolve um problema. Cada uma tem uma história.
Este foi o Tomo V — O Ecossistema. Sessenta capítulos. Um ecossistema. Mil processos. E um brasileiro que ouviu um sussurro.
No próximo tomo, A Batalha, vamos explorar concorrência, distribuídos, clusters, CAP, e todos os desafios de construir sistemas que nunca caem.
Até lá.
O fato por trás da lenda: O ecossistema Elixir é vasto e vibrante. Hex, Mix, Ecto, Phoenix, LiveView, Nx, Absinthe, Oban, Broadway, Tesla, Finch, Jason, Swoosh, Bamboo, Guardian, Pow, Ash, Livebook, e milhares de outras bibliotecas.
Agora, sério: O ecossistema Elixir é vasto. Hex é o gerenciador de pacotes. Mix é a ferramenta de build. Ecto.Schema mapeia dados. Ecto.Repo define a interface do banco. Phoenix.Router roteia URLs. Phoenix.Controller recebe requisições. Phoenix.View renderiza templates. Phoenix.Channel transmite em tempo real. Nx calcula tensores. Axon treina redes neurais. Bumblebee carrega modelos pré-treinados. Explorer explora dataframes. Scholar ensina ML clássico. Swoosh e Bamboo enviam emails. Guardian e Pow autenticam. Ash modela domínios. Livebook executa notebooks. Wallaby testa navegadores. Mox mocka. Faker inventa dados. Ecto.Migration escava o banco. Ecto.Sandbox isola testes. PropCheck testa propriedades. Mock substitui. Telemetry.Metrics conta. PromEx reporta. LiveDashboard visualiza. OpenApiSpex documenta. As capivaras quânticas não são reais — mas deveriam ser. Este artigo é uma fantasia satírica baseada em fatos. Mantenha o aviso para não enganar ninguém.
Top comments (0)