DEV Community: Ingresse

Docker e Docker Compose um guia para iniciantes.

Leoni Mella — Mon, 11 May 2020 14:24:17 +0000

Docker e Docker Compose um guia para iniciantes.

Quando comecei a usar Docker e o Docker Compose foi fácil entender quais eram suas funções, mas encontrei dificuldade em descobrir como eu poderia aplicá-los em meus projetos. Depois de muita leitura, tentativa e erro e algumas implementações eu consegui "decifrar" os pedaços que estavam faltando e aprendi o básico para utilizá-lo.

Nesse artigo tento explicar alguns desses pedaços que, os inciantes em Docker, geralmente se confundem.

Antes de começarmos

Caso você não conheça nada sobre Docker, sugiro que você leia a documentação oficial antes e se você ainda não tem Docker e Docker Compose instalado, aqui estão alguns links para ajuda-lo:

Docker
Docker Compose

Dividi este artigo por partes que considero importante, sinta-se livre para pular as que você já esteja familiarizado.

Parte 01 - Dockerfile, Imagens e Containers

Geralmente o arquivo Dockerfile é o ponto de entrada para quem começa a utilizar o Docker. Embora o guia explique bem as instruções definidas no arquivo eu não conseguia entender muito bem o que eram as imagens e o que eram os containers.

O Dockerfile define uma imagem. E o que é uma imagem? A imagem é um conjunto de recursos responsável pela execução de um código ou uma aplicação. Geralmente a imagem que você define sempre tem outra imagem como base. Você pode pensar nela como se fosse um pacote semelhante a um módulo do node_modules, ou um package dentro do vendor da sua aplicação, não é a forma mais correta de definir, mas pode ajudar a enxergar como ela funciona. Esses pacotes de recursos servem para executar alguma função dentro da sua aplicação, já as imagens servem para construir o container que você vai rodar sua aplicação.

Todo container roda em cima de uma imagem, é uma dependência direta, se tem um container sendo executado tem uma imagem por trás dele. Por exemplo, vamos supor que nós queremos executar o comando elixir -v. Nós precisamos definir uma imagem capaz de interpretar a linguagem Elixir e depois colocar um container para executar essa imagem. Vamos criar o Dockerfile e inserir nele o mínimo do mínimo para nosso exemplo:

FROM elixir:1.10

Agora vamos construir a imagem que estamos definindo com o comando build (mais sobre a --tag depois):

docker build --tag=elixir:example . # o ponto final é importante!

Pronto! Temos a imagem criada, você pode conferir ela listando as imagens no seu sistema, executando docker image ls

Agora que temos uma imagem definida, vamos criar nosso container e executar o comando que queremos:

docker run --rm elixir:example elixir -v

E pronto! A imagem que criamos foi utilizada nesse container que executou o comando elixir -v e foi destruído após essa execução graças a flag --rm que passamos.

"Pegadinhas"

Nosso Dockerfile é muito muito simples e nesse caso não precisaríamos ter definido um. O mesmo resultado pode ser obtido ao executar o comando:

docker run --rm elixir:1.10 elixir -v

Agora ao invés rodar um container em cima da imagem que criamos com o docker build ..., rodamos o container tendo como base a imagem padrão do Elixir 1.10: elixir:1.10. Já que nossa imagem só tem como dependência a elixir:1.10 cortamos caminho e executamos o container direto com ela.

Mas vamos supor que além da linguagem Elixir instalada, precisássemos também do Git. Ai sim declaramos um Dockerfile que reuna as duas dependências:

FROM elixir:1.10

RUN apt-get update && apt-get install git -y

Dessa forma a imagem gerada contém esses dois recursos que seriam necessários pela nossa aplicação.

E pra fechar essa primeira parte, e quanto a essa flag que utilizamos --tag? Quando "tageamos" uma imagem estamos versionando ela, você pode fazer um paralelo com o sistema de branches do Git. Ao tagear uma imagem nós salvamos tudo o que foi instalado nessa imagem naquela versão. Por exemplo, a imagem elixir:1.10 significa que estamos utilizando uma imagem com nome Elixir e que a versão dessa imagem é a 1.10, por convenção a versão de Elixir sendo executada dentro dessa imagem também é a 1.10.

Isso se repete para todas as outras linguagens e recursos: php:7.3, python:3.8, ubuntu:18.04 e etc...

Parte 02 - Operando o Container

O container é a parte responsável por executar o que foi definido na sua imagem, sendo assim é recomendado evitar qualquer mudança ou edição diretamente. Caso você instale ou modifique alguma coisa no container a alteração feita fica disponível somente no próprio container e não na imagem base. Dito isso, de vez em quando precisamos debugar, modificar ou experimentar alguma coisa em nossas aplicações.

Vamos cobrir algumas operações e configurações básicas que podem ajudar você a dar aquele ajuste fino na sua aplicação e ver o que está acontecendo dentro dela.

2.1 Criando

O comando docker run cria um container dada determinada imagem e ele ficará la até que você o remova. Se você usa a forma mais simples do comando, docker run elixir:1.10 o Docker cria um container com um nome default gerado automaticamente, executa o que está definido na imagem, ou o comando que você passou com o output do comando no terminal.

Podemos melhorar isso passando alguns parâmetros para o comando docker run.

Dê um nome ao seu container usando a flag --name:

docker run --name=application elixir:1.10

Isso facilita muito no manuseio, se você precisar executar um comando nesse container ou pausar, iniciar e remover ele, basta passar o nome selecionado ao invés do id. Por exemplo:

docker start application

docker stop application

docker exec application {command}

Executando o container em detached mode usando a flag -d:

docker run --name=application -d elixir:1.10

Após a inicialização do container ele continua rodando em segundo plano, liberando o seu terminal. Provavelmente você vai usar muito essa flag. Você pode conferir o status atual do seu container com o comando docker ps e ver que ele continua lá, rodando.

Exponha uma porta de rede de seu container para que ele possa receber tráfego com a flag --expose.

docker run --name=application --expose 4000 -d elixir:1.10

Dessa forma o container deixa a porta 4000 exposta para receber tráfego através dela. Provavelmente você vai expor a porta que sua aplicação está ouvindo. Ou você pode vincular com uma porta no seu localhost para que toda vez que você faça um request para essa porta, por exemplo: http://localhost:4000 esse request seja encaminhado para o seu container.

docker run --name=application -p 4000:4000 -d elixir:1.10

A flag -p 4000:4000 indica que a porta 4000 da sua máquina será encaminhada para a 4000 do container. Resumindo -p host_port:container_port.

É importante entender a diferença entre o vinculo -p e a exposição --expose de portas do container. Quando expomos uma porta do container, ela não está vinculada à nossa máquina, ela apenas está disponível para o request, dessa forma ao invés de fazer o request assim: http://localhost:4000 fazemos o request assim: http://{container_ip}:4000. Demorei um tempo para entender isso!

2.2 Gerenciando

Quando um container está rodando é corriqueiro executarmos algumas operações nele durante o desenvolvimento. As vezes precisamos ver os logs da aplicação, modificar algum comportamento, checar alguma outra coisa, enfim... Problemas que aparecem durante o desenvolvimento.

Vamos supor que criamos o container seguindo o exemplo do tópico anterior:

docker run --expose 4000 -d --name application elixir:1.10

Se quisermos ver os logs da aplicação que está sendo executada dentro do container, geralmente basta executar:

docker logs application

Executando esse comando todo o log que existe no seu container será exibido no seu terminal. Você pode aplicar a flag follow -f, isso fará com que o terminal fique "escutando" os logs e qualquer logs novos serão exibidos na sua tela.

docker logs application -f

Melhorando um pouco mais, podemos filtrar o output inicial desse comando com a quantidade de linhas que quiser ver. Fazemos isso com a flag --tail=number.

docker logs application -f --tail=10

Dessa forma seguimos os logs do container e será exibido somente as últimas 10 linhas.

Outra operação muito comum é o "ssh login" nos containers. Para tal operação utilizamos o seguinte comando:

docker exec -it application bash

Esse comando não faz um "ssh login". Na verdade ele vai modificar o input do seu terminal para que todos os comandos a seguir passem a rodar dentro do programa iniciado dentro do container, o bash nesse caso. E também vincula o output do container ao seu terminal. Tudo isso é feito pelas flags -it.

Você pode rodar comandos para o seu container sem essas flags. Algumas aplicações escrevem arquivos de logs ao invés de só exibi-los no terminal, para ler esses arquivos você poderia uilizar o docker exec da seguinte forma:

docker exec application tail -f /path/to/log_file

Agora que temos um entendimento claro da diferença entre imagens e containers e de alguns comandos básicos, vamos falar sobre o Docker Compose.

Parte 03 - Docker Compose não é Docker

Pode parecer besteira, mas é importante ressaltar aqui que Docker Compose e Docker são coisas diferentes!

Resumindo, o Docker Compose é uma ferramenta de administração de containers.

Geralmente, no mundo de aplicações descentralizadas, os famosos Micro Services, é comum que seu negócio esteja dividido em aplicações diferentes, as vezes em linguagens de programação diferentes. Por causa dessa separação, teoricamente, você precisaria de mais de uma imagem e mais de um container para que tudo funcione.

Mesmo se sua aplicação for um monolito, a chance de você utilizar um banco de dados, web server, redis e outras tecnologias fora da sua aplicação é grande o que "força" você a dividir cada vez mais em containers e imagem menores que sejam responsáveis somente por uma tarefa.

Então, se você tem uma aplicação monolítica, que se conecta a um banco de dados, o ideal seria ter um container com sua aplicação e outra com seu banco de dados, certo? Com o que vimos até agora você poderia criar esses dois containers rodando o docker run com especificações um pouco diferentes.

Mas vamos supor que além da aplicação e do banco de dados você também precise do Nginx. Ai você teria que criar mais um container. Percebe que começa a ficar complicado gerenciar esses containers "soltos" que estamos criando para nossa aplicação funcionar? Por causa dessa crescente complexidade você pode optar pelos seguintes cenários:

3.1 Rodar todos os containers de forma independente

Nesse cenário você sairia escrevendo docker run no seu terminal como se não houvesse amanhã. Destruindo e modificando containers até que eles funcionem da maneira que você espera.

Funciona, mas essa abordagem não é muito prática, imagina que para subir sua aplicação você tenha que iniciar cinco containers diferentes. Lá vai você docker run ..., docker run ..., docker run ..., docker run ... e por último docker run ... com flags e imagens diferentes em cada comando... Acho que já deu preguiça em você só de pensar no trabalho desse método.

3.2 Agregar todas as tecnologias em uma única imagem

Você poderia criar uma imagem que contenha todas as dependências do seu negócio. Parece interessante, certo?

Mas imagine o tanto de configuração necessária no seu Dockerfile para que você rode sua aplicação, seu banco de dados, seu web server e etc. Você acabaria tendo um Dockerfile mega extenso e difícil de manter. Seria praticamente fazer o setup disso tudo no seu próprio computador. Bem cansativo também.

Essa abordagem não é de todo o mal para ambientes de desenvolvimento ou homologação, mas imagine em um servidor de produção. Na AWS, por exemplo, você utilizar o seu banco de dados dentro de uma EC2 não parece uma boa ideia. Mas pode ser que você esteja usando Docker só em desenvolvimento, nesse caso pode ser uma abordagem válida.

3.3 Criar um docker-compose.yml

Essa provavelmente é a melhor abordagem para gerenciar vários containers dependentes. O arquivo docker-compose.yml é onde declaramos nossas instruções e o estado que cada container deve ser criado e operado bem como a comunicação entre eles.

Esse tópico é um pouco extenso, vamos elaborar melhor ele na próxima parte deste artigo.

Parte 04 - Docker Compose

