DEV Community: Leoni Mella

O que é um produto?

Leoni Mella — Sun, 08 May 2022 23:32:21 +0000

Faz tempo que penso em criar algum produto / empresa com as habilidades que adquiri ao longo dos anos como desenvolvedor, mas nunca tive um feeling do que fazer.

E ai um tempo atrás no trabalho aconteceu uma coisa que achei muito interessante.

Durante uma chamada de vídeo, com um possível fornecedor, eles apresentaram o produto deles e eu fiquei de boca aberta porque eu tinha desenvolvido a mesma coisa em 2018!!

O ano era 2018

Uma empresa da Estônia entrou em contato comigo pelo LinkedIn interessada no meu perfil e depois de uma conversa rápida marcamos a primeira entrevista.

Logo em seguida me passaram o teste técnico que era fazer uma API capaz de ler arquivos .csv e salvar o conteúdo em um banco de dados.

Se você quiser dar uma olhada no resultado desse teste ele está público no meu GitHub.

Mas vou deixar um disclaimer aqui devido ao fato dele ser bem antigo então não sei se ele funciona ainda hahaha.

Em todo o caso: Fractory

Cumpri os requisitos do teste e ainda fiz uma parada que se houvesse um erro em uma linha, ele retornava a mesma para o usuário pedindo para ele corrigir.

Ficou um projeto bem legal! Feito em PHP (com Laravel) e JS (front em React).

Apesar de gostarem do resultado e me chamarem para a última entrevista acabei não passando para a vaga, mas sem problemas, faz parte.

Voltando para 2022...

Eu conheci a FlatFile, uma empresa fundada em 2019 que levantou ~7.9M de dólares e o que eles fazem é exatamente a mesma coisa que o meu repozinho em PHP faz!!!

Claro que eles fazem de um jeito MUITO melhor e mais elegante, mas cara, o que eu fiz foi no mínimo o MVP da FlatFile.

E isso me faz pensar...

Deve existir mais um monte de coisas simples que nós fazemos e resolvemos durante nosso dia que teria espaço para crescer em algo maior.

Igual a FlatFile fez com uma ideia tão simples, mas que é uma dorzinha chata em várias aplicações e sistemas.

E também após esse episódio fico me perguntando:

"o que mais eu já fiz ou que eu faço que poderia virar um produto oferecido por uma empresa?"

Ainda não tenho uma resposta para essa pergunta.

Será que você também já não fez alguma coisa que poderia ter um valor grande e que pessoas estejam dispostas a pagar por isso?

Faz a gente pensar nas possibilidades, né?

Obrigado pelo tempo

🖖

Nasce um programador

Leoni Mella — Mon, 11 Jan 2021 15:15:27 +0000

E ai pessoal, Leoni aqui, voltando a publicar depois de quase um ano sem publicar nada 😮.

Para ganhar um pouco de inércia na criação de conteúdo eu queria contar para vocês como que eu comecei a programar e como construí a minha carreira no desenvolvimento.

Apesar de ser um tema bastante documentado, acredito que cada pessoa tem uma experiência única e por isso vim aqui contar um pouco do que passei, então bora lá!

Antes da programação só existia o caos!

Acho importante dizer logo de cara que eu nem sabia o que era programação, na realidade eu não tinha ideia do que queria fazer da vida.

E os primeiros anos da minha "carreira" refletiu bastante esse problema, pois sem saber muito bem o que fazer, fui aproveitando as oportunidades que apareciam.

Fui de montador veicular à assistente de compras, passando por corretor de imóveis, motorista Uber e algumas tentativas de "empreender" fracassadas.

Pois é, eu fazia o que aparecia na esperança de encontrar algo que eu realmente gostava.

Escrevi meu primeiro código no final de 2014, enquanto era corretor de imóveis, pois queria criar um site para anunciar os imóveis que eu poderia vender.

Resultado? Não fiz site nenhum e não aprendi a programar também. Beleza, vida que segue, mas gostei muito de ter aprendido um pouco sobre criação de sites e ter uma introdução a HTML e CSS

Até que no final de 2015 eu fui demitido do meu emprego de assistente de compras, que aliás eu achava um saco (talvez por isso mesmo eu tenha sido demitido...) e resolvi dar mais uma chance para "aprender a criar um site"

E daí em diante, não parei mais! 🚀

Nasce um programador

Ainda em 2015 eu comprei o curso Design and develop a killer website with html5 and css3 na Udemy.

É um curso bem simples sobre criação de websites usando HTML e CSS. Concluí o curso bem rápido e comecei a praticar criando sites pequenos para alguns amigos, tudo na faixa.

Depois de achar que tinha dominado bem HTML e CSS comecei a estudar JavaScript e PHP também em cursos onlines.

Depois de uns 5 meses eu senti que dava pra arriscar algumas entrevistas e comecei a montar um portfólio básico.

E foi em maio de 2016, 7 meses depois de começar a programar que consegui meu primeiro trabalho como Desenvolvedor Front-End!

Pausa para uma reflexão

