Forem: Diego Novais

O que eu gostaria de ter aprendido sobre rotas no Rails lá no início

Diego Novais — Sat, 22 Mar 2025 18:40:49 +0000

Introdução

As rotas no Rails são responsáveis por direcionar requisições HTTP para os controladores e suas respectivas ações. Elas são definidas no arquivo config/routes.rb e seguem uma estrutura declarativa que facilita a organização e manutenção do código. Este mini guia apresenta os principais conceitos sobre rotas no Rails, de forma clara e objetiva.

O Básico das Rotas

Definição de Rota Simples

As rotas básicas no Rails podem ser definidas de maneira direta. Por exemplo:

Rails.application.routes.draw do
  get 'home/index'
end

Essa rota faz com que uma requisição GET para /home/index seja direcionada para o HomeController, ação index.

Rotas RESTful

O Rails adota o padrão REST, permitindo a criação de rotas com um único comando:

resources :posts

Isso gera automaticamente as sete rotas principais para um recurso posts:

GET /posts → Lista todos os posts (index)
GET /posts/:id → Mostra um post específico (show)
GET /posts/new → Exibe o formulário de criação (new)
POST /posts → Cria um novo post (create)
GET /posts/:id/edit → Exibe o formulário de edição (edit)
PATCH/PUT /posts/:id → Atualiza um post (update)
DELETE /posts/:id → Exclui um post (destroy)

Definindo um Recurso Manualmente (Sem `resources`)

Nem sempre usamos o helper resources. Podemos definir manualmente as rotas para um recurso completo, como countries, caso queiramos mais controle ou aprendizado.

get    '/countries',          to: 'countries#index',   as: 'countries'
get    '/countries/new',      to: 'countries#new',     as: 'new_country'
post   '/countries',          to: 'countries#create'
get    '/countries/:id',      to: 'countries#show',    as: 'country'
get    '/countries/:id/edit', to: 'countries#edit',    as: 'edit_country'
patch  '/countries/:id',      to: 'countries#update'
put    '/countries/:id',      to: 'countries#update'
delete '/countries/:id',      to: 'countries#destroy'

Explicação

GET /countries → Lista todos os países (index)
GET /countries/new → Formulário de novo país (new)
POST /countries → Cria um novo país (create)
GET /countries/:id → Exibe detalhes de um país (show)
GET /countries/:id/edit → Formulário de edição (edit)
PATCH/PUT /countries/:id → Atualiza o país (update)
DELETE /countries/:id → Remove o país (destroy)

Vantagens e Uso

Essa abordagem é útil quando:

Você quer personalizar cada rota com mais liberdade
Deseja evitar geração automática de rotas não utilizadas
Precisa de nomes específicos para as rotas

Além disso, os helpers de caminho continuam disponíveis:

countries_path
new_country_path
country_path(@country)
edit_country_path(@country)

Rotas Aninhadas

Quando há um relacionamento entre recursos, podemos usar rotas aninhadas para estruturar as URLs:

resources :countries do
  resources :states do
    resources :cities
  end
end

Isso gera caminhos como:

/countries/:country_id/states/:state_id/cities/:id

Interpretando Paths em Rotas Profundas

Entender como interpretar paths em rotas aninhadas é essencial para evitar erros e construir URLs corretamente. Vamos analisar um exemplo:

Estrutura de Rotas

resources :universities do
  resources :departments do
    resources :professors do
      member do
        get 'profile' # /universities/:university_id/departments/:department_id/professors/:id/profile
      end
    end
  end
end

Como Ler e Construir Helpers de Caminho

Dado o exemplo acima, podemos identificar como construir corretamente as URLs.

Para listar todos os departamentos de uma universidade:

  university_departments_path(@university)
  # => '/universities/:university_id/departments'

Para acessar um departamento específico:

  university_department_path(@university, @department)
  # => '/universities/:university_id/departments/:id'

Para acessar os professores de um departamento específico:

  department_professors_path(@university, @department)
  # => '/universities/:university_id/departments/:department_id/professors'

Para acessar o perfil de um professor:

  profile_professor_path(@university, @department, @professor) 
  # => '/universities/:university_id/departments/:department_id/professors/:id/profile'

Dicas para Interpretação de Paths

A ordem dos argumentos importa: Sempre forneça os IDs dos recursos pais antes dos filhos.
Use rake routes: Esse comando exibe todas as rotas disponíveis e seus respectivos helpers.
Analise a hierarquia: Cada recurso dentro de outro exige os IDs dos níveis superiores.
Verifique o nome dos helpers: Rails gera nomes padronizados baseados na estrutura definida em routes.rb.

Buscando Rotas Específicas

Ao trabalhar com um grande número de rotas, pode ser desafiador encontrar uma específica. O Rails fornece algumas ferramentas para facilitar essa busca.

Usando `rake routes | grep`

Podemos filtrar rotas usando grep para encontrar apenas as que nos interessam:

rake routes | grep users

Isso retorna apenas as rotas que contêm users no nome ou caminho.

Usando `rails routes -g`

Uma alternativa mais eficiente no Rails 5+ é o comando:

rails routes -g users

Ele tem a mesma função do grep, mas de forma mais otimizada, sem a necessidade de encadear comandos.

Nomeação e Redirecionamento

Nomeando Rotas

Nomear rotas facilita seu uso no código:

get 'about', to: 'pages#about', as: 'about_page'

Agora podemos chamar about_page_path em vez de escrever manualmente '/about'.

Redirecionamento de Rotas

Podemos redirecionar URLs antigas para novas:

get '/old_route', to: redirect('/new_route')

Conclusão

As rotas são fundamentais para qualquer aplicação Rails, permitindo estruturar URLs de forma eficiente e organizada. O uso de helpers de caminho simplifica a navegação, enquanto rotas nomeadas e personalizadas tornam o código mais legível e fácil de manter. Além disso, aprender a interpretar paths e buscar rotas específicas com rails routes -g ou grep facilita a manutenção e depuração da aplicação. Com esse conhecimento, você pode criar aplicações escaláveis e bem estruturadas!

How to Ignore Files in Git Without Using .gitignore

Diego Novais — Fri, 20 Sep 2024 05:28:20 +0000

EN

Sometimes you need to ignore files or folders in your project, but you don't want to add these rules to the shared .gitignore file. Git offers an elegant solution for this: the .git/info/exclude file. Let's explore how to use this functionality.

What is the .git/info/exclude file?

