From document:

Project document (30 marks)

1. The team must provide a document that is an update of the former, documenting what was done to
   implement the client-side of the application. What functionalities were implemented? What were
   added that were not planned? What functionalities were removed? Such information should be
   provided in this document.
2. The document must have a section named Views where you document your views and what you
   can do with them (methods). Why are they necessary for your application?
3. The document should list and explain the elements used in assembling the client-side.
4. Describing the animation effects used is also important in this part of the report.

Project code (40 marks)

1. How much of the functionalities you declared in your project are you covering? Is everything
   working as supposed? Is there anything missing?
2. Your code should follow the structure detailed in the beginning of this document. Is it following
   the MVC pattern with the models, controllers, routes and view properly?
3. Is your data being saved properly in the database using the view? How well designed is(are) your
   view(s)?
4. I will test each functionality using the web interface. Are they working? How are you dealing with
   user inputs? Is it on the client side or server side?
5. How well-documented are your functions and codes from your view? Are they easily readable?

Video demo (30 marks)

1. The teams should assemble a video, at maximum 10 minutes.
2. The video should present in the introduction, the motivation and overall idea and goals of the
   project.
3. After, the teams should present the architecture with the technologies and libraries used to assemble
   your project.
4. In the last part, the team should present running examples of the functionalities implemented. What
   do they do? What can be achieved with them?

#62 might be required

🐳

CRNs are not unique!
yay!

move to SIDs

composite key of semester letter and year, g if graduate, hyphen, then crn

something is broken that should be fixed maybe? no clue :)

• add bookmarks
• remove bookmarks
• bookmarks screen, manage bookmakrs
• min / max bookmarks

no more // TODO make configurable; make them configurable

likely define a config.ts file, that brings in things from the environment, and defaults them if it doesn't exist.

such that they can view all of their schedules in one place

Test below fails.

Test below passes.

If a course were to be deleted from the list, it would still stay in the schedules / bookmarks. It doesn't make sense to check whether the course exists or not on removal.

Leave the validation on add.

such as adding a course to a schedule that doesn't match the schedules semester

we have this hard coded, should be query params

aggregate all the things

either do by reaching out to newsline-api, or intergrate newsline api into here via code, or make newsline-api a library itself

so many options

https://github.com/jackharrhy/newsline-api

• page
• limit
• include
• semesterYear
• semesterTerm
• semesterLevel
• subject
• number
• name
• prof
• days
• beginTimeMin
• beginTimeMax
• endTimeMin
• endTimeMax

peridocally, the app should:

• fetch the people api on a daily basis
• fetch course information blobs on a twice-a-week basis
• fetch course information from banner from the current semester on an every-30-minutes basis, since if wish to display waitlists, it be nice to have that information up to date

https://github.com/nint8835/MUNScraper has some logic which might be reusable :)

will mean:

• faster test startups
• explicit test cases
• more than just one semester
• no need to fetch out to MUN for every test run

test cases should also be added / modified to make up for multiple semesters

int parsing required at the very least

• upload doc here

Code:

• API spec outlined in the README implmented in full.
• Tests written for the controllers.
• Some comments added to models / controllers / other places.

Not required but nice-to-have:

• UI ideas of what the app can look like from @AidanLanger.
• Better error handling / messages
• OpenAPI v3

Documentation:

• Info on Models.
• Info on Routes & Controllers.
• Info on design of collections.
• Info on tests.
• Update on what we didn't do that we said we would in the initial document just yet.

From the document

The main goal of the second iteration is to evaluate your server-side code. In the first iteration, your
team has submitted your project's overall idea and goals with some functionalities that your system would like
to provide. Now it's time to code it!
Your team must use an MVC-like framework, as we have seen in the lectures. The project should have
the 'models' with classes and objects that must be manipulated on the server-side. All create, read, update and
delete (CRUD) functions for those objects must be created and documented at this stage. Following the MVC
pattern, your project code must have the 'controller' folder that will manipulate your application's business logic.
All projects must use a database, most of the teams will use MongoDB, but I approved some other options
depending on the project's final goal. Finally, you must assemble an API using express to provide all your
functionalities over HTTP requests. The last part of this deliverable is your server-side tests using Mocha.
Your project will be evaluated into two parts as follows:
Project document (50 marks)

1. The team must provide a document that is an update of the former, documenting what was done to
   implement the server-side of the application. What functionalities were implemented? What were
   added that were not planned? What functionalities were removed? Such information should be
   provided in this document.
2. The document must have a section named Models where you document your models and what you
   can do with them (methods). Why are they necessary for your application?
3. The document must have a section named Routes and Controllers that should report the paths used
   in your API. What each one of them does? How to use them? (Short code-snippets on how to access
   these paths are welcome in your report)
4. You should show how you designed your Data Model collection(s)? Which pattern is it following
   (embedded or normalized)? Why you chose this particular pattern?
5. The document must have a section named Tests documenting the tests performed. Which tools were
   used? Which tests were performed? Why? How complete are your tests? Did they cover all success
   and failure cases?
   Project code (50 marks)
6. How much of the functionalities you declared in the first iteration are you covering? Is it complete
   to start assembling the client-side? Is there anything missing?
7. Your code should follow the structure detailed in the beginning of this document. Is it following
   the MVC pattern with the models, controllers and routes properly?
8. Is your data being saved properly in the database? How well designed is(are) your collection(s)?
9. Are your tests complete, with several success and failing cases? Are you testing your models and
   your full requests properly? Are they covering success and failing cases? Are you doing simple
   and complex use cases for testing?
10. How well-documented are your functions and codes? Are they easily readable?

• username min max
• username min max test
• password min max
• password min max test
• max course bookmarks
• max course bookmarks test
• max schedules
• max schedules test
• max courses in schedule
• max courses in schedule test
• max title / desc length in schedule
• max title / desc length in schedule test
• validate that UI handles super long values correctly