Assignment Stage 2
===== PASS Level (from Stage 1) ===== Part 1 Guest Page
The homepage of your application may look like this sample page. It should have a “Home” button to always bring your application to this page. It should have a signup button to allow new users to register. Existing users should be able to login through this page as well.
This page should have a footer similar to above example. It allows guests sending a simple message to the webmaster. It shows some static links such as contact details, useful links
and social media. Social media links show icons when mouse hovers over them (as shown below).
The homepage should have three buttons in the header, Category, Location and Login. The first two buttons support dropdown menu. They all change appearances when a mouse over occurs.
Guests can view all courses by click the “Browse all courses” button. Each course should show its name, prerequisite, category, location and how long ago it was created.
Each course may have multiple categories e.g. “Web Development” and “Full Stack Dev”. One course may also have multiple locations.
Guests can view the number of thumb ups and downs. However they can NOT vote. Each coordinator has a Gravatar profile.
The course view should support a coordinator tab to list all course coordinators.
When a certain category is selected, then only the courses under that category will be listed. The following example shows all courses under “Web Development”.
Similarly guests can select a location to list all courses running at that location.
The category and location information of a course should be clickable and can act like the category and location buttons shown above.
Part 2 Signup and Login/Logout
===== CR Level =====
You need to complete the Pass Level before attempt the CR level and beyond
When a user clicks sign up, proper validation should be in place. See the error messages below. Only a RMIT staff, who has a
For an existing user, a temporary “login successful” message should be displayed. All the courses will also be displayed to these authorized users.
Now the user can thumb up or thumb down to any courses. However they can only vote once for one course. An error will occur for the second vote.
For a registered user, the Create button is enabled on the dropdown menus of both Category
and Location.
When “Create” is clicked, a form should appear to allow the user to create a new category.
Similarly, a registered user can add a location.
When logout, a temporary message is also displayed. The application returns to the guest mode ( Same as that in Stage 1).
A registered user can also create a new course. The course-creation form also has validation in place. See the error messages below.
User can select category and location. Note multiple categories and locations should be supported.
An image can be added to the new course.
In addition, the “Home” button for a logged-in user should always bring your application to the list of all courses, not to the homepage for guests
===== DI Level =====
You need to complete the CR Level before attempt the DI level and beyond.
A registered user can vote for any courses, but can NOT edit the course which is NOT created by him/her. For example the course “Web Development” was created by Andy Song, so Ali Yavari should not be able to edit it.
“Capstone Project” was created by Ali, so he does have the edit right.
Ali can change everything about the course then update the information. No user can delete a course.
A user can view and edit his/her profile.
Under the user profile, all courses created by this user are displayed, but without category and location information.
User can update his/her profile. However same validation as in the signup still apply here. E.g. they cannot change email to a non RMIT-staff email address, or use a password, which is too simple.
Contact Us
You are required to replace the footer with a link to a new “Contact Us” page where user can fill in an anonymous feedback form. The feedback need to be sent to an email address that you have access, e.g. your RMIT student email account. You may be requested to demo that during the final demo session.
===== 80+ Level ===== Advanced Features
1. If the user types a wrong URL, your application should show a proper message page such as “Oops, we cannot find that page” instead of a Rails error message.
2. Make sure unauthorized person cannot vote nor enter course editing pages.
Admin Functionalities
Now add admin functionalities. Admins can add or modify courses and coordinators. Admin can also delete courses, coordinators and reset votes. Admin can manage registered users.
Note if user A has voted for course X and then the votes for course X are reset to zero, user A should still be able to vote for course X after the reset, but only once.
You must use the following login for the admin. You can assume admin never change name/password.
Admin user name: admin Password: password
It is up to you how the admin page(s) should look like and how these functions are arranged.
===== 90+ Level =====
Images
In the previous levels, course images are stored inside of Rails, which is not really a good idea, because these images may not be placed at a permanent folder at deployment and may be lost. To improve the quality of the application, it is better to store these images on a third- party server such as AWS. You are required to implement this feature.
• https://devcenter.heroku.com/articles/s3
• AWS Simple Storage Service, e.g. S3, is a “highly durable and available store” and can be used to reliably store application content such as media files, static assets and user uploads. It allows you to offload your entire storage infrastructure and offers better scalability, reliability, and speed than just storing files on the filesystem.
API
Your application should support API calls from external sites to retrieve course info, coordinator info, course list and coordinator list. See the following site for example.
• https://about.coursera.org/affiliates
• Developers can get coursera catalog metadata and list courses in their rails application
through the URL provided, which is free to join
Additional Notes
1: Your application is expected to be production ready. Proper test and data validation should be embedded in your application regardless of the level that you are attempting.
2: There is no need for your application to look and behave exactly like the above example. You can make necessary adjustment to improve the design. However the aforementioned functionalities are the minimum requirement and should be well supported.
3: Only the following GEMS should be used in your application.
gem
gem
gem
gem
gem
gem
gem
gem
gem
gem
gem
gem
gem
‘rails’, ‘bootstrap-sass’, ‘puma’, ‘sass-rails’, ‘uglifier’, ‘coffee-rails’, ‘jquery-rails’, ‘turbolinks’, ‘jbuilder’, ‘carrierwave’, ‘ “mini_magick” “font-awesome-rails” ‘bcrypt’,
4. You are required to deploy the final version onto Heroku.
5. In the README.md file of your application, you should state
– Name(s) & student number(s) of the development team
– The highest level you attempted, e.g. CR, DI or 90+
– The time sheet for each team member (see Point 6 below)
– Heroku deployment URL and the last Heroku deployment log
6. For stage 2, you are required to keep track of the hours that you spent on the development including testing, discussion, reading.
For one professional developer working alone, the expected completion time is about 4 full days.
For time tracking purpose, we recommend toggl.com, a free online time tracker. You can sign in with your RMIT student account (under “SIGN UP WITH GOOGLE”). This log needs to be included in the README.md file (See Point 5 above).
7. Your assignment should hosted on a PRIVATE bitbucket or Github repository named as RAD19_group_{studentNumber_small}. You should update your repo as frequent as possible.
If you have completed Stage 1 and would like to start working on Stage 2 before your Stage 1 Demo, you can make a brand called “stage1” to store the stage 1 version.
Submission
– This assignment should use PRIVATE bitbucket or Github respository to host all your Rails files
o Create a private repo named as
RAD19_indiv_{studentNumber}
–
o Make a branch called “submission” for the final submission
o Invite the following people as default reviewers to your project
–
o Make a pull request to merge your branch submission to branch master
and include the following default reviewers (to ensure our access)
o The due date: 11:59pm of the 26th of May. o
– Warning
o You will receive ZERO mark if you don’t host your assignment in bitbucket or Github before the due day (see details later).
o You will receive ZERO mark if your application fails to run (see details later).