Documentar o código é parte do processo de design e implementação de um software. Ajuda a clarear a mente, ordenar conceitos e passos. Além de induzir os questionamento e também simplificação de código. Em muitos projetos e times, documentar é preciso pois não se sabe como vai ser a configuração do time ao médio e longo prazo. Pode ser que novos integrantes entrem e os mais antigos sejam deslocados para outras funções e com eles boa parte do conhecimento.

Recentemente comprei uma raspberry pi 4 com o propósito de usar o projeto retropie para jogar video game do século passado. Depois que comprei, lembrei que precisava também comprar controles (gamepads). Pesquisando na documentação do retropie, verifiquei que existe opções de usar um virtual gamepad e as duas soluções mais usadas são Mobile-Gamepad e Virtual-Gamepad. Ambas as soluções funcionam do mesmo jeito sendo compostas por: frontend em javascript simulando um controle e enviando eventos dos botões e direcionais para backend nodejs usando socket.

Vamos detalhar algumas características bem interessante utilizadas na implementação de um servidor riemann chamado katja_echo. riemann.io riemann.io é um servidor para processamento de stream de eventos, capaz de aplicar funções específicas para cada evento recebido e agregar ou gerar outros eventos para sistemas externos, escrito em Clojure e roda usando a JVM. riemann pode ser utilizado para processar métricas onde aplicações instrumentadas enviam para um servidor central métricas relacionadas com algo importante ocorrido.

Nesta série de posts sobre Observability vamos instrumentar e estruturar uma aplicação com o objetivo de estudar as estratégias escolhidas. O que é Observability Resumidamente, é coletar várias visões internas e externas de uma aplicação e correlacionar posteriormente em um sistema externo. As aplicações e dependências precisam ser instrumentados para enviarem diferentes visões: métricas traces logs alertas Observability para BEAM Existem várias bibliotecas e iniciativas quando usamos Elixir/Erlang. Veja uma lista neste link: https://github.

Este post faz parte de uma série de outros posts relacionados a como usar Erlang distribution protocol. Na primeira parte, Brincando com Erlang nodes: eclero criamos uma aplicação básica. Já na segunda parte, Brincando com Erlang nodes: embedded , criamos uma imagem Linux para a aplicação e clero. Na terceira parte, Brincando com Erlang nodes: epmd , apresentamos a solução para o problema do epmd. E agora vem a pergunta, como podemos simular mais nós dentro do ambiente ?

Este post faz parte de uma série de outros posts relacionados a como usar Erlang distribution protocol. Na primeira parte, Brincando com Erlang nodes: eclero , criamos uma aplicação básica. Já na segunda parte, Brincando com Erlang nodes: embedded , colocamos a aplicação em uma imagem Linux. Agora, o próximo passo é falar sobre o epmd. Mas antes vamos atualizar a lista dos requisitos: Cada nó necessita detectar e ser notificado de qualquer falha dos outros nós O cluster de nós Erlang deve ser configurado utilizando algum tipo de configuração vinda do ambiente O ambiente de execução é Linux embarcado rodando em qualquer plataforma Desejável poder rodar em um ambiente embarcado com o mínimo de recursos necessários Mínimo de 3 nós para a solução funcionar epmd epmd: Erlang Portmap Daemon é um daemon no qual conhece o endereço e nomes de todos os nós Erlang de dentro de um cluster.

Este post faz parte de uma série de outros posts relacionados a como usar Erlang distribution protocol. Na primeira parte, Brincando com Erlang nodes: eclero criamos uma aplicação básica. O próximo passo é continuar com o desenvolvimento dos requisitos. Relembrando e incrementando os requisitos, temos: Cada nó necessita detectar e ser notificado de qualquer falha dos outros nós O cluster de nós Erlang deve ser configurado utilizando algum tipo de configuração vinda do ambiente O ambiente de execução é Linux embarcado rodando em qualquer plataforma Desejável poder rodar em um ambiente embarcado com o mínimo de recursos necessários Mínimo de 3 nós para a solução funcionar Agora vamos abordar alguns assuntos que não são propriamente relacionados com Erlang e Elixir mas fazem parte do contexto dos requisitos.

Este post faz parte de uma série de outros posts relacionados a como usar Erlang distribution protocol. Vamos iniciar alguns trabalhos para explorar como desenvolver, testar e experimentar utilizando nodes Erlang e uma aplicação distribuída. Na primeira parte dos trabalhos vou contar um pouco sobre o design, detalhes de implementação e testes. A intenção foi implementar uma aplicação simples mas que utilize diversos conceitos e recursos do ambiente podendo ser utilizada para futuras experimentações.

Documentar um projeto de software com o objetivo de agilizar a comunicação durante o desenvolvimento de um projeto é fundamental para muitas equipes e pode minimizar o tempo de desenvolvimento. Um time alinhado, onde todos saibam como é a arquitetura das soluções, fortalece o senso de ownership. Mas como podemos documentar a arquitetura de software quando estamos utilizando Erlang ou Elixir? Será que existe algum padrão, diagrama ou técnica? Este post vai abordar como podemos criar uma documentação efetiva.

No primeiro artigo Gerenciamento out-of-band: SQL , introduzimos a ideia geral do out-of-band. Neste post vamos continuar e implementar uma outra forma de acesso. Desta vez utilizando um servidor SSH embutido na aplicação. Geralmente quando precisamos acessar alguma aplicação remotamente, utilizamos o SSH para conectar no servidor e depois podemos utilizar alguma interface de linha de comando no qual conversa com a aplicação ou fazer um ‘attach’ no node e executar qualquer comando.