DEV Community: Zoey de Souza Pessanha

Técnicas de Concorrência e Gerenciamento de Estado em Elixir com FSM

Zoey de Souza Pessanha — Fri, 21 Jun 2024 19:09:00 +0000

Introdução

Elixir é uma linguagem funcional que roda na máquina virtual BEAM, a mesma do Erlang, famosa por suas capacidades de concorrência e tolerância a falhas. Um dos padrões poderosos que podem ser implementados em Elixir é a Máquina de Estado Finito (FSM - Finite State Machine), combinada com processamento assíncrono. Este artigo explora como esses padrões podem beneficiar programas em Elixir, proporcionando controle sobre o fluxo de eventos e melhorando a eficiência e a robustez dos sistemas.

Máquinas de Estado Finito (FSM)

Uma Máquina de Estado Finito é um modelo computacional que consiste em um número finito de estados, transições entre esses estados, e ações, que podem ser acionadas por eventos. Em um sistema FSM, um objeto pode estar em apenas um estado de cada vez, e ele pode mudar de estado em resposta a um evento. Cada transição pode ser associada a uma ação específica.

Benefícios da FSM

Organização e Clareza: FSM ajuda a organizar e clarear o comportamento de sistemas complexos, tornando o fluxo de eventos mais previsível e fácil de entender.
Controle de Fluxo: Com FSM, o controle do fluxo de estados é explícito e definido claramente, permitindo transições apenas quando condições específicas são atendidas.
Facilidade de Manutenção: FSM permite encapsular a lógica de estado em um único lugar, facilitando a manutenção e atualização do sistema sem introduzir bugs.

Exemplo de FSM

Considere um sistema simples de autorização de pagamento com os seguintes estados: pending, authorized, denied e failed.

Estado Inicial: O pagamento começa no estado pending.
Transição para authorized: Quando uma solicitação de autorização é aprovada, o estado muda para authorized.
Transição para denied: Se a solicitação for negada, o estado muda para denied.
Transição para failed: Se houver um erro no processamento, o estado muda para failed.

Um fluxo simplificado de FSM poderia ser representado assim:

defmodule PaymentFSM do
  @moduledoc """
  Define a FSM para estados de pagamento.
  """

  use Fsmx.Fsm,
    transitions: %{
      "pending" => ["authorized", "denied", "failed"],
      "authorized" => [],
      "denied" => [],
      "failed" => []
    }
end

Aqui usamos a biblioteca Fsmx, mas é possível usar funções simples ou mesmo o ecto para definir uma FSM.

Neste exemplo, um pagamento pode mudar de pending para authorized, denied, ou failed. Uma vez que está em authorized, denied, ou failed, ele não pode transitar para outros estados.

Processamento Assíncrono

O processamento assíncrono permite que operações sejam executadas em paralelo ou de maneira não bloqueante, aumentando a eficiência e capacidade de resposta do sistema. Em Elixir, isso é conseguido utilizando processos leves gerenciados pela máquina virtual BEAM.

Benefícios do Processamento Assíncrono

Escalabilidade: O processamento assíncrono permite que múltiplas tarefas sejam executadas simultaneamente, aumentando a escalabilidade do sistema.
Responsividade: Sistemas assíncronos podem continuar a responder a novas requisições enquanto outras operações estão em andamento.
Tolerância a Falhas: A arquitetura de supervisão de Elixir permite que processos falhem e sejam reiniciados sem afetar o restante do sistema.

Exemplo de Processamento Assíncrono

Imagine um sistema que processa eventos de pagamento. Cada evento pode desencadear várias operações, como verificação de saldo, registro de transações, etc. Para não bloquear o processamento de novos eventos, podemos usar tarefas assíncronas.

defmodule PaymentProcessor do
  @moduledoc """
  Processa eventos de pagamento de forma assíncrona.
  """

  use GenServer

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

  def process_event(event) do
    GenServer.cast(__MODULE__, {:process, event})
  end

  @impl true
  def init(:ok) do
    {:ok, []}
  end

  @impl true
  def handle_cast({:process, event}, deadletter) do
    case handle_event(event) do
      :ok -> {:noreply, deadletter}
      {:error, reason} -> {:noreply, [event | deadletter]}
    end
  end

  # dependendo da complexidade, podem existir
  # diferentes módulos de handler para eventos
  defp handle_event(event) do
    # Lógica para processar o evento de pagamento
    # Efeitos colaterais
    # Observabilidade
    IO.puts("Processando evento: #{inspect(event)}")
  end
end

Neste exemplo, cada evento é processado em uma nova tarefa, permitindo que o sistema continue a receber e enfileirar novos eventos sem esperar que os eventos anteriores sejam processados.

Lock Otimista

O Lock Otimista é uma técnica utilizada para lidar com concorrência em sistemas distribuídos. Ao contrário do Lock Pessimista, que bloqueia os recursos até que uma transação seja concluída, o Lock Otimista assume que as colisões são raras e permite que múltiplas transações ocorram simultaneamente, verificando conflitos apenas no momento da confirmação.

Benefícios do Lock Otimista

Melhor Desempenho: Reduz a quantidade de bloqueios, permitindo maior paralelismo.
Menos Deadlocks: Minimiza a chance de deadlocks, uma vez que os recursos não são bloqueados por longos períodos.
Maior Escalabilidade: Facilita a escalabilidade horizontal, essencial para sistemas distribuídos de grande porte.

Exemplo de Lock Otimista

Vamos adicionar a lógica de lock otimista em nosso sistema de pagamentos. A ideia é verificar e atualizar o estado do pagamento apenas se ele não foi modificado por outro processo.

defmodule Payments do
  alias PaymentSystem.Repo
  alias PaymentSystem.Payments.Payment

  def update_payment_with_lock(id, attrs) do
    Repo.transaction(fn ->
      payment = Repo.get!(Payment, id)

      updated_payment = Payment.changeset(payment, attrs)
      case Repo.update(updated_payment) do
        {:ok, _payment} -> :ok
        {:error, changeset} -> Repo.rollback(changeset)
      end
    end)
  end
end

Neste exemplo, usamos uma transação para garantir que o pagamento seja atualizado apenas se ele não tiver sido modificado por outro processo desde a última leitura.

Integração de FSM, Lock Otimista e Processamento Assíncrono

Combinar FSM, Lock Otimista e Processamento Assíncrono em Elixir pode levar a sistemas altamente eficientes e robustos. A FSM controla o fluxo de estados, garantindo que as transições sejam ordenadas e previsíveis. O Lock Otimista permite que transações concorrentes sejam gerenciadas eficientemente, enquanto o Processamento Assíncrono garante que operações de longa duração não bloqueiem o sistema.

Exemplo Completo

Vamos combinar os conceitos discutidos anteriormente em um exemplo completo:

defmodule PaymentFSM do
  use Fsmx.Fsm,
    transitions: %{
      "pending" => ["authorized", "denied", "failed"],
      "authorized" => [],
      "denied" => [],
      "failed" => []
    }

  def start_payment(payment) do
    process_event(payment, "start")
  end

  defp process_event(payment, event) do
    PaymentProcessor.process_event(event)
  end

  defp handle_event(payment, event) do
    case transition(payment, event) do
      {:ok, new_payment} ->
        IO.puts("Evento processado com sucesso: #{inspect(new_payment)}")
      {:error, reason} ->
        IO.puts("Erro ao processar evento: #{inspect(reason)}")
    end
  end

  defp transition(payment, "start") do
    Fsmx.transition(payment, "authorized")
  end
end

defmodule PaymentProcessor do
  alias PaymentSystem.{Payments, PaymentFSM}

  def process_payment_async(payment) do
    Task.start(fn -> process_payment(payment) end)
  end

  defp process_payment(payment) do
    with {:ok, payment} <- PaymentFSM.authorize_payment(payment),
         {:ok, payment} <- Payments.update_payment_with_lock(payment.id, %{status: "authorized"}) do
      IO.puts("Pagamento processado com sucesso: #{inspect(payment)}")
    else
      {:error, reason} ->
        PaymentFSM.fail_payment(payment)
        IO.puts("Falha ao processar pagamento: #{inspect(payment)}. Motivo: #{reason}")
    end
  end
end

Neste exemplo, a FSM gerencia o estado do pagamento, o Lock Otimista garante que as atualizações de estado ocorram de maneira concorrente segura, e o processamento de eventos é feito de forma assíncrona, garantindo que o sistema permaneça responsivo e eficiente.