The .git/info/exclude file works similarly to .gitignore, but it's specific to your local repository. The rules defined in it are not shared with other collaborators when you push your code.

Step-by-step guide to using .git/info/exclude

Locate the file
Navigate to the root folder of your Git repository and look for the hidden .git folder.
Create or edit the file
Inside the .git folder, go to the info folder. If a file named exclude doesn't exist, create it. Otherwise, open it for editing.
Add the rules
The exclusion rules follow the same format as .gitignore. For example:

   # Ignore a specific folder
   my_folder/

   # Ignore a file type
   *.log

   # Ignore a specific file
   config.local

Save the file
After adding your rules, save and close the file.
Verify it's working
Use the git status command to confirm that the files/folders you want to ignore are not being tracked.

Advantages of using .git/info/exclude

Privacy: The rules are applied only locally.
Doesn't affect other collaborators: Your personal exclusions don't interfere with the team's work.
Ideal for specific configurations: Perfect for local configuration files or temporary files in your development environment.

Important considerations

Use relative paths for greater portability.
Remember that files already tracked by Git won't be automatically ignored. You'll need to remove them from tracking first.
If you need to share exclusion rules with the team, .gitignore is still the best option.

Conclusion

The .git/info/exclude file is a powerful tool for managing local exclusions in your Git repository. It offers flexibility to ignore files and folders without affecting the shared .gitignore, making it ideal for configurations specific to your development environment.

By mastering this technique, you'll have more control over what is versioned in your local repository, keeping your workspace organized and avoiding accidental commits of unnecessary files.

I hope that this content helps and makes sense to you! See ya!

Contacts:
Email: contato@diegonovais.com.br
LinkedIn: https://www.linkedin.com/in/diegonovais/
Github: https://github.com/dnovais

PTBR:

Como ignorar arquivos no Git sem usar o .gitignore

Às vezes, você precisa ignorar arquivos ou pastas em seu projeto, mas não quer adicionar essas regras ao arquivo .gitignore compartilhado. O Git oferece uma solução elegante para isso: o arquivo .git/info/exclude. Vamos explorar como usar essa funcionalidade.

O que é o arquivo .git/info/exclude?

O arquivo .git/info/exclude funciona de maneira similar ao .gitignore, mas é específico para o seu repositório local. As regras definidas nele não são compartilhadas com outros colaboradores quando você faz push do seu código.

Passo a passo para usar o .git/info/exclude

Localize o arquivo
Navegue até a pasta raiz do seu repositório Git e procure a pasta oculta .git.
Crie ou edite o arquivo
Dentro da pasta .git, vá para a pasta info. Se não existir um arquivo chamado exclude, crie-o. Caso contrário, abra-o para edição.
Adicione as regras
As regras de exclusão seguem o mesmo formato do .gitignore. Por exemplo:

   # Ignorar uma pasta específica
   minha_pasta/

   # Ignorar um tipo de arquivo
   *.log

   # Ignorar um arquivo específico
   config.local

Salve o arquivo
Após adicionar suas regras, salve e feche o arquivo.
Verifique se está funcionando
Use o comando git status para confirmar se os arquivos/pastas que você quer ignorar não estão sendo rastreados.

Vantagens de usar .git/info/exclude

Privacidade: As regras são aplicadas apenas localmente.
Não afeta outros colaboradores: Suas exclusões pessoais não interferem no trabalho da equipe.
Ideal para configurações específicas: Perfeito para arquivos de configuração local ou arquivos temporários do seu ambiente de desenvolvimento.

Considerações importantes

Use caminhos relativos para maior portabilidade.
Lembre-se que arquivos já rastreados pelo Git não serão ignorados automaticamente. Você precisará removê-los do rastreamento primeiro.
Se você precisar compartilhar regras de exclusão com a equipe, o .gitignore ainda é a melhor opção.

Conclusão

O arquivo .git/info/exclude é uma ferramenta poderosa para gerenciar exclusões locais em seu repositório Git. Ele oferece flexibilidade para ignorar arquivos e pastas sem afetar o .gitignore compartilhado, tornando-o ideal para configurações específicas do seu ambiente de desenvolvimento.

Ao dominar esta técnica, você terá mais controle sobre o que é versionado em seu repositório local, mantendo seu espaço de trabalho organizado e evitando commits acidentais de arquivos desnecessários.

Espero que este conteúdo ajude e faça sentido para você! Até mais!

Contato:
Email: contato@diegonovais.com.br
LinkedIn: https://www.linkedin.com/in/diegonovais/
Github: https://github.com/dnovais

Simplify Your Rails Route Filtering with This Quick Tip

Diego Novais — Tue, 03 Sep 2024 18:49:34 +0000

EN:

TIL: Quick tip for Rails users!

Instead of using rails routes | grep articles to filter routes, try using:

bin/rails routes -g articles

This makes searching for routes simpler and more straightforward, without the need for grep.

PT/BR:

TIL: Dica rápida para quem usa Rails!

Em vez de usar rails routes | grep articles para filtrar rotas, experimente usar:

bin/rails routes -g articles

Isso torna a busca por rotas mais simples e direta, sem precisar do grep.

4 Stages Of Problem Solving

Diego Novais — Fri, 10 Mar 2023 01:17:10 +0000

As software developers, we are faced with an array of tasks and problems that require our attention and expertise on a daily basis. To address these challenges, based on my studies, I rely on a problem-solving strategy that consists of four stages.

1 - Analyze

The first stage involves understanding the available resources and constraints of the problem. By assessing the resources at our disposal and identifying any limitations, we can gain a clear understanding of what is required to solve the problem effectively.

2 - Plan

The second stage is to write a program that outlines the steps needed to solve the problem. This plan of action serves as a roadmap that guides us toward a successful resolution.

3 - Implement

The third stage is to execute the program to obtain the desired results. By doing so, we can confirm that our solution is indeed effective and meets the requirements of the problem.

4 - Evaluate

Lastly, we match the results of the program with the desired output to determine if the problem has been successfully solved. This allows us to verify that our solution is accurate and meets the expectations of the stakeholders involved.

By following this four-stage problem-solving strategy, software developers can approach problems in a structured and systematic manner, leading to more efficient and effective solutions.

This four-stage problem-solving strategy is not only effective in the context of software development but can also be applied to various real-life situations. By breaking down complex problems into smaller, more manageable steps and following a structured approach, we can approach challenges with greater confidence and achieve successful outcomes.

Refactoring the Game

Diego Novais — Thu, 01 Sep 2022 05:15:49 +0000

