Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T20:48:53Z

Spsingh2: /* Database Optimization */

=Introduction=
'''Project name: [https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]'''<ref>[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]</ref>

Our project is to refactor the code in the ''"Leaderboard"'' functionality of the web application [https://github.com/expertiza/expertiza Expertiza]<ref>[https://github.com/expertiza/expertiza Expertiza]</ref>. The Expertiza project is a system to create reusable learning objects through peer review. The leaderboard functionality is to show top 3 individual scorers in each questionnaire type ( <code> Reviwed by Author, Reviewed by Teammates, Submitted Work and Reviewer </code>), in each course. The leaderboard also shows the current standing of the logged in user under personal achievements.

{| class="wikitable floatright"
| colspan="2" align="center" | Expertiza Link
|-
| Refactored Instance
| http://152.1.13.181:3000
|-
| Original Instance
| http://152.1.13.181:3001
|}
__TOC__

=Project Description=
'''Classes involved:''' ''leaderboard.rb'' and associated other model and controllers classes.

1. Come up with an efficient way to search for participants based on assignment ids.

2. Refactor score hash for personal achievements. (method: <code> extractPersonalAchievements </code>). Seperate out method which will rank individual personal achievements.

3. Refactor <code> addEntryToCSHash </code> according to your new metric method.

4. Seperate out computation of CS entries(metric) and refactor it to be more modular and elegant.

5. Refactor <code> getParticipantEntriesInAssignmentList </code> method. Its very complex <code>(Complexity=142)</code>.

6. Refactor <code> addEntryToCSHash </code> according to your new metric method.

=Existing Functionality=
Leaderboard.rb class gets all the assignments within all the courses taken by currently logged in user. It also fetches any independent assignments (not associated with any course), that the user has taken. Then, it fetches all the participants who have participated in the computed list of assignments and aggregates their scores based on the questionnaire type. Several questionnaire type is associated with a single assignment. e.g. Direwolf application has - ''Review Questionnaire'', ''Author Feedback Questionnaire'' and ''Teammate Review Questionnaire''.

Leaderboard model has following 3 important methods:
{| class="wikitable"
|-
! style="width:3%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:43%;"|Comment
|- style="vertical-align:top;"
|-
|''''' 1 '''''
| <code> getParticipantEntriesInAssignmentList(assignmentList) </code>
|This method is responsible for calculating the leaderboard of all the participants associated with assignments in given assignment list.
|-
|''''' 2 '''''
| <code> extractPersonalAchievements(csHash, courseIdList, userId) </code>
| This method is responsible for calculating personal aggregated score. It also calculates the ranking of currently logged in user against total users associated with the same set of courses as that of current user.
|-
|''''' 3 '''''
| <code> addEntryToCSHash(qtypeHash, qtype, userid, csEntry, courseid) </code>
| This method is called internally from <code> Leaderboard.getParticipantEntriesInAssignmentList </code>. This method aggregates score of a user grouped by course id, further grouped by questionnaire type.
|-
|}

In the OSS project, we have refactored these methods along with other smaller methods in
<code> Leaderboard.rb </code>, <code> Leaderboard_helper.rb </code>, <code> Leaderboard_controller.rb </code> and associated views files. We have also refactored ambiguous variable and method names.

We have keenly focussed in reducing the database calls, loops and redundant storage and computation. We have refactored many files related to Leaderboard implementation leading to reduction in overall complexity of the feature.

=Changes in Model =

Changes made in the methods of model <code> '''leaderboard.rb''' </code>
{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| <code> getIndependantAssignments </code>
| Separate db call for each user assignment.
| Single db call with an array of assignment ids.
|-
|''''' 2 '''''
| <code> getParticipantEntriesInCourses </code>
| Confusing code. Appends each entry to the end of list
| Used concat to clarify that we are adding the independent and other assignments in courses.
|-
|''''' 3 '''''
| <code> sortHash </code>
| in place changes.
| Returns a new deep copy of the updated hash.
|-
|''''' 4 '''''
| <code> extractPersonalAchievements </code>
| Confusing code with extra data base calls.
| This method is refactored to use only 1 database call unlike several within the loop in its prior implementation. We have also removed redundant code computation and made the logic easier to understand. The overall complexity of this method is reduced from 72 to 35.
|-
|''''' 5 '''''
| <code> addEntryToCSHash </code>
| Confusing name and hard to follow logic.
| The new method name is <code> addScoreToResultantHash </code>. As mentioned earlier, this is called internally by <code> getParticipantEntriesInAssignmentList </code>. The complexity of this method is reduced from 67 to 39 .
|-
|''''' 6 '''''
| <code> getParticipantEntriesInAssignmentList </code>
| This method was the most complex method in the class.
| The new refactored method name is <code> getParticipantsScore </code>. The method was refactored on various aspects like reducing database calls drastically, removing redundant code computation, redundant data storage in complex group of hashes and series of conditional statements. We would like to mention that previously, the method had 10 database calls within loop and 1 outside loop. After refactoring, the new method has just 1 database call within loop and 3 outside loops. Also, the overall code complexity is reduced from 142 to 64.
|-
|}

=Changes in Helper =

Changes made in methods of Helper <code> leaderboard_helper.rb </code>

{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| <code> userIsInstructor </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls. 4 database calls was replaced by single call.
|-
|''''' 2 '''''
| <code> studentInWhichCourses </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls and remove unnecessary loops. 1 database call outside and 1 within a loop was replaced by a |single call.
|-
|''''' 3 '''''
| <code> getTop3Leaderboards </code>
| Dead code
| Removed.
|-
|}

There are several other changes in the views and controller which deal with renaming of the methods
and variables, adding proper comments etc and minor code refactoring. Please refer to our forked
github repository to view those changes.

=Testing=

On VCL session there are 2 instances running. On <code> port 3001 </code> the original instance is setup and on <code> port 3000 </code> the refactored instance is setup.
In below images we have shown that the output after refactoring is same. We changed the order in which the output is displayed to make it more coherent.

{| class="wikitable"
|-
! View of Refactored Leaderboard
! View of Original Leaderboard

|-
| [[File:Refactored_Leaderboard_file.jpg|frame|left| ]]
| [[File:Non_Refactored_Leaderboard_file.jpg|frame|left| ]]

|-
| [[File:Refactored_personal_achievement_file.jpg|frame|left| ]]
| [[File:Non_personal_achievement_file.jpg|frame|left| ]]

|}

=Optimization=

The refactoring process included reducing the database calls, loops and redundant storage and computation in all classes associated with Leaderboard functionality. While refactoring, the team has ensured to improve the readability of the code too by renaming ambiguous method and variable names and adding relevant comments to explain the objective of a code construct.

== Code Optimization ==

In the project description code complexity has been highlighted for several methods. [https://codeclimate.com/ Code Climate]<ref>[https://codeclimate.com/ Code Climate]</ref> has been used to measure the code complexity of the current repository of Expertiza. After refactoring, we used the same tool i.e. Code Climate to measure the code complexity. Following is the snapshot of code complexity of <code> Leaderboard.rb </code> from Code Climate.

{| class="wikitable"
|-
! Code complexity of original leaderboard implementation
! Code complexity of refactored leaderboard implementation
|-
| [[File:Non_Refactored_Leaderboard_complexity.png|center|frame]]
| [[File:Refactored_Leaderboard_complexity.png|center|frame]]
|-
| [[File:Non_Refactored_Leaderboard_stats.png|center|frame]]
| [[File:Refactored_Leaderboard_stats.png|center|frame]]
|}

[[File:CodeClimate_codecomplexity.png|center]]

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%.

== Database Optimization ==
We computed the number of data base "SELECT" call generated the database driver by filtering the messages from the rails server. In the original code there were 625 data base select access generated for the leaderboard view. In the new code the number of select calls dropped to 111.
Shown below is the number of select calls generated per table.

{| class="wikitable"
|-
! Table Name
! Original Version
! Refactored Version
! Comment
|-
| roles
| 52
| 13
| Dummy
|-
| users
| 25
| 25
| No Change
|-
| participants
| 111
| 3
| Dummy
|-
| assignments
| 16
| 5
| Dummy
|-
| assignment_questionnaires
| 11
| 0
| Optimized
|-
| questionnaires
| 311
| 0
| Optimized
|-
| score_caches
| 22
| 1
| Optimized
|-
| teams
| 11
| 2
| Optimized
|-
| teams_users
| 52
| 52
| No change
|-
| leaderboards
| 9
| 5
| Optimized
|-
| courses
| 5
| 5
| No change
|-
|}

== Performance Optimization ==

Google Chrome extension [https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]<ref>
[https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]</ref> gives time to load a page.
We tried this extension to measure performance change after refactoring. We noticed that the time to load page reduced by almost 15%.

This table indicates time to load page in seconds
{| class="wikitable"
|-
! Iteration
! Original Version
! Refactored Version

|-
|1
| 2.08
| 1.76
|-
|2
| 2.02
| 1.66
|-
|3
| 2.01
| 1.76
|-
|4
| 1.97
| 1.76
|-
|5
| 1.93
| 1.72
|-
|6
| 1.97
| 1.75
|-
|7
| 2.12
| 1.74
|-
|8
| 1.99
| 1.71
|-
|9
| 2.12
| 1.80
|-
|10
| 2.00
| 1.75
|-
|Average
|2.02
|1.74
|}

=Future Work=
There was a requirement in the project, that we should come up with an efficient way to search for participants based on assignment ids. However, upon investigation, we found that scores stored in table ScoreCache, gives us revieweeId which is either participantId or teamId. Therefore, we have a method <code> getAssignmentMapping </code>, which creates a mapping of participant and team with corresponding assignment. This is very useful while computing leaderboard.

Lastly, we would like to recommend the readers to test the leaderboard functionality by any user who has participated in several assignments, some of them which is associated with any course and there
are other existing users who have participated in the same assignment. e.g. user480/password

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T20:48:29Z

Spsingh2: /* Database Optimization */

=Introduction=
'''Project name: [https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]'''<ref>[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]</ref>

Our project is to refactor the code in the ''"Leaderboard"'' functionality of the web application [https://github.com/expertiza/expertiza Expertiza]<ref>[https://github.com/expertiza/expertiza Expertiza]</ref>. The Expertiza project is a system to create reusable learning objects through peer review. The leaderboard functionality is to show top 3 individual scorers in each questionnaire type ( <code> Reviwed by Author, Reviewed by Teammates, Submitted Work and Reviewer </code>), in each course. The leaderboard also shows the current standing of the logged in user under personal achievements.

{| class="wikitable floatright"
| colspan="2" align="center" | Expertiza Link
|-
| Refactored Instance
| http://152.1.13.181:3000
|-
| Original Instance
| http://152.1.13.181:3001
|}
__TOC__

=Project Description=
'''Classes involved:''' ''leaderboard.rb'' and associated other model and controllers classes.

1. Come up with an efficient way to search for participants based on assignment ids.

2. Refactor score hash for personal achievements. (method: <code> extractPersonalAchievements </code>). Seperate out method which will rank individual personal achievements.

3. Refactor <code> addEntryToCSHash </code> according to your new metric method.

4. Seperate out computation of CS entries(metric) and refactor it to be more modular and elegant.

5. Refactor <code> getParticipantEntriesInAssignmentList </code> method. Its very complex <code>(Complexity=142)</code>.

6. Refactor <code> addEntryToCSHash </code> according to your new metric method.

=Existing Functionality=
Leaderboard.rb class gets all the assignments within all the courses taken by currently logged in user. It also fetches any independent assignments (not associated with any course), that the user has taken. Then, it fetches all the participants who have participated in the computed list of assignments and aggregates their scores based on the questionnaire type. Several questionnaire type is associated with a single assignment. e.g. Direwolf application has - ''Review Questionnaire'', ''Author Feedback Questionnaire'' and ''Teammate Review Questionnaire''.

Leaderboard model has following 3 important methods:
{| class="wikitable"
|-
! style="width:3%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:43%;"|Comment
|- style="vertical-align:top;"
|-
|''''' 1 '''''
| <code> getParticipantEntriesInAssignmentList(assignmentList) </code>
|This method is responsible for calculating the leaderboard of all the participants associated with assignments in given assignment list.
|-
|''''' 2 '''''
| <code> extractPersonalAchievements(csHash, courseIdList, userId) </code>
| This method is responsible for calculating personal aggregated score. It also calculates the ranking of currently logged in user against total users associated with the same set of courses as that of current user.
|-
|''''' 3 '''''
| <code> addEntryToCSHash(qtypeHash, qtype, userid, csEntry, courseid) </code>
| This method is called internally from <code> Leaderboard.getParticipantEntriesInAssignmentList </code>. This method aggregates score of a user grouped by course id, further grouped by questionnaire type.
|-
|}

In the OSS project, we have refactored these methods along with other smaller methods in
<code> Leaderboard.rb </code>, <code> Leaderboard_helper.rb </code>, <code> Leaderboard_controller.rb </code> and associated views files. We have also refactored ambiguous variable and method names.

We have keenly focussed in reducing the database calls, loops and redundant storage and computation. We have refactored many files related to Leaderboard implementation leading to reduction in overall complexity of the feature.

=Changes in Model =

Changes made in the methods of model <code> '''leaderboard.rb''' </code>
{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| <code> getIndependantAssignments </code>
| Separate db call for each user assignment.
| Single db call with an array of assignment ids.
|-
|''''' 2 '''''
| <code> getParticipantEntriesInCourses </code>
| Confusing code. Appends each entry to the end of list
| Used concat to clarify that we are adding the independent and other assignments in courses.
|-
|''''' 3 '''''
| <code> sortHash </code>
| in place changes.
| Returns a new deep copy of the updated hash.
|-
|''''' 4 '''''
| <code> extractPersonalAchievements </code>
| Confusing code with extra data base calls.
| This method is refactored to use only 1 database call unlike several within the loop in its prior implementation. We have also removed redundant code computation and made the logic easier to understand. The overall complexity of this method is reduced from 72 to 35.
|-
|''''' 5 '''''
| <code> addEntryToCSHash </code>
| Confusing name and hard to follow logic.
| The new method name is <code> addScoreToResultantHash </code>. As mentioned earlier, this is called internally by <code> getParticipantEntriesInAssignmentList </code>. The complexity of this method is reduced from 67 to 39 .
|-
|''''' 6 '''''
| <code> getParticipantEntriesInAssignmentList </code>
| This method was the most complex method in the class.
| The new refactored method name is <code> getParticipantsScore </code>. The method was refactored on various aspects like reducing database calls drastically, removing redundant code computation, redundant data storage in complex group of hashes and series of conditional statements. We would like to mention that previously, the method had 10 database calls within loop and 1 outside loop. After refactoring, the new method has just 1 database call within loop and 3 outside loops. Also, the overall code complexity is reduced from 142 to 64.
|-
|}

=Changes in Helper =

Changes made in methods of Helper <code> leaderboard_helper.rb </code>

{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| <code> userIsInstructor </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls. 4 database calls was replaced by single call.
|-
|''''' 2 '''''
| <code> studentInWhichCourses </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls and remove unnecessary loops. 1 database call outside and 1 within a loop was replaced by a |single call.
|-
|''''' 3 '''''
| <code> getTop3Leaderboards </code>
| Dead code
| Removed.
|-
|}

There are several other changes in the views and controller which deal with renaming of the methods
and variables, adding proper comments etc and minor code refactoring. Please refer to our forked
github repository to view those changes.

=Testing=

On VCL session there are 2 instances running. On <code> port 3001 </code> the original instance is setup and on <code> port 3000 </code> the refactored instance is setup.
In below images we have shown that the output after refactoring is same. We changed the order in which the output is displayed to make it more coherent.

{| class="wikitable"
|-
! View of Refactored Leaderboard
! View of Original Leaderboard

|-
| [[File:Refactored_Leaderboard_file.jpg|frame|left| ]]
| [[File:Non_Refactored_Leaderboard_file.jpg|frame|left| ]]

|-
| [[File:Refactored_personal_achievement_file.jpg|frame|left| ]]
| [[File:Non_personal_achievement_file.jpg|frame|left| ]]

|}

=Optimization=

The refactoring process included reducing the database calls, loops and redundant storage and computation in all classes associated with Leaderboard functionality. While refactoring, the team has ensured to improve the readability of the code too by renaming ambiguous method and variable names and adding relevant comments to explain the objective of a code construct.

== Code Optimization ==

In the project description code complexity has been highlighted for several methods. [https://codeclimate.com/ Code Climate]<ref>[https://codeclimate.com/ Code Climate]</ref> has been used to measure the code complexity of the current repository of Expertiza. After refactoring, we used the same tool i.e. Code Climate to measure the code complexity. Following is the snapshot of code complexity of <code> Leaderboard.rb </code> from Code Climate.

{| class="wikitable"
|-
! Code complexity of original leaderboard implementation
! Code complexity of refactored leaderboard implementation
|-
| [[File:Non_Refactored_Leaderboard_complexity.png|center|frame]]
| [[File:Refactored_Leaderboard_complexity.png|center|frame]]
|-
| [[File:Non_Refactored_Leaderboard_stats.png|center|frame]]
| [[File:Refactored_Leaderboard_stats.png|center|frame]]
|}

[[File:CodeClimate_codecomplexity.png|center]]

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%.

== Database Optimization ==
We computed the number of data base "SELECT" call generated the database driver by filtering the messages from the rails server. In the original code there were 625 data base select access generated for the leaderboard view. In the new code the number of select calls dropped to 111.
Shown below is the number of select calls generated per table.

{| class="wikitable"
|-
! Table Name
! Original Version
! Refactored Version
! Comment
|-
| roles
| 52
| 13
| Dummy
|-
| users
| 25
| 25
| No Change
|-
| participants
| 111
| 3
| Dummy
|-
| assignments
| 16
| 5
| Dummy
|-
| assignment_questionnaires
| 11
| 0
| Optimized
|-
| questionnaires
| 311
| 0
| Optimized
|-
| score_caches
| 22
| 1
| Optimized
|-
| teams
| 11
| 2
| Optimized
|-
| teams_users
| 52
| 52
| No change
| -
| leaderboards
| 9
| 5
| Optimized
|-
| courses
| 5
| 5
| No change
|-
|}

== Performance Optimization ==

Google Chrome extension [https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]<ref>
[https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]</ref> gives time to load a page.
We tried this extension to measure performance change after refactoring. We noticed that the time to load page reduced by almost 15%.

This table indicates time to load page in seconds
{| class="wikitable"
|-
! Iteration
! Original Version
! Refactored Version

|-
|1
| 2.08
| 1.76
|-
|2
| 2.02
| 1.66
|-
|3
| 2.01
| 1.76
|-
|4
| 1.97
| 1.76
|-
|5
| 1.93
| 1.72
|-
|6
| 1.97
| 1.75
|-
|7
| 2.12
| 1.74
|-
|8
| 1.99
| 1.71
|-
|9
| 2.12
| 1.80
|-
|10
| 2.00
| 1.75
|-
|Average
|2.02
|1.74
|}

=Future Work=
There was a requirement in the project, that we should come up with an efficient way to search for participants based on assignment ids. However, upon investigation, we found that scores stored in table ScoreCache, gives us revieweeId which is either participantId or teamId. Therefore, we have a method <code> getAssignmentMapping </code>, which creates a mapping of participant and team with corresponding assignment. This is very useful while computing leaderboard.

Lastly, we would like to recommend the readers to test the leaderboard functionality by any user who has participated in several assignments, some of them which is associated with any course and there
are other existing users who have participated in the same assignment. e.g. user480/password

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T20:46:52Z

Spsingh2: /* Database Optimization */

=Introduction=
'''Project name: [https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]'''<ref>[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]</ref>

Our project is to refactor the code in the ''"Leaderboard"'' functionality of the web application [https://github.com/expertiza/expertiza Expertiza]<ref>[https://github.com/expertiza/expertiza Expertiza]</ref>. The Expertiza project is a system to create reusable learning objects through peer review. The leaderboard functionality is to show top 3 individual scorers in each questionnaire type ( <code> Reviwed by Author, Reviewed by Teammates, Submitted Work and Reviewer </code>), in each course. The leaderboard also shows the current standing of the logged in user under personal achievements.

{| class="wikitable floatright"
| colspan="2" align="center" | Expertiza Link
|-
| Refactored Instance
| http://152.1.13.181:3000
|-
| Original Instance
| http://152.1.13.181:3001
|}
__TOC__

=Project Description=
'''Classes involved:''' ''leaderboard.rb'' and associated other model and controllers classes.

1. Come up with an efficient way to search for participants based on assignment ids.

2. Refactor score hash for personal achievements. (method: <code> extractPersonalAchievements </code>). Seperate out method which will rank individual personal achievements.

3. Refactor <code> addEntryToCSHash </code> according to your new metric method.

4. Seperate out computation of CS entries(metric) and refactor it to be more modular and elegant.

5. Refactor <code> getParticipantEntriesInAssignmentList </code> method. Its very complex <code>(Complexity=142)</code>.

6. Refactor <code> addEntryToCSHash </code> according to your new metric method.

=Existing Functionality=
Leaderboard.rb class gets all the assignments within all the courses taken by currently logged in user. It also fetches any independent assignments (not associated with any course), that the user has taken. Then, it fetches all the participants who have participated in the computed list of assignments and aggregates their scores based on the questionnaire type. Several questionnaire type is associated with a single assignment. e.g. Direwolf application has - ''Review Questionnaire'', ''Author Feedback Questionnaire'' and ''Teammate Review Questionnaire''.

Leaderboard model has following 3 important methods:
{| class="wikitable"
|-
! style="width:3%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:43%;"|Comment
|- style="vertical-align:top;"
|-
|''''' 1 '''''
| <code> getParticipantEntriesInAssignmentList(assignmentList) </code>
|This method is responsible for calculating the leaderboard of all the participants associated with assignments in given assignment list.
|-
|''''' 2 '''''
| <code> extractPersonalAchievements(csHash, courseIdList, userId) </code>
| This method is responsible for calculating personal aggregated score. It also calculates the ranking of currently logged in user against total users associated with the same set of courses as that of current user.
|-
|''''' 3 '''''
| <code> addEntryToCSHash(qtypeHash, qtype, userid, csEntry, courseid) </code>
| This method is called internally from <code> Leaderboard.getParticipantEntriesInAssignmentList </code>. This method aggregates score of a user grouped by course id, further grouped by questionnaire type.
|-
|}

In the OSS project, we have refactored these methods along with other smaller methods in
<code> Leaderboard.rb </code>, <code> Leaderboard_helper.rb </code>, <code> Leaderboard_controller.rb </code> and associated views files. We have also refactored ambiguous variable and method names.

We have keenly focussed in reducing the database calls, loops and redundant storage and computation. We have refactored many files related to Leaderboard implementation leading to reduction in overall complexity of the feature.

=Changes in Model =

Changes made in the methods of model <code> '''leaderboard.rb''' </code>
{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| <code> getIndependantAssignments </code>
| Separate db call for each user assignment.
| Single db call with an array of assignment ids.
|-
|''''' 2 '''''
| <code> getParticipantEntriesInCourses </code>
| Confusing code. Appends each entry to the end of list
| Used concat to clarify that we are adding the independent and other assignments in courses.
|-
|''''' 3 '''''
| <code> sortHash </code>
| in place changes.
| Returns a new deep copy of the updated hash.
|-
|''''' 4 '''''
| <code> extractPersonalAchievements </code>
| Confusing code with extra data base calls.
| This method is refactored to use only 1 database call unlike several within the loop in its prior implementation. We have also removed redundant code computation and made the logic easier to understand. The overall complexity of this method is reduced from 72 to 35.
|-
|''''' 5 '''''
| <code> addEntryToCSHash </code>
| Confusing name and hard to follow logic.
| The new method name is <code> addScoreToResultantHash </code>. As mentioned earlier, this is called internally by <code> getParticipantEntriesInAssignmentList </code>. The complexity of this method is reduced from 67 to 39 .
|-
|''''' 6 '''''
| <code> getParticipantEntriesInAssignmentList </code>
| This method was the most complex method in the class.
| The new refactored method name is <code> getParticipantsScore </code>. The method was refactored on various aspects like reducing database calls drastically, removing redundant code computation, redundant data storage in complex group of hashes and series of conditional statements. We would like to mention that previously, the method had 10 database calls within loop and 1 outside loop. After refactoring, the new method has just 1 database call within loop and 3 outside loops. Also, the overall code complexity is reduced from 142 to 64.
|-
|}

=Changes in Helper =

Changes made in methods of Helper <code> leaderboard_helper.rb </code>

{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| <code> userIsInstructor </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls. 4 database calls was replaced by single call.
|-
|''''' 2 '''''
| <code> studentInWhichCourses </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls and remove unnecessary loops. 1 database call outside and 1 within a loop was replaced by a |single call.
|-
|''''' 3 '''''
| <code> getTop3Leaderboards </code>
| Dead code
| Removed.
|-
|}

There are several other changes in the views and controller which deal with renaming of the methods
and variables, adding proper comments etc and minor code refactoring. Please refer to our forked
github repository to view those changes.

=Testing=

On VCL session there are 2 instances running. On <code> port 3001 </code> the original instance is setup and on <code> port 3000 </code> the refactored instance is setup.
In below images we have shown that the output after refactoring is same. We changed the order in which the output is displayed to make it more coherent.

{| class="wikitable"
|-
! View of Refactored Leaderboard
! View of Original Leaderboard

|-
| [[File:Refactored_Leaderboard_file.jpg|frame|left| ]]
| [[File:Non_Refactored_Leaderboard_file.jpg|frame|left| ]]

|-
| [[File:Refactored_personal_achievement_file.jpg|frame|left| ]]
| [[File:Non_personal_achievement_file.jpg|frame|left| ]]

|}

=Optimization=

The refactoring process included reducing the database calls, loops and redundant storage and computation in all classes associated with Leaderboard functionality. While refactoring, the team has ensured to improve the readability of the code too by renaming ambiguous method and variable names and adding relevant comments to explain the objective of a code construct.

== Code Optimization ==

In the project description code complexity has been highlighted for several methods. [https://codeclimate.com/ Code Climate]<ref>[https://codeclimate.com/ Code Climate]</ref> has been used to measure the code complexity of the current repository of Expertiza. After refactoring, we used the same tool i.e. Code Climate to measure the code complexity. Following is the snapshot of code complexity of <code> Leaderboard.rb </code> from Code Climate.

{| class="wikitable"
|-
! Code complexity of original leaderboard implementation
! Code complexity of refactored leaderboard implementation
|-
| [[File:Non_Refactored_Leaderboard_complexity.png|center|frame]]
| [[File:Refactored_Leaderboard_complexity.png|center|frame]]
|-
| [[File:Non_Refactored_Leaderboard_stats.png|center|frame]]
| [[File:Refactored_Leaderboard_stats.png|center|frame]]
|}

[[File:CodeClimate_codecomplexity.png|center]]

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%.

== Database Optimization ==
We computed the number of data base "SELECT" call to each of the table entries. In the original code there were 625 data base select access generated for the leaderboard view. In the new code the number of select calls dropped to 111.
Shown below is the number of select calls generated per table.

{| class="wikitable"
|-
! Table Name
! Original Version
! Refactored Version
! Comment
|-
| roles
| 52
| 13
| Dummy
|-
| users
| 25
| 25
| No Change
|-
| participants
| 111
| 3
| Dummy
|-
| assignments
| 16
| 5
| Dummy
|-
| assignment_questionnaires
| 11
| 0
| Optimized
|-
| questionnaires
| 311
| 0
| Optimized
|-
| score_caches
| 22
| 1
| Optimized
|-
| teams
| 11
| 2
| Optimized
|-
| teams_users
| 52
| 52
| No change
| -
| leaderboards
| 9
| 5
| Optimized
|-
| courses
| 5
| 5
| No change
|-
|}

== Performance Optimization ==

Google Chrome extension [https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]<ref>
[https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]</ref> gives time to load a page.
We tried this extension to measure performance change after refactoring. We noticed that the time to load page reduced by almost 15%.

This table indicates time to load page in seconds
{| class="wikitable"
|-
! Iteration
! Original Version
! Refactored Version

|-
|1
| 2.08
| 1.76
|-
|2
| 2.02
| 1.66
|-
|3
| 2.01
| 1.76
|-
|4
| 1.97
| 1.76
|-
|5
| 1.93
| 1.72
|-
|6
| 1.97
| 1.75
|-
|7
| 2.12
| 1.74
|-
|8
| 1.99
| 1.71
|-
|9
| 2.12
| 1.80
|-
|10
| 2.00
| 1.75
|-
|Average
|2.02
|1.74
|}

=Future Work=
There was a requirement in the project, that we should come up with an efficient way to search for participants based on assignment ids. However, upon investigation, we found that scores stored in table ScoreCache, gives us revieweeId which is either participantId or teamId. Therefore, we have a method <code> getAssignmentMapping </code>, which creates a mapping of participant and team with corresponding assignment. This is very useful while computing leaderboard.

Lastly, we would like to recommend the readers to test the leaderboard functionality by any user who has participated in several assignments, some of them which is associated with any course and there
are other existing users who have participated in the same assignment. e.g. user480/password

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T20:43:21Z

Spsingh2: /* Optimization */

=Introduction=
'''Project name: [https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]'''<ref>[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]</ref>

Our project is to refactor the code in the ''"Leaderboard"'' functionality of the web application [https://github.com/expertiza/expertiza Expertiza]<ref>[https://github.com/expertiza/expertiza Expertiza]</ref>. The Expertiza project is a system to create reusable learning objects through peer review. The leaderboard functionality is to show top 3 individual scorers in each questionnaire type ( <code> Reviwed by Author, Reviewed by Teammates, Submitted Work and Reviewer </code>), in each course. The leaderboard also shows the current standing of the logged in user under personal achievements.

{| class="wikitable floatright"
| colspan="2" align="center" | Expertiza Link
|-
| Refactored Instance
| http://152.1.13.181:3000
|-
| Original Instance
| http://152.1.13.181:3001
|}
__TOC__

=Project Description=
'''Classes involved:''' ''leaderboard.rb'' and associated other model and controllers classes.

1. Come up with an efficient way to search for participants based on assignment ids.

2. Refactor score hash for personal achievements. (method: <code> extractPersonalAchievements </code>). Seperate out method which will rank individual personal achievements.

3. Refactor <code> addEntryToCSHash </code> according to your new metric method.

4. Seperate out computation of CS entries(metric) and refactor it to be more modular and elegant.

5. Refactor <code> getParticipantEntriesInAssignmentList </code> method. Its very complex <code>(Complexity=142)</code>.

6. Refactor <code> addEntryToCSHash </code> according to your new metric method.

=Existing Functionality=
Leaderboard.rb class gets all the assignments within all the courses taken by currently logged in user. It also fetches any independent assignments (not associated with any course), that the user has taken. Then, it fetches all the participants who have participated in the computed list of assignments and aggregates their scores based on the questionnaire type. Several questionnaire type is associated with a single assignment. e.g. Direwolf application has - ''Review Questionnaire'', ''Author Feedback Questionnaire'' and ''Teammate Review Questionnaire''.

Leaderboard model has following 3 important methods:
{| class="wikitable"
|-
! style="width:3%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:43%;"|Comment
|- style="vertical-align:top;"
|-
|''''' 1 '''''
| <code> getParticipantEntriesInAssignmentList(assignmentList) </code>
|This method is responsible for calculating the leaderboard of all the participants associated with assignments in given assignment list.
|-
|''''' 2 '''''
| <code> extractPersonalAchievements(csHash, courseIdList, userId) </code>
| This method is responsible for calculating personal aggregated score. It also calculates the ranking of currently logged in user against total users associated with the same set of courses as that of current user.
|-
|''''' 3 '''''
| <code> addEntryToCSHash(qtypeHash, qtype, userid, csEntry, courseid) </code>
| This method is called internally from <code> Leaderboard.getParticipantEntriesInAssignmentList </code>. This method aggregates score of a user grouped by course id, further grouped by questionnaire type.
|-
|}

In the OSS project, we have refactored these methods along with other smaller methods in
<code> Leaderboard.rb </code>, <code> Leaderboard_helper.rb </code>, <code> Leaderboard_controller.rb </code> and associated views files. We have also refactored ambiguous variable and method names.

We have keenly focussed in reducing the database calls, loops and redundant storage and computation. We have refactored many files related to Leaderboard implementation leading to reduction in overall complexity of the feature.

=Changes in Model =

Changes made in the methods of model <code> '''leaderboard.rb''' </code>
{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| <code> getIndependantAssignments </code>
| Separate db call for each user assignment.
| Single db call with an array of assignment ids.
|-
|''''' 2 '''''
| <code> getParticipantEntriesInCourses </code>
| Confusing code. Appends each entry to the end of list
| Used concat to clarify that we are adding the independent and other assignments in courses.
|-
|''''' 3 '''''
| <code> sortHash </code>
| in place changes.
| Returns a new deep copy of the updated hash.
|-
|''''' 4 '''''
| <code> extractPersonalAchievements </code>
| Confusing code with extra data base calls.
| This method is refactored to use only 1 database call unlike several within the loop in its prior implementation. We have also removed redundant code computation and made the logic easier to understand. The overall complexity of this method is reduced from 72 to 35.
|-
|''''' 5 '''''
| <code> addEntryToCSHash </code>
| Confusing name and hard to follow logic.
| The new method name is <code> addScoreToResultantHash </code>. As mentioned earlier, this is called internally by <code> getParticipantEntriesInAssignmentList </code>. The complexity of this method is reduced from 67 to 39 .
|-
|''''' 6 '''''
| <code> getParticipantEntriesInAssignmentList </code>
| This method was the most complex method in the class.
| The new refactored method name is <code> getParticipantsScore </code>. The method was refactored on various aspects like reducing database calls drastically, removing redundant code computation, redundant data storage in complex group of hashes and series of conditional statements. We would like to mention that previously, the method had 10 database calls within loop and 1 outside loop. After refactoring, the new method has just 1 database call within loop and 3 outside loops. Also, the overall code complexity is reduced from 142 to 64.
|-
|}

=Changes in Helper =

Changes made in methods of Helper <code> leaderboard_helper.rb </code>

{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| <code> userIsInstructor </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls. 4 database calls was replaced by single call.
|-
|''''' 2 '''''
| <code> studentInWhichCourses </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls and remove unnecessary loops. 1 database call outside and 1 within a loop was replaced by a |single call.
|-
|''''' 3 '''''
| <code> getTop3Leaderboards </code>
| Dead code
| Removed.
|-
|}

There are several other changes in the views and controller which deal with renaming of the methods
and variables, adding proper comments etc and minor code refactoring. Please refer to our forked
github repository to view those changes.

=Testing=

On VCL session there are 2 instances running. On <code> port 3001 </code> the original instance is setup and on <code> port 3000 </code> the refactored instance is setup.
In below images we have shown that the output after refactoring is same. We changed the order in which the output is displayed to make it more coherent.

{| class="wikitable"
|-
! View of Refactored Leaderboard
! View of Original Leaderboard

|-
| [[File:Refactored_Leaderboard_file.jpg|frame|left| ]]
| [[File:Non_Refactored_Leaderboard_file.jpg|frame|left| ]]

|-
| [[File:Refactored_personal_achievement_file.jpg|frame|left| ]]
| [[File:Non_personal_achievement_file.jpg|frame|left| ]]

|}

=Optimization=

The refactoring process included reducing the database calls, loops and redundant storage and computation in all classes associated with Leaderboard functionality. While refactoring, the team has ensured to improve the readability of the code too by renaming ambiguous method and variable names and adding relevant comments to explain the objective of a code construct.

== Code Optimization ==

In the project description code complexity has been highlighted for several methods. [https://codeclimate.com/ Code Climate]<ref>[https://codeclimate.com/ Code Climate]</ref> has been used to measure the code complexity of the current repository of Expertiza. After refactoring, we used the same tool i.e. Code Climate to measure the code complexity. Following is the snapshot of code complexity of <code> Leaderboard.rb </code> from Code Climate.

{| class="wikitable"
|-
! Code complexity of original leaderboard implementation
! Code complexity of refactored leaderboard implementation
|-
| [[File:Non_Refactored_Leaderboard_complexity.png|center|frame]]
| [[File:Refactored_Leaderboard_complexity.png|center|frame]]
|-
| [[File:Non_Refactored_Leaderboard_stats.png|center|frame]]
| [[File:Refactored_Leaderboard_stats.png|center|frame]]
|}

[[File:CodeClimate_codecomplexity.png|center]]

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%.

== Database Optimization ==
We computed the number of data base "SELECT" call to each of the table entries.
{| class="wikitable"
|-
! Table Name
! Original Version
! Refactored Version
! Comment
|-
| roles
| 52
| 13
| Dummy
|-
| users
| 25
| 25
| No Change
|-
| participants
| 111
| 3
| Dummy
|-
| assignments
| 16
| 5
| Dummy
|-
| assignment_questionnaires
| 11
| 0
| Optimized
|-
| questionnaires
| 311
| 0
| Optimized
|-
| score_caches
| 22
| 1
|-
| teams
| 11
| 2
|-
| teams_users
| 52
| 52
| -
| leaderboards
| 9
| 5
| Comment
|-
| courses
| 5
| 5
| No changes
|-
|}

== Performance Optimization ==

Google Chrome extension [https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]<ref>
[https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time]</ref> gives time to load a page.
We tried this extension to measure performance change after refactoring. We noticed that the time to load page reduced by almost 15%.

This table indicates time to load page in seconds
{| class="wikitable"
|-
! Iteration
! Original Version
! Refactored Version

|-
|1
| 2.08
| 1.76
|-
|2
| 2.02
| 1.66
|-
|3
| 2.01
| 1.76
|-
|4
| 1.97
| 1.76
|-
|5
| 1.93
| 1.72
|-
|6
| 1.97
| 1.75
|-
|7
| 2.12
| 1.74
|-
|8
| 1.99
| 1.71
|-
|9
| 2.12
| 1.80
|-
|10
| 2.00
| 1.75
|-
|Average
|2.02
|1.74
|}

=Future Work=
There was a requirement in the project, that we should come up with an efficient way to search for participants based on assignment ids. However, upon investigation, we found that scores stored in table ScoreCache, gives us revieweeId which is either participantId or teamId. Therefore, we have a method <code> getAssignmentMapping </code>, which creates a mapping of participant and team with corresponding assignment. This is very useful while computing leaderboard.

Lastly, we would like to recommend the readers to test the leaderboard functionality by any user who has participated in several assignments, some of them which is associated with any course and there
are other existing users who have participated in the same assignment. e.g. user480/password

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T19:37:10Z

Spsingh2: /* Changes In Model (leaderboard.rb) */

=Introduction=
'''Project name: [https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]'''<ref>[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]</ref>

Our project is to refactor the code in the ''"Leaderboard"'' functionality of the web application [https://github.com/expertiza/expertiza Expertiza]<ref>[https://github.com/expertiza/expertiza Expertiza]</ref>. The Expertiza project is a system to create reusable learning objects through peer review. The leaderboard functionality is to show top 3 individual scorers in each questionnaire types, in each courses. The leaderboard also shows the current standing of the logged in user under personal achievements.

__TOC__

=Project Description=
'''Classes involved:''' ''leaderboard.rb'' and associated other model and controllers classes.

1. Come up with an efficient way to search for participants based on assignment ids.

2. Refactor score hash for personal achievements. (method: <code> extractPersonalAchievements </code>). Seperate out method which will rank individual personal achievements.

3. Refactor <code> addEntryToCSHash </code> according to your new metric method.

4. Seperate out computation of CS entries(metric) and refactor it to be more modular and elegant.

5. Refactor <code> getParticipantEntriesInAssignmentList </code> method. Its very complex (Complexity=142).

6. Refactor <code> addEntryToCSHash </code> according to your new metric method.

=Existing Functionality=
Leaderboard class gets all the assignments within all the courses taken by currently logged in user. It
also fetches any independent assignments (not associated with any course), that the user has taken.

Leaderboard model has following 3 important methods:
{| class="wikitable"
|-
! style="width:3%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:43%;"|Comment
|- style="vertical-align:top;"
|-
|''''' 1 '''''
| <code> getParticipantEntriesInAssignmentList(assignmentList) </code>
|This method is responsible for calculating the leaderboard of all the participants associated with assignments in given assignment list.
|-
|''''' 2 '''''
| <code> extractPersonalAchievements(csHash, courseIdList, userId) </code>
| This method is responsible for calculating personal aggregated score. It also calculates the ranking of currently logged in user against total users associated with the same set of courses as that of current user.
|-
|''''' 3 '''''
| <code> addEntryToCSHash(qtypeHash, qtype, userid, csEntry, courseid) </code>
| This method is called internally from <code> Leaderboard.getParticipantEntriesInAssignmentList </code>. This method aggregates score of a user grouped by course id, further grouped by questionnaire type.
|-
|}

In the OSS project, we have refactored these methods along with other smaller methods in
<code> Leaderboard.rb </code>, <code> Leaderboard_helper.rb </code>, <code> Leaderboard_controller.rb </code> and associated views files. We have also refactored ambiguous variable and method names.

We have keenly focussed in reducing the database calls, loops and redundant storage and computation. We have refactored many files related to Leaderboard implementation leading to enhancement of overall complexity of the feature.

=Changes In Model (leaderboard.rb) =
{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| <code> getIndependantAssignments </code>
| Separate db call for each user assignment.
| Single db call with an array of assignment ids.
|-
|''''' 2 '''''
| <code> getParticipantEntriesInCourses </code>
| Confusing code. Appends each entry to the end of list
| Used concat to clarify that we are adding the independent and other assignments in courses.
|-
|''''' 3 '''''
| <code> sortHash </code>
| in place changes.
| Returns a new deep copy of the updated hash.
|-
|''''' 4 '''''
| <code> extractPersonalAchievements </code>
| Confusing code with extra data base calls.
| This method is refactored to use only 1 database call unlike several within the loop in its prior implementation. We have also removed redundant code computation and made the logic easier to understand. The overall complexity of this method is reduced from 72 to 35.
|-
|''''' 5 '''''
| <code> addEntryToCSHash </code>
| Confusing name and hard to follow logic.
| The new method name is <code> addScoreToResultantHash </code>. As mentioned earlier, this is called internally by <code> getParticipantEntriesInAssignmentList </code>. The complexity of this method is reduced from 67 to 39 .
|-
|''''' 6 '''''
| <code> getParticipantEntriesInAssignmentList </code>
| This method was the most complex method in the class.
| The new refactored method name is <code> getParticipantsScore </code>. The method was refactored on various aspects like reducing database calls drastically, removing redundant code computation, redundant data storage in complex group of hashes and series of conditional statements. We would like to mention that previously, the method had 10 database calls within loop and 1 outside loop. After refactoring, the new method has just 1 database call within loop and 3 outside loops. Also, the overall code complexity is reduced from 142 to 64.
|-
|}

=Changes In Helper (leaderboard_helper.rb) =
{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| <code> userIsInstructor </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls. 4
database calls was replaced by single call.
|-
|''''' 2 '''''
| <code> studentInWhichCourses </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls
and remove unnecessary loops. 1 database call outside and 1 within a loop was replaced
by a single call.
|-
|''''' 3 '''''
| <code> getTop3Leaderboards </code>
| Dead code
| Removed.
|-
|}

There are several other changes in the views and controller which deal with renaming of the methods
and variables, adding proper comments etc and minor code refactoring. Please refer to our forked
github repository to view those changes.

=Testing=

Refactored Instance : http://152.1.13.181:3000 
Original Instance : http://152.1.13.181:3001

On VCL session there are 2 instances running. On <code> port 3001 </code> the orignal instance is setup and on <code> port 3000 </code> the refactored instance is setup.
In below images we have shown that the output after refactoring is same. We changed the order in which the output is displayed to make it more coherent.

{| class="wikitable"
|-
! View of Refactored Leaderboard
! View of Original Leaderboard

|-
| [[File:Refactored_Leaderboard_file.jpg|frame|left| ]]
| [[File:Non_Refactored_Leaderboard_file.jpg|frame|left| ]]

|-
| [[File:Refactored_personal_achievement_file.jpg|frame|left| ]]
| [[File:Non_personal_achievement_file.jpg|frame|left| ]]

|}

=Optimization=

The refactoring process included reducing the database calls, loops and redundant storage and computation in all classes associated with Leaderboard functionality. While refactoring, the team has ensured to improve the readability of the code too by renaming ambiguous method and variable names and adding relevant comments to explain the objective of a code construct.

== Code Optimization ==

In the project description code complexity has been highlighted for several methods. [https://codeclimate.com/ Code Climate]<ref>[https://codeclimate.com/ Code Climate]</ref> has been used to measure the code complexity of the current repository of Expertiza. After refactoring, we used the same tool i.e. Code Climate to measure the code complexity. Following is the snapshot of code complexity of <code> Leaderboard.rb </code> from Code Climate.

[[File:CodeClimate_codecomplexity.png|center]]

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%.

== Performance Optimization ==

Google Chrome extension [https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time] gives time to load a page.
We tried this extension to measure performance change after refactoring. We noticed that the time to load page reduced by 10-15%.

This table indicates time to load page in seconds
{| class="wikitable"
|-
| Iteration
! Original Version
! Refactored Version

|-
|1
| 2.08
| 1.76
|-
|2
| 2.02
| 1.66
|-
|3
| 2.01
| 1.76
|-
|4
| 1.97
| 1.76
|-
|5
| 1.93
| 1.72
|-
|6
| 1.97
| 1.75
|-
|7
| 2.12
| 1.74
|-
|8
| 1.99
| 1.71
|-
|9
| 2.12
| 1.80
|-
|10
| 2.00
| 1.75
|}

=Future Work=
There was a requirement in the project, that we should come up with an efficient way to search for participants based on assignment ids. However, upon investigation, we found that scores stored in table ScoreCache, gives us revieweeId which is either participantId or teamId. Therefore, we have a method <code> getAssignmentMapping </code>, which creates a mapping of participant and team with corresponding assignment. This is very useful while computing leaderboard.

Lastly, we would like to recommend the readers to test the leaderboard functionality by any user who has participated in several assignments, some of them which is associated with any course and there
are other existing users who have participated in the same assignment. e.g. user480/password

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T19:36:15Z

Spsingh2: /* Changes In Model (leaderboard.rb) */

=Introduction=
'''Project name: [https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]'''<ref>[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit E1467: Expertiza - Refactoring LeaderBoard model]</ref>

Our project is to refactor the code in the ''"Leaderboard"'' functionality of the web application [https://github.com/expertiza/expertiza Expertiza]<ref>[https://github.com/expertiza/expertiza Expertiza]</ref>. The Expertiza project is a system to create reusable learning objects through peer review. The leaderboard functionality is to show top 3 individual scorers in each questionnaire types, in each courses. The leaderboard also shows the current standing of the logged in user under personal achievements.

__TOC__

=Project Description=
'''Classes involved:''' ''leaderboard.rb'' and associated other model and controllers classes.

1. Come up with an efficient way to search for participants based on assignment ids.

2. Refactor score hash for personal achievements. (Method: <code> extractPersonalAchievements </code>). Seperate out method which will rank individual personal achievements.

3. Refactor <code> addEntryToCSHash </code> according to your new metric method.

4. Seperate out computation of CS entries(metric) and refactor it to be more modular and elegant.

5. Refactor <code> getParticipantEntriesInAssignmentList </code> method. Its very complex (Complexity=142).

6. Refactor <code> addEntryToCSHash </code> according to your new metric method.

=Existing Functionality=
Leaderboard class gets all the assignments within all the courses taken by currently logged in user. It
also fetches any independent assignments (not associated with any course), that the user has taken.

Leaderboard model has following 3 important methods:
{| class="wikitable"
|-
! style="width:3%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:43%;"|Comment
|- style="vertical-align:top;"
|-
|''''' 1 '''''
| <code> getParticipantEntriesInAssignmentList(assignmentList) </code>
|This method is responsible for calculating the leaderboard of all the participants associated with assignments in given assignment list.
|-
|''''' 2 '''''
| <code> extractPersonalAchievements(csHash, courseIdList, userId) </code>
| This method is responsible for calculating personal aggregated score. It also calculates the ranking of currently logged in user against total users associated with the same set of courses as that of current user.
|-
|''''' 3 '''''
| <code> addEntryToCSHash(qtypeHash, qtype, userid, csEntry, courseid) </code>
| This method is called internally from <code> Leaderboard.getParticipantEntriesInAssignmentList </code>. This method aggregates score of a user grouped by course id, further grouped by questionnaire type.
|-
|}

In the OSS project, we have refactored these methods along with other smaller methods in
<code> Leaderboard.rb </code>, <code> Leaderboard_helper.rb </code>, <code> Leaderboard_controller.rb </code> and associated views files. We have also refactored ambiguous variable and method names.

We have keenly focussed in reducing the database calls, loops and redundant storage and computation. We have refactored many files related to Leaderboard implementation leading to enhancement of overall complexity of the feature.

=Changes In Model (leaderboard.rb) =
{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| <code> getIndependantAssignments </code>
| Separate db call for each user assignment.
| Single db call with an array of assignment ids.
|-
|''''' 2 '''''
| <code> getParticipantEntriesInCourses </code>
| Confusing code. Appends each entry to the end of list
| Used concat to clarify that we are adding the independent and other assignments in courses.
|-
|''''' 3 '''''
| <code> sortHash </code>
| in place changes.
| Returns a new deep copy of the updated hash.
|-
|''''' 4 '''''
| <code> extractPersonalAchievements </code>
| Confusing code with extra data base calls.
| This method is refactored to use only 1 database call unlike several within the loop in its prior implementation. We have also removed redundant code computation and made the logic easier to understand. The overall complexity of this method is reduced from 72 to 35.
|-
|''''' 5 '''''
| <code> addEntryToCSHash </code>
| Confusing name and hard to follow logic.
| The new method name is <code> addScoreToResultantHash </code>. As mentioned earlier, this is called internally by <code> getParticipantEntriesInAssignmentList </code>. The complexity of this method is reduced from 67 to 39 .
|-
|''''' 6 '''''
| <code> getParticipantEntriesInAssignmentList </code>
| This method was the most complex method in the class.
| The new refactored method name is <code> getParticipantsScore </code>. The method was
refactored on various aspects like reducing database calls drastically, removing redundant
code computation, redundant data storage in complex group of hashes and series of
conditional statements. We would like to mention that previously, the method had 10
database calls within loop and 1 outside loop. After refactoring, the new method has just 1
database call within loop and 3 outside loops. Also, the overall code complexity is reduced
from 142 to 64.
|-
|}

=Changes In Helper (leaderboard_helper.rb) =
{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| <code> userIsInstructor </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls. 4
database calls was replaced by single call.
|-
|''''' 2 '''''
| <code> studentInWhichCourses </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls
and remove unnecessary loops. 1 database call outside and 1 within a loop was replaced
by a single call.
|-
|''''' 3 '''''
| <code> getTop3Leaderboards </code>
| Dead code
| Removed.
|-
|}

There are several other changes in the views and controller which deal with renaming of the methods
and variables, adding proper comments etc and minor code refactoring. Please refer to our forked
github repository to view those changes.

=Testing=

Refactored Instance : http://152.1.13.181:3000 
Original Instance : http://152.1.13.181:3001

On VCL session there are 2 instances running. On <code> port 3001 </code> the orignal instance is setup and on <code> port 3000 </code> the refactored instance is setup.
In below images we have shown that the output after refactoring is same. We changed the order in which the output is displayed to make it more coherent.

{| class="wikitable"
|-
! View of Refactored Leaderboard
! View of Original Leaderboard

|-
| [[File:Refactored_Leaderboard_file.jpg|frame|left| ]]
| [[File:Non_Refactored_Leaderboard_file.jpg|frame|left| ]]

|-
| [[File:Refactored_personal_achievement_file.jpg|frame|left| ]]
| [[File:Non_personal_achievement_file.jpg|frame|left| ]]

|}

=Optimization=

The refactoring process included reducing the database calls, loops and redundant storage and computation in all classes associated with Leaderboard functionality. While refactoring, the team has ensured to improve the readability of the code too by renaming ambiguous method and variable names and adding relevant comments to explain the objective of a code construct.

== Code Optimization ==

In the project description code complexity has been highlighted for several methods. [https://codeclimate.com/ Code Climate]<ref>[https://codeclimate.com/ Code Climate]</ref> has been used to measure the code complexity of the current repository of Expertiza. After refactoring, we used the same tool i.e. Code Climate to measure the code complexity. Following is the snapshot of code complexity of <code> Leaderboard.rb </code> from Code Climate.

[[File:CodeClimate_codecomplexity.png|center]]

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%.

== Performance Optimization ==

Google Chrome extension [https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en Page Load Time] gives time to load a page.
We tried this extension to measure performance change after refactoring. We noticed that the time to load page reduced by 10-15%.

This table indicates time to load page in seconds
{| class="wikitable"
|-
| Iteration
! Original Version
! Refactored Version

|-
|1
| 2.08
| 1.76
|-
|2
| 2.02
| 1.66
|-
|3
| 2.01
| 1.76
|-
|4
| 1.97
| 1.76
|-
|5
| 1.93
| 1.72
|-
|6
| 1.97
| 1.75
|-
|7
| 2.12
| 1.74
|-
|8
| 1.99
| 1.71
|-
|9
| 2.12
| 1.80
|-
|10
| 2.00
| 1.75
|}

=Future Work=
There was a requirement in the project, that we should come up with an efficient way to search for participants based on assignment ids. However, upon investigation, we found that scores stored in table ScoreCache, gives us revieweeId which is either participantId or teamId. Therefore, we have a method <code> getAssignmentMapping </code>, which creates a mapping of participant and team with corresponding assignment. This is very useful while computing leaderboard.

Lastly, we would like to recommend the readers to test the leaderboard functionality by any user who has participated in several assignments, some of them which is associated with any course and there
are other existing users who have participated in the same assignment. e.g. user480/password

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T19:32:22Z

Spsingh2: /* Changes In Model (leaderboard.rb) */

=Introduction=
'''Project name: [https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit#heading=h.p92p30rar40t E1467: Expertiza - Refactoring LeaderBoard model]'''

Our project is to refactor the code in the ''"Leaderboard"'' functionality of the web application [https://github.com/expertiza/expertiza Expertiza]<ref>[https://github.com/expertiza/expertiza Expertiza]</ref>. The Expertiza project is a system to create reusable learning objects through peer review. The leaderboard functionality is to show top 3 individual scorers in each questionnaire types, in each courses. The leaderboard also shows the current standing of the logged in user under personal achievements.

__TOC__

=Project Description=
Classes involved: leaderboard.rb and associated other model and controllers classes.

1. Come up with an efficient way to search for participants based on assignment ids.

2. Refactor score hash for personal achievements. (Method: <code> extractPersonalAchievements </code>). Seperate out method which will rank individual personal achievements.

3. Refactor <code> addEntryToCSHash </code> according to your new metric method.

4. Seperate out computation of CS entries(metric) and refactor it to be more modular and elegant.

5. Refactor <code> getParticipantEntriesInAssignmentList </code> method. Its very complex (Complexity=142).

6. Refactor <code> addEntryToCSHash </code> according to your new metric method.

=Existing Functionality=
Leaderboard class gets all the assignments within all the courses taken by currently logged in user. It
also fetches any independent assignments (not associated with any course), that the user has taken.

Leaderboard model has following 3 important methods:
{| class="wikitable"
|-
! style="width:3%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:43%;"|Comment
|- style="vertical-align:top;"
|-
|''''' 1 '''''
| <code> getParticipantEntriesInAssignmentList(assignmentList) </code>
|This method is responsible for calculating the leaderboard of all the participants associated with assignments in given assignment list.
|-
|''''' 2 '''''
| <code> extractPersonalAchievements(csHash, courseIdList, userId) </code>
| This method is responsible for calculating personal aggregated score. It also calculates the ranking of currently logged in user against total users associated with the same set of courses as that of current user.
|-
|''''' 3 '''''
| <code> addEntryToCSHash(qtypeHash, qtype, userid, csEntry, courseid) </code>
| This method is called internally from <code> Leaderboard.getParticipantEntriesInAssignmentList </code>. This method aggregates score of a user grouped by course id, further grouped by questionnaire type.
|-
|}

In the OSS project, we have refactored these methods along with other smaller methods in
<code> Leaderboard.rb </code>, <code> Leaderboard_helper.rb </code>, <code> Leaderboard_controller.rb </code> and associated views files. We have also refactored ambiguous variable and method names.

We have keenly focussed in reducing the database calls, loops and redundant storage and computation. We have refactored many files related to Leaderboard implementation leading to enhancement of overall complexity of the feature.

=Changes In Model (leaderboard.rb) =
{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| <code> getIndependantAssignments </code>
| Separate db call for each user assignment.
| Single db call with an array of assignment ids.
|-
|''''' 2 '''''
| <code> getParticipantEntriesInCourses </code>
| Confusing code. Appends each entry to the end of list
| Used concat to clarify that we are adding the independent and other assignments in courses.
|-
|''''' 3 '''''
| <code> sortHash </code>
| in place changes.
| Returns a new deep copy of the updated hash.
|-
|''''' 4 '''''
| <code> extractPersonalAchievements </code>
| Confusing code with extra data base calls.
| This method is refactored to use only 1 database call unlike several within the loop in its prior implementation. We have also removed redundantcode computation and made the logic easier to understand. The overall complexity of this method is reduced from 72 to 35.
|-
|''''' 5 '''''
| <code> addEntryToCSHash </code>
| Confusing code with extra data base calls.
| The new method name is <code> addScoreToResultantHash </code>. As mentioned earlier, this is called internally
by <code> getParticipantEntriesInAssignmentList </code>. The complexity of this method is reduced from 67 to 39 .
|-
|''''' 6 '''''
| <code> getParticipantEntriesInAssignmentList </code>
| This method was the most complex method in the class.
| The new refactored method name is <code> getParticipantsScore </code>. The method was
refactored on various aspects like reducing database calls drastically, removing redundant
code computation, redundant data storage in complex group of hashes and series of
conditional statements. We would like to mention that previously, the method had 10
database calls within loop and 1 outside loop. After refactoring, the new method has just 1
database call within loop and 3 outside loops. Also, the overall code complexity is reduced
from 142 to 64.
|-
|}

=Changes In Helper (leaderboard_helper.rb) =
{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| <code> userIsInstructor </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls. 4
database calls was replaced by single call.
|-
|''''' 2 '''''
| <code> studentInWhichCourses </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls
and remove unnecessary loops. 1 database call outside and 1 within a loop was replaced
by a single call.
|-
|''''' 3 '''''
| <code> getTop3Leaderboards </code>
| Dead code
| Removed.
|-
|}

There are several other changes in the views and controller which deal with renaming of the methods
and variables, adding proper comments etc and minor code refactoring. Please refer to our forked
github repository to view those changes.

=Testing=

Refactored Instance : http://152.1.13.181:3000 
Original Instance : http://152.1.13.181:3001

On VCL session there are 2 instances running. On <code> port 3001 </code> the orignal instance is setup and on <code> port 3000 </code> the refactored instance is setup.
In below images we have shown that the output after refactoring is same. We changed the order in which the output is displayed to make it more coherent.

{| class="wikitable"
|-
! View of Refactored Leaderboard
! View of Original Leaderboard

|-
| [[File:Refactored_Leaderboard_file.jpg|frame|left| ]]
| [[File:Non_Refactored_Leaderboard_file.jpg|frame|left| ]]

|-
| [[File:Refactored_personal_achievement_file.jpg|frame|left| ]]
| [[File:Non_personal_achievement_file.jpg|frame|left| ]]

|}

=Optimization=

The refactoring process included reducing the database calls, loops and redundant storage and computation in all classes associated with Leaderboard functionality. While refactoring, the team has ensured to improve the readability of the code too by renaming ambiguous method and variable names and adding relevant comments to explain the objective of a code construct.

== Code Optimization ==

In the project description code complexity has been highlighted for several methods. [https://codeclimate.com/ Code Climate]<ref>[https://codeclimate.com/ Code Climate]</ref> has been used to measure the code complexity of the current repository of Expertiza. After refactoring, we used the same tool i.e. Code Climate to measure the code complexity. Following is the snapshot of code complexity of <code> Leaderboard.rb </code> from Code Climate.

[[File:CodeClimate_codecomplexity.png|center]]

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%.

== Performance Optimization ==

Google Chrome extension [https://chrome.google.com/webstore/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=en | Page Load Time] gives time to load a page.
We tried this extension to measure performance change after refactoring. We noticed that the time to load page reduced by 10-15%.

{| class="wikitable"
|-
! Original Version
! Refactored Version

|-
| 2.08
| 1.76
|-
| 2.02
| 1.66
|-
| 2.01
| 1.76
|-
| 1.97
| 1.76
|-
| 1.93
| 1.72
|-
| 1.97
| 1.75
|-
| 2.12
| 1.74
|-
| 1.99
| 1.71
|-
| 2.12
| 1.80
|-
| 2.00
| 1.75
|}

=Future Work=
There was a requirement in the project, that we should come up with an efficient way to search for participants based on assignment ids. However, upon investigation, we found that scores stored in table ScoreCache, gives us revieweeId which is either participantId or teamId. Therefore, we have a method <code> getAssignmentMapping </code>, which creates a mapping of participant and team with corresponding assignment. This is very useful while computing leaderboard.

Lastly, we would like to recommend the readers to test the leaderboard functionality by any user who has participated in several assignments, some of them which is associated with any course and there
are other existing users who have participated in the same assignment. e.g. user480/password

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T19:17:16Z

Spsingh2: /* Changes In Model (leaderboard.rb) */

=Introduction=
'''Project name: [https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit#heading=h.p92p30rar40t E1467: Expertiza - Refactoring LeaderBoard model]'''

Our project is to refactor the code in the ''"Leaderboard"'' functionality of the web application [https://github.com/expertiza/expertiza Expertiza]<ref>[https://github.com/expertiza/expertiza Expertiza]</ref>. The Expertiza project is a system to create reusable learning objects through peer review. The leaderboard functionality is to show top 3 individual scorers in each questionnaire types, in each courses. The leaderboard also shows the current standing of the logged in user under personal achievements.

__TOC__

=Project Description=
Classes involved: leaderboard.rb and associated other model and controllers classes.

1. Come up with an efficient way to search for participants based on assignment ids.

2. Refactor score hash for personal achievements. (Method: <code> extractPersonalAchievements </code>). Seperate out method which will rank individual personal achievements.

3. Refactor <code> addEntryToCSHash </code> according to your new metric method.

4. Seperate out computation of CS entries(metric) and refactor it to be more modular and elegant.

5. Refactor <code> getParticipantEntriesInAssignmentList </code> method. Its very complex (Complexity=142).

6. Refactor <code> addEntryToCSHash </code> according to your new metric method.

=Existing Functionality=
Leaderboard class gets all the assignments within all the courses taken by currently logged in user. It
also fetches any independent assignments (not associated with any course), that the user has taken.

Leaderboard model has following 3 important methods:
{| class="wikitable"
|-
! style="width:3%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:43%;"|Comment
|- style="vertical-align:top;"
|-
|''''' 1 '''''
| <code> getParticipantEntriesInAssignmentList(assignmentList) </code>
|This method is responsible for calculating the leaderboard of all the participants associated with assignments in given assignment list.
|-
|''''' 2 '''''
| <code> extractPersonalAchievements(csHash, courseIdList, userId) </code>
| This method is responsible for calculating personal aggregated score. It also calculates the ranking of currently logged in user against total users associated with the same set of courses as that of current user.
|-
|''''' 3 '''''
| <code> addEntryToCSHash(qtypeHash, qtype, userid, csEntry, courseid) </code>
| This method is called internally from <code> Leaderboard.getParticipantEntriesInAssignmentList </code>. This method aggregates score of a user grouped by course id, further grouped by questionnaire type.
|-
|}

In the OSS project, we have refactored these methods along with other smaller methods in
<code> Leaderboard.rb </code>, <code> Leaderboard_helper.rb </code>, <code> Leaderboard_controller.rb </code> and associated views files. We have also refactored ambiguous variable and method names.

We have keenly focussed in reducing the database calls, loops and redundant storage and computation. We have refactored many files related to Leaderboard implementation leading to enhancement of overall complexity of the feature.

=Changes In Model (leaderboard.rb) =
{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| <code> getIndependantAssignments </code>
| Separate db call for each user assignment.
| Single db call with an array of assignment ids.
|-
|''''' 2 '''''
| <code> getParticipantEntriesInCourses </code>
| Confusing code. Appends each entry to the end of list
| Used concat to clarify that we are adding the independent and other assignments in courses.
|-
|''''' 3 '''''
| <code> sortHash </code>
| in place changes.
| Returns a new deep copy of the updated hash.
|-
|''''' 4 '''''
| <code> extractPersonalAchievements </code>
| Confusing code with extra data base calls.
| This method is refactored to use only 1 database call
unlike several within the loop in its prior implementation. We have also removed redundantcode computation and made the logic easier to understand. The overall complexity of this
method is reduced from 72 to 35.
|-
|''''' 5 '''''
| <code> addEntryToCSHash </code>
| Confusing code with extra data base calls.
| The new method name is <code> addScoreToResultantHash </code>. As mentioned earlier, this is called internally
by <code> getParticipantEntriesInAssignmentList </code>. The complexity of this method is reduced from 67 to 39 .
|-
|''''' 6 '''''
| <code> getParticipantEntriesInAssignmentList </code>
| This method was the most complex method in the class.
| The new refactored method name is <code> getParticipantsScore </code>. The method was
refactored on various aspects like reducing database calls drastically, removing redundant
code computation, redundant data storage in complex group of hashes and series of
conditional statements. We would like to mention that previously, the method had 10
database calls within loop and 1 outside loop. After refactoring, the new method has just 1
database call within loop and 3 outside loops. Also, the overall code complexity is reduced
from 142 to 64.
|-
|}

=Changes In Helper (leaderboard_helper.rb) =
{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| <code> userIsInstructor </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls. 4
database calls was replaced by single call.
|-
|''''' 2 '''''
| <code> studentInWhichCourses </code>
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls
and remove unnecessary loops. 1 database call outside and 1 within a loop was replaced
by a single call.
|-
|''''' 3 '''''
| <code> getTop3Leaderboards </code>
| Dead code
| Removed.
|-
|}

There are several other changes in the views and controller which deal with renaming of the methods
and variables, adding proper comments etc and minor code refactoring. Please refer to our forked
github repository to view those changes.

=Testing=

Refactored Instance : http://152.1.13.181:3000 
Original Instance : http://152.1.13.181:3001

On VCL session there are 2 instances running. On <code> port 3001 </code> the orignal instance is setup and on <code> port 3000 </code> the refactored instance is setup.
In below images we have shown that the output after refactoring is same. We changed the order in which the output is displayed to make it more coherent.

{| class="wikitable"
|-
! View of Refactored Leaderboard
! View of Original Leaderboard

|-
| [[File:Refactored_Leaderboard_file.jpg|frame|left| ]]
| [[File:Non_Refactored_Leaderboard_file.jpg|frame|left| ]]

|-
| [[File:Refactored_personal_achievement_file.jpg|frame|left| ]]
| [[File:Non_personal_achievement_file.jpg|frame|left| ]]

|}

=Optimization=

=Future Work=
There was a requirement in the project, that we should come up with an efficient way to search for participants based on assignment ids. However, upon investigation, we found that scores stored in table ScoreCache, gives us revieweeId which is either participantId or teamId. Therefore, we have a method <code> getAssignmentMapping </code>, which creates a mapping of participant and team with corresponding assignment. This is very useful while computing leaderboard.

Lastly, we would like to recommend the readers to test the leaderboard functionality by any user who has participated in several assignments, some of them which is associated with any course and there
are other existing users who have participated in the same assignment. e.g. user480/password

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T18:03:38Z

Spsingh2: /* Future Work */

[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit#heading=h.p92p30rar40t Writeup Page]
Expertiza - Refactoring LeaderBoard model

Our project is to refactor the code in the "Leaderboard" functionality of the web application Expertiza<ref name="expertiza>''Expertiza'' http://wikis.lib.ncsu.edu/index.php/Expertiza</ref>. The Expertiza project is a system to create reusable learning objects through peer review. The classes involved gets all the assignments in the course and all the participants in a course or in an assignment. The responsibility of the leaderboard module is to generate the top 3 individuals which is to be displayed as the leaderboard for the class and a personal leaderboard view to see a personal aggregated score.

__TOC__

=Project Description=
Classes involved: leaderboard.rb and associated other model and controllers classes.

1. Come up with an efficient way to search for participants based on assignment ids.

2. Refactor score hash for personal achievements. (Method: <code> extractPersonalAchievements </code>). Seperate out method which will rank individual personal achievements.

3. Refactor <code> addEntryToCSHash </code> according to your new metric method.

4. Seperate out computation of CS entries(metric) and refactor it to be more modular and elegant.

5. Refactor <code> getParticipantEntriesInAssignmentList </code> method. Its very complex (Complexity=142).

6. Refactor <code> addEntryToCSHash </code> according to your new metric method.

=Existing Functionality=
Leaderboard class gets all the assignments within all the courses taken by currently logged in user. It
also fetches any independent assignments (not associated with any course), that the user has taken.

Leaderboard model has following 3 important methods:
{| class="wikitable"
|-
! style="width:3%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:43%;"|Comment
|- style="vertical-align:top;"
|-
|''''' 1 '''''
| <code> getParticipantEntriesInAssignmentList(assignmentList) </code>
|This method is responsible for calculating the leaderboard of all the participants associated with assignments in given assignment list.
|-
|''''' 2 '''''
| <code> extractPersonalAchievements(csHash, courseIdList, userId) </code>
| This method is responsible for calculating personal aggregated score. It also calculates the ranking of currently logged in user against total users associated with the same set of courses as that of current user.
|-
|''''' 3 '''''
| <code> addEntryToCSHash(qtypeHash, qtype, userid, csEntry, courseid) </code>
| This method is called internally from <code> Leaderboard.getParticipantEntriesInAssignmentList </code>. This method aggregates score of a user grouped by course id, further grouped by questionnaire type.
|-
|}

In the OSS project, we have refactored these methods along with other smaller methods in
<code> Leaderboard.rb </code>, <code> Leaderboard_helper.rb </code>. We have also refactored ambiguous variable and method
names.

We have keenly focussed in reducing the database calls, loops and redundant storage and
computation.
We have refactored many files related to Leaderboard implementation leading to
enhancement of overall complexity of the feature.

=Changes In Model (leaderboard.rb) =
{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| getIndependantAssignments
| Reduced the number of database calls within loop.
| Less complexity and runs faster.
|-
|''''' 2 '''''
| getParticipantEntriesInCourses
| Reduced the number of database calls within loop.
| Less complexity and runs faster.
|-
|''''' 3 '''''
| sortHash
| in place changes.
| Returns a new deep copy of the updated hash.
|-
|''''' 4 '''''
| extractPersonalAchievements
| Confusing code with extra data base calls.
| This method is refactored to use only 1 database call
unlike several within the loop in its prior implementation. We have also removed redundantcode computation and made the logic easier to understand. The overall complexity of this
method is reduced from 72 to 35.
|-
|''''' 5 '''''
| addEntryToCSHash
| Confusing code with extra data base calls.
| The new method name is addScoreToResultantHash. As mentioned earlier, this is called internally
by getParticipantEntriesInAssignmentList. The complexity of this method is reduced from 67 to 39 .
|-
|''''' 6 '''''
| getParticipantEntriesInAssignmentList
| This method was the most complex method in the class.
| The new refactored method name is getParticipantsScore. The method was
refactored on various aspects like reducing database calls drastically, removing redundant
code computation, redundant data storage in complex group of hashes and series of
conditional statements. We would like to mention that previously, the method had 10
database calls within loop and 1 outside loop. After refactoring, the new method has just 1
database call within loop and 3 outside loops. Also, the overall code complexity is reduced
from 142 to 64.
|-
|}

=Changes In Helper (leaderboard_helper.rb) =
{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| userIsInstructor
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls. 4
database calls was replaced by single call.
|-
|''''' 2 '''''
| studentInWhichCourses
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls
and remove unnecessary loops. 1 database call outside and 1 within a loop was replaced
by a single call.
|-
|''''' 3 '''''
| getTop3Leaderboards
| Dead code
| Removed.
|-
|}

There are several other changes in the views and controller which deal with renaming of the methods
and variables, adding proper comments etc and minor code refactoring. Please refer to our forked
github repository to view those changes.

=Testing=

{| class="wikitable"
|-
! View of Refactored Leaderboard
! View of non Refactored Leaderboard

|-
| [[File:Refactored_Leaderboard_file.jpg|frame|left| ]]
| [[File:Non_Refactored_Leaderboard_file.jpg|frame|left| ]]

|}

=Optimization=

=Future Work=
There was a requirement in the project, that we should come up with an efficient way to search for participants based on assignment ids. However, upon investigation, we found that scores stored in table ScoreCache, gives us revieweeId which is either participantId or teamId. Therefore, we have a method getAssignmentMapping, which creates a mapping of participant and team with corresponding assignment. This is very useful while computing leaderboard.

Lastly, we would like to recommend the readers to test the leaderboard functionality by any user who has participated in several assignments, some of them which is associated with any course and there
are other existing users who have participated in the same assignment. e.g. user480/password

= References=
[http://expertiza.ncsu.edu/ Expertiza]

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T18:03:12Z

Spsingh2: /* Changes In Helper (leaderboard_helper.rb) */

[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit#heading=h.p92p30rar40t Writeup Page]
Expertiza - Refactoring LeaderBoard model

Our project is to refactor the code in the "Leaderboard" functionality of the web application Expertiza<ref name="expertiza>''Expertiza'' http://wikis.lib.ncsu.edu/index.php/Expertiza</ref>. The Expertiza project is a system to create reusable learning objects through peer review. The classes involved gets all the assignments in the course and all the participants in a course or in an assignment. The responsibility of the leaderboard module is to generate the top 3 individuals which is to be displayed as the leaderboard for the class and a personal leaderboard view to see a personal aggregated score.

__TOC__

=Project Description=
Classes involved: leaderboard.rb and associated other model and controllers classes.

1. Come up with an efficient way to search for participants based on assignment ids.

2. Refactor score hash for personal achievements. (Method: <code> extractPersonalAchievements </code>). Seperate out method which will rank individual personal achievements.

3. Refactor <code> addEntryToCSHash </code> according to your new metric method.

4. Seperate out computation of CS entries(metric) and refactor it to be more modular and elegant.

5. Refactor <code> getParticipantEntriesInAssignmentList </code> method. Its very complex (Complexity=142).

6. Refactor <code> addEntryToCSHash </code> according to your new metric method.

=Existing Functionality=
Leaderboard class gets all the assignments within all the courses taken by currently logged in user. It
also fetches any independent assignments (not associated with any course), that the user has taken.

Leaderboard model has following 3 important methods:
{| class="wikitable"
|-
! style="width:3%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:43%;"|Comment
|- style="vertical-align:top;"
|-
|''''' 1 '''''
| <code> getParticipantEntriesInAssignmentList(assignmentList) </code>
|This method is responsible for calculating the leaderboard of all the participants associated with assignments in given assignment list.
|-
|''''' 2 '''''
| <code> extractPersonalAchievements(csHash, courseIdList, userId) </code>
| This method is responsible for calculating personal aggregated score. It also calculates the ranking of currently logged in user against total users associated with the same set of courses as that of current user.
|-
|''''' 3 '''''
| <code> addEntryToCSHash(qtypeHash, qtype, userid, csEntry, courseid) </code>
| This method is called internally from <code> Leaderboard.getParticipantEntriesInAssignmentList </code>. This method aggregates score of a user grouped by course id, further grouped by questionnaire type.
|-
|}

In the OSS project, we have refactored these methods along with other smaller methods in
<code> Leaderboard.rb </code>, <code> Leaderboard_helper.rb </code>. We have also refactored ambiguous variable and method
names.

We have keenly focussed in reducing the database calls, loops and redundant storage and
computation.
We have refactored many files related to Leaderboard implementation leading to
enhancement of overall complexity of the feature.

=Changes In Model (leaderboard.rb) =
{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| getIndependantAssignments
| Reduced the number of database calls within loop.
| Less complexity and runs faster.
|-
|''''' 2 '''''
| getParticipantEntriesInCourses
| Reduced the number of database calls within loop.
| Less complexity and runs faster.
|-
|''''' 3 '''''
| sortHash
| in place changes.
| Returns a new deep copy of the updated hash.
|-
|''''' 4 '''''
| extractPersonalAchievements
| Confusing code with extra data base calls.
| This method is refactored to use only 1 database call
unlike several within the loop in its prior implementation. We have also removed redundantcode computation and made the logic easier to understand. The overall complexity of this
method is reduced from 72 to 35.
|-
|''''' 5 '''''
| addEntryToCSHash
| Confusing code with extra data base calls.
| The new method name is addScoreToResultantHash. As mentioned earlier, this is called internally
by getParticipantEntriesInAssignmentList. The complexity of this method is reduced from 67 to 39 .
|-
|''''' 6 '''''
| getParticipantEntriesInAssignmentList
| This method was the most complex method in the class.
| The new refactored method name is getParticipantsScore. The method was
refactored on various aspects like reducing database calls drastically, removing redundant
code computation, redundant data storage in complex group of hashes and series of
conditional statements. We would like to mention that previously, the method had 10
database calls within loop and 1 outside loop. After refactoring, the new method has just 1
database call within loop and 3 outside loops. Also, the overall code complexity is reduced
from 142 to 64.
|-
|}

=Changes In Helper (leaderboard_helper.rb) =
{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| userIsInstructor
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls. 4
database calls was replaced by single call.
|-
|''''' 2 '''''
| studentInWhichCourses
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls
and remove unnecessary loops. 1 database call outside and 1 within a loop was replaced
by a single call.
|-
|''''' 3 '''''
| getTop3Leaderboards
| Dead code
| Removed.
|-
|}

There are several other changes in the views and controller which deal with renaming of the methods
and variables, adding proper comments etc and minor code refactoring. Please refer to our forked
github repository to view those changes.

=Testing=

{| class="wikitable"
|-
! View of Refactored Leaderboard
! View of non Refactored Leaderboard

|-
| [[File:Refactored_Leaderboard_file.jpg|frame|left| ]]
| [[File:Non_Refactored_Leaderboard_file.jpg|frame|left| ]]

|}

=Optimization=

=Future Work=
There was a requirement in the project, that we should come up with an efficient way to search for participants based on assignment ids. However, upon investigation, we found that scores stored in table ScoreCache, gives us revieweeId which is either participantId or teamId. Therefore, we have a method getAssignmentMapping, which creates a mapping of participant and team with corresponding assignment. This is very useful while computing leaderboard.

= References=
[http://expertiza.ncsu.edu/ Expertiza]

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T18:00:36Z

Spsingh2: /* Changes In Model (leaderboard.rb) */

[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit#heading=h.p92p30rar40t Writeup Page]
Expertiza - Refactoring LeaderBoard model

Our project is to refactor the code in the "Leaderboard" functionality of the web application Expertiza<ref name="expertiza>''Expertiza'' http://wikis.lib.ncsu.edu/index.php/Expertiza</ref>. The Expertiza project is a system to create reusable learning objects through peer review. The classes involved gets all the assignments in the course and all the participants in a course or in an assignment. The responsibility of the leaderboard module is to generate the top 3 individuals which is to be displayed as the leaderboard for the class and a personal leaderboard view to see a personal aggregated score.

__TOC__

=Project Description=
Classes involved: leaderboard.rb and associated other model and controllers classes.

1. Come up with an efficient way to search for participants based on assignment ids.

2. Refactor score hash for personal achievements. (Method: <code> extractPersonalAchievements </code>). Seperate out method which will rank individual personal achievements.

3. Refactor <code> addEntryToCSHash </code> according to your new metric method.

4. Seperate out computation of CS entries(metric) and refactor it to be more modular and elegant.

5. Refactor <code> getParticipantEntriesInAssignmentList </code> method. Its very complex (Complexity=142).

6. Refactor <code> addEntryToCSHash </code> according to your new metric method.

=Existing Functionality=
Leaderboard class gets all the assignments within all the courses taken by currently logged in user. It
also fetches any independent assignments (not associated with any course), that the user has taken.

Leaderboard model has following 3 important methods:
{| class="wikitable"
|-
! style="width:3%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:43%;"|Comment
|- style="vertical-align:top;"
|-
|''''' 1 '''''
| <code> getParticipantEntriesInAssignmentList(assignmentList) </code>
|This method is responsible for calculating the leaderboard of all the participants associated with assignments in given assignment list.
|-
|''''' 2 '''''
| <code> extractPersonalAchievements(csHash, courseIdList, userId) </code>
| This method is responsible for calculating personal aggregated score. It also calculates the ranking of currently logged in user against total users associated with the same set of courses as that of current user.
|-
|''''' 3 '''''
| <code> addEntryToCSHash(qtypeHash, qtype, userid, csEntry, courseid) </code>
| This method is called internally from <code> Leaderboard.getParticipantEntriesInAssignmentList </code>. This method aggregates score of a user grouped by course id, further grouped by questionnaire type.
|-
|}

In the OSS project, we have refactored these methods along with other smaller methods in
<code> Leaderboard.rb </code>, <code> Leaderboard_helper.rb </code>. We have also refactored ambiguous variable and method
names.

We have keenly focussed in reducing the database calls, loops and redundant storage and
computation.
We have refactored many files related to Leaderboard implementation leading to
enhancement of overall complexity of the feature.

=Changes In Model (leaderboard.rb) =
{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| getIndependantAssignments
| Reduced the number of database calls within loop.
| Less complexity and runs faster.
|-
|''''' 2 '''''
| getParticipantEntriesInCourses
| Reduced the number of database calls within loop.
| Less complexity and runs faster.
|-
|''''' 3 '''''
| sortHash
| in place changes.
| Returns a new deep copy of the updated hash.
|-
|''''' 4 '''''
| extractPersonalAchievements
| Confusing code with extra data base calls.
| This method is refactored to use only 1 database call
unlike several within the loop in its prior implementation. We have also removed redundantcode computation and made the logic easier to understand. The overall complexity of this
method is reduced from 72 to 35.
|-
|''''' 5 '''''
| addEntryToCSHash
| Confusing code with extra data base calls.
| The new method name is addScoreToResultantHash. As mentioned earlier, this is called internally
by getParticipantEntriesInAssignmentList. The complexity of this method is reduced from 67 to 39 .
|-
|''''' 6 '''''
| getParticipantEntriesInAssignmentList
| This method was the most complex method in the class.
| The new refactored method name is getParticipantsScore. The method was
refactored on various aspects like reducing database calls drastically, removing redundant
code computation, redundant data storage in complex group of hashes and series of
conditional statements. We would like to mention that previously, the method had 10
database calls within loop and 1 outside loop. After refactoring, the new method has just 1
database call within loop and 3 outside loops. Also, the overall code complexity is reduced
from 142 to 64.
|-
|}

=Changes In Helper (leaderboard_helper.rb) =
{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| userIsInstructor
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls. 4
database calls was replaced by single call.
|-
|''''' 2 '''''
| studentInWhichCourses
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls
and remove unnecessary loops. 1 database call outside and 1 within a loop was replaced
by a single call.
|-
|''''' 3 '''''
| getTop3Leaderboards
| Dead code
| Removed.
|-
|}

There are several other changes in the views and controller which deal with renaming of the methods
and variables, adding proper comments etc and minor code refactoring. Please refer to our forked
github repository to view those changes.

Lastly, we would like to recommend the readers to test the leaderboard functionality by any user who
has participated in several assignments, some of them which is associated with any course and there
are other existing users who have participated in the same assignment. e.g. user480/password

=Testing=

{| class="wikitable"
|-
! View of Refactored Leaderboard
! View of non Refactored Leaderboard

|-
| [[File:Refactored_Leaderboard_file.jpg|frame|left| ]]
| [[File:Non_Refactored_Leaderboard_file.jpg|frame|left| ]]

|}

=Optimization=

=Future Work=
There was a requirement in the project, that we should come up with an efficient way to search for participants based on assignment ids. However, upon investigation, we found that scores stored in table ScoreCache, gives us revieweeId which is either participantId or teamId. Therefore, we have a method getAssignmentMapping, which creates a mapping of participant and team with corresponding assignment. This is very useful while computing leaderboard.

= References=
[http://expertiza.ncsu.edu/ Expertiza]

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T17:35:59Z

Spsingh2: /* Testing */

[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit#heading=h.p92p30rar40t Writeup Page]
=Expertiza - Refactoring LeaderBoard model=

Our project is to refactor the code in the "Leaderboard" functionality of the web application Expertiza<ref name="expertiza>''Expertiza'' http://wikis.lib.ncsu.edu/index.php/Expertiza</ref>. The Expertiza project is a system to create reusable learning objects through peer review. The classes involved gets all the assignments in the course and all the participants in a course or in an assignment. The responsibility of the leaderboard module is to generate the top 3 individuals which is to be displayed as the leaderboard for the class and a personal leaderboard view to see a personal aggregated score.

__TOC__

==Project Description==
Classes involved: leaderboard.rb and associated other model and controllers classes.

1. Come up with an efficient way to search for participants based on assignment ids.

2. Refactor score hash for personal achievements. (Method: <code>extractPersonalAchievements</code>). Seperate out method which will rank individual personal achievements.

3. Refactor ''addEntryToCSHash'' according to your new metric method.

4. Seperate out computation of CS entries(metric) and refactor it to be more modular and elegant.

5. Refactor ''getParticipantEntriesInAssignmentList'' method. Its very complex (Complexity=142).

6. Refactor ''addEntryToCSHash'' according to your new metric method.

==Existing Functionality==
Leaderboard class gets all the assignments within all the courses taken by currently logged in user. It
also fetches any independent assignments (not associated with any course), that the user has taken.

Leaderboard model has following 3 important methods:
{| class="wikitable"
|-
! style="width:3%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:43%;"|Comment
|- style="vertical-align:top;"
|-
|''''' 1 '''''
| ''getParticipantEntriesInAssignmentList(assignmentList)''
|This method is responsible for calculating the leaderboard of all the participants associated with assignments in given assignment list.
|-
|''''' 2 '''''
| ''extractPersonalAchievements(csHash, courseIdList, userId)''
| This method is responsible for calculating personal aggregated score. It also calculates the ranking of currently logged in user against total users associated with the same set of courses as that of current user.
|-
|''''' 3 '''''
| ''addEntryToCSHash(qtypeHash, qtype, userid, csEntry, courseid)''
| This method is called internally from ''Leaderboard.getParticipantEntriesInAssignmentList''. This method aggregates score of a user grouped by course id, further grouped by questionnaire type.
|-
|}

In the OSS project, we have refactored these methods along with other smaller methods in
Leaderboard.rb, Leaderboard_helper.rb. We have also refactored ambiguous variable and method
names.

We have keenly focussed in reducing the database calls, loops and redundant storage and
computation.
We have refactored many files related to Leaderboard implementation leading to
enhancement of overall complexity of the feature.

==Changes In Model (leaderboard.rb) ==
{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| getIndependantAssignments
| Reduced the number of database calls within loop.
| Less complexity and runs faster.
|-
|''''' 2 '''''
| getParticipantEntriesInCourses
| Reduced the number of database calls within loop.
| Less complexity and runs faster.
|-
|''''' 3 '''''
| sortHash
| in place changes.
| Returns a new deep copy of the updated hash.
|-
|''''' 4 '''''
| extractPersonalAchievements
| Confusing code with extra data base calls.
| This method is refactored to use only 1 database call
unlike several within the loop in its prior implementation. We have also removed redundantcode computation and made the logic easier to understand. The overall complexity of this
method is reduced from 72 to 35 *.
|-
|''''' 5 '''''
| addEntryToCSHash
| Confusing code with extra data base calls.
| The new method name is addScoreToResultantHash. As mentioned earlier, this is called internally
by getParticipantEntriesInAssignmentList. The complexity of this method is reduced from
67 to 39 *.
|-
|''''' 6 '''''
| getParticipantEntriesInAssignmentList
| This method was the most complex method in the class.
| The new refactored method name is getParticipantsScore. The method was
refactored on various aspects like reducing database calls drastically, removing redundant
code computation, redundant data storage in complex group of hashes and series of
conditional statements. We would like to mention that previously, the method had 10
database calls within loop and 1 outside loop. After refactoring, the new method has just 1
database call within loop and 3 outside loops. Also, the overall code complexity is reduced
from 142 to 64 *.
|-
|}

==Changes In Helper (leaderboard_helper.rb) ==
{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| userIsInstructor
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls. 4
database calls was replaced by single call.
|-
|''''' 2 '''''
| studentInWhichCourses
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls
and remove unnecessary loops. 1 database call outside and 1 within a loop was replaced
by a single call.
|-
|''''' 3 '''''
| getTop3Leaderboards
| Dead code
| Removed.
|-
|}

There are several other changes in the views and controller which deal with renaming of the methods
and variables, adding proper comments etc and minor code refactoring. Please refer to our forked
github repository to view those changes.

Lastly, we would like to recommend the readers to test the leaderboard functionality by any user who
has participated in several assignments, some of them which is associated with any course and there
are other existing users who have participated in the same assignment. e.g. user480/password

==Testing==
[[File:Refactored_Leaderboard_file.jpg| View of Refactored Leaderboard]]
[[File:Refactored_Personal_Achievement_file.jpg| View of Personal Achievement]]

==Optimization==

==Future Work==
There was a requirement in the project, that we should come up with an efficient way to search for participants based on assignment ids. However, upon investigation, we found that scores stored in table ScoreCache, gives us revieweeId which is either participantId or teamId. Therefore, we have a method getAssignmentMapping, which creates a mapping of participant and team with corresponding assignment. This is very useful while computing leaderboard.

== References==
[http://expertiza.ncsu.edu/ Expertiza]

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T17:33:20Z

Spsingh2: /* Expertiza - Refactoring LeaderBoard model */

[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit#heading=h.p92p30rar40t Writeup Page]
=Expertiza - Refactoring LeaderBoard model=

Our project is to refactor the code in the "Leaderboard" functionality of the web application Expertiza<ref name="expertiza>''Expertiza'' http://wikis.lib.ncsu.edu/index.php/Expertiza</ref>. The Expertiza project is a system to create reusable learning objects through peer review. The classes involved gets all the assignments in the course and all the participants in a course or in an assignment. The responsibility of the leaderboard module is to generate the top 3 individuals which is to be displayed as the leaderboard for the class and a personal leaderboard view to see a personal aggregated score.

__TOC__

==Project Description==
Classes involved: leaderboard.rb and associated other model and controllers classes.

1. Come up with an efficient way to search for participants based on assignment ids.

2. Refactor score hash for personal achievements. (Method: ''extractPersonalAchievements''). Seperate out method which will rank individual personal achievements.

3. Refactor ''addEntryToCSHash'' according to your new metric method.

4. Seperate out computation of CS entries(metric) and refactor it to be more modular and elegant.

5. Refactor ''getParticipantEntriesInAssignmentList'' method. Its very complex (Complexity=142).

6. Refactor ''addEntryToCSHash'' according to your new metric method.

==Existing Functionality==
Leaderboard class gets all the assignments within all the courses taken by currently logged in user. It
also fetches any independent assignments (not associated with any course), that the user has taken.

Leaderboard model has following 3 important methods:
{| class="wikitable"
|-
! style="width:3%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:43%;"|Comment
|- style="vertical-align:top;"
|-
|''''' 1 '''''
| ''getParticipantEntriesInAssignmentList(assignmentList)''
|This method is responsible for calculating the leaderboard of all the participants associated with assignments in given assignment list.
|-
|''''' 2 '''''
| ''extractPersonalAchievements(csHash, courseIdList, userId)''
| This method is responsible for calculating personal aggregated score. It also calculates the ranking of currently logged in user against total users associated with the same set of courses as that of current user.
|-
|''''' 3 '''''
| ''addEntryToCSHash(qtypeHash, qtype, userid, csEntry, courseid)''
| This method is called internally from ''Leaderboard.getParticipantEntriesInAssignmentList''. This method aggregates score of a user grouped by course id, further grouped by questionnaire type.
|-
|}

In the OSS project, we have refactored these methods along with other smaller methods in
Leaderboard.rb, Leaderboard_helper.rb. We have also refactored ambiguous variable and method
names.

We have keenly focussed in reducing the database calls, loops and redundant storage and
computation.
We have refactored many files related to Leaderboard implementation leading to
enhancement of overall complexity of the feature.

==Changes In Model (leaderboard.rb) ==
{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| getIndependantAssignments
| Reduced the number of database calls within loop.
| Less complexity and runs faster.
|-
|''''' 2 '''''
| getParticipantEntriesInCourses
| Reduced the number of database calls within loop.
| Less complexity and runs faster.
|-
|''''' 3 '''''
| sortHash
| in place changes.
| Returns a new deep copy of the updated hash.
|-
|''''' 4 '''''
| extractPersonalAchievements
| Confusing code with extra data base calls.
| This method is refactored to use only 1 database call
unlike several within the loop in its prior implementation. We have also removed redundantcode computation and made the logic easier to understand. The overall complexity of this
method is reduced from 72 to 35 *.
|-
|''''' 5 '''''
| addEntryToCSHash
| Confusing code with extra data base calls.
| The new method name is addScoreToResultantHash. As mentioned earlier, this is called internally
by getParticipantEntriesInAssignmentList. The complexity of this method is reduced from
67 to 39 *.
|-
|''''' 6 '''''
| getParticipantEntriesInAssignmentList
| This method was the most complex method in the class.
| The new refactored method name is getParticipantsScore. The method was
refactored on various aspects like reducing database calls drastically, removing redundant
code computation, redundant data storage in complex group of hashes and series of
conditional statements. We would like to mention that previously, the method had 10
database calls within loop and 1 outside loop. After refactoring, the new method has just 1
database call within loop and 3 outside loops. Also, the overall code complexity is reduced
from 142 to 64 *.
|-
|}

==Changes In Helper (leaderboard_helper.rb) ==
{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| userIsInstructor
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls. 4
database calls was replaced by single call.
|-
|''''' 2 '''''
| studentInWhichCourses
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls
and remove unnecessary loops. 1 database call outside and 1 within a loop was replaced
by a single call.
|-
|''''' 3 '''''
| getTop3Leaderboards
| Dead code
| Removed.
|-
|}

There are several other changes in the views and controller which deal with renaming of the methods
and variables, adding proper comments etc and minor code refactoring. Please refer to our forked
github repository to view those changes.

Lastly, we would like to recommend the readers to test the leaderboard functionality by any user who
has participated in several assignments, some of them which is associated with any course and there
are other existing users who have participated in the same assignment. e.g. user480/password

==Testing==
[[File:Refactored_Personal_Achievement_file.jpg|left|frame| View of Personal Achievement]]
[[File:Refactored_Leaderboard_file.jpg|right|frame| View of Refactored Leaderboard]]

==Optimization==

==Future Work==
There was a requirement in the project, that we should come up with an efficient way to search for participants based on assignment ids. However, upon investigation, we found that scores stored in table ScoreCache, gives us revieweeId which is either participantId or teamId. Therefore, we have a method getAssignmentMapping, which creates a mapping of participant and team with corresponding assignment. This is very useful while computing leaderboard.

== References==
[http://expertiza.ncsu.edu/ Expertiza]

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T17:22:48Z

Spsingh2: /* Expertiza - Refactoring LeaderBoard model */

[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit#heading=h.p92p30rar40t Writeup Page]
=Expertiza - Refactoring LeaderBoard model=

Our project is to refactor the code in the "Leaderboard" functionality of the web application Expertiza<ref name="expertiza>''Expertiza'' http://wikis.lib.ncsu.edu/index.php/Expertiza</ref>. The Expertiza project is a system to create reusable learning objects through peer review. The classes involved gets all the assignments in the course and all the participants in a course or in an assignment. The responsibility of the leaderboard module is to generate the top 3 individuals which is to be displayed as the leaderboard for the class and a personal leaderboard view to see a personal aggregated score.

__TOC__

==Project Description==
Classes involved: leaderboard.rb and associated other model and controllers classes.

1. Come up with an efficient way to search for participants based on assignment ids.

2. Refactor score hash for personal achievements. (Method: ''extractPersonalAchievements''). Seperate out method which will rank individual personal achievements.

3. Refactor ''addEntryToCSHash'' according to your new metric method.

4. Seperate out computation of CS entries(metric) and refactor it to be more modular and elegant.

5. Refactor ''getParticipantEntriesInAssignmentList'' method. Its very complex (Complexity=142).

6. Refactor ''addEntryToCSHash'' according to your new metric method.

==Existing Functionality==
Leaderboard class gets all the assignments within all the courses taken by currently logged in user. It
also fetches any independent assignments (not associated with any course), that the user has taken.

Leaderboard model has following 3 important methods:
{| class="wikitable"
|-
! style="width:3%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:43%;"|Comment
|- style="vertical-align:top;"
|-
|''''' 1 '''''
| ''getParticipantEntriesInAssignmentList(assignmentList)''
|This method is responsible for calculating the leaderboard of all the participants associated with assignments in given assignment list.
|-
|''''' 2 '''''
| ''extractPersonalAchievements(csHash, courseIdList, userId)''
| This method is responsible for calculating personal aggregated score. It also calculates the ranking of currently logged in user against total users associated with the same set of courses as that of current user.
|-
|''''' 3 '''''
| ''addEntryToCSHash(qtypeHash, qtype, userid, csEntry, courseid)''
| This method is called internally from ''Leaderboard.getParticipantEntriesInAssignmentList''. This method aggregates score of a user grouped by course id, further grouped by questionnaire type.
|-
|}

In the OSS project, we have refactored these methods along with other smaller methods in
Leaderboard.rb, Leaderboard_helper.rb. We have also refactored ambiguous variable and method
names.

We have keenly focussed in reducing the database calls, loops and redundant storage and
computation.
We have refactored many files related to Leaderboard implementation leading to
enhancement of overall complexity of the feature.

==Changes In Model (leaderboard.rb) ==
{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| getIndependantAssignments
| Reduced the number of database calls within loop.
| Less complexity and runs faster.
|-
|''''' 2 '''''
| getParticipantEntriesInCourses
| Reduced the number of database calls within loop.
| Less complexity and runs faster.
|-
|''''' 3 '''''
| sortHash
| in place changes.
| Returns a new deep copy of the updated hash.
|-
|''''' 4 '''''
| extractPersonalAchievements
| Confusing code with extra data base calls.
| This method is refactored to use only 1 database call
unlike several within the loop in its prior implementation. We have also removed redundantcode computation and made the logic easier to understand. The overall complexity of this
method is reduced from 72 to 35 *.
|-
|''''' 5 '''''
| addEntryToCSHash
| Confusing code with extra data base calls.
| The new method name is addScoreToResultantHash. As mentioned earlier, this is called internally
by getParticipantEntriesInAssignmentList. The complexity of this method is reduced from
67 to 39 *.
|-
|''''' 6 '''''
| getParticipantEntriesInAssignmentList
| This method was the most complex method in the class.
| The new refactored method name is getParticipantsScore. The method was
refactored on various aspects like reducing database calls drastically, removing redundant
code computation, redundant data storage in complex group of hashes and series of
conditional statements. We would like to mention that previously, the method had 10
database calls within loop and 1 outside loop. After refactoring, the new method has just 1
database call within loop and 3 outside loops. Also, the overall code complexity is reduced
from 142 to 64 *.
|-
|}

==Changes In Helper (leaderboard_helper.rb) ==
{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| userIsInstructor
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls. 4
database calls was replaced by single call.
|-
|''''' 2 '''''
| studentInWhichCourses
| Rewrote to reduce the number of database calls.
| This method was refactored to reduce multiple database calls
and remove unnecessary loops. 1 database call outside and 1 within a loop was replaced
by a single call.
|-
|''''' 3 '''''
| getTop3Leaderboards
| Dead code
| Removed.
|-
|}

There are several other changes in the views and controller which deal with renaming of the methods
and variables, adding proper comments etc and minor code refactoring. Please refer to our forked
github repository to view those changes.

Lastly, we would like to recommend the readers to test the leaderboard functionality by any user who
has participated in several assignments, some of them which is associated with any course and there
are other existing users who have participated in the same assignment. e.g. user480/password

==Testing==
[[File:Refactored_Personal_Achievement_file.jpg||frame| View of Personal Achievement]]
[[File:Refactored_Leaderboard_file.jpg||frame| View of Refactored Leaderboard]]

==Optimization==

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T17:18:57Z

Spsingh2: /* Changes */

[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit#heading=h.p92p30rar40t Writeup Page]
=Expertiza - Refactoring LeaderBoard model=

Our project is to refactor the code in the "Leaderboard" functionality of the web application Expertiza<ref name="expertiza>''Expertiza'' http://wikis.lib.ncsu.edu/index.php/Expertiza</ref>. The Expertiza project is a system to create reusable learning objects through peer review. The classes involved gets all the assignments in the course and all the participants in a course or in an assignment. The responsibility of the leaderboard module is to generate the top 3 individuals which is to be displayed as the leaderboard for the class and a personal leaderboard view to see a personal aggregated score.

__TOC__

==Project Description==
Classes involved: leaderboard.rb and associated other model and controllers classes.

1. Come up with an efficient way to search for participants based on assignment ids.

2. Refactor score hash for personal achievements. (Method: extractPersonalAchievements). Seperate out method which will rank individual personal achievements.

3. Refactor addEntryToCSHash according to your new metric method.

4. Seperate out computation of CS entries(metric) and refactor it to be more modular and elegant.

5. Refactor getParticipantEntriesInAssignmentList method. Its very complex (Complexity=142).

6. Refactor addEntryToCSHash according to your new metric method.

==Existing Functionality==
Leaderboard class gets all the assignments within all the courses taken by currently logged in user. It
also fetches any independent assignments (not associated with any course), that the user has taken.

Leaderboard model has following 3 important methods:
{| class="wikitable"
|-
! style="width:3%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:43%;"|Comment
|- style="vertical-align:top;"
|-
|''''' 1 '''''
| getParticipantEntriesInAssignmentList(assignmentList)
|This method is responsible for calculating the leaderboard of all the participants associated with assignments in given assignment list.
|-
|''''' 2 '''''
| extractPersonalAchievements(csHash, courseIdList, userId)
| This method is responsible for calculating personal aggregated score. It also calculates the ranking of currently logged in user against total users associated with the same set of courses as that of current user.
|-
|''''' 3 '''''
| addEntryToCSHash(qtypeHash, qtype, userid, csEntry, courseid)
| This method is called internally from Leaderboard.getParticipantEntriesInAssignmentList. This method aggregates score of a user grouped by course id, further grouped by questionnaire type.
|-
|}

In the OSS project, we have refactored these methods along with other smaller methods in
Leaderboard.rb, Leaderboard_helper.rb. We have also refactored ambiguous variable and method
names.

We have keenly focussed in reducing the database calls, loops and redundant storage and
computation.
We have refactored many files related to Leaderboard implementation leading to
enhancement of overall complexity of the feature.

==Changes In Model (leaderboard.rb) ==
{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| getIndependantAssignments
| Reduced the number of database calls within loop.
| Less complexity and runs faster.
|-
|''''' 2 '''''
| getParticipantEntriesInCourses
| Reduced the number of database calls within loop.
| Less complexity and runs faster.
|-
|''''' 3 '''''
| sortHash
| in place changes.
| Returns a new deep copy of the updated hash.
|-
|''''' 4 '''''
| extractPersonalAchievements
| Confusing code with extra data base calls.
| This method is refactored to use only 1 database call
unlike several within the loop in its prior implementation. We have also removed redundantcode computation and made the logic easier to understand. The overall complexity of this
method is reduced from 72 to 35 *.
|-
|''''' 5 '''''
| addEntryToCSHash
| Confusing code with extra data base calls.
| The new method name is addScoreToResultantHash. As mentioned earlier, this is called internally
by getParticipantEntriesInAssignmentList. The complexity of this method is reduced from
67 to 39 *.
|-
|''''' 6 '''''
| getParticipantEntriesInAssignmentList
| This method was the most complex method in the class.
| The new refactored method name is getParticipantsScore. The method was
refactored on various aspects like reducing database calls drastically, removing redundant
code computation, redundant data storage in complex group of hashes and series of
conditional statements. We would like to mention that previously, the method had 10
database calls within loop and 1 outside loop. After refactoring, the new method has just 1
database call within loop and 3 outside loops. Also, the overall code complexity is reduced
from 142 to 64 *.
|-
|}

○ There was a requirement in the project, that we should come up with an efficient way to
search for participants based on assignment ids. However, upon investigation, we found
that scores stored in table ScoreCache, gives us revieweeId which is either participantId or
teamId. Therefore, we have a method getAssignmentMapping, which creates a mapping of
participant and team with corresponding assignment. This is very useful while computing
leaderboard.

2. Leaderboard_helper.rb
○ userIsInstructor : This method was refactored to reduce multiple database calls. 4
database calls was replaced by single call.
○ studentInWhichCourses : This method was refactored to reduce multiple database calls
and remove unnecessary loops. 1 database call outside and 1 within a loop was replaced
by a single call.
○ getTop3Leaderboards : This method is a dead code, not called from anywhere, therefore,
we have commented this for the moment.

There are several other changes in the views and controller which deal with renaming of the methods
and variables, adding proper comments etc and minor code refactoring. Please refer to our forked
github repository to view those changes.

Lastly, we would like to recommend the readers to test the leaderboard functionality by any user who
has participated in several assignments, some of them which is associated with any course and there
are other existing users who have participated in the same assignment. e.g. user480/password

==Testing==
[[File:Refactored_Leaderboard_file.jpg||frame|Build Status Page in CruiseControl <ref name="cc"></ref>. View of Refactored Leaderboard]]

==Optimization==

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T17:18:04Z

Spsingh2: /* Changes */

[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit#heading=h.p92p30rar40t Writeup Page]
=Expertiza - Refactoring LeaderBoard model=

Our project is to refactor the code in the "Leaderboard" functionality of the web application Expertiza<ref name="expertiza>''Expertiza'' http://wikis.lib.ncsu.edu/index.php/Expertiza</ref>. The Expertiza project is a system to create reusable learning objects through peer review. The classes involved gets all the assignments in the course and all the participants in a course or in an assignment. The responsibility of the leaderboard module is to generate the top 3 individuals which is to be displayed as the leaderboard for the class and a personal leaderboard view to see a personal aggregated score.

__TOC__

==Project Description==
Classes involved: leaderboard.rb and associated other model and controllers classes.

1. Come up with an efficient way to search for participants based on assignment ids.

2. Refactor score hash for personal achievements. (Method: extractPersonalAchievements). Seperate out method which will rank individual personal achievements.

3. Refactor addEntryToCSHash according to your new metric method.

4. Seperate out computation of CS entries(metric) and refactor it to be more modular and elegant.

5. Refactor getParticipantEntriesInAssignmentList method. Its very complex (Complexity=142).

6. Refactor addEntryToCSHash according to your new metric method.

==Existing Functionality==
Leaderboard class gets all the assignments within all the courses taken by currently logged in user. It
also fetches any independent assignments (not associated with any course), that the user has taken.

Leaderboard model has following 3 important methods:
{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:43%;"|Comment
|- style="vertical-align:top;"
|''''' 1 '''''
| getParticipantEntriesInAssignmentList(assignmentList)
|This method is responsible for calculating the leaderboard of all the participants associated
with assignments in given assignment list.
|-
|''''' 2 '''''
| extractPersonalAchievements(csHash, courseIdList, userId)
| This method is responsible for calculating personal aggregated score. It also calculates the
ranking of currently logged in user against total users associated with the same set of
courses as that of current user.
|-
|''''' 3 '''''
| addEntryToCSHash(qtypeHash, qtype, userid, csEntry, courseid)
| This method is called internally from Leaderboard.getParticipantEntriesInAssignmentList. This method aggregates score of a user grouped by course id, further grouped by
questionnaire type.
|-
|}

In the OSS project, we have refactored these methods along with other smaller methods in
Leaderboard.rb, Leaderboard_helper.rb. We have also refactored ambiguous variable and method
names.

We have keenly focussed in reducing the database calls, loops and redundant storage and
computation.
We have refactored many files related to Leaderboard implementation leading to
enhancement of overall complexity of the feature.

==Changes==
{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| getIndependantAssignments
| Reduced the number of database calls within loop.
| Less complexity and runs faster.
|-
|''''' 2 '''''
| getParticipantEntriesInCourses
| Reduced the number of database calls within loop.
| Less complexity and runs faster.
|-
|''''' 3 '''''
| sortHash
| in place changes.
| Returns a new deep copy of the updated hash.
|-
|''''' 4 '''''
| extractPersonalAchievements
| Confusing code with extra data base calls.
| This method is refactored to use only 1 database call
unlike several within the loop in its prior implementation. We have also removed redundantcode computation and made the logic easier to understand. The overall complexity of this
method is reduced from 72 to 35 *.
|-
|''''' 5 '''''
| addEntryToCSHash
| Confusing code with extra data base calls.
| The new method name is addScoreToResultantHash. As mentioned earlier, this is called internally
by getParticipantEntriesInAssignmentList. The complexity of this method is reduced from
67 to 39 *.
|-
|''''' 6 '''''
| getParticipantEntriesInAssignmentList
| This method was the most complex method in the class.
| The new refactored method name is getParticipantsScore. The method was
refactored on various aspects like reducing database calls drastically, removing redundant
code computation, redundant data storage in complex group of hashes and series of
conditional statements. We would like to mention that previously, the method had 10
database calls within loop and 1 outside loop. After refactoring, the new method has just 1
database call within loop and 3 outside loops. Also, the overall code complexity is reduced
from 142 to 64 *.
|-
|}

○ There was a requirement in the project, that we should come up with an efficient way to
search for participants based on assignment ids. However, upon investigation, we found
that scores stored in table ScoreCache, gives us revieweeId which is either participantId or
teamId. Therefore, we have a method getAssignmentMapping, which creates a mapping of
participant and team with corresponding assignment. This is very useful while computing
leaderboard.

2. Leaderboard_helper.rb
○ userIsInstructor : This method was refactored to reduce multiple database calls. 4
database calls was replaced by single call.
○ studentInWhichCourses : This method was refactored to reduce multiple database calls
and remove unnecessary loops. 1 database call outside and 1 within a loop was replaced
by a single call.
○ getTop3Leaderboards : This method is a dead code, not called from anywhere, therefore,
we have commented this for the moment.

There are several other changes in the views and controller which deal with renaming of the methods
and variables, adding proper comments etc and minor code refactoring. Please refer to our forked
github repository to view those changes.

Lastly, we would like to recommend the readers to test the leaderboard functionality by any user who
has participated in several assignments, some of them which is associated with any course and there
are other existing users who have participated in the same assignment. e.g. user480/password

==Testing==
[[File:Refactored_Leaderboard_file.jpg||frame|Build Status Page in CruiseControl <ref name="cc"></ref>. View of Refactored Leaderboard]]

==Optimization==

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T17:04:55Z

Spsingh2: /* Expertiza - Refactoring LeaderBoard model */

=Expertiza - Refactoring LeaderBoard model=
__TOC__

==Introduction==
Our project is to refactor the code in the "Leaderboard" functionality of the web application Expertiza<ref name="expertiza>''Expertiza'' http://wikis.lib.ncsu.edu/index.php/Expertiza</ref>. The Expertiza project is a system to create reusable learning objects through peer review. The classes involved gets all the assignments in the course and all the participants in a course or in an assignment. The responsibility of the leaderboard module is to generate the top 3 individuals which is to be displayed as the leaderboard for the class and a personal leaderboard view to see a personal aggregated score.

==Project Description==
Classes involved: leaderboard.rb and associated other model and controllers classes.

1. Come up with an efficient way to search for participants based on assignment ids.

2. Refactor score hash for personal achievements. (Method: extractPersonalAchievements). Seperate out method which will rank individual personal achievements.

3. Refactor addEntryToCSHash according to your new metric method.

4. Seperate out computation of CS entries(metric) and refactor it to be more modular and elegant.

5. Refactor getParticipantEntriesInAssignmentList method. Its very complex (Complexity=142).

6. Refactor addEntryToCSHash according to your new metric method.

==Existing Functionality==
Leaderboard class gets all the assignments within all the courses taken by currently logged in user. It
also fetches any independent assignments (not associated with any course), that the user has taken.

Leaderboard model has following 3 important methods:
{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:43%;"|Comment
|- style="vertical-align:top;"
|''''' 1 '''''
| getParticipantEntriesInAssignmentList(assignmentList)
|This method is responsible for calculating the leaderboard of all the participants associated
with assignments in given assignment list.
|-
|''''' 2 '''''
| extractPersonalAchievements(csHash, courseIdList, userId)
| This method is responsible for calculating personal aggregated score. It also calculates the
ranking of currently logged in user against total users associated with the same set of
courses as that of current user.
|-
|''''' 3 '''''
| addEntryToCSHash(qtypeHash, qtype, userid, csEntry, courseid)
| This method is called internally from Leaderboard.getParticipantEntriesInAssignmentList. This method aggregates score of a user grouped by course id, further grouped by
questionnaire type.
|-
|}

In the OSS project, we have refactored these methods along with other smaller methods in
Leaderboard.rb, Leaderboard_helper.rb. We have also refactored ambiguous variable and method
names.

We have keenly focussed in reducing the database calls, loops and redundant storage and
computation.
We have refactored many files related to Leaderboard implementation leading to
enhancement of overall complexity of the feature.

==Changes==
1. Leaderboard.rb
○ Methods like getIndependantAssignments and getParticipantEntriesInCourses are
refactored to reduce the database calls within loop. Database calls have huge impact on
overall complexity of the code and performance of the software.
○ sortHash : This method modified the input hash. We refactored it to not alter the input
hash object, but rather return a new deep copy of the updated hash object.
○ extractPersonalAchievements : This method is refactored to use only 1 database call
unlike several within the loop in its prior implementation. We have also removed redundantcode computation and made the logic easier to understand. The overall complexity of this
method is reduced from 72 to 35 *.
○ addEntryToCSHash : This method is refactored to reduce the redundant code. The new
method name is addScoreToResultantHash. As mentioned earlier, this is called internally
by getParticipantEntriesInAssignmentList. The complexity of this method is reduced from
67 to 39 *.

○ getParticipantEntriesInAssignmentList : This method was the most complex method in
the class. The new refactored method name is getParticipantsScore. The method was
refactored on various aspects like reducing database calls drastically, removing redundant
code computation, redundant data storage in complex group of hashes and series of
conditional statements. We would like to mention that previously, the method had 10
database calls within loop and 1 outside loop. After refactoring, the new method has just 1
database call within loop and 3 outside loops. Also, the overall code complexity is reduced
from 142 to 64 *.
○ There was a requirement in the project, that we should come up with an efficient way to
search for participants based on assignment ids. However, upon investigation, we found
that scores stored in table ScoreCache, gives us revieweeId which is either participantId or
teamId. Therefore, we have a method getAssignmentMapping, which creates a mapping of
participant and team with corresponding assignment. This is very useful while computing
leaderboard.
2. Leaderboard_helper.rb
○ userIsInstructor : This method was refactored to reduce multiple database calls. 4
database calls was replaced by single call.
○ studentInWhichCourses : This method was refactored to reduce multiple database calls
and remove unnecessary loops. 1 database call outside and 1 within a loop was replaced
by a single call.
○ getTop3Leaderboards : This method is a dead code, not called from anywhere, therefore,
we have commented this for the moment.
There are several other changes in the views and controller which deal with renaming of the methods
and variables, adding proper comments etc and minor code refactoring. Please refer to our forked
github repository to view those changes.
Lastly, we would like to recommend the readers to test the leaderboard functionality by any user who
has participated in several assignments, some of them which is associated with any course and there
are other existing users who have participated in the same assignment. e.g. user480/password
* Code complexity measurement is according to Code Climate

==Testing==
==Optimization==

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T17:04:35Z

Spsingh2: /* Expertiza - Refactoring LeaderBoard model */

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T16:53:21Z

Spsingh2: /* Existing Functionality */

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T16:46:04Z

Spsingh2: /* Existing Functionality */

=Expertiza - Refactoring LeaderBoard model=
__TOC__

==Introduction==
Our project is to refactor the code in the "Leaderboard" functionality of the web application Expertiza<ref name="expertiza>''Expertiza'' http://wikis.lib.ncsu.edu/index.php/Expertiza</ref>. The Expertiza project is a system to create reusable learning objects through peer review. The classes involved gets all the assignments in the course and all the participants in a course or in an assignment. The responsibility of the leaderboard module is to generate the top 3 individuals which is to be displayed as the leaderboard for the class and a personal leaderboard view to see a personal aggregated score.

==Project Description==
Classes involved: leaderboard.rb and associated other model and controllers classes.

1. Come up with an efficient way to search for participants based on assignment ids.

2. Refactor score hash for personal achievements. (Method: extractPersonalAchievements). Seperate out method which will rank individual personal achievements.

3. Refactor addEntryToCSHash according to your new metric method.

4. Seperate out computation of CS entries(metric) and refactor it to be more modular and elegant.

5. Refactor getParticipantEntriesInAssignmentList method. Its very complex (Complexity=142).

6. Refactor addEntryToCSHash according to your new metric method.

==Existing Functionality==
Leaderboard class gets all the assignments within all the courses taken by currently logged in user. It
also fetches any independent assignments (not associated with any course), that the user has taken.

Leaderboard model has following 3 important methods:

1. getParticipantEntriesInAssignmentList(assignmentList)
○ This method is responsible for calculating the leaderboard of all the participants associated
with assignments in given assignment list.

2. extractPersonalAchievements(csHash, courseIdList, userId)
○ This method is responsible for calculating personal aggregated score. It also calculates the
ranking of currently logged in user against total users associated with the same set of
courses as that of current user.

3. addEntryToCSHash(qtypeHash, qtype, userid, csEntry, courseid)
○ This method is called internally from Leaderboard.getParticipantEntriesInAssignmentList.
○ This method aggregates score of a user grouped by course id, further grouped by
questionnaire type.

In the OSS project, we have refactored these methods along with other smaller methods in
Leaderboard.rb, Leaderboard_helper.rb. We have also refactored ambiguous variable and method
names.

We have keenly focussed in reducing the database calls, loops and redundant storage and
computation.
We have refactored many files related to Leaderboard implementation leading to
enhancement of overall complexity of the feature.

==Changes==
1. Leaderboard.rb
○ Methods like getIndependantAssignments and getParticipantEntriesInCourses are
refactored to reduce the database calls within loop. Database calls have huge impact on
overall complexity of the code and performance of the software.
○ sortHash : This method modified the input hash. We refactored it to not alter the input
hash object, but rather return a new deep copy of the updated hash object.
○ extractPersonalAchievements : This method is refactored to use only 1 database call
unlike several within the loop in its prior implementation. We have also removed redundantcode computation and made the logic easier to understand. The overall complexity of this
method is reduced from 72 to 35 *.
○ addEntryToCSHash : This method is refactored to reduce the redundant code. The new
method name is addScoreToResultantHash. As mentioned earlier, this is called internally
by getParticipantEntriesInAssignmentList. The complexity of this method is reduced from
67 to 39 *.

○ getParticipantEntriesInAssignmentList : This method was the most complex method in
the class. The new refactored method name is getParticipantsScore. The method was
refactored on various aspects like reducing database calls drastically, removing redundant
code computation, redundant data storage in complex group of hashes and series of
conditional statements. We would like to mention that previously, the method had 10
database calls within loop and 1 outside loop. After refactoring, the new method has just 1
database call within loop and 3 outside loops. Also, the overall code complexity is reduced
from 142 to 64 *.
○ There was a requirement in the project, that we should come up with an efficient way to
search for participants based on assignment ids. However, upon investigation, we found
that scores stored in table ScoreCache, gives us revieweeId which is either participantId or
teamId. Therefore, we have a method getAssignmentMapping, which creates a mapping of
participant and team with corresponding assignment. This is very useful while computing
leaderboard.
2. Leaderboard_helper.rb
○ userIsInstructor : This method was refactored to reduce multiple database calls. 4
database calls was replaced by single call.
○ studentInWhichCourses : This method was refactored to reduce multiple database calls
and remove unnecessary loops. 1 database call outside and 1 within a loop was replaced
by a single call.
○ getTop3Leaderboards : This method is a dead code, not called from anywhere, therefore,
we have commented this for the moment.
There are several other changes in the views and controller which deal with renaming of the methods
and variables, adding proper comments etc and minor code refactoring. Please refer to our forked
github repository to view those changes.
Lastly, we would like to recommend the readers to test the leaderboard functionality by any user who
has participated in several assignments, some of them which is associated with any course and there
are other existing users who have participated in the same assignment. e.g. user480/password
* Code complexity measurement is according to Code Climate

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T16:43:38Z

Spsingh2: /* Project Description */

=Expertiza - Refactoring LeaderBoard model=
__TOC__

==Introduction==
Our project is to refactor the code in the "Leaderboard" functionality of the web application Expertiza<ref name="expertiza>''Expertiza'' http://wikis.lib.ncsu.edu/index.php/Expertiza</ref>. The Expertiza project is a system to create reusable learning objects through peer review. The classes involved gets all the assignments in the course and all the participants in a course or in an assignment. The responsibility of the leaderboard module is to generate the top 3 individuals which is to be displayed as the leaderboard for the class and a personal leaderboard view to see a personal aggregated score.

==Project Description==
Classes involved: leaderboard.rb and associated other model and controllers classes.

1. Come up with an efficient way to search for participants based on assignment ids.

2. Refactor score hash for personal achievements. (Method: extractPersonalAchievements). Seperate out method which will rank individual personal achievements.

3. Refactor addEntryToCSHash according to your new metric method.

4. Seperate out computation of CS entries(metric) and refactor it to be more modular and elegant.

5. Refactor getParticipantEntriesInAssignmentList method. Its very complex (Complexity=142).

6. Refactor addEntryToCSHash according to your new metric method.

==Existing Code==
Leaderboard class gets all the assignments within all the courses taken by currently logged in user. It
also fetches any independent assignments (not associated with any course), that the user has taken.
leaderboard model has following 3 important methods:
1. getParticipantEntriesInAssignmentList(assignmentList)
○ This method is responsible for calculating the leaderboard of all the participants associated
with assignments in given assignment list.
2. extractPersonalAchievements(csHash, courseIdList, userId)
○ This method is responsible for calculating personal aggregated score. It also calculates the
ranking of currently logged in user against total users associated with the same set of
courses as that of current user.
3. addEntryToCSHash(qtypeHash, qtype, userid, csEntry, courseid)
○ This method is called internally from Leaderboard.getParticipantEntriesInAssignmentList.
○ This method aggregates score of a user grouped by course id, further grouped by
questionnaire type.
In the OSS project, we have refactored these methods along with other smaller methods in
Leaderboard.rb, Leaderboard_helper.rb. We have also refactored ambiguous variable and method
names.

We have keenly focussed in reducing the database calls, loops and redundant storage and
computation. We have refactored many files related to Leaderboard implementation leading to
enhancement of overall complexity of the feature. Following are some of the changes that we think are
sharing in readme file. For all the other changes, please visit our forked repository
(https://github.com/sanjeevs/expertiza/tree/rails4)

==Changes==
1. Leaderboard.rb
○ Methods like getIndependantAssignments and getParticipantEntriesInCourses are
refactored to reduce the database calls within loop. Database calls have huge impact on
overall complexity of the code and performance of the software.
○ sortHash : This method modified the input hash. We refactored it to not alter the input
hash object, but rather return a new deep copy of the updated hash object.
○ extractPersonalAchievements : This method is refactored to use only 1 database call
unlike several within the loop in its prior implementation. We have also removed redundantcode computation and made the logic easier to understand. The overall complexity of this
method is reduced from 72 to 35 *.
○ addEntryToCSHash : This method is refactored to reduce the redundant code. The new
method name is addScoreToResultantHash. As mentioned earlier, this is called internally
by getParticipantEntriesInAssignmentList. The complexity of this method is reduced from
67 to 39 *.

○ getParticipantEntriesInAssignmentList : This method was the most complex method in
the class. The new refactored method name is getParticipantsScore. The method was
refactored on various aspects like reducing database calls drastically, removing redundant
code computation, redundant data storage in complex group of hashes and series of
conditional statements. We would like to mention that previously, the method had 10
database calls within loop and 1 outside loop. After refactoring, the new method has just 1
database call within loop and 3 outside loops. Also, the overall code complexity is reduced
from 142 to 64 *.
○ There was a requirement in the project, that we should come up with an efficient way to
search for participants based on assignment ids. However, upon investigation, we found
that scores stored in table ScoreCache, gives us revieweeId which is either participantId or
teamId. Therefore, we have a method getAssignmentMapping, which creates a mapping of
participant and team with corresponding assignment. This is very useful while computing
leaderboard.
2. Leaderboard_helper.rb
○ userIsInstructor : This method was refactored to reduce multiple database calls. 4
database calls was replaced by single call.
○ studentInWhichCourses : This method was refactored to reduce multiple database calls
and remove unnecessary loops. 1 database call outside and 1 within a loop was replaced
by a single call.
○ getTop3Leaderboards : This method is a dead code, not called from anywhere, therefore,
we have commented this for the moment.
There are several other changes in the views and controller which deal with renaming of the methods
and variables, adding proper comments etc and minor code refactoring. Please refer to our forked
github repository to view those changes.
Lastly, we would like to recommend the readers to test the leaderboard functionality by any user who
has participated in several assignments, some of them which is associated with any course and there
are other existing users who have participated in the same assignment. e.g. user480/password
* Code complexity measurement is according to Code Climate

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T16:43:01Z

Spsingh2: /* Project Description */

=Expertiza - Refactoring LeaderBoard model=
__TOC__

==Introduction==
Our project is to refactor the code in the "Leaderboard" functionality of the web application Expertiza<ref name="expertiza>''Expertiza'' http://wikis.lib.ncsu.edu/index.php/Expertiza</ref>. The Expertiza project is a system to create reusable learning objects through peer review. The classes involved gets all the assignments in the course and all the participants in a course or in an assignment. The responsibility of the leaderboard module is to generate the top 3 individuals which is to be displayed as the leaderboard for the class and a personal leaderboard view to see a personal aggregated score.

==Project Description==
Classes involved: leaderboard.rb and associated other model and controllers classes.
1. Come up with an efficient way to search for participants based on assignment ids.

2. Refactor score hash for personal achievements. (Method: extractPersonalAchievements). Seperate out method which will rank individual personal achievements.

3. Refactor addEntryToCSHash according to your new metric method.

4. Seperate out computation of CS entries(metric) and refactor it to be more modular and elegant.

5. Refactor getParticipantEntriesInAssignmentList method. Its very complex (Complexity=142).

6.Refactor addEntryToCSHash according to your new metric method.

==Existing Code==
Leaderboard class gets all the assignments within all the courses taken by currently logged in user. It
also fetches any independent assignments (not associated with any course), that the user has taken.
leaderboard model has following 3 important methods:
1. getParticipantEntriesInAssignmentList(assignmentList)
○ This method is responsible for calculating the leaderboard of all the participants associated
with assignments in given assignment list.
2. extractPersonalAchievements(csHash, courseIdList, userId)
○ This method is responsible for calculating personal aggregated score. It also calculates the
ranking of currently logged in user against total users associated with the same set of
courses as that of current user.
3. addEntryToCSHash(qtypeHash, qtype, userid, csEntry, courseid)
○ This method is called internally from Leaderboard.getParticipantEntriesInAssignmentList.
○ This method aggregates score of a user grouped by course id, further grouped by
questionnaire type.
In the OSS project, we have refactored these methods along with other smaller methods in
Leaderboard.rb, Leaderboard_helper.rb. We have also refactored ambiguous variable and method
names.

We have keenly focussed in reducing the database calls, loops and redundant storage and
computation. We have refactored many files related to Leaderboard implementation leading to
enhancement of overall complexity of the feature. Following are some of the changes that we think are
sharing in readme file. For all the other changes, please visit our forked repository
(https://github.com/sanjeevs/expertiza/tree/rails4)

==Changes==
1. Leaderboard.rb
○ Methods like getIndependantAssignments and getParticipantEntriesInCourses are
refactored to reduce the database calls within loop. Database calls have huge impact on
overall complexity of the code and performance of the software.
○ sortHash : This method modified the input hash. We refactored it to not alter the input
hash object, but rather return a new deep copy of the updated hash object.
○ extractPersonalAchievements : This method is refactored to use only 1 database call
unlike several within the loop in its prior implementation. We have also removed redundantcode computation and made the logic easier to understand. The overall complexity of this
method is reduced from 72 to 35 *.
○ addEntryToCSHash : This method is refactored to reduce the redundant code. The new
method name is addScoreToResultantHash. As mentioned earlier, this is called internally
by getParticipantEntriesInAssignmentList. The complexity of this method is reduced from
67 to 39 *.

○ getParticipantEntriesInAssignmentList : This method was the most complex method in
the class. The new refactored method name is getParticipantsScore. The method was
refactored on various aspects like reducing database calls drastically, removing redundant
code computation, redundant data storage in complex group of hashes and series of
conditional statements. We would like to mention that previously, the method had 10
database calls within loop and 1 outside loop. After refactoring, the new method has just 1
database call within loop and 3 outside loops. Also, the overall code complexity is reduced
from 142 to 64 *.
○ There was a requirement in the project, that we should come up with an efficient way to
search for participants based on assignment ids. However, upon investigation, we found
that scores stored in table ScoreCache, gives us revieweeId which is either participantId or
teamId. Therefore, we have a method getAssignmentMapping, which creates a mapping of
participant and team with corresponding assignment. This is very useful while computing
leaderboard.
2. Leaderboard_helper.rb
○ userIsInstructor : This method was refactored to reduce multiple database calls. 4
database calls was replaced by single call.
○ studentInWhichCourses : This method was refactored to reduce multiple database calls
and remove unnecessary loops. 1 database call outside and 1 within a loop was replaced
by a single call.
○ getTop3Leaderboards : This method is a dead code, not called from anywhere, therefore,
we have commented this for the moment.
There are several other changes in the views and controller which deal with renaming of the methods
and variables, adding proper comments etc and minor code refactoring. Please refer to our forked
github repository to view those changes.
Lastly, we would like to recommend the readers to test the leaderboard functionality by any user who
has participated in several assignments, some of them which is associated with any course and there
are other existing users who have participated in the same assignment. e.g. user480/password
* Code complexity measurement is according to Code Climate

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T16:31:01Z

Spsingh2: /* Introduction */

=Expertiza - Refactoring LeaderBoard model=
__TOC__

==Introduction==
Our project is to refactor the code in the "Leaderboard" functionality of the web application Expertiza<ref name="expertiza>''Expertiza'' http://wikis.lib.ncsu.edu/index.php/Expertiza</ref>. The Expertiza project is a system to create reusable learning objects through peer review. The classes involved gets all the assignments in the course and all the participants in a course or in an assignment. The responsibility of the leaderboard module is to generate the top 3 individuals which is to be displayed as the leaderboard for the class and a personal leaderboard view to see a personal aggregated score.

==Project Description==
Classes involved: leaderboard.rb and associated other model and controllers classes.
What it does: This class gets all the assignments in the course and all the participants in a course or in an assignment. It also caches all the scores of the participants in various assignments. Its responsible for calculating top 3 individuals which is to be displayed as the leaderboard for the class and generates a metric which aggregates peer review scores for all course assignments and then sorts individuals. Also it has a personal leaderboard to see a personal aggregated score.
What needs to be done:
Refactor getParticipantEntriesInAssignmentList method. Its very complex (Complexity=142).
Seperate out computation of CS entries(metric) and refactor it to be more modular and elegant. You can even come up with a better metric to calculate an aggregate score for all peer reviews, metareviews(if any), teammate review, etc. Assign more weights to programming assignments. You will need to refactor other dependent classes.
Come up with an efficient way to search for participants based on assignment ids.
Refactor score hash for personal achievements. (Method: extractPersonalAchievements). Seperate out method which will rank individual personal achievements.
Refactor addEntryToCSHash according to your new metric method.

==Existing Code==
Leaderboard class gets all the assignments within all the courses taken by currently logged in user. It
also fetches any independent assignments (not associated with any course), that the user has taken.
leaderboard model has following 3 important methods:
1. getParticipantEntriesInAssignmentList(assignmentList)
○ This method is responsible for calculating the leaderboard of all the participants associated
with assignments in given assignment list.
2. extractPersonalAchievements(csHash, courseIdList, userId)
○ This method is responsible for calculating personal aggregated score. It also calculates the
ranking of currently logged in user against total users associated with the same set of
courses as that of current user.
3. addEntryToCSHash(qtypeHash, qtype, userid, csEntry, courseid)
○ This method is called internally from Leaderboard.getParticipantEntriesInAssignmentList.
○ This method aggregates score of a user grouped by course id, further grouped by
questionnaire type.
In the OSS project, we have refactored these methods along with other smaller methods in
Leaderboard.rb, Leaderboard_helper.rb. We have also refactored ambiguous variable and method
names.

We have keenly focussed in reducing the database calls, loops and redundant storage and
computation. We have refactored many files related to Leaderboard implementation leading to
enhancement of overall complexity of the feature. Following are some of the changes that we think are
sharing in readme file. For all the other changes, please visit our forked repository
(https://github.com/sanjeevs/expertiza/tree/rails4)

==Changes==
1. Leaderboard.rb
○ Methods like getIndependantAssignments and getParticipantEntriesInCourses are
refactored to reduce the database calls within loop. Database calls have huge impact on
overall complexity of the code and performance of the software.
○ sortHash : This method modified the input hash. We refactored it to not alter the input
hash object, but rather return a new deep copy of the updated hash object.
○ extractPersonalAchievements : This method is refactored to use only 1 database call
unlike several within the loop in its prior implementation. We have also removed redundantcode computation and made the logic easier to understand. The overall complexity of this
method is reduced from 72 to 35 *.
○ addEntryToCSHash : This method is refactored to reduce the redundant code. The new
method name is addScoreToResultantHash. As mentioned earlier, this is called internally
by getParticipantEntriesInAssignmentList. The complexity of this method is reduced from
67 to 39 *.

○ getParticipantEntriesInAssignmentList : This method was the most complex method in
the class. The new refactored method name is getParticipantsScore. The method was
refactored on various aspects like reducing database calls drastically, removing redundant
code computation, redundant data storage in complex group of hashes and series of
conditional statements. We would like to mention that previously, the method had 10
database calls within loop and 1 outside loop. After refactoring, the new method has just 1
database call within loop and 3 outside loops. Also, the overall code complexity is reduced
from 142 to 64 *.
○ There was a requirement in the project, that we should come up with an efficient way to
search for participants based on assignment ids. However, upon investigation, we found
that scores stored in table ScoreCache, gives us revieweeId which is either participantId or
teamId. Therefore, we have a method getAssignmentMapping, which creates a mapping of
participant and team with corresponding assignment. This is very useful while computing
leaderboard.
2. Leaderboard_helper.rb
○ userIsInstructor : This method was refactored to reduce multiple database calls. 4
database calls was replaced by single call.
○ studentInWhichCourses : This method was refactored to reduce multiple database calls
and remove unnecessary loops. 1 database call outside and 1 within a loop was replaced
by a single call.
○ getTop3Leaderboards : This method is a dead code, not called from anywhere, therefore,
we have commented this for the moment.
There are several other changes in the views and controller which deal with renaming of the methods
and variables, adding proper comments etc and minor code refactoring. Please refer to our forked
github repository to view those changes.
Lastly, we would like to recommend the readers to test the leaderboard functionality by any user who
has participated in several assignments, some of them which is associated with any course and there
are other existing users who have participated in the same assignment. e.g. user480/password
* Code complexity measurement is according to Code Climate

CSC/ECE 517 Fall 2014/ch1a 23 ss

2014-09-25T21:33:30Z

Spsingh2: /* Cookie Management */

= '''Security Features in Rails 4.x''' =

Web applications can be challenging for a developer to properly secure against threats. There are many attack vectors against web applications that must be carefully considered and mitigated. The developer must be responsible to understand these threats and take the necessary steps to secure the application and data. A web application may be vulnerable due to misconfiguration, poorly written code, or through un-patched vulnerabilities.

[http://rubyonrails.org/ Ruby on Rails], or just Rails, is a web application framework written in Ruby. It is a full-stack framework which attempts to make the development process easier and more accessible. This wiki aims to highlight all the security features in a Rails 4.x.

__TOC__

= Threats Against Web Applications =
Web applications are very open and susceptible to many types of attacks. Many of these attacks can be carried out anonymously and constantly. A web application developer must be vigilant in understanding the threats that exist, and the proper techniques to mitigate them.

==Cookie Management==
Cookies are used to maintain stateful sessions in HTTP. The cookies typically contain the user's session id which is used to identify the user. By stealing it, the attacker can use the application in the victim's name.
More over since the data is stored on the client machine, programmers should not store sensitive data in cookies.

The cookie is sent in the clear and so the easiest way for the attacker is to sniff the packets. This attack is shown below in Figure 1.[[File:cookie_sniffing.png|none]]
Figure1: Packet Sniffing Attack

To manage the cookies Rails provide several options to the programmer.
===Use SSL===
SSL prevents the attacker from sniffing the cookie from the network.

<pre>
config.force_ssl = true
</pre>

===New Session Identifier===
Configure Rails to issue a new session identifier and declare the old one invalid after a successful login.

===Fast Timeout===
Set the expiry time stamp of the cookie to a small value so that chances of attacker using a stale cookie is minimized.

===Improved Cookie Serializer(Rails 4.x) ===
Earlier versions of Rails had a bug where serializing the cookie hash could cause remote code execution. This could happen if the attacker got hold of the application secret. Version 4.1 added a smarter serializer that will '''not''' recreate complex objects besides Strings, Integers and other JSON data types. This also prevents the bad practice of placing more complex objects in the session that can’t be completely restored by the JSON serializer.

==Injection ==
An attacker can inject client site executable code. When the victim renders it, it can steal the cookie, hijack the session and redirect the victim to a different page.

Injection can be a script, sql statement, ajax code or header injection. Though the root cause is poor programming, Rails provide various plug ins that allow the programmer to avoid it.

==== Cross Site Scripting (XSS) <ref>https://www.acunetix.com/websitesecurity/xss/</ref>====

XSS is an attack where an adversary places client-side code in the web application, often through a valid method such as posting to a message board. This code is then viewed by other application users and executed by their client machines.

The general form of XSS attack is show below in Figure2.
[[File:Xss.png|none]]
Figure2: XSS attack in progress
This attack is mitigated by properly sanitizing any input to the application. <ref>https://www.netsparker.com/blog/web-security/ruby-on-rails-security-basics/</ref> The sanitize method may be used to strip improper code from user input.

'''Input to be sanitized''':
<pre><%= sanitize '<img src=x onerror=prompt(1)>' %></pre>

'''Sanitized output:'''
<pre>
<img src=“x”>
</pre>

==== SQL Injection ====

SQL injection is a very common and serious vulnerability for many applications. The generalized concept is to pass carefully crafted input that will eventually get passed as parameters in a SQL statement. In July of 2014, Rails developers released version 4.1.3 in order to patch a serious vulnurability affecting applications using a PostgreSQL database system. <ref>http://www.computerworld.com/article/2489654/malware-vulnerabilities/ruby-on-rails-patches-tackle-sql-injection-vulnerabilities.html</ref> This vulnerability allowed attackers to inject arbitrary SQL code into the affected Rails applications.

To protect the application from this potential vulnerability, you should be careful when processing any SQL query that contains user submitted data. <ref>http://guides.rubyonrails.org/security.html</ref> The sanitize_SQL method may be used to remove improper characters.

==== Header Injection ====

HTTP request headers have various fields that are user supplied and may be manipulated with more or less effort. Programmer need to escape these header fields and avoid building partial headers based on user input. Rails provide a rich api that can be used to create the headers in a secure fashion.

==Cross Site Request Forgery (CSRF)==
This attack method works by including malicious code or a link in a page that accesses a web application that the user is believed to have authenticated. If the session for that web application has not timed out, an attacker may execute unauthorized commands. This is shown below in Figure 3.
[[File:My_csrf.png|none]]
Figure 3: CSRF attack

To fix this the application needs to do the following:

===Security Token===
All non GET request should use a security token. Rails inserts this required security token that our site knows but other sites don't know. This is verified on the server. If the security token does not match then the session will be reset.

Enable this in the application controller.

<pre>
protect_from_forgery
</pre>

== Application Logic ==
There are certain common functionality that most applications need to implement. If these are not implemented correctly, then they can cause a security vulnerability. Rails provide plug ins that make the job easier to implement. Some common cases are discussed below.

===User Authentication===
Most web applications have to deal with user authorization and authentication. Hence it is up to the programmer to implement it correctly. Rails provide built in "''has_secure_password'' feature that stores the password in encrypted manner.
*Brute Force Attack
** Good Password: Ensure that the user password are "random" enough. Rails make it easy to define requirements for the password field in the model.
** Implement CAPTCHAs:This is a challenge response test that determines that the response is not generated by a computer. Rails provide extensive API for implementing it.
*Logging:Rails should be configured to not put passwords into log files by using the followingn in applicatin controller.
<pre>
config.filter_parameters
</pre>
*Anchor Regular Expressions:Ruby has extensive options that can be used to anchor it at the line beginning and line end. Rails 4 also introduces a multiline option for validates_format_of.

===File Upload===
Many applications allow user to upload files. Use Rail plugin to handle unsafe file names and file upload.

===Command Line===
Ruby provides api like "''system(command, parameters)'' which passes command line parameters safely.

= Security Enhancements =
In this section, we examine techniques to improve to the security of Rails web applications.
==Automated Security Scanners==
There are a number of different security analysis tools available for Ruby on Rails applications.

*[http://brakemanscanner.org/docs/introduction/ Brakeman] is an open source, automated static-analysis scanner available for Rails developers. Brakeman scans the source code for misconfiguration, conformance to best practices, and other potential security issues.

*[https://github.com/codesake/codesake-dawn Codesake::Dawn] is another open source scanner for Rails applications. It attempts to detect the MVC architecture of your application to properly check the code base. Codesake scans for XSS scripting and SQL injection vulnerabilities.

*[https://github.com/LTe/scanny Scanny] is and open source security scanner for Rails source code. It works by parsing individual Ruby files and looking for suspicious patterns in them. Scanny produces a security report after completion.

= Unresolved Issues =
There are a few unresolved issues in the current release of Rails. In this section, we examine and describe those concerns with instructions on methods to mitigate them.

== Verbose Servers Headers ==
The default web server for a Rails application is [http://en.wikipedia.org/wiki/WEBrick WEBrick]. It is a simple open source server that is not often used in production, but has a potential security vulnerability if used in a live application. WEBrick returns a verbose security header which returns the full version number of both WEBrick and Ruby. <ref>http://blog.codeclimate.com/blog/2013/03/27/rails-insecure-defaults/</ref>

Example HTTP Response:<ref>http://blog.codeclimate.com/blog/2013/03/27/rails-insecure-defaults/</ref>
<pre>
HTTP/1.1 200 OK
# …
Server: WEBrick/1.3.1 (Ruby/1.9.3/2012-04-20)
</pre>

This verbose message is unnecessary and provides too much information to a potential intruder. An adversary can easily scan many web applications looking for un-patched servers that may be exploited.

== Binding to 0.0.0.0 ==
By default when starting a Rails server, it will bind to ''http://0.0.0.0:3000''. For a development environment, this is often unnecessary and only needs to bind to ''127.0.0.1''. Developers should use the ''--binding'' option to limit the interfaces to only those that are necessary.

== Versioned Secret Tokens ==
In Rails applications up through version 4.0, a generated secret security token was created in ''config/initializers/secret_token.rb'' when creating a Rails application. This token was vulnerable to being left unsecured by developers, or accidentally getting committed to a version control system. An adversary who obtained the secret token could trivially exploit the web application.

These concerns were alleviated in Ruby 4.1. The secret token file was replaced by a ''secrets.yml'' file in the config folder.

'''secrets.yml:'''
<pre>
development:
secret_key_base:

test:
secret_key_base:

production:
secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>
</pre>

This provides the ability to store your sensitive tokens in an environment variable for better security. The ''secrets.yml'' file is also in .gitignore by default, which helps out unaware programmers from accidentally committing their key.

= Reference =

<references />

CSC/ECE 517 Fall 2014/ch1a 23 ss

2014-09-19T16:27:32Z

Spsingh2: /* Unresolved Issues */

= '''Security Features in Rails 4.x''' =

Web applications can be challenging for a developer to properly secure against threats. There are many attack vectors against web applications that must be carefully considered and mitigated. The developer must be responsible to understand these threats and take the necessary steps to secure the application and data. A web application may be vulnerable due to misconfiguration, poorly written code, or through un-patched vulnerabilities.

[http://rubyonrails.org/ Ruby on Rails], or just Rails, is a web application framework written in Ruby. It is a full-stack framework which attempts to make the development process easier and more accessible. This wiki aims to highlight all the security features in a Rails 4.x.

__TOC__

= Threats Against Web Applications =

==Cookie Management==
Cookies are used to maintain stateful sessions in HTTP. The cookies typically contain the user's session id which is used to identify the user. By stealing it, the attacker can use the application in the victim's name.
More over since the data is stored on the client machine, programmers should not store sensitive data in cookies.

The cookie is sent in the clear and so the easiest way for the attacker is to sniff the packets. This attack is shown below in Figure 1.[[File:cookie_sniffing.png|none]]
Figure1: Packet Sniffing Attack

To manage the cookies Rails provide several options to the programmer.
===Use SSL===
SSL prevents the attacker from sniffing the cookie from the network.

<pre>
config.force_ssl = true
</pre>

===New Session Identifier===
Configure Rails to issue a new session identifier and declare the old one invalid after a successful login.

===Fast Timeout===
Set the expiry time stamp of the cookie to a small value so that chances of attacker using a stale cookie is minimized.

==Injection ==
An attacker can inject client site executable code. When the victim renders it, it can steal the cookie, hijack the session and redirect the victim to a different page.

Injection can be a script, sql statement, ajax code or header injection. Though the root cause is poor programming, Rails provide various plug ins that allow the programmer to avoid it.

==== Cross Site Scripting (XSS) ====

XSS is an attack where an adversary places client-side code in the web application, often through a valid method such as posting to a message board. This code is then viewed by other application users and executed by their client machines.

The general form of XSS attack is show below in Figure2.
[[File:Xss.png|none]]
Figure2: XSS attack in progress
This attack is mitigated by properly sanitizing any input to the application. <ref>https://www.netsparker.com/blog/web-security/ruby-on-rails-security-basics/</ref> The sanitize method may be used to strip improper code from user input.

'''Input to be sanitized''':
<pre><%= sanitize '<img src=x onerror=prompt(1)>' %></pre>

'''Sanitized output:'''
<pre>
<img src=“x”>
</pre>

==== SQL Injection ====

SQL injection is a very common and serious vulnerability for many applications. The generalized concept is to pass carefully crafted input that will eventually get passed as parameters in a SQL statement. In July of 2014, Rails developers released version 4.1.3 in order to patch a serious vulnurability affecting applications using a PostgreSQL database system. <ref>http://www.computerworld.com/article/2489654/malware-vulnerabilities/ruby-on-rails-patches-tackle-sql-injection-vulnerabilities.html</ref> This vulnerability allowed attackers to inject arbitrary SQL code into the affected Rails applications.

To protect the application from this potential vulnerability, you should be careful when processing any SQL query that contains user submitted data. The sanitize_SQL method may be used to remove improper characters.

==== Header Injection ====

HTTP request headers have various fields that are user supplied and may be manipulated with more or less effort. Programmer need to escape these header fields and avoid building partial headers based on user input. Rails provide a rich api that can be used to create the headers in a secure fashion.

==Cross Site Request Forgery (CSRF)==
This attack method works by including malicious code or a link in a page that accesses a web application that the user is believed to have authenticated. If the session for that web application has not timed out, an attacker may execute unauthorized commands. This is shown below in Figure 3.
[[File:My_csrf.png|none]]
Figure 3: CSRF attack

To fix this the application needs to do the following.

===Security Token===
All non GET request should use a security token. Rails inserts this required security token that our site knows but other sites don't know. This is verified on the server. If the security token does not match then the session will be reset.

Enable this in the application controller.

<pre>
protect_from_forgery
</pre>

== Application Logic ==
There are certain common functionality that most applications need to implement. If these are not implemented correctly, then they can cause a security vulnerability. Rails provide plug ins that make the job easier to implement. Some common cases are discussed below.

===User Authentication===
Most web applications have to deal with user authorization and authentication. Hence it is up to the programmer to implement it correctly. Rails provide built in "''has_secure_password'' feature that stores the password in encrypted manner.
*Brute Force Attack
** Good Password: Ensure that the user password are "random" enough. Rails make it easy to define requirements for the password field in the model.
** Implement CAPTCHAs:This is a challenge response test that determines that the response is not generated by a computer. Rails provide extensive API for implementing it.
*Logging:Rails should be configured to not put passwords into log files by using the followingn in applicatin controller.
<pre>
config.filter_parameters
</pre>
*Anchor Regular Expressions:Ruby has extensive options that can be used to anchor it at the line beginning and line end. Rails 4 also introduces a multiline option for validates_format_of.

===File Upload===
Many applications allow user to upload files. Use Rail plugin to handle unsafe file names and file upload.

===Command Line===
Ruby provides api like "''system(command, parameters)'' which passes command line parameters safely.

= Security Enhancements =
==Automated Security Scanners==
There are a number of different security analysis tools available for Ruby on Rails applications.

*[http://brakemanscanner.org/docs/introduction/ Brakeman] is an open source, automated static-analysis scanner available for Rails developers. Brakeman scans the source code for misconfiguration, conformance to best practices, and other potential security issues.

*[https://github.com/codesake/codesake-dawn Codesake::Dawn] is another open source scanner for Rails applications. It attempts to detect the MVC architecture of your application to properly check the code base. Codesake scans for XSS scripting and SQL injection vulnerabilities.

= Unresolved Issues =
== Verbose Servers Headers ==
The default web server for a Rails application is [http://en.wikipedia.org/wiki/WEBrick WEBrick]. It is a simple open source server that is not often used in production, but has a potential security vulnerability if used in a live application. WEBrick returns a verbose security header which returns the full version number of both WEBrick and Ruby. <ref>http://blog.codeclimate.com/blog/2013/03/27/rails-insecure-defaults/</ref>

Example HTTP Response:<ref>http://blog.codeclimate.com/blog/2013/03/27/rails-insecure-defaults/</ref>
<pre>
HTTP/1.1 200 OK
# …
Server: WEBrick/1.3.1 (Ruby/1.9.3/2012-04-20)
</pre>

This verbose message is unnecessary and provides too much information to a potential intruder. An adversary can easily scan many web applications looking for un-patched servers that may be exploited.

== Binding to 0.0.0.0 ==
By default when starting a Rails server, it will bind to ''http://0.0.0.0:3000''. For a development environment, this is often unnecessary and only needs to bind to ''127.0.0.1''. Developers should use the ''--binding'' option to limit the interfaces to only those that are necessary.

== Versioned Secret Tokens ==
In Rails applications up through version 4.0, a generated secret security token was created in ''config/initializers/secret_token.rb'' when creating a Rails application. This token was vulnerable to being left unsecured by developers, or accidentally getting committed to a version control system. An adversary who obtained the secret token could trivially exploit the web application.

These concerns were alleviated in Ruby 4.1. The secret token file was replaced by a ''secrets.yml'' file in the config folder.

'''secrets.yml:'''
<pre>
development:
secret_key_base:

test:
secret_key_base:

production:
secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>
</pre>

This provides the ability to store your sensitive tokens in an environment variable for better security. The ''secrets.yml'' file is also in .gitignore by default, which helps out unaware programmers from accidentally committing their key.

= Reference =
http://blog.codeclimate.com/blog/2013/03/27/rails-insecure-defaults/

http://guides.rubyonrails.org/security.html

https://www.acunetix.com/websitesecurity/xss/

<references />

CSC/ECE 517 Fall 2014/ch1a 23 ss

2014-09-19T16:26:38Z

Spsingh2: /* User Authentication */

= '''Security Features in Rails 4.x''' =

Web applications can be challenging for a developer to properly secure against threats. There are many attack vectors against web applications that must be carefully considered and mitigated. The developer must be responsible to understand these threats and take the necessary steps to secure the application and data. A web application may be vulnerable due to misconfiguration, poorly written code, or through un-patched vulnerabilities.

[http://rubyonrails.org/ Ruby on Rails], or just Rails, is a web application framework written in Ruby. It is a full-stack framework which attempts to make the development process easier and more accessible. This wiki aims to highlight all the security features in a Rails 4.x.

__TOC__

= Threats Against Web Applications =

==Cookie Management==
Cookies are used to maintain stateful sessions in HTTP. The cookies typically contain the user's session id which is used to identify the user. By stealing it, the attacker can use the application in the victim's name.
More over since the data is stored on the client machine, programmers should not store sensitive data in cookies.

The cookie is sent in the clear and so the easiest way for the attacker is to sniff the packets. This attack is shown below in Figure 1.[[File:cookie_sniffing.png|none]]
Figure1: Packet Sniffing Attack

To manage the cookies Rails provide several options to the programmer.
===Use SSL===
SSL prevents the attacker from sniffing the cookie from the network.

<pre>
config.force_ssl = true
</pre>

===New Session Identifier===
Configure Rails to issue a new session identifier and declare the old one invalid after a successful login.

===Fast Timeout===
Set the expiry time stamp of the cookie to a small value so that chances of attacker using a stale cookie is minimized.

==Injection ==
An attacker can inject client site executable code. When the victim renders it, it can steal the cookie, hijack the session and redirect the victim to a different page.

Injection can be a script, sql statement, ajax code or header injection. Though the root cause is poor programming, Rails provide various plug ins that allow the programmer to avoid it.

==== Cross Site Scripting (XSS) ====

XSS is an attack where an adversary places client-side code in the web application, often through a valid method such as posting to a message board. This code is then viewed by other application users and executed by their client machines.

The general form of XSS attack is show below in Figure2.
[[File:Xss.png|none]]
Figure2: XSS attack in progress
This attack is mitigated by properly sanitizing any input to the application. <ref>https://www.netsparker.com/blog/web-security/ruby-on-rails-security-basics/</ref> The sanitize method may be used to strip improper code from user input.

'''Input to be sanitized''':
<pre><%= sanitize '<img src=x onerror=prompt(1)>' %></pre>

'''Sanitized output:'''
<pre>
<img src=“x”>
</pre>

==== SQL Injection ====

SQL injection is a very common and serious vulnerability for many applications. The generalized concept is to pass carefully crafted input that will eventually get passed as parameters in a SQL statement. In July of 2014, Rails developers released version 4.1.3 in order to patch a serious vulnurability affecting applications using a PostgreSQL database system. <ref>http://www.computerworld.com/article/2489654/malware-vulnerabilities/ruby-on-rails-patches-tackle-sql-injection-vulnerabilities.html</ref> This vulnerability allowed attackers to inject arbitrary SQL code into the affected Rails applications.

To protect the application from this potential vulnerability, you should be careful when processing any SQL query that contains user submitted data. The sanitize_SQL method may be used to remove improper characters.

==== Header Injection ====

HTTP request headers have various fields that are user supplied and may be manipulated with more or less effort. Programmer need to escape these header fields and avoid building partial headers based on user input. Rails provide a rich api that can be used to create the headers in a secure fashion.

==Cross Site Request Forgery (CSRF)==
This attack method works by including malicious code or a link in a page that accesses a web application that the user is believed to have authenticated. If the session for that web application has not timed out, an attacker may execute unauthorized commands. This is shown below in Figure 3.
[[File:My_csrf.png|none]]
Figure 3: CSRF attack

To fix this the application needs to do the following.

===Security Token===
All non GET request should use a security token. Rails inserts this required security token that our site knows but other sites don't know. This is verified on the server. If the security token does not match then the session will be reset.

Enable this in the application controller.

<pre>
protect_from_forgery
</pre>

== Application Logic ==
There are certain common functionality that most applications need to implement. If these are not implemented correctly, then they can cause a security vulnerability. Rails provide plug ins that make the job easier to implement. Some common cases are discussed below.

===User Authentication===
Most web applications have to deal with user authorization and authentication. Hence it is up to the programmer to implement it correctly. Rails provide built in "''has_secure_password'' feature that stores the password in encrypted manner.
*Brute Force Attack
** Good Password: Ensure that the user password are "random" enough. Rails make it easy to define requirements for the password field in the model.
** Implement CAPTCHAs:This is a challenge response test that determines that the response is not generated by a computer. Rails provide extensive API for implementing it.
*Logging:Rails should be configured to not put passwords into log files by using the followingn in applicatin controller.
<pre>
config.filter_parameters
</pre>
*Anchor Regular Expressions:Ruby has extensive options that can be used to anchor it at the line beginning and line end. Rails 4 also introduces a multiline option for validates_format_of.

===File Upload===
Many applications allow user to upload files. Use Rail plugin to handle unsafe file names and file upload.

===Command Line===
Ruby provides api like "''system(command, parameters)'' which passes command line parameters safely.

= Security Enhancements =
==Automated Security Scanners==
There are a number of different security analysis tools available for Ruby on Rails applications.

*[http://brakemanscanner.org/docs/introduction/ Brakeman] is an open source, automated static-analysis scanner available for Rails developers. Brakeman scans the source code for misconfiguration, conformance to best practices, and other potential security issues.

*[https://github.com/codesake/codesake-dawn Codesake::Dawn] is another open source scanner for Rails applications. It attempts to detect the MVC architecture of your application to properly check the code base. Codesake scans for XSS scripting and SQL injection vulnerabilities.

= Unresolved Issues =
== Verbose Servers Headers ==
The default web server for a Rails application is [http://en.wikipedia.org/wiki/WEBrick WEBrick]. It is a simple open source server that is not often used in production, but has a potential security vulnerability if used in a live application. WEBrick returns a verbose security header which returns the full version number of both WEBrick and Ruby. <ref>http://blog.codeclimate.com/blog/2013/03/27/rails-insecure-defaults/</ref>

Example HTTP Response:<ref>http://blog.codeclimate.com/blog/2013/03/27/rails-insecure-defaults/</ref>
<pre>
HTTP/1.1 200 OK
# …
Server: WEBrick/1.3.1 (Ruby/1.9.3/2012-04-20)
</pre>

This verbose message is unnecessary and provides too much information to a potential intruder. An adversary can easily scan many web applications looking for un-patched servers that may be exploited.

== Binding to 0.0.0.0 ==
By default when starting a Rails server, it will bind to ''http://0.0.0.0:3000''. For a development environment, this is often unnecessary and only needs to bind to ''127.0.0.1''. Developers should use the ''--binding'' option to limit the interfaces to only those that are necessary.

== Versioned Secret Tokens ==
In Rails applications up through version 4.0, a generated secret security token was created in ''config/initializers/secret_token.rb'' when creating a Rails application. This token was vulnerable to being left unsecured by developers, or accidentally getting committed to a version control system. An adversary who obtained the secret token could trivially exploit the web application.

These concerns were alleviated in Ruby 4.1. The secret token file was replaced by a ''secrets.yml'' file in the config folder.

'''secrets.yml:'''
<pre>
development:
secret_key_base:

test:
secret_key_base:

production:
secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>
</pre>

This provides the ability to store your sensitive tokens in an environment variable for better security. The ''secrets.yml'' file is also in .gitignore by default, which helps out unaware programmers from accidentally committing their key.

== Logging Values in SQL statements ==
== Offsite Redirects ==

= Reference =
http://blog.codeclimate.com/blog/2013/03/27/rails-insecure-defaults/

http://guides.rubyonrails.org/security.html

https://www.acunetix.com/websitesecurity/xss/

<references />

CSC/ECE 517 Fall 2014/ch1a 23 ss

2014-09-19T16:25:29Z

Spsingh2: /* Security Token */

= '''Security Features in Rails 4.x''' =

Web applications can be challenging for a developer to properly secure against threats. There are many attack vectors against web applications that must be carefully considered and mitigated. The developer must be responsible to understand these threats and take the necessary steps to secure the application and data. A web application may be vulnerable due to misconfiguration, poorly written code, or through un-patched vulnerabilities.

[http://rubyonrails.org/ Ruby on Rails], or just Rails, is a web application framework written in Ruby. It is a full-stack framework which attempts to make the development process easier and more accessible. This wiki aims to highlight all the security features in a Rails 4.x.

__TOC__

= Threats Against Web Applications =

==Cookie Management==
Cookies are used to maintain stateful sessions in HTTP. The cookies typically contain the user's session id which is used to identify the user. By stealing it, the attacker can use the application in the victim's name.
More over since the data is stored on the client machine, programmers should not store sensitive data in cookies.

The cookie is sent in the clear and so the easiest way for the attacker is to sniff the packets. This attack is shown below in Figure 1.[[File:cookie_sniffing.png|none]]
Figure1: Packet Sniffing Attack

To manage the cookies Rails provide several options to the programmer.
===Use SSL===
SSL prevents the attacker from sniffing the cookie from the network.

<pre>
config.force_ssl = true
</pre>

===New Session Identifier===
Configure Rails to issue a new session identifier and declare the old one invalid after a successful login.

===Fast Timeout===
Set the expiry time stamp of the cookie to a small value so that chances of attacker using a stale cookie is minimized.

==Injection ==
An attacker can inject client site executable code. When the victim renders it, it can steal the cookie, hijack the session and redirect the victim to a different page.

Injection can be a script, sql statement, ajax code or header injection. Though the root cause is poor programming, Rails provide various plug ins that allow the programmer to avoid it.

==== Cross Site Scripting (XSS) ====

XSS is an attack where an adversary places client-side code in the web application, often through a valid method such as posting to a message board. This code is then viewed by other application users and executed by their client machines.

The general form of XSS attack is show below in Figure2.
[[File:Xss.png|none]]
Figure2: XSS attack in progress
This attack is mitigated by properly sanitizing any input to the application. <ref>https://www.netsparker.com/blog/web-security/ruby-on-rails-security-basics/</ref> The sanitize method may be used to strip improper code from user input.

'''Input to be sanitized''':
<pre><%= sanitize '<img src=x onerror=prompt(1)>' %></pre>

'''Sanitized output:'''
<pre>
<img src=“x”>
</pre>

==== SQL Injection ====

SQL injection is a very common and serious vulnerability for many applications. The generalized concept is to pass carefully crafted input that will eventually get passed as parameters in a SQL statement. In July of 2014, Rails developers released version 4.1.3 in order to patch a serious vulnurability affecting applications using a PostgreSQL database system. <ref>http://www.computerworld.com/article/2489654/malware-vulnerabilities/ruby-on-rails-patches-tackle-sql-injection-vulnerabilities.html</ref> This vulnerability allowed attackers to inject arbitrary SQL code into the affected Rails applications.

To protect the application from this potential vulnerability, you should be careful when processing any SQL query that contains user submitted data. The sanitize_SQL method may be used to remove improper characters.

==== Header Injection ====

HTTP request headers have various fields that are user supplied and may be manipulated with more or less effort. Programmer need to escape these header fields and avoid building partial headers based on user input. Rails provide a rich api that can be used to create the headers in a secure fashion.

==Cross Site Request Forgery (CSRF)==
This attack method works by including malicious code or a link in a page that accesses a web application that the user is believed to have authenticated. If the session for that web application has not timed out, an attacker may execute unauthorized commands. This is shown below in Figure 3.
[[File:My_csrf.png|none]]
Figure 3: CSRF attack

To fix this the application needs to do the following.

===Security Token===
All non GET request should use a security token. Rails inserts this required security token that our site knows but other sites don't know. This is verified on the server. If the security token does not match then the session will be reset.

Enable this in the application controller.

<pre>
protect_from_forgery
</pre>

== Application Logic ==
There are certain common functionality that most applications need to implement. If these are not implemented correctly, then they can cause a security vulnerability. Rails provide plug ins that make the job easier to implement. Some common cases are discussed below.

===User Authentication===
Most web applications have to deal with user authorization and authentication. Hence it is up to the programmer to implement it correctly. Rails provide built in "''has_secure_password'' feature that stores the password in encrypted manner.
*Brute Force Attack
** Good Password: Ensure that the user password are "random" enough. Rails make it easy to define requirements for the password field in the model.
** Implement CAPTCHAs:This is a challenge response test that determines that the response is not generated by a computer. Rails provide extensive API for implementing it.
*Logging:Rails should be configured to not put passwords into log files by using "''config.filter_parameters'' in application configuration.
*Anchor Regular Expressions:Ruby has extensive options that can be used to anchor it at the line beginning and line end. Rails 4 also introduces a multiline option for validates_format_of.

===File Upload===
Many applications allow user to upload files. Use Rail plugin to handle unsafe file names and file upload.

===Command Line===
Ruby provides api like "''system(command, parameters)'' which passes command line parameters safely.

= Security Enhancements =
==Automated Security Scanners==
There are a number of different security analysis tools available for Ruby on Rails applications.

*[http://brakemanscanner.org/docs/introduction/ Brakeman] is an open source, automated static-analysis scanner available for Rails developers. Brakeman scans the source code for misconfiguration, conformance to best practices, and other potential security issues.

*[https://github.com/codesake/codesake-dawn Codesake::Dawn] is another open source scanner for Rails applications. It attempts to detect the MVC architecture of your application to properly check the code base. Codesake scans for XSS scripting and SQL injection vulnerabilities.

= Unresolved Issues =
== Verbose Servers Headers ==
The default web server for a Rails application is [http://en.wikipedia.org/wiki/WEBrick WEBrick]. It is a simple open source server that is not often used in production, but has a potential security vulnerability if used in a live application. WEBrick returns a verbose security header which returns the full version number of both WEBrick and Ruby. <ref>http://blog.codeclimate.com/blog/2013/03/27/rails-insecure-defaults/</ref>

Example HTTP Response:<ref>http://blog.codeclimate.com/blog/2013/03/27/rails-insecure-defaults/</ref>
<pre>
HTTP/1.1 200 OK
# …
Server: WEBrick/1.3.1 (Ruby/1.9.3/2012-04-20)
</pre>

This verbose message is unnecessary and provides too much information to a potential intruder. An adversary can easily scan many web applications looking for un-patched servers that may be exploited.

== Binding to 0.0.0.0 ==
By default when starting a Rails server, it will bind to ''http://0.0.0.0:3000''. For a development environment, this is often unnecessary and only needs to bind to ''127.0.0.1''. Developers should use the ''--binding'' option to limit the interfaces to only those that are necessary.

== Versioned Secret Tokens ==
In Rails applications up through version 4.0, a generated secret security token was created in ''config/initializers/secret_token.rb'' when creating a Rails application. This token was vulnerable to being left unsecured by developers, or accidentally getting committed to a version control system. An adversary who obtained the secret token could trivially exploit the web application.

These concerns were alleviated in Ruby 4.1. The secret token file was replaced by a ''secrets.yml'' file in the config folder.

'''secrets.yml:'''
<pre>
development:
secret_key_base:

test:
secret_key_base:

production:
secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>
</pre>

This provides the ability to store your sensitive tokens in an environment variable for better security. The ''secrets.yml'' file is also in .gitignore by default, which helps out unaware programmers from accidentally committing their key.

== Logging Values in SQL statements ==
== Offsite Redirects ==

= Reference =
http://blog.codeclimate.com/blog/2013/03/27/rails-insecure-defaults/

http://guides.rubyonrails.org/security.html

https://www.acunetix.com/websitesecurity/xss/

<references />

CSC/ECE 517 Fall 2014/ch1a 23 ss

2014-09-19T16:23:38Z

Spsingh2: /* Security Token */

= '''Security Features in Rails 4.x''' =

Web applications can be challenging for a developer to properly secure against threats. There are many attack vectors against web applications that must be carefully considered and mitigated. The developer must be responsible to understand these threats and take the necessary steps to secure the application and data. A web application may be vulnerable due to misconfiguration, poorly written code, or through un-patched vulnerabilities.

[http://rubyonrails.org/ Ruby on Rails], or just Rails, is a web application framework written in Ruby. It is a full-stack framework which attempts to make the development process easier and more accessible. This wiki aims to highlight all the security features in a Rails 4.x.

__TOC__

= Threats Against Web Applications =

==Cookie Management==
Cookies are used to maintain stateful sessions in HTTP. The cookies typically contain the user's session id which is used to identify the user. By stealing it, the attacker can use the application in the victim's name.
More over since the data is stored on the client machine, programmers should not store sensitive data in cookies.

The cookie is sent in the clear and so the easiest way for the attacker is to sniff the packets. This attack is shown below in Figure 1.[[File:cookie_sniffing.png|none]]
Figure1: Packet Sniffing Attack

To manage the cookies Rails provide several options to the programmer.
===Use SSL===
SSL prevents the attacker from sniffing the cookie from the network.

<pre>
config.force_ssl = true
</pre>

===New Session Identifier===
Configure Rails to issue a new session identifier and declare the old one invalid after a successful login.

===Fast Timeout===
Set the expiry time stamp of the cookie to a small value so that chances of attacker using a stale cookie is minimized.

==Injection ==
An attacker can inject client site executable code. When the victim renders it, it can steal the cookie, hijack the session and redirect the victim to a different page.

Injection can be a script, sql statement, ajax code or header injection. Though the root cause is poor programming, Rails provide various plug ins that allow the programmer to avoid it.

==== Cross Site Scripting (XSS) ====

XSS is an attack where an adversary places client-side code in the web application, often through a valid method such as posting to a message board. This code is then viewed by other application users and executed by their client machines.

The general form of XSS attack is show below in Figure2.
[[File:Xss.png|none]]
Figure2: XSS attack in progress
This attack is mitigated by properly sanitizing any input to the application. <ref>https://www.netsparker.com/blog/web-security/ruby-on-rails-security-basics/</ref> The sanitize method may be used to strip improper code from user input.

'''Input to be sanitized''':
<pre><%= sanitize '<img src=x onerror=prompt(1)>' %></pre>

'''Sanitized output:'''
<pre>
<img src=“x”>
</pre>

==== SQL Injection ====

SQL injection is a very common and serious vulnerability for many applications. The generalized concept is to pass carefully crafted input that will eventually get passed as parameters in a SQL statement. In July of 2014, Rails developers released version 4.1.3 in order to patch a serious vulnurability affecting applications using a PostgreSQL database system. <ref>http://www.computerworld.com/article/2489654/malware-vulnerabilities/ruby-on-rails-patches-tackle-sql-injection-vulnerabilities.html</ref> This vulnerability allowed attackers to inject arbitrary SQL code into the affected Rails applications.

To protect the application from this potential vulnerability, you should be careful when processing any SQL query that contains user submitted data. The sanitize_SQL method may be used to remove improper characters.

==== Header Injection ====

HTTP request headers have various fields that are user supplied and may be manipulated with more or less effort. Programmer need to escape these header fields and avoid building partial headers based on user input. Rails provide a rich api that can be used to create the headers in a secure fashion.

==Cross Site Request Forgery (CSRF)==
This attack method works by including malicious code or a link in a page that accesses a web application that the user is believed to have authenticated. If the session for that web application has not timed out, an attacker may execute unauthorized commands. This is shown below in Figure 3.
[[File:My_csrf.png|none]]
Figure 3: CSRF attack

To fix this the application needs to do the following.

===Security Token===
All non GET request should use a security token. Rails inserts this required security token that our site knows but other sites don't know. This is verified on the server.

== Application Logic ==
There are certain common functionality that most applications need to implement. If these are not implemented correctly, then they can cause a security vulnerability. Rails provide plug ins that make the job easier to implement. Some common cases are discussed below.

===User Authentication===
Most web applications have to deal with user authorization and authentication. Hence it is up to the programmer to implement it correctly. Rails provide built in "''has_secure_password'' feature that stores the password in encrypted manner.
*Brute Force Attack
** Good Password: Ensure that the user password are "random" enough. Rails make it easy to define requirements for the password field in the model.
** Implement CAPTCHAs:This is a challenge response test that determines that the response is not generated by a computer. Rails provide extensive API for implementing it.
*Logging:Rails should be configured to not put passwords into log files by using "''config.filter_parameters'' in application configuration.
*Anchor Regular Expressions:Ruby has extensive options that can be used to anchor it at the line beginning and line end. Rails 4 also introduces a multiline option for validates_format_of.

===File Upload===
Many applications allow user to upload files. Use Rail plugin to handle unsafe file names and file upload.

===Command Line===
Ruby provides api like "''system(command, parameters)'' which passes command line parameters safely.

= Security Enhancements =
==Automated Security Scanners==
There are a number of different security analysis tools available for Ruby on Rails applications.

*[http://brakemanscanner.org/docs/introduction/ Brakeman] is an open source, automated static-analysis scanner available for Rails developers. Brakeman scans the source code for misconfiguration, conformance to best practices, and other potential security issues.

*[https://github.com/codesake/codesake-dawn Codesake::Dawn] is another open source scanner for Rails applications. It attempts to detect the MVC architecture of your application to properly check the code base. Codesake scans for XSS scripting and SQL injection vulnerabilities.

= Unresolved Issues =
== Verbose Servers Headers ==
The default web server for a Rails application is [http://en.wikipedia.org/wiki/WEBrick WEBrick]. It is a simple open source server that is not often used in production, but has a potential security vulnerability if used in a live application. WEBrick returns a verbose security header which returns the full version number of both WEBrick and Ruby. <ref>http://blog.codeclimate.com/blog/2013/03/27/rails-insecure-defaults/</ref>

Example HTTP Response:<ref>http://blog.codeclimate.com/blog/2013/03/27/rails-insecure-defaults/</ref>
<pre>
HTTP/1.1 200 OK
# …
Server: WEBrick/1.3.1 (Ruby/1.9.3/2012-04-20)
</pre>

This verbose message is unnecessary and provides too much information to a potential intruder. An adversary can easily scan many web applications looking for un-patched servers that may be exploited.

== Binding to 0.0.0.0 ==
By default when starting a Rails server, it will bind to ''http://0.0.0.0:3000''. For a development environment, this is often unnecessary and only needs to bind to ''127.0.0.1''. Developers should use the ''--binding'' option to limit the interfaces to only those that are necessary.

== Versioned Secret Tokens ==
In Rails applications up through version 4.0, a generated secret security token was created in ''config/initializers/secret_token.rb'' when creating a Rails application. This token was vulnerable to being left unsecured by developers, or accidentally getting committed to a version control system. An adversary who obtained the secret token could trivially exploit the web application.

These concerns were alleviated in Ruby 4.1. The secret token file was replaced by a ''secrets.yml'' file in the config folder.

'''secrets.yml:'''
<pre>
development:
secret_key_base:

test:
secret_key_base:

production:
secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>
</pre>

This provides the ability to store your sensitive tokens in an environment variable for better security. The ''secrets.yml'' file is also in .gitignore by default, which helps out unaware programmers from accidentally committing their key.

== Logging Values in SQL statements ==
== Offsite Redirects ==

= Reference =
http://blog.codeclimate.com/blog/2013/03/27/rails-insecure-defaults/

http://guides.rubyonrails.org/security.html

https://www.acunetix.com/websitesecurity/xss/

<references />

CSC/ECE 517 Fall 2014/ch1a 23 ss

2014-09-19T16:22:00Z

Spsingh2: /* Cross Site Request Forgery (CSRF) */

= '''Security Features in Rails 4.x''' =

Web applications can be challenging for a developer to properly secure against threats. There are many attack vectors against web applications that must be carefully considered and mitigated. The developer must be responsible to understand these threats and take the necessary steps to secure the application and data. A web application may be vulnerable due to misconfiguration, poorly written code, or through un-patched vulnerabilities.

[http://rubyonrails.org/ Ruby on Rails], or just Rails, is a web application framework written in Ruby. It is a full-stack framework which attempts to make the development process easier and more accessible. This wiki aims to highlight all the security features in a Rails 4.x.

__TOC__

= Threats Against Web Applications =

==Cookie Management==
Cookies are used to maintain stateful sessions in HTTP. The cookies typically contain the user's session id which is used to identify the user. By stealing it, the attacker can use the application in the victim's name.
More over since the data is stored on the client machine, programmers should not store sensitive data in cookies.

The cookie is sent in the clear and so the easiest way for the attacker is to sniff the packets. This attack is shown below in Figure 1.[[File:cookie_sniffing.png|none]]
Figure1: Packet Sniffing Attack

To manage the cookies Rails provide several options to the programmer.
===Use SSL===
SSL prevents the attacker from sniffing the cookie from the network.

<pre>
config.force_ssl = true
</pre>

===New Session Identifier===
Configure Rails to issue a new session identifier and declare the old one invalid after a successful login.

===Fast Timeout===
Set the expiry time stamp of the cookie to a small value so that chances of attacker using a stale cookie is minimized.

==Injection ==
An attacker can inject client site executable code. When the victim renders it, it can steal the cookie, hijack the session and redirect the victim to a different page.

Injection can be a script, sql statement, ajax code or header injection. Though the root cause is poor programming, Rails provide various plug ins that allow the programmer to avoid it.

==== Cross Site Scripting (XSS) ====

XSS is an attack where an adversary places client-side code in the web application, often through a valid method such as posting to a message board. This code is then viewed by other application users and executed by their client machines.

The general form of XSS attack is show below in Figure2.
[[File:Xss.png|none]]
Figure2: XSS attack in progress
This attack is mitigated by properly sanitizing any input to the application. <ref>https://www.netsparker.com/blog/web-security/ruby-on-rails-security-basics/</ref> The sanitize method may be used to strip improper code from user input.

'''Input to be sanitized''':
<pre><%= sanitize '<img src=x onerror=prompt(1)>' %></pre>

'''Sanitized output:'''
<pre>
<img src=“x”>
</pre>

==== SQL Injection ====

SQL injection is a very common and serious vulnerability for many applications. The generalized concept is to pass carefully crafted input that will eventually get passed as parameters in a SQL statement. In July of 2014, Rails developers released version 4.1.3 in order to patch a serious vulnurability affecting applications using a PostgreSQL database system. <ref>http://www.computerworld.com/article/2489654/malware-vulnerabilities/ruby-on-rails-patches-tackle-sql-injection-vulnerabilities.html</ref> This vulnerability allowed attackers to inject arbitrary SQL code into the affected Rails applications.

To protect the application from this potential vulnerability, you should be careful when processing any SQL query that contains user submitted data. The sanitize_SQL method may be used to remove improper characters.

==== Header Injection ====

HTTP request headers have various fields that are user supplied and may be manipulated with more or less effort. Programmer need to escape these header fields and avoid building partial headers based on user input. Rails provide a rich api that can be used to create the headers in a secure fashion.

==Cross Site Request Forgery (CSRF)==
This attack method works by including malicious code or a link in a page that accesses a web application that the user is believed to have authenticated. If the session for that web application has not timed out, an attacker may execute unauthorized commands. This is shown below in Figure 3.
[[File:My_csrf.png|none]]
Figure 3: CSRF attack

To fix this the application needs to do the following.

===Security Token===
All non GET request should use a security token.

== Application Logic ==
There are certain common functionality that most applications need to implement. If these are not implemented correctly, then they can cause a security vulnerability. Rails provide plug ins that make the job easier to implement. Some common cases are discussed below.

===User Authentication===
Most web applications have to deal with user authorization and authentication. Hence it is up to the programmer to implement it correctly. Rails provide built in "''has_secure_password'' feature that stores the password in encrypted manner.
*Brute Force Attack
** Good Password: Ensure that the user password are "random" enough. Rails make it easy to define requirements for the password field in the model.
** Implement CAPTCHAs:This is a challenge response test that determines that the response is not generated by a computer. Rails provide extensive API for implementing it.
*Logging:Rails should be configured to not put passwords into log files by using "''config.filter_parameters'' in application configuration.
*Anchor Regular Expressions:Ruby has extensive options that can be used to anchor it at the line beginning and line end. Rails 4 also introduces a multiline option for validates_format_of.

===File Upload===
Many applications allow user to upload files. Use Rail plugin to handle unsafe file names and file upload.

===Command Line===
Ruby provides api like "''system(command, parameters)'' which passes command line parameters safely.

= Security Enhancements =
==Automated Security Scanners==
There are a number of different security analysis tools available for Ruby on Rails applications.

*[http://brakemanscanner.org/docs/introduction/ Brakeman] is an open source, automated static-analysis scanner available for Rails developers. Brakeman scans the source code for misconfiguration, conformance to best practices, and other potential security issues.

*[https://github.com/codesake/codesake-dawn Codesake::Dawn] is another open source scanner for Rails applications. It attempts to detect the MVC architecture of your application to properly check the code base. Codesake scans for XSS scripting and SQL injection vulnerabilities.

= Unresolved Issues =
== Verbose Servers Headers ==
The default web server for a Rails application is [http://en.wikipedia.org/wiki/WEBrick WEBrick]. It is a simple open source server that is not often used in production, but has a potential security vulnerability if used in a live application. WEBrick returns a verbose security header which returns the full version number of both WEBrick and Ruby. <ref>http://blog.codeclimate.com/blog/2013/03/27/rails-insecure-defaults/</ref>

Example HTTP Response:<ref>http://blog.codeclimate.com/blog/2013/03/27/rails-insecure-defaults/</ref>
<pre>
HTTP/1.1 200 OK
# …
Server: WEBrick/1.3.1 (Ruby/1.9.3/2012-04-20)
</pre>

This verbose message is unnecessary and provides too much information to a potential intruder. An adversary can easily scan many web applications looking for un-patched servers that may be exploited.

== Binding to 0.0.0.0 ==
By default when starting a Rails server, it will bind to ''http://0.0.0.0:3000''. For a development environment, this is often unnecessary and only needs to bind to ''127.0.0.1''. Developers should use the ''--binding'' option to limit the interfaces to only those that are necessary.

== Versioned Secret Tokens ==
In Rails applications up through version 4.0, a generated secret security token was created in ''config/initializers/secret_token.rb'' when creating a Rails application. This token was vulnerable to being left unsecured by developers, or accidentally getting committed to a version control system. An adversary who obtained the secret token could trivially exploit the web application.

These concerns were alleviated in Ruby 4.1. The secret token file was replaced by a ''secrets.yml'' file in the config folder.

'''secrets.yml:'''
<pre>
development:
secret_key_base:

test:
secret_key_base:

production:
secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>
</pre>

This provides the ability to store your sensitive tokens in an environment variable for better security. The ''secrets.yml'' file is also in .gitignore by default, which helps out unaware programmers from accidentally committing their key.

== Logging Values in SQL statements ==
== Offsite Redirects ==

= Reference =
http://blog.codeclimate.com/blog/2013/03/27/rails-insecure-defaults/

http://guides.rubyonrails.org/security.html

https://www.acunetix.com/websitesecurity/xss/

<references />

CSC/ECE 517 Fall 2014/ch1a 23 ss

2014-09-19T16:21:24Z

Spsingh2: /* Injection */

= '''Security Features in Rails 4.x''' =

Web applications can be challenging for a developer to properly secure against threats. There are many attack vectors against web applications that must be carefully considered and mitigated. The developer must be responsible to understand these threats and take the necessary steps to secure the application and data. A web application may be vulnerable due to misconfiguration, poorly written code, or through un-patched vulnerabilities.

[http://rubyonrails.org/ Ruby on Rails], or just Rails, is a web application framework written in Ruby. It is a full-stack framework which attempts to make the development process easier and more accessible. This wiki aims to highlight all the security features in a Rails 4.x.

__TOC__

= Threats Against Web Applications =

==Cookie Management==
Cookies are used to maintain stateful sessions in HTTP. The cookies typically contain the user's session id which is used to identify the user. By stealing it, the attacker can use the application in the victim's name.
More over since the data is stored on the client machine, programmers should not store sensitive data in cookies.

The cookie is sent in the clear and so the easiest way for the attacker is to sniff the packets. This attack is shown below in Figure 1.[[File:cookie_sniffing.png|none]]
Figure1: Packet Sniffing Attack

To manage the cookies Rails provide several options to the programmer.
===Use SSL===
SSL prevents the attacker from sniffing the cookie from the network.

<pre>
config.force_ssl = true
</pre>

===New Session Identifier===
Configure Rails to issue a new session identifier and declare the old one invalid after a successful login.

===Fast Timeout===
Set the expiry time stamp of the cookie to a small value so that chances of attacker using a stale cookie is minimized.

==Injection ==
An attacker can inject client site executable code. When the victim renders it, it can steal the cookie, hijack the session and redirect the victim to a different page.

Injection can be a script, sql statement, ajax code or header injection. Though the root cause is poor programming, Rails provide various plug ins that allow the programmer to avoid it.

==== Cross Site Scripting (XSS) ====

XSS is an attack where an adversary places client-side code in the web application, often through a valid method such as posting to a message board. This code is then viewed by other application users and executed by their client machines.

The general form of XSS attack is show below in Figure2.
[[File:Xss.png|none]]
Figure2: XSS attack in progress
This attack is mitigated by properly sanitizing any input to the application. <ref>https://www.netsparker.com/blog/web-security/ruby-on-rails-security-basics/</ref> The sanitize method may be used to strip improper code from user input.

'''Input to be sanitized''':
<pre><%= sanitize '<img src=x onerror=prompt(1)>' %></pre>

'''Sanitized output:'''
<pre>
<img src=“x”>
</pre>

==== SQL Injection ====

SQL injection is a very common and serious vulnerability for many applications. The generalized concept is to pass carefully crafted input that will eventually get passed as parameters in a SQL statement. In July of 2014, Rails developers released version 4.1.3 in order to patch a serious vulnurability affecting applications using a PostgreSQL database system. <ref>http://www.computerworld.com/article/2489654/malware-vulnerabilities/ruby-on-rails-patches-tackle-sql-injection-vulnerabilities.html</ref> This vulnerability allowed attackers to inject arbitrary SQL code into the affected Rails applications.

To protect the application from this potential vulnerability, you should be careful when processing any SQL query that contains user submitted data. The sanitize_SQL method may be used to remove improper characters.

==== Header Injection ====

HTTP request headers have various fields that are user supplied and may be manipulated with more or less effort. Programmer need to escape these header fields and avoid building partial headers based on user input. Rails provide a rich api that can be used to create the headers in a secure fashion.

==Cross Site Request Forgery (CSRF)==
This attack method works by including malicious code or a link in a page that accesses a web application that the user is believed to have authenticated. If the session for that web application has not timed out, an attacker may execute unauthorized commands. This is shown below in Figure 2.
[[File:My_csrf.png|none]]
Figure 2: CSRF attack

To fix this the application needs to do the following.

===Security Token===
All non GET request should use a security token.

== Application Logic ==
There are certain common functionality that most applications need to implement. If these are not implemented correctly, then they can cause a security vulnerability. Rails provide plug ins that make the job easier to implement. Some common cases are discussed below.

===User Authentication===
Most web applications have to deal with user authorization and authentication. Hence it is up to the programmer to implement it correctly. Rails provide built in "''has_secure_password'' feature that stores the password in encrypted manner.
*Brute Force Attack
** Good Password: Ensure that the user password are "random" enough. Rails make it easy to define requirements for the password field in the model.
** Implement CAPTCHAs:This is a challenge response test that determines that the response is not generated by a computer. Rails provide extensive API for implementing it.
*Logging:Rails should be configured to not put passwords into log files by using "''config.filter_parameters'' in application configuration.
*Anchor Regular Expressions:Ruby has extensive options that can be used to anchor it at the line beginning and line end. Rails 4 also introduces a multiline option for validates_format_of.

===File Upload===
Many applications allow user to upload files. Use Rail plugin to handle unsafe file names and file upload.

===Command Line===
Ruby provides api like "''system(command, parameters)'' which passes command line parameters safely.

= Security Enhancements =
==Automated Security Scanners==
There are a number of different security analysis tools available for Ruby on Rails applications.

*[http://brakemanscanner.org/docs/introduction/ Brakeman] is an open source, automated static-analysis scanner available for Rails developers. Brakeman scans the source code for misconfiguration, conformance to best practices, and other potential security issues.

*[https://github.com/codesake/codesake-dawn Codesake::Dawn] is another open source scanner for Rails applications. It attempts to detect the MVC architecture of your application to properly check the code base. Codesake scans for XSS scripting and SQL injection vulnerabilities.

= Unresolved Issues =
== Verbose Servers Headers ==
The default web server for a Rails application is [http://en.wikipedia.org/wiki/WEBrick WEBrick]. It is a simple open source server that is not often used in production, but has a potential security vulnerability if used in a live application. WEBrick returns a verbose security header which returns the full version number of both WEBrick and Ruby. <ref>http://blog.codeclimate.com/blog/2013/03/27/rails-insecure-defaults/</ref>

Example HTTP Response:<ref>http://blog.codeclimate.com/blog/2013/03/27/rails-insecure-defaults/</ref>
<pre>
HTTP/1.1 200 OK
# …
Server: WEBrick/1.3.1 (Ruby/1.9.3/2012-04-20)
</pre>

This verbose message is unnecessary and provides too much information to a potential intruder. An adversary can easily scan many web applications looking for un-patched servers that may be exploited.

== Binding to 0.0.0.0 ==
By default when starting a Rails server, it will bind to ''http://0.0.0.0:3000''. For a development environment, this is often unnecessary and only needs to bind to ''127.0.0.1''. Developers should use the ''--binding'' option to limit the interfaces to only those that are necessary.

== Versioned Secret Tokens ==
In Rails applications up through version 4.0, a generated secret security token was created in ''config/initializers/secret_token.rb'' when creating a Rails application. This token was vulnerable to being left unsecured by developers, or accidentally getting committed to a version control system. An adversary who obtained the secret token could trivially exploit the web application.

These concerns were alleviated in Ruby 4.1. The secret token file was replaced by a ''secrets.yml'' file in the config folder.

'''secrets.yml:'''
<pre>
development:
secret_key_base:

test:
secret_key_base:

production:
secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>
</pre>

This provides the ability to store your sensitive tokens in an environment variable for better security. The ''secrets.yml'' file is also in .gitignore by default, which helps out unaware programmers from accidentally committing their key.

== Logging Values in SQL statements ==
== Offsite Redirects ==

= Reference =
http://blog.codeclimate.com/blog/2013/03/27/rails-insecure-defaults/

http://guides.rubyonrails.org/security.html

https://www.acunetix.com/websitesecurity/xss/

<references />

CSC/ECE 517 Fall 2014/ch1a 23 ss

2014-09-19T16:14:04Z

Spsingh2: /* Injection */

= '''Security Features in Rails 4.x''' =

Web applications can be challenging for a developer to properly secure against threats. There are many attack vectors against web applications that must be carefully considered and mitigated. The developer must be responsible to understand these threats and take the necessary steps to secure the application and data. A web application may be vulnerable due to misconfiguration, poorly written code, or through un-patched vulnerabilities.

[http://rubyonrails.org/ Ruby on Rails], or just Rails, is a web application framework written in Ruby. It is a full-stack framework which attempts to make the development process easier and more accessible. This wiki aims to highlight all the security features in a Rails 4.x.

__TOC__

= Threats Against Web Applications =

==Cookie Management==
Cookies are used to maintain stateful sessions in HTTP. The cookies typically contain the user's session id which is used to identify the user. By stealing it, the attacker can use the application in the victim's name.
More over since the data is stored on the client machine, programmers should not store sensitive data in cookies.

The cookie is sent in the clear and so the easiest way for the attacker is to sniff the packets. This attack is shown below in Figure 1.[[File:cookie_sniffing.png|none]]
Figure1: Packet Sniffing Attack

To manage the cookies Rails provide several options to the programmer.
===Use SSL===
SSL prevents the attacker from sniffing the cookie from the network.

<pre>
config.force_ssl = true
</pre>

===New Session Identifier===
Configure Rails to issue a new session identifier and declare the old one invalid after a successful login.

===Fast Timeout===
Set the expiry time stamp of the cookie to a small value so that chances of attacker using a stale cookie is minimized.

==Injection ==
An attacker can inject client site executable code. When the victim renders it, it can steal the cookie, hijack the session and redirect the victim to a different page.

==== Cross Site Scripting (XSS) ====

XSS is an attack where an adversary places client-side code in the web application, often through a valid method such as posting to a message board. This code is then viewed by other application users and executed by their client machines.

The general form of XSS attack is show below in Figure2.
[[File:Xss.png|none]]
Figure2: XSS attack in progress
This attack is mitigated by properly sanitizing any input to the application. <ref>https://www.netsparker.com/blog/web-security/ruby-on-rails-security-basics/</ref> The sanitize method may be used to strip improper code from user input.

'''Input to be sanitized''':
<pre><%= sanitize '<img src=x onerror=prompt(1)>' %></pre>

'''Sanitized output:'''
<pre>
<img src=“x”>
</pre>

==== SQL Injection ====

SQL injection is a very common and serious vulnerability for many applications. The generalized concept is to pass carefully crafted input that will eventually get passed as parameters in a SQL statement. In July of 2014, Rails developers released version 4.1.3 in order to patch a serious vulnurability affecting applications using a PostgreSQL database system. <ref>http://www.computerworld.com/article/2489654/malware-vulnerabilities/ruby-on-rails-patches-tackle-sql-injection-vulnerabilities.html</ref> This vulnerability allowed attackers to inject arbitrary SQL code into the affected Rails applications.

To protect the application from this potential vulnerability, you should be careful when processing any SQL query that contains user submitted data. The sanitize_SQL method may be used to remove improper characters.

==== Ajax Injection ====

==== Header Injection ====

==Cross Site Request Forgery (CSRF)==
This attack method works by including malicious code or a link in a page that accesses a web application that the user is believed to have authenticated. If the session for that web application has not timed out, an attacker may execute unauthorized commands. This is shown below in Figure 2.
[[File:My_csrf.png|none]]
Figure 2: CSRF attack

To fix this the application needs to do the following.

===Security Token===
All non GET request should use a security token.

== Application Logic ==
There are certain common functionality that most applications need to implement. If these are not implemented correctly, then they can cause a security vulnerability. Rails provide plug ins that make the job easier to implement. Some common cases are discussed below.

===User Authentication===
Most web applications have to deal with user authorization and authentication. Hence it is up to the programmer to implement it correctly. Rails provide built in "''has_secure_password'' feature that stores the password in encrypted manner.
*Brute Force Attack
** Good Password: Ensure that the user password are "random" enough. Rails make it easy to define requirements for the password field in the model.
** Implement CAPTCHAs:This is a challenge response test that determines that the response is not generated by a computer. Rails provide extensive API for implementing it.
*Logging:Rails should be configured to not put passwords into log files by using "''config.filter_parameters'' in application configuration.
*Anchor Regular Expressions:Ruby has extensive options that can be used to anchor it at the line beginning and line end. Rails 4 also introduces a multiline option for validates_format_of.

===File Upload===
Many applications allow user to upload files. Use Rail plugin to handle unsafe file names and file upload.

===Command Line===
Ruby provides api like "''system(command, parameters)'' which passes command line parameters safely.

= Security Enhancements =
==Automated Security Scanners==
There are a number of different security analysis tools available for Ruby on Rails applications.

*[http://brakemanscanner.org/docs/introduction/ Brakeman] is an open source, automated static-analysis scanner available for Rails developers. Brakeman scans the source code for misconfiguration, conformance to best practices, and other potential security issues.

*[https://github.com/codesake/codesake-dawn Codesake::Dawn] is another open source scanner for Rails applications. It attempts to detect the MVC architecture of your application to properly check the code base. Codesake scans for XSS scripting and SQL injection vulnerabilities.

= Unresolved Issues =
== Verbose Servers Headers ==
The default web server for a Rails application is [http://en.wikipedia.org/wiki/WEBrick WEBrick]. It is a simple open source server that is not often used in production, but has a potential security vulnerability if used in a live application. WEBrick returns a verbose security header which returns the full version number of both WEBrick and Ruby. <ref>http://blog.codeclimate.com/blog/2013/03/27/rails-insecure-defaults/</ref>

Example HTTP Response:<ref>http://blog.codeclimate.com/blog/2013/03/27/rails-insecure-defaults/</ref>
<pre>
HTTP/1.1 200 OK
# …
Server: WEBrick/1.3.1 (Ruby/1.9.3/2012-04-20)
</pre>

This verbose message is unnecessary and provides too much information to a potential intruder. An adversary can easily scan many web applications looking for un-patched servers that may be exploited.

== Binding to 0.0.0.0 ==
By default when starting a Rails server, it will bind to ''http://0.0.0.0:3000''. For a development environment, this is often unnecessary and only needs to bind to ''127.0.0.1''. Developers should use the ''--binding'' option to limit the interfaces to only those that are necessary.

== Versioned Secret Tokens ==
In Rails applications up through version 4.0, a generated secret security token was created in ''config/initializers/secret_token.rb'' when creating a Rails application. This token was vulnerable to being left unsecured by developers, or accidentally getting committed to a version control system. An adversary who obtained the secret token could trivially exploit the web application.

These concerns were alleviated in Ruby 4.1. The secret token file was replaced by a ''secrets.yml'' file in the config folder.

'''secrets.yml:'''
<pre>
development:
secret_key_base:

test:
secret_key_base:

production:
secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>
</pre>

This provides the ability to store your sensitive tokens in an environment variable for better security. The ''secrets.yml'' file is also in .gitignore by default, which helps out unaware programmers from accidentally committing their key.

== Logging Values in SQL statements ==
== Offsite Redirects ==

= Reference =
http://blog.codeclimate.com/blog/2013/03/27/rails-insecure-defaults/

http://guides.rubyonrails.org/security.html

https://www.acunetix.com/websitesecurity/xss/

<references />

CSC/ECE 517 Fall 2014/ch1a 23 ss

2014-09-18T20:22:51Z

Spsingh2: /* Injection */

= '''Security Features in Rails 4.x''' =

Web applications can be challenging for a developer to properly secure against threats. There are many attack vectors against web applications that must be carefully considered and mitigated. The developer must be responsible to understand these threats and take the necessary steps to secure the application and data. A web application may be vulnerable due to misconfiguration, poorly written code, or through un-patched vulnerabilities.

[http://rubyonrails.org/ Ruby on Rails], or just Rails, is a web application framework written in Ruby. It is a full-stack framework which attempts to make the development process easier and more accessible. This wiki aims to highlight all the security features in a Rails 4.x.

__TOC__

= Threats Against Web Applications =

==Cookie Management==
Cookies are used to maintain stateful sessions in HTTP. The cookies typically contain the user's session id which is used to identify the user. By stealing it, the attacker can use the application in the victim's name.
More over since the data is stored on the client machine, programmers should not store sensitive data in cookies.

The cookie is sent in the clear and so the easiest way for the attacker is to sniff the packets. This attack is shown below in Figure 1.[[File:cookie_sniffing.png|none]]
Figure1: Packet Sniffing Attack

To manage the cookies Rails provide several options to the programmer.
===Use SSL===
SSL prevents the attacker from sniffing the cookie from the network.

<pre>
config.force_ssl = true
</pre>

===New Session Identifier===
Configure Rails to issue a new session identifier and declare the old one invalid after a successful login.

===Fast Timeout===
Set the expiry time stamp of the cookie to a small value so that chances of attacker using a stale cookie is minimized.

==Injection ==
An attacker can inject client site executable code. When the victim renders it, it can steal the cookie, hijack the session and redirect the victim to a different page.
The general form of XSS attack is show below in Figure.
[[File:Xss.png|none]]
Figure2: XSS attack in progress

==== Cross Site Scripting (XSS) ====

XSS is an attack where an adversary places client-side code in the web application, often through a valid method such as posting to a message board. This code is then viewed by other application users and executed by their client machines.

This attack is mitigated by properly sanitizing any input to the application. <ref>https://www.netsparker.com/blog/web-security/ruby-on-rails-security-basics/</ref> The sanitize method may be used to strip improper code from user input.

'''Input to be sanitized''':
<pre><%= sanitize '<img src=x onerror=prompt(1)>' %></pre>

'''Sanitized output:'''
<pre>
<img src=“x”>
</pre>

==== SQL Injection ====

SQL injection is a very common and serious vulnerability for many applications. The generalized concept is to pass carefully crafted input that will eventually get passed as parameters in a SQL statement. In July of 2014, Rails developers released version 4.1.3 in order to patch a serious vulnurability affecting applications using a PostgreSQL database system. <ref>http://www.computerworld.com/article/2489654/malware-vulnerabilities/ruby-on-rails-patches-tackle-sql-injection-vulnerabilities.html</ref> This vulnerability allowed attackers to inject arbitrary SQL code into the affected Rails applications.

To protect the application from this potential vulnerability, you should be careful when processing any SQL query that contains user submitted data. The sanitize_SQL method may be used to remove improper characters.

==== Ajax Injection ====

==== Header Injection ====

==Cross Site Request Forgery (CSRF)==
This attack method works by including malicious code or a link in a page that accesses a web application that the user is believed to have authenticated. If the session for that web application has not timed out, an attacker may execute unauthorized commands. This is shown below in Figure 2.
[[File:My_csrf.png|none]]
Figure 2: CSRF attack

To fix this the application needs to do the following.

===Security Token===
All non GET request should use a security token.

== Application Logic ==
There are certain common functionality that most applications need to implement. If these are not implemented correctly, then they can cause a security vulnerability. Rails provide plug ins that make the job easier to implement. Some common cases are discussed below.

===User Authentication===
Most web applications have to deal with user authorization and authentication. Hence it is up to the programmer to implement it correctly. Rails provide built in "''has_secure_password'' feature that stores the password in encrypted manner.
*Brute Force Attack
** Good Password: Ensure that the user password are "random" enough. Rails make it easy to define requirements for the password field in the model.
** Implement CAPTCHAs:This is a challenge response test that determines that the response is not generated by a computer. Rails provide extensive API for implementing it.
*Logging:Rails should be configured to not put passwords into log files by using "''config.filter_parameters'' in application configuration.
*Anchor Regular Expressions:Ruby has extensive options that can be used to anchor it at the line beginning and line end. Rails 4 also introduces a multiline option for validates_format_of.

===File Upload===
Many applications allow user to upload files. Use Rail plugin to handle unsafe file names and file upload.

===Command Line===
Ruby provides api like "''system(command, parameters)'' which passes command line parameters safely.

= Security Enhancements =
==Automated Security Scanners==
There are a number of different security analysis tools available for Ruby on Rails applications.

*[http://brakemanscanner.org/docs/introduction/ Brakeman] is an open source, automated static-analysis scanner available for Rails developers. Brakeman scans the source code for misconfiguration, conformance to best practices, and other potential security issues.

*[https://github.com/codesake/codesake-dawn Codesake::Dawn] is another open source scanner for Rails applications. It attempts to detect the MVC architecture of your application to properly check the code base. Codesake scans for XSS scripting and SQL injection vulnerabilities.

= Unresolved Issues =
== Verbose Servers Headers ==
The default web server for a Rails application is [http://en.wikipedia.org/wiki/WEBrick WEBrick]. It is a simple open source server that is not often used in production, but has a potential security vulnerability if used in a live application. WEBrick returns a verbose security header which returns the full version number of both WEBrick and Ruby. <ref>http://blog.codeclimate.com/blog/2013/03/27/rails-insecure-defaults/</ref>

Example HTTP Response:<ref>http://blog.codeclimate.com/blog/2013/03/27/rails-insecure-defaults/</ref>
<pre>
HTTP/1.1 200 OK
# …
Server: WEBrick/1.3.1 (Ruby/1.9.3/2012-04-20)
</pre>

This verbose message is unnecessary and provides too much information to a potential intruder. An adversary can easily scan many web applications looking for un-patched servers that may be exploited.

== Binding to 0.0.0.0 ==
By default when starting a Rails server, it will bind to ''http://0.0.0.0:3000''. For a development environment, this is often unnecessary and only needs to bind to ''127.0.0.1''. Developers should use the ''--binding'' option to limit the interfaces to only those that are necessary.

== Versioned Secret Tokens ==
In Rails applications up through version 4.0, a generated secret security token was created in ''config/initializers/secret_token.rb'' when creating a Rails application. This token was vulnerable to being left unsecured by developers, or accidentally getting committed to a version control system. An adversary who obtained the secret token could trivially exploit the web application.

These concerns were alleviated in Ruby 4.1. The secret token file was replaced by a ''secrets.yml'' file in the config folder.

'''secrets.yml:'''
<pre>
development:
secret_key_base:

test:
secret_key_base:

production:
secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>
</pre>

This file is in .gitignore by default, when helps out unaware programmers.

== Logging Values in SQL statements ==
== Offsite Redirects ==

= Reference =
http://blog.codeclimate.com/blog/2013/03/27/rails-insecure-defaults/

http://guides.rubyonrails.org/security.html

https://www.acunetix.com/websitesecurity/xss/

<references />

File:Xss.png

2014-09-18T20:20:31Z

Spsingh2:

CSC/ECE 517 Fall 2014/ch1a 23 ss

2014-09-18T20:08:49Z

Spsingh2: /* Reference */

= '''Security Features in Rails 4.x''' =

Web applications can be challenging for a developer to properly secure against threats. There are many attack vectors against web applications that must be carefully considered and mitigated. The developer must be responsible to understand these threats and take the necessary steps to secure the application and data. A web application may be vulnerable due to misconfiguration, poorly written code, or through un-patched vulnerabilities.

[http://rubyonrails.org/ Ruby on Rails], or just Rails, is a web application framework written in Ruby. It is a full-stack framework which attempts to make the development process easier and more accessible. This wiki aims to highlight all the security features in a Rails 4.x.

__TOC__

= Threats Against Web Applications =

==Cookie Management==
Cookies are used to maintain stateful sessions in HTTP. The cookies typically contain the user's session id which is used to identify the user. By stealing it, the attacker can use the application in the victim's name.
More over since the data is stored on the client machine, programmers should not store sensitive data in cookies.

The cookie is sent in the clear and so the easiest way for the attacker is to sniff the packets. This attack is shown below in Figure 1.[[File:cookie_sniffing.png|none]]
Figure1: Packet Sniffing Attack

To manage the cookies Rails provide several options to the programmer.
===Use SSL===
SSL prevents the attacker from sniffing the cookie from the network.

<pre>
config.force_ssl = true
</pre>

===New Session Identifier===
Configure Rails to issue a new session identifier and declare the old one invalid after a successful login.

===Fast Timeout===
Set the expiry time stamp of the cookie to a small value so that chances of attacker using a stale cookie is minimized.

==Injection ==
An attacker can inject client site executable code. When the victim renders it, it can steal the cookie, hijack the session and redirect the victim to a different page.
==== Cross Site Scripting (XSS) ====

XSS is an attack where an adversary places client-side code in the web application, often through a valid method such as posting to a message board. This code is then viewed by other application users and executed by their client machines.

This attack is mitigated by properly sanitizing any input to the application. <ref>https://www.netsparker.com/blog/web-security/ruby-on-rails-security-basics/</ref> The sanitize method may be used to strip improper code from user input.

'''Input to be sanitized''':
<pre><%= sanitize '<img src=x onerror=prompt(1)>' %></pre>

'''Sanitized output:'''
<pre>
<img src=“x”>
</pre>

==== SQL Injection ====

SQL injection is a very common and serious vulnerability for many applications. The generalized concept is to pass carefully crafted input that will eventually get passed as parameters in a SQL statement. In July of 2014, Rails developers released version 4.1.3 in order to patch a serious vulnurability affecting applications using a PostgreSQL database system. <ref>http://www.computerworld.com/article/2489654/malware-vulnerabilities/ruby-on-rails-patches-tackle-sql-injection-vulnerabilities.html</ref> This vulnerability allowed attackers to inject arbitrary SQL code into the affected Rails applications.

To protect the application from this potential vulnerability, you should be careful when processing any SQL query that contains user submitted data. The sanitize_SQL method may be used to remove improper characters.

==== Ajax Injection ====

==== Header Injection ====

==Cross Site Request Forgery (CSRF)==
This attack method works by including malicious code or a link in a page that accesses a web application that the user is believed to have authenticated. If the session for that web application has not timed out, an attacker may execute unauthorized commands. This is shown below in Figure 2.
[[File:My_csrf.png|none]]
Figure 2: CSRF attack

To fix this the application needs to do the following.

===Security Token===
All non GET request should use a security token.

== Application Logic ==
There are certain common functionality that most applications need to implement. If these are not implemented correctly, then they can cause a security vulnerability. Rails provide plug ins that make the job easier to implement. Some common cases are discussed below.

===User Authentication===
Most web applications have to deal with user authorization and authentication. Hence it is up to the programmer to implement it correctly. Rails provide built in "''has_secure_password'' feature that stores the password in encrypted manner.
*Brute Force Attack
** Good Password: Ensure that the user password are "random" enough. Rails make it easy to define requirements for the password field in the model.
** Implement CAPTCHAs:This is a challenge response test that determines that the response is not generated by a computer. Rails provide extensive API for implementing it.
*Logging:Rails should be configured to not put passwords into log files by using "''config.filter_parameters'' in application configuration.
*Anchor Regular Expressions:Ruby has extensive options that can be used to anchor it at the line beginning and line end. Rails 4 also introduces a multiline option for validates_format_of.

===File Upload===
Many applications allow user to upload files. Use Rail plugin to handle unsafe file names and file upload.

===Command Line===
Ruby provides api like "''system(command, parameters)'' which passes command line parameters safely.

= Security Enhancements =
==Automated Security Scanners==
There are a number of different security analysis tools available for Ruby on Rails applications.

*[http://brakemanscanner.org/docs/introduction/ Brakeman] is an open source, automated static-analysis scanner available for Rails developers. Brakeman scans the source code for misconfiguration, conformance to best practices, and other potential security issues.

*[https://github.com/codesake/codesake-dawn Codesake::Dawn] is another open source scanner for Rails applications. It attempts to detect the MVC architecture of your application to properly check the code base. Codesake scans for XSS scripting and SQL injection vulnerabilities.

= Unresolved Issues =
== Verbose Servers Headers ==
The default web server for a Rails application is [http://en.wikipedia.org/wiki/WEBrick WEBrick]. It is a simple open source server that is not often used in production, but has a potential security vulnerability if used in a live application. WEBrick returns a verbose security header which returns the full version number of both WEBrick and Ruby. <ref>http://blog.codeclimate.com/blog/2013/03/27/rails-insecure-defaults/</ref>

Example HTTP Response:<ref>http://blog.codeclimate.com/blog/2013/03/27/rails-insecure-defaults/</ref>
<pre>
HTTP/1.1 200 OK
# …
Server: WEBrick/1.3.1 (Ruby/1.9.3/2012-04-20)
</pre>

This verbose message is unnecessary and provides too much information to a potential intruder. An adversary can easily scan many web applications looking for un-patched servers that may be exploited.

== Binding to 0.0.0.0 ==
By default when starting a Rails server, it will bind to ''http://0.0.0.0:3000''. For a development environment, this is often unnecessary and only needs to bind to ''127.0.0.1''. Developers should use the ''--binding'' option to limit the interfaces to only those that are necessary.

== Versioned Secret Tokens ==
== Logging Values in SQL statements ==
== Offsite Redirects ==

= Reference =
http://blog.codeclimate.com/blog/2013/03/27/rails-insecure-defaults/

http://guides.rubyonrails.org/security.html

https://www.acunetix.com/websitesecurity/xss/

<references />

CSC/ECE 517 Fall 2014/ch1a 23 ss

2014-09-18T20:01:46Z

Spsingh2: /* Cross Site Request Forgery (CSRF) */

CSC/ECE 517 Fall 2014/ch1a 23 ss

2014-09-18T20:00:56Z

Spsingh2: /* Cross Site Request Forgery (CSRF) */

File:My csrf.png

2014-09-18T19:58:19Z

Spsingh2:

CSC/ECE 517 Fall 2014/ch1a 23 ss

2014-09-18T19:39:51Z

Spsingh2: /* SQL Injection */

CSC/ECE 517 Fall 2014/ch1a 23 ss

2014-09-18T18:49:17Z

Spsingh2: /* Security Enhancements */

CSC/ECE 517 Fall 2014/ch1a 23 ss

2014-09-18T18:48:45Z

Spsingh2: /* User Authentication */

CSC/ECE 517 Fall 2014/ch1a 23 ss

2014-09-18T18:42:41Z

Spsingh2: /* User Security Policies */

CSC/ECE 517 Fall 2014/ch1a 23 ss

2014-09-18T17:49:05Z

Spsingh2: /* Redirection */

CSC/ECE 517 Fall 2014/ch1a 23 ss

2014-09-18T17:48:43Z

Spsingh2: /* File Upload */

CSC/ECE 517 Fall 2014/ch1a 23 ss

2014-09-18T17:47:27Z

Spsingh2: /* User Security Policies */

CSC/ECE 517 Fall 2014/ch1a 23 ss

2014-09-18T16:41:11Z

Spsingh2: /* Use SSL */

CSC/ECE 517 Fall 2014/ch1a 23 ss

2014-09-18T16:40:40Z

Spsingh2: /* Timeout Cookies */

CSC/ECE 517 Fall 2014/ch1a 23 ss

2014-09-18T16:40:14Z

Spsingh2: /* Cookie Management */

CSC/ECE 517 Fall 2014/ch1a 23 ss

2014-09-18T16:34:46Z

Spsingh2: /* Cookie Management */

CSC/ECE 517 Fall 2014/ch1a 23 ss

2014-09-18T16:21:16Z

Spsingh2: /* Cookie Management */

File:Cookie sniffing.png

2014-09-18T16:19:07Z

Spsingh2: