Forem: Trybe

Funções Built In no Elixir

Igor Giamoniano — Fri, 28 Oct 2022 23:36:34 +0000

Também conhecidas como funções internas, as funções built in são recursos muito uteis encontrados na maioria das linguagens de programação.

Nesse capítulo exploraremos algumas que são bastante uteis para diversas situações.

String

Comecemos com algumas bem simples para trabalharmos com string.

String.reverse("Trybe")
# "ebyrT"

String.split("Trybe escola de programação")
# ["Trybe", "escola", "de", "programação"]

String.replace("meen", "e", "o")
# "moon"

String.replace("Vamos usar Javascript", "Javascript", "Elixir")
# "Vamos usar Elixir"

Enum

Agora que já deu pra sentir um gostinho, falaremos do módulo Enum.

O Enum é o módulo que utilizamos no Elixir para trabalhar com dados “enumeráveis”, como Lists, Maps e Ranges.

O Enum.map(), por exemplo, é muito parecido com o .map do Python ou do Javascript, o primeiro argumento é uma coleção e o segundo argumento é uma função, que pode ser anônima, que lida com os valores passados e retorna uma nova coleção.

Enum.map([10, 20, 30], fn num -> num * 2 end)
# [20, 40, 60]

O Enum.reduce() pega uma coleção de elementos e reduz eles a um único resultado, segundo os critérios que passarmos.

Observe o exemplo abaixo:

students = [
    %{name: "Paracelso", media_final: 10},
    %{name: "Rasputin", media_final: 8},
    %{name: "Eliphas Levi", media_final: 9},
]

Enum.reduce(students, 0, fn (%{media_final: media_final}, acc) -> acc + media_final end)
# 27

Uma maneira muito útil de acessarmos uma determinada posição em uma lista é usando Enum.at()

Observe o exemplo:

Enum.at(students, -1)
# %{name: "Eliphas Levi", media_final: 9}

Enum.at(students, 2)
# %{name: "Rasputin", media_final: 8}

É importante ressaltar que estamos utilizando listas nos exemplos, mas também podemos realizar as operações diretamente nos maps.

Enum.map(%{name: "Eliphas Levi", media_final: 9}, fn {_key, value} -> value end)
# ["Eliphas Levi", 9]

Stream

Agora para fechar a seção de funções Built In é importante falarmos sobre Stream!

Muitas vezes precisaremos lidar com uma enorme quantidade de dados e a função Enum armazena seu resultado direto, na memória, o que pode trazer problemas de desempenho.

Com o Stream armazenamos o resultado na memória somente quando ele é implicitamente invocado, ou seja, “Lazy method”.

Observe o exemplo:

Stream.map(students, fn (%{name: name}) -> name end)

#Stream<[
  enum: [
    %{media_final: 10, name: "Paracelso"},
    %{media_final: 8, name: "Rasputin"},
    %{media_final: 9, name: "Eliphas Levi"}
  ],
  funs: [#Function<47.58486609/1 in Stream.map/2>]
]>

No exemplo anterior vemos que o map não foi feito ainda e somente sera efetuado quando invocarmos o resultado, assim otimizamos o nosso fluxo:

Stream.map(students, fn (%{name: name}) -> name end) |> Enum.to_list()
# ["Paracelso", "Rasputin", "Eliphas Levi"]

Conclusão

Nesse artigo aplicamos algumas funções Built in uteis para o nosso dia a dia.

O próximo artigo encerra a série “Meus primeiros passos no Elixir” e falarei sobre a Phoenix uma poderosa framework Elixir para desenvolvimento web.

Como automatizamos a avaliação de projetos com Github Actions e o Broadway do Elixir

Renan — Thu, 08 Sep 2022 19:17:54 +0000

Introdução

Aqui na Trybe, ao final de cada seção de conteúdos, as pessoas estudantes precisam desenvolver um projeto para avaliarmos seu aprendizado. O repositório do projeto é disponibilizado no Github e elas fazem clone para iniciar o desenvolvimento em suas máquinas. A cada commit da pessoa no repositório nós disparamos a execução de uma avaliação através das Github Actions.

Processamento de uma delivery (commit)

Após abrir um pull request com o código desenvolvido, cada commit dispara uma github action que irá avaliar o código da pessoa estudante e guardará no nosso banco de dados informações sobre a avaliação do código dessa pessoa.

Os commits são enfileirados e assim conseguimos controlar o status do seu processamento, para garantir que todos os commits tenham suas avaliações devidamente calculadas. Em caso de falhas, reprocessamos automaticamente a cada 5 minutos.

O processamento do commit no backend foi implementado em cima do conceito de processamento de dados em multi-etapas com a biblioteca Broadway. Consistindo em um módulo produtor que é responsável por buscar no banco todas as deliveries que estão aguardando processamento para repassar ao consumidor. Já o consumidor é o módulo Broadway que é responsável por demandar as avaliações ao produtor, processar a nota e criar o comentário de feedback no Github.

Como temos uma grande quantidade de commits sendo feitos nos projetos, a primeira coisa que tentamos fazer é utilizar os recursos da programação concorrente disponível na linguagem Elixir para processar várias deliveries ao mesmo tempo, com o objetivo de evitar um atraso no feedback para as pessoas estudantes.

No código abaixo, observe nas configurações do Broadway que na linha 10 foi definido qual é o módulo produtor e nas linhas 16 e 17 foi definido a quantidade de processos concorrentes e a quantidade de demanda que cada processo irá solicitar ao produtor.

defmodule Trybe.Consumer do
  use Broadway

  alias Broadway.Message

  def start_link(_opts) do
    Broadway.start_link(__MODULE__,
      name: __MODULE__,
      producer: [
        module: Trybe.Producer,
        transformer: {__MODULE__, :transform, []},
        concurrency: 1
      ],
      processors: [
        default: [
          concurrency: 10,
          max_demand: 10
        ]
      ]
    )
  end

  def handle_message(_processor, message, _context),
    do: Message.update_data(message, &process_data/1)

  def transform(event, _opts),
    do: %Message{data: event, acknowledger: {__MODULE__, :ack_id, :ack_data}}

  def ack(:ack_id, _successful, _failed), do: :ok

  defp process_data(delivery) do
    # => 1- Calcula a nota e salva no banco
    # => 2- Faz request no Github criando o comentário de feedback.
    # => 3- Atualiza o status da avaliação para `finished`.
  end
end

Já no produtor, com base na demanda definida nas configurações do Broadway, seu papel é buscar no banco de dados as deliveries que estão aguardando o processamento e repassar para o consumidor. Caso o produtor não encontre mais deliveries, é feito um agendamento de um novo processo para buscar novas deliveries nos próximos 10 segundos.