Our game is almost finished (at least part of it). But we can improve the module game and do it together.

Let's start...

I found modular arithmetic, looking for something with a mathematical approach to solving the logic of our game (if you are interested in the subject, take a look here).

Now we'll use modular arithmetic to add a few math to our code. And make the code brighter and cleaner.

The mathematical approach

The mod function provides the remainder when one integer is divided by another. And it will help us to a cyclical relationship between the three choices: Rock, Paper, and Scissors.

r = a mod b
r is the remainder when a is divided by b

So, looking into our code, more specifically on module attributes:

  @stone 1
  @paper 2
  @scissor 3

I saw a tip that can help us to make calculus more efficiently:

(first_player_choice - second_player_choice) % 3

Refactoring the Game

Adding the function to calculate the result of the game game_calc:

defmodule Game do
  @moduledoc """
  Documentation for `Game`.
  """

  @stone 1
  @paper 2
  @scissor 3

  def play(first_player_choice, second_player_choice) do
    result(first_player_choice, second_player_choice)
  end

  defp result(first_player_choice, second_player_choice) do
    cond do
      first_player_choice == second_player_choice ->
        {:ok, "Draw!"}

      first_player_choice == @scissor && second_player_choice == @paper ->
        {:ok, "First player win!!!"}

      first_player_choice == @paper && second_player_choice == @stone ->
        {:ok, "First player win!!!"}

      first_player_choice == @stone && second_player_choice == @scissor ->
        {:ok, "First player win!!!"}

      first_player_choice == @paper && second_player_choice == @scissor ->
        {:ok, "Second player win!!!"}

      first_player_choice == @stone && second_player_choice == @paper ->
        {:ok, "Second player win!!!"}

      first_player_choice == @scissor && second_player_choice == @stone ->
        {:ok, "Second player win!!!"}
    end
  end

  defp game_calc(first_player_item, second_player_item) do
    rem(first_player_item - second_player_item, 3)
  end
end

And then now, we can simplify the function result:

defmodule Game do
  @moduledoc """
  Documentation for `Game`.
  """

  @stone 1
  @paper 2
  @scissor 3

  def play(first_player_choice, second_player_choice) do
    result(first_player_choice, second_player_choice)
  end

  defp result(first_player_choice, second_player_choice) do
    game_calc_result = game_calc(first_player_choice, second_player_choice)

    case game_calc_result do
      0 -> {:ok, "Draw!"}
      1 -> {:ok, "First player win!!!"}
      _ -> {:ok, "Second player win!!!"}
    end
  end

  defp game_calc(first_player_item, second_player_item) do
    rem(first_player_item - second_player_item, 3)
  end
end

Running the tests:

mix test

Something is wrong. We got three warnings and one failure message when we ran the tests.

Compiling 1 file (.ex)
warning: module attribute @scissor was set but never used
  lib/game.ex:8

warning: module attribute @paper was set but never used
  lib/game.ex:7

warning: module attribute @stone was set but never used
  lib/game.ex:6

..

  1) test Game.play/2 when first player wins when first player chooses stone and second player chooses scissors (GameTest)
     test/game_test.exs:55
     Assertion with == failed
     code:  assert match == "First player win!!!"
     left:  "Second player win!!!"
     right: "First player win!!!"
     stacktrace:
       test/game_test.exs:61: (test)

......

Finished in 0.05 seconds (0.00s async, 0.05s sync)
9 tests, 1 failure

Randomized with seed 811857

To solve the warning messages, we need to remove the module attributes:

defmodule Game do
  @moduledoc """
  Documentation for `Game`.
  """

  def play(first_player_choice, second_player_choice) do
    result(first_player_choice, second_player_choice)
  end

  defp result(first_player_choice, second_player_choice) do
    game_calc_result = game_calc(first_player_choice, second_player_choice)

    case game_calc_result do
      0 -> {:ok, "Draw!"}
      1 -> {:ok, "First player win!!!"}
      _ -> {:ok, "Second player win!!!"}
    end
  end

  defp game_calc(first_player_item, second_player_item) do
    rem(first_player_item - second_player_item, 3)
  end
end

And now, if we rerun the tests:

mix test

We'll see only the tests failure:

Compiling 1 file (.ex)
....

  1) test Game.play/2 when first player wins when first player chooses stone and second player chooses scissors (GameTest)
     test/game_test.exs:55
     Assertion with == failed
     code:  assert match == "First player win!!!"
     left:  "Second player win!!!"
     right: "First player win!!!"
     stacktrace:
       test/game_test.exs:61: (test)

....

Finished in 0.04 seconds (0.00s async, 0.04s sync)
9 tests, 1 failure

Randomized with seed 730068

Understanding the failure message

The failure is because we pass to kernel function rem/2 a dividend negative in our formula. And according to the documentation, this kernel function uses truncated division, which means that the result will always have the sign of the dividend.

When first player wins when first player chooses stone and second player chooses scissors, the result is -2:

# stone = 1
# paper = 2
# scissor = 3

# R = (first_player_choice - second_player_choice) % 3
# R = (stone - scissors) % 3
# R = (1 - 3) % 3

# In elixir using rem/2

rem(1-3, 3)
> -2

Solving the failure message

According to the documentation, the function Integer.mod/2 Computes the modulo remainder of an integer division.

It's important to know: Integer.mod/2 uses floored division, which means that the result will always have the sign of the divisor.

So, when first player wins when first player chooses stone and second player chooses scissors, the result is 1:

# stone = 1
# paper = 2
# scissor = 3

# R = (first_player_choice - second_player_choice) % 3
# R = (stone - scissors) % 3
# R = (1 - 3) % 3

# In elixir using rem/2

Integer.mod(1-3, 3)
> 1

So, To solve the failure message, we need to remove the rem/2 function and add the Integer.mod/2:

defmodule Game do
  @moduledoc """
  Documentation for `Game`.
  """

  def play(first_player_choice, second_player_choice) do
    result(first_player_choice, second_player_choice)
  end

  defp result(first_player_choice, second_player_choice) do
    game_calc_result = game_calc(first_player_choice, second_player_choice)

    case game_calc_result do
      0 -> {:ok, "Draw!"}
      1 -> {:ok, "First player win!!!"}
      _ -> {:ok, "Second player win!!!"}
    end
  end

  defp game_calc(first_player_item, second_player_item) do
    Integer.mod(first_player_item - second_player_item, 3)
  end
end

And now, finally, if we rerun the tests:

