DEV Community: Mateus Martins

Aprendizado Elixir - módulo 2

Mateus Martins — Mon, 27 Jun 2022 13:00:57 +0000

Nesse módulo, criaremos um projeto chamado reports_generator, então já vamos cria-lo no terminal:

mix new reports_generator


* creating README.md
* creating .formatter.exs
* creating .gitignore
* creating mix.exs
* creating lib
* creating lib/reports_generator.ex
* creating test
* creating test/test_helper.exs
* creating test/reports_generator_test.exs

Desta vez, já iremos utilizar uma lib externa, então iremos aprender a instalar uma lib externa.

A lib em questão será o CREDO.

Para instala-lo, basta pesquisar por “elixir credo” no google, ou acessar o link.

Mas afinal, o que é o credo?

O credo é um analisador sintático de código. Ele Irá nos ajudar a manter boas práticas de escrita do nosso código, além do mix format que irá nos ajudar a formatar o código.

Para instalar o credo, basta acessar a pasta “mix .exs” dentro do projeto e ir até a função “defp deps do”.
Lá iremos inserir:

{:credo, "~> 1.6", only: [:dev, :test], runtime: false}

No terminal, utilizamos o comando “mix deps.get” para instalar as libs.

Agora, uma vez que o credo está instalado, rodaremos o comando:

mix credo gen.config

Este comando irá gerar um arquivo de configuração do credo que podemos configura-lo para decidirmos o que queremos que ele cheque ou não.

Agora, se visualizarmos dentro do nosso código, veremos que foi criada uma pasta com o nome “.credo.exs":

Para testarmos, vamos rodar o comando mix credo no terminal

Como estamos em um projeto recém criado, ele não irá apresentar nenhuma issues.
Porém, se entrarmos dentro da lib “reports_generator.ex” e apagarmos a doc e rodarmos novamente o comando mix credo, ele irá nos devolver a seguinte mensagem:

3 mods/funs, found 1 code readability issue.

Agora, ele nos diz que os módulos devem ter documentação.
Como não iremos trabalhar com documentação, iremos a pasta credo.exs e adicionar “false” em um dos nossos checks:

{Credo.Check.Readability.ModuleDoc, false},

Outra coisa que podemos fazer é observar que o credo vem como padrão um limite por linhas (nesse caso, 120)
Para obtermos esse resultado no credo, precisamos rodar um comando mais severo do credo:

 mix credo —strict

E o credo irá nos retornar:

Line is too long (max is 120, was 164).

Existe uma extensão no vscode chamada Elixirlint que executa de forma dinâmica e executa os erros de forma ao vivo, sem precisarmos de rodar os checks o tempo todo.

