DEV Community: Luan Gomes

Deploying Elixir LiveView for free on Render using Docker

Luan Gomes — Mon, 09 May 2022 10:54:20 +0000

Deploying an Elixir application has been complicated some time ago, but now we have so many tools that facilitate our job that is very simple to set up a production environment for free.

Render is a platform as a service that offers a host for our server, DDoS protection, auto-deploy on git, and many more features that we can use without putting a credit card! They support Docker as well, so we are going to use it.

The objective here is to create a simple LiveView application, change it and deploy it on Render using a Docker image.

So let's start!

Creating the app and running on docker locally

Our application will be called Render Deploy, it has no functionality, it is just to demonstrate the deployment.

To create a LiveView app, run the command below:

mix phx.new render_deploy --live --no-ecto

- - live: This is the indication that the new project is a LiveView app.
- - no-ecto: Indicates that we don't want ecto, so it will not have a Repo.

Now, on the config/dev.exs, line 12 change 127, 0, 0, 1 to 0, 0, 0, 0 to allow access from docker.

We must create the ./Dockerfile on the directory root to run locally:

FROM hexpm/elixir:1.13.0-erlang-23.3.4.10-alpine-3.14.3 AS base

WORKDIR /render_deploy

RUN mix do local.hex --force, local.rebar --force

RUN apk add npm inotify-tools

This is a docker multistage build, it keeps the file more readable and creates a smaller image, you can read more here.
FROM hexpm/elixir:1.13.0-erlang-23.3.4.10-alpine-3.14.3 AS base: Here we are pulling the elixir image based on alpine, which is a smaller image.
WORKDIR /render_deploy: This will be our work directory, inside the container.
RUN mix do local.hex --force, local.rebar --force: Installs precompiled hex and rebar.
RUN apk add npm inotify-tools: Live reloading tool

We could run docker build and docker run, but I prefer using docker-compose to manage the containers, so let's create a new ./docker-compose.yml on the directory root.

version: "3.8"

services:
  app:
    build:
      context: .
      target: base
    container_name: render_deploy_web
    command: mix phx.server
    restart: unless-stopped
    ports:
      - 4000:4000
    volumes:
      - .:/render_deploy

With multistage build we can set a specific target when creating the container, in this case, is target: base.

After creating the files we can run these commands to install dependencies, create the container and run the server locally.

docker-compose run --rm app mix deps.get

docker-compose up

If we can access localhost:4000 we will see this page:

Let's change it to make it unique.

lib/render_deploy_web/templates/page/index.html.heex line 2 change

<h1><%= gettext "Welcome to %{name}!", name: "Phoenix" %></h1>
to
<h1><%= gettext "Welcome to %{name}!", name: "Render deploy" %></h1>

Adjusting the code before deploy

We are going to use mix releases, which is a way to package our application into an executable binary and use it to deploy the application.

For this, we must add the following code to the end of ./Dockerfile file:

# -----------------
# BUILD
# -----------------
FROM base AS build

RUN apk add curl bash git

ARG MIX_ENV=prod
ENV MIX_ENV=$MIX_ENV
COPY . ./

# install application
RUN mix do deps.get, compile

# -----------------
# RELEASE
# -----------------
FROM build AS release

# digests and compresses static files
RUN mix assets.deploy

# generate release executable
RUN mix release

# -----------------
# PRODUCTION
# -----------------
FROM alpine:3.14.3

WORKDIR /render_deploy

ARG MIX_ENV=prod

# install dependencies
RUN apk add ncurses-libs curl

COPY --from=release /render_deploy/_build/$MIX_ENV/rel/render_deploy ./

# start application
CMD ["bin/render_deploy", "start"]

Important things about the code:
ARG MIX_ENV=prod: We set our mix env to prod.
RUN mix assets.deploy: minify esbuild and compresses static files.
COPY --from=release /render_deploy/_build/$MIX_ENV/rel/render_deploy ./: Copy the previous build stage to the current stage.
CMD ["bin/render_deploy", "start"]: It will start the application.

Now, before deploying we must adjust our config/runtime.exs so Render will put the production URL:

import Config

if System.get_env("PHX_SERVER") && System.get_env("RELEASE_NAME") do
  config :render_deploy, RenderDeployWeb.Endpoint, server: true
end