mix test

All the tests pass with success \o/:

Compiling 1 file (.ex)
.........

Finished in 0.04 seconds (0.00s async, 0.04s sync)
9 tests, 0 failures

Randomized with seed 992719

It's time to celebrate, the game Rock, Paper, and Scissors is "done"!

Repository of the project: https://github.com/dnovais/rock_paper_scissor_elixir

See you soon!

Contacts

Email: contato@diegonovais.com.br
Linkedin: https://www.linkedin.com/in/diegonovais/
Twitter: https://twitter.com/diegonovaistech

Sources and references

Second player wins! Building the code and make the tests pass

Diego Novais — Wed, 31 Aug 2022 18:59:07 +0000

Now, according to our tests, we'll add the condition that guarantees that the second player is the winner.

Our Game module looks like this:

# lib/game.ex

defmodule Game do
  @moduledoc """
  Documentation for `Game`.
  """
  @stone 1
  @paper 2
  @scissor 3

  def play(first_player_choice, second_player_choice) do
    result(first_player_choice, second_player_choice)
  end

  defp result(first_player_choice, second_player_choice) do
    cond do
      first_player_choice == second_player_choice ->
        {:ok, "Draw!"}

      first_player_choice == @scissor && second_player_choice == @paper ->
        {:ok, "First player win!!!"}

      first_player_choice == @paper && second_player_choice == @stone ->
        {:ok, "First player win!!!"}

      first_player_choice == @stone && second_player_choice == @scissor ->
        {:ok, "First player win!!!"}
    end
  end
end

If we run the tests now:

mix test

We'll see the tests failures:

..

  1) test Game.play/2 when second player wins when second player chooses stone and first player chooses scissors (GameTest)
     test/game_test.exs:85
     ** (CondClauseError) no cond clause evaluated to a truthy value
     code: assert {:ok, match} = Game.play(first_player_choice, second_player_choise)
     stacktrace:
       (rock_paper_scissor_elixir 0.1.0) lib/game.ex:24: Game.result/2
       test/game_test.exs:89: (test)



  2) test Game.play/2 when second player wins when second player chooses scissors and first player chooses paper (GameTest)
     test/game_test.exs:67
     ** (CondClauseError) no cond clause evaluated to a truthy value
     code: assert {:ok, match} = Game.play(first_player_choice, second_player_choise)
     stacktrace:
       (rock_paper_scissor_elixir 0.1.0) lib/game.ex:24: Game.result/2
       test/game_test.exs:71: (test)

...

  3) test Game.play/2 when second player wins when second player chooses paper and first player chooses stone (GameTest)
     test/game_test.exs:76
     ** (CondClauseError) no cond clause evaluated to a truthy value
     code: assert {:ok, match} = Game.play(first_player_choice, second_player_choise)
     stacktrace:
       (rock_paper_scissor_elixir 0.1.0) lib/game.ex:24: Game.result/2
       test/game_test.exs:80: (test)

.

Finished in 0.05 seconds (0.00s async, 0.05s sync)
9 tests, 3 failures

Randomized with seed 710365

When the first player chooses paper and the second player chooses scissors

We'll add the condition when the first player chooses paper and the second player chooses scissors:

# lib/game.ex

defmodule Game do
  @moduledoc """
  Documentation for `Game`.
  """

  def play(first_player_choice, second_player_choice) do
    result(first_player_choice, second_player_choice)
  end

  defp result(first_player_choice, second_player_choice) do
    cond do
      # ...

      first_player_choice == @paper && second_player_choice == @scissor ->
        {:ok, "Second player win!!!"}
    end
  end
end

And now, if we rerun the tests:

mix test

The test with the actual scenario passed ok. And now we have just two tests with failure.

Compiling 1 file (.ex)
.

  1) test Game.play/2 when second player wins when second player chooses stone and first player chooses scissors (GameTest)
     test/game_test.exs:85
     ** (CondClauseError) no cond clause evaluated to a truthy value
     code: assert {:ok, match} = Game.play(first_player_choice, second_player_choise)
     stacktrace:
       (rock_paper_scissor_elixir 0.1.0) lib/game.ex:27: Game.result/2
       test/game_test.exs:89: (test)

.....

  2) test Game.play/2 when second player wins when second player chooses paper and first player chooses stone (GameTest)
     test/game_test.exs:76
     ** (CondClauseError) no cond clause evaluated to a truthy value
     code: assert {:ok, match} = Game.play(first_player_choice, second_player_choise)
     stacktrace:
       (rock_paper_scissor_elixir 0.1.0) lib/game.ex:27: Game.result/2
       test/game_test.exs:80: (test)

.

Finished in 0.04 seconds (0.00s async, 0.04s sync)
9 tests, 2 failures

Randomized with seed 862104

When the first player chooses stone and the second player chooses paper

We'll add the condition when the first player chooses stone and the second player chooses paper:

# lib/game.ex

defmodule Game do
  @moduledoc """
  Documentation for `Game`.
  """

  def play(first_player_choice, second_player_choice) do
    result(first_player_choice, second_player_choice)
  end

  defp result(first_player_choice, second_player_choice) do
    cond do
      # ...

      first_player_choice == @paper && second_player_choice == @scissor ->
        {:ok, "Second player win!!!"}

      first_player_choice == @stone && second_player_choice == @paper ->
        {:ok, "Second player win!!!"}
    end
  end
end

And now, if we rerun the tests:

mix test

The test with the actual scenario passed ok. And now we have just one tests with failure.

Compiling 1 file (.ex)


  1) test Game.play/2 when second player wins when second player chooses stone and first player chooses scissors (GameTest)
     test/game_test.exs:85
     ** (CondClauseError) no cond clause evaluated to a truthy value
     code: assert {:ok, match} = Game.play(first_player_choice, second_player_choise)
     stacktrace:
       (rock_paper_scissor_elixir 0.1.0) lib/game.ex:30: Game.result/2
       test/game_test.exs:89: (test)

........

Finished in 0.04 seconds (0.00s async, 0.04s sync)
9 tests, 1 failure

Randomized with seed 980583

When first player chooses scissors and the the second player chooses stone

We'll add the condition when the first player chooses scissors and the second player chooses stone:

# lib/game.ex