Vimos que o Docker Compose é uma ferramenta para gerenciar containers que tenham algum tipo de dependência entre si. Nós declaramos esses containers e seus parâmetros em um arquivo chamado docker-compose.yml.

Vamos supor que em uma empresa o negócio dela esteja dividido em três partes: Uma aplicação que utiliza o Phoenix (um web framework feito com Elixir), um servidor web Nginx e um banco de dados Postgres.

Dado esse cenário, vamos criar um docker-compose.yml capaz de definir 3 containers diferentes para que cada tecnologia tenha seu próprio ambiente e sejam capazes de conversar entre si.

4.1 Criando o docker-compose.yml

A primeira coisa que fazemos no arquivo é declarar os 3 containers que precisamos:

version: "3.7"
services:
  app:
    build: .
    command: "mix phx.server"

  nginx:
    image: nginx:1.17

  postgres:
    image: postgres:9.5

O bloco version mostra pra gente qual versão do docker-compose está sendo utilizada e o bloco services declara os 3 containers necessários: app, nginx e postgres. Cada service é um bloco indenpendente com as próprias declarações.

No service app temos duas declarações. A primeira é a build: . essa declaração define que para construir esse container deve ser utilizado um Dockerfile que deve estar no mesmo diretório que o arquivo docker-compose.yml. Por esse service representar o container da nossa aplicação, é comum que tenhamos um Dockerfile que declara os recursos que precisamos em nossa imagem para que a aplicação rode corretamente.

Nos demais services, nginx e postgres, nós substituímos a declaração build pela declaração image. Dessa forma ao invés de procurar outro Dockerfile para construir uma imagem do Nginx e outro para construir a imagem do Postgres, nós utilizamos uma imagem pronta, fornecida pelo Docker Hub que já possui essas duas tecnologias prontas para uso.

Você poderia declarar Dockerfiles diferentes para cada service, mas em nosso caso não é necessário, já que as imagens nginx:1-17 e a postgres:9.5 já tem tudo o que precisamos para as respectivas tecnologias.

E a ultima declaração do app é a command. Nela nós colocamos o valor mix phx.server, que é um comando do Phoenix responsável por inicializá-lo. Assim, quando o container ficar pronto, esse comando será executado e nossa aplicação é iniciada dentro dele.

Não utilizamos command nos outros services pois as imagens que escolhemos já lidam com essa parte da inicialização do serviço dentro delas.

4.2 Melhorando os serviços

4.2.1 App

Além dos pedaços que já definimos no tópico anterior temos que nos preocupar com alguns outros aspectos da nossa aplicação e do nosso container. Precisamos expor a porta que nossa aplicação ouve, montar um "volume" que vai ligar os arquivos locais com os arquivos do container e também, por comodidade, definir um working directory para facilitar a execução de alguns comandos da nossa aplicação.

Para que todos os requisitos sejam atendidos, modificamos o bloco app da seguinte forma:

app:
    build: .
    container_name: "app"
    volumes:
      - ./:/var/www/application/
    working_dir: "/var/www/application/"
    expose:
      - "4000"
    command: "mix phx.server"

Como vimos anteriormente expose expõe a porta 4000 do container para que ela receba tráfego. working_dir define que o path que passamos à ela, /var/www/application/ daqui pra frente seja o diretório padrão onde os comandos serão executados. Então quando o container for executar o mix phx.server ou qualquer outro comando passado à ele, ele vai executar no diretório /var/www/application/.

O container_name é basicamente isso, estamos definindo um nome para nosso container.

E por últimos temos o volume, essa declaração faz uma "ligação" com o diretório da sua máquina (host) com o diretório do container. Então, nós estamos "ligando" o diretório em que o docker-compose.yml está ./ com o diretório /var/www/application/ dentro do container. Dessa forma todos os arquivos que tem em um diretório aparecerá no outro.

4.2.2 Nginx e Postgres

Para concluir a definição do nosso docker-compose.yml vamos complementar os serviços restantes:

nginx:
    image: nginx:1.17
    container_name: "nginx"
    volumes:
      - ./nginx:/etc/nginx/conf.d
    ports:t
      - "80:80"

Adicionamos o volume, que colocará os arquivos de configuração do Nginx dentro do caminho correto do container. E por último adicionamos o port que vai vincular o nosso localhost ao container do nginx. Dessa forma, sempre que fazemos um request http://localhost, ele será encaminhado para o container do nginx que, por sua vez, encaminhará o request para o container app, conforme dita as configurações nos arquivos dentro da pasta./nginx.

E por último, completamos a definição do Postgres

 postgres:
    image: postgres:9.5
    container_name: "postgres"
    volumes:
      - ./postgres:/var/lib/postgres
    environment:
      - POSTGRES_DB=your_db
      - POSTGRES_USER=your_user
      - POSTGRES_PASSWORD=your_secret
    ports:
      - "5432:5432"

A única descrição nova aqui é a environment. Com ela você adiciona env variables ao seu container. As três variáveis que adicionamos servem para o Postgres configurar um banco de dados, usuário e senha.

Vinculamos as ports do Postgres com o host para facilitar a conexão ao container do banco de dados. Dessa forma, se você possui algum programa para gerenciar banco de dados, por exemplo, facilita a conexão com esse container.

4.3 Completando o docker-compose.yml

Se você seguiu esse guia até agora, a versão final do seu docker-compose.yml será assim:

version: "3.7"
services:
  app:
    build: .
    container_name: "app"
    volumes:
      - ./:/var/www/application/
    working_dir: "/var/www/application/"
    expose:
      - "4000"
    command: "mix phx.server"

  nginx:
    image: nginx:1.17
    container_name: "nginx"
    volumes:
      - ./nginx:/etc/nginx
    ports:
      - "80:80"

  postgres:
    image: postgres:9.5
    container_name: "postgres"
    volumes:
      - ./postgres:/var/lib/postgres
    environment:
      - POSTGRES_DB=your_db
      - POSTGRES_USER=your_user
      - POSTGRES_PASSWORD=your_secret
    ports:
      - "5432:5432"

Agora que temos o nosso arquivo do docker-compose configurado, vamos ver como utilizá-lo!

Parte 05 - Usando o Docker Compose

No tópico anterior definimos um docker-compose.yml com três containers para nossa aplicação ser executada, porém para que tudo funcione nesse momento, vamos fazer pequenas alterações na declaração do nosso serviço app:

app:
    image: elixir:1.10
    container_name: "app"
    volumes:
        - ./:/var/www/application/
    working_dir: "/var/www/application/"
    expose:
        - "4000"
    tty: true

Como não temos uma aplicação Phoenix pronta para rodar o comando mix phx.server não vai funcionar e nosso container não conseguirá subir.

Substituímos por um container criado a partir de uma image padrão de Elixir elixir:1.10 e trocamos a declaração command por tty. A declaração tty faz com que o container fique em execução em segundo plano mesmo se nenhum comando for executado, o que é justamente o que queremos.

Outra modificação que precisamos fazer é remover o volume do serviço nginx. Como não temos aplicação rodando, não precisamos configurar o Nginx para rotear o tráfego para o container desejado.

Resumindo, o novo docker-compose.yml fica assim:

version: "3.7"
services:
  app:
    image: elixir:1.10
    container_name: "app"
    volumes:
        - ./:/var/www/application/
    working_dir: "/var/www/application/"
    expose:
        - "4000"
    tty: true

  nginx:
    image: nginx:1.17
    container_name: "nginx"
    ports:
      - "80:80"

  postgres:
    image: postgres:9.5
    container_name: "postgres"
    volumes:
      - ./postgres:/var/lib/postgres
    environment:
      - POSTGRES_DB=your_db
      - POSTGRES_USER=your_user
      - POSTGRES_PASSWORD=your_secret
    ports:
      - "5432:5432"

Feito isso podemos colocar todos esses containers para rodar com o comando

docker-compose up -d

O Docker vai validar nosso arquivo yml e se tudo estiver ok vai começar a procurar as imagens que nossos containers precisam para serem executados. Aqui nós também adicionamos a flag -d para que nosso terminal seja liberado após a conclusão desse comando.

A primeira vez que você executa esse comando em um projeto pode demorar um pouco. O Docker precisa preparar todas as imagens que esses containers utilizarão e dependendo da sua internet ou do seu computador essa etapa pode levar alguns minutos.

Feito isso o Docker começa a criar os containers na ordem e inicializá-los. E se tudo correu bem você pode listar os containers criados com docker ps. O output desse comando mostra todos os containers que estão em execução, adiciona a flag -a para ver todos os containers que existe na sua máquina.

Deixo abaixo uma lista com os comandos mais corriqueiros do Docker Compose:

Parando todos os containers:

docker-compose stop

Removendo todos os containers:

docker-compose rm -f

Vendo o log de todos os containers:

docker-compose logs -f

Construir os containers sem inicializá-los:

docker-compose build

Vale ressaltar que os containers criados pelo comando docker-compose são "comuns", sendo assim os outros comandos de Docker também são válidos. Você pode até parar e retomar a execução de um container em específico.

Parte 06 - Interação entre Containers

Teoricamente, todos os containers que criamos no tópico anterior fazem parte da mesma aplicação e por isso precisam se comunicar. Quando criamos containers utilizando o docker-compose, além dos containers, outras entidades são criadas. Uma das mais importantes é a Network.

Na versão 2.x todos os containers de todos os arquivos docker-compose.yml que eram criados se juntavam em uma mesma network com nome default. Na versão 3.x esse comportamento mudou, de modo que cada arquivo docker-compose.yml tem sua própria network. O docker-compose nomeia a network do arquivo docker-compose.yml utilizando o nome do diretório concatenado com a string _default.

O tópico de network do Docker é muito extenso para esse artigo, então vou deixar ele para um post dedicado. O que você precisa saber aqui é que na versão 3.x do docker-compose a network é definida por arquivos docker-compose.yml e um container de fora desse arquivo, por padrão, não se comunica com os que estão definidos nele. É possível conectá-lo à network, mas não está no escopo deste artigo.

Enfim, todos os nossos containers fazem parte da mesma network e por isso a comunicação entre eles é muito fácil. O Docker facilita nossa vida fornecendo um "DNS" para os containers da mesma rede. Vamos utilizar o container do Postgres como exemplo. Para a nossa aplicação usar o container do postgres, tudo o que precisamos fazer é colocar o nome do container no host do nosso banco de dados na aplicação. Simples assim!

Não se esqueça que outros parâmetros de rede também são importantes. Certifique-se de que a porta correta esteja exposta (expose) no container desejado e que o request está sendo enviado para aquela porta!

Conclusão

Espero ter ajudado você na compreensão dessa ótima ferramenta de desenvolvimento! Lidar com o Docker pode ser complicado no começo, mas é uma excelente ferramenta para cuidar de um pedaço muito importante da aplicação que geralmente deixamos passar: A Infraestrutura!

Eu acho que o Docker lida com esse lado de nosso trabalho de forma primorosa, possibilitando e facilitando muito do nosso dia-a-dia! Por isso, é uma ferramenta que vale muito a pena!

Obrigado pelo seu tempo e até a próxima 🖖

Implementando árvores em Elixir

Vinicius Luiz — Thu, 16 Apr 2020 14:48:33 +0000

Problema

Com o aumento na demanda de requisições feitas para a API da Ingresse alguns processos se tornaram um tipo de gargalo. O exemplo que usarei durante este artigo será o nosso processo de definir se a sessão (data/hora) de um evento está disponível para venda ou não.

Cada requisição feita pelo usuário a nossa API faz uma grande quantidade de buscas no nosso banco de dados e no Redis. São operações simples e que não deveriam ser muito custosas, porém são muitos dados que temos que buscar, e isso em grande escala de requests se torna bastante custoso.

Prova de conceito