if config_env() == :prod do
  secret_key_base =
    System.get_env("SECRET_KEY_BASE") ||
      raise """
      environment variable SECRET_KEY_BASE is missing.
      You can generate one by calling: mix phx.gen.secret
      """

  port = String.to_integer(System.get_env("PORT") || "4000")

  config :render_deploy, RenderDeployWeb.Endpoint,
    url: [host: System.get_env("RENDER_EXTERNAL_HOSTNAME") || "localhost", port: 80],
    http: [
      ip: {0, 0, 0, 0, 0, 0, 0, 0},
      port: port
    ],
    secret_key_base: secret_key_base

  config :render_deploy, RenderDeployWeb.Endpoint, server: true
end

Preparing the deploy

Ok, we have our development setup done with docker and we are ready to deploy in production with render.com

First of all, we need to create a repository with the code on Github.

Now let's access render.com and create the project, if you don't have an account, create it then click on New, Web Service.

Select your repository:

Choose a name, select Docker as the environment runtime and the free plan.

Now we must set the secret key, to do this, run the following command to generate a secret:

docker-compose run --rm app mix phx.gen.secret

After this, scroll down the page and click on "Advanced", then put the SECRET_KEY_BASE with the secret generated before.

Now we just click on "Create Web Service" and wait for Render to deploy our application to production.

When the deployment is completed you will see the "Live" label, now just click on the URL and check our new LiveView application running on the cloud 🎉

Render has some limitations on the free plan, the apps are automatically spun down after 15 minutes of inactivity and a new request after this time can take 30 seconds to be up again, also the free plan allows for 750 hours of running time per month across all free web services in your account, you can see all limitations here.

Even with these constraints, it is a nice platform to have our services and to practice the production deployment.

You can check the source code here: https://github.com/Lgdev07/render_deploy and the application that we've just built here: https://render-example-71rp.onrender.com/

I appreciate everyone who has read through here, if you guys have anything to add, please leave a comment.

Elixir SOLID Principles - Examples

Luan Gomes — Sat, 25 Dec 2021 23:11:36 +0000

Building an application can be hard depending on how you do it, as our career passes and the knowledge we get, more information and good practices we use for creating and improving the software we maintain.

Some good practices are in SOLID Principles, a mnemonic acronym for five design principles intended to make software designs more understandable, flexible, and maintainable.

Is good to be clear, SOLID has been created with Object-Oriented Programming in mind, so we are adapting to Elixir, a functional programming language, we are going to see that the benefits do not depend on the programming paradigm.

Example - Animals module

To explain better how we use the solid principles on elixir, I am gonna create a module and for each principle, we refactor it, the module is called Animals and is responsible to create an animal, adding some customization, getting and sending a picture of it.

The example below is the first version:

defmodule Animals do
    def create_mammal(), do: #create an animal of type mammal

    def create_carnivorous(), do: #create an animal of type carnivorous

    def add_hat(animal), do: #add a hat to the animal

    def add_shirt(animal), do: #add a hat to the animal

    def get_picture(animal), do: #get picture from the animal

    def send_picture_email(picture, email), do: #send the picture to email

    def send_picture_whatsapp(picture, number), do: #send the picture to whatsapp
end

iex> {:ok, animal} = Animals.create_mammal()
iex> {:ok, animal_customized} = animal |> Animals.add_hat() |> Animals.add_shirt()
iex> :ok = animal_customized |> Animals.get_picture() |> Animals.send_picture_email("email@example.com")

if you noticed that this is not maintainable or scalable, you are right, in the first moment that could work, but responsibilities are mixed in a single module and are confusing.

The first principle that we are going to use is Single Responsibility, modules must be separated by their context.

Single Responsibility Principle

"There should never be more than one reason for a class to change."

defmodule Animals do
    def create_mammal(), do: #create an animal of type mammal

    def create_carnivorous(), do: #create an animal of type carnivorous
end

defmodule Animals.Clothes do
    def add_hat(animal), do: #add a hat to the animal

    def add_shirt(animal), do: #add a hat to the animal
end

defmodule Animals.Pictures do
    def get_picture(animal), do: #get picture from the animal

    def send_picture_email(picture, email), do: #send the picture to email

    def send_picture_whatsapp(picture, number), do: #send the picture to whatsapp
end

iex> {:ok, animal} = Animals.create_mammal()
iex> {:ok, animal_customized} = animal |> Animals.Clothes.add_hat() |> Animals.Clothes.add_shirt()
iex> :ok = animal_customized |> Animals.Pictures.get_picture() |> Animals.Pictures.send_picture_email("email@example.com")

Now is more clear what each module does, but if we get the Animals.Pictures and try to add one more sending method, it starts to be a little repetitive and we break Open Closed principle, because we are modifying an entity.

Open Closed Principle

"Software entities ... should be open for extension, but closed for modification."