Conclusão

O uso de Máquinas de Estado Finito (FSM) e processamento assíncrono interno pode trazer inúmeros benefícios para programas em Elixir, desde melhor organização e controle de fluxo até maior resiliência e escalabilidade. Ao combinar esses padrões, é possível criar sistemas robustos, capazes de lidar com complexidade e alta carga de forma eficaz.

Parse, Don’t Validate: Embracing Data Integrity in Elixir

Zoey de Souza Pessanha — Wed, 19 Jun 2024 13:30:00 +0000

Introduction

In the world of functional programming, ensuring data integrity is paramount. One effective way to achieve this is by adopting the principle of "Parse, Don’t Validate". This approach emphasizes the transformation of raw input data into structured, well-defined data early in the application flow, thereby enhancing reliability and maintainability. While this concept is not new, its application in Elixir—a functional and concurrent programming language—offers unique benefits and challenges. This article delves into the theory behind parsing over validation and how it aligns with Elixir's paradigms.

Theoretical Foundations

Parsing vs. Validation

Validation involves checking if data meets certain criteria, often at multiple points in an application. This can lead to redundancy and inconsistencies, as the same checks are repeated, and errors may not be handled uniformly.

Parsing, on the other hand, transforms data into a structured format that inherently satisfies the required criteria. This approach ensures that once data is parsed successfully, it is guaranteed to be valid throughout the application, eliminating the need for repeated checks.

Why Parsing over Validation?

Early Error Detection: Parsing catches errors at the boundaries of your system, preventing invalid data from entering the core logic.
Simplified Code: By transforming data into a well-defined structure upfront, the core application logic becomes simpler and more focused on business requirements rather than data validation.
Enhanced Maintainability: Centralizing data integrity checks in parsing functions makes the system easier to understand and maintain.

Functional Programming and Parsing

In functional programming, functions are first-class citizens, and immutability is a core principle. Parsing fits naturally into this paradigm as it allows data to be transformed in a pure, deterministic manner. Once data is parsed into a well-defined structure, it remains immutable, ensuring consistency and reliability.

Concurrency and Data Integrity in Elixir

Elixir, built on the Erlang VM, excels in building concurrent, distributed systems. In such environments, data integrity is crucial, as concurrent processes need to operate on reliable data. By parsing data at the boundaries, Elixir applications can ensure that all processes work with valid, consistent data, thereby reducing the risk of concurrency-related bugs.

Applying the "Parse, Don’t Validate" Principle in Elixir

Conceptual Approach

Define Data Structures: Use Elixir structs or maps to define the shape of your data.
Parse Input Data: Transform raw input data into these well-defined structures at the earliest possible point in your application.
Centralize Parsing Logic: Encapsulate parsing logic in dedicated modules or functions to ensure uniformity and reuse.
Leverage Pattern Matching: Utilize Elixir’s powerful pattern matching to simplify the parsing process and handle different data shapes effectively.

Example Scenario

Consider an API endpoint that accepts user registration data. Instead of validating fields individually, parse the entire payload into a User struct.

Defining the Data Structure

defmodule User do
  defstruct [:name, :email, :age, :address]
end

Parsing the Input Data

defmodule UserParser do
  def parse(params) do
    with {:ok, name} <- validate_name(params["name"]),
         {:ok, email} <- validate_email(params["email"]),
         {:ok, age} <- validate_age(params["age"]),
         {:ok, address} <- validate_address(params["address"]) do
      {:ok, %User{name: name, email: email, age: age, address: address}}
    else
      {:error, reason} -> {:error, reason}
    end
  end

  defp validate_name(name) when is_binary(name) and byte_size(name) > 0, do: {:ok, name}
  defp validate_name(_), do: {:error, "Invalid name"}

  defp validate_email(email) when is_binary(email) and String.contains?(email, "@"), do: {:ok, email}
  defp validate_email(_), do: {:error, "Invalid email"}

  defp validate_age(age) when is_integer(age) and age > 0, do: {:ok, age}
  defp validate_age(_), do: {:error, "Invalid age"}

  defp validate_address(address) when is_map(address), do: {:ok, address}
  defp validate_address(_), do: {:error, "Invalid address"}
end

Using the Parser in Your Application

defmodule UserController do
  alias MyApp.UserParser

  def register_user(conn, params) do
    case UserParser.parse(params) do
      {:ok, user} ->
        # Proceed with business logic using the parsed user
        json(conn, %{status: "success", user: user})

      {:error, reason} ->
        # Handle parsing errors
        json(conn, %{status: "error", reason: reason})
    end
  end
end

Parsing with Peri

While the above example demonstrates a manual approach to parsing, the Peri library offers a more structured way to define and enforce schemas in Elixir.

Defining a Schema with Peri

defmodule MySchemas do
  import Peri

  defschema :user, %{
    name: :string,
    email: {:required, :string},
    age: :integer,
    address: %{
      street: :string,
      city: :string
    },
    role: {:required, {:enum, [:admin, :user]}}
  }
end

Parsing Data with Peri

defmodule UserController do
  alias MyApp.MySchemas

  def register_user(conn, params) do
    case MySchemas.user(params) do
      {:ok, user} ->
        # Proceed with business logic using the parsed user
        json(conn, %{status: "success", user: user})

      {:error, errors} ->
        # Handle parsing errors
        json(conn, %{status: "error", errors: errors})
    end
  end
end

Conclusion

Adopting the "Parse, Don’t Validate" principle in Elixir ensures data integrity, simplifies code, and enhances maintainability. By transforming raw input data into structured, well-defined data at the system's boundaries, you create a robust foundation for your application.

Elixir's functional and concurrent nature makes it an ideal language for embracing this approach. While manual parsing is effective, libraries like Peri offer powerful tools to define and enforce schemas, ensuring consistency and reliability throughout your application.

Embrace the power of parsing in Elixir, and let your code benefit from cleaner, more maintainable, and type-safe data handling.

Parsing and Validating Data in Elixir

Zoey de Souza Pessanha — Tue, 18 Jun 2024 22:40:53 +0000

In the enchanting world of Elixir programming, data validation is a quest every developer embarks on. It's a journey through the land of schemas, types, and constraints, ensuring data integrity and correctness. Today, we'll explore four powerful artifacts: Ecto, Norm, Drops, and Peri. Each of these tools offers unique powers for taming your data. We'll delve into their strengths, use cases, and compare them to help you choose the right one for your quest.

The Quest: Parse, Don't Validate

Before we embark on our journey, let's discuss a guiding principle in functional programming: Parse, Don't Validate. This pattern emphasizes transforming data into a well-defined structure as early as possible. By doing so, you avoid scattered, ad-hoc validation throughout your codebase, leading to clearer, more maintainable code. It's like casting a spell to organize the chaos of raw data into a neat, structured form.

The Artifacts

1. Ecto

Ecto is a robust toolkit primarily designed for interacting with databases. However, it also offers powerful capabilities for embedded schemas and schemaless changesets, making it versatile for data validation.

Embedded Schemas

Ecto allows defining schemas that don't map to a database table, ideal for validating nested data structures.

defmodule User do
  use Ecto.Schema

  embedded_schema do
    field :name, :string
    field :email, :string
  end
end

def changeset(data) do
  %User{}
  |> Ecto.Changeset.cast(data, [:name, :email])
  |> Ecto.Changeset.validate_required([:name, :email])
end

Schemaless Changesets

For dynamic data, Ecto provides schemaless changesets, offering flexibility at the cost of increased complexity.

def changeset(data) do
  Ecto.Changeset.cast({%{}, %{name: :string, email: :string}}, data, [:name, :email])
  |> Ecto.Changeset.validate_required([:name, :email])
end

2. Norm

Norm focuses on defining and conforming to data structures with custom predicates, offering a clean syntax and powerful validation.

defmodule User do
  import Norm

  defschema do
    schema(%{
      name: spec(is_binary()),
      age: spec(is_integer() and &(&1 > 18))
    })
  end
end

Norm.conform(%{name: "Jane", age: 25}, User.schema())
# => {:ok, %{name: "Jane", age: 25}}

3. Drops

Drops is a newer library that provides a rich set of tools for defining and validating schemas, leveraging Elixir's type system.

