Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2016 E1682: Improve score calculation

2016-12-05T04:51:25Z

Svenka15: /* Usecase Diagram */

E1682. Improve score calculation

== Introduction ==

=== Expertiza ===
Expertiza is an open source project for school assignment management for instructors and students based on the Ruby on Rails framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and word documents. Expertiza provides a dashboard for all the assignments corresponding to a course and provides absolute control to the Instructors and Teaching Assistants. In addition to assignments, it encompasses peer reviews wherein participants are allowed to provide feedback anonymously about each other's work thereby providing scope for the better outcome. The due_date.rb file is responsible for informing the users about the deadline for submission of the each assignment. Due dates in Expertiza have their association with many other components like assignments, reviews etc.

=== Purpose ===
The purpose of the project is to improve the functionality of score calculation. The scores in expertiza were calculated by taking the sum of weighted scores to calculate the total every time it is called. This takes considerable amount of time as there is a calculation involved each time. The methodology behind score calculation in expertiza can be significantly improved. The design behind calculating and storing scores can be tweaked to offer significant performance improvements. To achieve this, it is ideal to store overall holistic stores in addition to individual criterion scores.

=== Problem Statement ===
The current drawback of the expertiza system lies in how the scores are stored: Expertiza stores the scores based on each response to each criterion, but no holistic scores are stored. As a result of this mechanism, the process slows down. This means that if we need to know what score user A gives to user B based on 100, we have to rely on the code to calculate it (since in answers table we only have the score that A gives B on each criterion).

To overcome this bottleneck, two additional mechanisms can be included for handling the holistic scores.

== Overall Description ==
Expertiza currently calculates scores dynamically when a page is called by taking the weighted scores of each question into consideration. This calculation is a time consuming process with a considerable overhead that significantly affects the performance. To solve the issue we propose a solution to store the holistic scores in a database, retrieving it every time it is required. This reduces the calculation that is required every time the score is called. When the user wants to check the scores of a completed assignment, a method localDB_calc is called and expertiza retrieves the scores of the student from the database rather than calculating the total from weighted scores. But, when the scores of an ongoing assignment is required, a method on_the_fly_calc is called that calculates the current score of the user. To determine which method will be invoked(on_the_fly_calc and localDB_calc), the current system time will be compared with last_review_deadline
* If system time is greater than last_review_deadline, indicating that the deadline has passed, the method localDbcal will retrieve the holistic score from the database
* If system time is lesser than last_review_deadline, indicating that the deadline has not passed, the method on_the_fly_cal will calculate the holistic score and display it.

The Dataflow diagram (DFD) for the proposed system is shown below.

[[File:Flowchart12.png|center|frame|flowchart]]

== Tasks Identified ==
The two suggested mechanisms for handling the storage and calculation of holistic scores for peer-reviews, as specified in the requirements document are :
* on_the_fly_calc
* localDB_calc

=== on_the_fly_calc ===
When the assignment is still ongoing , this method is called and it calculates holistic scores over a set of data (in this case, a set of record in answers table, namely the responses from user A to user B on each criterion) and store it in localdbscores. This stored score is retrieved and printed when the user A clicks on the "Your scores" link.

In the current implementation, when a user A wants to view the score given by user B, user A's score(i.e. out of 100) will be calculated everytime using the scores given by user B for each criterion (i.e.. score out of 5).

Handles the calculation of reputations for each reviewer in the case of an ongoing assignment.

=== localDB_calc ===
Once the deadline for an assignment is completed, the method localDB_calc calculates the holistic score over a single db query (in this case, a query would be: “get the score that user A gives user B on assignment 999 on round 2”). The query can also ask to print the average of all the scores in round 1 and round2, this average will be retrieved from localdbscores and printed.

This method handles the calculation of reputations for each reviewer in the case of a finished assignment. (all the reputations are calculated and stored since they are finalized).

=== Database ===
To store the holistic scores when an assignment is completed, a database localdbscores needs to be created. The value from this db is retrieved and displayed when the scores of a completed assignment needs to be viewed. The database Design is shown below.

== Database Design ==
A table localdbscores will be created as:

class CreateLocalDB<ActiveRecord::Migration

def self.up

create_table :localdb_scores do |t|

t.column :id, :integer

t.column :score, :integer

t.column :round, :integer

t.column :type, :string

t.column :reference_id, :integer

end

with id, score, round, type, reference_id as its attributes as shown in the table below

"localdbscores" will have the following scores
{| class="wikitable"
|
|t.integer "id", limit: 24
|id
|Primary Key, Auto generated
|-
|
|t.string "Type", limit: 255
|Type
|Type of score: either final or intermediate
|-
|
|t.integer "Score", limit: 24
|Score
|Total score calculated based on each response to each criterion
|-
|
|t.integer "Round", limit:24
|Round
|The completed round number
|-
|
|t.integer "Reference_id" , limit:45
|Reference_id
|Acts as the foreign Key
|}

== Implementation ==

=== Assignment.rb ===
A new function get_last_review_date is added which takes assignid as a parameter and returns the last review deadline of the assignment. The deadline obtained from AssignmentDueDate for the corresponding assignid is stored in last_review_deadline and is returned.

=== Parent Class:ScoreCal ===
ScoreCal stores the score calculated by its sub classes: on_the_fly_cal and LocalDbcal to the database. In the database, a new table localdbscore is created with the schema as explained in section 2.2. Depending upon the deadline_type, object of either on_the_fly_cal or LocalDbcal is created and the appropriate functions within the classes are called.

=== Sub class 1: on_the_fly_cal ===
This is a subclass of class Scorecal contains a method calc_score whose functionality is to compute the holistic score. An object of on_the_fly_cal is called when the current time has not yet surpassed the time stored in last_review_deadline variable which contains the review duedate indicating that the assignment is still ongoing and has not been completed. The individual scores are retrieved from the database ScoreView and is stored in QuestionnaireData from which the holistic score of a student is calculated .

When the user accesses the scores for a review, the current implementation does not store a holistic score but rather calculates the holistic score from the score for every individual criterion. To calculate the total holistic score for a specific round, the individual scores are weighted and added.

This functionality is achieved by on_the_fly_calc.

A snapshot of the system before implementing the changes is shown below.
[[File:rsz_flycur.png]]

The proposed implementation involves computing the holistic score once and storing it in the local_db_scores database for a particular user and for a specified round. The stored value is accessed and obtained instead of computing the holistic score every single time.

[[File:rsz_flyadb.png]]

=== Sub class 2: LocalDbcal ===
This is a subclass of Scorecal and contains a function calc_score in class localDbcal. An object of LocalDbcal is called when the current time has surpassed the time stored in last_review_deadline variable which contains the review due date indicating that the assignment has been completed. This subclass retrieves the score from the database localDbscores for a corresponding student. If the score is not found in the database localDbscores, the function calc_score of on_the_fly_cal class is called to calculate the total from the weighted scores of each question. This calculated score is then inserted into the database.

This score is now returned to the view from where it was called.
[[File:rsz_loccur.png]]

The proposed implementation retrieves the round wise scores from the local_db_scores database and displays the average score once the deadline has passed rather than computing the average of the weighted scores for every access of the page as shown below.

[[File:rsz_locadb.png]]

=== _review_table.html.erb ===
The current implementation of this was to calculate the score and display it which as we know is a time consuming process. It has been changed to check if the current time has crossed the last_review_deadline obtained in assignments.rb and call the corresponding class as required.

If the current date has surpassed the last_review_deadline, it is an indication that the due date has passed and the class localDbcal is called to retrieve a value from the database as mentioned above. On the other hand, on_the_fly_cal is called when the current date has not surpassed the last_review_deadline, indicating that the assignment is ongoing and the holistic score is calculated and passed to the view.

== Design Pattern ==
The ScoreCal superclass has 2 subclasses: OnTheFlyCal and LocalDbCal. ScoreCal acts as an interface to obtain the scores, either from OnTheFlyCal or LocalDbCal depending on the last_review_deadline obtained from the get_last_review_date() in the assignment model. This pattern is similar to strategy pattern where the client is the _review_tble.html.erb, interface is the superclass and the subclasses are called accordingly.

[[File:UseCaseDiagram2.png]]

==Usecase Diagram==

[[File:UseCaseDiagram.png]]

The actors are :

1.Reviewer

2.Reviewee

3.Instructor/TA

The reviewer selects a topic from the list of topics to be reviewed and starts the review. He allots scores out of 5 for every question and the avaerage of this score gets stored in the database when the reviewer clicks on submit. The reviewee views this stored score when he clicks on "view scores".

== Testing ==
The testing for model: on_the_fly_calc is carried out by questionnaire_spec.rb in the spec folder. The minimum and maximum score that an user gives for each criterion is checked.

Two more test cases to check whether the average score of each review falls within a given range:(0,100) will be added.

For LocalDB_calc, the average calculated across round 1 and round 2 will be checked to fall within 0 to 100. These test cases will be added to questionnaire_spec.rb.

CSC/ECE 517 Fall 2016 E1682: Improve score calculation

2016-12-05T04:50:03Z

Svenka15: /* Usecase Diagram */

E1682. Improve score calculation

== Introduction ==

=== Expertiza ===
Expertiza is an open source project for school assignment management for instructors and students based on the Ruby on Rails framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and word documents. Expertiza provides a dashboard for all the assignments corresponding to a course and provides absolute control to the Instructors and Teaching Assistants. In addition to assignments, it encompasses peer reviews wherein participants are allowed to provide feedback anonymously about each other's work thereby providing scope for the better outcome. The due_date.rb file is responsible for informing the users about the deadline for submission of the each assignment. Due dates in Expertiza have their association with many other components like assignments, reviews etc.

=== Purpose ===
The purpose of the project is to improve the functionality of score calculation. The scores in expertiza were calculated by taking the sum of weighted scores to calculate the total every time it is called. This takes considerable amount of time as there is a calculation involved each time. The methodology behind score calculation in expertiza can be significantly improved. The design behind calculating and storing scores can be tweaked to offer significant performance improvements. To achieve this, it is ideal to store overall holistic stores in addition to individual criterion scores.

=== Problem Statement ===
The current drawback of the expertiza system lies in how the scores are stored: Expertiza stores the scores based on each response to each criterion, but no holistic scores are stored. As a result of this mechanism, the process slows down. This means that if we need to know what score user A gives to user B based on 100, we have to rely on the code to calculate it (since in answers table we only have the score that A gives B on each criterion).

To overcome this bottleneck, two additional mechanisms can be included for handling the holistic scores.

== Overall Description ==
Expertiza currently calculates scores dynamically when a page is called by taking the weighted scores of each question into consideration. This calculation is a time consuming process with a considerable overhead that significantly affects the performance. To solve the issue we propose a solution to store the holistic scores in a database, retrieving it every time it is required. This reduces the calculation that is required every time the score is called. When the user wants to check the scores of a completed assignment, a method localDB_calc is called and expertiza retrieves the scores of the student from the database rather than calculating the total from weighted scores. But, when the scores of an ongoing assignment is required, a method on_the_fly_calc is called that calculates the current score of the user. To determine which method will be invoked(on_the_fly_calc and localDB_calc), the current system time will be compared with last_review_deadline
* If system time is greater than last_review_deadline, indicating that the deadline has passed, the method localDbcal will retrieve the holistic score from the database
* If system time is lesser than last_review_deadline, indicating that the deadline has not passed, the method on_the_fly_cal will calculate the holistic score and display it.

The Dataflow diagram (DFD) for the proposed system is shown below.

[[File:Flowchart12.png|center|frame|flowchart]]

== Tasks Identified ==
The two suggested mechanisms for handling the storage and calculation of holistic scores for peer-reviews, as specified in the requirements document are :
* on_the_fly_calc
* localDB_calc

=== on_the_fly_calc ===
When the assignment is still ongoing , this method is called and it calculates holistic scores over a set of data (in this case, a set of record in answers table, namely the responses from user A to user B on each criterion) and store it in localdbscores. This stored score is retrieved and printed when the user A clicks on the "Your scores" link.

In the current implementation, when a user A wants to view the score given by user B, user A's score(i.e. out of 100) will be calculated everytime using the scores given by user B for each criterion (i.e.. score out of 5).

Handles the calculation of reputations for each reviewer in the case of an ongoing assignment.

=== localDB_calc ===
Once the deadline for an assignment is completed, the method localDB_calc calculates the holistic score over a single db query (in this case, a query would be: “get the score that user A gives user B on assignment 999 on round 2”). The query can also ask to print the average of all the scores in round 1 and round2, this average will be retrieved from localdbscores and printed.

This method handles the calculation of reputations for each reviewer in the case of a finished assignment. (all the reputations are calculated and stored since they are finalized).

=== Database ===
To store the holistic scores when an assignment is completed, a database localdbscores needs to be created. The value from this db is retrieved and displayed when the scores of a completed assignment needs to be viewed. The database Design is shown below.

== Database Design ==
A table localdbscores will be created as:

class CreateLocalDB<ActiveRecord::Migration

def self.up

create_table :localdb_scores do |t|

t.column :id, :integer

t.column :score, :integer

t.column :round, :integer

t.column :type, :string

t.column :reference_id, :integer

end

with id, score, round, type, reference_id as its attributes as shown in the table below

"localdbscores" will have the following scores
{| class="wikitable"
|
|t.integer "id", limit: 24
|id
|Primary Key, Auto generated
|-
|
|t.string "Type", limit: 255
|Type
|Type of score: either final or intermediate
|-
|
|t.integer "Score", limit: 24
|Score
|Total score calculated based on each response to each criterion
|-
|
|t.integer "Round", limit:24
|Round
|The completed round number
|-
|
|t.integer "Reference_id" , limit:45
|Reference_id
|Acts as the foreign Key
|}

== Implementation ==

=== Assignment.rb ===
A new function get_last_review_date is added which takes assignid as a parameter and returns the last review deadline of the assignment. The deadline obtained from AssignmentDueDate for the corresponding assignid is stored in last_review_deadline and is returned.

=== Parent Class:ScoreCal ===
ScoreCal stores the score calculated by its sub classes: on_the_fly_cal and LocalDbcal to the database. In the database, a new table localdbscore is created with the schema as explained in section 2.2. Depending upon the deadline_type, object of either on_the_fly_cal or LocalDbcal is created and the appropriate functions within the classes are called.

