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 VII: As Ferramentas
Capítulos 31 a 55
(Continuação direta do Tomo VII — As Ferramentas, após o Capítulo 30 — Libcluster)
Capítulo 31 — Observer CLI: A Janela que Não Tem Janela
A lenda diz que o observer_cli é uma janela. Mas não tem janela. Ele vive no terminal. Ele mostra tudo. Memória. Processos. Alocadores. Nós. Árvores de supervisão. Ele é o Observer para quem não tem GUI. Ele nunca dorme. Ele nunca reclama.
A verdade é que observer_cli é uma ferramenta que visualiza nós Erlang/Elixir na linha de comando. Ele é baseado no recon e inspeciona sistemas Erlang e Elixir vivos através de duas interfaces explícitas: a CLI e saída JSON. Ele pode inspecionar memória, alocadores, um processo, uma porta Erlang, uma árvore de supervisão ou estado OTP limitado. Ele é production-ready para operadores e tem cerca de 1.380 estrelas no GitHub.
A lenda diz que, na primeira vez que um programador usou o observer_cli, ele perguntou: "Onde está a GUI?" O instrutor respondeu: "Não tem. É CLI. Mas mostra tudo."
O fato por trás da lenda: observer_cli visualiza nós Erlang/Elixir na linha de comando. É baseado no recon. Inspeciona memória, alocadores, processos, portas e árvores de supervisão. É production-ready. Cerca de 1.380 estrelas no GitHub.
Gancho: A janela mostra. Mas há uma coisa que observa pelo navegador: o Wobserver.
Capítulo 32 — Wobserver: O Observador que Mora na Web
A lenda diz que o Wobserver é um observador. Mas não é um observador comum. Ele mora na web. Ele tem uma interface. Ele tem gráficos. Ele tem métricas. Ele pode ser montado em uma aplicação Phoenix. Ele pode ser conectado ao Prometheus. Ele nunca dorme. Ele nunca reclama.
A verdade é que Wobserver é uma ferramenta de métricas, monitoramento e observação baseada na web. Ele fornece monitoramento drop-in através de uma interface web. Ele pode ser integrado a uma aplicação Phoenix ou outro aplicativo web através do modo plug (que previne a inicialização de um servidor web separado). Ele pode ser montado em um endpoint Phoenix e conectado ao Prometheus.
A lenda diz que, na primeira vez que um programador usou o Wobserver, ele perguntou: "Onde está a interface?" O instrutor respondeu: "Na web. E ela é bonita."
O fato por trás da lenda: Wobserver é uma ferramenta de métricas, monitoramento e observação baseada na web. Fornece monitoramento drop-in e pode ser integrado a uma aplicação Phoenix através do modo plug. Pode ser conectado ao Prometheus.
Gancho: O observador observa. Mas há uma coisa que rastreia: o recon.
Capítulo 33 — Recon: O Detetive que Diagnostica em Produção
A lenda diz que o recon é um detetive. Ele diagnostica. Ele investiga. Ele encontra o problema. Ele trabalha em produção. Ele não para o sistema. Ele não derruba nada. Ele é seguro. Ele é poderoso.
A verdade é que recon é uma biblioteca de ferramentas de diagnóstico para uso em produção. Ela fornece facilidades de tracing production-safe, análise de memória, inspeção de processos, e muito mais. O recon tem cerca de 1.327 estrelas no GitHub e mais de 89,7 milhões de downloads. Ele é mantido por Ferd (Fred Hébert) e é usado por praticamente todos os projetos Elixir/Erlang que precisam de diagnóstico em produção.
A lenda diz que, na primeira vez que um programador usou recon, ele perguntou: "Posso usar em produção?" O instrutor respondeu: "Pode. É para isso que ele existe."
O fato por trás da lenda: recon é uma biblioteca de ferramentas de diagnóstico para uso em produção. Fornece tracing production-safe, análise de memória e inspeção de processos. Cerca de 1.327 estrelas no GitHub. Mantido por Ferd (Fred Hébert).
Gancho: O detetive diagnostica. Mas há uma coisa que rastreia chamadas: o recon_trace.
Capítulo 34 — recon_trace: O Rastreador que Nunca Derruba o Sistema
A lenda diz que o recon_trace é um rastreador. Ele rastreia chamadas de função. Ele mostra os argumentos. Ele mostra os resultados. Ele nunca derruba o sistema. Ele nunca enche o disco. Ele é production-safe. Ele é seguro.
A verdade é que recon_trace é uma ferramenta de tracing production-safe que faz parte da biblioteca recon. Ela fornece uma maneira segura de debugar sistemas BEAM vivos. Você dá a ela um módulo, uma função e uma aridade, e o número máximo de traces que você quer (isso previne que você acidentalmente sobrecarregue o sistema). O Twine é um wrapper Elixir para recon_trace que torna o tracing mais fácil em sistemas Elixir.
A lenda diz que, na primeira vez que um programador usou recon_trace, ele perguntou: "Isso vai derrubar o sistema?" O instrutor respondeu: "Não. É production-safe."
O fato por trás da lenda: recon_trace é uma ferramenta de tracing production-safe. Fornece uma maneira segura de debugar sistemas BEAM vivos. O Twine é um wrapper Elixir.
Gancho: O rastreador rastreia. Mas há uma coisa que visualiza: o eflambe.
Capítulo 35 — eFlambe: O Flambé que Gera Flame Graphs
A lenda diz que o eFlambe é um flambé. Ele flamba. Ele queima. Ele gera flame graphs. Ele mostra onde o tempo está sendo gasto. Ele mostra o que está lento. Ele nunca mente. Ele nunca esconde.
A verdade é que eFlambe é uma ferramenta para profiling rápido de aplicações Erlang e Elixir. Ele gera flame graphs de qualquer função que você especificar. Há duas maneiras de fazer profiling com o eFlambe: você pode invocar o código diretamente usando eflambe:apply/1,2, ou pode capturar dados de trace de uma função quando ela é invocada enquanto sua aplicação está rodando com eflambe:capture/1.
A lenda diz que, na primeira vez que um programador usou eFlambe, ele perguntou: "O que é um flame graph?" O instrutor respondeu: "É uma imagem que mostra onde seu código está queimando tempo."
O fato por trás da lenda: eFlambe é uma ferramenta para profiling rápido de aplicações Erlang e Elixir. Gera flame graphs de qualquer função especificada. Pode invocar código diretamente ou capturar dados de trace de uma função em execução.
Gancho: O flambé queima. Mas há uma coisa que ilumina: o BeamLens.
Capítulo 36 — BeamLens: A Lente que Vê o Runtime
A lenda diz que o BeamLens é uma lente. Ele vê o runtime. Ele vê a memória. Ele vê os processos. Ele vê os alocadores. Ele vê os gargalos. Ele detecta anomalias. Ele nunca dorme. Ele nunca pisca.
A verdade é que BeamLens é uma biblioteca que traz inteligência de runtime adaptativa para a BEAM. Ele fornece skills para monitoramento comum de runtime: Beam (saúde da VM: memória, processos, schedulers, átomos, portas), Allocator (fragmentação de alocadores), Tracer (tracing de processos para debugging), ETS, GC e mais. Ele pode detectar anomalias estatísticas e auto-disparar investigações, identificar gargalos de message queue, monitorar fragmentação de alocadores de memória, e rastrear chamadas de função com segurança em produção. As skills existentes ganharam scheduler utilization tracking, ETS leak detection, binary memory monitoring, orphaned process detection e mais.
A lenda diz que, na primeira vez que um programador usou BeamLens, ele perguntou: "O que é isso?" O instrutor respondeu: "É a lente que vê o runtime. E ela te avisa quando algo está errado."
O fato por trás da lenda: BeamLens traz inteligência de runtime adaptativa para a BEAM. Detecta anomalias, identifica gargalos, monitora fragmentação e rastreia chamadas de função em produção.
Gancho: A lente vê. Mas há uma coisa que ilumina ainda mais: o xprof.
Capítulo 37 — xprof: O Profiler Visual que Nunca Para
A lenda diz que o xprof é um profiler. Mas não é um profiler comum. Ele é visual. Ele mostra gráficos. Ele mostra o que está sendo executado. Ele mostra o que está lento. Ele nunca para. Ele nunca mente.
A verdade é que xprof é um tracer e profiler visual para linguagens BEAM. Ele fornece uma interface gráfica para profiling de aplicações Erlang e Elixir. Ele mostra informações sobre funções em execução, tempo gasto, e muito mais. O xprof é uma ferramenta poderosa para encontrar gargalos de performance.
A lenda diz que, na primeira vez que um programador usou xprof, ele perguntou: "O que é isso?" O instrutor respondeu: "É o profiler visual. Ele te mostra onde o tempo está indo."
O fato por trás da lenda: xprof é um tracer e profiler visual para linguagens BEAM. Fornece interface gráfica para profiling de aplicações Erlang e Elixir.
Gancho: O profiler visualiza. Mas há uma coisa que mede com mix: o mix profile.
Capítulo 38 — mix profile: O Comando que Perfilha Tudo
A lenda diz que o mix profile é um comando. Ele perfilha. Ele mede. Ele analisa. Ele mostra onde o tempo está sendo gasto. Ele mostra onde a memória está sendo usada. Ele nunca mente. Ele nunca para.
A verdade é que mix profile é uma tarefa do Mix que perfilha o código usando ferramentas do Erlang. Ele suporta diferentes profilers: cprof (contagem de chamadas por função), eprof (tempo gasto em cada função), fprof (tracing detalhado com call graph), e tprof (introduzido no Erlang/OTP 27, unifica call count, time e allocation). Os profilers cprof e eprof foram deprecados em favor do tprof no OTP 27.
A lenda diz que, na primeira vez que um programador usou mix profile.eprof, ele perguntou: "O que é isso?" O instrutor respondeu: "É o comando que perfilha. E ele te mostra onde o tempo está indo."
O fato por trás da lenda: mix profile perfilha código usando ferramentas do Erlang. Suporta cprof, eprof, fprof e tprof (OTP 27+). cprof e eprof foram deprecados em favor do tprof.
Gancho: O comando perfilha. Mas há uma coisa que mede com precisão: o tprof.
Capítulo 39 — tprof: O Profiler que Substitui Todos os Outros
A lenda diz que o tprof é um profiler. Mas não é um profiler comum. Ele substitui todos os outros. Ele mede call count, time, e allocation. Ele é unificado. Ele é experimental. Ele é o futuro.
A verdade é que tprof é um módulo experimental introduzido no Erlang/OTP 27 que fornece uma API unificada para medir call count, time, e allocation. Ele visa substituir o eprof e o cprof. O mix profile.tprof foi adicionado no Elixir 1.17 e requer Erlang/OTP 27+.
A lenda diz que, na primeira vez que um programador usou tprof, ele perguntou: "O que é isso?" O instrutor respondeu: "É o futuro do profiling. Ele mede tudo."
O fato por trás da lenda: tprof é um módulo experimental introduzido no OTP 27 que unifica call count, time e allocation. Visa substituir eprof e cprof. mix profile.tprof foi adicionado no Elixir 1.17.
Gancho: O profiler unifica. Mas há uma coisa que testa propriedades: o ExUnitProperties.
Capítulo 40 — ExUnitProperties: O Feiticeiro que Testa Propriedades
A lenda diz que o ExUnitProperties é um feiticeiro. Ele testa propriedades. Ele gera dados aleatórios. Ele testa se a propriedade é verdadeira para todos os casos. Ele encontra contra-exemplos. Ele encolhe o caso. Ele nunca desiste. Ele nunca erra.
A verdade é que ExUnitProperties é um módulo que fornece macros para property-based testing em Elixir. Ele faz parte da biblioteca StreamData. As macros principais são check/3, property/3 e gen/2. O property/3 é um açúcar sintático para ExUnit.Case.test/3 que configura um caso de teste para property-based testing. Ele gera milhares de casos de teste automaticamente.
A lenda diz que, na primeira vez que um programador usou ExUnitProperties, ele perguntou: "O que é isso?" O instrutor respondeu: "É o feiticeiro que testa propriedades."
O fato por trás da lenda: ExUnitProperties fornece macros para property-based testing. Faz parte da biblioteca StreamData. As macros principais são check/3, property/3 e gen/2.
Gancho: O feiticeiro testa. Mas há uma coisa que gera dados específicos: o Faker.
Capítulo 41 — Faker (Parte 3): O Mago que Gera Dados Específicos
A lenda diz que o Faker é um mago. Ele gera dados. Mas não são dados quaisquer. São dados específicos. Nomes. Endereços. Emails. Telefones. Empresas. Avatares. Códigos. Ele nunca repete. Ele nunca erra.
A verdade é que Faker é uma biblioteca pura em Elixir para gerar dados falsos. Ela pode ser usada para popular bancos de dados, criar documentos XML, preencher sua persistência para stress test, ou anonimizar dados retirados de um serviço de produção. Ela tem uma ampla variedade de geradores: endereços, avatares, códigos, comércio, empresas, internet, lorem ipsum, e muito mais. Faker tem cerca de 2.000 estrelas no GitHub.
A lenda diz que, na primeira vez que um programador usou Faker, ele perguntou: "O que posso gerar?" O instrutor respondeu: "Tudo. Desde que seja falso."
O fato por trás da lenda: Faker é uma biblioteca pura em Elixir para gerar dados falsos. Usada para popular bancos de dados, criar fixtures e anonimizar dados. Geradores incluem endereços, avatares, códigos, comércio, empresas, internet e lorem ipsum. Cerca de 2.000 estrelas no GitHub.
Gancho: O mago gera. Mas há uma coisa que mocka: o Mox.
Capítulo 42 — Mox (Parte 3): O Ator que Nunca Sai do Personagem
A lenda diz que o Mox é um ator. Ele finge ser outro. Ele interpreta. Ele substitui. Ele mocka. Ele define comportamentos. Ele define expectativas. Ele nunca sai do personagem. Ele nunca erra.
A verdade é que Mox é uma biblioteca para definir mocks concorrentes em Elixir. A biblioteca segue os princípios de "Mocks and explicit contracts": sem mocks ad-hoc (você só pode criar mocks baseados em behaviours), sem geração dinâmica de módulos durante os testes, suporte a concorrência, e dependência de pattern matching e cláusulas de função para assertions. O objetivo por trás do Mox é ajudar você a pensar e definir o contrato entre as diferentes partes da sua aplicação. Mox é mantido pela Dashbit e tem cerca de 1.385 estrelas no GitHub.
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 baseada em behaviours. Define mocks, expectativas e verificações. Segue os princípios de "Mocks and explicit contracts". Mantida pela Dashbit.
Gancho: O ator finge. Mas há uma coisa que também mocka: o Mimic.
Capítulo 43 — Mimic: O Sósia que Substitui Sem Behaviours
A lenda diz que o Mimic é um sósia. Ele substitui. Ele mocka. Mas ele não exige behaviours. Ele é mais flexível. Ele é mais simples. Ele nunca erra. Ele nunca reclama.
A verdade é que Mimic é uma biblioteca de mocking para Elixir que não exige behaviours. Ele permite substituir módulos e funções em tempo de execução, similar ao Mock, mas com uma API mais moderna e suporte a concorrência. Mimic é frequentemente usado em projetos que precisam mockar módulos que não definem behaviours.
A lenda diz que, na primeira vez que um programador usou Mimic, ele perguntou: "Por que não usar Mox?" O instrutor respondeu: "Porque o módulo não tem behaviour. O Mimic aceita."
O fato por trás da lenda: Mimic é uma biblioteca de mocking que não exige behaviours. Permite substituir módulos e funções em tempo de execução, com suporte a concorrência.
Gancho: O sósia substitui. Mas há uma coisa que mede: o Benchee.
Capítulo 44 — Benchee (Parte 3): O Cronômetro que Mede com Plugins
A lenda diz que o Benchee é um cronômetro. Mas não é um cronômetro comum. Ele tem plugins. Eles geram gráficos HTML. Eles exportam PNG. Eles salvam CSV. Eles nunca param. Eles nunca deixam uma métrica sem gráfico.
A verdade é que Benchee tem uma família de bibliotecas. O benchee_html desenha gráficos de micro-benchmarking bonitos em HTML e permite exportá-los como PNG. O benchee_csv exporta benchmarks como CSV para gerar gráficos em planilhas. O Benchee tem uma abordagem em camadas focada na intercambialidade. Ele tem cerca de 1.416 estrelas no GitHub e foi criado há quase nove anos.
A lenda diz que, na primeira vez que um programador usou um plugin do Benchee, ele perguntou: "O que é isso?" O instrutor respondeu: "É o cronômetro com superpoderes."
O fato por trás da lenda: Benchee tem plugins como benchee_html (gráficos HTML/PNG) e benchee_csv (exportação CSV). A biblioteca tem uma abordagem em camadas focada na intercambialidade. Cerca de 1.416 estrelas no GitHub.
Gancho: O cronômetro mede. Mas há uma coisa que ensina: o Credo.
Capítulo 45 — Credo (Parte 3): O Professor que Tem um Style Guide
A lenda diz que o Credo é um professor. Mas não é um professor comum. Ele tem um style guide. Ele tem regras. Ele tem checks. Ele quer que você siga o estilo. Ele quer que você seja consistente. Ele nunca desiste de você.
A verdade é que Credo é uma ferramenta de análise estática com foco em ensino e consistência de código. Ele implementa seu próprio style guide e pode ser configurado com checks que são configuradas com parâmetros no arquivo de configuração. Existem checks de comunidade que implementam regras comuns de Elixir/Phoenix e vulnerabilidades de segurança do CWE Top 25. Credo tem mais de 5.140 estrelas no GitHub.
A lenda diz que, na primeira vez que um programador viu todas as checks do Credo, ele perguntou: "Preciso seguir todas?" O instrutor respondeu: "Não. Mas o professor vai reclamar."
O fato por trás da lenda: Credo implementa um style guide com muitas regras verificáveis. Checks são configuradas com parâmetros no arquivo de configuração. Checks de comunidade implementam vulnerabilidades de segurança. Mais de 5.140 estrelas no GitHub.
Gancho: O professor ensina. Mas há uma coisa que formata: o mix format.
Capítulo 46 — Mix Format (Parte 3): O Cabeleireiro que Tem Plugins
A lenda diz que o mix format é um cabeleireiro. Mas não é um cabeleireiro comum. Ele tem plugins. Eles formatam não só código Elixir, mas também .heex, .exs, e outros arquivos. Eles são a extensão do cabeleireiro. Eles nunca erram. Eles nunca deixam um arquivo bagunçado.
A verdade é que mix format é uma maneira built-in de formatar seu código Elixir de acordo com o estilo consistente acordado pela comunidade. Ele lê um arquivo .formatter.exs para configuração. Desde o Elixir 1.13, é possível usar plugins de formatador para estender o comportamento do formatador para outros tipos de arquivo. O phoenix_live_view fornece um plugin para formatar templates .heex.
A lenda diz que, na primeira vez que um programador configurou um plugin, ele perguntou: "O que é isso?" O instrutor respondeu: "É o estilista. Ele formata o que o cabeleireiro não alcança."
O fato por trás da lenda: mix format formata código de acordo com o estilo consistente acordado pela comunidade. Lê .formatter.exs para configuração. Suporta plugins desde o Elixir 1.13.
Gancho: O cabeleireiro formata. Mas há uma coisa que gera documentação: o ExDoc.
Capítulo 47 — ExDoc (Parte 4): O Papagaio que Gera EPUB
A lenda diz que o ExDoc é um papagaio. Mas não é um papagaio comum. Ele gera HTML. Ele gera EPUB. Ele gera Markdown. Ele é um papagaio que escreve livros. Ele nunca para. Ele nunca erra.
A verdade é que ExDoc é uma ferramenta para gerar documentação para projetos Erlang e Elixir. Ele produz documentação em HTML, EPUB e Markdown a partir de documentação de API. Você pode usar ExDoc com Mix (recomendado para projetos Elixir), com Rebar (recomendado para projetos Erlang), ou via linha de comando. ExDoc é usado para gerar a documentação oficial do Elixir.
A lenda diz que, na primeira vez que um programador gerou um EPUB, ele perguntou: "Isso é um livro?" O instrutor respondeu: "É a sua documentação, em formato de livro."
O fato por trás da lenda: ExDoc gera documentação para projetos Erlang e Elixir em HTML, EPUB e Markdown. Funciona com Mix, Rebar ou linha de comando.
Gancho: O papagaio documenta. Mas há uma coisa que analisa: o Dialyzer.
Capítulo 48 — Dialyzer (Parte 3): O Detector que Tem Success Typing
A lenda diz que o Dialyzer é um detector de mentiras. Mas não é um detector comum. Ele usa success typing. Ele infere os tipos que podem levar a um sucesso em runtime. Ele nunca mente. Ele nunca perdoa um any().
A verdade é que Dialyzer (DIscrepancy AnaLYZer for ERlang programs) é uma poderosa ferramenta de análise estática baseada em success typing, uma abordagem que infere os tipos que podem levar a um sucesso em runtime. Ele é excelente em encontrar incompatibilidades de tipo, código inalcançável e funções desnecessárias através de análise de fluxo sofisticada. Para projetos Elixir, a maneira recomendada de usar o Dialyzer é através do Dialyxir.
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 é baseada em success typing. Identifica incompatibilidades de tipo, código inalcançável e funções desnecessárias. O Dialyxir é a forma recomendada de usá-lo em projetos Elixir.
Gancho: O detector analisa. Mas há uma coisa que testa: o ExUnit.
Capítulo 49 — ExUnit (Parte 3): O Tribunal que Tem Doctests
A lenda diz que o ExUnit é um tribunal. Mas não é um tribunal comum. Ele tem doctests. Ele testa seus exemplos de documentação. Ele garante que a documentação está correta. Ele nunca mente. Ele nunca perdoa uma mentira na documentação.
A verdade é que ExUnit é o framework de testes unitários do Elixir. Ele fornece assert, refute, assert_raise, assert_receive e outras macros. Ele também suporta doctests, que testam os exemplos de código na documentação. Se a documentação mentir, o doctest falha. 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 escreveu um doctest, ele perguntou: "Isso testa a documentação?" O instrutor respondeu: "Sim. E se você mentir, o tribunal te condena."
O fato por trás da lenda: ExUnit é o framework de testes unitários do Elixir. Fornece assert, refute, assert_raise, assert_receive. Suporta doctests. É executado com mix test.
Gancho: O tribunal julga. Mas há uma coisa que mede cobertura: o Cover.
Capítulo 50 — Cover: O Detetive que Mede Cobertura
A lenda diz que o Cover é um detetive. Ele investiga seu código. Ele vê quais linhas foram executadas. Ele vê quais linhas foram ignoradas. Ele te mostra a verdade. Ele nunca mente. Ele nunca esconde uma linha morta.
A verdade é que mix test --cover executa os testes com cobertura de código. O Cover mostra quais linhas do seu código foram executadas pelos testes e quais não foram. Ele gera um relatório de cobertura que ajuda a identificar áreas do código que não estão sendo testadas. O Cover é uma ferramenta essencial para garantir que seus testes estão cobrindo o código de forma adequada.
A lenda diz que, na primeira vez que um programador rodou mix test --cover, ele perguntou: "O que é isso?" O instrutor respondeu: "É o detetive. Ele te mostra o que você não testou."
O fato por trás da lenda: mix test --cover executa testes com cobertura de código, mostrando quais linhas foram executadas e quais não foram.
Gancho: O detetive mede. Mas há uma coisa que verifica tipos: o Dialyzer.
Capítulo 51 — Telemetry (Parte 3): O Olho que Tem Métricas
A lenda diz que o Telemetry é um olho. Mas não é um olho comum. Ele tem métricas. Ele tem eventos. Ele tem LiveDashboard. Ele mostra tudo em tempo real. Ele nunca dorme. Ele nunca mente.
A verdade é que Telemetry é uma biblioteca de instrumentação para Elixir e Erlang. Ele fornece eventos que podem ser consumidos por bibliotecas como telemetry_metrics e visualizados pelo Phoenix LiveDashboard. O Phoenix integra a Telemetry para medir e reportar métricas padrão do Phoenix, Ecto e da VM Elixir. O LiveDashboard converte cada métrica do Telemetry.Metrics em um gráfico em tempo real bonito.
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. Fornece eventos para telemetry_metrics e LiveDashboard. O Phoenix integra a Telemetry para medir métricas de Phoenix, Ecto e VM.
Gancho: O olho observa. Mas há uma coisa que registra: o Logger.
Capítulo 52 — Logger (Parte 3): O Diário que Tem Níveis
A lenda diz que o Logger é um diário. Mas não é um diário comum. Ele tem níveis. debug, info, warn, error. Ele registra tudo. Ele nunca mente. Ele nunca esquece.
A verdade é que Logger é o módulo de logging do Elixir. Ele foi introduzido no Elixir v0.15.0 (agosto de 2014). Ele fornece 4 níveis de log: debug, info, warn e error, e suporta múltiplos backends que são automaticamente supervisionados quando plugados no Logger. O Logger formata e trunca mensagens no cliente para evitar entupir os backends, e alterna entre modos síncronos e assíncronos para permanecer performático quando necessário.
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. Com o nível certo."
O fato por trás da lenda: Logger é o módulo de logging do Elixir. Foi introduzido no Elixir v0.15.0 (agosto de 2014). Fornece 4 níveis de log e suporta múltiplos backends.
Gancho: O diário registra. Mas há uma coisa que conecta nós: o Libcluster.
Capítulo 53 — Libcluster (Parte 2): O Feitiço que Tem Estratégias
A lenda diz que o Libcluster é um feitiço. Mas não é um feitiço comum. Ele tem estratégias. EPMD. Kubernetes. Gossip. DNS. Rancher. Ele forma clusters. Ele conecta nós. Ele nunca falha. Ele nunca desiste.
A verdade é que Libcluster fornece um mecanismo para formar automaticamente clusters de nós Erlang, com adesão estática ou dinâmica. Ele fornece um mecanismo de publish/subscribe para eventos de cluster, para que você possa ser notificado quando membros entram ou saem, e fornece um sistema de estratégias plugável. Ele suporta várias estratégias: EPMD, Kubernetes, Gossip, DNS, Rancher.
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. Fornece publish/subscribe para eventos de cluster e um sistema de estratégias plugável.
Gancho: O feitiço junta. Mas há uma coisa que explica os limites: o Teorema CAP.
Capítulo 54 — CAP (Parte 9): O Teorema que Tem Lados
A lenda diz que, quando os aliens criaram a BEAM, eles leram o Teorema CAP e disseram: "Vamos escolher AP." E assim fizeram. A maioria das bibliotecas distribuídas do Elixir fica do lado AP. O Paxtor é CP.
A verdade é que a maioria das bibliotecas distribuídas do Elixir (Phoenix Pub/Sub, Horde, Swarm, Delta CRDTs) fica do lado AP do Teorema CAP. Elas preferem disponibilidade a consistência estrita. No entanto, existe o Paxtor, uma biblioteca Elixir para construir sistemas distribuídos CP (Consistent and Partition-tolerant) no BEAM. O Paxtor é baseado no PaxosKV, que fornece uma camada de consenso baseada no algoritmo Basic 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 do Teorema CAP. O Paxtor é uma biblioteca CP que usa Paxos.
Gancho: O teorema explica. Mas há uma coisa que a BEAM faz melhor: tolerância a falhas.
Capítulo 55 — O Fim Parcial do Tomo VII: As Ferramentas que Nunca Param
A lenda diz que, no fim de tudo, quando todos os tomos forem escritos, as ferramentas continuarão funcionando. O Dialyzer continuará analisando. O Credo continuará ensinando. O Benchee continuará medindo. O Observer continuará observando. E a BEAM continuará rodando.
A verdade é que o ecossistema de ferramentas do Elixir é vasto. Dialyzer analisa tipos. Credo ensina. Benchee mede. Observer observa. ExDoc documenta. Mix format formata. ExUnit testa. StreamData gera dados. Wallaby testa navegadores. Mox mocka. Faker inventa dados. Ecto.Sandbox isola testes. Telemetry observa. Logger registra. Libcluster conecta. observer_cli visualiza. Wobserver monitora. recon diagnostica. eFlambe perfila. BeamLens ilumina. xprof visualiza. tprof unifica. ExUnitProperties testa propriedades. Mimic substitui. E muitas outras ferramentas continuam sendo criadas.
Este foi o Tomo VII — As Ferramentas. Cinquenta e cinco capítulos. Ferramentas. Mil processos. E um brasileiro que ouviu um sussurro.
No próximo tomo, Os Guardiões, vamos explorar a comunidade, as conferências, a Erlang Ecosystem Foundation, e as pessoas que mantêm o ecossistema vivo.
Até lá.
O fato por trás da lenda: O ecossistema de ferramentas do Elixir é vasto. Dialyzer, Credo, Benchee, Observer, ExDoc, Mix format, ExUnit, StreamData, Wallaby, Mox, Faker, Ecto.Sandbox, Telemetry, Logger, Libcluster, observer_cli, Wobserver, recon, eFlambe, BeamLens, xprof, tprof, ExUnitProperties, Mimic, e muitas outras ferramentas.
Agora, sério: O ecossistema de ferramentas do Elixir é vasto. Dialyzer analisa tipos. Credo ensina. Benchee mede. Observer observa. ExDoc documenta. Mix format formata. ExUnit testa. StreamData gera dados. Wallaby testa navegadores. Mox mocka. Faker inventa dados. Ecto.Sandbox isola testes. Telemetry observa. Logger registra. Libcluster conecta. observer_cli visualiza. Wobserver monitora. recon diagnostica. eFlambe perfila. BeamLens ilumina. xprof visualiza. tprof unifica. ExUnitProperties testa propriedades. Mimic substitui. 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)