defmodule UserContract do
  use Drops.Contract

  schema do
    %{
      required(:name) => string(:filled?),
      required(:age) => integer(gt?: 18)
    }
  end
end

UserContract.conform(%{name: "Jane", age: 21})
# => {:ok, %{name: "Jane", age: 21}}

4. Peri

Peri is inspired by Clojure's Plumatic Schema, focusing on validating raw maps with nested schemas and optional fields. It's designed to be powerful yet simple, embracing the "Parse, Don't Validate" pattern.

defmodule MySchemas do
  import Peri

  defschema :user, %{
    name: :string,
    age: :integer,
    email: {:required, :string},
    role: {:enum, [:admin, :user]}
  }

  defschema :profile, %{
    user: {:custom, &MySchemas.user/1},
    bio: :string
  }
end

MySchemas.user(%{name: "John", age: 30, email: "john@example.com", role: :admin})
# => {:ok, %{name: "John", age: 30, email: "john@example.com", role: :admin}}

MySchemas.user(%{name: "John", age: "thirty", email: "john@example.com"})
# => {:error, [%Peri.Error{path: [:age], message: "expected integer received \"thirty\""}]}

Conditional and Composable Types in Peri

Peri shines with its support for conditional and composable types, making it a powerful tool for complex validation scenarios.

defmodule AdvancedSchemas do
  import Peri

  defschema :user, %{
    name: :string,
    age: {:cond, &(&1 >= 18), :integer, :nil},
    email: {:either, {:string, :nil}},
    preferences: {:list, {:oneof, [:string, :atom]}}
  }
end

AdvancedSchemas.user(%{name: "Alice", age: 25, email: nil, preferences: ["coding", :reading]})
# => {:ok, %{name: "Alice", age: 25, email: nil, preferences: ["coding", :reading]}}

AdvancedSchemas.user(%{name: "Bob", age: 17})
# => {:ok, %{name: "Bob", age: 17, email: nil, preferences: nil}}

Conclusion

Each of these tools offers unique advantages and caters to different needs:

Ecto is great for data associated with databases but can handle schemaless and embedded data structures too.
Norm provides a clean and powerful way to define and validate data structures.
Drops leverages Elixir's type system and offers rich schema definitions and validations.
Peri emphasizes simplicity and power, supporting complex types and conditional validations.

By understanding the strengths and weaknesses of each, you can choose the right tool for your data validation needs in Elixir. Happy coding, fellow sorcerers of Elixiria!

References

Feel free to dive into the source code and contribute to these projects to make Elixiria an even more magical place!

Introdução a programação funcional com War game

Zoey de Souza Pessanha — Sun, 30 Apr 2023 03:04:00 +0000

Durante um freela, o cliente pediu para que fosse implementado o jogo War em três linguagens de programação:

Elixir
Rust
Clojure

Essas são minhas linguagens favoritas, não necessariamente pela sintaxe mas pelo modelo diferente de se programar, pois todas pertencem ao paradigma funcional, mesmo que parcialmente como no caso de Rust, mas também possuem suas peculiaridades.

Durante essa série de artigos, será explicado minuciosamente as decisões de implementação, sempre tentando usar o máximo de cada linguagem de programação.

Porém antes, nos artigos iniciais, gostaria de introduzir as linguagens de programação utilizadas e o paradigma funcional, além de descrever como funciona o jogo de cartas War.

Boas vindas ao Paradigma Funcional

Muitas pessoas se assustam quando o tópico é programação funcional (FP). De fato, tanto no mercado quanto no ensino superior, o paradigma padrão a ser usado é o imperativo/estrutural em conjunto com o Orientado a Objetos (OO), mas o que essa sopa de palavras quer dizer, na prática?

Senta que lá vem história...

Vocês já devem ter ouvido que Alan Turing, pai da computação moderna, descreveu um modelo computacional no qual todos (bem, quase todos...) os sistemas computacionais se baseiam até hoje, certo? Esse modelo foi descrito conforme a Máquina de Turing. Mas como ela funciona?

Máquina de Turing

A Máquina de Turing é um modelo matemático descrito na tese de Church-Turing.

Falaremos sobre Alonzo Church logo a seguir!

Esse modelo matemático tem a capacidade de descrever qualquer algoritmo, apesar de ser um modelo relativamente simples.

Para entendê-la, imagine uma fita horizontal, de tamanho variável, separada por células que possuem uma marcação, que se chama "alfabeto" da máquina. Nesse exemplo vamos usar 0 e 1.

Em conjunto existe uma máquina, imagine uma caixa, onde possui uma agulha, que é a "cabeça" da máquina, permitindo ler e modificar a marcação da célula atual. A mesma consegue se movimentar por essa fita e realizar comandos por ela, como:

mova para a esquerda;
mova para a direita;
deixe o valor da célula como está;
modifique a célula;
apague a marcação desta célula;

A célula onde a caixa está seria seu estado atual e o propósito da máquina é chegar no "estado de espera", que representaria o final do algoritmo. Portanto, os valores das marcações nas células após a execução dos comandos direcionados à caixa representa a solução da computação/algoritmo.

Cálculo Lambda

Lembra do Alonzo Church citado anteriormente? O mesmo foi orientador do Turing e também tinha proposto um modelo matemático para computações, diferente da máquina de Turing.

Hoje em dia entendemos que os dois modelos são equivalentes. Logo, toda computação realizada por uma Máquina de Turing pode ser computada pelo Cálculo Lambda e vice-versa!

O modelo consiste na definição de termos e na redução dos mesmos. Na sua versão mais simples, descrita na década de 30, os termos são construídos seguindo as seguintes regras:

variável, que representa um parâmetro ou um valor lógico/matemático;
abstração, que representa a definição de uma função, como: λx. M, onde M é um outro termo qualquer e x um parâmetro;
aplicação de uma função, como M N, que aplica a função M (um termo) sobre outro termo N.

Esse modelo matemático é a base do paradigma funcional! A seguir, vamos implementar lógica booleana usando apenas as regras citadas acima:

true = λx.λ.y x
false = λx.λy y

not = λx.x false true
and = λx.λy.x y false
or = λx.λy.x true y

Para ficar mais entendível, vamos usar uma linguagem de programação de alto nível (JavaScript):

const TRUE = x => y => x
const FALSE = x => y => y

Se utilizando das funções lambda (arrow functions), que possuem esse nome de forma proposital, criamos duas funções que representam os valores lógicos "verdadeiro", que retorna o primeiro termo recebido, e "falso" , que retorna o segundo termo passado como parâmetro.

Vamos agora criar as operações de negação (not), conjunção (and) e disjunção inclusiva (or):

const NOT = termo => termo(FALSE)(TRUE)

// NOT(TRUE) - [Function: FALSE]
// NOT(FALSE) - [Function: TRUE]

A negação é a definição de uma função lambda onde recebe um termo, e aplica esse termo aos termos FALSE e TRUE, respectivamente.

Como TRUE retorna o primeiro termo recebido, caso o termo passado para NOT seja TRUE, o termo a ser resolvido é FALSE, e contrário acontece caso o parâmetro de NOT seja FALSE!

Agora, vamos para a conjunção lógica (and):

const AND = termo => outro_termo => termo(outro_termo)(FALSE)

// AND(TRUE)(TRUE) - [Function: TRUE)
// AND(TRUE)(FALSE) - [Function: FALSE)
// AND(FALSE)(TRUE) - [Function: FALSE)
// AND(FALSE)(FALSE) - [Function: FALSE)

Se utilizando do que chamamos de "avaliação de curto-circuito", o termo AND recebe dois termos e aplica o primeiro sobre o segundo e o termo FALSE.

Por fim, vamos implementar a disjunção lógica (or), que é bem semelhante:

const OR = termo => outro_termo => termo(TRUE)(outro_termo)

// OR(TRUE)(TRUE) - [Function: TRUE)
// OR(TRUE)(FALSE) - [Function: TRUE)
// OR(FALSE)(TRUE) - [Function: TRUE)
// OR(FALSE)(FALSE) - [Function: FALSE)

Com essa definições, podemos expandir ainda mais e definir a operação de controle de fluxo if:

const IF_THEN_ELSE = predicado => then => else_branch => predicado(then)(else_branch)

// IF_THEN_ELSE(TRUE)(1)(2) - 1
// IF_THEN_ELSE(FALSE)(1)(2) - 2