defmodule Trybe.Producer do
  use GenStage

  alias Trybe.Deliveries

  def start_link(initial \\ []) do
    GenStage.start_link(__MODULE__, initial, name: __MODULE__)
  end

  def init(deliveries) do
    {:producer, deliveries}
  end

  # Função que irá enviar as deliveries para o consumidor
  def handle_demand(demand, state) when demand > 0 do
    send_deliveries(demand, state)
  end

  # Função que é chamada quando um processo é agendado 
  # solicitando mais deliveries.
  def handle_info({:get_deliveries, demand}, state) do 
    send_deliveries(demand, state)
  end

  defp send_deliveries(demand, state) do
    deliveries = list_deliveries(demand)
    maybe_schedule_next_deliveries(deliveries, demand)

    {:noreply, deliveries, state}
  end

  # Função responsável por buscar novas deliveries 
  # nos próximos 10 segundos caso a quantidade de deliveries 
  # no estado seja menor do que o solicitado.
  defp maybe_schedule_next_deliveries(deliveries, demand) when length(deliveries) == demand,
    do: nil

  defp maybe_schedule_next_deliveries(_deliveries, demand) do
    Process.send_after(self(), {:get_deliveries, demand}, :timer.seconds(10))
  end

  # Função responsável por buscar as deliveries no banco 
  # e mudar o status delas para `processing`.
  defp list_deliveries(demand) do
    with deliveries when deliveries != [] <- Deliveries.list_deliveries_waiting_process(demand),
         {_, deliveries} <- Deliveries.set_processing_status_to_deliveries(deliveries) do
      deliveries
    end
  end
end

Logo abaixo um exemplo de como o Broadway se comporta com as configurações definidas.

Problemas ao fazer requests simultâneas na API do Github

No primeiro momento tudo parecia perfeito, mas infelizmente não funcionou da maneira esperada por causa do rate limit do Github, que acabou gerando um grande atraso na entrega dos feedbacks para as pessoas estudantes.

Na API do Github existem dois tipos de rate limit para garantir a disponibilidade da API para todos. Aqui no post iremos focar apenas no secondary rate limit que é nosso principal vilão, mas saiba que também existe o primary rate limit.

Na documentação do Github existem algumas práticas recomendadas para evitar o rate limit secundário, e os nossos maiores vilões são:

Não faça solicitações simultâneas para um mesmo token.
Solicitações que criam conteúdo que acionam notificações, tais como issues, comentários e pull requests, podem ser ainda mais limitadas.Crie este conteúdo em um ritmo razoável para evitar maiores limitações.

Requisições moderadas ao Github

Sorte a nossa que o Broadway já estava preparado para esse tipo de problema e implementou uma feature que nos possibilita botar o pé no freio do nosso produtor. A configuração é a rate_limiting, com ela é possível definir a quantidade de deliveries que podemos processar em um intervalo de tempo.

defmodule Trybe.Consumer do
  use Broadway

  ......
  ......

  def start_link(_opts) do
    Broadway.start_link(__MODULE__,
      name: __MODULE__,
      producer: [
        module: Trybe.Producer,
        transformer: {__MODULE__, :transform, []},
        concurrency: 1,
        rate_limiting: [
          allowed_messages: 10,
          interval: 30_000
        ]
      ],
      processors: [
        default: [
          concurrency: 1,
          max_demand: 10
        ]
      ]
    )
  end
end

Mas só essa configuração ainda não foi o suficiente, ela apenas desacelera a quantidade de requisições que fazemos no serviço em um intervalo de tempo, mas o problema de requests simultâneas ainda permanece. Dito isso, tivemos que também mudar as configurações dos processors, definindo o campo concurrency: 1 para que exista apenas um único processo recebendo deliveries do produtor evitando requisições concorrentes.

Dessa forma, conseguimos fazer requisições moderadas e sequenciais no serviço do Github sem comprometer o tempo de retorno do feedback para as pessoas estudantes.

Conclusão

A solução implementada nos possibilitou controlar o secondary rate limit e assim conseguimos processar os feedbacks para as pessoas estudantes de forma eficiente, ou seja, com poucas linhas de código podemos reajustar as configurações do Broadway novamente para que o processamento de deliveries possa ser feita de maneira concorrente em grande escala.

Se você tiver curiosidade de saber como é a infraestrutura que permite a Trybe corrigir mais de 20mil avaliações por semana, recomendo também a leitura do post publicado pelo Biasi.

Como utilizamos design tokens na Trybe

Claudio Furini Jr. — Wed, 31 Aug 2022 17:42:23 +0000

Em uma publicação anterior, apontamos a importância da consistência no design de uma aplicação e como isso pode ser alcançado com o uso de design tokens.

Neste post, vamos mostrar como a Trybe utiliza os tokens de design no dia a dia.

Nossos tokens

Nosso time de design definiu 6 categorias de tokens que são usados nos nossos produtos:

Cor
Tipografia
Sombra
Borda
Espaçamentos
Z-index

Não cabe a este post entrar em detalhes de cada valor dos nossos tokens e como foram definidos. A definição dos valores dos tokens de um produto deve partir de uma análise feita pelo time de design para encontrar padrões que irão representar a marca/produto em questão.

Fonte da verdade

Um ponto muito importante para sucesso e adoção dos tokens é ter uma maneira simples onde design e desenvolvimento possam consumir os mesmos valores.

Como fonte da verdade dos nossos tokens, adotamos um arquivo JSON.

Como design constrói e utiliza o JSON?

Sabemos que não é uma experiencia muito boa definir manualmente valores em um JSON. Pensando nisso, buscamos uma ferramenta que nos auxiliasse no processo e encontramos o Figma Tokens.

O Figma Tokens é um plugin disponível na comunidade do Figma, que possibilita a administração de tokens que podem ser aplicados durante a construção de um layout, dessa forma o próprio plugin gera e consome o arquivo JSON.

No caso da Trybe, demos um passo a mais e conectamos o plugin à nossa conta do Github e o JSON oficial fica armazenado no repositório do nosso Design System.

O Figma Tokens também possibilita a adição de temas relacionados aos tokens, como por exemplo um tema escuro. Mas vamos falar sobre dark mode em um outro post.

Como desenvolvimento constrói e utiliza o JSON?

Outro ponto importante da adoção dos tokens de design é o uso deles no nosso código. Mas como podemos usar valores de um JSON no nosso CSS?

O primeiro passo é converter esse JSON em um padrão que possa ser usado pela nossa linguagem de programação. Para isso nós usamos o Style Dictionary. Essa ferramenta nos possibilita converter o JSON em muitos outros formatos, como por exemplo, variáveis de CSS puras.

No caso da Trybe, estamos utilizando uma biblioteca de estilização no JavaScript chamada Stitches. Essa biblioteca já tem suporte a variáveis e nos da uma ótima experiência de desenvolvimento.

Para utilizarmos as variáveis do Stitches, usamos o Styled Dictionary para converter os valores do JSON para variáveis JavaScript e passamos esses valores para a configuração do Stitches.

Assim utilizamos nossos tokens de maneira direta no momento de estilização de um componente.

Conclusão

Utilizando as ferramentas Figma Tokens, Style Dictionary e Stitches a Trybe garante que tanto o time de design quanto o time de desenvolvimento falem a mesma linguagem e utilizem os mesmos valores durante o desenvolvimento.

Esse padrão garante não só um bom alinhamento entre os times, mas diminui a carga cognitiva que nosso time precisa durante a execução de uma tarefa, pois todos esses valores já estão definidos e são usados de maneira semântica.

