Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2014/final design doc M1450 navr

2014-11-12T01:11:26Z

Ravnee: /* Proposed Test Cases */

== Introduction ==

=== [http://www.rust-lang.org/ Rust]===

Rust is a modern systems programming language focusing on safety and speed to build reliable and efficient systems <ref> http://doc.rust-lang.org/nightly/intro.html </ref>. It accomplishes the goals of memory safe without using garbage collection and it supports concurrency and parallelism in building platforms.

Rust’s lightweight task mechanism also promises to allow fine-grained isolation between browser components, such as tabs and extensions, without the need for expensive runtime protection schemes, like operating system process isolation. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== [http://github.com/servo/servo/wiki/Design Servo] ===

Mozilla Research team is currently working on an experimental project to develop a new Web browser engine "Servo", that is capable of supporting a variety of current and next generation of hardware like mobile devices, multi-core processors and high-performance GPUs. Servo builds on top of Rust to provide a secure and reliable foundation. It is currently developed on 64 bit devices.<ref> https://www.mozilla.org/en-US/research/projects/ </ref>

The main objectives of this experimentation project is improving the layout to graphics rendering - to optimize for power efficiency and maximize parallelism. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== Purpose ===

The purpose of this project is to introduce the support related to sessionstorage and localstorage in Servo Broswer, for this we have to create Storage structure and allow web pages to store data in the Servo memory space.

=== Background ===

Persistent storage on the web is used by many services such as the popular Disqus commenting interface. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause.

== Architecture ==

[[File:task.jpg]]

The Architecture comprises of a Storage Task which will be responsible to hold all the data that the web page requests to save. This happens via Channels in Rust, which implements a Sender Receiver protocol, the task is runnning in the background and waits to receive the data sent from the web page.

=== Architecture Explained ===
*Each box represents a Rust task.
*Blue boxes represent the primary tasks in the browser pipeline.
*Gray boxes represent tasks auxiliary to the browser pipeline.
*White boxes represent worker tasks. Each such box represents several tasks, the precise number of which will vary with the workload.
*Dashed lines indicate supervisor relationships.
*Solid lines indicate communication channels.

== Requirement Analysis <ref>https://github.com/servo/servo/wiki/Storage-student-project</ref> ==

As part of our [http://github.com/servo/servo/wiki/Storage-student-project project], we have to implement the [http://html.spec.whatwg.org/multipage/webstorage.html#webstorage Web Storage] specification in Servo. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause. <ref> https://github.com/servo/servo/wiki/Storage-student-project</ref>

Below is a high level overview of the various steps that need to be carried out to achieve this:

* Create the Storage interface and its stub implementation.
* Create the WindowSessionStorage interface making it return a Storage instance.
* Create a Storage Task which will be used to contain all stored data.
* Define a message-passing interface for reading and writing stored data for a particular browser tab.
* Use the Storage task in the implementation of Storage.
* When the value of a stored data is changed, notify its respective browser tab.
* Pass as many tests as possible.
* Implement the WindowLocalStorage interface which behaves slightly different from the WindowSessionStorage interface.

== Data Design ==

=== Data Description ===

''The following are the data structures that will be used.''

'''Storage''' | TreeMap<String,String>

'''UrlMap''' | TreeMap<String,TreeMap<String,String>>

== Component Design ==
[[File:servo.jpg]]
=== Task ===
Rust provides safe concurrent abstractions through a number of core library primitives. This guide will describe the concurrency model in Rust, how it relates to the Rust type system, and introduce the fundamental library abstractions for constructing concurrent programs.

Tasks provide failure isolation and recovery. When a fatal error occurs in Rust code as a result of an explicit call to panic!(), an assertion failure, or another invalid operation, the runtime system destroys the entire task. Unlike in languages such as Java and C++, there is no way to catch an exception. Instead, tasks may monitor each other to see if they panic.

Tasks use Rust's type system to provide strong memory safety guarantees. In particular, the type system guarantees that tasks cannot induce a data race from shared mutable state.

<pre>
// Generate some state locally
let child_task_number = generate_task_number();

spawn(proc() {
// Capture it in the remote task
println!("I am child number {}", child_task_number);
});
</pre>

=== Channel ===
Now that we have spawned a new task, it would be nice if we could communicate with it. For this, we use channels. A channel is simply a pair of endpoints: one for sending messages and another for receiving messages.

The simplest way to create a channel is to use the channel function to create a (Sender, Receiver) pair. In Rust parlance, a sender is a sending endpoint of a channel, and a receiver is the receiving endpoint.
<pre>
let (tx, rx): (Sender<int>, Receiver<int>) = channel();

spawn(proc() {
let result = some_expensive_computation();
tx.send(result);
});

some_other_expensive_computation();
let result = rx.recv();
</pre>

== Design patterns ==

We will be using "Delegation Pattern" in our project. The Storage interface is used by web applications to access the Web Storage provided by the browser. However, the actual data is stored somewhere else(Database/FileSystem/Memory). So, it makes sense to create another class which will maintain the actual stored data. The Storage class can then delegate the task of storing/retrieving data to this class. We will create a class "WebStorageTask" for this purpose.

== UML diagrams (Eg use case diagram, class diagrams) ==

[[File:Flow_Chart_Storage.png]][[File:Use_Case_Storage.jpg|right]]

== Proposed Test Cases ==

To test the session storage in servo, we will be implementing the storage tasks. Some of the test cases for reference are:
* Clear session storage
* Set items in sessions storage
* Get stored items from session storage
* Check the number of items storage in session storage
* On removing the item from storage, it should be inaccessible
* Check if out of range indexes give error
* Access for out of range arguments as keys should return null
* Get an error on exceeding the limit of session storage

You can find the detailed list of test cases at [https://github.com/servo/web-platform-tests/tree/servo/webstorage Webstorage Tests]

== Further Readings ==

Learning Rust by Examples: http://rustbyexample.com/ 
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ 

== References ==
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T22:25:43Z

Ravnee: /* Project Description */

=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="3" align="center" | Expertiza instance links
|-
| Refactored Instance
| http://152.1.13.181:3000
| rowspan="2" align="center" | '''username= "user480" password= "password"'''
|-
| 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 style="background:#F0F0FF"> extractPersonalAchievements </code>). Seperate out method which will rank individual personal achievements.

3. Refactor <code style="background:#F0F0FF"> 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 style="background:#F0F0FF"> getParticipantEntriesInAssignmentList </code> method. Its very complex <code style="background:#F0F0FF">(Complexity=142)</code>.

6. Refactor <code style="background:#F0F0FF"> 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:2%;"|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 style="background:#F0F0FF"> 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 style="background:#F0F0FF"> Leaderboard.rb </code>, <code style="background:#F0F0FF"> Leaderboard_helper.rb </code>, <code style="background:#F0F0FF"> 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:2%;"|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 style="background:#F0F0FF"> addScoreToResultantHash </code>. As mentioned earlier, this is called internally by <code style="background:#F0F0FF"> 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 style="background:#F0F0FF"> 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.

'''Note for testing :''' It is recommended that in order 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. 
[[#TestingLinks|'''Expertiza Test instances links''']]

{| 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 style="background:#F0F0FF"> 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]]
|}

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%. Following is the overall improvement report by Code Climate.

[[File:CodeClimate_codecomplexity.png|center|frame]]

== 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
| Optimized the SQL query in leaderboard_helper.rb to replace multiple database calls.
|-
| users
| 25
| 25
| No Change
|-
| participants
| 111
| 3
| All the participants associated with computed assignment list are calculated in a single database call and cached in memory rather than calling repetitively within loop.
|-
| assignments
| 16
| 5
| Database calls to ''Assignments'' table was reduced as result of removing it from multiple loops. Supporting data structure and caching enabled to achieve this reduction.
|-
| assignment_questionnaires
| 11
| 0
| Upon careful code investigation, we felt there is no need of any database calls to assignment_questionnaires table. This contains mapping of assignment id and questionnaire id.
|-
| questionnaires
| 311
| 0
| Leaderboard reads the scores from ''ScoreCache'' table, which has ''revieweeId'' and a response object_type (''ReviewResponseMap'', ''AuthorFeedbackResponseMap'', etc.). Refactored code reuses the association of ''response object_type'' to the ''questionnaire_type'' and reduces the usage to 0. this is the most significant reduction in database calls.
|-
| score_caches
| 22
| 1
| ScoreCache table has a field - ''revieweeId'' which can be either ''participantId'' or ''teamId''. All repetitive database calls was reduced to a single call by combining target participantId and teamId as a list of ''revieweeId''.
|-
| teams
| 11
| 2
| Teams table was repetitively called within a loop to retrieve participation in a set of assignments. It was pulled out of the loop and modified to get the same result for all the teams for a larger set of assignments.
|-
| teams_users
| 52
| 52
| No change
|-
| leaderboards
| 9
| 5
| Leaderboards table was called multiple times to retrieve the Label for scores of corresponding questionnaire type. e.g. ''"ReviewQuestionnaire" - "Submitted Work"''. It was reduced to fetch all such mapping and cached.
|-
| 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=
Based on use case and requirement, we can implement a metric to calculate final scores based on weights of an assignment or a questionnaire type. However, it solely depends on the the requirement whether such logic should be implemented in the Leaderboard model or the Score computation model. The team recommends that such manipulation and calculation of scores should not be part of Leaderboard model. Leaderboard model should focus on determining the eligible participants and compute the final leaderboard list.

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T22:25:12Z

Ravnee: /* Code 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="3" align="center" | Expertiza instance links
|-
| Refactored Instance
| http://152.1.13.181:3000
| rowspan="2" align="center" | '''username= "user480" password= "password"'''
|-
| 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 style="background:#F0F0FF"> extractPersonalAchievements </code>). Seperate out method which will rank individual personal achievements.

3. Refactor <code style="background:#F0F0FF"> 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 style="background:#F0F0FF"> getParticipantEntriesInAssignmentList </code> method. Its very complex <code>(Complexity=142)</code>.

6. Refactor <code style="background:#F0F0FF"> 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:2%;"|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 style="background:#F0F0FF"> 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 style="background:#F0F0FF"> Leaderboard.rb </code>, <code style="background:#F0F0FF"> Leaderboard_helper.rb </code>, <code style="background:#F0F0FF"> 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:2%;"|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 style="background:#F0F0FF"> addScoreToResultantHash </code>. As mentioned earlier, this is called internally by <code style="background:#F0F0FF"> 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 style="background:#F0F0FF"> 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.

'''Note for testing :''' It is recommended that in order 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. 
[[#TestingLinks|'''Expertiza Test instances links''']]

{| 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 style="background:#F0F0FF"> 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]]
|}

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%. Following is the overall improvement report by Code Climate.

[[File:CodeClimate_codecomplexity.png|center|frame]]

== 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
| Optimized the SQL query in leaderboard_helper.rb to replace multiple database calls.
|-
| users
| 25
| 25
| No Change
|-
| participants
| 111
| 3
| All the participants associated with computed assignment list are calculated in a single database call and cached in memory rather than calling repetitively within loop.
|-
| assignments
| 16
| 5
| Database calls to ''Assignments'' table was reduced as result of removing it from multiple loops. Supporting data structure and caching enabled to achieve this reduction.
|-
| assignment_questionnaires
| 11
| 0
| Upon careful code investigation, we felt there is no need of any database calls to assignment_questionnaires table. This contains mapping of assignment id and questionnaire id.
|-
| questionnaires
| 311
| 0
| Leaderboard reads the scores from ''ScoreCache'' table, which has ''revieweeId'' and a response object_type (''ReviewResponseMap'', ''AuthorFeedbackResponseMap'', etc.). Refactored code reuses the association of ''response object_type'' to the ''questionnaire_type'' and reduces the usage to 0. this is the most significant reduction in database calls.
|-
| score_caches
| 22
| 1
| ScoreCache table has a field - ''revieweeId'' which can be either ''participantId'' or ''teamId''. All repetitive database calls was reduced to a single call by combining target participantId and teamId as a list of ''revieweeId''.
|-
| teams
| 11
| 2
| Teams table was repetitively called within a loop to retrieve participation in a set of assignments. It was pulled out of the loop and modified to get the same result for all the teams for a larger set of assignments.
|-
| teams_users
| 52
| 52
| No change
|-
| leaderboards
| 9
| 5
| Leaderboards table was called multiple times to retrieve the Label for scores of corresponding questionnaire type. e.g. ''"ReviewQuestionnaire" - "Submitted Work"''. It was reduced to fetch all such mapping and cached.
|-
| 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=
Based on use case and requirement, we can implement a metric to calculate final scores based on weights of an assignment or a questionnaire type. However, it solely depends on the the requirement whether such logic should be implemented in the Leaderboard model or the Score computation model. The team recommends that such manipulation and calculation of scores should not be part of Leaderboard model. Leaderboard model should focus on determining the eligible participants and compute the final leaderboard list.

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T22:24:46Z

Ravnee: /* Changes in Model */

=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="3" align="center" | Expertiza instance links
|-
| Refactored Instance
| http://152.1.13.181:3000
| rowspan="2" align="center" | '''username= "user480" password= "password"'''
|-
| 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 style="background:#F0F0FF"> extractPersonalAchievements </code>). Seperate out method which will rank individual personal achievements.

3. Refactor <code style="background:#F0F0FF"> 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 style="background:#F0F0FF"> getParticipantEntriesInAssignmentList </code> method. Its very complex <code>(Complexity=142)</code>.

6. Refactor <code style="background:#F0F0FF"> 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:2%;"|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 style="background:#F0F0FF"> 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 style="background:#F0F0FF"> Leaderboard.rb </code>, <code style="background:#F0F0FF"> Leaderboard_helper.rb </code>, <code style="background:#F0F0FF"> 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:2%;"|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 style="background:#F0F0FF"> addScoreToResultantHash </code>. As mentioned earlier, this is called internally by <code style="background:#F0F0FF"> 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 style="background:#F0F0FF"> 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.

'''Note for testing :''' It is recommended that in order 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. 
[[#TestingLinks|'''Expertiza Test instances links''']]

{| 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]]
|}

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%. Following is the overall improvement report by Code Climate.

[[File:CodeClimate_codecomplexity.png|center|frame]]

== 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
| Optimized the SQL query in leaderboard_helper.rb to replace multiple database calls.
|-
| users
| 25
| 25
| No Change
|-
| participants
| 111
| 3
| All the participants associated with computed assignment list are calculated in a single database call and cached in memory rather than calling repetitively within loop.
|-
| assignments
| 16
| 5
| Database calls to ''Assignments'' table was reduced as result of removing it from multiple loops. Supporting data structure and caching enabled to achieve this reduction.
|-
| assignment_questionnaires
| 11
| 0
| Upon careful code investigation, we felt there is no need of any database calls to assignment_questionnaires table. This contains mapping of assignment id and questionnaire id.
|-
| questionnaires
| 311
| 0
| Leaderboard reads the scores from ''ScoreCache'' table, which has ''revieweeId'' and a response object_type (''ReviewResponseMap'', ''AuthorFeedbackResponseMap'', etc.). Refactored code reuses the association of ''response object_type'' to the ''questionnaire_type'' and reduces the usage to 0. this is the most significant reduction in database calls.
|-
| score_caches
| 22
| 1
| ScoreCache table has a field - ''revieweeId'' which can be either ''participantId'' or ''teamId''. All repetitive database calls was reduced to a single call by combining target participantId and teamId as a list of ''revieweeId''.
|-
| teams
| 11
| 2
| Teams table was repetitively called within a loop to retrieve participation in a set of assignments. It was pulled out of the loop and modified to get the same result for all the teams for a larger set of assignments.
|-
| teams_users
| 52
| 52
| No change
|-
| leaderboards
| 9
| 5
| Leaderboards table was called multiple times to retrieve the Label for scores of corresponding questionnaire type. e.g. ''"ReviewQuestionnaire" - "Submitted Work"''. It was reduced to fetch all such mapping and cached.
|-
| 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=
Based on use case and requirement, we can implement a metric to calculate final scores based on weights of an assignment or a questionnaire type. However, it solely depends on the the requirement whether such logic should be implemented in the Leaderboard model or the Score computation model. The team recommends that such manipulation and calculation of scores should not be part of Leaderboard model. Leaderboard model should focus on determining the eligible participants and compute the final leaderboard list.

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T22:24:05Z

Ravnee: /* Existing Functionality */

=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="3" align="center" | Expertiza instance links
|-
| Refactored Instance
| http://152.1.13.181:3000
| rowspan="2" align="center" | '''username= "user480" password= "password"'''
|-
| 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 style="background:#F0F0FF"> extractPersonalAchievements </code>). Seperate out method which will rank individual personal achievements.

3. Refactor <code style="background:#F0F0FF"> 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 style="background:#F0F0FF"> getParticipantEntriesInAssignmentList </code> method. Its very complex <code>(Complexity=142)</code>.

6. Refactor <code style="background:#F0F0FF"> 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:2%;"|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 style="background:#F0F0FF"> 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 style="background:#F0F0FF"> Leaderboard.rb </code>, <code style="background:#F0F0FF"> Leaderboard_helper.rb </code>, <code style="background:#F0F0FF"> 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:2%;"|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.

'''Note for testing :''' It is recommended that in order 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. 
[[#TestingLinks|'''Expertiza Test instances links''']]

{| 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]]
|}

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%. Following is the overall improvement report by Code Climate.

[[File:CodeClimate_codecomplexity.png|center|frame]]

== 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
| Optimized the SQL query in leaderboard_helper.rb to replace multiple database calls.
|-
| users
| 25
| 25
| No Change
|-
| participants
| 111
| 3
| All the participants associated with computed assignment list are calculated in a single database call and cached in memory rather than calling repetitively within loop.
|-
| assignments
| 16
| 5
| Database calls to ''Assignments'' table was reduced as result of removing it from multiple loops. Supporting data structure and caching enabled to achieve this reduction.
|-
| assignment_questionnaires
| 11
| 0
| Upon careful code investigation, we felt there is no need of any database calls to assignment_questionnaires table. This contains mapping of assignment id and questionnaire id.
|-
| questionnaires
| 311
| 0
| Leaderboard reads the scores from ''ScoreCache'' table, which has ''revieweeId'' and a response object_type (''ReviewResponseMap'', ''AuthorFeedbackResponseMap'', etc.). Refactored code reuses the association of ''response object_type'' to the ''questionnaire_type'' and reduces the usage to 0. this is the most significant reduction in database calls.
|-
| score_caches
| 22
| 1
| ScoreCache table has a field - ''revieweeId'' which can be either ''participantId'' or ''teamId''. All repetitive database calls was reduced to a single call by combining target participantId and teamId as a list of ''revieweeId''.
|-
| teams
| 11
| 2
| Teams table was repetitively called within a loop to retrieve participation in a set of assignments. It was pulled out of the loop and modified to get the same result for all the teams for a larger set of assignments.
|-
| teams_users
| 52
| 52
| No change
|-
| leaderboards
| 9
| 5
| Leaderboards table was called multiple times to retrieve the Label for scores of corresponding questionnaire type. e.g. ''"ReviewQuestionnaire" - "Submitted Work"''. It was reduced to fetch all such mapping and cached.
|-
| 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=
Based on use case and requirement, we can implement a metric to calculate final scores based on weights of an assignment or a questionnaire type. However, it solely depends on the the requirement whether such logic should be implemented in the Leaderboard model or the Score computation model. The team recommends that such manipulation and calculation of scores should not be part of Leaderboard model. Leaderboard model should focus on determining the eligible participants and compute the final leaderboard list.

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T22:23:03Z

Ravnee: /* Existing Functionality */

=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="3" align="center" | Expertiza instance links
|-
| Refactored Instance
| http://152.1.13.181:3000
| rowspan="2" align="center" | '''username= "user480" password= "password"'''
|-
| 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 style="background:#F0F0FF"> extractPersonalAchievements </code>). Seperate out method which will rank individual personal achievements.