Eu entendo o quanto eu fui privilegiado aqui. Minha vida estava estável o suficiente para que eu dedicasse 6 a 7 meses a uma prática sem precisar me preocupar com a minha sobrevivência uma vez que sai com uma grana da minha demissão e ainda morava com os meus pais.

Muita gente que está lendo isso não tem condição alguma de fazer, de pausar a vida para se dedicar a algo que elas gostem, por isso sou muito grato pela oportunidade que tive.

No entanto, mesmo sem dispor desse tempo ainda é possível aprender a programar. Se você tem esse objetivo, não desista e saiba que você tem uma comunidade de desenvolvedores e desenvolvedoras incríveis que vão te ajudar a chegar onde você quer.

Se dedique o quanto você conseguir, mesmo que for só alguns minutos por semana e tenha consistência que o resultado vai chegar, foque no longo prazo e tente fazer pequenas coisas, mas faça!

O primeiro emprego

Comecei a trabalhar em uma agência digital fazendo temas institucionais no WordPress para os clientes que eles possuíam. Eu era o único desenvolvedor lá e o trabalho era bem tranquilo.

Mas devo confessar que eu não fazia ideia de como era programar um tema de WordPress antes de fazer a entrevista nesta agência 😅.

Eu tinha um curso comprado que ensinava exatamente isso, mas nunca tinha feito ele e durante a entrevista quando me perguntaram se eu sabia mexer com o WordPress eu dei uma leeeeve enrolada, joguei um "veja bem..." e "conheço o básico" e assim que eu saí da entrevista fui correndo para casa começar o bendito curso Hahahaha.

Eu sei, não foi o mais correto a se fazer, mas eu tinha certeza que eu conseguiria aprender a tempo e apesar de eu não entender especificamente o WordPress eu já tinha uma boa base de PHP, por isso senti essa confiança.

No final, tudo deu certo. Trabalhei nesta agência por quase um ano e depois saí dela procurando um lugar de volta na minha cidade natal, São Paulo, mas a experiência toda lá foi excelente.

4 anos depois...

Uma vez que você consegue um emprego como programador o crescimento na área fica mais fluído e natural.

Frequentemente você precisa aprender a usar uma ferramenta, linguagem ou recurso que você não conhece e aí você começa a estudar, praticar e implementar essas coisas novas e com isso vai montando um repertório cada vez maior de conhecimento.

E foi exatamente assim que eu passei esses últimos 4 anos, desde que comecei a programar. No meu caso as coisas aconteceram mais ou menos assim:

1) Primeiro emprego HTML e CSS, com uma pitada de PHP e JavaScript.

2) Segundo, mergulhando um pouco mais no desenvolvimento de temas em WordPress e entendimento mais profundo em PHP, MySQL e JavaScript.

3) Terceiro, agora trabalhando como Fullstack em PHP, pude aprender a utilizar frameworks como: Laravel, Symfony.

4) Quarto, programador back-end em 3 linguagens principais: PHP, Elixir e Python. Diversas outras ferramentas nessas linguagens aprendidas e utilizadas.

É incrível ver como cada coisinha nova que aprendo vai se acumulando nesse, agora, grande repositório de conhecimento. O que me permite crescer cada vez mais.

É claro que nessa contagem eu listei apenas as experiências que agregaram todo mundo vai passar por perrengues, mas no meu caso eles foram exceções bem raras (ainda bem) e sinceramente não merecem o meu tempo - nem o seu.

A melhor profissão do mundo

Ok, talvez não seja, mas eu amo o que faço.

É muito legal ver o quanto eu era perdido, profissionalmente, e como estou agora... fazendo o que amo realmente!

Apesar disso eu penso na programação como um meio e não um fim. Eu descobri no que eu sou bom e quero utilizar dessa habilidade para construir uma vida melhor para mim e minha família.

Pra mim, programação é uma habilidade, uma ferramenta e não um objetivo de vida.

E espero tirar o máximo de proveito dessa habilidade e poder ajudar pessoas que também desejam aprender como dominá-la.

E pra encerrar

O melhor de programar é a comunidade. Sempre muito colaborativa e preocupada em fornecer conteúdo de qualidade e acessível.

Por isso, recentemente, passei a produzir conteúdo na esperança de conseguir devolver um pouco todo o conhecimento que adquiri para essa comunidade maravilhosa e ajudar tantos outros que estão começando nessa jornada.

Se você gostou desse artigo, não deixe de me seguir aqui, e em outras plataformas onde eu produzo conteúdo. Gosto de conversar sobre programação e se tiver alguma dúvida ou gostaria de algum conselho, não se acanhe! Pode me procurar!

Meu perfil aqui, na comunidade Dev: leonimella
Meu Twitter, praticamente a única rede social que uso ferquentemente @LeoniMella
Meu canal de lives na Twitch: MrLeoni, essa é minha forma preferida de gerar conteúdo!
E não podia faltar, meu perfil no Github: leonimella

E como sempre, obrigado pelo seu tempo e até a próxima 🖖

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 🖖

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 🖖