E assim estamos cada vez mais perto de alcançar a consistência de design no nosso produto.

Data migrations para Phoenix

José Camelo de Freitas — Mon, 29 Aug 2022 18:55:00 +0000

O que são?

Migrations estão geralmente relacionadas a alterações na estrutura do banco de dados, mas é recorrente em ambientes de produção termos também a necessidade de efetuar operações em nossos dados. Chamaremos isso de data migrations. Nessas situações, é comum fazer essas data migrations através do mecanismo das migrations normais, as estruturais, ou até mesmo se conectar diretamente ao banco de dados e executar um SQL com as operações desejadas.

Mas…

Executar a SQL direto no banco não é a melhor das ideias, pois incentiva a falta de code review nessas operações, e é bastante propenso a erro humano, como esquecer uma transação aberta ou fazer um update sem where. Já fazer essas migrações junto das tradicionais migrações de estrutura, é um code smell conhecido.

A solução

Uma solução recomendada é criar Mix Scripts para essas operações em dados, mas com Mix Releases não temos o Mix disponível, pois o Mix é uma ferramenta de desenvolvimento e build, e no binário gerado de uma release o objetivo é não incluir nada que não seja estritamente necessário para que o projeto seja executado. Aqui na Trybe, em vários serviços não temos nem Elixir nem Erlang instalados dentro dos containers — tudo é executado a partir do binário gerado pela release.

Para contornar isso, dentro do nosso serviço responsável por projetos, adotamos uma solução levemente customizada para nossas data migrations.

Nosso serviço de projetos é uma aplicação Phoenix, e nela já tínhamos um módulo chamado Release, responsável por executar as migrações tradicionais, e como a própria documentação diz, esse é o local perfeito para adicionar qualquer tipo de comando customizado que venha precisar ser executado em produção!

No módulo Release, e seguindo o esqueleto da função migrate/0 que já temos por padrão, podemos ter uma função que ficará responsável por executar data migrations no nosso serviço.

Primeiro, vamos definir como serão nossas data migrations!

Elas devem estar em um diretório separado. Podemos colocar essas data migrations em um diretório chamado data_migrations, ao lado do nosso diretório migrations tradicional.
Elas vão receber um Repo para fazer suas operações no banco de dados. Significa que não precisaremos acessar diretamente o módulo Repo da nossa aplicação, receberemos ele como parâmetro de uma função. Já podemos definir que essa função deverá ser chamada run/1.
Elas podem ser executadas “n” vezes, individualmente, e não possuem uma ordem específica.

Com essas premissas já podemos começar nossa implementação:

Essa é a função migrate/0 do nosso módulo Release:

def migrate do
  load_app()

  for repo <- repos() do
    {:ok, _, _} = Ecto.Migrator.with_repo(repo, &Ecto.Migrator.run(&1, :up, all: true))
  end
end

A função migrate/0 é responsável por:

Garantir o carregamento da aplicação;
Pegar uma lista de todos os repos disponível através da repos/0;
Pedir para que o ecto execute as migrações pendentes para cada repo disponível;

Bem simples, nossa função customizada para migrações de dados reaproveitará os passos 1 e 2, só se diferenciando no 3, que irá executar uma data migration a partir de seu nome de arquivo.

Nossa implementação fica assim:

  def migrate_data(file_name) do
    load_app()

    for repo <- repos() do
      with {:ok, migration} <- eval_data_migration(repo, file_name),
           {:ok, _, _} <- Ecto.Migrator.with_repo(repo, &migration.run(&1)) do
        Logger.info("A migração de dados foi executada.")
      else
        {:error, message} -> Logger.error(inspect(message))
      end
    end
  end

  defp eval_data_migration(repo, file_name) do
    with file_path <- get_data_migration_path(repo, file_name),
         true <- File.regular?(file_path),
         {{:module, module, _, _}, _} <- Code.eval_file(file_path) do
      {:ok, module}
    else
      false -> {:error, "Não foi possível encontrar a migração de dados."}
      _ -> {:error, "A migração de dados aparenta ser inválida."}
    end
  end

  defp get_data_migration_path(repo, file_name) do
    repo
    |> Ecto.Migrator.migrations_path("data_migrations")
    |> Path.join(file_name)
  end

Temos 2 funções auxiliares aqui:

get_data_migrations_path/2: será responsável retornar o path do arquivo de migração que será executado.
eval_data_migration/2: irá fazer um eval da migração, retornando uma tupla de sucesso/erro, e o módulo da migração em caso de sucesso

A nossa função migrate_data/1 irá:

Garantir o carregamento da aplicação;
Iterar numa lista de repos;
Para cada repo pegar o path completo do arquivo de data migration;
Fazer o eval da data_migration;
Passar a função run/1 da data migration para o Ecto.Migrator, que irá executar a migração;

Criando uma data migration

Para criar uma data migration basta criar um arquivo no diretório /priv/repo/data_migrations/. Devemos dar um nome descritivo para o arquivo, como fix_trybetunes_module.exs.

Nossa migração só irá precisar ser um módulo simples com nossa função run/1:

defmodule MyProject.Repo.DataMigrations.FixTrybetunesModule do
  def run(repo) do
    repo.update_all(
      from(p in "projects",
        where: p.template == "trybetunes",
        update: [set: [module: "frontend"]] 
      ),
      []
    )
  end
end

Usando as data migrations

Com a nossa nova função Release.migrate_data/1, executar nossas data migrations é tão simples quanto… chamar uma função 😀

Utilizando o IEx:

iex -S mix em ambiente de desenvolvimento;
./release_bin remote em ambiente de produção ou staging, onde um deploy já foi feito, a aplicação já está sendo executada, e só temos o binário dela disponível;

iex(1)> Release.migrate_data("fix_trybetunes_module.exs")
[info] A migração de dados foi executada.

Chamando a função diretamente através do binário de release:

$ ./release_bin eval "Release.migrate_data('fix_trybetunes_module.exs')"
[info] A migração de dados foi executada.

Vantagens

Separação das responsabilidades;
Versionamento e revisão de operações que em outro momento seriam feitas diretamente no banco de dados;
Controle de quando será executado, e a possibilidade de executar a mesma operação quantas vezes se fizer necessário;

E é isso, implementadas as migrações de dados!

Uma introdução ao Pattern Matching

Igor Giamoniano — Fri, 19 Aug 2022 20:42:06 +0000

Intro

Ufa, nós aprendemos bastante coisa sobre a linguagem de programação Elixir!

Configuramos o nosso Setup, iniciamos um projeto no Mix, falamos sobre programação funcional e Aridade.

Agora falemos de um assunto, considerado um dos ‘cores’ do Elixir, falemos de Pattern Matching então prepara o café e vamos lá!

Pattern Matching

Começaremos do início ok? Na maior parte das linguagens de programação o sinal de igual (=) é usado como um operador de atribuição, ou seja, eu atribuo um valor a uma determinada variável, no Elixir isso não se aplica!

No elixir o sinal de igual é um operador de correspondência (’Match operator’).
Vamos dar uma olhada no exemplo abaixo:

x = 1    # 1
1 = x    # 1
2 = x    **(MatchError) no match of right hand side value: 1