3. Refactor <code style="background:#F0F0FF"> 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 style="background:#F0F0FF"> getParticipantEntriesInAssignmentList </code> method. Its very complex <code>(Complexity=142)</code>.

6. Refactor <code style="background:#F0F0FF"> 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:2%;"|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 style="background:F0F0FF"> 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 style="background:F0F0FF"> Leaderboard.rb </code>, <code style="background:F0F0FF"> Leaderboard_helper.rb </code>, <code style="background:F0F0FF"> 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:2%;"|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.

'''Note for testing :''' It is recommended that in order 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. 
[[#TestingLinks|'''Expertiza Test instances links''']]

{| 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]]
|}

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%. Following is the overall improvement report by Code Climate.

[[File:CodeClimate_codecomplexity.png|center|frame]]

== 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
| Optimized the SQL query in leaderboard_helper.rb to replace multiple database calls.
|-
| users
| 25
| 25
| No Change
|-
| participants
| 111
| 3
| All the participants associated with computed assignment list are calculated in a single database call and cached in memory rather than calling repetitively within loop.
|-
| assignments
| 16
| 5
| Database calls to ''Assignments'' table was reduced as result of removing it from multiple loops. Supporting data structure and caching enabled to achieve this reduction.
|-
| assignment_questionnaires
| 11
| 0
| Upon careful code investigation, we felt there is no need of any database calls to assignment_questionnaires table. This contains mapping of assignment id and questionnaire id.
|-
| questionnaires
| 311
| 0
| Leaderboard reads the scores from ''ScoreCache'' table, which has ''revieweeId'' and a response object_type (''ReviewResponseMap'', ''AuthorFeedbackResponseMap'', etc.). Refactored code reuses the association of ''response object_type'' to the ''questionnaire_type'' and reduces the usage to 0. this is the most significant reduction in database calls.
|-
| score_caches
| 22
| 1
| ScoreCache table has a field - ''revieweeId'' which can be either ''participantId'' or ''teamId''. All repetitive database calls was reduced to a single call by combining target participantId and teamId as a list of ''revieweeId''.
|-
| teams
| 11
| 2
| Teams table was repetitively called within a loop to retrieve participation in a set of assignments. It was pulled out of the loop and modified to get the same result for all the teams for a larger set of assignments.
|-
| teams_users
| 52
| 52
| No change
|-
| leaderboards
| 9
| 5
| Leaderboards table was called multiple times to retrieve the Label for scores of corresponding questionnaire type. e.g. ''"ReviewQuestionnaire" - "Submitted Work"''. It was reduced to fetch all such mapping and cached.
|-
| 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=
Based on use case and requirement, we can implement a metric to calculate final scores based on weights of an assignment or a questionnaire type. However, it solely depends on the the requirement whether such logic should be implemented in the Leaderboard model or the Score computation model. The team recommends that such manipulation and calculation of scores should not be part of Leaderboard model. Leaderboard model should focus on determining the eligible participants and compute the final leaderboard list.

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T22:20:57Z

Ravnee: /* Existing Functionality */

=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="3" align="center" | Expertiza instance links
|-
| Refactored Instance
| http://152.1.13.181:3000
| rowspan="2" align="center" | '''username= "user480" password= "password"'''
|-
| 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 style="background:#F0F0FF"> extractPersonalAchievements </code>). Seperate out method which will rank individual personal achievements.

3. Refactor <code style="background:#F0F0FF"> 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 style="background:#F0F0FF"> getParticipantEntriesInAssignmentList </code> method. Its very complex <code>(Complexity=142)</code>.

6. Refactor <code style="background:#F0F0FF"> 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:2%;"|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 F0F0FF> 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 F0F0FF> Leaderboard.rb </code>, <code F0F0FF> Leaderboard_helper.rb </code>, <code F0F0FF> 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:2%;"|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.

'''Note for testing :''' It is recommended that in order 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. 
[[#TestingLinks|'''Expertiza Test instances links''']]

{| 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]]
|}

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%. Following is the overall improvement report by Code Climate.

[[File:CodeClimate_codecomplexity.png|center|frame]]

