Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2016/ E1700 Integrate Google doc editor/viewer

2016-12-04T20:59:53Z

Asagarwa: /* Testing Plan */

=='''Expertiza 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 it’s code is available on Github. Using Expertiza students can bid for a particular project topic and the faculty assigns the same to different groups. Students can track their grades for previous projects and make new submissions for current projects. It also allows students to review each other’s work and improve their work upon this feedback.

=='''Project Description'''==

Currently the instructor creates rubrics for an assignment through questionnaires which students use to review other students' submissions. The only way reviewers can suggest some more changes to the author is by using the 'additional comments' section in the review form which is not very helpful. In this project we will be looking towards improving this functionality by adding an extra medium through which multiple reviewers can collectively comment on the author's work and collaborate their answers in a constructive way. This will be achieved by displaying alert messages to the authors and the reviewers who will use the newly created Google document links embedded into Expertiza. Every project will have a Google doc link for itself which the reviewers can access and make further comments about the project. Once on the Google doc, the reviewer's comments will be posted anonymously, the reviewer's comment will be anonymous to both, other fellow reviewers as well as the author. This feature will help the author to better understand where is his work exactly lacking and how exactly should the changes be worked upon based on the comments received. The reviewers will just need the Google doc link to post comments and it wouldn't be required to login into Expertiza or any google account for using this feature.

== '''Key Points To Consider''' ==

* The alert message should only pop up when the faculty as indicated to do so
* The Google doc link needs to be added on the submissions page by the author of the project
* The settings for the Google doc should be set to "anyone with link can comment" by the author
* A peer reviewer needs be directed not login to any Google account to comment on the doc, and all peer reviewer comments shall be anonymous
* Multiple commenting at a specific instance is taken care of by the google document settings and it will be placed one below the other.

== '''Approach''' ==

Generally, we can always create a Google document, slide presentation, or spreadsheet using Google Drive and then embed that document anywhere in our application using iFrame as a dynamic rich content editor. The rich content editor is used in features that support the editor (Announcements, Quizzes or Collaborative Reviewing in our case). Any time you make changes to the Google document (like comments), it will be automatically updated in the application's content editor.

The first phase of our project aimed at embedding a google a document which enables the project author to automatically generate a google document with specified permissions for the reviews such that when a reviewer makes a comment it appears without his identity.
We succeeded in authorizing the user to the google documents by using the google-client-API (aouth + signet) credentials and the API console also showed positive results for the "request" sent over to the client and created a google document but to access that particular binary file we had to set the permission rights of the service account for which the google document is created which is different from the credentials account. We also tried hard coding and giving all access rights to anyone who wanted to open the file but it seems practically impossible to get those rights.

The second half of the project aimed at creating a flash box which directs the author to set the comment rights on the review google document as decided by the professor subject to the condition and complexity of the project. This will happen on the go and the author is notified to "enable commenting rights only" only if the faculty checks the option for that particular project.
On the other side whenever the reviewers click on the google document link attached to the project for reviewing or commenting on a project they will get a notification alert to log out of all google accounts in order to assure the anonymity of the reviewer. This is done because google documents does not support complete anonymity.
In this the assumption is that the google doc is created in the same manner as the other hyperlinks are added. Additionally whenever the the which will be already created by the author
===Creating Google document, Setting Up its Link===

* First and foremost a provision (button) for creating a Google document is added to the ''Your Work'' page of ''Assignments''.
* When the authors would select this button before submitting their assignment, a new Google doc is created.
* The document's Sharing criteria is set using google docs API such that the authors of the team can edit the document.
* Sharing criteria is also set such that anyone else having the link to this document can only comment.
* The authors would then copy paste their content, to be reviewed, on to the document.

[[File:Doceditor.png|thumb=Doceditor.png|center|alt=none|The expected display on the google documents]]

* Now the file sharable link must be pasted while submitting an Assignment in expertiza as shown below.
* The new Google doc link will be saved with other hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.

[[File:Googledoc.png|thumb=Googledoc.png|center|alt=none|The list of hyperlinks a project author would ideally have]]

===Publishing the document to Web===

* Open the File menu in Google doc and select Publish to the web....
* Make sure that the Automatically republish when changes are made checkbox is selected. Click the Start publishing button.
* When a confirmation prompt pops up, click the OK button.
* Click on the Embed tab to get the below screen, now copy the text in order to use it in our expertiza code.

[[File:Publish.png]]

===Security Risks===

As mentioned in the requirement document, there are 2 security risks associated with this project, they are:
*A situation where the peer reviewer forgets to logout would result in his/ her name being added to the history of document edits which will reveal the identity.
*Possible security violations like an user with access to the link deletes all the content on that doc.

Proposed solution to mitigate the risk:
*When a reviewer goes on the page of submitted contents, he'll be shown an alert message to logout from google accounts if there exists a google docs link in the submitted content and instructor has enabled anonymous commenting.
*The authors of the project will be shown an alert to modify the settings of their google doc to 'Anyone with the link can comment' when they submit a google doc link.

[[File:can_comment.png|thumb=can_comment.png|center|alt = ScreenShot of google document settings|ScreenShot of google document settings]]

*As it can be seen, Google doc has 3 access levels and the 'can comment' option will allow the users only to add more comments on the Google doc. They won't be able to edit or delete previously entered comments.
*Doing this will ensure that no user even unintentionally will be able to delete or edit previous comments which might be of great value to the authors of that project.
* Also the anonymity is handled if the user directly comments on the document without loging in into other google accounts.

===Embedding the document editor in expertiza===

* When an instructor will create a new assignment, he should be able to select a checkbox if he wants to enable anonymous commenting for google docs.
* If the instructor selects this then the authors will not be able to identify the individuals commenting on the doc.
* The below image shows how we aim to create a checkbox about the same for the instructor.

[[File:newassign.png|center|]]

* We will try to create an alert message whenever the author submits a google doc link.
* The alert message will ask the author to change the sharing settings of the doc to 'Anyone with the link can comment'.
* This message should be thrown only when the author submits a google doc link and not any other link.
* The below image shows the desirable alert message when author tries to submit a google doc link.

[[File:google doc.png|center|]]

* If the instructor has enabled anonymous commenting on google docs then the reviewer should see an alert message which will ask the reviewer to log out from all google accounts before opening the google doc link.
* The reviewer will need to logout because google allows anonymous commenting on a doc only if the user is currently not logged into any google account.
* The below image shows the desirable alert message when a reviewer tries to review a project which has google docs in its submission and anonymous commenting is enabled.

[[File:anonymous.png|center|]]

== '''Project File and Database additions''' ==

* The new outcome will involve accessing the database table 'assignments' and we will make a change to the schema of the table by adding a column 'allow_anonymous_commenting' of the type 'Boolean' to indicate whether the professor has asked the project developers to have a review document created with the rights of anonymous comments.
* To incorporate the database changes we will generate a migration file in the "db" migrate named: '_add_allow_anonymous_commenting_to_assignemnnts.rb'
* The 'factories' file in the spec will have a variable added with the default value set as 'FALSE'
* '_genral.html.erb' page in the edit assignments view will have a 'check box' and a label added to it.
* A function will be added in the 'assignments_form' model which sets the visibility to false/ true depending on the input
* Newly added Google doc hyperlinks will be saved with other assignment hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.

== '''Testing Plan''' ==

This UI enhancement will be tested to check whether the following required functionalities are implemented successfully:

i. Any user having the doc link should only be able to comment on the Google doc 
ii. Alert should be shown to the authors only while submitting a google doc link 
iii. Users need not login to comment in the Google doc 
iv. Alert should be shown to the reviewers only if the submissions contain a google doc link and anonymous commenting is enabled 
v. Multiple comments made at the same time should not lead to any conflicts 

== '''References''' ==

*[https://community.canvaslms.com/docs/DOC-1885 Guide to Embedding Google doc editor]
*[https://expertiza.ncsu.edu/ Expertiza application]
*[https://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

CSC/ECE 517 Fall 2016/ E1700 Integrate Google doc editor/viewer

2016-12-04T20:52:05Z

Asagarwa: /* Embedding the document editor in expertiza */

=='''Expertiza 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 it’s code is available on Github. Using Expertiza students can bid for a particular project topic and the faculty assigns the same to different groups. Students can track their grades for previous projects and make new submissions for current projects. It also allows students to review each other’s work and improve their work upon this feedback.

=='''Project Description'''==

Currently the instructor creates rubrics for an assignment through questionnaires which students use to review other students' submissions. The only way reviewers can suggest some more changes to the author is by using the 'additional comments' section in the review form which is not very helpful. In this project we will be looking towards improving this functionality by adding an extra medium through which multiple reviewers can collectively comment on the author's work and collaborate their answers in a constructive way. This will be achieved by displaying alert messages to the authors and the reviewers who will use the newly created Google document links embedded into Expertiza. Every project will have a Google doc link for itself which the reviewers can access and make further comments about the project. Once on the Google doc, the reviewer's comments will be posted anonymously, the reviewer's comment will be anonymous to both, other fellow reviewers as well as the author. This feature will help the author to better understand where is his work exactly lacking and how exactly should the changes be worked upon based on the comments received. The reviewers will just need the Google doc link to post comments and it wouldn't be required to login into Expertiza or any google account for using this feature.

== '''Key Points To Consider''' ==

* The alert message should only pop up when the faculty as indicated to do so
* The Google doc link needs to be added on the submissions page by the author of the project
* The settings for the Google doc should be set to "anyone with link can comment" by the author
* A peer reviewer needs be directed not login to any Google account to comment on the doc, and all peer reviewer comments shall be anonymous
* Multiple commenting at a specific instance is taken care of by the google document settings and it will be placed one below the other.

== '''Approach''' ==

Generally, we can always create a Google document, slide presentation, or spreadsheet using Google Drive and then embed that document anywhere in our application using iFrame as a dynamic rich content editor. The rich content editor is used in features that support the editor (Announcements, Quizzes or Collaborative Reviewing in our case). Any time you make changes to the Google document (like comments), it will be automatically updated in the application's content editor.

The first phase of our project aimed at embedding a google a document which enables the project author to automatically generate a google document with specified permissions for the reviews such that when a reviewer makes a comment it appears without his identity.
We succeeded in authorizing the user to the google documents by using the google-client-API (aouth + signet) credentials and the API console also showed positive results for the "request" sent over to the client and created a google document but to access that particular binary file we had to set the permission rights of the service account for which the google document is created which is different from the credentials account. We also tried hard coding and giving all access rights to anyone who wanted to open the file but it seems practically impossible to get those rights.

The second half of the project aimed at creating a flash box which directs the author to set the comment rights on the review google document as decided by the professor subject to the condition and complexity of the project. This will happen on the go and the author is notified to "enable commenting rights only" only if the faculty checks the option for that particular project.
On the other side whenever the reviewers click on the google document link attached to the project for reviewing or commenting on a project they will get a notification alert to log out of all google accounts in order to assure the anonymity of the reviewer. This is done because google documents does not support complete anonymity.
In this the assumption is that the google doc is created in the same manner as the other hyperlinks are added. Additionally whenever the the which will be already created by the author
===Creating Google document, Setting Up its Link===

* First and foremost a provision (button) for creating a Google document is added to the ''Your Work'' page of ''Assignments''.
* When the authors would select this button before submitting their assignment, a new Google doc is created.
* The document's Sharing criteria is set using google docs API such that the authors of the team can edit the document.
* Sharing criteria is also set such that anyone else having the link to this document can only comment.
* The authors would then copy paste their content, to be reviewed, on to the document.

[[File:Doceditor.png|thumb=Doceditor.png|center|alt=none|The expected display on the google documents]]

* Now the file sharable link must be pasted while submitting an Assignment in expertiza as shown below.
* The new Google doc link will be saved with other hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.

[[File:Googledoc.png|thumb=Googledoc.png|center|alt=none|The list of hyperlinks a project author would ideally have]]

===Publishing the document to Web===

* Open the File menu in Google doc and select Publish to the web....
* Make sure that the Automatically republish when changes are made checkbox is selected. Click the Start publishing button.
* When a confirmation prompt pops up, click the OK button.
* Click on the Embed tab to get the below screen, now copy the text in order to use it in our expertiza code.

[[File:Publish.png]]

===Security Risks===

As mentioned in the requirement document, there are 2 security risks associated with this project, they are:
*A situation where the peer reviewer forgets to logout would result in his/ her name being added to the history of document edits which will reveal the identity.
*Possible security violations like an user with access to the link deletes all the content on that doc.

Proposed solution to mitigate the risk:
*When a reviewer goes on the page of submitted contents, he'll be shown an alert message to logout from google accounts if there exists a google docs link in the submitted content and instructor has enabled anonymous commenting.
*The authors of the project will be shown an alert to modify the settings of their google doc to 'Anyone with the link can comment' when they submit a google doc link.

[[File:can_comment.png|thumb=can_comment.png|center|alt = ScreenShot of google document settings|ScreenShot of google document settings]]

*As it can be seen, Google doc has 3 access levels and the 'can comment' option will allow the users only to add more comments on the Google doc. They won't be able to edit or delete previously entered comments.
*Doing this will ensure that no user even unintentionally will be able to delete or edit previous comments which might be of great value to the authors of that project.
* Also the anonymity is handled if the user directly comments on the document without loging in into other google accounts.

===Embedding the document editor in expertiza===

* When an instructor will create a new assignment, he should be able to select a checkbox if he wants to enable anonymous commenting for google docs.
* If the instructor selects this then the authors will not be able to identify the individuals commenting on the doc.
* The below image shows how we aim to create a checkbox about the same for the instructor.

[[File:newassign.png|center|]]

* We will try to create an alert message whenever the author submits a google doc link.
* The alert message will ask the author to change the sharing settings of the doc to 'Anyone with the link can comment'.
* This message should be thrown only when the author submits a google doc link and not any other link.
* The below image shows the desirable alert message when author tries to submit a google doc link.

[[File:google doc.png|center|]]

* If the instructor has enabled anonymous commenting on google docs then the reviewer should see an alert message which will ask the reviewer to log out from all google accounts before opening the google doc link.
* The reviewer will need to logout because google allows anonymous commenting on a doc only if the user is currently not logged into any google account.
* The below image shows the desirable alert message when a reviewer tries to review a project which has google docs in its submission and anonymous commenting is enabled.

[[File:anonymous.png|center|]]

== '''Project File and Database additions''' ==

* The new outcome will involve accessing the database table 'assignments' and we will make a change to the schema of the table by adding a column 'allow_anonymous_commenting' of the type 'Boolean' to indicate whether the professor has asked the project developers to have a review document created with the rights of anonymous comments.
* To incorporate the database changes we will generate a migration file in the "db" migrate named: '_add_allow_anonymous_commenting_to_assignemnnts.rb'
* The 'factories' file in the spec will have a variable added with the default value set as 'FALSE'
* '_genral.html.erb' page in the edit assignments view will have a 'check box' and a label added to it.
* A function will be added in the 'assignments_form' model which sets the visibility to false/ true depending on the input
* Newly added Google doc hyperlinks will be saved with other assignment hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.

== '''Testing Plan''' ==

This UI enhancement will be tested to check whether the following required functionalities are implemented successfully:

i. Any user having the doc link should only be able to comment on the Google doc 
ii. Changes made in the original Google doc should be reflected in the embedded doc editor in expertiza 
iii. Users need not login to comment in the Google doc 
iv. All comments made must be anonymous 
v. Multiple comments made at the same time should not lead to any conflicts 

== '''References''' ==