Desde o início dos estudos para completar esta tarefa de refatoração nós optamos por dividi-la em duas partes, sendo elas:

Construir a árvore completa de um evento

A ideia nesta etapa é fazer todo o processo de buscas necessárias nos bancos de dados, percorrer esses dados e construir a árvore que será consumida por outros processos.

Aqui foram criados os dois principais módulos (ou classes para quem estiver mais habituado com linguagens OOP) que são os que representam os nós e a árvore em si. Esses dois módulos são uma implementação simples de uma árvore e com eles nós conseguimos criá-la a partir de uma estrutura de evento que é a entidade carregada do banco de dados com suas respectivas associações como sessões, grupo de ingressos e ingressos.

node.ex

tree.ex

Calcular os status de sessões a partir de uma árvore já construída

Esta etapa é a responsável por consumir uma árvore já criada e percorrer sobre os nós dela para calcular o status de cada um. Neste ponto nós usaremos a árvore criada pela etapa anterior a esta, assim, conseguiremos percorrer por todos os nós dentro da árvore utilizando o algoritmo Postorder Traversal.

Para fazer os cálculos dos status nós decidimos utilizar pesos neles, o que significa que, cada status terá um peso de acordo com o tipo de status que ele é, com o intuito de podermos definir qual status é mais relevante comparado com outros.

É importante deixar claro que nós temos dois grupos de status que são: Disponível e Indisponível.
Dentro do grupo Indisponível nós temos outros tipos de status, que podem ser: sem estoque, vendas não iniciadas, encerrado, etc, e esses sim tem o peso mencionado acima.

Nesta estapa também decidimos usar uma tabela ETS para guardar o status de cada nó e dar como resposta para nosso cliente.

Recursive Traversal

Depois de termos concluido essas duas etapas, começamos a pesquisar qual seria a melhor forma de construirmos a árvore e evitar ter que construí-la toda vez que alguém fizesse algum request para nosso serviço. Diante disto, pensamos em cachea-la no Redis como JSON, porém algumas árvores seriam muito grandes e parsear o JSON sempre seria algo custoso, depois de algumas pesquisas, achamos algo que poderia funcionar para a gente, em Elixir podemos facilmente transformar uma struct em um binário usando a função term_to_binary do Erlang, e tendo esse binário podemos usar um algoritmo de hash, assim teremos a hash de uma estrutura válida para guardarmos em algum tipo de cache e então reconstruir a árvore sem executar muitos processos usando a função binary_to_term do Erlang.


# iex

iex(1)> tree = Tree.build(event)
%Tree.Node{
  childs: [
    %Tree.Node{
      childs: [
        %Tree.Node{
          childs: nil,
          name: 55089
        }
      ],
      name:26190
     },
     %Tree.Node{
       childs: [],
       name: 26230
     }
  ],
  name: "Teste arena alterado"
}

iex(2)> binary = tree |> :erlang.term_to_binary()
<<131, 116, 0, 0, 0, 3, 100, 0, 10, 95, 95, 115, 116, 114, 117, 99, 116, 95, 95, 100, 0, 16, 69, 108, 105, 120, 105, 114, 46, 84, 114, 101, 101, 46, 78, 111, 100, 101, 100, 0, 6, 99, 104, 105, 108, 100, 115, 108, 0, 0, ...>>


iex(3)> hash = binary |> Base.encode64()
"g3QAAAADZAAKX19zdHJ1Y3RfX2QAEEVsaXhpci5UcmVlLk5vZGVkAAZjaGlsZHNsAAAAAnQAAAADZAAKX19zdHJ1Y3RfX2QAEEVsaXhpci5UcmVlLk5vZGVkAAZjaGlsZHNsAAAAAXQAAAADZAAKX19zdHJ1Y3RfX2QAEEVsaXhpci5UcmVlLk5vZGVkAAZjaGlsZHNkAANuaWxkAARuYW1lYgAA1zFqZAAEbmFtZWIAAGZOdAAAAANkAApfX3N0cnVjdF9fZAAQRWxpeGlyLlRyZWUuTm9kZWQABmNoaWxkc2pkAARuYW1lYgAAZnZqZAAEbmFtZW0AAAAUVGVzdGUgYXJlbmEgYWx0ZXJhZG8="

Tendo esta hash, podemos voltar à estrutura usando o caminho inverso.

hash = "g3QAAAADZAAKX19zdHJ1Y3RfX2QAEEVsaXhpci5UcmVlLk5vZGVkAAZjaGlsZHNsAAAAAnQAAAADZAAKX19zdHJ1Y3RfX2QAEEVsaXhpci5UcmVlLk5vZGVkAAZjaGlsZHNsAAAAAXQAAAADZAAKX19zdHJ1Y3RfX2QAEEVsaXhpci5UcmVlLk5vZGVkAAZjaGlsZHNkAANuaWxkAARuYW1lYgAA1zFqZAAEbmFtZWIAAGZOdAAAAANkAApfX3N0cnVjdF9fZAAQRWxpeGlyLlRyZWUuTm9kZWQABmNoaWxkc2pkAARuYW1lYgAAZnZqZAAEbmFtZW0AAAAUVGVzdGUgYXJlbmEgYWx0ZXJhZG8="

decoded_hash = Base.decode64!(hash)
<<131, 116, 0, 0, 0, 3, 100, 0, 10, 95, 95, 115, 116, 114, 117, 99, 116, 95, 95, 100, 0, 16, 69, 108, 105, 120, 105, 114, 46, 84, 114, 101, 101, 46, 78, 111, 100, 101, 100, 0, 6, 99, 104, 105, 108, 100, 115, 108, 0, 0, ...>>

structure = :erlang.binary_to_term(decoded_hash)
%Tree.Node{
  childs: [
    %Tree.Node{
      childs: [
        %Tree.Node{
          childs: nil,
          name: 55089
        }
      ],
      name:26190
     },
     %Tree.Node{
       childs: [],
       name: 26230
     }
  ],
  name: "Teste arena alterado"
}

Resultados Obtidos

Aqui devemos considerar os seguintes atributos

ips - iterations per second: a quantidade de iterações que podemos executar a cada segundo.
median: a mediana dos tempos de execução calculada no benchmark

Events

Id	Session Qty.	Groups Qty.	Tickets Qty.
34392	1	3	12
31627	11	11	746
34477	2020	349	361

Queries

Performance Statistics

Name	ips	average	deviation	median	99th %
repo.by_id.34392	1.54	648.62 ms	±6.75%	631.75 ms	756.44 ms
repo.by_id.31627	1.20	833.57 ms	±9.18%	826.11 ms	930.56 ms
repo.by_id.34477	1.09	913.59 ms	±0.41%	913.63 ms	919.02 ms

Memory Usage Statistics

Name	average	deviation	median	99th %
repo.by_id.34392	0.111 MB	±0.09%	0.111 MB	0.111 MB
repo.by_id.31627	1.08 MB	±0.30%	1.08 MB	1.08 MB
repo.by_id.34477	3.76 MB	±0.13%	3.76 MB	3.77 MB

Builds

Performance Statistics

Name	ips	average	deviation	median	99th %
tree.build.34392	215.20 K	4.65 μs	±425.27%	3.46 μs	19.62 μs
tree.build.31627	5.94 K	168.23 μs	±60.08%	137.62 μs	654.07 μs
tree.build.34477	1.98 K	506.14 μs	±59.40%	392.54 μs	1864.66 μs

Memory Usage Statistics

Name	Memory usage
tree.build.34392	4.66 KB
tree.build.31627	188.73 KB - 40.53x memory usage +184.08 KB
tree.build.34477	429.12 KB - 92.16x memory usage +424.46 KB

Recursive Traversal

Performance Statistics

Name	ips	average	deviation	median	99th %
recursive.traversal.tree.34392	101.38 K	9.86 μs	±101.58%	9.18 μs	21.58 μs
recursive.traversal.tree.31627	10.18 K	98.19 μs	±51.78%	86.70 μs	264.75 μs
recursive.traversal.tree.34477	0.84 K	1188.36 μs	±3.93%	1183.79 μs	1387.74 μs

Memory Usage Statistics

Name	Memory usage
recursive.traversal.tree.34392	6.18 KB
recursive.traversal.tree.31627	43.16 KB - 6.98x memory usage +36.98 KB
recursive.traversal.tree.34477	1010.42 KB - 163.51x memory usage +1004.24 KB

Tree to binary

Performance Statistics

Name	ips	average	deviation	median	99th %
tree.to.binary.34392	177.49 K	5.63 μs	±470.90%	4.18 μs	23.35 μs
tree.to.binary.31627	5.89 K	169.79 μs	±32.19%	152.80 μs	411.31 μs
tree.to.binary.34477	2.21 K	451.81 μs	±60.66%	344.38 μs	1628.34 μs

Memory Usage Statistics

Name	Memory usage
tree.to.binary.34392	48 B
tree.to.binary.31627	48 B - 1.00x memory usage +0 B
tree.to.binary.34477	48 B - 1.00x memory usage +0 B

Binary to Hash

Performance Statistics

Name	ips	average	deviation	median	99th %
binary.to.hash.34392	22191.97	0.0451 ms	±53.24%	0.0379 ms	0.132 ms
binary.to.hash.31627	475.17	2.10 ms	±34.34%	1.83 ms	4.86 ms
binary.to.hash.34477	298.97	3.34 ms	±27.40%	3.02 ms	6.71 ms

Memory Usage Statistics

Name	Memory usage
binary.to.hash.34392	304 B
binary.to.hash.31627	376 B - 1.24x memory usage +72 B
binary.to.hash.34477	376 B - 1.24x memory usage +72 B

Serialize

Performance Statistics

Name	ips	average	deviation	median	99th %
tree.serialize.34392	21510.67	0.0465 ms	±78.93%	0.0374 ms	0.149 ms
tree.serialize.31627	520.52	1.92 ms	±33.44%	1.69 ms	4.42 ms
tree.serialize.34477	280.24	3.57 ms	±30.92%	3.13 ms	7.16 ms

Memory Usage Statistics

Name	Memory usage
tree.serialize.34392	424 B
tree.serialize.31627	424 B - 1.00x memory usage +0 B
tree.serialize.34477	424 B - 1.00x memory usage +0 B

Com esses resultados temos apenas uma preocupação no momento que é a quantidade de memória utilizada no algoritmo recursive traversal, por ser uma função recursiva nós já tinhamos em mente que ela usaria bastante memória e isso pode nos trazer problemas em um cenário de um evento gigante, o evento exemplo 34477 já é um evento considerado grande para nós devido a quantidade de ingressos e sessões que ele possui. Talvez iremos procurar resoluções para esse possível problema e acredito que se conseguirmos achar algo iremos trazer em um futuro post.

Conclusão

No final dessa POC conseguimos comprovar que nós conseguimos ter o mesmo cálculo que temos hoje, porém utilizando a estrutura de árvore que montamos para esse caso que se provou muito mais eficiente que o que temos hoje, pois os resultados que tivemos se provaram muito eficientes para diversos casos que temos hoje em nosso sistema.

Agradecimentos especiais ao Arthur por me orientar e acompanhar durante o processo de desenvolvimento!

Espero que gostem do post.

Até uma próxima!

GitHub Actions - Elixir

Vitor Leal — Tue, 07 Apr 2020 01:55:45 +0000

O Actions é uma ferramenta integrada aos seus repositórios do GitHub para automatizar os seus workflows de CI/CD (continuous delivery / continuous deploy). Você consegue rodar esses workflows baseado em diversos eventos do GitHub, como um novo push em uma branch a criação de uma nova issue ou uma nova release publicada.

Contexto

Desde que o GitHub lançou a versão beta do Actions, a Ingresse vem a testando. No final do ano passado o Actions saiu da versão beta e a gente decidiu finalmente migrar nossos workflows para lá.