// IF_THEN_ELSE(NOT(TRUE))(1)(2) - 2
// IF_THEN_ELSE(NOT(FALSE))(1)(2) - 1

// IF_THEN_ELSE(AND(TRUE)(TRUE))(1)(2) - 1
// IF_THEN_ELSE(AND(TRUE)(FALSE))(1)(2) - 2
// IF_THEN_ELSE(AND(FALSE)(TRUE))(1)(2) - 2
// IF_THEN_ELSE(AND(FALSE)(FALSE))(1)(2) - 2

// IF_THEN_ELSE(OR(TRUE)(TRUE))(1)(2) - 1
// IF_THEN_ELSE(OR(TRUE)(FALSE))(1)(2) - 1
// IF_THEN_ELSE(OR(FALSE)(TRUE))(1)(2) - 1
// IF_THEN_ELSE(OR(FALSE)(FALSE))(1)(2) - 2

A operação IF recebe um primeiro termo que chamamos de "predicado", que será avaliado em TRUE ou FALSE. Caso o termo avaliado seja TRUE, o termo then é retornado, caso contrário o termo else_branch é devolvida.

O que acabamos de implementar é equivalente à:

const predicado = true;
const then = 1;
const else_branch = 2;

if (predicado) {
  return then;
} else {
  return else_branch;
}

O que torna um linguagem "funcional"?

Para uma linguagem de programação ser considerada funcional, ela precisa atender alguns requisitos. É importante notar, que mesmo que uma linguagem não pertença ao paradigma funcional, a mesma pode implementar funcionalidades funcionais, como Python e JavaScript, que pertencem ao paradigma Orientado a Objetos porém possuem características do paradigma funcional!

Vamos entender esses requisitos!

Imutabildiade

O conceito mais básico de uma linguagem funcional é ter seus valores imutáveis. Isso significa que não é possível modificar o valor de termo em memória, apenas criar novos valores a partir dele. Alguns exemplos usando TypeSript e Elixir:

type User = {
  id: string,
  name: string
};

const user: User = Object.freeze({id: "123", name: "Joe"});

user.id = "431"; // válido
user.name = null; // válido
user.x = true; // inválido

Uma das maneiras mais primitivas de exigir imutabilidade dentro do universo JS/TS é usando Object.freeze. Essa função força um objeto a ter um certo formato, porém permite que os valores de uma chave válida seja modificada em memória, o que não queremos!

type User = ReadOnly<{id: string, name: string}>;