*[https://community.canvaslms.com/docs/DOC-1885 Guide to Embedding Google doc editor]
*[https://expertiza.ncsu.edu/ Expertiza application]
*[https://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

File:Newassign.png

2016-12-04T20:51:14Z

Asagarwa:

CSC/ECE 517 Fall 2016/ E1700 Integrate Google doc editor/viewer

2016-12-04T20:03:59Z

Asagarwa: /* Embedding the document editor in expertiza */

=='''Expertiza 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 it’s code is available on Github. Using Expertiza students can bid for a particular project topic and the faculty assigns the same to different groups. Students can track their grades for previous projects and make new submissions for current projects. It also allows students to review each other’s work and improve their work upon this feedback.

=='''Project Description'''==

Currently the instructor creates rubrics for an assignment through questionnaires which students use to review other students' submissions. The only way reviewers can suggest some more changes to the author is by using the 'additional comments' section in the review form which is not very helpful. In this project we will be looking towards improving this functionality by adding an extra medium through which multiple reviewers can collectively comment on the author's work and collaborate their answers in a constructive way. This will be achieved by displaying alert messages to the authors and the reviewers who will use the newly created Google document links embedded into Expertiza. Every project will have a Google doc link for itself which the reviewers can access and make further comments about the project. Once on the Google doc, the reviewer's comments will be posted anonymously, the reviewer's comment will be anonymous to both, other fellow reviewers as well as the author. This feature will help the author to better understand where is his work exactly lacking and how exactly should the changes be worked upon based on the comments received. The reviewers will just need the Google doc link to post comments and it wouldn't be required to login into Expertiza or any google account for using this feature.

== '''Key Points To Consider''' ==

* The alert message should only pop up when the faculty as indicated to do so
* The Google doc link needs to be added on the submissions page by the author of the project
* The settings for the Google doc should be set to "anyone with link can comment" by the author
* A peer reviewer needs be directed not login to any Google account to comment on the doc, and all peer reviewer comments shall be anonymous
* Multiple commenting at a specific instance is taken care of by the google document settings and it will be placed one below the other.

== '''Approach''' ==

Generally, we can always create a Google document, slide presentation, or spreadsheet using Google Drive and then embed that document anywhere in our application using iFrame as a dynamic rich content editor. The rich content editor is used in features that support the editor (Announcements, Quizzes or Collaborative Reviewing in our case). Any time you make changes to the Google document (like comments), it will be automatically updated in the application's content editor.

The first phase of our project aimed at embedding a google a document which enables the project author to automatically generate a google document with specified permissions for the reviews such that when a reviewer makes a comment it appears without his identity.
We succeeded in authorizing the user to the google documents by using the google-client-API (aouth + signet) credentials and the API console also showed positive results for the "request" sent over to the client and created a google document but to access that particular binary file we had to set the permission rights of the service account for which the google document is created which is different from the credentials account. We also tried hard coding and giving all access rights to anyone who wanted to open the file but it seems practically impossible to get those rights.

The second half of the project aimed at creating a flash box which directs the author to set the comment rights on the review google document as decided by the professor subject to the condition and complexity of the project. This will happen on the go and the author is notified to "enable commenting rights only" only if the faculty checks the option for that particular project.
On the other side whenever the reviewers click on the google document link attached to the project for reviewing or commenting on a project they will get a notification alert to log out of all google accounts in order to assure the anonymity of the reviewer. This is done because google documents does not support complete anonymity.
In this the assumption is that the google doc is created in the same manner as the other hyperlinks are added. Additionally whenever the the which will be already created by the author
===Creating Google document, Setting Up its Link===

* First and foremost a provision (button) for creating a Google document is added to the ''Your Work'' page of ''Assignments''.
* When the authors would select this button before submitting their assignment, a new Google doc is created.
* The document's Sharing criteria is set using google docs API such that the authors of the team can edit the document.
* Sharing criteria is also set such that anyone else having the link to this document can only comment.
* The authors would then copy paste their content, to be reviewed, on to the document.

[[File:Doceditor.png|thumb=Doceditor.png|center|alt=none|The expected display on the google documents]]

* Now the file sharable link must be pasted while submitting an Assignment in expertiza as shown below.
* The new Google doc link will be saved with other hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.

[[File:Googledoc.png|thumb=Googledoc.png|center|alt=none|The list of hyperlinks a project author would ideally have]]

===Publishing the document to Web===

* Open the File menu in Google doc and select Publish to the web....
* Make sure that the Automatically republish when changes are made checkbox is selected. Click the Start publishing button.
* When a confirmation prompt pops up, click the OK button.
* Click on the Embed tab to get the below screen, now copy the text in order to use it in our expertiza code.

[[File:Publish.png]]

===Security Risks===

As mentioned in the requirement document, there are 2 security risks associated with this project, they are:
*A situation where the peer reviewer forgets to logout would result in his/ her name being added to the history of document edits which will reveal the identity.
*Possible security violations like an user with access to the link deletes all the content on that doc.

Proposed solution to mitigate the risk:
*When a reviewer goes on the page of submitted contents, he'll be shown an alert message to logout from google accounts if there exists a google docs link in the submitted content and instructor has enabled anonymous commenting.
*The authors of the project will be shown an alert to modify the settings of their google doc to 'Anyone with the link can comment' when they submit a google doc link.

[[File:can_comment.png|thumb=can_comment.png|center|alt = ScreenShot of google document settings|ScreenShot of google document settings]]

*As it can be seen, Google doc has 3 access levels and the 'can comment' option will allow the users only to add more comments on the Google doc. They won't be able to edit or delete previously entered comments.
*Doing this will ensure that no user even unintentionally will be able to delete or edit previous comments which might be of great value to the authors of that project.
* Also the anonymity is handled if the user directly comments on the document without loging in into other google accounts.

===Embedding the document editor in expertiza===

* When an instructor will create a new assignment, he should be able to select a checkbox if he wants to enable anonymous commenting for google docs.
* If the instructor selects this then the authors will not be able to identify the individuals commenting on the doc.
* The below image shows how we aim to create a checkbox about the same for the instructor.

* We will try to create an alert message whenever the author submits a google doc link.
* The alert message will ask the author to change the sharing settings of the doc to 'Anyone with the link can comment'.
* This message should be thrown only when the author submits a google doc link and not any other link.
* The below image shows the desirable alert message when author tries to submit a google doc link.

[[File:google doc.png|center|]]

* If the instructor has enabled anonymous commenting on google docs then the reviewer should see an alert message which will ask the reviewer to log out from all google accounts before opening the google doc link.
* The reviewer will need to logout because google allows anonymous commenting on a doc only if the user is currently not logged into any google account.
* The below image shows the desirable alert message when a reviewer tries to review a project which has google docs in its submission and anonymous commenting is enabled.

[[File:anonymous.png|center|]]

== '''Project File and Database additions''' ==

* The new outcome will involve accessing the database table 'assignments' and we will make a change to the schema of the table by adding a column 'allow_anonymous_commenting' of the type 'Boolean' to indicate whether the professor has asked the project developers to have a review document created with the rights of anonymous comments.
* To incorporate the database changes we will generate a migration file in the "db" migrate named: '_add_allow_anonymous_commenting_to_assignemnnts.rb'
* The 'factories' file in the spec will have a variable added with the default value set as 'FALSE'
* '_genral.html.erb' page in the edit assignments view will have a 'check box' and a label added to it.
* A function will be added in the 'assignments_form' model which sets the visibility to false/ true depending on the input
* Newly added Google doc hyperlinks will be saved with other assignment hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.

== '''Testing Plan''' ==

This UI enhancement will be tested to check whether the following required functionalities are implemented successfully:

i. Any user having the doc link should only be able to comment on the Google doc 
ii. Changes made in the original Google doc should be reflected in the embedded doc editor in expertiza 
iii. Users need not login to comment in the Google doc 
iv. All comments made must be anonymous 
v. Multiple comments made at the same time should not lead to any conflicts 

== '''References''' ==

*[https://community.canvaslms.com/docs/DOC-1885 Guide to Embedding Google doc editor]
*[https://expertiza.ncsu.edu/ Expertiza application]
*[https://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

CSC/ECE 517 Fall 2016/ E1700 Integrate Google doc editor/viewer

2016-12-04T19:57:37Z

Asagarwa: /* Project File and Database additions */

=='''Expertiza 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 it’s code is available on Github. Using Expertiza students can bid for a particular project topic and the faculty assigns the same to different groups. Students can track their grades for previous projects and make new submissions for current projects. It also allows students to review each other’s work and improve their work upon this feedback.

=='''Project Description'''==

Currently the instructor creates rubrics for an assignment through questionnaires which students use to review other students' submissions. The only way reviewers can suggest some more changes to the author is by using the 'additional comments' section in the review form which is not very helpful. In this project we will be looking towards improving this functionality by adding an extra medium through which multiple reviewers can collectively comment on the author's work and collaborate their answers in a constructive way. This will be achieved by displaying alert messages to the authors and the reviewers who will use the newly created Google document links embedded into Expertiza. Every project will have a Google doc link for itself which the reviewers can access and make further comments about the project. Once on the Google doc, the reviewer's comments will be posted anonymously, the reviewer's comment will be anonymous to both, other fellow reviewers as well as the author. This feature will help the author to better understand where is his work exactly lacking and how exactly should the changes be worked upon based on the comments received. The reviewers will just need the Google doc link to post comments and it wouldn't be required to login into Expertiza or any google account for using this feature.

== '''Key Points To Consider''' ==

* The alert message should only pop up when the faculty as indicated to do so
* The Google doc link needs to be added on the submissions page by the author of the project
* The settings for the Google doc should be set to "anyone with link can comment" by the author
* A peer reviewer needs be directed not login to any Google account to comment on the doc, and all peer reviewer comments shall be anonymous
* Multiple commenting at a specific instance is taken care of by the google document settings and it will be placed one below the other.

== '''Approach''' ==

Generally, we can always create a Google document, slide presentation, or spreadsheet using Google Drive and then embed that document anywhere in our application using iFrame as a dynamic rich content editor. The rich content editor is used in features that support the editor (Announcements, Quizzes or Collaborative Reviewing in our case). Any time you make changes to the Google document (like comments), it will be automatically updated in the application's content editor.

The first phase of our project aimed at embedding a google a document which enables the project author to automatically generate a google document with specified permissions for the reviews such that when a reviewer makes a comment it appears without his identity.
We succeeded in authorizing the user to the google documents by using the google-client-API (aouth + signet) credentials and the API console also showed positive results for the "request" sent over to the client and created a google document but to access that particular binary file we had to set the permission rights of the service account for which the google document is created which is different from the credentials account. We also tried hard coding and giving all access rights to anyone who wanted to open the file but it seems practically impossible to get those rights.

The second half of the project aimed at creating a flash box which directs the author to set the comment rights on the review google document as decided by the professor subject to the condition and complexity of the project. This will happen on the go and the author is notified to "enable commenting rights only" only if the faculty checks the option for that particular project.
On the other side whenever the reviewers click on the google document link attached to the project for reviewing or commenting on a project they will get a notification alert to log out of all google accounts in order to assure the anonymity of the reviewer. This is done because google documents does not support complete anonymity.
In this the assumption is that the google doc is created in the same manner as the other hyperlinks are added. Additionally whenever the the which will be already created by the author
===Creating Google document, Setting Up its Link===

* First and foremost a provision (button) for creating a Google document is added to the ''Your Work'' page of ''Assignments''.
* When the authors would select this button before submitting their assignment, a new Google doc is created.
* The document's Sharing criteria is set using google docs API such that the authors of the team can edit the document.
* Sharing criteria is also set such that anyone else having the link to this document can only comment.
* The authors would then copy paste their content, to be reviewed, on to the document.

[[File:Doceditor.png|thumb=Doceditor.png|center|alt=none|The expected display on the google documents]]

* Now the file sharable link must be pasted while submitting an Assignment in expertiza as shown below.
* The new Google doc link will be saved with other hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.

[[File:Googledoc.png|thumb=Googledoc.png|center|alt=none|The list of hyperlinks a project author would ideally have]]

===Publishing the document to Web===

* Open the File menu in Google doc and select Publish to the web....
* Make sure that the Automatically republish when changes are made checkbox is selected. Click the Start publishing button.
* When a confirmation prompt pops up, click the OK button.
* Click on the Embed tab to get the below screen, now copy the text in order to use it in our expertiza code.

[[File:Publish.png]]

===Security Risks===

As mentioned in the requirement document, there are 2 security risks associated with this project, they are:
*A situation where the peer reviewer forgets to logout would result in his/ her name being added to the history of document edits which will reveal the identity.
*Possible security violations like an user with access to the link deletes all the content on that doc.

Proposed solution to mitigate the risk:
*When a reviewer goes on the page of submitted contents, he'll be shown an alert message to logout from google accounts if there exists a google docs link in the submitted content and instructor has enabled anonymous commenting.
*The authors of the project will be shown an alert to modify the settings of their google doc to 'Anyone with the link can comment' when they submit a google doc link.

[[File:can_comment.png|thumb=can_comment.png|center|alt = ScreenShot of google document settings|ScreenShot of google document settings]]

*As it can be seen, Google doc has 3 access levels and the 'can comment' option will allow the users only to add more comments on the Google doc. They won't be able to edit or delete previously entered comments.
*Doing this will ensure that no user even unintentionally will be able to delete or edit previous comments which might be of great value to the authors of that project.
* Also the anonymity is handled if the user directly comments on the document without loging in into other google accounts.

===Embedding the document editor in expertiza===

* We will try to create an alert message whenever the author submits a google doc link.
* The alert message will ask the author to change the sharing settings of the doc to 'Anyone with the link can comment'.
* This message should be thrown only when the author submits a google doc link and not any other link.
* The below image shows the desirable alert message when author tries to submit a google doc link.

[[File:google doc.png|center|]]

* If the instructor has enabled anonymous commenting on google docs then the reviewer should see an alert message which will ask the reviewer to log out from all google accounts before opening the google doc link.
* The reviewer will need to logout because google allows anonymous commenting on a doc only if the user is currently not logged into any google account.
* The below image shows the desirable alert message when a reviewer tries to review a project which has google docs in its submission and anonymous commenting is enabled.

[[File:anonymous.png|center|]]

== '''Project File and Database additions''' ==

* The new outcome will involve accessing the database table 'assignments' and we will make a change to the schema of the table by adding a column 'allow_anonymous_commenting' of the type 'Boolean' to indicate whether the professor has asked the project developers to have a review document created with the rights of anonymous comments.
* To incorporate the database changes we will generate a migration file in the "db" migrate named: '_add_allow_anonymous_commenting_to_assignemnnts.rb'
* The 'factories' file in the spec will have a variable added with the default value set as 'FALSE'
* '_genral.html.erb' page in the edit assignments view will have a 'check box' and a label added to it.
* A function will be added in the 'assignments_form' model which sets the visibility to false/ true depending on the input
* Newly added Google doc hyperlinks will be saved with other assignment hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.

== '''Testing Plan''' ==

This UI enhancement will be tested to check whether the following required functionalities are implemented successfully:

i. Any user having the doc link should only be able to comment on the Google doc 
ii. Changes made in the original Google doc should be reflected in the embedded doc editor in expertiza 
iii. Users need not login to comment in the Google doc 
iv. All comments made must be anonymous 
v. Multiple comments made at the same time should not lead to any conflicts 

== '''References''' ==

*[https://community.canvaslms.com/docs/DOC-1885 Guide to Embedding Google doc editor]
*[https://expertiza.ncsu.edu/ Expertiza application]
*[https://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

CSC/ECE 517 Fall 2016/ E1700 Integrate Google doc editor/viewer

2016-12-04T19:53:07Z

Asagarwa: /* Embedding the document editor in expertiza */

=='''Expertiza 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 it’s code is available on Github. Using Expertiza students can bid for a particular project topic and the faculty assigns the same to different groups. Students can track their grades for previous projects and make new submissions for current projects. It also allows students to review each other’s work and improve their work upon this feedback.

=='''Project Description'''==

Currently the instructor creates rubrics for an assignment through questionnaires which students use to review other students' submissions. The only way reviewers can suggest some more changes to the author is by using the 'additional comments' section in the review form which is not very helpful. In this project we will be looking towards improving this functionality by adding an extra medium through which multiple reviewers can collectively comment on the author's work and collaborate their answers in a constructive way. This will be achieved by displaying alert messages to the authors and the reviewers who will use the newly created Google document links embedded into Expertiza. Every project will have a Google doc link for itself which the reviewers can access and make further comments about the project. Once on the Google doc, the reviewer's comments will be posted anonymously, the reviewer's comment will be anonymous to both, other fellow reviewers as well as the author. This feature will help the author to better understand where is his work exactly lacking and how exactly should the changes be worked upon based on the comments received. The reviewers will just need the Google doc link to post comments and it wouldn't be required to login into Expertiza or any google account for using this feature.

== '''Key Points To Consider''' ==

* The alert message should only pop up when the faculty as indicated to do so
* The Google doc link needs to be added on the submissions page by the author of the project
* The settings for the Google doc should be set to "anyone with link can comment" by the author
* A peer reviewer needs be directed not login to any Google account to comment on the doc, and all peer reviewer comments shall be anonymous
* Multiple commenting at a specific instance is taken care of by the google document settings and it will be placed one below the other.

== '''Approach''' ==

Generally, we can always create a Google document, slide presentation, or spreadsheet using Google Drive and then embed that document anywhere in our application using iFrame as a dynamic rich content editor. The rich content editor is used in features that support the editor (Announcements, Quizzes or Collaborative Reviewing in our case). Any time you make changes to the Google document (like comments), it will be automatically updated in the application's content editor.

The first phase of our project aimed at embedding a google a document which enables the project author to automatically generate a google document with specified permissions for the reviews such that when a reviewer makes a comment it appears without his identity.
We succeeded in authorizing the user to the google documents by using the google-client-API (aouth + signet) credentials and the API console also showed positive results for the "request" sent over to the client and created a google document but to access that particular binary file we had to set the permission rights of the service account for which the google document is created which is different from the credentials account. We also tried hard coding and giving all access rights to anyone who wanted to open the file but it seems practically impossible to get those rights.

The second half of the project aimed at creating a flash box which directs the author to set the comment rights on the review google document as decided by the professor subject to the condition and complexity of the project. This will happen on the go and the author is notified to "enable commenting rights only" only if the faculty checks the option for that particular project.
On the other side whenever the reviewers click on the google document link attached to the project for reviewing or commenting on a project they will get a notification alert to log out of all google accounts in order to assure the anonymity of the reviewer. This is done because google documents does not support complete anonymity.
In this the assumption is that the google doc is created in the same manner as the other hyperlinks are added. Additionally whenever the the which will be already created by the author
===Creating Google document, Setting Up its Link===

* First and foremost a provision (button) for creating a Google document is added to the ''Your Work'' page of ''Assignments''.
* When the authors would select this button before submitting their assignment, a new Google doc is created.
* The document's Sharing criteria is set using google docs API such that the authors of the team can edit the document.
* Sharing criteria is also set such that anyone else having the link to this document can only comment.
* The authors would then copy paste their content, to be reviewed, on to the document.

[[File:Doceditor.png|thumb=Doceditor.png|center|alt=none|The expected display on the google documents]]

* Now the file sharable link must be pasted while submitting an Assignment in expertiza as shown below.
* The new Google doc link will be saved with other hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.

[[File:Googledoc.png|thumb=Googledoc.png|center|alt=none|The list of hyperlinks a project author would ideally have]]

===Publishing the document to Web===

* Open the File menu in Google doc and select Publish to the web....
* Make sure that the Automatically republish when changes are made checkbox is selected. Click the Start publishing button.
* When a confirmation prompt pops up, click the OK button.
* Click on the Embed tab to get the below screen, now copy the text in order to use it in our expertiza code.

[[File:Publish.png]]

===Security Risks===

As mentioned in the requirement document, there are 2 security risks associated with this project, they are:
*A situation where the peer reviewer forgets to logout would result in his/ her name being added to the history of document edits which will reveal the identity.
*Possible security violations like an user with access to the link deletes all the content on that doc.

Proposed solution to mitigate the risk:
*When a reviewer goes on the page of submitted contents, he'll be shown an alert message to logout from google accounts if there exists a google docs link in the submitted content and instructor has enabled anonymous commenting.
*The authors of the project will be shown an alert to modify the settings of their google doc to 'Anyone with the link can comment' when they submit a google doc link.

[[File:can_comment.png|thumb=can_comment.png|center|alt = ScreenShot of google document settings|ScreenShot of google document settings]]

*As it can be seen, Google doc has 3 access levels and the 'can comment' option will allow the users only to add more comments on the Google doc. They won't be able to edit or delete previously entered comments.
*Doing this will ensure that no user even unintentionally will be able to delete or edit previous comments which might be of great value to the authors of that project.
* Also the anonymity is handled if the user directly comments on the document without loging in into other google accounts.

===Embedding the document editor in expertiza===

* We will try to create an alert message whenever the author submits a google doc link.
* The alert message will ask the author to change the sharing settings of the doc to 'Anyone with the link can comment'.
* This message should be thrown only when the author submits a google doc link and not any other link.
* The below image shows the desirable alert message when author tries to submit a google doc link.

[[File:google doc.png|center|]]

* If the instructor has enabled anonymous commenting on google docs then the reviewer should see an alert message which will ask the reviewer to log out from all google accounts before opening the google doc link.
* The reviewer will need to logout because google allows anonymous commenting on a doc only if the user is currently not logged into any google account.
* The below image shows the desirable alert message when a reviewer tries to review a project which has google docs in its submission and anonymous commenting is enabled.

[[File:anonymous.png|center|]]

== '''Project File and Database additions''' ==

* The new outcome will involve accessing the data base table 'assignments' and we have made a change to the schema of the table by adding a column 'allow_anonymous_commenting' of the type 'Boolean' to indicate whether the professor has asked the project developers to have a review document created with the rights of anonymous comments.
* To incorporate the data base changes we generated a migration file in the "db" migrate named: '_add_allow_anonymous_commenting_to_assignemnnts.rb'
* The 'factories' file in the spec has a variable added with the default value set as 'FALSE'
* '_genral.html.erb' page in the edit assignments view has a 'check box' and a label added to it.
* A function is added in the 'assignments_form' model which sets the visibility to false/ true depending on the input
* The submitted_content view file '_main.html.erb' has the button to upload the google doc link.
* The 'submitted_content_controller.erb' has the code which directs the author to enable the anonymous commenting.
* Newly added Google doc hyperlinks will be saved with other assignment hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.
* The iFrame tag will be added to the 'view.html.erb' file in 'response' View in order to embed the Google doc.

== '''Testing Plan''' ==

This UI enhancement will be tested to check whether the following required functionalities are implemented successfully:

i. Any user having the doc link should only be able to comment on the Google doc 
ii. Changes made in the original Google doc should be reflected in the embedded doc editor in expertiza 
iii. Users need not login to comment in the Google doc 
iv. All comments made must be anonymous 
v. Multiple comments made at the same time should not lead to any conflicts 

== '''References''' ==

*[https://community.canvaslms.com/docs/DOC-1885 Guide to Embedding Google doc editor]
*[https://expertiza.ncsu.edu/ Expertiza application]
*[https://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

CSC/ECE 517 Fall 2016/ E1700 Integrate Google doc editor/viewer

2016-12-04T19:52:52Z

Asagarwa: /* Embedding the document editor in expertiza */

=='''Expertiza 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 it’s code is available on Github. Using Expertiza students can bid for a particular project topic and the faculty assigns the same to different groups. Students can track their grades for previous projects and make new submissions for current projects. It also allows students to review each other’s work and improve their work upon this feedback.

=='''Project Description'''==

Currently the instructor creates rubrics for an assignment through questionnaires which students use to review other students' submissions. The only way reviewers can suggest some more changes to the author is by using the 'additional comments' section in the review form which is not very helpful. In this project we will be looking towards improving this functionality by adding an extra medium through which multiple reviewers can collectively comment on the author's work and collaborate their answers in a constructive way. This will be achieved by displaying alert messages to the authors and the reviewers who will use the newly created Google document links embedded into Expertiza. Every project will have a Google doc link for itself which the reviewers can access and make further comments about the project. Once on the Google doc, the reviewer's comments will be posted anonymously, the reviewer's comment will be anonymous to both, other fellow reviewers as well as the author. This feature will help the author to better understand where is his work exactly lacking and how exactly should the changes be worked upon based on the comments received. The reviewers will just need the Google doc link to post comments and it wouldn't be required to login into Expertiza or any google account for using this feature.

== '''Key Points To Consider''' ==

* The alert message should only pop up when the faculty as indicated to do so
* The Google doc link needs to be added on the submissions page by the author of the project
* The settings for the Google doc should be set to "anyone with link can comment" by the author
* A peer reviewer needs be directed not login to any Google account to comment on the doc, and all peer reviewer comments shall be anonymous
* Multiple commenting at a specific instance is taken care of by the google document settings and it will be placed one below the other.

== '''Approach''' ==

Generally, we can always create a Google document, slide presentation, or spreadsheet using Google Drive and then embed that document anywhere in our application using iFrame as a dynamic rich content editor. The rich content editor is used in features that support the editor (Announcements, Quizzes or Collaborative Reviewing in our case). Any time you make changes to the Google document (like comments), it will be automatically updated in the application's content editor.

The first phase of our project aimed at embedding a google a document which enables the project author to automatically generate a google document with specified permissions for the reviews such that when a reviewer makes a comment it appears without his identity.
We succeeded in authorizing the user to the google documents by using the google-client-API (aouth + signet) credentials and the API console also showed positive results for the "request" sent over to the client and created a google document but to access that particular binary file we had to set the permission rights of the service account for which the google document is created which is different from the credentials account. We also tried hard coding and giving all access rights to anyone who wanted to open the file but it seems practically impossible to get those rights.

The second half of the project aimed at creating a flash box which directs the author to set the comment rights on the review google document as decided by the professor subject to the condition and complexity of the project. This will happen on the go and the author is notified to "enable commenting rights only" only if the faculty checks the option for that particular project.
On the other side whenever the reviewers click on the google document link attached to the project for reviewing or commenting on a project they will get a notification alert to log out of all google accounts in order to assure the anonymity of the reviewer. This is done because google documents does not support complete anonymity.
In this the assumption is that the google doc is created in the same manner as the other hyperlinks are added. Additionally whenever the the which will be already created by the author
===Creating Google document, Setting Up its Link===

* First and foremost a provision (button) for creating a Google document is added to the ''Your Work'' page of ''Assignments''.
* When the authors would select this button before submitting their assignment, a new Google doc is created.
* The document's Sharing criteria is set using google docs API such that the authors of the team can edit the document.
* Sharing criteria is also set such that anyone else having the link to this document can only comment.
* The authors would then copy paste their content, to be reviewed, on to the document.

[[File:Doceditor.png|thumb=Doceditor.png|center|alt=none|The expected display on the google documents]]

* Now the file sharable link must be pasted while submitting an Assignment in expertiza as shown below.
* The new Google doc link will be saved with other hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.

[[File:Googledoc.png|thumb=Googledoc.png|center|alt=none|The list of hyperlinks a project author would ideally have]]

===Publishing the document to Web===

* Open the File menu in Google doc and select Publish to the web....
* Make sure that the Automatically republish when changes are made checkbox is selected. Click the Start publishing button.
* When a confirmation prompt pops up, click the OK button.
* Click on the Embed tab to get the below screen, now copy the text in order to use it in our expertiza code.

[[File:Publish.png]]

===Security Risks===

As mentioned in the requirement document, there are 2 security risks associated with this project, they are:
*A situation where the peer reviewer forgets to logout would result in his/ her name being added to the history of document edits which will reveal the identity.
*Possible security violations like an user with access to the link deletes all the content on that doc.

Proposed solution to mitigate the risk:
*When a reviewer goes on the page of submitted contents, he'll be shown an alert message to logout from google accounts if there exists a google docs link in the submitted content and instructor has enabled anonymous commenting.
*The authors of the project will be shown an alert to modify the settings of their google doc to 'Anyone with the link can comment' when they submit a google doc link.

[[File:can_comment.png|thumb=can_comment.png|center|alt = ScreenShot of google document settings|ScreenShot of google document settings]]

*As it can be seen, Google doc has 3 access levels and the 'can comment' option will allow the users only to add more comments on the Google doc. They won't be able to edit or delete previously entered comments.
*Doing this will ensure that no user even unintentionally will be able to delete or edit previous comments which might be of great value to the authors of that project.
* Also the anonymity is handled if the user directly comments on the document without loging in into other google accounts.

===Embedding the document editor in expertiza===

* We will try to create an alert message whenever the author submits a google doc link.
* The alert message will ask the author to change the sharing settings of the doc to 'Anyone with the link can comment'.
* This message should be thrown only when the author submits a google doc link and not any other link.
* The below image shows the desirable alert message when author tries to submit a google doc link.

[[File:google doc.png|center|]]

* If the instructor has enabled anonymous commenting on google docs then the reviewer should see an alert message which will ask the reviewer to log out from all google accounts before opening the google doc link.
* The reviewer will need to logout because google allows anonymous commenting on a doc only if the user is currently not logged into any google account.
* The below image shows the desirable alert message when a reviewer tries to review a project which has google docs in its submission and anonymous commenting is enabled..

[[File:anonymous.png|center|]]

== '''Project File and Database additions''' ==

* The new outcome will involve accessing the data base table 'assignments' and we have made a change to the schema of the table by adding a column 'allow_anonymous_commenting' of the type 'Boolean' to indicate whether the professor has asked the project developers to have a review document created with the rights of anonymous comments.
* To incorporate the data base changes we generated a migration file in the "db" migrate named: '_add_allow_anonymous_commenting_to_assignemnnts.rb'
* The 'factories' file in the spec has a variable added with the default value set as 'FALSE'
* '_genral.html.erb' page in the edit assignments view has a 'check box' and a label added to it.
* A function is added in the 'assignments_form' model which sets the visibility to false/ true depending on the input
* The submitted_content view file '_main.html.erb' has the button to upload the google doc link.
* The 'submitted_content_controller.erb' has the code which directs the author to enable the anonymous commenting.
* Newly added Google doc hyperlinks will be saved with other assignment hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.
* The iFrame tag will be added to the 'view.html.erb' file in 'response' View in order to embed the Google doc.

== '''Testing Plan''' ==

This UI enhancement will be tested to check whether the following required functionalities are implemented successfully:

i. Any user having the doc link should only be able to comment on the Google doc 
ii. Changes made in the original Google doc should be reflected in the embedded doc editor in expertiza 
iii. Users need not login to comment in the Google doc 
iv. All comments made must be anonymous 
v. Multiple comments made at the same time should not lead to any conflicts 

== '''References''' ==

*[https://community.canvaslms.com/docs/DOC-1885 Guide to Embedding Google doc editor]
*[https://expertiza.ncsu.edu/ Expertiza application]
*[https://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

CSC/ECE 517 Fall 2016/ E1700 Integrate Google doc editor/viewer

2016-12-04T19:52:30Z

Asagarwa: /* Embedding the document editor in expertiza */

=='''Expertiza 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 it’s code is available on Github. Using Expertiza students can bid for a particular project topic and the faculty assigns the same to different groups. Students can track their grades for previous projects and make new submissions for current projects. It also allows students to review each other’s work and improve their work upon this feedback.

=='''Project Description'''==

Currently the instructor creates rubrics for an assignment through questionnaires which students use to review other students' submissions. The only way reviewers can suggest some more changes to the author is by using the 'additional comments' section in the review form which is not very helpful. In this project we will be looking towards improving this functionality by adding an extra medium through which multiple reviewers can collectively comment on the author's work and collaborate their answers in a constructive way. This will be achieved by displaying alert messages to the authors and the reviewers who will use the newly created Google document links embedded into Expertiza. Every project will have a Google doc link for itself which the reviewers can access and make further comments about the project. Once on the Google doc, the reviewer's comments will be posted anonymously, the reviewer's comment will be anonymous to both, other fellow reviewers as well as the author. This feature will help the author to better understand where is his work exactly lacking and how exactly should the changes be worked upon based on the comments received. The reviewers will just need the Google doc link to post comments and it wouldn't be required to login into Expertiza or any google account for using this feature.

== '''Key Points To Consider''' ==

* The alert message should only pop up when the faculty as indicated to do so
* The Google doc link needs to be added on the submissions page by the author of the project
* The settings for the Google doc should be set to "anyone with link can comment" by the author
* A peer reviewer needs be directed not login to any Google account to comment on the doc, and all peer reviewer comments shall be anonymous
* Multiple commenting at a specific instance is taken care of by the google document settings and it will be placed one below the other.

== '''Approach''' ==

Generally, we can always create a Google document, slide presentation, or spreadsheet using Google Drive and then embed that document anywhere in our application using iFrame as a dynamic rich content editor. The rich content editor is used in features that support the editor (Announcements, Quizzes or Collaborative Reviewing in our case). Any time you make changes to the Google document (like comments), it will be automatically updated in the application's content editor.

The first phase of our project aimed at embedding a google a document which enables the project author to automatically generate a google document with specified permissions for the reviews such that when a reviewer makes a comment it appears without his identity.
We succeeded in authorizing the user to the google documents by using the google-client-API (aouth + signet) credentials and the API console also showed positive results for the "request" sent over to the client and created a google document but to access that particular binary file we had to set the permission rights of the service account for which the google document is created which is different from the credentials account. We also tried hard coding and giving all access rights to anyone who wanted to open the file but it seems practically impossible to get those rights.

The second half of the project aimed at creating a flash box which directs the author to set the comment rights on the review google document as decided by the professor subject to the condition and complexity of the project. This will happen on the go and the author is notified to "enable commenting rights only" only if the faculty checks the option for that particular project.
On the other side whenever the reviewers click on the google document link attached to the project for reviewing or commenting on a project they will get a notification alert to log out of all google accounts in order to assure the anonymity of the reviewer. This is done because google documents does not support complete anonymity.
In this the assumption is that the google doc is created in the same manner as the other hyperlinks are added. Additionally whenever the the which will be already created by the author
===Creating Google document, Setting Up its Link===

* First and foremost a provision (button) for creating a Google document is added to the ''Your Work'' page of ''Assignments''.
* When the authors would select this button before submitting their assignment, a new Google doc is created.
* The document's Sharing criteria is set using google docs API such that the authors of the team can edit the document.
* Sharing criteria is also set such that anyone else having the link to this document can only comment.
* The authors would then copy paste their content, to be reviewed, on to the document.

[[File:Doceditor.png|thumb=Doceditor.png|center|alt=none|The expected display on the google documents]]

* Now the file sharable link must be pasted while submitting an Assignment in expertiza as shown below.
* The new Google doc link will be saved with other hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.

[[File:Googledoc.png|thumb=Googledoc.png|center|alt=none|The list of hyperlinks a project author would ideally have]]

===Publishing the document to Web===

* Open the File menu in Google doc and select Publish to the web....
* Make sure that the Automatically republish when changes are made checkbox is selected. Click the Start publishing button.
* When a confirmation prompt pops up, click the OK button.
* Click on the Embed tab to get the below screen, now copy the text in order to use it in our expertiza code.

[[File:Publish.png]]

===Security Risks===

As mentioned in the requirement document, there are 2 security risks associated with this project, they are:
*A situation where the peer reviewer forgets to logout would result in his/ her name being added to the history of document edits which will reveal the identity.
*Possible security violations like an user with access to the link deletes all the content on that doc.

Proposed solution to mitigate the risk:
*When a reviewer goes on the page of submitted contents, he'll be shown an alert message to logout from google accounts if there exists a google docs link in the submitted content and instructor has enabled anonymous commenting.
*The authors of the project will be shown an alert to modify the settings of their google doc to 'Anyone with the link can comment' when they submit a google doc link.

[[File:can_comment.png|thumb=can_comment.png|center|alt = ScreenShot of google document settings|ScreenShot of google document settings]]

*As it can be seen, Google doc has 3 access levels and the 'can comment' option will allow the users only to add more comments on the Google doc. They won't be able to edit or delete previously entered comments.
*Doing this will ensure that no user even unintentionally will be able to delete or edit previous comments which might be of great value to the authors of that project.
* Also the anonymity is handled if the user directly comments on the document without loging in into other google accounts.

===Embedding the document editor in expertiza===

* We will try to create an alert message whenever the author submits a google doc link.
* The alert message will ask the author to change the sharing settings of the doc to 'Anyone with the link can comment'.
* This message should be thrown only when the author submits a google doc link and not any other link.
* The below image shows the desirable alert message when author tries to submit a google doc link.

[[File:google doc.png|center|]]

* If the instructor has enabled anonymous commenting on google docs then the reviewer should see an alert message which will ask the reviewer to log out from all google accounts before opening the google doc link.
* The reviewer will need to logout because google allows anonymous commenting on a doc only if the user is currently not logged into any google account.
* The below image shows the desirable alert message when a reviewer tries to review a project which has google docs in its submission and anonymous commenting is enabled..

[[File:anonymous.png|center|]]

== '''Project File and Database additions''' ==

* The new outcome will involve accessing the data base table 'assignments' and we have made a change to the schema of the table by adding a column 'allow_anonymous_commenting' of the type 'Boolean' to indicate whether the professor has asked the project developers to have a review document created with the rights of anonymous comments.
* To incorporate the data base changes we generated a migration file in the "db" migrate named: '_add_allow_anonymous_commenting_to_assignemnnts.rb'
* The 'factories' file in the spec has a variable added with the default value set as 'FALSE'
* '_genral.html.erb' page in the edit assignments view has a 'check box' and a label added to it.
* A function is added in the 'assignments_form' model which sets the visibility to false/ true depending on the input
* The submitted_content view file '_main.html.erb' has the button to upload the google doc link.
* The 'submitted_content_controller.erb' has the code which directs the author to enable the anonymous commenting.
* Newly added Google doc hyperlinks will be saved with other assignment hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.
* The iFrame tag will be added to the 'view.html.erb' file in 'response' View in order to embed the Google doc.

== '''Testing Plan''' ==

This UI enhancement will be tested to check whether the following required functionalities are implemented successfully:

i. Any user having the doc link should only be able to comment on the Google doc 
ii. Changes made in the original Google doc should be reflected in the embedded doc editor in expertiza 
iii. Users need not login to comment in the Google doc 
iv. All comments made must be anonymous 
v. Multiple comments made at the same time should not lead to any conflicts 

== '''References''' ==

*[https://community.canvaslms.com/docs/DOC-1885 Guide to Embedding Google doc editor]
*[https://expertiza.ncsu.edu/ Expertiza application]
*[https://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

CSC/ECE 517 Fall 2016/ E1700 Integrate Google doc editor/viewer

2016-12-04T19:38:37Z

Asagarwa: /* Embedding the document editor in expertiza */

=='''Expertiza 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 it’s code is available on Github. Using Expertiza students can bid for a particular project topic and the faculty assigns the same to different groups. Students can track their grades for previous projects and make new submissions for current projects. It also allows students to review each other’s work and improve their work upon this feedback.

=='''Project Description'''==

Currently the instructor creates rubrics for an assignment through questionnaires which students use to review other students' submissions. The only way reviewers can suggest some more changes to the author is by using the 'additional comments' section in the review form which is not very helpful. In this project we will be looking towards improving this functionality by adding an extra medium through which multiple reviewers can collectively comment on the author's work and collaborate their answers in a constructive way. This will be achieved by displaying alert messages to the authors and the reviewers who will use the newly created Google document links embedded into Expertiza. Every project will have a Google doc link for itself which the reviewers can access and make further comments about the project. Once on the Google doc, the reviewer's comments will be posted anonymously, the reviewer's comment will be anonymous to both, other fellow reviewers as well as the author. This feature will help the author to better understand where is his work exactly lacking and how exactly should the changes be worked upon based on the comments received. The reviewers will just need the Google doc link to post comments and it wouldn't be required to login into Expertiza or any google account for using this feature.

== '''Key Points To Consider''' ==

* The alert message should only pop up when the faculty as indicated to do so
* The Google doc link needs to be added on the submissions page by the author of the project
* The settings for the Google doc should be set to "anyone with link can comment" by the author
* A peer reviewer needs be directed not login to any Google account to comment on the doc, and all peer reviewer comments shall be anonymous
* Multiple commenting at a specific instance is taken care of by the google document settings and it will be placed one below the other.

== '''Approach''' ==

Generally, we can always create a Google document, slide presentation, or spreadsheet using Google Drive and then embed that document anywhere in our application using iFrame as a dynamic rich content editor. The rich content editor is used in features that support the editor (Announcements, Quizzes or Collaborative Reviewing in our case). Any time you make changes to the Google document (like comments), it will be automatically updated in the application's content editor.

The first phase of our project aimed at embedding a google a document which enables the project author to automatically generate a google document with specified permissions for the reviews such that when a reviewer makes a comment it appears without his identity.
We succeeded in authorizing the user to the google documents by using the google-client-API (aouth + signet) credentials and the API console also showed positive results for the "request" sent over to the client and created a google document but to access that particular binary file we had to set the permission rights of the service account for which the google document is created which is different from the credentials account. We also tried hard coding and giving all access rights to anyone who wanted to open the file but it seems practically impossible to get those rights.

The second half of the project aimed at creating a flash box which directs the author to set the comment rights on the review google document as decided by the professor subject to the condition and complexity of the project. This will happen on the go and the author is notified to "enable commenting rights only" only if the faculty checks the option for that particular project.
On the other side whenever the reviewers click on the google document link attached to the project for reviewing or commenting on a project they will get a notification alert to log out of all google accounts in order to assure the anonymity of the reviewer. This is done because google documents does not support complete anonymity.
In this the assumption is that the google doc is created in the same manner as the other hyperlinks are added. Additionally whenever the the which will be already created by the author
===Creating Google document, Setting Up its Link===

* First and foremost a provision (button) for creating a Google document is added to the ''Your Work'' page of ''Assignments''.
* When the authors would select this button before submitting their assignment, a new Google doc is created.
* The document's Sharing criteria is set using google docs API such that the authors of the team can edit the document.
* Sharing criteria is also set such that anyone else having the link to this document can only comment.
* The authors would then copy paste their content, to be reviewed, on to the document.

[[File:Doceditor.png|thumb=Doceditor.png|center|alt=none|The expected display on the google documents]]

* Now the file sharable link must be pasted while submitting an Assignment in expertiza as shown below.
* The new Google doc link will be saved with other hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.

[[File:Googledoc.png|thumb=Googledoc.png|center|alt=none|The list of hyperlinks a project author would ideally have]]

===Publishing the document to Web===

* Open the File menu in Google doc and select Publish to the web....
* Make sure that the Automatically republish when changes are made checkbox is selected. Click the Start publishing button.
* When a confirmation prompt pops up, click the OK button.
* Click on the Embed tab to get the below screen, now copy the text in order to use it in our expertiza code.

[[File:Publish.png]]

===Security Risks===

As mentioned in the requirement document, there are 2 security risks associated with this project, they are:
*A situation where the peer reviewer forgets to logout would result in his/ her name being added to the history of document edits which will reveal the identity.
*Possible security violations like an user with access to the link deletes all the content on that doc.

Proposed solution to mitigate the risk:
*When a reviewer goes on the page of submitted contents, he'll be shown an alert message to logout from google accounts if there exists a google docs link in the submitted content and instructor has enabled anonymous commenting.
*The authors of the project will be shown an alert to modify the settings of their google doc to 'Anyone with the link can comment' when they submit a google doc link.

[[File:can_comment.png|thumb=can_comment.png|center|alt = ScreenShot of google document settings|ScreenShot of google document settings]]

*As it can be seen, Google doc has 3 access levels and the 'can comment' option will allow the users only to add more comments on the Google doc. They won't be able to edit or delete previously entered comments.
*Doing this will ensure that no user even unintentionally will be able to delete or edit previous comments which might be of great value to the authors of that project.
* Also the anonymity is handled if the user directly comments on the document without loging in into other google accounts.

===Embedding the document editor in expertiza===

* Our aim is to incorporate the dynamic content editor in the Review Assignments page, so that all the users can make collaborative suggestions in the document at the time of Review.
* In order to embed this editor, the code needs to be added in the View page for student responses.
* For example, to embed the editor for Assignment Responses the above code must be incorporated in the view.html.erb file in the response View, as shown below.

[[File:google doc.png|center|]]

* On building the code and running expertiza, we must be able to see the Google doc editor successfully embedded in the Assignment Reviews page.
* In the below image, we can see the frame where the saved Google doc is embedded. Instead of embedding the doc, we can also have a pop-up window of the doc.
* All the text in ''black'' in the below image, is the content added by the authors. Hence this cannot be edited by the reviewers.
* The text in colored font are the comments made by reviewers. The below comments have been written for illustrations sake.
* The comments in reality would be different and will be shown on the right side of the document page. (We can correlate this with comments made in MS Word document)
* The users need not login to Google in order to comment in the document. Hence, the comments made will be anonymous.
* If the users are already logged in to Google, constraints will be set such that their ''ID'' is hidden and their comments are still made anonymous.

[[File:anonymous.png|center|]]

== '''Project File and Database additions''' ==

* The new outcome will involve accessing the data base table 'assignments' and we have made a change to the schema of the table by adding a column 'allow_anonymous_commenting' of the type 'Boolean' to indicate whether the professor has asked the project developers to have a review document created with the rights of anonymous comments.
* To incorporate the data base changes we generated a migration file in the "db" migrate named: '_add_allow_anonymous_commenting_to_assignemnnts.rb'
* The 'factories' file in the spec has a variable added with the default value set as 'FALSE'
* '_genral.html.erb' page in the edit assignments view has a 'check box' and a label added to it.
* A function is added in the 'assignments_form' model which sets the visibility to false/ true depending on the input
* The submitted_content view file '_main.html.erb' has the button to upload the google doc link.
* The 'submitted_content_controller.erb' has the code which directs the author to enable the anonymous commenting.
* Newly added Google doc hyperlinks will be saved with other assignment hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.
* The iFrame tag will be added to the 'view.html.erb' file in 'response' View in order to embed the Google doc.

== '''Testing Plan''' ==

This UI enhancement will be tested to check whether the following required functionalities are implemented successfully:

i. Any user having the doc link should only be able to comment on the Google doc 
ii. Changes made in the original Google doc should be reflected in the embedded doc editor in expertiza 
iii. Users need not login to comment in the Google doc 
iv. All comments made must be anonymous 
v. Multiple comments made at the same time should not lead to any conflicts 

== '''References''' ==

*[https://community.canvaslms.com/docs/DOC-1885 Guide to Embedding Google doc editor]
*[https://expertiza.ncsu.edu/ Expertiza application]
*[https://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

File:Anonymous.png

2016-12-04T19:37:32Z

Asagarwa:

CSC/ECE 517 Fall 2016/ E1700 Integrate Google doc editor/viewer

2016-12-04T19:29:29Z

Asagarwa: /* Embedding the document editor in expertiza */

=='''Expertiza 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 it’s code is available on Github. Using Expertiza students can bid for a particular project topic and the faculty assigns the same to different groups. Students can track their grades for previous projects and make new submissions for current projects. It also allows students to review each other’s work and improve their work upon this feedback.

=='''Project Description'''==

Currently the instructor creates rubrics for an assignment through questionnaires which students use to review other students' submissions. The only way reviewers can suggest some more changes to the author is by using the 'additional comments' section in the review form which is not very helpful. In this project we will be looking towards improving this functionality by adding an extra medium through which multiple reviewers can collectively comment on the author's work and collaborate their answers in a constructive way. This will be achieved by displaying alert messages to the authors and the reviewers who will use the newly created Google document links embedded into Expertiza. Every project will have a Google doc link for itself which the reviewers can access and make further comments about the project. Once on the Google doc, the reviewer's comments will be posted anonymously, the reviewer's comment will be anonymous to both, other fellow reviewers as well as the author. This feature will help the author to better understand where is his work exactly lacking and how exactly should the changes be worked upon based on the comments received. The reviewers will just need the Google doc link to post comments and it wouldn't be required to login into Expertiza or any google account for using this feature.

== '''Key Points To Consider''' ==

* The alert message should only pop up when the faculty as indicated to do so
* The Google doc link needs to be added on the submissions page by the author of the project
* The settings for the Google doc should be set to "anyone with link can comment" by the author
* A peer reviewer needs be directed not login to any Google account to comment on the doc, and all peer reviewer comments shall be anonymous
* Multiple commenting at a specific instance is taken care of by the google document settings and it will be placed one below the other.

== '''Approach''' ==

Generally, we can always create a Google document, slide presentation, or spreadsheet using Google Drive and then embed that document anywhere in our application using iFrame as a dynamic rich content editor. The rich content editor is used in features that support the editor (Announcements, Quizzes or Collaborative Reviewing in our case). Any time you make changes to the Google document (like comments), it will be automatically updated in the application's content editor.

The first phase of our project aimed at embedding a google a document which enables the project author to automatically generate a google document with specified permissions for the reviews such that when a reviewer makes a comment it appears without his identity.
We succeeded in authorizing the user to the google documents by using the google-client-API (aouth + signet) credentials and the API console also showed positive results for the "request" sent over to the client and created a google document but to access that particular binary file we had to set the permission rights of the service account for which the google document is created which is different from the credentials account. We also tried hard coding and giving all access rights to anyone who wanted to open the file but it seems practically impossible to get those rights.

The second half of the project aimed at creating a flash box which directs the author to set the comment rights on the review google document as decided by the professor subject to the condition and complexity of the project. This will happen on the go and the author is notified to "enable commenting rights only" only if the faculty checks the option for that particular project.
On the other side whenever the reviewers click on the google document link attached to the project for reviewing or commenting on a project they will get a notification alert to log out of all google accounts in order to assure the anonymity of the reviewer. This is done because google documents does not support complete anonymity.
In this the assumption is that the google doc is created in the same manner as the other hyperlinks are added. Additionally whenever the the which will be already created by the author
===Creating Google document, Setting Up its Link===

* First and foremost a provision (button) for creating a Google document is added to the ''Your Work'' page of ''Assignments''.
* When the authors would select this button before submitting their assignment, a new Google doc is created.
* The document's Sharing criteria is set using google docs API such that the authors of the team can edit the document.
* Sharing criteria is also set such that anyone else having the link to this document can only comment.
* The authors would then copy paste their content, to be reviewed, on to the document.

[[File:Doceditor.png|thumb=Doceditor.png|center|alt=none|The expected display on the google documents]]

* Now the file sharable link must be pasted while submitting an Assignment in expertiza as shown below.
* The new Google doc link will be saved with other hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.

[[File:Googledoc.png|thumb=Googledoc.png|center|alt=none|The list of hyperlinks a project author would ideally have]]

===Publishing the document to Web===

* Open the File menu in Google doc and select Publish to the web....
* Make sure that the Automatically republish when changes are made checkbox is selected. Click the Start publishing button.
* When a confirmation prompt pops up, click the OK button.
* Click on the Embed tab to get the below screen, now copy the text in order to use it in our expertiza code.

[[File:Publish.png]]

===Security Risks===

As mentioned in the requirement document, there are 2 security risks associated with this project, they are:
*A situation where the peer reviewer forgets to logout would result in his/ her name being added to the history of document edits which will reveal the identity.
*Possible security violations like an user with access to the link deletes all the content on that doc.

Proposed solution to mitigate the risk:
*When a reviewer goes on the page of submitted contents, he'll be shown an alert message to logout from google accounts if there exists a google docs link in the submitted content and instructor has enabled anonymous commenting.
*The authors of the project will be shown an alert to modify the settings of their google doc to 'Anyone with the link can comment' when they submit a google doc link.

[[File:can_comment.png|thumb=can_comment.png|center|alt = ScreenShot of google document settings|ScreenShot of google document settings]]

*As it can be seen, Google doc has 3 access levels and the 'can comment' option will allow the users only to add more comments on the Google doc. They won't be able to edit or delete previously entered comments.
*Doing this will ensure that no user even unintentionally will be able to delete or edit previous comments which might be of great value to the authors of that project.
* Also the anonymity is handled if the user directly comments on the document without loging in into other google accounts.

===Embedding the document editor in expertiza===

* Our aim is to incorporate the dynamic content editor in the Review Assignments page, so that all the users can make collaborative suggestions in the document at the time of Review.
* In order to embed this editor, the code needs to be added in the View page for student responses.
* For example, to embed the editor for Assignment Responses the above code must be incorporated in the view.html.erb file in the response View, as shown below.

[[File:google doc.png|center|]]

* On building the code and running expertiza, we must be able to see the Google doc editor successfully embedded in the Assignment Reviews page.
* In the below image, we can see the frame where the saved Google doc is embedded. Instead of embedding the doc, we can also have a pop-up window of the doc.
* All the text in ''black'' in the below image, is the content added by the authors. Hence this cannot be edited by the reviewers.
* The text in colored font are the comments made by reviewers. The below comments have been written for illustrations sake.
* The comments in reality would be different and will be shown on the right side of the document page. (We can correlate this with comments made in MS Word document)
* The users need not login to Google in order to comment in the document. Hence, the comments made will be anonymous.
* If the users are already logged in to Google, constraints will be set such that their ''ID'' is hidden and their comments are still made anonymous.

[[File:Embeddoc.png]]

== '''Project File and Database additions''' ==

* The new outcome will involve accessing the data base table 'assignments' and we have made a change to the schema of the table by adding a column 'allow_anonymous_commenting' of the type 'Boolean' to indicate whether the professor has asked the project developers to have a review document created with the rights of anonymous comments.
* To incorporate the data base changes we generated a migration file in the "db" migrate named: '_add_allow_anonymous_commenting_to_assignemnnts.rb'
* The 'factories' file in the spec has a variable added with the default value set as 'FALSE'
* '_genral.html.erb' page in the edit assignments view has a 'check box' and a label added to it.
* A function is added in the 'assignments_form' model which sets the visibility to false/ true depending on the input
* The submitted_content view file '_main.html.erb' has the button to upload the google doc link.
* The 'submitted_content_controller.erb' has the code which directs the author to enable the anonymous commenting.
* Newly added Google doc hyperlinks will be saved with other assignment hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.
* The iFrame tag will be added to the 'view.html.erb' file in 'response' View in order to embed the Google doc.

== '''Testing Plan''' ==

This UI enhancement will be tested to check whether the following required functionalities are implemented successfully:

i. Any user having the doc link should only be able to comment on the Google doc 
ii. Changes made in the original Google doc should be reflected in the embedded doc editor in expertiza 
iii. Users need not login to comment in the Google doc 
iv. All comments made must be anonymous 
v. Multiple comments made at the same time should not lead to any conflicts 

== '''References''' ==

*[https://community.canvaslms.com/docs/DOC-1885 Guide to Embedding Google doc editor]
*[https://expertiza.ncsu.edu/ Expertiza application]
*[https://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

CSC/ECE 517 Fall 2016/ E1700 Integrate Google doc editor/viewer

2016-12-04T19:26:18Z

Asagarwa: /* Embedding the document editor in expertiza */

=='''Expertiza 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 it’s code is available on Github. Using Expertiza students can bid for a particular project topic and the faculty assigns the same to different groups. Students can track their grades for previous projects and make new submissions for current projects. It also allows students to review each other’s work and improve their work upon this feedback.

=='''Project Description'''==

Currently the instructor creates rubrics for an assignment through questionnaires which students use to review other students' submissions. The only way reviewers can suggest some more changes to the author is by using the 'additional comments' section in the review form which is not very helpful. In this project we will be looking towards improving this functionality by adding an extra medium through which multiple reviewers can collectively comment on the author's work and collaborate their answers in a constructive way. This will be achieved by displaying alert messages to the authors and the reviewers who will use the newly created Google document links embedded into Expertiza. Every project will have a Google doc link for itself which the reviewers can access and make further comments about the project. Once on the Google doc, the reviewer's comments will be posted anonymously, the reviewer's comment will be anonymous to both, other fellow reviewers as well as the author. This feature will help the author to better understand where is his work exactly lacking and how exactly should the changes be worked upon based on the comments received. The reviewers will just need the Google doc link to post comments and it wouldn't be required to login into Expertiza or any google account for using this feature.

== '''Key Points To Consider''' ==

* The alert message should only pop up when the faculty as indicated to do so
* The Google doc link needs to be added on the submissions page by the author of the project
* The settings for the Google doc should be set to "anyone with link can comment" by the author
* A peer reviewer needs be directed not login to any Google account to comment on the doc, and all peer reviewer comments shall be anonymous
* Multiple commenting at a specific instance is taken care of by the google document settings and it will be placed one below the other.

== '''Approach''' ==

Generally, we can always create a Google document, slide presentation, or spreadsheet using Google Drive and then embed that document anywhere in our application using iFrame as a dynamic rich content editor. The rich content editor is used in features that support the editor (Announcements, Quizzes or Collaborative Reviewing in our case). Any time you make changes to the Google document (like comments), it will be automatically updated in the application's content editor.

The first phase of our project aimed at embedding a google a document which enables the project author to automatically generate a google document with specified permissions for the reviews such that when a reviewer makes a comment it appears without his identity.
We succeeded in authorizing the user to the google documents by using the google-client-API (aouth + signet) credentials and the API console also showed positive results for the "request" sent over to the client and created a google document but to access that particular binary file we had to set the permission rights of the service account for which the google document is created which is different from the credentials account. We also tried hard coding and giving all access rights to anyone who wanted to open the file but it seems practically impossible to get those rights.

The second half of the project aimed at creating a flash box which directs the author to set the comment rights on the review google document as decided by the professor subject to the condition and complexity of the project. This will happen on the go and the author is notified to "enable commenting rights only" only if the faculty checks the option for that particular project.
On the other side whenever the reviewers click on the google document link attached to the project for reviewing or commenting on a project they will get a notification alert to log out of all google accounts in order to assure the anonymity of the reviewer. This is done because google documents does not support complete anonymity.
In this the assumption is that the google doc is created in the same manner as the other hyperlinks are added. Additionally whenever the the which will be already created by the author
===Creating Google document, Setting Up its Link===

* First and foremost a provision (button) for creating a Google document is added to the ''Your Work'' page of ''Assignments''.
* When the authors would select this button before submitting their assignment, a new Google doc is created.
* The document's Sharing criteria is set using google docs API such that the authors of the team can edit the document.
* Sharing criteria is also set such that anyone else having the link to this document can only comment.
* The authors would then copy paste their content, to be reviewed, on to the document.

[[File:Doceditor.png|thumb=Doceditor.png|center|alt=none|The expected display on the google documents]]

* Now the file sharable link must be pasted while submitting an Assignment in expertiza as shown below.
* The new Google doc link will be saved with other hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.

[[File:Googledoc.png|thumb=Googledoc.png|center|alt=none|The list of hyperlinks a project author would ideally have]]

===Publishing the document to Web===

* Open the File menu in Google doc and select Publish to the web....
* Make sure that the Automatically republish when changes are made checkbox is selected. Click the Start publishing button.
* When a confirmation prompt pops up, click the OK button.
* Click on the Embed tab to get the below screen, now copy the text in order to use it in our expertiza code.

[[File:Publish.png]]

===Security Risks===

As mentioned in the requirement document, there are 2 security risks associated with this project, they are:
*A situation where the peer reviewer forgets to logout would result in his/ her name being added to the history of document edits which will reveal the identity.
*Possible security violations like an user with access to the link deletes all the content on that doc.

Proposed solution to mitigate the risk:
*When a reviewer goes on the page of submitted contents, he'll be shown an alert message to logout from google accounts if there exists a google docs link in the submitted content and instructor has enabled anonymous commenting.
*The authors of the project will be shown an alert to modify the settings of their google doc to 'Anyone with the link can comment' when they submit a google doc link.

[[File:can_comment.png|thumb=can_comment.png|center|alt = ScreenShot of google document settings|ScreenShot of google document settings]]

*As it can be seen, Google doc has 3 access levels and the 'can comment' option will allow the users only to add more comments on the Google doc. They won't be able to edit or delete previously entered comments.
*Doing this will ensure that no user even unintentionally will be able to delete or edit previous comments which might be of great value to the authors of that project.
* Also the anonymity is handled if the user directly comments on the document without loging in into other google accounts.

===Embedding the document editor in expertiza===

* Our aim is to incorporate the dynamic content editor in the Review Assignments page, so that all the users can make collaborative suggestions in the document at the time of Review.
* In order to embed this editor, the code needs to be added in the View page for student responses.
* For example, to embed the editor for Assignment Responses the above code must be incorporated in the view.html.erb file in the response View, as shown below.

[[File:google doc.png]]

* On building the code and running expertiza, we must be able to see the Google doc editor successfully embedded in the Assignment Reviews page.
* In the below image, we can see the frame where the saved Google doc is embedded. Instead of embedding the doc, we can also have a pop-up window of the doc.
* All the text in ''black'' in the below image, is the content added by the authors. Hence this cannot be edited by the reviewers.
* The text in colored font are the comments made by reviewers. The below comments have been written for illustrations sake.
* The comments in reality would be different and will be shown on the right side of the document page. (We can correlate this with comments made in MS Word document)
* The users need not login to Google in order to comment in the document. Hence, the comments made will be anonymous.
* If the users are already logged in to Google, constraints will be set such that their ''ID'' is hidden and their comments are still made anonymous.

[[File:Embeddoc.png]]

== '''Project File and Database additions''' ==

* The new outcome will involve accessing the data base table 'assignments' and we have made a change to the schema of the table by adding a column 'allow_anonymous_commenting' of the type 'Boolean' to indicate whether the professor has asked the project developers to have a review document created with the rights of anonymous comments.
* To incorporate the data base changes we generated a migration file in the "db" migrate named: '_add_allow_anonymous_commenting_to_assignemnnts.rb'
* The 'factories' file in the spec has a variable added with the default value set as 'FALSE'
* '_genral.html.erb' page in the edit assignments view has a 'check box' and a label added to it.
* A function is added in the 'assignments_form' model which sets the visibility to false/ true depending on the input
* The submitted_content view file '_main.html.erb' has the button to upload the google doc link.
* The 'submitted_content_controller.erb' has the code which directs the author to enable the anonymous commenting.
* Newly added Google doc hyperlinks will be saved with other assignment hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.
* The iFrame tag will be added to the 'view.html.erb' file in 'response' View in order to embed the Google doc.

== '''Testing Plan''' ==

This UI enhancement will be tested to check whether the following required functionalities are implemented successfully:

i. Any user having the doc link should only be able to comment on the Google doc 
ii. Changes made in the original Google doc should be reflected in the embedded doc editor in expertiza 
iii. Users need not login to comment in the Google doc 
iv. All comments made must be anonymous 
v. Multiple comments made at the same time should not lead to any conflicts 

== '''References''' ==

*[https://community.canvaslms.com/docs/DOC-1885 Guide to Embedding Google doc editor]
*[https://expertiza.ncsu.edu/ Expertiza application]
*[https://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

File:Google doc.png

2016-12-04T19:24:54Z

Asagarwa:

CSC/ECE 517 Fall 2016/ E1700 Integrate Google doc editor/viewer

2016-12-04T19:09:05Z

Asagarwa: /* Security Risks */

=='''Expertiza 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 it’s code is available on Github. Using Expertiza students can bid for a particular project topic and the faculty assigns the same to different groups. Students can track their grades for previous projects and make new submissions for current projects. It also allows students to review each other’s work and improve their work upon this feedback.

=='''Project Description'''==

Currently the instructor creates rubrics for an assignment through questionnaires which students use to review other students' submissions. The only way reviewers can suggest some more changes to the author is by using the 'additional comments' section in the review form which is not very helpful. In this project we will be looking towards improving this functionality by adding an extra medium through which multiple reviewers can collectively comment on the author's work and collaborate their answers in a constructive way. This will be achieved by displaying alert messages to the authors and the reviewers who will use the newly created Google document links embedded into Expertiza. Every project will have a Google doc link for itself which the reviewers can access and make further comments about the project. Once on the Google doc, the reviewer's comments will be posted anonymously, the reviewer's comment will be anonymous to both, other fellow reviewers as well as the author. This feature will help the author to better understand where is his work exactly lacking and how exactly should the changes be worked upon based on the comments received. The reviewers will just need the Google doc link to post comments and it wouldn't be required to login into Expertiza or any google account for using this feature.

== '''Key Points To Consider''' ==

* The alert message should only pop up when the faculty as indicated to do so
* The Google doc link needs to be added on the submissions page by the author of the project
* The settings for the Google doc should be set to "anyone with link can comment" by the author
* A peer reviewer needs be directed not login to any Google account to comment on the doc, and all peer reviewer comments shall be anonymous
* Multiple commenting at a specific instance is taken care of by the google document settings and it will be placed one below the other.

== '''Approach''' ==

Generally, we can always create a Google document, slide presentation, or spreadsheet using Google Drive and then embed that document anywhere in our application using iFrame as a dynamic rich content editor. The rich content editor is used in features that support the editor (Announcements, Quizzes or Collaborative Reviewing in our case). Any time you make changes to the Google document (like comments), it will be automatically updated in the application's content editor.

The first phase of our project aimed at embedding a google a document which enables the project author to automatically generate a google document with specified permissions for the reviews such that when a reviewer makes a comment it appears without his identity.
We succeeded in authorizing the user to the google documents by using the google-client-API (aouth + signet) credentials and the API console also showed positive results for the "request" sent over to the client and created a google document but to access that particular binary file we had to set the permission rights of the service account for which the google document is created which is different from the credentials account. We also tried hard coding and giving all access rights to anyone who wanted to open the file but it seems practically impossible to get those rights.

The second half of the project aimed at creating a flash box which directs the author to set the comment rights on the review google document as decided by the professor subject to the condition and complexity of the project. This will happen on the go and the author is notified to "enable commenting rights only" only if the faculty checks the option for that particular project.
On the other side whenever the reviewers click on the google document link attached to the project for reviewing or commenting on a project they will get a notification alert to log out of all google accounts in order to assure the anonymity of the reviewer. This is done because google documents does not support complete anonymity.
In this the assumption is that the google doc is created in the same manner as the other hyperlinks are added. Additionally whenever the the which will be already created by the author
===Creating Google document, Setting Up its Link===

* First and foremost a provision (button) for creating a Google document is added to the ''Your Work'' page of ''Assignments''.
* When the authors would select this button before submitting their assignment, a new Google doc is created.
* The document's Sharing criteria is set using google docs API such that the authors of the team can edit the document.
* Sharing criteria is also set such that anyone else having the link to this document can only comment.
* The authors would then copy paste their content, to be reviewed, on to the document.

[[File:Doceditor.png|thumb=Doceditor.png|center|alt=none|The expected display on the google documents]]

* Now the file sharable link must be pasted while submitting an Assignment in expertiza as shown below.
* The new Google doc link will be saved with other hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.

[[File:Googledoc.png|thumb=Googledoc.png|center|alt=none|The list of hyperlinks a project author would ideally have]]

===Publishing the document to Web===

* Open the File menu in Google doc and select Publish to the web....
* Make sure that the Automatically republish when changes are made checkbox is selected. Click the Start publishing button.
* When a confirmation prompt pops up, click the OK button.
* Click on the Embed tab to get the below screen, now copy the text in order to use it in our expertiza code.

[[File:Publish.png]]

===Security Risks===

As mentioned in the requirement document, there are 2 security risks associated with this project, they are:
*A situation where the peer reviewer forgets to logout would result in his/ her name being added to the history of document edits which will reveal the identity.
*Possible security violations like an user with access to the link deletes all the content on that doc.

Proposed solution to mitigate the risk:
*When a reviewer goes on the page of submitted contents, he'll be shown an alert message to logout from google accounts if there exists a google docs link in the submitted content and instructor has enabled anonymous commenting.
*The authors of the project will be shown an alert to modify the settings of their google doc to 'Anyone with the link can comment' when they submit a google doc link.

[[File:can_comment.png|thumb=can_comment.png|center|alt = ScreenShot of google document settings|ScreenShot of google document settings]]

*As it can be seen, Google doc has 3 access levels and the 'can comment' option will allow the users only to add more comments on the Google doc. They won't be able to edit or delete previously entered comments.
*Doing this will ensure that no user even unintentionally will be able to delete or edit previous comments which might be of great value to the authors of that project.
* Also the anonymity is handled if the user directly comments on the document without loging in into other google accounts.

===Embedding the document editor in expertiza===

* Our aim is to incorporate the dynamic content editor in the Review Assignments page, so that all the users can make collaborative suggestions in the document at the time of Review.
* In order to embed this editor, the code needs to be added in the View page for student responses.
* For example, to embed the editor for Assignment Responses the above code must be incorporated in the view.html.erb file in the response View, as shown below.

[[File:Iframecode.png]]

* On building the code and running expertiza, we must be able to see the Google doc editor successfully embedded in the Assignment Reviews page.
* In the below image, we can see the frame where the saved Google doc is embedded. Instead of embedding the doc, we can also have a pop-up window of the doc.
* All the text in ''black'' in the below image, is the content added by the authors. Hence this cannot be edited by the reviewers.
* The text in colored font are the comments made by reviewers. The below comments have been written for illustrations sake.
* The comments in reality would be different and will be shown on the right side of the document page. (We can correlate this with comments made in MS Word document)
* The users need not login to Google in order to comment in the document. Hence, the comments made will be anonymous.
* If the users are already logged in to Google, constraints will be set such that their ''ID'' is hidden and their comments are still made anonymous.

[[File:Embeddoc.png]]

== '''Project File and Database additions''' ==

* The new outcome will involve accessing the data base table 'assignments' and we have made a change to the schema of the table by adding a column 'allow_anonymous_commenting' of the type 'Boolean' to indicate whether the professor has asked the project developers to have a review document created with the rights of anonymous comments.
* To incorporate the data base changes we generated a migration file in the "db" migrate named: '_add_allow_anonymous_commenting_to_assignemnnts.rb'
* The 'factories' file in the spec has a variable added with the default value set as 'FALSE'
* '_genral.html.erb' page in the edit assignments view has a 'check box' and a label added to it.
* A function is added in the 'assignments_form' model which sets the visibility to false/ true depending on the input
* The submitted_content view file '_main.html.erb' has the button to upload the google doc link.
* The 'submitted_content_controller.erb' has the code which directs the author to enable the anonymous commenting.
* Newly added Google doc hyperlinks will be saved with other assignment hyperlinks in the 'submitted_hyperlinks' column of 'teams' table.
* The iFrame tag will be added to the 'view.html.erb' file in 'response' View in order to embed the Google doc.

== '''Testing Plan''' ==

This UI enhancement will be tested to check whether the following required functionalities are implemented successfully:

i. Any user having the doc link should only be able to comment on the Google doc 
ii. Changes made in the original Google doc should be reflected in the embedded doc editor in expertiza 
iii. Users need not login to comment in the Google doc 
iv. All comments made must be anonymous 
v. Multiple comments made at the same time should not lead to any conflicts 

== '''References''' ==

*[https://community.canvaslms.com/docs/DOC-1885 Guide to Embedding Google doc editor]
*[https://expertiza.ncsu.edu/ Expertiza application]
*[https://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

CSC/ECE 517 Fall 2016/ E1700 Integrate Google doc editor/viewer

2016-11-15T02:21:37Z

Asagarwa: /* Security Risks */

File:Googledoc.png

2016-11-15T01:59:57Z

Asagarwa: uploaded a new version of "File:Googledoc.png"

File:Can comment.png

2016-11-15T01:17:12Z

Asagarwa: uploaded a new version of "File:Can comment.png"

CSC/ECE 517 Fall 2016/ E1700 Integrate Google doc editor/viewer

2016-11-15T01:15:17Z

Asagarwa: /* Security Risks */

CSC/ECE 517 Fall 2016/ E1700 Integrate Google doc editor/viewer

2016-11-15T01:08:19Z

Asagarwa:

File:Can comment.png

2016-11-15T01:00:34Z

Asagarwa:

File:Googledoc.png

2016-11-10T03:18:34Z

Asagarwa: uploaded a new version of "File:Googledoc.png"

CSC/ECE 517 Fall 2016/ E1700 Integrate Google doc editor/viewer

2016-11-10T03:10:43Z

Asagarwa:

File:Googledoc.png

2016-11-10T03:08:22Z

Asagarwa:

CSC/ECE 517 Fall 2016/ E1700 Integrate Google doc editor/viewer

2016-11-10T02:44:52Z

Asagarwa: /* Expertiza Background */

CSC/ECE 517 Fall 2016/ E1700 Integrate Google doc editor/viewer

2016-11-10T01:59:32Z

Asagarwa: /* Expertiza Background */

CSC/ECE 517 Fall 2016/ E1700 Integrate Google doc editor/viewer

2016-11-10T01:58:40Z

Asagarwa: Created page with "==Expertiza 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 p..."

==Expertiza 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 it’s code is available on Github. Using Expertiza students can bid for a particular project topic and the faculty assigns the same to different groups. Students can track their grades for previous projects and make new submissions for current projects. It also allows students to review each other’s work and improve their work upon this feedback.

CSC/ECE 517 Fall 2016

2016-11-10T01:56:04Z

Asagarwa: /* Final Project Design Document */

[http://www.example.com link title]==Calibration Assignment Submissions==
*[[Calibration Assignment Submission (Firebrick JS)]]
*[[Calibration Assignment Submission (Active Job)]]
==Writing Assignments 2==
*[[CSC/ECE 517 Fall 2016/E1666. Test team functionality]]
*[[CSC/ECE 517 Fall 2016/E1643. Refactor Suggestion controller]]
*[[CSC/ECE 517 Fall 2016/E1631. Refactoring Bidding Interface]]
*[[CSC/ECE 517 Fall 2016/E1674.Refactor leaderboard.rb and write unit tests]]
*[[CSC/ECE 517 Fall 2016/E1671. Unit Tests for participants.rb Hierarchy]]
*[[CSC/ECE 517 Fall 2016/E1668.Test e-mailing functionality]]
*[[CSC/ECE 517 Fall 2016/E1658. Refractor lottery_controller.rb and write integration tests]]
*[[CSC/ECE 517 Fall 2016/E1660. Review requirements and thresholds]]
*[[CSC/ECE 517 Fall 2016/E1650. Sort instructor views alphabetically by default]]
*[[CSC/ECE 517 Fall 2016/E1644. Refactor and test Teams Controller]]
*[[CSC/ECE 517 Fall 2016/E1645. Refactoring Tree Display Controller]]
*[[CSC/ECE 517 Fall 2016/E1659. Refactor on_the_fly_calc.rb]]
*[[CSC/ECE 517 Fall 2016/E1657. Introduce a Student View for instructors]]
*[[CSC/ECE 517 Fall 2016/E1653. Fix and improve rubric criteria]]
*[[CSC/ECE 517 Fall 2016/E1642. Refactor review_response_map.rb]]
*[[CSC/ECE 517 Fall 2016/E1633. Refactor different question types from quiz feature]]
*[[CSC/ECE_517_Fall_2016/E1664:_Feature_Test_Assignment_Creation]]
*[[CSC/ECE 517 Fall 2016/E1666. Test team functionality]]
*[[CSC/ECE_517_Fall_2016/E1654. Improve_date-picker_and_deadlines]]
*[[CSC/ECE_517_Fall_2016/E1652 Fix teammate advertisements and requests to join a team ]]
*[[CSC/ECE_517_Fall_2016/E1662. UI issues/fixes]]
*[[CSC/ECE_517_Fall_2016/E1673. Refactor question_type.rb]]
*[[CSC/ECE_517_Fall_2016/E1675. Timestamp for student file & hyperlink submissions]]
*[[CSC/ECE_517_Fall_2016/E1640. Refactor response.rb and response_helper.rb]]
*[[CSC/ECE 517 Fall 2016/E1634. Refactor and write unit test of due_date.rb and deadline_helper.rb]]
*[[CSC/ECE_517_Fall_2016/M1654._Improve_network_security_features]]
*[[CSC/ECE_517_Fall_2016/E1670._Unit_tests_for_answers.rb]]
*[[CSC/ECE_517_Fall_2016/E1641. Refactor review_mapping_controller.rb]]
*[[CSC/ECE_517_Fall_2016/M1652_Implement_ImageMap_Support_Servo]]
*[[CSC/ECE_517_Fall_2016/E1648/Add_past_due_assignment]]
*[[CSC/ECE 517 Fall 2016/E1656. Improve imports]]
*[[CSC/ECE_517_Fall_2016/M1653_Implement_HTML_form_validation]]
==Final Project Design Document==
*[[CSC/ECE 517 Fall 2016 E1696 Improve Self-Review]]
*[[CSC/ECE 517 Fall 2016 E1676 Role-based reviewing]]
*[[CSC/ECE 517 Fall 2016/E1680. Improve survey functionality]]
*[[CSC/ECE 517 Fall 2016/E1693. Drag-and-drop interface for creating rubrics]]
*[[CSC/ECE 517 Fall 2016/E1701. Accelerate RSpec testing]]
*[[CSC/ECE 517 Fall 2016/E1705. Tracking the time students look at the others' submissions]]
*[[CSC/ECE 517 Fall 2016/E1688. Send feedback to support + tree display improvement]]
*[[CSC/ECE 517 Fall 2016 E1707: Top trading cycles to exclude previous teammates]]
*[[CSC/ECE 517 Fall 2016 E1678: Review configuration options]]
*[[CSC/ECE 517 Fall 2016 E1682: Improve score calculation]]
*[[CSC/ECE 517 Fall 2016 E1684: Feature Test for Assignment Submission]]
*[[CSC/ECE 517 Fall 2016 E1689: Anonymous Chat Between Author and Reviewer]]
*[[CSC/ECE 517 Fall 2016 E1703: Logging for Expertiza]]
*[[CSC/ECE 517 Fall 2016 E1708: Improvements to staggered-deadline assignments]]
*[[CSC/ECE 517 Fall 2016 E1685: UI changes for review and score reports]]
*[[CSC/ECE 517 Fall 2016/ M1653 Implement HTML form validation]]
*[[CSC/ECE 517 Fall 2016/ E1700 Integrate Google doc editor/viewer]]

CSC/ECE 517 Fall 2016/E1659. Refactor on the fly calc.rb

2016-11-05T00:45:44Z

Asagarwa:

This wiki page is for the description of changes made under E1659 OSS assignment for Fall 2016, CSC/ECE 517.

== Peer Review Information ==

For users intending to view the deployed Expertiza associated with this assignment, the credentials are below:
* Instructor login: username -> instructor6, password -> password
* Student login: username -> student5431, password -> password
* Student login: username -> student5427, password -> password

== Expertiza 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 it’s code is available on Github. Using Expertiza students can bid for a particular project topic and the faculty assigns the same to different groups. Students can track their grades for previous projects and make new submissions for current projects. It also allows students to review each other’s work and improve their work upon this feedback.

== Description of the current project ==

We worked on a module named on_the_fly_calc in this Expertiza based OSS project. We focussed on refactoring some methods which were very complex and also modified the language of the module to make it more ruby-istic. We also worked on refactoring the code to reduce redundancy. Our goal in this project was to make this model easier to read and maintain.

== Files modified in current project ==

A model was modified for this project namely: 
1. On_the_fly_calc

=== On_the_fly_calc ===

On_the_fly_calc is a module that is included in assignment.rb. What this module does is that it calculates the score for both students and instructors. E.g., when a student clicks “view my score”, Expertiza calculates the review scores for each review. This is called “on the fly” because expertiza stores the review scores based on each question (in answers table), but does not store the total score that a reviewer gives to a reviewee. It directly calculates the total review score for each review, using the score values in the answer table during run-time.
Eg: For a set of 4 questions a reviewer gives 5 on 5 points for 2 questions and 4 on 5 points for other 2 questions. So only these points are stored in the database and when a reviewee clicks to see the score given by this particular reviewer, on_the_fly_calc module helps calculate the total score i.e. 90% in this case.

== List of changes ==
The main aim was to reduce the complexity grade of ‘on_the_fly_calc.rb’ module from “F” to “C” in CodeClimate, which was achieved. We worked on the following work items(WIs) in order to refactor the module: 
WI1 : Refactor ‘Similar Code’ in lines 34-42 and 62-70 in on_the_fly_calc.rb 
WI2 : Prefer ‘each’ over every instance of ‘for loop’ 
WI3 : Refactor ‘scores’ method to reduce ABC (assignment, branch and condition) size 
WI4 : Refactor ‘compute_reviews_hash’ method to reduce ABC (assignment, branch and condition) size 
WI5 : Refactor ‘compute_avg_and_ranges_hash’ method to reduce ABC (assignment, branch and condition) size

=== Solutions Implemented and Delivered ===

==== Refactored similar code ====

Lines 34-42 and 62-70 were similar in compute_reviews_hash method. Hence, a dedicated method ‘calc_review_score’ was defined and this method was called in the both instances inside compute_reviews_hash.

Lines 34-42 in compute_reviews_hash:

[[File:Similar code1.png]]

Similar code in Lines 62-70:

[[File:Similar code 2.png]]

Refactored method 'calc_review_score' for the two similar codes:

[[File:Same code method.png]]

==== Each loop prefered over For loop ====

In every instance where ‘for’ loops were used in on_the_fly_calc module, ‘each…do’ was replaced instead. This significantly reduced the Cyclomatic complexity of the code.

The following screen shows the instances where for loops where replaced:

[[File:Eachloop.png]]

==== Refactored methods - 'scores', 'compute_reviews_hash', 'compute_avg_and_ranges_hash' ====

1. a) Method ‘scores’ was very complex, performing too many functions within a single method. Hence, every specific function was broken down into 4 separate smaller methods. This significantly reduced the Assignment, Branch, Condition size for ‘scores’ method.

<pre>
def scores(questions)
scores = {}
score_team = scores[:teams][index.to_s.to_sym]
score = score_team[:scores]
scores[:participants] = {}
participant_score #New method defined - participant_score
scores[:teams] = {}
index = 0
self.teams.each do |team|
score_team = {}
score_team[:team] = team
if self.varying_rubrics_by_round?
assess #New method defined - assess
calculate_score #New method defined - calculate_score
calculate_assessment #New method defined - calculate_assessment
else
assessments = ReviewResponseMap.get_assessments_for(team)
score = Answer.compute_scores(assessments, questions[:review])
end
index += 1
end
scores
end
</pre>

b) The following 4 methods were created after splitting the first method 
i. participant_score 

<pre>
def participant_score
self.participants.each do |participant|
scores[:participants][participant.id.to_s.to_sym] = participant.scores(questions)
end
end
</pre>

ii. assess 

<pre>
def assess
self.num_review_rounds.each do |i|
total_score = 0
total_num_of_assessments = 0 # calculate grades for each rounds
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
assessments = ReviewResponseMap.get_assessments_round_for(team, i)
round_sym = ("review" + i.to_s).to_sym
round = Answer.compute_scores(assessments, questions[round_sym])
total_num_of_assessments += assessments.size
total_score += round[:avg] * assessments.size.to_f unless round[:avg].nil?
end
end
</pre>

iii. calculate_score 

<pre>
def calculate_score
score = {}
score[:max] = -999_999_999
score[:min] = 999_999_999
score[:avg] = 0
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
self.num_review_rounds.each do |i|
round_sym = ("review" + i.to_s).to_sym
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
score[:max] = round[:max] if max_condition
score[:min] = round[:min] if min_condition
end
end
</pre>

iv. calculate_assessment

<pre>
def calculate_assessment
if total_num_of_assessments.nonzero?
score[:avg] = total_score / total_num_of_assessments
else
score[:avg] = nil
score[:max] = 0
score[:min] = 0
end
end
</pre>

c) Complex and long statements or loops were broken into simpler multiple statements.

For example, the unless condition in Lines 132-134 was refactored to Line 127. This reduced the Perceived Complexity of 'scores' method.

[[File:Conditionsimpler.png]]

2. a) We also refactored method ‘compute_reviews_hash’ which was very complex and modularized individual functionalities into 2 separate methods.
b) The following 2 methods were created and called after refactoring: 
i. scores_varying_rubrics 
ii. scores_non_varying_rubrics 

3. Similarly, method ‘compute_avg_and_ranges_hash’ was also refactored and a seperate method calc_contri_score was defined to calculate contributor’s score. This method was then called from ‘compute_avg_and_ranges_hash’.

[[File:rsz_unnamed.png]]
The Code Climate Grade Before Refactoring

[[File:rsz_1after.png]]
The Code Climate Grade After Refactoring
== Testing Details==

===UI Testing===

1. Login into Expertiza as a student or an instructor.(You can use the student ids in the peer review section above) 
2. Go to an assignment which has some prior reviews for a previous project and click on view scores. 
3. The total score for a review is calculated on the fly using this module. 
4. You will be able to see the average score that each reviewer gave you on the top right of your page. 
5. This ensured that the refactoring done by us didn't break the code and it delivered it's expected functionality. 

===Unit Testing===

We created unit tests as well to check that the module performs as it did earlier before we refactored it. There were no pre-existing test cases for this module. 
We first had to create a dummy class to test the module. The new test file can be viewed at the mentioned GitHub link.

[[File:testtt.png]]
All the test cases pass.

== Scope for future improvement ==

Every code has future improvements possible. We have evolved the Code Climate Grade 'F' to a Grade 'C' currently by removing the Cyclomatic complexity, the Perceived Complexity and replaced with the "for" with the 'each' to reduce the size .
There are modifications that can still reduce the "ABC" Assignment Branches and Conditions Score as we can include the variables and functions in the "before action clauses", and rename long names with shorter yet appropriate names thus moving towards the score of "A".

CSC/ECE 517 Fall 2016/E1659. Refactor on the fly calc.rb

2016-11-05T00:44:33Z

Asagarwa: /* Unit Testing */

This wiki page is for the description of changes made under E1659 OSS assignment for Fall 2016, CSC/ECE 517.

== Peer Review Information ==

For users intending to view the deployed Expertiza associated with this assignment, the credentials are below:
* Instructor login: username -> instructor6, password -> password
* Student login: username -> student5431, password -> password
* Student login: username -> student5427, password -> password

== Expertiza 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 it’s code is available on Github. Using Expertiza students can bid for a particular project topic and the faculty assigns the same to different groups. Students can track their grades for previous projects and make new submissions for current projects. It also allows students to review each other’s work and improve their work upon this feedback.

== Description of the current project ==

We worked on a module named on_the_fly_calc in this Expertiza based OSS project. We focussed on refactoring some methods which were very complex and also modified the language of the module to make it more ruby-istic. We also worked on refactoring the code to reduce redundancy. Our goal in this project was to make this model easier to read and maintain.

== Files modified in current project ==

A model was modified for this project namely: 
1. On_the_fly_calc

=== On_the_fly_calc ===

On_the_fly_calc is a module that is included in assignment.rb. What this module does is that it calculates the score for both students and instructors. E.g., when a student clicks “view my score”, Expertiza calculates the review scores for each review. This is called “on the fly” because expertiza stores the review scores based on each question (in answers table), but does not store the total score that a reviewer gives to a reviewee. It directly calculates the total review score for each review, using the score values in the answer table during run-time.
Eg: For a set of 4 questions a reviewer gives 5 on 5 points for 2 questions and 4 on 5 points for other 2 questions. So only these points are stored in the database and when a reviewee clicks to see the score given by this particular reviewer, on_the_fly_calc module helps calculate the total score i.e. 90% in this case.

== List of changes ==
The main aim was to reduce the complexity grade of ‘on_the_fly_calc.rb’ module from “F” to “C” in CodeClimate, which was achieved. We worked on the following work items(WIs) in order to refactor the module: 
WI1 : Refactor ‘Similar Code’ in lines 34-42 and 62-70 in on_the_fly_calc.rb 
WI2 : Prefer ‘each’ over every instance of ‘for loop’ 
WI3 : Refactor ‘scores’ method to reduce ABC (assignment, branch and condition) size 
WI4 : Refactor ‘compute_reviews_hash’ method to reduce ABC (assignment, branch and condition) size 
WI5 : Refactor ‘compute_avg_and_ranges_hash’ method to reduce ABC (assignment, branch and condition) size

=== Solutions Implemented and Delivered ===

==== Refactored similar code ====

Lines 34-42 and 62-70 were similar in compute_reviews_hash method. Hence, a dedicated method ‘calc_review_score’ was defined and this method was called in the both instances inside compute_reviews_hash.

Lines 34-42 in compute_reviews_hash:

[[File:Similar code1.png]]

Similar code in Lines 62-70:

[[File:Similar code 2.png]]

Refactored method 'calc_review_score' for the two similar codes:

[[File:Same code method.png]]

==== Each loop prefered over For loop ====

In every instance where ‘for’ loops were used in on_the_fly_calc module, ‘each…do’ was replaced instead. This significantly reduced the Cyclomatic complexity of the code.

The following screen shows the instances where for loops where replaced:

[[File:Eachloop.png]]

==== Refactored methods - 'scores', 'compute_reviews_hash', 'compute_avg_and_ranges_hash' ====

1. a) Method ‘scores’ was very complex, performing too many functions within a single method. Hence, every specific function was broken down into 4 separate smaller methods. This significantly reduced the Assignment, Branch, Condition size for ‘scores’ method.

<pre>
def scores(questions)
scores = {}
score_team = scores[:teams][index.to_s.to_sym]
score = score_team[:scores]
scores[:participants] = {}
participant_score #New method defined - participant_score
scores[:teams] = {}
index = 0
self.teams.each do |team|
score_team = {}
score_team[:team] = team
if self.varying_rubrics_by_round?
assess #New method defined - assess
calculate_score #New method defined - calculate_score
calculate_assessment #New method defined - calculate_assessment
else
assessments = ReviewResponseMap.get_assessments_for(team)
score = Answer.compute_scores(assessments, questions[:review])
end
index += 1
end
scores
end
</pre>

b) The following 4 methods were created after splitting the first method 
i. participant_score 

<pre>
def participant_score
self.participants.each do |participant|
scores[:participants][participant.id.to_s.to_sym] = participant.scores(questions)
end
end
</pre>

ii. assess 

<pre>
def assess
self.num_review_rounds.each do |i|
total_score = 0
total_num_of_assessments = 0 # calculate grades for each rounds
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
assessments = ReviewResponseMap.get_assessments_round_for(team, i)
round_sym = ("review" + i.to_s).to_sym
round = Answer.compute_scores(assessments, questions[round_sym])
total_num_of_assessments += assessments.size
total_score += round[:avg] * assessments.size.to_f unless round[:avg].nil?
end
end
</pre>

iii. calculate_score 

<pre>
def calculate_score
score = {}
score[:max] = -999_999_999
score[:min] = 999_999_999
score[:avg] = 0
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
self.num_review_rounds.each do |i|
round_sym = ("review" + i.to_s).to_sym
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
score[:max] = round[:max] if max_condition
score[:min] = round[:min] if min_condition
end
end
</pre>

iv. calculate_assessment

<pre>
def calculate_assessment
if total_num_of_assessments.nonzero?
score[:avg] = total_score / total_num_of_assessments
else
score[:avg] = nil
score[:max] = 0
score[:min] = 0
end
end
</pre>

c) Complex and long statements or loops were broken into simpler multiple statements.

For example, the unless condition in Lines 132-134 was refactored to Line 127. This reduced the Perceived Complexity of 'scores' method.

[[File:Conditionsimpler.png]]

2. a) We also refactored method ‘compute_reviews_hash’ which was very complex and modularized individual functionalities into 2 separate methods.
b) The following 2 methods were created and called after refactoring: 
i. scores_varying_rubrics 
ii. scores_non_varying_rubrics 

3. Similarly, method ‘compute_avg_and_ranges_hash’ was also refactored and a seperate method calc_contri_score was defined to calculate contributor’s score. This method was then called from ‘compute_avg_and_ranges_hash’.

[[File:rsz_unnamed.png]]
The Code Climate Grade Before Refactoring

[[File:rsz_1after.png]]
The Code Climate Grade After Refactoring
== Testing Details==

===UI Testing===

1. Login into Expertiza as a student or an instructor.(You can use the student ids in the peer review section above) 
2. Go to an assignment which has some prior reviews for a previous project and click on view scores. 
3. The total score for a review is calculated on the fly using this module. 
4. You will be able to see the average score that each reviewer gave you on the top right of your page. 
5. This ensured that the refactoring done by us didn't break the code and it delivered it's expected functionality. 

===Unit Testing===

We created unit tests as well to check that the module performs as it did earlier before we refactored it. There were no pre-existing test cases for this module. 
We first had to create a dummy class to test the module. The new test file can be viewed at the mentioned GitHub link.

[[File:testtt.png]]

== Scope for future improvement ==

Every code has future improvements possible. We have evolved the Code Climate Grade 'F' to a Grade 'C' currently by removing the Cyclomatic complexity, the Perceived Complexity and replaced with the "for" with the 'each' to reduce the size .
There are modifications that can still reduce the "ABC" Assignment Branches and Conditions Score as we can include the variables and functions in the "before action clauses", and rename long names with shorter yet appropriate names thus moving towards the score of "A".

CSC/ECE 517 Fall 2016/E1659. Refactor on the fly calc.rb

2016-11-04T23:49:27Z

Asagarwa:

This wiki page is for the description of changes made under E1659 OSS assignment for Fall 2016, CSC/ECE 517.

== Peer Review Information ==

For users intending to view the deployed Expertiza associated with this assignment, the credentials are below:
* Instructor login: username -> instructor6, password -> password
* Student login: username -> student5431, password -> password
* Student login: username -> student5427, password -> password

== Expertiza 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 it’s code is available on Github. Using Expertiza students can bid for a particular project topic and the faculty assigns the same to different groups. Students can track their grades for previous projects and make new submissions for current projects. It also allows students to review each other’s work and improve their work upon this feedback.

== Description of the current project ==

We worked on a module named on_the_fly_calc in this Expertiza based OSS project. We focussed on refactoring some methods which were very complex and also modified the language of the module to make it more ruby-istic. We also worked on refactoring the code to reduce redundancy. Our goal in this project was to make this model easier to read and maintain.

== Files modified in current project ==

A model was modified for this project namely: 
1. On_the_fly_calc

=== On_the_fly_calc ===

On_the_fly_calc is a module that is included in assignment.rb. What this module does is that it calculates the score for both students and instructors. E.g., when a student clicks “view my score”, Expertiza calculates the review scores for each review. This is called “on the fly” because expertiza stores the review scores based on each question (in answers table), but does not store the total score that a reviewer gives to a reviewee. It directly calculates the total review score for each review, using the score values in the answer table during run-time.
Eg: For a set of 4 questions a reviewer gives 5 on 5 points for 2 questions and 4 on 5 points for other 2 questions. So only these points are stored in the database and when a reviewee clicks to see the score given by this particular reviewer, on_the_fly_calc module helps calculate the total score i.e. 90% in this case.

== List of changes ==
The main aim was to reduce the complexity grade of ‘on_the_fly_calc.rb’ module from “F” to “C” in CodeClimate, which was achieved. We worked on the following work items(WIs) in order to refactor the module: 
WI1 : Refactor ‘Similar Code’ in lines 34-42 and 62-70 in on_the_fly_calc.rb 
WI2 : Prefer ‘each’ over every instance of ‘for loop’ 
WI3 : Refactor ‘scores’ method to reduce ABC (assignment, branch and condition) size 
WI4 : Refactor ‘compute_reviews_hash’ method to reduce ABC (assignment, branch and condition) size 
WI5 : Refactor ‘compute_avg_and_ranges_hash’ method to reduce ABC (assignment, branch and condition) size

=== Solutions Implemented and Delivered ===

==== Refactored similar code ====

Lines 34-42 and 62-70 were similar in compute_reviews_hash method. Hence, a dedicated method ‘calc_review_score’ was defined and this method was called in the both instances inside compute_reviews_hash.

Lines 34-42 in compute_reviews_hash:

[[File:Similar code1.png]]

Similar code in Lines 62-70:

[[File:Similar code 2.png]]

Refactored method 'calc_review_score' for the two similar codes:

[[File:Same code method.png]]

==== Each loop prefered over For loop ====

In every instance where ‘for’ loops were used in on_the_fly_calc module, ‘each…do’ was replaced instead. This significantly reduced the Cyclomatic complexity of the code.

The following screen shows the instances where for loops where replaced:

[[File:Eachloop.png]]

==== Refactored methods - 'scores', 'compute_reviews_hash', 'compute_avg_and_ranges_hash' ====

1. a) Method ‘scores’ was very complex, performing too many functions within a single method. Hence, every specific function was broken down into 4 separate smaller methods. This significantly reduced the Assignment, Branch, Condition size for ‘scores’ method.

<pre>
def scores(questions)
scores = {}
score_team = scores[:teams][index.to_s.to_sym]
score = score_team[:scores]
scores[:participants] = {}
participant_score #New method defined - participant_score
scores[:teams] = {}
index = 0
self.teams.each do |team|
score_team = {}
score_team[:team] = team
if self.varying_rubrics_by_round?
assess #New method defined - assess
calculate_score #New method defined - calculate_score
calculate_assessment #New method defined - calculate_assessment
else
assessments = ReviewResponseMap.get_assessments_for(team)
score = Answer.compute_scores(assessments, questions[:review])
end
index += 1
end
scores
end
</pre>

b) The following 4 methods were created after splitting the first method 
i. participant_score 

<pre>
def participant_score
self.participants.each do |participant|
scores[:participants][participant.id.to_s.to_sym] = participant.scores(questions)
end
end
</pre>

ii. assess 

<pre>
def assess
self.num_review_rounds.each do |i|
total_score = 0
total_num_of_assessments = 0 # calculate grades for each rounds
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
assessments = ReviewResponseMap.get_assessments_round_for(team, i)
round_sym = ("review" + i.to_s).to_sym
round = Answer.compute_scores(assessments, questions[round_sym])
total_num_of_assessments += assessments.size
total_score += round[:avg] * assessments.size.to_f unless round[:avg].nil?
end
end
</pre>

iii. calculate_score 

<pre>
def calculate_score
score = {}
score[:max] = -999_999_999
score[:min] = 999_999_999
score[:avg] = 0
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
self.num_review_rounds.each do |i|
round_sym = ("review" + i.to_s).to_sym
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
score[:max] = round[:max] if max_condition
score[:min] = round[:min] if min_condition
end
end
</pre>

iv. calculate_assessment

<pre>
def calculate_assessment
if total_num_of_assessments.nonzero?
score[:avg] = total_score / total_num_of_assessments
else
score[:avg] = nil
score[:max] = 0
score[:min] = 0
end
end
</pre>

c) Complex and long statements or loops were broken into simpler multiple statements.

For example, the unless condition in Lines 132-134 was refactored to Line 127. This reduced the Perceived Complexity of 'scores' method.

[[File:Conditionsimpler.png]]

2. a) We also refactored method ‘compute_reviews_hash’ which was very complex and modularized individual functionalities into 2 separate methods.
b) The following 2 methods were created and called after refactoring: 
i. scores_varying_rubrics 
ii. scores_non_varying_rubrics 

3. Similarly, method ‘compute_avg_and_ranges_hash’ was also refactored and a seperate method calc_contri_score was defined to calculate contributor’s score. This method was then called from ‘compute_avg_and_ranges_hash’.

[[File:rsz_unnamed.png]]
The Code Climate Grade Before Refactoring

[[File:rsz_1after.png]]
The Code Climate Grade After Refactoring
== Testing Details==

===UI Testing===

1. Login into Expertiza as a student or an instructor.(You can use the student ids in the peer review section above) 
2. Go to an assignment which has some prior reviews for a previous project and click on view scores. 
3. The total score for a review is calculated on the fly using this module. 
4. You will be able to see the average score that each reviewer gave you on the top right of your page. 
5. This ensured that the refactoring done by us didn't break the code and it delivered it's expected functionality. 

===Unit Testing===

[[File:testtt.png]]

== Scope for future improvement ==

Every code has future improvements possible. We have evolved the Code Climate Grade 'F' to a Grade 'C' currently by removing the Cyclomatic complexity, the Perceived Complexity and replaced with the "for" with the 'each' to reduce the size .
There are modifications that can still reduce the "ABC" Assignment Branches and Conditions Score as we can include the variables and functions in the "before action clauses", and rename long names with shorter yet appropriate names thus moving towards the score of "A".

File:Testtt.png

2016-11-04T23:48:26Z

Asagarwa:

CSC/ECE 517 Fall 2016/E1659. Refactor on the fly calc.rb

2016-11-04T23:43:42Z

Asagarwa: /* Testing Details */

This wiki page is for the description of changes made under E1659 OSS assignment for Fall 2016, CSC/ECE 517.

== Peer Review Information ==

For users intending to view the deployed Expertiza associated with this assignment, the credentials are below:
* Instructor login: username -> instructor6, password -> password
* Student login: username -> student5431, password -> password
* Student login: username -> student5427, password -> password

== Expertiza 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 it’s code is available on Github. Using Expertiza students can bid for a particular project topic and the faculty assigns the same to different groups. Students can track their grades for previous projects and make new submissions for current projects. It also allows students to review each other’s work and improve their work upon this feedback.

== Description of the current project ==

We worked on a module named on_the_fly_calc in this Expertiza based OSS project. We focussed on refactoring some methods which were very complex and also modified the language of the module to make it more ruby-istic. We also worked on refactoring the code to reduce redundancy. Our goal in this project was to make this model easier to read and maintain.

== Files modified in current project ==

A model was modified for this project namely: 
1. On_the_fly_calc

=== On_the_fly_calc ===

On_the_fly_calc is a module that is included in assignment.rb. What this module does is that it calculates the score for both students and instructors. E.g., when a student clicks “view my score”, Expertiza calculates the review scores for each review. This is called “on the fly” because expertiza stores the review scores based on each question (in answers table), but does not store the total score that a reviewer gives to a reviewee. It directly calculates the total review score for each review, using the score values in the answer table during run-time.
Eg: For a set of 4 questions a reviewer gives 5 on 5 points for 2 questions and 4 on 5 points for other 2 questions. So only these points are stored in the database and when a reviewee clicks to see the score given by this particular reviewer, on_the_fly_calc module helps calculate the total score i.e. 90% in this case.

== List of changes ==
The main aim was to reduce the complexity grade of ‘on_the_fly_calc.rb’ module from “F” to “C” in CodeClimate, which was achieved. We worked on the following work items(WIs) in order to refactor the module: 
WI1 : Refactor ‘Similar Code’ in lines 34-42 and 62-70 in on_the_fly_calc.rb 
WI2 : Prefer ‘each’ over every instance of ‘for loop’ 
WI3 : Refactor ‘scores’ method to reduce ABC (assignment, branch and condition) size 
WI4 : Refactor ‘compute_reviews_hash’ method to reduce ABC (assignment, branch and condition) size 
WI5 : Refactor ‘compute_avg_and_ranges_hash’ method to reduce ABC (assignment, branch and condition) size

=== Solutions Implemented and Delivered ===

==== Refactored similar code ====

Lines 34-42 and 62-70 were similar in compute_reviews_hash method. Hence, a dedicated method ‘calc_review_score’ was defined and this method was called in the both instances inside compute_reviews_hash.

Lines 34-42 in compute_reviews_hash:

[[File:Similar code1.png]]

Similar code in Lines 62-70:

[[File:Similar code 2.png]]

Refactored method 'calc_review_score' for the two similar codes:

[[File:Same code method.png]]

==== Each loop prefered over For loop ====

In every instance where ‘for’ loops were used in on_the_fly_calc module, ‘each…do’ was replaced instead. This significantly reduced the Cyclomatic complexity of the code.

The following screen shows the instances where for loops where replaced:

[[File:Eachloop.png]]

==== Refactored methods - 'scores', 'compute_reviews_hash', 'compute_avg_and_ranges_hash' ====

1. a) Method ‘scores’ was very complex, performing too many functions within a single method. Hence, every specific function was broken down into 4 separate smaller methods. This significantly reduced the Assignment, Branch, Condition size for ‘scores’ method.

<pre>
def scores(questions)
scores = {}
score_team = scores[:teams][index.to_s.to_sym]
score = score_team[:scores]
scores[:participants] = {}
participant_score #New method defined - participant_score
scores[:teams] = {}
index = 0
self.teams.each do |team|
score_team = {}
score_team[:team] = team
if self.varying_rubrics_by_round?
assess #New method defined - assess
calculate_score #New method defined - calculate_score
calculate_assessment #New method defined - calculate_assessment
else
assessments = ReviewResponseMap.get_assessments_for(team)
score = Answer.compute_scores(assessments, questions[:review])
end
index += 1
end
scores
end
</pre>

b) The following 4 methods were created after splitting the first method 
i. participant_score 

<pre>
def participant_score
self.participants.each do |participant|
scores[:participants][participant.id.to_s.to_sym] = participant.scores(questions)
end
end
</pre>

ii. assess 

<pre>
def assess
self.num_review_rounds.each do |i|
total_score = 0
total_num_of_assessments = 0 # calculate grades for each rounds
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
assessments = ReviewResponseMap.get_assessments_round_for(team, i)
round_sym = ("review" + i.to_s).to_sym
round = Answer.compute_scores(assessments, questions[round_sym])
total_num_of_assessments += assessments.size
total_score += round[:avg] * assessments.size.to_f unless round[:avg].nil?
end
end
</pre>

iii. calculate_score 

<pre>
def calculate_score
score = {}
score[:max] = -999_999_999
score[:min] = 999_999_999
score[:avg] = 0
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
self.num_review_rounds.each do |i|
round_sym = ("review" + i.to_s).to_sym
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
score[:max] = round[:max] if max_condition
score[:min] = round[:min] if min_condition
end
end
</pre>

iv. calculate_assessment

<pre>
def calculate_assessment
if total_num_of_assessments.nonzero?
score[:avg] = total_score / total_num_of_assessments
else
score[:avg] = nil
score[:max] = 0
score[:min] = 0
end
end
</pre>

c) Complex and long statements or loops were broken into simpler multiple statements.

For example, the unless condition in Lines 132-134 was refactored to Line 127. This reduced the Perceived Complexity of 'scores' method.

[[File:Conditionsimpler.png]]

2. a) We also refactored method ‘compute_reviews_hash’ which was very complex and modularized individual functionalities into 2 separate methods.
b) The following 2 methods were created and called after refactoring: 
i. scores_varying_rubrics 
ii. scores_non_varying_rubrics 

3. Similarly, method ‘compute_avg_and_ranges_hash’ was also refactored and a seperate method calc_contri_score was defined to calculate contributor’s score. This method was then called from ‘compute_avg_and_ranges_hash’.

[[File:rsz_unnamed.png]]
The Code Climate Grade Before Refactoring

[[File:rsz_1after.png]]
The Code Climate Grade After Refactoring
== Testing Details==

===UI Testing===

1. Login into Expertiza as a student or an instructor.(You can use the student ids in the peer review section above) 
2. Go to an assignment which has some prior reviews for a previous project and click on view scores. 
3. The total score for a review is calculated on the fly using this module. 
4. You will be able to see the average score that each reviewer gave you on the top right of your page. 
5. This ensured that the refactoring done by us didn't break the code and it delivered it's expected functionality. 

===Unit Testing===

[[File:Screen Shot 2016-11-04 at 7.31.32 PM.png]]

== Scope for future improvement ==

Every code has future improvements possible. We have evolved the Code Climate Grade 'F' to a Grade 'C' currently by removing the Cyclomatic complexity, the Perceived Complexity and replaced with the "for" with the 'each' to reduce the size .
There are modifications that can still reduce the "ABC" Assignment Branches and Conditions Score as we can include the variables and functions in the "before action clauses", and rename long names with shorter yet appropriate names thus moving towards the score of "A".

CSC/ECE 517 Fall 2016/E1659. Refactor on the fly calc.rb

2016-11-04T23:42:25Z

Asagarwa: /* UI Testing */

This wiki page is for the description of changes made under E1659 OSS assignment for Fall 2016, CSC/ECE 517.

== Peer Review Information ==

For users intending to view the deployed Expertiza associated with this assignment, the credentials are below:
* Instructor login: username -> instructor6, password -> password
* Student login: username -> student5431, password -> password
* Student login: username -> student5427, password -> password

== Expertiza 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 it’s code is available on Github. Using Expertiza students can bid for a particular project topic and the faculty assigns the same to different groups. Students can track their grades for previous projects and make new submissions for current projects. It also allows students to review each other’s work and improve their work upon this feedback.

== Description of the current project ==

We worked on a module named on_the_fly_calc in this Expertiza based OSS project. We focussed on refactoring some methods which were very complex and also modified the language of the module to make it more ruby-istic. We also worked on refactoring the code to reduce redundancy. Our goal in this project was to make this model easier to read and maintain.

== Files modified in current project ==

A model was modified for this project namely: 
1. On_the_fly_calc

=== On_the_fly_calc ===

On_the_fly_calc is a module that is included in assignment.rb. What this module does is that it calculates the score for both students and instructors. E.g., when a student clicks “view my score”, Expertiza calculates the review scores for each review. This is called “on the fly” because expertiza stores the review scores based on each question (in answers table), but does not store the total score that a reviewer gives to a reviewee. It directly calculates the total review score for each review, using the score values in the answer table during run-time.
Eg: For a set of 4 questions a reviewer gives 5 on 5 points for 2 questions and 4 on 5 points for other 2 questions. So only these points are stored in the database and when a reviewee clicks to see the score given by this particular reviewer, on_the_fly_calc module helps calculate the total score i.e. 90% in this case.

== List of changes ==
The main aim was to reduce the complexity grade of ‘on_the_fly_calc.rb’ module from “F” to “C” in CodeClimate, which was achieved. We worked on the following work items(WIs) in order to refactor the module: 
WI1 : Refactor ‘Similar Code’ in lines 34-42 and 62-70 in on_the_fly_calc.rb 
WI2 : Prefer ‘each’ over every instance of ‘for loop’ 
WI3 : Refactor ‘scores’ method to reduce ABC (assignment, branch and condition) size 
WI4 : Refactor ‘compute_reviews_hash’ method to reduce ABC (assignment, branch and condition) size 
WI5 : Refactor ‘compute_avg_and_ranges_hash’ method to reduce ABC (assignment, branch and condition) size

=== Solutions Implemented and Delivered ===

==== Refactored similar code ====

Lines 34-42 and 62-70 were similar in compute_reviews_hash method. Hence, a dedicated method ‘calc_review_score’ was defined and this method was called in the both instances inside compute_reviews_hash.

Lines 34-42 in compute_reviews_hash:

[[File:Similar code1.png]]

Similar code in Lines 62-70:

[[File:Similar code 2.png]]

Refactored method 'calc_review_score' for the two similar codes:

[[File:Same code method.png]]

==== Each loop prefered over For loop ====

In every instance where ‘for’ loops were used in on_the_fly_calc module, ‘each…do’ was replaced instead. This significantly reduced the Cyclomatic complexity of the code.

The following screen shows the instances where for loops where replaced:

[[File:Eachloop.png]]

==== Refactored methods - 'scores', 'compute_reviews_hash', 'compute_avg_and_ranges_hash' ====

1. a) Method ‘scores’ was very complex, performing too many functions within a single method. Hence, every specific function was broken down into 4 separate smaller methods. This significantly reduced the Assignment, Branch, Condition size for ‘scores’ method.

<pre>
def scores(questions)
scores = {}
score_team = scores[:teams][index.to_s.to_sym]
score = score_team[:scores]
scores[:participants] = {}
participant_score #New method defined - participant_score
scores[:teams] = {}
index = 0
self.teams.each do |team|
score_team = {}
score_team[:team] = team
if self.varying_rubrics_by_round?
assess #New method defined - assess
calculate_score #New method defined - calculate_score
calculate_assessment #New method defined - calculate_assessment
else
assessments = ReviewResponseMap.get_assessments_for(team)
score = Answer.compute_scores(assessments, questions[:review])
end
index += 1
end
scores
end
</pre>

b) The following 4 methods were created after splitting the first method 
i. participant_score 

<pre>
def participant_score
self.participants.each do |participant|
scores[:participants][participant.id.to_s.to_sym] = participant.scores(questions)
end
end
</pre>

ii. assess 

<pre>
def assess
self.num_review_rounds.each do |i|
total_score = 0
total_num_of_assessments = 0 # calculate grades for each rounds
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
assessments = ReviewResponseMap.get_assessments_round_for(team, i)
round_sym = ("review" + i.to_s).to_sym
round = Answer.compute_scores(assessments, questions[round_sym])
total_num_of_assessments += assessments.size
total_score += round[:avg] * assessments.size.to_f unless round[:avg].nil?
end
end
</pre>

iii. calculate_score 

<pre>
def calculate_score
score = {}
score[:max] = -999_999_999
score[:min] = 999_999_999
score[:avg] = 0
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
self.num_review_rounds.each do |i|
round_sym = ("review" + i.to_s).to_sym
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
score[:max] = round[:max] if max_condition
score[:min] = round[:min] if min_condition
end
end
</pre>

iv. calculate_assessment

<pre>
def calculate_assessment
if total_num_of_assessments.nonzero?
score[:avg] = total_score / total_num_of_assessments
else
score[:avg] = nil
score[:max] = 0
score[:min] = 0
end
end
</pre>

c) Complex and long statements or loops were broken into simpler multiple statements.

For example, the unless condition in Lines 132-134 was refactored to Line 127. This reduced the Perceived Complexity of 'scores' method.

[[File:Conditionsimpler.png]]

2. a) We also refactored method ‘compute_reviews_hash’ which was very complex and modularized individual functionalities into 2 separate methods.
b) The following 2 methods were created and called after refactoring: 
i. scores_varying_rubrics 
ii. scores_non_varying_rubrics 

3. Similarly, method ‘compute_avg_and_ranges_hash’ was also refactored and a seperate method calc_contri_score was defined to calculate contributor’s score. This method was then called from ‘compute_avg_and_ranges_hash’.

[[File:rsz_unnamed.png]]
The Code Climate Grade Before Refactoring

[[File:rsz_1after.png]]
The Code Climate Grade After Refactoring
== Testing Details==

===UI Testing===

1. Login into Expertiza as a student or an instructor.(You can use the student ids in the peer review section above) 
2. Go to an assignment which has some prior reviews for a previous project and click on view scores. 
3. The total score for a review is calculated on the fly using this module. 
4. You will be able to see the average score that each reviewer gave you on the top right of your page. 
5. This ensured that the refactoring done by us didn't break the code and it delivered it's expected functionality. 

== Scope for future improvement ==

Every code has future improvements possible. We have evolved the Code Climate Grade 'F' to a Grade 'C' currently by removing the Cyclomatic complexity, the Perceived Complexity and replaced with the "for" with the 'each' to reduce the size .
There are modifications that can still reduce the "ABC" Assignment Branches and Conditions Score as we can include the variables and functions in the "before action clauses", and rename long names with shorter yet appropriate names thus moving towards the score of "A".

CSC/ECE 517 Fall 2016/E1659. Refactor on the fly calc.rb

2016-11-04T23:42:05Z

Asagarwa: /* UI Testing */

This wiki page is for the description of changes made under E1659 OSS assignment for Fall 2016, CSC/ECE 517.

== Peer Review Information ==

For users intending to view the deployed Expertiza associated with this assignment, the credentials are below:
* Instructor login: username -> instructor6, password -> password
* Student login: username -> student5431, password -> password
* Student login: username -> student5427, password -> password

== Expertiza 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 it’s code is available on Github. Using Expertiza students can bid for a particular project topic and the faculty assigns the same to different groups. Students can track their grades for previous projects and make new submissions for current projects. It also allows students to review each other’s work and improve their work upon this feedback.

== Description of the current project ==

We worked on a module named on_the_fly_calc in this Expertiza based OSS project. We focussed on refactoring some methods which were very complex and also modified the language of the module to make it more ruby-istic. We also worked on refactoring the code to reduce redundancy. Our goal in this project was to make this model easier to read and maintain.

== Files modified in current project ==

A model was modified for this project namely: 
1. On_the_fly_calc

=== On_the_fly_calc ===

On_the_fly_calc is a module that is included in assignment.rb. What this module does is that it calculates the score for both students and instructors. E.g., when a student clicks “view my score”, Expertiza calculates the review scores for each review. This is called “on the fly” because expertiza stores the review scores based on each question (in answers table), but does not store the total score that a reviewer gives to a reviewee. It directly calculates the total review score for each review, using the score values in the answer table during run-time.
Eg: For a set of 4 questions a reviewer gives 5 on 5 points for 2 questions and 4 on 5 points for other 2 questions. So only these points are stored in the database and when a reviewee clicks to see the score given by this particular reviewer, on_the_fly_calc module helps calculate the total score i.e. 90% in this case.

== List of changes ==
The main aim was to reduce the complexity grade of ‘on_the_fly_calc.rb’ module from “F” to “C” in CodeClimate, which was achieved. We worked on the following work items(WIs) in order to refactor the module: 
WI1 : Refactor ‘Similar Code’ in lines 34-42 and 62-70 in on_the_fly_calc.rb 
WI2 : Prefer ‘each’ over every instance of ‘for loop’ 
WI3 : Refactor ‘scores’ method to reduce ABC (assignment, branch and condition) size 
WI4 : Refactor ‘compute_reviews_hash’ method to reduce ABC (assignment, branch and condition) size 
WI5 : Refactor ‘compute_avg_and_ranges_hash’ method to reduce ABC (assignment, branch and condition) size

=== Solutions Implemented and Delivered ===

==== Refactored similar code ====

Lines 34-42 and 62-70 were similar in compute_reviews_hash method. Hence, a dedicated method ‘calc_review_score’ was defined and this method was called in the both instances inside compute_reviews_hash.

Lines 34-42 in compute_reviews_hash:

[[File:Similar code1.png]]

Similar code in Lines 62-70:

[[File:Similar code 2.png]]

Refactored method 'calc_review_score' for the two similar codes:

[[File:Same code method.png]]

==== Each loop prefered over For loop ====

In every instance where ‘for’ loops were used in on_the_fly_calc module, ‘each…do’ was replaced instead. This significantly reduced the Cyclomatic complexity of the code.

The following screen shows the instances where for loops where replaced:

[[File:Eachloop.png]]

==== Refactored methods - 'scores', 'compute_reviews_hash', 'compute_avg_and_ranges_hash' ====

1. a) Method ‘scores’ was very complex, performing too many functions within a single method. Hence, every specific function was broken down into 4 separate smaller methods. This significantly reduced the Assignment, Branch, Condition size for ‘scores’ method.

<pre>
def scores(questions)
scores = {}
score_team = scores[:teams][index.to_s.to_sym]
score = score_team[:scores]
scores[:participants] = {}
participant_score #New method defined - participant_score
scores[:teams] = {}
index = 0
self.teams.each do |team|
score_team = {}
score_team[:team] = team
if self.varying_rubrics_by_round?
assess #New method defined - assess
calculate_score #New method defined - calculate_score
calculate_assessment #New method defined - calculate_assessment
else
assessments = ReviewResponseMap.get_assessments_for(team)
score = Answer.compute_scores(assessments, questions[:review])
end
index += 1
end
scores
end
</pre>

b) The following 4 methods were created after splitting the first method 
i. participant_score 

<pre>
def participant_score
self.participants.each do |participant|
scores[:participants][participant.id.to_s.to_sym] = participant.scores(questions)
end
end
</pre>

ii. assess 

<pre>
def assess
self.num_review_rounds.each do |i|
total_score = 0
total_num_of_assessments = 0 # calculate grades for each rounds
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
assessments = ReviewResponseMap.get_assessments_round_for(team, i)
round_sym = ("review" + i.to_s).to_sym
round = Answer.compute_scores(assessments, questions[round_sym])
total_num_of_assessments += assessments.size
total_score += round[:avg] * assessments.size.to_f unless round[:avg].nil?
end
end
</pre>

iii. calculate_score 

<pre>
def calculate_score
score = {}
score[:max] = -999_999_999
score[:min] = 999_999_999
score[:avg] = 0
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
self.num_review_rounds.each do |i|
round_sym = ("review" + i.to_s).to_sym
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
score[:max] = round[:max] if max_condition
score[:min] = round[:min] if min_condition
end
end
</pre>

iv. calculate_assessment

<pre>
def calculate_assessment
if total_num_of_assessments.nonzero?
score[:avg] = total_score / total_num_of_assessments
else
score[:avg] = nil
score[:max] = 0
score[:min] = 0
end
end
</pre>

c) Complex and long statements or loops were broken into simpler multiple statements.

For example, the unless condition in Lines 132-134 was refactored to Line 127. This reduced the Perceived Complexity of 'scores' method.

[[File:Conditionsimpler.png]]

2. a) We also refactored method ‘compute_reviews_hash’ which was very complex and modularized individual functionalities into 2 separate methods.
b) The following 2 methods were created and called after refactoring: 
i. scores_varying_rubrics 
ii. scores_non_varying_rubrics 

3. Similarly, method ‘compute_avg_and_ranges_hash’ was also refactored and a seperate method calc_contri_score was defined to calculate contributor’s score. This method was then called from ‘compute_avg_and_ranges_hash’.

[[File:rsz_unnamed.png]]
The Code Climate Grade Before Refactoring

[[File:rsz_1after.png]]
The Code Climate Grade After Refactoring
== Testing Details==

=======UI Testing=======

1. Login into Expertiza as a student or an instructor.(You can use the student ids in the peer review section above) 
2. Go to an assignment which has some prior reviews for a previous project and click on view scores. 
3. The total score for a review is calculated on the fly using this module. 
4. You will be able to see the average score that each reviewer gave you on the top right of your page. 
5. This ensured that the refactoring done by us didn't break the code and it delivered it's expected functionality. 

== Scope for future improvement ==

Every code has future improvements possible. We have evolved the Code Climate Grade 'F' to a Grade 'C' currently by removing the Cyclomatic complexity, the Perceived Complexity and replaced with the "for" with the 'each' to reduce the size .
There are modifications that can still reduce the "ABC" Assignment Branches and Conditions Score as we can include the variables and functions in the "before action clauses", and rename long names with shorter yet appropriate names thus moving towards the score of "A".

CSC/ECE 517 Fall 2016/E1659. Refactor on the fly calc.rb

2016-11-04T23:41:46Z

Asagarwa: /* Testing Details */

This wiki page is for the description of changes made under E1659 OSS assignment for Fall 2016, CSC/ECE 517.

== Peer Review Information ==

For users intending to view the deployed Expertiza associated with this assignment, the credentials are below:
* Instructor login: username -> instructor6, password -> password
* Student login: username -> student5431, password -> password
* Student login: username -> student5427, password -> password

== Expertiza 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 it’s code is available on Github. Using Expertiza students can bid for a particular project topic and the faculty assigns the same to different groups. Students can track their grades for previous projects and make new submissions for current projects. It also allows students to review each other’s work and improve their work upon this feedback.

== Description of the current project ==

We worked on a module named on_the_fly_calc in this Expertiza based OSS project. We focussed on refactoring some methods which were very complex and also modified the language of the module to make it more ruby-istic. We also worked on refactoring the code to reduce redundancy. Our goal in this project was to make this model easier to read and maintain.

== Files modified in current project ==

A model was modified for this project namely: 
1. On_the_fly_calc

=== On_the_fly_calc ===

On_the_fly_calc is a module that is included in assignment.rb. What this module does is that it calculates the score for both students and instructors. E.g., when a student clicks “view my score”, Expertiza calculates the review scores for each review. This is called “on the fly” because expertiza stores the review scores based on each question (in answers table), but does not store the total score that a reviewer gives to a reviewee. It directly calculates the total review score for each review, using the score values in the answer table during run-time.
Eg: For a set of 4 questions a reviewer gives 5 on 5 points for 2 questions and 4 on 5 points for other 2 questions. So only these points are stored in the database and when a reviewee clicks to see the score given by this particular reviewer, on_the_fly_calc module helps calculate the total score i.e. 90% in this case.

== List of changes ==
The main aim was to reduce the complexity grade of ‘on_the_fly_calc.rb’ module from “F” to “C” in CodeClimate, which was achieved. We worked on the following work items(WIs) in order to refactor the module: 
WI1 : Refactor ‘Similar Code’ in lines 34-42 and 62-70 in on_the_fly_calc.rb 
WI2 : Prefer ‘each’ over every instance of ‘for loop’ 
WI3 : Refactor ‘scores’ method to reduce ABC (assignment, branch and condition) size 
WI4 : Refactor ‘compute_reviews_hash’ method to reduce ABC (assignment, branch and condition) size 
WI5 : Refactor ‘compute_avg_and_ranges_hash’ method to reduce ABC (assignment, branch and condition) size

=== Solutions Implemented and Delivered ===

==== Refactored similar code ====

Lines 34-42 and 62-70 were similar in compute_reviews_hash method. Hence, a dedicated method ‘calc_review_score’ was defined and this method was called in the both instances inside compute_reviews_hash.

Lines 34-42 in compute_reviews_hash:

[[File:Similar code1.png]]

Similar code in Lines 62-70:

[[File:Similar code 2.png]]

Refactored method 'calc_review_score' for the two similar codes:

[[File:Same code method.png]]

==== Each loop prefered over For loop ====

In every instance where ‘for’ loops were used in on_the_fly_calc module, ‘each…do’ was replaced instead. This significantly reduced the Cyclomatic complexity of the code.

The following screen shows the instances where for loops where replaced:

[[File:Eachloop.png]]

==== Refactored methods - 'scores', 'compute_reviews_hash', 'compute_avg_and_ranges_hash' ====

1. a) Method ‘scores’ was very complex, performing too many functions within a single method. Hence, every specific function was broken down into 4 separate smaller methods. This significantly reduced the Assignment, Branch, Condition size for ‘scores’ method.

<pre>
def scores(questions)
scores = {}
score_team = scores[:teams][index.to_s.to_sym]
score = score_team[:scores]
scores[:participants] = {}
participant_score #New method defined - participant_score
scores[:teams] = {}
index = 0
self.teams.each do |team|
score_team = {}
score_team[:team] = team
if self.varying_rubrics_by_round?
assess #New method defined - assess
calculate_score #New method defined - calculate_score
calculate_assessment #New method defined - calculate_assessment
else
assessments = ReviewResponseMap.get_assessments_for(team)
score = Answer.compute_scores(assessments, questions[:review])
end
index += 1
end
scores
end
</pre>

b) The following 4 methods were created after splitting the first method 
i. participant_score 

<pre>
def participant_score
self.participants.each do |participant|
scores[:participants][participant.id.to_s.to_sym] = participant.scores(questions)
end
end
</pre>

ii. assess 

<pre>
def assess
self.num_review_rounds.each do |i|
total_score = 0
total_num_of_assessments = 0 # calculate grades for each rounds
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
assessments = ReviewResponseMap.get_assessments_round_for(team, i)
round_sym = ("review" + i.to_s).to_sym
round = Answer.compute_scores(assessments, questions[round_sym])
total_num_of_assessments += assessments.size
total_score += round[:avg] * assessments.size.to_f unless round[:avg].nil?
end
end
</pre>

iii. calculate_score 

<pre>
def calculate_score
score = {}
score[:max] = -999_999_999
score[:min] = 999_999_999
score[:avg] = 0
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
self.num_review_rounds.each do |i|
round_sym = ("review" + i.to_s).to_sym
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
score[:max] = round[:max] if max_condition
score[:min] = round[:min] if min_condition
end
end
</pre>

iv. calculate_assessment

<pre>
def calculate_assessment
if total_num_of_assessments.nonzero?
score[:avg] = total_score / total_num_of_assessments
else
score[:avg] = nil
score[:max] = 0
score[:min] = 0
end
end
</pre>

c) Complex and long statements or loops were broken into simpler multiple statements.

For example, the unless condition in Lines 132-134 was refactored to Line 127. This reduced the Perceived Complexity of 'scores' method.

[[File:Conditionsimpler.png]]

2. a) We also refactored method ‘compute_reviews_hash’ which was very complex and modularized individual functionalities into 2 separate methods.
b) The following 2 methods were created and called after refactoring: 
i. scores_varying_rubrics 
ii. scores_non_varying_rubrics 

3. Similarly, method ‘compute_avg_and_ranges_hash’ was also refactored and a seperate method calc_contri_score was defined to calculate contributor’s score. This method was then called from ‘compute_avg_and_ranges_hash’.

[[File:rsz_unnamed.png]]
The Code Climate Grade Before Refactoring

[[File:rsz_1after.png]]
The Code Climate Grade After Refactoring
== Testing Details==

=====UI Testing=====

1. Login into Expertiza as a student or an instructor.(You can use the student ids in the peer review section above) 
2. Go to an assignment which has some prior reviews for a previous project and click on view scores. 
3. The total score for a review is calculated on the fly using this module. 
4. You will be able to see the average score that each reviewer gave you on the top right of your page. 
5. This ensured that the refactoring done by us didn't break the code and it delivered it's expected functionality. 

== Scope for future improvement ==

Every code has future improvements possible. We have evolved the Code Climate Grade 'F' to a Grade 'C' currently by removing the Cyclomatic complexity, the Perceived Complexity and replaced with the "for" with the 'each' to reduce the size .
There are modifications that can still reduce the "ABC" Assignment Branches and Conditions Score as we can include the variables and functions in the "before action clauses", and rename long names with shorter yet appropriate names thus moving towards the score of "A".

CSC/ECE 517 Fall 2016/E1659. Refactor on the fly calc.rb

2016-11-04T23:41:15Z

Asagarwa: /* UI Testing */

This wiki page is for the description of changes made under E1659 OSS assignment for Fall 2016, CSC/ECE 517.

== Peer Review Information ==

For users intending to view the deployed Expertiza associated with this assignment, the credentials are below:
* Instructor login: username -> instructor6, password -> password
* Student login: username -> student5431, password -> password
* Student login: username -> student5427, password -> password

== Expertiza 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 it’s code is available on Github. Using Expertiza students can bid for a particular project topic and the faculty assigns the same to different groups. Students can track their grades for previous projects and make new submissions for current projects. It also allows students to review each other’s work and improve their work upon this feedback.

== Description of the current project ==

We worked on a module named on_the_fly_calc in this Expertiza based OSS project. We focussed on refactoring some methods which were very complex and also modified the language of the module to make it more ruby-istic. We also worked on refactoring the code to reduce redundancy. Our goal in this project was to make this model easier to read and maintain.

== Files modified in current project ==

A model was modified for this project namely: 
1. On_the_fly_calc

=== On_the_fly_calc ===

On_the_fly_calc is a module that is included in assignment.rb. What this module does is that it calculates the score for both students and instructors. E.g., when a student clicks “view my score”, Expertiza calculates the review scores for each review. This is called “on the fly” because expertiza stores the review scores based on each question (in answers table), but does not store the total score that a reviewer gives to a reviewee. It directly calculates the total review score for each review, using the score values in the answer table during run-time.
Eg: For a set of 4 questions a reviewer gives 5 on 5 points for 2 questions and 4 on 5 points for other 2 questions. So only these points are stored in the database and when a reviewee clicks to see the score given by this particular reviewer, on_the_fly_calc module helps calculate the total score i.e. 90% in this case.

== List of changes ==
The main aim was to reduce the complexity grade of ‘on_the_fly_calc.rb’ module from “F” to “C” in CodeClimate, which was achieved. We worked on the following work items(WIs) in order to refactor the module: 
WI1 : Refactor ‘Similar Code’ in lines 34-42 and 62-70 in on_the_fly_calc.rb 
WI2 : Prefer ‘each’ over every instance of ‘for loop’ 
WI3 : Refactor ‘scores’ method to reduce ABC (assignment, branch and condition) size 
WI4 : Refactor ‘compute_reviews_hash’ method to reduce ABC (assignment, branch and condition) size 
WI5 : Refactor ‘compute_avg_and_ranges_hash’ method to reduce ABC (assignment, branch and condition) size

=== Solutions Implemented and Delivered ===

==== Refactored similar code ====

Lines 34-42 and 62-70 were similar in compute_reviews_hash method. Hence, a dedicated method ‘calc_review_score’ was defined and this method was called in the both instances inside compute_reviews_hash.

Lines 34-42 in compute_reviews_hash:

[[File:Similar code1.png]]

Similar code in Lines 62-70:

[[File:Similar code 2.png]]

Refactored method 'calc_review_score' for the two similar codes:

[[File:Same code method.png]]

==== Each loop prefered over For loop ====

In every instance where ‘for’ loops were used in on_the_fly_calc module, ‘each…do’ was replaced instead. This significantly reduced the Cyclomatic complexity of the code.

The following screen shows the instances where for loops where replaced:

[[File:Eachloop.png]]

==== Refactored methods - 'scores', 'compute_reviews_hash', 'compute_avg_and_ranges_hash' ====

1. a) Method ‘scores’ was very complex, performing too many functions within a single method. Hence, every specific function was broken down into 4 separate smaller methods. This significantly reduced the Assignment, Branch, Condition size for ‘scores’ method.

<pre>
def scores(questions)
scores = {}
score_team = scores[:teams][index.to_s.to_sym]
score = score_team[:scores]
scores[:participants] = {}
participant_score #New method defined - participant_score
scores[:teams] = {}
index = 0
self.teams.each do |team|
score_team = {}
score_team[:team] = team
if self.varying_rubrics_by_round?
assess #New method defined - assess
calculate_score #New method defined - calculate_score
calculate_assessment #New method defined - calculate_assessment
else
assessments = ReviewResponseMap.get_assessments_for(team)
score = Answer.compute_scores(assessments, questions[:review])
end
index += 1
end
scores
end
</pre>

b) The following 4 methods were created after splitting the first method 
i. participant_score 

<pre>
def participant_score
self.participants.each do |participant|
scores[:participants][participant.id.to_s.to_sym] = participant.scores(questions)
end
end
</pre>

ii. assess 

<pre>
def assess
self.num_review_rounds.each do |i|
total_score = 0
total_num_of_assessments = 0 # calculate grades for each rounds
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
assessments = ReviewResponseMap.get_assessments_round_for(team, i)
round_sym = ("review" + i.to_s).to_sym
round = Answer.compute_scores(assessments, questions[round_sym])
total_num_of_assessments += assessments.size
total_score += round[:avg] * assessments.size.to_f unless round[:avg].nil?
end
end
</pre>

iii. calculate_score 

<pre>
def calculate_score
score = {}
score[:max] = -999_999_999
score[:min] = 999_999_999
score[:avg] = 0
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
self.num_review_rounds.each do |i|
round_sym = ("review" + i.to_s).to_sym
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
score[:max] = round[:max] if max_condition
score[:min] = round[:min] if min_condition
end
end
</pre>

iv. calculate_assessment

<pre>
def calculate_assessment
if total_num_of_assessments.nonzero?
score[:avg] = total_score / total_num_of_assessments
else
score[:avg] = nil
score[:max] = 0
score[:min] = 0
end
end
</pre>

c) Complex and long statements or loops were broken into simpler multiple statements.

For example, the unless condition in Lines 132-134 was refactored to Line 127. This reduced the Perceived Complexity of 'scores' method.

[[File:Conditionsimpler.png]]

2. a) We also refactored method ‘compute_reviews_hash’ which was very complex and modularized individual functionalities into 2 separate methods.
b) The following 2 methods were created and called after refactoring: 
i. scores_varying_rubrics 
ii. scores_non_varying_rubrics 

3. Similarly, method ‘compute_avg_and_ranges_hash’ was also refactored and a seperate method calc_contri_score was defined to calculate contributor’s score. This method was then called from ‘compute_avg_and_ranges_hash’.

[[File:rsz_unnamed.png]]
The Code Climate Grade Before Refactoring

[[File:rsz_1after.png]]
The Code Climate Grade After Refactoring
== Testing Details==

===UI Testing===

1. Login into Expertiza as a student or an instructor.(You can use the student ids in the peer review section above) 
2. Go to an assignment which has some prior reviews for a previous project and click on view scores. 
3. The total score for a review is calculated on the fly using this module. 
4. You will be able to see the average score that each reviewer gave you on the top right of your page. 
5. This ensured that the refactoring done by us didn't break the code and it delivered it's expected functionality. 

== Scope for future improvement ==

Every code has future improvements possible. We have evolved the Code Climate Grade 'F' to a Grade 'C' currently by removing the Cyclomatic complexity, the Perceived Complexity and replaced with the "for" with the 'each' to reduce the size .
There are modifications that can still reduce the "ABC" Assignment Branches and Conditions Score as we can include the variables and functions in the "before action clauses", and rename long names with shorter yet appropriate names thus moving towards the score of "A".

File:Screen Shot 2016-11-04 at 7.31.32 PM.png

2016-11-04T23:33:33Z

Asagarwa:

CSC/ECE 517 Fall 2016/E1659. Refactor on the fly calc.rb

2016-11-04T23:20:08Z

Asagarwa: /* Testing Details */

This wiki page is for the description of changes made under E1659 OSS assignment for Fall 2016, CSC/ECE 517.

== Peer Review Information ==

For users intending to view the deployed Expertiza associated with this assignment, the credentials are below:
* Instructor login: username -> instructor6, password -> password
* Student login: username -> student5431, password -> password
* Student login: username -> student5427, password -> password

== Expertiza 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 it’s code is available on Github. Using Expertiza students can bid for a particular project topic and the faculty assigns the same to different groups. Students can track their grades for previous projects and make new submissions for current projects. It also allows students to review each other’s work and improve their work upon this feedback.

== Description of the current project ==

We worked on a module named on_the_fly_calc in this Expertiza based OSS project. We focussed on refactoring some methods which were very complex and also modified the language of the module to make it more ruby-istic. We also worked on refactoring the code to reduce redundancy. Our goal in this project was to make this model easier to read and maintain.

== Files modified in current project ==

A model was modified for this project namely: 
1. On_the_fly_calc

=== On_the_fly_calc ===

On_the_fly_calc is a module that is included in assignment.rb. What this module does is that it calculates the score for both students and instructors. E.g., when a student clicks “view my score”, Expertiza calculates the review scores for each review. This is called “on the fly” because expertiza stores the review scores based on each question (in answers table), but does not store the total score that a reviewer gives to a reviewee. It directly calculates the total review score for each review, using the score values in the answer table during run-time.
Eg: For a set of 4 questions a reviewer gives 5 on 5 points for 2 questions and 4 on 5 points for other 2 questions. So only these points are stored in the database and when a reviewee clicks to see the score given by this particular reviewer, on_the_fly_calc module helps calculate the total score i.e. 90% in this case.

== List of changes ==
The main aim was to reduce the complexity grade of ‘on_the_fly_calc.rb’ module from “F” to “C” in CodeClimate, which was achieved. We worked on the following work items(WIs) in order to refactor the module: 
WI1 : Refactor ‘Similar Code’ in lines 34-42 and 62-70 in on_the_fly_calc.rb 
WI2 : Prefer ‘each’ over every instance of ‘for loop’ 
WI3 : Refactor ‘scores’ method to reduce ABC (assignment, branch and condition) size 
WI4 : Refactor ‘compute_reviews_hash’ method to reduce ABC (assignment, branch and condition) size 
WI5 : Refactor ‘compute_avg_and_ranges_hash’ method to reduce ABC (assignment, branch and condition) size

=== Solutions Implemented and Delivered ===

==== Refactored similar code ====

Lines 34-42 and 62-70 were similar in compute_reviews_hash method. Hence, a dedicated method ‘calc_review_score’ was defined and this method was called in the both instances inside compute_reviews_hash.

Lines 34-42 in compute_reviews_hash:

[[File:Similar code1.png]]

Similar code in Lines 62-70:

[[File:Similar code 2.png]]

Refactored method 'calc_review_score' for the two similar codes:

[[File:Same code method.png]]

==== Each loop prefered over For loop ====

In every instance where ‘for’ loops were used in on_the_fly_calc module, ‘each…do’ was replaced instead. This significantly reduced the Cyclomatic complexity of the code.

The following screen shows the instances where for loops where replaced:

[[File:Eachloop.png]]

==== Refactored methods - 'scores', 'compute_reviews_hash', 'compute_avg_and_ranges_hash' ====

1. a) Method ‘scores’ was very complex, performing too many functions within a single method. Hence, every specific function was broken down into 4 separate smaller methods. This significantly reduced the Assignment, Branch, Condition size for ‘scores’ method.

<pre>
def scores(questions)
scores = {}
score_team = scores[:teams][index.to_s.to_sym]
score = score_team[:scores]
scores[:participants] = {}
participant_score #New method defined - participant_score
scores[:teams] = {}
index = 0
self.teams.each do |team|
score_team = {}
score_team[:team] = team
if self.varying_rubrics_by_round?
assess #New method defined - assess
calculate_score #New method defined - calculate_score
calculate_assessment #New method defined - calculate_assessment
else
assessments = ReviewResponseMap.get_assessments_for(team)
score = Answer.compute_scores(assessments, questions[:review])
end
index += 1
end
scores
end
</pre>

b) The following 4 methods were created after splitting the first method 
i. participant_score 

<pre>
def participant_score
self.participants.each do |participant|
scores[:participants][participant.id.to_s.to_sym] = participant.scores(questions)
end
end
</pre>

ii. assess 

<pre>
def assess
self.num_review_rounds.each do |i|
total_score = 0
total_num_of_assessments = 0 # calculate grades for each rounds
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
assessments = ReviewResponseMap.get_assessments_round_for(team, i)
round_sym = ("review" + i.to_s).to_sym
round = Answer.compute_scores(assessments, questions[round_sym])
total_num_of_assessments += assessments.size
total_score += round[:avg] * assessments.size.to_f unless round[:avg].nil?
end
end
</pre>

iii. calculate_score 

<pre>
def calculate_score
score = {}
score[:max] = -999_999_999
score[:min] = 999_999_999
score[:avg] = 0
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
self.num_review_rounds.each do |i|
round_sym = ("review" + i.to_s).to_sym
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
score[:max] = round[:max] if max_condition
score[:min] = round[:min] if min_condition
end
end
</pre>

iv. calculate_assessment

<pre>
def calculate_assessment
if total_num_of_assessments.nonzero?
score[:avg] = total_score / total_num_of_assessments
else
score[:avg] = nil
score[:max] = 0
score[:min] = 0
end
end
</pre>

c) Complex and long statements or loops were broken into simpler multiple statements.

For example, the unless condition in Lines 132-134 was refactored to Line 127. This reduced the Perceived Complexity of 'scores' method.

[[File:Conditionsimpler.png]]

2. a) We also refactored method ‘compute_reviews_hash’ which was very complex and modularized individual functionalities into 2 separate methods.
b) The following 2 methods were created and called after refactoring: 
i. scores_varying_rubrics 
ii. scores_non_varying_rubrics 

3. Similarly, method ‘compute_avg_and_ranges_hash’ was also refactored and a seperate method calc_contri_score was defined to calculate contributor’s score. This method was then called from ‘compute_avg_and_ranges_hash’.

[[File:rsz_unnamed.png]]
The Code Climate Grade Before Refactoring

[[File:rsz_1after.png]]
The Code Climate Grade After Refactoring
== Testing Details==

===UI Testing===

1. Login into Expertiza as a student or an instructor. 
2. Go to an assignment which has some prior reviews for a previous project and click on view scores. 
3. The total score for a review is calculated on the fly using this module. 
4. You will be able to see the average score that each reviewer gave you on the top right of your page. 
5. This ensured that the refactoring done by us didn't break the code and it delivered it's expected functionality. 

== Scope for future improvement ==

Every code has future improvements possible. We have evolved the Code Climate Grade 'F' to a Grade 'C' currently by removing the Cyclomatic complexity, the Perceived Complexity and replaced with the "for" with the 'each' to reduce the size .
There are modifications that can still reduce the "ABC" Assignment Branches and Conditions Score as we can include the variables and functions in the "before action clauses", and rename long names with shorter yet appropriate names thus moving towards the score of "A".

CSC/ECE 517 Fall 2016/E1659. Refactor on the fly calc.rb

2016-11-04T23:19:26Z

Asagarwa:

This wiki page is for the description of changes made under E1659 OSS assignment for Fall 2016, CSC/ECE 517.

== Peer Review Information ==

For users intending to view the deployed Expertiza associated with this assignment, the credentials are below:
* Instructor login: username -> instructor6, password -> password
* Student login: username -> student5431, password -> password
* Student login: username -> student5427, password -> password

== Expertiza 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 it’s code is available on Github. Using Expertiza students can bid for a particular project topic and the faculty assigns the same to different groups. Students can track their grades for previous projects and make new submissions for current projects. It also allows students to review each other’s work and improve their work upon this feedback.

== Description of the current project ==

We worked on a module named on_the_fly_calc in this Expertiza based OSS project. We focussed on refactoring some methods which were very complex and also modified the language of the module to make it more ruby-istic. We also worked on refactoring the code to reduce redundancy. Our goal in this project was to make this model easier to read and maintain.

== Files modified in current project ==

A model was modified for this project namely: 
1. On_the_fly_calc

=== On_the_fly_calc ===

On_the_fly_calc is a module that is included in assignment.rb. What this module does is that it calculates the score for both students and instructors. E.g., when a student clicks “view my score”, Expertiza calculates the review scores for each review. This is called “on the fly” because expertiza stores the review scores based on each question (in answers table), but does not store the total score that a reviewer gives to a reviewee. It directly calculates the total review score for each review, using the score values in the answer table during run-time.
Eg: For a set of 4 questions a reviewer gives 5 on 5 points for 2 questions and 4 on 5 points for other 2 questions. So only these points are stored in the database and when a reviewee clicks to see the score given by this particular reviewer, on_the_fly_calc module helps calculate the total score i.e. 90% in this case.

== List of changes ==
The main aim was to reduce the complexity grade of ‘on_the_fly_calc.rb’ module from “F” to “C” in CodeClimate, which was achieved. We worked on the following work items(WIs) in order to refactor the module: 
WI1 : Refactor ‘Similar Code’ in lines 34-42 and 62-70 in on_the_fly_calc.rb 
WI2 : Prefer ‘each’ over every instance of ‘for loop’ 
WI3 : Refactor ‘scores’ method to reduce ABC (assignment, branch and condition) size 
WI4 : Refactor ‘compute_reviews_hash’ method to reduce ABC (assignment, branch and condition) size 
WI5 : Refactor ‘compute_avg_and_ranges_hash’ method to reduce ABC (assignment, branch and condition) size

=== Solutions Implemented and Delivered ===

==== Refactored similar code ====

Lines 34-42 and 62-70 were similar in compute_reviews_hash method. Hence, a dedicated method ‘calc_review_score’ was defined and this method was called in the both instances inside compute_reviews_hash.

Lines 34-42 in compute_reviews_hash:

[[File:Similar code1.png]]

Similar code in Lines 62-70:

[[File:Similar code 2.png]]

Refactored method 'calc_review_score' for the two similar codes:

[[File:Same code method.png]]

==== Each loop prefered over For loop ====

In every instance where ‘for’ loops were used in on_the_fly_calc module, ‘each…do’ was replaced instead. This significantly reduced the Cyclomatic complexity of the code.

The following screen shows the instances where for loops where replaced:

[[File:Eachloop.png]]

==== Refactored methods - 'scores', 'compute_reviews_hash', 'compute_avg_and_ranges_hash' ====

1. a) Method ‘scores’ was very complex, performing too many functions within a single method. Hence, every specific function was broken down into 4 separate smaller methods. This significantly reduced the Assignment, Branch, Condition size for ‘scores’ method.

<pre>
def scores(questions)
scores = {}
score_team = scores[:teams][index.to_s.to_sym]
score = score_team[:scores]
scores[:participants] = {}
participant_score #New method defined - participant_score
scores[:teams] = {}
index = 0
self.teams.each do |team|
score_team = {}
score_team[:team] = team
if self.varying_rubrics_by_round?
assess #New method defined - assess
calculate_score #New method defined - calculate_score
calculate_assessment #New method defined - calculate_assessment
else
assessments = ReviewResponseMap.get_assessments_for(team)
score = Answer.compute_scores(assessments, questions[:review])
end
index += 1
end
scores
end
</pre>

b) The following 4 methods were created after splitting the first method 
i. participant_score 

<pre>
def participant_score
self.participants.each do |participant|
scores[:participants][participant.id.to_s.to_sym] = participant.scores(questions)
end
end
</pre>

ii. assess 

<pre>
def assess
self.num_review_rounds.each do |i|
total_score = 0
total_num_of_assessments = 0 # calculate grades for each rounds
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
assessments = ReviewResponseMap.get_assessments_round_for(team, i)
round_sym = ("review" + i.to_s).to_sym
round = Answer.compute_scores(assessments, questions[round_sym])
total_num_of_assessments += assessments.size
total_score += round[:avg] * assessments.size.to_f unless round[:avg].nil?
end
end
</pre>

iii. calculate_score 

<pre>
def calculate_score
score = {}
score[:max] = -999_999_999
score[:min] = 999_999_999
score[:avg] = 0
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
self.num_review_rounds.each do |i|
round_sym = ("review" + i.to_s).to_sym
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
score[:max] = round[:max] if max_condition
score[:min] = round[:min] if min_condition
end
end
</pre>

iv. calculate_assessment

<pre>
def calculate_assessment
if total_num_of_assessments.nonzero?
score[:avg] = total_score / total_num_of_assessments
else
score[:avg] = nil
score[:max] = 0
score[:min] = 0
end
end
</pre>

c) Complex and long statements or loops were broken into simpler multiple statements.

For example, the unless condition in Lines 132-134 was refactored to Line 127. This reduced the Perceived Complexity of 'scores' method.

[[File:Conditionsimpler.png]]

2. a) We also refactored method ‘compute_reviews_hash’ which was very complex and modularized individual functionalities into 2 separate methods.
b) The following 2 methods were created and called after refactoring: 
i. scores_varying_rubrics 
ii. scores_non_varying_rubrics 

3. Similarly, method ‘compute_avg_and_ranges_hash’ was also refactored and a seperate method calc_contri_score was defined to calculate contributor’s score. This method was then called from ‘compute_avg_and_ranges_hash’.

[[File:rsz_unnamed.png]]
The Code Climate Grade Before Refactoring

[[File:rsz_1after.png]]
The Code Climate Grade After Refactoring
== Testing Details==

====UI Testing====

1. Login into Expertiza as a student or an instructor. 
2. Go to an assignment which has some prior reviews for a previous project and click on view scores. 
3. The total score for a review is calculated on the fly using this module. 
4. You will be able to see the average score that each reviewer gave you on the top right of your page. 
5. This ensured that the refactoring done by us didn't break the code and it delivered it's expected functionality. 

== Scope for future improvement ==

Every code has future improvements possible. We have evolved the Code Climate Grade 'F' to a Grade 'C' currently by removing the Cyclomatic complexity, the Perceived Complexity and replaced with the "for" with the 'each' to reduce the size .
There are modifications that can still reduce the "ABC" Assignment Branches and Conditions Score as we can include the variables and functions in the "before action clauses", and rename long names with shorter yet appropriate names thus moving towards the score of "A".

CSC/ECE 517 Fall 2016/E1659. Refactor on the fly calc.rb

2016-11-04T23:18:20Z

Asagarwa: /* UI Testing */

This wiki page is for the description of changes made under E1659 OSS assignment for Fall 2016, CSC/ECE 517.

== Peer Review Information ==

For users intending to view the deployed Expertiza associated with this assignment, the credentials are below:
* Instructor login: username -> instructor6, password -> password
* Student login: username -> student5431, password -> password
* Student login: username -> student5427, password -> password

== Expertiza 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 it’s code is available on Github. Using Expertiza students can bid for a particular project topic and the faculty assigns the same to different groups. Students can track their grades for previous projects and make new submissions for current projects. It also allows students to review each other’s work and improve their work upon this feedback.

== Description of the current project ==

We worked on a module named on_the_fly_calc in this Expertiza based OSS project. We focussed on refactoring some methods which were very complex and also modified the language of the module to make it more ruby-istic. We also worked on refactoring the code to reduce redundancy. Our goal in this project was to make this model easier to read and maintain.

== Files modified in current project ==

A model was modified for this project namely: 
1. On_the_fly_calc

=== On_the_fly_calc ===

On_the_fly_calc is a module that is included in assignment.rb. What this module does is that it calculates the score for both students and instructors. E.g., when a student clicks “view my score”, Expertiza calculates the review scores for each review. This is called “on the fly” because expertiza stores the review scores based on each question (in answers table), but does not store the total score that a reviewer gives to a reviewee. It directly calculates the total review score for each review, using the score values in the answer table during run-time.
Eg: For a set of 4 questions a reviewer gives 5 on 5 points for 2 questions and 4 on 5 points for other 2 questions. So only these points are stored in the database and when a reviewee clicks to see the score given by this particular reviewer, on_the_fly_calc module helps calculate the total score i.e. 90% in this case.

== List of changes ==
The main aim was to reduce the complexity grade of ‘on_the_fly_calc.rb’ module from “F” to “C” in CodeClimate, which was achieved. We worked on the following work items(WIs) in order to refactor the module: 
WI1 : Refactor ‘Similar Code’ in lines 34-42 and 62-70 in on_the_fly_calc.rb 
WI2 : Prefer ‘each’ over every instance of ‘for loop’ 
WI3 : Refactor ‘scores’ method to reduce ABC (assignment, branch and condition) size 
WI4 : Refactor ‘compute_reviews_hash’ method to reduce ABC (assignment, branch and condition) size 
WI5 : Refactor ‘compute_avg_and_ranges_hash’ method to reduce ABC (assignment, branch and condition) size

=== Solutions Implemented and Delivered ===

==== Refactored similar code ====

Lines 34-42 and 62-70 were similar in compute_reviews_hash method. Hence, a dedicated method ‘calc_review_score’ was defined and this method was called in the both instances inside compute_reviews_hash.

Lines 34-42 in compute_reviews_hash:

[[File:Similar code1.png]]

Similar code in Lines 62-70:

[[File:Similar code 2.png]]

Refactored method 'calc_review_score' for the two similar codes:

[[File:Same code method.png]]

==== Each loop prefered over For loop ====

In every instance where ‘for’ loops were used in on_the_fly_calc module, ‘each…do’ was replaced instead. This significantly reduced the Cyclomatic complexity of the code.

The following screen shows the instances where for loops where replaced:

[[File:Eachloop.png]]

==== Refactored methods - 'scores', 'compute_reviews_hash', 'compute_avg_and_ranges_hash' ====

1. a) Method ‘scores’ was very complex, performing too many functions within a single method. Hence, every specific function was broken down into 4 separate smaller methods. This significantly reduced the Assignment, Branch, Condition size for ‘scores’ method.

<pre>
def scores(questions)
scores = {}
score_team = scores[:teams][index.to_s.to_sym]
score = score_team[:scores]
scores[:participants] = {}
participant_score #New method defined - participant_score
scores[:teams] = {}
index = 0
self.teams.each do |team|
score_team = {}
score_team[:team] = team
if self.varying_rubrics_by_round?
assess #New method defined - assess
calculate_score #New method defined - calculate_score
calculate_assessment #New method defined - calculate_assessment
else
assessments = ReviewResponseMap.get_assessments_for(team)
score = Answer.compute_scores(assessments, questions[:review])
end
index += 1
end
scores
end
</pre>

b) The following 4 methods were created after splitting the first method 
i. participant_score 

<pre>
def participant_score
self.participants.each do |participant|
scores[:participants][participant.id.to_s.to_sym] = participant.scores(questions)
end
end
</pre>

ii. assess 

<pre>
def assess
self.num_review_rounds.each do |i|
total_score = 0
total_num_of_assessments = 0 # calculate grades for each rounds
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
assessments = ReviewResponseMap.get_assessments_round_for(team, i)
round_sym = ("review" + i.to_s).to_sym
round = Answer.compute_scores(assessments, questions[round_sym])
total_num_of_assessments += assessments.size
total_score += round[:avg] * assessments.size.to_f unless round[:avg].nil?
end
end
</pre>

iii. calculate_score 

<pre>
def calculate_score
score = {}
score[:max] = -999_999_999
score[:min] = 999_999_999
score[:avg] = 0
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
self.num_review_rounds.each do |i|
round_sym = ("review" + i.to_s).to_sym
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
score[:max] = round[:max] if max_condition
score[:min] = round[:min] if min_condition
end
end
</pre>

iv. calculate_assessment

<pre>
def calculate_assessment
if total_num_of_assessments.nonzero?
score[:avg] = total_score / total_num_of_assessments
else
score[:avg] = nil
score[:max] = 0
score[:min] = 0
end
end
</pre>

c) Complex and long statements or loops were broken into simpler multiple statements.

For example, the unless condition in Lines 132-134 was refactored to Line 127. This reduced the Perceived Complexity of 'scores' method.

[[File:Conditionsimpler.png]]

2. a) We also refactored method ‘compute_reviews_hash’ which was very complex and modularized individual functionalities into 2 separate methods.
b) The following 2 methods were created and called after refactoring: 
i. scores_varying_rubrics 
ii. scores_non_varying_rubrics 

3. Similarly, method ‘compute_avg_and_ranges_hash’ was also refactored and a seperate method calc_contri_score was defined to calculate contributor’s score. This method was then called from ‘compute_avg_and_ranges_hash’.

[[File:rsz_unnamed.png]]
The Code Climate Grade Before Refactoring

[[File:rsz_1after.png]]
The Code Climate Grade After Refactoring
== Testing Details==

====UI Testing====

1. Login into Expertiza as a student or an instructor.
2. Go to an assignment which has some prior reviews for a previous project and click on view scores.
3. The total score for a review is calculated on the fly using this module.
4. You will be able to see the average score that each reviewer gave you on the top right of your page.
5. This ensured that the refactoring done by us didn't break the code and it delivered it's expected functionality.

== Scope for future improvement ==

Every code has future improvements possible. We have evolved the Code Climate Grade 'F' to a Grade 'C' currently by removing the Cyclomatic complexity, the Perceived Complexity and replaced with the "for" with the 'each' to reduce the size .
There are modifications that can still reduce the "ABC" Assignment Branches and Conditions Score as we can include the variables and functions in the "before action clauses", and rename long names with shorter yet appropriate names thus moving towards the score of "A".

CSC/ECE 517 Fall 2016/E1659. Refactor on the fly calc.rb

2016-11-04T23:16:41Z

Asagarwa:

This wiki page is for the description of changes made under E1659 OSS assignment for Fall 2016, CSC/ECE 517.

== Peer Review Information ==

For users intending to view the deployed Expertiza associated with this assignment, the credentials are below:
* Instructor login: username -> instructor6, password -> password
* Student login: username -> student5431, password -> password
* Student login: username -> student5427, password -> password

== Expertiza 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 it’s code is available on Github. Using Expertiza students can bid for a particular project topic and the faculty assigns the same to different groups. Students can track their grades for previous projects and make new submissions for current projects. It also allows students to review each other’s work and improve their work upon this feedback.

== Description of the current project ==

We worked on a module named on_the_fly_calc in this Expertiza based OSS project. We focussed on refactoring some methods which were very complex and also modified the language of the module to make it more ruby-istic. We also worked on refactoring the code to reduce redundancy. Our goal in this project was to make this model easier to read and maintain.

== Files modified in current project ==

A model was modified for this project namely: 
1. On_the_fly_calc

=== On_the_fly_calc ===

On_the_fly_calc is a module that is included in assignment.rb. What this module does is that it calculates the score for both students and instructors. E.g., when a student clicks “view my score”, Expertiza calculates the review scores for each review. This is called “on the fly” because expertiza stores the review scores based on each question (in answers table), but does not store the total score that a reviewer gives to a reviewee. It directly calculates the total review score for each review, using the score values in the answer table during run-time.
Eg: For a set of 4 questions a reviewer gives 5 on 5 points for 2 questions and 4 on 5 points for other 2 questions. So only these points are stored in the database and when a reviewee clicks to see the score given by this particular reviewer, on_the_fly_calc module helps calculate the total score i.e. 90% in this case.

== List of changes ==
The main aim was to reduce the complexity grade of ‘on_the_fly_calc.rb’ module from “F” to “C” in CodeClimate, which was achieved. We worked on the following work items(WIs) in order to refactor the module: 
WI1 : Refactor ‘Similar Code’ in lines 34-42 and 62-70 in on_the_fly_calc.rb 
WI2 : Prefer ‘each’ over every instance of ‘for loop’ 
WI3 : Refactor ‘scores’ method to reduce ABC (assignment, branch and condition) size 
WI4 : Refactor ‘compute_reviews_hash’ method to reduce ABC (assignment, branch and condition) size 
WI5 : Refactor ‘compute_avg_and_ranges_hash’ method to reduce ABC (assignment, branch and condition) size

=== Solutions Implemented and Delivered ===

==== Refactored similar code ====

Lines 34-42 and 62-70 were similar in compute_reviews_hash method. Hence, a dedicated method ‘calc_review_score’ was defined and this method was called in the both instances inside compute_reviews_hash.

Lines 34-42 in compute_reviews_hash:

[[File:Similar code1.png]]

Similar code in Lines 62-70:

[[File:Similar code 2.png]]

Refactored method 'calc_review_score' for the two similar codes:

[[File:Same code method.png]]

==== Each loop prefered over For loop ====

In every instance where ‘for’ loops were used in on_the_fly_calc module, ‘each…do’ was replaced instead. This significantly reduced the Cyclomatic complexity of the code.

The following screen shows the instances where for loops where replaced:

[[File:Eachloop.png]]

==== Refactored methods - 'scores', 'compute_reviews_hash', 'compute_avg_and_ranges_hash' ====

1. a) Method ‘scores’ was very complex, performing too many functions within a single method. Hence, every specific function was broken down into 4 separate smaller methods. This significantly reduced the Assignment, Branch, Condition size for ‘scores’ method.

<pre>
def scores(questions)
scores = {}
score_team = scores[:teams][index.to_s.to_sym]
score = score_team[:scores]
scores[:participants] = {}
participant_score #New method defined - participant_score
scores[:teams] = {}
index = 0
self.teams.each do |team|
score_team = {}
score_team[:team] = team
if self.varying_rubrics_by_round?
assess #New method defined - assess
calculate_score #New method defined - calculate_score
calculate_assessment #New method defined - calculate_assessment
else
assessments = ReviewResponseMap.get_assessments_for(team)
score = Answer.compute_scores(assessments, questions[:review])
end
index += 1
end
scores
end
</pre>

b) The following 4 methods were created after splitting the first method 
i. participant_score 

<pre>
def participant_score
self.participants.each do |participant|
scores[:participants][participant.id.to_s.to_sym] = participant.scores(questions)
end
end
</pre>

ii. assess 

<pre>
def assess
self.num_review_rounds.each do |i|
total_score = 0
total_num_of_assessments = 0 # calculate grades for each rounds
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
assessments = ReviewResponseMap.get_assessments_round_for(team, i)
round_sym = ("review" + i.to_s).to_sym
round = Answer.compute_scores(assessments, questions[round_sym])
total_num_of_assessments += assessments.size
total_score += round[:avg] * assessments.size.to_f unless round[:avg].nil?
end
end
</pre>

iii. calculate_score 

<pre>
def calculate_score
score = {}
score[:max] = -999_999_999
score[:min] = 999_999_999
score[:avg] = 0
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
self.num_review_rounds.each do |i|
round_sym = ("review" + i.to_s).to_sym
grades_by_rounds = {}
round = grades_by_rounds[round_sym]
score[:max] = round[:max] if max_condition
score[:min] = round[:min] if min_condition
end
end
</pre>

iv. calculate_assessment

<pre>
def calculate_assessment
if total_num_of_assessments.nonzero?
score[:avg] = total_score / total_num_of_assessments
else
score[:avg] = nil
score[:max] = 0
score[:min] = 0
end
end
</pre>

c) Complex and long statements or loops were broken into simpler multiple statements.

For example, the unless condition in Lines 132-134 was refactored to Line 127. This reduced the Perceived Complexity of 'scores' method.

[[File:Conditionsimpler.png]]

2. a) We also refactored method ‘compute_reviews_hash’ which was very complex and modularized individual functionalities into 2 separate methods.
b) The following 2 methods were created and called after refactoring: 
i. scores_varying_rubrics 
ii. scores_non_varying_rubrics 

3. Similarly, method ‘compute_avg_and_ranges_hash’ was also refactored and a seperate method calc_contri_score was defined to calculate contributor’s score. This method was then called from ‘compute_avg_and_ranges_hash’.

[[File:rsz_unnamed.png]]
The Code Climate Grade Before Refactoring

[[File:rsz_1after.png]]
The Code Climate Grade After Refactoring
== Testing Details==

====UI Testing====

Login into Expertiza as a student or an instructor. Go to an assignment which has some reviews for a previous project and click on view scores. The total score for a review is calculated on the fly using this module. You will be able to see the average score that each reviewer gave you on the top right of your page. This ensured that the refactoring done by us didn't break the code and it delivered it's expected functionality.

== Scope for future improvement ==

Every code has future improvements possible. We have evolved the Code Climate Grade 'F' to a Grade 'C' currently by removing the Cyclomatic complexity, the Perceived Complexity and replaced with the "for" with the 'each' to reduce the size .
There are modifications that can still reduce the "ABC" Assignment Branches and Conditions Score as we can include the variables and functions in the "before action clauses", and rename long names with shorter yet appropriate names thus moving towards the score of "A".

CSC/ECE 517 Fall 2016/E1659. Refactor on the fly calc.rb

2016-10-28T06:08:07Z

Asagarwa:

CSC/ECE 517 Fall 2016/E1659. Refactor on the fly calc.rb

2016-10-28T05:56:31Z

Asagarwa: Created page with "This wiki page is for the description of changes made under E1659 OSS assignment for Fall 2016, CSC/ECE 517. == Peer Review Information == For users intending to view the deplo..."

CSC/ECE 517 Fall 2016

2016-10-28T04:48:37Z

Asagarwa: /* Writing Assignments 2 */

CSC/ECE 517 Fall 2016/E1659.Refactor on the fly calc.rb

2016-10-28T04:44:17Z

Asagarwa:

a
n

CSC/ECE 517 Fall 2016/E1659.Refactor on the fly calc.rb

2016-10-28T04:43:18Z

Asagarwa: Created page with "a"