search

selfint / degree-planner

Plan your Technion degree.
https://degree-planner-two.vercel.app
Apache License 2.0
0 stars 0 forks source link

readme

Technion degree planner logo

Test Status Data

Technion Degree Planner

A tool for planning an entire Technion degree.

Why?

For fun, this is an interesting project to work on.

Data sources

  1. ~Technion student services: https://students.technion.ac.il/local/technionsearch/course~ (deprecated)
  2. Cheese fork histograms: https://michael-maltsev.github.io/technion-histograms
  3. Technion SAP: https://portalex.technion.ac.il
  4. Technion catalogs: https://ugportal.technion.ac.il/%d7%9e%d7%99%d7%93%d7%a2-%d7%9c%d7%a1%d7%98%d7%95%d7%93%d7%a0%d7%98%d7%99%d7%9d/%d7%a7%d7%98%d7%9c%d7%95%d7%92-%d7%9c%d7%99%d7%9e%d7%95%d7%93%d7%99%d7%9d/

Problems to solve

  1. It's hard to iterate on entire degree plan: These are the current solutions:

    • Sogrim doesn't take into account course prerequisites.
    • CheeseFork only supports current and previous semesters.

    Both solutions also don't support rapid course re-ordering.

  2. It's hard to find interesting courses that also have high median grades:

    • Sogrim has no course search capabilities (other than course code -> name translation).

    • CheeseFork has amazing data, but missing advanced query capabilities:

      1. No way to sort courses by median grade.
      2. No way to get course median by semester/professor.
      3. Course median doesn't take into account course prerequisites median (so you might find a high median course, but its prerequisites have low medians).

Data model

The static/_catalogs directory contains files representing degree and course information.

The goal is to represent each degree requirements in a static file format that is easy to create from the catalog (currently manually, hopefull in the future automated), and easy to parse from code.

The benefit of this data model is that non-technical users can easily suggest fixes to wrong requirements. For example if the 3_year/core/points requirement is wrong, (e.g. it's 84 and should be 84.5) all that is required to fix it is changing the content of the file from 84 to 84.5.

Generally, information in these files is unstructured, and parsed at runtime. Again the benefit here is that no technical knowledge is required to fix mistakes. If courses are missing from a requirement, all the is required is to copy paste text containing the course codes, and pasting it in the file.

In the future data this might change, since there are also downsides to unstructured data:

  1. A lot of unnecessary data.
  2. Diffing files isn't very informative.
  3. Removing courses from a file is a bit harder (requires an automated find & replace tool).
  4. Technically slower that storing a deduplicated list of course codes, but this isn't a big issue since we are dealing with very small amount of text (entire catalogs are just 10s of kbs).

Year

Create a directory for each year. There are no connections between years.

University-wide courses

For course lists that are relevant for all degrees, like english and malag (general) courses, create a file with the list name in the year's shared directory.

Degree

Create a directory for each degree, in each year.

Degree path

For each way to complete the degree (path), create a directory inside the degree directory.

Recommended semesters

Each degree path has a recommended directory, create a file called semesterX where X is the semester number (start at 1) containing the recommended semester courses.

Requirements

Requirements can be complex, as such their representation has to be flexible, while sticking to plaintext files only*.

Each degree path has a requirement directory. This directory contains the subdirectories named after requirements to complete the degree. A requirement directory can also contain:

  1. courses file - A list of courses relevant to the requirement. If this file is missing, the courses are taken recursively from courses files in subdirectories.

  2. count file - A file containing a single number specifying the amount of courses from the courses file that are needed to fulfill the requirement.

  3. points file - A file containing a single float specifying the points of courses from the courses file that are needed to fulfill the requirement.

  4. subdirectory - Each named after a sub-requirement needed to complete the requirement, they are also requirements themselves.

  5. amount file - A file containing a single number specifying the amount of choices from the subdirectories that are needed to fulfill the requirement.

  6. overflow file - A file containing a single line specifying the list to transfer overflowing points and count requirements to.

    Point overflow - some lists (like the "science" list in the CS degree) have an amount of points required, with "overflowing" points transferred to a different list ("list b" in the CS degree's case). To achieve this, any condition that has overflow can add an "overflow" file, with the name of the requirement it overflows to.

    In the future we might need to more fine-grained control of overflow, such as "only points" or "only specific courses". Any of these should be possible by making overflow a directory analogous to a nested requirement.

    Both the source requirement and the overflow requirement must have the same type of requirement (either points or count), currently there is no support for mixing the two.

  7. hooks.js file - A file containing JavaScript code that will be executed in the from of (<content>)(semesters, progress), where semesters are the courses the student has taken, and progress is the progress object for the requirement (see the src/app.d.ts file for the structure of the progress object).

    The hooks file can be used to implement complex requirements that can't be represented in the current data model. For example, in the 4 year CS degree the student must take 26 points from 3 specializations, but they can choose from 11 specializations. Without the hook, the points would be counted from all specializations the user took courses in. With a hook, we can sort the specializations by the amount of points taken, and take the points from the top 3 specializations.

Acknowledgements