Pra darmos continuidade ao nosso projeto, utilizaremos um arquivo que irá conter todos os CSV`s que iremos precisar.

Vamos alterar o nome da função para def build(filename) que irá receber o nome do arquivo que queremos abrir
Para ler o arquivo, colocamos dentro da nossa função:

File = File.read(“reports/#{filename})”)

Agora, vamos rodar o iex -S mix para tentar abrir um arquivo do nosso projeto

iex(1)> ReportsGenerator.build("report_test.csv") {:ok, "1,pizza,48\r\n2,açaí,45\r\n3,hambúrguer,31\r\n4,esfirra,42\r\n5,hambúrguer,49\r\n6,esfirra,18\r\n7,pizza,27\r\n8,esfirra,25\r\n9,churrasco,24\r\n10,churrasco,36"}

E obtemos um :ok.
Mas como podemos lidar melhor com o erro ao não encontrarmos um arquivo?
Na prática, criamos o “corpo” do case desta maneira:

Nós tentamos dar match em alguma ocasião , ou seja, se tivermos um “ok, result”, devolveremos result.
Mas, se recebermos um “error, reason”, devolveremos um reason (o motivo de error)

Agora, testamos no terminal as duas opções e ele irá nos retornar:

iex(4)> ReportsGenerator.build("report_test.csv") "1,pizza,48\r\n2,açaí,45\r\n3,hambúrguer,31\r\n4,esfirra,42\r\n5,hambúrguer,49\r\n6,esfirra,18\r\n7,pizza,27\r\n8,esfirra,25\r\n9,churrasco,24\r\n10,churrasco,36" iex(5)> ReportsGenerator.build("report_tawdest.csv") :enoent

Uma outra forma, talvez mais elegante e mais aderente ao nosso exemplo quando entendermos o nosso módulo.

Vamos iniciar o conhecimento em Pipe Operator

Vamos dar um exemplo na prática para entendermos o seu funcionamento.
No terminal, vou criar uma String simples:

iex(4)> string = " aaaaaaaaAaaaAa \n" " aaaaaaaaAaaaAa \n"

Agora, queremos gerar uma string sem o “/n” e sem esses “a” maiúsculos.
Uma opção seria passar: String.trim(string)
Assim, ele deletaria todos os espaços e o “/n”.
Só que estamos em uma linguagem imutável, então teríamos que atribuir a nossa string novamente:

String = String.trim(string)

E só assim modificamos a nossa string de fato.
Mas e se eu quiser deixa-la toda minúscula também?
Então teríamos que de fato fazer outra atribuição:

iex(10)> string = " aaaaAaaaaaa \n" " aaaaAaaaaaa \n" iex(11)> String.trim(string) "aaaaAaaaaaa" iex(12)> string = String.trim(string) "aaaaAaaaaaa" iex(13)> string "aaaaAaaaaaa" iex(14)> string = String.downcase(string) "aaaaaaaaaaa"

Pouco legível e muita concatenação. Atrapalharia inclusive a leitura do código por outros desenvolvedores.

E onde o Pipe Operator entra?
Vamos seguir o mesmo exemplo de cima:

iex(16)> " aaaaaaAAAAAAaaaa \n" |> String.trim() |> String.downcase() "aaaaaaaaaaaaaaaa"

Olha como fica legal, mais legível e extende bem menos o código.

O Pipe Operator nada mais faz do que pegar o primeiro o resultado de qualquer operação antes dele e passar pra função seguinte como primeiro argumento, e o resultado da da primeira função ele passaria pra segunda, e assim adiante, e por isso não há nada dentro dos parênteses, pois está vindo como resultado do “|>(pipe).

E como podemos aplicar isso dentro do nosso exemplo lá no projeto?

Vamos lá no código pegar o nome do nosso arquivo “filename” e concatenar com a variável reports:

Estamos pegando essa string: "reports/#{filename}" e passando para a primeira função |>File.read() e o resultado da função file.read eu estou passando para a função |>handle_file

Agora, vamos testar com um arquivo que existe:

iex(2)> ReportsGenerator.build("report_test.csv") "1,pizza,48\r\n2,açaí,45\r\n3,hambúrguer,31\r\n4,esfirra,42\r\n5,hambúrguer,49\r\n6,esfirra,18\r\n7,pizza,27\r\n8,esfirra,25\r\n9,churrasco,24\r\n10,churrasco,36"

E quando tentamos um arquivo não existente, obtemos:

iex(3)> ReportsGenerator.build("report_tesawdt.csv") "Error while opening file!"

Assim, conseguimos trabalhar com Pipe Operator e pattern matching, controlando o fluxo da nossa execução, sem dependermos de if&else ou “complicando” o nosso código.

Voltando ao nosso projeto, dentro temos um arquivo chamado “report_complete.csv” contendo 300 mil linhas.
Será com esse arquivo que iremos inicialmente trabalhar.

Em um cenário real, um arquivo contendo 1 milhão de linhas poderia ser muito pesado de ser carregado completamente na memória.
Então, a primeira coisa que iremos mudar é ao invés de utilizarmos “File.read()” nós iremos usar “File.stream!().

Usaremos um IO.inspect() para debugar no terminal o resultado desta operação. O IO sempre irá imprimir no terminal aquilo que passamos para ele como parâmetro.

Agora, faremos um recompile no terminal e iremos chamar novamente a função ReportsGenerator.build("report_test.csv”), e ele irá nos retornar:

%File.Stream{
line_or_bytes: :line,
modes: [:raw, :read_ahead, :binary],
path: "reports/report_test.csv",
raw: true
}
%File.Stream{
line_or_bytes: :line,
modes: [:raw, :read_ahead, :binary],
path: "reports/report_test.csv",
raw: true
}
`

