illinois / clickin Goto Github PK

Right now our flask application is using global variables to keep track of the current instructor, list of students, question, answers, etc. on a per-room basis, but this needs to be stored in a database. I think we should use an in-memory database like redis to preserve global state in our app while giving faster response times than a regular SQL database

To ensure that reviewers can understand commit messages and pull requests quickly, guidelines on their formats and content should be established and documented accordingly.

For commit messages, How to Write a Git Commit Message is a blog post that discusses what I consider good guidelines for commit messages:

1. Separate subject from body with a blank line
2. Limit the subject line to 50 characters
3. Capitalize the subject line
4. Do not end the subject line with a period
5. Use the imperative mood in the subject line
6. Wrap the body at 72 characters
7. Use the body to explain what and why vs. how

Additionally, the blog post also provides an example of a commit message that lists resolved and related issue numbers at the bottom:

Resolves: #123
See also: #456, #789

Commit 042edf7 is an example of what I would consider an ideal commit message format.

For pull requests, it is important to provide a big-picture overview of what the pull request is doing in the first comment. For pull requests related to the frontend, it is also valuable to provide screenshots of new or updated UI. The first comment of #45 is what I would consider an ideal example of both of these principles.

Adding the NCSA license to the ClickIn project

Component that's going to be used in student's default view after Authentication. Contains a list of classes they're in and active polling sessions they can join.

Wireframe:

We need to add a .gitignore for .pycache and any other files

Set-up Google Apps Authentication

We need to figure out how we want to structure our Python unit tests, and which framework we should use. unittest is part of the Python standard library, but is more barebones. pytest and nose are some popular alternatives which are a bit more full-featured.

Clicking on a question on #32 will lead here. Detailed view of question along with answer options and ability to start polling.

Wireframe:

Looks like we will need to contact someone from the school to get this set up. We need a URL similar to https://queue.illinois.edu/ which needs to be whitelisted by the school. Upon authentication, we will receive a parameter called eppn which I believe is the user's school email, i.e. [email protected]

It would be good to set up some sort of linting/formatting requirement before the codebase grows. I'm partial to black, which is part of the PSF. It has plugin support for most major editors and can be set up with CI to check for proper formatting at PR time.

flake8 checks code compliance with the PEP 8 Python style guide. We could run this after black to catch any other linting errors. The downside of solely using flake8 is that it won't fix these issues for you - black will happily format your code and fix most problems.

Of course, introducing style requirements does raise the bar to commit a bit. If we do implement style guidelines, we should ensure it's as easy as possible to install and run the needed tools.

We are using the regular WS protocol, but we should be using WSS instead. The difference is similar to that of HTTP and HTTPS. Data is encrypted over SSL/TLS.

For example, "80Ok" is hard-to-read since a 0 is similar to a O. So are 1, I, and l.

To facilitate development of the Flask API, a consensus should be reached on how the frontend and backend will communicate through this API. Some design points to address:

1. What are the API endpoints? (E.g. is the target polling session endpoint "join.click.in/xYz6" or "click.in/xYz6"?)
2. What types of requests do these endpoints support? (e.g. HTTP requests: GET, PUT, POST, DELETE)
3. What are the parameters to each endpoint? (e.g. three-character session hash)
4. What functionality should each endpoint support? (e.g. "it should route user to target polling session page and authenticate if previously logged in.")
5. What data should responses return, and in what format? (e.g. a JSON list of a student's/professor's courses)
6. How should errors be handled? (e.g. 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 500 Internal Server Error)

A consensus should be reached on which database model (https://en.wikipedia.org/wiki/Database_model#targetText=A%20database%20model%20is%20a,uses%20a%20table%2Dbased%20format.) and schemas should be used. These decisions should aim to make CRUD operations efficient and the database scalable.

Below are pictures from today's meeting of ideas for schemas:

We should consider using a static type checker and PEP 484 type hints in our codebase.

There are a few benefits to using type annotations for function signatures - they help self-document the codebase as it grows, and they help catch type errors which may introduce bugs into our code.

While type hints are a built-in part of the Python language, Python doesn't validate the correctness of these types. This is where a static type checker would be useful, which could be run during development and by CI at PR time. The de-facto standard is mypy, but pyre is also an option.

We will need to generate a short url to quick-join a polling session. For example, click.in/xYz6. The code that's generated should be easy to read/type (no special characters). Think of edge cases of specific words we want to avoid (censor out swear word possibilities).

The main Remote screen should be centered on the page.

I also added some flair to the "waiting for question" default that animates the ellipsis to be "loading"

Instructors should be able to view an overview of questions in a polling session. If they have a pre-determined list of questions they should be able to select a question to poll for. They should also be able to add questions from this page.

Here's a rough outline of a wireframe for guidance:

Self-explanatory. Design wireframes as you're working so we can discuss UI.

Features:

1. 5 option buttons
2. Question Display
3. Transmission Confirmation
4. Text Input

Add a guide for people interested in contributing to the project, especially those who did not attend earlier HackNights.

Related to #30 .

Given a short URL (e.g. join.click.in/xYz6), it should route user to target polling session page and authenticate if previously logged in.

Display a message that says something along the lines of "waiting for instructor..." if there is no instructor in a room

We could create a library of reusable React components that can be called for things like buttons, lists, question types, etc. instead of using bootstrap. Thoughts?

We probably want some sort of CI (Travis or otherwise) setup w/ our backend so we can run tests on PRs before merging.