DEV Community: Mário Melo

Dependências: Bibliotecas ou OTP Applications?

Mário Melo — Sat, 20 Jun 2020 21:03:18 +0000

O projeto: Scrumchkin Online

Há cerca de um ano atrás criei um jogo de cartas para ensinar Scrum: o Scrumchkin. O jogo tornou o processo de aprendizado mais divertido e foi adotado por Scrum Trainers de diversos países, até que a pandemia inviabilizou qualquer turma presencial.

E foi daí que surgiu meu projeto pessoal: criar uma versão online do Scrumchkin. O que seria uma ótima oportunidade para brincar e aprender mais sobre Phoenix Liveview.

Inicialmente, pensei na seguinte estrutura para o projeto:

Desta forma, seria possível criar jogos em processos separados e ter um registro com identificadores únicos de cada jogo para que cada partida pudesse ser acessada através de uma URL diferente.

Exemplo:

O usuário acessa a URL http://scrumchkin.com/game/abc123
A aplicação web pergunta ao Registro de Jogos onde está o jogo abc123
O Registro de Jogos encontra o PID da partida e retorna para aplicação web

O Registro de Jogos como uma biblioteca

Tendo em mente o princípio da responsabilidade única, o desenho acima deixa bem evidente a existência de 3 projetos diferentes: O Registro de Jogos, o Servidor de Jogos e a Interface Web.

Os próximos parágrafos vão falar sobre alguns aspectos técnicos de Elixir a título de curiosidade. Se você quiser apenas entender a diferença entre uma biblioteca e uma aplicação OTP basta pular esta parte :)

Tecnicamente o Registro de Jogos é extremamente simples: ele vincula um ID único a uma partida. Ele é basicamente um dicionário que tem como chave um UUID e como valor um PID de um GenServer para uma partida.

Inicialmente, criei o Registro de Jogos como uma biblioteca capaz de fazer operações CRUD em uma tabela ets:

defmodule GameRegister do
  def init() do
    :ets.new(:scrumchkin, [:set, :public, :named_table])
  end

  def save(value) do
    key = UUID.uuid1()
    :ets.insert_new(:scrumchkin, {key, value})
    key
  end

  def delete(key) do
    :ets.delete(:scrumchkin, key)
  end

  def get(key) do
    :scrumchkin
    |> :ets.lookup(key)
    |> format_result
  end

  def list_all do
    :ets.tab2list(:scrumchkin)
  end

  defp format_result([]), do: {:error, "Game not found"}

  defp format_result(item_list) do
    item_list
    |> hd
  end
end

TL;DR - A biblioteca armazena o estado atual de partidas e as vincula a um código identificador. Ela é capaz de listar, obter, salvar e deletar partidas do registro.

Um pequeno problema

Para que eu pudesse utilizar a tabela ets, ela precisava existir. Isto significa que em algum momento a função init do código acima precisaria ser chamada pela minha aplicação web.

  def init() do
    :ets.new(:scrumchkin, [:set, :public, :named_table])
  end

Mas isso vai contra o princípio de responsabilidade única que utilizei para dividir este projeto em partes menores, certo?

O Registro como uma aplicação

Mas o que é uma dependência como biblioteca? Ela é uma engrenagem que faz parte de um todo; algo bem parecido com uma peça de Lego. Sabemos onde estão os pinos e buracos e a utilizamos para construir algo maior.

A dependência de uma aplicação OTP é um pouco diferente.

Pense em um carro. Geralmente, carros têm um mecanismo de refrigeração do motor que é iniciado no momento em que você vira a chave e dá a partida. O carro depende deste mecanismo para funcionar, mas ele é um tanto quanto independente: muitas vezes ele é acionado quando desligamos o carro (aquele barulho de ventilador que vem de debaixo do capô, principalmente em dias quentes).

Esse mecanismo de refrigeração tem interfaces com o motor do carro, mas controla seu próprio estado. Existe uma relação clara de dependência, mas não de controle. O motor depende do sistema de refrigeração para não superaquecer, mas não o controla.

E o mesmo precisava acontecer com meu Registro de Jogos, que ficou assim:

defmodule GameRegister do
  use GenServer

  def start_link(state) do
    GenServer.start_link(__MODULE__, state, name: __MODULE__)
  end

  def init(stack) do
    :ets.new(:scrumchkin, [:set, :public, :named_table])
    IO.puts("Tabela scrumchkin criada")
    {:ok, stack}
  end

  def handle_call({:save, game}, _from, state) do
    key = UUID.uuid1()
    :ets.insert_new(:scrumchkin, {key, game})
    {:reply, key, state}
  end

  def handle_call({:delete, game_id}, _from, state) do
    :ets.delete(:scrumchkin, game_id)
    {:reply, :ok, state}
  end

  def handle_call({:get, game_id}, _from, state) do
    result =
      :scrumchkin
      |> :ets.lookup(game_id)
      |> format_result

    {:reply, result, state}
  end

  def handle_call(:list_all, _from, state) do
    {:reply, :ets.tab2list(:scrumchkin), state}
  end

  def save(game) do
    GenServer.call(__MODULE__, {:save, game})
  end

  def delete(game_id) do
    GenServer.call(__MODULE__, {:delete, game_id})
  end

  def get(game_id) do
    GenServer.call(__MODULE__, {:get, game_id})
  end

  def list_all do
    GenServer.call(__MODULE__, :list_all)
  end

  defp format_result([]), do: {:error, "Game not found"}

  defp format_result(item_list) do
    item_list
    |> hd
  end