Já que Elixir é a nossa linguagem principal na Ingresse, começamos a migrar primeiro os workflows dos serviços em Elixir para o Actions e aqui tem algumas dicas de como a gente faz.

Básico

Antes de tudo vou apresentar um pouco do básico do GitHub Actions, se você já tem familiaridade pode seguir passar direto essa seção.

O Actions vai ler os arquivos .yml ou .yaml dentro da pasta .github/workflows na raiz do seu projeto.

Primeiro vamos criar a pasta .github com a pasta workflows dentro:

mkdir -p .github/workflows

Agora vamos criar um arquivo que a gente pode chamar de ci.yml:

touch .github/workflows/ci.yml

Agora vamos adicionar o seguinte conteúdo nele:

name: Meu Workflow

on: push

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v1

Vamos aos detalhes do conteúdo desse arquivo.

`name`

O nome do seu workflow. É um campo opcional.

`on`

O nome do evento do GitHub que vai iniciar esse workflow.

Pode ser um evento apenas:

# Vai rodar sempre que alguém realizar um push no repositório
on: push

Pode ser uma lista de eventos:

# Vai rodar sempre que alguém realizar um push no repositório
# e quando for criado um novo pull request
on: [push, pull_request]

Pode ser customizado por evento:

on:
  # Vai rodar sempre que um pull request for criado
  pull_request:
    # Mas quando estiver apontando para a master
    branches:
      - master

  # Vai rodar sempre que uma release for criada
  release:
    # Mas se ela estiver com o status de publicada
    types: 
      - published

`jobs`

Um workflow pode ter um ou mais jobs. Por padrão, múltiplos jobs rodam em paralelo.

`jobs.<id-do-job>.run-on`

Em que tipo de máquina o job vai ser executado.

Pode ser em um tipo de máquina:

jobs:
  test:
    runs-on: ubuntu-latest

Podem ser em múltiplos tipos de máquinas, incluindo `ubuntu`, `macos` e `windows`:

jobs:
  test:
    strategy:
      matrix:
        platform: [ubuntu-latest, macos-latest, windows-latest]

    runs-on: ${{ matrix.platform }}

`jobs.<id-do-job>.steps`

Um job pode ter uma ou mais tarefas que vão ser executadas. Uma tarefa pode executar comandos, rodar setups ou rodar outras actions. O próprio GitHub tem uma série de actions publicadas que facilitam muitos trabalhos. Nesse exemplo estamos usando a action actions/checkout na versão v1 para clonar o repositório do projeto.

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      # Primeira tarefa a ser executada vai ser clonar o repositório
      - uses: actions/checkout@v1

Próximos passos

Bom agora que a gente já sabe um pouco mais sobe a estrutura básica de um workflow do GitHub Actions vamos começar a moldar ele para executar por exemplo uma tarefa de mix format e uma tarefa de mix test em um projeto Elixir.

Para evitar ter que instalar o Elixir no processo de build, vamos utilizar o atributo container para baixar uma imagem Docker já existente.

name: Meu Workflow

on: push

jobs:
  test:
    runs-on: ubuntu-latest

    container:
      image: elixir:1.10

    steps:
      - uses: actions/checkout@v1

`jobs.<id-do-job>.container`

Em qual imagem Docker vai rodar as tarefas desse job.

jobs:
  test:
    container:
      image: elixir:1.10

Agora que nosso ambiente já tem Elixir, podemos criar as tarefas para executar o mix format e mix test.

name: Meu Workflow

on: push

jobs:
  test:
    runs-on: ubuntu-latest

    container:
      image: elixir:1.10

    steps:
      - uses: actions/checkout@v1

      - name: Formatar
        run: mix format --check-formatted

      - name: Instalar as dependências
        run: mix deps.get

      - name: Testar
        run: mix test

Pronto já temos um workflow que clona nosso repositório, verifica se nosso código está formatado de acordo com as configurações do projeto, instala as dependências e roda nossos testes.

Utilizando serviços

O cenário anterior funciona perfeitamente para quando a gente tem um lib escrita em Elixir, mas para casos que a gente esteja trabalhando em um projeto com Phoenix por exemplo, a gente vai precisar provavelmente conectar em um banco de dados para poder executar alguns testes.

Nesse momento a gente consegue utilizar os services para criar containers de um banco de dados Postgres, por exemplo, para que os nossos jobs possam ter onde se conectar.

`jobs.<id-do-job>.services`

services:
  postgres:
    image: postgres

    # Mapeia a porta 5432 no container Docker para a porta 5432 no container do Postgres
    ports:
      - 5432:5432

    # Configura os dados de acesso ao banco de teste
    env:
      POSTGRES_USER: usuario
      POSTGRES_PASSWORD: senha
      POSTGRES_DB: banco

Agora que o nosso workflow vai criar o banco de dados pra gente poder conectar, tem um detalhe que temos que alterar nas nossas tarefas que vão rodar para conectar nesse banco. No caso, a nossa tarefa mix test tem que receber uma variável de ambiente para poder conectar corretamente no banco criado pelo Actions.

- name: Testar
  run: mix test
   env:
     POSTGRES_HOST: postgres
     POSTGRES_PORT: $❴❴ job.services.postgres.ports[5672] ❵❵

O exemplo completo fica assim:

name: Meu Workflow

on: push

jobs:
  test:
    runs-on: ubuntu-latest

    container:
      image: elixir:1.10

    services:
      postgres:
        image: postgres

        ports:
          - 5432:5432

        env:
          POSTGRES_USER: usuario
          POSTGRES_PASSWORD: senha
          POSTGRES_DB: banco

    steps:
      - uses: actions/checkout@v1

      - name: Formatar
        run: mix format --check-formatted

      - name: Instalar as dependências
        run: mix deps.get

      - name: Testar
        run: mix test
        env:
          POSTGRES_HOST: postgres
          POSTGRES_PORT: $❴❴ job.services.postgres.ports[5432] ❵❵

Agora basta alterar as configurações da nosso ambiente de teste para receber utilizar as variáveis de ambiente:

import Config

config :meu_app, Meu.Repo,
  adapter: Ecto.Adapters.Postgres,
  username: "usuario",
  password: "senha",
  database: "banco",
  port: String.to_integer(System.get_env("POSTGRES_PORT", "5432"))
  hostname: System.get_env("POSTGRES_HOST"),
  pool: Ecto.Adapters.SQL.Sandbox

Docker Compose

Se você já utiliza Docker Compose nos seus projetos você não precisa criar os services no arquivo do Actions e pode criar esses serviços direto no seu arquivo do Docker Compose de teste.

Exemplo do arquivo docker-compose-test.yml:

version: "3.3"
services:
  meu_servico:
    build: .
    depends_on:
      - meu_postgres
    ports:
      - "4000:4000"
    environment:
      - MIX_ENV=test
    command: mix phx.server

  postgres:
    image: postgres
    container_name: meu_postgres
    environment:
      - POSTGRES_DB=banco
      - POSTGRES_USER=usuario
      - POSTGRES_PASSWORD=senha
    ports:
      - "5433:5432"

Para rodar os testes com o Docker Compose, o ideal é mudar a imagem que roda no Actions para uma imagem que tenha já tenha o compose instalado.

jobs:
    container:
      image: docker/compose

O exemplo completo fica assim:

name: Meu Workflow

on: push

jobs:
  test:
    runs-on: ubuntu-latest

    container:
      image: docker/compose

    steps:
      - uses: actions/checkout@v1

      - name: Formatar
        run: docker-compose -f docker-compose-test.yml run meu_servico mix format --check-formatted

      - name: Testar
        run: docker-compose -f docker-compose-test.yml run meu_servico mix test

Espero que tenha ajudado vocês a entender um pouco melhor como rodar projetos Elixir no GitHub Actions.

Até a próxima!

Adotando o Elixir na Ingresse

Vitor Leal — Fri, 06 Mar 2020 20:26:57 +0000

Com o crescimento acelerado da Ingresse nos últimos anos, tivemos que reformular nossa arquitetura e infraestrutura inicial para poder escalar com essa demanda.

A Ingresse nasceu com uma base em PHP, um Monolito que atendeu bem o MVP e os primeiros anos do produto, mas com o passar do tempo acabou dificultando a evolução dele.

No processo de reformulação da arquitetura em 2016 nasceram os primeiros serviços em Python que resolveram bem os problemas para qual a linguagem foi escolhida. No início de 2017 quando estávamos com uma stack com um misto de PHP e Python começamos a olhar para outras linguagens que nos ajudasse a escalar e aproveitar melhor todos os recursos disponíveis da nossa infra. Mas para essa linguagem a gente tinha um foco muito importante, ela tinha que ser developer friendly, estávamos buscando uma linguagem que nos ajudasse na escalabilidade e performance mas principalmente na produtividade do nosso time.

Prova de conceito

Para começar fizemos uma prova de conceito de um microserviço novo implementando poucas features, mas desenvolvendo as mesmas features utilizando duas das linguagens que estávamos analisando. A idéia não era comparar só a performance do serviço entre essas duas linguagens, mas também, como é o dia a dia desenvolvendo com essas linguagens.

Escolhendo o Elixir

Uma das linguagens escolhidas para o teste foi o Elixir. Uma linguagem open source criada pelo José Valim na Plataformatec, empresa recentemente adquirida pelo Nubank.

O Elixir é uma linguagem moderna que executa na Máquina Virtual Erlang (BEAM), conhecida por executar sistemas de baixa latência, distribuídos e tolerantes a falhas.

Além disso tem uma comunidade muito ativa e frameworks para desenvolvimento web como o Phoenix que tem foco em criar uma estrutura produtiva que não compromete a velocidade de desenvolvimento nem a manutenção.

Alguns pontos altos do Elixir:

Instalação simples

A instalação do Elixir é muito simples, tem instalador para Linux, Mac, Windows e para quem prefere container como eu, imagens Docker para não sujar seu ambiente.

Documentação e conteúdo

A documentação é bem completa e fácil de navegar. O site da linguagem aponta diversos materiais de leitura, cursos e screencasts para quem quer começar. Tem muito material gerado pela comunidade, tanto aqui no Dev.to quanto no Medium.

Um ótimo lugar para iniciar com conteúdo em português é o ElixirSchool.

Gerenciador de pacotes

Uma coisa que a gente espera em todas as linguagens modernas é um gerenciador de pacotes decente. E esse é o caso do Hex, um gerenciador de pacotes para as linguagens que compilam para rodar na Maquina Virtual do Erlang (BEAM).

Ferramenta de build

O Mix é uma ferramenta de build que fornece tasks para criar, compilar e testar projetos Elixir, gerenciar suas dependências e muito mais. É uma ferramenta que facilita o dia a dia no desenvolvimento e nos processos de automatização.

Testes

O ExUnit é um framework completo para testes no Elixir. Totalmente integrado para ser executado com um simples mix test e com capacidade de rodar os testes de forma assíncrona.

Produtividade

A velocidade de desenvolvimento no Elixir é muito boa. Tem um syntax que é fácil escrever um código limpo e compreensível sem sacrificar a produtividade de um desenvolvedor.

Processo de mudança

Hoje ainda temos microserviços em outras linguagens rodando em produção, simplesmente porque estão dando conta do recado. Já até pensamos em migrar alguns mas se ainda estão funcionando bem não tem porque mexer.

Com o tempo o nosso time foi pegando pequenas tarefas para executar em Elixir até sentirem que tinham o domínio na linguagem para poder dar manutenção e criar novos microserviços do zero. A troca de conhecimento entre as equipes é essencial para que esse tipo de mudança tenha sucesso.

Com certeza não é um processo rápido adotar uma nova linguagem em produção, quando se tem uma quantidade enorme de acessos, mas acredito que os benefícios de ter uma linguagem moderna com um grande foco no desenvolvedor e na sua produtividade é um grande diferencial para a equipe e para o futuro da empresa.