== 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
| Optimized the SQL query in leaderboard_helper.rb to replace multiple database calls.
|-
| users
| 25
| 25
| No Change
|-
| participants
| 111
| 3
| All the participants associated with computed assignment list are calculated in a single database call and cached in memory rather than calling repetitively within loop.
|-
| assignments
| 16
| 5
| Database calls to ''Assignments'' table was reduced as result of removing it from multiple loops. Supporting data structure and caching enabled to achieve this reduction.
|-
| assignment_questionnaires
| 11
| 0
| Upon careful code investigation, we felt there is no need of any database calls to assignment_questionnaires table. This contains mapping of assignment id and questionnaire id.
|-
| questionnaires
| 311
| 0
| Leaderboard reads the scores from ''ScoreCache'' table, which has ''revieweeId'' and a response object_type (''ReviewResponseMap'', ''AuthorFeedbackResponseMap'', etc.). Refactored code reuses the association of ''response object_type'' to the ''questionnaire_type'' and reduces the usage to 0. this is the most significant reduction in database calls.
|-
| score_caches
| 22
| 1
| ScoreCache table has a field - ''revieweeId'' which can be either ''participantId'' or ''teamId''. All repetitive database calls was reduced to a single call by combining target participantId and teamId as a list of ''revieweeId''.
|-
| teams
| 11
| 2
| Teams table was repetitively called within a loop to retrieve participation in a set of assignments. It was pulled out of the loop and modified to get the same result for all the teams for a larger set of assignments.
|-
| teams_users
| 52
| 52
| No change
|-
| leaderboards
| 9
| 5
| Leaderboards table was called multiple times to retrieve the Label for scores of corresponding questionnaire type. e.g. ''"ReviewQuestionnaire" - "Submitted Work"''. It was reduced to fetch all such mapping and cached.
|-
| 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=
Based on use case and requirement, we can implement a metric to calculate final scores based on weights of an assignment or a questionnaire type. However, it solely depends on the the requirement whether such logic should be implemented in the Leaderboard model or the Score computation model. The team recommends that such manipulation and calculation of scores should not be part of Leaderboard model. Leaderboard model should focus on determining the eligible participants and compute the final leaderboard list.

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T22:20:19Z

Ravnee: /* Project Description */

=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="3" align="center" | Expertiza instance links
|-
| Refactored Instance
| http://152.1.13.181:3000
| rowspan="2" align="center" | '''username= "user480" password= "password"'''
|-
| 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 style="background:#F0F0FF"> extractPersonalAchievements </code>). Seperate out method which will rank individual personal achievements.

3. Refactor <code style="background:#F0F0FF"> 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 style="background:#F0F0FF"> getParticipantEntriesInAssignmentList </code> method. Its very complex <code>(Complexity=142)</code>.

6. Refactor <code style="background:#F0F0FF"> 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:2%;"|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:2%;"|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.

'''Note for testing :''' It is recommended that in order 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. 
[[#TestingLinks|'''Expertiza Test instances links''']]

{| 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]]
|}

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%. Following is the overall improvement report by Code Climate.

[[File:CodeClimate_codecomplexity.png|center|frame]]

== 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
| Optimized the SQL query in leaderboard_helper.rb to replace multiple database calls.
|-
| users
| 25
| 25
| No Change
|-
| participants
| 111
| 3
| All the participants associated with computed assignment list are calculated in a single database call and cached in memory rather than calling repetitively within loop.
|-
| assignments
| 16
| 5
| Database calls to ''Assignments'' table was reduced as result of removing it from multiple loops. Supporting data structure and caching enabled to achieve this reduction.
|-
| assignment_questionnaires
| 11
| 0
| Upon careful code investigation, we felt there is no need of any database calls to assignment_questionnaires table. This contains mapping of assignment id and questionnaire id.
|-
| questionnaires
| 311
| 0
| Leaderboard reads the scores from ''ScoreCache'' table, which has ''revieweeId'' and a response object_type (''ReviewResponseMap'', ''AuthorFeedbackResponseMap'', etc.). Refactored code reuses the association of ''response object_type'' to the ''questionnaire_type'' and reduces the usage to 0. this is the most significant reduction in database calls.
|-
| score_caches
| 22
| 1
| ScoreCache table has a field - ''revieweeId'' which can be either ''participantId'' or ''teamId''. All repetitive database calls was reduced to a single call by combining target participantId and teamId as a list of ''revieweeId''.
|-
| teams
| 11
| 2
| Teams table was repetitively called within a loop to retrieve participation in a set of assignments. It was pulled out of the loop and modified to get the same result for all the teams for a larger set of assignments.
|-
| teams_users
| 52
| 52
| No change
|-
| leaderboards
| 9
| 5
| Leaderboards table was called multiple times to retrieve the Label for scores of corresponding questionnaire type. e.g. ''"ReviewQuestionnaire" - "Submitted Work"''. It was reduced to fetch all such mapping and cached.
|-
| 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=
Based on use case and requirement, we can implement a metric to calculate final scores based on weights of an assignment or a questionnaire type. However, it solely depends on the the requirement whether such logic should be implemented in the Leaderboard model or the Score computation model. The team recommends that such manipulation and calculation of scores should not be part of Leaderboard model. Leaderboard model should focus on determining the eligible participants and compute the final leaderboard list.

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T22:15:40Z

Ravnee: /* Project Description */

=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="3" align="center" | Expertiza instance links
|-
| Refactored Instance
| http://152.1.13.181:3000
| rowspan="2" align="center" | '''username= "user480" password= "password"'''
|-
| 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 style="background:#E6E6FA"> extractPersonalAchievements </code>). Seperate out method which will rank individual personal achievements.

3. Refactor <code style="background:#E6E6FA"> 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 style="background:#E6E6FA"> getParticipantEntriesInAssignmentList </code> method. Its very complex <code>(Complexity=142)</code>.

6. Refactor <code style="background:#E6E6FA"> 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:2%;"|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:2%;"|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.

'''Note for testing :''' It is recommended that in order 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. 
[[#TestingLinks|'''Expertiza Test instances links''']]

{| 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]]
|}

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%. Following is the overall improvement report by Code Climate.

[[File:CodeClimate_codecomplexity.png|center|frame]]

== 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
| Optimized the SQL query in leaderboard_helper.rb to replace multiple database calls.
|-
| users
| 25
| 25
| No Change
|-
| participants
| 111
| 3
| All the participants associated with computed assignment list are calculated in a single database call and cached in memory rather than calling repetitively within loop.
|-
| assignments
| 16
| 5
| Database calls to ''Assignments'' table was reduced as result of removing it from multiple loops. Supporting data structure and caching enabled to achieve this reduction.
|-
| assignment_questionnaires
| 11
| 0
| Upon careful code investigation, we felt there is no need of any database calls to assignment_questionnaires table. This contains mapping of assignment id and questionnaire id.
|-
| questionnaires
| 311
| 0
| Leaderboard reads the scores from ''ScoreCache'' table, which has ''revieweeId'' and a response object_type (''ReviewResponseMap'', ''AuthorFeedbackResponseMap'', etc.). Refactored code reuses the association of ''response object_type'' to the ''questionnaire_type'' and reduces the usage to 0. this is the most significant reduction in database calls.
|-
| score_caches
| 22
| 1
| ScoreCache table has a field - ''revieweeId'' which can be either ''participantId'' or ''teamId''. All repetitive database calls was reduced to a single call by combining target participantId and teamId as a list of ''revieweeId''.
|-
| teams
| 11
| 2
| Teams table was repetitively called within a loop to retrieve participation in a set of assignments. It was pulled out of the loop and modified to get the same result for all the teams for a larger set of assignments.
|-
| teams_users
| 52
| 52
| No change
|-
| leaderboards
| 9
| 5
| Leaderboards table was called multiple times to retrieve the Label for scores of corresponding questionnaire type. e.g. ''"ReviewQuestionnaire" - "Submitted Work"''. It was reduced to fetch all such mapping and cached.
|-
| 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=
Based on use case and requirement, we can implement a metric to calculate final scores based on weights of an assignment or a questionnaire type. However, it solely depends on the the requirement whether such logic should be implemented in the Leaderboard model or the Score computation model. The team recommends that such manipulation and calculation of scores should not be part of Leaderboard model. Leaderboard model should focus on determining the eligible participants and compute the final leaderboard list.

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T22:14:37Z

Ravnee: /* Project Description */

=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="3" align="center" | Expertiza instance links
|-
| Refactored Instance
| http://152.1.13.181:3000
| rowspan="2" align="center" | '''username= "user480" password= "password"'''
|-
| 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 style="background:#F0F8FF"> extractPersonalAchievements </code>). Seperate out method which will rank individual personal achievements.

3. Refactor <code style="background:#F0F8FF"> 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 style="background:#F0F8FF"> getParticipantEntriesInAssignmentList </code> method. Its very complex <code>(Complexity=142)</code>.

6. Refactor <code style="background:#F0F8FF"> 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:2%;"|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:2%;"|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.

'''Note for testing :''' It is recommended that in order 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. 
[[#TestingLinks|'''Expertiza Test instances links''']]

{| 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]]
|}

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%. Following is the overall improvement report by Code Climate.

[[File:CodeClimate_codecomplexity.png|center|frame]]

== 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
| Optimized the SQL query in leaderboard_helper.rb to replace multiple database calls.
|-
| users
| 25
| 25
| No Change
|-
| participants
| 111
| 3
| All the participants associated with computed assignment list are calculated in a single database call and cached in memory rather than calling repetitively within loop.
|-
| assignments
| 16
| 5
| Database calls to ''Assignments'' table was reduced as result of removing it from multiple loops. Supporting data structure and caching enabled to achieve this reduction.
|-
| assignment_questionnaires
| 11
| 0
| Upon careful code investigation, we felt there is no need of any database calls to assignment_questionnaires table. This contains mapping of assignment id and questionnaire id.
|-
| questionnaires
| 311
| 0
| Leaderboard reads the scores from ''ScoreCache'' table, which has ''revieweeId'' and a response object_type (''ReviewResponseMap'', ''AuthorFeedbackResponseMap'', etc.). Refactored code reuses the association of ''response object_type'' to the ''questionnaire_type'' and reduces the usage to 0. this is the most significant reduction in database calls.
|-
| score_caches
| 22
| 1
| ScoreCache table has a field - ''revieweeId'' which can be either ''participantId'' or ''teamId''. All repetitive database calls was reduced to a single call by combining target participantId and teamId as a list of ''revieweeId''.
|-
| teams
| 11
| 2
| Teams table was repetitively called within a loop to retrieve participation in a set of assignments. It was pulled out of the loop and modified to get the same result for all the teams for a larger set of assignments.
|-
| teams_users
| 52
| 52
| No change
|-
| leaderboards
| 9
| 5
| Leaderboards table was called multiple times to retrieve the Label for scores of corresponding questionnaire type. e.g. ''"ReviewQuestionnaire" - "Submitted Work"''. It was reduced to fetch all such mapping and cached.
|-
| 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=
Based on use case and requirement, we can implement a metric to calculate final scores based on weights of an assignment or a questionnaire type. However, it solely depends on the the requirement whether such logic should be implemented in the Leaderboard model or the Score computation model. The team recommends that such manipulation and calculation of scores should not be part of Leaderboard model. Leaderboard model should focus on determining the eligible participants and compute the final leaderboard list.

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T22:14:23Z

Ravnee: /* Project Description */

=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="3" align="center" | Expertiza instance links
|-
| Refactored Instance
| http://152.1.13.181:3000
| rowspan="2" align="center" | '''username= "user480" password= "password"'''
|-
| 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 style="background:#F0F8FF"> extractPersonalAchievements </code>). Seperate out method which will rank individual personal achievements.

3. Refactor <code style="background:#F0F8FF"> 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 style="background:#F0F8FF"> getParticipantEntriesInAssignmentList </code> method. Its very complex <code>(Complexity=142)</code>.

6. Refactor <code style=background:#F0F8FF"> 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:2%;"|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:2%;"|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.

'''Note for testing :''' It is recommended that in order 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. 
[[#TestingLinks|'''Expertiza Test instances links''']]

{| 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]]
|}

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%. Following is the overall improvement report by Code Climate.

[[File:CodeClimate_codecomplexity.png|center|frame]]

