osumb / challenges

Challenge Signup Manager

OSUMB Challenges

Manage the challenge process for the Ohio State University Marching Band

Installation and setup

This app has a few dependencies you need to install yourself. The use of each will be explained below

• Docker
• Docker Compose
• Rails
• Postgres <-- This is just for the ability to install the pg gem
• Node
• Heroku CLI

Docker/Docker Compose

We're using Docker to run our datastores (PostgreSQL and Redis). The benefit of using Docker is that it eliminates the need to install the data stores and have them running/cluttering up your computer.

Rails

Rails is a popular web server framework. It's used to handle web requests

Heroku CLI

The app is running on Heroku! Their cli comes in handy if/when you need to use the service. It's also leveraged for local development (see bin/server). See Heroku.md for more details.

Get the Code

Inside your terminal, run the following commands to get the code.

git clone https://github.com/osumb/challenges.git
cd challenges

Install Rails Dependencies

bundle install

Datastores

Every web app needs a database! You can run one locally with docker-compose up -d

Environment variables

Rails will yell at you if you don't have a .env file available, so add one! The required keys are listed in config/envvars.yml. The format of your .env file should be:

ENVIRONMENT_VARIABLE_KEY=environment_variable_value

Start the app

You should be good to go with dependencies and everything. To start app locally, just run

bin/server

This command will start a rails web server and a Resque worker for asynchronous jobs

The rails server will run at localhost:3000

Application Stack

Rails

The API layer is a Ruby on Rails App

Tests

Tests are cool and you should run them a lot!

bundle exec rspec .

Code Formatting

Ruby

Checkout .rubocop.yml to see the ruby specific code formatting rules

Heroku

The app lives on Heroku. @atareshawty has the logins. Ask him if you want the ability to deploy or have access to the Heroku git remotes.

Deploying

To deploy to either environment, simply run bin/deploy <remote>, where <remote> is either production or staging.

You can optionally deploy a branch to staging or production (staging for testing, production for emergencies). Example: If I wanted to deploy my branch alex-cool-new-feature to staging for testing, I'd run:

bin/deploy <staging|production> cool-new-feature

Staging vs Production

Staging

The staging instance is used to test new features, specifically ones that have made it into PRs. There is no staging branch. To test, just do a manual deploy to the staging instance.

Production

The master branch is protected from force pushes and PR's must pass

challenges's Issues

Have current performance associated with session

So we don't have to query for it every time we need it

Authentication Middleware!

BEFORE YOU TEST EVERYTHING: Rather than each controller action having to check for authentication, have that as middleware in the router file!!

Handlebars Helpers

This will really clean up the templates. Separate the registered helpers from app.js though!

Logging for successful Challenge signup

We should be logging other things too

Login Through OSU SSO

Email once user challenge is successful

https://github.com/niftylettuce/node-email-templates
https://github.com/nodemailer/nodemailer

Logger should take message and object

It'll look like

console.log(`JOBS_LOG: ${message}`, obj);

Challengeable person list styling

In the list of people to challenge, we want to signify if the spot is challenged by making the selection grayed out and not clickable. Also let the user know if the spot is open. Don't include the user's name who had the spot if that's the case

Heroku Broke!

Upgrade to node 6

Specific Director Challenge Result Approval

Some directors have 'reign' over a specific instrument group for challenges. We need to add permissions for that

Controller Actions Should prevent bad, but authenticated actions

For example, if a person sends a challenge request, but we're past the performance closeAt or if someone makes a challenge, but he/she is the last one and an open spot hasn't been challenge yet

Email Templates For Challenges

Can be written in handlebars and compiled

Open Spots Need A Reason

Either discipline or others

All of the javascript goodness

My local machine is now on Node 6, so Heroku should be too! Travis is already there. Along with the upgrade, I should use all of the new js goodness this allows

Better Linting

I want more enforcement with linting rules

Make Challenge Link In Navbar Broken

Yeah...

Performance Upload Cron Job

Should build the result objects at the same time the challenge list is exported. That way, SL's can't see challenges until the list is created

