Architecture

Languages and Framework

Our application will be created with the Django framework (Django 5.1). Our code will be written in Python (3.13.0).

Building and Package Manager

Code Assignments

Deployment

Deployment is fairly simple. Once the DJANGO_SETTINGS_MODULE is set up to work with WSGI, you run a new thread using gunicorn (file).wsgi. Once this is done, all it takes to update is a git pull and re-run the server. Thomas Kareka will be running the website using a personal linux server running Ubuntu 24. (should be accessible through direct ip, don’t have a domain to host it at) While it would be possible to set up a script to reboot and pull from our github repo daily, this most likely isn't necessary. For testing purposes, a Django debug server is very similar to a server in production.

Virtual Machines and Containers

A virtual machine is not necessary. While Python is mostly universal, Gunicorn is not, but we have a server ready to deploy to. As a backup, we can use PythonAnywhere. A container is also not necessary, but at the very least, we should be using a Python virtual environment.

SPA or Traditional

Our application will not be a SPA. Although a SPA is possible with Django, the design that we created (as seen in the Design section of the wiki) involves the use of multiple pages. The user will navigate to different pages on the app, which each have a specific functionality.

URL Space

Django URLs follow the format /app/page/subpage, using <type:var> for pages where data must be passed through.

/coldcall/ - Main page
/coldcall/<int:pk> - Main page with course selected
/coldcall/student/<int:pk> - Student metrics page

It should be possible to change the template django uses for each view by getting and parsing the user's User-Agent.

REST API

Views

Database Schema

We will be using SQLite for our database, interfacing through django.db.models. Users will simply use the default configuration from django.contrib.auth, as not much else needs to be stored for user authentication itself. (just user, name, and hashed password).

Each model will cascade down through a many-to-one system, all leading back to the original user.

Class(models.Model):

• professor_key: Foreign key reference to the user in which the class belongs to, should delete all nested data if deleted. (models.CASCADE)
  
• class_name: String of characters limited to 200 characters. (models.CharField)
  

Student(models.Model):

• class_key: Foreign key reference to class that the student is part of.
  
• first_name: CharField limited to 100 characters.
  
• last_name: CharField limited to 100 characters.
  
• seating: Stored using a CharField, has a list of potential seating arrangements using models.Field.choices, combination between front/back and left/center/right or none.
  The following could be used to minimize recalculating existing data or additional db calls on the class list page:
  
• total_calls: IntegerField
  
• absent_calls: IntegerField
  
• total_score: IntegerField (Average score would then be calculated from total_score/(total_calls-absent_calls))
  

StudentRating(models.Model):

• student_key: Foreign key reference.
  
• date: Date or UNIX timestamp in which the rating was created. (models.DateField)
  
• attendance: Was the student present when called on? (models.BooleanField)
  
• prepared: Another boolean to indicate whether the student was underprepared or not.
  
• score: IntegerField, limited between 1-5.
  

Common Queries

In Django, queries are handled through django.db.models. For example, to get the first 20 ratings from a student, you would import models.Student and return Post.objects.order_by("-date")[:20]. Retrieving a single object is also simple, through Student.objects.get(id=student_id). Saving changes to a database object requries retrieving it, modifying it, and simply calling Object.save().