== 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
| Optimized the SQL query in leaderboard_helper.rb to replace multiple database calls.
|-
| users
| 25
| 25
| No Change
|-
| participants
| 111
| 3
| All the participants associated with computed assignment list are calculated in a single database call and cached in memory rather than calling repetitively within loop.
|-
| assignments
| 16
| 5
| Database calls to ''Assignments'' table was reduced as result of removing it from multiple loops. Supporting data structure and caching enabled to achieve this reduction.
|-
| assignment_questionnaires
| 11
| 0
| Upon careful code investigation, we felt there is no need of any database calls to assignment_questionnaires table. This contains mapping of assignment id and questionnaire id.
|-
| questionnaires
| 311
| 0
| Leaderboard reads the scores from ''ScoreCache'' table, which has ''revieweeId'' and a response object_type (''ReviewResponseMap'', ''AuthorFeedbackResponseMap'', etc.). Refactored code reuses the association of ''response object_type'' to the ''questionnaire_type'' and reduces the usage to 0. this is the most significant reduction in database calls.
|-
| score_caches
| 22
| 1
| ScoreCache table has a field - ''revieweeId'' which can be either ''participantId'' or ''teamId''. All repetitive database calls was reduced to a single call by combining target participantId and teamId as a list of ''revieweeId''.
|-
| teams
| 11
| 2
| Teams table was repetitively called within a loop to retrieve participation in a set of assignments. It was pulled out of the loop and modified to get the same result for all the teams for a larger set of assignments.
|-
| teams_users
| 52
| 52
| No change
|-
| leaderboards
| 9
| 5
| Leaderboards table was called multiple times to retrieve the Label for scores of corresponding questionnaire type. e.g. ''"ReviewQuestionnaire" - "Submitted Work"''. It was reduced to fetch all such mapping and cached.
|-
| 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=
Based on use case and requirement, we can implement a metric to calculate final scores based on weights of an assignment or a questionnaire type. However, it solely depends on the the requirement whether such logic should be implemented in the Leaderboard model or the Score computation model. The team recommends that such manipulation and calculation of scores should not be part of Leaderboard model. Leaderboard model should focus on determining the eligible participants and compute the final leaderboard list.

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T22:13:51Z

Ravnee: /* Project Description */

=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="3" align="center" | Expertiza instance links
|-
| Refactored Instance
| http://152.1.13.181:3000
| rowspan="2" align="center" | '''username= "user480" password= "password"'''
|-
| 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 style="background:#F0F8FF"> extractPersonalAchievements </code>). Seperate out method which will rank individual personal achievements.

3. Refactor <code "background:#F0F8FF"> 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 "background:#F0F8FF"> getParticipantEntriesInAssignmentList </code> method. Its very complex <code>(Complexity=142)</code>.

6. Refactor <code "background:#F0F8FF"> 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:2%;"|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:2%;"|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.

'''Note for testing :''' It is recommended that in order 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. 
[[#TestingLinks|'''Expertiza Test instances links''']]

{| 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]]
|}

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%. Following is the overall improvement report by Code Climate.

[[File:CodeClimate_codecomplexity.png|center|frame]]

== 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
| Optimized the SQL query in leaderboard_helper.rb to replace multiple database calls.
|-
| users
| 25
| 25
| No Change
|-
| participants
| 111
| 3
| All the participants associated with computed assignment list are calculated in a single database call and cached in memory rather than calling repetitively within loop.
|-
| assignments
| 16
| 5
| Database calls to ''Assignments'' table was reduced as result of removing it from multiple loops. Supporting data structure and caching enabled to achieve this reduction.
|-
| assignment_questionnaires
| 11
| 0
| Upon careful code investigation, we felt there is no need of any database calls to assignment_questionnaires table. This contains mapping of assignment id and questionnaire id.
|-
| questionnaires
| 311
| 0
| Leaderboard reads the scores from ''ScoreCache'' table, which has ''revieweeId'' and a response object_type (''ReviewResponseMap'', ''AuthorFeedbackResponseMap'', etc.). Refactored code reuses the association of ''response object_type'' to the ''questionnaire_type'' and reduces the usage to 0. this is the most significant reduction in database calls.
|-
| score_caches
| 22
| 1
| ScoreCache table has a field - ''revieweeId'' which can be either ''participantId'' or ''teamId''. All repetitive database calls was reduced to a single call by combining target participantId and teamId as a list of ''revieweeId''.
|-
| teams
| 11
| 2
| Teams table was repetitively called within a loop to retrieve participation in a set of assignments. It was pulled out of the loop and modified to get the same result for all the teams for a larger set of assignments.
|-
| teams_users
| 52
| 52
| No change
|-
| leaderboards
| 9
| 5
| Leaderboards table was called multiple times to retrieve the Label for scores of corresponding questionnaire type. e.g. ''"ReviewQuestionnaire" - "Submitted Work"''. It was reduced to fetch all such mapping and cached.
|-
| 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=
Based on use case and requirement, we can implement a metric to calculate final scores based on weights of an assignment or a questionnaire type. However, it solely depends on the the requirement whether such logic should be implemented in the Leaderboard model or the Score computation model. The team recommends that such manipulation and calculation of scores should not be part of Leaderboard model. Leaderboard model should focus on determining the eligible participants and compute the final leaderboard list.

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T22:03:46Z

Ravnee: /* Changes in Model */

=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="3" align="center" | Expertiza instance links
|-
| Refactored Instance
| http://152.1.13.181:3000
| rowspan="2" align="center" | '''username= "user480" password= "password"'''
|-
| 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:2%;"|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:2%;"|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.

'''Note for testing :''' It is recommended that in order 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. 
[[#TestingLinks|'''Expertiza Test instances links''']]

{| 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]]
|}

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%. Following is the overall improvement report by Code Climate.

[[File:CodeClimate_codecomplexity.png|center|frame]]

== 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
| Optimized the SQL query in leaderboard_helper.rb to replace multiple database calls.
|-
| users
| 25
| 25
| No Change
|-
| participants
| 111
| 3
| All the participants associated with computed Assignment list are calculated in a single database call and cached in memory rather than calling repetitively.
|-
| assignments
| 16
| 5
| Database calls to Assignments table was reduced as result of removing it from multiple loops. Supporting data structure and caching enabled to achieve this.
|-
| assignment_questionnaires
| 11
| 0
| Upon careful code investigation, we felt there is no need of any database calls to assignment_questionnaires table. This contains mapping of assignment id and questionnaire id.
|-
| questionnaires
| 311
| 0
| Leaderboard reads the scores from ScoreCache, which has revieweeId and a response object_type (''ReviewResponseMap'', ''AuthorFeedbackResponseMap'', etc.). Refactored code reuses the association of response object_type to the questionnaire_type and reduces the usage to 0.
|-
| 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=
Based on use case and requirement, we can implement a metric to calculate final scores based on weights of an assignment or a questionnaire type. However, it solely depends on the the requirement whether such logic should be implemented in the Leaderboard model or the Score computation model. The team recommends that such manipulation and calculation of scores should not be part of Leaderboard model. Leaderboard model should focus on determining the eligible participants and compute the final leaderboard list.

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T22:03:28Z

Ravnee: /* Existing Functionality */

=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="3" align="center" | Expertiza instance links
|-
| Refactored Instance
| http://152.1.13.181:3000
| rowspan="2" align="center" | '''username= "user480" password= "password"'''
|-
| 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:2%;"|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.

'''Note for testing :''' It is recommended that in order 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. 
[[#TestingLinks|'''Expertiza Test instances links''']]

{| 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]]
|}

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%. Following is the overall improvement report by Code Climate.

[[File:CodeClimate_codecomplexity.png|center|frame]]

== 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
| Optimized the SQL query in leaderboard_helper.rb to replace multiple database calls.
|-
| users
| 25
| 25
| No Change
|-
| participants
| 111
| 3
| All the participants associated with computed Assignment list are calculated in a single database call and cached in memory rather than calling repetitively.
|-
| assignments
| 16
| 5
| Database calls to Assignments table was reduced as result of removing it from multiple loops. Supporting data structure and caching enabled to achieve this.
|-
| assignment_questionnaires
| 11
| 0
| Upon careful code investigation, we felt there is no need of any database calls to assignment_questionnaires table. This contains mapping of assignment id and questionnaire id.
|-
| questionnaires
| 311
| 0
| Leaderboard reads the scores from ScoreCache, which has revieweeId and a response object_type (''ReviewResponseMap'', ''AuthorFeedbackResponseMap'', etc.). Refactored code reuses the association of response object_type to the questionnaire_type and reduces the usage to 0.
|-
| 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=
Based on use case and requirement, we can implement a metric to calculate final scores based on weights of an assignment or a questionnaire type. However, it solely depends on the the requirement whether such logic should be implemented in the Leaderboard model or the Score computation model. The team recommends that such manipulation and calculation of scores should not be part of Leaderboard model. Leaderboard model should focus on determining the eligible participants and compute the final leaderboard list.

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T21:14:11Z

Ravnee: /* Introduction */

=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="3" align="center" | Expertiza Links
|-
| Refactored Instance
| http://152.1.13.181:3000
| rowspan="2" align="center" | username= "user480" password= "password"
|-
| 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.

'''Note for testing :''' It is recommended that in order 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. 
[[#TestingLinks|'''Testing Links''']]

{| 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]]
|}

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%. Following is the overall improvement report by Code Climate.

[[File:CodeClimate_codecomplexity.png|center|frame]]

== 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
| Optimized the SQL query in leaderboard_helper.rb to replace multiple database calls.
|-
| users
| 25
| 25
| No Change
|-
| participants
| 111
| 3
| All the participants associated with computed Assignment list are calculated in a single database call and cached in memory rather than calling repetitively.
|-
| assignments
| 16
| 5
| Assignem
|-
| 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=
Based on use case and requirement, we can implement a metric to calculate final scores based on weights of an assignment or a questionnaire type. However, it solely depends on the the requirement whether such logic should be implemented in the Leaderboard model or the Score computation model. The team recommends that such manipulation and calculation of scores should not be part of Leaderboard model. Leaderboard model should focus on determining the eligible participants and compute the final leaderboard list.

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T21:13:36Z

Ravnee: /* Testing */

=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="3" align="center" | Expertiza Link
|-
| Refactored Instance
| http://152.1.13.181:3000
| rowspan="2" align="center" | username= "user480" password= "password"
|-
| 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.

'''Note for testing :''' It is recommended that in order 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. 
[[#TestingLinks|'''Testing Links''']]

{| 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]]
|}

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%. Following is the overall improvement report by Code Climate.

[[File:CodeClimate_codecomplexity.png|center|frame]]

== 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
| Optimized the SQL query in leaderboard_helper.rb to replace multiple database calls.
|-
| users
| 25
| 25
| No Change
|-
| participants
| 111
| 3
| All the participants associated with computed Assignment list are calculated in a single database call and cached in memory rather than calling repetitively.
|-
| assignments
| 16
| 5
| Assignem
|-
| 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=
Based on use case and requirement, we can implement a metric to calculate final scores based on weights of an assignment or a questionnaire type. However, it solely depends on the the requirement whether such logic should be implemented in the Leaderboard model or the Score computation model. The team recommends that such manipulation and calculation of scores should not be part of Leaderboard model. Leaderboard model should focus on determining the eligible participants and compute the final leaderboard list.

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T21:13:08Z

Ravnee: /* Testing */

=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="3" align="center" | Expertiza Link
|-
| Refactored Instance
| http://152.1.13.181:3000
| rowspan="2" align="center" | username= "user480" password= "password"
|-
| 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.

'''Note for testing :''' It is recommended that in order 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. 
[[#TestingLinks|Testing Links]]

{| 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]]
|}

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%. Following is the overall improvement report by Code Climate.

[[File:CodeClimate_codecomplexity.png|center|frame]]

== 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
| Optimized the SQL query in leaderboard_helper.rb to replace multiple database calls.
|-
| users
| 25
| 25
| No Change
|-
| participants
| 111
| 3
| All the participants associated with computed Assignment list are calculated in a single database call and cached in memory rather than calling repetitively.
|-
| assignments
| 16
| 5
| Assignem
|-
| 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=
Based on use case and requirement, we can implement a metric to calculate final scores based on weights of an assignment or a questionnaire type. However, it solely depends on the the requirement whether such logic should be implemented in the Leaderboard model or the Score computation model. The team recommends that such manipulation and calculation of scores should not be part of Leaderboard model. Leaderboard model should focus on determining the eligible participants and compute the final leaderboard list.

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T21:11:42Z

Ravnee: /* Testing */

=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="3" align="center" | Expertiza Link
|-
| Refactored Instance
| http://152.1.13.181:3000
| rowspan="2" align="center" | username= "user480" password= "password"
|-
| 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.