defmodule Game do
  @moduledoc """
  Documentation for `Game`.
  """

  def play(first_player_choice, second_player_choice) do
    result(first_player_choice, second_player_choice)
  end

  defp result(first_player_choice, second_player_choice) do
    cond do
      # ...

      first_player_choice == @paper && second_player_choice == @scissor ->
        {:ok, "Second player win!!!"}

      first_player_choice == @stone && second_player_choice == @paper ->
        {:ok, "Second player win!!!"}

      first_player_choice == @scissor && second_player_choice == @stone ->
        {:ok, "Second player win!!!"}
    end
  end
end

And now, if we rerun the tests:

mix test

All the tests pass with success.

Compiling 1 file (.ex)
......

Finished in 0.03 seconds (0.00s async, 0.03s sync)
6 tests, 0 failures

Randomized with seed 795123

In the next post (soon), we'll refactor and improve our module Game.

Contacts

Email: contato@diegonovais.com.br
Linkedin: https://www.linkedin.com/in/diegonovais/
Twitter: https://twitter.com/diegonovaistech

Building the tests when the second player wins

Diego Novais — Wed, 31 Aug 2022 15:34:56 +0000

The second player wins when his item chosen is the most powerful.

When the second player chooses scissors and the first player chooses the paper:

defmodule GameTest do
  use ExUnit.Case

  @stone 1
  @paper 2
  @scissor 3

  # ...

  describe "Game.play/2 when second player wins" do
    test "when second player chooses scissor and first player chooses paper" do
      first_player_choice = @paper
      second_player_choise = @scissor

      assert {:ok, match} = Game.play(first_player_choice, second_player_choise)

      assert match == "Second player win!!!"
    end
  end
end

When the second player chooses paper and the first player chooses the stone:

defmodule GameTest do
  use ExUnit.Case

  @stone 1
  @paper 2
  @scissor 3

  # ...

  describe "Game.play/2 when second player wins" do

    #...

    test "when second player chooses paper and first player chooses stone" do
      first_player_choice = @stone
      second_player_choise = @paper

      assert {:ok, match} = Game.play(first_player_choice, second_player_choise)

      assert match == "Second player win!!!"
    end
  end
end

When the second player chooses stone and the first player chooses the scissor:

defmodule GameTest do
  use ExUnit.Case

  @stone 1
  @paper 2
  @scissor 3

  # ...

  describe "Game.play/2 when second player wins" do

    #...

    test "when second player chooses stone and first player chooses scissor" do
      first_player_choice = @scissor
      second_player_choise = @stone

      assert {:ok, match} = Game.play(first_player_choice, second_player_choise)

      assert match == "Second player win!!!"
    end
  end
end

Let's look at the code of the tests when the game's result is "Second player win!!!".

defmodule GameTest do
  use ExUnit.Case

  @stone 1
  @paper 2
  @scissor 3

# ...

  describe "Game.play/2 when second player wins" do
    test "when second player chooses scissors and first player chooses paper" do
      first_player_choice = @paper
      second_player_choise = @scissor

      assert {:ok, match} = Game.play(first_player_choice, second_player_choise)

      assert match == "Second player win!!!"
    end

    test "when second player chooses paper and first player chooses stone" do
      first_player_choice = @stone
      second_player_choise = @paper

      assert {:ok, match} = Game.play(first_player_choice, second_player_choise)

      assert match == "Second player win!!!"
    end

    test "when second player chooses stone and first player chooses scissors" do
      first_player_choice = @scissor
      second_player_choise = @stone

      assert {:ok, match} = Game.play(first_player_choice, second_player_choise)

      assert match == "Second player win!!!"
    end
  end
end

In the next post (soon), we'll code our module Game following the tests when the Second Player wins.

Contacts

Email: contato@diegonovais.com.br
Linkedin: https://www.linkedin.com/in/diegonovais/
Twitter: https://twitter.com/diegonovaistech

First player wins! Building the code and make the tests pass

Diego Novais — Wed, 31 Aug 2022 15:29:09 +0000

Now we'll continue to code our module Game following the tests. But this time, covering the scenario when the first player wins.

Our Game module looks like this:

# lib/game.ex

defmodule Game do
defmodule Game do
  @moduledoc """
  Documentation for `Game`.
  """

  def play(first_player_choice, second_player_choice) do
    result(first_player_choice, second_player_choice)
  end

  defp result(first_player_choice, second_player_choice) do
    cond do
      first_player_choice == second_player_choice -> {:ok, "Draw!"}
    end
  end
end

end

With our tests done, if we run the tests now:

mix test

We'll see the tests failures:

  1) test Game.play/2 when first player wins when first player chooses scissors and second player chooses paper (GameTest)
     test/game_test.exs:38
     ** (CondClauseError) no cond clause evaluated to a truthy value
     code: assert {:ok, match} = Game.play(first_player_choice, second_player_choise)
     stacktrace:
       (rock_paper_scissor_elixir 0.1.0) lib/game.ex:12: Game.result/2
       test/game_test.exs:42: (test)


  2) test Game.play/2 when first player wins when first player chooses stone and second player chooses scissors (GameTest)
     test/game_test.exs:56
     ** (CondClauseError) no cond clause evaluated to a truthy value
     code: assert {:ok, match} = Game.play(first_player_choice, second_player_choise)
     stacktrace:
       (rock_paper_scissor_elixir 0.1.0) lib/game.ex:12: Game.result/2
       test/game_test.exs:60: (test)


  3) test Game.play/2 when first player wins when first player chooses paper and second player chooses stone (GameTest)
     test/game_test.exs:47
     ** (CondClauseError) no cond clause evaluated to a truthy value
     code: assert {:ok, match} = Game.play(first_player_choice, second_player_choise)
     stacktrace:
       (rock_paper_scissor_elixir 0.1.0) lib/game.ex:12: Game.result/2
       test/game_test.exs:51: (test)

..

Finished in 0.03 seconds (0.00s async, 0.03s sync)
6 tests, 3 failures

Let's make those tests pass

Now, we need to create some module attributes for stone, paper, and scissors:

defmodule Game do
  @moduledoc """
  Documentation for `Game`.
  """

  @stone 1
  @paper 2
  @scissor 3

# ...
end

And then, we'll add the condition that guarantees that the first player is the winner according to our tests.

When the first player chooses scissors and the second player chooses paper

We'll add the condition when the first player chooses scissors and the second player chooses paper:

defmodule Game do
  @moduledoc """
  Documentation for `Game`.
  """

  def play(first_player_choice, second_player_choice) do
    result(first_player_choice, second_player_choice)
  end

  defp result(first_player_choice, second_player_choice) do
    cond do
      first_player_choice == second_player_choice ->
        {:ok, "Draw!"}

      first_player_choice == @scissor && second_player_choice == @paper ->
        {:ok, "First player win!!!"}
    end
  end