# FROM
defmodule Animals.Pictures do
    def get_picture(animal), do: #get picture from the animal

    def send_picture_email(picture, email), do: #send the picture to email

    def send_picture_whatsapp(picture, number), do: #send the picture to whatsapp
end

#TO
defmodule Animals.Pictures do
    def get(animal), do: #get picture from the animal

    def send(picture, data, :email), do: #send the picture to email

    def send(picture, data. :whats), do: #send the picture to whatsapp
end

iex> {:ok, animal} = Animals.create_mammal()
iex> {:ok, animal_customized} = animal |> Animals.Clothes.add_hat() |> Animals.Clothes.add_shirt()
iex> :ok = animal_customized |> Animals.Pictures.get() |> Animals.Pictures.send("email@example.com", :email)

In that way, we just create a new function send/3 without modifying the entity.

Another thing that can be improved is the module that creates the animals, currently, it has a general proposal, which is not extensible because we are changing the interface at each modification, sometimes is better to have a specific module that uses the same interface.

Interface segregation principle

"Many client-specific interfaces are better than one general-purpose interface."

# FROM
defmodule Animals do
    def create_mammal(), do: #create an animal of type mammal

    def create_carnivorous(), do: #create an animal of type carnivorous
end

#TO
defmodule Animals.Mammal do
    def create(), do: #create an animal of type mammal
end

defmodule Animals.Carnivorous do
    def create(), do: #create an animal of type carnivorous
end

iex> {:ok, animal} = Animals.Mammal.create()
iex> {:ok, animal_customized} = animal |> Animals.Clothes.add_hat() |> Animals.Clothes.add_shirt()
iex> :ok = animal_customized |> Animals.Pictures.get() |> Animals.Pictures.send("email@example.com", :email)

Now they are using the same interface and it is easy to extend each specific module without changing the interface that creates a new animal.

The Liskov principle states that a superclass object should be replaceable with a subclass object without breaking the functionality of the software and makes heavy use of inheritance and polymorphism, but for a functional programming language we have to deal with it in another way, elixir has behaviours, so all the modules that use the defined behaviour must implement their functions.

Liskov substitution principle

"Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it."

# FROM
defmodule Animals.Clothes do
    def add_hat(animal), do: #add a hat to the animal

    def add_shirt(animal), do: #add a shit to the animal
end

#TO
defmodule Animals.Animal do
  @type t :: %{type: String.t, name: String.t}

  defstruct ~w(type name)a
end

defmodule Animals.Clothes.Clothing do
  @callback add(Animals.Animal.t) :: Animals.Animal.t
end

defmodule Animals.Clothes.Hat do
  @behaviour Animals.Clothes.Clothing

  def add(animal), do: #add a hat to the animal
end

defmodule Animals.Clothes.Shirt do
  @behaviour Animals.Clothes.Clothing

  def add(animal), do: #add a shirt to the animal
end

defmodule Animals.Clothes do
  @spec apply(Animals.Animal.t, String.t)
  def apply(animal, :hat), do: Animals.Clothes.Hat.add(animal)
  def apply(animal, :shirt), do: Animals.Clothes.Shirt.add(animal)
end

iex> {:ok, animal} = Animals.Mammal.create()
iex> {:ok, animal_customized} = animal |> Animals.Clothes.apply(:hat) |> |> Animals.Clothes.apply(:shirt)
iex> :ok = animal_customized |> Animals.Pictures.get() |> Animals.Pictures.send("email@example.com", :email)

We have defined the Animals.Clothes.Clothing behaviour and for instance the Animals.Clothes.Hat must use the add/1 callback, so in this way, we guarantee that all the modules that implement it have the same action without breaking the functionality.

Now if we look at the Animals.Clothes module, we are explicitly declaring witch module has to be used depending on function parameters, this is incorrect accordingly with Dependency inversion principle, the correct way to fix this is to abstract the apply/2 function to receive a module in its arguments and use the function of that module because we have the type definition.

Dependency inversion principle

"Depend upon abstractions, [not] concretions."

# FROM
defmodule Animals.Clothes.Clothing do
  @callback add(Animals.Animal.t) :: Animals.Animal.t
end

defmodule Animals.Clothes do
  @spec apply(Animals.Animal.t, String.t)
  def apply(animal, :hat), do: Animals.Clothes.Hat.add(animal)
  def apply(animal, :shirt), do: Animals.Clothes.Shirt.add(animal)
end

#TO
defmodule Animals.Clothes.Clothing do
  @type t :: module()

  @callback add(Animals.Animal.t) :: Animals.Animal.t
end

defmodule Animals.Clothes do
  @spec apply(Animals.Animal.t, Animals.Clothes.Clothing.t)
  def apply(animal, clothing), do: clothing.add(animal)