const user: User = {id: "um-id", name: "Dantas";

user.id = null // erro de compilação
user.x = true // erro de compilação

E caso quisermos atualizar nosso user?

function updateUser(user: User, params: Partial<User>): User {
  return Object.assign({}, user, params);
}

const newUser = updateUser(user, {id: "outro-id"})

console.log(newUser.name == user.name) // true
console.log(newUser.id == user.id) // false

newUser.id = "123" // erro de compilação

Agora sim temos imutabilidade! Mas me parece um tanto quanto verboso 🤔. Vamos ver o mesmo exemplo em Elixir:

defmodule User do
  @enforce_keys [:id, :name]
  defstruct [:id, :name]

  def update_user(user, params) do
    Map.merge(user, params)
  end
end

user = %User{id: "123", name: "Joe"}

user.id = "4321" # erro de compilação

new_user = User.update_user(user, %{id: "4321", name: "Dantas"})

new_user == user // false
user.id == "123" // true

Neste exemplo foi criado um Struct para forçar um formato, porém a mesma lógica se aplica a hashmaps planos! Todo termo em Elixir é imutável, ou seja, sempre que precisar atualizar um termo, um novo será gerado. As expressões na linguagem já foram implementadas para retornar novos termos, sendo muito menos verboso!

Funções como valores de primeira classe

Outra característica básica de uma linguagem de programação funcional é que as funções são valores da mesma ordem dos tipos primitivos como integer ou string. Isso significa que funções podem ser passadas como parâmetro de outra função ou serem retornadas de outra função. Vamos acompanhar alguns exemplos:

const inc = x => x + 1;

const numbers = [1, 2, 3, 4, 5];

numbers.map(inc); // [2, 3, 4, 5, 6]

Passamos a função inc, que incrementa o valor de um termo, como parâmetro da função map, que itera sobre um array de termos e aplica a função recebida em cada termo, retornando um novo valor modificado. Vamos ver uma função retornando outra:

function soma_parcial(x) {
  return y => x + y;
}

const soma5 = soma_parcial(5);

soma5(10) // 15;

Neste exemplo criamos uma função soma _parcial, que recebe um número e devolve uma outra função, que também recebe um número, onde a avaliação dessa ultima retorna a soma dos dois números.

Chamamos essa técnica de closure, quando uma função interna utiliza o contexto do nível acima dentro do próprio escopo. O termo x, criado pelo contexto da função soma_parcial fica guardado na memória até a segunda função que é retornada, usá-lo.

Portanto, quando criamos o termo soma5, fazemos o que é chamado de "aplicação parcial", pois podemos entender que a função soma_parcial recebe dois parâmetros, porém apenas passamos o primeiro! Neste caso x terá o valor de 5.

Como o retorno da aplicação parcial é uma outra função, soma5 pode receber outro termo, que no exemplo passamos 10, no que resulta na avaliação de x = 5 + y = 10, sendo retornado 15.

Funções puras e Transparência Referencial

Uma função pura é uma função que dado o mesmo termo como parâmetro, o mesmo resultado será retornado. Para ser pura, a função também não pode modificar o contexto externo dela. Vamos ver alguns exemplos:

let x = 10;

function somaX(y) {
  return x + y;
}

Essa função é impura, pois a mesma modifica/utiliza o contexto externo a si mesma!

Um exemplo claro de função pura são as operações matemáticas, como soma, multiplicação, subtração e divisão. Todas elas recebem dois parâmetros e aplica a operação sobre os dois. Dado os mesmos parâmetros, o mesmo termo será retornado:

const soma = (x, y) => x + y;

soma(1, 2) // 3
soma(1, 2) // 3
// ... assim infinitamente

Com isso, conseguimos introduzir outro conceito: Transparência Referencial, acontece quando podemos substituir a chamada de uma função pelo seu retorno, uma vez que dado o mesmo parâmetro, será retornado o mesmo resultado. Uma função só pode sofrer transparência referencial quando a mesma for pura!

Recursão

Como linguagens de programação funcionais são imutáveis, iterar sobre uma coleção de termos usando loops perde seu significado. Por isso, o mais comum quando precisamos iterar sob uma coleção é usarmos recursão, que é o ato de uma função chamar a si mesma, criando uma pilha de execução! Vamos ver a diferença entre loops e recursão:

function fatorial(number) {
  let fact = 1;

  if (number == 0) return 1;

  for (let i = 1; i <= number; i++) {
    fact *= i;
  }

  return fact;
}

Com um for loop, criamos uma variável de estado fact que é modificada a cada iteração do loop com um novo valor do fatorial calculado. Vamos ver como seria a implementação com recursão:

function factorial(number) {
  if (number < 2) return 1;

  return number * factorial(number - 1);
}

Apesar de ter menos código, a lógica por trás da recursão pode ser um tanto quanto mais complexa. Toda recursão precisa de uma "condição de parada", que é uma condição base para que a recursão seja finalizada. No caso do cálculo do fatorial, o caso base é quando o número for menor que 2, onde será retornado o valor 1.

Depois, temos a definição da recursão, onde o resultado é o termo number multiplicado pelo resultado da chamada factorial(number - 1). Veja na imagem a seguir a sequência de avaliação da recursão:

Conforme a imagem, é possível notar que é criada uma pilha de avaliação, onde a cada resultado a pilha diminui, fazendo o caminho "inverso" da avaliação.

Conclusão

Neste artigo entendemos a história da programação funcional e as características que fazem com que uma linguagem de programação possa ser considerada "funcional".

Vimos que a base da programação funcional é a definição e aplicação de funções, num modelo matemático, podendo ser funções puras ou não.

No próximo artigo, as linguagens Elixir, Rust e Clojure serão introduzidas, seguida pela introdução ao jogo de cartas War!

Referências

Identificação de caracteres Unicode em Elixir

Zoey de Souza Pessanha — Thu, 30 Sep 2021 07:15:12 +0000

AVISO INICIAL
Este artigo é uma tradução (não direta e com adaptações) de um artigo publicado no blog do exercism.io pelo Percy Grunwald. O artigo original pode ser encontrado por esse link.

Uma das maiores vantagens de usar uma linguagem expressiva como Elixir é a possibilidade de solucionar problemas de forma clara, explícita e com um toque de elegância devido a sua sintaxe!

Hoje vou mostrar como podemos identificar ou "casar" (it's a match!) caracteres pertencentes ao padrão Unicode. Para quem não conhece ou não sabe em detalhes, Unicode é uma solução criada para evitar o conflito entre diferentes codificadores de caracteres.
Isto é, cada um dos codificadores de caracteres implementava números diferentes para representar cada símbolo de uma ou mais línguas.

Porém, nenhum deles realmente conseguia abranger as extensas possibilidades de combinações, letras, símbolos e pontuações que centenas de línguas possuem. Por isso nasce o Unicode ou, código único (unique code), onde cada caractere recebe um identificador único, não sendo restingido por nenhuma plataforma, programa ou linguagem!

Ok, mas vamos falar de Elixir agora! Já de ínicio vou propor um desafio:

"Implemente uma função frequencia/1 que dada uma lista de strings devolva a frequência de cada caractere. Lembre que as strings podem estar descritas em qualquer linguagem!"

Exemplo:

iex> Frequencia.frequencia(["ciências", "naturais"])
%{
  "a" => 3,
  "i" => 3,
  "ê" => 1,
  "c" => 2,
  "n" => 2,
  "r" => 1,
  "s" => 2,
  "t" => 1,
  "u" => 1
}

Aqui estão alguns casos de teste:

["Eorum" "argumentum" "audiri" "posse" "per" "raedam" "multum"]
["When" "transplanting" "seedlings" "candied" "teapots" "will" "make" "the" "task" "easier"]
["El" "zorro" "del" "sombrero" "de" "copa" "le" "susurró" "al" "oído" "del" "conejo"]
["Estava" "escurecendo" "e" "ainda" "não" "estávamos" "lá"]
["E" "ʻike" "ʻoe" "i" "ke" "alahaka" "ānuenue" "ma" "hope" "o" "ka" "ua" "ʻana" "o" "nā" "pōpoki" "a" "me" "nā" "ʻīlio"]
["Σήμερα" "είναι" "η" "μέρα" "που" "θα" "ξέρω" "επιτέλους" "τι" "γεύση" "έχει" "το" "τούβλο"]

Vai lá, tenta implementar! Precisa de tempo? Tudo bem, eu espero...

Identificação de letras em Elixir

5 minutos depois... 10 anos depois... Podemos fazer em conjunto! Vamos tentar com testes mais simples!

Partindo do básico, como podemos determinar que "z" é uma letra?

Obs: Existe uma funcionalidade na linguagem Elixir que torna a resolução desse exercício algo, digamos... único e intrigante! Nada prático, mas interessante! Deixarei uma demonstração no final deste artigo!

O caminho mais "comum" seria escolher o uso de expressões regulares. Uma dica: o site regexr.com será seu guia para entender cada modificador e sintaxes específicas.

iex> String.match?("z", ~r|[a-z]|)
true

Realmente bem simples, mas e a letra "Z"?

Ah, fácil também:

iex> String.match?("Z", ~r|[A-Za-z]|)
true

iex> String.match?("Z", ~r|[a-z]|i)
true

No segundo exemplo, é adicionado o nosso primeiro modificador: i modificador caseless que permite a não diferenciação entre letras maiúsculas ou minúsculas.

Tudo bem, por enquanto está bem simples, que tal testarmos com um caractere com acento, como "ê". Bem, esse caractere também é uma letra, então...

iex> String.match?("ê", ~r|[a-z]|i)
false

Opa, estranho, mas esperado, uma vez que "ê" é um caractere especial. Uma solução poderia ser usar uma expressão regular que falhe caso encontre um caractere especial. Algo como (de forma simplificada):

iex> String.match? "É", ~r|[a-z0-9]|i
false

É uma solução válida, mas muito frágil. Como poderíamos cobrir todos os casos possíveis? Fora que seria necessário testar se cada caractere é especial ou não, identificá-lo manualmente e contabilizar sua frequência. Definitivamente tá longe de ser o caminho feliz e muito menos elegante.

Expressões regulares com suporte a Unicode

Existe um modificador para expressões regulares que inclui e permite a identificação de caracteres Unicode numa expressão regular. Esse modificador é o u

unicode (u) - habilita a identificação de padrões Unicode específicos como \p e modifica os já conhecidos operadores \w, \W e \s e similares para que possam detectar caracteres Unicode.

De fato o modificador u e em especial o operador \p, torna nossa solução bem elegante. O operador \p permite a identificação de um grafema.

Grafema é a unidade fundamental de um sistema de escrita que pode representar um fonema em escritas alfabéticas, uma ideia numa escrita ou até uma sílaba nas escritas silábicas. Pode ser entendido como um conjunto de caracteres.

Com este operador é possível detectar um grafema dentro de qualquer categoria de caracteres Unicode. Não incluindo apenas as subcategorias Ll (letra, caixa baixa) ou Sc (símbolo, moeda), mas também as categorias mães L (letra) e S (símbolo).

Em outras palavras, você consegue identificar qualquer caractere, em qualquer tipografia em qualquer língua humana suportada pelo Unicode com o padrão \p{L}!

Vamos aos testes então!

Letras latinas comuns do português são facilmente detectadas:

iex> String.match?("o", ~r|\p{L}|u)
true

iex> String.match?("O", ~r|\p{L}|u)
true

Caracteres latinos com acentos agudos ou trema também não causam nenhum problema:

iex> String.match?("ü", ~r|\p{L}|u)
true

iex> String.match?("í", ~r|\p{L}|u)
true

Mas então esse padrão não acusaria verdadeiro para qualquer caractere? Veja a seguir:

iex> String.match?("$", ~r|\p{L}|u)
false

iex> String.match?("&", ~r|\p{L}|u)
false

Entendido. Esses grafemas parecem letras, mas não são! Mas e quanto ao nosso problema com internacionalizações? Bem...

# Grafema que representa "casa" ou "construção" em japônes
iex> String.match?("舎", ~r|\p{L}|u)
true

# Grafema que significa "eu" em cingalês
iex> String.match?("මට", ~r|\p{L}|u)
true

Aplicando a identificação de caracteres Unicode ao nosso desafio

Agora temos todas as ferramentas necessárias para nos ajudar a decidir se um determinado grafema é ou não uma letra. A seguir, temos uma implementação inicial:

defmodule Frequencia do
  def frequencia(sentencas) when is_list(sentencas) do
    sentencas
    |> separar_grafemas()
    |> contar_letras()
  end

  defp separar_grafemas(sentencas) do
    sentencas
    |> Enum.join()
    |> String.graphemes() # sim, esta função é nativa :P
  end
end

A função principal é a contar_letras/1, que aplicará a expressão regular ~r|\p{L}|u em cada grafema, decidindo se é ou não uma letra! Aqui está uma implementação de exemplo:

defmodule Frequencia do
  defp contar_letras(grafemas) do
    for grafema <- grafemas, letra?(grafema), reduce: %{} do
      acc -> Map.update(acc, grafema, 1, & &1 + 1)
    end
  end

  defp letra?(grafema), do: String.match?(grafema, ~r|\p{L}|u)
end

Nossa função aceita uma lista de grafemas e por meio de compreensões de lista, iteramos sobre cada elemento da lista, apenas mantendo os elementos que passarem no teste (a chamada da função auxiliar letra?/1) e reduzimos a lista em um mapa, onde cada chave é uma letra e seu valor é a frequência em que tal caractere aparece!

Bônus: Sequências!

No começo deste artigo eu mencionei que Elixir possibilita uma forma bem mais "diferentona" de se resolver esse problema. Isso se deve ao fato de que a própria linguagem em si, suporta caracteres Unicode.

Uma das funcionalidades mais interessantes da linguagem são as sequências! Dado um valor inicial, um valor final e um "passo", é gerado um conjunto que representa aquela sequência (de forma inclusiva).

Exemplos!

iex> Enum.to_list(1..10)
[1, 2, 3, 4, 5]

iex> Enum.to_list(1..5//-1)
[5, 4, 3, 2, 1]

Mas isso é muito comum, vamos incrementar essa funcionaldiade! Que tal criarmos sequências para letras? A expressão ? antes dos caracteres permite que recupermos seus códigos em decimal:

iex> Enum.to_list(?a..?c)
'abc'

iex> Enum.to_list(?c..?a)
'cba'

Uhumm... Mas onde quero chegar com isso? Lembra que Elixir suporta nativamente caracteres Unicode (infelizmente não para criação de variáveis haha)? Vamos usar isso então:

iex> ?é
233

iex> ?ﬦ
64294

iex> ?😅
128517

Possível solução para o problema

Com um algumas composições de funções, podemos solucionar nosso problema, não de uma maneira eficiente, não de uma maneira totalmente legível, mas certamente com toda a elegância possível!

defmodule Frequencia do
  # [...]

  defp contar_letras(grafemas) do
    Enum.reduce(grafemas, %{}, fn grafema, acc ->
      codigo = 
        grafema 
        |> String.to_charlist() # charlists são literalmente listas de caracteres
        |> hd() # logo, precisamos apenas do cabeçalho da mesma, ou seja, um "codepoint"

      cond do
        caixa_alta?(codigo) -> Map.update(acc, grafema, 1, & &1 + 1)
        caixa_baixa?(codigo) -> Map.update(acc, grafema, 1, & &1 + 1)
        latin_A_e_B?(codigo) -> Map.update(acc, grafema, 1, & &1 + 1)
        true -> acc
      end
    end)
  end

  defp caixa_alta?(ch), do: ch in ?A..?Z # 65..90
  defp caixa_baixa?(ch), do: ch in ?a..?z # 97..122
  defp latin_A_e_B?(ch), do: ch in ?À..?ɏ # 192..591
end

Conclusão

Descobrimos duas maneiras incríveis de detectar grafemas de múltiplas nacionalidades! Ok, talvez uma delas seja um tanto quanto.. exótica eu diria, mas ainda sim divertida de se implementar!

Essas funcuionalidades permitam que um leque de outras funcionalidades ou problemas sejam contruídos e solucionados com uma expressividade clara, sucinta e simples.

Vale lembrar que no exemplo usando sequências eu limitei os códigos Unicode levando emconta apenas os caracteres latinos básicos e as extensões A e B, além do suplemento 1 latino para fins de exemplificação, mas qualquer caractere Unicode é válido em Elixir!

Ambiente de desevolvimento Elixir/Phoenix com Nix

Zoey de Souza Pessanha — Thu, 06 May 2021 03:30:38 +0000

Nos artigos anteriores, escrevi uma breve introdução ao Nix, apresentei algumas vantagens e exemplos,
e a especificação da sintaxe da linaguagem além de apresentar alguns contras e limitações dessa ferramenta!

Neste artigo irei mostrar um exemplo de configuração para um ambiente de desenvolvimento de projetos na linguagem
Elixir com o mix e também suporte ao framework Phoenix

Requisitos

Os únicos requisitos para seguir este tutorial é ter um conhecimento brévio sobre o ecossistema Elixir e
possuir o gerenciador de pacotes Nix instalado no seu sistema.

Caso esteja usando a distribuição NixOS, o gerenciador de pacotes já estará disponível.

Projeto base criado com o mix

O mix é a ferramenta de contrução utilizada no ecossistema Elixir para compilar seu projeto,
realizar tarefas mix, rodar os testes de sua apliação dentre outras funcionalidades.

Para torná-lo acessível num ambiente isolado, crie um arquivo shell.nix, com esse conteúdo:

{ pkgs ? import <nixpkgs> {} }:

with pkgs;

let
  elixirDrv = elixir.override {
    version = "1.11.4";
    rev = "308255bda81e7f76f9bec838cef033e8e869981b";
    sha256 = "1y8fbhli29agf84ja0fwz6gf22a46738b50nwy26yvcl2n2zl9d8";
    minimumOTPVersion = "23";
  };
in mkShell {
  name = "exemplo_dev";

  buildInputs = [ readline elixirDrv ]

  shellHook = ''
    mkdir -p .nix-mix
    mkdir -p .nix-hex
    export MIX_HOME=$PWD/.nix-mix
    export HEX_HOME=$PWD/.nix-hex
    export PATH=$MIX_HOME/bin:$PATH
    export PATH=$HEX_HOME/bin:$PATH
    export LANG=en_US.UTF-8
    export ERL_AFLAGS="-kernel shell_history enabled"
    export ERL_LIBS=$HEX_HOME/lib/erlang/lib
  '';
}

Com isso, execute nix-shell ou nix-shell <caminho/para/shell.nix> e você poderá
utilizar o mix!

Vamos desconstruir esse arquivo:

{ pkgs ? import <nixpkgs> {} }:

with pkgs;

No começo do arquivo importamos os pacotes a aprtir do repositório nixpkgs e trazemos todas as opções desse
módulo para o escopo léxico atual.

Já dentro do bloco let...in, sobrescrevo a versão do pacote da linguagem Elixir, que atualmente está na versão 1.10.4
no canal estável:

elixirDrv = elixir.override {
  version = "1.11.4";
  rev = "308255bda81e7f76f9bec838cef033e8e869981b";
  sha256 = "1y8fbhli29agf84ja0fwz6gf22a46738b50nwy26yvcl2n2zl9d8";
  minimumOTPVersion = "23";
};

Essa expressão pode ser usada para utilizar qualquer versão da linguagem. Existem versões anteriores já envelopadas
no reposiório nixpkgs como os pacotes elixir_1_9 e elixir_1_7.

Dentro da derivção especial mkShell, definimos um nome para esse ambiente e depois definimos a opção buildInputs,
que presenta quais são as dependências desse ambiente a ser criado:

buildInputs = [ readline elixirDrv ]

E por último declaramos um pequeno script que será executado antes do ambiente ser criado:

shellHook = ''
  mkdir -p .nix-mix
  mkdir -p .nix-hex
  export MIX_HOME=$PWD/.nix-mix
  export HEX_HOME=$PWD/.nix-hex
  export PATH=$MIX_HOME/bin:$PATH
  export PATH=$HEX_HOME/bin:$PATH
  export LANG=en_US.UTF-8
  export ERL_AFLAGS="-kernel shell_history enabled"
  export ERL_LIBS=$HEX_HOME/lib/erlang/lib
'';

Neste exemplo, criamos dois diretórios para abrigar as instalações locais
do mix e hex, tornamos disponmíveis os seus executáveis, e definimos duas
variáveis ambiente referentes à BEAM:

ERL_AFLAGS: o conteúdo dessa variáveis é adicionado no começo do comando erl
ERL_LIBS: necessária caso você já possua uma instalação local de elixir, suprimindo os avisos que a biblioteca padrão está sendo redefinida durante a compilação

Projetos Phoenix

Já para projetos Phoenix, devemos realizar algumas mudanças no arquivo shell.nix.

Phoenix + PostgreSQL

A primeira mudança é na opção buildInputs, onde adicionamos algumas dependência para compilação de
algumas dependências do projeto dentre outros utilitários:

buildInputs = [
  gnumake
  gcc
  readline
  openssl
  zlib
  libxml2
  curl
  libiconv
  # minha versão do pacote `elixir`
  elixirDrv
  glibcLocales
  nodejs-12_x
  yarn
  postgresql
  gtk-engine-murrine
] ++ lib.optional stdenv.isLinux [ 
      inotify-tools 
      # dependência do GTK para usar o observer
      gtk-engine-murrine 
    ]
  ++ lib.optionals stdenv.isDarwin (with darwin.apple_sdk.frameworks; [
      CoreFoundation
      CoreServices
    ]);

A segunda alteração é no script inicial do ambiente, onde definimos algumas váriaveis ambiente
para configuração do servidor do PostgreSQL e criamos um usuário padrão.

Para isso, adicione os seguintes comandos na opção shellHook:

export PGHOST=$PWD/.postgres
export PGDATA=$PGHOST/data
export PGLOG=$PGHOST/postgres.log
export PGPASSWORD=postgres

if [ ! -d $PGDATA ]; then
  echo 'Initializing postgresql database...'
  initdb --auth=trust --no-locale --encoding=UTF8 >/dev/null
fi

# inicializando o servidor
pg_ctl start -l $PGLOG -o "--unix_socket_directories='$PGHOST'"

# verifica se existe um usuário padrão, caso contrário ele é criado
psql -d postgres -tAc "SELECT 1 FROM pg_roles WHERE rolname='postgres'" | grep -q 1 \
  || createuser -s postgres

# assim que você sair do ambiente criado pelo `nix-shell`
# o servidor do postgres será desligado 
finish() {
  pg_ctl -D $PGDATA stop
}

trap finish EXIT

O código completo desta expressão Nix está disponível neste gist.

Phoenix + MariaDB/MySQL

Caso você esteja usando o MariaDB ou MySQL como SGBD, apenas altere a útilma parte do shellHook, removendo
as opções relacionadas ao PostgreSQL e adicionando essas linhas:

export MYSQL_BASEDIR=${pkgs.mariadb}
export MYSQL_HOME=$PWD/mysql
export MYSQL_DATADIR=$MYSQL_HOME/data
export MYSQL_UNIX_PORT=$MYSQL_HOME/mysql.sock
export MYSQL_PID_FILE=$MYSQL_HOME/mysql.pid

mysql_install_db --datadir=$MYSQL_DATADIR --basedir=$MYSQL_BASEDIR --pid-file=$MYSQL_PID_FILE
mysqld --datadir=$MYSQL_DATADIR --pid-file=$MYSQL_PID_FILE --socket=$MYSQL_UNIX_PORT &
export MYSQL_PID=$!

finish() {
  mysqladmin --socket=$MYSQL_UNIX_PORT shutdown
  kill $MYSQL_PID
  wait $MYSQL_PID
}
trap finish EXIT

Conclusão

Utilizando essas derivações, é possível configurar um ambiente de densenvolvimento totalmente reproduzível
e estável em poucos minutos!

Vale lembrar que esta derivação é plenamente editável e pode ser adaptada para outros tipo de ambientes,
por exemplo aplicações Rails, Django ou mesmo Express ou AdonisJS.

Este post foi publicado com minha ferramenta de linha de comando devit!
Você pode encontrar instruções para instalação neste link.

Sintaxe e especificação da linguagem Nix

Zoey de Souza Pessanha — Thu, 06 May 2021 03:28:49 +0000

Com o Nix devidamente apresentado no post anterior, agora irei introduzir a
sintaxe da linguagem!

Este artigo foi feito com a intenção de traduzir, resumidamente, a especificação oficial
da linguagem que pode ser encontrada no link no final do post.

Paradigmas da linguagem

"Preguiçosa"

Isso significa que as expressões somente são executadas caso realmente sejam necessárias.

Neste exemplo, a função abort nunca será executada:

let
  a = abort "nunca irá acontecer";
  b = "olá";
  c = "mundo";
in b + c

Funcional

Programação Funcional é um paradigma de linguagens de computação onde a estrutura e elementos de
um programa são tratados como expressões matemáticas, evitando a mutabilidade de estado. Linguagens
funcionais também tendem a fazer parte do paradigma declarativo, onde a construção do programa
é baseado em expressões.

Pura

Definimos uma função como pura quando o retorno dela é unicamente definido pelos seus argumentos
de entrada, ou seja, não há efeitos colaterais externos ou "observáveis".

Especificação da linguagem

Expressões

Quando um tutorial referencia uma expressão Nix, significa que ele está descrevendo a
definição de uma função com várias entradas. Porém, uma expressão Nix pode ser definida como
um simples texto, até uma função ou um conjunto de outras expressões!

Tipos primitivos

Texto

Pode ser definido com aspas duplas " ou duas aspas simples '' para mais de uma linha:

# também suportam interpolações
"Diga ${pkgs.hello.name}"

''primeira linha
  segunda linha
''

Números

Existem os tipos interios e ponto de fltuação que possuem precisão limitada:

5

1.18

Caminhos

Caminhos relativos serão convertidos em absolutos quando a expressão for executada:

./ola/mundo
# /caminho/asbsoluto/para/ola/mundo

<nixpkgs/lib>
# /caminho/para/nixpkgs/lib

URIs

URIs podem ser representadas independentemente, como:

let
  uri = https://github.com/Mdsp9070/dotfiles 
in fetchTarball { src = uri }

Booleanos

Também existem os booleanos true e false.

Nulidade

A nulidade é representada pela expressão null.

Funções

Todas as funções são anônimas com o formato: argumento: expressão-Nix, como: x: x * x.

Caso queira nomear a função, você pode declarar: quadrado = x: x * x. E para executar essa
função com argumento: quadrado 3;

Múltiplos argumentos podem ser exigidos no formato: arg1: arg2: expressão-Nix.

É comum que Conjuntos sejam passados como argumentos para funções, e é possível referenciar apenas
os argumentos necessários:

a_e_b = conjunto: conjunto.a + conjunto.b

a_e_b { a = "ola"; b = "mundo"; }

# pode ser reescrita dessa maneira:
a_e_b = {a, b}: a + b

Também é possível definir argumentos padrões:

soma = { a ? 1, b ? 2 }: a + b

soma {}
# 3

soma { a = 3; }
# 5

Caso um argumento não declarado no cabeçalho da função seja fornecido, ocorrerá um erro, porém
isso pode ser evitado caso use reticências ...:

soma = { a, b }: a + b
soma { a = 5; b = 2; c = 10; }
# error: anonymous function at (string):1:2 called with unexpected argument 'c', at (string):1:1

soma = { a, b, ... }: a + b
soma { a = 5; b = 2; c = 10; }
# 7

Você também pode referenciar todos os argumentos num Cojunto com a notação @:

soma = args@{ a, b, ... }: a + b + args.c
soma { a = 5; b = 2; c = 10; }
# 17

Listas

É um conjunto de diversos valores separados por espaços em branco, que podem ter vários tipos:

[ 123 ./exemplo.nix "abc" (f { x = y; }) ]

Define uma lista com quatro elementos. Note que a função f está dentro parênteses, caso contrário,
haveria cinco elementos na lista, sendo o quarto uma função f previamente declarada e o quinto um
conjunto.

Os valores de uma lista são "preguiçosos", mas seu tamanho não.

Conjuntos

Esta estrutura é o coração da linguagem, já que o foco principal é criar derivações, que são apenas conjuntos
de atributos que são passados para scripts construtores.

Conjuntos são estrutas de nome/valor definidos dentro de chaves:

{ x = 123;
  texto = "hello";
  y = f { tudo = 42; };
}

A ordem dos atributos não é importante e é uma boa prática não haver repetições nos nomes das chaves.

Cada atributo pode ser acessado com o operador .:

{ a = "Foo"; b = "Bar" }.a

Retorna "Foo". Também é possível definir um valor padrão caso um atributo não exista com a palavra-chave or:

{ a = "Foo"; b = "Bar" }.c or "xyz"

As chaves também podem ser definidas por textos entre aspas duplas ":

{ "exemplo de ${chave}" = "Foo"; }."exemplo de ${chave}"

Caso a chave de atributo tenha o valor nulo, o atributo não é executado:

{ ${if exemplo then "bar" else null} = true; }

Retorna {} caso exemplo seja falso.

Conjuntos podem ter chaves que referem-se umas às outras com o construtor rec:

rec {
  x = y;
  y = 123l
}.x

Operadores

# acesso
e . atributo

# chamada de função
e1 e2

# negação numérica
-e

# testa a existência de um atributo
e ? atributo

# concatenação de listas
e1 ++ e2

# multiplicação numérica
e1 * e2

# divisão numérica
e1 / e2

# soma numérica
e1 + e2

# subtração
e1 - e2

# operadores relacionais
e1 > e2
e1 >= e2
e1 < e2
e1 <= e2
e1 == e2
e1 != e2

# operadores booleanos
!e
e1 && e2
e1 || e2
e1 -> e2 # equivalente a !e1 || e2

# concatenação de conjuntos
e1 // e2

Importações

import carrega, valida e importa expressões Nix a partir de um caminho, a palavra-chave não faz parte da linguagem em si:

x = import <nixpkgs> {}
y = trace x.pkgs.hello.name x;

Construtores

with

O construtor with introduz o escopo léxico da expressão referenciada na próxima expressão:

let
  conjunto = { a = 1; b = 2 };
in
  with conjunto; "Tenho acesso aos atributos ${toString a} e ${toString b}"

Pode ser muito útil nas expressões onde há necessidade de repetição de um atributo:

{ pkgs, ... }:

{
  buildInputs = with pkgs; [ curl rust bat ffmpeg ];
}

# ao invés de
{
  buildInputs = [ pkgs.curl pkgs.rust pkgs.bat pkgs.ffmpeg ];
}

let...in

Permite a crição de variáveis locais:

let
  a = 2;
  b = 3;
in a + b
# 5

inherit

Traz o escopo léxico externo para um interno:

buildPythonPackage rec {
  pname = "ola";
  version = "1.0";
  src = fetchPypi {
    inherit pname version;
   sha256 = "01ba..0";
  };
}

Conclusão

Este artigo é uma tentativa de tornar a documentação do Nix acessível em português! Sempre irei
referenciar as fontes oficiais no final de cada artigo, junto com alguns recursos adicionais!

Fontes e recursos adicionais

Este post foi publicado com minha ferramenta de linha de comando devit!
Você pode encontrar instruções para instalação neste link.

O que é Nix e por que você deveria experimentar?

Zoey de Souza Pessanha — Thu, 06 May 2021 01:00:01 +0000

Hoje em dia temos inúmeras opções para configurar um ambiente de desenvolvimento
que seja facilmente reproduzível e encapsulado. A escolha mais comum tem sido os
contêineres Docker.

Entretanto, nas minhas pesquisas aventureiras pela internet, descobri uma ferramenta bem
atrativa: o Nix.

Nesta breve série de artigos irei discorrer não só sobre o gerenciador de pacotes mas também mostrar
exemplos de ambientes para desenvolvimento que utilizam as vantagens do Nix!

O que é Nix?

Nix é um gerenciador de pacotes e uma linguagem de programação
funcional-declarativa, preguiçosa (nem sempre), e dinamicamente tipada que usamos
para descrever as _derivações (resultado das expressões em Nix) para esse gerenciador.

Como o gerenciador de pacotes funciona?

A partir de um arquivo que contenha as instruções para construção do pacote, o Nix computa
uma derivação. Para uma derivação ser considerada válida, o arquivo precisa ter as seguintes informações:

referência para as dependências do pacote a ser construído;
intruções de como construir o pacote;
metainformações sobre o pacote, como os mantenedores;

Quando o pacote for construído com sucesso, um caminho será criada com o resultado da construção
no formato: /nix/store/<hash>-<nome>-<versão>, onde o hash é criado a partir dos dados da derivação.

Veja o conjunto de expressões Nix que gera a derivação do software GNU hello, por exemplo:

{ lib, stdenv, fetchurl }:

stdenv.mkDerivation rec {
  pname = "hello";
  version = "2.10";

  src = fetchurl {
    url = "mirror://gnu/hello/${pname}-${version}.tar.gz";
    sha256 = "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i";
  };

  doCheck = true;

  meta = with lib; {
    description = "A program that produces a familiar, friendly greeting";
    longDescription = ''
      GNU Hello is a program that prints "Hello, world!" when you run it.
      It is fully customizable.
    '';
    homepage = "https://www.gnu.org/software/hello/manual/";
    changelog = "https://git.savannah.gnu.org/cgit/hello.git/plain/NEWS?h=v${version}";
    license = licenses.gpl3Plus;
    maintainers = [ maintainers.eelco ];
    platforms = platforms.all;
  };
}

Dessa forma o Nix consegue assegurar que a mesma derivação vai sempre construir o mesmo pacote,
a não ser que alguma instrução de construção use informações dependentes de hardware.

Vantagens de usar Nix

Ambiente sempre reproduzível

Essa é a vantagem mais clara da utilização do Nix para gerir pacotes e dependências, pois como
dito anteriormente, se duas pessoas contruirem um pacote com a mesma derivação, as duas terão o mesmo
resultado final. Mesmo que haja uma diferença na versão de alguma dependência, o caminho gerado pela
derivação irá se alterar, explicitando que houve uma mudança.

Múltiplas versões do mesmo pacote simultâneamente

Como cada pacote é instalado em seu próprio caminho, não há colissões. Isso se torna muito atrativo para
desenvolvedores, pois pode ser comparado com os ambientes virtuais de Python, só que para qualquer programa.

Além disso, como a cada versão construída do pacote gera um novo caminho, há sempre a possibilidade de retornar
à uma versão antiga, desde que ela não tenha sido apagada pelo garbage-collector.

Construções seguras

Toda a contrução de cada derivação é isolada do sistema, o que torna seguro permitir que usuários
com menos privilégios executem suas derivações.

Teste novas ferramentas temporariamente

Digamos que você precisa converter um arquivo escrito com Markdown para HTML com o pandoc! Porém, você
se lembra que não possui esse programa e precisa usá-lo apenas uma vez.

Naturalmente você possui algumas opções:

Baixar o programa dos repositórios oficiais, realizar a conversão e desinstalar;
Usar uma imagem Docker do programa, utilizá-la e deixar ela ocupando espaço na sua máquina;

Com o Nix é possível criar um ambiente sob demanda, mas sempre reprodutível, no qual um pacote não
existente no seu sistema passe a ser utilizável.

No caso do pandoc, com um simples nix-shell -p pandoc você tem acesso ao pacote de forma temporária!

Ecossistema

Essas vantagens são bem atrativas, mas os casos de uso para o Nix não param por aí. A seguir,
mostro exemplos do mundo real que usam Nix.

Nixpkgs

nixpkgs é a maior coleção de derivações para o gerenciador de pacotes que podem ser alteradas e combinadas.
Além de derivações específicas para cada linguagem, como um mirror atualizado do Hackage, existem derivações de
diversos outros softwares.

NixOS

Já o NixOS é uma distribuição GNU/Linux que é configurada a partir de expressões Nix, além de possuir nativamente
o gerenciador de pacotes. Todo o sistema é tratado como uma grande derivação que depende de todas as outras sub derivações
que você monta.

Neste trecho de exemplo, mostro como habilitar o uso do pulseaudio no NixOS:

sound.enable = true;
hardware.pulseaudio = {
  enable = true;
  package = pkgs.pulseaudioFull;
};

Esse trecho foi retirado da minha configuração pessoal.

Home Manager

Um projeto muito interessante no ecossistema Nix é o home-manager, que permite
gerenciar um ambiente (dotfiles) completo a nível de usuário.

Neste trecho da minha configuração pessoal, declaro alguns pacotes a nível de usuário:

programs = {
  home-manager.enable = true;
  gpg.enable = true;
  command-not-found.enable = true;
  emacs.enable = true;
};

services.clipmenu.enable = true;
services.emacs.enable = true;

home.username = "matthew";
home.homeDirectory = "/home/matthew";

home.packages = with pkgs; [
  # bar
  haskellPackages.xmobar

  # chat
  tdesktop discord

  # browser
  google-chrome

  # theme
  lxappearance

  # tools
  docker-compose insomnia
  qbittorrent obs-studio
  screenkey gitAndTools.gh

  # audio
  spotify

  # images
  peek flameshot imagemagick

  # others
  any-nix-shell arandr
  bitwarden-cli
];

Integração com diversas ferramentas

Também é possível usar o Nix para outras tarefas, como descrever a construção de uma imagem Docker:

{ pkgs ? import <nixpkgs> { system = "x86_64-linux" } }:

pkgs.dockerTools.buildLayeredImage { # função para facilitar a construção da imagem
  name = "nix-hello";                # nome da imagem a ser construída
  tag = "latest";                    # tag para a imagem
  contents = [ pkgs.hello ];         # pacotes presentes na imagem
}

Conclusão

Em suma, o Nix e seu ecossistema é uma boa opção para quem quer ter novas experiências
no mundo Unix, permitindo que um ambiente de desenvolvimento ou até mesmo uma distribuição
GNU/Linux completa possa ser facilmente reproduzida, além de usufruir das vantagens da imutabilidade
de uma linguagem funcional.

Porém, é importante ter em mente que assim como qualquer ferramenta, o Nix não funciona como
"bala de prata". Existem alguns contras que você deve levar em consideração:

O número de pacotes envelopados, apesar de serem inúmeros, não se comparam (ainda) com os repositórios oficiais de algumas distribuições, por exemplo.
Alguns pacotes podem não ser atualizados com frequência.

Fontes e recursos adicionais

Este post foi publicado com minha ferramenta de linha de comando devit!
Você pode encontrar instruções para instalação neste link.