end

And now, if we rerun the tests:

mix test

The test with the actual scenario passed ok. And now we have just two tests with failure.

Ps.: We have one warning message about the module attributes @stone that was set but never used.

Compiling 1 file (.ex)
warning: module attribute @stone was set but never used
  lib/game.ex:5

...

  1) test Game.play/2 when first player wins when first player chooses stone and second player chooses scissors (GameTest)
     test/game_test.exs:56
     ** (CondClauseError) no cond clause evaluated to a truthy value
     code: assert {:ok, match} = Game.play(first_player_choice, second_player_choise)
     stacktrace:
       (rock_paper_scissor_elixir 0.1.0) lib/game.ex:18: Game.result/2
       test/game_test.exs:60: (test)

.

  2) test Game.play/2 when first player wins when first player chooses paper and second player chooses stone (GameTest)
     test/game_test.exs:47
     ** (CondClauseError) no cond clause evaluated to a truthy value
     code: assert {:ok, match} = Game.play(first_player_choice, second_player_choise)
     stacktrace:
       (rock_paper_scissor_elixir 0.1.0) lib/game.ex:18: Game.result/2
       test/game_test.exs:51: (test)



Finished in 0.03 seconds (0.00s async, 0.03s sync)
6 tests, 2 failures

Randomized with seed 797736
...

Finished in 0.02 seconds (0.00s async, 0.02s sync)
3 tests, 0 failures

Randomized with seed 352470

When the first player chooses paper and the second player chooses stone

We'll add the condition when the first player chooses paper and the second player chooses stone:

defmodule Game do
  @moduledoc """
  Documentation for `Game`.
  """

  def play(first_player_choice, second_player_choice) do
    result(first_player_choice, second_player_choice)
  end

  defp result(first_player_choice, second_player_choice) do
    cond do
      first_player_choice == second_player_choice ->
        {:ok, "Draw!"}

      first_player_choice == @scissor && second_player_choice == @paper ->
        {:ok, "First player win!!!"}

      first_player_choice == @paper && second_player_choice == @stone ->
        {:ok, "First player win!!!"}
    end
  end
end

And now, if we rerun the tests:

mix test

The test with the actual scenario passed ok. And now we have just one tests with failure.

Compiling 1 file (.ex)
..

  1) test Game.play/2 when first player wins when first player chooses stone and second player chooses scissors (GameTest)
     test/game_test.exs:56
     ** (CondClauseError) no cond clause evaluated to a truthy value
     code: assert {:ok, match} = Game.play(first_player_choice, second_player_choise)
     stacktrace:
       (rock_paper_scissor_elixir 0.1.0) lib/game.ex:21: Game.result/2
       test/game_test.exs:60: (test)

...

Finished in 0.03 seconds (0.00s async, 0.03s sync)
6 tests, 1 failure

Randomized with seed 450094

When the first player chooses stone and the second player chooses scissors

We'll add the condition when the first player chooses stone and the second player chooses scissors:

defmodule Game do
  @moduledoc """
  Documentation for `Game`.
  """

  def play(first_player_choice, second_player_choice) do
    result(first_player_choice, second_player_choice)
  end

  defp result(first_player_choice, second_player_choice) do
    cond do
      first_player_choice == second_player_choice ->
        {:ok, "Draw!"}

      first_player_choice == @scissor && second_player_choice == @paper ->
        {:ok, "First player win!!!"}

      first_player_choice == @paper && second_player_choice == @stone ->
        {:ok, "First player win!!!"}

      first_player_choice == @stone && second_player_choice == @scissor ->
        {:ok, "First player win!!!"}
    end
  end
end

And now, if we rerun the tests:

mix test

All the tests pass with success.

Compiling 1 file (.ex)
......

Finished in 0.03 seconds (0.00s async, 0.03s sync)
6 tests, 0 failures

Randomized with seed 795123

In the next post, we'll build the tests covering the scenario when the second player wins.

Contacts

Email: contato@diegonovais.com.br
Linkedin: https://www.linkedin.com/in/diegonovais/
Twitter: https://twitter.com/diegonovaistech

Building the tests when the first player wins

Diego Novais — Tue, 30 Aug 2022 04:12:00 +0000

The first player wins when his item chosen is the most powerful.

When the first player chooses scissors and the second player chooses the paper:

defmodule GameTest do
  use ExUnit.Case

  @stone 1
  @paper 2
  @scissor 3

# ...

  describe "Game.play/2 when first player wins" do
    test "when first player chooses scissor and second player chooses paper" do
      first_player_choice = @scissor
      second_player_choise = @paper

      assert {:ok, match} = Game.play(first_player_choice, second_player_choise)

      assert match == "First player win!!!"
    end
  end
end

When the first player chooses paper and the second player chooses the stone:

defmodule GameTest do
  use ExUnit.Case

  @stone 1
  @paper 2
  @scissor 3

# ...

  describe "Game.play/2 when first player wins" do
    # ...
    test "when first player chooses paper and second player chooses stone" do
      first_player_choice = @paper
      second_player_choise = @stone

      assert {:ok, match} = Game.play(first_player_choice, second_player_choise)

      assert match == "First player win!!!"
    end
  end
end

When the first player chooses stone and the second player chooses the scissor:

defmodule GameTest do
  use ExUnit.Case

  @stone 1
  @paper 2
  @scissor 3

# ...

  describe "Game.play/2 when first player wins" do
    # ...
    test "when first player chooses stone and second player chooses scissor" do
      first_player_choice = @stone
      second_player_choise = @scissor

      assert {:ok, match} = Game.play(first_player_choice, second_player_choise)

      assert match == "First player win!!!"
    end
  end
end

Let's look at the code of the tests when the game's result is "First player win!!!".

defmodule GameTest do
  use ExUnit.Case

  @stone 1
  @paper 2
  @scissor 3

# ...

  describe "Game.play/2 when first player wins" do
    test "when first player chooses scissor and second player chooses paper" do
      first_player_choice = @scissor
      second_player_choise = @paper

      assert {:ok, match} = Game.play(first_player_choice, second_player_choise)

      assert match == "First player win!!!"
    end

    test "when first player chooses paper and second player chooses stone" do
      first_player_choice = @paper
      second_player_choise = @stone

      assert {:ok, match} = Game.play(first_player_choice, second_player_choise)

      assert match == "First player win!!!"
    end

    test "when first player chooses stone and second player chooses scissor" do
      first_player_choice = @stone
      second_player_choise = @scissor

      assert {:ok, match} = Game.play(first_player_choice, second_player_choise)

      assert match == "First player win!!!"
    end
  end