=== Sub class 1: on_the_fly_cal ===
This is a subclass of class Scorecal contains a method calc_score whose functionality is to compute the holistic score. An object of on_the_fly_cal is called when the current time has not yet surpassed the time stored in last_review_deadline variable which contains the review duedate indicating that the assignment is still ongoing and has not been completed. The individual scores are retrieved from the database ScoreView and is stored in QuestionnaireData from which the holistic score of a student is calculated .

When the user accesses the scores for a review, the current implementation does not store a holistic score but rather calculates the holistic score from the score for every individual criterion. To calculate the total holistic score for a specific round, the individual scores are weighted and added.

This functionality is achieved by on_the_fly_calc.

A snapshot of the system before implementing the changes is shown below.
[[File:rsz_flycur.png]]

The proposed implementation involves computing the holistic score once and storing it in the local_db_scores database for a particular user and for a specified round. The stored value is accessed and obtained instead of computing the holistic score every single time.

[[File:rsz_flyadb.png]]

=== Sub class 2: LocalDbcal ===
This is a subclass of Scorecal and contains a function calc_score in class localDbcal. An object of LocalDbcal is called when the current time has surpassed the time stored in last_review_deadline variable which contains the review due date indicating that the assignment has been completed. This subclass retrieves the score from the database localDbscores for a corresponding student. If the score is not found in the database localDbscores, the function calc_score of on_the_fly_cal class is called to calculate the total from the weighted scores of each question. This calculated score is then inserted into the database.

This score is now returned to the view from where it was called.
[[File:rsz_loccur.png]]

The proposed implementation retrieves the round wise scores from the local_db_scores database and displays the average score once the deadline has passed rather than computing the average of the weighted scores for every access of the page as shown below.

[[File:rsz_locadb.png]]

=== _review_table.html.erb ===
The current implementation of this was to calculate the score and display it which as we know is a time consuming process. It has been changed to check if the current time has crossed the last_review_deadline obtained in assignments.rb and call the corresponding class as required.

If the current date has surpassed the last_review_deadline, it is an indication that the due date has passed and the class localDbcal is called to retrieve a value from the database as mentioned above. On the other hand, on_the_fly_cal is called when the current date has not surpassed the last_review_deadline, indicating that the assignment is ongoing and the holistic score is calculated and passed to the view.

== Design Pattern ==
The ScoreCal superclass has 2 subclasses: OnTheFlyCal and LocalDbCal. ScoreCal acts as an interface to obtain the scores, either from OnTheFlyCal or LocalDbCal depending on the last_review_deadline obtained from the get_last_review_date() in the assignment model. This pattern is similar to strategy pattern where the client is the _review_tble.html.erb, interface is the superclass and the subclasses are called accordingly.

[[File:UseCaseDiagram2.png]]

==Usecase Diagram==

[[File:UseCaseDiagram.png]]

The actors are :
1.Reviewer
2.Reviewee
3.Instructor/TA

The reviewer selects a topic from the list of topics to be reviewed and starts the review. He allots scores out of 5 for every question and the avaerage of this score gets stored in the database when the reviewer clicks on submit. The reviewee views this stored score when he clicks on "view scores".

== Testing ==
The testing for model: on_the_fly_calc is carried out by questionnaire_spec.rb in the spec folder. The minimum and maximum score that an user gives for each criterion is checked.

Two more test cases to check whether the average score of each review falls within a given range:(0,100) will be added.

For LocalDB_calc, the average calculated across round 1 and round 2 will be checked to fall within 0 to 100. These test cases will be added to questionnaire_spec.rb.

File:UseCaseDiagram2.png

2016-12-05T04:49:20Z

Svenka15: uploaded a new version of "File:UseCaseDiagram2.png"

File:UseCaseDiagram2.png

2016-12-05T04:48:43Z

Svenka15: uploaded a new version of "File:UseCaseDiagram2.png"

File:UseCaseDiagram2.png

2016-12-05T04:48:13Z

Svenka15: uploaded a new version of "File:UseCaseDiagram2.png"

File:UseCaseDiagram2.png

2016-12-05T04:48:03Z

Svenka15: uploaded a new version of "File:UseCaseDiagram2.png"

File:UseCaseDiagram2.png

2016-12-05T04:47:20Z

Svenka15: uploaded a new version of "File:UseCaseDiagram2.png"

File:UseCaseDiagram2.png

2016-12-05T04:46:54Z

Svenka15: uploaded a new version of "File:UseCaseDiagram2.png"

CSC/ECE 517 Fall 2016 E1682: Improve score calculation

2016-12-05T04:46:25Z

Svenka15: /* Testing */

E1682. Improve score calculation

== Introduction ==

=== Expertiza ===
Expertiza is an open source project for school assignment management for instructors and students based on the Ruby on Rails framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and word documents. Expertiza provides a dashboard for all the assignments corresponding to a course and provides absolute control to the Instructors and Teaching Assistants. In addition to assignments, it encompasses peer reviews wherein participants are allowed to provide feedback anonymously about each other's work thereby providing scope for the better outcome. The due_date.rb file is responsible for informing the users about the deadline for submission of the each assignment. Due dates in Expertiza have their association with many other components like assignments, reviews etc.

=== Purpose ===
The purpose of the project is to improve the functionality of score calculation. The scores in expertiza were calculated by taking the sum of weighted scores to calculate the total every time it is called. This takes considerable amount of time as there is a calculation involved each time. The methodology behind score calculation in expertiza can be significantly improved. The design behind calculating and storing scores can be tweaked to offer significant performance improvements. To achieve this, it is ideal to store overall holistic stores in addition to individual criterion scores.

=== Problem Statement ===
The current drawback of the expertiza system lies in how the scores are stored: Expertiza stores the scores based on each response to each criterion, but no holistic scores are stored. As a result of this mechanism, the process slows down. This means that if we need to know what score user A gives to user B based on 100, we have to rely on the code to calculate it (since in answers table we only have the score that A gives B on each criterion).

To overcome this bottleneck, two additional mechanisms can be included for handling the holistic scores.

== Overall Description ==
Expertiza currently calculates scores dynamically when a page is called by taking the weighted scores of each question into consideration. This calculation is a time consuming process with a considerable overhead that significantly affects the performance. To solve the issue we propose a solution to store the holistic scores in a database, retrieving it every time it is required. This reduces the calculation that is required every time the score is called. When the user wants to check the scores of a completed assignment, a method localDB_calc is called and expertiza retrieves the scores of the student from the database rather than calculating the total from weighted scores. But, when the scores of an ongoing assignment is required, a method on_the_fly_calc is called that calculates the current score of the user. To determine which method will be invoked(on_the_fly_calc and localDB_calc), the current system time will be compared with last_review_deadline
* If system time is greater than last_review_deadline, indicating that the deadline has passed, the method localDbcal will retrieve the holistic score from the database
* If system time is lesser than last_review_deadline, indicating that the deadline has not passed, the method on_the_fly_cal will calculate the holistic score and display it.

The Dataflow diagram (DFD) for the proposed system is shown below.

[[File:Flowchart12.png|center|frame|flowchart]]

== Tasks Identified ==
The two suggested mechanisms for handling the storage and calculation of holistic scores for peer-reviews, as specified in the requirements document are :
* on_the_fly_calc
* localDB_calc

=== on_the_fly_calc ===
When the assignment is still ongoing , this method is called and it calculates holistic scores over a set of data (in this case, a set of record in answers table, namely the responses from user A to user B on each criterion) and store it in localdbscores. This stored score is retrieved and printed when the user A clicks on the "Your scores" link.

In the current implementation, when a user A wants to view the score given by user B, user A's score(i.e. out of 100) will be calculated everytime using the scores given by user B for each criterion (i.e.. score out of 5).

Handles the calculation of reputations for each reviewer in the case of an ongoing assignment.

=== localDB_calc ===
Once the deadline for an assignment is completed, the method localDB_calc calculates the holistic score over a single db query (in this case, a query would be: “get the score that user A gives user B on assignment 999 on round 2”). The query can also ask to print the average of all the scores in round 1 and round2, this average will be retrieved from localdbscores and printed.

This method handles the calculation of reputations for each reviewer in the case of a finished assignment. (all the reputations are calculated and stored since they are finalized).

=== Database ===
To store the holistic scores when an assignment is completed, a database localdbscores needs to be created. The value from this db is retrieved and displayed when the scores of a completed assignment needs to be viewed. The database Design is shown below.

== Database Design ==
A table localdbscores will be created as:

class CreateLocalDB<ActiveRecord::Migration

def self.up

create_table :localdb_scores do |t|

t.column :id, :integer

t.column :score, :integer

t.column :round, :integer

t.column :type, :string

t.column :reference_id, :integer

end

with id, score, round, type, reference_id as its attributes as shown in the table below

"localdbscores" will have the following scores
{| class="wikitable"
|
|t.integer "id", limit: 24
|id
|Primary Key, Auto generated
|-
|
|t.string "Type", limit: 255
|Type
|Type of score: either final or intermediate
|-
|
|t.integer "Score", limit: 24
|Score
|Total score calculated based on each response to each criterion
|-
|
|t.integer "Round", limit:24
|Round
|The completed round number
|-
|
|t.integer "Reference_id" , limit:45
|Reference_id
|Acts as the foreign Key
|}

== Implementation ==

=== Assignment.rb ===
A new function get_last_review_date is added which takes assignid as a parameter and returns the last review deadline of the assignment. The deadline obtained from AssignmentDueDate for the corresponding assignid is stored in last_review_deadline and is returned.

=== Parent Class:ScoreCal ===
ScoreCal stores the score calculated by its sub classes: on_the_fly_cal and LocalDbcal to the database. In the database, a new table localdbscore is created with the schema as explained in section 2.2. Depending upon the deadline_type, object of either on_the_fly_cal or LocalDbcal is created and the appropriate functions within the classes are called.

=== Sub class 1: on_the_fly_cal ===
This is a subclass of class Scorecal contains a method calc_score whose functionality is to compute the holistic score. An object of on_the_fly_cal is called when the current time has not yet surpassed the time stored in last_review_deadline variable which contains the review duedate indicating that the assignment is still ongoing and has not been completed. The individual scores are retrieved from the database ScoreView and is stored in QuestionnaireData from which the holistic score of a student is calculated .

When the user accesses the scores for a review, the current implementation does not store a holistic score but rather calculates the holistic score from the score for every individual criterion. To calculate the total holistic score for a specific round, the individual scores are weighted and added.

This functionality is achieved by on_the_fly_calc.

A snapshot of the system before implementing the changes is shown below.
[[File:rsz_flycur.png]]

The proposed implementation involves computing the holistic score once and storing it in the local_db_scores database for a particular user and for a specified round. The stored value is accessed and obtained instead of computing the holistic score every single time.

[[File:rsz_flyadb.png]]

=== Sub class 2: LocalDbcal ===
This is a subclass of Scorecal and contains a function calc_score in class localDbcal. An object of LocalDbcal is called when the current time has surpassed the time stored in last_review_deadline variable which contains the review due date indicating that the assignment has been completed. This subclass retrieves the score from the database localDbscores for a corresponding student. If the score is not found in the database localDbscores, the function calc_score of on_the_fly_cal class is called to calculate the total from the weighted scores of each question. This calculated score is then inserted into the database.

This score is now returned to the view from where it was called.
[[File:rsz_loccur.png]]

The proposed implementation retrieves the round wise scores from the local_db_scores database and displays the average score once the deadline has passed rather than computing the average of the weighted scores for every access of the page as shown below.

[[File:rsz_locadb.png]]

=== _review_table.html.erb ===
The current implementation of this was to calculate the score and display it which as we know is a time consuming process. It has been changed to check if the current time has crossed the last_review_deadline obtained in assignments.rb and call the corresponding class as required.

If the current date has surpassed the last_review_deadline, it is an indication that the due date has passed and the class localDbcal is called to retrieve a value from the database as mentioned above. On the other hand, on_the_fly_cal is called when the current date has not surpassed the last_review_deadline, indicating that the assignment is ongoing and the holistic score is calculated and passed to the view.

== Design Pattern ==
The ScoreCal superclass has 2 subclasses: OnTheFlyCal and LocalDbCal. ScoreCal acts as an interface to obtain the scores, either from OnTheFlyCal or LocalDbCal depending on the last_review_deadline obtained from the get_last_review_date() in the assignment model. This pattern is similar to strategy pattern where the client is the _review_tble.html.erb, interface is the superclass and the subclasses are called accordingly.

[[File:UseCaseDiagram2.png]]

==Usecase Diagram==

[[File:UseCaseDiagram2.png]]

The actors are :
1.Reviewer
2.Reviewee
3.Instructor/TA

The reviewer selects a topic from the list of topics to be reviewed and starts the review. He allots scores out of 5 for every question and the avaerage of this score gets stored in the database when the reviewer clicks on submit. The reviewee views this stored score when he clicks on "view scores".

== Testing ==
The testing for model: on_the_fly_calc is carried out by questionnaire_spec.rb in the spec folder. The minimum and maximum score that an user gives for each criterion is checked.

Two more test cases to check whether the average score of each review falls within a given range:(0,100) will be added.

For LocalDB_calc, the average calculated across round 1 and round 2 will be checked to fall within 0 to 100. These test cases will be added to questionnaire_spec.rb.

File:UseCaseDiagram2.png

2016-12-05T03:23:56Z

Svenka15: uploaded a new version of "File:UseCaseDiagram2.png"

File:UseCaseDiagram2.png

2016-12-05T02:52:56Z

Svenka15:

CSC/ECE 517 Fall 2016 E1682: Improve score calculation

2016-12-05T02:52:32Z

Svenka15: /* Design Pattern */

E1682. Improve score calculation

== Introduction ==

=== Purpose ===
The methodology behind score calculation in expertiza can be significantly improved. The design behind calculating and storing scores can be tweaked to offer significant performance improvements. To achieve this, it is ideal to store overall holistic stores in addition to individual criterion scores.

=== Problem Statement ===
The current drawback of the expertiza system lies in how the scores are stored: Expertiza stores the scores based on each response to each criterion, but no holistic scores are stored. As a result of this mechanism, the process slows down. This means that if we need to know what score user A gives to user B based on 100, we have to rely on the code to calculate it (since in answers table we only have the score that A gives B on each criterion).

To overcome this bottleneck, two additional mechanisms can be included for handling the holistic scores.