end

iex> {:ok, animal} = Animals.Mammal.create()
iex> {:ok, animal_customized} = animal |> Animals.Clothes.apply(Animals.Clothes.Hat) |> |> Animals.Clothes.apply(Animals.Clothes.Shirt)
iex> :ok = animal_customized |> Animals.Pictures.get() |> Animals.Pictures.send("email@example.com", :email)

With the type definition, we can abstract the inner implementation to depend on the module itself, and we know what the module does because of the behaviour that it uses.

If we look for the difference between the first implementation and the final result, it is more verbose, but much more readable, maintainable and extensible.

# FROM
defmodule Animals do
    def create_mammal(), do: #create an animal of type lion

    def create_carnivorous(), do: #create an animal of type dog

    def add_hat(animal), do: #add a hat to the animal

    def add_shirt(animal), do: #add a hat to the animal

    def get_picture(animal), do: #get picture from the animal

    def send_picture_email(picture, email), do: #send the picture to email

    def send_picture_whatsapp(picture, number), do: #send the picture to whatsapp
end

#TO
defmodule Animals.Mammal do
    def create(), do: #create an animal of type mammal
end

defmodule Animals.Carnivorous do
    def create(), do: #create an animal of type carnivorous
end

defmodule Animals.Pictures do
    def get(animal), do: #get picture from the animal

    def send(picture, data, :email), do: #send the picture to email

    def send(picture, data. :whats), do: #send the picture to whatsapp
end

defmodule Animals.Animal do
  @type t :: %{type: String.t, name: String.t}

  defstruct ~w(type name)a
end

defmodule Animals.Clothes.Clothing do
  @type t :: module()

  @callback add(Animals.Animal.t) :: Animals.Animal.t
end

defmodule Animals.Clothes.Hat do
  @behaviour Animals.Clothes.Clothing

  def add(animal), do: #add a hat to the animal
end

defmodule Animals.Clothes.Shirt do
  @behaviour Animals.Clothes.Clothing

  def add(animal), do: #add a shirt to the animal
end

defmodule Animals.Clothes do
  @spec apply(Animals.Animal.t, Animals.Clothes.Clothing.t)
  def apply(animal, clothing), do: clothing.add(animal)
end

iex> {:ok, animal} = Animals.Mammal.create()
iex> {:ok, animal_customized} = animal |> Animals.Clothes.apply(Animals.Clothes.Hat) |> |> Animals.Clothes.apply(Animals.Clothes.Shirt)
iex> :ok = animal_customized |> Animals.Pictures.get() |> Animals.Pictures.send("email@example.com", :email)

I appreciate everyone who has read through here, if you guys have anything to add, please leave a comment.

This post was inspired by:

https://medium.com/@andreichernykh/solid-elixir-777584a9ccba

Amazing way to learn: compare languages and contribute with your code!

Luan Gomes — Sun, 05 Sep 2021 14:54:55 +0000

Code Comparison

During my studies with elixir, I wanted to create something simple just to try LiveView.

So I had an idea of creating an app that shows the difference between programming languages by topics.

For example, you want to know how to create a map in Python or Go, you just select in the dropdown.

All the code is in the repo, allowing the user to contribute with their own code in Github, which is a great way for beginners to learn and help others.

You can see the site in action here: https://www.codecomparison.me/

How to contribute?

Forking the project or Creating the PR via Github.com

Forking the project

Access the repo: https://github.com/Lgdev07/code_comparison
Fork the repository
In the root directory, the topics folder is where you can create a new one, change a code that already exists or create a new file with the language you know.
After finishing your code, create a new branch git checkout -b my-feature
Commit the changes git add . && git commit -m 'feat: My new feature'
Push the changes git push origin my-feature
Open the Pull Request

Or Creating the PR via Github.com

Access the topics folder: https://github.com/Lgdev07/code_comparison/tree/main/topics
The topics folder is where you can create a new one, change a code that already exists or create a new file with the language you know.
For example, if I want to create a new file in the map topic
I go to map, and click on Create new file
After finishing your code, you can create a pull request by the end of the page, clicking on Propose new file
Don't forget to describe your commit and PR.

Github code: https://github.com/Lgdev07/code_comparison

I appreciate everyone who has read through here, if you guys have anything to add, please leave a comment.

Elixir OTP - Basics with project example

Luan Gomes — Sun, 27 Jun 2021 22:21:07 +0000

OTP

OTP (Open Telecom Platform) can be defined with three components: is based on Erlang, has a set of libraries from BEAM (Erlang VM) and follow a system design principles.