Um dos nossos desenvolvedores Backend escreveu um post sobre Elixir, com uma visão de quem veio do PHP. Muito útil pra quem está tendo seu primeiro contato com a linguagem e com o paradigma funcional.

Conclusão

Essa prova de conceito hoje se tornou um dos nossos principais serviços e está em produção desde o final de 2017.

Ele é responsável por transacionar centenas de milhões de Reais em ingressos todo ano, não só na Ingresse mas em outras "tiqueteiras" do mercado que utilizam nossas API's. É um Gateway de pagamentos, com múltiplos adquirentes e plataformas de pagamento integradas como Cielo, Stone, Getnet, PicPay, StarkBank, Iugu e PayPal.

Hoje todos os nossos serviços novos são desenvolvidos em Elixir. Até agora temos 5 deles em produção e no momento mais 3 sendo desenvolvidos em 2020.

Se já trabalha com Elixir ou estiver querendo aprender estamos sempre com vagas abertas.

Learning Elixir with PHP help

Leoni Mella — Tue, 18 Feb 2020 12:00:24 +0000

🇧🇷 Artigo original em português: Entendendo Elixir com a ajuda de PHP

After some years and differents experiences with PHP and some frameworks like WordPress, Laravel, Symfony and Phalcon, I had the opportunity to work with Elixir and since then it has been my go to language for new projects.

For those who have never had a previous experience with a functional language this first contact could be a little confusing, that was my case when I first start with Elixir.

The "help" offered in this article by PHP it's just a merely comparison made between the two languages, which by the way are NOTHING similar.

In this article I've just implemented the same functionalities using both languages so you can compare the logic of a new programming paradigm with a more familiar one offered by PHP.

I will approach the Elixir functionalities that I most use on a daily basis applying the 80/20 rule, but I'm sure that with this simple knowledge you can read a .ex or .exs file and don't lose yourself on the way.

Before we begin...

If you don't know Elixir at all I suggest that you read at least the Starting Guide on their docs. It will show the syntax, the primitives types and operators of the language.

Without further ado, let's dive in!

Pattern Matching

The best pattern matching definition is the following:

Pattern matching is a powerful part of Elixir. It allows us to match simple values, data structures, and even functions - Elixir School

But what exactly does this mean? To better understand this we need to take a look at the match operator =. This operator can attribute values to variables and can be used to decompose more complex structures, like tuples and lists.

# iex

iex(1)> {a, b, c} = {"São Paulo", "Rio de Janeiro", "Fortaleza"}
{"São Paulo", "Rio de Janeiro", "Fortaleza"}

iex(2)> a
"São Paulo"

iex(3)> b
"Rio de Janeiro"

iex(4)> c
"Fortaleza"

# Another example
iex(5)> {_, "Ecuador", country} = {"Brasil", "Ecuador", "Chile"}
{"Brasil", "Ecuador", "Chile"}

iex(6)> country
"Chile"

Also, you can fetch the first item of a list

# iex

iex(1)> [head | tail] = ["Olá", "Hello", "Hola"]
["Olá", "Hello", "Hola"]

iex(2)> head
"Olá"

iex(3)> tail
["Hello", "Hola"]

Case a tuple can't be match against the left hand side of the operator, that means, maybe a tuple don't have the same number of fields or the same expected value of the left side of the = a exception will occur:

# iex

iex(1)> {a, b} = {"São Paulo", "Rio de Janeiro", "Fortaleza"}
# ** (MatchError) no match of right hand side value: {"São Paulo", "Rio de Janeiro", "Fortaleza"}
#    (stdlib) erl_eval.erl:453: :erl_eval.expr/5
#    ...

iex(1)> {_, "United States", country} = {"Brasil", "Ecuador", "Chile"}
# ** (MatchError) no match of right hand side value: {"Brasil", "Ecuador", "Chile"}
#    (stdlib) erl_eval.erl:453: :erl_eval.expr/5
#    ...

The above code gave us an understanding of the first half of the pattern matching definition. What about the other half that allow us to look for patterns in functions definitions? Let's take a look:

To help with this part I'll create a PHP class so you can compare with the equivalent Elixir module. To start with let's just create a class and module that have a hello/1 function that receive the user_name as parameter.

PHP class

<?php
// ./GreetUser.php

class GreetUser
{
    public function hello($userName)
    {
        echo "Hello, " . $userName;
    }
}

$greetUser = new GreetUser;
$greetUser->hello("Joe");

Elixir module

# ./greet_user.exs

defmodule GreetUser do

    def hello(user_name) do
        IO.puts("Hello, #{user_name}")
    end

end

GreetUser.hello("Joe")

So far, so good, right? We have a hello/1 function that will print "Hello, Joe" both in PHP class and in Elixir module.

But let's assume that the user_name parameter could be nil (null in PHP). How can we adjust our code to attend this requirement?

PHP class

<?php
// ./GreetUser.php

class GreetUser
{
    public function hello($userName = null)
    {
        if(is_null($userName)) {
            echo "Hello world!";
            return;
        }
        echo "Hello, " . $userName;
    }
}

$greetUser = new GreetUser;
$greetUser->hello("Joe");
$greetUser->hello(null);

Using PHP we could add a default value to the $userName and handle this with a if statement inside our function in case $userName is really null and display a different message.

If execute GreetUser.php we would get:

"Hello, Joe"
"Hello world!"

Although the same solution is possible in Elixir, we can use pattern matching and remove the complexity of the code from our function by get rid of the if statement:

# ./greet_user.exs

defmodule GreetUser do

    def hello(nil) do
        IO.puts("Hello world!")
    end
    def hello(user_name) do
        IO.puts("Hello, #{user_name}")
    end

end

GreetUser.hello("Joe")
GreetUser.hello(nil)

As there are two functions with the same name, the chosen one will be the one that has the correct parameter value.

This means that only when user_name = nil the first function will be executed, in any other case it will skip this function definition and go to the next hello/1 declared within this module.

It's important to say that due to function arity GreetUser.hello(nil) is different then GreetUser.hello(). In the former we would call hello/1 and the last we would call hello/0 which does not exists and would break. Always have the arity in mind!

Any primitive of the language can be used in pattern matching. So let's assume that the GreetUser module now have to greet a specific message to users that have the name "Jane", we could achieve this by doing this:

PHP Class

<?php
// ./GreetUser.php

class GreetUser
{
    public function hello($userName)
    {
        if($userName === "Jane") {
            echo "Nice to see you, Jane!";
            return;
        }
        echo "Hello, " . $userName;
    }
}

$greetUser = new GreetUser;
$greetUser->hello("Joe");
$greetUser->hello("Jane");

Elixir Module

# ./greet_user.exs

defmodule GreetUser do

    def hello("Jane" = user_name) do
        IO.puts("Nice to see you, #{user_name}!")
    end
    def hello(user_name) do
        IO.puts("Hello, #{user_name}")
    end

end

GreetUser.hello("Joe")
GreetUser.hello("Jane")

This time we specified the user_name value and add the match operator to the parameter: ("Jane" = user_name). By doing this we are matching user_name to "Jane" and them we can use the variable inside our function. If you don't want to use the parameter inside your function you can dismiss it by prepending it with an underscore: ("Jane" = _user_name). Elixir understand that this variable will never be used.

Declared variables that are not used will raise a warning in compilation time, keep that in mind!

I hope that with this example you began to see how pattern matching can remove complexity away from our code. Doesn't Elixir module look more simple and better to read than the class in PHP? We no longer have to "calculate" ifs statement to know what a function will return, pretty good, right?

Guards

If you enjoy the wonders of pattern matching you can go beyond using guards. It will allow you to make more complex parameter validation in your functions declaration.

Guards are defined using a when after a function declaration. While pattern matching is useful to check explicit values, with guards we can apply some boolean logic to it. We can check a parameter's type, length, if it is nil, if it is higher or lower given a determined number and some others validations.

Back to our GreetUser, we will use guard to validate if user_name is a string.

Elixir module

# ./greet_user.exs

defmodule GreetUser do

    def hello(user_name) when is_binary(user_name) do
        IO.puts("Hello, #{user_name}")
    end

end

GreetUser.hello("Joe")

The is_binary/1 function will return a boolean value and according to it (true or false) hello/1 get invoked or not. Elixir has several type-checks” functions like this so you can check a expression type.

Here is a tip. Either using a pattern matching or guard it's always a good practice to at least think about a alternative in case of a parameter mismatch. You could get a runtime error if a parameter won't match a function

** (FunctionClauseError) no function clause matching in GreetUser.hello/1

The above error will happen if we call hello/1 with an integer: GreetUser.hello(1).

As an alternative we could add another declaration of hello/1 just dismissing the parameter, so everything that is not a string will be direct to it:

# ./greet_user.exs

defmodule GreetUser do

    def hello(user_name) when is_binary(user_name) do
        IO.puts("Hello, #{user_name}")
    end
    def hello(_) do
        IO.puts("Only string is allowed in this function")
    end

end

GreetUser.hello("Joe")
GreetUser.hello(1)

Important!

The function declaration order is extremely important!!
In the above example we restrict hello/1 to only accept string. No problem there, but what if we had reversed the function declaration orders by placing hello(_) before the hello(user_name) when is_binary(user_name)?

# ./greet_user.exs

defmodule GreetUser do

    def hello(_) do
        IO.puts("Only string is allowed in this function")
    end
    def hello(user_name) when is_binary(user_name) do
        IO.puts("Hello, #{user_name}")
    end

end

GreetUser.hello("Joe")
GreetUser.hello(1)

Running the code we would get the following:
warning: this clause cannot match because a previous clause at line 5 always matches

Our code still run with no errors, but hello/1 with the guard when is_binary/1 would never be called because hello/1 without the guard will ALWAYS be evaluated first! So pay attention to function's declaration order!!

Pipe Operator

This one is a bit trick, but in a nutshell the pipe operator is represented by the symbol |> and all that it does is pass an expression evaluation (or result) as the first parameter to the next one.

With this you can create a function pipeline (get the name?) given a expression (variable or function).

To illustrate this concept, now GreetUser has a new requirement, we'll need to greet some users which their names will came in a list. To do that we'll create another function named hello_group/1. This new function will receive the list of names as users_name.

# ./greet_user.exs

defmodule GreetUser do
    def hello_group(users_name) when is_list(users_name) do
        # code
    end
    def hello_group(_) do
        IO.puts("Only lists are allowed")
    end
end

We declared the function and added a guard so we can validate that the parameter is indeed a list, and defined a "default" hello_group/1 in the chance that users_name is not a list.

The next step it's to handle the users_name using the pipe operator. First we'll go through the list and normalize the names. The first part can be achieve using the map/2 function from Elixir's Enum module.

# ./greet_user.exs

defmodule GreetUser do
    def hello_group(users_name) when is_list(users_name) do
        users_name
        |> Enum.map(fn user_name -> String.capitalize(user_name) end)
    end
    def hello_group(_) do
        IO.puts("Only lists are allowed")
    end
end

Let's breakdown this code:

We called users_name inside our function
Then we added the |> (pipe operator) bellow users_name. It could be called by the right side as well.
To loop the list, we use the map/2, that will return another list.
As map/2 second parameter we gave a anonymous function fn user_name -> ... end that will be executed for each element on the list
Inside the anonymous function we called the capitalize/2 from Elixir String module to capitalize the names.

The bit that you need understand is that we pass only map/2 second parameter because the first parameter is passed by the |>.

Remember: "The pipe operator forwards the result of an expression as the first parameter on to the next expression". In our case the first expression is the variable users_name and when it gets evaluated will return the list of names. And our pipeline worked because map/2 expected as the first parameter a list!