== Proposed changes ==
The two suggested mechanisms for handling the storage and calculation of holistic scores for peer-reviews, as specified in the requirements document are :
* on_the_fly_calc
* localDB_calc

=== on_the_fly_calc ===
Calculate holistic scores over a set of data (in this case, a set of record in answers table, namely the responses from user A to user B on each criterion) and store it in local_db_scores. This stored score is retrieved and printed when the user A clicks on the "Your scores" link.

In the current implementation, when a user A wants to view the score given by user B, user A's score(i.e. out of 100) will be calculated everytime using the scores given by user B for each criterion (i.e.. score out of 5).

Handles the calculation of reputations for each reviewer in the case of an ongoing assignment.

=== localDB_calc ===
Calculate the holistic score over a single db query (in this case, a query would be: “get the score that user A gives user B on assignment 999 on round 2”). The query can also ask to print the average of all the scores in round 1 and round2, this average will be retrieved from local_db_scores and printed.

Handles the calculation of reputations for each reviewer in the case of a finished assignment. (all the reputations are calculated and stored since they are finalized).

== Design Pattern ==
The ScoreCal superclass has 2 subclasses: OnTheFlyCal and LocalDbCal. ScoreCal acts as an interface to obtain the scores, either from OnTheFlyCal or LocalDbCal depending on the last_review_deadline obtained from the get_last_review_date() in the assignment model. This pattern is similar to strategy pattern where the client is the _review_tble.html.erb, interface is the superclass and the subclasses are called accordingly.
[[File:UseCaseDiagram2.png]]

== Implementation ==

=== Parent Class:ScoreCalc ===
ScoreCalc stores the score calculated by its sub classes: on_the_fly_calc and LocalDBcalc to the database. In the database, a new table local_db_scoresn is created with the schema as explained in section 2.2. Depending upon the deadline_type, object of either on_the_fly_calc or LocalDBcalc is created and the appropriate functions within the classes are called.

==== Database design ====
A table local_db_scores will be created as:

create_table "local_db_scores",force::cascade do|t|

"local_db_scores" will have the following scores
{| class="wikitable"
|
|t.integer "id", limit: 24
|id
|Primary Key, Auto generated
|-
|
|t.string "Type", limit: 255
|Type
|Type of score: either final or intermediate
|-
|
|t.integer "Score", limit: 24
|Score
|Total score calculated based on each response to each criterion
|-
|
|t.integer "Round", limit:24
|Round
|The completed round number
|-
|
|t.integer "Reference_id" , limit:45
|Reference_id
|Acts as the foreign Key
|}

=== Sub class 1: on_the_fly_calc ===
An object of on_the_fly_calc is called when the deadline_type is not "review of review" which means that the assignment is ongoing and has not been completed and stores the scores till the current stage that will change once the assignment passes the deadline

The function compute_total_scores(scores) is used to calculate the total score based on each response to each criterion. The function is as below:

def compute_total_scores(scores)

total=0

self.questionnaires.each{|questionnaire| total+=questionnaire.get_weighted_score(self,scores)}

total

end

The value in variable "total" needs to be stored in local_db_scores under "Score" and will be retrieved by using another function retrieve_total_score to display the total score instead of calculating it every time a user wants to view the scores.

When the user accesses the scores for a review, the current implementation does not store a holistic score but rather calculates the holistic score from the score for every individual criterion. To calculate the total holistic score for a specific round, the individual scores are weighted and added.

This functionality is achieved by on_the_fly_calc.

The current system calculates the holistic score every single time from the individual criterion. A snapshot of the system before implementing the changes is shown below.

[[File:rsz_flycur.png]]

The proposed implementation involves computing the holistic score once and storing it in the local_db_scores database for a particular user and for a specified round. The stored value is accessed and obtained instead of computing the holistic score every single time.

[[File:rsz_flyadb.png]]

=== Sub class 2: LocalDB_calc ===
An object of LocalDB_calc is called when the deadline_type is "review of review" which means that the assignment is completed and stores the final score in the database local_db_scores after computing it rather than computing it every time the score is required.

Function compute_total_scores(scores) is added to the class which calculates the total score based on each response to each criterion. The function(polymorphism) is as below:

def compute_total_scores(scores)

total=0

self.questionnaires.each{|questionnaire| total+=questionnaire.get_weighted_score(self,scores)}

total

end

The value in variable "total" needs to be stored in local_db_scores under "Score" and will be retrieved by using another function retrieve_total_score to display the total score instead of calculating it every time a user wants to view the scores.

The snapshots prior to and post implementation are shown below :

[[File:rsz_loccur.png]]

The proposed implementation retrieves the round wise scores from the local_db_scores database and displays the average score once the deadline has passed rather than computing the average of the weighted scores for every access of the page as shown below.

[[File:rsz_locadb.png]]

The Dataflow diagram (DFD) for the proposed system is shown below.

[[File:Flowchart12.png|center|frame|flowchart]]

== Testing ==
The testing for model: on_the_fly_calc is carried out by questionnaire_spec.rb in the spec folder. The minimum and maximum score that an user gives for each criterion is checked.

Two more test cases to check whether the average score of each review falls within a given range:(0,100) will be added.

For LocalDB_calc, the average calculated across round 1 and round 2 will be checked to fall within 0 to 100. These test cases will be added to questionnaire_spec.rb.

File:UseCaseDiagram.png

2016-12-05T02:52:07Z

Svenka15: uploaded a new version of "File:UseCaseDiagram.png"

File:UseCaseDiagram.png

2016-12-05T02:50:29Z

Svenka15: uploaded a new version of "File:UseCaseDiagram.png"

File:UseCaseDiagram.png

2016-12-05T02:49:20Z

Svenka15: uploaded a new version of "File:UseCaseDiagram.png"

File:UseCaseDiagram.png

2016-12-05T02:48:50Z

Svenka15:

CSC/ECE 517 Fall 2016 E1682: Improve score calculation

2016-12-05T02:48:32Z

Svenka15: /* Design Pattern */

E1682. Improve score calculation

== Introduction ==

=== Purpose ===
The methodology behind score calculation in expertiza can be significantly improved. The design behind calculating and storing scores can be tweaked to offer significant performance improvements. To achieve this, it is ideal to store overall holistic stores in addition to individual criterion scores.

=== Problem Statement ===
The current drawback of the expertiza system lies in how the scores are stored: Expertiza stores the scores based on each response to each criterion, but no holistic scores are stored. As a result of this mechanism, the process slows down. This means that if we need to know what score user A gives to user B based on 100, we have to rely on the code to calculate it (since in answers table we only have the score that A gives B on each criterion).

To overcome this bottleneck, two additional mechanisms can be included for handling the holistic scores.

== Proposed changes ==
The two suggested mechanisms for handling the storage and calculation of holistic scores for peer-reviews, as specified in the requirements document are :
* on_the_fly_calc
* localDB_calc

=== on_the_fly_calc ===
Calculate holistic scores over a set of data (in this case, a set of record in answers table, namely the responses from user A to user B on each criterion) and store it in local_db_scores. This stored score is retrieved and printed when the user A clicks on the "Your scores" link.

In the current implementation, when a user A wants to view the score given by user B, user A's score(i.e. out of 100) will be calculated everytime using the scores given by user B for each criterion (i.e.. score out of 5).

Handles the calculation of reputations for each reviewer in the case of an ongoing assignment.

=== localDB_calc ===
Calculate the holistic score over a single db query (in this case, a query would be: “get the score that user A gives user B on assignment 999 on round 2”). The query can also ask to print the average of all the scores in round 1 and round2, this average will be retrieved from local_db_scores and printed.

Handles the calculation of reputations for each reviewer in the case of a finished assignment. (all the reputations are calculated and stored since they are finalized).

== Design Pattern ==
The ScoreCal superclass has 2 subclasses: OnTheFlyCal and LocalDbCal. ScoreCal acts as an interface to obtain the scores, either from OnTheFlyCal or LocalDbCal depending on the last_review_deadline obtained from the get_last_review_date() in the assignment model. This pattern is similar to strategy pattern where the client is the _review_tble.html.erb, interface is the superclass and the subclasses are called accordingly.
[[File:UseCaseDiagram.png]]

== Implementation ==

=== Parent Class:ScoreCalc ===
ScoreCalc stores the score calculated by its sub classes: on_the_fly_calc and LocalDBcalc to the database. In the database, a new table local_db_scoresn is created with the schema as explained in section 2.2. Depending upon the deadline_type, object of either on_the_fly_calc or LocalDBcalc is created and the appropriate functions within the classes are called.

==== Database design ====
A table local_db_scores will be created as:

create_table "local_db_scores",force::cascade do|t|

"local_db_scores" will have the following scores
{| class="wikitable"
|
|t.integer "id", limit: 24
|id
|Primary Key, Auto generated
|-
|
|t.string "Type", limit: 255
|Type
|Type of score: either final or intermediate
|-
|
|t.integer "Score", limit: 24
|Score
|Total score calculated based on each response to each criterion
|-
|
|t.integer "Round", limit:24
|Round
|The completed round number
|-
|
|t.integer "Reference_id" , limit:45
|Reference_id
|Acts as the foreign Key
|}

=== Sub class 1: on_the_fly_calc ===
An object of on_the_fly_calc is called when the deadline_type is not "review of review" which means that the assignment is ongoing and has not been completed and stores the scores till the current stage that will change once the assignment passes the deadline

The function compute_total_scores(scores) is used to calculate the total score based on each response to each criterion. The function is as below:

def compute_total_scores(scores)

total=0

self.questionnaires.each{|questionnaire| total+=questionnaire.get_weighted_score(self,scores)}

total

end

The value in variable "total" needs to be stored in local_db_scores under "Score" and will be retrieved by using another function retrieve_total_score to display the total score instead of calculating it every time a user wants to view the scores.

When the user accesses the scores for a review, the current implementation does not store a holistic score but rather calculates the holistic score from the score for every individual criterion. To calculate the total holistic score for a specific round, the individual scores are weighted and added.

This functionality is achieved by on_the_fly_calc.

The current system calculates the holistic score every single time from the individual criterion. A snapshot of the system before implementing the changes is shown below.

[[File:rsz_flycur.png]]

The proposed implementation involves computing the holistic score once and storing it in the local_db_scores database for a particular user and for a specified round. The stored value is accessed and obtained instead of computing the holistic score every single time.

[[File:rsz_flyadb.png]]

=== Sub class 2: LocalDB_calc ===
An object of LocalDB_calc is called when the deadline_type is "review of review" which means that the assignment is completed and stores the final score in the database local_db_scores after computing it rather than computing it every time the score is required.

Function compute_total_scores(scores) is added to the class which calculates the total score based on each response to each criterion. The function(polymorphism) is as below:

def compute_total_scores(scores)

total=0

self.questionnaires.each{|questionnaire| total+=questionnaire.get_weighted_score(self,scores)}

total

end

The value in variable "total" needs to be stored in local_db_scores under "Score" and will be retrieved by using another function retrieve_total_score to display the total score instead of calculating it every time a user wants to view the scores.

The snapshots prior to and post implementation are shown below :

[[File:rsz_loccur.png]]

The proposed implementation retrieves the round wise scores from the local_db_scores database and displays the average score once the deadline has passed rather than computing the average of the weighted scores for every access of the page as shown below.

[[File:rsz_locadb.png]]

The Dataflow diagram (DFD) for the proposed system is shown below.

[[File:Flowchart12.png|center|frame|flowchart]]

== Testing ==
The testing for model: on_the_fly_calc is carried out by questionnaire_spec.rb in the spec folder. The minimum and maximum score that an user gives for each criterion is checked.

Two more test cases to check whether the average score of each review falls within a given range:(0,100) will be added.

For LocalDB_calc, the average calculated across round 1 and round 2 will be checked to fall within 0 to 100. These test cases will be added to questionnaire_spec.rb.

CSC/ECE 517 Fall 2016 E1682: Improve score calculation

2016-12-05T02:39:28Z

Svenka15: /* Observer Pattern */

E1682. Improve score calculation

== Introduction ==

=== Purpose ===
The methodology behind score calculation in expertiza can be significantly improved. The design behind calculating and storing scores can be tweaked to offer significant performance improvements. To achieve this, it is ideal to store overall holistic stores in addition to individual criterion scores.

=== Problem Statement ===
The current drawback of the expertiza system lies in how the scores are stored: Expertiza stores the scores based on each response to each criterion, but no holistic scores are stored. As a result of this mechanism, the process slows down. This means that if we need to know what score user A gives to user B based on 100, we have to rely on the code to calculate it (since in answers table we only have the score that A gives B on each criterion).

To overcome this bottleneck, two additional mechanisms can be included for handling the holistic scores.

== Proposed changes ==
The two suggested mechanisms for handling the storage and calculation of holistic scores for peer-reviews, as specified in the requirements document are :
* on_the_fly_calc
* localDB_calc

=== on_the_fly_calc ===
Calculate holistic scores over a set of data (in this case, a set of record in answers table, namely the responses from user A to user B on each criterion) and store it in local_db_scores. This stored score is retrieved and printed when the user A clicks on the "Your scores" link.

In the current implementation, when a user A wants to view the score given by user B, user A's score(i.e. out of 100) will be calculated everytime using the scores given by user B for each criterion (i.e.. score out of 5).

Handles the calculation of reputations for each reviewer in the case of an ongoing assignment.

=== localDB_calc ===
Calculate the holistic score over a single db query (in this case, a query would be: “get the score that user A gives user B on assignment 999 on round 2”). The query can also ask to print the average of all the scores in round 1 and round2, this average will be retrieved from local_db_scores and printed.

Handles the calculation of reputations for each reviewer in the case of a finished assignment. (all the reputations are calculated and stored since they are finalized).

== Design Pattern ==
The ScoreCal superclass has 2 subclasses: OnTheFlyCal and LocalDbCal. ScoreCal acts as an interface to obtain the scores, either from OnTheFlyCal or LocalDbCal depending on the last_review_deadline obtained from the get_last_review_date() in the assignment model. This pattern is similar to strategy pattern where the client is the _review_tble.html.erb, interface is the superclass and the subclasses are called accordingly.

== Implementation ==

=== Parent Class:ScoreCalc ===
ScoreCalc stores the score calculated by its sub classes: on_the_fly_calc and LocalDBcalc to the database. In the database, a new table local_db_scoresn is created with the schema as explained in section 2.2. Depending upon the deadline_type, object of either on_the_fly_calc or LocalDBcalc is created and the appropriate functions within the classes are called.