Vamos entender o que esta acontecendo, na linha 1 estamos correspondendo o valor 1 a uma variável x, dando um match!

Na linha 2 estamos correspondendo o valor 1 a uma variável que possui valor 1, deu match com certeza!

Na linha 3 estamos correspondendo o valor 2 a variável x que possui valor 1, e isso nitidamente não da match, é exatamente isso que o log esta nos informando!

No Pattern Matching o lado direito deve ser correspondente ao lado esquerdo. Se você veio do JavaScript, deve estar pensando que o Pattern Matching é muito parecido com Destrutcing. Na verdade, são coisas diferentes, mas através do Pattern Matching conseguimos fazer destruct no Elixir, vamos dar uma olhada neste outro exemplo:

[1, x, 3] = [1, 2, 3]
# [1, x, 3] = [1, 2, 3]

x
# 2

No exemplo anterior estamos correspondendo a variável x o segundo valor da lista a direita, também poderíamos fazer o seguinte:

[y, x, 3] = [1, 2, 3]
# [y, x, 3] = [1, 2, 3]

y
# 1

x
# 2

Lembrando que os dois lados devem ser correspondentes, nos exemplos abaixo temos o mesmo erro que vimos la atrás:

[y, x, 3] = [1, 2, 3, 4]
** (MatchError) no match of right hand side value: [1, 2, 3, 4]

[y, x, 3] = [1, 2]
** (MatchError) no match of right hand side value: [1, 2]

Mais alguns exemplos de Pattern Matching

No caso do map não precisamos referenciar todos os valores dos dois lados justamente porque no map não importa a ordem dos elementos, portanto podemos corresponder somente a chave que precisamos do valor.

%{school: school_name} = %{school: "Trybe", country: "BR"}
# %{school: "Trybe", country: "BR"}

school_name
# "Trybe"

Para concluir veja no próximo exemplo como usamos Pattern Matching para controle de fluxo em uma função de cláusula múltipla.

control_function = fn
    {:ok, response} -> "Great: #{response}"
    {:error, response} -> "Error: #{response}"
end


control_function.({:ok, "register concluded"})
# "Great: register concluded"

control_function.({:error, "Disconnected"})
# "Error: Disconnected"

Ao receber o argumento da função o Elixir faz a comparação com a cláusula, caso “dê match” ele envia o retorno esperado, senão envia uma exceção, por exemplo:

control_function.(5)

**(FunctionClauseError) no function clause matching in :erl_eval."-inside-an-interpreted-fun-"/1

Conclusão

Vimos então como o Pattern Matching é poderoso e, porque ele faz parte do core do Elixir, no próximo artigo falaremos sobre funções built in e como usamos no nosso dia a dia, até lá!

Criando consistência de design com tokens

Claudio Furini Jr. — Wed, 06 Apr 2022 20:10:21 +0000

Imagine você entrar em um site e cada elemento da página possui um estilo diferente. Múltiplos tipos de fonte, cada texto com um tamanho, uso de diversos tipos e tons de cores sem nenhuma lógica aparente, espaçamentos entre componentes que nunca se alinham... é um pesadelo tentar entender qualquer coisa nesse cenário.

Para diminuir a carga cognitiva, usuários buscam padrões e modelos que tornem as interações simples e fáceis. No design da experiência do usuário, um dos fatores que contribui para esse objetivo é a consistência.

O que significa consistência em design?

A consistência no design une os elementos, facilita o entendimento da conexão entre os componentes e garante que o seu usuário sinta-se seguro para aprender e a explorar seu produto.

Ao garantir que a consistência seja prioridade, seu produto terá ótima usabilidade e acessibilidade. Os usuários poderão navegar facilmente pelo seu produto sem parar para questionar se estão fazendo algo errado.

Existem diversas maneiras de buscar e garantir consistência no design de um produto. Principalmente no momento de concepção das ideias e protótipos.

O propósito deste artigo não é detalhar todos os métodos. Mas sim falar de um em específico: design tokens.

O que são design tokens?

De maneira resumida, Design Tokens são variáveis semânticas que carregam determinadas informações. Como cores, espaçamentos e tamanhos, que quando sozinhos parecem não ter muita importância, mas que em conjunto são muito relevantes para determinar a consistência de um produto.

Cada token tem um nome exclusivo que faz referência a um valor específico. Por exemplo, quando a pessoa designer precisa definir uma cor de fundo, ao invés de usar o valor #ffffff no elemento, passaria a usar background-primary.

Pode parecer desnecessário, em primeiro momento, utilizar background-primary sendo que essa variável tem o valor #ffffff. Mas imagine que no futuro queremos alterar a cor de fundo do nosso produto para um tom mais cinza, como #fafafa. Como isso seria feito sem tokens?

Teríamos que localizar todos os lugares do nosso produto que estão usando o valor #ffffff, garantir que estão sendo usado para cor de fundo e ai substituir todos para #fafafa. Já com o uso do token background-primary, nós já garantimos que todos os usos são referentes a cor de fundo (o nome semântico nos ajuda a garantir isso) e caso necessitamos alterar o valor, basta alterar em um único lugar para que todo o seu produto reflita essa mudança.

Como design tokens garantem consistência?

Definindo uma lista semântica de variáveis, faz com que a pessoa responsável pela implementação (seja no Figma ou o código CSS) selecione apenas valores existentes ao invés de usar valores e variações específicas.

Introduzir um novo valor, como por exemplo tamanho de fonte, se torna mais difícil. Pois o fluxo de trabalho, das pessoas designers e desenvolvedoras, passa a ser de utilizar valores pré-existentes. Qualquer valor que não tenha uma variável estabelecida, é facilmente identificado como variante.

A utilização do tokens torna o processo saudável, evitando atritos e inconsistências, tornando o processo flexível e dinâmico para todos os envolvidos.

Nos próximos artigos, vamos mostrar a implementação dos design tokens da Trybe e como garantimos que pessoas designers e desenvolvedoras utilizem o mesmo valor tendo uma única fonte da verdade. Aguarde!

Um guia sobre estruturação de pastas para projetos em Next.js

Gabriel Nunes — Fri, 01 Apr 2022 18:23:11 +0000

Sempre que vou iniciar um novo projeto usando Next.js a primeira coisa que vem na cabeça é: como eu mantenho as coisas organizadas em um padrão de Developer Experience semelhante ao que o time do Next já criou?

É realmente impressionante a forma como é simples, fácil de entender e prático. Toda nova atualização mais facilidades são adicionadas ao framework e ele fica cada vez mais maravilhoso (ok, sou fã, como descobriu?).

Aqui na Trybe, começamos recentemente o trabalho de migração do site institucional para Next.js, e tivemos que pesquisar um bocado para entender a melhor forma de organizar as pastas do projeto. Não existe uma unanimidade, algumas pessoas gostam de usar um padrão semelhante ao que usam em projetos em React, outras criam seus próprios padrões. Que foi o nosso caso.

Decidimos primeiro entender qual seria a estrutura de um site, para depois pensarmos na estrutura das pastas, sempre tentando entender o que seria mais fácil de compreender somente olhando para o projeto... e ficou assim:

- site-trybe
    > __tests__
        index.test.tsx
        primeiros-passos.test.tsx
    > components
        > _ui
            > Button
                Button.tsx
                Button.module.scss
                Button.test.tsx
                index.tsx
            > Navbar
        > home
            > Hero
                constants.ts
                Hero.tsx
                Hero.module.scss
                Hero.test.tsx
                index.tsx
        > first-steps
            > Video
            > Form
    > hooks
    > pages
        > primeiros-passos
            confirmacao.tsx
            index.tsx
        _app.tsx
        index.tsx
    > public
        > images
        > fonts
        > icons
    > styles
        theme.scss
        global.scss
    > utils
        > constants
            navigation.ts

Agora, vamos entender melhor o que temos em cada pasta.

Testes de snapshot para cada página

    > __tests__
        index.test.tsx
        primeiros-passos.test.tsx

Para manter a consistência do site, e evitar, ou melhor, avisar, quando alterações sejam feitas em conteúdos ou ordem de componentes, decidimos criar testes simples para cada página do site, apenas para manter o snapshot.

Pasta de componentes separados por páginas

    > components
        > _ui
            > Button
                Button.tsx
                Button.module.scss
                Button.test.tsx
                index.tsx
            > Navbar
        > home
            > Hero
                constants.ts
                Hero.tsx
                Hero.module.scss
                Hero.test.tsx
                index.tsx
        > first-steps
            > Video
            > Form

A pasta _ui é onde ficam todos os componentes em comum entre várias páginas do site, quase que como se fosse o nosso Design System.

Além disso, cada página do site possui uma pasta dentro da pasta de componentes. Dentro dessa pasta, então, são adicionados todos os componentes, com seus arquivos de estilo, constantes que são usadas apenas ali e seu arquivo de teste (caso seja necessário).

Dessa forma, podemos ter dois componentes <Hero />, porém, eles estarão em suas pastas relacionadas a cada página/contexto. Nós também focamos em manter os textos e organização do layout em cada componente, dessa forma, uma página apenas importa os componentes que formam ela.

/* /pages/empresas-parceiras/index.tsx */

/* ... aqui vão todos os imports */

const ParnerCompanies: NextPage = () => (
    <>
      <Page
        title="Contrate programadores e desenvolvedores pela Trybe"
        description="Empresas inovadoras contratam talentos de tecnologia na Trybe. E o melhor: elas não pagam nada por isso. Contrate agora!"
      >
        <Hero />
        <CompleteTraining />
        <WhyHireTrybers />
        <WhatCompaniesSays />
        <OurTraining />
        <WorldOfPossibility />
        <Benefits />
        <HowItWorks />
        <NoCosts />
      </Page>
    </>
  );

export default ParnerCompanies;

Outras pastas complementares

    > hooks
    > public
        > images
        > fonts
        > icons
    > styles
    > utils
        > constants

Fora a pasta pages que é padrão dos projetos Next.js, também criamos pastas para deixar organizados os estilos, os hooks e os utils, como as constantes globais do projeto.

Também separamos a pasta public em outras três: images, fonts e icons.

Organização é tudo para uma pessoa desenvolvedora feliz

Sim, meu amigo e minha amiga. Ter um projeto organizado é o que nos dá vontade de trabalhar todo dia.

Acredito que este artigo pode ajudar você, que estava perdido em qual arquitetura utilizar na hora de deixar o seu projeto Next.js mais arrumadinho.

Como a Trybe corrige mais de 20 mil avaliações por semana!

Gabriel de Biasi — Tue, 29 Mar 2022 18:06:46 +0000

Para quem não conhece a Trybe, é uma escola de desenvolvimento web que tem comprometimento genuíno com o sucesso profissional de quem estuda conosco. Com o Modelo de Sucesso Compartilhado (MSC) ofertado pela Trybe Fintech, a pessoa estudante tem a opção de pagar apenas quando já estiver trabalhando, você acredita nesse nível de confiança?

E para isso precisamos ter um infraestrutura para avaliar todos os projetos enviados pelas pessoas estudantes! Hoje utilizamos GitHub Actions, entretanto, usar os executores oferecidos pelo próprio GitHub Cloud não é o suficiente, pois esgotaríamos os minutos oferecidos pelo plano rapidamente.

Simulação de uma pessoa estudante esperando pela sua avaliação

Logo, optamos por manter nossa própria infraestrutura de self-hosted runners, e melhor ainda, tudo orquestrado usando Kubernetes!

Veja na imagem abaixo como é o esquema de funcionamento. Após isso, temos o passo-a-passo explicando o fluxo.

Passo 1: A pessoa estudante envia seu projeto como um pull request no repositório.

Passo 2: De acordo com a configuração do workflow, o trigger é acionado e uma nova avaliação é inserida na fila de workflows do repositório;

Passo 3: Os self-hosted runners funcionam como pull-based, ou seja, eles fazem pulling no GitHub API aguardando por jobs à serem executados.

É possível que não haja runners disponíveis no momento. Então, nós temos um controller que se comunica com o GitHub API sobre a condição atual dos runners. Se não houver runners disponíveis no momento, o controler aciona o Horizontal Runner Autoscaler para escalar para cima o número de runners em nossa infraestrutura.

Ao mesmo tempo, nosso controler também verifica se não temos "runners demais": Se mais de 50% dos runners atuais estão em idle, isso significa que podemos diminuir o número de runners para melhorarmos nossos custos com infraestrutura. O controler aciona o Horizontal Runner Autoscaler para escalar para baixo o número de runners em nossa infraestrutura.

Passo 4: A avaliação é feita utilizando uma série de actions implementados pelo time da Trybe. Essas actions envolvem linters de arquivos, execução do cypress, testes unitários, etc.

Passo 5: Após executar a avaliação, a última action do workflow envia o resultado obtido para o nosso backend de avaliações, para ser armazenado em nosso banco de dados.

Passo 6: Como muitas pessoas estudantes enviam suas avaliações ao mesmo tempo, foi implementado uma solução utilizando Amazon MQ, para enfilieirar o processo de avaliação e também evitar um possível rate limit na API do GitHub.

Passo 7-8: Após processar a avaliação que estava na fila de mensageria, o backend de avaliação faz um comentário no PR da pessoa estudante, informando o resultado!

Bem simples, né? O processo parece ser complicado, mas é necessário pelo tamanho da demanda que temos em corrigir mais de 20 mil avaliações por semana. Agora veja todo o processo em apenas uma figura:

Processo de correção

Gostou do que viu? Quer ajudar a Trybe a manter esta infraestrutura? Venha pois temos várias vagas abertas!!

Automatizando tarefas com Go

Matheus Mina — Fri, 11 Mar 2022 17:43:48 +0000

Na vida de uma pessoa desenvolvedora, nos deparamos diversas vezes com tarefas monótonas, repetitivas e sempre nos vem a ideia na cabeça de como podemos automatizar isso. Aqui na Trybe, temos dois cenários bem legais de como Go nos ajudou a automatizar algumas dessas tarefas.