Using PHP we could achieve the same with this code:

<?php
// ./GreetUser.php

class GreetUser
{
    public function helloGroup($usersName)
    {
        if(!is_array($usersName)) {
            echo "Only arrays are allowed";
            return;
        }

        $usersNameNormalized = array_map(function ($name) {
            return ucfirst($name);
        }, $usersName);
    }
}

The next step is to "glue" all the names in a single string. We'll use join/2 which is another function from Enum module. This function will receive in the first parameter a list and in the second parameter receives a string as the joiner element. We'll use just a ", " to separate the names.

Elixir module

# ./greet_user.exs

defmodule GreetUser do
    def hello_group(users_name) when is_list(users_name) do
        users_name
        |> Enum.map(fn user_name -> String.capitalize(user_name) end)
        |> Enum.join(", ")
    end
    def hello_group(_) do
        IO.puts("Only lists are allowed")
    end
end

PHP class

<?php
// ./GreetUser.php

class GreetUser
{
    public function helloGroup($usersName)
    {
        if(!is_array($usersName)) {
            echo "Only arrays are allowed";
            return;
        }

        $usersNameNormalized = array_map(function ($name) {
            return ucfirst($name);
        }, $usersName);

        $usersNameString = implode(", ", $usersNameNormalized);
    }
}

Our pipeline still functions because map/2 will return a new list and the |> forwards it as the first parameter to the join/2 function.

Great! hello_group/1 is able to normalize and glue together the names. Now we just need to print a message to the user.

So far the result of hello_group/1 would be a string with the users names. We could use hello/1, which receives a string as first parameter to print the message to our user.

# ./greet_user.exs

defmodule GreetUser do

    def hello(user_name) when is_binary(user_name) do
        IO.puts("Hello, #{user_name}")
    end
    def hello(_) do
        IO.puts("Only strings are allowed")
    end

    def hello_group(users_name) when is_list(users_name) do
        users_name
        |> Enum.map(fn user_name -> String.capitalize(user_name) end)
        |> Enum.join(", ")
        |> hello
    end
    def hello_group(_) do
        IO.puts("Only lists are allowed")
    end
end

GreetUser.hello_group(["joe", "jane", "jim"])

By adding hello/1 in the pipeline we fulfill all the requirements for hello_group/1.

Take a look at the same feature in PHP

<?php
// ./GreetUser.php

class GreetUser
{
    public function hello($userName)
    {
        echo "Hello, " . $userName;
    }

    public function helloGroup($usersName)
    {
        if(!is_array($usersName)) {
            echo "Only arrays are allowed";
            return;
        }

        $usersNameNormalized = array_map(
            function ($name) { return ucfirst($name); },
            $usersName
        );

        $usersNameString = implode(", ", $usersNameNormalized);

        return $this->hello($usersNameString);
    }
}

$greetUser = new GreetUser;
$greetUser->helloGroup(["joe", "jane", "jim"]);

We could make the above code better by splitting in different functions, but do notice that even if we make such change the code in Elixir has a LOT more readability and less complexity.

Here is another way to visualize the same code without using the pipe operator:

# ./greet_user.exs

defmodule GreetUser do

    def hello(user_name)do
        IO.puts("Hello, #{user_name}")
    end

    def hello_group(users_name) do
        users_name
        |> Enum.map(fn user_name -> String.capitalize(user_name) end)
        |> Enum.join(", ")
        |> hello
    end

    def hello_group(users_name, :notpiped) do
        hello(
            Enum.join(
                Enum.map(
                    users_name,
                    fn user_name -> String.capitalize(user_name) end),
                ", "
            )
        )
    end
end

GreetUser.hello_group(["joe", "jane", "jim"])
GreetUser.hello_group(["joe", "jane", "jim"], :notpiped)

Here we defined another function: hello_group/2, despite the arity, both functions will return the same result.
But hello_group/1 is cleaner and easier to understand.

Control Structures

In Elixir we have access to certain tools that allow us to remove complexity from our code, but sometimes we have no other option and we have to use a if or a switch.
The control structures available to us are: if, unless, case, cond and with. This article is an overview of the language and because of that I'm not write about all this structures. I'll focus in the with because this one can be harder to understand than the others.

The first thing that we need to understand is that in a functional language the result of a function is always the result of the last expression that get executed, we don't have the return keyword in this functional world. Because of this, control structures will return the result of the last expression, so you need to be careful when write them. This can be challenging at first, but you get used to it quite fast.

In a functional language we cannot do some like this:

public function anotherFunction() {
    $param = null;

    if ($condition) {
        $param = "PHP";
    }

    return $param;
}

In the above PHP code we are defining a default value to $param and based on $condition's his value will change. This wouldn't work in a Elixir code because de if is an expression! If this was an Elixir code, all that this if expression was doing is to match $param to "PHP", and the return of this expression would be an :ok atom. The $param variable would never match "PHP" outside the if statement.

To this work in Elixir, one could do as the following:

def another_function do
    param = if condition do
        "Elixir"
    else
        nil
    end
end

By doing this, the return of the if would be matched to the param variable.
With that in mind, let's move on.

With

You can think in with like a pipeline that checks the result of each expression and if some of those return an unexpected value the code inside the with block won't get executed. You can also add fallback clausules to handle some unexpected behaviour or errors.

Let's add this structure in our hello/1 function and see how it works:

# ./greet_user.exs

defmodule GreetUser do

    def dummy_function, do: :ok

    def hello(user_name)do
        with :ok <- dummy_function() do
            IO.puts("Hello, #{user_name}")
        end
    end

end

GreetUser.hello("Joe")

We created an dummy_function/0 that will only return an :ok atom and we added an with block to check the returned value. If the returned value was indeed an :ok atom, them we print "Hello, Joe" on the screen.

If dummy_function/0 won't return an :ok we could add a fallback clausule to handle this:

# ./greet_user.exs

defmodule GreetUser do

    def dummy_function, do: :error

    def hello(user_name)do
        with :ok <- dummy_function() do
            IO.puts("Hello, #{user_name}")
        else
            _ ->
                IO.puts("dummy_functtion didn't return an :ok atom")
        end
    end

end

GreetUser.hello("Joe")

We can match variables and other structures on the left side of the <- operator, so we can use the value returned by the function inside de with block:

# ./greet_user.exs

defmodule GreetUser do

    def dummy_function, do: {:ok, "dummy function"}

    def hello(user_name)do
        with {:ok, _response} <- dummy_function() do
            IO.puts("Hello, #{user_name}")
        else
            {:error, message} ->
                IO.puts("dummy_functtion return an error: #{message}")
            _ ->
                IO.puts("I can't figure what dummy_function has returned")
        end
    end

end

GreetUser.hello("Joe")

We checked if dummy_function/0 will return an {:ok, response} result, if it does the function proceed and print the greeting. If dummy_function/0 returns an {:error, message} it prints the message with the error. And at last if dummy_function/0 returns something unexpected the last clausule, which matches everything, will be executed printing the generic error message. The last clausule will not match on the other cases ({:ok, response} and {:error, message}) because the others two clausules will match first, remember, the declaration other matter!

With this knowledge we can create an pipeline of functions that will be validated in each step and handle any possible error individually:

def hello(user_name)do
    with {:ok, response1} <- dummy_function(),
         {:ok, _response2} <- dummy_function_2(reponse1) do
            IO.puts("Hello, #{user_name}")
    else
        {:error, message} ->
            IO.puts("dummy_functtion return an error: #{message}")
        _ ->
            IO.puts("I can't figure what dummy_function has returned")
    end
end

And there you have it!

If you can wrap your mind around these Elixir's concepts I'm guarantee that you will have the basic knowledge to handle quite some understanding of an Elixir's code.

Here are some topics for you to get deeper into the language and its ecosystem

Mix

Task runner (similar to composer on PHP), link to the guide and docs

Phoenix

Web framework (similar to Symfony, Laravel, etc... on PHP), link to the site and docs

Ecto

ORM (similar to Doctrine on php), link to the guide and docs

Hex

Package repository (similar to Packgist of Composer), link to the site

References

And here, some usefull links and references that I used to write this article:

Official website: https://elixir-lang.org/
Elixir School: https://elixirschool.com/pt/
Tiny documentary of the language: https://www.youtube.com/watch?v=lxYFOM3UJzo
Elixir lang on twitter: https://twitter.com/elixirlang

I hope that you enjoyed read this article and that was useful to you. If you have any suggestion or feedback leave a comment. This is one of my first articles and I would like to know how I'm doing 😁

Thank you for your time! See you soon 🖖

Entendendo Elixir com ajuda de PHP

Leoni Mella — Thu, 30 Jan 2020 16:32:31 +0000

🇬🇧 Would you like to read this article in english? Learning Elixir with PHP help

Depois de alguns anos e diversas experiências em PHP utilizando WordPress, Laravel, Symfony e Phalcon, tive a oportunidade de trabalhar com Elixir e desde então ela tem sido a minha linguagem para desenvolvimento de novos projetos

Para quem nunca teve contato com uma linguagem funcional pode ser um pouco difícil entender como Elixir funciona, foi o meu caso quando comecei a utilizá-la.

A “ajuda” oferecida por PHP, nesse artigo, não passa de uma mera comparação feita entre as duas linguagens que por sinal não são NADA semelhante.

O que fiz foi implementar a mesma funcionalidade com linguagens diferentes para que você possa comparar a lógica de uma linguagem mais familiar com uma que talvez não seja.

Vou abordar as funcionalidades do Elixir que mais utilizo no dia-a-dia, meio que aplicando a regra 80/20, mas tenho certeza que com esse conhecimento você poderá ao menos ler um arquivo .ex ou .exs e não se perder completamente, caso você seja novo na linguagem.

Antes de começarmos...

Caso você não conheça absolutamente nada sobre Elixir, como é a syntax, seus operadores e primitivos sugiro a leitura do Starting Guide na documentação oficial.

Sem mais demoras, vamos ao código!

Pattern Matching

Acho que a melhor definição do conceito de pattern matching é a seguinte:

Pattern matching é uma poderosa parte de Elixir que nos permite procurar padrões simples em valores, estruturas de dados, e até funções - Elixir School

Mas o que exatamente significa? Para entender melhor precisamos falar sobre o match operator =. Além de utilizado para atribuir valores à variáveis, ele também pode ser usado para decompor estruturas mais complexas como tuplas.

# iex

iex(1)> {a, b, c} = {"São Paulo", "Rio de Janeiro", "Fortaleza"}
{"São Paulo", "Rio de Janeiro", "Fortaleza"}

iex(2)> a
"São Paulo"

iex(3)> b
"Rio de Janeiro"

iex(4)> c
"Fortaleza"

# Another example
iex(5)> {_, "Ecuador", country} = {"Brasil", "Ecuador", "Chile"}
{"Brasil", "Ecuador", "Chile"}

iex(6)> country
"Chile"

Ou obter o primeiro valor de uma lista

# iex

iex(1)> [head | tail] = ["Olá", "Hello", "Hola"]
["Olá", "Hello", "Hola"]

iex(2)> head
"Olá"

iex(3)> tail
["Hello", "Hola"]

Caso uma tupla não possa ser equiparada com o lado esquerdo do operador, isso é, caso a tupla tenha número de campos diferente ou algum valor que não condiz com o lado esquerdo do = uma exception acontecerá:

# iex

iex(1)> {a, b} = {"São Paulo", "Rio de Janeiro", "Fortaleza"}
# ** (MatchError) no match of right hand side value: {"São Paulo", "Rio de Janeiro", "Fortaleza"}
#    (stdlib) erl_eval.erl:453: :erl_eval.expr/5
#    ...

