Parseando Imagine a situação na qual o seu programa precisa ler arquivos texto no qual o conteúdo está em um formato adhoc ou muito criativo e você não tem ideia de como implementar o parser do arquivo. Muitas vezes até sabemos como implementar mas é uma tarefa tediosa. Outras vezes tentamos fugir da implementação. A verdade é que precisamos conhecer as ferramentas para melhor sair das situações. Nesse post vamos percorrer alguns possíveis caminhos para implementar alguns parses de arquivos.

O que é BEAM Tools ? beamtools é um conjunto de software no qual instala versões de Erlang e Elixir prontas para uso. Sem a necessidade de compilar ou instalar mais nada. Disponível para usuários Linux, pode ser uma alternativa os métodos de instalação de Erlang e Elixir. Atualmente, quando precisamos instalar Erlang ou Elixir vamos ter algumas opções: usar os pacotes da distribuição Linux. Enquanto a instalação é bem prática e funcional.

Este post descreve alguns projetos open source onde um desenvolvedor, no qual precisa escrever um software que faz acesso aos barramentos de comunicação entre periféricos, poderia utilizar bibliotecas open source como uma base e evitando gerencia o acesso por ele mesmo ou pelo menos evitar construir algum código desde o começo. Como um desenvolvedor começa ? Quais são os principais bibliotecas open source ? Estas bibliotecas estão prontas para serem usadas ou precisam de ajustes ou revitalizações ?

Simuladores em Erlang, ideia geral Camadas em software podem ser implementadas para flexibilizar e melhorar o feedback loop durante o desenvolvimento de sistemas que interagem com hardware. Estas camadas podem ser simuladores nos quais, quando ativados, interceptam as chamadas de determinada camada roteando para as APIs simuladas. O seguinte paper apresenta a ideia geral e motivos do uso de simuladores para desenvolvimento de projetos que interagem com hardware: Erlang Embedded Simulation Thesis Report, segue o abstract do paper:

Distributed applications O conceito de distributed applications em Erlang/OTP segue a ideia de que determinada aplicação executa em um determinado nó de um cluster. Se a aplicação parar por alguma falha, então a aplicação vai ser iniciada em outro nó. Isso não quer dizer que a aplicação vai estar rodando em todos os nós ao mesmo tempo. Mas sim em apenas um determinado nó (de maior prioridade configurada). O que vai estar rodando e ativamente controlando a aplicação é o _distributed application controller.

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 , 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.

A ideia deste post é abordar algumas maneiras de fazer um gerenciamento out-of-band de uma aplicação. E a inspiração veio desta discussão sqlapi: library to connect to your erlang server via SQL: This library can help you to make an SQL server from your existing server. For example you have a server and let it be ejabberd. You want to give a list of connected users. Of course you will start from making HTTP endpoint that will reply with JSON with list of users.

Neste post vamos ativar o suporte LTTng na BEAM VM usando o projeto Yocto com a layer meta-erlang. O objetivo é demonstrar como podemos fazer a análise de um problema utilizando esta abordagem. Caso nunca tenha ouvido falar do projeto Yocto, tenha em mente que os conhecimentos usados aqui funcionam para qualquer distribuição Linux. Basicamente vamos explorar quatro grandes blocos: BEAM VM, com suporte ao LTTng habilitado Yocto Project, onde vamos usar uma distro básica com Erlang Tracecompass, um plugin do projeto Eclipse para visualização e monitoramento de traces Um código de exemplo em Erlang, apresentando algum problema no qual podemos visualizar com o LTTng.

Neste post vamos descobrir como podemos instrumentar aplicações Erlang/Elixir dinamicamente. Trace dinâmicos Um trace dinâmico é um conjunto de bibliotecas nas quais permitem instrumentar partes do sistema em tempo de execução, com o objetivo de extrair métricas de performance, ajudando na resolução de problemas. Geralmente estes traces possibilitam uma visão fim-a-fim envolvendo a aplicação e chamadas de sistema. Trace BEAM Existem três modos de utilizar traces dinâmicos no BEAM. Sendo dependente do Sistema Operacional:

Quando desenvolvemos em Elixir ou Erlang, de forma open source, geralmente publicamos o código em um repositório de código público e também divulgamos no hex.pm para que outros usuários possam encontrar e usar. Mas como podemos tornar o processo de publicação eficiente dentro de uma empresa ? A seguir, algumas formas de resolver. Em diversas empresas, após construir alguns códigos, isolar em funcionalidades específicas e transformar em bibliotecas Elixir ou Erlang.

Este post é uma pequena nota sobre Erlang Ecosystem Foundation. Basicamente é uma organização sem fins lucrativos onde um conjunto de membros trabalham em diversos grupos de trabalho. Os seguintes grupos de trabalho foram definidos inicialmente: Marketing Fellowship Security Observability Sponsorship Erlang Ecosystem Foundation Building and Packaging Education, Training, & Adoption Documentation Qualquer pessoa ou empresa pode fazer parte da EEF gratuitamente. Podendo, se quiser, fazer doações de horas trabalhando em determinados projetos de algum grupo de trabalho ou ajudando financeiramente a EFF.

polibot é um pequeno projeto demonstrando como testar um equipamento fictício utilizando Erlang e o framework common_test. Durante este post, vamos exercitar um cenário e construir uma solução para testes sistêmicos. O código do projeto foi disponibilizado aqui: polibot Geometric Box System O nome do equipamento é Geometric Box System (GBS) e possui três principais tipos de hardwares, onde cada hardware é composto por uma placa processadora e alguns devices para realizar determinadas operações.

Este post é sobre como instrumentar uma aplicação e coletar traces para posterior analise. A ideia veio deste post: Erlang trace files in Wireshark e também deste código hackney_trace.erl. Aqui estamos falando de como utilizar a BEAM VM para capturar traces da aplicação. Podemos usar trace nas seguintes situações: low level information próprio para debug do software queremos localizar extamente o ponto que ocorre algum evento as informações são destinadas para o desenvolvedor adicionar e remover trace devem ser rápidos Um módulo em Elixir pode ser construído para instrumentar uma aplicação com pontos de trace.

ExUnit é o framework padrão quando falamos de testes em Elixir. Ele é simples e ao mesmo tempo poderoso. Todos os testes em Elixir ficam separados da implementação, geralmente no diretório test. Todos os arquivos teste diretório que seguem o padrão de nome: <nome do teste>_test.exs são compilados e executados como testes pelo comando mix test. Cada teste é implementado dentro de um módulo normal no usa as macros contidas no ExUnit.

As duas abordagens abaixo servem para configurar um projeto para utilizar mocks durante os testes. Abordagem 1: mocks sem ajuda O arquivo mix.exs deve ser ajustado acrescentando um diretório adicional para a propriedade elixirc_paths: def project do [app: :coffee_fsm, version: "0.1.0", elixir: "~> 1.4", elixirc_paths: elixirc_paths(Mix.env), build_embedded: Mix.env == :prod, start_permanent: Mix.env == :prod, deps: deps()] end def application do # Specify extra applications you'll use from Erlang/Elixir [extra_applications: [:logger]] end defp elixirc*paths(:test), do: ["lib","test/support"] defp elixirc_paths(*), do: ["lib"] Quando MIX_ENV for test a função elixirc_paths/1 retorna uma lista com dois diretórios onde existe código Elixir para ser compilado.

Alguns comentários sobre as questões contidas nesta apresentação On Network Configuration, Distributed and Concurrent Programming with Erlang Chalmers sobre o tema “Erlang bad parts”: The syntax Pessoalmente, eu acho a sintaxe da linguagem (tanto Erlang quanto Elixir) bem prática. Mas ao mesmo tempo, se você comparar com qualquer outra linguagem (exemplo: C ou Javascript) vai notar algumas construções esquisitas. Mas, depois de um tempo tudo fica confortável e prático. A dica aqui é não focar na sintaxe, busque entender o paradigma funcional e como a sintaxe ajuda nisso.