O primeiro cenário é o nosso trybe-cli. Isso mesmo, escrevemos um client em Go, para ajudar nossas pessoas desenvolvedoras e executar tarefas repetitivas com alguns comandos. Neste momento, nosso cli nos permite:

criar todos os arquivos da esteira de deploy;
criar flags e segmentos no nosso serviço de feature flags;
gerenciar as tarefas no Jira: mover a tarefa pra doing, mover a tarefa pra review e até mesmo ter algumas estatísticas de tempo do ticket aberto e etc;

Para escrever esse cli, duas ferramentas nos ajudaram muito. A primeira delas é a lib cobra e ela auxilia na criação de CLIs e é utilizada por diversos lugares como Kubernetes, Hugo, GitHub cli, Docker e mais todas os lugares apontados nessa lista. Das diversas funcionalidades, as mais legais são:

sugestões inteligentes: (app srver... did you mean app server?);
criação automática de um help para seu cli;
criação automática de auto-complete para bash, zsh e etc;
reconhece flags de forma automática e inteligente, por exemplo -h e --help;

A segunda ferramenta é a goreleaser, responsável por buildar e gerar os binários em todas as plataformas: MacOS, Linux e Windows. Para nós, isso é extremamente útil, já que não precisamos nos preocupar com as particularidades de cada sistema operacional e nossas pessoas desenvolvedoras não ficam travadas em um sistema ou outro. Isso só é possível porque Go é uma linguagem cross-plataform.

O segundo cenário, é um micro-serviço responsável somente por receber requisições do GitHub. Para explicar o porque fazemos isso, vale a pena explicar um pouco sobre nosso ambiente de desenvolvimento. Hoje temos os seguintes ambientes, que podem ser traduzidos em clusters kubernetes:

produção: ambiente que as pessoas estudantes, candidatas e empregadas utilizam;
staging: ambiente que simula o ambiente produtivo. Utilizado para testar funcionalidades maiores;
preview-app: ambiente de teste para funcionalidades especificas. Cada pull request aberto, em cada repositório nosso, gera um pod neste cluster;
homologação: ambiente de testes utilizados por nossos QAs;

Como podem ver, o cluster das preview-apps cresce exponencialmente, já que pra cada pull request aberto, um pod lá é criado. Para consumir menos recursos, nossos SREs criaram uma tarefa em background para limpar os pods que eram mais velhos que 5 dias. Contudo, ainda era possível melhorar este gerenciamento.

Ao fechar um pull request, seja ao fazer um merge ou ao recusar, aquele pod se torna automaticamente obsoleto e dispensável. Com isso, um pequeno micro-serviço foi criado com a única responsabilidade de escutar estes eventos do GitHub e apagar o pod. Assim nosso cluster só mantem os pods que estão de fato sendo utilizados.

Como podemos ver, Go é bem versátil e que pode nos ajudar em diversos cenários de automação, criando desde clis multi-plataformas até micro-serviços pequenos e robustos. É definitivamente uma linguagem a se avaliar neste cenário.

Elixir - Conceitos Iniciais

Igor Giamoniano — Thu, 10 Mar 2022 22:41:35 +0000

Intro

No último artigo, ensinei a configurar a máquina para começarmos a usar o Elixir, agora falaremos um pouco sobre a linguagem.

Elixir x Erlang

Você deve ter notado no último artigo, que tivemos que instalar o Elixir e o Erlang, mas o que é Erlang?

O Erlang é uma linguagem de programação criada muitos anos antes do Elixir para solucionar demandas relacionadas a rede de telefonia, é uma linguagem muito poderosa porem com uma sintaxe bastante complexa e é aí que entra o Elixir.

O Elixir traz uma sintaxe mais amigável porem sua estrutura é idêntica a do Erlang sendo assim nosso código pode ser escrito em Elixir e depois transpilado para Erlang e por último compilado pela BEAM.

BEAM?

BEAM é um acrônimo para "Bogdan/Björn's Erlang Abstract Machine” (Sendo Bogdan e Björn's o nome original dos criadores) e é simplesmente o nome da Virtual Machine (VM) como a Java Virtual Machine (JVM) para quem conhece Java.

Agora que já falamos bastante, vamos pro código!

Iniciando um Projeto com Mix

Acredito que a melhor forma de se aprender uma linguagem de programação é criando um projeto, então por mais que leiamos a documentação ou vejamos vários vídeos tutoriais, o aprendizado só é consolidado quando realmente aplicamos a linguagem.

Então vamos aplicar alguns conceitos de Elixir, na prática, para isso iniciaremos um projeto com o Mix!

Mix o quê?

Chegamos naquele momento em que parece que o sentido foi deixado para trás, acreditem isso é muito comum principalmente se você veio de outra linguagem de programação e está aprendendo Elixir agora, mas calma que as coisas vão começar a se encaixar.

Mix é uma ferramenta de linha de comando que integra o ecossistema Elixir e a utilizamos para gerenciar uma porção de coisas diferentes no nosso código (ex: Gerar e compilar projetos, rodar ‘Tasks’, gerenciar dependências).

Portanto, iniciaremos um projeto usando Mix!

No seu terminal digite o seguinte comando:

mix new basics

Você vera algo parecido com isso:

~/projetos 
❯ mix new basics
* creating README.md
* creating .formatter.exs
* creating .gitignore
* creating mix.exs
* creating lib
* creating lib/basics.ex
* creating test
* creating test/test_helper.exs
* creating test/basics_test.exs

Your Mix project was created successfully.
You can use "mix" to compile it, test it, and more:

    cd basics
    mix test

Run "mix help" for more commands.

Perceba que ele pede para você entrar no diretório criado para começar, vamos lá:

cd basics

Módulos e Funções

A primeira coisa que devemos notar é como as funções se comportam, como falamos lá atrás o Elixir usa o paradigma funcional, falaremos disso mais tarde, antes disso quero que você preste atenção na sintaxe.

Lá no diretório lib, perceba que foi gerado um arquivo basics.ex e dentro dele um módulo Basics:

defmodule Basics do
end

Para definir um módulo no elixir usamos a sintaxe defmodule você perceberá que basicamente, 100% dos códigos escritos em Elixir estão dentro de algum módulo.

Um módulo é uma coleção de diferentes métodos ou funções.

Então deixaremos de ser tediosos e escreveremos um pouco de código aqui!

Vamos criar uma função create_list que retornara uma lista.

defmodule Basics do
  def create_list do
    [1, 2, 3, "little indians"]
  end
end

Perceba que usamos a sintaxe def para definir uma função create_list dentro do nosso método Basics.

Rodando nosso projeto

Para rodar nosso projeto, utilizaremos o IEx (Interactive Elixir Shell). O IEx é como o Shell do Python ou o IRB do Ruby, podemos escrever qualquer código Elixir dentro dele e executar em Real Time.

Na pasta do projeto em seu terminal digite:

iex -S mix

Com isso você devera abrir o IEx com seu projeto compilado, para testar digite:

Basics.create_list()

Você devera receber a seguinte resposta:

[1, 2, 3, "little indians"]

Um ponto importante que devemos notar é que nossa lista foi retornada automaticamente, isso é chamado retorno implícito onde o último valor da função chamada é retornado.