end

In the next post, we'll code our module Game following the tests when the First Player wins.

Contacts

Email: contato@diegonovais.com.br
Linkedin: https://www.linkedin.com/in/diegonovais/
Twitter: https://twitter.com/diegonovaistech

Game draw! Building the code and make the tests pass

Diego Novais — Tue, 30 Aug 2022 04:07:00 +0000

Now we'll code our module Game following the tests.

# lib/game.ex

defmodule Game do
  @moduledoc """
  Documentation for `Game`.
  """
end

If we run the tests now:

mix test

We'll see the tests failures:

  1) test Game.play/2 when the players draw when all players choose scissor (GameTest)
     test/game_test.exs:27
     ** (UndefinedFunctionError) function Game.play/2 is undefined or private
     code: assert {:ok, match} = Game.play(first_player_choice, second_player_choise)
     stacktrace:
       (rock_paper_scissor_elixir 0.1.0) Game.play(3, 3)
       test/game_test.exs:31: (test)


  2) test Game.play/2 when the players draw when all players choose paper (GameTest)
     test/game_test.exs:18
     ** (UndefinedFunctionError) function Game.play/2 is undefined or private
     code: assert {:ok, match} = Game.play(first_player_choice, second_player_choise)
     stacktrace:
       (rock_paper_scissor_elixir 0.1.0) Game.play(2, 2)
       test/game_test.exs:22: (test)


  3) test Game.play/2 when the players draw when all players choose stone (GameTest)
     test/game_test.exs:9
     ** (UndefinedFunctionError) function Game.play/2 is undefined or private
     code: assert {:ok, match} = Game.play(first_player_choice, second_player_choise)
     stacktrace:
       (rock_paper_scissor_elixir 0.1.0) Game.play(1, 1)
       test/game_test.exs:13: (test)



Finished in 0.02 seconds (0.00s async, 0.02s sync)
3 tests, 3 failures

Let's make those tests pass

Firstly, we must create the function play passing two arguments, first_player_choice and second_player_choice:

defmodule Game do
  @moduledoc """
  Documentation for `Game`.
  """

  def play(first_player_choice, second_player_choice) do
  end
end

And then let's rerun the tests:

mix test

 1) test Game.play/2 when the players draw when all players choose stone (GameTest)
     test/game_test.exs:9
     match (=) failed
     code:  assert {:ok, match} = Game.play(first_player_choice, second_player_choise)
     left:  {:ok, match}
     right: nil
     stacktrace:
       test/game_test.exs:13: (test)



  2) test Game.play/2 when the players draw when all players choose scissor (GameTest)
     test/game_test.exs:27
     match (=) failed
     code:  assert {:ok, match} = Game.play(first_player_choice, second_player_choise)
     left:  {:ok, match}
     right: nil
     stacktrace:
       test/game_test.exs:31: (test)



  3) test Game.play/2 when the players draw when all players choose paper (GameTest)
     test/game_test.exs:18
     match (=) failed
     code:  assert {:ok, match} = Game.play(first_player_choice, second_player_choise)
     left:  {:ok, match}
     right: nil
     stacktrace:
       test/game_test.exs:22: (test)



Finished in 0.03 seconds (0.00s async, 0.03s sync)
3 tests, 3 failures

Now we need to guarantee that the game will draw if the player chooses the same item:

defmodule Game do
  @moduledoc """
  Documentation for `Game`.
  """

  def play(first_player_choice, second_player_choice) do
    result(first_player_choice, second_player_choice)
  end

  defp result(first_player_choice, second_player_choice) do
    cond do
      first_player_choice == second_player_choice -> {:ok, "Draw!"}
    end
  end
end

And now, if we rerun the tests:

mix test

Everything passed, and everything was ok.

...

Finished in 0.02 seconds (0.00s async, 0.02s sync)
3 tests, 0 failures

Randomized with seed 352470

In the next post, we'll build the tests covering the scenario when the first player wins.

Contacts

Email: contato@diegonovais.com.br
Linkedin: https://www.linkedin.com/in/diegonovais/
Twitter: https://twitter.com/diegonovaistech

Building the tests when players draw

Diego Novais — Tue, 30 Aug 2022 04:01:34 +0000

Now we'll develop the tests, and after, we'll make the tests pass, and subsequently, we'll make some refactoring.

Building the tests

Inside the module Game, we'll create the function called play, which will receive the choice of the first player and the second player as arguments.

And with this data, we'll make some calculus, and then we'll know who the winner is.

So, let's go to tests and scenarios...

When players draw

When the first and second players choose the same item, the game is Draw!

So, if the players choose stone:

defmodule GameTest do
  use ExUnit.Case

  @stone 1
  @paper 2
  @scissor 3

  describe "Game.play/2 when the players draw" do
    test "when all players choose stone" do
      first_player_choice = @stone
      second_player_choise = @stone

      assert {:ok, match} = Game.play(first_player_choice, second_player_choise)

      assert match == "Draw!"
    end
  end
end

So, if the players choose paper:

defmodule GameTest do
  use ExUnit.Case

  @stone 1
  @paper 2
  @scissor 3

  describe "Game.play/2 when the players draw" do
    #...

    test "when all players choose paper" do
      first_player_choice = @paper
      second_player_choise = @paper

      assert {:ok, match} = Game.play(first_player_choice, second_player_choise)

      assert match == "Draw!"
    end
  end
end

So, if the players choose scissor:

defmodule GameTest do
  use ExUnit.Case

  @stone 1
  @paper 2
  @scissor 3

  describe "Game.play/2 when the players draw" do
    #...
    test "when all players choose scissor" do
      first_player_choice = @scissor
      second_player_choise = @scissor

      assert {:ok, match} = Game.play(first_player_choice, second_player_choise)

      assert match == "Draw!"
    end
  end
end

Let's look at the code of the tests when the game's result is "Draw!".