If you want to know more about the design principles, take a look at the book Designing for Scalability with Erlang/OTP from Francesco Cesarini and Steve Vinoski.

Processes

In the core of the OTP we have the processes, not those of the operating system, they are created directly in BEAM, lighter, totally isolated and communicate via messages asynchronously.

In addition to all these advantages, Elixir also provides some abstractions for developers to work faster and more productively with them, through tools that allow the creation of new processes, communication and finalization, besides, thanks to immutability we don't need to worry with saving state, then problems with race condition can be avoided more easily.

An example of process creation:

iex(1)> process = spawn(fn -> IO.puts("hey there!") end)
Hey there!
#PID<0.108.0>

Supervisor

We can create several processes but so far we have no control over them, what happens if one dies? If we need to group by context? How to organize them? For this, the OTP provides the Supervisor, with him we can start and end a list of pre-defined processes, define a behavior so that when a process dies, it is executed, for example, restarted, in addition to leaving the structure according to the context through the Supervision Tree .

Creating a simple demo project

After understanding the basics, we will create a small project to demonstrate the ease of creating and killing processes, in addition to the communication between them, in this project we will manage the number of store employees.

Creating the project:

mix new otp_test --sup

cd otp_test

We will create the store struct:

otp_test/lib/otp_test/store/struct.ex

defmodule Store.Struct do
  @enforce_keys [:name, :employees]
  defstruct [:name, :employees]
end

Let's implement the GenServer behavior, with our customization:

otp_test/lib/otp_test/core/store.ex

defmodule Core.Store do
  use GenServer

  alias Store.Struct, as: Store

  def start_link(%Store{} = store) do
    GenServer.start_link(__MODULE__, store, name: String.to_atom(store.name))
  end

  @impl true
  def init(%Store{} = store) do
    {:ok, store}
  end

  @impl true
  def handle_call(:store, _from, %Store{} = store) do
    {:reply, store, store}
  end

  @impl true
  def handle_cast({:add_employees, amount}, %Store{} = store) do
    store =
      store
      |> Map.put(:employees, store.employees + amount)

    {:noreply, store}
  end
end

Here we implement the GenServer behavior, let's analyze the functions/callbacks:

start_link: Function to start the process, we define the name as an atom of the store name.
init: Function executed as soon as the process is started.
handle_call: Callback for synchronous executions, in this case we just want to return the store.
handle_cast: Callback for asynchronous executions, here we add more employees according to the sent parameter.

We can now test the implementation, checking if the init function is executed when generating the process:

iex -S mix