end

Mas... o que muda?

Minha aplicação web não é responsável por criar a tabela ets. Ela apenas diz que depende do Registro de Jogos e que ele é agora uma aplicação extra.

A alteração no arquivo mix.exs é simples:

  def application do
    [
      mod: {Scrumchkin.Application, []},
      extra_applications: [:logger, :runtime_tools, :game_register, :game_engine]
    ]
  end
  defp deps do
    [
      {:game_engine, path: "../game_engine"},
      {:game_register, path: "../game_register"}
    ]
  end

Agora, toda vez que inicio minha aplicação com um mix phx.server omeu registro de jogos é iniciado automaticamente e assume a responsabilidade de criar a tabela ets onde vai armazenar os PIDs das partidas de Scrumchkin.

A minha aplicação web depende do Registro de Jogos, mas confia que ele consegue resolver seus problemas sozinho.

Os perigos da cultura da perfeição

Mário Melo — Tue, 09 Jun 2020 00:39:33 +0000

Este texto é uma tradução de um post escrito por mim no Medium em inglês. Link original: Medium

Errar ou não errar, eis a questão

Enquanto seres humanos, todos somos propensos ao erro. No entanto, muitos têm dificuldade de aceitar isso.

Quando você dá o seu melhor para alcançar um objetivo e eventualmente as coisas não saem como o planejado, o que acontece?

Você já se prepara para algum tipo de penalidade que vem pelo caminho?

Ambientes sem espaço para erros

Qualquer que seja sua resposta para a pergunta, ela foi pelo menos parcialmente criada pelo ambiente no qual você viveu até agora.

Você foi livre o bastante para falhar enquanto era jovem?

Você trabalha em uma empresa onde as pessoas s√£o punidas quando se enganam?

Você se sente confortável quando encara pessoas que decepcionou?

Um ambiente onde falhas não são toleradas limita experimentos: tudo precisa dar certo, e quando isto n√£o acontece alguma pessoa será penalizada.
Esta penalidade pode vir em forma de demissão, palmadas dos pais ou at√© mesmo o fim de relacionamentos.

Você sabe bem do que estou falando.

Você está errado. Que vergonha!

Se você já passou por este tipo de ambiente (e as chances são bem grandes) você sabe o quanto precisa pensar e calcular antes de dar cada passo para frente. Ou para trás.
Você precisa pensar e repensar cada movimento, pois se você falhar a punição estará logo ali lhe esperando.

As consequências das condenações

Bem, se você olhar na face do mal, o mal estará olhando de volta para você. E quando lhe tiram o direito de falhar você pode começar a achar isso natural e replicar o mesmo comportamento.

Digo isso porque isso aconteceu comigo, e na medida em que comecei a tentar reverter o problema percebi algumas consequências diretas deste tipo de cultura.

Estagnação

Nós geralmente evoluímos por tentativa e erros. E aceitamos conceitos aprendidos na prática mais facilmente do que aqueles aprendidos pela teoria.

Por que nós caímos, mestre Bruce? Para podermos aprender a nos levantar novamente. - Alfred Pennyworth

Na empresa onde trabalho estamos sempre nos incentivando a tentar coisas novas. Independentemente do que venha à cabeça, todos se sentem livre para propor e contestar idéias com qualquer um.
Falhas são toleradas desde que possamos aprender alguma coisa com elas, e isto nos tem feito evoluir de maneira rápida e constante.

Se ninguém tivesse esta liberdade para falhar, perderíamos nossa autonomia e auto-confiança para tentar novas idéias e provavelmente ainda estaríamos presos em 2011 (Data de fundação da empresa).

Procrastinação

Eu não posso falhar, então preciso trabalhar nisto até ficar perfeito. E não importa quanto tempo leve.

Eu quero um novo engano, perder é melhor que hesitar - Queens of the Stone Age

Certa vez trabalhei em um projeto que visava aprimorar um indicador interno de uma empresa de 10% para 90%.
Depois de 5 meses de trabalho o projeto j√° era capaz de aumentar o indicador para algo pr√≥ximo de 65% caso fosse implantado.

Os responsáveis pelo projeto preferiram não implantar enquanto não fosse possível chegar os 90% desejados. Isto durou 2 anos inteiros.

Durante 2 anos a empresa continuou com seu indicador na casa dos 10% enquanto poderia ter algo próximo de 65% porque ninguém quis dizer
"Ei, ainda não foi possível chegar nos 90%, mas podemos começar com 65% e evoluir aos poucos".

E provavelmente teriam alcançado os 90% muito mais rapidamente se tivessem arriscado.

Mas falhar era pesado demais. E demorar pra falhar faz com que demoremos para evoluir.

Mentiras e Apatia

A casa está em chamas mas ninguém tem coragem de chamar os bombeiros. Inclusive, parece que jogaram o isqueiro fora porque ele poderia ligar alguém ao foco do incêndio.

Não fui eu - Shaggy (e 94.7% da humanidade)

É difícil encontrar alguém com mais informações sobre um problema do que a pessoa que o criou inicialmente.
Se esta pessoa se sentir confortável o suficiente para assumir o erro, sua ajuda pode ser crucial para a solução do mesmo.

Quando não há espaço para erros eles não desaparecem, eles apenas somem de vista: vão para debaixo do tapete.

É por isso que retrospectivas são essenciais: elas abrem um espaço para falarmos sobre nossos erros e aprender com eles.
É onde aprendemos a limpar a poeira que às vezes fica acumulada embaixo do tapete.