Home

NOTE: Below is background information/general docs on the topic of this project. If want to know how to be able to build & deploy the project then please read our Deployment Guide

Our server

The server we use to host our website is rented from Digital Ocean. The operating system is CentOS 7 and its IP address is 138.197.6.26 but all you have to remember is our domain name: conucourseplanner.online. If you can remember the name but need to know the IP address, you can always run nslookup conucourseplanner.online. Unfortunately all devs currently sign onto the server as the same user: david. This quirk may change in the future.

We have three processes related to this project which are constantly running on the server:

1. Our main Tomcat server

• Installed at /opt/tomcat
• Started via sudo systemctl start tomcat

This serves the frontend to all clients as well as a REST API. Our REST API provides a number of functions callable by the client via AJAX requests in the front end. Each of these functions is described in detail on our REST API Spec page.

We have some rudimentary logging done by our backend via log4j. Normal logs (done with logger.info() in the Java code) will be written to the file named /opt/tomcat/logs/courseplanner.log and system logs (done with System.out.print(), System.err.print(), Exception.printStackTrace()) are written to /opt/tomcat/logs/catalina.out.

IMPORTANT: We are currently (as of Oct 8th, 2017) running tomcat with memory profiling enabled. This was done by updating /opt/tomcat/bin/setenv.sh, adding the options -agentpath:/opt/yourkit/YourKit-JavaProfiler-2017.02/bin/linux-x86-64/libyjpagent.so and -XX:+HeapDumpOnOutOfMemoryError to the CATALINA_OPTS variable. This change can be reverted by replacing setenv.sh with the default one that comes with tomcat which I backed up in a file called setenv.backup.sh

2. Our MongoDB database server

• Started via sudo mongod --auth --dbpath=/opt/cp-course-db & sudo systemctl start mongod
• View contents of db via mongo -u username -p password --authenticationDatabase=admin (this command starts the mongo shell)

Two users are allowed to interact with the DB:

• User 1: username=username, password=password - this user has read-only access

• User 2: username=tranzoneAdmin password={secret} - this user is the dbOwner. he is god. he can create. he can destroy. fear god.

The backend of our website (the REST API) communicates with this server in order to perform the aforementioned functions.

We have two databases courseplannerdb (used only by prod version of website) and courseplannerdb-dev (shared by all development versions of website). Each database contains two collections:

courseInfo which represents information related to individual courses such as name, credits, pre-requisites, etc.

courseSequences which represents the sequence of courses recommended to students by Concordia that they should take from their first to last semester.

3. Our webscraper cron job

• Crontab entry: 0 0 * * * sh /opt/cp-webscraping/scrapeTheWeb.sh "$(< ~/tranzoneAdminPass.txt)" --prod

This is a cron job which periodically (currently every 24 hours) runs a shell script which performs all of our data acquisition (scraping) by downloading various public concordia webpages, pulling and formatting relevant data out of the pages, then storing the results in the MongoDB database. The fact that it runs periodically ensures that changes to the concordia site will be continuously integrated into our database.

Travis CI integration

As per our .travis.yml file, we have set up Travis Continuous Integration. As such, each time a commit is pushed upstream, travis will attempt to build our application through our top-level build script: /scripts/buildApp.sh. In the case that the commit is made to the master branch, Travis will also deploy our application as well as our webscraping sources to our production hosting environment.

This ensures that all of our commits to master get automatically deployed to the actual website, meaning that we will only do manual deploys during development.

We also have a little picture on our repository's front-page README file which displays the current build status of the master branch (passing/failing).

React frontend

We have built a frontend to our application using react/ES6, and we build/compile it with babel and browserify.