Need a way to tell current performance other than by time

When the time window ends for a current performance, we still need to be able to reference it easily. Maybe a current boolean on the performance model?

SL shouldn't be able to evaluate themselves

They shouldn't be able to see it all all

SLs would rather have all people available listed for challengeable people with spots taken already grayed out

I'm not sure why, but that was the prevailing opinion at the squad leader retreat

Flash message on new challenge success/failure

Right now it redirects and that's kind of crappy. Let's have a flash message

More Front End Js

Right now, there's a weird mix between server side redirects and js fetches happening and it's confusing. This takes priority over other things before development can continue so things don't get too hairy

Sockets

For after challenge creation is implemented. When a user is logged in and looking at a list of potential people to challenge, if a person on the list is challenged, that person should be deleted from the list. This will reduce conflicts if two people try to challenge the same person within a short time of each other

User Profile

"You're not currently signed up for a challenge" should not show if user is ineligible for a challenge.

Scrip/Setup still has incorrect database name

The database name is spending_tracker_development and should be challenges_dev

Clean Up User Profile Controller/Query Code

A lot of the code from #35 is kind of nasty, but we need it for demo purposes. Do yourself a favor and clean this up when you get a chance. Particularly around the query for the data/parsing of the results. Also, there are some similar functions in the ChallengersControllerSpec and UsersControllerSpec that can be abstracted out

Challenge Select Link Should Always Be There

And the controller that renders the page checks of the user is good

TODO

These are the things that for sure need to get done to be usable:

• Email user when he/she signs up for challenge
• Spot switch when challenge result is confirmed
• Challenge list exporting when signup time is over (Node-Schedule when a performance is created)
• Logging on challenge success (for my sanity and debugging)
• #87
• Admin things that would be useful to have (probably need to meet with Tess)
• #114
• #110
• Just learned today that different directors are going to be responsible for approving different instrument groups so there are some permission things that need to get built
• #108
• #126
• Styling
• #125 (@tarebyte)
• Automated Testing of the entire process
• #156
• Finish all TODO:'s in the code
• #164
• Sockets - to remove a person from the list if they've been challenged while a user is on the page (not high priority. Probably shouldn't mess since release is soon)

Testing

Styling

Should be using Flexbox

Promise.all

We probably don't need nested promises anywhere they're being used. Take a look at those spots and replace with Promise.all([promise list])

Webpack for client side js

I think it breaks on safari.......

Change /performances/:performanceId/results/:resultId to a put

When the fetch stuff is implemented, get rid of the form and make that request a put

Challenge Window Shouldn't show up on home screen when we're past the window

Inconsistent Model API

Some models use getX while others use findX. These should be consistent

connect.session Heroku

Warning: connect.session() MemoryStore is not designed for a production environment, as it will leak memory, and will not scale past a single process.
That shouldn't be happening as we're using Redis

New Performance Form

Should warn admin to correctly enter data as job will be triggered when performance is submitted

User Profile

Since our db is never going to be large, consider querying all information about a user on every request. It might make some thing easier. This could be middleware that updates req.user or something to that effect. Just a thought

Milestones

Development

• Figure out hosting
• Testing framework
• CI
• Easy deployments (through whatever hosting is chosen)

Features

• Data Models/Database setup
• Consistent URL structure

Home Page

Look ahead for next performance if there isn't a current performance

Login with incorrect username

Pending Attribute of Results Model

It's not being used at all.

Current Performance As Middleware

I might need to rethink this. Right now a person can sign up for a challenge outside of the current performance window

Heroku db is different?

Better Routes

Most of the routes don't make sense

Better Error Page

This has served it's purpose, but we need better

Better Make Challenge Url

Having the url be a post to /challenge/:performanceId doesn't make a ton of sense

Make Challenge Link Shows When User Already Made Challenge

Better initial setup instructions

From #60. We're going to need to add stuff for redis and remove the nginx stuff because it doesn't get used anymore

Current Performance Session Object Will Get Stale

If the user stays logged in from one challenge to the next, the current performance object will get stale. So if we're past the window by a day, refresh the object in middleware