viroulep / btest Goto Github PK

It would be nice to preselect a few deezer mix to choose from when creating the game.

À faire pour mot par mot (mais vérifier que les gens ne soumettent pas un nombre infini de mots)

• Full games index should only be available to admin.
• The landing page should display two tabs:
  • current (pending or started) competitions
  • past (finished or aborted) competitions
• Games should be able to be started/aborted only by their creator

Some tracks are listed through the deezer API but are not actually readable.
We filter them on the fly, but it may be frustrating to not precisely which tracks are not available.

We could create a button to "analyze playlist" on the "create game" view, that would query the deezer API for the tracklist, and display in a modal which tracks are not available.

Relevant code is in the Answer model, we should make it clear in the doc/client faq.

It's API only so it should be fairly easy to test the expected behavior through rspec.

We create and programatically start an Audio object, which is considered as autoplay by web browsers.
By default they actually don't play it, unless the user made an explicit interaction with the webpage (such as focusing a field, clicking a link, ...).
We auto-focus the input, which means that a user can actually open a direct link to the game and be ready to type in an answer without having interacted with the page (which also means the preview won't be played...).
We should create a modal to inform the user they are joining a game, which will make interact with the page.

When visiting a game it should be clear if we're waiting on it to start, if it's running, finished, or aborted.

Although i18n is implemented, the string are not yet extracted.
We should do that, and go through internationalize to get the French translation.

@zeecho ? ;)

I used the rails infrastructure for i18n (which means strings are to be put in the usual server/config/locales/locale.yml), then running bin/rails i18n:exports will create the appropriate js exports at the appropriate place in the client (generated_locales is a symlink to there).
In the js files it's just a matter of doing import I18n from 'i18n-js';, and using the helper just as in a rails app (I've added an example here).

Depends on #3.
Since we know how fast a complete answer is given, we could display all of them above/below the progress bar, to get an idea of who has replied how fast.

'btest' is not quite great.

Because the jobs use the default queue, it's executed by the same process as the server.
So if it restarts, the queued jobs are lost.
We should simply use an adapter running in a different process (eg: DelayedJobs).

It could be one, it could be multiple :

• if #9 is implemented, we could display the current user's public playlists
• in any case, we could let them add up to N < 15 public playlist to pick songs from

When creating the game :

• pick one of N playlist, pick 1 song from it
• repeat until we have 15 songs
  It's better than just concatenating all songs and picking 15, as it gives equal weight for all playlists.

We should setup some feedback about where we are in the current song.
Setting a timer and using a linear determinate should do the trick.

For non anonymous users, we should:

• send a PUT to the server whenever the user changes its session locale
• send a locale attribute in the me object
• update the function getting the user's preference to first take a look at the me object

The client is using vanilla material ui, it could be nice to come up with a specific set of colors (primary/secondary) to make it feel less like a default theme.

Request may fail if something wrong happens with the server.
Currently they are silently ignore, we should figure out a common way to handle them (maybe some common Snackbar?).

Client-side version of #11.

Clearly describe what the website is intended for (and what is it not!), describe the basic features and such, and provide alternative websites in case it doesn't match their expectations.

Basically there will be a lot of them, and they change every time the browser is closed.
We should implement a job that delete any anonymous user created more than 7 days ago (arbitrary).

Currently the workflow only supports a 1-1 relation between the local user and the provider's user.
It would be nice to let them sign in from multiple providers into the same local account.
We could use the email address to identify them across providers.
Tricky part: what if they change email in one of their provider?

This requires fairly serious work, and should be done later.

This is currently targeted to our friends and families, not everyone speaks English.

omnioauth has an adapter for it, but it's outdated.
It shouldn't be too hard to refresh/reimplement it.

It's going to get tricky once #10 is implemented, but that could be nice to save the user from setting everything again.

This will require very basic user management capabilities on the API.
It's fine if the first user has to be marked as admin on the rails console.

Most likely use chef to provision the given environment, assuming it runs from a fresh debian install.

Other things to consider:

• a docker image to build the client code (provide a dockerfile for the client, create a container based on it, mount /client, and get the result in /client/build.
• a docker image containing the stuff needed to start the whole app (for a production image, it's basically a fresh container + running chef)