Assim, ele nos traz uma Struct (nada mais é do que um map com um nome, resumidamente por hora)
O file.stream não traz o conteúdo em si, mas sim metadados

O file.stream possui um “!” no fim pois ele só abre arquivos existentes, não devolvendo tuplas com “error” ou “ok”.

Vamos usar o Enum.each e para cada elemento que tiver nesse arquivo (cada linha), daremos um IO.inspect

|> Enum.each(fn elem -> IO.inspect(elem) end)

E agora vamos chamar o mesmo comando iex(14)> ReportsGenerator.build("report_test.csv”)
E ele irá nos retornar:

`
%File.Stream{
line_or_bytes: :line,
modes: [:raw, :read_ahead, :binary],
path: "reports/report_test.csv",
raw: true
}
"1,pizza,48\n"
"2,açaí,45\n"
"3,hambúrguer,31\n"
"4,esfirra,42\n"
"5,hambúrguer,49\n"
"6,esfirra,18\n"
"7,pizza,27\n"
"8,esfirra,25\n"
"9,churrasco,24\n"
"10,churrasco,36"
:ok

Agora, pra cada linha do arquivo, ele leu e deu inspect.

Agora, faremos um exemplo utilizando Enum.map e para cada linha nós iremos trabalhar essa linha.
Por exemplo: nós iremos separar os elementos para visualizarmos de maneira melhor cada item.

Adicionamos algumas strings e mudamos o nosso enum e quando testamos novamente no terminal, ele nos retorna desta forma:

iex(22)> ReportsGenerator.build("report_test.csv") [ ["1", "pizza", "48"], ["2", "açaí", "45"], ["3", "hambúrguer", "31"], ["4", "esfirra", "42"], ["5", "hambúrguer", "49"], ["6", "esfirra", "18"], ["7", "pizza", "27"], ["8", "esfirra", "25"], ["9", "churrasco", "24"], ["10", "churrasco", "36"] ]

Mas por que utilizamos o &?
Quando criamos uma função anonima, podemos usar o fn com o E comercial e criar uma função de forma implícita.

Prosseguindo com o nosso parseamento do arquivo, podemos ver que ainda não está em um formato muito legal.
Estamos consumindo uma lista de listas basicamente, o que não seria muito legal.
Pra melhorarmos isso podemos utilizar a função reduce, que funciona da seguinte forma:

Enum.reduce([1,2,3,4], 0, fn elem, acc -> acc + elem end)

Nessa função, passamos a coleção de dados que queremos passar, no nosso caso uma lista “1, 2,3.4”, um valor de acumulador inicial, no nosso caso “0”, e uma função anonima “fn”, e essa função anonima sempre como primeiro elemento ela vai receber cada elemento da lista, e como segundo elemento o valor atual do acumulador, no nosso caso “acc"

Quando aplicamos a função dentro do nosso projeto, obtemos como resultado:

iex(4)> ReportsGenerator.build("report_test.csv")
%{
"1" => 48,
"10" => 36,
"2" => 45,
"3" => 31,
"4" => 42,
"5" => 49,
"6" => 18,
"7" => 27,
"8" => 25,
"9" => 24

Agora, ao invés de uma lista de listas, temos um Map onde temos o ID do usuário e quanto ele consumiu, de acordo com o nosso arquivo de teste.

Introdução ao Elixir

Mateus Martins — Mon, 27 Jun 2022 01:37:40 +0000

Strings

Por padrão, uma string em Elixir sempre utilizará aspas duplas.
Por exemplo:

iex(1)> "mateus"
"mateus"

Criando interpolação de strings:

iex(7)> x = "martins"
"martins"
iex(8)> "mateus #{x}"
"mateus martins"

O que são esses /1, /2 que encontramos em algumas funções dentro das documentações?

São chamadas de Aridade da função.
E o que são?

Aridade nada mais é do que quantas argumentos a função recebe.
Por exemplo:

A função length/1 (do modulo String) só recebe um argumento.
E qual argumento é esse?

A string que eu quero saber o cumprimento:

iex(1)> String.length("mateus")
>6

Neste caso, a função length está passando um único argumento, e me retornando o número de letras dentro dessa função.

Como obter as funções do módulo String:

String.

Assim, obtemos todas as funções do módulo String.

E como sabemos o que cada função faz?

Para isso, podemos usar o h(helper) antes de passar as funções:

H String.slice

iex(2)> h String.slice


## Examples

    iex> String.slice("elixir", 1..3)
    "lix"

    iex> String.slice("elixir", 1..10)
    "lixir"

    iex> String.slice("elixir", -4..-1)
    "ixir"

    iex> String.slice("elixir", -4..6)
    "ixir"

For ranges where start > stop, you need to explicit mark them as increasing:

    iex> String.slice("elixir", 2..-1//1)
    "ixir"

    iex> String.slice("elixir", 1..-2//1)
    "lixi"

If values are out of bounds, it returns an empty string:

    iex> String.slice("elixir", 10..3)
    ""

    iex> String.slice("elixir", -10..-7)
    ""

    iex> String.slice("a", 0..1500)
    "a"

    iex> String.slice("a", 1..1500)
    ""


                        def slice(string, start, length)                        

  @spec slice(t(), integer(), non_neg_integer()) :: grapheme()



## Examples

    iex> String.slice("elixir", 1, 3)
    "lix"

    iex> String.slice("elixir", 1, 10)
    "lixir"

    iex> String.slice("elixir", 10, 3)
    ""

    iex> String.slice("elixir", -4, 4)
    "ixir"

Agora na prática:

iex(4)> String.slice("MATEUSMARTINS", 2, 5)
"TEUSM"

Outras formas de realiza-lar essa alteração:

iex(7)> x = "mateus"
"mateus"
iex(8)> String.downcase(x)
"mateus"

Atoms

O que são atoms em Elixir?

São constantes onde o valor da constante é o próprio nome.
Exemplos:

iex(10)> :error
:error
iex(11)> :ok
:ok
iex(12)> :mateus
:mateus

Listas

É possível passar uma lista com vários “tipos” diferentes:

[1, 2, 3, 4.5, “string”]

Exemplos de listas somadas:

iex(14)> [1, 2, 3] ++ [4, 5, 6]
[1, 2, 3, 4, 5, 6]

iex(15)> hd([1,2,3])
1

iex(3)> tl([1,2,3])
[2, 3]

Alguns outros exemplos:

iex(17)> x =  [1, 2, 3] ++ [4]  
[1, 2, 3, 4]

iex(18)> x
[1, 2, 3, 4]

Tuplas

Ao invés de se utilizar colchetes, utilizamos chaves:

iex(4)> {1,2,3}
{1, 2, 3}

Qual a principal diferença entre Tuplas e Listas?

A tupla é armazenada quantiguamente na memória, ou seja, em endereços de memória um após o outro, seguintes.
Por exemplo:

iex(5)> x = {1, 2, 3, 4, 5, 6, 7}
{1, 2, 3, 4, 5, 6, 7}
iex(6)> elem(x, 4)
5

Também podemos armazenar valores diferentes:

iex(7)> put_elem(x, 4, "banana")
{1, 2, 3, 4, "banana", 6, 7}

Geralmente uma tupla tem 2 elementos apenas:

iex(9)> {:ok, "meu arquivo"}
{:ok, "meu arquivo"}

Maps

São utilizados para quando precisamos armazenar chave e valor em uma estrutura de dados por acesso direto por chave.

Como criamos um mapa?

iex(1)> %{a: 1, b: 2, c: 3}
%{a: 1, b: 2, c: 3}

Usando strings:

iex(3)> %{"a" => 1, "b" => 2, "c" => 3}
%{"a" => 1, "b" => 2, "c" => 3}

Qual a diferença na hora de criarmos um map?

Atribuindo dentro de uma variável:

meu_map = %{a: 1, b: 2, c: 3}  
%{a: 1, b: 2, c: 3}

iex(5)> meu_map.a
1

Porém, o mesmo não acontece com Strings.

Maps também podem ter valores mesclados.
Alguns meios de uso:

iex(18)> meu_map                   
%{a: 1, b: 2, c: 3}
iex(19)> Map.put(meu_map, "d", 5.5)
%{:a => 1, :b => 2, :c => 3, "d" => 5.5}

Como podemos alterar um valor dentro de um map?
Neste exemplo criamos um map:

iex(6)> x = %{c: 5, d: 6, e: "sal", f: 5.5}
%{c: 5, d: 6, e: "sal", f: 5.5}

Porém, gostaria de mudar o valor de “D”. Como podemos fazer isso?

Basta passar o map da seguinte maneira:

ex(7)> %{x | d: 10}                       
%{c: 5, d: 10, e: "sal", f: 5.5}

Não é possível adicionar um valor, apenas alterar um já existente.
Um caso bem comum é na criação de usuários:

iex(8)> users = [%{name: "Mateus", age: 22}, %{name: "Lucas", age: 25}]
[%{age: 22, name: "Mateus"}, %{age: 25, name: "Lucas"}]

Pattern Matching

Exemplos de Pattern Matching com mapas:

ex(1)> %{a: 1, b: 2, c: 3, d: 4}
%{a: 1, b: 2, c: 3, d: 4}
iex(2)> %{c: valor} = %{a: 1, b: 2, c: 3, d: 4}
%{a: 1, b: 2, c: 3, d: 4}
iex(3)> valor
3

Exemplos com tuplas:

iex(4)> {:ok, result} =  {:ok, 14}
{:ok, 14}
iex(5)> result
14

Criando uma função anonima: (sintaxe de uma função anonima: fn)

iex(1)> multiply = fn a, b -> a * b end
#Function<43.65746770/2 in :erl_eval.expr/5>

Agora, com a função criada, executamos ela dessa maneira:

iex(2)> multiply.(2,3)
6

Outro exemplo de função anonima:

iex(3)> read_file = fn
...(3)> {:ok, result} -> "Sucess #{result}" 
...(3)> {:error, reason} -> "Error #{reason}" 
...(3)> end
#Function<44.65746770/1 in :erl_eval.expr/5>

Usando a função que foi criada:

iex(4)> read_file.(File.read("test.txt"))
"Error enoent"

*Agora que aprendemos algumas funções básicas, vamos ao nosso primeiro projeto Elixir! *

Para criarmos um projeto em Elixir, basta realizar-mos o seguinte comando dentro do terminal:

mateusmartins@Mateuss-MacBook-Pro ~ % mix new name_project
* creating README.md
* creating .formatter.exs
* creating .gitignore
* creating mix.exs
* creating lib
* creating lib/name_project.ex
* creating test
* creating test/test_helper.exs
* creating test/name_project_test.exs

Com o projeto criado, podemos abri-lo desta maneira no próprio terminal:

cd name_projct/
code .

(No meu caso, usei palace_list)
Com isso, conseguiremos ver a estrutura básica de um projeto.

Algumas dicas do pacote mix:
Mix test = roda os testes da aplicação
Mix compile = compila a aplicação
Mix format = formata o código automaticamente

Pra rodar o iex dentro do seu projeto basta rodar o comando dentro do terminal:

iex -S mix

Quando fazemos isso ele automaticamente compila o nosso código e carrega todo o nosso código no iex.

E como chamamos uma função específica de dentro de um módulo?

Para isso, chamamos o nome do módulo (no meu caso, PalaceList) e o nome da função (por exemplo: hello)
Ficando assim:

iex(2)> PalaceList.hello
:world

Criando nossa primeira função dentro do projeto

Def (pra definir uma função), entre parênteses quais argumentos essa função recebe:

def sum([], acc) do 0 end
Depois criamos uma mesma função para definirmos o head, com o mesmo nome:

def sum([head | tail], acc) do head end

E quando rodamos o recompile e chamamos a função dentro do terminal, obtemos este resultado:

iex(7)> PalaceList.sum([1,2,3], 0)
1

Podemos atribuir o retorno do Match a uma variável:

def sum([head | tail] =list, acc) do list end

iex(10)> PalaceList.sum([1,2,3], 0)
[1, 2, 3]

E agora estamos imprimindo a lista inteira.

iex(8)> PalaceList.sum([1,2,3], 0) 
6
iex(9)> PalaceList.sum([1,2,4], 0)
7

Porém, ainda temos um bug que se eu chamar a lista com o “5” no final, ele retorna 5.

Para consertamos isso, ao invés de executarmos essa função direto, tornaremos essas funções PRIVADAS, ou seja, não permitiremos que o usuário execute elas, elas apenas são funções pra gente utilizar ela dentro do nosso módulo.

Para deixar-mos uma função privada alteramos o def para defp

E agora criaremos uma função chamada “call”, que irá chamar a função do módulo que é somar.

Criamos ela dessa maneira: def call(lista) (aqui ela recebe uma lista qualquer) , do: sum(List, 0) (e ela sempre irá chamar a nossa função privada SUM com a lista que recebemos e o acumulador 0)

Def call(lista), do: sum(list, 0)

Agora, quando executamos no terminal, quando chamamos uma lista vazia obtemos o “0”

iex(12)> PalaceList.call([])   
0

E quando chamamos uma lista obtemos a soma:

iex(13)> PalaceList.call([1,2,3])
6

Testando nossa aplicação

Dentro do nosso projeto, abriremos a pasta “test” e acessaremos o arquivo “palace_list_test.exs”

Dentro do nosso teste, podemos deletar o “doctest PalaceList”, pois ele executa todo o código que temos na documentação e ve se o código executa corretamente.
Como deletemos a documentação, não iremos utilizar o doctest.

Sempre teremos os testes com os nomes “exs”, enquanto os arquivos “comuns” serão “ex”.

Temos dentro do nosso arquivo de test um “use ExUnit.Case”. Mas o que é e para que serve?

Estamos trazendo todas as macros que temos pra usarmos no nosso test, trazendo todas as funcionalidades do ExUnit para dentro do módulo.

Todo test começaremos com “describe” acompanhado do nome da função que queremos testar junto da sua aridade.
Vale lembrar que sempre fazemos de funções PÚBLICAS.

No nosso caso, ficaria assim: describe “call/1” do
End

Usamos a “/“ para dizer qual é a aridade.
Poderíamos ter vários parâmetros, então dessa forma especificamos qual deles estamos testando.

Agora, iremos descrever o nosso test junto de uma descrição:
Test “return the list sum""

Agora, criaremos um setup para o nosso test:
List = [1, 2, 3]

E criaremos uma nova variável que irá armazenar a resposta
Chamaremos o nosso módulo “PalaceList” com a função “Call”
Não precisamos importar o módulo pois já temos acesso dentro do nosso test.

response = PalaceList.call(list)

Agora, criaremos uma resposta esperada:

expect_response = “mateus”

E, para executarmos o nosso test, utilizamos o assert.
O assert irá verificar se um valor é igual ao outro.

Faremos um primeiro test com valores diferentes para ele nos mostrar um erro.

No terminal, fora do iex, rodaremos o comando “mix test”, e ele irá nos retornar a seguinte mensagem de erro:

== Compilation error in file test/palace_list_test.exs ==
** (ExUnit.AssertionError) 

Assertion with == failed
code:  assert response == expect_response
left:  6
right: "mateus"

Tínhamos o valor 6 de um lado, e recebemos “mateus”.

Agora, vamos voltar ao módulo de test e levar o resultado corretamente substituindo o nome pelo valor “6”.

Rodamos o test novamente e obtemos o resultado:

mix test

.

Finished in 0.01 seconds (0.00s async, 0.01s sync)
1 test, 0 failures

Podemos realizar o teste de outra maneira também:

assert PalaceList.call([1, 2, 3]) == 6

Enum

Uma breve introdução ao módulo Enum

Normalmente, trabalhamos com o módulo Enum utilizando Listas, Maps ou Ranges.
Mudamos a nossa função para “def call_enum(list), do: Enum.sum(list)”, e dentro do terminal chamamos ela desta maneira:

iex(3)> PalaceList.call_enum([1, 2, 3, 4])
10

Veja que o próprio Enum já possui uma função para somar todos os elementos.
Também podemos realizar um teste com valores mínimos ou máximos de uma lista, utilizando o próprio enum.
Desta forma, a função ficaria assim:

def call_enum(list), do: Enum.min(list)

E o retorno de uma lista iex(5)> PalaceList.call_enum([1, 2, 3, 4]) seria “1”

Ou podemos transformar em valor máximo:

def call_enum(list), do: Enum.max(list)

E o maior valor da nossa lista seria o “4”.

E outra função muito utilizada é o Map

def call_enum(list), do: Enum.map(list, fn elem -> elem + 1 end)

Assim, criamos uma função dentro do map que irá cada valor dentro dessa lista:

iex(12)> PalaceList.call_enum([1, 2, 3, 4])
[2, 3, 4, 5]

Por hoje é isso pessoal!
Nos vemos no próximo capítulo "Introdução ao Elixir - módulo 2""

O que são API's? (para iniciantes)

Mateus Martins — Thu, 10 Feb 2022 15:27:57 +0000

Por que você precisa se preocupar com API's?

Como desenvolvedor (ou até mesmo empresa), as APIs ajudam você a economizar tempo e facilitam muito o processo de desenvolvimento de software. Isso permite que você crie e libere produtos rapidamente. Se esses benefícios parecem interessantes para você, continue lendo!

O que são APIs?

Antes de entrarmos em qualquer detalhe técnico, vamos dar uma olhada em um exemplo do mundo real para termos um contexto.
No exemplo, veremos uma interação que todos nós já experimentamos um dia, pedindo comida diretamente para algum restaurante ou aplicativo.

Pense sobre esta situação por um momento: como você normalmente pediria comida?

Na sua forma mais simples, você faria um pedido e pegaria sua comida logo depois (espero). Em outras palavras, você faz um pedido e recebe uma resposta (na forma de comida). Esse tipo básico de interação (ou seja, fazer algum tipo de solicitação e obter algum tipo de resposta de volta) se aplica a muitos outros contextos. Mas, por enquanto, vamos nos concentrar no exemplo de pedido de comida.

Vamos visualizar essa interação abaixo:

Então, o que pedir comida tem a ver com API's?

Em sua essência, as API's se comportam da mesma maneira. Pense em uma API como uma maneira de um software solicitar informações de outro software e receber uma resposta de volta. Bem, de que tipo de informação estamos falando? Na maioria das vezes, estamos falando de dados. Quaisquer dados que algum software deseja. Por exemplo: um site pode querer saber o clima em um local específico, ou um aplicativo de mídia social pode querer saber o que as pessoas estão fazendo. Basicamente, quaisquer dados que atendam às suas necessidades de negócios.

Vamos visualizar como uma API se comporta:

Como você pode ver, uma API ajuda você a solicitar e receber dados.

No caso do nosso exemplo do pedido de comida, um cliente faz um pedido, que é então enviado para a cozinha. A cozinha então processa o pedido e envia a comida de volta ao cliente. O cliente não precisa saber como a cozinha faz sua comida, apenas que recebe o pedido solicitado.

As API's funcionam da mesma maneira. Um sistema faz uma solicitação, que é processada pelo receptor. O receptor então envia a resposta de volta ao solicitante. O solicitante não precisa saber como o destinatário processa a solicitação, apenas que recebe a resposta contendo a solicitação que requerida.

Agora que temos uma ideia do que é uma API, o que significa?

API significa Application Programming Interface, ou na sua tradução literária, Interface de Programação de Aplicações.

Se você olhar para essas três palavras, uma delas pode ser menos clara do que as outras. Aposto que "interface" é essa palavra. Então o que isso significa?

Vejamos outro exemplo: se quiser ouvir sons do seu computador, você precisará conectar algum dispositivo de áudio no computador. Mas como você faz isso? Você conectaria os fones de ouvido, por exemplo, a uma entrada USB. A entrada USB, neste exemplo, é uma interface entre seus fones de ouvido e o computador. Essa entrada USB expõe a funcionalidade ao usuário, para que o usuário obtenha o que deseja (som). O usuário não precisa entender como isso funciona, apenas receber o retorno que está buscando (neste caso, o som).

Interfaces em software atuam no mesmo princípio. No contexto de software, uma Interface de Programação de Aplicativo ajuda o software a obter informações de outro software sem precisar saber como ele funciona, apenas que eles obtenham o que desejam.

Você percebe como esse princípio pode ser benéfico? Como seu software apenas solicita e recebe o que está procurando, você economiza tempo reutilizando a funcionalidade que já existe. Não há necessidade de reinventar os dados.
Aqui está um exemplo: por que fazer pão caseiro quando você pode comprá-lo em uma loja? Isso economizaria muito tempo, o que ajuda a enviar seu produto mais rapidamente.

Excelente! Agora que entendemos melhor as APIs, vamos entrar em mais detalhes. Vou voltar ao nosso primeiro exemplo: pedir comida. Como você sabe, existem alguns passos extras que você precisa tomar antes de pedir comida. Não é tão simples como pedir e depois receber comida. Essas etapas podem ser divididas em:

Passo 1: Reconheça que você está com fome e que gostaria de comer alguma coisa.
Passo 2: Vá a um restaurante que sirva o que você procura.
Passo 3: Navegue pelo cardápio.
Passo 4: Decida o que você gostaria de pedir.
Passo 5: Fale com um garçom e faça seu pedido.
Passo 6: Espere um pouco e, eventualmente, seu garçom trará o seu pedido.

Vamos traduzir cada uma dessas etapas no contexto das API's:

Etapa 1: Reconheça que você precisa de dados e gostaria de obtê-los sem precisar construí-los do zero.
Etapa 2: Faça uma pesquisa na Internet para encontrar a API que deseja.
Etapa 3: Navegue pela documentação da API.
Etapa 4: Decida quais dados você precisa e como os solicitaria.
Etapa 5: Interaja com a API e envie sua solicitação.
Etapa 6: Espere um pouco e, eventualmente, sua API trará os seus dados.
Fornecerei mais detalhes sobre cada uma dessas etapas em um artigo futuro, mas por enquanto, o propósito desse artigo é entender o que é uma API. Espero ter ajudado de uma forma mais interessante, com uma leitura simples.

Onde você pode encontrar uma API?

Às vezes, encontrar o prato que você quer pedir pode ser difícil. Por exemplo, se você quiser comer macarrão, pode visitar o restaurante que visitou anteriormente ou procurar online um novo restaurante com boas críticas. Outras vezes, você pode nem saber o que quer comer.

Essa ideia também se aplica às API's. Se você quiser usar uma API, você pode usar uma com a qual esteja familiarizado ou fazer uma pesquisa no Google para encontrar o que está procurando. Mas isso pode ser difícil porque existem muitas API's por aí. E muitas vezes, pode ser difícil encontrar a API certa de que você precisa. Às vezes, você pode querer navegar pelas API's por categorias e ver o que há por aí.

Bem, e se você quisesse tornar as coisas mais fáceis? Você pode ir a um buffet, pois sabe que eles têm todos os tipos de comida. E se você pudesse visitar um mercado agregado para todos os tipos de API's? Não seria muito mais fácil?

Felizmente, existe um produto que faz exatamente isso! RapidAP é um mercado/agregado de API's, para ajudar a encontrar a API certa para suas necessidades. Você pode pensar nisso como um buffet de API's porque tem tudo o que você pode precisar.

Quer aprender mais?

Esta foi apenas uma introdução para ajudar os iniciantes a entender as API's e por que elas são importantes. Em um artigo futuro, entrarei em mais detalhes. Vou explicar como você pode encontrar a API certa para suas necessidades e como usá-las (com trechos de código). Espero que isso tenha ajudado você!

Até mais!

Quer aprender sobre git e GitHub de uma forma mais divertida?

Mateus Martins — Fri, 04 Feb 2022 17:34:48 +0000

Nós sempre assistimos a muitos vídeos e tutoriais e passamos por muita documentação para aprender algum conceito ou qualquer linguagem de programação.

Mas você sabia que é possível aprender git e GitHub de uma maneira mais divertida, como jogar ou visualizar?
SIM! você ouviu direito, jogando!

Aqui estão alguns dos recursos para aprender git e GitHub de uma maneira mais divertida.

1) TwilioQuest - "Floresta de código aberto":

Este é um jogo feito por Twilio , você aprenderá sobre git e GitHub enquanto joga e faz tarefas. Além disso, você ganhará XP após cada tarefa que concluir.

Link

2) E não para por ai!:

Ele permite que você visualize as estruturas internas dos repositórios Git em tempo real.
Link

3) Aprenda a ramificação do Git:

Você pode dominar seu conceito de ramificação do git visualizando, jogando e fazendo certas tarefas.

Link

4) Laboratório de aprendizagem do GitHub:

O próprio GitHub fornece uma trilha de aprendizado, que aumenta suas habilidades ao concluir projetos divertidos e realistas.
Link

Obrigado!

Qualquer dúvida ou sugestão você pode entrar em contato comigo através do Instagram

Bye!