defmodule GameTest do
  use ExUnit.Case

  @stone 1
  @paper 2
  @scissor 3

  describe "Game.play/2 when the players draw" do
    test "when all players choose stone" do
      first_player_choice = @stone
      second_player_choise = @stone

      assert {:ok, match} = Game.play(first_player_choice, second_player_choise)

      assert match == "Draw!"
    end

    test "when all players choose paper" do
      first_player_choice = @paper
      second_player_choise = @paper

      assert {:ok, match} = Game.play(first_player_choice, second_player_choise)

      assert match == "Draw!"
    end

    test "when all players choose scissor" do
      first_player_choice = @scissor
      second_player_choise = @scissor

      assert {:ok, match} = Game.play(first_player_choice, second_player_choise)

      assert match == "Draw!"
    end
  end
end

In the next post, we'll code our module Game following the tests.

Contacts

Email: contato@diegonovais.com.br
Linkedin: https://www.linkedin.com/in/diegonovais/
Twitter: https://twitter.com/diegonovaistech

A List is not an Array

Diego Novais — Fri, 26 Aug 2022 22:31:16 +0000

When I saw the code below for the first time, I thought it was probably an Array. And then, it could be that you have the same thought. lol

# Creating a list
list = [1, :atom, 3, 4, "string"]

But in Elixir, the code above it's a List.

What is a List?

In a few words, a List is Linked List. But to understand better, let's remember what an array is and then talk about the List.

About the Array

The Array is a data collection of the same type.

In the Array, we can access the content through the indices. And when we need, for example, to get the third element of an Array directly, in Ruby, we can do by passing the index number 2:

> x = [1, 2, 3, 4]
[1, 2, 3, 4]

> x[2]
3

Another feature of the Array is that we can iterate between the elements, one by one, directly. And in Ruby, we can do by:

> x.each{|element| puts element}
1
2
3
4

Now, let's go back to talking about List and Elixir again

In Elixir the lists are linked lists. That means each item is bound to the next element through the position in memory.

How can we iterate through the items in a List?

Firstly we need to know that a List is composed of 2 parts: the head is the List's first item, and the tail is the rest of the items.

In Elixir we have the kernel function hd(list) to access the first item of the List (head), and we also have the kernel function tl(list) to access the rest of the items from the List (tail). Take a look on the example below:

> # creating the List
> list = [1, :atom, 3, 4, "string"]
[1, :atom, 3, 4, "string"]

> # Return the first item of the List - Head
> hd(list)
1

> # Return the rest of items of the List - Tail
> tl(list)
[:atom, 3, 4, "string"]

Also, it's possible to access the head and tail of a list using Pattern Matching:

# Creating a list
> list = [1, :atom, 3, 4, "string"]
[1, :atom, 3, 4, "string"]

# Using Pattern Matching to assign the first element 
# to the head and the rest of the list to the tail.
> [head | tail] = list
[1, :atom, 3, 4, "string"]

# Return the first element from the list
> head
1

# Return the rest of elements from the list
> tail
[:atom, 3, 4, "string"]

And to iterate each item in a list, we use recursion:

# Creating the module as example
defmodule Example do
  def show_each_one([head | tail]) do
    # The kernel function IO to show the content of head
    IO.puts(head)

    # Calling the function itself
    # (where the recursion happens)
    # by passing the tail as the argument of the function
    show_each_one(tail)
  end

  # Creating the function using the pattern Matching
  # In the case of an empty list, it will return null (nil)
  def show_each_one([]), do: nil
end

# Creating a list
list = [1, :atom, 3, 4, "string"]
[1, :atom, 3, 4, "string"]


# Call the function Example.show_each_one/1
# by passing the list as argument
Example.show_each_one(list)

# It will return the result below:
1
atom
3
4
string
nil

We could use many other kernel functions to work with the lists:

first(list) - To return the first element of the list.
last(list) - To return the list element of the list.
insert_at(list, index, value) - To insert one element in the list in a certain position.
And many others.

If you need to know more about the details of the List, I suggest you look at the Elixir documentation about the List.

Something interesting that we need to know is that the functions we use to work with a List use recursion in their implementation.

I hope that this content helps and makes sense to you! See ya!

Contacts:
Email: contato@diegonovais.com.br
LinkedIn: https://www.linkedin.com/in/diegonovais/
Github: https://github.com/dnovais
Twitter: https://twitter.com/diegonovaistech

Forem: Diego Novais

O que eu gostaria de ter aprendido sobre rotas no Rails lá no início

Introdução

O Básico das Rotas

Definição de Rota Simples

Rotas RESTful

Definindo um Recurso Manualmente (Sem resources)

Explicação

Vantagens e Uso

Rotas Aninhadas

Interpretando Paths em Rotas Profundas

Estrutura de Rotas

Como Ler e Construir Helpers de Caminho

Dicas para Interpretação de Paths

Buscando Rotas Específicas

Usando rake routes | grep

Usando rails routes -g

Nomeação e Redirecionamento

Nomeando Rotas

Redirecionamento de Rotas

Conclusão

How to Ignore Files in Git Without Using .gitignore

What is the .git/info/exclude file?

Step-by-step guide to using .git/info/exclude

Advantages of using .git/info/exclude

Important considerations

Conclusion

Como ignorar arquivos no Git sem usar o .gitignore

O que é o arquivo .git/info/exclude?

Passo a passo para usar o .git/info/exclude

Vantagens de usar .git/info/exclude

Considerações importantes

Conclusão

Simplify Your Rails Route Filtering with This Quick Tip

TIL: Quick tip for Rails users!

TIL: Dica rápida para quem usa Rails!

4 Stages Of Problem Solving

1 - Analyze

2 - Plan

3 - Implement

4 - Evaluate

Refactoring the Game

The mathematical approach

Refactoring the Game

Running the tests:

Understanding the failure message

Solving the failure message

Contacts

Sources and references

Second player wins! Building the code and make the tests pass

When the first player chooses paper and the second player chooses scissors

When the first player chooses stone and the second player chooses paper

When first player chooses scissors and the the second player chooses stone

Contacts

Building the tests when the second player wins

Contacts

First player wins! Building the code and make the tests pass

Let's make those tests pass

When the first player chooses scissors and the second player chooses paper

When the first player chooses paper and the second player chooses stone

When the first player chooses stone and the second player chooses scissors

Contacts

Building the tests when the first player wins

Contacts

Game draw! Building the code and make the tests pass

Let's make those tests pass

Contacts

Building the tests when players draw

Building the tests

When players draw

Contacts

A List is not an Array

What is a List?

About the Array

Now, let's go back to talking about List and Elixir again

How can we iterate through the items in a List?

Definindo um Recurso Manualmente (Sem `resources`)

Usando `rake routes | grep`

Usando `rails routes -g`