lux é um framework para automação de testes utilizando o estilo Expect (https://en.wikipedia.org/wiki/Expect, https://core.tcl-lang.org/expect/index). A ideia básica é a definição de um script contendo os comandos usados para testar alguma aplicação e tambem colocando algumas marcações no script que irão controlar o lux. Este framework provê mecanismos de fazer uma automação de testes, ou seja, aqueles comandos que são utilizados para testar alguma aplicação podem ser escritos em uma forma bem simples nos quais o lux vai controlar a execução.

common_test é uma das aplicações mais interessantes que acompanha a distribuição Erlang/OTP. Digo isso pois os casos de uso que a ferramenta resolve são baseados em casos reais da indústria. Podemos realizar vários tipos de testes, por exemplo: black-box, utilizando algum protocolo de comunicação: ssh, netconf, telnet, ftp white-box, para testar aplicações escritas em Erlang ou Elixir, fazendo chamadas reais unit tests, há vários projetos que utilizam somente o common_test para implementar todos os testes necessários É possível criar suites de testes com várias formas de execução dos testes e organização.

eunit é um framework para testes leves e parte da distribuição Erlang/OTP padrão. Os testes podem ser definidos dentro de cada módulo, dentro de blocos -ifdef(EUNIT). % test code here ... -endif. Ou em arquivos separados, geralmente dentro do diretório test, em uma base de código. A filosofia do framework segue a linha XUnit, mas adaptado para o conceito funcional. Vejo duas principais vantagens para definir os testes dentro de módulos:

Algumas dicas e guias gerais para começar um projeto. Defina um repositório git git init já no começo do projeto ajuda a manter o histórico das mudanças de forma consistente. Crie o arquivo .gitignore No arquivo .gitignore, colocamos todos os arquivos temporários do projeto e também resultados de compilação. Utilize editorconfig editorconfig é uma forma de padronizar o estilo de código para alguns tipos de arquivos. A maioria dos editores suporta, usando plugins ou nativamente.

meta-erlang é uma layer compatível com o Yocto Project e Openembedded. A intenção é trazer Erlang e Elixir como alternativas para o desenvolvimento de aplicações embarcadas. A layer oferece suporte para cross-compilação de projetos Erlang e Elixir para qualquer BSP suportado pelo Yocto. Também existe uma layer chamada meta-axon no qual é uma layer que faz uso da meta-erlang, como se fosse um projeto real. Criei uma documentação oficial do projeto aqui no qual pode ser utilizada para os primeiros passos.

BEAM VM BEAM VM é o nome formal da máquina virtual no qual algumas linguagens de programação utilizam para executar as instruções de um programa. As principais linguagens são: Erlang e Elixir. Mas existem outras: luerl efene clojerl Erlang Erlang github https://www.erlang.org/ Jira É uma linguagem de programação funcional com primitivas de concorrência integrados na linguagem. Geralmente os programas são organizados em módulos contendo funções privadas e públicas. Eu gosto de comparar com programas escritos em linguagem C (apesar do paradigma ser bem diferente, a estrutura e organização é similar, ou seja, funções e módulos).

Como conheci Erlang/OTP Tudo começou em 2009 quando estava procurando alguma biblioteca opensource já pronto e testado para um protocolo chamado MEGACO, H.248. Após algumas pesquisas encontrei algo sobre Erlang, mas não tinha entendido nada e muito menos como integrar com o trabalho que tinha que fazer utilizando linguagem C em uma plataforma embarcada. Então abandonei a ideia mas mantive o nome da linguagem na lista de coisas para estudar.

Um blog em português A ideia inicial é construir algum tipo de documentação em Português, com links e referências interessantes nas quais possam ser utilizadas no futuro. De fato não há muita documentação sobre Erlang e Elixir em português. Fico pensando como novos desenvolvedores podem utilizar estas tecnologias (BEAM, Erlang, Elixir) e creio que escrevendo posso ajudar. Lembrando que a linguagem Elixir foi inventada por um brasileiro, mas se tornou popular fora do Brasil, talvez um blog em Português possa ajudar a comunidade brasileira.