mayppong / gyro Goto Github PK

When sending spinner info to the client, mark with a boolean or something whether a spinner is actually spinning or not. This could allow the template to update with appropriate colors or shit.

We're currently using Erlang's :calendar module for the timestamps which doesn't JSON-ify with Poison. Because of this, we have to manually remove date fields before outputting the data down to users. Hopefully with the new Calendar module in the standard library, we can either pass the datetime down and it will get JSON-ified correctly, write a transformation method to interface with it, or decide on something. At this point though, we should wait and see until 1.3 is out.

Supervisor.start_child seems to be returning the same pid no matter what squad name we're passing into the worker function. IO.inspect the worker seems to be generating the data struct correctly. I think it might be how we are naming the worker that ends up referencing the same worker every time.

When iterate through member list and getting data, let's try to do them using Stream instead. This might help reduce the memory footprint especially when it comes to the arena and large squads.

Front-end development (templates, css, javascript) seems overly complicated when using Phoenix. I suggest simply serving front-end static files (html, javascript, css, images) from nginx.

The Squad GenServer currently starts with link to the current process that the socket connection also uses. That means if the first squad member who started the squad leaves, the GenServer would trigger the :EXIT message and try to terminate the GenServer instance. Unlike with Spinner, we want the Squad GenServer to lives past the first member life cycle. That means we need to link the process to another Supervisor tree.

@alexblackie suggested creating a new Supervisor (let's call it Referee) to monitors the Squad GenServers. In turn, instead of create a Squad GenServer directly, we ask the Referee to create one for us under its supervision. This Referee would then also be added to the application supervisor tree as well so itself can also be monitored.
http://elixir-lang.org/getting-started/mix-otp/supervisor-and-application.html#simple-one-for-one-supervisors

Technically this is something we're already doing with the Arena GenServer where it's being added to the Gyro application supervisor tree and instantiate when the application is started.

Since we're currently only add spinner to the list but not checking for duplicate, the same spinner could show up multiple times.

This one will likely depends on #32 to be implemented first otherwise we won't be able to identify one spinner from another.

Would be good to know how many spinners and squads are in the system.

** Update **
Changing the scope slightly since I've implemented the scoreboard class. We should keep track of the total size of either spinners or squad in the scoreboard as well. This means total size of spinners in the arena or a squad, or total size of squad in the arena.

When updating spinner data from Arena or Squad, we need to check and make sure that the member is still in the system before making a GenServer call, otherwise we'll get an error saying no process.

Application processes like Arena should be using module name instead of atom like :arena. This way, we don't need to worry about maintaining separate atom name. Plus, the module names need to be unique anyway.

Currently there's a lot of hardcoding of functionality for spinner arena and squad arena. Would be nice to see those clean up.

When it was done originally, I just needed something to work so it wouldn't hold back the front-end work.

We should switch the member list in the Squad state to be more like the Arena's spinner roster. It stores just a map of spinner id to the pid. During each spin, we then inspect the spinners' states and calculate the stats we need before discarding them. This should make the actual state we store back as the GenServer's state much lighter.

We should broadcast a spinner's name change to the chatroom.

To reproduce:

1. open a tab (Tab A) and choose a name and a team. (eg team ABC)
2. wait about a minute for the score to be over 1.0 spins.
3. Open another tab (Tab B) and choose a new name, and join the same team as team A (eg ABC)
4. After another minute, in Tab B, choose a new team name. (eg AB2)

symptoms:

1. In Tab A, the score still shows the second player in the original team
2. In Tab B, the team score shows team scores from both teams, one after the other.

We should implement a proper UUID for spinner since pid gets reused, meaning we won't be able to tell people apart in legendary scoreboard.

After some chatting in elixir-lang IRC, @ericmj suggests it's better for the GenServers that require pids to monitor those pids instead of having them report the termination.
ie. it's better for the Squad and Arena to monitor Spinner pids and handle the down message than to let the Spinner delist itself from Squad and Arena on terminate. As @micmus points out, this is because there can be instances where the process dies that doesn't cause terminate to be triggered. Like something bad happens.

This obviously will mean the Arena has to be smart enough to know whether it's monitoring a Spinner or a Squad pid.

PS. Since this could lead to issues, we should treat it as a bug.

Especially testing Squad's implementation. Instead of starting the GenServer process and sending it messages which involves other moving parts than the message handlers, we should test by calling the handle_* directly and test the response. This should make the tests a lot simpler and faster.

Currently, Spinner and Arena doesn't test the GenServer implementation at all, only the public APIs.

It would be wild to see the overall spin rate of the whole game.

Since we're now using sass, it should be done with brunch to keep the number of commands we have to run down.

Currently there is not backend guard against a spinner subscribing to, and consequently joining, multiple squads.

1. In the newer version of Phoenix, the channels are getting unsubscribe method that I could use to remove a spinner from a team. We'll probably want to use this to unsubscribe a spinner from the channel.
2. However, we should still delist a spinner from a squad before enlisting them as part of the GenServer's client API implementation as well anyway.