Lab5 - Back-End 2

Date: Monday, 27 February 2017

Well, back in Lab2, remember that your company UWishWCode decided to hire you (TOGETHER WITH YOUR CLASSMATES: Read: 'the other sub-group(s) that has just been merged with yours'). It turns out the last few weeks were the in-house testing weeks where all of your were asked to develop this same ranklist app web application... Your boss (your Lab TA) have evaluated the progress of each sub-groups so far. Now you and your group mates, now tied together until the end of this module, need to decide which development pathway to choose from now onwards and to combine the best features from individual sub-groups, as there is only one final version that your company will submit to the client (mentioned in Lab1)...

Basic technical requirements:

  • Peacefully resolve the impending "integration conflict" between the code base of two (or three) sub groups which have been merged into one single capstone project group of size [5..7]. Some DO droplet can be 'destroyed' if no longer used (so that you can keep your DO droplet remaining balance), or you can use those extra droplet(s) for "production" droplet (for Lab TA to grade your work) versus "debug" droplet (for you/group mates to test various stuffs).

  • Use the extra manpower from the combined sub-groups to ensure that all basic+extra requirements in Lab1-4 are now implemented in your latest web application. Handle those incompatibility issues as early as you can rather than waiting until Monday of Week 07...

  • The most important basic requirement for this Lab5: Make your data persistent across sessions despite various database-altering Create/Update/Delete actions.

  • Improve the Web Application Features:
    1. On Create/Update/Delete action as described in Lab4, give a dismissible "alert", like this.
    2. On accessing unavailable routes (HTTP error 404), or any other non HTTP 200 responses, give a more graceful error message than Laravel default, like this.
    3. Back in Lab3, we have:
      Set the row height of row i+1 according to the difference of column Sum values between row i and row i+1. That is, the bigger the gap, the bigger the visual gap has to be (you are free to calibrate the gap rules as long as it is visually consistent). However, turn off this feature when user clicks on a column header as the sort order will likely be different. This likely requires some custom JS coding work.
      Now use this rule:
      Set the row height of row i+1 according to the difference of the active sort column values between row i and row i+1. That is, the bigger the gap, the bigger the visual gap has to be (although you are still free to calibrate the gap rules as long as it is visually consistent, you should minimize vertical scrolling, i.e. don't use too much whitespace). of course, only apply this row height feature when the active sort column contains numbers.
    4. Use built-in timestamps feature in Laravel Eloquent ORM to display time-related information, e.g. the ranklist is last updated ['X days ago' or 'on Monday, 13 February 2017, 9.58pm SGT']..., etc.
    5. Add "progress over time" feature. Currently the landing page/the ranklist of our ranklist app shows the latest scores of every student at this point of time. What if we want to show progress over time (e.g. NUS week 1 to week 13)? We may have to record more data or put timestamp-related features in our database. Display this progress over time as a line chart (use whatever line chart) where the y-axis should be the sum scores and the x-axis should be the time (e.g. 13 ticks: Week 1 to Week 13). Give option to turn on/off certain students in this "progress over time" chart. In my mind, I am thinking of this. Decide what changes (another migration) that you have to do to your underlying database scheme (if your group has used it earlier) or to think from scratch to support this feature if your group has not used database before.
    6. Give another view for editing the student data. For now, most groups show edit feature one student at a time, as that is what was asked in Lab4. However, notice that for example after a CS3233 Mini Contest has been completed, the lecturer has to click N edit buttons, update that particular Mini Contest scores of all students, then click N update buttons, one after another... This should be simplified by having another view where the lecturer can edit/upload all N scores of a certain Mini Contest, a certain Homework, a certain Kattis set, etc in three steps only: click to open this new view, enter N data, and then click one single update button only. Do you need to change your underlying database schema or is there another way?
    7. Use Eloquent relationship to model the achievement system of CS3233. Currently, only when we click a student detail, then we can see his/her list of achievements (as raw text). Remodel this using Eloquent relationship so that we can give additional view in our ranklist app: Show which students that have "Kattis apprentice 1/6", for example.

      PS: You need to rethink your database schema to support especially the "progress over time" feature, the different edit view, and the achievement system view above.

  • Software Engineering/Group Dynamics checklist
    1. Your capstone project group needs to set up a combined private, non Google-searchable repository where all [5..7] members are included and actively committing various small progress of this Lab5 (NOT ONLY ON SUNDAY 26 or MONDAY 27 FEBRUARY 2017). We want to see at least 3 (three) reasonable commits with proper commit summary/description (summary like 'bug fix' is NOT a good summary... use a more detailed summary) by each individual member at 3 different calendar days as recorded by GitHub (Graphs tab).
    2. One of the member must be randomly chosen to do a live demonstration of a random edit requested by Lab TA (e.g. change the title from X to Y), commit such changes to your group's GitHub repo, and then clone the latest version of that repo to your group's DO droplet.
    3. We will ask another random member to explain a random feature of your capstone project group joint-work, i.e. you have this feature 'x', show the piece of code that perform this task, show me how to make it 'x-variant', etc. That is, you cannot just piggy back the group and hope that the stronger technical member of your group will carry you through Lab 5-6 and the 41% capstone project.

The Extra Challenges for Lab5:

  1. A1+A2 CHALLENGE: Self-learn Laravel A1 (built-in) and A2 (need to adjust a bit) features to ensure that your ranklist database is not corrupted by malicious users (including your own Lab TA)...
  2. Forgot Password Feature: You need a bit more work in order to make this Laravel built-in feature (for user to reset his/her own password) work.
  3. Survive Hacking Attempt (only if the security features above are implemented by the project group): If you are not careful, others can still inject 'bad data' to/corrupt existing data in/delete data from your database (even after that A1+A2). We will try hacking your project group's web application against a checklist (that is not shown to you) and if it survives, we will consider that it is safe enough.


  1. Q: Help... I am clueless with not just database topic but also many other topics of the first half of CS3226... What should I do?
    A: Find help before it is too late... Contact the lecturer or your Lab TA.

Lab TA Checklist

  1. Showcase the selected best Lab4 work so far.
  2. Review the concept of Database Migration (Create Table), Laravel Eloquent ORM, the concept of Laravel Model (M in MVC) encapsulating a database table, example of CRUD operations on that model, Query that results in multiple row is a Laravel Collections that can be manipulated accordingly, Eloquent relationships, etc...
  3. Grade groups who have completed Lab5 and nominate ONE best lab work in your lab group so far to be showcased.