iex(1)> {_, "United States", country} = {"Brasil", "Ecuador", "Chile"}
# ** (MatchError) no match of right hand side value: {"Brasil", "Ecuador", "Chile"}
#    (stdlib) erl_eval.erl:453: :erl_eval.expr/5
#    ...

Os exemplos acima exemplificam a primeira parte da definição de pattern matching. E quanto a parte que fala que podemos procurar padrões em funções? Vamos dar uma olhada.

Para ajudar no entendimento dessa vez vou criar uma classe semelhante em PHP.

Classe PHP

<?php
// ./GreetUser.php

class GreetUser
{
    public function hello($userName)
    {
        echo "Hello, " . $userName;
    }
}

$greetUser = new GreetUser;
$greetUser->hello("Joe");

Módulo Elixir

# ./greet_user.exs

defmodule GreetUser do

    def hello(user_name) do
        IO.puts("Hello, #{user_name}")
    end

end

GreetUser.hello("Joe")

Até aqui, sem novidades, certo? Se chamarmos a função hello/1 ela vai exibir na tela a mensagem “Hello, Joe”. Mesma coisa com a função hello() da classe em PHP.

Mas vamos supor que nem sempre eu teria o nome do meu usuário disponível. Em determinadas vezes a variável user_name poderia ser nil (null em PHP). Como podemos ajustar nosso código para esse requisito?

Classe PHP

<?php
// ./GreetUser.php

class GreetUser
{
    public function hello($userName = null)
    {
        if(is_null($userName)) {
            echo "Hello world!";
            return;
        }
        echo "Hello, " . $userName;
    }
}

$greetUser = new GreetUser;
$greetUser->hello("Joe");
$greetUser->hello(null);

Em PHP poderíamos adicionar um valor default para o parâmetro $userName e tratar esse caso com um if dentro da nossa função exibindo uma mensagem diferente caso o argumento seja null.

Executando GreetUser.php obteríamos o resultado:

"Hello, Joe"
"Hello world!"

Embora a mesma solução seja possível, em Elixir podemos utilizar o pattern matching ao nosso favor para simplificar o nosso código sem a necessidade do if.

Módulo Elixir

# ./greet_user.exs

defmodule GreetUser do

    def hello(nil) do
        IO.puts("Hello world!")
    end
    def hello(user_name) do
        IO.puts("Hello, #{user_name}")
    end

end

GreetUser.hello("Joe")
GreetUser.hello(nil)

Como existem duas funções com o mesmo nome a escolhida será aquela que possuir o parâmetro correto.

Isso quer dizer que somente quando user_name = nil é que a primeira função será executada, caso contrário ele “pula” essa função e vai para a próxima hello/1 declarada neste módulo.

Importante dizer que devido à aridade da função, GreetUser.hello(nil) é diferente de GreetUser.hello(). Em uma expressão invocamos hello/1 e na outra hello/0, que não existe e portanto nos retornaria um erro, fique atento a aridade!

Qualquer tipo primitivo da linguagem pode ser utilizado para pattern matching. Se o módulo GreetUser agora tem que enviar uma mensagem específica para usuários que tenham o nome "Jane”, poderíamos fazer da seguinte forma

Classe em PHP

<?php
// ./GreetUser.php

class GreetUser
{
    public function hello($userName)
    {
        if($userName === "Jane") {
            echo "Nice to see you, Jane!";
            return;
        }
        echo "Hello, " . $userName;
    }
}

$greetUser = new GreetUser;
$greetUser->hello("Joe");
$greetUser->hello("Jane");

Módulo Elixir

# ./greet_user.exs

defmodule GreetUser do

    def hello("Jane" = user_name) do
        IO.puts("Nice to see you, #{user_name}!")
    end
    def hello(user_name) do
        IO.puts("Hello, #{user_name}")
    end

end

GreetUser.hello("Joe")
GreetUser.hello("Jane")

Dessa vez além de especificarmos qual seria o valor de user_name nós também adicionamos o match operator no parâmetro da função: ("Jane" = user_name). Fizemos isso para que possamos utilizar o valor dentro da função. Caso não quiséssemos utilizar o parâmetro podemos omiti-lo ("Jane") ou adicionar um _ underscore na frente dele ("Jane" = _user_name). Com isso o Elixir entende que você está desprezando esse valor e que ele não será utilizado.

Variáveis declaradas, mas não utilizadas recebem um warning no momento da compilação do seu código, fique atento!

Aqui já é possível enxergar um pouco melhor como esse conceito reduz a complexidade em nossas funções. Agora que você entende pattern matching não fica melhor ler a função em Elixir do que em PHP? Não precisamos mais ficar “calculando” ifs para saber qual o resultado esperado, uma bela vantagem, não?

Guards

Se você gostou do conceito de pattern matching você pode ir além utilizando guards. Eles permitem verificações mais completas dos parâmetros que sua função está recebendo.

Guards são definidos com um when após a declaração da função. Enquanto o pattern matching é útil para valores explícitos, com guards podemos criar diversas condições para serem checadas. Podemos checar o tipo de um parâmetro, o tamanho dele se ele é ou não nil, se ele é maior ou menor que determinado valor entre outras.

Voltando ao nosso exemplo GreetUser, podemos utilizar um guard para verificar se user_name é uma string.

Módulo Elixir

# ./greet_user.exs

defmodule GreetUser do

    def hello(user_name) when is_binary(user_name) do
        IO.puts("Hello, #{user_name}")
    end

end

GreetUser.hello("Joe")

A função utilizada no guard is_binary/1 retorna um booleano e com esse resultado (true ou false) hello/1 é invocada ou não. Elixir possui diversas funções “type-checks” como essa que usamos para checar tipos.

Lembrando, que usando guard ou pattern matching você precisa pensar em uma alternativa para o caso em que um parâmetro não se enquadre em nenhuma validação caso contrário um runtime error será lançado

** (FunctionClauseError) no function clause matching in GreetUser.hello/1

O Erro acima aconteceria se nós invocarmos com um inteiro, por exemplo:GreetUser.hello(1).

Como alternativa podemos adicionar mais uma declaração de hello/1 desprezando o parâmetro user_name. Como vimos antes, basta adicionarmos o undersocre na frente do nome do parâmetro: _user_name. Ou simplesmente substituirmos pelo _.

# ./greet_user.exs

defmodule GreetUser do

    def hello(user_name) when is_binary(user_name) do
        IO.puts("Hello, #{user_name}")
    end
    def hello(_) do
        IO.puts("Only string is allowed in this function")
    end

end

GreetUser.hello("Joe")
GreetUser.hello(1)

Importante!

A ordem de declaração das funções em linguagens funcionais é de extrema importância!
No exemplo acima o uso de hello/1 ficou restrita à parâmetros do tipo string. Como alternativa declaramos novamente hello/1 desprezando o parâmetro user_name. Até ai tudo legal, mas e se tivéssemos invertido as ordens de declaração das funções colocando hello(_) antes da hello/1 que possui guard?

# ./greet_user.exs

defmodule GreetUser do

    def hello(_) do
        IO.puts("Only string is allowed in this function")
    end
    def hello(user_name) when is_binary(user_name) do
        IO.puts("Hello, #{user_name}")
    end

end

GreetUser.hello("Joe")
GreetUser.hello(1)

Executando o código acima teríamos o seguinte aviso:

warning: this clause cannot match because a previous clause at line 5 always matches

Nosso código rodaria sem problemas, mas a função hello/1 com o guard when is_binary/1 nunca seria executada porque a hello/1 sem guard é sempre validada antes. Por isso preste sempre atenção à ordem de declaração de suas funções!

Pipe Operator

Esse pode ser um pouco mais complicado para entender, mas em resumo o pipe operator é representado por esse símbolo |> e o trabalho dele é passar o resultado de uma expressão como primeiro parâmetro de outra expressão.

Com isso você pode criar pipelines (sacou o nome?) de execução dada determinada expressão (variável ou função).

Para exemplificar, agora nosso módulo GreetUser deve ser capaz de cumprimentar diversas pessoas cujo os nomes serão enviados em forma de uma lista. Para fazer isso vamos criar uma função hello_group/1 que recebe como argumento users_name que nada mais é do que uma lista contendo o nome dos usuários em string.

Além disso precisamos também tratar os nomes dos usuários para que eles fiquem capitalizados, isso é, somente a primeira letra do seu nome em maiúsculo.

# ./greet_user.exs

defmodule GreetUser do
    def hello_group(users_name) when is_list(users_name) do
        # code
    end
    def hello_group(_) do
        IO.puts("Only lists are allowed")
    end
end

Aproveitamos para adicionar um guard na nossa função para nos certificar de que o parâmetro é mesmo uma lista e também definimos uma hello_group/1 default para ser utilizada caso users_name não seja uma lista.

O próximo passo é manipular a lista aplicando os requisitos acima utilizando o pipe operator. Como primeiro passo, vamos percorrer a lista e normalizar os nomes. Faremos isso com a ajuda do módulo Enum que é um módulo nativo do Elixir para trabalhar com elementos enumeráveis, o que é o caso da nossa lista de nomes

# ./greet_user.exs

defmodule GreetUser do
    def hello_group(users_name) when is_list(users_name) do
        users_name
        |> Enum.map(fn user_name -> String.capitalize(user_name) end)
    end
    def hello_group(_) do
        IO.puts("Only lists are allowed")
    end
end

Vamos quebrar o código acima em pontos chaves:

Invocamos users_name dentro da nossa função
Invocamos |> (pipe operator) abaixo de users_name poderia ser do lado direito também.
Invocamos map/2 do módulo Enum para percorrer a lista de nomes e nos retornar uma lista
Passamos como segundo parâmetro de map/2 uma função anônima fn user_name -> end que será executada para cada nome da lista
Dentro da função anônima utilizamos a função capitalize/2 do módulo String também nativo do Elixir para capitalizar os nomes.

O que precisa ser entendido desse código é que só passamos o segundo argumento para a função map/2 porque o primeiro argumento que deve ser uma lista (no nosso caso a lista com os nomes dos usuários) já foi passada à essa função pelo |>.

Lembre que: “O pipe operator é responsável por passar o valor de uma expressão como o primeiro parâmetro da próxima expressão” No caso nossa primeira expressão é a variável users_name que ao ser processada retorna nossa lista de nomes e uma lista é justamente o que map/2 recebe no primeiro parâmetro, por isso nossa pipeline funciona!

E o segundo parâmetro passado ao map/2 foi uma função anônima (requerida por map/2) que recebe como argumento o elemento da lista que está sendo percorrida para que possamos manipulá-lo.

Em PHP podemos obter o mesmo resultado até aqui dessa forma:

<?php
// ./GreetUser.php

class GreetUser
{
    public function helloGroup($usersName)
    {
        if(!is_array($usersName)) {
            echo "Only arrays are allowed";
            return;
        }

        $usersNameNormalized = array_map(function ($name) {
            return ucfirst($name);
        }, $usersName);
    }
}

O próximo passo nessa função é juntarmos todos os nomes em uma única string. Para isso utilizaremos outra função nativa do Elixir, a join/2 do módulo Enum. Ela recebe como primeiro parâmetro uma lista e como segundo parâmetro um elemento de junção, no nosso caso utilizaremos uma vírgula seguida de espaço em branco, para separar os nomes dentro da string.

Módulo Elixir

# ./greet_user.exs

defmodule GreetUser do
    def hello_group(users_name) when is_list(users_name) do
        users_name
        |> Enum.map(fn user_name -> String.capitalize(user_name) end)
        |> Enum.join(", ")
    end
    def hello_group(_) do
        IO.puts("Only lists are allowed")
    end
end

Classe PHP

<?php
// ./GreetUser.php

class GreetUser
{
    public function helloGroup($usersName)
    {
        if(!is_array($usersName)) {
            echo "Only arrays are allowed";
            return;
        }

        $usersNameNormalized = array_map(function ($name) {
            return ucfirst($name);
        }, $usersName);

        $usersNameString = implode(", ", $usersNameNormalized);
    }
}