POO x Programação Funcional

Se você já usou Javascript ou Ruby provavelmente já escreveu algo do tipo:

this.myList = [1, 2, 3, "little indians"]

Como observamos na sessão anterior não precisamos fazer isso no Elixir, o valor simplesmente foi retornado chamando a função que estava dentro do nosso módulo. Isso é extremamente importante quando estamos falando de Programação Funcional x Programação Orientada a Objeto.

Na prática na POO você cria classes e estancia essas classes em variáveis sempre que precisa utilizar os seus métodos, na PF você atribui um valor primitivo a um método que retornara algo.

Não é possível na programação funcional criar ou estanciar classes, lembre-se: um módulo no Elixir é apenas uma coleção de métodos e nada mais.

Para se aprofundar no assunto, estou colocando aqui um link para um curso de Programação Funcional com Elixir

Aridade

Veja bem eu disse ARIDADE (do inglês, Arity) e não RARIDADE ou PARIDADE, mas o que raios é Aridade 🤔?

Vamos criar uma nova função abaixo da que criamos anteriormente chamada shuffle:

def shuffle(list) do    
end

Agora com no IEx usaremos a palavra reservada recompile para recompilar nossa aplicação, basta escrever:

recompile

Depois vamos testar a função que acabamos de criar:

Basics.shuffle

Você verá um erro parecido com esse:

** (UndefinedFunctionError) function Basics.shuffle/0 is undefined or private. Did you mean:
      * shuffle/1
    (basics 0.1.0) Basics.shuffle()

Perceba o que este log esta nos falando, ele diz que a função Basics.shuffle precisa de um argumento shuffle/1, ou seja, a função Basics.shuffle possui aridade 1.

Veja esse exemplo:

defmodule Basics do
    def hello(), do: "Hello World"                              # hello/0
    def hello(name), do "Hello, #{name}"                        # hello/1
    def hello(name1, name2), do: "Hello, #{name1} and #{name2}" # hello/2
end

iex> Basics.hello()
"Hello World"
iex> Basics.hello("John")
"Hello, John"
iex> Basics.hello("John", "Nicole")
"Hello John and Nicole"

No Elixir aridade é um cidadão de primeira classe, ou seja, podemos invocar funções sem necessariamente informar os parâmetros.

Com base no nosso exemplo podemos perceber como o Elixir percebe cada função como diferente uma da outra devido a sua aridade, ou seja, através da aridade sabemos qual função deve ser chamada.

Isso será muito importante no futuro quando falarmos de Pattern Matching.

Para resumir, aridade se refere a quantidade de argumentos que uma função deve receber conforme a sua implementação e por padrão referimos-lhe com / e o número de argumentos do lado direito.

Para se aprofundar no assunto estou colocando um artigo da Elixir School.

Conclusão

Nesse artigo falamos um pouco sobre Elixir, Erlang e Beam, iniciamos nossa primeira aplicação com MIX, falamos um pouco sobre programação funcional e Aridade.

No próximo artigo vamos dar mais funcionalidades para a nossa aplicação.

Te vejo em breve! ;)

Evite configuration drift no seu estado de terraform ao usar aws_security_group

Gabriel de Biasi — Tue, 08 Mar 2022 11:02:37 +0000

O terraform é uma ferramenta fantástica para provisionar e manter o estado de uma infraestrutura, tanto on-premises quanto nos ambientes de cloud. Entretanto, algumas vezes passamos por algumas situações que nós temos uma expectativa de que o terraform funcione de uma maneira, porém o terraform acaba funcionando de outra forma.

Foi o que aconteceu comigo ao utilizar o recurso aws_security_group. Este recurso permite criar um Security Group dentro de uma VPC, que na prática pode ser aplicado a outros recursos, como instâncias EC2, banco de dados, clusters Kubernetes, para fechar portas de conexão e liberar apenas algumas portas específicas (ou nenhuma).

Meu caso de uso foi criar um Security Group para uma instância EC2 que iria trabalhar como um worker, ou seja, essa instância iria obter os jobs através de uma fonte externa, realizar o processamento e enviar o resultado. Em resumo, por trabalhar em pull-based, essa instância não precisaria ter nenhuma regra de ingresso (entrada), apenas uma regra de egresso (saída) para qualquer IP.

Logo, fiz o recurso da seguinte maneira:

resource "aws_security_group" "sg" {
  name   = "my-amazing-security-group"
  vpc_id = aws_vpc.main.id

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

Ao executar o comando terraform apply, obtive a seguinte saída:

gabriel@machine:~/terraform$ terraform apply

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # aws_security_group.sg will be created
  + resource "aws_security_group" "sg" {
      + arn                    = (known after apply)
      + description            = "Managed by Terraform"
      + egress                 = [
          + {
              + cidr_blocks      = [
                  + "0.0.0.0/0",
                ]
              + description      = ""
              + from_port        = 0
              + ipv6_cidr_blocks = []
              + prefix_list_ids  = []
              + protocol         = "-1"
              + security_groups  = []
              + self             = false
              + to_port          = 0
            },
        ]
      + id                     = (known after apply)
      + ingress                = (known after apply)
      + name                   = "my-amazing-security-group"
      + name_prefix            = (known after apply)
      + owner_id               = (known after apply)
      + revoke_rules_on_delete = false
      + tags_all               = (known after apply)
      + vpc_id                 = "vpc-0101010101"
    }

Plan: 1 to add, 0 to change, 0 to destroy.

aws_security_group.sg: Creating...
aws_security_group.sg: Creation complete after 2s [id=sg-0101010101010101]

Ótimo! O terraform criou o security group e eu pude utilizar na instância EC2 que criei. Entretanto, percebi que tinha cometido um erro ao provisionar a instância EC2 e eu precisava me conectar nessa instância usando ssh.

Para possibilitar o acesso, eu precisava criar a regra de ingresso no security group. Logo, fui diretamente no dashboard da AWS, editei o security group manualmente liberando a porta 22 para apenas o meu IP.

Após me conectar na instância e resolver o problema, pensei: “Vou simplesmente executar terraform apply, pois o terraform irá perceber a regra extra no security group e criar um plano para remover esta regra”. Então, ao executar o comando, obtive a seguinte saída:

gabriel@machine:~/terraform$ terraform apply
aws_security_group.sg: Refreshing state... [id=sg-0101010101010101]

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration and found no differences, so no changes are needed.

Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

Na hora fiquei confuso. O terraform não percebeu a regra nova no security group? Fui no dashboard da AWS e vi que a regra de ingresso ainda estava presente! E agora?

Pesquisando melhor, entendi que o recurso aws_security_group não mantém o estado das regras, se isso não for explícito. Ou seja, precisamos deixar explícito na definição do recurso que não queremos nenhuma regra de ingresso. Corrigindo nosso código, ficaria assim:

resource "aws_security_group" "sg" {
  name   = "my-amazing-security-group"
  vpc_id = data.aws_vpc.main.id

  ingress = []    # explicitamente nenhuma regra de ingresso

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

Perceba que o atributo ingress recebe uma lista vazia. Isto deixa explícito que não queremos nenhuma regra de ingresso para este security group. Logo, executando o comando terraform apply novamente, finalmente podemos ter o estado garantido:

gabriel@machine:~/terraform$ terraform apply
aws_security_group.sg: Refreshing state... [id=sg-0110522c7ec4870d0]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # aws_security_group.sg will be updated in-place
  ~ resource "aws_security_group" "sg" {
        id                     = "sg-0110522c7ec4870d0"
      ~ ingress                = [
          - {
              - cidr_blocks      = [
                  - "169.169.169.169/32",
                ]
              - description      = "My IP"
              - from_port        = 22
              - ipv6_cidr_blocks = []
              - prefix_list_ids  = []
              - protocol         = "tcp"
              - security_groups  = []
              - self             = false
              - to_port          = 22
            },
        ]
        name                   = "my-amazing-security-group"
        tags                   = {}
        # (7 unchanged attributes hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

aws_security_group.sg: Modifying... [id=sg-0110522c7ec4870d0]
aws_security_group.sg: Modifications complete after 0s [id=sg-0110522c7ec4870d0]

Apply complete! Resources: 0 added, 1 changed, 0 destroyed.

Ufa! Agora sim o terraform nos garante que este security group não ganhe novas regras através do dashboard da AWS e mantenha este estado pra gente.

Elixir - Configurando o Setup

Igor Giamoniano — Thu, 03 Mar 2022 17:47:52 +0000

Introdução

Antes de começarmos é importante trazer que esse artigo faz parte de uma série de outros artigos, nos quais documentarei a minha experiência pessoal com Elixir e meus primeiros passos.

Vim recentemente do Node.js e todo mundo sabe como é simples configurar o seu setup, baixar o NPM, Snippets no VSCode, etc.

No Elixir não é tão difícil porem tive muita dificuldade de encontrar um passo a passo e acabei pulando etapas o que me deu muita dor de cabeça depois para consertar.

Dito isto, resolvi trazer um passo a passo para você configurar seu setup do zero, bora lá!

P.S. Utilizarei o Linux Mint e você pode adaptar para o seu SO ok?

ASDF (What?)

A primeira coisa que nos vamos instalar na nossa maquina é esse bichinho chamado ASDF e se você nunca ouviu falar nele faço questão de te apresentar.

ASDF e um gerenciador de máquina virtual que nós vamos utilizar para instalar o Elixir e o Erlang.

Então de um gole no café ☕ e vamos começar!

Instalando ASDF-Vm.

Primeiro acesse o site oficial.

Clique em 'Get Started'

Procure o gerenciador de pacotes para o seu SO, no meu caso como estou usando o Mint vou usar o Aptitude (o famoso APT).

apt install curl git

Depois disso vamos clonar o repositório do ASDF na nossa maquina.

git clone https://github.com/asdf-vm/asdf.git ~/.asdf --branch v0.9.0

⚠️ Esse passo é muito importante ⚠️ Vamos combinar a instalação com o Shell, no meu caso como estou usando Oh-My-ZSH vou nessa opção:

Se você estiver utilizando Oh-My-ZSH basta seguir o passo-a-passo do repositório do plugin.

Que é basicamente adicionar essa linha de código ao arquivo ./zshrc fechar o terminal e abri-lo novamente.

plugins=(git asdf)

Caso você esteja utilizando o terminal puro vá à opção Bash & Git.

Basta adicionar essas duas linhas de código no arquivo ~/.bashrc fechar o terminal e abri-lo novamente.

. $HOME/.asdf/asdf.sh
. $HOME/.asdf/completions/asdf.bash

Rode o seguinte comando para testar se deu tudo certo:

asdf --version

Você devera ver algo parecido com isso:

>asdf --version
v0.9.0-9ee24a3

Instalando Plugin Erlang na ASDF.

Beleza 👍, com a ASDF instalada chegou a hora de instalar os plugins, vamos começar pelo Erlang.

Vamos começar rodando o seguinte comando no terminal:

asdf plugin-add erlang

Após isso, precisaremos instalar algumas dependências que estão aqui nesse repositório.

No meu caso, como estou rodando no Mint vou buscar para Ubuntu 20:

sudo apt-get -y install build-essential autoconf m4 libncurses5-dev libwxgtk3.0-gtk3-dev libgl1-mesa-dev libglu1-mesa-dev libpng-dev libssh-dev unixodbc-dev xsltproc fop libxml2-utils libncurses-dev openjdk-11-jdk

Instalando Erlang

Com as dependências baixadas vamos procurar as versões do Erlang com o seguinte comando:

asdf list-all erlang

Seu terminal deve ter uma lista parecida com essa:

Vamos instalar a última versão estável que até o momento desse artigo é a 24.2.1:

asdf install erlang 24.2.1

Você vera a instalação do Erlang e não se preocupe, ela demora e realmente parece que seu computador travou, tenha calma!

Iniciando o Erlang

Agora com o Erlang instalado vamos rodar o comando para iniciar globalmente:

asdf global erlang 24.2.1

E vamos testar abrindo o Shell do Erlang:

erl

Você devera ver algo parecido com isso, basta sair dando CTRL + C duas vezes.

Instalando Plugin Elixir na ASDF.

Ufa! Cansou? Estamos acabando dá mais um gole no café e roda esse comando no terminal.

Vamos rodar o seguinte comando no terminal:

asdf plugin-add elixir

Vamos ver todas as versões do Elixir assim como fizemos com Erlang:

asdf list-all elixir

Instalando Elixir

Como instalamos o Erlang 24 temos que instalar o Elixir OTP para versão 24, a versão mais recente até o momento desse artigo é a 1.13.3-otp-24.

Vamos rodar o seguinte comando:

asdf install elixir 1.13.3-otp-24

Vamos configurar o Elixir globalmente, assim como fizemos com o Erlang:

asdf global elixir 1.13.3-otp-24

Iniciando o Elixir

Vamos testar se deu tudo certo rodando o IEX:

iex

Você deverá ver algo parecido com isso:

Hello World!

E para começar do jeito certo, não se esqueça de não cair na maldição do Hello World, rodando o seguinte comando no IEX:

IO.puts("Hello World")

Be Cool with Livebook

O Livebook é parecido com o Jupyter Notebook do Python, é uma forma de você aplicar, documentar e testar códigos Elixir e salvar seus arquivos MD.

Instalando Livebook

A primeira coisa que vamos fazer é ir até o repositório do Livebook.

Como já estamos com o Elixir instalado globalmente vamos rodar o seguinte comando.

mix escript.install hex livebook # mix é um comando global do Elixir

A instalação pode demorar um pouco e pedira algumas confirmações no processo, no final ele perguntara se você quer realmente instalar o livebook, vamos responder Y.

Feito isso, como estamos rodando o ASDF precisamos usar o RESHIM para reconhecer os novos comandos.

asdf reshim

Por fim podemos iniciar o Livebook com o seguinte comando.

livebook server

Ele rodara na porta 8080 na sua localhost.

Conclusão

Nesse artigo aprendemos a instalar e configurar a ASDF-VM para rodar o Erlang e o Elixir e instalar o Livebook local.

Até a próxima!