[[#TestingLinks|Testing Links]]

'''Note for testing :''' It is recommended that in order 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. Username/Password: user480/password'''

{| 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]]
|}

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%. Following is the overall improvement report by Code Climate.

[[File:CodeClimate_codecomplexity.png|center|frame]]

== 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
| Optimized the SQL query in leaderboard_helper.rb to replace multiple database calls.
|-
| users
| 25
| 25
| No Change
|-
| participants
| 111
| 3
| All the participants associated with computed Assignment list are calculated in a single database call and cached in memory rather than calling repetitively.
|-
| assignments
| 16
| 5
| Assignem
|-
| 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=
Based on use case and requirement, we can implement a metric to calculate final scores based on weights of an assignment or a questionnaire type. However, it solely depends on the the requirement whether such logic should be implemented in the Leaderboard model or the Score computation model. The team recommends that such manipulation and calculation of scores should not be part of Leaderboard model. Leaderboard model should focus on determining the eligible participants and compute the final leaderboard list.

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T21:10:58Z

Ravnee: /* Testing */

=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="3" align="center" | Expertiza Link
|-
| Refactored Instance
| http://152.1.13.181:3000
| rowspan="2" align="center" | username= "user480" password= "password"
|-
| 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.
[[#TestingLinks|Testing Links]]
'''Note for testing :''' It is recommended that in order 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. Username/Password: user480/password'''

{| 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]]
|}

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%. Following is the overall improvement report by Code Climate.

[[File:CodeClimate_codecomplexity.png|center|frame]]

== 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=
Based on use case and requirement, we can implement a metric to calculate final scores based on weights of an assignment or a questionnaire type. However, it solely depends on the the requirement whether such logic should be implemented in the Leaderboard model or the Score computation model. The team recommends that such manipulation and calculation of scores should not be part of Leaderboard model. Leaderboard model should focus on determining the eligible participants and compute the final leaderboard list.

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T21:04:58Z

Ravnee: /* Introduction */

=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="3" align="center" | Expertiza Link
|-
| Refactored Instance
| http://152.1.13.181:3000
| rowspan="2" align="center" | username= "user480" password= "password"
|-
| 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]]
|}

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%. Following is the overall improvement report by Code Climate.

[[File:CodeClimate_codecomplexity.png|center|frame]]

== 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=
Based on use case and requirement, we can implement a metric to calculate final scores based on weights of an assignment or a questionnaire type. However, it solely depends on the the requirement whether such logic should be implemented in the Leaderboard model or the Score computation model. The team recommends that such manipulation and calculation of scores should not be part of Leaderboard model. Leaderboard model should focus on determining the eligible participants and compute the final leaderboard list.

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T21:04:43Z

Ravnee: /* Introduction */

=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="3" align="center" | Expertiza Link
|-
| Refactored Instance
| http://152.1.13.181:3000
| rowspan="2" align="center" | username= "user480" password= "password"
|-
| 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]]
|}

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%. Following is the overall improvement report by Code Climate.

[[File:CodeClimate_codecomplexity.png|center|frame]]

== 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=
Based on use case and requirement, we can implement a metric to calculate final scores based on weights of an assignment or a questionnaire type. However, it solely depends on the the requirement whether such logic should be implemented in the Leaderboard model or the Score computation model. The team recommends that such manipulation and calculation of scores should not be part of Leaderboard model. Leaderboard model should focus on determining the eligible participants and compute the final leaderboard list.

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T21:01:06Z

Ravnee:

=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="3" align="center" | Expertiza Link
|-
| Refactored Instance
| http://152.1.13.181:3000
| rowspan="2" align="center" | username= "user480" password= "password"
|-
| 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]]
|}

The report shows that all the 3 methods to be refactored have improved code complexity by over 50%. Following is the overall improvement report by Code Climate.

[[File:CodeClimate_codecomplexity.png|center|frame]]

== 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.

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T20:51:36Z

Ravnee:

=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="3" align="center" | Expertiza Link
|-
| Refactored Instance
| http://152.1.13.181:3000
| rowspan="2" align="center" | username= "user480", password= "password"
|-
| 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.

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T20:50:37Z

Ravnee:

=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.

= References =
<references/>

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T20:34:12Z

Ravnee: /* Changes in Helper */

=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.