Nossa pipeline continua funcionando porque map/2, após ser executada, retorna uma lista e o |> passa essa lista como primeiro parâmetro para a próxima função join/2.

Ótimo! hello_group/1 já consegue normalizar e juntar os nomes enviados como lista em uma única string! Agora só nos resta imprimir nossa mensagem para o usuário.

Até agora o retorno de hello_group/1 seria uma string contendo os nomes de usuários que foi passado à ela. Podemos utilizar hello/1, que recebe como primeiro parâmetro uma string, para exibir a mensagem padrão

# ./greet_user.exs

defmodule GreetUser do

    def hello(user_name) when is_binary(user_name) do
        IO.puts("Hello, #{user_name}")
    end
    def hello(_) do
        IO.puts("Only strings are allowed")
    end

    def hello_group(users_name) when is_list(users_name) do
        users_name
        |> Enum.map(fn user_name -> String.capitalize(user_name) end)
        |> Enum.join(", ")
        |> hello
    end
    def hello_group(_) do
        IO.puts("Only lists are allowed")
    end
end

GreetUser.hello_group(["joe", "jane", "jim"])

Adicionamos hello/1 no final de nossa pipeline concluindo os requisitos exigidos para hello_group/1.

Veja como ficaria o mesmo código em PHP

<?php
// ./GreetUser.php

class GreetUser
{
    public function hello($userName)
    {
        echo "Hello, " . $userName;
    }

    public function helloGroup($usersName)
    {
        if(!is_array($usersName)) {
            echo "Only arrays are allowed";
            return;
        }

        $usersNameNormalized = array_map(
            function ($name) { return ucfirst($name); },
            $usersName
        );

        $usersNameString = implode(", ", $usersNameNormalized);

        return $this->hello($usersNameString);
    }
}

$greetUser = new GreetUser;
$greetUser->helloGroup(["joe", "jane", "jim"]);

Poderíamos melhorar o código PHP quebrando-o em diferentes funções, mas repare que mesmo dessa forma em Elixir temos um código MUITO mais limpo e legível.

Caso você ainda esteja um pouco confuso em como o pipe operator funciona, aqui está uma outra forma de visualizar o mesmo código:

# ./greet_user.exs

defmodule GreetUser do

    def hello(user_name)do
        IO.puts("Hello, #{user_name}")
    end

    def hello_group(users_name) do
        users_name
        |> Enum.map(fn user_name -> String.capitalize(user_name) end)
        |> Enum.join(", ")
        |> hello
    end

    def hello_group(users_name, :notpiped) do
        hello(
            Enum.join(
                Enum.map(
                    users_name,
                    fn user_name -> String.capitalize(user_name) end),
                ", "
            )
        )
    end
end

GreetUser.hello_group(["joe", "jane", "jim"])
GreetUser.hello_group(["joe", "jane", "jim"], :notpiped)

Definimos duas funções hello_group(). Uma com aridade hello_group/1 e outra com hello_group/2. Apesar da aridade diferente, as duas executam o mesmo papel, mas a hello_group/1 cria uma pipeline enquanto a hello_group/2 não, mas as duas chegam no mesmo resultado.

Porém hello_group/1 é bem mais legível e de fácil entendimento se comparada a hello_group/2, concordam? Esse é o propósito do pipe operator, deixar nosso código mais legível.

Para concluir aqui vai uma observação muito importante! Em linguagens funcionais nós não temos a opção de utilizar returns dentro das funções. As funções retornarão o resultado da última expressão executada, vamos explorar mais sobre isso no próximo tópico.

Estruturas de Controle

Vimos que em Elixir é possível simplificar muito nossas funções removendo condicionais através do pattern matching e guards. Mas as vezes não temos outra alternativa a não ser utilizar um if ou switch.

As estruturas de controles presentes em Elixir são: if, unless, case, cond e with.

Como esse é um overview da linguagem, não vou me aprofundar em todas elas com exceção do with, talvez ele cause mais estranheza enquanto as outras são mais familiares.

É importante notar que essas estruturas de controles se comportam como funções e por isso alguns hábitos de outras linguagens devem ser evitados em Elixir. Um exemplo disso é quando você define um valor default para uma variável e dentro de um if você troca esse valor. Algo parecido com isso:

public function anotherFunction() {
    $param = null;

    if ($condition) {
        $param = "PHP";
    }

    return $param;
}

Esse código não funciona do jeito que você espera em Elixir, como if se comporta como uma função ela vai retornar o resultado que foi executado dentro do seu body. Sendo assim o valor que você atribuiu dentro dele para a sua variável não será aplicado pois não faz parte do escopo da função.

Para que isso funcionasse você teria que fazer algo desse gênero:

def another_function do
    param = if condition do
        "Elixir"
    else
        nil
    end
end

Dessa forma o retorno de if seria atribuído à nossa variável.

With

Você pode pensar nele como uma pipeline que checa o resultado de cada expressão e caso o resultado dessa expressão não foi o que você havia descrito ela não executa o código dentro dela. Ou você também pode validar o erro gerado pela expressão para tratá-lo de uma forma mais coerente.

Para ilustrar melhor, vamos adicionar essa estrutura na nossa função hello/1. Criaremos também uma dummy_function/0 que a única coisa que ela faz é retornar o atom :ok, e em hello/1 verificamos se dummy_function/0 realmente volta :ok

# ./greet_user.exs

defmodule GreetUser do

    def dummy_function, do: :ok

    def hello(user_name)do
        with :ok <- dummy_function() do
            IO.puts("Hello, #{user_name}")
        end
    end

end

GreetUser.hello("Joe")

No código acima, a mensagem só será exibida caso dummy_function/0 retornar :ok. Se o retorno for outro a mensagem não será exibida.

Se dummy_function/0 não retornar o esperado, podemos adicionar uma cláusula para tratar o resultado.

# ./greet_user.exs

defmodule GreetUser do

    def dummy_function, do: :error

    def hello(user_name)do
        with :ok <- dummy_function() do
            IO.puts("Hello, #{user_name}")
        else
            _ ->
                IO.puts("dummy_functtion didn't return an :ok atom")
        end
    end

end

GreetUser.hello("Joe")

Podemos também atribuir variáveis do lado esquerdo do <- ou -> que nem fizemos quando vimos sobre pattern matching. Com isso é possível verificar o retorno da função e já atribuir uma variável

# ./greet_user.exs

defmodule GreetUser do

    def dummy_function, do: {:ok, "dummy function"}

    def hello(user_name)do
        with {:ok, _response} <- dummy_function() do
            IO.puts("Hello, #{user_name}")
        else
            {:error, message} ->
                IO.puts("dummy_functtion return an error: #{message}")
            _ ->
                IO.puts("I can't figure what dummy_function has returned")
        end
    end

end

GreetUser.hello("Joe")

No código acima checamos se dummy_function/0 retorna {:ok, _response} Caso um erro ocorra e dummy_function/0 retornar {:error, "dummy function"} nós vamos exibir "dummy function", que foi o erro retornado. E ainda adicionamos uma cláusula default se dummy_function/0 retornar algo totalmente inesperado.

Agora que já temos um bom entendimento sobre o with podemos criar uma pipeline de funções cujo os retornos são verificados pelo with e podemos também tratar individualmente cada etapa:

def hello(user_name)do
    with {:ok, response1} <- dummy_function(),
         {:ok, _response2} <- dummy_function_2(reponse1) do
            IO.puts("Hello, #{user_name}")
    else
        {:error, message} ->
            IO.puts("dummy_functtion return an error: #{message}")
        _ ->
            IO.puts("I can't figure what dummy_function has returned")
    end
end

O código acima cria uma pipeline que checa passo a passo o retorno das funções possibilitando o tratamento personalizado para cada erro que possa acontecer.

And there you have it!

Embora Elixir seja um mundo de funcionalidades e paradigmas diferentes se você possuir um bom entendimento dos tópicos acima você conseguirá se localizar muito bem no código escrito nessa linguagem.

Estes são alguns tópicos importantes para você que deseja continuar interagindo com a linguagem:

Mix

Task runner da linguagem (equivalente ao composer em PHP), link para o guia e documentação

Phoenix

Web framework (equivalente ao Symfony, Laravel, etc... em PHP), link para o site e documentação

Ecto

ORM (equivalente ao Doctrine em php), link para o guia e documentação

Hex

Package repository (equivalente ao Packgist do Composer), link para o site

Referências

Abaixo uma lista de sites, vídeos e outros materiais para você ler e que foram utilizados para compor esse artigo:

Site oficial da linguagem: https://elixir-lang.org/
Para aprender mais: https://elixirschool.com/pt/
Mini documentário da origem da linguagem: https://www.youtube.com/watch?v=lxYFOM3UJzo
Hipster ponto tech com o José Valim sobre Elixir: https://hipsters.tech/elixir-a-linguagem-hipster-hipsters-48/
Principal evento da linguagem no Brasil: https://twitter.com/elixir_brasil

Espero que esse artigo tenha sido útil para você. Caso tenha alguma sugestão e/ou feedback deixe nos comentários, esse é um dos meus primeiros artigos e gostaria de saber como estou me saindo 😁

Obrigado pelo seu tempo e até a próxima 🖖

DEV Community: Ingresse

Docker e Docker Compose um guia para iniciantes.

Docker e Docker Compose um guia para iniciantes.

Antes de começarmos

Parte 01 - Dockerfile, Imagens e Containers

"Pegadinhas"

Parte 02 - Operando o Container

2.1 Criando

2.2 Gerenciando

Parte 03 - Docker Compose não é Docker

3.1 Rodar todos os containers de forma independente

3.2 Agregar todas as tecnologias em uma única imagem

3.3 Criar um docker-compose.yml

Parte 04 - Docker Compose

4.1 Criando o docker-compose.yml

4.2 Melhorando os serviços

4.2.1 App

4.2.2 Nginx e Postgres

4.3 Completando o docker-compose.yml

Parte 05 - Usando o Docker Compose

Parte 06 - Interação entre Containers

Conclusão

Implementando árvores em Elixir

Problema

Prova de conceito

node.ex

tree.ex

Recursive Traversal

Resultados Obtidos

Events

Queries

Performance Statistics

Memory Usage Statistics

Builds

Performance Statistics

Memory Usage Statistics

Recursive Traversal

Performance Statistics

Memory Usage Statistics

Tree to binary

Performance Statistics

Memory Usage Statistics

Binary to Hash

Performance Statistics

Memory Usage Statistics

Serialize

Performance Statistics

Memory Usage Statistics

Conclusão

GitHub Actions - Elixir

Contexto

Básico

name

on

Pode ser um evento apenas:

Pode ser uma lista de eventos:

Pode ser customizado por evento:

jobs

jobs.<id-do-job>.run-on

Pode ser em um tipo de máquina:

Podem ser em múltiplos tipos de máquinas, incluindo ubuntu, macos e windows:

jobs.<id-do-job>.steps

Próximos passos

jobs.<id-do-job>.container

Utilizando serviços

jobs.<id-do-job>.services

Docker Compose

Adotando o Elixir na Ingresse

Prova de conceito

Escolhendo o Elixir

Instalação simples

Documentação e conteúdo

Gerenciador de pacotes

Ferramenta de build

Testes

Produtividade

Processo de mudança

Conclusão

Learning Elixir with PHP help

Before we begin...

`name`

`on`

`jobs`

`jobs.<id-do-job>.run-on`

Podem ser em múltiplos tipos de máquinas, incluindo `ubuntu`, `macos` e `windows`:

`jobs.<id-do-job>.steps`

`jobs.<id-do-job>.container`

`jobs.<id-do-job>.services`