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 61 a 100
Capítulo 61 — Phoenix.Component: O Legista de Componentes
A lenda diz que o Phoenix.Component é um legista de componentes. Ele examina cada componente. Ele verifica cada atributo. Ele declara a causa da morte quando um componente falha. Ele nunca erra. Ele nunca deixa passar um componente defeituoso.
A verdade é que Phoenix.Component é o módulo que define componentes de função reutilizáveis com templates HEEx. O sigilo ~H significa HEEx (HTML + EEx), uma linguagem de template que mistura HTML com interpolação Elixir. Componentes de função podem aceitar atributos e blocos de conteúdo HEEx, chamados de slots. HEEx é baseado em EEx e foi construído como um motor EEx customizado, usando change tracking para garantir que partes dinâmicas só sejam enviadas ao cliente quando mudam.
A lenda diz que, na primeira vez que um programador criou um componente, ele perguntou: "Isso é uma função?" O instrutor respondeu: "É uma função que retorna HEEx."
O fato por trás da lenda: Phoenix.Component define componentes de função reutilizáveis com templates HEEx. O ~H é o sigilo para HEEx. Componentes aceitam atributos e slots. HEEx usa change tracking para otimizar atualizações.
Gancho: O legista examina. Mas há uma coisa que executa comandos no cliente: o Phoenix.LiveView.JS.
Capítulo 62 — Phoenix.LiveView.JS: O Maestro dos Comandos no Cliente
A lenda diz que o Phoenix.LiveView.JS é um maestro. Ele rege os comandos no navegador. Ele adiciona classes. Ele remove classes. Ele mostra elementos. Ele esconde elementos. Ele nunca erra. Ele nunca desafina.
A verdade é que Phoenix.LiveView.JS fornece comandos para executar operações utilitárias JavaScript no cliente. As utilidades incluem add_class, remove_class, toggle_class, set_attribute, show, hide, toggle, dispatch, push, e focus. Esses comandos são usados em atributos como phx-click, phx-focus, phx-blur para interações do lado do cliente sem escrever JavaScript manualmente.
A lenda diz que, na primeira vez que um programador usou JS.show(), ele perguntou: "Isso é JavaScript?" O instrutor respondeu: "Não. É Elixir que vira JavaScript."
O fato por trás da lenda: Phoenix.LiveView.JS fornece comandos para operações JavaScript no cliente: add_class, remove_class, toggle_class, set_attribute, show, hide, toggle, dispatch, push, focus.
Gancho: O maestro rege. Mas há uma coisa que transmite dados em tempo real: o Phoenix.LiveView.Stream.
Capítulo 63 — Phoenix.LiveView.Stream: O Rio que Não Guarda Água
A lenda diz que o LiveView.Stream é um rio. Ele flui. Ele não guarda água. Ele envia água para o cliente e esquece. Se o cliente quer mais, ele pede. O rio nunca transborda. O rio nunca seca.
A verdade é que LiveView.Stream é um mecanismo para gerenciar coleções grandes no LiveView sem mantê-las na memória do servidor. Itens são enviados ao cliente e não retidos no servidor. stream_insert e stream_delete atualizam elementos DOM individuais sem manter a coleção no lado do servidor. Streams são usados para coleções grandes ou que crescem ao longo da vida do socket.
A lenda diz que, na primeira vez que um programador usou um stream, ele perguntou: "Onde estão os dados?" O instrutor respondeu: "No cliente. O servidor esqueceu."
O fato por trás da lenda: LiveView.Stream gerencia coleções grandes sem mantê-las na memória do servidor. Itens são enviados ao cliente e não retidos. stream_insert e stream_delete atualizam o DOM individualmente.
Gancho: O rio flui. Mas há uma coisa que envia arquivos: o Phoenix.LiveView.Upload.
Capítulo 64 — Phoenix.LiveView.Upload: O Carteiro que Entrega Arquivos
A lenda diz que o LiveView.Upload é um carteiro. Ele recebe arquivos. Ele verifica o tipo. Ele verifica o tamanho. Ele entrega ao servidor. Ele nunca perde uma encomenda. Ele nunca aceita um pacote proibido.
A verdade é que LiveView.Upload permite uploads de arquivos diretamente para o LiveView, com suporte a validação de tipo, tamanho e número de arquivos. Uploads são escritos em arquivos temporários no servidor e consumidos pelo LiveView. Para casos de uso que exigem tratamento customizado dos chunks, como streaming para outro servidor, existe o Phoenix.LiveView.UploadWriter.
A lenda diz que, na primeira vez que um programador usou upload, ele perguntou: "Onde estão os arquivos?" O instrutor respondeu: "No servidor. Mas o LiveView não esqueceu."
O fato por trás da lenda: LiveView.Upload permite uploads com validação de tipo, tamanho e número. Arquivos são escritos em arquivos temporários no servidor. UploadWriter permite tratamento customizado.
Gancho: O carteiro entrega. Mas há uma coisa que conecta o cliente ao servidor: o Phoenix.LiveView.Hook.
Capítulo 65 — Phoenix.LiveView.Hook: A Ponte Entre Dois Mundos
A lenda diz que o LiveView.Hook é uma ponte. Ele conecta o cliente ao servidor. Ele recebe eventos do servidor. Ele envia eventos para o servidor. Ele nunca cai. Ele nunca deixa ninguém preso.
A verdade é que LiveView.Hook é um mecanismo que permite escrever JavaScript no cliente para interagir com o LiveView no servidor. Hooks são objetos JavaScript que lidam com JavaScript customizado quando o servidor adiciona, atualiza ou remove um elemento. Eles incluem métodos para enviar eventos do cliente para o servidor (pushEventTo) e lidar com eventos enviados do servidor (handleEvent). Hooks são usados quando você precisa de interações complexas no cliente que o LiveView não cobre nativamente.
A lenda diz que, na primeira vez que um programador usou um hook, ele perguntou: "Isso é JavaScript?" O instrutor respondeu: "Sim. Mas é JavaScript que conversa com Elixir."
O fato por trás da lenda: LiveView.Hook permite escrever JavaScript no cliente para interagir com o LiveView. Hooks enviam eventos para o servidor (pushEventTo) e lidam com eventos do servidor (handleEvent).
Gancho: A ponte conecta. Mas há uma coisa que rastreia presenças: o Phoenix.Presence.
Capítulo 66 — Phoenix.Presence: O Vigia que Sabe Quem Está Online
A lenda diz que o Phoenix.Presence é um vigia. Ele sabe quem está online. Ele sabe quando alguém entra. Ele sabe quando alguém sai. Ele replica essa informação para todos os nós do cluster. O vigia nunca dorme. O vigia nunca esquece.
A verdade é que Phoenix.Presence fornece rastreamento de presença para processos e canais. É um behaviour que fornece recursos como buscar presenças para um tópico e lidar com diffs de eventos de join e leave em tempo real. Usar este módulo define um supervisor e permite que o módulo chamador implemente o behaviour Phoenix.Tracker, que inicia um processo tracker para lidar com informações de presença. Presence.track registra o processo do canal como presença para o ID do usuário do socket, com um mapa de metadados.
A lenda diz que, na primeira vez que um programador usou Presence, ele perguntou: "Como isso funciona em cluster?" O instrutor respondeu: "PubSub."
O fato por trás da lenda: Phoenix.Presence fornece rastreamento de presença para processos e canais. Define um supervisor e usa Phoenix.Tracker com Phoenix.PubSub para broadcast de atualizações de presença.
Gancho: O vigia rastreia. Mas há uma coisa que agrupa operações: o Ecto.Multi.
Capítulo 67 — Ecto.Multi: O Maestro de Transações
A lenda diz que o Ecto.Multi é um maestro. Ele agrupa operações. Ele executa todas ou nenhuma. Se uma falha, todas as outras são revertidas. O maestro nunca erra. O maestro nunca deixa uma transação pela metade.
A verdade é que Ecto.Multi é uma estrutura de dados para agrupar múltiplas operações de Repo. Ele torna possível empacotar operações que devem ser realizadas em uma única transação de banco de dados e dá uma maneira de introspectar as operações enfileiradas sem realmente executá-las. Se o Multi contém operações que usam changesets, o Ecto primeiro verifica se todos os changesets são válidos.
A lenda diz que, na primeira vez que um programador usou Multi, ele perguntou: "O que acontece se uma operação falhar?" O instrutor respondeu: "Todas são revertidas."
O fato por trás da lenda: Ecto.Multi agrupa múltiplas operações de Repo em uma única transação. Se uma falhar, todas são revertidas. Changesets são validados antes da execução.
Gancho: O maestro agrupa. Mas há uma coisa que define tipos enumerados: o Ecto.Enum.
Capítulo 68 — Ecto.Enum: O Tradutor de Valores
A lenda diz que o Ecto.Enum é um tradutor. Ele traduz átomos para strings. Ele traduz strings para átomos. Ele garante que apenas valores permitidos sejam usados. O tradutor nunca erra. O tradutor nunca mente.
A verdade é que Ecto.Enum é um tipo que mapeia átomos Elixir para valores no banco de dados. Ele permite definir um campo como enum, com uma lista de valores permitidos. Por exemplo, field :status, Ecto.Enum, values: [:active, :inactive]. O Ecto.Enum garante que apenas os valores definidos possam ser usados, tanto na leitura quanto na escrita.
A lenda diz que, na primeira vez que um programador usou Ecto.Enum, ele perguntou: "O que acontece se eu passar um valor inválido?" O instrutor respondeu: "O changeset rejeita."
O fato por trás da lenda: Ecto.Enum mapeia átomos Elixir para valores no banco de dados. Define valores permitidos. Apenas valores definidos podem ser usados.
Gancho: O tradutor traduz. Mas há uma coisa que embute estruturas: o Ecto.Embedded.
Capítulo 69 — Ecto.Embedded: O Arquiteto de Estruturas Aninhadas
A lenda diz que o Ecto.Embedded é um arquiteto. Ele constrói estruturas aninhadas. Ele embute um schema dentro de outro. Ele permite que você guarde mapas complexos em um único campo. O arquiteto nunca erra. O arquiteto nunca deixa uma estrutura solta.
A verdade é que Ecto.Embedded permite embutir um schema dentro de outro. Embeds são usados para armazenar estruturas de dados complexas em um único campo do banco de dados, geralmente como JSONB no PostgreSQL. embeds_one embute um único schema, enquanto embeds_many embute uma lista de schemas. Embeds são úteis para dados que não precisam de uma tabela separada.
A lenda diz que, na primeira vez que um programador usou um embed, ele perguntou: "Isso é uma associação?" O instrutor respondeu: "Não. É um embed. A estrutura mora dentro de outra."
O fato por trás da lenda: Ecto.Embedded permite embutir um schema dentro de outro. embeds_one embute um único schema; embeds_many embute uma lista. Usado para estruturas complexas em um único campo.
Gancho: O arquiteto constrói. Mas há uma coisa que guarda cache: o Cachex.
Capítulo 70 — Cachex: O Cofre que Guarda Tudo
A lenda diz que o Cachex é um cofre. Ele guarda tudo. Ele guarda chaves. Ele guarda valores. Ele expira. Ele coleta estatísticas. Ele transaciona. O cofre nunca perde nada. O cofre nunca deixa ninguém esperando.
A verdade é que Cachex é um armazenamento de chave/valor em memória extremamente rápido, com suporte a muitas funcionalidades úteis: expirações baseadas em tempo, hooks de pré/pós-execução, coleta de estatísticas, cache multi-camadas com fallbacks, distribuição para nós remotos, transações e row locking. Cachex é mantido por Isaac Whitfield.
A lenda diz que, na primeira vez que um programador usou Cachex, ele perguntou: "Onde estão os dados?" O instrutor respondeu: "Na memória. Rápido."
O fato por trás da lenda: Cachex é um armazenamento de chave/valor em memória extremamente rápido. Suporta expirações, hooks, estatísticas, multi-camadas, distribuição, transações e row locking.
Gancho: O cofre guarda. Mas há uma coisa que limita: o Hammer.
Capítulo 71 — Hammer: O Guarda de Trânsito que Limita Requisições
A lenda diz que o Hammer é um guarda de trânsito. Ele conta quantas vezes você passou. Se você passar demais, ele te bloqueia. Ele usa um balde de tokens. Ele nunca erra. Ele nunca deixa passar um abusador.
A verdade é que Hammer é uma biblioteca de rate-limiting para Elixir com backends de armazenamento plugáveis. Hammer permite definir limites de ações realizadas dentro de intervalos de tempo especificados, aplicando limites por usuário ou globais em requisições de API, uploads de arquivos e mais. Hammer usa o algoritmo Token Bucket para contar o número de ações que ocorrem em um "bucket". O backend padrão é ETS.
A lenda diz que, na primeira vez que um programador usou Hammer, ele perguntou: "O que é um balde de tokens?" O instrutor respondeu: "É um balde com tokens. Cada requisição gasta um token. Quando acaba, você espera."
O fato por trás da lenda: Hammer é uma biblioteca de rate-limiting com backends plugáveis. Usa o algoritmo Token Bucket. O backend padrão é ETS.
Gancho: O guarda limita. Mas há uma coisa que ativa funcionalidades: o FunWithFlags.
Capítulo 72 — FunWithFlags: O Interruptor que Liga e Desliga Funcionalidades
A lenda diz que o FunWithFlags é um interruptor. Ele liga funcionalidades. Ele desliga funcionalidades. Ele ativa para alguns usuários. Ele ativa para grupos. Ele nunca erra. Ele nunca deixa uma funcionalidade presa.
A verdade é que FunWithFlags é uma biblioteca de feature toggle para Elixir. É uma aplicação OTP que fornece um armazenamento de dois níveis para salvar e recuperar feature flags, uma API Elixir para alternar e consultar, e um dashboard web como painel de controle. FunWithFlags usa Redis ou Ecto para persistência, um cache ETS para velocidade e PubSub para cache distribuído. As gates incluem Boolean Gate, Actor Gate e Group Gate.
A lenda diz que, na primeira vez que um programador usou FunWithFlags, ele perguntou: "Como eu ativo para 50% dos usuários?" O instrutor respondeu: "Use a gate de porcentagem."
O fato por trás da lenda: FunWithFlags é uma biblioteca de feature toggle com armazenamento de dois níveis (Redis/Ecto + ETS) e PubSub para cache distribuído. Gates incluem Boolean, Actor e Group.
Gancho: O interruptor ativa. Mas há uma coisa que processa sinais: o NxSignal.
Capítulo 73 — NxSignal: O Feiticeiro que Lê Ondas
A lenda diz que o NxSignal é um feiticeiro. Ele lê ondas. Ele aplica Fourier. Ele filtra. Ele transforma. Ele nunca erra. Ele nunca perde uma frequência.
A verdade é que NxSignal é uma biblioteca de DSP (Digital Signal Processing) com Nx. Ela fornece ferramentas para uma abordagem mais clássica de lidar com séries temporais, através de Transformadas de Fourier, filtros FIR, filtros IIR e ferramentas matemáticas similares. NxSignal foi criado por Paulo Valente.
A lenda diz que, na primeira vez que um programador usou NxSignal, ele perguntou: "O que é uma Transformada de Fourier?" O instrutor respondeu: "É uma forma de ver o mundo em frequências."
O fato por trás da lenda: NxSignal é uma biblioteca de DSP com Nx. Fornece Transformadas de Fourier, filtros FIR e IIR. Foi criado por Paulo Valente.
Gancho: O feiticeiro lê ondas. Mas há uma coisa que constrói aplicações nativas: o LiveView Native.
Capítulo 74 — LiveView Native: A Janela para o Mundo Nativo
A lenda diz que o LiveView Native é uma janela. Ele mostra a mesma LiveView em um navegador. Ele mostra a mesma LiveView em um aplicativo iOS. Ele mostra a mesma LiveView em um aplicativo Android. Ele nunca erra. Ele nunca se perde entre plataformas.
A verdade é que LiveView Native é uma plataforma para construir aplicações nativas usando Elixir e Phoenix LiveView. Ele permite que uma única LiveView sirva tanto clientes web quanto não-web, transformando código de template específico da plataforma em UIs nativas. O projeto está em desenvolvimento ativo, com suporte para iOS e planos para Android.
A lenda diz que, na primeira vez que um programador usou LiveView Native, ele perguntou: "Preciso escrever Swift?" O instrutor respondeu: "Não. Escreva Elixir. O resto é com o LiveView Native."
O fato por trás da lenda: LiveView Native permite construir aplicações nativas com Elixir e Phoenix LiveView. Uma única LiveView serve clientes web e não-web, transformando templates em UIs nativas.
Gancho: A janela mostra. Mas há uma coisa que roda em dispositivos embarcados: o Nerves.
Capítulo 75 — Nerves: O Construtor de Firmware
A lenda diz que o Nerves é um construtor. Ele constrói firmware. Ele constrói imagens. Ele constrói dispositivos. Ele usa a BEAM. Ele usa Elixir. Ele nunca erra. Ele nunca deixa um dispositivo brickado.
A verdade é que Nerves fornece ferramentas e bibliotecas para construir imagens de software que rodam em sistemas embarcados. Ele usa a máquina virtual Erlang e traz a experiência de desenvolvimento do Elixir para microcomputadores. Nerves é um conjunto de componentes que trabalham juntos para criar firmware reproduzível usando a linguagem Elixir. Ele não usa sistemas init embarcados como systemd ou BusyBox; em vez disso, a própria BEAM é o sistema init.
A lenda diz que, na primeira vez que um programador usou Nerves, ele perguntou: "Onde está o sistema operacional?" O instrutor respondeu: "A BEAM é o sistema operacional."
O fato por trás da lenda: Nerves constrói firmware reproduzível com Elixir e a BEAM. Usa a BEAM como sistema init em vez de systemd ou BusyBox.
Gancho: O construtor constrói. Mas há uma coisa que roda em microcontroladores: o AtomVM.
Capítulo 76 — AtomVM: A BEAM que Cabe na Palma da Mão
A lenda diz que o AtomVM é uma BEAM em miniatura. Ele roda em microcontroladores. Ele roda com 32 KB de RAM. Ele roda Elixir. Ele roda Erlang. Ele roda Gleam. Ele nunca erra. Ele nunca explode.
A verdade é que AtomVM é uma implementação leve da Erlang VM que pode rodar em ambientes restritos, como microcontroladores com apenas algumas centenas de kilobytes de memória, como ESP32, STM32 ou Raspberry Pi Pico. AtomVM é uma implementação from-scratch da Bogdan Erlang Abstract Machine (BEAM) projetada especificamente para rodar em sistemas pequenos. Ele pode rodar em apenas 32 KiB de RAM. AtomVM foi criado por Davide Bettio em 2017.
A lenda diz que, na primeira vez que um programador rodou Elixir em um ESP32, ele perguntou: "Isso é possível?" O instrutor respondeu: "Com AtomVM, sim."
O fato por trás da lenda: AtomVM é uma implementação leve da Erlang VM para microcontroladores como ESP32, STM32 e Raspberry Pi Pico. Pode rodar em 32 KiB de RAM. Criado por Davide Bettio em 2017.
Gancho: A BEAM em miniatura roda. Mas há uma coisa que testa tudo: o ExUnit.
Capítulo 77 — ExUnit (Parte 4): O Tribunal que Nunca Dorme
A lenda diz que o ExUnit é um tribunal. Cada teste é um julgamento. Cada assert é uma sentença. Se o código passa, ele é absolvido. Se falha, é condenado.
A verdade é que ExUnit é o framework de testes unitários do Elixir. Ele fornece assert, refute, assert_raise, assert_receive e outras macros para escrever testes. Testes são organizados em módulos que usam ExUnit.Case. ExUnit é integrado ao Mix, então você roda mix test para executar todos os testes.
A lenda diz que, na primeira vez que um programador rodou mix test, ele perguntou: "Quantos testes eu preciso?" O instrutor respondeu: "Todos."
O fato por trás da lenda: ExUnit é o framework de testes unitários do Elixir. Fornece assert, refute, assert_raise, assert_receive. Testes usam ExUnit.Case.
Gancho: O tribunal julga. Mas há uma coisa que documenta: o ExDoc.
Capítulo 78 — ExDoc (Parte 5): O Papagaio que Nunca se Cala
A lenda diz que o ExDoc é um papagaio. Ele lê seus @doc e repete em voz alta. Se você não escrever nada, ele fica quieto e gera uma página em branco. O mix docs é o comando para alimentar o papagaio com sementes.
A verdade é que ExDoc é a ferramenta oficial de geração de documentação do Elixir. Ela lê os atributos @doc e @moduledoc e gera documentação HTML navegável. ExDoc é usado por praticamente todos os projetos Elixir.
A lenda diz que, na primeira vez que um programador rodou mix docs, ele perguntou: "Onde está a documentação?" O instrutor respondeu: "Na pasta doc."
O fato por trás da lenda: ExDoc é a ferramenta oficial de geração de documentação do Elixir. Lê @doc e @moduledoc e gera HTML.
Gancho: O papagaio documenta. Mas há uma coisa que analisa: o Dialyzer.
Capítulo 79 — Dialyzer (Parte 5): O Detector que Nunca se Cansa
A lenda diz que o Dialyzer é um detector de mentiras. Quando encontra um any(), ele chora copiosamente e se recusa a continuar.
A verdade é que Dialyzer é uma ferramenta de análise estática para bytecode da BEAM. Ele fornece avisos sobre tipos incompatíveis, código inalcançável e outros problemas comuns.
A lenda diz que, na primeira vez que um programador rodou o Dialyzer, ele perguntou: "Por que está chorando?" O instrutor respondeu: "Porque você tem any() no código."
O fato por trás da lenda: Dialyzer é uma ferramenta de análise estática para bytecode da BEAM. Fornece avisos sobre tipos incompatíveis e código inalcançável.
Gancho: O detector analisa. Mas há uma coisa que formata: o mix format.
Capítulo 80 — Mix Format (Parte 4): O Cabeleireiro que Nunca Erra
A lenda diz que o mix format arruma seu código com pomada de unicórnio. Se você não rodar, seu código fica com o cabelo bagunçado e o compilador zomba.
A verdade é que mix format é a ferramenta oficial de formatação de código do Elixir. Ela usa um formatador opinativo que garante consistência de estilo em toda a comunidade.
A lenda diz que, na primeira vez que um programador rodou mix format, ele perguntou: "Posso escolher o estilo?" O instrutor respondeu: "Não. O estilo é opinativo."
O fato por trás da lenda: mix format é a ferramenta oficial de formatação. Usa um formatador opinativo.
Gancho: O cabeleireiro formata. Mas há uma coisa que compila: o mix compile.
Capítulo 81 — Mix Compile (Parte 4): O DJ que Nunca Para
A lenda diz que o mix compile não compila. Ele toca uma música. No final, seu código está compilado.
A verdade é que mix compile é a tarefa do Mix que compila o código-fonte do projeto. Ela verifica dependências, compila os arquivos .ex e .exs e gera os arquivos .beam.
A lenda diz que, na primeira vez que um programador rodou mix compile, ele perguntou: "Onde está o binário?" O instrutor respondeu: "Na pasta _build."
O fato por trás da lenda: mix compile compila o código-fonte do projeto, gerando arquivos .beam na pasta _build.
Gancho: O DJ compila. Mas há uma coisa que baixa pacotes: o Hex.
Capítulo 82 — Hex (Parte 7): O Feitiço que Nunca Falha
A lenda diz que o Hex é um feitiço. Quando você roda mix hex.info, um sapo aparece no terminal e pergunta se você aceita os termos de uso.
A verdade é que Hex é o gerenciador de pacotes oficial do ecossistema BEAM. Ele foi iniciado em 2013 por Eric Meadows-Jönsson e serve tanto Elixir quanto Erlang.
A lenda diz que, na primeira vez que um programador publicou um pacote, ele perguntou: "Posso despublicar?" O instrutor respondeu: "Pode. Mas cuidado. O sapo lembra."
O fato por trás da lenda: Hex é o gerenciador de pacotes oficial do ecossistema BEAM, iniciado em 2013 por Eric Meadows-Jönsson.
Gancho: O feitiço invoca. Mas há uma coisa que observa: o Telemetry.
Capítulo 83 — Telemetry (Parte 4): O Olho que Nunca Fecha
A lenda diz que o Telemetry é um olho. Ele mede tudo: requisições, queries, erros. E o LiveDashboard mostra tudo em tempo real.
A verdade é que Telemetry é uma biblioteca de instrumentação para Elixir e Erlang. O Phoenix integra a Telemetry para medir métricas de Phoenix, Ecto e VM.
A lenda diz que, na primeira vez que um programador usou Telemetry, ele perguntou: "O que posso medir?" O instrutor respondeu: "Tudo."
O fato por trás da lenda: Telemetry é uma biblioteca de instrumentação para Elixir e Erlang. O Phoenix integra a Telemetry para medir métricas.
Gancho: O olho observa. Mas há uma coisa que registra: o Logger.
Capítulo 84 — Logger (Parte 3): O Diário que Nunca Esquece
A lenda diz que o Logger é um diário secreto. Ele registra tudo. Cada mensagem. Cada erro. Cada aviso.
A verdade é que Logger é o módulo de logging do Elixir. Ele fornece funções como Logger.debug/2, Logger.info/2, Logger.warn/2, Logger.error/2.
A lenda diz que, na primeira vez que um programador usou Logger.info, ele perguntou: "Onde está o log?" O instrutor respondeu: "No diário."
O fato por trás da lenda: Logger é o módulo de logging do Elixir. Fornece Logger.debug/2, Logger.info/2, Logger.warn/2, Logger.error/2.
Gancho: O diário registra. Mas há uma coisa que conecta nós: o Libcluster.
Capítulo 85 — Libcluster (Parte 6): O Feitiço que Nunca Se Desfaz
A lenda diz que, para formar um cluster Elixir, você precisa de magia. Você roda libcluster e, de repente, todos os nós se encontram.
A verdade é que Libcluster fornece um mecanismo para formar automaticamente clusters de nós Erlang, com adesão estática ou dinâmica.
A lenda diz que, na primeira vez que um programador usou Libcluster, ele perguntou: "Como isso funciona?" O instrutor respondeu: "Magia com estratégia."
O fato por trás da lenda: Libcluster forma clusters de nós Erlang automaticamente, com adesão estática ou dinâmica.
Gancho: O feitiço junta. Mas há uma coisa que explica os limites: o Teorema CAP.
Capítulo 86 — CAP (Parte 5): O Teorema que Nunca Mente
A lenda diz que, quando os aliens criaram a BEAM, eles leram o Teorema CAP e disseram: "Vamos escolher AP."
A verdade é que a maioria das bibliotecas distribuídas do Elixir fica do lado AP do Teorema CAP. O Paxtor é uma biblioteca CP que usa Paxos.
A lenda diz que, na primeira vez que um programador ouviu falar do CAP, ele perguntou: "Qual lado é melhor?" O instrutor respondeu: "Depende do que você não pode perder."
O fato por trás da lenda: A maioria das bibliotecas distribuídas do Elixir fica do lado AP. O Paxtor é CP.
Gancho: O teorema explica. Mas há uma coisa que a BEAM faz melhor: tolerância a falhas.
Capítulo 87 — Tolerância a Falhas (Parte 6): A Filosofia que Nunca Morre
A lenda diz que, num benchmark acadêmico, o Elixir atingiu o maior throughput e a menor variabilidade sob condições de falha.
A verdade é que a tolerância a falhas da BEAM é um dos seus pontos mais fortes. Processos isolados, supervisores, árvores de supervisão, "let it crash".
A lenda diz que, na primeira vez que um programador viu um sistema se recuperar sozinho, ele perguntou: "Como?" O instrutor respondeu: "Supervisores."
O fato por trás da lenda: A tolerância a falhas da BEAM é um dos seus pontos mais fortes.
Gancho: A tolerância é a base. Mas há uma coisa que mantém os processos vivos: os supervisores.
Capítulo 88 — Supervisor (Parte 7): As Babás que Nunca Dormem
A lenda diz que os supervisores são babás. Se um processo morre, a babá chora, pega um novo processo no berçário e coloca no lugar.
A verdade é que supervisores monitoram processos filhos e os reiniciam quando falham. Formam árvores de supervisão.
A lenda diz que, na primeira vez que um programador viu uma árvore de supervisão, ele perguntou: "Quantos níveis?" O instrutor respondeu: "Quantos você precisar."
O fato por trás da lenda: Supervisores monitoram processos filhos e os reiniciam quando falham. Formam árvores de supervisão.
Gancho: As babás cuidam. Mas há um processo que serve: o GenServer.
Capítulo 89 — GenServer (Parte 7): O Mordomo que Nunca Para
A lenda diz que um GenServer é um mordomo. Quando você chama GenServer.call, ele responde "Pois não, senhor".
A verdade é que GenServer é um comportamento do OTP para construir servidores genéricos. Encapsula estado e concorrência.
A lenda diz que, na primeira vez que um programador criou um GenServer, ele perguntou: "Preciso implementar tudo?" O instrutor respondeu: "Só os callbacks."
O fato por trás da lenda: GenServer é um comportamento do OTP para construir servidores genéricos. Encapsula estado e concorrência.
Gancho: O mordomo serve. Mas há uma coisa que persiste: o Ecto.
Capítulo 90 — Ecto (Parte 8): O Fantasma que Nunca Desaparece
A lenda diz que Ecto é um fantasma. Cada Repo.insert é um exorcismo.
A verdade é que Ecto é uma biblioteca de persistência para Elixir. Fornece mapeamento, migrações, queries e transações.
A lenda diz que, na primeira vez que um programador usou Ecto, ele perguntou: "Isso é um ORM?" O instrutor respondeu: "Não. É uma biblioteca de persistência."
O fato por trás da lenda: Ecto é uma biblioteca de persistência para Elixir. Fornece mapeamento, migrações, queries e transações.
Gancho: O fantasma persiste. Mas há uma coisa que conecta tudo: o Phoenix.
Capítulo 91 — Phoenix (Parte 8): A Fênix que Nunca Morre
A lenda diz que Phoenix é um framework web que invoca uma fênix de verdade.
A verdade é que Phoenix é um framework web para Elixir, criado por Chris McCord e lançado em 28 de agosto de 2015.
A lenda diz que, na primeira vez que um programador rodou mix phx.server, ele perguntou: "Onde está a fênix?" O instrutor respondeu: "No Arizona."
O fato por trás da lenda: Phoenix é um framework web para Elixir, criado por Chris McCord e lançado em 28 de agosto de 2015.
Gancho: A fênix constrói. Mas há uma coisa que conecta usuários: o LiveView.
Capítulo 92 — LiveView (Parte 8): A Janela que Nunca Fecha
A lenda diz que, na primeira vez que alguém rodou uma LiveView, uma janela para outra dimensão se abriu.
A verdade é que Phoenix LiveView permite construir aplicações interativas renderizadas no servidor sem JavaScript. Versão 1.0 em 3 de dezembro de 2024.
A lenda diz que, na primeira vez que um programador viu uma LiveView, ele perguntou: "Onde está o JavaScript?" O instrutor respondeu: "Não tem."
O fato por trás da lenda: Phoenix LiveView permite construir aplicações interativas renderizadas no servidor sem JavaScript. Versão 1.0 em 3 de dezembro de 2024.
Gancho: A janela interage. Mas há uma coisa que calcula: o Nx.
Capítulo 93 — Nx (Parte 4): A Calculadora que Nunca Erra
A lenda diz que o Nx é uma calculadora que pensa em tensores.
A verdade é que Nx é uma biblioteca de arrays multidimensionais (tensores) e definições numéricas para 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.
Gancho: A calculadora calcula. Mas há uma coisa que treina: o Axon.
Capítulo 94 — Axon (Parte 2): O Treinador que Nunca Desiste
A lenda diz que o Axon é um treinador de redes neurais.
A verdade é que Axon é uma biblioteca para criar e treinar redes neurais em Elixir, construída sobre o Nx.
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.
Gancho: O treinador treina. Mas há uma coisa que carrega modelos: o Bumblebee.
Capítulo 95 — Bumblebee (Parte 2): A Abelha que Nunca Cansa
A lenda diz que o Bumblebee é uma abelha que carrega modelos pré-treinados.
A verdade é que Bumblebee fornece modelos de redes neurais pré-treinados sobre o Axon, com integração com o Hugging Face.
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.
Gancho: A abelha carrega. Mas há uma coisa que explora dados: o Explorer.
Capítulo 96 — Explorer (Parte 2): O Detetive que Nunca Desiste
A lenda diz que o Explorer é um detetive que investiga dataframes.
A verdade é que Explorer traz séries e dataframes para exploração de dados em Elixir. É 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. Escrito em Rust.
Gancho: O detetive investiga. Mas há uma coisa que aprende: o Scholar.
Capítulo 97 — Scholar (Parte 2): O Professor que Nunca se Confunde
A lenda diz que o Scholar é um professor de machine learning clássico.
A verdade é que Scholar implementa ferramentas de machine learning tradicional sobre Nx. Classificação, regressão, clustering, redução de dimensionalidade, métricas e pré-processamento.
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. Comparável ao scikit-learn.
Gancho: O professor ensina. Mas há uma coisa que envia emails: o Swoosh.
Capítulo 98 — Swoosh (Parte 2): O Carteiro que Nunca Perde uma Carta
A lenda diz que o Swoosh é um carteiro que entrega emails.
A verdade é que Swoosh é uma biblioteca para compor, entregar e testar emails em Elixir. Vem com 12 adapters.
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.
Gancho: O carteiro entrega. Mas há uma coisa que também entrega: o Bamboo.
Capítulo 99 — Bamboo (Parte 2): O Panda que Nunca Desiste
A lenda diz que o Bamboo é um panda que também entrega emails.
A verdade é que Bamboo é uma biblioteca de email baseada em adapters para Elixir. Separa criação e envio.
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.
Gancho: O panda entrega. Mas há uma coisa que autentica: o Guardian.
Capítulo 100 — 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. Cem 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.Multi agrupa transações. Ecto.Enum mapeia átomos. Ecto.Embedded embute estruturas. Cachex guarda em memória. Hammer limita requisições. FunWithFlags ativa funcionalidades. NxSignal processa sinais. LiveView Native constrói aplicações nativas. Nerves constrói firmware. AtomVM roda em microcontroladores. Phoenix.Component define componentes. Phoenix.LiveView.JS executa comandos no cliente. LiveView.Stream gerencia coleções grandes. LiveView.Upload envia arquivos. LiveView.Hook conecta cliente e servidor. Phoenix.Presence rastreia presenças. 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)