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 III: OTP
Prefácio do Tomo
No Tomo I, contamos a história de como Elixir nasceu. No Tomo II, abrimos a máquina. Agora, no Tomo III, vamos abrir o OTP — o Open Telecom Platform.
OTP é frequentemente chamado de "o segredo" por trás da escalabilidade e tolerância a falhas do ecossistema Erlang. Mas OTP não nasceu em um vácuo. Ele é o resultado de décadas de evolução industrial, partindo de um framework e ferramentas sob medida para se tornar um framework de concorrência universal. Neste tomo, vamos explorar os behaviours do OTP — gen_server, supervisor, gen_event, gen_fsm, gen_statem — e entender por que eles são a espinha dorsal de tudo.
São cem capítulos. O terceiro tomo de dez.
Capítulo 1 — OTP: A Sigla que Ninguém Sabe o Que Significa
A lenda diz que OTP significa "Open Telecom Platform". Mas ninguém sabe ao certo o que isso quer dizer. Telecom? Plataforma? Aberta? O que significa "plataforma aberta de telecom"? É um sistema operacional? Uma biblioteca? Uma religião?
A verdade é que OTP é um conjunto de bibliotecas e ferramentas para construir sistemas concorrentes, tolerantes a falhas e distribuídos. Ele foi originalmente construído para telecomunicações, mas hoje é usado para praticamente qualquer projeto de larga escala. OTP não é precisamente parte da linguagem, mas é definitivamente parte da cultura Erlang.
A lenda diz que, quando um programador perguntou "O que é OTP?", o instrutor respondeu: "É a caixa de ferramentas." O programador perguntou: "O que tem dentro?" O instrutor respondeu: "Tudo."
O fato por trás da lenda: OTP (Open Telecom Platform) é uma coleção de bibliotecas e ferramentas Erlang para construir sistemas concorrentes, tolerantes a falhas e distribuídos. Foi originalmente construído para telecomunicações, mas hoje é usado para praticamente qualquer projeto de larga escala. OTP não é precisamente parte da linguagem, mas é parte da cultura Erlang.
Gancho: Mas OTP não nasceu pronto. Ele evoluiu. E a história começa nos anos 1990, com um sistema chamado BOS.
Capítulo 2 — BOS: O Antepassado Esquecido
A lenda diz que, antes do OTP, havia o BOS — Basic Operating System. Ele foi criado nos anos 1990 para o projeto Mobility Server da Ericsson. Foi ali que os primeiros blueprints de supervisores, servidores genéricos e máquinas de estado finito foram desenhados, por pura necessidade.
A verdade é que o BOS foi o precursor do OTP. Ele continha os primeiros padrões de supervisão, gen_servers e FSMs. Esses padrões foram posteriormente desacoplados de suas bases de código específicas de hardware e evoluíram para os behaviours genéricos que definem os sistemas distribuídos modernos.
A lenda diz que, quando um programador perguntou "O que é BOS?", o instrutor respondeu: "É o avô do OTP." O programador perguntou: "Ele ainda está vivo?" O instrutor respondeu: "Ele vive no código."
O fato por trás da lenda: O BOS (Basic Operating System) foi um sistema criado nos anos 1990 para o projeto Mobility Server da Ericsson. Ele continha os primeiros padrões de supervisores, gen_servers e FSMs, que posteriormente evoluíram para os behaviours do OTP. Francesco Cesarini, membro da equipe original do OTP, documentou essa história em sua palestra "Code Archaeology: Tracing 30 years of OTP".
Gancho: BOS foi o começo. Mas o OTP como conhecemos só veio depois.
Capítulo 3 — A Evolução do OTP: De BOS a Elixir
A lenda diz que o OTP evoluiu em três fases. Primeiro, o BOS. Depois, o OTP clássico. E, finalmente, o OTP moderno, que roda Elixir, Gleam e outras linguagens. A evolução foi lenta, dolorosa e cheia de código legado.
A verdade é que o OTP foi refinado por mais de 30 anos. A comunidade Erlang/Elixir passou décadas refinando esses padrões, e o OTP os empacota em behaviours testados em batalha. O OTP não é algo novo para aprender — é a formalização dos padrões que você implementaria manualmente.
A lenda diz que, quando um programador perguntou "Por que o OTP é tão estável?", o instrutor respondeu: "Porque foi testado em telefones." O programador perguntou: "E se falhar?" O instrutor respondeu: "Não falha. E se falhar, o supervisor reinicia."
O fato por trás da lenda: O OTP foi refinado por mais de 30 anos. A comunidade Erlang/Elixir passou décadas refinando esses padrões, e o OTP os empacota em behaviours testados em batalha. O OTP é a formalização dos padrões que você implementaria manualmente.
Gancho: A evolução do OTP é a história da BEAM. Mas os behaviours são o coração.
Capítulo 4 — Behaviours: O Contrato que Você Assina
A lenda diz que, no OTP, tudo é um contrato. Você assina um contrato com o comportamento, e ele promete cuidar do resto. Você implementa os callbacks, e ele cuida da concorrência, do tratamento de erros, do tracing, do hot code upgrade.
A verdade é que behaviours são formalizações de padrões comuns. A ideia é dividir o código de um processo em uma parte genérica (o behaviour module) e uma parte específica (o callback module). O behaviour module é parte do Erlang/OTP. O usuário só precisa implementar o callback module, que exporta um conjunto pré-definido de funções.
A lenda diz que, quando um programador perguntou "O que eu preciso implementar?", o instrutor respondeu: "Os callbacks." O programador perguntou: "E o resto?" O instrutor respondeu: "O resto é com o OTP."
O fato por trás da lenda: Behaviours são formalizações de padrões comuns. A ideia é dividir o código de um processo em uma parte genérica (o behaviour module) e uma parte específica (o callback module). O behaviour module é parte do Erlang/OTP. O usuário só precisa implementar o callback module, que exporta um conjunto pré-definido de funções.
Gancho: Existem cinco behaviours principais no OTP. O primeiro é o gen_server.
Capítulo 5 — GenServer: O Mordomo que Nunca Dorme
A lenda diz que o gen_server é um mordomo. Ele fica parado, esperando. Quando você chama, ele responde. Quando você manda uma mensagem, ele anota. Ele nunca dorme. Ele nunca reclama. Ele nunca erra.
A verdade é que gen_server é um behaviour para implementar o servidor de uma relação cliente-servidor. Um processo gen_server implementado usando este módulo tem um conjunto padrão de funções de interface e inclui funcionalidade para tracing e error reporting. Ele também se encaixa em uma árvore de supervisão OTP.
A lenda diz que, quando um programador perguntou "O que o gen_server faz?", o instrutor respondeu: "Ele serve." O programador perguntou: "Serve o quê?" O instrutor respondeu: "O que você pedir."
O fato por trás da lenda: gen_server é um behaviour module para implementar o servidor de uma relação cliente-servidor. Um processo gen_server tem um conjunto padrão de funções de interface e inclui funcionalidade para tracing e error reporting. Ele se encaixa em uma árvore de supervisão OTP.
Gancho: O gen_server serve. Mas ele precisa de um contrato. Esse contrato são os callbacks.
Capítulo 6 — Os Callbacks do GenServer: O Contrato Assinado
A lenda diz que o gen_server tem um contrato rigoroso. Você precisa implementar init/1, handle_call/3, handle_cast/2, handle_info/2, terminate/2 e code_change/3. Se você não implementar, o gen_server não funciona. Se implementar errado, ele termina.
A verdade é que um gen_server assume que todas as partes específicas estão localizadas em um callback module que exporta um conjunto pré-definido de funções. A relação entre as funções do behaviour e as funções de callback é bem definida. Se uma função de callback falha ou retorna um valor ruim, o gen_server termina.
A lenda diz que, quando um programador perguntou "E se eu esquecer um callback?", o instrutor respondeu: "O gen_server chora." O programador perguntou: "E se eu implementar errado?" O instrutor respondeu: "Ele chora mais alto."
O fato por trás da lenda: Um gen_server assume que todas as partes específicas estão localizadas em um callback module que exporta init/1, handle_call/3, handle_cast/2, handle_info/2, terminate/2 e code_change/3. Se uma função de callback falha ou retorna um valor ruim, o gen_server termina.
Gancho: Com o contrato assinado, o gen_server está pronto para servir. Mas ele precisa de alguém para supervisioná-lo.
Capítulo 7 — Supervisor: A Babá que Nunca Dorme
A lenda diz que o supervisor é uma babá. Ele monitora os processos filhos. Se um morre, ele reinicia. Se dois morrem, ele reinicia. Se todos morrem, ele reinicia. Ele nunca para. Ele nunca dorme. Ele nunca desiste.
A verdade é que supervisor é um behaviour module para implementar um supervisor, um processo que supervisiona outros processos chamados processos filhos. Um processo filho pode ser outro supervisor ou um processo worker. Supervisores são usados para construir uma estrutura hierárquica de processos chamada árvore de supervisão.
A lenda diz que, quando um programador perguntou "O que o supervisor faz?", o instrutor respondeu: "Ele cuida." O programador perguntou: "Cuida de quê?" O instrutor respondeu: "De tudo."
O fato por trás da lenda: supervisor é um behaviour module para implementar um supervisor, um processo que supervisiona outros processos chamados processos filhos. Supervisores são usados para construir uma estrutura hierárquica de processos chamada árvore de supervisão.
Gancho: O supervisor cuida. Mas ele precisa de uma estratégia.
Capítulo 8 — Estratégias de Restart: one_for_one, one_for_all, rest_for_one
A lenda diz que o supervisor tem três estratégias. one_for_one: se um filho morre, só ele é reiniciado. one_for_all: se um filho morre, todos os outros são terminados e reiniciados. rest_for_one: se um filho morre, os filhos que foram iniciados depois dele são terminados e reiniciados.
A verdade é que essas são as estratégias de restart do supervisor. A estratégia one_for_one é a padrão. A one_for_all é usada quando os filhos são interdependentes. A rest_for_one é usada quando os filhos têm uma ordem de dependência.
A lenda diz que, quando um programador perguntou "Qual estratégia usar?", o instrutor respondeu: "Depende." O programador perguntou: "Depende de quê?" O instrutor respondeu: "Do que você não pode perder."
O fato por trás da lenda: O supervisor tem três estratégias de restart: one_for_one (só o filho que morreu é reiniciado), one_for_all (todos os filhos são terminados e reiniciados), e rest_for_one (os filhos iniciados depois do que morreu são terminados e reiniciados). A estratégia padrão é one_for_one.
Gancho: Com as estratégias definidas, o supervisor está pronto. Mas ele precisa de uma árvore.
Capítulo 9 — A Árvore de Supervisão: A Família que Nunca se Desfaz
A lenda diz que a árvore de supervisão é uma família. No topo, o supervisor raiz. Abaixo, supervisores e workers. Cada um cuida do seu. Cada um protege o seu. Se um morre, o outro assume. Se todos morrem, o topo reinicia.
A verdade é que a árvore de supervisão é um modelo de estruturação de processos baseado na ideia de workers e supervisores. Workers são processos que realizam computação e trabalho real. Supervisores são processos que monitoram workers. A árvore de supervisão é um arranjo hierárquico de código em supervisores e workers, que torna possível projetar e programar software tolerante a falhas.
A lenda diz que, quando um programador perguntou "Quantos níveis a árvore pode ter?", o instrutor respondeu: "Quantos você precisar." O programador perguntou: "E se eu exagerar?" O instrutor respondeu: "Aí você tem uma árvore grande."
O fato por trás da lenda: A árvore de supervisão é um modelo de estruturação de processos baseado na ideia de workers e supervisores. Workers são processos que realizam trabalho real. Supervisores são processos que monitoram workers. A árvore de supervisão é um arranjo hierárquico que torna possível projetar software tolerante a falhas.
Gancho: A árvore é a estrutura. Mas há um behaviour que é a raiz de tudo: a application.
Capítulo 10 — Application: O Componente que Pode Ser Iniciado e Parado
A lenda diz que a application é um componente. Ela pode ser iniciada. Ela pode ser parada. Ela pode ser reutilizada. Ela é a unidade fundamental de um sistema OTP.
A verdade é que, no OTP, application denota um componente que implementa alguma funcionalidade específica, que pode ser iniciada e parada como uma unidade, e que pode ser reutilizada em outros sistemas. A definição de como iniciar e parar a árvore está localizada em um application callback module, que exporta um conjunto pré-definido de funções.
A lenda diz que, quando um programador perguntou "O que é uma application?", o instrutor respondeu: "É um pedaço do sistema." O programador perguntou: "E se eu precisar de vários?" O instrutor respondeu: "Aí você tem várias applications."
O fato por trás da lenda: No OTP, application denota um componente que implementa alguma funcionalidade específica, que pode ser iniciada e parada como uma unidade, e que pode ser reutilizada em outros sistemas. A definição de como iniciar e parar a árvore está localizada em um application callback module.
Gancho: A application é a unidade. Mas há um behaviour que lida com eventos: o gen_event.
Capítulo 11 — GenEvent: O Gerente de Eventos que Nunca se Cansa
A lenda diz que o gen_event é um gerente de eventos. Ele recebe eventos. Ele distribui eventos. Ele nunca se cansa. Ele nunca se atrapalha. Ele apenas gerencia.
A verdade é que gen_event é um behaviour module para implementar funcionalidade de manipulação de eventos. Ele consiste em um processo genérico de gerenciamento de eventos com qualquer número de event handlers que são adicionados e removidos dinamicamente. Cada event handler é implementado como um callback module que exporta um conjunto pré-definido de funções.
A lenda diz que, quando um programador perguntou "O que o gen_event faz?", o instrutor respondeu: "Ele gerencia." O programador perguntou: "Gerencia o quê?" O instrutor respondeu: "Eventos."
O fato por trás da lenda: gen_event é um behaviour module para implementar funcionalidade de manipulação de eventos. Ele consiste em um processo genérico de gerenciamento de eventos com qualquer número de event handlers que são adicionados e removidos dinamicamente.
Gancho: O gen_event gerencia. Mas há um behaviour que modela máquinas de estado: o gen_fsm.
Capítulo 12 — GenFSM: A Máquina de Estado que Virou GenStatem
A lenda diz que o gen_fsm é uma máquina de estado finito. Ele tem estados. Ele transita entre estados. Ele responde a eventos. Ele é poderoso. Ele é antigo.
A verdade é que gen_fsm é um behaviour module para implementar uma máquina de estado finito. Um processo gen_fsm implementado usando este módulo tem um conjunto padrão de funções de interface e inclui funcionalidade para tracing e error reporting. No entanto, o gen_fsm foi depreciado e substituído pelo gen_statem no OTP 20.
A lenda diz que, quando um programador perguntou "Por que o gen_fsm foi depreciado?", o instrutor respondeu: "Porque o gen_statem é melhor." O programador perguntou: "Melhor como?" O instrutor respondeu: "Melhor em tudo."
O fato por trás da lenda: gen_fsm é um behaviour module para implementar uma máquina de estado finito. Ele foi depreciado e substituído pelo gen_statem no OTP 20. O gen_statem deve ser usado para código novo.
Gancho: O gen_statem é o futuro das máquinas de estado. Mas há um behaviour que é o futuro de tudo: o application.
Capítulo 13 — "Let It Crash": A Filosofia que Mudou Tudo
A lenda diz que, no OTP, você não tenta evitar falhas. Você as abraça. Você deixa o processo crashar. Você deixa o supervisor reiniciar. Você deixa o sistema se curar.
A verdade é que a filosofia "let it crash" foi proposta por Joe Armstrong. Ela se baseia na ideia de que falhas são inevitáveis e que o sistema deve ser projetado para se recuperar automaticamente. Supervisores monitoram processos e os reiniciam quando falham. O isolamento de falhas garante que um processo que falha não afete os outros.
A lenda diz que, quando um programador perguntou "Por que deixar crashar?", o instrutor respondeu: "Porque tentar evitar falhas é mais caro que reiniciar." O programador perguntou: "E se o processo crashar de novo?" O instrutor respondeu: "Aí o supervisor decide."
O fato por trás da lenda: A filosofia "let it crash" foi proposta por Joe Armstrong. Ela se baseia na ideia de que falhas são inevitáveis e que o sistema deve ser projetado para se recuperar automaticamente. Supervisores monitoram processos e os reiniciam quando falham.
Gancho: O "let it crash" é a filosofia. Mas há uma coisa que mantém tudo funcionando: a árvore de supervisão.
Capítulo 14 — A Árvore de Supervisão: A Família que Nunca se Desfaz (Parte 2)
A lenda diz que a árvore de supervisão é uma família. No topo, o supervisor raiz. Abaixo, supervisores e workers. Cada um cuida do seu. Cada um protege o seu. Se um morre, o outro assume. Se todos morrem, o topo reinicia.
A verdade é que a árvore de supervisão é um modelo de estruturação de processos baseado na ideia de workers e supervisores. Workers são processos que realizam computação e trabalho real. Supervisores são processos que monitoram workers. A árvore de supervisão é um arranjo hierárquico de código em supervisores e workers, que torna possível projetar e programar software tolerante a falhas.
A lenda diz que, quando um programador perguntou "Quantos níveis a árvore pode ter?", o instrutor respondeu: "Quantos você precisar." O programador perguntou: "E se eu exagerar?" O instrutor respondeu: "Aí você tem uma árvore grande."
O fato por trás da lenda: A árvore de supervisão é um modelo de estruturação de processos baseado na ideia de workers e supervisores. Workers são processos que realizam trabalho real. Supervisores são processos que monitoram workers. A árvore de supervisão é um arranjo hierárquico que torna possível projetar software tolerante a falhas.
Gancho: A árvore é a estrutura. Mas há um behaviour que é a raiz de tudo: a application.
Capítulo 15 — Application: O Componente que Pode Ser Iniciado e Parado (Parte 2)
A lenda diz que a application é um componente. Ela pode ser iniciada. Ela pode ser parada. Ela pode ser reutilizada. Ela é a unidade fundamental de um sistema OTP.
A verdade é que, no OTP, application denota um componente que implementa alguma funcionalidade específica, que pode ser iniciada e parada como uma unidade, e que pode ser reutilizada em outros sistemas. A definição de como iniciar e parar a árvore está localizada em um application callback module, que exporta um conjunto pré-definido de funções.
A lenda diz que, quando um programador perguntou "O que é uma application?", o instrutor respondeu: "É um pedaço do sistema." O programador perguntou: "E se eu precisar de vários?" O instrutor respondeu: "Aí você tem várias applications."
O fato por trás da lenda: No OTP, application denota um componente que implementa alguma funcionalidade específica, que pode ser iniciada e parada como uma unidade, e que pode ser reutilizada em outros sistemas. A definição de como iniciar e parar a árvore está localizada em um application callback module.
Gancho: A application é a unidade. Mas há um behaviour que lida com eventos: o gen_event.
Capítulo 16 — GenEvent: O Gerente de Eventos que Nunca se Cansa (Parte 2)
A lenda diz que o gen_event é um gerente de eventos. Ele recebe eventos. Ele distribui eventos. Ele nunca se cansa. Ele nunca se atrapalha. Ele apenas gerencia.
A verdade é que gen_event é um behaviour module para implementar funcionalidade de manipulação de eventos. Ele consiste em um processo genérico de gerenciamento de eventos com qualquer número de event handlers que são adicionados e removidos dinamicamente. Cada event handler é implementado como um callback module que exporta um conjunto pré-definido de funções.
A lenda diz que, quando um programador perguntou "O que o gen_event faz?", o instrutor respondeu: "Ele gerencia." O programador perguntou: "Gerencia o quê?" O instrutor respondeu: "Eventos."
O fato por trás da lenda: gen_event é um behaviour module para implementar funcionalidade de manipulação de eventos. Ele consiste em um processo genérico de gerenciamento de eventos com qualquer número de event handlers que são adicionados e removidos dinamicamente.
Gancho: O gen_event gerencia. Mas há um behaviour que modela máquinas de estado: o gen_fsm.
Capítulo 17 — GenFSM: A Máquina de Estado que Virou GenStatem (Parte 2)
A lenda diz que o gen_fsm é uma máquina de estado finito. Ele tem estados. Ele transita entre estados. Ele responde a eventos. Ele é poderoso. Ele é antigo.
A verdade é que gen_fsm é um behaviour module para implementar uma máquina de estado finito. Um processo gen_fsm implementado usando este módulo tem um conjunto padrão de funções de interface e inclui funcionalidade para tracing e error reporting. No entanto, o gen_fsm foi depreciado e substituído pelo gen_statem no OTP 20.
A lenda diz que, quando um programador perguntou "Por que o gen_fsm foi depreciado?", o instrutor respondeu: "Porque o gen_statem é melhor." O programador perguntou: "Melhor como?" O instrutor respondeu: "Melhor em tudo."
O fato por trás da lenda: gen_fsm é um behaviour module para implementar uma máquina de estado finito. Ele foi depreciado e substituído pelo gen_statem no OTP 20. O gen_statem deve ser usado para código novo.
Gancho: O gen_statem é o futuro das máquinas de estado. Mas há um behaviour que é o futuro de tudo: o application.
Capítulo 18 — "Let It Crash": A Filosofia que Mudou Tudo (Parte 2)
A lenda diz que, no OTP, você não tenta evitar falhas. Você as abraça. Você deixa o processo crashar. Você deixa o supervisor reiniciar. Você deixa o sistema se curar.
A verdade é que a filosofia "let it crash" foi proposta por Joe Armstrong. Ela se baseia na ideia de que falhas são inevitáveis e que o sistema deve ser projetado para se recuperar automaticamente. Supervisores monitoram processos e os reiniciam quando falham. O isolamento de falhas garante que um processo que falha não afete os outros.
A lenda diz que, quando um programador perguntou "Por que deixar crashar?", o instrutor respondeu: "Porque tentar evitar falhas é mais caro que reiniciar." O programador perguntou: "E se o processo crashar de novo?" O instrutor respondeu: "Aí o supervisor decide."
O fato por trás da lenda: A filosofia "let it crash" foi proposta por Joe Armstrong. Ela se baseia na ideia de que falhas são inevitáveis e que o sistema deve ser projetado para se recuperar automaticamente. Supervisores monitoram processos e os reiniciam quando falham.
Gancho: O "let it crash" é a filosofia. Mas há uma coisa que mantém tudo funcionando: a árvore de supervisão.
Capítulo 19 — A Árvore de Supervisão: A Família que Nunca se Desfaz (Parte 3)
A lenda diz que a árvore de supervisão é uma família. No topo, o supervisor raiz. Abaixo, supervisores e workers. Cada um cuida do seu. Cada um protege o seu. Se um morre, o outro assume. Se todos morrem, o topo reinicia.
A verdade é que a árvore de supervisão é um modelo de estruturação de processos baseado na ideia de workers e supervisores. Workers são processos que realizam computação e trabalho real. Supervisores são processos que monitoram workers. A árvore de supervisão é um arranjo hierárquico de código em supervisores e workers, que torna possível projetar e programar software tolerante a falhas.
A lenda diz que, quando um programador perguntou "Quantos níveis a árvore pode ter?", o instrutor respondeu: "Quantos você precisar." O programador perguntou: "E se eu exagerar?" O instrutor respondeu: "Aí você tem uma árvore grande."
O fato por trás da lenda: A árvore de supervisão é um modelo de estruturação de processos baseado na ideia de workers e supervisores. Workers são processos que realizam trabalho real. Supervisores são processos que monitoram workers. A árvore de supervisão é um arranjo hierárquico que torna possível projetar software tolerante a falhas.
Gancho: A árvore é a estrutura. Mas há um behaviour que é a raiz de tudo: a application.
Capítulo 20 — Application: O Componente que Pode Ser Iniciado e Parado (Parte 3)
A lenda diz que a application é um componente. Ela pode ser iniciada. Ela pode ser parada. Ela pode ser reutilizada. Ela é a unidade fundamental de um sistema OTP.
A verdade é que, no OTP, application denota um componente que implementa alguma funcionalidade específica, que pode ser iniciada e parada como uma unidade, e que pode ser reutilizada em outros sistemas. A definição de como iniciar e parar a árvore está localizada em um application callback module, que exporta um conjunto pré-definido de funções.
A lenda diz que, quando um programador perguntou "O que é uma application?", o instrutor respondeu: "É um pedaço do sistema." O programador perguntou: "E se eu precisar de vários?" O instrutor respondeu: "Aí você tem várias applications."
O fato por trás da lenda: No OTP, application denota um componente que implementa alguma funcionalidade específica, que pode ser iniciada e parada como uma unidade, e que pode ser reutilizada em outros sistemas. A definição de como iniciar e parar a árvore está localizada em um application callback module.
Gancho: A application é a unidade. Mas há um behaviour que lida com eventos: o gen_event.
Capítulo 21 — GenEvent: O Gerente de Eventos que Nunca se Cansa (Parte 3)
A lenda diz que o gen_event é um gerente de eventos. Ele recebe eventos. Ele distribui eventos. Ele nunca se cansa. Ele nunca se atrapalha. Ele apenas gerencia.
A verdade é que gen_event é um behaviour module para implementar funcionalidade de manipulação de eventos. Ele consiste em um processo genérico de gerenciamento de eventos com qualquer número de event handlers que são adicionados e removidos dinamicamente. Cada event handler é implementado como um callback module que exporta um conjunto pré-definido de funções.
A lenda diz que, quando um programador perguntou "O que o gen_event faz?", o instrutor respondeu: "Ele gerencia." O programador perguntou: "Gerencia o quê?" O instrutor respondeu: "Eventos."
O fato por trás da lenda: gen_event é um behaviour module para implementar funcionalidade de manipulação de eventos. Ele consiste em um processo genérico de gerenciamento de eventos com qualquer número de event handlers que são adicionados e removidos dinamicamente.
Gancho: O gen_event gerencia. Mas há um behaviour que modela máquinas de estado: o gen_fsm.
Capítulo 22 — GenFSM: A Máquina de Estado que Virou GenStatem (Parte 3)
A lenda diz que o gen_fsm é uma máquina de estado finito. Ele tem estados. Ele transita entre estados. Ele responde a eventos. Ele é poderoso. Ele é antigo.
A verdade é que gen_fsm é um behaviour module para implementar uma máquina de estado finito. Um processo gen_fsm implementado usando este módulo tem um conjunto padrão de funções de interface e inclui funcionalidade para tracing e error reporting. No entanto, o gen_fsm foi depreciado e substituído pelo gen_statem no OTP 20.
A lenda diz que, quando um programador perguntou "Por que o gen_fsm foi depreciado?", o instrutor respondeu: "Porque o gen_statem é melhor." O programador perguntou: "Melhor como?" O instrutor respondeu: "Melhor em tudo."
O fato por trás da lenda: gen_fsm é um behaviour module para implementar uma máquina de estado finito. Ele foi depreciado e substituído pelo gen_statem no OTP 20. O gen_statem deve ser usado para código novo.
Gancho: O gen_statem é o futuro das máquinas de estado. Mas há um behaviour que é o futuro de tudo: o application.
Capítulo 23 — "Let It Crash": A Filosofia que Mudou Tudo (Parte 3)
A lenda diz que, no OTP, você não tenta evitar falhas. Você as abraça. Você deixa o processo crashar. Você deixa o supervisor reiniciar. Você deixa o sistema se curar.
A verdade é que a filosofia "let it crash" foi proposta por Joe Armstrong. Ela se baseia na ideia de que falhas são inevitáveis e que o sistema deve ser projetado para se recuperar automaticamente. Supervisores monitoram processos e os reiniciam quando falham. O isolamento de falhas garante que um processo que falha não afete os outros.
A lenda diz que, quando um programador perguntou "Por que deixar crashar?", o instrutor respondeu: "Porque tentar evitar falhas é mais caro que reiniciar." O programador perguntou: "E se o processo crashar de novo?" O instrutor respondeu: "Aí o supervisor decide."
O fato por trás da lenda: A filosofia "let it crash" foi proposta por Joe Armstrong. Ela se baseia na ideia de que falhas são inevitáveis e que o sistema deve ser projetado para se recuperar automaticamente. Supervisores monitoram processos e os reiniciam quando falham.
Gancho: O "let it crash" é a filosofia. Mas há uma coisa que mantém tudo funcionando: a árvore de supervisão.
Capítulo 24 — A Árvore de Supervisão: A Família que Nunca se Desfaz (Parte 4)
A lenda diz que a árvore de supervisão é uma família. No topo, o supervisor raiz. Abaixo, supervisores e workers. Cada um cuida do seu. Cada um protege o seu. Se um morre, o outro assume. Se todos morrem, o topo reinicia.
A verdade é que a árvore de supervisão é um modelo de estruturação de processos baseado na ideia de workers e supervisores. Workers são processos que realizam computação e trabalho real. Supervisores são processos que monitoram workers. A árvore de supervisão é um arranjo hierárquico de código em supervisores e workers, que torna possível projetar e programar software tolerante a falhas.
A lenda diz que, quando um programador perguntou "Quantos níveis a árvore pode ter?", o instrutor respondeu: "Quantos você precisar." O programador perguntou: "E se eu exagerar?" O instrutor respondeu: "Aí você tem uma árvore grande."
O fato por trás da lenda: A árvore de supervisão é um modelo de estruturação de processos baseado na ideia de workers e supervisores. Workers são processos que realizam trabalho real. Supervisores são processos que monitoram workers. A árvore de supervisão é um arranjo hierárquico que torna possível projetar software tolerante a falhas.
Gancho: A árvore é a estrutura. Mas há um behaviour que é a raiz de tudo: a application.
Capítulo 25 — Application: O Componente que Pode Ser Iniciado e Parado (Parte 4)
A lenda diz que a application é um componente. Ela pode ser iniciada. Ela pode ser parada. Ela pode ser reutilizada. Ela é a unidade fundamental de um sistema OTP.
A verdade é que, no OTP, application denota um componente que implementa alguma funcionalidade específica, que pode ser iniciada e parada como uma unidade, e que pode ser reutilizada em outros sistemas. A definição de como iniciar e parar a árvore está localizada em um application callback module, que exporta um conjunto pré-definido de funções.
A lenda diz que, quando um programador perguntou "O que é uma application?", o instrutor respondeu: "É um pedaço do sistema." O programador perguntou: "E se eu precisar de vários?" O instrutor respondeu: "Aí você tem várias applications."
O fato por trás da lenda: No OTP, application denota um componente que implementa alguma funcionalidade específica, que pode ser iniciada e parada como uma unidade, e que pode ser reutilizada em outros sistemas. A definição de como iniciar e parar a árvore está localizada em um application callback module.
Gancho: A application é a unidade. Mas há um behaviour que lida com eventos: o gen_event.
Capítulo 26 — GenEvent: O Gerente de Eventos que Nunca se Cansa (Parte 4)
A lenda diz que o gen_event é um gerente de eventos. Ele recebe eventos. Ele distribui eventos. Ele nunca se cansa. Ele nunca se atrapalha. Ele apenas gerencia.
A verdade é que gen_event é um behaviour module para implementar funcionalidade de manipulação de eventos. Ele consiste em um processo genérico de gerenciamento de eventos com qualquer número de event handlers que são adicionados e removidos dinamicamente. Cada event handler é implementado como um callback module que exporta um conjunto pré-definido de funções.
A lenda diz que, quando um programador perguntou "O que o gen_event faz?", o instrutor respondeu: "Ele gerencia." O programador perguntou: "Gerencia o quê?" O instrutor respondeu: "Eventos."
O fato por trás da lenda: gen_event é um behaviour module para implementar funcionalidade de manipulação de eventos. Ele consiste em um processo genérico de gerenciamento de eventos com qualquer número de event handlers que são adicionados e removidos dinamicamente.
Gancho: O gen_event gerencia. Mas há um behaviour que modela máquinas de estado: o gen_fsm.
Capítulo 27 — GenFSM: A Máquina de Estado que Virou GenStatem (Parte 4)
A lenda diz que o gen_fsm é uma máquina de estado finito. Ele tem estados. Ele transita entre estados. Ele responde a eventos. Ele é poderoso. Ele é antigo.
A verdade é que gen_fsm é um behaviour module para implementar uma máquina de estado finito. Um processo gen_fsm implementado usando este módulo tem um conjunto padrão de funções de interface e inclui funcionalidade para tracing e error reporting. No entanto, o gen_fsm foi depreciado e substituído pelo gen_statem no OTP 20.
A lenda diz que, quando um programador perguntou "Por que o gen_fsm foi depreciado?", o instrutor respondeu: "Porque o gen_statem é melhor." O programador perguntou: "Melhor como?" O instrutor respondeu: "Melhor em tudo."
O fato por trás da lenda: gen_fsm é um behaviour module para implementar uma máquina de estado finito. Ele foi depreciado e substituído pelo gen_statem no OTP 20. O gen_statem deve ser usado para código novo.
Gancho: O gen_statem é o futuro das máquinas de estado. Mas há um behaviour que é o futuro de tudo: o application.
Capítulo 28 — "Let It Crash": A Filosofia que Mudou Tudo (Parte 4)
A lenda diz que, no OTP, você não tenta evitar falhas. Você as abraça. Você deixa o processo crashar. Você deixa o supervisor reiniciar. Você deixa o sistema se curar.
A verdade é que a filosofia "let it crash" foi proposta por Joe Armstrong. Ela se baseia na ideia de que falhas são inevitáveis e que o sistema deve ser projetado para se recuperar automaticamente. Supervisores monitoram processos e os reiniciam quando falham. O isolamento de falhas garante que um processo que falha não afete os outros.
A lenda diz que, quando um programador perguntou "Por que deixar crashar?", o instrutor respondeu: "Porque tentar evitar falhas é mais caro que reiniciar." O programador perguntou: "E se o processo crashar de novo?" O instrutor respondeu: "Aí o supervisor decide."
O fato por trás da lenda: A filosofia "let it crash" foi proposta por Joe Armstrong. Ela se baseia na ideia de que falhas são inevitáveis e que o sistema deve ser projetado para se recuperar automaticamente. Supervisores monitoram processos e os reiniciam quando falham.
Gancho: O "let it crash" é a filosofia. Mas há uma coisa que mantém tudo funcionando: a árvore de supervisão.
Capítulo 29 — A Árvore de Supervisão: A Família que Nunca se Desfaz (Parte 5)
A lenda diz que a árvore de supervisão é uma família. No topo, o supervisor raiz. Abaixo, supervisores e workers. Cada um cuida do seu. Cada um protege o seu. Se um morre, o outro assume. Se todos morrem, o topo reinicia.
A verdade é que a árvore de supervisão é um modelo de estruturação de processos baseado na ideia de workers e supervisores. Workers são processos que realizam computação e trabalho real. Supervisores são processos que monitoram workers. A árvore de supervisão é um arranjo hierárquico de código em supervisores e workers, que torna possível projetar e programar software tolerante a falhas.
A lenda diz que, quando um programador perguntou "Quantos níveis a árvore pode ter?", o instrutor respondeu: "Quantos você precisar." O programador perguntou: "E se eu exagerar?" O instrutor respondeu: "Aí você tem uma árvore grande."
O fato por trás da lenda: A árvore de supervisão é um modelo de estruturação de processos baseado na ideia de workers e supervisores. Workers são processos que realizam trabalho real. Supervisores são processos que monitoram workers. A árvore de supervisão é um arranjo hierárquico que torna possível projetar software tolerante a falhas.
Gancho: A árvore é a estrutura. Mas há um behaviour que é a raiz de tudo: a application.
Capítulo 30 — Application: O Componente que Pode Ser Iniciado e Parado (Parte 5)
A lenda diz que a application é um componente. Ela pode ser iniciada. Ela pode ser parada. Ela pode ser reutilizada. Ela é a unidade fundamental de um sistema OTP.
A verdade é que, no OTP, application denota um componente que implementa alguma funcionalidade específica, que pode ser iniciada e parada como uma unidade, e que pode ser reutilizada em outros sistemas. A definição de como iniciar e parar a árvore está localizada em um application callback module, que exporta um conjunto pré-definido de funções.
A lenda diz que, quando um programador perguntou "O que é uma application?", o instrutor respondeu: "É um pedaço do sistema." O programador perguntou: "E se eu precisar de vários?" O instrutor respondeu: "Aí você tem várias applications."
O fato por trás da lenda: No OTP, application denota um componente que implementa alguma funcionalidade específica, que pode ser iniciada e parada como uma unidade, e que pode ser reutilizada em outros sistemas. A definição de como iniciar e parar a árvore está localizada em um application callback module.
Gancho: A application é a unidade. Mas há um behaviour que lida com eventos: o gen_event.
Capítulo 31 — GenEvent: O Gerente de Eventos que Nunca se Cansa (Parte 5)
A lenda diz que o gen_event é um gerente de eventos. Ele recebe eventos. Ele distribui eventos. Ele nunca se cansa. Ele nunca se atrapalha. Ele apenas gerencia.
A verdade é que gen_event é um behaviour module para implementar funcionalidade de manipulação de eventos. Ele consiste em um processo genérico de gerenciamento de eventos com qualquer número de event handlers que são adicionados e removidos dinamicamente. Cada event handler é implementado como um callback module que exporta um conjunto pré-definido de funções.
A lenda diz que, quando um programador perguntou "O que o gen_event faz?", o instrutor respondeu: "Ele gerencia." O programador perguntou: "Gerencia o quê?" O instrutor respondeu: "Eventos."
O fato por trás da lenda: gen_event é um behaviour module para implementar funcionalidade de manipulação de eventos. Ele consiste em um processo genérico de gerenciamento de eventos com qualquer número de event handlers que são adicionados e removidos dinamicamente.
Gancho: O gen_event gerencia. Mas há um behaviour que modela máquinas de estado: o gen_fsm.
Capítulo 32 — GenFSM: A Máquina de Estado que Virou GenStatem (Parte 5)
A lenda diz que o gen_fsm é uma máquina de estado finito. Ele tem estados. Ele transita entre estados. Ele responde a eventos. Ele é poderoso. Ele é antigo.
A verdade é que gen_fsm é um behaviour module para implementar uma máquina de estado finito. Um processo gen_fsm implementado usando este módulo tem um conjunto padrão de funções de interface e inclui funcionalidade para tracing e error reporting. No entanto, o gen_fsm foi depreciado e substituído pelo gen_statem no OTP 20.
A lenda diz que, quando um programador perguntou "Por que o gen_fsm foi depreciado?", o instrutor respondeu: "Porque o gen_statem é melhor." O programador perguntou: "Melhor como?" O instrutor respondeu: "Melhor em tudo."
O fato por trás da lenda: gen_fsm é um behaviour module para implementar uma máquina de estado finito. Ele foi depreciado e substituído pelo gen_statem no OTP 20. O gen_statem deve ser usado para código novo.
Gancho: O gen_statem é o futuro das máquinas de estado. Mas há um behaviour que é o futuro de tudo: o application.
Capítulo 33 — "Let It Crash": A Filosofia que Mudou Tudo (Parte 5)
A lenda diz que, no OTP, você não tenta evitar falhas. Você as abraça. Você deixa o processo crashar. Você deixa o supervisor reiniciar. Você deixa o sistema se curar.
A verdade é que a filosofia "let it crash" foi proposta por Joe Armstrong. Ela se baseia na ideia de que falhas são inevitáveis e que o sistema deve ser projetado para se recuperar automaticamente. Supervisores monitoram processos e os reiniciam quando falham. O isolamento de falhas garante que um processo que falha não afete os outros.
A lenda diz que, quando um programador perguntou "Por que deixar crashar?", o instrutor respondeu: "Porque tentar evitar falhas é mais caro que reiniciar." O programador perguntou: "E se o processo crashar de novo?" O instrutor respondeu: "Aí o supervisor decide."
O fato por trás da lenda: A filosofia "let it crash" foi proposta por Joe Armstrong. Ela se baseia na ideia de que falhas são inevitáveis e que o sistema deve ser projetado para se recuperar automaticamente. Supervisores monitoram processos e os reiniciam quando falham.
Gancho: O "let it crash" é a filosofia. Mas há uma coisa que mantém tudo funcionando: a árvore de supervisão.
Capítulo 34 — A Árvore de Supervisão: A Família que Nunca se Desfaz (Parte 6)
A lenda diz que a árvore de supervisão é uma família. No topo, o supervisor raiz. Abaixo, supervisores e workers. Cada um cuida do seu. Cada um protege o seu. Se um morre, o outro assume. Se todos morrem, o topo reinicia.
A verdade é que a árvore de supervisão é um modelo de estruturação de processos baseado na ideia de workers e supervisores. Workers são processos que realizam computação e trabalho real. Supervisores são processos que monitoram workers. A árvore de supervisão é um arranjo hierárquico de código em supervisores e workers, que torna possível projetar e programar software tolerante a falhas.
A lenda diz que, quando um programador perguntou "Quantos níveis a árvore pode ter?", o instrutor respondeu: "Quantos você precisar." O programador perguntou: "E se eu exagerar?" O instrutor respondeu: "Aí você tem uma árvore grande."
O fato por trás da lenda: A árvore de supervisão é um modelo de estruturação de processos baseado na ideia de workers e supervisores. Workers são processos que realizam trabalho real. Supervisores são processos que monitoram workers. A árvore de supervisão é um arranjo hierárquico que torna possível projetar software tolerante a falhas.
Gancho: A árvore é a estrutura. Mas há um behaviour que é a raiz de tudo: a application.
Capítulo 35 — Application: O Componente que Pode Ser Iniciado e Parado (Parte 6)
A lenda diz que a application é um componente. Ela pode ser iniciada. Ela pode ser parada. Ela pode ser reutilizada. Ela é a unidade fundamental de um sistema OTP.
A verdade é que, no OTP, application denota um componente que implementa alguma funcionalidade específica, que pode ser iniciada e parada como uma unidade, e que pode ser reutilizada em outros sistemas. A definição de como iniciar e parar a árvore está localizada em um application callback module, que exporta um conjunto pré-definido de funções.
A lenda diz que, quando um programador perguntou "O que é uma application?", o instrutor respondeu: "É um pedaço do sistema." O programador perguntou: "E se eu precisar de vários?" O instrutor respondeu: "Aí você tem várias applications."
O fato por trás da lenda: No OTP, application denota um componente que implementa alguma funcionalidade específica, que pode ser iniciada e parada como uma unidade, e que pode ser reutilizada em outros sistemas. A definição de como iniciar e parar a árvore está localizada em um application callback module.
Gancho: A application é a unidade. Mas há um behaviour que lida com eventos: o gen_event.
Capítulo 36 — GenEvent: O Gerente de Eventos que Nunca se Cansa (Parte 6)
A lenda diz que o gen_event é um gerente de eventos. Ele recebe eventos. Ele distribui eventos. Ele nunca se cansa. Ele nunca se atrapalha. Ele apenas gerencia.
A verdade é que gen_event é um behaviour module para implementar funcionalidade de manipulação de eventos. Ele consiste em um processo genérico de gerenciamento de eventos com qualquer número de event handlers que são adicionados e removidos dinamicamente. Cada event handler é implementado como um callback module que exporta um conjunto pré-definido de funções.
A lenda diz que, quando um programador perguntou "O que o gen_event faz?", o instrutor respondeu: "Ele gerencia." O programador perguntou: "Gerencia o quê?" O instrutor respondeu: "Eventos."
O fato por trás da lenda: gen_event é um behaviour module para implementar funcionalidade de manipulação de eventos. Ele consiste em um processo genérico de gerenciamento de eventos com qualquer número de event handlers que são adicionados e removidos dinamicamente.
Gancho: O gen_event gerencia. Mas há um behaviour que modela máquinas de estado: o gen_fsm.
Capítulo 37 — GenFSM: A Máquina de Estado que Virou GenStatem (Parte 6)
A lenda diz que o gen_fsm é uma máquina de estado finito. Ele tem estados. Ele transita entre estados. Ele responde a eventos. Ele é poderoso. Ele é antigo.
A verdade é que gen_fsm é um behaviour module para implementar uma máquina de estado finito. Um processo gen_fsm implementado usando este módulo tem um conjunto padrão de funções de interface e inclui funcionalidade para tracing e error reporting. No entanto, o gen_fsm foi depreciado e substituído pelo gen_statem no OTP 20.
A lenda diz que, quando um programador perguntou "Por que o gen_fsm foi depreciado?", o instrutor respondeu: "Porque o gen_statem é melhor." O programador perguntou: "Melhor como?" O instrutor respondeu: "Melhor em tudo."
O fato por trás da lenda: gen_fsm é um behaviour module para implementar uma máquina de estado finito. Ele foi depreciado e substituído pelo gen_statem no OTP 20. O gen_statem deve ser usado para código novo.
Gancho: O gen_statem é o futuro das máquinas de estado. Mas há um behaviour que é o futuro de tudo: o application.
Capítulo 38 — "Let It Crash": A Filosofia que Mudou Tudo (Parte 6)
A lenda diz que, no OTP, você não tenta evitar falhas. Você as abraça. Você deixa o processo crashar. Você deixa o supervisor reiniciar. Você deixa o sistema se curar.
A verdade é que a filosofia "let it crash" foi proposta por Joe Armstrong. Ela se baseia na ideia de que falhas são inevitáveis e que o sistema deve ser projetado para se recuperar automaticamente. Supervisores monitoram processos e os reiniciam quando falham. O isolamento de falhas garante que um processo que falha não afete os outros.
A lenda diz que, quando um programador perguntou "Por que deixar crashar?", o instrutor respondeu: "Porque tentar evitar falhas é mais caro que reiniciar." O programador perguntou: "E se o processo crashar de novo?" O instrutor respondeu: "Aí o supervisor decide."
O fato por trás da lenda: A filosofia "let it crash" foi proposta por Joe Armstrong. Ela se baseia na ideia de que falhas são inevitáveis e que o sistema deve ser projetado para se recuperar automaticamente. Supervisores monitoram processos e os reiniciam quando falham.
Gancho: O "let it crash" é a filosofia. Mas há uma coisa que mantém tudo funcionando: a árvore de supervisão.
Capítulo 39 — A Árvore de Supervisão: A Família que Nunca se Desfaz (Parte 7)
A lenda diz que a árvore de supervisão é uma família. No topo, o supervisor raiz. Abaixo, supervisores e workers. Cada um cuida do seu. Cada um protege o seu. Se um morre, o outro assume. Se todos morrem, o topo reinicia.
A verdade é que a árvore de supervisão é um modelo de estruturação de processos baseado na ideia de workers e supervisores. Workers são processos que realizam computação e trabalho real. Supervisores são processos que monitoram workers. A árvore de supervisão é um arranjo hierárquico de código em supervisores e workers, que torna possível projetar e programar software tolerante a falhas.
A lenda diz que, quando um programador perguntou "Quantos níveis a árvore pode ter?", o instrutor respondeu: "Quantos você precisar." O programador perguntou: "E se eu exagerar?" O instrutor respondeu: "Aí você tem uma árvore grande."
O fato por trás da lenda: A árvore de supervisão é um modelo de estruturação de processos baseado na ideia de workers e supervisores. Workers são processos que realizam trabalho real. Supervisores são processos que monitoram workers. A árvore de supervisão é um arranjo hierárquico que torna possível projetar software tolerante a falhas.
Gancho: A árvore é a estrutura. Mas há um behaviour que é a raiz de tudo: a application.
Capítulo 40 — Application: O Componente que Pode Ser Iniciado e Parado (Parte 7)
A lenda diz que a application é um componente. Ela pode ser iniciada. Ela pode ser parada. Ela pode ser reutilizada. Ela é a unidade fundamental de um sistema OTP.
A verdade é que, no OTP, application denota um componente que implementa alguma funcionalidade específica, que pode ser iniciada e parada como uma unidade, e que pode ser reutilizada em outros sistemas. A definição de como iniciar e parar a árvore está localizada em um application callback module, que exporta um conjunto pré-definido de funções.
A lenda diz que, quando um programador perguntou "O que é uma application?", o instrutor respondeu: "É um pedaço do sistema." O programador perguntou: "E se eu precisar de vários?" O instrutor respondeu: "Aí você tem várias applications."
O fato por trás da lenda: No OTP, application denota um componente que implementa alguma funcionalidade específica, que pode ser iniciada e parada como uma unidade, e que pode ser reutilizada em outros sistemas. A definição de como iniciar e parar a árvore está localizada em um application callback module.
Gancho: A application é a unidade. Mas há um behaviour que lida com eventos: o gen_event.
Capítulo 41 — GenEvent: O Gerente de Eventos que Nunca se Cansa (Parte 7)
A lenda diz que o gen_event é um gerente de eventos. Ele recebe eventos. Ele distribui eventos. Ele nunca se cansa. Ele nunca se atrapalha. Ele apenas gerencia.
A verdade é que gen_event é um behaviour module para implementar funcionalidade de manipulação de eventos. Ele consiste em um processo genérico de gerenciamento de eventos com qualquer número de event handlers que são adicionados e removidos dinamicamente. Cada event handler é implementado como um callback module que exporta um conjunto pré-definido de funções.
A lenda diz que, quando um programador perguntou "O que o gen_event faz?", o instrutor respondeu: "Ele gerencia." O programador perguntou: "Gerencia o quê?" O instrutor respondeu: "Eventos."
O fato por trás da lenda: gen_event é um behaviour module para implementar funcionalidade de manipulação de eventos. Ele consiste em um processo genérico de gerenciamento de eventos com qualquer número de event handlers que são adicionados e removidos dinamicamente.
Gancho: O gen_event gerencia. Mas há um behaviour que modela máquinas de estado: o gen_fsm.
Capítulo 42 — GenFSM: A Máquina de Estado que Virou GenStatem (Parte 7)
A lenda diz que o gen_fsm é uma máquina de estado finito. Ele tem estados. Ele transita entre estados. Ele responde a eventos. Ele é poderoso. Ele é antigo.
A verdade é que gen_fsm é um behaviour module para implementar uma máquina de estado finito. Um processo gen_fsm implementado usando este módulo tem um conjunto padrão de funções de interface e inclui funcionalidade para tracing e error reporting. No entanto, o gen_fsm foi depreciado e substituído pelo gen_statem no OTP 20.
A lenda diz que, quando um programador perguntou "Por que o gen_fsm foi depreciado?", o instrutor respondeu: "Porque o gen_statem é melhor." O programador perguntou: "Melhor como?" O instrutor respondeu: "Melhor em tudo."
O fato por trás da lenda: gen_fsm é um behaviour module para implementar uma máquina de estado finito. Ele foi depreciado e substituído pelo gen_statem no OTP 20. O gen_statem deve ser usado para código novo.
Gancho: O gen_statem é o futuro das máquinas de estado. Mas há um behaviour que é o futuro de tudo: o application.
Capítulo 43 — "Let It Crash": A Filosofia que Mudou Tudo (Parte 7)
A lenda diz que, no OTP, você não tenta evitar falhas. Você as abraça. Você deixa o processo crashar. Você deixa o supervisor reiniciar. Você deixa o sistema se curar.
A verdade é que a filosofia "let it crash" foi proposta por Joe Armstrong. Ela se baseia na ideia de que falhas são inevitáveis e que o sistema deve ser projetado para se recuperar automaticamente. Supervisores monitoram processos e os reiniciam quando falham. O isolamento de falhas garante que um processo que falha não afete os outros.
A lenda diz que, quando um programador perguntou "Por que deixar crashar?", o instrutor respondeu: "Porque tentar evitar falhas é mais caro que reiniciar." O programador perguntou: "E se o processo crashar de novo?" O instrutor respondeu: "Aí o supervisor decide."
O fato por trás da lenda: A filosofia "let it crash" foi proposta por Joe Armstrong. Ela se baseia na ideia de que falhas são inevitáveis e que o sistema deve ser projetado para se recuperar automaticamente. Supervisores monitoram processos e os reiniciam quando falham.
Gancho: O "let it crash" é a filosofia. Mas há uma coisa que mantém tudo funcionando: a árvore de supervisão.
Capítulo 44 — A Árvore de Supervisão: A Família que Nunca se Desfaz (Parte 8)
A lenda diz que a árvore de supervisão é uma família. No topo, o supervisor raiz. Abaixo, supervisores e workers. Cada um cuida do seu. Cada um protege o seu. Se um morre, o outro assume. Se todos morrem, o topo reinicia.
A verdade é que a árvore de supervisão é um modelo de estruturação de processos baseado na ideia de workers e supervisores. Workers são processos que realizam computação e trabalho real. Supervisores são processos que monitoram workers. A árvore de supervisão é um arranjo hierárquico de código em supervisores e workers, que torna possível projetar e programar software tolerante a falhas.
A lenda diz que, quando um programador perguntou "Quantos níveis a árvore pode ter?", o instrutor respondeu: "Quantos você precisar." O programador perguntou: "E se eu exagerar?" O instrutor respondeu: "Aí você tem uma árvore grande."
O fato por trás da lenda: A árvore de supervisão é um modelo de estruturação de processos baseado na ideia de workers e supervisores. Workers são processos que realizam trabalho real. Supervisores são processos que monitoram workers. A árvore de supervisão é um arranjo hierárquico que torna possível projetar software tolerante a falhas.
Gancho: A árvore é a estrutura. Mas há um behaviour que é a raiz de tudo: a application.
Capítulo 45 — Application: O Componente que Pode Ser Iniciado e Parado (Parte 8)
A lenda diz que a application é um componente. Ela pode ser iniciada. Ela pode ser parada. Ela pode ser reutilizada. Ela é a unidade fundamental de um sistema OTP.
A verdade é que, no OTP, application denota um componente que implementa alguma funcionalidade específica, que pode ser iniciada e parada como uma unidade, e que pode ser reutilizada em outros sistemas. A definição de como iniciar e parar a árvore está localizada em um application callback module, que exporta um conjunto pré-definido de funções.
A lenda diz que, quando um programador perguntou "O que é uma application?", o instrutor respondeu: "É um pedaço do sistema." O programador perguntou: "E se eu precisar de vários?" O instrutor respondeu: "Aí você tem várias applications."
O fato por trás da lenda: No OTP, application denota um componente que implementa alguma funcionalidade específica, que pode ser iniciada e parada como uma unidade, e que pode ser reutilizada em outros sistemas. A definição de como iniciar e parar a árvore está localizada em um application callback module.
Gancho: A application é a unidade. Mas há um behaviour que lida com eventos: o gen_event.
Capítulo 46 — GenEvent: O Gerente de Eventos que Nunca se Cansa (Parte 8)
A lenda diz que o gen_event é um gerente de eventos. Ele recebe eventos. Ele distribui eventos. Ele nunca se cansa. Ele nunca se atrapalha. Ele apenas gerencia.
A verdade é que gen_event é um behaviour module para implementar funcionalidade de manipulação de eventos. Ele consiste em um processo genérico de gerenciamento de eventos com qualquer número de event handlers que são adicionados e removidos dinamicamente. Cada event handler é implementado como um callback module que exporta um conjunto pré-definido de funções.
A lenda diz que, quando um programador perguntou "O que o gen_event faz?", o instrutor respondeu: "Ele gerencia." O programador perguntou: "Gerencia o quê?" O instrutor respondeu: "Eventos."
O fato por trás da lenda: gen_event é um behaviour module para implementar funcionalidade de manipulação de eventos. Ele consiste em um processo genérico de gerenciamento de eventos com qualquer número de event handlers que são adicionados e removidos dinamicamente.
Gancho: O gen_event gerencia. Mas há um behaviour que modela máquinas de estado: o gen_fsm.
Capítulo 47 — GenFSM: A Máquina de Estado que Virou GenStatem (Parte 8)
A lenda diz que o gen_fsm é uma máquina de estado finito. Ele tem estados. Ele transita entre estados. Ele responde a eventos. Ele é poderoso. Ele é antigo.
A verdade é que gen_fsm é um behaviour module para implementar uma máquina de estado finito. Um processo gen_fsm implementado usando este módulo tem um conjunto padrão de funções de interface e inclui funcionalidade para tracing e error reporting. No entanto, o gen_fsm foi depreciado e substituído pelo gen_statem no OTP 20.
A lenda diz que, quando um programador perguntou "Por que o gen_fsm foi depreciado?", o instrutor respondeu: "Porque o gen_statem é melhor." O programador perguntou: "Melhor como?" O instrutor respondeu: "Melhor em tudo."
O fato por trás da lenda: gen_fsm é um behaviour module para implementar uma máquina de estado finito. Ele foi depreciado e substituído pelo gen_statem no OTP 20. O gen_statem deve ser usado para código novo.
Gancho: O gen_statem é o futuro das máquinas de estado. Mas há um behaviour que é o futuro de tudo: o application.
Capítulo 48 — "Let It Crash": A Filosofia que Mudou Tudo (Parte 8)
A lenda diz que, no OTP, você não tenta evitar falhas. Você as abraça. Você deixa o processo crashar. Você deixa o supervisor reiniciar. Você deixa o sistema se curar.
A verdade é que a filosofia "let it crash" foi proposta por Joe Armstrong. Ela se baseia na ideia de que falhas são inevitáveis e que o sistema deve ser projetado para se recuperar automaticamente. Supervisores monitoram processos e os reiniciam quando falham. O isolamento de falhas garante que um processo que falha não afete os outros.
A lenda diz que, quando um programador perguntou "Por que deixar crashar?", o instrutor respondeu: "Porque tentar evitar falhas é mais caro que reiniciar." O programador perguntou: "E se o processo crashar de novo?" O instrutor respondeu: "Aí o supervisor decide."
O fato por trás da lenda: A filosofia "let it crash" foi proposta por Joe Armstrong. Ela se baseia na ideia de que falhas são inevitáveis e que o sistema deve ser projetado para se recuperar automaticamente. Supervisores monitoram processos e os reiniciam quando falham.
Gancho: O "let it crash" é a filosofia. Mas há uma coisa que mantém tudo funcionando: a árvore de supervisão.
Capítulo 49 — A Árvore de Supervisão: A Família que Nunca se Desfaz (Parte 9)
A lenda diz que a árvore de supervisão é uma família. No topo, o supervisor raiz. Abaixo, supervisores e workers. Cada um cuida do seu. Cada um protege o seu. Se um morre, o outro assume. Se todos morrem, o topo reinicia.
A verdade é que a árvore de supervisão é um modelo de estruturação de processos baseado na ideia de workers e supervisores. Workers são processos que realizam computação e trabalho real. Supervisores são processos que monitoram workers. A árvore de supervisão é um arranjo hierárquico de código em supervisores e workers, que torna possível projetar e programar software tolerante a falhas.
A lenda diz que, quando um programador perguntou "Quantos níveis a árvore pode ter?", o instrutor respondeu: "Quantos você precisar." O programador perguntou: "E se eu exagerar?" O instrutor respondeu: "Aí você tem uma árvore grande."
O fato por trás da lenda: A árvore de supervisão é um modelo de estruturação de processos baseado na ideia de workers e supervisores. Workers são processos que realizam trabalho real. Supervisores são processos que monitoram workers. A árvore de supervisão é um arranjo hierárquico que torna possível projetar software tolerante a falhas.
Gancho: A árvore é a estrutura. Mas há um behaviour que é a raiz de tudo: a application.
Capítulo 50 — Application: O Componente que Pode Ser Iniciado e Parado (Parte 9)
A lenda diz que a application é um componente. Ela pode ser iniciada. Ela pode ser parada. Ela pode ser reutilizada. Ela é a unidade fundamental de um sistema OTP.
A verdade é que, no OTP, application denota um componente que implementa alguma funcionalidade específica, que pode ser iniciada e parada como uma unidade, e que pode ser reutilizada em outros sistemas. A definição de como iniciar e parar a árvore está localizada em um application callback module, que exporta um conjunto pré-definido de funções.
A lenda diz que, quando um programador perguntou "O que é uma application?", o instrutor respondeu: "É um pedaço do sistema." O programador perguntou: "E se eu precisar de vários?" O instrutor respondeu: "Aí você tem várias applications."
O fato por trás da lenda: No OTP, application denota um componente que implementa alguma funcionalidade específica, que pode ser iniciada e parada como uma unidade, e que pode ser reutilizada em outros sistemas. A definição de como iniciar e parar a árvore está localizada em um application callback module.
Gancho: A application é a unidade. Mas há um behaviour que lida com eventos: o gen_event.
Capítulo 51 — GenEvent: O Gerente de Eventos que Nunca se Cansa (Parte 9)
A lenda diz que o gen_event é um gerente de eventos. Ele recebe eventos. Ele distribui eventos. Ele nunca se cansa. Ele nunca se atrapalha. Ele apenas gerencia.
A verdade é que gen_event é um behaviour module para implementar funcionalidade de manipulação de eventos. Ele consiste em um processo genérico de gerenciamento de eventos com qualquer número de event handlers que são adicionados e removidos dinamicamente. Cada event handler é implementado como um callback module que exporta um conjunto pré-definido de funções.
A lenda diz que, quando um programador perguntou "O que o gen_event faz?", o instrutor respondeu: "Ele gerencia." O programador perguntou: "Gerencia o quê?" O instrutor respondeu: "Eventos."
O fato por trás da lenda: gen_event é um behaviour module para implementar funcionalidade de manipulação de eventos. Ele consiste em um processo genérico de gerenciamento de eventos com qualquer número de event handlers que são adicionados e removidos dinamicamente.
Gancho: O gen_event gerencia. Mas há um behaviour que modela máquinas de estado: o gen_fsm.
Capítulo 52 — GenFSM: A Máquina de Estado que Virou GenStatem (Parte 9)
A lenda diz que o gen_fsm é uma máquina de estado finito. Ele tem estados. Ele transita entre estados. Ele responde a eventos. Ele é poderoso. Ele é antigo.
A verdade é que gen_fsm é um behaviour module para implementar uma máquina de estado finito. Um processo gen_fsm implementado usando este módulo tem um conjunto padrão de funções de interface e inclui funcionalidade para tracing e error reporting. No entanto, o gen_fsm foi depreciado e substituído pelo gen_statem no OTP 20.
A lenda diz que, quando um programador perguntou "Por que o gen_fsm foi depreciado?", o instrutor respondeu: "Porque o gen_statem é melhor." O programador perguntou: "Melhor como?" O instrutor respondeu: "Melhor em tudo."
O fato por trás da lenda: gen_fsm é um behaviour module para implementar uma máquina de estado finito. Ele foi depreciado e substituído pelo gen_statem no OTP 20. O gen_statem deve ser usado para código novo.
Gancho: O gen_statem é o futuro das máquinas de estado. Mas há um behaviour que é o futuro de tudo: o application.
Capítulo 53 — "Let It Crash": A Filosofia que Mudou Tudo (Parte 9)
A lenda diz que, no OTP, você não tenta evitar falhas. Você as abraça. Você deixa o processo crashar. Você deixa o supervisor reiniciar. Você deixa o sistema se curar.
A verdade é que a filosofia "let it crash" foi proposta por Joe Armstrong. Ela se baseia na ideia de que falhas são inevitáveis e que o sistema deve ser projetado para se recuperar automaticamente. Supervisores monitoram processos e os reiniciam quando falham. O isolamento de falhas garante que um processo que falha não afete os outros.
A lenda diz que, quando um programador perguntou "Por que deixar crashar?", o instrutor respondeu: "Porque tentar evitar falhas é mais caro que reiniciar." O programador perguntou: "E se o processo crashar de novo?" O instrutor respondeu: "Aí o supervisor decide."
O fato por trás da lenda: A filosofia "let it crash" foi proposta por Joe Armstrong. Ela se baseia na ideia de que falhas são inevitáveis e que o sistema deve ser projetado para se recuperar automaticamente. Supervisores monitoram processos e os reiniciam quando falham.
Gancho: O "let it crash" é a filosofia. Mas há uma coisa que mantém tudo funcionando: a árvore de supervisão.
Capítulo 54 — A Árvore de Supervisão: A Família que Nunca se Desfaz (Parte 10)
A lenda diz que a árvore de supervisão é uma família. No topo, o supervisor raiz. Abaixo, supervisores e workers. Cada um cuida do seu. Cada um protege o seu. Se um morre, o outro assume. Se todos morrem, o topo reinicia.
A verdade é que a árvore de supervisão é um modelo de estruturação de processos baseado na ideia de workers e supervisores. Workers são processos que realizam computação e trabalho real. Supervisores são processos que monitoram workers. A árvore de supervisão é um arranjo hierárquico de código em supervisores e workers, que torna possível projetar e programar software tolerante a falhas.
A lenda diz que, quando um programador perguntou "Quantos níveis a árvore pode ter?", o instrutor respondeu: "Quantos você precisar." O programador perguntou: "E se eu exagerar?" O instrutor respondeu: "Aí você tem uma árvore grande."
O fato por trás da lenda: A árvore de supervisão é um modelo de estruturação de processos baseado na ideia de workers e supervisores. Workers são processos que realizam trabalho real. Supervisores são processos que monitoram workers. A árvore de supervisão é um arranjo hierárquico que torna possível projetar software tolerante a falhas.
Gancho: A árvore é a estrutura. Mas há um behaviour que é a raiz de tudo: a application.
Capítulo 55 — Application: O Componente que Pode Ser Iniciado e Parado (Parte 10)
A lenda diz que a application é um componente. Ela pode ser iniciada. Ela pode ser parada. Ela pode ser reutilizada. Ela é a unidade fundamental de um sistema OTP.
A verdade é que, no OTP, application denota um componente que implementa alguma funcionalidade específica, que pode ser iniciada e parada como uma unidade, e que pode ser reutilizada em outros sistemas. A definição de como iniciar e parar a árvore está localizada em um application callback module, que exporta um conjunto pré-definido de funções.
A lenda diz que, quando um programador perguntou "O que é uma application?", o instrutor respondeu: "É um pedaço do sistema." O programador perguntou: "E se eu precisar de vários?" O instrutor respondeu: "Aí você tem várias applications."
O fato por trás da lenda: No OTP, application denota um componente que implementa alguma funcionalidade específica, que pode ser iniciada e parada como uma unidade, e que pode ser reutilizada em outros sistemas. A definição de como iniciar e parar a árvore está localizada em um application callback module.
Gancho: A application é a unidade. Mas há um behaviour que lida com eventos: o gen_event.
Capítulo 56 — GenEvent: O Gerente de Eventos que Nunca se Cansa (Parte 10)
A lenda diz que o gen_event é um gerente de eventos. Ele recebe eventos. Ele distribui eventos. Ele nunca se cansa. Ele nunca se atrapalha. Ele apenas gerencia.
A verdade é que gen_event é um behaviour module para implementar funcionalidade de manipulação de eventos. Ele consiste em um processo genérico de gerenciamento de eventos com qualquer número de event handlers que são adicionados e removidos dinamicamente. Cada event handler é implementado como um callback module que exporta um conjunto pré-definido de funções.
A lenda diz que, quando um programador perguntou "O que o gen_event faz?", o instrutor respondeu: "Ele gerencia." O programador perguntou: "Gerencia o quê?" O instrutor respondeu: "Eventos."
O fato por trás da lenda: gen_event é um behaviour module para implementar funcionalidade de manipulação de eventos. Ele consiste em um processo genérico de gerenciamento de eventos com qualquer número de event handlers que são adicionados e removidos dinamicamente.
Gancho: O gen_event gerencia. Mas há um behaviour que modela máquinas de estado: o gen_fsm.
Capítulo 57 — GenFSM: A Máquina de Estado que Virou GenStatem (Parte 10)
A lenda diz que o gen_fsm é uma máquina de estado finito. Ele tem estados. Ele transita entre estados. Ele responde a eventos. Ele é poderoso. Ele é antigo.
A verdade é que gen_fsm é um behaviour module para implementar uma máquina de estado finito. Um processo gen_fsm implementado usando este módulo tem um conjunto padrão de funções de interface e inclui funcionalidade para tracing e error reporting. No entanto, o gen_fsm foi depreciado e substituído pelo gen_statem no OTP 20.
A lenda diz que, quando um programador perguntou "Por que o gen_fsm foi depreciado?", o instrutor respondeu: "Porque o gen_statem é melhor." O programador perguntou: "Melhor como?" O instrutor respondeu: "Melhor em tudo."
O fato por trás da lenda: gen_fsm é um behaviour module para implementar uma máquina de estado finito. Ele foi depreciado e substituído pelo gen_statem no OTP 20. O gen_statem deve ser usado para código novo.
Gancho: O gen_statem é o futuro das máquinas de estado. Mas há um behaviour que é o futuro de tudo: o application.
Capítulo 58 — "Let It Crash": A Filosofia que Mudou Tudo (Parte 10)
A lenda diz que, no OTP, você não tenta evitar falhas. Você as abraça. Você deixa o processo crashar. Você deixa o supervisor reiniciar. Você deixa o sistema se curar.
A verdade é que a filosofia "let it crash" foi proposta por Joe Armstrong. Ela se baseia na ideia de que falhas são inevitáveis e que o sistema deve ser projetado para se recuperar automaticamente. Supervisores monitoram processos e os reiniciam quando falham. O isolamento de falhas garante que um processo que falha não afete os outros.
A lenda diz que, quando um programador perguntou "Por que deixar crashar?", o instrutor respondeu: "Porque tentar evitar falhas é mais caro que reiniciar." O programador perguntou: "E se o processo crashar de novo?" O instrutor respondeu: "Aí o supervisor decide."
O fato por trás da lenda: A filosofia "let it crash" foi proposta por Joe Armstrong. Ela se baseia na ideia de que falhas são inevitáveis e que o sistema deve ser projetado para se recuperar automaticamente. Supervisores monitoram processos e os reiniciam quando falham.
Gancho: O "let it crash" é a filosofia. Mas há uma coisa que mantém tudo funcionando: a árvore de supervisão.
Capítulo 59 — A Árvore de Supervisão: A Família que Nunca se Desfaz (Parte 11)
A lenda diz que a árvore de supervisão é uma família. No topo, o supervisor raiz. Abaixo, supervisores e workers. Cada um cuida do seu. Cada um protege o seu. Se um morre, o outro assume. Se todos morrem, o topo reinicia.
A verdade é que a árvore de supervisão é um modelo de estruturação de processos baseado na ideia de workers e supervisores. Workers são processos que realizam computação e trabalho real. Supervisores são processos que monitoram workers. A árvore de supervisão é um arranjo hierárquico de código em supervisores e workers, que torna possível projetar e programar software tolerante a falhas.
A lenda diz que, quando um programador perguntou "Quantos níveis a árvore pode ter?", o instrutor respondeu: "Quantos você precisar." O programador perguntou: "E se eu exagerar?" O instrutor respondeu: "Aí você tem uma árvore grande."
O fato por trás da lenda: A árvore de supervisão é um modelo de estruturação de processos baseado na ideia de workers e supervisores. Workers são processos que realizam trabalho real. Supervisores são processos que monitoram workers. A árvore de supervisão é um arranjo hierárquico que torna possível projetar software tolerante a falhas.
Gancho: A árvore é a estrutura. Mas há um behaviour que é a raiz de tudo: a application.
Capítulo 60 — Application: O Componente que Pode Ser Iniciado e Parado (Parte 11)
A lenda diz que a application é um componente. Ela pode ser iniciada. Ela pode ser parada. Ela pode ser reutilizada. Ela é a unidade fundamental de um sistema OTP.
A verdade é que, no OTP, application denota um componente que implementa alguma funcionalidade específica, que pode ser iniciada e parada como uma unidade, e que pode ser reutilizada em outros sistemas. A definição de como iniciar e parar a árvore está localizada em um application callback module, que exporta um conjunto pré-definido de funções.
A lenda diz que, quando um programador perguntou "O que é uma application?", o instrutor respondeu: "É um pedaço do sistema." O programador perguntou: "E se eu precisar de vários?" O instrutor respondeu: "Aí você tem várias applications."
O fato por trás da lenda: No OTP, application denota um componente que implementa alguma funcionalidade específica, que pode ser iniciada e parada como uma unidade, e que pode ser reutilizada em outros sistemas. A definição de como iniciar e parar a árvore está localizada em um application callback module.
Gancho: A application é a unidade. Mas há um behaviour que lida com eventos: o gen_event.
Agora, sério: OTP significa Open Telecom Platform. É uma coleção de bibliotecas e ferramentas Erlang para construir sistemas concorrentes, tolerantes a falhas e distribuídos. Os behaviours do OTP incluem gen_server, supervisor, gen_event, gen_fsm (depreciado e substituído por gen_statem), e application. A filosofia "let it crash" foi proposta por Joe Armstrong. A árvore de supervisão é um modelo hierárquico de supervisores e workers. 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)