Task 3 Web Development 2015
Task 3: Web Development
Hi everyone! We come to the third and final main task of the web development induction process. Your Task 1 involved work with the frontend, and the Task 2 involved a greater portion of the backend. Your Task 3 is going to be an intermediate between these two, involving some work on both the frontend and the backend. Overall, this task will be easier than task 2, in terms of new concepts.
Your task is to create a basic quiz platform. This platform will allow users to login and submit questions and publish them for other users to answer. The platform shall keep track of the user’s score and answered questions.
- Please READ ALL THE INSTRUCTIONS ON THIS PAGE CAREFULLY before you begin your task. It is apparent when you ignore clear instructions and will reflect poorly in your evaluation.
- Write readable code. Many of you have written code without indentation and with overall poor readability. Pay attention to your variable names and object names.
- Write good commit messages. A good commit message should be short and to the point. It should give a <10 word overview of what exactly the commit does. Messages like
Updated XYZ.html and
Change #6 etc. are examples of poor commit messages. A good commit message would be
Update ABC.js to add sin() function. This is a great short guide on writing commit messages. Please go through it.
- Commit frequently, but not THAT frequently. A commit must have one definite basic logical change. A commit for changing a single character is not encouraged. Please do not flood your repositories with commits – a commit is not equal to a Ctrl+S. At the same time, don’t make a single commit change 20 files and 2000 lines of code.
- Test your own code thoroughly. Your code should be working for you, at the least. Do not submit code that you have not completely tested.
- Write a proper README. There are more instructions on this later in the page. This is perhaps the most important instruction here, apart from the first one.
- Create a user management system. A user should be able to register with three fields: name, unique username and password. Store the user credentials securely in the database. Further instructions all apply only for the user who is logged in.
- Create a route for submitting a quiz question. This route must be accessible only to logged-in users. There should be a text field for the question and four more text fields for the answers. All questions shall be single-answer MCQs with answers for A, B, C and D. The correct answer option must also be provided.
- On successfully submitting a quiz question, it must be stored in the database for future access.
- Create another route URL for answering questions which will only be accessible to logged-in users. Here, it will display a list of questions which have not yet been answered by the user. The questions will be displayed from all submitted questions by all users (except the current user’s own questions). Upon selecting an answer for any question, it must request the server with that question ID, and the server must respond with the right answer option. Also, the server must update the user’s score with +1 for right and -1 for wrong answer. Also, the server must mark the particular question as “answered“. Previously answered questions must no longer be shown to the user.
- The interface must be neat and easy-to-use. Unlike Task 2, frontend work will be considered on this task.
- A logged-in user must be able to view his own score at any time.
- If a non-logged-in user tries to access any of the quiz-related pages, it must redirect him to the login page automatically.
- Make sure you’ve done all the Basic Round requirements before attempting the bonus round.
- For the bonus round, allow the user to attach a category to the question when submitting. This category must be among a dropdown of predefined categories, not a text field. Keep five to six categories. All publicly available questions will be available for answering on a single route, say
/quiz, as per the basic round. However for the bonus round, on navigating to a route like
/quiz/sports, it should show only the questions in the category “sports”. On opening
/quiz/movies, it should show only the related category questions, etc. This should be in addition to the normal
- Keep a basic leaderboard that is public. All users’ score will be visible there, ordered by score. This leaderboard will be on a separate route, like
/scores. It will be even better if you show the leaderboard in the form of a bargraph, or if you allow sorting by both username and score.
- Any other improvements that you can make are good. Consider changes like a route for keeping track of answered questions, along with the given option and the right answer, so that users can keep track of where they went wrong. Also consider management of questions by the user who submitted it: a user who submits a question can make edits or delete it later. Also consider marking submitted questions with a difficulty rating, like “difficult” questions which give more than one point.
- Note that any number of changes from the bonus round may be attempted. It is not necessary to do all of them.
- Push EXACTLY the code that you write. Any external or downloaded modules, auto-generated files etc should not be pushed to the repository. Ask your mentor about which folders to push to the repo and which ones to ignore depending on the backend system you are using. The auto-generated files and modules to download must be explicitly mentioned in the build instructions in the README.
- For this task you are permitted to use the backend system and modules of your choice. You will not be questioned on it. However, you must list out the modules you use in the README.
- Every submission MUST include a comprehensive README.md file. Submissions with an incomplete or empty README will not be considered.
- The README must contain an overview of the project and how you went about it.
- It should contain a list of the server routes you are using.
- It should illustrate the tables/collections used in your database and the information and relations you are modeling.
- It must contain build instructions. The build instructions must be extremely comprehensive and MUST work. Test out your own build instructions by cloning into a new local folder and seeing if the server still works. Basically it is a step-by-step approach explaining how to set up the server you have in your own local folder into some other computer.
- The build instructions must provide links for downloading ALL necessary software, including the server and the database system. It should also provide any other links / start scripts that require for setting up the server.
- Include a short description of each and every external module or library that you use in the project. We do not know what libraries you plan on using. The description will help us to see what the module is being used for. Also provide a link to the documentation/website/Github of every module/library you use.
- Include various screenshots of the website in action.
Before you begin
- Create a new repository on Github. Also clone this repository to a local directory. We shall henceforth refer to this directory as your “project root”.
- Copy this URL (https://integram.org/h38zjstxdle78go09) and add it as a webhook to your newly created Github repository. To do this:
- Go to Settings -> Webhooks and Services -> Add Webhook
- Enter your password if Github asks you for it
- Enter the URL above into the “Payload URL” box.
- The “Content Type” does not matter. Make the “Secret” field blank.
- On “Which events would you like to trigger this webhook?”, select “Send me everything”.
- Make sure the “Active” box is checked. Click “Add Webhook”
- Open your project root locally. You can now push any code you commit locally by using
During the task
- Push your local commits frequently. We cannot know the pace of your updates if you push really late. Don’t delay pushing your code till the last minute.
- At any time during the task period, you can comment the details of your repository on this page, in this format:
Github URL: <url link>
Name: <your name>
Roll Number: <your roll number>
Server system: <name of server system eg. PHP+Apache, NodeJS, Flask etc>
Database: <name of your database software eg. MySQL, MongoDB, PostgreSQL etc>
After the task
- Once you have completed your task, make a commit with the commit message beginning with the word
[SUBMIT]. An example commit message is
[SUBMIT] Make final changes, update README. This will be taken as the first production-ready server and will be used as the primary point of evaluation.
- DO NOT label any further commits with the
[SUBMIT] tag. Many of you have labeled all subsequent commits with
[SUBMIT]. This makes evaluation extremely difficult as we have to sift through your commits to find the first
[SUBMIT] message. Only label ONE commit with this tag. All further commits will be considered as improvements and viewed as such.
- Make sure the
[SUBMIT] label is at the BEGINNING of the commit message and INCLUDES the
 (square brackets). A commit message labeled
Submit. Final commit will not be accepted.
- You may continue to make improvements to your project after the submission commit and date. However they will be viewed as improvements and will have a smaller impact to your evaluations. Do not label them with the submission tag.
The deadline for this task is the midnight of the 12th of July 2015. You have 14 days (including today) for its submission. Though this deadline is also technically a soft deadline, you should treat it as a hard one, as your college resumes about then and the Induction PIs will also begin soon. You are allowed to submit a few days after this date, but for your own convenience, start early. The backend work you did for Task 2 should help you begin this task quickly.
Make sure you follow the submission guidelines. Again, read through all the instructions and make sure you are thorough with them.
The Spider Webdev Inductions Team