yamun's Introduction
yamun's People
Forkers
keenan-nicholsonyamun's Issues
Iteration 3
From document:
Project document (30 marks)
- 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. - 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? - The document should list and explain the elements used in assembling the client-side.
- Describing the animation effects used is also important in this part of the report.
Project code (40 marks)
- How much of the functionalities you declared in your project are you covering? Is everything
working as supposed? Is there anything missing? - 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? - Is your data being saved properly in the database using the view? How well designed is(are) your
view(s)? - 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? - How well-documented are your functions and codes from your view? Are they easily readable?
Video demo (30 marks)
- The teams should assemble a video, at maximum 10 minutes.
- The video should present in the introduction, the motivation and overall idea and goals of the
project. - After, the teams should present the architecture with the technologies and libraries used to assemble
your project. - In the last part, the team should present running examples of the functionalities implemented. What
do they do? What can be achieved with them?
user model tests
course api tests
run tests in ci
#62 might be required
schedule api tests
people directory
dockerize
๐ณ
crn -> sid
CRNs are not unique!
yay!
move to SIDs
composite key of semester letter and year, g if graduate, hyphen, then crn
replace mongodb lol
fix ics such that it works with google calender
something is broken that should be fixed maybe? no clue :)
bookmark model tests
bookmark model + controller
use uni. cal. api on frontend
schedule model tests
bookmarks ui
- add bookmarks
- remove bookmarks
- bookmarks screen, manage bookmakrs
- min / max bookmarks
make configurable things configurable
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.
export as ics
user passwording hash + salt
user api tests
find all schedules for the logged in user
such that they can view all of their schedules in one place
user creation race condition
remove course existence validation from schedule/bookmark course remove
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.
add / change tests to use things from semester2
such as adding a course to a schedule that doesn't match the schedules semester
create auth middleware for routes that require auth
user input in export ics
we have this hard coded, should be query params
bake in newsline
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
user permissions
add filters that already exist for course searching to the frontend
- page
- limit
-
include - semesterYear
- semesterTerm
- semesterLevel
- subject
- number
- name
- prof
- days
- beginTimeMin
- beginTimeMax
- endTimeMin
- endTimeMax
after initial data pull, keep data up to date
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
university calendar intergration
https://github.com/nint8835/MUNScraper has some logic which might be reusable :)
hard code test data, with smaller subset and multiple semesters
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
start and end times, duration are in incorrect format for ICS files
int parsing required at the very least
Iteration 2
- 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)
- 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. - 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? - 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) - 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? - 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) - 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? - 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? - Is your data being saved properly in the database? How well designed is(are) your collection(s)?
- 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? - How well-documented are your functions and codes? Are they easily readable?
add sensible limits to things around the app so things don't overflow
- 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
bookmark api tests
use people api on frontend
course model tests
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ๐๐๐
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google โค๏ธ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.