==== Database design ====
A table local_db_scores will be created as:

create_table "local_db_scores",force::cascade do|t|

"local_db_scores" will have the following scores
{| class="wikitable"
|
|t.integer "id", limit: 24
|id
|Primary Key, Auto generated
|-
|
|t.string "Type", limit: 255
|Type
|Type of score: either final or intermediate
|-
|
|t.integer "Score", limit: 24
|Score
|Total score calculated based on each response to each criterion
|-
|
|t.integer "Round", limit:24
|Round
|The completed round number
|-
|
|t.integer "Reference_id" , limit:45
|Reference_id
|Acts as the foreign Key
|}

=== Sub class 1: on_the_fly_calc ===
An object of on_the_fly_calc is called when the deadline_type is not "review of review" which means that the assignment is ongoing and has not been completed and stores the scores till the current stage that will change once the assignment passes the deadline

The function compute_total_scores(scores) is used to calculate the total score based on each response to each criterion. The function is as below:

def compute_total_scores(scores)

total=0

self.questionnaires.each{|questionnaire| total+=questionnaire.get_weighted_score(self,scores)}

total

end

The value in variable "total" needs to be stored in local_db_scores under "Score" and will be retrieved by using another function retrieve_total_score to display the total score instead of calculating it every time a user wants to view the scores.

When the user accesses the scores for a review, the current implementation does not store a holistic score but rather calculates the holistic score from the score for every individual criterion. To calculate the total holistic score for a specific round, the individual scores are weighted and added.

This functionality is achieved by on_the_fly_calc.

The current system calculates the holistic score every single time from the individual criterion. A snapshot of the system before implementing the changes is shown below.

[[File:rsz_flycur.png]]

The proposed implementation involves computing the holistic score once and storing it in the local_db_scores database for a particular user and for a specified round. The stored value is accessed and obtained instead of computing the holistic score every single time.

[[File:rsz_flyadb.png]]

=== Sub class 2: LocalDB_calc ===
An object of LocalDB_calc is called when the deadline_type is "review of review" which means that the assignment is completed and stores the final score in the database local_db_scores after computing it rather than computing it every time the score is required.

Function compute_total_scores(scores) is added to the class which calculates the total score based on each response to each criterion. The function(polymorphism) is as below:

def compute_total_scores(scores)

total=0

self.questionnaires.each{|questionnaire| total+=questionnaire.get_weighted_score(self,scores)}

total

end

The value in variable "total" needs to be stored in local_db_scores under "Score" and will be retrieved by using another function retrieve_total_score to display the total score instead of calculating it every time a user wants to view the scores.

The snapshots prior to and post implementation are shown below :

[[File:rsz_loccur.png]]

The proposed implementation retrieves the round wise scores from the local_db_scores database and displays the average score once the deadline has passed rather than computing the average of the weighted scores for every access of the page as shown below.

[[File:rsz_locadb.png]]

The Dataflow diagram (DFD) for the proposed system is shown below.

[[File:Flowchart12.png|center|frame|flowchart]]

== Testing ==
The testing for model: on_the_fly_calc is carried out by questionnaire_spec.rb in the spec folder. The minimum and maximum score that an user gives for each criterion is checked.

Two more test cases to check whether the average score of each review falls within a given range:(0,100) will be added.

For LocalDB_calc, the average calculated across round 1 and round 2 will be checked to fall within 0 to 100. These test cases will be added to questionnaire_spec.rb.

CSC/ECE 517 Fall 2016 E1682: Improve score calculation

2016-11-11T19:43:34Z

Svenka15: /* Sub class 2: LocalDB_calc */

CSC/ECE 517 Fall 2016 E1682: Improve score calculation

2016-11-11T19:43:08Z

Svenka15: /* LocalDBCalc: */

CSC/ECE 517 Fall 2016 E1682: Improve score calculation

2016-11-11T19:42:46Z

Svenka15:

CSC/ECE 517 Fall 2016 E1682: Improve score calculation

2016-11-09T19:51:56Z

Svenka15:

E1682. Improve score calculation
=== LocalDBCalc: ===
Calculate the holistic score over a single db query (in this case, a query would be: “get the score that user A gives user B on assignment 999 on round 2”)

Handles the calculation of reputations for each reviewer in the case of a finished assignment. (all the reputations are calculated and stored since they are finalized)

== Implementation ==

=== Parent Class:ScoreCalc ===
ScoreCalc stores the score calculated by its sub classes: on_the_fly_calc and LocalDBcalc to the database. In the database, a new table local_db_scoresn is created with the schema as explained in section 2.2. Depending upon the deadline_type, object of either on_the_fly_calc or LocalDBcalc is created and the appropriate functions within the classes are called.

==== Database design ====
A table local_db_scores will be created as:

create_table "local_db_scores",force::cascade do|t|

"local_db_scores" will have the following scores
{| class="wikitable"
|
|t.integer "id", limit: 24
|id
|Primary Key, Auto generated
|-
|
|t.string "Type", limit: 255
|Type
|Type of score: either final or intermediate
|-
|
|t.integer "Score", limit: 24
|Score
|Total score calculated based on each response to each criterion
|-
|
|t.integer "Round", limit:24
|Round
|The completed round number
|-
|
|t.integer "Reference_id" , limit:45
|Reference_id
|Acts as the foreign Key
|}

=== Sub class 1: on_the_fly_calc ===
An object of on_the_fly_calc is called when the deadline_type is not "review of review" which means that the assignment is ongoing and has not been completed and stores the scores till the current stage that will change once the assignment passes the deadline

The function compute_total_scores(scores) is used to calculate the total score based on each response to each criterion. The function is as below:

def compute_total_scores(scores)

total=0

self.questionnaires.each{|questionnaire| total+=questionnaire.get_weighted_score(self,scores)}

total

end

The value in variable "total" needs to be stored in local_db_scores under "Score" and will be retrieved by using another function retrieve_total_score to display the total score instead of calculating it every time a user wants to view the scores.

=== Sub class 2: LocalDB_calc ===
An object of LocalDB_calc is called when the deadline_type is "review of review" which means that the assignment is completed and stores the final score in the database local_db_scores after computing it rather than computing it every time the score is required.

Function compute_total_scores(scores) is added to the class which calculates the total score based on each response to each criterion. The function(polymorphism) is as below:

def compute_total_scores(scores)

total=0

self.questionnaires.each{|questionnaire| total+=questionnaire.get_weighted_score(self,scores)}

total

end

The value in variable "total" needs to be stored in local_db_scores under "Score" and will be retrieved by using another function retrieve_total_score to display the total score instead of calculating it every time a user wants to view the scores.
[[File:Flowchart12.png]]

User:Svenka15

2016-10-29T06:34:22Z

Svenka15: /* 2. Use find_by instead of dynamic find_by_name. */

CSC/ECE 517 Fall 2016/E1672
Remove duplicated code in feature tests

== Introduction ==
This project mainly focuses on removing duplicated codes in feature tests and using Code Climate Chrome Extension and Travis CI to evaluate the modified code.

=== Background ===
Expertiza is an educational web application created and maintained by the joint efforts of the students and the faculty at NCSU. It’s an open source project developed on Ruby on Rails platform and the code is available on Github. It's a web portal used by students for assignment submission and team selection among other activities as listed below
* It allows students to submit their work- either a wiki page or a deployed link.
* Review other’s work and grade them.
* Make changes according to user reviews
* Allows the instructor to create new assignments and customize new or existing assignments.
* Allows the instructor to create a list of topics the students can sign up for.
* Students can bid for topics of their interest by assigning priorities to the topics
* Students can form teams in Expertiza to work on various projects and assignments.

=== Project Description ===
The following is an Expertiza based OSS project which deals with the files in spec/features folder, to be specific: assignment_creation_spec.rb, instructor_interface_spec.rb, questionnaire_spec.rb, quiz_spec.rb, delayed_mailer_spec.rb and scheduled_task_spec.rb. It focuses on removing the duplicate codes, following DRY concepts, change DateTime class object invocation, etc. The goal of this project is to attempt to make this part of the application easier to read, maintain and improve the quality of the code. The existing redundant codes, use of long methods, incorrect method invocation and other errors are pointed out by the Code climate extension which are modified in this project. The code climate extension also provides a rating for all files as well as an overall score for the entire application, to help us make proper modifications.

=== Problem Statement ===
The following tasks were accomplished in this project:

Install the Code Climate Chrome Extension, and when you go to Expertiza repo, you will see the extension will highlight the duplication code. Improved the clarity of code by improving the variable and parameter names. Remove the duplicated code by extracting a new method, moving code to before(:each) block, etc. Long character strings were taken and given appropriate names. Improve the Code Climate rating of classes whose original rating is F. Do not delete existing test cases and keep them pass TravisCI after refactoring. Files modified in current project