iex(1)> store = %Store.Struct{name: "test1", employees: 2}
%Store.Struct{employees: 2, name: "test1"}
iex(2)> Core.Store.start_link store
{:ok, #PID<0.164.0>}

Let's add some employees:

iex(3)> GenServer.cast String.to_atom(store.name), {:add_employees, 4}     
:ok     
iex(4)> GenServer.call String.to_atom(store.name), :store             
%Store.Struct{employees: 6, name: "test1"}

Now this store has 6 employees, we were able to change the value as we configured! 🎉

A simpler way to deal with GenServer is separating its implementation to a public api, let's do that:

otp_test/lib/otp_test/store/management.ex

defmodule Store.Management do
  alias Store.Struct, as: Store

  def open(%Store{} = store) do
    store
    |> Core.Store.start_link()
  end

  def get_store(%Store{} = store) do
    GenServer.call(String.to_atom(store.name), :store)
  end

  def add_employees(%Store{} = store, amount) do
    GenServer.cast(String.to_atom(store.name), {:add_employees, amount})
  end
end

Here we abstract the implementation for use in a public api that calls GenServer but doesn't care about implementing its callbacks.

Lets test:

iex(7)> store = %Store.Struct{name: "test2", employees: 3}
%Store.Struct{employees: 3, name: "test2"}
iex(8)> Store.Management.open store                       
{:ok, #PID<0.179.0>}
iex(9)> Store.Management.add_employees store, 4 
:ok     
iex(10)> Store.Management.get_store store       
%Store.Struct{employees: 7, name: "test2"}

So far we've created processes, but we don't use Supervisors, let's put it into practice:

otp_test/lib/otp_test/store/supervisor.ex

defmodule Store.Supervisor do
  use Supervisor

  alias Store.Struct, as: Store

  def start_link(init_arg) do
    Supervisor.start_link(__MODULE__, init_arg,  name: __MODULE__)
  end

  def init(_init_arg) do
    children = [
      create_store(%Store{name: "Test1", employees: 2}),
      create_store(%Store{name: "Test2", employees: 2})
    ]

    Supervisor.init(children, strategy: :one_for_one)
  end

  defp create_store(%Store{} = store) do
    %{
      id: String.to_atom(store.name),
      start: {Core.Store, :start_link, [store]}
    }
  end
end

This way we create a unique supervisor for the store context, when we start, we create two children processes.

The strategy we define for this supervisor's processes is :one_for_one , which restarts each time one of them dies.

To test that our project will start with this supervisor, it is necessary to include it in the Supervisors list, in otp_test/lib/otp_test/application.ex

defmodule OtpTest.Application do
  # See https://hexdocs.pm/elixir/Application.html
  # for more information on OTP Applications
  @moduledoc false

  use Application

  @impl true
  def start(_type, _args) do
    children = [
      # Starts a worker by calling: OtpTest.Worker.start_link(arg)
    ]

    # See https://hexdocs.pm/elixir/Supervisor.html
    # for other strategies and supported options
    opts = [strategy: :one_for_one, name: OtpTest.Supervisor]
    Supervisor.start_link(children, opts)
    Store.Supervisor.start_link([])
  end
end

To test our Supervisor started, let's restart the application and check how many processes are in it:

iex(1)> Supervisor.which_children Store.Supervisor
[
  {:Test2, #PID<0.143.0>, :worker, [Core.Store]},
  {:Test1, #PID<0.142.0>, :worker, [Core.Store]}
]
iex(2)> Supervisor.which_children OtpTest.Supervisor
[]

We were able to confirm that when starting the application, Store.Supervisor created the two initial processes, let's test killing one to see if it will restart:

iex(3)> :sys.terminate :Test1, :kill
:ok
iex(4)> 
18:56:44.901 [error] GenServer :Test1 terminating
** (stop) :kill
Last message: []
State: %Store.Struct{employees: 2, name: "Test1"}

nil
iex(5)> Process.whereis :Test1
#PID<0.149.0>
iex(6)>

It worked! 🎉

We killed the :Test1 process, which had the id 142, a new one was automatically generated, this time with the id 149.

With this example I hope that the importance and ease of using OTP in elixir applications is clear, its ease and extensibility allows for great productivity in projects.

Github code: https://github.com/Lgdev07/otp_test

I appreciate everyone who has read through here, if you guys have anything to add, please leave a comment.

Elixir difference between Behaviour and Protocol

Luan Gomes — Sun, 16 May 2021 02:19:29 +0000

While building and analyzing code in Elixir, you have probably come across the keywords behavior, impl, defprotocol and defimpl, while searching you may have found a short description that can confuse you about when to use them and their differences, this post brings some examples of when to use them and how to implement them in a real project.

Behaviour

Behaviour is a way to implement a user interface for a module to share its api in a public way, this module must have functions that need to be used in the ones that implement this behaviour.

Let's get to the examples:

Suppose we need to define an interface for our parsers, for this we will create a module:

defmodule Parser do
    @callback parse_ids(map) :: map

    @spec to_downcase(map) :: map
    def to_downcase(attrs) do
        attrs
        |> Map.new(fn {i, v} -> {i, String.downcase(v)} end)
    end
end

In this case we create a Parser module with an @callback and a function that takes a map and transforms its values into downcase.

@callback is the function that should be implemented by all modules that use the Parser behavior.

Let's look at an example of its use.

defmodule Person do
    @behaviour Parser

    @impl Parser
    def parse_ids(attrs) do
        attrs
        |> Map.put_new("name", get_in(attrs, ["user", "name"]))
        |> Map.put_new("email", get_in(attrs, ["user", "email"]))
        |> Parser.to_downcase()
    end
end

Here we use the Parser behaviour to define the parse_ids function, otherwise the compiler will return a warning.

Although not required, the @impl ensures that we are implementing the correct callbacks.

Behaviours are a great way to ensure behavior when we need to export a module's public api, as they have types defined in their construction.

Protocols

In a very direct way, protocols are a way to implement polymorphism in Elixir, we use them when we need a module to have a different behavior depending on the type of the value.

Here are some examples:

defprotocol Document do
    @spec id(any) :: any
    def id(item)

    @spec encode(any) :: map
    def encode(item)
end

Here we define our protocol, so everyone who uses it can create the function with a return that is within the specifications and is for a unique type.

Let's use the protocol.

defmodule Person do
    embedded_schema do
        field :name, :string
        field :social_security_number, :string
    end

    defimpl Document, for: __MODULE__ do
        def id(struct), do: struct.social_security_number     

        def encode(struct) do
            struct
            |> Person.to_map()
        end
    end

    def to_map(struct) do
        %{
        name: struct.name,
        social_security_number: struct.social_security_number
        }
    end
end

Here we define the use of the Document protocol with defimpl, see that we are defining the type, through for: __MODULE__, that way when Document.encode is called, it already knows it will return a map, the definition of which map it will return is in the module specification, very separate responsibilities.

But what is the difference between Behaviour and Protocol?

A good example is given by the creator of the language, José Valim, in this post: https://groups.google.com/forum/#!msg/elixir-lang-talk/S0NlOoc4ThM/J2aD2hKrtuoJ

"""A protocol is indeed a behaviour + dispatching logic.

However I think you are missing the point of behaviours. Behaviours are extremely useful. For example, a GenServer defines a behaviour. A behaviour is a way to say: give me a module as argument and I will invoke the following callbacks on it, which these argument and so on. A more complex example for behaviours besides a GenServer are the Ecto adapters.

However, this does not work if you have a data structure and you want to dispatch based on the data structure. Hence protocols."""

I appreciate everyone who has read through here, if you guys have anything to add, please leave a comment.

What I've learned today - 5 - Using Golang channels as async await

Luan Gomes — Sat, 08 May 2021 01:15:04 +0000

For people accustomed to using Javascript, they have certainly used or heard about async / await, it is a feature of the language that allows working with asynchronous programming.

Golang has channels and goroutines, allowing this to be used very smoothly, however, people who have just come to the language may not know how to do it, to have a base, I prepared an example that can help to understand.

We will use the public pokeapi api.

How it is done in Javascript

const awaitTask = async () => {
    let response = await fetch('https://pokeapi.co/api/v2/pokemon/ditto');

    if (!response.ok) {
      throw new Error(`HTTP error! status: ${response.status}`);
    }
    return response
  }

awaitTask()
    .then(r => r.json())
    .then(r => console.log(r))

How we do it in Golang

package main

import (
    "fmt"
    "io/ioutil"
    "log"
    "net/http"
)

func awaitTask() <-chan string {
    fmt.Println("Starting Task...")

    c := make(chan string)

    go func() {
        resp, err := http.Get("https://pokeapi.co/api/v2/pokemon/ditto")
        if err != nil {
            log.Fatalln(err)
        }

        body, err := ioutil.ReadAll(resp.Body)
        if err != nil {
            log.Fatalln(err)
        }

        c <- string(body)

        fmt.Println("...Done!")
    }()

    return c
}

func main() {
    value := <-awaitTask()

    fmt.Println(value)
}

How to make:

Set the return type to be a channel.
Create a channel to return a value.
Add a go func for asynchronous execution.
Within the function, assign the value to the channel.
At the end of the function, indicate the return of the channel with the value.
In the main function, assign the return of the channel to a variable.

I appreciate everyone who has read through here, if you guys have anything to add, please leave a comment.

What I've learned today - 4 - Elixir - Executing a code after load

Luan Gomes — Thu, 06 May 2021 02:53:16 +0000

Quick tip

Executing code Immediately after loading a Module

Elixir has @on_load which accepts atom as function name in the same module or a tuple with function_name and its arity like {function_name, 0}.

Examples

#Hello module 
defmodule Hello do
@on_load :onload     # this executes after module gets loaded 
  def onload do
    IO.puts "#{__MODULE__} is loaded successfully"
  end
end
# Execution .... Just copy and paste the code in the iex terminal
# You will see the output something like this ....
Elixir.Hello is loaded successfully  
{:module, Hello,
 <<70, 79, 82, 49, 0, 0, 4, 72, 66, 69, 65, 77, 65, 116, 85, 56, 0, 0, 0, 130,
   0, 0, 0, 12, 12, 69, 108, 105, 120, 105, 114, 46, 72, 101, 108, 108, 111, 8,
   95, 95, 105, 110, 102, 111, 95, 95, 9, ...>>, {:onload, 0}}

Obtained from: https://github.com/blackode/elixir-tips

I appreciate everyone who has read through here, if you guys have anything to add, please leave a comment.

What I've learned today - 3 - Elixir add color to console

Luan Gomes — Wed, 05 May 2021 03:04:52 +0000

Coloring your console prints

Since Elixir 1.4.0 we have ANSI color printing option.

Ir supports also background colors.

For more information, see: https://hexdocs.pm/elixir/IO.ANSI.html

Examples

import IO.ANSI
IO.puts red <> "red" <> green <> " green" <> yellow <> " yellow" <> reset <> " normal"
IO.puts Enum.join [red, "red", green, " green", yellow, " yellow", reset, " normal"]
IO.puts IO.ANSI.format([:blue_background, "Example"])
IO.puts IO.ANSI.format([:green_background, "Example"])

I appreciate everyone who has read through here, if you guys have anything to add, please leave a comment.

What I've learned today - 2 - Walrus Operator (:=) in Python

Luan Gomes — Tue, 04 May 2021 02:40:18 +0000

What is?

The new operator allows variable assignments within expressions (also called Walrus Operator). It started as a proposal in PEP572 and became available in Python 3.8.

Benefits

Make things more compact.
Compress code when using regular expressions.
Speed up the processing of large data.
Code more readable.

Examples

A good example can be found in PEP572 documentation:

Current:

reductor = dispatch_table.get(cls)
if reductor:
    rv = reductor(x)
else:
    reductor = getattr(x, "__reduce_ex__", None)
    if reductor:
        rv = reductor(4)
    else:
        reductor = getattr(x, "__reduce__", None)
        if reductor:
            rv = reductor()
        else:
            raise Error(
                "un(deep)copyable object of type %s" % cls)

Improved:

if reductor := dispatch_table.get(cls):
    rv = reductor(x)
elif reductor := getattr(x, "__reduce_ex__", None):
    rv = reductor(4)
elif reductor := getattr(x, "__reduce__", None):
    rv = reductor()
else:
    raise Error("un(deep)copyable object of type %s" % cls)

This code is from python's core, and is a improved version of copy.py

We can use in any condition structure:

# While loop
while (command := input("> ")) != "quit":
    print("You entered:", command)

# Any
if any((comment := line).startswith('#') for line in lines):
    print("First comment:", comment)
else:
    print("There are no comments")

# List comprehenssion
stuff = [[(f(x) as .y), x/.y] for x in range(5)] # with "as"

Observations

The operator cannot be used for everything, in some cases he won't work:

a := 1 #INVALID must be done with a=1.
a = b := 2 #INVALID must be done with a=b=2

I appreciate everyone who has read through here, if you guys have anything to add, please leave a comment.

What I've learned today - 1 - SSL

Luan Gomes — Sun, 02 May 2021 23:09:40 +0000

What is SSL?

SSL stands for Secure Sockets Layer, a type of digital security that allows encrypted communication between a website and a browser. They are digital passports that provide authentication to protect the confidentiality and integrity of website communication with browsers.

How SSL Certificates Work

When accessing a web page, it is safe to perform certification of the page for data transmission in a secure manner.

Especially for sites where we need to send personal data, such as e-commerce, it is essential that you have an active SSL certificate.

SSL handshake

The handshake is done at the beginning of the communication between the browser and the web server, they use asymmetric encryption for certification on both sides.

Steps:

→ Browser tries to connect to the web server.

→ Web server sends back a copy of the SSL certificate.

→ The browser checks whether the certificate is valid.

→ If valid, the browser sends the response to the web server.

→ Web server sends the acknowledgement to start an encrypted session with the browser.

SSL data transfer

Data transfer is done using symmetric encryption, where the browser and web server have the same session key that will be used to encrypt and decrypt the data.

→ At this moment there is the exchange of data using the session key

How to know if a website has SSL

Simple, we just need to verify if that site has HTTPS at the start of the address (instead of “HTTP”).

Benefits of using SSL

Safety.
Your user can trust that their data is being cryptography.
HTTPS instead of HTTP, which ranks better on google.

I appreciate everyone who has read through here, if you guys have anything to add, please leave a comment.

Example of Generators in Python

Luan Gomes — Sat, 08 Aug 2020 00:12:54 +0000

Memory management is very important during software development, to scale it in a healthy way, knowledge of its language functions must provide the performance that will make a difference.

Let's get to know generators in Python, what it is, how to use it and the relationship with memory management.

We can define generators as iterators, with the difference that the value is not stored, the execution occurs on the fly.

The best way to use is through functions, that you can get the value as the generation occur.

def generator_function():
    for i in range(5):
        yield i

# Output: 0
# 1
# 2
# 3
# 4

A good use is the fibonacci numbers, if we pass a function a like that...

def fibon(n):
    a = b = 1
    result = []
    for i in range(n):
        result.append(a)
        a, b = b, a + b
    return result

for x in fibon(1000000):
    print(x)

We will probably run out of memory, because the result is being stored in a array.

With the generators...

def fibon(n):
    a = b = 1
    for i in range(n):
        yield a
        a, b = b, a + b

We will use far fewer resources because there is no value being stored.

This was just a simple example, but you had a view how the things work, the generators are powerful and a good friend of your system.