Latest blog entries

Erlang and Elixir Factory Lite B.A.

A brief introduction about what was the Erlang Factory Conference in Buenos Aires for some Inaka team members

Jul 07 2017 : Euen Lopez

The Art of Writing a Blogpost

The Art of Writing a Blogpost

Apr 11 2017 : Matias Vera

SpellingCI: No more spelling mistakes in your markdown flies!

Feb 14 2017 : Felipe Ripoll

Fast reverse geocoding with offline-geocoder

Do you need a blazing fast reverse geocoder? Enter offline-geocoder!

Jan 18 2017 : Roberto Romero

Using Jayme to connect to the new MongooseIM REST services

MongooseIM has RESTful services!! Here I show how you can use them in an iOS application.

Dec 13 2016 : Sergio Abraham

20 Questions, or Maybe a Few More

20 Questions, or Maybe a Few More

Nov 16 2016 : Stephanie Goldner

The Power of Meeting People

Because conferences and meetups are not just about the technical stuff.

Nov 01 2016 : Pablo Villar

Finding the right partner for your app build

Sharing some light on how it is to partner with us.

Oct 27 2016 : Inaka

Just Play my Sound

How to easily play a sound in Android

Oct 25 2016 : Giaquinta Emiliano

Opening our Guidelines to the World

We're publishing our work guidelines for the world to see.

Oct 13 2016 : Brujo Benavides

Using NIFs: the easy way

Using niffy to simplify working with NIFs on Erlang

Oct 05 2016 : Hernan Rivas Acosta

Function Naming In Swift 3

How to write clear function signatures, yet expressive, while following Swift 3 API design guidelines.

Sep 16 2016 : Pablo Villar

Jenkins automated tests for Rails

How to automatically trigger rails tests with a Jenkins job

Sep 14 2016 : Demian Sciessere

Erlang REST Server Stack

A description of our usual stack for building REST servers in Erlang

Sep 06 2016 : Brujo Benavides

Replacing JSON when talking to Erlang

Using Erlang's External Term Format

Aug 17 2016 : Hernan Rivas Acosta

Gadget + Lewis = Android Lint CI

Integrating our Android linter with Github's pull requests

Aug 04 2016 : Fernando Ramirez and Euen Lopez

Passwordless login with phoenix

Introducing how to implement passwordless login with phoenix framework

Jul 27 2016 : Thiago Borges

Beam Olympics

Our newest game to test your Beam Skills

Jul 14 2016 : Brujo Benavides


Three Open Source Projects, one App

Jun 28 2016 : Andrés Gerace


Running credo checks for elixir code on your github pull requests

Jun 16 2016 : Alejandro Mataloni

See all Inaka's blog posts >>

Beam Olympics

A photo of Brujo Benavides wrote this on July 14, 2016 under elixir, erlang, game .

We did it again!

Just like last year, Franco Bulgarelli and his team invited us to share a class with their students at UTN-FRBA, where they teach Distributed Programming. And exactly like last year, they gave us a great welcome and allow us the possibility of meeting a group of very talented people.

We had the chance to show them what we do and how we work, but the best part of the meeting started when I booted up a Beam Olympics server and we all started playing the game.

Beam Olympics

Last year we also played a game with the students. Back then we used Gold Fever, which is a game that requires some serious Erlang skills to solve its puzzles. Since Franco teaches Elixir in his course, this year we wanted to let them use the tools they're most familiar with. So, with Hernán and Marcos, we built a new game: Beam Olympics. This game works in a similar fashion as Gold Fever, but it can be played using Elixir as well.

And you can play as well!

As you might have guessed from the links above, Beam Olympics is open-source. That means you and your friends can play, too. And not only that, it's configurable so you can build your own version of it and make it as easy or as challenging as you want.


The easiest way to install your server is to download the latest release from github, uncompress the zip file that comes with it and, if needed, update the vm.args file that you will find inside beam_olympics/releases/$NUMBER/. In that file, you can define the node name of your server and the cookie it will use. It's important that you set those values appropriately so other nodes can connect to it.

Booting up

Once you have that release unzipped and everything appropriately configured in vm.args, you can start your server with the following command:

$ beam_olympics/bin/beam_olympics console

That will open up an Erlang console for you. You can use start instead of console if you don't need the terminal.


To play the game, players will need to boot up nodes with the same cookie as the one used for the server. If they use elixir and mix, they can do it like this:

$ iex --name player_name --cookie cookie -S mix

Once that is done, players will communicate with a gen_server called bo_server that will be running on the server node. All messages should be sent using typical gen_server calls, like this one:{:bo_server, server}, command)

In that expression, server is the server node's name (as an atom) and command is one of the valid commands listed below:

  • {:signup, player_name}: register a player. Multiple players can play in the same node, but every player must stay in the same node the whole game.
  • {:task, player_name}: get the next challenge to solve.
  • {:submit, player_name, solution}: Used to submit the solution for the current task.
  • {:skip, player_name}: give up on the current task and move to the next one.
  • {:score, player_name}: retrieve the current player's score
  • :stats: retrieve a snapshot of the match statistics


The basic mechanics of the game are straightforward: When players sign up, they receive a task to solve. They can choose to either submit a solution or skip the task. If they choose to submit a solution and the solution is valid, they move to the next task. If the solution is not valid, the server will report the reasons for that and the players can try again as many times as they want. If they decide to skip a task, the server will simply provide the next task. Besides that, there are a few other rules:

  • To prevent fraud, users must always submit solutions from the same node in which they signed up. The node might crash or be closed, but when restarted it has to be called with the same name as before, otherwise submissions will be rejected.
  • There is no undo, if you skipped a task you can't choose to submit a solution for it later.
  • If there are no more tasks left after skipping or completing a task, the user will receive the atom the_end, indicating that the game is over for him.
  • Each task has it's own associated score. Points are assigned this way:
    • Each time a task is correctly solved, the player obtains score points.
    • Each time a task is skipped, the player loses score / 2 points.

The Tasks

We created a fair number of tasks to play. We keep several tasks in a private repository so that we can use them multiple times with deferent groups of players, but we left some tasks on the project repo. Those should be enough to entertain you for a while, but if you want to add more, you just need to create new modules implementing the bo_task behaviour and add them to the all_tasks environmental variable for beam_olympics.

That's all! Have fun and, if you play this game with your friends, don't forget to tell us all about it in the comments below!