deliverable.org

Tyr

Project Name Background

Tyr (pronounced teer) is the Nordic god who presides over matters of law, justice and wisdom. This name is befitting to our project as we provide a strict grading service that will uphold the rules set by educators in their test scripts. In addition, Tyr can be viewed as a pun of the word tear (like teardrop), as the students will be sad when their code fails the test cases.

Introduction

About

Tyr is a web application that helps educators assess student assignments on a scalable, fault tolerant, and uniform testing environment. The professor or educator will write a script to gauge the correctness of user submitted code. The students will upload their submissions and run the professor defined tests on their code, in a unified environment via a web interface. Tyr differentiates itself from other grading services with its complex management of ephermal single-use containers. The utilization of containers provides a few key features:

1. Fault tolerance: Improper code will not take down the whole server
2. Scalability: Tyr is able to handle many clients
3. Uniformity: Every container environment will be the same

In the back end, Tyr manages a collection of microservices to create identical and ephemeral testing environments via a Kubernetes cluster hosted on Google Cloud. For the front end, Tyr provides a web interface (https://tyr.tools) to upload code to be processed.

Similar tools

• Mimir - a scaling platform for testing class room code.
  • What makes ours different is we our aiming our tool for more than

  just classrooms.

  • We are aiming to make Tyr have plugins to other CMS APIs such as

  the Canvas CMS.

  • They have set languages. We are making it so we have predefined

  languages but a user can easily add a new language from the web interface easily.

• Codio - An online IDE with a terminal to interface with code.
  • This requires users to use a terminal. While ours is a web interface with a easy-to-use GUI.
  • Ideally we will be able to add a terminal interface, but only when wanted.
• repl.it - A online IDE that supports many languages.
  • They are an IDE which could be used to run code consistently, but we want a platform to test code, not develop.
  • Users would be able to see test cases or a tester would have to upload everyone’s files themself after using another service to have them handed in.

Technical Plan

This section’s purpose is to list and describe the technology and software used for team communication and development.

Category	Type	Software
	Communication
Email		Stevens email
Instant Messaging		Slack
	Collaboration
Document Collab + Code		Github
Task Delegation		Trello(Spring board)
	Web Development
Supported Browsers		Chrome, Firefox
Front End		NodeJS + React/Redux + SASS
Back End		Golang
Database		MongoDB
Scaling/Management		Kubernetes

Team Members

Client

The client is a professor from Stevens Institute of Technology.

• Brian Borowski
  • Email: [email protected]

Team Members

Below is the list of Team Members and roles. The roles were more needed for the Senior D requirement. In actuality all team members work collaboratively on all parts.

• Andrew Chen - UX Designer/Frontend Developer
  • Grader
    • CS 546
    • Professor Hill
    • [email protected]
  • Email: [email protected]
• Taylor He - Backend Developer/Software Engineer
  • Email: [email protected]
  • TA
    • CS 306
    • Professor Triandopoulos
    • [email protected]
• Rob Herley - Frontend Developer/Kubernetes/DevOps
  • Email: [email protected]
  • TA
    • CS 146
    • Professor Herc
    • [email protected]
  • TA
    • CS 546
    • Professor Hill
    • [email protected]
• Jonathan Pavlik - Project Manager/Backend Developer/Software Engineer
  • Email: [email protected]
  • TA
    • CS 385
    • Professor Borowski
    • [email protected]
• Alex Supkay - GCP/Kubernetes Manager
  • Email: [email protected]
  • TA
    • CS 511
    • Professor Bonelli
    • [email protected]

Delegation of Tasks/Completion Schedule

We are using an agile development system as it allows us to work more concurrently on project flow. To do this we use a Trello Board with Esprint planning. Which you can find https://trello.com/b/U5NIyhQs/senior-design.

Tasks Completed by week.

<2019-02-07 Thu>-

• Andrew Chen
  • Assigned Previous Week
    • New UI Mockups
  • Finished Previous Week
    • New UI Mockups
  • Todo Next Week
    • New UI Mockups Continued
• Taylor He
  • Assigned Previous Week

• Proper Error Codes for Existing Routes
• API Documentation
  • Finished Previous Week
• Proper Error Codes for Existing Routes
• API Documentation
  • Todo Next Week
    • Bulk add users api
• API Documentation
  • Robert Herley
    • Assigned Previous Week
      • Look into servers offered by sys admin
• Flesh out designed pages
  • Finished Previous Week
    • Look into servers offered by sys admin
• Flesh out designed pages
  • Todo Next Week
    • Look into servers offered by sys admin continued
• Flesh out designed pages continued
  • Jonathan Pavlik
    • Assigned Previous Week
• Security and admin role implementation
• Fix security of other routes
  • Finished Previous Week
• Security and admin role implementation
• Fix security of other routes
  • Todo Next Week.
    • Clean up gridfs
• Fix create assignment files upload
• Save assignment as file
  • Alex Supkay
    • Assigned Previous Week
      • Venture Center Talk documentation
    • Finished Previous Week
      • Venture Center Talk documentation
    • Todo Next Week
      • Venture Center Talk documentation continued
• Kluster maitnence

Components

This section will be expanded as we work through several stages of MVPs.

Backend: APIs for front end to interact with.

Determine if submission of code is of proper type.

Can specify type of submission such as zip, tar.gz, etc.

We need to correctly identity that the submission is of the correct type.

Limit Number of Submissions

If specified we need to limit the number of submissions to test allowed.

Need service to relay output.

An Api that formats stdout in a specific format to send to front end.

Make a call to Kubernetes to spin up job upon submission.

Need a service that interacts with Kubernetes.

Needs to be able to know which job it should be spinning up.

Logging

For Admin purposes we need proper log outputs that are easy to read.

Also needs to integrate into any service.

Database Schema

Mongo Collection Types

Users

Courses

Assignments

Submissions

Users Collection

   {
	  "_id": ObjectId,
	  "email": String,
	  "firstName": String,
	  "lastName": String,
	  "password": String,
	  "enrolledCourses": [
	      {
		  "courseID": Courses._id,
		  "enrollmentType": String
	      }
	  ]
   }

Courses Collection

   {
	  "_id": ObjectId,
	  "department": String,
	  "number": Number,
	  "section": String,
	  "semester": String,
	  "professors": [Users._id],
	  "assistants": [Users._id],
	  "students": [Users._id],
	  "assignments": [Assignments._id]
   }

Assignments Collection

   {
	  "_id": ObjectId,
	  "language": String,
	  "version": String,
	  "name": String,
	  "description": String,
	  "supportingFiles": String,
	  "dueDate": ISODate,
	  "published": Boolean,
	  "testBuildCMD": String,
	  "tests": [
	      {
		  "name": String,
		  "expectedOutput": String,
		  "studentFacing": Boolean,
		  "testCMD": String,
	      },
	  ],
	  "submissions": [Submissions._id]
   }

Submissions Collection

   {
	  "_id": ObjectID,
	  "userId": Users._id,
	  "submissionDate": ISODate,
	  "file": String,
	  "errorTesting": Boolean,
	  "cases": {
	      "studentFacing": {
		  "pass": Number,
		  "fail": Number
	      },
	      "adminFacing": {
		  "pass": Number,
		  "fail": Number
	      }
	  }
   };

Frontend: The interactive elements of our application

A simple form page Mock up.

Must have submission upload.

Test script Upload.

Gives message for incorrect submission upload.

Gives message for max number of attempts reached.

Displays number of attempts left.

A list of UI flows

This section is meant to show where each button/element takes you in the application. Some flows are purposefully left out because they are obvious, and take up unnecessary space, such as any file upload/download button, or navigating to login/signup from the homepage, etc.

The application has some screens that although serve the same purpose, are different in appearance for Students and Professors in order to allow for each role to perform different tasks.

Kubernetes: The scaling and environment builder

Need a C++ Environment that can run shell test scripts (First MVP).

Requires setting up Kubernetes infrastructure.

There’s a lot of work to this even though it sounds simple.

The ability to spin up jobs per user.

Completion Schedule

Here is our timeline of what we expect to have done. Note this schedule is landscape.

Date	Front End	Back End	Kubernetes	Other/Notes
10/11/2018	Mockup Designs	Logging boilerplate	-	-
10/18/2018	React skeleton code	Microservice Health Monitor	-	-
10/25/2018	Create account	DB schema design for login	Create Deployments for microservices	-
		Store student and professor accounts	Certs
11/01/2018	Login, logout frontend with jwt encryption	Login authentication API with jwt	Dockerize deployments	-
11/15/2018	Dashboard view		Service networking
		DB schema design for courses, assignments, submissions	Ingress Controller	-
11/22/2018	Assignments view component	File upload API	-	-
	Professor view: Assignment creation		_
11/29/2018	Deomable UI For submitting Grading	File type verification, submit assignment route	-	-
12/06/2018	Student view: Layout	Integrate with Kubernetes API for creating jobs	-	-
12/06/2018	Student view: Course view	Integrate with Kubernetes API (cont)	-	-
	Student view: Assignment view	Integrate with Kubernetes API (cont)	-	-
12/13/2018	Student view: Assignmnet Submission	API for relaying Kubernetes output to front end	-	-
1/24/2019	Professor view: Student Submissions	User permissions create course	_	_
1/31/2019	Provessor view: Student Submission	User permissions view health checks
2/07/2019	Course Creation Page	Course Creation endpoints
2/14/2019	Professor Course View	Add Students to Course endpoints
2/21/2019	Student Course View	Add Students to Course endpoints (cont)
2/28/2019	Professor Course View (Revision)	File upload API (cont)	Migrate to Stevens servers from GCP	Target: Backend beta
3/07/2019	Professor Course View (Revision)	Testing (Endpoint)	Migrate to Stevens servers
3/14/2019	Professor Course View (Revision)	Testing (Endpoint)	Migrate to Stevens servers
3/21/2019	Student Course View (Revision)	Testing (Functionality)	Migrate to Stevens servers
3/28/2019	Student Course View (Revision)	Testing (Functionality)		Target: Release Candidate
4/04/2019	Final UI verification	Bugfixes from testing
4/11/2019	Testing, bugfixes, code cleanup	Bugfixes
4/18/2019	Testing, bugfixes, code cleanup	Code cleanup
4/25/2019	Buffer week	Buffer week		For potential bugs
5/02/2019	Documentation	Documentation

• First MVP (Fall Semester): To have a small demo web app that only accepts very specific code types and test scripts.
• Second MVP
  • Having a more extended web app where we can have users create assignments and pick a programming language.
• Final Product
  • Having hopefully our final product finished. Where adding a programming language can easily be added, we accept many file types and we are fully scalable. Hopefully we can give users a terminal interface through our web page as well.

Dependency Diagram

Below is our dependency diagram.

\FloatBarrier

Venture Center

Filling out the business paperwork for venture center.