[[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]<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:32:30Z

Ravnee: /* Existing Functionality */

=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.

[[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]<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:27:54Z

Ravnee: /* Project Description */

=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 enhancement of 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.

[[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]<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:27:27Z

Ravnee: /* Changes In Model */

=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 (Complexity=142).

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 enhancement of 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.

[[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]<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:27:13Z

Ravnee: /* Changes In Helper (leaderboard_helper.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 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 (Complexity=142).

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 enhancement of 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.

[[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]<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:23:59Z

Ravnee: /* 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 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 (Complexity=142).

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 enhancement of 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 (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=

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.

[[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]<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:16:51Z

Ravnee: /* Introduction */

=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 (Complexity=142).

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 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=

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.

[[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]<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:16:18Z

Ravnee: /* Introduction */

=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, 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 (Complexity=142).

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 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=

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.

[[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]<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:02:50Z

Ravnee:

=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.

{| 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 (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=

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]<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-29T18:26:31Z

Ravnee:

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

'''<big>Expertiza - Refactoring LeaderBoard model</big>'''

Our project is to refactor the code in the "Leaderboard" functionality of the web application Expertiza. 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 '''''
| <code> getIndependantAssignments </code>
| Reduced the number of database calls within loop.
| Less complexity and runs faster.
|-
|''''' 2 '''''
| <code> getParticipantEntriesInCourses </code>
| Reduced the number of database calls within loop.
| Less complexity and runs faster.
|-
|''''' 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| ]]

|}

=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:16:17Z

Ravnee:

[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. 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 '''''
| <code> getIndependantAssignments </code>
| Reduced the number of database calls within loop.
| Less complexity and runs faster.
|-
|''''' 2 '''''
| <code> getParticipantEntriesInCourses </code>
| Reduced the number of database calls within loop.
| Less complexity and runs faster.
|-
|''''' 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=
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 except for order in which it is displayed.

{| 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| ]]

|}

=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=
[http://expertiza.ncsu.edu/ Expertiza]

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T18:12:59Z

Ravnee: /* 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 '''''
| <code> getIndependantAssignments </code>
| Reduced the number of database calls within loop.
| Less complexity and runs faster.
|-
|''''' 2 '''''
| <code> getParticipantEntriesInCourses </code>
| Reduced the number of database calls within loop.
| Less complexity and runs faster.
|-
|''''' 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=
On VCL session there are 2 instances running. On <code> port 3001 </code> the non refactored 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 except for some cosmetic changes and order in which it is displayed.

{| 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 <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=
[http://expertiza.ncsu.edu/ Expertiza]

CSC/ECE 517 Fall 2014/OSS E1467 rsv

2014-10-29T18:12:05Z

Ravnee: /* 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 <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 '''''
| <code> getIndependantAssignments </code>
| Reduced the number of database calls within loop.
| Less complexity and runs faster.
|-
|''''' 2 '''''
| <code> getParticipantEntriesInCourses </code>
| Reduced the number of database calls within loop.
| Less complexity and runs faster.
|-
|''''' 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=
On VCL session there are 2 instances running. On <code> port 3001 </code> the non refactored 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 except for some cosmetic changes and order in which it is displayed.

{| 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:10:35Z

Ravnee: /* 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 '''''
| <code> getIndependantAssignments </code>
| Reduced the number of database calls within loop.
| Less complexity and runs faster.
|-
|''''' 2 '''''
| <code> getParticipantEntriesInCourses </code>
| Reduced the number of database calls within loop.
| Less complexity and runs faster.
|-
|''''' 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=
On VCL session there are 2 instances running. On port 3001 the non refactored instance is setup and on port 3000 the refactored instance is setup.
In below images we have shown that the output after refactoring is same except for some cosmetic changes and order in which it is displayed.

{| 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:09:23Z

Ravnee: /* 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 '''''
| <code> getIndependantAssignments </code>
| Reduced the number of database calls within loop.
| Less complexity and runs faster.
|-
|''''' 2 '''''
| <code> getParticipantEntriesInCourses </code>
| Reduced the number of database calls within loop.
| Less complexity and runs faster.
|-
|''''' 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 '''''
| 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-29T17:46:29Z

Ravnee: /* 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: <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=
[[File:Refactored_Leaderboard_file.jpg|frame|left| View of Refactored Leaderboard]]
[[File:Non_Refactored_Leaderboard_file.jpg|frame|right| View of non 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:42:36Z

Ravnee: /* Existing Functionality */

[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==
[[File:Refactored_Leaderboard_file.jpg|frame|left| View of Refactored Leaderboard]]
[[File:Non_Refactored_Leaderboard_file.jpg|frame|right| View of non 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:40:40Z

Ravnee: /* Project Description */

[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 '''''
| ''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|frame| View of Refactored Leaderboard]]
[[File:Non_Refactored_Leaderboard_file.jpg|frame| View of non 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:34:13Z

Ravnee: /* Project Description */

[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_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:21:28Z

Ravnee: /* Existing Functionality */

[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:20:31Z

Ravnee: /* Project Description */

[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:20Z

Ravnee: /* Existing Functionality */

[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==
{| 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:11:04Z

Ravnee:

[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==
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/ch1a 1 rm

2014-09-25T21:05:58Z

Ravnee: /* History */

[https://docs.google.com/document/d/1eq3XHiUUBIrEBx-R2Mgolaw7HttSgzPniwDLEF5oVk0/edit?pli=1 Writeup Page]

'''Play Framework'''

Play is modern web framework that provides support for writing scalable applications in either Java or Scala. It is an open source web framework and follows model–view–controller [http://en.wikipedia.org/wiki/Model-view-controller MVC] architectural pattern. It mainly focuses on being stateless and non-blocking I/O which is one of the main drawbacks among its competitors like Tomcat, [http://en.wikipedia.org/wiki/Spring_Framework Spring MVC] etc. Unlike these, Play’s approach is not threaded, it is a framework that is based on event model. This support for a full HTTP asynchronous programming model, makes Play an ideal framework for writing highly-distributed systems while maintaining performance, reliability and developer productivity.

Play is built on [http://en.wikipedia.org/wiki/Akka_(toolkit) Akka](Actor based model), providing predictable and minimal resource consumption for highly scalable applications. It used for handling highly concurrent systems and allows to develop applications in both Java and Scala.<ref> http://www.playframework.com </ref>

[[File:Normal.png‎|right|]]
__TOC__

==History==

Play Framework development started back in 2007 at Zenexity but it’s first release as a open source framework was available not available until 2009.
In May 2008 the first published code for 1.0 appeared on Launchpad. This was followed by a full 1.0 release in October 2009.

Play 1.1 <ref name="history">http://en.wikipedia.org/wiki/Play_framework#History</ref> was released in November 2010 after a move from Launchpad to GitHub. It included a migration from Apache MINA to JBoss Netty, Scala support, native GlassFishcontainer, an asynchronous web services library, OAuth support, HTTPS support and other features.

Play 1.2 <ref name="history"/> was released in April 2011. It included dependency management with Apache Ivy, support for WebSocket, integrated database migration (reversion is not implemented yet), a switch to the H2 database and other features.

Play 2.0 was released on March 13, 2012 in conjunction with Typesafe Stack 2.0.

Play 2.1 <ref name="history"/> was released on February 6, 2013, upgraded to Scala 2.10 and introduced, among other new features, modularisation, a new JSON API, filters and RequireJS support.

Play 2.2 <ref name="history"/> was released on September 20, 2013. Upgraded support for SBT to 0.13, better support for buffering, built in support for gzip and new stage and dist tasks with support for native packaging on several platforms such as OS X (DMG), Linux (RPM, DEB), and Windows (MSI) as well as zip files.

Play 2.3<ref>https://www.playframework.com/documentation/2.3.x/Highlights23</ref> has updated to include Activator, improved build environment(sbt), compatibilty with Java 8. This version of Play has been built on multiple version of Scala both 2.10 and 2.11. The WS client library has been refactored into its own library so that Play can have multiple WSClient objects, rather than only using the WS singleton. A method to use actors for handling websocket interactions has been incorporated for both Java and Scala. Anorm ( a simple data access layer that uses plain SQL to interact with the database and provides an API to parse and transform the resulting datasets) has been updated to include type safety, option parsing, error handling.

==Development with Play==

Let us see the features offered by Play from a developers perspective, who wants to develop a web application in Play framework.
===Installing Play===
To install Play framework, download the binaries from [https://www.playframework.com/download download page] and extract the contents to any folder. Add the extracted folder to path variable<ref>https://www.playframework.com/documentation/2.3.x/Installing </ref> and verify whether you were able to execute the below command :
<pre>
activator ui
</pre>
This starts the play server and if everything goes well, you should see a default play application running at http: //127.0.0.1:8888/home .

===Creating a new project===

To create a new project just type the below command and Play will take care of creating directory structure for your app with a standard layout.
<pre>
activator new <app name>
</pre>
If you are wondering what folders were created and what they imply, here is a brief explanation to get you started :

*app folder: It contains the main part of the application,i.e.,models, views, controllers. All the source code is present here.

*conf folder: It will contain all the configuration files especially the application.conf, the routes file and the messages file used for [https://www.playframework.com/documentation/1.2/i18n Internationalization](a way of adopting your application to different languages for different regions). The main entry point of the application is conf/routes file, it will contain the list of URL’s that are accessible in a application.

*lib folder: It is used for extending libraries.

*public: It used for all static files like JavaScript files, style sheets and images directories, resources which are available publicly.

*test folder: All the application tests are written in this folder, JUnit for functional testing and Selenium tests for Web application testing.

There won’t be any predefined folder to store Java .class files, as Play doesn’t need one. It internally uses eclipse compiler and compiles Java classes on the fly. This gives the ability to reflect the changes made in Java files, without having to compile them again. Another advantage of having an inbuilt compiler is that Play will create a better error report by showing the point of failure <ref>http://stackoverflow.com/questions/11704951/play-framework-no-need-to-compile</ref>.

===How to run an application?===

Navigate to the app directory and execute below command :
<pre>
activator run
</pre>
Your application will be loaded and a web server is started at 9000 port. Application can be accessed at http://localhost:9000/

Similar to [http://rubyonrails.org/ Rails], Play also uses config/routes file to map the request URL to the respective controller method. A sample entry looks like this :
<pre>
Get / Users.index
</pre>
The above line invokes index() method in Users controller when you access the application home page.

You can either use a text editor to make code changes or even there is a support for IDEs like [https://netbeans.org/ Netbeans] and [https://www.eclipse.org/ Eclipse] in Play. If you want to set up a Java IDE, please check [https://www.playframework.com/documentation/1.1.1/ide this page].

===Database support===

Play comes with an inbuilt Database called HSQLDB<ref>http://en.wikipedia.org/wiki/HSQLDB</ref>, this is an in-memory database and if you want to use any other persisting databases like [http://www.oracle.com/us/products/database/overview/index.html Oracle], [http://www.postgresql.org/ Postgres] etc, you can add those configs in conf/application.conf file. Play will connect to the specified database while application startup.

Play uses 'Object Relational Mapper' to persist the model objects to a persistent DB. JPA<ref>http://en.wikipedia.org/wiki/Java_Persistence_API</ref> is a Java specification that defines a standard API for object relational mapping. As implementation of JPA, play uses the well-known Hibernate framework.

===Testing===

To run a test case, you need to start the application in a special ‘test’ mode. Stop the currently running application, open a command line and type:
<pre>
activator test
</pre>
The 'play test' command is almost the same than 'play run', except that it loads a test runner module that allows to run test suite directly from a browser. When you run a play application in test mode, play will automatically switch to the test framework id and load the application.conf file accordingly. Check this page for more information. Open a browser to the http://localhost:9000/@tests URL to see the test runner.

Similar to Rails, one can use Fixtures to load the test data in test. These data files reside in appname/test/ folder.

Play gives you a way to test directly the controller part of the application using [http://junit.org/ JUnit]. These are called 'Functional tests'. Basically a functional test calls the play ActionInvoker directly, simulating an HTTP request. So we give an HTTP method, an URI and HTTP parameters. Play then routes the request, invokes the corresponding action and sends you back the filled response. You can then analyze it to check that the response content is like you expected.

Play provides an additional functionality for [http://www.seleniumhq.org/ Selenium] tests, which are specifically written for web based applications. The benefit of using Selenium is that it will test your application in your browser and not a built in simulator.

===Play Templates===

Play has an efficient templating system which allows to dynamically generate HTML, XML, JSON or any text based format document. The template engine uses Groovy as an expression language. A tag system allows you to create reusable functions. Templates are stored in the app/views directory.

This template language is useful in various ways and you can read more about it [https://www.playframework.com/documentation/1.0/templates here]

===Play Modules===

A play application can be assembled from several application modules. This lets you reuse components across several applications or split a large application into several smaller ones. A module is just another play application; however some differences exist in the way resources are loaded for an application module :
A module does not have a conf/application.conf file.
A module can have a conf/routes file, but these routes will not be loaded automatically.
All files are first searched for in the main application path, then in all loaded modules.
Everything in a module is optional.
You can create a module with the play new command, just like you do for any other application.

To load an external module<ref>https://www.playframework.com/modules</ref>, just declare it in the application.conf file of main application. One of such useful modules in CRUD module. Using [http://en.wikipedia.org/wiki/Create,_read,_update_and_delete CRUD] you can easily configure your application to have an administration area where you can add/update/delete any model objects present in your application.

Another such frequently used module is a code coverage module based on the [http://cobertura.github.io/cobertura/ Cobertura] tool.

==Why Play?==

Play is a lightweight framework that offers so many options for [http://en.wikipedia.org/wiki/Java_%28programming_language%29 Java] and [http://en.wikipedia.org/wiki/Scala_%28programming_language%29 Scala] developers, without compromising much on productivity. Here are some of the features describing why one should opt for Play:

===Developer Friendly===
*Change the code wherever like Java classes or Templates and just hit refresh to see your changes.
*Lot of support for testing tools.

===Scalable and Efficient===
*Play is built on Akka, so it supports non-blocking I/O<ref>http://www.playframework.com/documentation/2.0.4/ScalaAsync</ref>. This means it's very easy and inexpensive to make remote calls in parallel, which is important for high performance apps in a service oriented architecture.

===Good Support===
*Commercial support is provided by [http://zenexity.com/ Zenexity] and [http://typesafe.com/ Typesafe].
*Easy cloud hosting options like Stax cloud hosting platform and can be deployed virtually anywhere: inside Servlet containers, as standalone servers, in Google Application Engine etc.

===Open source===
*Play is a open source project and this enables you to see what happens under the hood.
*Also there is vast support through plugins modules etc which can be reused in building your application.

===Built for latest technologies===
*Play has extensive NoSql and BigData support.
*Built-in support for REST, JSON/XML handling, non-blocking I/O, WebSockets <ref>http://www.playframework.com/documentation/2.0.4/ScalaWebSockets</ref>, asset compilation (CoffeeScript, less), ORM, NoSQL support, and many.

===Notable uses of Play===

LinkedIn is the one of the most popular companies that uses play in its production.<ref> https://engineering.linkedin.com/play/play-framework-linkedin</ref>
Some of the other websites that use Play are [https://www.coursera.org/ Coursera], Mashape, [http://typesafe.com/ typesafe], [http://prenser.com/ Prenser], [http://subscribe.peachdish.com/ PeachDish]<ref>http://en.wikipedia.org/wiki/Play_framework#Usage</ref>.

==Comparison with other frameworks==
{| {{table}}
|+ Feature-based Comparison on Web Frameworks <ref>http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2014/ch1a_1c_yj#Feature-based_Comparison_on_Web_Frameworks</ref>
|-
| align="center" style="background:#f0f0f0;"|'''Project'''
| align="center" style="background:#f0f0f0;"|'''Language'''
| align="center" style="background:#f0f0f0;"|'''Ajax'''
| align="center" style="background:#f0f0f0;"|'''MVC framework'''
| align="center" style="background:#f0f0f0;"|'''MVC push-pull'''
| align="center" style="background:#f0f0f0;"|'''Testing framework(s)'''
| align="center" style="background:#f0f0f0;"|'''DB migration framework(s)'''
| align="center" style="background:#f0f0f0;"|'''Security framework(s)'''
| align="center" style="background:#f0f0f0;"|'''Template framework(s)'''
| align="center" style="background:#f0f0f0;"|'''Caching framework(s)'''
| align="center" style="background:#f0f0f0;"|'''Form validation framework(s)'''
| align="center" style="background:#f0f0f0;"|'''Scaffolding'''
|-
| Ruby on Rails||Ruby||[http://prototypejs.org/ Prototype], [http://script.aculo.us/ script.aculo.us], [http://jquery.com/? jQuery]||Yes (ActiveRecord, Action Pack)||Push||Unit Tests, Functional Tests and Integration Tests||Yes||Plug-in||Yes||Yes||Yes||Yes
|-
| CakePHP||PHP >= 5.2||[http://prototypejs.org/ Prototype], [http://script.aculo.us/ script.aculo.us], [http://jquery.com/? jQuery], [http://http://mootools.net/ MooTools]||Yes||Push||Unit tests, object mocking, fixtures, code coverage, memory analysis with SimpleTest and XDebug PHPUnit (cakephp 2.0)||Yes, [http://book.cakephp.org/2.0/en/console-and-shells/schema-management-and-migrations.html CakePHP Schema Shell] by default, and some others||[http://en.wikipedia.org/wiki/Access_control_list ACL-based]||Themes, layouts, views, elements||Memcache, Redis, XCache, APC, File||Validation, security||Yes
|-
| Django||Python||Yes||Yes||Push||unittest, test client, LiveServerTestCase||Provided by South(http://south.aeracode.org/), Django Evolution||[http://en.wikipedia.org/wiki/Access_control_list ACL-based]||Django Template Language||Cache Framework||Django Forms API||No, not by default
|-
| Play||Scala/Java||Yes||Yes||Push-pull||Unit test, Functional test, Selenium||Yes, similar to Ruby on Rails||via Core Security module||Yes||Yes||Server-side validation||Yes
|-
|
|}

==References==
<references/>

==External links==
*[http://www.playframework.com/documentation/2.1.0/Home Play 2.1 Documentation]

*[https://groups.google.com/forum/#%21forum/play-framework Play Framework Google Group]

*[http://engineering.linkedin.com/play/play-framework-async-io-without-thread-pool-and-callback-hell Play framework at LinkedIn]

*[https://github.com/playframework/Play20/wiki/Modules Play framework at github]

*[http://stackoverflow.com/tags/playframework Stackoverflow Page]

*[http://en.wikipedia.org/wiki/Play_framework Play framework Wiki Page]

CSC/ECE 517 Fall 2014/ch1a 1 rm

2014-09-25T21:04:11Z

Ravnee: /* History */

[https://docs.google.com/document/d/1eq3XHiUUBIrEBx-R2Mgolaw7HttSgzPniwDLEF5oVk0/edit?pli=1 Writeup Page]

'''Play Framework'''

Play is modern web framework that provides support for writing scalable applications in either Java or Scala. It is an open source web framework and follows model–view–controller [http://en.wikipedia.org/wiki/Model-view-controller MVC] architectural pattern. It mainly focuses on being stateless and non-blocking I/O which is one of the main drawbacks among its competitors like Tomcat, [http://en.wikipedia.org/wiki/Spring_Framework Spring MVC] etc. Unlike these, Play’s approach is not threaded, it is a framework that is based on event model. This support for a full HTTP asynchronous programming model, makes Play an ideal framework for writing highly-distributed systems while maintaining performance, reliability and developer productivity.

Play is built on [http://en.wikipedia.org/wiki/Akka_(toolkit) Akka](Actor based model), providing predictable and minimal resource consumption for highly scalable applications. It used for handling highly concurrent systems and allows to develop applications in both Java and Scala.<ref> http://www.playframework.com </ref>

[[File:Normal.png‎|right|]]
__TOC__

==History==

Play Framework development started back in 2007 at Zenexity but it’s first release as a open source framework was available not available until 2009.
In May 2008 the first published code for 1.0 appeared on Launchpad. This was followed by a full 1.0 release in October 2009.

Play 1.1 <ref name="history">http://en.wikipedia.org/wiki/Play_framework#History</ref> was released in November 2010 after a move from Launchpad to GitHub. It included a migration from Apache MINA to JBoss Netty, Scala support, native GlassFishcontainer, an asynchronous web services library, OAuth support, HTTPS support and other features.

Play 1.2 <ref name="history"/> was released in April 2011. It included dependency management with Apache Ivy, support for WebSocket, integrated database migration (reversion is not implemented yet), a switch to the H2 database and other features.

Play 2.0 <ref name="history"/> was released on March 13, 2012 in conjunction with Typesafe Stack 2.0.

Play 2.1 <ref name="history"/> was released on February 6, 2013, upgraded to Scala 2.10 and introduced, among other new features, modularisation, a new JSON API, filters and RequireJS support.

Play 2.2 <ref name="history"/> was released on September 20, 2013. Upgraded support for SBT to 0.13, better support for buffering, built in support for gzip and new stage and dist tasks with support for native packaging on several platforms such as OS X (DMG), Linux (RPM, DEB), and Windows (MSI) as well as zip files.

Play 2.3<ref>https://www.playframework.com/documentation/2.3.x/Highlights23</ref> has updated to include Activator, improved build environment(sbt), compatibilty with Java 8. This version of Play has been built on multiple version of Scala both 2.10 and 2.11. The WS client library has been refactored into its own library so that Play can have multiple WSClient objects, rather than only using the WS singleton. A method to use actors for handling websocket interactions has been incorporated for both Java and Scala. Anorm ( a simple data access layer that uses plain SQL to interact with the database and provides an API to parse and transform the resulting datasets) has been updated to include type safety, option parsing, error handling.

==Development with Play==

Let us see the features offered by Play from a developers perspective, who wants to develop a web application in Play framework.
===Installing Play===
To install Play framework, download the binaries from [https://www.playframework.com/download download page] and extract the contents to any folder. Add the extracted folder to path variable<ref>https://www.playframework.com/documentation/2.3.x/Installing </ref> and verify whether you were able to execute the below command :
<pre>
activator ui
</pre>
This starts the play server and if everything goes well, you should see a default play application running at http: //127.0.0.1:8888/home .

===Creating a new project===

To create a new project just type the below command and Play will take care of creating directory structure for your app with a standard layout.
<pre>
activator new <app name>
</pre>
If you are wondering what folders were created and what they imply, here is a brief explanation to get you started :

*app folder: It contains the main part of the application,i.e.,models, views, controllers. All the source code is present here.

*conf folder: It will contain all the configuration files especially the application.conf, the routes file and the messages file used for [https://www.playframework.com/documentation/1.2/i18n Internationalization](a way of adopting your application to different languages for different regions). The main entry point of the application is conf/routes file, it will contain the list of URL’s that are accessible in a application.

*lib folder: It is used for extending libraries.

*public: It used for all static files like JavaScript files, style sheets and images directories, resources which are available publicly.

*test folder: All the application tests are written in this folder, JUnit for functional testing and Selenium tests for Web application testing.

There won’t be any predefined folder to store Java .class files, as Play doesn’t need one. It internally uses eclipse compiler and compiles Java classes on the fly. This gives the ability to reflect the changes made in Java files, without having to compile them again. Another advantage of having an inbuilt compiler is that Play will create a better error report by showing the point of failure <ref>http://stackoverflow.com/questions/11704951/play-framework-no-need-to-compile</ref>.

===How to run an application?===

Navigate to the app directory and execute below command :
<pre>
activator run
</pre>
Your application will be loaded and a web server is started at 9000 port. Application can be accessed at http://localhost:9000/

Similar to [http://rubyonrails.org/ Rails], Play also uses config/routes file to map the request URL to the respective controller method. A sample entry looks like this :
<pre>
Get / Users.index
</pre>
The above line invokes index() method in Users controller when you access the application home page.

You can either use a text editor to make code changes or even there is a support for IDEs like [https://netbeans.org/ Netbeans] and [https://www.eclipse.org/ Eclipse] in Play. If you want to set up a Java IDE, please check [https://www.playframework.com/documentation/1.1.1/ide this page].

===Database support===

Play comes with an inbuilt Database called HSQLDB<ref>http://en.wikipedia.org/wiki/HSQLDB</ref>, this is an in-memory database and if you want to use any other persisting databases like [http://www.oracle.com/us/products/database/overview/index.html Oracle], [http://www.postgresql.org/ Postgres] etc, you can add those configs in conf/application.conf file. Play will connect to the specified database while application startup.

Play uses 'Object Relational Mapper' to persist the model objects to a persistent DB. JPA<ref>http://en.wikipedia.org/wiki/Java_Persistence_API</ref> is a Java specification that defines a standard API for object relational mapping. As implementation of JPA, play uses the well-known Hibernate framework.

===Testing===

To run a test case, you need to start the application in a special ‘test’ mode. Stop the currently running application, open a command line and type:
<pre>
activator test
</pre>
The 'play test' command is almost the same than 'play run', except that it loads a test runner module that allows to run test suite directly from a browser. When you run a play application in test mode, play will automatically switch to the test framework id and load the application.conf file accordingly. Check this page for more information. Open a browser to the http://localhost:9000/@tests URL to see the test runner.

Similar to Rails, one can use Fixtures to load the test data in test. These data files reside in appname/test/ folder.

Play gives you a way to test directly the controller part of the application using [http://junit.org/ JUnit]. These are called 'Functional tests'. Basically a functional test calls the play ActionInvoker directly, simulating an HTTP request. So we give an HTTP method, an URI and HTTP parameters. Play then routes the request, invokes the corresponding action and sends you back the filled response. You can then analyze it to check that the response content is like you expected.

Play provides an additional functionality for [http://www.seleniumhq.org/ Selenium] tests, which are specifically written for web based applications. The benefit of using Selenium is that it will test your application in your browser and not a built in simulator.

===Play Templates===

Play has an efficient templating system which allows to dynamically generate HTML, XML, JSON or any text based format document. The template engine uses Groovy as an expression language. A tag system allows you to create reusable functions. Templates are stored in the app/views directory.

This template language is useful in various ways and you can read more about it [https://www.playframework.com/documentation/1.0/templates here]

===Play Modules===

A play application can be assembled from several application modules. This lets you reuse components across several applications or split a large application into several smaller ones. A module is just another play application; however some differences exist in the way resources are loaded for an application module :
A module does not have a conf/application.conf file.
A module can have a conf/routes file, but these routes will not be loaded automatically.
All files are first searched for in the main application path, then in all loaded modules.
Everything in a module is optional.
You can create a module with the play new command, just like you do for any other application.

To load an external module<ref>https://www.playframework.com/modules</ref>, just declare it in the application.conf file of main application. One of such useful modules in CRUD module. Using [http://en.wikipedia.org/wiki/Create,_read,_update_and_delete CRUD] you can easily configure your application to have an administration area where you can add/update/delete any model objects present in your application.

Another such frequently used module is a code coverage module based on the [http://cobertura.github.io/cobertura/ Cobertura] tool.

==Why Play?==

Play is a lightweight framework that offers so many options for [http://en.wikipedia.org/wiki/Java_%28programming_language%29 Java] and [http://en.wikipedia.org/wiki/Scala_%28programming_language%29 Scala] developers, without compromising much on productivity. Here are some of the features describing why one should opt for Play:

===Developer Friendly===
*Change the code wherever like Java classes or Templates and just hit refresh to see your changes.
*Lot of support for testing tools.

===Scalable and Efficient===
*Play is built on Akka, so it supports non-blocking I/O<ref>http://www.playframework.com/documentation/2.0.4/ScalaAsync</ref>. This means it's very easy and inexpensive to make remote calls in parallel, which is important for high performance apps in a service oriented architecture.

===Good Support===
*Commercial support is provided by [http://zenexity.com/ Zenexity] and [http://typesafe.com/ Typesafe].
*Easy cloud hosting options like Stax cloud hosting platform and can be deployed virtually anywhere: inside Servlet containers, as standalone servers, in Google Application Engine etc.

===Open source===
*Play is a open source project and this enables you to see what happens under the hood.
*Also there is vast support through plugins modules etc which can be reused in building your application.

===Built for latest technologies===
*Play has extensive NoSql and BigData support.
*Built-in support for REST, JSON/XML handling, non-blocking I/O, WebSockets <ref>http://www.playframework.com/documentation/2.0.4/ScalaWebSockets</ref>, asset compilation (CoffeeScript, less), ORM, NoSQL support, and many.

===Notable uses of Play===

LinkedIn is the one of the most popular companies that uses play in its production.<ref> https://engineering.linkedin.com/play/play-framework-linkedin</ref>
Some of the other websites that use Play are [https://www.coursera.org/ Coursera], Mashape, [http://typesafe.com/ typesafe], [http://prenser.com/ Prenser], [http://subscribe.peachdish.com/ PeachDish]<ref>http://en.wikipedia.org/wiki/Play_framework#Usage</ref>.

==Comparison with other frameworks==
{| {{table}}
|+ Feature-based Comparison on Web Frameworks <ref>http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2014/ch1a_1c_yj#Feature-based_Comparison_on_Web_Frameworks</ref>
|-
| align="center" style="background:#f0f0f0;"|'''Project'''
| align="center" style="background:#f0f0f0;"|'''Language'''
| align="center" style="background:#f0f0f0;"|'''Ajax'''
| align="center" style="background:#f0f0f0;"|'''MVC framework'''
| align="center" style="background:#f0f0f0;"|'''MVC push-pull'''
| align="center" style="background:#f0f0f0;"|'''Testing framework(s)'''
| align="center" style="background:#f0f0f0;"|'''DB migration framework(s)'''
| align="center" style="background:#f0f0f0;"|'''Security framework(s)'''
| align="center" style="background:#f0f0f0;"|'''Template framework(s)'''
| align="center" style="background:#f0f0f0;"|'''Caching framework(s)'''
| align="center" style="background:#f0f0f0;"|'''Form validation framework(s)'''
| align="center" style="background:#f0f0f0;"|'''Scaffolding'''
|-
| Ruby on Rails||Ruby||[http://prototypejs.org/ Prototype], [http://script.aculo.us/ script.aculo.us], [http://jquery.com/? jQuery]||Yes (ActiveRecord, Action Pack)||Push||Unit Tests, Functional Tests and Integration Tests||Yes||Plug-in||Yes||Yes||Yes||Yes
|-
| CakePHP||PHP >= 5.2||[http://prototypejs.org/ Prototype], [http://script.aculo.us/ script.aculo.us], [http://jquery.com/? jQuery], [http://http://mootools.net/ MooTools]||Yes||Push||Unit tests, object mocking, fixtures, code coverage, memory analysis with SimpleTest and XDebug PHPUnit (cakephp 2.0)||Yes, [http://book.cakephp.org/2.0/en/console-and-shells/schema-management-and-migrations.html CakePHP Schema Shell] by default, and some others||[http://en.wikipedia.org/wiki/Access_control_list ACL-based]||Themes, layouts, views, elements||Memcache, Redis, XCache, APC, File||Validation, security||Yes
|-
| Django||Python||Yes||Yes||Push||unittest, test client, LiveServerTestCase||Provided by South(http://south.aeracode.org/), Django Evolution||[http://en.wikipedia.org/wiki/Access_control_list ACL-based]||Django Template Language||Cache Framework||Django Forms API||No, not by default
|-
| Play||Scala/Java||Yes||Yes||Push-pull||Unit test, Functional test, Selenium||Yes, similar to Ruby on Rails||via Core Security module||Yes||Yes||Server-side validation||Yes
|-
|
|}

==References==
<references/>

==External links==
*[http://www.playframework.com/documentation/2.1.0/Home Play 2.1 Documentation]

*[https://groups.google.com/forum/#%21forum/play-framework Play Framework Google Group]

*[http://engineering.linkedin.com/play/play-framework-async-io-without-thread-pool-and-callback-hell Play framework at LinkedIn]

*[https://github.com/playframework/Play20/wiki/Modules Play framework at github]

*[http://stackoverflow.com/tags/playframework Stackoverflow Page]

*[http://en.wikipedia.org/wiki/Play_framework Play framework Wiki Page]

CSC/ECE 517 Fall 2014/ch1a 1 rm

2014-09-25T21:03:02Z

Ravnee:

[https://docs.google.com/document/d/1eq3XHiUUBIrEBx-R2Mgolaw7HttSgzPniwDLEF5oVk0/edit?pli=1 Writeup Page]

'''Play Framework'''

Play is modern web framework that provides support for writing scalable applications in either Java or Scala. It is an open source web framework and follows model–view–controller [http://en.wikipedia.org/wiki/Model-view-controller MVC] architectural pattern. It mainly focuses on being stateless and non-blocking I/O which is one of the main drawbacks among its competitors like Tomcat, [http://en.wikipedia.org/wiki/Spring_Framework Spring MVC] etc. Unlike these, Play’s approach is not threaded, it is a framework that is based on event model. This support for a full HTTP asynchronous programming model, makes Play an ideal framework for writing highly-distributed systems while maintaining performance, reliability and developer productivity.

Play is built on [http://en.wikipedia.org/wiki/Akka_(toolkit) Akka](Actor based model), providing predictable and minimal resource consumption for highly scalable applications. It used for handling highly concurrent systems and allows to develop applications in both Java and Scala.<ref> http://www.playframework.com </ref>

[[File:Normal.png‎|right|]]
__TOC__

==History==

Play Framework development started back in 2007 at Zenexity but it’s first release as a open source framework was available not available until 2009.
In May 2008 the first published code for 1.0 appeared on Launchpad. This was followed by a full 1.0 release in October 2009.<ref name="history">http://en.wikipedia.org/wiki/Play_framework#History</ref>

Play 1.1 <ref name="history"/>was released in November 2010 after a move from Launchpad to GitHub. It included a migration from Apache MINA to JBoss Netty, Scala support, native GlassFishcontainer, an asynchronous web services library, OAuth support, HTTPS support and other features.

Play 1.2 <ref name="history"/>was released in April 2011. It included dependency management with Apache Ivy, support for WebSocket, integrated database migration (reversion is not implemented yet), a switch to the H2 database and other features.

Play 2.0 <ref name="history"/>was released on March 13, 2012 in conjunction with Typesafe Stack 2.0.

Play 2.1 <ref name="history"/>was released on February 6, 2013, upgraded to Scala 2.10 and introduced, among other new features, modularisation, a new JSON API, filters and RequireJS support.

Play 2.2 <ref name="history"/>was released on September 20, 2013. Upgraded support for SBT to 0.13, better support for buffering, built in support for gzip and new stage and dist tasks with support for native packaging on several platforms such as OS X (DMG), Linux (RPM, DEB), and Windows (MSI) as well as zip files.

Play 2.3<ref>https://www.playframework.com/documentation/2.3.x/Highlights23</ref> has updated to include Activator, improved build environment(sbt), compatibilty with Java 8. This version of Play has been built on multiple version of Scala both 2.10 and 2.11. The WS client library has been refactored into its own library so that Play can have multiple WSClient objects, rather than only using the WS singleton. A method to use actors for handling websocket interactions has been incorporated for both Java and Scala. Anorm ( a simple data access layer that uses plain SQL to interact with the database and provides an API to parse and transform the resulting datasets) has been updated to include type safety, option parsing, error handling.

==Development with Play==

Let us see the features offered by Play from a developers perspective, who wants to develop a web application in Play framework.
===Installing Play===
To install Play framework, download the binaries from [https://www.playframework.com/download download page] and extract the contents to any folder. Add the extracted folder to path variable<ref>https://www.playframework.com/documentation/2.3.x/Installing </ref> and verify whether you were able to execute the below command :
<pre>
activator ui
</pre>
This starts the play server and if everything goes well, you should see a default play application running at http: //127.0.0.1:8888/home .

===Creating a new project===

To create a new project just type the below command and Play will take care of creating directory structure for your app with a standard layout.
<pre>
activator new <app name>
</pre>
If you are wondering what folders were created and what they imply, here is a brief explanation to get you started :

*app folder: It contains the main part of the application,i.e.,models, views, controllers. All the source code is present here.

*conf folder: It will contain all the configuration files especially the application.conf, the routes file and the messages file used for [https://www.playframework.com/documentation/1.2/i18n Internationalization](a way of adopting your application to different languages for different regions). The main entry point of the application is conf/routes file, it will contain the list of URL’s that are accessible in a application.

*lib folder: It is used for extending libraries.

*public: It used for all static files like JavaScript files, style sheets and images directories, resources which are available publicly.

*test folder: All the application tests are written in this folder, JUnit for functional testing and Selenium tests for Web application testing.

There won’t be any predefined folder to store Java .class files, as Play doesn’t need one. It internally uses eclipse compiler and compiles Java classes on the fly. This gives the ability to reflect the changes made in Java files, without having to compile them again. Another advantage of having an inbuilt compiler is that Play will create a better error report by showing the point of failure <ref>http://stackoverflow.com/questions/11704951/play-framework-no-need-to-compile</ref>.

===How to run an application?===

Navigate to the app directory and execute below command :
<pre>
activator run
</pre>
Your application will be loaded and a web server is started at 9000 port. Application can be accessed at http://localhost:9000/

Similar to [http://rubyonrails.org/ Rails], Play also uses config/routes file to map the request URL to the respective controller method. A sample entry looks like this :
<pre>
Get / Users.index
</pre>
The above line invokes index() method in Users controller when you access the application home page.

You can either use a text editor to make code changes or even there is a support for IDEs like [https://netbeans.org/ Netbeans] and [https://www.eclipse.org/ Eclipse] in Play. If you want to set up a Java IDE, please check [https://www.playframework.com/documentation/1.1.1/ide this page].

===Database support===

Play comes with an inbuilt Database called HSQLDB<ref>http://en.wikipedia.org/wiki/HSQLDB</ref>, this is an in-memory database and if you want to use any other persisting databases like [http://www.oracle.com/us/products/database/overview/index.html Oracle], [http://www.postgresql.org/ Postgres] etc, you can add those configs in conf/application.conf file. Play will connect to the specified database while application startup.

Play uses 'Object Relational Mapper' to persist the model objects to a persistent DB. JPA<ref>http://en.wikipedia.org/wiki/Java_Persistence_API</ref> is a Java specification that defines a standard API for object relational mapping. As implementation of JPA, play uses the well-known Hibernate framework.

===Testing===

To run a test case, you need to start the application in a special ‘test’ mode. Stop the currently running application, open a command line and type:
<pre>
activator test
</pre>
The 'play test' command is almost the same than 'play run', except that it loads a test runner module that allows to run test suite directly from a browser. When you run a play application in test mode, play will automatically switch to the test framework id and load the application.conf file accordingly. Check this page for more information. Open a browser to the http://localhost:9000/@tests URL to see the test runner.

Similar to Rails, one can use Fixtures to load the test data in test. These data files reside in appname/test/ folder.

Play gives you a way to test directly the controller part of the application using [http://junit.org/ JUnit]. These are called 'Functional tests'. Basically a functional test calls the play ActionInvoker directly, simulating an HTTP request. So we give an HTTP method, an URI and HTTP parameters. Play then routes the request, invokes the corresponding action and sends you back the filled response. You can then analyze it to check that the response content is like you expected.

Play provides an additional functionality for [http://www.seleniumhq.org/ Selenium] tests, which are specifically written for web based applications. The benefit of using Selenium is that it will test your application in your browser and not a built in simulator.

===Play Templates===

Play has an efficient templating system which allows to dynamically generate HTML, XML, JSON or any text based format document. The template engine uses Groovy as an expression language. A tag system allows you to create reusable functions. Templates are stored in the app/views directory.

This template language is useful in various ways and you can read more about it [https://www.playframework.com/documentation/1.0/templates here]

===Play Modules===

A play application can be assembled from several application modules. This lets you reuse components across several applications or split a large application into several smaller ones. A module is just another play application; however some differences exist in the way resources are loaded for an application module :
A module does not have a conf/application.conf file.
A module can have a conf/routes file, but these routes will not be loaded automatically.
All files are first searched for in the main application path, then in all loaded modules.
Everything in a module is optional.
You can create a module with the play new command, just like you do for any other application.

To load an external module<ref>https://www.playframework.com/modules</ref>, just declare it in the application.conf file of main application. One of such useful modules in CRUD module. Using [http://en.wikipedia.org/wiki/Create,_read,_update_and_delete CRUD] you can easily configure your application to have an administration area where you can add/update/delete any model objects present in your application.

Another such frequently used module is a code coverage module based on the [http://cobertura.github.io/cobertura/ Cobertura] tool.

==Why Play?==

Play is a lightweight framework that offers so many options for [http://en.wikipedia.org/wiki/Java_%28programming_language%29 Java] and [http://en.wikipedia.org/wiki/Scala_%28programming_language%29 Scala] developers, without compromising much on productivity. Here are some of the features describing why one should opt for Play:

===Developer Friendly===
*Change the code wherever like Java classes or Templates and just hit refresh to see your changes.
*Lot of support for testing tools.

===Scalable and Efficient===
*Play is built on Akka, so it supports non-blocking I/O<ref>http://www.playframework.com/documentation/2.0.4/ScalaAsync</ref>. This means it's very easy and inexpensive to make remote calls in parallel, which is important for high performance apps in a service oriented architecture.

===Good Support===
*Commercial support is provided by [http://zenexity.com/ Zenexity] and [http://typesafe.com/ Typesafe].
*Easy cloud hosting options like Stax cloud hosting platform and can be deployed virtually anywhere: inside Servlet containers, as standalone servers, in Google Application Engine etc.

===Open source===
*Play is a open source project and this enables you to see what happens under the hood.
*Also there is vast support through plugins modules etc which can be reused in building your application.

===Built for latest technologies===
*Play has extensive NoSql and BigData support.
*Built-in support for REST, JSON/XML handling, non-blocking I/O, WebSockets <ref>http://www.playframework.com/documentation/2.0.4/ScalaWebSockets</ref>, asset compilation (CoffeeScript, less), ORM, NoSQL support, and many.

===Notable uses of Play===

LinkedIn is the one of the most popular companies that uses play in its production.<ref> https://engineering.linkedin.com/play/play-framework-linkedin</ref>
Some of the other websites that use Play are [https://www.coursera.org/ Coursera], Mashape, [http://typesafe.com/ typesafe], [http://prenser.com/ Prenser], [http://subscribe.peachdish.com/ PeachDish]<ref>http://en.wikipedia.org/wiki/Play_framework#Usage</ref>.

==Comparison with other frameworks==
{| {{table}}
|+ Feature-based Comparison on Web Frameworks <ref>http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2014/ch1a_1c_yj#Feature-based_Comparison_on_Web_Frameworks</ref>
|-
| align="center" style="background:#f0f0f0;"|'''Project'''
| align="center" style="background:#f0f0f0;"|'''Language'''
| align="center" style="background:#f0f0f0;"|'''Ajax'''
| align="center" style="background:#f0f0f0;"|'''MVC framework'''
| align="center" style="background:#f0f0f0;"|'''MVC push-pull'''
| align="center" style="background:#f0f0f0;"|'''Testing framework(s)'''
| align="center" style="background:#f0f0f0;"|'''DB migration framework(s)'''
| align="center" style="background:#f0f0f0;"|'''Security framework(s)'''
| align="center" style="background:#f0f0f0;"|'''Template framework(s)'''
| align="center" style="background:#f0f0f0;"|'''Caching framework(s)'''
| align="center" style="background:#f0f0f0;"|'''Form validation framework(s)'''
| align="center" style="background:#f0f0f0;"|'''Scaffolding'''
|-
| Ruby on Rails||Ruby||[http://prototypejs.org/ Prototype], [http://script.aculo.us/ script.aculo.us], [http://jquery.com/? jQuery]||Yes (ActiveRecord, Action Pack)||Push||Unit Tests, Functional Tests and Integration Tests||Yes||Plug-in||Yes||Yes||Yes||Yes
|-
| CakePHP||PHP >= 5.2||[http://prototypejs.org/ Prototype], [http://script.aculo.us/ script.aculo.us], [http://jquery.com/? jQuery], [http://http://mootools.net/ MooTools]||Yes||Push||Unit tests, object mocking, fixtures, code coverage, memory analysis with SimpleTest and XDebug PHPUnit (cakephp 2.0)||Yes, [http://book.cakephp.org/2.0/en/console-and-shells/schema-management-and-migrations.html CakePHP Schema Shell] by default, and some others||[http://en.wikipedia.org/wiki/Access_control_list ACL-based]||Themes, layouts, views, elements||Memcache, Redis, XCache, APC, File||Validation, security||Yes
|-
| Django||Python||Yes||Yes||Push||unittest, test client, LiveServerTestCase||Provided by South(http://south.aeracode.org/), Django Evolution||[http://en.wikipedia.org/wiki/Access_control_list ACL-based]||Django Template Language||Cache Framework||Django Forms API||No, not by default
|-
| Play||Scala/Java||Yes||Yes||Push-pull||Unit test, Functional test, Selenium||Yes, similar to Ruby on Rails||via Core Security module||Yes||Yes||Server-side validation||Yes
|-
|
|}

==References==
<references/>

==External links==
*[http://www.playframework.com/documentation/2.1.0/Home Play 2.1 Documentation]

*[https://groups.google.com/forum/#%21forum/play-framework Play Framework Google Group]

*[http://engineering.linkedin.com/play/play-framework-async-io-without-thread-pool-and-callback-hell Play framework at LinkedIn]

*[https://github.com/playframework/Play20/wiki/Modules Play framework at github]

*[http://stackoverflow.com/tags/playframework Stackoverflow Page]

*[http://en.wikipedia.org/wiki/Play_framework Play framework Wiki Page]