Six files in spec/features that are to be modified are :
* [https://github.com/expertiza/expertiza/blob/master/spec/features/assignment_creation_spec.rb assignment_creation_spec.rb]
* [https://github.com/expertiza/expertiza/blob/master/spec/features/instructor_interface_spec.rb instructor_interface_spec.rb]
* [https://github.com/expertiza/expertiza/blob/master/spec/features/questionnaire_spec.rb questionnaire_spec.rb]
* [https://github.com/expertiza/expertiza/blob/master/spec/features/quiz_spec.rb quiz_spec.rb]
* [https://github.com/expertiza/expertiza/blob/master/spec/features/delayed_mailer_spec.rb delayed_mailer_spec.rb]
* [https://github.com/expertiza/expertiza/blob/master/spec/features/scheduled_task_spec.rb scheduled_task_spec.rb]

=== '''Code Climate''' ===
Code Climate is a open and extensible platform for static analysis and works on the principle: healthy code ships faster. Code climate platform leads to healthier code by clear and actionable static analysis regardless of the technology used.

The static analysis engines and all the static analysis code used are published under Open Source licenses. This paves way for the users to dig in and understand how the code is being evaluated.

The rating and GPA provided by Code Climate extension is an estimate of the quality of the code. The ratings vary from A to F and the GPA varies from 1 to 5. Code with a higher GPA is expected to have higher quality.

'''Getting started with Code Climate'''

To get started with Code Climate the following 4 steps are to be followed
* [https://docs.codeclimate.com/docs/getting-started-with-code-climate Create an account with Code Climate and add the first repository]
* [https://docs.codeclimate.com/docs/getting-started-with-code-climate Configure and customise your analysis]
* [https://docs.codeclimate.com/docs/workflow Add Code Climate to your work flow]
* [https://docs.codeclimate.com/docs/getting-started-test-coverage Set up test coverage]

==== User perspective ====
* [https://codeclimate.com Download Code climate] and allow the extension to be used with your browser
* Sign into your Github account and add the repository to be checked by clicking the extension from your browser.
[[File:Code Climate.png]]
* Manually add the repository from the dashboard.
[[File:Dash board.png]]

== List of changes ==

Similar code found in 1 other location (mass = 50) Duplicated code can lead to software that is hard to understand and difficult to change. Refactorings -Extract Method,Extract Class,Form Template Method,Introduce Null Object,Pull Up Method,Pull Up Field,Substitute Algorithm Use find_by instead of dynamic find_by_name. Do not use DateTime.now without zone.

The files in the project include duplicated code which violates DRY concept and is to be removed. The various changes that can be made to the files are explained.

=== 1. Similar code found in 1 other location ===

When there is duplicated code within the file or between files of the same project, the code can be created as a function with variables that are assigned based on the different cases. This function can be called wherever the functionality is required to be fulfilled and also by passing the required parameters. This makes the code more readable and in fact, much easier to understand. By writing similar lines of code again and again, we only increase the number of lines and decrease the efficiency of the code.For example, the following error was pointed out by Code Climate Extension in [https://github.com/expertiza/expertiza/blob/master/spec/features/assignment_creation_spec.rb assignment_creation_spec.rb]

Similar code was found
[[File:Similarcode.png|thumb|code similarity]]

New functions were added to remove duplicates

[[File:Similarcode2.png|thumb|code similarity]]

=== 2. Use find_by instead of dynamic find_by_name. ===
In the different spec files, find_by_name function is used to identify variables according to their name. find_by can be used to match the argument with the variable directly, instead of making sure if the function parameters are matching with the given file.

For example in file [https://github.com/expertiza/expertiza/blob/master/spec/features/assignment_creation_spec.rb assignment_creation_spec.rb], find_by_name was detected:

[[File:Find by nameee.png]]

This was corrected to find_by

[[File:Find by name.png]]

The grade of the code improved when find_by_name was changed to find_by.

=== 3. Refactoring - Extract Method,Extract Class,Form Template Method,Introduce Null Object,Pull Up Method,Pull Up Field,Substitute Algorithm ===

Refactoring is the process of improving a source code without altering the external behaviour. It improves Extensibility and Maintainability. We can implement refactoring using one of the methods mentioned above.

A common code that is present across files can be added to rails_helper.rb and called across files when needed. One example of this is the cod in integration_test_instructor_interface function which was typed out without being encapsulated as a function in both [https://github.com/expertiza/expertiza/blob/master/spec/features/instructor_interface_spec.rb instructor_interface_spec.rb] and [https://github.com/expertiza/expertiza/blob/master/spec/features/questionnaire_spec.rb questionnaire_spec.rb].
[[File:Rails helper.rb.png]]
A common definition was added to rails_helper.rb for the integration_test_instructor_interface function as shown below

[[File:Rails helper.rb modified.png]]

=== 4. Useless Assignments of Variables ===

Same variables may be assigned values through the program which may not be used later. These assignments are said to be useless as the new value never gets used anywhere. These lines can be removed from the program as they do not implement anything and are of no use.

[[File:Uselessassignment.png]]

And another example:

[[File:Useless.png|thumb|Useless assignment]]

These assignments were removed

=== 5.Do not use DateTime.now without Time.zone.now ===

To use the current time in the program, we need use Time.zone.now instead of DateTime.now. The latter uses the system's date and time as it is part of the Ruby standard library. It is better to use Time.zone.now because it returns the time that is corrected according to our corresponding Time zone as it has been extended by ActiveSupport. Example is as given :

[[File:Timezone.png]]

[[File:Timelocal.png]]

=== 6. Indentation ===

Programs need to be indented properly. 2 White spaces are used to write statements within any block. Accordingly, the end of the block statements also follow the corresponding white spaces. Indentation improves code readability and makes it easy for the user/programmer to understand what happens within the program.

===Results and grades===

The grades of the 6 files changed after the duplicates were removed
Before modification :
[[File:Originalgrades.png]]
After modification:
[[File:Modifiedgrades.png]]

File:Find by nameee.png

2016-10-29T06:34:08Z

Svenka15:

File:Find by name1.png

2016-10-29T06:33:03Z

Svenka15:

File:Find by.png

2016-10-29T06:29:28Z

Svenka15: uploaded a new version of "File:Find by.png": correction

displays the changes of done in E1642

File:Find by.png

2016-10-29T06:28:18Z

Svenka15: uploaded a new version of "File:Find by.png"

displays the changes of done in E1642

User:Svenka15

2016-10-29T06:24:52Z

Svenka15:

CSC/ECE 517 Fall 2016/E1672
Remove duplicated code in feature tests

== Introduction ==
This project mainly focuses on removing duplicated codes in feature tests and using Code Climate Chrome Extension and Travis CI to evaluate the modified code.

=== Background ===
Expertiza is an educational web application created and maintained by the joint efforts of the students and the faculty at NCSU. It’s an open source project developed on Ruby on Rails platform and the code is available on Github. It's a web portal used by students for assignment submission and team selection among other activities as listed below
* It allows students to submit their work- either a wiki page or a deployed link.
* Review other’s work and grade them.
* Make changes according to user reviews
* Allows the instructor to create new assignments and customize new or existing assignments.
* Allows the instructor to create a list of topics the students can sign up for.
* Students can bid for topics of their interest by assigning priorities to the topics
* Students can form teams in Expertiza to work on various projects and assignments.

=== Project Description ===
The following is an Expertiza based OSS project which deals with the files in spec/features folder, to be specific: assignment_creation_spec.rb, instructor_interface_spec.rb, questionnaire_spec.rb, quiz_spec.rb, delayed_mailer_spec.rb and scheduled_task_spec.rb. It focuses on removing the duplicate codes, following DRY concepts, change DateTime class object invocation, etc. The goal of this project is to attempt to make this part of the application easier to read, maintain and improve the quality of the code. The existing redundant codes, use of long methods, incorrect method invocation and other errors are pointed out by the Code climate extension which are modified in this project. The code climate extension also provides a rating for all files as well as an overall score for the entire application, to help us make proper modifications.

=== Problem Statement ===
The following tasks were accomplished in this project:

Install the Code Climate Chrome Extension, and when you go to Expertiza repo, you will see the extension will highlight the duplication code. Improved the clarity of code by improving the variable and parameter names. Remove the duplicated code by extracting a new method, moving code to before(:each) block, etc. Long character strings were taken and given appropriate names. Improve the Code Climate rating of classes whose original rating is F. Do not delete existing test cases and keep them pass TravisCI after refactoring. Files modified in current project

Six files in spec/features that are to be modified are :
* [https://github.com/expertiza/expertiza/blob/master/spec/features/assignment_creation_spec.rb assignment_creation_spec.rb]
* [https://github.com/expertiza/expertiza/blob/master/spec/features/instructor_interface_spec.rb instructor_interface_spec.rb]
* [https://github.com/expertiza/expertiza/blob/master/spec/features/questionnaire_spec.rb questionnaire_spec.rb]
* [https://github.com/expertiza/expertiza/blob/master/spec/features/quiz_spec.rb quiz_spec.rb]
* [https://github.com/expertiza/expertiza/blob/master/spec/features/delayed_mailer_spec.rb delayed_mailer_spec.rb]
* [https://github.com/expertiza/expertiza/blob/master/spec/features/scheduled_task_spec.rb scheduled_task_spec.rb]

=== '''Code Climate''' ===
Code Climate is a open and extensible platform for static analysis and works on the principle: healthy code ships faster. Code climate platform leads to healthier code by clear and actionable static analysis regardless of the technology used.

The static analysis engines and all the static analysis code used are published under Open Source licenses. This paves way for the users to dig in and understand how the code is being evaluated.

The rating and GPA provided by Code Climate extension is an estimate of the quality of the code. The ratings vary from A to F and the GPA varies from 1 to 5. Code with a higher GPA is expected to have higher quality.

'''Getting started with Code Climate'''

To get started with Code Climate the following 4 steps are to be followed
* [https://docs.codeclimate.com/docs/getting-started-with-code-climate Create an account with Code Climate and add the first repository]
* [https://docs.codeclimate.com/docs/getting-started-with-code-climate Configure and customise your analysis]
* [https://docs.codeclimate.com/docs/workflow Add Code Climate to your work flow]
* [https://docs.codeclimate.com/docs/getting-started-test-coverage Set up test coverage]

==== User perspective ====
* [https://codeclimate.com Download Code climate] and allow the extension to be used with your browser
* Sign into your Github account and add the repository to be checked by clicking the extension from your browser.
[[File:Code Climate.png]]
* Manually add the repository from the dashboard.
[[File:Dash board.png]]

== List of changes ==

Similar code found in 1 other location (mass = 50) Duplicated code can lead to software that is hard to understand and difficult to change. Refactorings -Extract Method,Extract Class,Form Template Method,Introduce Null Object,Pull Up Method,Pull Up Field,Substitute Algorithm Use find_by instead of dynamic find_by_name. Do not use DateTime.now without zone.

The files in the project include duplicated code which violates DRY concept and is to be removed. The various changes that can be made to the files are explained.

=== 1. Similar code found in 1 other location ===

When there is duplicated code within the file or between files of the same project, the code can be created as a function with variables that are assigned based on the different cases. This function can be called wherever the functionality is required to be fulfilled and also by passing the required parameters. This makes the code more readable and in fact, much easier to understand. By writing similar lines of code again and again, we only increase the number of lines and decrease the efficiency of the code.For example, the following error was pointed out by Code Climate Extension in [https://github.com/expertiza/expertiza/blob/master/spec/features/assignment_creation_spec.rb assignment_creation_spec.rb]

Similar code was found
[[File:Similarcode.png|thumb|code similarity]]

New functions were added to remove duplicates

[[File:Similarcode2.png|thumb|code similarity]]

=== 2. Use find_by instead of dynamic find_by_name. ===
In the different spec files, find_by_name function is used to identify variables according to their name. find_by can be used to match the argument with the variable directly, instead of making sure if the function parameters are matching with the given file.

For example in file [https://github.com/expertiza/expertiza/blob/master/spec/features/assignment_creation_spec.rb assignment_creation_spec.rb], find_by_name was detected:

[[File:Find_by_name.png]]

This was corrected to find_by

[[File:Find by.png]]

The grade of the code improved when find_by_name was changed to find_by.

=== 3. Refactoring - Extract Method,Extract Class,Form Template Method,Introduce Null Object,Pull Up Method,Pull Up Field,Substitute Algorithm ===

Refactoring is the process of improving a source code without altering the external behaviour. It improves Extensibility and Maintainability. We can implement refactoring using one of the methods mentioned above.

A common code that is present across files can be added to rails_helper.rb and called across files when needed. One example of this is the cod in integration_test_instructor_interface function which was typed out without being encapsulated as a function in both [https://github.com/expertiza/expertiza/blob/master/spec/features/instructor_interface_spec.rb instructor_interface_spec.rb] and [https://github.com/expertiza/expertiza/blob/master/spec/features/questionnaire_spec.rb questionnaire_spec.rb].
[[File:Rails helper.rb.png]]
A common definition was added to rails_helper.rb for the integration_test_instructor_interface function as shown below

[[File:Rails helper.rb modified.png]]

=== 4. Useless Assignments of Variables ===

Same variables may be assigned values through the program which may not be used later. These assignments are said to be useless as the new value never gets used anywhere. These lines can be removed from the program as they do not implement anything and are of no use.

[[File:Uselessassignment.png]]

And another example:

[[File:Useless.png|thumb|Useless assignment]]

These assignments were removed

=== 5.Do not use DateTime.now without Time.zone.now ===

To use the current time in the program, we need use Time.zone.now instead of DateTime.now. The latter uses the system's date and time as it is part of the Ruby standard library. It is better to use Time.zone.now because it returns the time that is corrected according to our corresponding Time zone as it has been extended by ActiveSupport. Example is as given :

[[File:Timezone.png]]

[[File:Timelocal.png]]

=== 6. Indentation ===

Programs need to be indented properly. 2 White spaces are used to write statements within any block. Accordingly, the end of the block statements also follow the corresponding white spaces. Indentation improves code readability and makes it easy for the user/programmer to understand what happens within the program.

===Results and grades===

The grades of the 6 files changed after the duplicates were removed
Before modification :
[[File:Originalgrades.png]]
After modification:
[[File:Modifiedgrades.png]]

User:Svenka15

2016-10-29T06:23:04Z

Svenka15: /* 2. Use find_by instead of dynamic find_by_name. */

CSC/ECE 517 Fall 2016/E1672
Remove duplicated code in feature tests

== Introduction ==
This project mainly focuses on removing duplicated codes in feature tests and using Code Climate Chrome Extension and Travis CI to evaluate the modified code.

=== Background ===
Expertiza is an educational web application created and maintained by the joint efforts of the students and the faculty at NCSU. It’s an open source project developed on Ruby on Rails platform and the code is available on Github. It's a web portal used by students for assignment submission and team selection among other activities as listed below
* It allows students to submit their work- either a wiki page or a deployed link.
* Review other’s work and grade them.
* Make changes according to user reviews
* Allows the instructor to create new assignments and customize new or existing assignments.
* Allows the instructor to create a list of topics the students can sign up for.
* Students can bid for topics of their interest by assigning priorities to the topics
* Students can form teams in Expertiza to work on various projects and assignments.

=== Project Description ===
The following is an Expertiza based OSS project which deals with the files in spec/features folder, to be specific: assignment_creation_spec.rb, instructor_interface_spec.rb, questionnaire_spec.rb, quiz_spec.rb, delayed_mailer_spec.rb and scheduled_task_spec.rb. It focuses on removing the duplicate codes, following DRY concepts, change DateTime class object invocation, etc. The goal of this project is to attempt to make this part of the application easier to read, maintain and improve the quality of the code. The existing redundant codes, use of long methods, incorrect method invocation and other errors are pointed out by the Code climate extension which are modified in this project. The code climate extension also provides a rating for all files as well as an overall score for the entire application, to help us make proper modifications.

=== Problem Statement ===
The following tasks were accomplished in this project:

Install the Code Climate Chrome Extension, and when you go to Expertiza repo, you will see the extension will highlight the duplication code. Improved the clarity of code by improving the variable and parameter names. Remove the duplicated code by extracting a new method, moving code to before(:each) block, etc. Long character strings were taken and given appropriate names. Improve the Code Climate rating of classes whose original rating is F. Do not delete existing test cases and keep them pass TravisCI after refactoring. Files modified in current project

Six files in spec/features that are to be modified are :
* [https://github.com/expertiza/expertiza/blob/master/spec/features/assignment_creation_spec.rb assignment_creation_spec.rb]
* [https://github.com/expertiza/expertiza/blob/master/spec/features/instructor_interface_spec.rb instructor_interface_spec.rb]
* [https://github.com/expertiza/expertiza/blob/master/spec/features/questionnaire_spec.rb questionnaire_spec.rb]
* [https://github.com/expertiza/expertiza/blob/master/spec/features/quiz_spec.rb quiz_spec.rb]
* [https://github.com/expertiza/expertiza/blob/master/spec/features/delayed_mailer_spec.rb delayed_mailer_spec.rb]
* [https://github.com/expertiza/expertiza/blob/master/spec/features/scheduled_task_spec.rb scheduled_task_spec.rb]

=== '''Code Climate''' ===
Code Climate is a open and extensible platform for static analysis and works on the principle: healthy code ships faster. Code climate platform leads to healthier code by clear and actionable static analysis regardless of the technology used.

The static analysis engines and all the static analysis code used are published under Open Source licenses. This paves way for the users to dig in and understand how the code is being evaluated.

The rating and GPA provided by Code Climate extension is an estimate of the quality of the code. The ratings vary from A to F and the GPA varies from 1 to 5. Code with a higher GPA is expected to have higher quality.

'''Getting started with Code Climate'''

To get started with Code Climate the following 4 steps are to be followed
* [https://docs.codeclimate.com/docs/getting-started-with-code-climate Create an account with Code Climate and add the first repository]
* [https://docs.codeclimate.com/docs/getting-started-with-code-climate Configure and customise your analysis]
* [https://docs.codeclimate.com/docs/workflow Add Code Climate to your work flow]
* [https://docs.codeclimate.com/docs/getting-started-test-coverage Set up test coverage]

==== User perspective ====
* [https://codeclimate.com Download Code climate] and allow the extension to be used with your browser
* Sign into your Github account and add the repository to be checked by clicking the extension from your browser.
[[File:Code Climate.png]]
* Manually add the repository from the dashboard.
[[File:Dash board.png]]

== List of changes ==
Similar code found in 1 other location (mass = 50) Duplicated code can lead to software that is hard to understand and difficult to change. Refactorings -Extract Method,Extract Class,Form Template Method,Introduce Null Object,Pull Up Method,Pull Up Field,Substitute Algorithm Use find_by instead of dynamic find_by_name. Do not use DateTime.now without zone.

The files in the project include duplicated code which violates DRY concept and is to be removed. The various changes that can be made to the files are explained.

=== 1. Similar code found in 1 other location ===
When there is duplicated code within the file or between files of the same project, the code can be created as a function with variables that are assigned based on the different cases. This function can be called wherever the functionality is required to be fulfilled and also by passing the required parameters. This makes the code more readable and in fact, much easier to understand. By writing similar lines of code again and again, we only increase the number of lines and decrease the efficiency of the code.For example, the following error was pointed out by Code Climate Extension in [https://github.com/expertiza/expertiza/blob/master/spec/features/assignment_creation_spec.rb assignment_creation_spec.rb]

Similar code was found
[[File:Similarcode.png|thumb|code similarity]]

New functions were added to remove duplicates

[[File:Similarcode2.png|thumb|code similarity]]

=== 2. Use find_by instead of dynamic find_by_name. ===
In the different spec files, find_by_name function is used to identify variables according to their name. find_by can be used to match the argument with the variable directly, instead of making sure if the function parameters are matching with the given file.

For example in file [https://github.com/expertiza/expertiza/blob/master/spec/features/assignment_creation_spec.rb assignment_creation_spec.rb], find_by_name was detected:

[[File:Find_by_name.png]]

This was corrected to find_by

[[File:Find by.png]]

The grade of the code improved when find_by_name was changed to find_by.

=== 3. Refactoring - Extract Method,Extract Class,Form Template Method,Introduce Null Object,Pull Up Method,Pull Up Field,Substitute Algorithm ===

Refactoring is the process of improving a source code without altering the external behaviour. It improves Extensibility and Maintainability. We can implement refactoring using one of the methods mentioned above.

A common code that is present across files can be added to rails_helper.rb and called across files when needed. One example of this is the cod in integration_test_instructor_interface function which was typed out without being encapsulated as a function in both [https://github.com/expertiza/expertiza/blob/master/spec/features/instructor_interface_spec.rb instructor_interface_spec.rb] and [https://github.com/expertiza/expertiza/blob/master/spec/features/questionnaire_spec.rb questionnaire_spec.rb].
[[File:Rails helper.rb.png]]
A common definition was added to rails_helper.rb for the integration_test_instructor_interface function as shown below
[[File:Rails helper.rb modified.png]]

=== 4. Useless Assignments of Variables ===

Same variables may be assigned values through the program which may not be used later. These assignments are said to be useless as the new value never gets used anywhere. These lines can be removed from the program as they do not implement anything and are of no use.
[[File:Uselessassignment.png]]
And another example:
[[File:Useless.png|thumb|Useless assignment]]
These assignenments were removed

=== 5.Do not use DateTime.now without Time.zone.now ===

To use the current time in the program, we need use Time.zone.now instead of DateTime.now. The latter uses the system's date and time as it is part of the Ruby standard library. It is better to use Time.zone.now because it returns the time that is corrected according to our corresponding Time zone as it has been extended by ActiveSupport. Example is as given :
[[File:Timezone.png]]
[[File:Timelocal.png]]

=== 6. Indentation ===

Programs need to be indented properly. 2 White spaces are used to write statements within any block. Accordingly, the end of the block statements also follow the corresponding white spaces. Indentation improves code readability and makes it easy for the user/programmer to understand what happens within the program.

===Results and grades===

The grades of the 6 files changed after the duplicates were removed
Before modification :
[[File:Originalgrades.png]]
After modification:
[[File:Modifiedgrades.png]]

File:Similarcode.png

2016-10-29T06:20:40Z

Svenka15: uploaded a new version of "File:Similarcode.png"

File:Modifiedgrades.png

2016-10-29T06:19:18Z

Svenka15: uploaded a new version of "File:Modifiedgrades.png"

File:Originalgrades.png

2016-10-29T06:18:52Z

Svenka15: uploaded a new version of "File:Originalgrades.png"

File:Modifiedgrades.png

2016-10-29T06:17:33Z

Svenka15:

File:Originalgrades.png

2016-10-29T06:16:56Z

Svenka15:

User:Svenka15

2016-10-29T06:16:40Z

Svenka15: /* Results and grades */

CSC/ECE 517 Fall 2016/E1672
Remove duplicated code in feature tests

== Introduction ==
This project mainly focuses on removing duplicated codes in feature tests and using Code Climate Chrome Extension and Travis CI to evaluate the modified code.

=== Background ===
Expertiza is an educational web application created and maintained by the joint efforts of the students and the faculty at NCSU. It’s an open source project developed on Ruby on Rails platform and the code is available on Github. It's a web portal used by students for assignment submission and team selection among other activities as listed below
* It allows students to submit their work- either a wiki page or a deployed link.
* Review other’s work and grade them.
* Make changes according to user reviews
* Allows the instructor to create new assignments and customize new or existing assignments.
* Allows the instructor to create a list of topics the students can sign up for.
* Students can bid for topics of their interest by assigning priorities to the topics
* Students can form teams in Expertiza to work on various projects and assignments.

=== Project Description ===
The following is an Expertiza based OSS project which deals with the files in spec/features folder, to be specific: assignment_creation_spec.rb, instructor_interface_spec.rb, questionnaire_spec.rb, quiz_spec.rb, delayed_mailer_spec.rb and scheduled_task_spec.rb. It focuses on removing the duplicate codes, following DRY concepts, change DateTime class object invocation, etc. The goal of this project is to attempt to make this part of the application easier to read, maintain and improve the quality of the code. The existing redundant codes, use of long methods, incorrect method invocation and other errors are pointed out by the Code climate extension which are modified in this project. The code climate extension also provides a rating for all files as well as an overall score for the entire application, to help us make proper modifications.

=== Problem Statement ===
The following tasks were accomplished in this project:

Install the Code Climate Chrome Extension, and when you go to Expertiza repo, you will see the extension will highlight the duplication code. Improved the clarity of code by improving the variable and parameter names. Remove the duplicated code by extracting a new method, moving code to before(:each) block, etc. Long character strings were taken and given appropriate names. Improve the Code Climate rating of classes whose original rating is F. Do not delete existing test cases and keep them pass TravisCI after refactoring. Files modified in current project

Six files in spec/features that are to be modified are :
* [https://github.com/expertiza/expertiza/blob/master/spec/features/assignment_creation_spec.rb assignment_creation_spec.rb]
* [https://github.com/expertiza/expertiza/blob/master/spec/features/instructor_interface_spec.rb instructor_interface_spec.rb]
* [https://github.com/expertiza/expertiza/blob/master/spec/features/questionnaire_spec.rb questionnaire_spec.rb]
* [https://github.com/expertiza/expertiza/blob/master/spec/features/quiz_spec.rb quiz_spec.rb]
* [https://github.com/expertiza/expertiza/blob/master/spec/features/delayed_mailer_spec.rb delayed_mailer_spec.rb]
* [https://github.com/expertiza/expertiza/blob/master/spec/features/scheduled_task_spec.rb scheduled_task_spec.rb]

=== '''Code Climate''' ===
Code Climate is a open and extensible platform for static analysis and works on the principle: healthy code ships faster. Code climate platform leads to healthier code by clear and actionable static analysis regardless of the technology used.

The static analysis engines and all the static analysis code used are published under Open Source licenses. This paves way for the users to dig in and understand how the code is being evaluated.

The rating and GPA provided by Code Climate extension is an estimate of the quality of the code. The ratings vary from A to F and the GPA varies from 1 to 5. Code with a higher GPA is expected to have higher quality.

'''Getting started with Code Climate'''

To get started with Code Climate the following 4 steps are to be followed
* [https://docs.codeclimate.com/docs/getting-started-with-code-climate Create an account with Code Climate and add the first repository]
* [https://docs.codeclimate.com/docs/getting-started-with-code-climate Configure and customise your analysis]
* [https://docs.codeclimate.com/docs/workflow Add Code Climate to your work flow]
* [https://docs.codeclimate.com/docs/getting-started-test-coverage Set up test coverage]

==== User perspective ====
* [https://codeclimate.com Download Code climate] and allow the extension to be used with your browser
* Sign into your Github account and add the repository to be checked by clicking the extension from your browser.
[[File:Code Climate.png]]
* Manually add the repository from the dashboard.
[[File:Dash board.png]]

== List of changes ==
Similar code found in 1 other location (mass = 50) Duplicated code can lead to software that is hard to understand and difficult to change. Refactorings -Extract Method,Extract Class,Form Template Method,Introduce Null Object,Pull Up Method,Pull Up Field,Substitute Algorithm Use find_by instead of dynamic find_by_name. Do not use DateTime.now without zone.

The files in the project include duplicated code which violates DRY concept and is to be removed. The various changes that can be made to the files are explained.

=== 1. Similar code found in 1 other location ===
When there is duplicated code within the file or between files of the same project, the code can be created as a function with variables that are assigned based on the different cases. This function can be called wherever the functionality is required to be fulfilled and also by passing the required parameters. This makes the code more readable and in fact, much easier to understand. By writing similar lines of code again and again, we only increase the number of lines and decrease the efficiency of the code.For example, the following error was pointed out by Code Climate Extension in [https://github.com/expertiza/expertiza/blob/master/spec/features/assignment_creation_spec.rb assignment_creation_spec.rb]

Similar code was found
[[File:Similarcode.png|thumb|code similarity]]

New functions were added to remove duplicates

[[File:Similarcode2.png|thumb|code similarity]]

=== 2. Use find_by instead of dynamic find_by_name. ===
In the different spec files, find_by_name function is used to identify variables according to their name. find_by can be used to match the argument with the variable directly, instead of making sure if the function parameters are matching with the given file.

For example in file [https://github.com/expertiza/expertiza/blob/master/spec/features/assignment_creation_spec.rb assignment_creation_spec.rb], find_by_name was detected:[[File:Fine_by.png]]

This was corrected to find_by
[[File:Find by name.png]]

The grade of the code improved when find_by_name was changed to find_by.

=== 3. Refactoring - Extract Method,Extract Class,Form Template Method,Introduce Null Object,Pull Up Method,Pull Up Field,Substitute Algorithm ===

Refactoring is the process of improving a source code without altering the external behaviour. It improves Extensibility and Maintainability. We can implement refactoring using one of the methods mentioned above.

A common code that is present across files can be added to rails_helper.rb and called across files when needed. One example of this is the cod in integration_test_instructor_interface function which was typed out without being encapsulated as a function in both [https://github.com/expertiza/expertiza/blob/master/spec/features/instructor_interface_spec.rb instructor_interface_spec.rb] and [https://github.com/expertiza/expertiza/blob/master/spec/features/questionnaire_spec.rb questionnaire_spec.rb].
[[File:Rails helper.rb.png]]
A common definition was added to rails_helper.rb for the integration_test_instructor_interface function as shown below
[[File:Rails helper.rb modified.png]]

=== 4. Useless Assignments of Variables ===

Same variables may be assigned values through the program which may not be used later. These assignments are said to be useless as the new value never gets used anywhere. These lines can be removed from the program as they do not implement anything and are of no use.
[[File:Uselessassignment.png]]
And another example:
[[File:Useless.png|thumb|Useless assignment]]
These assignenments were removed

=== 5.Do not use DateTime.now without Time.zone.now ===

To use the current time in the program, we need use Time.zone.now instead of DateTime.now. The latter uses the system's date and time as it is part of the Ruby standard library. It is better to use Time.zone.now because it returns the time that is corrected according to our corresponding Time zone as it has been extended by ActiveSupport. Example is as given :
[[File:Timezone.png]]
[[File:Timelocal.png]]

=== 6. Indentation ===

Programs need to be indented properly. 2 White spaces are used to write statements within any block. Accordingly, the end of the block statements also follow the corresponding white spaces. Indentation improves code readability and makes it easy for the user/programmer to understand what happens within the program.

===Results and grades===

The grades of the 6 files changed after the duplicates were removed
Before modification :
[[File:Originalgrades.png]]
After modification:
[[File:Modifiedgrades.png]]

File:Final.png

2016-10-29T06:15:50Z

Svenka15: uploaded a new version of "File:Final.png"

File:Final.png

2016-10-29T06:11:58Z

Svenka15: uploaded a new version of "File:Final.png"

User:Svenka15

2016-10-29T06:10:56Z

Svenka15: /* 6. Indentation */

CSC/ECE 517 Fall 2016/E1672
Remove duplicated code in feature tests

== Introduction ==
This project mainly focuses on removing duplicated codes in feature tests and using Code Climate Chrome Extension and Travis CI to evaluate the modified code.

=== Background ===
Expertiza is an educational web application created and maintained by the joint efforts of the students and the faculty at NCSU. It’s an open source project developed on Ruby on Rails platform and the code is available on Github. It's a web portal used by students for assignment submission and team selection among other activities as listed below
* It allows students to submit their work- either a wiki page or a deployed link.
* Review other’s work and grade them.
* Make changes according to user reviews
* Allows the instructor to create new assignments and customize new or existing assignments.
* Allows the instructor to create a list of topics the students can sign up for.
* Students can bid for topics of their interest by assigning priorities to the topics
* Students can form teams in Expertiza to work on various projects and assignments.

=== Project Description ===
The following is an Expertiza based OSS project which deals with the files in spec/features folder, to be specific: assignment_creation_spec.rb, instructor_interface_spec.rb, questionnaire_spec.rb, quiz_spec.rb, delayed_mailer_spec.rb and scheduled_task_spec.rb. It focuses on removing the duplicate codes, following DRY concepts, change DateTime class object invocation, etc. The goal of this project is to attempt to make this part of the application easier to read, maintain and improve the quality of the code. The existing redundant codes, use of long methods, incorrect method invocation and other errors are pointed out by the Code climate extension which are modified in this project. The code climate extension also provides a rating for all files as well as an overall score for the entire application, to help us make proper modifications.

=== Problem Statement ===
The following tasks were accomplished in this project:

Install the Code Climate Chrome Extension, and when you go to Expertiza repo, you will see the extension will highlight the duplication code. Improved the clarity of code by improving the variable and parameter names. Remove the duplicated code by extracting a new method, moving code to before(:each) block, etc. Long character strings were taken and given appropriate names. Improve the Code Climate rating of classes whose original rating is F. Do not delete existing test cases and keep them pass TravisCI after refactoring. Files modified in current project

Six files in spec/features that are to be modified are :
* [https://github.com/expertiza/expertiza/blob/master/spec/features/assignment_creation_spec.rb assignment_creation_spec.rb]
* [https://github.com/expertiza/expertiza/blob/master/spec/features/instructor_interface_spec.rb instructor_interface_spec.rb]
* [https://github.com/expertiza/expertiza/blob/master/spec/features/questionnaire_spec.rb questionnaire_spec.rb]
* [https://github.com/expertiza/expertiza/blob/master/spec/features/quiz_spec.rb quiz_spec.rb]
* [https://github.com/expertiza/expertiza/blob/master/spec/features/delayed_mailer_spec.rb delayed_mailer_spec.rb]
* [https://github.com/expertiza/expertiza/blob/master/spec/features/scheduled_task_spec.rb scheduled_task_spec.rb]

=== '''Code Climate''' ===
Code Climate is a open and extensible platform for static analysis and works on the principle: healthy code ships faster. Code climate platform leads to healthier code by clear and actionable static analysis regardless of the technology used.

The static analysis engines and all the static analysis code used are published under Open Source licenses. This paves way for the users to dig in and understand how the code is being evaluated.

The rating and GPA provided by Code Climate extension is an estimate of the quality of the code. The ratings vary from A to F and the GPA varies from 1 to 5. Code with a higher GPA is expected to have higher quality.

'''Getting started with Code Climate'''

To get started with Code Climate the following 4 steps are to be followed
* [https://docs.codeclimate.com/docs/getting-started-with-code-climate Create an account with Code Climate and add the first repository]
* [https://docs.codeclimate.com/docs/getting-started-with-code-climate Configure and customise your analysis]
* [https://docs.codeclimate.com/docs/workflow Add Code Climate to your work flow]
* [https://docs.codeclimate.com/docs/getting-started-test-coverage Set up test coverage]

==== User perspective ====
* [https://codeclimate.com Download Code climate] and allow the extension to be used with your browser
* Sign into your Github account and add the repository to be checked by clicking the extension from your browser.
[[File:Code Climate.png]]
* Manually add the repository from the dashboard.
[[File:Dash board.png]]

== List of changes ==
Similar code found in 1 other location (mass = 50) Duplicated code can lead to software that is hard to understand and difficult to change. Refactorings -Extract Method,Extract Class,Form Template Method,Introduce Null Object,Pull Up Method,Pull Up Field,Substitute Algorithm Use find_by instead of dynamic find_by_name. Do not use DateTime.now without zone.

The files in the project include duplicated code which violates DRY concept and is to be removed. The various changes that can be made to the files are explained.

=== 1. Similar code found in 1 other location ===
When there is duplicated code within the file or between files of the same project, the code can be created as a function with variables that are assigned based on the different cases. This function can be called wherever the functionality is required to be fulfilled and also by passing the required parameters. This makes the code more readable and in fact, much easier to understand. By writing similar lines of code again and again, we only increase the number of lines and decrease the efficiency of the code.For example, the following error was pointed out by Code Climate Extension in [https://github.com/expertiza/expertiza/blob/master/spec/features/assignment_creation_spec.rb assignment_creation_spec.rb]

Similar code was found
[[File:Similarcode.png|thumb|code similarity]]

New functions were added to remove duplicates

[[File:Similarcode2.png|thumb|code similarity]]

=== 2. Use find_by instead of dynamic find_by_name. ===
In the different spec files, find_by_name function is used to identify variables according to their name. find_by can be used to match the argument with the variable directly, instead of making sure if the function parameters are matching with the given file.

For example in file [https://github.com/expertiza/expertiza/blob/master/spec/features/assignment_creation_spec.rb assignment_creation_spec.rb], find_by_name was detected:[[File:Fine_by.png]]

This was corrected to find_by
[[File:Find by name.png]]

The grade of the code improved when find_by_name was changed to find_by.

=== 3. Refactoring - Extract Method,Extract Class,Form Template Method,Introduce Null Object,Pull Up Method,Pull Up Field,Substitute Algorithm ===

Refactoring is the process of improving a source code without altering the external behaviour. It improves Extensibility and Maintainability. We can implement refactoring using one of the methods mentioned above.

A common code that is present across files can be added to rails_helper.rb and called across files when needed. One example of this is the cod in integration_test_instructor_interface function which was typed out without being encapsulated as a function in both [https://github.com/expertiza/expertiza/blob/master/spec/features/instructor_interface_spec.rb instructor_interface_spec.rb] and [https://github.com/expertiza/expertiza/blob/master/spec/features/questionnaire_spec.rb questionnaire_spec.rb].
[[File:Rails helper.rb.png]]
A common definition was added to rails_helper.rb for the integration_test_instructor_interface function as shown below
[[File:Rails helper.rb modified.png]]

=== 4. Useless Assignments of Variables ===

Same variables may be assigned values through the program which may not be used later. These assignments are said to be useless as the new value never gets used anywhere. These lines can be removed from the program as they do not implement anything and are of no use.
[[File:Uselessassignment.png]]
And another example:
[[File:Useless.png|thumb|Useless assignment]]
These assignenments were removed

=== 5.Do not use DateTime.now without Time.zone.now ===

To use the current time in the program, we need use Time.zone.now instead of DateTime.now. The latter uses the system's date and time as it is part of the Ruby standard library. It is better to use Time.zone.now because it returns the time that is corrected according to our corresponding Time zone as it has been extended by ActiveSupport. Example is as given :
[[File:Timezone.png]]
[[File:Timelocal.png]]

=== 6. Indentation ===

Programs need to be indented properly. 2 White spaces are used to write statements within any block. Accordingly, the end of the block statements also follow the corresponding white spaces. Indentation improves code readability and makes it easy for the user/programmer to understand what happens within the program.

===Results and grades===

The grades of the 6 files changed after the duplicates were removed
Before modification :
[[File:final.png]]
After modification:
[[File:image.pnf]]

User:Svenka15

2016-10-29T02:16:26Z

Svenka15: topic changed

CSC/ECE 517 Fall 2016/E1672
Remove duplicated code in feature tests

== Introduction ==
This project mainly focuses on removing duplicated codes in feature tests and using Code Climate Chrome Extension and Travis CI to evaluate the modified code.

=== Background ===
Expertiza is an educational web application created and maintained by the joint efforts of the students and the faculty at NCSU. It’s an open source project developed on Ruby on Rails platform and the code is available on Github. It's a web portal used by students for assignment submission and team selection among other activities as listed below
* It allows students to submit their work- either a wiki page or a deployed link.
* Review other’s work and grade them.
* Make changes according to user reviews
* Allows the instructor to create new assignments and customize new or existing assignments.
* Allows the instructor to create a list of topics the students can sign up for.
* Students can bid for topics of their interest by assigning priorities to the topics
* Students can form teams in Expertiza to work on various projects and assignments.

=== Project Description ===
The following is an Expertiza based OSS project which deals with the files in spec/features folder, to be specific: assignment_creation_spec.rb, instructor_interface_spec.rb, questionnaire_spec.rb, quiz_spec.rb, delayed_mailer_spec.rb and scheduled_task_spec.rb. It focuses on removing the duplicate codes, following DRY concepts, change DateTime class object invocation, etc. The goal of this project is to attempt to make this part of the application easier to read, maintain and improve the quality of the code. The existing redundant codes, use of long methods, incorrect method invocation and other errors are pointed out by the Code climate extension which are modified in this project. The code climate extension also provides a rating for all files as well as an overall score for the entire application, to help us make proper modifications.

=== Problem Statement ===
The following tasks were accomplished in this project:

Install the Code Climate Chrome Extension, and when you go to Expertiza repo, you will see the extension will highlight the duplication code. Improved the clarity of code by improving the variable and parameter names. Remove the duplicated code by extracting a new method, moving code to before(:each) block, etc. Long character strings were taken and given appropriate names. Improve the Code Climate rating of classes whose original rating is F. Do not delete existing test cases and keep them pass TravisCI after refactoring. Files modified in current project

Six files in spec/features that are to be modified are :
* [https://github.com/expertiza/expertiza/blob/master/spec/features/assignment_creation_spec.rb assignment_creation_spec.rb]
* [https://github.com/expertiza/expertiza/blob/master/spec/features/instructor_interface_spec.rb instructor_interface_spec.rb]
* [https://github.com/expertiza/expertiza/blob/master/spec/features/questionnaire_spec.rb questionnaire_spec.rb]
* [https://github.com/expertiza/expertiza/blob/master/spec/features/quiz_spec.rb quiz_spec.rb]
* [https://github.com/expertiza/expertiza/blob/master/spec/features/delayed_mailer_spec.rb delayed_mailer_spec.rb]
* [https://github.com/expertiza/expertiza/blob/master/spec/features/scheduled_task_spec.rb scheduled_task_spec.rb]

=== '''Code Climate''' ===
Code Climate is a open and extensible platform for static analysis and works on the principle: healthy code ships faster. Code climate platform leads to healthier code by clear and actionable static analysis regardless of the technology used.

The static analysis engines and all the static analysis code used are published under Open Source licenses. This paves way for the users to dig in and understand how the code is being evaluated.

The rating and GPA provided by Code Climate extension is an estimate of the quality of the code. The ratings vary from A to F and the GPA varies from 1 to 5. Code with a higher GPA is expected to have higher quality.

'''Getting started with Code Climate'''

To get started with Code Climate the following 4 steps are to be followed
* [https://docs.codeclimate.com/docs/getting-started-with-code-climate Create an account with Code Climate and add the first repository]
* [https://docs.codeclimate.com/docs/getting-started-with-code-climate Configure and customise your analysis]
* [https://docs.codeclimate.com/docs/workflow Add Code Climate to your work flow]
* [https://docs.codeclimate.com/docs/getting-started-test-coverage Set up test coverage]

==== User perspective ====
* [https://codeclimate.com Download Code climate] and allow the extension to be used with your browser
* Sign into your Github account and add the repository to be checked by clicking the extension from your browser.
[[File:Code Climate.png]]
* Manually add the repository from the dashboard.
[[File:Dash board.png]]

== List of changes ==
Similar code found in 1 other location (mass = 50) Duplicated code can lead to software that is hard to understand and difficult to change. Refactorings -Extract Method,Extract Class,Form Template Method,Introduce Null Object,Pull Up Method,Pull Up Field,Substitute Algorithm Use find_by instead of dynamic find_by_name. Do not use DateTime.now without zone.

The files in the project include duplicated code which violates DRY concept and is to be removed. The various changes that can be made to the files are explained.

=== 1. Similar code found in 1 other location ===
When there is duplicated code within the file or between files of the same project, the code can be created as a function with variables that are assigned based on the different cases. This function can be called wherever the functionality is required to be fulfilled and also by passing the required parameters. This makes the code more readable and in fact, much easier to understand. By writing similar lines of code again and again, we only increase the number of lines and decrease the efficiency of the code.For example, the following error was pointed out by Code Climate Extension in [https://github.com/expertiza/expertiza/blob/master/spec/features/assignment_creation_spec.rb assignment_creation_spec.rb]

Similar code was found
[[File:Similarcode.png|thumb|code similarity]]

New functions were added to remove duplicates

[[File:Similarcode2.png|thumb|code similarity]]

=== 2. Use find_by instead of dynamic find_by_name. ===
In the different spec files, find_by_name function is used to identify variables according to their name. find_by can be used to match the argument with the variable directly, instead of making sure if the function parameters are matching with the given file.

For example in file [https://github.com/expertiza/expertiza/blob/master/spec/features/assignment_creation_spec.rb assignment_creation_spec.rb], find_by_name was detected:[[File:Fine_by.png]]

This was corrected to find_by
[[File:Find by name.png]]

The grade of the code improved when find_by_name was changed to find_by.

=== 3. Refactoring - Extract Method,Extract Class,Form Template Method,Introduce Null Object,Pull Up Method,Pull Up Field,Substitute Algorithm ===

Refactoring is the process of improving a source code without altering the external behaviour. It improves Extensibility and Maintainability. We can implement refactoring using one of the methods mentioned above.

A common code that is present across files can be added to rails_helper.rb and called across files when needed. One example of this is the cod in integration_test_instructor_interface function which was typed out without being encapsulated as a function in both [https://github.com/expertiza/expertiza/blob/master/spec/features/instructor_interface_spec.rb instructor_interface_spec.rb] and [https://github.com/expertiza/expertiza/blob/master/spec/features/questionnaire_spec.rb questionnaire_spec.rb].
[[File:Rails helper.rb.png]]
A common definition was added to rails_helper.rb for the integration_test_instructor_interface function as shown below
[[File:Rails helper.rb modified.png]]

=== 4. Useless Assignments of Variables ===

Same variables may be assigned values through the program which may not be used later. These assignments are said to be useless as the new value never gets used anywhere. These lines can be removed from the program as they do not implement anything and are of no use.
[[File:Uselessassignment.png]]
And another example:
[[File:Useless.png|thumb|Useless assignment]]
These assignenments were removed

=== 5.Do not use DateTime.now without Time.zone.now ===

To use the current time in the program, we need use Time.zone.now instead of DateTime.now. The latter uses the system's date and time as it is part of the Ruby standard library. It is better to use Time.zone.now because it returns the time that is corrected according to our corresponding Time zone as it has been extended by ActiveSupport. Example is as given :
[[File:Timezone.png]]
[[File:Timelocal.png]]

=== 6. Indentation ===

Programs need to be indented properly. 2 White spaces are used to write statements within any block. Accordingly, the end of the block statements also follow the corresponding white spaces. Indentation improves code readability and makes it easy for the user/programmer to understand what happens within the program.

User:Svenka15

2016-10-29T02:15:34Z

Svenka15:

CSC/ECE 517 Fall 2015/E1672

== Introduction ==
This project mainly focuses on removing duplicated codes in feature tests and using Code Climate Chrome Extension and Travis CI to evaluate the modified code.

=== Background ===
Expertiza is an educational web application created and maintained by the joint efforts of the students and the faculty at NCSU. It’s an open source project developed on Ruby on Rails platform and the code is available on Github. It's a web portal used by students for assignment submission and team selection among other activities as listed below
* It allows students to submit their work- either a wiki page or a deployed link.
* Review other’s work and grade them.
* Make changes according to user reviews
* Allows the instructor to create new assignments and customize new or existing assignments.
* Allows the instructor to create a list of topics the students can sign up for.
* Students can bid for topics of their interest by assigning priorities to the topics
* Students can form teams in Expertiza to work on various projects and assignments.

=== Project Description ===
The following is an Expertiza based OSS project which deals with the files in spec/features folder, to be specific: assignment_creation_spec.rb, instructor_interface_spec.rb, questionnaire_spec.rb, quiz_spec.rb, delayed_mailer_spec.rb and scheduled_task_spec.rb. It focuses on removing the duplicate codes, following DRY concepts, change DateTime class object invocation, etc. The goal of this project is to attempt to make this part of the application easier to read, maintain and improve the quality of the code. The existing redundant codes, use of long methods, incorrect method invocation and other errors are pointed out by the Code climate extension which are modified in this project. The code climate extension also provides a rating for all files as well as an overall score for the entire application, to help us make proper modifications.

=== Problem Statement ===
The following tasks were accomplished in this project:

Install the Code Climate Chrome Extension, and when you go to Expertiza repo, you will see the extension will highlight the duplication code. Improved the clarity of code by improving the variable and parameter names. Remove the duplicated code by extracting a new method, moving code to before(:each) block, etc. Long character strings were taken and given appropriate names. Improve the Code Climate rating of classes whose original rating is F. Do not delete existing test cases and keep them pass TravisCI after refactoring. Files modified in current project

Six files in spec/features that are to be modified are :
* [https://github.com/expertiza/expertiza/blob/master/spec/features/assignment_creation_spec.rb assignment_creation_spec.rb]
* [https://github.com/expertiza/expertiza/blob/master/spec/features/instructor_interface_spec.rb instructor_interface_spec.rb]
* [https://github.com/expertiza/expertiza/blob/master/spec/features/questionnaire_spec.rb questionnaire_spec.rb]
* [https://github.com/expertiza/expertiza/blob/master/spec/features/quiz_spec.rb quiz_spec.rb]
* [https://github.com/expertiza/expertiza/blob/master/spec/features/delayed_mailer_spec.rb delayed_mailer_spec.rb]
* [https://github.com/expertiza/expertiza/blob/master/spec/features/scheduled_task_spec.rb scheduled_task_spec.rb]

=== '''Code Climate''' ===
Code Climate is a open and extensible platform for static analysis and works on the principle: healthy code ships faster. Code climate platform leads to healthier code by clear and actionable static analysis regardless of the technology used.

The static analysis engines and all the static analysis code used are published under Open Source licenses. This paves way for the users to dig in and understand how the code is being evaluated.

The rating and GPA provided by Code Climate extension is an estimate of the quality of the code. The ratings vary from A to F and the GPA varies from 1 to 5. Code with a higher GPA is expected to have higher quality.

'''Getting started with Code Climate'''

To get started with Code Climate the following 4 steps are to be followed
* [https://docs.codeclimate.com/docs/getting-started-with-code-climate Create an account with Code Climate and add the first repository]
* [https://docs.codeclimate.com/docs/getting-started-with-code-climate Configure and customise your analysis]
* [https://docs.codeclimate.com/docs/workflow Add Code Climate to your work flow]
* [https://docs.codeclimate.com/docs/getting-started-test-coverage Set up test coverage]

==== User perspective ====
* [https://codeclimate.com Download Code climate] and allow the extension to be used with your browser
* Sign into your Github account and add the repository to be checked by clicking the extension from your browser.
[[File:Code Climate.png]]
* Manually add the repository from the dashboard.
[[File:Dash board.png]]

== List of changes ==
Similar code found in 1 other location (mass = 50) Duplicated code can lead to software that is hard to understand and difficult to change. Refactorings -Extract Method,Extract Class,Form Template Method,Introduce Null Object,Pull Up Method,Pull Up Field,Substitute Algorithm Use find_by instead of dynamic find_by_name. Do not use DateTime.now without zone.

The files in the project include duplicated code which violates DRY concept and is to be removed. The various changes that can be made to the files are explained.

=== 1. Similar code found in 1 other location ===
When there is duplicated code within the file or between files of the same project, the code can be created as a function with variables that are assigned based on the different cases. This function can be called wherever the functionality is required to be fulfilled and also by passing the required parameters. This makes the code more readable and in fact, much easier to understand. By writing similar lines of code again and again, we only increase the number of lines and decrease the efficiency of the code.For example, the following error was pointed out by Code Climate Extension in [https://github.com/expertiza/expertiza/blob/master/spec/features/assignment_creation_spec.rb assignment_creation_spec.rb]

Similar code was found
[[File:Similarcode.png|thumb|code similarity]]

New functions were added to remove duplicates

[[File:Similarcode2.png|thumb|code similarity]]

=== 2. Use find_by instead of dynamic find_by_name. ===
In the different spec files, find_by_name function is used to identify variables according to their name. find_by can be used to match the argument with the variable directly, instead of making sure if the function parameters are matching with the given file.

For example in file [https://github.com/expertiza/expertiza/blob/master/spec/features/assignment_creation_spec.rb assignment_creation_spec.rb], find_by_name was detected:[[File:Fine_by.png]]

This was corrected to find_by
[[File:Find by name.png]]

The grade of the code improved when find_by_name was changed to find_by.

=== 3. Refactoring - Extract Method,Extract Class,Form Template Method,Introduce Null Object,Pull Up Method,Pull Up Field,Substitute Algorithm ===

Refactoring is the process of improving a source code without altering the external behaviour. It improves Extensibility and Maintainability. We can implement refactoring using one of the methods mentioned above.

A common code that is present across files can be added to rails_helper.rb and called across files when needed. One example of this is the cod in integration_test_instructor_interface function which was typed out without being encapsulated as a function in both [https://github.com/expertiza/expertiza/blob/master/spec/features/instructor_interface_spec.rb instructor_interface_spec.rb] and [https://github.com/expertiza/expertiza/blob/master/spec/features/questionnaire_spec.rb questionnaire_spec.rb].
[[File:Rails helper.rb.png]]
A common definition was added to rails_helper.rb for the integration_test_instructor_interface function as shown below
[[File:Rails helper.rb modified.png]]

=== 4. Useless Assignments of Variables ===

Same variables may be assigned values through the program which may not be used later. These assignments are said to be useless as the new value never gets used anywhere. These lines can be removed from the program as they do not implement anything and are of no use.
[[File:Uselessassignment.png]]
And another example:
[[File:Useless.png|thumb|Useless assignment]]
These assignenments were removed

=== 5.Do not use DateTime.now without Time.zone.now ===

To use the current time in the program, we need use Time.zone.now instead of DateTime.now. The latter uses the system's date and time as it is part of the Ruby standard library. It is better to use Time.zone.now because it returns the time that is corrected according to our corresponding Time zone as it has been extended by ActiveSupport. Example is as given :
[[File:Timezone.png]]
[[File:Timelocal.png]]

=== 6. Indentation ===

Programs need to be indented properly. 2 White spaces are used to write statements within any block. Accordingly, the end of the block statements also follow the corresponding white spaces. Indentation improves code readability and makes it easy for the user/programmer to understand what happens within the program.

File:Find by name.png

2016-10-29T02:14:11Z

Svenka15: uploaded a new version of "File:Find by name.png"

File:Fine by.png

2016-10-29T02:12:17Z

Svenka15: uploaded a new version of "File:Fine by.png": correct

File:Fine by.png

2016-10-29T02:11:09Z

Svenka15: uploaded a new version of "File:Fine by.png"

File:Fine by.png

2016-10-29T02:10:26Z

Svenka15: uploaded a new version of "File:Fine by.png"

File:Find by name.png

2016-10-29T02:09:29Z

Svenka15: uploaded a new version of "File:Find by name.png"

File:Useless.png

2016-10-29T01:09:22Z

Svenka15: uploaded a new version of "File:Useless.png": cropped

File:Similarcode.png

2016-10-29T01:08:15Z

Svenka15: uploaded a new version of "File:Similarcode.png"

File:Similarcode2.png

2016-10-29T01:07:33Z

Svenka15:

File:Similarcode.png

2016-10-29T01:07:14Z

Svenka15:

User:Svenka15

2016-10-29T01:00:16Z

Svenka15: /* 2. Use find_by instead of dynamic find_by_name. */

CSC/ECE 517 Fall 2015/E1672

== Introduction ==
This project mainly focuses on removing duplicated codes in feature tests and using Code Climate Chrome Extension and Travis CI to evaluate the modified code.

=== Background ===
Expertiza is an educational web application created and maintained by the joint efforts of the students and the faculty at NCSU. It’s an open source project developed on Ruby on Rails platform and the code is available on Github. It's a web portal used by students for assignment submission and team selection among other activities as listed below
* It allows students to submit their work- either a wiki page or a deployed link.
* Review other’s work and grade them.
* Make changes according to user reviews
* Allows the instructor to create new assignments and customize new or existing assignments.
* Allows the instructor to create a list of topics the students can sign up for.
* Students can bid for topics of their interest by assigning priorities to the topics
* Students can form teams in Expertiza to work on various projects and assignments.

=== Project Description ===
The following is an Expertiza based OSS project which deals with the files in spec/features folder, to be specific: assignment_creation_spec.rb, instructor_interface_spec.rb, questionnaire_spec.rb, quiz_spec.rb, delayed_mailer_spec.rb and scheduled_task_spec.rb. It focuses on removing the duplicate codes, following DRY concepts, change DateTime class object invocation, etc. The goal of this project is to attempt to make this part of the application easier to read, maintain and improve the quality of the code. The existing redundant codes, use of long methods, incorrect method invocation and other errors are pointed out by the Code climate extension which are modified in this project. The code climate extension also provides a rating for all files as well as an overall score for the entire application, to help us make proper modifications.

=== Problem Statement ===
The following tasks were accomplished in this project:

Install the Code Climate Chrome Extension, and when you go to Expertiza repo, you will see the extension will highlight the duplication code. Improved the clarity of code by improving the variable and parameter names. Remove the duplicated code by extracting a new method, moving code to before(:each) block, etc. Long character strings were taken and given appropriate names. Improve the Code Climate rating of classes whose original rating is F. Do not delete existing test cases and keep them pass TravisCI after refactoring. Files modified in current project

Six files in spec/features that are to be modified are :
* [https://github.com/expertiza/expertiza/blob/master/spec/features/assignment_creation_spec.rb assignment_creation_spec.rb]
* [https://github.com/expertiza/expertiza/blob/master/spec/features/instructor_interface_spec.rb instructor_interface_spec.rb]
* [https://github.com/expertiza/expertiza/blob/master/spec/features/questionnaire_spec.rb questionnaire_spec.rb]
* [https://github.com/expertiza/expertiza/blob/master/spec/features/quiz_spec.rb quiz_spec.rb]
* [https://github.com/expertiza/expertiza/blob/master/spec/features/delayed_mailer_spec.rb delayed_mailer_spec.rb]
* [https://github.com/expertiza/expertiza/blob/master/spec/features/scheduled_task_spec.rb scheduled_task_spec.rb]

=== '''Code Climate''' ===
Code Climate is a open and extensible platform for static analysis and works on the principle: healthy code ships faster. Code climate platform leads to healthier code by clear and actionable static analysis regardless of the technology used.

The static analysis engines and all the static analysis code used are published under Open Source licenses. This paves way for the users to dig in and understand how the code is being evaluated.

The rating and GPA provided by Code Climate extension is an estimate of the quality of the code. The ratings vary from A to F and the GPA varies from 1 to 5. Code with a higher GPA is expected to have higher quality.

'''Getting started with Code Climate'''

To get started with Code Climate the following 4 steps are to be followed
* [https://docs.codeclimate.com/docs/getting-started-with-code-climate Create an account with Code Climate and add the first repository]
* [https://docs.codeclimate.com/docs/getting-started-with-code-climate Configure and customise your analysis]
* [https://docs.codeclimate.com/docs/workflow Add Code Climate to your work flow]
* [https://docs.codeclimate.com/docs/getting-started-test-coverage Set up test coverage]

==== User perspective ====
* [https://codeclimate.com Download Code climate] and allow the extension to be used with your browser
* Sign into your Github account and add the repository to be checked by clicking the extension from your browser.
[[File:Code Climate.png]]
* Manually add the repository from the dashboard.
[[File:Dash board.png]]

== List of changes ==
Similar code found in 1 other location (mass = 50) Duplicated code can lead to software that is hard to understand and difficult to change. Refactorings -Extract Method,Extract Class,Form Template Method,Introduce Null Object,Pull Up Method,Pull Up Field,Substitute Algorithm Use find_by instead of dynamic find_by_name. Do not use DateTime.now without zone.

The files in the project include duplicated code which violates DRY concept and is to be removed. The various changes that can be made to the files are explained.

=== 1. Similar code found in 1 other location ===
When there is duplicated code within the file or between files of the same project, the code can be created as a function with variables that are assigned based on the different cases. This function can be called wherever the functionality is required to be fulfilled and also by passing the required parameters. This makes the code more readable and in fact, much easier to understand. By writing similar lines of code again and again, we only increase the number of lines and decrease the efficiency of the code.For example, the following error was pointed out by Code Climate Extension in [https://github.com/expertiza/expertiza/blob/master/spec/features/assignment_creation_spec.rb assignment_creation_spec.rb]

//image

=== 2. Use find_by instead of dynamic find_by_name. ===
In the different spec files, find_by_name function is used to identify variables according to their name. find_by can be used to match the argument with the variable directly, instead of making sure if the function parameters are matching with the given file.

For example in file [https://github.com/expertiza/expertiza/blob/master/spec/features/assignment_creation_spec.rb assignment_creation_spec.rb], find_by_name was detected:[[File:Find by name.png]]

This was corrected to find_by
[[File:Fine_by.png]]

The grade of the code improved when find_by_name was changed to find_by.

=== 3. Refactoring - Extract Method,Extract Class,Form Template Method,Introduce Null Object,Pull Up Method,Pull Up Field,Substitute Algorithm ===

Refactoring is the process of improving a source code without altering the external behaviour. It improves Extensibility and Maintainability. We can implement refactoring using one of the methods mentioned above.

A common code that is present across files can be added to rails_helper.rb and called across files when needed. One example of this is the cod in integration_test_instructor_interface function which was typed out without being encapsulated as a function in both [https://github.com/expertiza/expertiza/blob/master/spec/features/instructor_interface_spec.rb instructor_interface_spec.rb] and [https://github.com/expertiza/expertiza/blob/master/spec/features/questionnaire_spec.rb questionnaire_spec.rb].
[[File:Rails helper.rb.png]]
A common definition was added to rails_helper.rb for the integration_test_instructor_interface function as shown below
[[File:Rails helper.rb modified.png]]

=== 4. Useless Assignments of Variables ===

Same variables may be assigned values through the program which may not be used later. These assignments are said to be useless as the new value never gets used anywhere. These lines can be removed from the program as they do not implement anything and are of no use.
[[File:Uselessassignment.png]]
And another example:
[[File:Useless.png|thumb|Useless assignment]]
These assignenments were removed

=== 5.Do not use DateTime.now without Time.zone.now ===

To use the current time in the program, we need use Time.zone.now instead of DateTime.now. The latter uses the system's date and time as it is part of the Ruby standard library. It is better to use Time.zone.now because it returns the time that is corrected according to our corresponding Time zone as it has been extended by ActiveSupport. Example is as given :
[[File:Timezone.png]]
[[File:Timelocal.png]]

=== 6. Indentation ===

Programs need to be indented properly. 2 White spaces are used to write statements within any block. Accordingly, the end of the block statements also follow the corresponding white spaces. Indentation improves code readability and makes it easy for the user/programmer to understand what happens within the program.