Expertiza_Wiki - User contributions [en]

Use of bullet gem and .includes to speed up db accesses

2021-12-24T00:08:19Z

Hmkachha:

==Introduction==
=== Team ===
Dr. Gehringer (mentor),
* Harsh Kachhadia (hmkachha)
* Tirth Patel (tdpatel2)

==Background==

===N+1 problem===

In terms of performance, one of the most common problems faced in ORMs is the N+1 query problem. This query problem is a result when a query is made on the result of previous query. That is, when our application tries to retrive data from its database and then loops through the resulting data to get various results. This problem is normally not seen in small applications where the data is small and there are less requests and queries. But if we want to make a scalable application, it becomes important to handle the N+1 query problem from start otherwise the performance of the application will decrease as the application codebase gets bigger and more queries gets fired.

===Solution===

'''How eager loading solves the problem'''

To solve the N+1 problem, we use a process called 'eager loading'. In general, whenever code requests for a resource using db query, a query is fired to the database and the particular resource is fetched. In lazy loading, only the resources required at the moment are fetched and if in future more resources or entities are needed, then additional queries are fired into database. This significantly increases the number of queries fired whenever there is some loop construct in the code. This results into slow page load speed. As opposed to lazy loading, by using eager loading, we load additional required entities which we might require in near future, along with the main resource required by the query. Especially, during loops such as .each, eager loading significantly lowers the page load time, due to less queries fired resulting from additional data loaded from a single main resource query.

For instance, if we are firing a query to fetch all participants, and then loop through all the participants using .each to display their course name, then using eager loading, we can load all the course names for all participants in the same query in which all the participants are fetched from the database, as opposed to individual queries fired to access course names for individual participants in lazy loading.

'''How 'includes' method helps in eager loading'''

In Rails, 'includes' method specifies model associations to be included in the result set of the query being fired to the database.

For eg. current_user.participants.includes(:assignment, assignment: [:course]).each{|p| course_ids << p.assignment.course.id if p.assignment and p.assignment.course

Here participants.includes(:assignment, assignment: [:course]) will retrieve all the assignment and course records relating to each participant using 2 queries (1 for participants, 1 for assignments and courses relating to participants), so that when each loop accesses the assignment and course for a participant using 'p.assignment.course' or 'p.assignment', no new query will be fired. This reduces the number of queries using 'includes' method to 2 queries even if we have 1000 participants as compared to 2000 queries.

===Bullet Gem===

'''How bullet gem helps in solving N+1 problem'''

The Bullet Gem has been programmed in such a way that it helps in reducing the number of queries the application makes. This helps in increasing the application performance. When the user runs their application, the bullet gem will watch the queries that the application makes and will notify the user/programmer of the places where eager loading (N+1 queries) can be applied. That is, it will show places where eager loading is needed and where it is not needed.

'''How to use bullet gem in rails'''

Adding bullet gem:

[[File:Gemfileimg.png | 700px]]

To Install:

'''You can install it as a gem:'''
gem install bullet

or '''add this into a Gemfile (Bundler):'''
gem 'bullet', group: 'development'

'''To enable the Bullet gem with generate command:'''
bundle exec rails g bullet:install

The generate command will auto generate the default configuration and may ask to include in the test environment as well. See below for custom configuration in development.rb

[[File:Developmentrb.png | 700px]]

Once everything is set, you can run your application. The bullet gem will find places in the code (only the one being used while accessing the application) where eager loading is needed. The user can find the bullet logs at 'logs/bullet.log'

==Overview of changes we made during this project==

With the use of above mentioned bullet gem, we found the locations in the expertiza code, where eager loading needs to be implemented, by looking at the stack trace recorded in bullet.log file by bullet gem. Bullet gem locates these code locations, as we navigate throughout the website.

For this project, we targeted the following areas of expertiza, those which loads very slow and needs eager loading.

'''tree_display_controller'''
* Courses
* Assignments
* Questionnaires
* Users

'''grades_controller'''
* view (View scores)

'''review_mapping_controller'''
* list_mappings

'''reports_controller'''
* Review report
* Author-feedback report
* Teammate-review report
* Answer-tagging report

'''student_task_controller'''
* Impersonating a student

We navigated through the UI, that use the code in above mentioned controllers, during which bullet gem located the code locations in these files where eager loading has to be implemented using 'includes' method.

===Files that are modified in this project===

* tree_display_controller.rb
* feedback_response_map
* instructor.rb
* student_task.rb
* user.rb
* _feedback_report.html.erb
* _flash_notifications.html.erb
* development.rb
* Gemfile

===Code changes to resolve N+1 Problem in Expertiza===

====Courses, Assignments, Questionnaires, Users====

* '''tree_display_controller.rb'''
[[File:Tree_display_controllerrb.png | 700px]]

'''Explanation:''' Here FolderNode.includes(:folder) will retrieve all the folder records relating to each FolderNode using 2 queries (1 for FolderNode, 1 for folder associations relating to folder nodes), so that when each loop accesses the folder for a folder node , no new query will be fired. Thus, reducing the number of queries using 'includes' method to 2 queries as compared to large number of queries which slows down the system.

* '''_flash_notifications.html.erb'''
[[File:Flash_notificationserb.png | 700px]]

'''Explanation:''' Here participants.includes(:assignment, assignment: [:course]) will retrieve all the assignment and course records relating to each participant using 2 queries(1 for participants, 1 for assignments and courses relating to participants), so that when each loop accesses the assignment and course for a participant using 'p.assignment.course' or 'p.assignment', no new query will be fired. Thus, reducing the number of queries using 'includes' method to 2 queries even if we have 1000 participants as compared to 2000 queries.

* '''user.rb'''
[[File:Userrb.png | 700px]]

'''Explanation:''' Here User.includes(:parent, :role, parent: [:parent, :role]) will retrieve all the parent and role records relating to each User using 2 queries (1 for User, 1 for parent and role associations relating to User), so that when each loop accesses the parent and role record for a User , no new query will be fired. Thus, reducing the number of queries using 'includes' method to 2 queries as compared to large number of queries which slows down the system.

====Review Report, Author Feedback Report====

* '''feedback_response_map'''
[[File:Feedback_response_maprb.png | 700px]]

'''Explanation:''' Here AssignmentTeam.includes(:users) will retrieve all the user records relating to each team using 2 queries (1 for team, 1 for users associations relating to Team), so that when each loop accesses the user for a team , no new query will be fired. Thus, reducing the number of queries using 'includes' method to 2 queries as compared to large number of queries which slows down the system.

* '''_feedback_report.html.erb'''
[[File:Feedback_reporterb.png | 700px]]

'''Explanation:''' Here @review_responses.includes([:response_map]) will retrieve all the response map records relating to each response using 2 queries (1 for response, 1 for response map associations relating to each response), so that when each loop accesses the response map for a response, no new query will be fired. Thus, reducing the number of queries using 'includes' method to 2 queries as compared to large number of queries which slows down the system.

====Impersonating a User====

* '''instructor.rb'''
[[File:Instructorrb.png | 700px]]

'''Explanation:''' Here assignments.includes(:participants) will retrieve all the participant records relating to each assignment using 2 queries (1 for assignment, 1 for participants associations relating to assignment), so that when each loop accesses the participant for a assignment , no new query will be fired. Thus, reducing the number of queries using 'includes' method to 2 queries as compared to large number of queries which slows down the system.

Here p_s.includes(:user, user: [:role]) will retrieve all the user and role records relating to each participant using 2 queries(1 for participant, 1 for user and role associations relating to participant), so that when each loop accesses the user and role record for a participant , no new query will be fired. Thus, reducing the number of queries using 'includes' method to 2 queries as compared to large number of queries which slows down the system.

* '''student_task.rb'''
[[File:Student_task_nrb.png | 700px]]

'''Explanation:''' Here assignment_participants.includes([:assignment, :topic]) will retrieve all the assignment and topic records relating to each participant using 2 queries (1 for participant, 1 for assignment and topic associations relating to participant), so that when each loop accesses the assignment and topic record for a participant , no new query will be fired. Thus, reducing the number of queries using 'includes' method to 2 queries as compared to large number of queries which slows down the system.

==Challenges faced during implementation==

* Review Report shows 'Nil Class error' when we try to open it. So we couldn't proceed further with it.
* When we tried to improve performance for 'Users' which is basically how fast list of all users in expertiza loads, we found some N+1 issues using bullet gem, but even after fixing all the N+1 issues for users, the page load time improved by just 2-3 seconds which seems like an insignificant changes in page load time as compared to the actual page load time of more than a minute.
* We worked on VCL version of expertiza, which uses Ruby version 2.3, and so the latest version of bullet gem - 6.1.5 works on it seamlessly, but the beta version in original expertiza repository uses Ruby version 2.2.7p, due to which latest version of bullet gem is not compatible with it. As a result, we had to downgrade bullet gem version to 5.7.6 in order to make it compatible with Ruby version - 2.2.7p of beta branch of expertiza GitHub reporsitory.

==Testing plan==

We aim to perform automatic and manual testing for this project in order to achieve better reliability for this implementation.

As for this project, very few lines of code have been modified in the above mentioned files and also as this is more of a refactoring project, automatic testing was done by checking whether the existing tests pass or not.

Manual testing was done by navigating the UI to the locations using the code from the files that were modified. All manual tests are passed.

==Important Links==

* [https://github.com/expertiza/expertiza/pull/2171 GitHub pull request link]
* [https://expertiza.csc.ncsu.edu/index.php/Use_of_bullet_gem_and_.includes_to_speed_up_db_accesses Expertiza wiki page link] (the link is mentioned here for records. It redirects to this same page.)
* [https://github.com/harshkachhadia/expertiza/tree/beta Github Repository Link for this expertiza fork] (make sure you change branch to 'beta' branch if the page doesn't load by default to beta branch)

Use of bullet gem and .includes to speed up db accesses

2021-12-20T14:32:57Z

Hmkachha:

==Introduction==
=== Team ===
Dr. Gehringer (mentor),
* Harsh Kachhadia (hmkachha)
* Tirth Patel (tdpatel2)

==Background==

===N+1 problem===

In terms of performance, one of the most common problems faced in ORMs is the N+1 query problem. This query problem is a result when a query is made on the result of previous query. That is, when our application tries to retrive data from its database and then loops through the resulting data to get various results. This problem is normally not seen in small applications where the data is small and there are less requests and queries. But if we want to make a scalable application, it becomes important to handle the N+1 query problem from start otherwise the performance of the application will decrease as the application codebase gets bigger and more queries gets fired.

===Solution===

'''How eager loading solves the problem'''

To solve the N+1 problem, we use a process called 'eager loading'. In general, whenever code requests for a resource using db query, a query is fired to the database and the particular resource is fetched. In lazy loading, only the resources required at the moment are fetched and if in future more resources or entities are needed, then additional queries are fired into database. This significantly increases the number of queries fired whenever there is some loop construct in the code. This results into slow page load speed. As opposed to lazy loading, by using eager loading, we load additional required entities which we might require in near future, along with the main resource required by the query. Especially, during loops such as .each, eager loading significantly lowers the page load time, due to less queries fired resulting from additional data loaded from a single main resource query.

For instance, if we are firing a query to fetch all participants, and then loop through all the participants using .each to display their course name, then using eager loading, we can load all the course names for all participants in the same query in which all the participants are fetched from the database, as opposed to individual queries fired to access course names for individual participants in lazy loading.

'''How 'includes' method helps in eager loading'''

In Rails, 'includes' method specifies model associations to be included in the result set of the query being fired to the database.

For eg. current_user.participants.includes(:assignment, assignment: [:course]).each{|p| course_ids << p.assignment.course.id if p.assignment and p.assignment.course

Here participants.includes(:assignment, assignment: [:course]) will retrieve all the assignment and course records relating to each participant using 2 queries(1 for participants, 1 for assignments and courses relating to participants), so that when each loop accesses the assignment and course for a participant using 'p.assignment.course' or 'p.assignment', no new query will be fired. Thus, reducing the number of queries using 'includes' method to 2 queries even if we have 1000 participants as compared to 2000 queries.

===Bullet Gem===

'''How bullet gem helps in solving N+1 problem'''

The Bullet Gem has been programmed in such a way that it helps in reducing the number of queries the application makes. This helps in increasing the application performance. When the user runs their application, the bullet gem will watch the queries that the application makes and will notify the user/programmer of the places where eager loading (N+1 queries) can be applied. That is, it will show places where eager loading is needed and where it is not needed.

'''How to use bullet gem in rails'''

Adding bullet gem:

[[File:Gemfileimg.png | 700px]]

To Install:

'''You can install it as a gem:'''
gem install bullet

or '''add this into a Gemfile (Bundler):'''
gem 'bullet', group: 'development'

'''To enable the Bullet gem with generate command:'''
bundle exec rails g bullet:install

The generate command will auto generate the default configuration and may ask to include in the test environment as well. See below for custom configuration in development.rb

[[File:Developmentrb.png | 700px]]

Once everything is set, you can run your application. The bullet gem will find places in the code (only the one being used while accessing the application) where eager loading is needed. The user can find the bullet logs at 'logs/bullet.log'

==Overview of changes we made during this project==

With the use of above mentioned bullet gem, we found the locations in the expertiza code, where eager loading needs to be implemented, by looking at the stack trace recorded in bullet.log file by bullet gem. Bullet gem locates these code locations, as we navigate throughout the website.

For this project, we targeted the following areas of expertiza, those which loads very slow and needs eager loading.

'''tree_display_controller'''
* Courses
* Assignments
* Questionnaires
* Users

'''grades_controller'''
* view (View scores)

'''review_mapping_controller'''
* list_mappings

'''reports_controller'''
* Review report
* Author-feedback report
* Teammate-review report
* Answer-tagging report

'''student_task_controller'''
* Impersonating a student

We navigated through the UI, that use the code in above mentioned controllers, during which bullet gem located the code locations in these files where eager loading has to be implemented using 'includes' method.

===Files that are modified in this project===

* tree_display_controller.rb
* feedback_response_map
* instructor.rb
* student_task.rb
* user.rb
* _feedback_report.html.erb
* _flash_notifications.html.erb
* development.rb
* Gemfile

===Code changes to resolve N+1 Problem in Expertiza===
* '''tree_display_controller.rb'''
[[File:Tree_display_controllerrb.png | 700px]]

'''Explanation:''' Here FolderNode.includes(:folder) will retrieve all the folder records relating to each FolderNode using 2 queries(1 for FolderNode, 1 for folder associations relating to folder nodes), so that when each loop accesses the folder for a folder node , no new query will be fired. Thus, reducing the number of queries using 'includes' method to 2 queries as compared to large number of queries which slows down the system.

* '''feedback_response_map'''
[[File:Feedback_response_maprb.png | 700px]]

'''Explanation:''' Here AssignmentTeam.includes(:users) will retrieve all the user records relating to each team using 2 queries(1 for team, 1 for users associations relating to Team), so that when each loop accesses the user for a team , no new query will be fired. Thus, reducing the number of queries using 'includes' method to 2 queries as compared to large number of queries which slows down the system.

* '''instructor.rb'''
[[File:Instructorrb.png | 700px]]

'''Explanation:''' Here assignments.includes(:participants) will retrieve all the participant records relating to each assignment using 2 queries(1 for assignment, 1 for participants associations relating to assignment), so that when each loop accesses the participant for a assignment , no new query will be fired. Thus, reducing the number of queries using 'includes' method to 2 queries as compared to large number of queries which slows down the system.

Here p_s.includes(:user, user: [:role]) will retrieve all the user and role records relating to each participant using 2 queries(1 for participant, 1 for user and role associations relating to participant), so that when each loop accesses the user and role record for a participant , no new query will be fired. Thus, reducing the number of queries using 'includes' method to 2 queries as compared to large number of queries which slows down the system.

* '''student_task.rb'''
[[File:Student_task_nrb.png | 700px]]

'''Explanation:''' Here assignment_participants.includes([:assignment, :topic]) will retrieve all the assignment and topic records relating to each participant using 2 queries(1 for participant, 1 for assignment and topic associations relating to participant), so that when each loop accesses the assignment and topic record for a participant , no new query will be fired. Thus, reducing the number of queries using 'includes' method to 2 queries as compared to large number of queries which slows down the system.

* '''user.rb'''
[[File:Userrb.png | 700px]]

'''Explanation:''' Here User.includes(:parent, :role, parent: [:parent, :role]) will retrieve all the parent and role records relating to each User using 2 queries(1 for User, 1 for parent and role associations relating to User), so that when each loop accesses the parent and role record for a User , no new query will be fired. Thus, reducing the number of queries using 'includes' method to 2 queries as compared to large number of queries which slows down the system.

* '''_feedback_report.html.erb'''
[[File:Feedback_reporterb.png | 700px]]

'''Explanation:''' Here @review_responses.includes([:response_map]) will retrieve all the response map records relating to each response using 2 queries(1 for response, 1 for response map associations relating to each response), so that when each loop accesses the response map for a response, no new query will be fired. Thus, reducing the number of queries using 'includes' method to 2 queries as compared to large number of queries which slows down the system.

* '''_flash_notifications.html.erb'''
[[File:Flash_notificationserb.png | 700px]]

'''Explanation:''' Here participants.includes(:assignment, assignment: [:course]) will retrieve all the assignment and course records relating to each participant using 2 queries(1 for participants, 1 for assignments and courses relating to participants), so that when each loop accesses the assignment and course for a participant using 'p.assignment.course' or 'p.assignment', no new query will be fired. Thus, reducing the number of queries using 'includes' method to 2 queries even if we have 1000 participants as compared to 2000 queries.

==Testing plan==

We aim to perform automatic and manual testing for this project in order to achieve better reliability for this implementation.

As for this project, very few lines of code have been modified in the above mentioned files and also as this is more of a refactoring project, automatic testing was done by checking whether the existing tests pass or not.

Manual testing was done by navigating the UI to the locations using the code from the files that were modified. All manual tests are passed.

==Important Links==

* [https://github.com/expertiza/expertiza/pull/2171 GitHub pull request link]
* [https://expertiza.csc.ncsu.edu/index.php/Use_of_bullet_gem_and_.includes_to_speed_up_db_accesses Expertiza wiki page link] (the link is mentioned here for records. It redirects to this same page.)
* [https://github.com/harshkachhadia/expertiza/tree/beta Github Repository Link for this expertiza fork] (make sure you change branch to 'beta' branch if the page doesn't load by default to beta branch)

Use of bullet gem and .includes to speed up db accesses

2021-12-20T14:00:51Z

Hmkachha:

Use of bullet gem and .includes to speed up db accesses

2021-12-20T13:58:11Z

Hmkachha:

Use of bullet gem and .includes to speed up db accesses

2021-12-20T13:56:54Z

Hmkachha:

File:Developmentrb.png

2021-12-20T13:47:19Z

Hmkachha:

File:Flash notificationserb.png

2021-12-20T13:47:02Z

Hmkachha:

File:Feedback reporterb.png

2021-12-20T13:46:45Z

Hmkachha:

File:Userrb.png

2021-12-20T13:46:28Z

Hmkachha:

File:Student task nrb.png

2021-12-20T13:45:46Z

Hmkachha:

File:Student taskrb.png

2021-12-20T13:44:17Z

Hmkachha:

File:Gemfileimglock.png

2021-12-20T13:43:18Z

Hmkachha:

File:Gemfileimg.png

2021-12-20T13:42:39Z

Hmkachha:

File:Instructorrb.png

2021-12-20T13:42:22Z

Hmkachha:

File:Feedback response maprb.png

2021-12-20T13:42:08Z

Hmkachha:

File:Tree display controllerrb.png

2021-12-20T13:41:40Z

Hmkachha:

Use of bullet gem and .includes to speed up db accesses

2021-12-20T13:32:31Z

Hmkachha: /* Bullet Gem */

Use of bullet gem and .includes to speed up db accesses

2021-12-20T13:32:06Z

Hmkachha: /* Bullet Gem */

Use of bullet gem and .includes to speed up db accesses

2021-12-20T13:30:41Z

Hmkachha:

Use of bullet gem and .includes to speed up db accesses

2021-12-17T21:17:01Z

Hmkachha: /* Code changes to resolve N+1 Problem in Expertiza */

==Introduction==
=== Team ===
Dr. Gehringer (mentor),
* Harsh Kachhadia (hmkachha)
* Tirth Patel (tdpatel2)

==Background==

===N+1 problem===

===Solution===

'''How eager loading solves the problem'''

To solve the N+1 problem, we use a process called 'eager loading'. In general, whenever code requests for a resource using db query, a query is fired to the database and the particular resource is fetched. In lazy loading, only the resources required at the moment are fetched and if in future more resources or entities are needed, then additional queries are fired into database. This significantly increases the number of queries fired whenever there is some loop construct in the code. This results into slow page load speed. As opposed to lazy loading, by using eager loading, we load additional required entities which we might require in near future, along with the main resource required by the query. Especially, during loops such as .each, eager loading significantly lowers the page load time, due to less queries fired resulting from additional data loaded from a single main resource query.

For instance, if we are firing a query to fetch all participants, and then loop through all the participants using .each to display their course name, then using eager loading, we can load all the course names for all participants in the same query in which all the participants are fetched from the database, as opposed to individual queries fired to access course names for individual participants in lazy loading.

'''How 'includes' method helps in eager loading'''

In Rails, 'includes' method specifies model associations to be included in the result set of the query being fired to the database.

For eg. current_user.participants.includes(:assignment, assignment: [:course]).each{|p| course_ids << p.assignment.course.id if p.assignment and p.assignment.course

What happened is Post.includes(:user) told ActiveRecord to retrieve the corresponding user records from the database immediately after the initial request for all posts. Since the records of users were already in the memory, post.user.username could be retrieved by only one query. Now, even if we have 10,000 posts in our database, we can execute the example code above by just 2 queries! This is a huge difference.

Here participants.includes(:assignment, assignment: [:course]) will retrieve all the assignment and course records relating to each participant using 2 queries(1 for participants, 1 for assignments and courses relating to participants), so that when each loop accesses the assignment and course for a participant using 'p.assignment.course' or 'p.assignment', no new query will be fired. Thus, reducing the number of queries using 'includes' method to 2 queries even if we have 1000 participants as compared to 2000 queries.

===Bullet Gem===

'''How bullet gem helps in solving N+1 problem'''

'''How to use bullet gem in rails'''

==Overview of changes we made during this project==

With the use of above mentioned bullet gem, we found the locations in the expertiza code, where eager loading needs to be implemented, by looking at the stack trace recorded in bullet.log file by bullet gem. Bullet gem locates these code locations, as we navigate throughout the website.

For this project, we targeted the following areas of expertiza, those which loads very slow and needs eager loading.

'''tree_display_controller'''
* Courses
* Assignments
* Questionnaires
* Users

'''grades_controller'''
* view (View scores)

'''review_mapping_controller'''
* list_mappings

'''reports_controller'''
* Review report
* Author-feedback report
* Teammate-review report
* Answer-tagging report

'''student_task_controller'''
* Impersonating a student

We navigated through the UI, that use the code in above mentioned controllers, during which bullet gem located the code locations in these files where eager loading has to be implemented using 'includes' method.

===Files that are modified in this project===

* tree_display_controller.rb
* feedback_response_map
* instructor.rb
* student_task.rb
* user.rb
* _feedback_report.html.erb
* _flash_notifications.html.erb
* development.rb
* Gemfile

===Code changes to resolve N+1 Problem in Expertiza===
* '''tree_display_controller.rb'''
'''Explanation:'''
* '''feedback_response_map'''
'''Explanation:'''
* '''instructor.rb'''
'''Explanation:'''
* '''student_task.rb'''
'''Explanation:'''
* '''user.rb'''
'''Explanation:'''
* '''_feedback_report.html.erb'''
'''Explanation:'''
* '''_flash_notifications.html.erb'''
'''Explanation:'''
* '''development.rb'''
'''Explanation:'''
* '''Gemfile'''
'''Explanation:'''

==Testing plan==

We aim to perform automatic and manual testing for this project in order to achieve better reliability for this implementation.

As for this project, very few lines of code have been modified in the above mentioned files and also as this is more of a refactoring project, automatic testing was done by checking whether the existing tests pass or not.

Manual testing was done by navigating the UI to the locations using the code from the files that were modified. All manual tests are passed.

==Important Links==

* [https://github.com/expertiza/expertiza/pull/2171 GitHub pull request link]
* [https://expertiza.csc.ncsu.edu/index.php/Use_of_bullet_gem_and_.includes_to_speed_up_db_accesses Expertiza wiki page link] (the link is mentioned here for records. It redirects to this same page.)
* [https://github.com/harshkachhadia/expertiza/tree/beta Github Repository Link for this expertiza fork] (make sure you change branch to 'beta' branch if the page doesn't load by default to beta branch)

Use of bullet gem and .includes to speed up db accesses

2021-12-17T21:16:26Z

Hmkachha:

==Introduction==
=== Team ===
Dr. Gehringer (mentor),
* Harsh Kachhadia (hmkachha)
* Tirth Patel (tdpatel2)

==Background==

===N+1 problem===

===Solution===

'''How eager loading solves the problem'''

To solve the N+1 problem, we use a process called 'eager loading'. In general, whenever code requests for a resource using db query, a query is fired to the database and the particular resource is fetched. In lazy loading, only the resources required at the moment are fetched and if in future more resources or entities are needed, then additional queries are fired into database. This significantly increases the number of queries fired whenever there is some loop construct in the code. This results into slow page load speed. As opposed to lazy loading, by using eager loading, we load additional required entities which we might require in near future, along with the main resource required by the query. Especially, during loops such as .each, eager loading significantly lowers the page load time, due to less queries fired resulting from additional data loaded from a single main resource query.

For instance, if we are firing a query to fetch all participants, and then loop through all the participants using .each to display their course name, then using eager loading, we can load all the course names for all participants in the same query in which all the participants are fetched from the database, as opposed to individual queries fired to access course names for individual participants in lazy loading.

'''How 'includes' method helps in eager loading'''

In Rails, 'includes' method specifies model associations to be included in the result set of the query being fired to the database.

For eg. current_user.participants.includes(:assignment, assignment: [:course]).each{|p| course_ids << p.assignment.course.id if p.assignment and p.assignment.course

What happened is Post.includes(:user) told ActiveRecord to retrieve the corresponding user records from the database immediately after the initial request for all posts. Since the records of users were already in the memory, post.user.username could be retrieved by only one query. Now, even if we have 10,000 posts in our database, we can execute the example code above by just 2 queries! This is a huge difference.

Here participants.includes(:assignment, assignment: [:course]) will retrieve all the assignment and course records relating to each participant using 2 queries(1 for participants, 1 for assignments and courses relating to participants), so that when each loop accesses the assignment and course for a participant using 'p.assignment.course' or 'p.assignment', no new query will be fired. Thus, reducing the number of queries using 'includes' method to 2 queries even if we have 1000 participants as compared to 2000 queries.

===Bullet Gem===

'''How bullet gem helps in solving N+1 problem'''

'''How to use bullet gem in rails'''

==Overview of changes we made during this project==

With the use of above mentioned bullet gem, we found the locations in the expertiza code, where eager loading needs to be implemented, by looking at the stack trace recorded in bullet.log file by bullet gem. Bullet gem locates these code locations, as we navigate throughout the website.

For this project, we targeted the following areas of expertiza, those which loads very slow and needs eager loading.

'''tree_display_controller'''
* Courses
* Assignments
* Questionnaires
* Users

'''grades_controller'''
* view (View scores)

'''review_mapping_controller'''
* list_mappings

'''reports_controller'''
* Review report
* Author-feedback report
* Teammate-review report
* Answer-tagging report

'''student_task_controller'''
* Impersonating a student

We navigated through the UI, that use the code in above mentioned controllers, during which bullet gem located the code locations in these files where eager loading has to be implemented using 'includes' method.

===Files that are modified in this project===

* tree_display_controller.rb
* feedback_response_map
* instructor.rb
* student_task.rb
* user.rb
* _feedback_report.html.erb
* _flash_notifications.html.erb
* development.rb
* Gemfile

===Code changes to resolve N+1 Problem in Expertiza===
* '''tree_display_controller.rb'''
'''Explanation'''
* '''feedback_response_map'''
'''Explanation'''
* '''instructor.rb'''
'''Explanation'''
* '''student_task.rb'''
'''Explanation'''
* '''user.rb'''
'''Explanation'''
* '''_feedback_report.html.erb'''
'''Explanation'''
* '''_flash_notifications.html.erb'''
'''Explanation'''
* '''development.rb'''
'''Explanation'''
* '''Gemfile'''
'''Explanation'''

==Testing plan==

We aim to perform automatic and manual testing for this project in order to achieve better reliability for this implementation.

As for this project, very few lines of code have been modified in the above mentioned files and also as this is more of a refactoring project, automatic testing was done by checking whether the existing tests pass or not.

Manual testing was done by navigating the UI to the locations using the code from the files that were modified. All manual tests are passed.

==Important Links==

* [https://github.com/expertiza/expertiza/pull/2171 GitHub pull request link]
* [https://expertiza.csc.ncsu.edu/index.php/Use_of_bullet_gem_and_.includes_to_speed_up_db_accesses Expertiza wiki page link] (the link is mentioned here for records. It redirects to this same page.)
* [https://github.com/harshkachhadia/expertiza/tree/beta Github Repository Link for this expertiza fork] (make sure you change branch to 'beta' branch if the page doesn't load by default to beta branch)

Use of bullet gem and .includes to speed up db accesses

2021-12-17T21:12:59Z

Hmkachha: /* Code changes to resolve N+1 Problem in Expertiza */

==Introduction==
=== Team ===
Dr. Gehringer (mentor),
* Harsh Kachhadia (hmkachha)
* Tirth Patel (tdpatel2)

==Background==

===N+1 problem===

===Solution===

'''How eager loading solves the problem'''

To solve the N+1 problem, we use a process called 'eager loading'. In general, whenever code requests for a resource using db query, a query is fired to the database and the particular resource is fetched. In lazy loading, only the resources required at the moment are fetched and if in future more resources or entities are needed, then additional queries are fired into database. This significantly increases the number of queries fired whenever there is some loop construct in the code. This results into slow page load speed. As opposed to lazy loading, by using eager loading, we load additional required entities which we might require in near future, along with the main resource required by the query. Especially, during loops such as .each, eager loading significantly lowers the page load time, due to less queries fired resulting from additional data loaded from a single main resource query.

For instance, if we are firing a query to fetch all participants, and then loop through all the participants using .each to display their course name, then using eager loading, we can load all the course names for all participants in the same query in which all the participants are fetched from the database, as opposed to individual queries fired to access course names for individual participants in lazy loading.

'''How 'includes' method helps in eager loading'''

In Rails, 'includes' method specifies model associations to be included in the result set of the query being fired to the database.

For eg. current_user.participants.includes(:assignment, assignment: [:course]).each{|p| course_ids << p.assignment.course.id if p.assignment and p.assignment.course

What happened is Post.includes(:user) told ActiveRecord to retrieve the corresponding user records from the database immediately after the initial request for all posts. Since the records of users were already in the memory, post.user.username could be retrieved by only one query. Now, even if we have 10,000 posts in our database, we can execute the example code above by just 2 queries! This is a huge difference.

Here participants.includes(:assignment, assignment: [:course]) will retrieve all the assignment and course records relating to each participant using 2 queries(1 for participants, 1 for assignments and courses relating to participants), so that when each loop accesses the assignment and course for a participant using 'p.assignment.course' or 'p.assignment', no new query will be fired. Thus, reducing the number of queries using 'includes' method to 2 queries even if we have 1000 participants as compared to 2000 queries.

===Bullet Gem===

'''How bullet gem helps in solving N+1 problem'''

'''How to use bullet gem in rails'''

==Overview of changes we made during this project==

With the use of above mentioned bullet gem, we found the locations in the expertiza code, where eager loading needs to be implemented, by looking at the stack trace recorded in bullet.log file by bullet gem. Bullet gem locates these code locations, as we navigate throughout the website.

For this project, we targeted the following areas of expertiza, those which loads very slow and needs eager loading.

'''tree_display_controller'''
* Courses
* Assignments
* Questionnaires
* Users

'''grades_controller'''
* view (View scores)

'''review_mapping_controller'''
* list_mappings

'''reports_controller'''
* Review report
* Author-feedback report
* Teammate-review report
* Answer-tagging report

'''student_task_controller'''
* Impersonating a student

We navigated through the UI, that use the code in above mentioned controllers, during which bullet gem located the code locations in these files where eager loading has to be implemented using 'includes' method.

===Files that are modified in this project===

* tree_display_controller.rb
* feedback_response_map
* instructor.rb
* student_task.rb
* user.rb
* _feedback_report.html.erb
* _flash_notifications.html.erb
* development.rb

===Code changes to resolve N+1 Problem in Expertiza===
'''tree_display_controller.rb'''
'''Bold text'''

==Testing plan==

We aim to perform automatic and manual testing for this project in order to achieve better reliability for this implementation.

As for this project, very few lines of code have been modified in the above mentioned files and also as this is more of a refactoring project, automatic testing was done by checking whether the existing tests pass or not.

Manual testing was done by navigating the UI to the locations using the code from the files that were modified. All manual tests are passed.

==Important Links==

* [https://github.com/expertiza/expertiza/pull/2171 GitHub pull request link]
* [https://expertiza.csc.ncsu.edu/index.php/Use_of_bullet_gem_and_.includes_to_speed_up_db_accesses Expertiza wiki page link] (the link is mentioned here for records. It redirects to this same page.)
* [https://github.com/harshkachhadia/expertiza/tree/beta Github Repository Link for this expertiza fork] (make sure you change branch to 'beta' branch if the page doesn't load by default to beta branch)

Use of bullet gem and .includes to speed up db accesses

2021-12-17T21:11:54Z

Hmkachha: /* Important Links */

==Introduction==
=== Team ===
Dr. Gehringer (mentor),
* Harsh Kachhadia (hmkachha)
* Tirth Patel (tdpatel2)

==Background==

===N+1 problem===

===Solution===

'''How eager loading solves the problem'''

To solve the N+1 problem, we use a process called 'eager loading'. In general, whenever code requests for a resource using db query, a query is fired to the database and the particular resource is fetched. In lazy loading, only the resources required at the moment are fetched and if in future more resources or entities are needed, then additional queries are fired into database. This significantly increases the number of queries fired whenever there is some loop construct in the code. This results into slow page load speed. As opposed to lazy loading, by using eager loading, we load additional required entities which we might require in near future, along with the main resource required by the query. Especially, during loops such as .each, eager loading significantly lowers the page load time, due to less queries fired resulting from additional data loaded from a single main resource query.

For instance, if we are firing a query to fetch all participants, and then loop through all the participants using .each to display their course name, then using eager loading, we can load all the course names for all participants in the same query in which all the participants are fetched from the database, as opposed to individual queries fired to access course names for individual participants in lazy loading.

'''How 'includes' method helps in eager loading'''

In Rails, 'includes' method specifies model associations to be included in the result set of the query being fired to the database.

For eg. current_user.participants.includes(:assignment, assignment: [:course]).each{|p| course_ids << p.assignment.course.id if p.assignment and p.assignment.course

What happened is Post.includes(:user) told ActiveRecord to retrieve the corresponding user records from the database immediately after the initial request for all posts. Since the records of users were already in the memory, post.user.username could be retrieved by only one query. Now, even if we have 10,000 posts in our database, we can execute the example code above by just 2 queries! This is a huge difference.

Here participants.includes(:assignment, assignment: [:course]) will retrieve all the assignment and course records relating to each participant using 2 queries(1 for participants, 1 for assignments and courses relating to participants), so that when each loop accesses the assignment and course for a participant using 'p.assignment.course' or 'p.assignment', no new query will be fired. Thus, reducing the number of queries using 'includes' method to 2 queries even if we have 1000 participants as compared to 2000 queries.

===Bullet Gem===

'''How bullet gem helps in solving N+1 problem'''

'''How to use bullet gem in rails'''

==Overview of changes we made during this project==

With the use of above mentioned bullet gem, we found the locations in the expertiza code, where eager loading needs to be implemented, by looking at the stack trace recorded in bullet.log file by bullet gem. Bullet gem locates these code locations, as we navigate throughout the website.

For this project, we targeted the following areas of expertiza, those which loads very slow and needs eager loading.

'''tree_display_controller'''
* Courses
* Assignments
* Questionnaires
* Users

'''grades_controller'''
* view (View scores)

'''review_mapping_controller'''
* list_mappings

'''reports_controller'''
* Review report
* Author-feedback report
* Teammate-review report
* Answer-tagging report

'''student_task_controller'''
* Impersonating a student

We navigated through the UI, that use the code in above mentioned controllers, during which bullet gem located the code locations in these files where eager loading has to be implemented using 'includes' method.

===Files that are modified in this project===

* tree_display_controller.rb
* feedback_response_map
* instructor.rb
* student_task.rb
* user.rb
* _feedback_report.html.erb
* _flash_notifications.html.erb
* development.rb

===Code changes to resolve N+1 Problem in Expertiza===

==Testing plan==

We aim to perform automatic and manual testing for this project in order to achieve better reliability for this implementation.

As for this project, very few lines of code have been modified in the above mentioned files and also as this is more of a refactoring project, automatic testing was done by checking whether the existing tests pass or not.

Manual testing was done by navigating the UI to the locations using the code from the files that were modified. All manual tests are passed.

==Important Links==

* [https://github.com/expertiza/expertiza/pull/2171 GitHub pull request link]
* [https://expertiza.csc.ncsu.edu/index.php/Use_of_bullet_gem_and_.includes_to_speed_up_db_accesses Expertiza wiki page link] (the link is mentioned here for records. It redirects to this same page.)
* [https://github.com/harshkachhadia/expertiza/tree/beta Github Repository Link for this expertiza fork] (make sure you change branch to 'beta' branch if the page doesn't load by default to beta branch)

Use of bullet gem and .includes to speed up db accesses

2021-12-17T21:11:24Z

Hmkachha:

==Introduction==
=== Team ===
Dr. Gehringer (mentor),
* Harsh Kachhadia (hmkachha)
* Tirth Patel (tdpatel2)

==Background==

===N+1 problem===

===Solution===

'''How eager loading solves the problem'''

To solve the N+1 problem, we use a process called 'eager loading'. In general, whenever code requests for a resource using db query, a query is fired to the database and the particular resource is fetched. In lazy loading, only the resources required at the moment are fetched and if in future more resources or entities are needed, then additional queries are fired into database. This significantly increases the number of queries fired whenever there is some loop construct in the code. This results into slow page load speed. As opposed to lazy loading, by using eager loading, we load additional required entities which we might require in near future, along with the main resource required by the query. Especially, during loops such as .each, eager loading significantly lowers the page load time, due to less queries fired resulting from additional data loaded from a single main resource query.

For instance, if we are firing a query to fetch all participants, and then loop through all the participants using .each to display their course name, then using eager loading, we can load all the course names for all participants in the same query in which all the participants are fetched from the database, as opposed to individual queries fired to access course names for individual participants in lazy loading.

'''How 'includes' method helps in eager loading'''

In Rails, 'includes' method specifies model associations to be included in the result set of the query being fired to the database.

For eg. current_user.participants.includes(:assignment, assignment: [:course]).each{|p| course_ids << p.assignment.course.id if p.assignment and p.assignment.course

What happened is Post.includes(:user) told ActiveRecord to retrieve the corresponding user records from the database immediately after the initial request for all posts. Since the records of users were already in the memory, post.user.username could be retrieved by only one query. Now, even if we have 10,000 posts in our database, we can execute the example code above by just 2 queries! This is a huge difference.

Here participants.includes(:assignment, assignment: [:course]) will retrieve all the assignment and course records relating to each participant using 2 queries(1 for participants, 1 for assignments and courses relating to participants), so that when each loop accesses the assignment and course for a participant using 'p.assignment.course' or 'p.assignment', no new query will be fired. Thus, reducing the number of queries using 'includes' method to 2 queries even if we have 1000 participants as compared to 2000 queries.

===Bullet Gem===

'''How bullet gem helps in solving N+1 problem'''

'''How to use bullet gem in rails'''

==Overview of changes we made during this project==

With the use of above mentioned bullet gem, we found the locations in the expertiza code, where eager loading needs to be implemented, by looking at the stack trace recorded in bullet.log file by bullet gem. Bullet gem locates these code locations, as we navigate throughout the website.

For this project, we targeted the following areas of expertiza, those which loads very slow and needs eager loading.

'''tree_display_controller'''
* Courses
* Assignments
* Questionnaires
* Users

'''grades_controller'''
* view (View scores)

'''review_mapping_controller'''
* list_mappings

'''reports_controller'''
* Review report
* Author-feedback report
* Teammate-review report
* Answer-tagging report

'''student_task_controller'''
* Impersonating a student

We navigated through the UI, that use the code in above mentioned controllers, during which bullet gem located the code locations in these files where eager loading has to be implemented using 'includes' method.

===Files that are modified in this project===

* tree_display_controller.rb
* feedback_response_map
* instructor.rb
* student_task.rb
* user.rb
* _feedback_report.html.erb
* _flash_notifications.html.erb
* development.rb

===Code changes to resolve N+1 Problem in Expertiza===

==Testing plan==

We aim to perform automatic and manual testing for this project in order to achieve better reliability for this implementation.

As for this project, very few lines of code have been modified in the above mentioned files and also as this is more of a refactoring project, automatic testing was done by checking whether the existing tests pass or not.

Manual testing was done by navigating the UI to the locations using the code from the files that were modified. All manual tests are passed.

==Important Links==

* [https://github.com/expertiza/expertiza/pull/2171]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2021_-_E2112._Integrate_Suggestion_Detection_Algorithm Expertiza wiki page link] (the link is mentioned here for records. It redirects to this same page.)
* [https://github.com/harshkachhadia/expertiza/tree/beta Github Repository Link for this expertiza fork] (make sure you change branch to 'beta' branch if the page doesn't load by default to beta branch)

Use of bullet gem and .includes to speed up db accesses

2021-12-17T21:07:59Z

Hmkachha:

==Introduction==
=== Team ===
Dr. Gehringer (mentor),
* Harsh Kachhadia (hmkachha)
* Tirth Patel (tdpatel2)

==Background==

===N+1 problem===

===Solution===

'''How eager loading solves the problem'''

To solve the N+1 problem, we use a process called 'eager loading'. In general, whenever code requests for a resource using db query, a query is fired to the database and the particular resource is fetched. In lazy loading, only the resources required at the moment are fetched and if in future more resources or entities are needed, then additional queries are fired into database. This significantly increases the number of queries fired whenever there is some loop construct in the code. This results into slow page load speed. As opposed to lazy loading, by using eager loading, we load additional required entities which we might require in near future, along with the main resource required by the query. Especially, during loops such as .each, eager loading significantly lowers the page load time, due to less queries fired resulting from additional data loaded from a single main resource query.

For instance, if we are firing a query to fetch all participants, and then loop through all the participants using .each to display their course name, then using eager loading, we can load all the course names for all participants in the same query in which all the participants are fetched from the database, as opposed to individual queries fired to access course names for individual participants in lazy loading.

'''How 'includes' method helps in eager loading'''

In Rails, 'includes' method specifies model associations to be included in the result set of the query being fired to the database.

For eg. current_user.participants.includes(:assignment, assignment: [:course]).each{|p| course_ids << p.assignment.course.id if p.assignment and p.assignment.course

What happened is Post.includes(:user) told ActiveRecord to retrieve the corresponding user records from the database immediately after the initial request for all posts. Since the records of users were already in the memory, post.user.username could be retrieved by only one query. Now, even if we have 10,000 posts in our database, we can execute the example code above by just 2 queries! This is a huge difference.

Here participants.includes(:assignment, assignment: [:course]) will retrieve all the assignment and course records relating to each participant using 2 queries(1 for participants, 1 for assignments and courses relating to participants), so that when each loop accesses the assignment and course for a participant using 'p.assignment.course' or 'p.assignment', no new query will be fired. Thus, reducing the number of queries using 'includes' method to 2 queries even if we have 1000 participants as compared to 2000 queries.

===Bullet Gem===

'''How bullet gem helps in solving N+1 problem'''

'''How to use bullet gem in rails'''

==Overview of changes we made during this project==

With the use of above mentioned bullet gem, we found the locations in the expertiza code, where eager loading needs to be implemented, by looking at the stack trace recorded in bullet.log file by bullet gem. Bullet gem locates these code locations, as we navigate throughout the website.

For this project, we targeted the following areas of expertiza, those which loads very slow and needs eager loading.

'''tree_display_controller'''
* Courses
* Assignments
* Questionnaires
* Users

'''grades_controller'''
* view (View scores)

'''review_mapping_controller'''
* list_mappings

'''reports_controller'''
* Review report
* Author-feedback report
* Teammate-review report
* Answer-tagging report

'''student_task_controller'''
* Impersonating a student

We navigated through the UI, that use the code in above mentioned controllers, during which bullet gem located the code locations in these files where eager loading has to be implemented using 'includes' method.

'''Files that are modified in this project'''

* tree_display_controller.rb
* feedback_response_map
* instructor.rb
* student_task.rb
* user.rb
* _feedback_report.html.erb
* _flash_notifications.html.erb
* development.rb

'''Code changes to resolve N+1 Problem in Expertiza'''

==Testing plan==

We aim to perform automatic and manual testing for this project in order to achieve better reliability for this implementation.

As for this project, very few lines of code have been modified in the above mentioned files and also as this is more of a refactoring project, automatic testing was done by checking whether the existing tests pass or not.

Manual testing was done by navigating the UI to the locations using the code from the files that were modified. All manual tests are passed.

==Important Links==

* [https://github.com/expertiza/expertiza/pull/1952 Github Pull Request]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2021_-_E2112._Integrate_Suggestion_Detection_Algorithm Expertiza wiki page link] (the link is mentioned here for records. It redirects to this same page.)
* [https://docs.google.com/document/d/1uzr5pybVKYr_K1Q8wSd4t-Id9nqTt3k1ePseDjY-RJg/edit#heading=h.fxfungdw1d5r Google Doc Project Description]
* [https://github.com/harshkachhadia/expertiza/tree/beta Github Repository Link for this expertiza fork] (make sure you change branch to 'beta' branch if the page doesn't load by default to beta branch)
* [https://youtu.be/OYZvNVa3GZ8 Youtube Video Link]

Use of bullet gem and .includes to speed up db accesses

2021-12-17T21:05:27Z

Hmkachha: Created page with "==Introduction== === Team === Dr. Gehringer (mentor), * Harsh Kachhadia (hmkachha) * Tirth Patel (tdpatel2) ==N+1 problem background== ==How eager loading solves the problem..."

==Introduction==
=== Team ===
Dr. Gehringer (mentor),
* Harsh Kachhadia (hmkachha)
* Tirth Patel (tdpatel2)

==N+1 problem background==

==How eager loading solves the problem==

To solve the N+1 problem, we use a process called 'eager loading'. In general, whenever code requests for a resource using db query, a query is fired to the database and the particular resource is fetched. In lazy loading, only the resources required at the moment are fetched and if in future more resources or entities are needed, then additional queries are fired into database. This significantly increases the number of queries fired whenever there is some loop construct in the code. This results into slow page load speed. As opposed to lazy loading, by using eager loading, we load additional required entities which we might require in near future, along with the main resource required by the query. Especially, during loops such as .each, eager loading significantly lowers the page load time, due to less queries fired resulting from additional data loaded from a single main resource query.

For instance, if we are firing a query to fetch all participants, and then loop through all the participants using .each to display their course name, then using eager loading, we can load all the course names for all participants in the same query in which all the participants are fetched from the database, as opposed to individual queries fired to access course names for individual participants in lazy loading.

==How 'includes' method helps in eager loading==

In Rails, 'includes' method specifies model associations to be included in the result set of the query being fired to the database.

For eg. current_user.participants.includes(:assignment, assignment: [:course]).each{|p| course_ids << p.assignment.course.id if p.assignment and p.assignment.course

What happened is Post.includes(:user) told ActiveRecord to retrieve the corresponding user records from the database immediately after the initial request for all posts. Since the records of users were already in the memory, post.user.username could be retrieved by only one query. Now, even if we have 10,000 posts in our database, we can execute the example code above by just 2 queries! This is a huge difference.

Here participants.includes(:assignment, assignment: [:course]) will retrieve all the assignment and course records relating to each participant using 2 queries(1 for participants, 1 for assignments and courses relating to participants), so that when each loop accesses the assignment and course for a participant using 'p.assignment.course' or 'p.assignment', no new query will be fired. Thus, reducing the number of queries using 'includes' method to 2 queries even if we have 1000 participants as compared to 2000 queries.

==How bullet gem helps in solving N+1 problem==

===How to use bullet gem in rails====

==Overview of changes we made during this project==

With the use of above mentioned bullet gem, we found the locations in the expertiza code, where eager loading needs to be implemented, by looking at the stack trace recorded in bullet.log file by bullet gem. Bullet gem locates these code locations, as we navigate throughout the website.

For this project, we targeted the following areas of expertiza, those which loads very slow and needs eager loading.

'''tree_display_controller'''
* Courses
* Assignments
* Questionnaires
* Users

'''grades_controller'''
* view (View scores)

'''review_mapping_controller'''
* list_mappings

'''reports_controller'''
* Review report
* Author-feedback report
* Teammate-review report
* Answer-tagging report

'''student_task_controller'''
* Impersonating a student

We navigated through the UI, that use the code in above mentioned controllers, during which bullet gem located the code locations in these files where eager loading has to be implemented using 'includes' method.

'''Files that are modified in this project'''

* tree_display_controller.rb
* feedback_response_map
* instructor.rb
* student_task.rb
* user.rb
* _feedback_report.html.erb
* _flash_notifications.html.erb
* development.rb

'''Code changes to resolve N+1 Problem in Expertiza'''

==Testing plan==

We aim to perform automatic and manual testing for this project in order to achieve better reliability for this implementation.

As for this project, very few lines of code have been modified in the above mentioned files and also as this is more of a refactoring project, automatic testing was done by checking whether the existing tests pass or not.

Manual testing was done by navigating the UI to the locations using the code from the files that were modified. All manual tests are passed.

==Important Links==

* [https://github.com/expertiza/expertiza/pull/1952 Github Pull Request]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2021_-_E2112._Integrate_Suggestion_Detection_Algorithm Expertiza wiki page link] (the link is mentioned here for records. It redirects to this same page.)
* [https://docs.google.com/document/d/1uzr5pybVKYr_K1Q8wSd4t-Id9nqTt3k1ePseDjY-RJg/edit#heading=h.fxfungdw1d5r Google Doc Project Description]
* [https://github.com/harshkachhadia/expertiza/tree/beta Github Repository Link for this expertiza fork] (make sure you change branch to 'beta' branch if the page doesn't load by default to beta branch)
* [https://youtu.be/OYZvNVa3GZ8 Youtube Video Link]

CSC/ECE 517 Spring 2021 - E2112. Integrate Suggestion Detection Algorithm

2021-05-01T02:59:20Z

Hmkachha: /* Important Links */

==Introduction==
=== Team ===
Dr. Gehringer (mentor),
John Bumgardner (mentor)
* Harsh Kachhadia (hmkachha)
* Parimal Mehta (pmehta3)
* Jatin Chinchkar (jchinch)
* Jordan Farthing (mjfarthi)

==Project Background==

Peer-review systems like Expertiza utilize a lot of students’ input to determine each other’s performance. At the same time, we hope students learn from the reviews they receive to improve their own performance. In order to make this happen, we would like to have everyone give quality reviews instead of generic ones. Currently we have a few classifiers that can detect useful features of review comments, such as whether they contain suggestions. The suggestion-detection algorithm has been coded as a web service, and other detection algorithms, such as problem detection and sentiment analysis, also exist as newer web services..but they need to be integrated properly using API calls in expertiza code.

=== Implementation Overview ===

Initially, we had planned to work on the work already done by the previous students [https://github.com/expertiza/expertiza/pull/1427 Spring 2019 pull request]. But later on we faced many issues such as: 1) The API call links were outdated 2) The new link that we found were incompatible with the previous work 3) The planned task of adding new API calls as per Carl Colglaizer's Framework turned out to be irrelevant or not required for this project, so we dropped it.

So we decided to start with integrating these API Calls from scratch.

'''Features we added in this project'''
* Setting up a config file 'review_metric.yml' where instructor can select what review metric to display for the current assignments
* Based on the selection made by professor, API calls(sentiment, problem, sugegstion) are made and a colorful table is displayed below the review form for student to review
* The total time taken for making these API calls will be displayed below the table.

'''Files that are modified or added in this project'''
* review_metrics.yml
* response.html.erb
* _response_analysis.html.erb
* response_controller.rb
* load_config.rb
* response_controller_spec.rb

'''Design Pattern'''

In order to achieve the primary tasks of integrating the API along with making the application more extensible, the team implemented a more extensive application of the '''Facade''' design pattern to decouple the details of the calling the APIs from the caller method (here - makeArequest method). This design pattern helped us achieve the decoupling and abstraction of implementation code base (makeARequest Function) of API call from the calling function (getReviewFeedback function). Later, refactoring of _response_analysis.html.erb partial further decoupled the implementation. Thus, in a nutshell, application of facade pattern along with some refactoring lead to a decoupled implementation of integration of all 3 API calls.

=== UI Screenshots===

* '''Frontend: '''This image shows the flow of control for a '''reviewer'''.
[[File:Steps_metric.png|800px]]

=== Control Flow ===

[[File:Review_metric.png]]

To inspect implementation in detail, check out the 'Javascript Functionality'

=== Javascript Functionality ===

In the partial view file _response_analysis.html.erb file, we added new javascript functions to make, process and display output of API calls.

* ''' review_metric.yml config file'''

In this file, the configuration for this functionality on which metrics to display in the table, can be set by the
instructor. Instructor can change which metric to display or not display in feedback by changing the value for that
particular metric as 'true' or 'false'.

[[File:Configfile.png|800px]]

* ''' response_controller.rb'''

In this file, we added a method 'fetch_review_metric' which fetches the configurations set by instructor in the review_metric.yml file by
the instructor and passes those fetched values to the response.html.erb view using the 'new' or 'edit' method.

[[File:Response_controller.png|800px]]

* ''' response.html.rb'''

Here, we added a line that renders the partial _response_analysis.html.erb after the Save button to show the 'get review feedback' button and
display the metrics table. Also, we fetch the passed configuration data here.

[[File:response_html.png|800px]]

* ''' _response_analysis.html.erb - fetch_response_comments() function'''

This function fetches the comments written by the user in the review form and formats the collected comments as per the expectation of the API
calls.

[[File:Fetchcomments.png|800px]]

* ''' _response_analysis.html.erb - getReviewFeedback() function'''

This function makes calls to respective APIs and get their output based on the configuration received from the review_metrics.yml file.

[[File:Makesapicalls.png|800px]]

* ''' _response_analysis.html.erb - makeARequest() function'''

This is the driver function for making API call request to any url and data that is passed to it.

[[File:Makearequest.png|800px]]

* ''' _response_analysis.html.erb - combine_api_output() function'''

This function combines the output received from different API responses, combines them and formats the combined data to one that is suitable for
table generation.

[[File:Combineapioutput.png|800px]]

* ''' _response_analysis.html.erb - generateTable() function'''

This code generates a colorful table dynamically on the UI so that the reviewer can get a visual feedback on the comments that he/she wrote.

[[File:Generatetable.png|800px]]

=== API Details/Endpoints Appendix I ===

Here are the various endpoints for the deployment of Suggestion Detection Algorithm.

(We can't make the API links unclickable for this design doc, but clicking on them won't lead you anywhere. They are just endpoints and are mentioned here for reference only.)

* http://152.7.99.200:5000/problem for problem metrics only
* https://peerlogic.csc.ncsu.edu/sentiment/analyze_reviews_bulk for sentiment metrics only
* http://152.7.99.200:5000/suggestions for suggestions metrics only

===API Action===

In order to make the API call, the partial view "_response_analysis.html.erb" is rendered in "response.html.erb" view file which will be responsible for sending a JSON input to the web service. The input will contain the review comment written by the user and when the student hits the "Get review feedback button" the comments will be sent to these api calls in the following json format:

Below is a sample input
'''Sample Input:'''

{"reviews" : [
{
"id" : 1,
"text" : "Comment 1."
},
{
"id" : 2,
"text" : "Comment 2."
}
]}

Once the request is sent, we expect the output to be in the following format:

'''Sample Output: (for sentiment analysis API call)'''
{"sentiments": [
{
"id": 1,
"neg": "0.00",
"neu": "0.95",
"pos": "0.05",
"sentiment": "0.11",
"text": "Comment 1."
},
{
"id": 2,
"neg": "0.00",
"neu": "0.95",
"pos": "0.05",
"sentiment": "0.11",
"text": "Comment 2."
}
]}

'''Sample Output: (for problem detection API call)'''
{"reviews": [
{
"id": 1,
"problems": "Present",
"text": "Comment 1."
},
{
"id": 2,
"problems": "Present",
"text": "Comment 2."
}
]}

'''Sample Output: (for suggestion detection API call)'''
{"reviews": [
{
"id": 1,
"suggestions": "Present",
"text": "Comment 1."
},
{
"id": 2,
"suggestions": "Present",
"text": "Comment 2."
}
]}

These outputs (which is a JSON) will be parsed and the concerned metrics such as the sentiment, problem and suggestion will be extracted so the user will be able to view a summarized result of how well their review comments are. In addition, the result will be presented in a colorful tabular format to the user after they hit the "Get Review Feedback" button. Also, the total time taken for making these API calls will be displayed below the table.

==Testing plan==
We aim to perform automatic and manual testing for this project in order to achieve better reliability for this implementation.

As for this project, very few lines of code have been written in ruby (fetch_review_metric method in response_controller.rb) we will be testing that method in response controller using rspec tests.

'''Rspec tests for the same have been written in response_controller_spec.rb'''

[[File:Rspectests.png|800px]]

===View Tests===
* The functionality was written on the client side in javascript solely in _response_analysis.html.erb
* To test this view, any type of review must be accessible as a student.
* There is a button at the bottom of the review called 'Get Review Feedback'.
* When pressing button, API calls are issued and the metrics will show up within the table (a sample of which is displayed below).
* API calls are slow and will take time to process until the 'Loading...' text disappears.
* You can modify the comments and click the 'Get Review Feedback' button again to get new feedback, that too can be achieved without the need of saving the review, but still saving the review first is a better option to approach this.
* All the review feedback for the comments will be displayed in a colorful table.

=== Sample image of the table ===

[[File:Metric_table.png]]

==Important Links==

* [https://github.com/expertiza/expertiza/pull/1952 Github Pull Request]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2021_-_E2112._Integrate_Suggestion_Detection_Algorithm Expertiza wiki page link] (the link is mentioned here for records. It redirects to this same page.)
* [https://docs.google.com/document/d/1uzr5pybVKYr_K1Q8wSd4t-Id9nqTt3k1ePseDjY-RJg/edit#heading=h.fxfungdw1d5r Google Doc Project Description]
* [https://github.com/harshkachhadia/expertiza/tree/beta Github Repository Link for this expertiza fork] (make sure you change branch to 'beta' branch if the page doesn't load by default to beta branch)
* [https://youtu.be/OYZvNVa3GZ8 Youtube Video Link]

CSC/ECE 517 Spring 2021 - E2112. Integrate Suggestion Detection Algorithm

2021-04-30T18:43:44Z

Hmkachha:

CSC/ECE 517 Spring 2021 - E2112. Integrate Suggestion Detection Algorithm

2021-04-30T18:42:17Z

Hmkachha: /* UI Screenshots */

==Introduction==
=== Team ===
Dr. Gehringer (mentor),
John Bumgardner (mentor)
* Harsh Kachhadia (hmkachha)
* Parimal Mehta (pmehta3)
* Jatin Chinchkar (jchinch)
* Jordan Farthing (mjfarthi)

==Project Background==

Peer-review systems like Expertiza utilize a lot of students’ input to determine each other’s performance. At the same time, we hope students learn from the reviews they receive to improve their own performance. In order to make this happen, we would like to have everyone give quality reviews instead of generic ones. Currently we have a few classifiers that can detect useful features of review comments, such as whether they contain suggestions. The suggestion-detection algorithm has been coded as a web service, and other detection algorithms, such as problem detection and sentiment analysis, also exist as newer web services..but they need to be integrated properly using API calls in expertiza code.

=== Implementation Overview ===

Initially, we had planned to work on the work already done by the previous students [https://github.com/expertiza/expertiza/pull/1427 Spring 2019 pull request]. But later on we faced many issues such as: 1) The API call links were outdated 2) The new link that we found were incompatible with the previous work 3) The planned task of adding new API calls as per Carl Colglaizer's Framework turned out to be irrelevant or not required for this project, so we dropped it.

So we decided to start with integrating these API Calls from scratch.

'''Features we added in this project'''
* Setting up a config file 'review_metric.yml' where instructor can select what review metric to display for the current assignments
* Based on the selection made by professor, API calls(sentiment, problem, sugegstion) are made and a colorful table is displayed below the review form for student to review
* The total time taken for making these API calls will be displayed below the table.

'''Files that are modified or added in this project'''
* review_metrics.yml
* response.html.erb
* _response_analysis.html.erb
* response_controller.rb
* load_config.rb
* response_controller_spec.rb

'''Design Pattern'''

In order to achieve the primary tasks of integrating the API along with making the application more extensible, the team implemented a more extensive application of the '''Facade''' design pattern to decouple the details of the calling the APIs from the caller method (here - makeArequest method). This design pattern helped us achieve the decoupling and abstraction of implementation code base (makeARequest Function) of API call from the calling function (getReviewFeedback function). Later, refactoring of _response_analysis.html.erb partial further decoupled the implementation. Thus, in a nutshell, application of facade pattern along with some refactoring lead to a decoupled implementation of integration of all 3 API calls.

=== Control Flow ===

[[File:Review_metric.png]]

=== UI Screenshots===

* '''Frontend: '''This image shows the flow of control for a '''reviewer'''.
[[File:Steps_metric.png|800px]]

To inspect implementation in detail, check out the 'Javascript Functionality'

=== Javascript Functionality ===

In the partial view file _response_analysis.html.erb file, we added new javascript functions to make, process and display output of API calls.

* ''' review_metric.yml config file'''

In this file, the configuration for this functionality on which metrics to display in the table, can be set by the
instructor. Instructor can change which metric to display or not display in feedback by changing the value for that
particular metric as 'true' or 'false'.

[[File:Configfile.png|800px]]

* ''' response_controller.rb'''

In this file, we added a method 'fetch_review_metric' which fetches the configurations set by instructor in the review_metric.yml file by
the instructor and passes those fetched values to the response.html.erb view using the 'new' or 'edit' method.

[[File:Response_controller.png|800px]]

* ''' response.html.rb'''

Here, we added a line that renders the partial _response_analysis.html.erb after the Save button to show the 'get review feedback' button and
display the metrics table. Also, we fetch the passed configuration data here.

[[File:response_html.png|800px]]

* ''' _response_analysis.html.erb - fetch_response_comments() function'''

This function fetches the comments written by the user in the review form and formats the collected comments as per the expectation of the API
calls.

[[File:Fetchcomments.png|800px]]

* ''' _response_analysis.html.erb - getReviewFeedback() function'''

This function makes calls to respective APIs and get their output based on the configuration received from the review_metrics.yml file.

[[File:Makesapicalls.png|800px]]

* ''' _response_analysis.html.erb - makeARequest() function'''

This is the driver function for making API call request to any url and data that is passed to it.

[[File:Makearequest.png|800px]]

* ''' _response_analysis.html.erb - combine_api_output() function'''

This function combines the output received from different API responses, combines them and formats the combined data to one that is suitable for
table generation.

[[File:Combineapioutput.png|800px]]

* ''' _response_analysis.html.erb - generateTable() function'''

This code generates a colorful table dynamically on the UI so that the reviewer can get a visual feedback on the comments that he/she wrote.

[[File:Generatetable.png|800px]]

=== API Details/Endpoints Appendix I ===

Here are the various endpoints for the deployment of Suggestion Detection Algorithm.

(We can't make the API links unclickable for this design doc, but clicking on them won't lead you anywhere. They are just endpoints and are mentioned here for reference only.)

* http://152.7.99.200:5000/problem for problem metrics only
* https://peerlogic.csc.ncsu.edu/sentiment/analyze_reviews_bulk for sentiment metrics only
* http://152.7.99.200:5000/suggestions for suggestions metrics only

===API Action===

In order to make the API call, the partial view "_response_analysis.html.erb" is rendered in "response.html.erb" view file which will be responsible for sending a JSON input to the web service. The input will contain the review comment written by the user and when the student hits the "Get review feedback button" the comments will be sent to these api calls in the following json format:

Below is a sample input
'''Sample Input:'''

{"reviews" : [
{
"id" : 1,
"text" : "Comment 1."
},
{
"id" : 2,
"text" : "Comment 2."
}
]}

Once the request is sent, we expect the output to be in the following format:

'''Sample Output: (for sentiment analysis API call)'''
{"sentiments": [
{
"id": 1,
"neg": "0.00",
"neu": "0.95",
"pos": "0.05",
"sentiment": "0.11",
"text": "Comment 1."
},
{
"id": 2,
"neg": "0.00",
"neu": "0.95",
"pos": "0.05",
"sentiment": "0.11",
"text": "Comment 2."
}
]}

'''Sample Output: (for problem detection API call)'''
{"reviews": [
{
"id": 1,
"problems": "Present",
"text": "Comment 1."
},
{
"id": 2,
"problems": "Present",
"text": "Comment 2."
}
]}

'''Sample Output: (for suggestion detection API call)'''
{"reviews": [
{
"id": 1,
"suggestions": "Present",
"text": "Comment 1."
},
{
"id": 2,
"suggestions": "Present",
"text": "Comment 2."
}
]}

These outputs (which is a JSON) will be parsed and the concerned metrics such as the sentiment, problem and suggestion will be extracted so the user will be able to view a summarized result of how well their review comments are. In addition, the result will be presented in a colorful tabular format to the user after they hit the "Get Review Feedback" button. Also, the total time taken for making these API calls will be displayed below the table.

==Testing plan==
We aim to perform automatic and manual testing for this project in order to achieve better reliability for this implementation.

As for this project, very few lines of code have been written in ruby (fetch_review_metric method in response_controller.rb) we will be testing that method in response controller using rspec tests.

'''Rspec tests for the same have been written in response_controller_spec.rb'''

[[File:Rspectests.png|800px]]

===View Tests===
* The functionality was written on the client side in javascript solely in _response_analysis.html.erb
* To test this view, any type of review must be accessible as a student.
* There is a button at the bottom of the review called 'Get Review Feedback'.
* When pressing button, API calls are issued and the metrics will show up within the table (a sample of which is displayed below).
* API calls are slow and will take time to process until the 'Loading...' text disappears.
* You can modify the comments and click the 'Get Review Feedback' button again to get new feedback, that too can be achieved without the need of saving the review, but still saving the review first is a better option to approach this.
* All the review feedback for the comments will be displayed in a colorful table.

=== Sample image of the table ===

[[File:Metric_table.png]]

==Important Links==

* [https://github.com/expertiza/expertiza/pull/1952 Github Pull Request]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2021_-_E2112._Integrate_Suggestion_Detection_Algorithm Expertiza wiki page link] (the link is mentioned here for records. It redirects to this same page.)
* [https://docs.google.com/document/d/1uzr5pybVKYr_K1Q8wSd4t-Id9nqTt3k1ePseDjY-RJg/edit#heading=h.fxfungdw1d5r Google Doc Project Description]
* [https://github.com/harshkachhadia/expertiza/tree/beta Github Repository Link for this expertiza fork] (make sure you change branch to 'beta' branch if the page doesn't load by default to beta branch)

CSC/ECE 517 Spring 2021 - E2112. Integrate Suggestion Detection Algorithm

2021-04-30T18:41:55Z

Hmkachha: /* Sample UI Screenshots that will be worked upon */

==Introduction==
=== Team ===
Dr. Gehringer (mentor),
John Bumgardner (mentor)
* Harsh Kachhadia (hmkachha)
* Parimal Mehta (pmehta3)
* Jatin Chinchkar (jchinch)
* Jordan Farthing (mjfarthi)

==Project Background==

Peer-review systems like Expertiza utilize a lot of students’ input to determine each other’s performance. At the same time, we hope students learn from the reviews they receive to improve their own performance. In order to make this happen, we would like to have everyone give quality reviews instead of generic ones. Currently we have a few classifiers that can detect useful features of review comments, such as whether they contain suggestions. The suggestion-detection algorithm has been coded as a web service, and other detection algorithms, such as problem detection and sentiment analysis, also exist as newer web services..but they need to be integrated properly using API calls in expertiza code.

=== Implementation Overview ===

Initially, we had planned to work on the work already done by the previous students [https://github.com/expertiza/expertiza/pull/1427 Spring 2019 pull request]. But later on we faced many issues such as: 1) The API call links were outdated 2) The new link that we found were incompatible with the previous work 3) The planned task of adding new API calls as per Carl Colglaizer's Framework turned out to be irrelevant or not required for this project, so we dropped it.

So we decided to start with integrating these API Calls from scratch.

'''Features we added in this project'''
* Setting up a config file 'review_metric.yml' where instructor can select what review metric to display for the current assignments
* Based on the selection made by professor, API calls(sentiment, problem, sugegstion) are made and a colorful table is displayed below the review form for student to review
* The total time taken for making these API calls will be displayed below the table.

'''Files that are modified or added in this project'''
* review_metrics.yml
* response.html.erb
* _response_analysis.html.erb
* response_controller.rb
* load_config.rb
* response_controller_spec.rb

'''Design Pattern'''

In order to achieve the primary tasks of integrating the API along with making the application more extensible, the team implemented a more extensive application of the '''Facade''' design pattern to decouple the details of the calling the APIs from the caller method (here - makeArequest method). This design pattern helped us achieve the decoupling and abstraction of implementation code base (makeARequest Function) of API call from the calling function (getReviewFeedback function). Later, refactoring of _response_analysis.html.erb partial further decoupled the implementation. Thus, in a nutshell, application of facade pattern along with some refactoring lead to a decoupled implementation of integration of all 3 API calls.

=== Control Flow ===

[[File:Review_metric.png]]

=== UI Screenshots===

* '''Frontend: '''This image shows the flow of control for a '''reviewer'''.
[[File:Steps_metric.png]]

To inspect implementation in detail, check out the 'Javascript Functionality'

=== Javascript Functionality ===

In the partial view file _response_analysis.html.erb file, we added new javascript functions to make, process and display output of API calls.

* ''' review_metric.yml config file'''

In this file, the configuration for this functionality on which metrics to display in the table, can be set by the
instructor. Instructor can change which metric to display or not display in feedback by changing the value for that
particular metric as 'true' or 'false'.

[[File:Configfile.png|800px]]

* ''' response_controller.rb'''

In this file, we added a method 'fetch_review_metric' which fetches the configurations set by instructor in the review_metric.yml file by
the instructor and passes those fetched values to the response.html.erb view using the 'new' or 'edit' method.

[[File:Response_controller.png|800px]]

* ''' response.html.rb'''

Here, we added a line that renders the partial _response_analysis.html.erb after the Save button to show the 'get review feedback' button and
display the metrics table. Also, we fetch the passed configuration data here.

[[File:response_html.png|800px]]

* ''' _response_analysis.html.erb - fetch_response_comments() function'''

This function fetches the comments written by the user in the review form and formats the collected comments as per the expectation of the API
calls.

[[File:Fetchcomments.png|800px]]

* ''' _response_analysis.html.erb - getReviewFeedback() function'''

This function makes calls to respective APIs and get their output based on the configuration received from the review_metrics.yml file.

[[File:Makesapicalls.png|800px]]

* ''' _response_analysis.html.erb - makeARequest() function'''

This is the driver function for making API call request to any url and data that is passed to it.

[[File:Makearequest.png|800px]]

* ''' _response_analysis.html.erb - combine_api_output() function'''

This function combines the output received from different API responses, combines them and formats the combined data to one that is suitable for
table generation.

[[File:Combineapioutput.png|800px]]

* ''' _response_analysis.html.erb - generateTable() function'''

This code generates a colorful table dynamically on the UI so that the reviewer can get a visual feedback on the comments that he/she wrote.

[[File:Generatetable.png|800px]]

=== API Details/Endpoints Appendix I ===

Here are the various endpoints for the deployment of Suggestion Detection Algorithm.

(We can't make the API links unclickable for this design doc, but clicking on them won't lead you anywhere. They are just endpoints and are mentioned here for reference only.)

* http://152.7.99.200:5000/problem for problem metrics only
* https://peerlogic.csc.ncsu.edu/sentiment/analyze_reviews_bulk for sentiment metrics only
* http://152.7.99.200:5000/suggestions for suggestions metrics only

===API Action===

In order to make the API call, the partial view "_response_analysis.html.erb" is rendered in "response.html.erb" view file which will be responsible for sending a JSON input to the web service. The input will contain the review comment written by the user and when the student hits the "Get review feedback button" the comments will be sent to these api calls in the following json format:

Below is a sample input
'''Sample Input:'''

{"reviews" : [
{
"id" : 1,
"text" : "Comment 1."
},
{
"id" : 2,
"text" : "Comment 2."
}
]}

Once the request is sent, we expect the output to be in the following format:

'''Sample Output: (for sentiment analysis API call)'''
{"sentiments": [
{
"id": 1,
"neg": "0.00",
"neu": "0.95",
"pos": "0.05",
"sentiment": "0.11",
"text": "Comment 1."
},
{
"id": 2,
"neg": "0.00",
"neu": "0.95",
"pos": "0.05",
"sentiment": "0.11",
"text": "Comment 2."
}
]}

'''Sample Output: (for problem detection API call)'''
{"reviews": [
{
"id": 1,
"problems": "Present",
"text": "Comment 1."
},
{
"id": 2,
"problems": "Present",
"text": "Comment 2."
}
]}

'''Sample Output: (for suggestion detection API call)'''
{"reviews": [
{
"id": 1,
"suggestions": "Present",
"text": "Comment 1."
},
{
"id": 2,
"suggestions": "Present",
"text": "Comment 2."
}
]}

These outputs (which is a JSON) will be parsed and the concerned metrics such as the sentiment, problem and suggestion will be extracted so the user will be able to view a summarized result of how well their review comments are. In addition, the result will be presented in a colorful tabular format to the user after they hit the "Get Review Feedback" button. Also, the total time taken for making these API calls will be displayed below the table.

==Testing plan==
We aim to perform automatic and manual testing for this project in order to achieve better reliability for this implementation.

As for this project, very few lines of code have been written in ruby (fetch_review_metric method in response_controller.rb) we will be testing that method in response controller using rspec tests.

'''Rspec tests for the same have been written in response_controller_spec.rb'''

[[File:Rspectests.png|800px]]

===View Tests===
* The functionality was written on the client side in javascript solely in _response_analysis.html.erb
* To test this view, any type of review must be accessible as a student.
* There is a button at the bottom of the review called 'Get Review Feedback'.
* When pressing button, API calls are issued and the metrics will show up within the table (a sample of which is displayed below).
* API calls are slow and will take time to process until the 'Loading...' text disappears.
* You can modify the comments and click the 'Get Review Feedback' button again to get new feedback, that too can be achieved without the need of saving the review, but still saving the review first is a better option to approach this.
* All the review feedback for the comments will be displayed in a colorful table.

=== Sample image of the table ===

[[File:Metric_table.png]]

==Important Links==

* [https://github.com/expertiza/expertiza/pull/1952 Github Pull Request]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2021_-_E2112._Integrate_Suggestion_Detection_Algorithm Expertiza wiki page link] (the link is mentioned here for records. It redirects to this same page.)
* [https://docs.google.com/document/d/1uzr5pybVKYr_K1Q8wSd4t-Id9nqTt3k1ePseDjY-RJg/edit#heading=h.fxfungdw1d5r Google Doc Project Description]
* [https://github.com/harshkachhadia/expertiza/tree/beta Github Repository Link for this expertiza fork] (make sure you change branch to 'beta' branch if the page doesn't load by default to beta branch)

File:Steps metric.png

2021-04-30T18:40:27Z

Hmkachha:

CSC/ECE 517 Spring 2021 - E2112. Integrate Suggestion Detection Algorithm

2021-04-30T18:40:02Z

Hmkachha:

==Introduction==
=== Team ===
Dr. Gehringer (mentor),
John Bumgardner (mentor)
* Harsh Kachhadia (hmkachha)
* Parimal Mehta (pmehta3)
* Jatin Chinchkar (jchinch)
* Jordan Farthing (mjfarthi)

==Project Background==

Peer-review systems like Expertiza utilize a lot of students’ input to determine each other’s performance. At the same time, we hope students learn from the reviews they receive to improve their own performance. In order to make this happen, we would like to have everyone give quality reviews instead of generic ones. Currently we have a few classifiers that can detect useful features of review comments, such as whether they contain suggestions. The suggestion-detection algorithm has been coded as a web service, and other detection algorithms, such as problem detection and sentiment analysis, also exist as newer web services..but they need to be integrated properly using API calls in expertiza code.

=== Implementation Overview ===

Initially, we had planned to work on the work already done by the previous students [https://github.com/expertiza/expertiza/pull/1427 Spring 2019 pull request]. But later on we faced many issues such as: 1) The API call links were outdated 2) The new link that we found were incompatible with the previous work 3) The planned task of adding new API calls as per Carl Colglaizer's Framework turned out to be irrelevant or not required for this project, so we dropped it.

So we decided to start with integrating these API Calls from scratch.

'''Features we added in this project'''
* Setting up a config file 'review_metric.yml' where instructor can select what review metric to display for the current assignments
* Based on the selection made by professor, API calls(sentiment, problem, sugegstion) are made and a colorful table is displayed below the review form for student to review
* The total time taken for making these API calls will be displayed below the table.

'''Files that are modified or added in this project'''
* review_metrics.yml
* response.html.erb
* _response_analysis.html.erb
* response_controller.rb
* load_config.rb
* response_controller_spec.rb

'''Design Pattern'''

In order to achieve the primary tasks of integrating the API along with making the application more extensible, the team implemented a more extensive application of the '''Facade''' design pattern to decouple the details of the calling the APIs from the caller method (here - makeArequest method). This design pattern helped us achieve the decoupling and abstraction of implementation code base (makeARequest Function) of API call from the calling function (getReviewFeedback function). Later, refactoring of _response_analysis.html.erb partial further decoupled the implementation. Thus, in a nutshell, application of facade pattern along with some refactoring lead to a decoupled implementation of integration of all 3 API calls.

=== Control Flow ===

[[File:Review_metric.png]]

=== Sample UI Screenshots that will be worked upon ===

* '''Frontend: '''This image shows the flow of control for a '''reviewer'''.
[[File:Steps_metric.png]]

To inspect implementation in detail, check out the 'Javascript Functionality'

=== Javascript Functionality ===

In the partial view file _response_analysis.html.erb file, we added new javascript functions to make, process and display output of API calls.

* ''' review_metric.yml config file'''

In this file, the configuration for this functionality on which metrics to display in the table, can be set by the
instructor. Instructor can change which metric to display or not display in feedback by changing the value for that
particular metric as 'true' or 'false'.

[[File:Configfile.png|800px]]

* ''' response_controller.rb'''

In this file, we added a method 'fetch_review_metric' which fetches the configurations set by instructor in the review_metric.yml file by
the instructor and passes those fetched values to the response.html.erb view using the 'new' or 'edit' method.

[[File:Response_controller.png|800px]]

* ''' response.html.rb'''

Here, we added a line that renders the partial _response_analysis.html.erb after the Save button to show the 'get review feedback' button and
display the metrics table. Also, we fetch the passed configuration data here.

[[File:response_html.png|800px]]

* ''' _response_analysis.html.erb - fetch_response_comments() function'''

This function fetches the comments written by the user in the review form and formats the collected comments as per the expectation of the API
calls.

[[File:Fetchcomments.png|800px]]

* ''' _response_analysis.html.erb - getReviewFeedback() function'''

This function makes calls to respective APIs and get their output based on the configuration received from the review_metrics.yml file.

[[File:Makesapicalls.png|800px]]

* ''' _response_analysis.html.erb - makeARequest() function'''

This is the driver function for making API call request to any url and data that is passed to it.

[[File:Makearequest.png|800px]]

* ''' _response_analysis.html.erb - combine_api_output() function'''

This function combines the output received from different API responses, combines them and formats the combined data to one that is suitable for
table generation.

[[File:Combineapioutput.png|800px]]

* ''' _response_analysis.html.erb - generateTable() function'''

This code generates a colorful table dynamically on the UI so that the reviewer can get a visual feedback on the comments that he/she wrote.

[[File:Generatetable.png|800px]]

=== API Details/Endpoints Appendix I ===

Here are the various endpoints for the deployment of Suggestion Detection Algorithm.

(We can't make the API links unclickable for this design doc, but clicking on them won't lead you anywhere. They are just endpoints and are mentioned here for reference only.)

* http://152.7.99.200:5000/problem for problem metrics only
* https://peerlogic.csc.ncsu.edu/sentiment/analyze_reviews_bulk for sentiment metrics only
* http://152.7.99.200:5000/suggestions for suggestions metrics only

===API Action===

In order to make the API call, the partial view "_response_analysis.html.erb" is rendered in "response.html.erb" view file which will be responsible for sending a JSON input to the web service. The input will contain the review comment written by the user and when the student hits the "Get review feedback button" the comments will be sent to these api calls in the following json format:

Below is a sample input
'''Sample Input:'''

{"reviews" : [
{
"id" : 1,
"text" : "Comment 1."
},
{
"id" : 2,
"text" : "Comment 2."
}
]}

Once the request is sent, we expect the output to be in the following format:

'''Sample Output: (for sentiment analysis API call)'''
{"sentiments": [
{
"id": 1,
"neg": "0.00",
"neu": "0.95",
"pos": "0.05",
"sentiment": "0.11",
"text": "Comment 1."
},
{
"id": 2,
"neg": "0.00",
"neu": "0.95",
"pos": "0.05",
"sentiment": "0.11",
"text": "Comment 2."
}
]}

'''Sample Output: (for problem detection API call)'''
{"reviews": [
{
"id": 1,
"problems": "Present",
"text": "Comment 1."
},
{
"id": 2,
"problems": "Present",
"text": "Comment 2."
}
]}

'''Sample Output: (for suggestion detection API call)'''
{"reviews": [
{
"id": 1,
"suggestions": "Present",
"text": "Comment 1."
},
{
"id": 2,
"suggestions": "Present",
"text": "Comment 2."
}
]}

These outputs (which is a JSON) will be parsed and the concerned metrics such as the sentiment, problem and suggestion will be extracted so the user will be able to view a summarized result of how well their review comments are. In addition, the result will be presented in a colorful tabular format to the user after they hit the "Get Review Feedback" button. Also, the total time taken for making these API calls will be displayed below the table.

==Testing plan==
We aim to perform automatic and manual testing for this project in order to achieve better reliability for this implementation.

As for this project, very few lines of code have been written in ruby (fetch_review_metric method in response_controller.rb) we will be testing that method in response controller using rspec tests.

'''Rspec tests for the same have been written in response_controller_spec.rb'''

[[File:Rspectests.png|800px]]

===View Tests===
* The functionality was written on the client side in javascript solely in _response_analysis.html.erb
* To test this view, any type of review must be accessible as a student.
* There is a button at the bottom of the review called 'Get Review Feedback'.
* When pressing button, API calls are issued and the metrics will show up within the table (a sample of which is displayed below).
* API calls are slow and will take time to process until the 'Loading...' text disappears.
* You can modify the comments and click the 'Get Review Feedback' button again to get new feedback, that too can be achieved without the need of saving the review, but still saving the review first is a better option to approach this.
* All the review feedback for the comments will be displayed in a colorful table.

=== Sample image of the table ===

[[File:Metric_table.png]]

==Important Links==

* [https://github.com/expertiza/expertiza/pull/1952 Github Pull Request]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2021_-_E2112._Integrate_Suggestion_Detection_Algorithm Expertiza wiki page link] (the link is mentioned here for records. It redirects to this same page.)
* [https://docs.google.com/document/d/1uzr5pybVKYr_K1Q8wSd4t-Id9nqTt3k1ePseDjY-RJg/edit#heading=h.fxfungdw1d5r Google Doc Project Description]
* [https://github.com/harshkachhadia/expertiza/tree/beta Github Repository Link for this expertiza fork] (make sure you change branch to 'beta' branch if the page doesn't load by default to beta branch)

CSC/ECE 517 Spring 2021 - E2112. Integrate Suggestion Detection Algorithm

2021-04-30T17:49:18Z

Hmkachha: /* Implementation Overview */

==Introduction==
=== Team ===
Dr. Gehringer (mentor),
John Bumgardner (mentor)
* Harsh Kachhadia (hmkachha)
* Parimal Mehta (pmehta3)
* Jatin Chinchkar (jchinch)
* Jordan Farthing (mjfarthi)

==Project Background==

Peer-review systems like Expertiza utilize a lot of students’ input to determine each other’s performance. At the same time, we hope students learn from the reviews they receive to improve their own performance. In order to make this happen, we would like to have everyone give quality reviews instead of generic ones. Currently we have a few classifiers that can detect useful features of review comments, such as whether they contain suggestions. The suggestion-detection algorithm has been coded as a web service, and other detection algorithms, such as problem detection and sentiment analysis, also exist as newer web services..but they need to be integrated properly using API calls in expertiza code.

=== Implementation Overview ===

Initially, we had planned to work on the work already done by the previous students [https://github.com/expertiza/expertiza/pull/1427 Spring 2019 pull request]. But later on we faced many issues such as: 1) The API call links were outdated 2) The new link that we found were incompatible with the previous work 3) The planned task of adding new API calls as per Carl Colglaizer's Framework turned out to be irrelevant or not required for this project, so we dropped it.

So we decided to start with integrating these API Calls from scratch.

'''Features we added in this project'''
* Setting up a config file 'review_metric.yml' where instructor can select what review metric to display for the current assignments
* Based on the selection made by professor, API calls(sentiment, problem, sugegstion) are made and a colorful table is displayed below the review form for student to review
* The total time taken for making these API calls will be displayed below the table.

'''Files that are modified or added in this project'''
* review_metrics.yml
* response.html.erb
* _response_analysis.html.erb
* response_controller.rb
* load_config.rb
* response_controller_spec.rb

'''Design Pattern'''

In order to achieve the primary tasks of integrating the API along with making the application more extensible, the team implemented a more extensive application of the '''Facade''' design pattern to decouple the details of the calling the APIs from the caller method (here - makeArequest method). This design pattern helped us achieve the decoupling and abstraction of implementation code base (makeARequest Function) of API call from the calling function (getReviewFeedback function). Later, refactoring of _response_analysis.html.erb partial further decoupled the implementation. Thus, in a nutshell, application of facade pattern along with some refactoring lead to a decoupled implementation of integration of all 3 API calls.

=== Control Flow ===

[[File:Review_metric.png]]

To inspect implementation in detail, check out the 'Javascript Functionality'

=== Javascript Functionality ===

In the partial view file _response_analysis.html.erb file, we added new javascript functions to make, process and display output of API calls.

* ''' review_metric.yml config file'''

In this file, the configuration for this functionality on which metrics to display in the table, can be set by the
instructor. Instructor can change which metric to display or not display in feedback by changing the value for that
particular metric as 'true' or 'false'.

[[File:Configfile.png|800px]]

* ''' response_controller.rb'''

In this file, we added a method 'fetch_review_metric' which fetches the configurations set by instructor in the review_metric.yml file by
the instructor and passes those fetched values to the response.html.erb view using the 'new' or 'edit' method.

[[File:Response_controller.png|800px]]

* ''' response.html.rb'''

Here, we added a line that renders the partial _response_analysis.html.erb after the Save button to show the 'get review feedback' button and
display the metrics table. Also, we fetch the passed configuration data here.

[[File:response_html.png|800px]]

* ''' _response_analysis.html.erb - fetch_response_comments() function'''

This function fetches the comments written by the user in the review form and formats the collected comments as per the expectation of the API
calls.

[[File:Fetchcomments.png|800px]]

* ''' _response_analysis.html.erb - getReviewFeedback() function'''

This function makes calls to respective APIs and get their output based on the configuration received from the review_metrics.yml file.

[[File:Makesapicalls.png|800px]]

* ''' _response_analysis.html.erb - makeARequest() function'''

This is the driver function for making API call request to any url and data that is passed to it.

[[File:Makearequest.png|800px]]

* ''' _response_analysis.html.erb - combine_api_output() function'''

This function combines the output received from different API responses, combines them and formats the combined data to one that is suitable for
table generation.

[[File:Combineapioutput.png|800px]]

* ''' _response_analysis.html.erb - generateTable() function'''

This code generates a colorful table dynamically on the UI so that the reviewer can get a visual feedback on the comments that he/she wrote.

[[File:Generatetable.png|800px]]

=== API Details/Endpoints Appendix I ===

Here are the various endpoints for the deployment of Suggestion Detection Algorithm.

(We can't make the API links unclickable for this design doc, but clicking on them won't lead you anywhere. They are just endpoints and are mentioned here for reference only.)

* http://152.7.99.200:5000/problem for problem metrics only
* https://peerlogic.csc.ncsu.edu/sentiment/analyze_reviews_bulk for sentiment metrics only
* http://152.7.99.200:5000/suggestions for suggestions metrics only

===API Action===

In order to make the API call, the partial view "_response_analysis.html.erb" is rendered in "response.html.erb" view file which will be responsible for sending a JSON input to the web service. The input will contain the review comment written by the user and when the student hits the "Get review feedback button" the comments will be sent to these api calls in the following json format:

Below is a sample input
'''Sample Input:'''

{"reviews" : [
{
"id" : 1,
"text" : "Comment 1."
},
{
"id" : 2,
"text" : "Comment 2."
}
]}

Once the request is sent, we expect the output to be in the following format:

'''Sample Output: (for sentiment analysis API call)'''
{"sentiments": [
{
"id": 1,
"neg": "0.00",
"neu": "0.95",
"pos": "0.05",
"sentiment": "0.11",
"text": "Comment 1."
},
{
"id": 2,
"neg": "0.00",
"neu": "0.95",
"pos": "0.05",
"sentiment": "0.11",
"text": "Comment 2."
}
]}

'''Sample Output: (for problem detection API call)'''
{"reviews": [
{
"id": 1,
"problems": "Present",
"text": "Comment 1."
},
{
"id": 2,
"problems": "Present",
"text": "Comment 2."
}
]}

'''Sample Output: (for suggestion detection API call)'''
{"reviews": [
{
"id": 1,
"suggestions": "Present",
"text": "Comment 1."
},
{
"id": 2,
"suggestions": "Present",
"text": "Comment 2."
}
]}

These outputs (which is a JSON) will be parsed and the concerned metrics such as the sentiment, problem and suggestion will be extracted so the user will be able to view a summarized result of how well their review comments are. In addition, the result will be presented in a colorful tabular format to the user after they hit the "Get Review Feedback" button. Also, the total time taken for making these API calls will be displayed below the table.

==Testing plan==
We aim to perform automatic and manual testing for this project in order to achieve better reliability for this implementation.

As for this project, very few lines of code have been written in ruby (fetch_review_metric method in response_controller.rb) we will be testing that method in response controller using rspec tests.

'''Rspec tests for the same have been written in response_controller_spec.rb'''

[[File:Rspectests.png|800px]]

===View Tests===
* The functionality was written on the client side in javascript solely in _response_analysis.html.erb
* To test this view, any type of review must be accessible as a student.
* There is a button at the bottom of the review called 'Get Review Feedback'.
* When pressing button, API calls are issued and the metrics will show up within the table (a sample of which is displayed below).
* API calls are slow and will take time to process until the 'Loading...' text disappears.
* You can modify the comments and click the 'Get Review Feedback' button again to get new feedback, that too can be achieved without the need of saving the review, but still saving the review first is a better option to approach this.
* All the review feedback for the comments will be displayed in a colorful table.

=== Sample image of the table ===

[[File:Metric_table.png]]

==Important Links==

* [https://github.com/expertiza/expertiza/pull/1952 Github Pull Request]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2021_-_E2112._Integrate_Suggestion_Detection_Algorithm Expertiza wiki page link] (the link is mentioned here for records. It redirects to this same page.)
* [https://docs.google.com/document/d/1uzr5pybVKYr_K1Q8wSd4t-Id9nqTt3k1ePseDjY-RJg/edit#heading=h.fxfungdw1d5r Google Doc Project Description]
* [https://github.com/harshkachhadia/expertiza/tree/beta Github Repository Link for this expertiza fork] (make sure you change branch to 'beta' branch if the page doesn't load by default to beta branch)

CSC/ECE 517 Spring 2021 - E2112. Integrate Suggestion Detection Algorithm

2021-04-30T17:31:17Z

Hmkachha:

==Introduction==
=== Team ===
Dr. Gehringer (mentor),
John Bumgardner (mentor)
* Harsh Kachhadia (hmkachha)
* Parimal Mehta (pmehta3)
* Jatin Chinchkar (jchinch)
* Jordan Farthing (mjfarthi)

==Project Background==

Peer-review systems like Expertiza utilize a lot of students’ input to determine each other’s performance. At the same time, we hope students learn from the reviews they receive to improve their own performance. In order to make this happen, we would like to have everyone give quality reviews instead of generic ones. Currently we have a few classifiers that can detect useful features of review comments, such as whether they contain suggestions. The suggestion-detection algorithm has been coded as a web service, and other detection algorithms, such as problem detection and sentiment analysis, also exist as newer web services..but they need to be integrated properly using API calls in expertiza code.

=== Implementation Overview ===

Initially, we had planned to work on the work already done by the previous students [https://github.com/expertiza/expertiza/pull/1427 Spring 2019 pull request]. But later on we faced many issues such as: 1) The API call links were outdated 2) The new link that we found were incompatible with the previous work 3) The planned task of adding new API calls as per Carl Colglaizer's Framework turned out to be irrelevant or not required for this project, so we dropped it.

So we decided to start with integrating these API Calls from scratch.

'''Features we added in this project'''
* Setting up a config file 'review_metric.yml' where instructor can select what review metric to display for the current assignments
* Based on the selection made by professor, API calls(sentiment, problem, sugegstion) are made and a colorful table is displayed below the review form for student to review
* The total time taken for making these API calls will be displayed below the table.

'''Files that are modified or added in this project'''
* review_metrics.yml
* response.html.erb
* _response_analysis.html.erb
* response_controller.rb
* load_config.rb
* response_controller_spec.rb

=== Control Flow ===

[[File:Review_metric.png]]

To inspect implementation in detail, check out the 'Javascript Functionality'

=== Javascript Functionality ===

In the partial view file _response_analysis.html.erb file, we added new javascript functions to make, process and display output of API calls.

* ''' review_metric.yml config file'''

In this file, the configuration for this functionality on which metrics to display in the table, can be set by the
instructor. Instructor can change which metric to display or not display in feedback by changing the value for that
particular metric as 'true' or 'false'.

[[File:Configfile.png|800px]]

* ''' response_controller.rb'''

In this file, we added a method 'fetch_review_metric' which fetches the configurations set by instructor in the review_metric.yml file by
the instructor and passes those fetched values to the response.html.erb view using the 'new' or 'edit' method.

[[File:Response_controller.png|800px]]

* ''' response.html.rb'''

Here, we added a line that renders the partial _response_analysis.html.erb after the Save button to show the 'get review feedback' button and
display the metrics table. Also, we fetch the passed configuration data here.

[[File:response_html.png|800px]]

* ''' _response_analysis.html.erb - fetch_response_comments() function'''

This function fetches the comments written by the user in the review form and formats the collected comments as per the expectation of the API
calls.

[[File:Fetchcomments.png|800px]]

* ''' _response_analysis.html.erb - getReviewFeedback() function'''

This function makes calls to respective APIs and get their output based on the configuration received from the review_metrics.yml file.

[[File:Makesapicalls.png|800px]]

* ''' _response_analysis.html.erb - makeARequest() function'''

This is the driver function for making API call request to any url and data that is passed to it.

[[File:Makearequest.png|800px]]

* ''' _response_analysis.html.erb - combine_api_output() function'''

This function combines the output received from different API responses, combines them and formats the combined data to one that is suitable for
table generation.

[[File:Combineapioutput.png|800px]]

* ''' _response_analysis.html.erb - generateTable() function'''

This code generates a colorful table dynamically on the UI so that the reviewer can get a visual feedback on the comments that he/she wrote.

[[File:Generatetable.png|800px]]

=== API Details/Endpoints Appendix I ===

Here are the various endpoints for the deployment of Suggestion Detection Algorithm.

(We can't make the API links unclickable for this design doc, but clicking on them won't lead you anywhere. They are just endpoints and are mentioned here for reference only.)

* http://152.7.99.200:5000/problem for problem metrics only
* https://peerlogic.csc.ncsu.edu/sentiment/analyze_reviews_bulk for sentiment metrics only
* http://152.7.99.200:5000/suggestions for suggestions metrics only

===API Action===

In order to make the API call, the partial view "_response_analysis.html.erb" is rendered in "response.html.erb" view file which will be responsible for sending a JSON input to the web service. The input will contain the review comment written by the user and when the student hits the "Get review feedback button" the comments will be sent to these api calls in the following json format:

Below is a sample input
'''Sample Input:'''

{"reviews" : [
{
"id" : 1,
"text" : "Comment 1."
},
{
"id" : 2,
"text" : "Comment 2."
}
]}

Once the request is sent, we expect the output to be in the following format:

'''Sample Output: (for sentiment analysis API call)'''
{"sentiments": [
{
"id": 1,
"neg": "0.00",
"neu": "0.95",
"pos": "0.05",
"sentiment": "0.11",
"text": "Comment 1."
},
{
"id": 2,
"neg": "0.00",
"neu": "0.95",
"pos": "0.05",
"sentiment": "0.11",
"text": "Comment 2."
}
]}

'''Sample Output: (for problem detection API call)'''
{"reviews": [
{
"id": 1,
"problems": "Present",
"text": "Comment 1."
},
{
"id": 2,
"problems": "Present",
"text": "Comment 2."
}
]}

'''Sample Output: (for suggestion detection API call)'''
{"reviews": [
{
"id": 1,
"suggestions": "Present",
"text": "Comment 1."
},
{
"id": 2,
"suggestions": "Present",
"text": "Comment 2."
}
]}

These outputs (which is a JSON) will be parsed and the concerned metrics such as the sentiment, problem and suggestion will be extracted so the user will be able to view a summarized result of how well their review comments are. In addition, the result will be presented in a colorful tabular format to the user after they hit the "Get Review Feedback" button. Also, the total time taken for making these API calls will be displayed below the table.

==Testing plan==
We aim to perform automatic and manual testing for this project in order to achieve better reliability for this implementation.

As for this project, very few lines of code have been written in ruby (fetch_review_metric method in response_controller.rb) we will be testing that method in response controller using rspec tests.

'''Rspec tests for the same have been written in response_controller_spec.rb'''

[[File:Rspectests.png|800px]]

===View Tests===
* The functionality was written on the client side in javascript solely in _response_analysis.html.erb
* To test this view, any type of review must be accessible as a student.
* There is a button at the bottom of the review called 'Get Review Feedback'.
* When pressing button, API calls are issued and the metrics will show up within the table (a sample of which is displayed below).
* API calls are slow and will take time to process until the 'Loading...' text disappears.
* You can modify the comments and click the 'Get Review Feedback' button again to get new feedback, that too can be achieved without the need of saving the review, but still saving the review first is a better option to approach this.
* All the review feedback for the comments will be displayed in a colorful table.

=== Sample image of the table ===

[[File:Metric_table.png]]

==Important Links==

* [https://github.com/expertiza/expertiza/pull/1952 Github Pull Request]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2021_-_E2112._Integrate_Suggestion_Detection_Algorithm Expertiza wiki page link] (the link is mentioned here for records. It redirects to this same page.)
* [https://docs.google.com/document/d/1uzr5pybVKYr_K1Q8wSd4t-Id9nqTt3k1ePseDjY-RJg/edit#heading=h.fxfungdw1d5r Google Doc Project Description]
* [https://github.com/harshkachhadia/expertiza/tree/beta Github Repository Link for this expertiza fork] (make sure you change branch to 'beta' branch if the page doesn't load by default to beta branch)

CSC/ECE 517 Spring 2021 - E2112. Integrate Suggestion Detection Algorithm

2021-04-30T17:23:25Z

Hmkachha:

==Introduction==
=== Team ===
Dr. Gehringer (mentor),
John Bumgardner (mentor)
* Harsh Kachhadia (hmkachha)
* Parimal Mehta (pmehta3)
* Jatin Chinchkar (jchinch)
* Jordan Farthing (mjfarthi)

==Project Background==

Peer-review systems like Expertiza utilize a lot of students’ input to determine each other’s performance. At the same time, we hope students learn from the reviews they receive to improve their own performance. In order to make this happen, we would like to have everyone give quality reviews instead of generic ones. Currently we have a few classifiers that can detect useful features of review comments, such as whether they contain suggestions. The suggestion-detection algorithm has been coded as a web service, and other detection algorithms, such as problem detection and sentiment analysis, also exist as newer web services..but they need to be integrated properly using API calls in expertiza code.

=== Implementation Overview ===

Initially, we had planned to work on the work already done by the previous students [https://github.com/expertiza/expertiza/pull/1427 Spring 2019 pull request]. But later on we faced many issues such as: 1) The API call links were outdated 2) The new link that we found were incompatible with the previous work 3) The planned task of adding new API calls as per Carl Colglaizer's Framework turned out to be irrelevant or not required for this project, so we dropped it.

So we decided to start with integrating these API Calls from scratch.

'''Features we added in this project'''
* Setting up a config file 'review_metric.yml' where instructor can select what review metric to display for the current assignments
* Based on the selection made by professor, API calls(sentiment, problem, sugegstion) are made and a colorful table is displayed below the review form for student to review
* The total time taken for making these API calls will be displayed below the table.

'''Files that are modified or added in this project'''
* review_metrics.yml
* response.html.erb
* _response_analysis.html.erb
* response_controller.rb
* load_config.rb
* response_controller_spec.rb

=== Control Flow ===

[[File:Review_metric.png]]

To inspect implementation in detail, check out the 'Javascript Functionality'

=== Javascript Functionality ===

In the partial view file _response_analysis.html.erb file, we added new javascript functions to make, process and display output of API calls.

* ''' review_metric.yml config file'''

In this file, the configuration for this functionality on which metrics to display in the table, can be set by the
instructor. Instructor can change which metric to display or not display in feedback by changing the value for that
particular metric as 'true' or 'false'.

[[File:Configfile.png|800px]]

* ''' response_controller.rb'''

In this file, we added a method 'fetch_review_metric' which fetches the configurations set by instructor in the review_metric.yml file by
the instructor and passes those fetched values to the response.html.erb view using the 'new' or 'edit' method.

[[File:Response_controller.png|800px]]

* ''' response.html.rb'''

Here, we added a line that renders the partial _response_analysis.html.erb after the Save button to show the 'get review feedback' button and
display the metrics table. Also, we fetch the passed configuration data here.

[[File:response_html.png|800px]]

* ''' _response_analysis.html.erb - fetch_response_comments() function'''

This function fetches the comments written by the user in the review form and formats the collected comments as per the expectation of the API
calls.

[[File:Fetchcomments.png|800px]]

* ''' _response_analysis.html.erb - getReviewFeedback() function'''

This function makes calls to respective APIs and get their output based on the configuration received from the review_metrics.yml file.

[[File:Makesapicalls.png|800px]]

* ''' _response_analysis.html.erb - makeARequest() function'''

This is the driver function for making API call request to any url and data that is passed to it.

[[File:Makearequest.png|800px]]

* ''' _response_analysis.html.erb - combine_api_output() function'''

This function combines the output received from different API responses, combines them and formats the combined data to one that is suitable for
table generation.

[[File:Combineapioutput.png|800px]]

* ''' _response_analysis.html.erb - generateTable() function'''

This code generates a colorful table dynamically on the UI so that the reviewer can get a visual feedback on the comments that he/she wrote.

[[File:Generatetable.png|800px]]

=== API Details/Endpoints Appendix I ===

Here are the various endpoints for the deployment of Suggestion Detection Algorithm.

(We can't make the API links unclickable for this design doc, but clicking on them won't lead you anywhere. They are just endpoints and are mentioned here for reference only.)

* http://152.7.99.200:5000/problem for problem metrics only
* https://peerlogic.csc.ncsu.edu/sentiment/analyze_reviews_bulk for sentiment metrics only
* http://152.7.99.200:5000/suggestions for suggestions metrics only

===API Action===

In order to make the API call, the partial view "_response_analysis.html.erb" is rendered in "response.html.erb" view file which will be responsible for sending a JSON input to the web service. The input will contain the review comment written by the user and when the student hits the "Get review feedback button" the comments will be sent to these api calls in the following json format:

Below is a sample input
'''Sample Input:'''

{"reviews" : [
{
"id" : 1,
"text" : "Comment 1."
},
{
"id" : 2,
"text" : "Comment 2."
}
]}

Once the request is sent, we expect the output to be in the following format:

'''Sample Output: (for sentiment analysis API call)'''
{"sentiments": [
{
"id": 1,
"neg": "0.00",
"neu": "0.95",
"pos": "0.05",
"sentiment": "0.11",
"text": "Comment 1."
},
{
"id": 2,
"neg": "0.00",
"neu": "0.95",
"pos": "0.05",
"sentiment": "0.11",
"text": "Comment 2."
}
]}

'''Sample Output: (for problem detection API call)'''
{"reviews": [
{
"id": 1,
"problems": "Present",
"text": "Comment 1."
},
{
"id": 2,
"problems": "Present",
"text": "Comment 2."
}
]}

'''Sample Output: (for suggestion detection API call)'''
{"reviews": [
{
"id": 1,
"suggestions": "Present",
"text": "Comment 1."
},
{
"id": 2,
"suggestions": "Present",
"text": "Comment 2."
}
]}

These outputs (which is a JSON) will be parsed and the concerned metrics such as the sentiment, problem and suggestion will be extracted so the user will be able to view a summarized result of how well their review comments are. In addition, the result will be presented in a colorful tabular format to the user after they hit the "Get Review Feedback" button. Also, the total time taken for making these API calls will be displayed below the table.

==Testing plan==
We aim to perform automatic and manual testing for this project in order to achieve better reliability for this implementation.

As for this project, very few lines of code have been written in ruby (fetch_review_metric method in response_controller.rb) we will be testing that method in response controller using rspec tests.

'''Rspec tests for the same have been written in response_controller_spec.rb'''

[[File:Rspectests.png|800px]]

===View Tests===
* The functionality was written on the client side in javascript solely in _response_analysis.html.erb
* To test this view, any type of review must be accessible as a student.
* There is a button at the bottom of the review called 'Get Review Feedback'.
* When pressing button, API calls are issued and the metrics will show up within the table (a sample of which is displayed below).
* API calls are slow and will take time to process until the 'Loading...' text disappears.
* You can modify the comments and click the 'Get Review Feedback' button again to get new feedback, that too can be achieved without the need of saving the review, but still saving the review first is a better option to approach this.
* All the review feedback for the comments will be displayed in a colorful table.

'''NOTE: ''' The tests we wrote are passing on Travis CI, but after we synced new changes from original expertiza beta branch, the new tests that came with the pulled changes are failing and they have nothing to do with our current implementation. This is the reason for build failing on the pull request.

=== Sample image of the table ===

[[File:Metric_table.png]]

==Important Links==

* [https://github.com/expertiza/expertiza/pull/1952 Github Pull Request]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2021_-_E2112._Integrate_Suggestion_Detection_Algorithm Expertiza wiki page link] (the link is mentioned here for records. It redirects to this same page.)
* [https://docs.google.com/document/d/1uzr5pybVKYr_K1Q8wSd4t-Id9nqTt3k1ePseDjY-RJg/edit#heading=h.fxfungdw1d5r Google Doc Project Description]
* [https://github.com/harshkachhadia/expertiza/tree/beta Github Repository Link for this expertiza fork] (make sure you change branch to 'beta' branch if the page doesn't load by default to beta branch)

File:Metric table.png

2021-04-30T17:23:02Z

Hmkachha:

CSC/ECE 517 Spring 2021 - E2112. Integrate Suggestion Detection Algorithm

2021-04-30T17:15:53Z

Hmkachha: /* Testing plan */

==Introduction==
=== Team ===
Dr. Gehringer (mentor),
John Bumgardner (mentor)
* Harsh Kachhadia (hmkachha)
* Parimal Mehta (pmehta3)
* Jatin Chinchkar (jchinch)
* Jordan Farthing (mjfarthi)

==Project Background==

Peer-review systems like Expertiza utilize a lot of students’ input to determine each other’s performance. At the same time, we hope students learn from the reviews they receive to improve their own performance. In order to make this happen, we would like to have everyone give quality reviews instead of generic ones. Currently we have a few classifiers that can detect useful features of review comments, such as whether they contain suggestions. The suggestion-detection algorithm has been coded as a web service, and other detection algorithms, such as problem detection and sentiment analysis, also exist as newer web services..but they need to be integrated properly using API calls in expertiza code.

=== Implementation Overview ===

Initially, we had planned to work on the work already done by the previous students [https://github.com/expertiza/expertiza/pull/1427 Spring 2019 pull request]. But later on we faced many issues such as: 1) The API call links were outdated 2) The new link that we found were incompatible with the previous work 3) The planned task of adding new API calls as per Carl Colglaizer's Framework turned out to be irrelevant or not required for this project, so we dropped it.

So we decided to start with integrating these API Calls from scratch.

'''Features we added in this project'''
* Setting up a config file 'review_metric.yml' where instructor can select what review metric to display for the current assignments
* Based on the selection made by professor, API calls(sentiment, problem, sugegstion) are made and a colorful table is displayed below the review form for student to review
* The total time taken for making these API calls will be displayed below the table.

'''Files that are modified or added in this project'''
* review_metrics.yml
* response.html.erb
* _response_analysis.html.erb
* response_controller.rb
* load_config.rb
* response_controller_spec.rb

=== Control Flow ===

[[File:Review_metric.png]]

To inspect implementation in detail, check out the 'Javascript Functionality'

=== Javascript Functionality ===

In the partial view file _response_analysis.html.erb file, we added new javascript functions to make, process and display output of API calls.

* ''' review_metric.yml config file'''

In this file, the configuration for this functionality on which metrics to display in the table, can be set by the
instructor. Instructor can change which metric to display or not display in feedback by changing the value for that
particular metric as 'true' or 'false'.

[[File:Configfile.png|800px]]

* ''' response_controller.rb'''

In this file, we added a method 'fetch_review_metric' which fetches the configurations set by instructor in the review_metric.yml file by
the instructor and passes those fetched values to the response.html.erb view using the 'new' or 'edit' method.

[[File:Response_controller.png|800px]]

* ''' response.html.rb'''

Here, we added a line that renders the partial _response_analysis.html.erb after the Save button to show the 'get review feedback' button and
display the metrics table. Also, we fetch the passed configuration data here.

[[File:response_html.png|800px]]

* ''' _response_analysis.html.erb - fetch_response_comments() function'''

This function fetches the comments written by the user in the review form and formats the collected comments as per the expectation of the API
calls.

[[File:Fetchcomments.png|800px]]

* ''' _response_analysis.html.erb - getReviewFeedback() function'''

This function makes calls to respective APIs and get their output based on the configuration received from the review_metrics.yml file.

[[File:Makesapicalls.png|800px]]

* ''' _response_analysis.html.erb - makeARequest() function'''

This is the driver function for making API call request to any url and data that is passed to it.

[[File:Makearequest.png|800px]]

* ''' _response_analysis.html.erb - combine_api_output() function'''

This function combines the output received from different API responses, combines them and formats the combined data to one that is suitable for
table generation.

[[File:Combineapioutput.png|800px]]

* ''' _response_analysis.html.erb - generateTable() function'''

This code generates a colorful table dynamically on the UI so that the reviewer can get a visual feedback on the comments that he/she wrote.

[[File:Generatetable.png|800px]]

=== API Details/Endpoints Appendix I ===

Here are the various endpoints for the deployment of Suggestion Detection Algorithm.

(We can't make the API links unclickable for this design doc, but clicking on them won't lead you anywhere. They are just endpoints and are mentioned here for reference only.)

* http://152.7.99.200:5000/problem for problem metrics only
* https://peerlogic.csc.ncsu.edu/sentiment/analyze_reviews_bulk for sentiment metrics only
* http://152.7.99.200:5000/suggestions for suggestions metrics only

===API Action===

In order to make the API call, the partial view "_response_analysis.html.erb" is rendered in "response.html.erb" view file which will be responsible for sending a JSON input to the web service. The input will contain the review comment written by the user and when the student hits the "Get review feedback button" the comments will be sent to these api calls in the following json format:

Below is a sample input
'''Sample Input:'''

{"reviews" : [
{
"id" : 1,
"text" : "Comment 1."
},
{
"id" : 2,
"text" : "Comment 2."
}
]}

Once the request is sent, we expect the output to be in the following format:

'''Sample Output: (for sentiment analysis API call)'''
{"sentiments": [
{
"id": 1,
"neg": "0.00",
"neu": "0.95",
"pos": "0.05",
"sentiment": "0.11",
"text": "Comment 1."
},
{
"id": 2,
"neg": "0.00",
"neu": "0.95",
"pos": "0.05",
"sentiment": "0.11",
"text": "Comment 2."
}
]}

'''Sample Output: (for problem detection API call)'''
{"reviews": [
{
"id": 1,
"problems": "Present",
"text": "Comment 1."
},
{
"id": 2,
"problems": "Present",
"text": "Comment 2."
}
]}

'''Sample Output: (for suggestion detection API call)'''
{"reviews": [
{
"id": 1,
"suggestions": "Present",
"text": "Comment 1."
},
{
"id": 2,
"suggestions": "Present",
"text": "Comment 2."
}
]}

These outputs (which is a JSON) will be parsed and the concerned metrics such as the sentiment, problem and suggestion will be extracted so the user will be able to view a summarized result of how well their review comments are. In addition, the result will be presented in a colorful tabular format to the user after they hit the "Get Review Feedback" button. Also, the total time taken for making these API calls will be displayed below the table.

==Testing plan==
We aim to perform automatic and manual testing for this project in order to achieve better reliability for this implementation.

As for this project, very few lines of code have been written in ruby (fetch_review_metric method in response_controller.rb) we will be testing that method in response controller using rspec tests.

'''Rspec tests for the same have been written in response_controller_spec.rb'''

[[File:Rspectests.png|800px]]

===View Tests===
* The functionality was written on the client side in javascript solely in _response_analysis.html.erb
* To test this view, any type of review must be accessible as a student.
* There is a button at the bottom of the review called 'Get Review Feedback'.
* When pressing button, API calls are issued and the metrics will show up within the table (a sample of which is displayed below).
* API calls are slow and will take time to process until the 'Loading...' text disappears.
* You can modify the comments and click the 'Get Review Feedback' button again to get new feedback, that too can be achieved without the need of saving the review, but still saving the review first is a better option to approach this.
* All the review feedback for the comments will be displayed in a colorful table.

'''NOTE: ''' The tests we wrote are passing on Travis CI, but after we synced new changes from original expertiza beta branch, the new tests that came with the pulled changes are failing and they have nothing to do with our current implementation. This is the reason for build failing on the pull request.

=== Sample image of the table ===

[[File:Table_metrics.png]]

==Important Links==

* [https://github.com/expertiza/expertiza/pull/1952 Github Pull Request]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2021_-_E2112._Integrate_Suggestion_Detection_Algorithm Expertiza wiki page link] (the link is mentioned here for records. It redirects to this same page.)
* [https://docs.google.com/document/d/1uzr5pybVKYr_K1Q8wSd4t-Id9nqTt3k1ePseDjY-RJg/edit#heading=h.fxfungdw1d5r Google Doc Project Description]
* [https://github.com/harshkachhadia/expertiza/tree/beta Github Repository Link for this expertiza fork] (make sure you change branch to 'beta' branch if the page doesn't load by default to beta branch)

CSC/ECE 517 Spring 2021 - E2112. Integrate Suggestion Detection Algorithm

2021-04-30T17:12:11Z

Hmkachha: /* Testing plan */

==Introduction==
=== Team ===
Dr. Gehringer (mentor),
John Bumgardner (mentor)
* Harsh Kachhadia (hmkachha)
* Parimal Mehta (pmehta3)
* Jatin Chinchkar (jchinch)
* Jordan Farthing (mjfarthi)

==Project Background==

Peer-review systems like Expertiza utilize a lot of students’ input to determine each other’s performance. At the same time, we hope students learn from the reviews they receive to improve their own performance. In order to make this happen, we would like to have everyone give quality reviews instead of generic ones. Currently we have a few classifiers that can detect useful features of review comments, such as whether they contain suggestions. The suggestion-detection algorithm has been coded as a web service, and other detection algorithms, such as problem detection and sentiment analysis, also exist as newer web services..but they need to be integrated properly using API calls in expertiza code.

=== Implementation Overview ===

Initially, we had planned to work on the work already done by the previous students [https://github.com/expertiza/expertiza/pull/1427 Spring 2019 pull request]. But later on we faced many issues such as: 1) The API call links were outdated 2) The new link that we found were incompatible with the previous work 3) The planned task of adding new API calls as per Carl Colglaizer's Framework turned out to be irrelevant or not required for this project, so we dropped it.

So we decided to start with integrating these API Calls from scratch.

'''Features we added in this project'''
* Setting up a config file 'review_metric.yml' where instructor can select what review metric to display for the current assignments
* Based on the selection made by professor, API calls(sentiment, problem, sugegstion) are made and a colorful table is displayed below the review form for student to review
* The total time taken for making these API calls will be displayed below the table.

'''Files that are modified or added in this project'''
* review_metrics.yml
* response.html.erb
* _response_analysis.html.erb
* response_controller.rb
* load_config.rb
* response_controller_spec.rb

=== Control Flow ===

[[File:Review_metric.png]]

To inspect implementation in detail, check out the 'Javascript Functionality'

=== Javascript Functionality ===

In the partial view file _response_analysis.html.erb file, we added new javascript functions to make, process and display output of API calls.

* ''' review_metric.yml config file'''

In this file, the configuration for this functionality on which metrics to display in the table, can be set by the
instructor. Instructor can change which metric to display or not display in feedback by changing the value for that
particular metric as 'true' or 'false'.

[[File:Configfile.png|800px]]

* ''' response_controller.rb'''

In this file, we added a method 'fetch_review_metric' which fetches the configurations set by instructor in the review_metric.yml file by
the instructor and passes those fetched values to the response.html.erb view using the 'new' or 'edit' method.

[[File:Response_controller.png|800px]]

* ''' response.html.rb'''

Here, we added a line that renders the partial _response_analysis.html.erb after the Save button to show the 'get review feedback' button and
display the metrics table. Also, we fetch the passed configuration data here.

[[File:response_html.png|800px]]

* ''' _response_analysis.html.erb - fetch_response_comments() function'''

This function fetches the comments written by the user in the review form and formats the collected comments as per the expectation of the API
calls.

[[File:Fetchcomments.png|800px]]

* ''' _response_analysis.html.erb - getReviewFeedback() function'''

This function makes calls to respective APIs and get their output based on the configuration received from the review_metrics.yml file.

[[File:Makesapicalls.png|800px]]

* ''' _response_analysis.html.erb - makeARequest() function'''

This is the driver function for making API call request to any url and data that is passed to it.

[[File:Makearequest.png|800px]]

* ''' _response_analysis.html.erb - combine_api_output() function'''

This function combines the output received from different API responses, combines them and formats the combined data to one that is suitable for
table generation.

[[File:Combineapioutput.png|800px]]

* ''' _response_analysis.html.erb - generateTable() function'''

This code generates a colorful table dynamically on the UI so that the reviewer can get a visual feedback on the comments that he/she wrote.

[[File:Generatetable.png|800px]]

=== API Details/Endpoints Appendix I ===

Here are the various endpoints for the deployment of Suggestion Detection Algorithm.

(We can't make the API links unclickable for this design doc, but clicking on them won't lead you anywhere. They are just endpoints and are mentioned here for reference only.)

* http://152.7.99.200:5000/problem for problem metrics only
* https://peerlogic.csc.ncsu.edu/sentiment/analyze_reviews_bulk for sentiment metrics only
* http://152.7.99.200:5000/suggestions for suggestions metrics only

===API Action===

In order to make the API call, the partial view "_response_analysis.html.erb" is rendered in "response.html.erb" view file which will be responsible for sending a JSON input to the web service. The input will contain the review comment written by the user and when the student hits the "Get review feedback button" the comments will be sent to these api calls in the following json format:

Below is a sample input
'''Sample Input:'''

{"reviews" : [
{
"id" : 1,
"text" : "Comment 1."
},
{
"id" : 2,
"text" : "Comment 2."
}
]}

Once the request is sent, we expect the output to be in the following format:

'''Sample Output: (for sentiment analysis API call)'''
{"sentiments": [
{
"id": 1,
"neg": "0.00",
"neu": "0.95",
"pos": "0.05",
"sentiment": "0.11",
"text": "Comment 1."
},
{
"id": 2,
"neg": "0.00",
"neu": "0.95",
"pos": "0.05",
"sentiment": "0.11",
"text": "Comment 2."
}
]}

'''Sample Output: (for problem detection API call)'''
{"reviews": [
{
"id": 1,
"problems": "Present",
"text": "Comment 1."
},
{
"id": 2,
"problems": "Present",
"text": "Comment 2."
}
]}

'''Sample Output: (for suggestion detection API call)'''
{"reviews": [
{
"id": 1,
"suggestions": "Present",
"text": "Comment 1."
},
{
"id": 2,
"suggestions": "Present",
"text": "Comment 2."
}
]}

These outputs (which is a JSON) will be parsed and the concerned metrics such as the sentiment, problem and suggestion will be extracted so the user will be able to view a summarized result of how well their review comments are. In addition, the result will be presented in a colorful tabular format to the user after they hit the "Get Review Feedback" button. Also, the total time taken for making these API calls will be displayed below the table.

==Testing plan==
We aim to perform automatic and manual testing for this project in order to achieve better reliability for this implementation.

As for this project, very few lines of code have been written in ruby (fetch_review_metric method in response_controller.rb) we will be testing that method in response controller using rspec tests.

'''Rspec tests for the same have been written in response_controller_spec.rb'''

[[File:Rspectests.png|800px]]

===View Tests===
* The functionality was written on the client side in javascript solely in _response_analysis.html.erb
* To test this view, any type of review must be accessible as a student.
* There is a button at the bottom of the review called 'Get Review Feedback'.
* When pressing button, API calls are issued and the metrics will show up within the table (a sample of which is displayed below).
* API calls are slow and will take time to process until the 'Loading...' text disappears.
* You can modify the comments and click the 'Get Review Feedback' button again to get new feedback, that too can be achieved without the need of saving the review, but still saving the review first is a better option to approach this.
* All the review feedback for the comments will be displayed in a colorful table.

=== Sample image of the table ===

[[File:Table_metrics.png]]

==Important Links==

* [https://github.com/expertiza/expertiza/pull/1952 Github Pull Request]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2021_-_E2112._Integrate_Suggestion_Detection_Algorithm Expertiza wiki page link] (the link is mentioned here for records. It redirects to this same page.)
* [https://docs.google.com/document/d/1uzr5pybVKYr_K1Q8wSd4t-Id9nqTt3k1ePseDjY-RJg/edit#heading=h.fxfungdw1d5r Google Doc Project Description]
* [https://github.com/harshkachhadia/expertiza/tree/beta Github Repository Link for this expertiza fork] (make sure you change branch to 'beta' branch if the page doesn't load by default to beta branch)

CSC/ECE 517 Spring 2021 - E2112. Integrate Suggestion Detection Algorithm

2021-04-30T17:11:37Z

Hmkachha: /* Testing plan */

==Introduction==
=== Team ===
Dr. Gehringer (mentor),
John Bumgardner (mentor)
* Harsh Kachhadia (hmkachha)
* Parimal Mehta (pmehta3)
* Jatin Chinchkar (jchinch)
* Jordan Farthing (mjfarthi)

==Project Background==

Peer-review systems like Expertiza utilize a lot of students’ input to determine each other’s performance. At the same time, we hope students learn from the reviews they receive to improve their own performance. In order to make this happen, we would like to have everyone give quality reviews instead of generic ones. Currently we have a few classifiers that can detect useful features of review comments, such as whether they contain suggestions. The suggestion-detection algorithm has been coded as a web service, and other detection algorithms, such as problem detection and sentiment analysis, also exist as newer web services..but they need to be integrated properly using API calls in expertiza code.

=== Implementation Overview ===

Initially, we had planned to work on the work already done by the previous students [https://github.com/expertiza/expertiza/pull/1427 Spring 2019 pull request]. But later on we faced many issues such as: 1) The API call links were outdated 2) The new link that we found were incompatible with the previous work 3) The planned task of adding new API calls as per Carl Colglaizer's Framework turned out to be irrelevant or not required for this project, so we dropped it.

So we decided to start with integrating these API Calls from scratch.

'''Features we added in this project'''
* Setting up a config file 'review_metric.yml' where instructor can select what review metric to display for the current assignments
* Based on the selection made by professor, API calls(sentiment, problem, sugegstion) are made and a colorful table is displayed below the review form for student to review
* The total time taken for making these API calls will be displayed below the table.

'''Files that are modified or added in this project'''
* review_metrics.yml
* response.html.erb
* _response_analysis.html.erb
* response_controller.rb
* load_config.rb
* response_controller_spec.rb

=== Control Flow ===

[[File:Review_metric.png]]

To inspect implementation in detail, check out the 'Javascript Functionality'

=== Javascript Functionality ===

In the partial view file _response_analysis.html.erb file, we added new javascript functions to make, process and display output of API calls.

* ''' review_metric.yml config file'''

In this file, the configuration for this functionality on which metrics to display in the table, can be set by the
instructor. Instructor can change which metric to display or not display in feedback by changing the value for that
particular metric as 'true' or 'false'.

[[File:Configfile.png|800px]]

* ''' response_controller.rb'''

In this file, we added a method 'fetch_review_metric' which fetches the configurations set by instructor in the review_metric.yml file by
the instructor and passes those fetched values to the response.html.erb view using the 'new' or 'edit' method.

[[File:Response_controller.png|800px]]

* ''' response.html.rb'''

Here, we added a line that renders the partial _response_analysis.html.erb after the Save button to show the 'get review feedback' button and
display the metrics table. Also, we fetch the passed configuration data here.

[[File:response_html.png|800px]]

* ''' _response_analysis.html.erb - fetch_response_comments() function'''

This function fetches the comments written by the user in the review form and formats the collected comments as per the expectation of the API
calls.

[[File:Fetchcomments.png|800px]]

* ''' _response_analysis.html.erb - getReviewFeedback() function'''

This function makes calls to respective APIs and get their output based on the configuration received from the review_metrics.yml file.

[[File:Makesapicalls.png|800px]]

* ''' _response_analysis.html.erb - makeARequest() function'''

This is the driver function for making API call request to any url and data that is passed to it.

[[File:Makearequest.png|800px]]

* ''' _response_analysis.html.erb - combine_api_output() function'''

This function combines the output received from different API responses, combines them and formats the combined data to one that is suitable for
table generation.

[[File:Combineapioutput.png|800px]]

* ''' _response_analysis.html.erb - generateTable() function'''

This code generates a colorful table dynamically on the UI so that the reviewer can get a visual feedback on the comments that he/she wrote.

[[File:Generatetable.png|800px]]

=== API Details/Endpoints Appendix I ===

Here are the various endpoints for the deployment of Suggestion Detection Algorithm.

(We can't make the API links unclickable for this design doc, but clicking on them won't lead you anywhere. They are just endpoints and are mentioned here for reference only.)

* http://152.7.99.200:5000/problem for problem metrics only
* https://peerlogic.csc.ncsu.edu/sentiment/analyze_reviews_bulk for sentiment metrics only
* http://152.7.99.200:5000/suggestions for suggestions metrics only

===API Action===

In order to make the API call, the partial view "_response_analysis.html.erb" is rendered in "response.html.erb" view file which will be responsible for sending a JSON input to the web service. The input will contain the review comment written by the user and when the student hits the "Get review feedback button" the comments will be sent to these api calls in the following json format:

Below is a sample input
'''Sample Input:'''

{"reviews" : [
{
"id" : 1,
"text" : "Comment 1."
},
{
"id" : 2,
"text" : "Comment 2."
}
]}

Once the request is sent, we expect the output to be in the following format:

'''Sample Output: (for sentiment analysis API call)'''
{"sentiments": [
{
"id": 1,
"neg": "0.00",
"neu": "0.95",
"pos": "0.05",
"sentiment": "0.11",
"text": "Comment 1."
},
{
"id": 2,
"neg": "0.00",
"neu": "0.95",
"pos": "0.05",
"sentiment": "0.11",
"text": "Comment 2."
}
]}

'''Sample Output: (for problem detection API call)'''
{"reviews": [
{
"id": 1,
"problems": "Present",
"text": "Comment 1."
},
{
"id": 2,
"problems": "Present",
"text": "Comment 2."
}
]}

'''Sample Output: (for suggestion detection API call)'''
{"reviews": [
{
"id": 1,
"suggestions": "Present",
"text": "Comment 1."
},
{
"id": 2,
"suggestions": "Present",
"text": "Comment 2."
}
]}

These outputs (which is a JSON) will be parsed and the concerned metrics such as the sentiment, problem and suggestion will be extracted so the user will be able to view a summarized result of how well their review comments are. In addition, the result will be presented in a colorful tabular format to the user after they hit the "Get Review Feedback" button. Also, the total time taken for making these API calls will be displayed below the table.

==Testing plan==
We aim to perform automatic and manual testing for this project in order to achieve better reliability for this implementation.

As for this project, very few lines of code have been written in ruby (fetch_review_metric method in response_controller.rb) we will be testing that method in response controller using rspec tests.

'''Rspec tests for the same have been written in response_controller_spec.rb'''

[[File:Rspectests.png 800px]]

===View Tests===
* The functionality was written on the client side in javascript solely in _response_analysis.html.erb
* To test this view, any type of review must be accessible as a student.
* There is a button at the bottom of the review called 'Get Review Feedback'.
* When pressing button, API calls are issued and the metrics will show up within the table (a sample of which is displayed below).
* API calls are slow and will take time to process until the 'Loading...' text disappears.
* You can modify the comments and click the 'Get Review Feedback' button again to get new feedback, that too can be achieved without the need of saving the review, but still saving the review first is a better option to approach this.
* All the review feedback for the comments will be displayed in a colorful table.

=== Sample image of the table ===

[[File:Table_metrics.png]]

==Important Links==

* [https://github.com/expertiza/expertiza/pull/1952 Github Pull Request]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2021_-_E2112._Integrate_Suggestion_Detection_Algorithm Expertiza wiki page link] (the link is mentioned here for records. It redirects to this same page.)
* [https://docs.google.com/document/d/1uzr5pybVKYr_K1Q8wSd4t-Id9nqTt3k1ePseDjY-RJg/edit#heading=h.fxfungdw1d5r Google Doc Project Description]
* [https://github.com/harshkachhadia/expertiza/tree/beta Github Repository Link for this expertiza fork] (make sure you change branch to 'beta' branch if the page doesn't load by default to beta branch)

CSC/ECE 517 Spring 2021 - E2112. Integrate Suggestion Detection Algorithm

2021-04-30T17:10:58Z

Hmkachha: /* Testing plan */

==Introduction==
=== Team ===
Dr. Gehringer (mentor),
John Bumgardner (mentor)
* Harsh Kachhadia (hmkachha)
* Parimal Mehta (pmehta3)
* Jatin Chinchkar (jchinch)
* Jordan Farthing (mjfarthi)

==Project Background==

Peer-review systems like Expertiza utilize a lot of students’ input to determine each other’s performance. At the same time, we hope students learn from the reviews they receive to improve their own performance. In order to make this happen, we would like to have everyone give quality reviews instead of generic ones. Currently we have a few classifiers that can detect useful features of review comments, such as whether they contain suggestions. The suggestion-detection algorithm has been coded as a web service, and other detection algorithms, such as problem detection and sentiment analysis, also exist as newer web services..but they need to be integrated properly using API calls in expertiza code.

=== Implementation Overview ===

Initially, we had planned to work on the work already done by the previous students [https://github.com/expertiza/expertiza/pull/1427 Spring 2019 pull request]. But later on we faced many issues such as: 1) The API call links were outdated 2) The new link that we found were incompatible with the previous work 3) The planned task of adding new API calls as per Carl Colglaizer's Framework turned out to be irrelevant or not required for this project, so we dropped it.

So we decided to start with integrating these API Calls from scratch.

'''Features we added in this project'''
* Setting up a config file 'review_metric.yml' where instructor can select what review metric to display for the current assignments
* Based on the selection made by professor, API calls(sentiment, problem, sugegstion) are made and a colorful table is displayed below the review form for student to review
* The total time taken for making these API calls will be displayed below the table.

'''Files that are modified or added in this project'''
* review_metrics.yml
* response.html.erb
* _response_analysis.html.erb
* response_controller.rb
* load_config.rb
* response_controller_spec.rb

=== Control Flow ===

[[File:Review_metric.png]]

To inspect implementation in detail, check out the 'Javascript Functionality'

=== Javascript Functionality ===

In the partial view file _response_analysis.html.erb file, we added new javascript functions to make, process and display output of API calls.

* ''' review_metric.yml config file'''

In this file, the configuration for this functionality on which metrics to display in the table, can be set by the
instructor. Instructor can change which metric to display or not display in feedback by changing the value for that
particular metric as 'true' or 'false'.

[[File:Configfile.png|800px]]

* ''' response_controller.rb'''

In this file, we added a method 'fetch_review_metric' which fetches the configurations set by instructor in the review_metric.yml file by
the instructor and passes those fetched values to the response.html.erb view using the 'new' or 'edit' method.

[[File:Response_controller.png|800px]]

* ''' response.html.rb'''

Here, we added a line that renders the partial _response_analysis.html.erb after the Save button to show the 'get review feedback' button and
display the metrics table. Also, we fetch the passed configuration data here.

[[File:response_html.png|800px]]

* ''' _response_analysis.html.erb - fetch_response_comments() function'''

This function fetches the comments written by the user in the review form and formats the collected comments as per the expectation of the API
calls.

[[File:Fetchcomments.png|800px]]

* ''' _response_analysis.html.erb - getReviewFeedback() function'''

This function makes calls to respective APIs and get their output based on the configuration received from the review_metrics.yml file.

[[File:Makesapicalls.png|800px]]

* ''' _response_analysis.html.erb - makeARequest() function'''

This is the driver function for making API call request to any url and data that is passed to it.

[[File:Makearequest.png|800px]]

* ''' _response_analysis.html.erb - combine_api_output() function'''

This function combines the output received from different API responses, combines them and formats the combined data to one that is suitable for
table generation.

[[File:Combineapioutput.png|800px]]

* ''' _response_analysis.html.erb - generateTable() function'''

This code generates a colorful table dynamically on the UI so that the reviewer can get a visual feedback on the comments that he/she wrote.

[[File:Generatetable.png|800px]]

=== API Details/Endpoints Appendix I ===

Here are the various endpoints for the deployment of Suggestion Detection Algorithm.

(We can't make the API links unclickable for this design doc, but clicking on them won't lead you anywhere. They are just endpoints and are mentioned here for reference only.)

* http://152.7.99.200:5000/problem for problem metrics only
* https://peerlogic.csc.ncsu.edu/sentiment/analyze_reviews_bulk for sentiment metrics only
* http://152.7.99.200:5000/suggestions for suggestions metrics only

===API Action===

In order to make the API call, the partial view "_response_analysis.html.erb" is rendered in "response.html.erb" view file which will be responsible for sending a JSON input to the web service. The input will contain the review comment written by the user and when the student hits the "Get review feedback button" the comments will be sent to these api calls in the following json format:

Below is a sample input
'''Sample Input:'''

{"reviews" : [
{
"id" : 1,
"text" : "Comment 1."
},
{
"id" : 2,
"text" : "Comment 2."
}
]}

Once the request is sent, we expect the output to be in the following format:

'''Sample Output: (for sentiment analysis API call)'''
{"sentiments": [
{
"id": 1,
"neg": "0.00",
"neu": "0.95",
"pos": "0.05",
"sentiment": "0.11",
"text": "Comment 1."
},
{
"id": 2,
"neg": "0.00",
"neu": "0.95",
"pos": "0.05",
"sentiment": "0.11",
"text": "Comment 2."
}
]}

'''Sample Output: (for problem detection API call)'''
{"reviews": [
{
"id": 1,
"problems": "Present",
"text": "Comment 1."
},
{
"id": 2,
"problems": "Present",
"text": "Comment 2."
}
]}

'''Sample Output: (for suggestion detection API call)'''
{"reviews": [
{
"id": 1,
"suggestions": "Present",
"text": "Comment 1."
},
{
"id": 2,
"suggestions": "Present",
"text": "Comment 2."
}
]}

These outputs (which is a JSON) will be parsed and the concerned metrics such as the sentiment, problem and suggestion will be extracted so the user will be able to view a summarized result of how well their review comments are. In addition, the result will be presented in a colorful tabular format to the user after they hit the "Get Review Feedback" button. Also, the total time taken for making these API calls will be displayed below the table.

==Testing plan==
We aim to perform automatic and manual testing for this project in order to achieve better reliability for this implementation.

As for this project, very few lines of code have been written in ruby (fetch_review_metric method in response_controller.rb) we will be testing that method in response controller using rspec tests.

'''Rspec tests for the same have been written in response_controller_spec.rb'''

[[File:Rspectests.png]]

===View Tests===
* The functionality was written on the client side in javascript solely in _response_analysis.html.erb
* To test this view, any type of review must be accessible as a student.
* There is a button at the bottom of the review called 'Get Review Feedback'.
* When pressing button, API calls are issued and the metrics will show up within the table (a sample of which is displayed below).
* API calls are slow and will take time to process until the 'Loading...' text disappears.
* You can modify the comments and click the 'Get Review Feedback' button again to get new feedback, that too can be achieved without the need of saving the review, but still saving the review first is a better option to approach this.
* All the review feedback for the comments will be displayed in a colorful table.

=== Sample image of the table ===

[[File:Table_metrics.png 800px]]

==Important Links==

* [https://github.com/expertiza/expertiza/pull/1952 Github Pull Request]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2021_-_E2112._Integrate_Suggestion_Detection_Algorithm Expertiza wiki page link] (the link is mentioned here for records. It redirects to this same page.)
* [https://docs.google.com/document/d/1uzr5pybVKYr_K1Q8wSd4t-Id9nqTt3k1ePseDjY-RJg/edit#heading=h.fxfungdw1d5r Google Doc Project Description]
* [https://github.com/harshkachhadia/expertiza/tree/beta Github Repository Link for this expertiza fork] (make sure you change branch to 'beta' branch if the page doesn't load by default to beta branch)

CSC/ECE 517 Spring 2021 - E2112. Integrate Suggestion Detection Algorithm

2021-04-30T17:10:37Z

Hmkachha:

==Introduction==
=== Team ===
Dr. Gehringer (mentor),
John Bumgardner (mentor)
* Harsh Kachhadia (hmkachha)
* Parimal Mehta (pmehta3)
* Jatin Chinchkar (jchinch)
* Jordan Farthing (mjfarthi)

==Project Background==

Peer-review systems like Expertiza utilize a lot of students’ input to determine each other’s performance. At the same time, we hope students learn from the reviews they receive to improve their own performance. In order to make this happen, we would like to have everyone give quality reviews instead of generic ones. Currently we have a few classifiers that can detect useful features of review comments, such as whether they contain suggestions. The suggestion-detection algorithm has been coded as a web service, and other detection algorithms, such as problem detection and sentiment analysis, also exist as newer web services..but they need to be integrated properly using API calls in expertiza code.

=== Implementation Overview ===

Initially, we had planned to work on the work already done by the previous students [https://github.com/expertiza/expertiza/pull/1427 Spring 2019 pull request]. But later on we faced many issues such as: 1) The API call links were outdated 2) The new link that we found were incompatible with the previous work 3) The planned task of adding new API calls as per Carl Colglaizer's Framework turned out to be irrelevant or not required for this project, so we dropped it.

So we decided to start with integrating these API Calls from scratch.

'''Features we added in this project'''
* Setting up a config file 'review_metric.yml' where instructor can select what review metric to display for the current assignments
* Based on the selection made by professor, API calls(sentiment, problem, sugegstion) are made and a colorful table is displayed below the review form for student to review
* The total time taken for making these API calls will be displayed below the table.

'''Files that are modified or added in this project'''
* review_metrics.yml
* response.html.erb
* _response_analysis.html.erb
* response_controller.rb
* load_config.rb
* response_controller_spec.rb

=== Control Flow ===

[[File:Review_metric.png]]

To inspect implementation in detail, check out the 'Javascript Functionality'

=== Javascript Functionality ===

In the partial view file _response_analysis.html.erb file, we added new javascript functions to make, process and display output of API calls.

* ''' review_metric.yml config file'''

In this file, the configuration for this functionality on which metrics to display in the table, can be set by the
instructor. Instructor can change which metric to display or not display in feedback by changing the value for that
particular metric as 'true' or 'false'.

[[File:Configfile.png|800px]]

* ''' response_controller.rb'''

In this file, we added a method 'fetch_review_metric' which fetches the configurations set by instructor in the review_metric.yml file by
the instructor and passes those fetched values to the response.html.erb view using the 'new' or 'edit' method.

[[File:Response_controller.png|800px]]

* ''' response.html.rb'''

Here, we added a line that renders the partial _response_analysis.html.erb after the Save button to show the 'get review feedback' button and
display the metrics table. Also, we fetch the passed configuration data here.

[[File:response_html.png|800px]]

* ''' _response_analysis.html.erb - fetch_response_comments() function'''

This function fetches the comments written by the user in the review form and formats the collected comments as per the expectation of the API
calls.

[[File:Fetchcomments.png|800px]]

* ''' _response_analysis.html.erb - getReviewFeedback() function'''

This function makes calls to respective APIs and get their output based on the configuration received from the review_metrics.yml file.

[[File:Makesapicalls.png|800px]]

* ''' _response_analysis.html.erb - makeARequest() function'''

This is the driver function for making API call request to any url and data that is passed to it.

[[File:Makearequest.png|800px]]

* ''' _response_analysis.html.erb - combine_api_output() function'''

This function combines the output received from different API responses, combines them and formats the combined data to one that is suitable for
table generation.

[[File:Combineapioutput.png|800px]]

* ''' _response_analysis.html.erb - generateTable() function'''

This code generates a colorful table dynamically on the UI so that the reviewer can get a visual feedback on the comments that he/she wrote.

[[File:Generatetable.png|800px]]

=== API Details/Endpoints Appendix I ===

Here are the various endpoints for the deployment of Suggestion Detection Algorithm.

(We can't make the API links unclickable for this design doc, but clicking on them won't lead you anywhere. They are just endpoints and are mentioned here for reference only.)

* http://152.7.99.200:5000/problem for problem metrics only
* https://peerlogic.csc.ncsu.edu/sentiment/analyze_reviews_bulk for sentiment metrics only
* http://152.7.99.200:5000/suggestions for suggestions metrics only

===API Action===

In order to make the API call, the partial view "_response_analysis.html.erb" is rendered in "response.html.erb" view file which will be responsible for sending a JSON input to the web service. The input will contain the review comment written by the user and when the student hits the "Get review feedback button" the comments will be sent to these api calls in the following json format:

Below is a sample input
'''Sample Input:'''

{"reviews" : [
{
"id" : 1,
"text" : "Comment 1."
},
{
"id" : 2,
"text" : "Comment 2."
}
]}

Once the request is sent, we expect the output to be in the following format:

'''Sample Output: (for sentiment analysis API call)'''
{"sentiments": [
{
"id": 1,
"neg": "0.00",
"neu": "0.95",
"pos": "0.05",
"sentiment": "0.11",
"text": "Comment 1."
},
{
"id": 2,
"neg": "0.00",
"neu": "0.95",
"pos": "0.05",
"sentiment": "0.11",
"text": "Comment 2."
}
]}

'''Sample Output: (for problem detection API call)'''
{"reviews": [
{
"id": 1,
"problems": "Present",
"text": "Comment 1."
},
{
"id": 2,
"problems": "Present",
"text": "Comment 2."
}
]}

'''Sample Output: (for suggestion detection API call)'''
{"reviews": [
{
"id": 1,
"suggestions": "Present",
"text": "Comment 1."
},
{
"id": 2,
"suggestions": "Present",
"text": "Comment 2."
}
]}

These outputs (which is a JSON) will be parsed and the concerned metrics such as the sentiment, problem and suggestion will be extracted so the user will be able to view a summarized result of how well their review comments are. In addition, the result will be presented in a colorful tabular format to the user after they hit the "Get Review Feedback" button. Also, the total time taken for making these API calls will be displayed below the table.

==Testing plan==
We aim to perform automatic and manual testing for this project in order to achieve better reliability for this implementation.

As for this project, very few lines of code have been written in ruby (fetch_review_metric method in response_controller.rb) we will be testing that method in response controller using rspec tests.

'''Rspec tests for the same have been written in response_controller_spec.rb'''

[[File:Rspectests.png]]

===View Tests===
* The functionality was written on the client side in javascript solely in _response_analysis.html.erb
* To test this view, any type of review must be accessible as a student.
* There is a button at the bottom of the review called 'Get Review Feedback'.
* When pressing button, API calls are issued and the metrics will show up within the table (a sample of which is displayed below).
* API calls are slow and will take time to process until the 'Loading...' text disappears.
* You can modify the comments and click the 'Get Review Feedback' button again to get new feedback, that too can be achieved without the need of saving the review, but still saving the review first is a better option to approach this.
* All the review feedback for the comments will be displayed in a colorful table.

=== Sample image of the table ===

[[File:Table_metrics.png]]

==Important Links==

* [https://github.com/expertiza/expertiza/pull/1952 Github Pull Request]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2021_-_E2112._Integrate_Suggestion_Detection_Algorithm Expertiza wiki page link] (the link is mentioned here for records. It redirects to this same page.)
* [https://docs.google.com/document/d/1uzr5pybVKYr_K1Q8wSd4t-Id9nqTt3k1ePseDjY-RJg/edit#heading=h.fxfungdw1d5r Google Doc Project Description]
* [https://github.com/harshkachhadia/expertiza/tree/beta Github Repository Link for this expertiza fork] (make sure you change branch to 'beta' branch if the page doesn't load by default to beta branch)

File:Rspectests.png

2021-04-30T17:09:37Z

Hmkachha:

CSC/ECE 517 Spring 2021 - E2112. Integrate Suggestion Detection Algorithm

2021-04-30T17:06:23Z

Hmkachha: /* Implementation Overview */

==Introduction==
=== Team ===
Dr. Gehringer (mentor),
John Bumgardner (mentor)
* Harsh Kachhadia (hmkachha)
* Parimal Mehta (pmehta3)
* Jatin Chinchkar (jchinch)
* Jordan Farthing (mjfarthi)

==Project Background==

Peer-review systems like Expertiza utilize a lot of students’ input to determine each other’s performance. At the same time, we hope students learn from the reviews they receive to improve their own performance. In order to make this happen, we would like to have everyone give quality reviews instead of generic ones. Currently we have a few classifiers that can detect useful features of review comments, such as whether they contain suggestions. The suggestion-detection algorithm has been coded as a web service, and other detection algorithms, such as problem detection and sentiment analysis, also exist as newer web services..but they need to be integrated properly using API calls in expertiza code.

=== Implementation Overview ===

Initially, we had planned to work on the work already done by the previous students [https://github.com/expertiza/expertiza/pull/1427 Spring 2019 pull request]. But later on we faced many issues such as: 1) The API call links were outdated 2) The new link that we found were incompatible with the previous work 3) The planned task of adding new API calls as per Carl Colglaizer's Framework turned out to be irrelevant or not required for this project, so we dropped it.

So we decided to start with integrating these API Calls from scratch.

'''Features we added in this project'''
* Setting up a config file 'review_metric.yml' where instructor can select what review metric to display for the current assignments
* Based on the selection made by professor, API calls(sentiment, problem, sugegstion) are made and a colorful table is displayed below the review form for student to review
* The total time taken for making these API calls will be displayed below the table.

'''Files that are modified or added in this project'''
* review_metrics.yml
* response.html.erb
* _response_analysis.html.erb
* response_controller.rb
* load_config.rb
* response_controller_spec.rb

=== Control Flow ===

[[File:Review_metric.png]]

To inspect implementation in detail, check out the 'Javascript Functionality'

=== Javascript Functionality ===

In the partial view file _response_analysis.html.erb file, we added new javascript functions to make, process and display output of API calls.

* ''' review_metric.yml config file'''

In this file, the configuration for this functionality on which metrics to display in the table, can be set by the
instructor. Instructor can change which metric to display or not display in feedback by changing the value for that
particular metric as 'true' or 'false'.

[[File:Configfile.png|800px]]

* ''' response_controller.rb'''

In this file, we added a method 'fetch_review_metric' which fetches the configurations set by instructor in the review_metric.yml file by
the instructor and passes those fetched values to the response.html.erb view using the 'new' or 'edit' method.

[[File:Response_controller.png|800px]]

* ''' response.html.rb'''

Here, we added a line that renders the partial _response_analysis.html.erb after the Save button to show the 'get review feedback' button and
display the metrics table. Also, we fetch the passed configuration data here.

[[File:response_html.png|800px]]

* ''' _response_analysis.html.erb - fetch_response_comments() function'''

This function fetches the comments written by the user in the review form and formats the collected comments as per the expectation of the API
calls.

[[File:Fetchcomments.png|800px]]

* ''' _response_analysis.html.erb - getReviewFeedback() function'''

This function makes calls to respective APIs and get their output based on the configuration received from the review_metrics.yml file.

[[File:Makesapicalls.png|800px]]

* ''' _response_analysis.html.erb - makeARequest() function'''

This is the driver function for making API call request to any url and data that is passed to it.

[[File:Makearequest.png|800px]]

* ''' _response_analysis.html.erb - combine_api_output() function'''

This function combines the output received from different API responses, combines them and formats the combined data to one that is suitable for
table generation.

[[File:Combineapioutput.png|800px]]

* ''' _response_analysis.html.erb - generateTable() function'''

This code generates a colorful table dynamically on the UI so that the reviewer can get a visual feedback on the comments that he/she wrote.

[[File:Generatetable.png|800px]]

=== API Details/Endpoints Appendix I ===

Here are the various endpoints for the deployment of Suggestion Detection Algorithm.

(We can't make the API links unclickable for this design doc, but clicking on them won't lead you anywhere. They are just endpoints and are mentioned here for reference only.)

* http://152.7.99.200:5000/problem for problem metrics only
* https://peerlogic.csc.ncsu.edu/sentiment/analyze_reviews_bulk for sentiment metrics only
* http://152.7.99.200:5000/suggestions for suggestions metrics only

===API Action===

In order to make the API call, the partial view "_response_analysis.html.erb" is rendered in "response.html.erb" view file which will be responsible for sending a JSON input to the web service. The input will contain the review comment written by the user and when the student hits the "Get review feedback button" the comments will be sent to these api calls in the following json format:

Below is a sample input
'''Sample Input:'''

{"reviews" : [
{
"id" : 1,
"text" : "Comment 1."
},
{
"id" : 2,
"text" : "Comment 2."
}
]}

Once the request is sent, we expect the output to be in the following format:

'''Sample Output: (for sentiment analysis API call)'''
{"sentiments": [
{
"id": 1,
"neg": "0.00",
"neu": "0.95",
"pos": "0.05",
"sentiment": "0.11",
"text": "Comment 1."
},
{
"id": 2,
"neg": "0.00",
"neu": "0.95",
"pos": "0.05",
"sentiment": "0.11",
"text": "Comment 2."
}
]}

'''Sample Output: (for problem detection API call)'''
{"reviews": [
{
"id": 1,
"problems": "Present",
"text": "Comment 1."
},
{
"id": 2,
"problems": "Present",
"text": "Comment 2."
}
]}

'''Sample Output: (for suggestion detection API call)'''
{"reviews": [
{
"id": 1,
"suggestions": "Present",
"text": "Comment 1."
},
{
"id": 2,
"suggestions": "Present",
"text": "Comment 2."
}
]}

These outputs (which is a JSON) will be parsed and the concerned metrics such as the sentiment, problem and suggestion will be extracted so the user will be able to view a summarized result of how well their review comments are. In addition, the result will be presented in a colorful tabular format to the user after they hit the "Get Review Feedback" button. Also, the total time taken for making these API calls will be displayed below the table.

==Testing plan==
We aim to perform automatic and manual testing for this project in order to achieve better reliability for this implementation.

As for this project, very few lines of code have been written in ruby (fetch_review_metric method in response_controller.rb) we will be testing that method in response controller using rspec tests.

'''Rspec tests for the same have been written in response_controller_spec.rb'''

===View Tests===
* The functionality was written on the client side in javascript solely in _response_analysis.html.erb
* To test this view, any type of review must be accessible as a student.
* There is a button at the bottom of the review called 'Get Review Feedback'.
* When pressing button, API calls are issued and the metrics will show up within the table (a sample of which is displayed below).
* API calls are slow and will take time to process until the 'Loading...' text disappears.
* You can modify the comments and click the 'Get Review Feedback' button again to get new feedback, that too can be achieved without the need of saving the review, but still saving the review first is a better option to approach this.
* All the review feedback for the comments will be displayed in a colorful table.

=== Sample image of the table ===

[[File:Table_metrics.png]]

==Important Links==

* [https://github.com/expertiza/expertiza/pull/1952 Github Pull Request]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2021_-_E2112._Integrate_Suggestion_Detection_Algorithm Expertiza wiki page link] (the link is mentioned here for records. It redirects to this same page.)
* [https://docs.google.com/document/d/1uzr5pybVKYr_K1Q8wSd4t-Id9nqTt3k1ePseDjY-RJg/edit#heading=h.fxfungdw1d5r Google Doc Project Description]
* [https://github.com/harshkachhadia/expertiza/tree/beta Github Repository Link for this expertiza fork] (make sure you change branch to 'beta' branch if the page doesn't load by default to beta branch)

CSC/ECE 517 Spring 2021 - E2112. Integrate Suggestion Detection Algorithm

2021-04-30T17:06:02Z

Hmkachha: /* Implementation Overview */

==Introduction==
=== Team ===
Dr. Gehringer (mentor),
John Bumgardner (mentor)
* Harsh Kachhadia (hmkachha)
* Parimal Mehta (pmehta3)
* Jatin Chinchkar (jchinch)
* Jordan Farthing (mjfarthi)

==Project Background==

Peer-review systems like Expertiza utilize a lot of students’ input to determine each other’s performance. At the same time, we hope students learn from the reviews they receive to improve their own performance. In order to make this happen, we would like to have everyone give quality reviews instead of generic ones. Currently we have a few classifiers that can detect useful features of review comments, such as whether they contain suggestions. The suggestion-detection algorithm has been coded as a web service, and other detection algorithms, such as problem detection and sentiment analysis, also exist as newer web services..but they need to be integrated properly using API calls in expertiza code.

=== Implementation Overview ===

Initially, we had planned to work on the work already done by the previous students [https://github.com/expertiza/expertiza/pull/1427 Spring 2019 pull request]. But later on we faced many issues such as: 1) The API call links were outdated 2) The new link that we found were incompatible with the previous work 3) The planned task of adding new API calls as per Carl Colglaizer's Framework turned out to be irrelevant or not required for this project, so we dropped it.

So we decided to start with integrating these API Calls from scratch.

'''Features we added in this project'''
* Setting up a config file 'review_metric.yml' where instructor can select what review metric to display for the current assignments
* Based on the selection made by professor, API calls(sentiment, problem, sugegstion) are made and a colorful table is displayed below the review form for student to review
* The total time taken for making these API calls will be displayed below the table.

'''Files that are modified or added in this project'''
* review_metrics.yml
* response.html.erb
* _response_analysis.html.erb
* response_controller.rb
* load_config.rb

=== Control Flow ===

[[File:Review_metric.png]]

To inspect implementation in detail, check out the 'Javascript Functionality'

=== Javascript Functionality ===

In the partial view file _response_analysis.html.erb file, we added new javascript functions to make, process and display output of API calls.

* ''' review_metric.yml config file'''

In this file, the configuration for this functionality on which metrics to display in the table, can be set by the
instructor. Instructor can change which metric to display or not display in feedback by changing the value for that
particular metric as 'true' or 'false'.

[[File:Configfile.png|800px]]

* ''' response_controller.rb'''

In this file, we added a method 'fetch_review_metric' which fetches the configurations set by instructor in the review_metric.yml file by
the instructor and passes those fetched values to the response.html.erb view using the 'new' or 'edit' method.

[[File:Response_controller.png|800px]]

* ''' response.html.rb'''

Here, we added a line that renders the partial _response_analysis.html.erb after the Save button to show the 'get review feedback' button and
display the metrics table. Also, we fetch the passed configuration data here.

[[File:response_html.png|800px]]

* ''' _response_analysis.html.erb - fetch_response_comments() function'''

This function fetches the comments written by the user in the review form and formats the collected comments as per the expectation of the API
calls.

[[File:Fetchcomments.png|800px]]

* ''' _response_analysis.html.erb - getReviewFeedback() function'''

This function makes calls to respective APIs and get their output based on the configuration received from the review_metrics.yml file.

[[File:Makesapicalls.png|800px]]

* ''' _response_analysis.html.erb - makeARequest() function'''

This is the driver function for making API call request to any url and data that is passed to it.

[[File:Makearequest.png|800px]]

* ''' _response_analysis.html.erb - combine_api_output() function'''

This function combines the output received from different API responses, combines them and formats the combined data to one that is suitable for
table generation.

[[File:Combineapioutput.png|800px]]

* ''' _response_analysis.html.erb - generateTable() function'''

This code generates a colorful table dynamically on the UI so that the reviewer can get a visual feedback on the comments that he/she wrote.

[[File:Generatetable.png|800px]]

=== API Details/Endpoints Appendix I ===

Here are the various endpoints for the deployment of Suggestion Detection Algorithm.

(We can't make the API links unclickable for this design doc, but clicking on them won't lead you anywhere. They are just endpoints and are mentioned here for reference only.)

* http://152.7.99.200:5000/problem for problem metrics only
* https://peerlogic.csc.ncsu.edu/sentiment/analyze_reviews_bulk for sentiment metrics only
* http://152.7.99.200:5000/suggestions for suggestions metrics only

===API Action===

In order to make the API call, the partial view "_response_analysis.html.erb" is rendered in "response.html.erb" view file which will be responsible for sending a JSON input to the web service. The input will contain the review comment written by the user and when the student hits the "Get review feedback button" the comments will be sent to these api calls in the following json format:

Below is a sample input
'''Sample Input:'''

{"reviews" : [
{
"id" : 1,
"text" : "Comment 1."
},
{
"id" : 2,
"text" : "Comment 2."
}
]}

Once the request is sent, we expect the output to be in the following format:

'''Sample Output: (for sentiment analysis API call)'''
{"sentiments": [
{
"id": 1,
"neg": "0.00",
"neu": "0.95",
"pos": "0.05",
"sentiment": "0.11",
"text": "Comment 1."
},
{
"id": 2,
"neg": "0.00",
"neu": "0.95",
"pos": "0.05",
"sentiment": "0.11",
"text": "Comment 2."
}
]}

'''Sample Output: (for problem detection API call)'''
{"reviews": [
{
"id": 1,
"problems": "Present",
"text": "Comment 1."
},
{
"id": 2,
"problems": "Present",
"text": "Comment 2."
}
]}

'''Sample Output: (for suggestion detection API call)'''
{"reviews": [
{
"id": 1,
"suggestions": "Present",
"text": "Comment 1."
},
{
"id": 2,
"suggestions": "Present",
"text": "Comment 2."
}
]}

These outputs (which is a JSON) will be parsed and the concerned metrics such as the sentiment, problem and suggestion will be extracted so the user will be able to view a summarized result of how well their review comments are. In addition, the result will be presented in a colorful tabular format to the user after they hit the "Get Review Feedback" button. Also, the total time taken for making these API calls will be displayed below the table.

==Testing plan==
We aim to perform automatic and manual testing for this project in order to achieve better reliability for this implementation.

As for this project, very few lines of code have been written in ruby (fetch_review_metric method in response_controller.rb) we will be testing that method in response controller using rspec tests.

'''Rspec tests for the same have been written in response_controller_spec.rb'''

===View Tests===
* The functionality was written on the client side in javascript solely in _response_analysis.html.erb
* To test this view, any type of review must be accessible as a student.
* There is a button at the bottom of the review called 'Get Review Feedback'.
* When pressing button, API calls are issued and the metrics will show up within the table (a sample of which is displayed below).
* API calls are slow and will take time to process until the 'Loading...' text disappears.
* You can modify the comments and click the 'Get Review Feedback' button again to get new feedback, that too can be achieved without the need of saving the review, but still saving the review first is a better option to approach this.
* All the review feedback for the comments will be displayed in a colorful table.

=== Sample image of the table ===

[[File:Table_metrics.png]]

==Important Links==

* [https://github.com/expertiza/expertiza/pull/1952 Github Pull Request]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2021_-_E2112._Integrate_Suggestion_Detection_Algorithm Expertiza wiki page link] (the link is mentioned here for records. It redirects to this same page.)
* [https://docs.google.com/document/d/1uzr5pybVKYr_K1Q8wSd4t-Id9nqTt3k1ePseDjY-RJg/edit#heading=h.fxfungdw1d5r Google Doc Project Description]
* [https://github.com/harshkachhadia/expertiza/tree/beta Github Repository Link for this expertiza fork] (make sure you change branch to 'beta' branch if the page doesn't load by default to beta branch)

CSC/ECE 517 Spring 2021 - E2112. Integrate Suggestion Detection Algorithm

2021-04-30T17:05:25Z

Hmkachha: /* API Action */

==Introduction==
=== Team ===
Dr. Gehringer (mentor),
John Bumgardner (mentor)
* Harsh Kachhadia (hmkachha)
* Parimal Mehta (pmehta3)
* Jatin Chinchkar (jchinch)
* Jordan Farthing (mjfarthi)

==Project Background==

Peer-review systems like Expertiza utilize a lot of students’ input to determine each other’s performance. At the same time, we hope students learn from the reviews they receive to improve their own performance. In order to make this happen, we would like to have everyone give quality reviews instead of generic ones. Currently we have a few classifiers that can detect useful features of review comments, such as whether they contain suggestions. The suggestion-detection algorithm has been coded as a web service, and other detection algorithms, such as problem detection and sentiment analysis, also exist as newer web services..but they need to be integrated properly using API calls in expertiza code.

=== Implementation Overview ===

Initially, we had planned to work on the work already done by the previous students [https://github.com/expertiza/expertiza/pull/1427 Spring 2019 pull request]. But later on we faced many issues such as: 1) The API call links were outdated 2) The new link that we found were incompatible with the previous work 3) The planned task of adding new API calls as per Carl Colglaizer's Framework turned out to be irrelevant or not required for this project, so we dropped it.

So we decided to start with integrating these API Calls from scratch.

'''Features we added in this project'''
* Setting up a config file 'review_metric.yml' where instructor can select what review metric to display for the current assignments
* Based on the selection made by professor, API calls(sentiment, problem, sugegstion) are made and a colorful table is displayed below the review form for student to review
* The total time taken for making these API calls will be displayed below the table.

'''Files that are modified or added in this project'''
* review_metrics.yml
* response.html.erb
* _rseponse_analysis.html.erb
* response_controller.rb
* load_config.rb

=== Control Flow ===

[[File:Review_metric.png]]

To inspect implementation in detail, check out the 'Javascript Functionality'

=== Javascript Functionality ===

In the partial view file _response_analysis.html.erb file, we added new javascript functions to make, process and display output of API calls.

* ''' review_metric.yml config file'''

In this file, the configuration for this functionality on which metrics to display in the table, can be set by the
instructor. Instructor can change which metric to display or not display in feedback by changing the value for that
particular metric as 'true' or 'false'.

[[File:Configfile.png|800px]]

* ''' response_controller.rb'''

In this file, we added a method 'fetch_review_metric' which fetches the configurations set by instructor in the review_metric.yml file by
the instructor and passes those fetched values to the response.html.erb view using the 'new' or 'edit' method.

[[File:Response_controller.png|800px]]

* ''' response.html.rb'''

Here, we added a line that renders the partial _response_analysis.html.erb after the Save button to show the 'get review feedback' button and
display the metrics table. Also, we fetch the passed configuration data here.

[[File:response_html.png|800px]]

* ''' _response_analysis.html.erb - fetch_response_comments() function'''

This function fetches the comments written by the user in the review form and formats the collected comments as per the expectation of the API
calls.

[[File:Fetchcomments.png|800px]]

* ''' _response_analysis.html.erb - getReviewFeedback() function'''

This function makes calls to respective APIs and get their output based on the configuration received from the review_metrics.yml file.

[[File:Makesapicalls.png|800px]]

* ''' _response_analysis.html.erb - makeARequest() function'''

This is the driver function for making API call request to any url and data that is passed to it.

[[File:Makearequest.png|800px]]

* ''' _response_analysis.html.erb - combine_api_output() function'''

This function combines the output received from different API responses, combines them and formats the combined data to one that is suitable for
table generation.

[[File:Combineapioutput.png|800px]]

* ''' _response_analysis.html.erb - generateTable() function'''

This code generates a colorful table dynamically on the UI so that the reviewer can get a visual feedback on the comments that he/she wrote.

[[File:Generatetable.png|800px]]

=== API Details/Endpoints Appendix I ===

Here are the various endpoints for the deployment of Suggestion Detection Algorithm.

(We can't make the API links unclickable for this design doc, but clicking on them won't lead you anywhere. They are just endpoints and are mentioned here for reference only.)

* http://152.7.99.200:5000/problem for problem metrics only
* https://peerlogic.csc.ncsu.edu/sentiment/analyze_reviews_bulk for sentiment metrics only
* http://152.7.99.200:5000/suggestions for suggestions metrics only

===API Action===

In order to make the API call, the partial view "_response_analysis.html.erb" is rendered in "response.html.erb" view file which will be responsible for sending a JSON input to the web service. The input will contain the review comment written by the user and when the student hits the "Get review feedback button" the comments will be sent to these api calls in the following json format:

Below is a sample input
'''Sample Input:'''

{"reviews" : [
{
"id" : 1,
"text" : "Comment 1."
},
{
"id" : 2,
"text" : "Comment 2."
}
]}

Once the request is sent, we expect the output to be in the following format:

'''Sample Output: (for sentiment analysis API call)'''
{"sentiments": [
{
"id": 1,
"neg": "0.00",
"neu": "0.95",
"pos": "0.05",
"sentiment": "0.11",
"text": "Comment 1."
},
{
"id": 2,
"neg": "0.00",
"neu": "0.95",
"pos": "0.05",
"sentiment": "0.11",
"text": "Comment 2."
}
]}

'''Sample Output: (for problem detection API call)'''
{"reviews": [
{
"id": 1,
"problems": "Present",
"text": "Comment 1."
},
{
"id": 2,
"problems": "Present",
"text": "Comment 2."
}
]}

'''Sample Output: (for suggestion detection API call)'''
{"reviews": [
{
"id": 1,
"suggestions": "Present",
"text": "Comment 1."
},
{
"id": 2,
"suggestions": "Present",
"text": "Comment 2."
}
]}

These outputs (which is a JSON) will be parsed and the concerned metrics such as the sentiment, problem and suggestion will be extracted so the user will be able to view a summarized result of how well their review comments are. In addition, the result will be presented in a colorful tabular format to the user after they hit the "Get Review Feedback" button. Also, the total time taken for making these API calls will be displayed below the table.

==Testing plan==
We aim to perform automatic and manual testing for this project in order to achieve better reliability for this implementation.

As for this project, very few lines of code have been written in ruby (fetch_review_metric method in response_controller.rb) we will be testing that method in response controller using rspec tests.

'''Rspec tests for the same have been written in response_controller_spec.rb'''

===View Tests===
* The functionality was written on the client side in javascript solely in _response_analysis.html.erb
* To test this view, any type of review must be accessible as a student.
* There is a button at the bottom of the review called 'Get Review Feedback'.
* When pressing button, API calls are issued and the metrics will show up within the table (a sample of which is displayed below).
* API calls are slow and will take time to process until the 'Loading...' text disappears.
* You can modify the comments and click the 'Get Review Feedback' button again to get new feedback, that too can be achieved without the need of saving the review, but still saving the review first is a better option to approach this.
* All the review feedback for the comments will be displayed in a colorful table.

=== Sample image of the table ===

[[File:Table_metrics.png]]

==Important Links==

* [https://github.com/expertiza/expertiza/pull/1952 Github Pull Request]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2021_-_E2112._Integrate_Suggestion_Detection_Algorithm Expertiza wiki page link] (the link is mentioned here for records. It redirects to this same page.)
* [https://docs.google.com/document/d/1uzr5pybVKYr_K1Q8wSd4t-Id9nqTt3k1ePseDjY-RJg/edit#heading=h.fxfungdw1d5r Google Doc Project Description]
* [https://github.com/harshkachhadia/expertiza/tree/beta Github Repository Link for this expertiza fork] (make sure you change branch to 'beta' branch if the page doesn't load by default to beta branch)

CSC/ECE 517 Spring 2021 - E2112. Integrate Suggestion Detection Algorithm

2021-04-30T17:04:49Z

Hmkachha:

==Introduction==
=== Team ===
Dr. Gehringer (mentor),
John Bumgardner (mentor)
* Harsh Kachhadia (hmkachha)
* Parimal Mehta (pmehta3)
* Jatin Chinchkar (jchinch)
* Jordan Farthing (mjfarthi)

==Project Background==

Peer-review systems like Expertiza utilize a lot of students’ input to determine each other’s performance. At the same time, we hope students learn from the reviews they receive to improve their own performance. In order to make this happen, we would like to have everyone give quality reviews instead of generic ones. Currently we have a few classifiers that can detect useful features of review comments, such as whether they contain suggestions. The suggestion-detection algorithm has been coded as a web service, and other detection algorithms, such as problem detection and sentiment analysis, also exist as newer web services..but they need to be integrated properly using API calls in expertiza code.

=== Implementation Overview ===

Initially, we had planned to work on the work already done by the previous students [https://github.com/expertiza/expertiza/pull/1427 Spring 2019 pull request]. But later on we faced many issues such as: 1) The API call links were outdated 2) The new link that we found were incompatible with the previous work 3) The planned task of adding new API calls as per Carl Colglaizer's Framework turned out to be irrelevant or not required for this project, so we dropped it.

So we decided to start with integrating these API Calls from scratch.

'''Features we added in this project'''
* Setting up a config file 'review_metric.yml' where instructor can select what review metric to display for the current assignments
* Based on the selection made by professor, API calls(sentiment, problem, sugegstion) are made and a colorful table is displayed below the review form for student to review
* The total time taken for making these API calls will be displayed below the table.

'''Files that are modified or added in this project'''
* review_metrics.yml
* response.html.erb
* _rseponse_analysis.html.erb
* response_controller.rb
* load_config.rb

=== Control Flow ===

[[File:Review_metric.png]]

To inspect implementation in detail, check out the 'Javascript Functionality'

=== Javascript Functionality ===

In the partial view file _response_analysis.html.erb file, we added new javascript functions to make, process and display output of API calls.

* ''' review_metric.yml config file'''

In this file, the configuration for this functionality on which metrics to display in the table, can be set by the
instructor. Instructor can change which metric to display or not display in feedback by changing the value for that
particular metric as 'true' or 'false'.

[[File:Configfile.png|800px]]

* ''' response_controller.rb'''

In this file, we added a method 'fetch_review_metric' which fetches the configurations set by instructor in the review_metric.yml file by
the instructor and passes those fetched values to the response.html.erb view using the 'new' or 'edit' method.

[[File:Response_controller.png|800px]]

* ''' response.html.rb'''

Here, we added a line that renders the partial _response_analysis.html.erb after the Save button to show the 'get review feedback' button and
display the metrics table. Also, we fetch the passed configuration data here.

[[File:response_html.png|800px]]

* ''' _response_analysis.html.erb - fetch_response_comments() function'''

This function fetches the comments written by the user in the review form and formats the collected comments as per the expectation of the API
calls.

[[File:Fetchcomments.png|800px]]

* ''' _response_analysis.html.erb - getReviewFeedback() function'''

This function makes calls to respective APIs and get their output based on the configuration received from the review_metrics.yml file.

[[File:Makesapicalls.png|800px]]

* ''' _response_analysis.html.erb - makeARequest() function'''

This is the driver function for making API call request to any url and data that is passed to it.

[[File:Makearequest.png|800px]]

* ''' _response_analysis.html.erb - combine_api_output() function'''

This function combines the output received from different API responses, combines them and formats the combined data to one that is suitable for
table generation.

[[File:Combineapioutput.png|800px]]

* ''' _response_analysis.html.erb - generateTable() function'''

This code generates a colorful table dynamically on the UI so that the reviewer can get a visual feedback on the comments that he/she wrote.

[[File:Generatetable.png|800px]]

=== API Details/Endpoints Appendix I ===

Here are the various endpoints for the deployment of Suggestion Detection Algorithm.

(We can't make the API links unclickable for this design doc, but clicking on them won't lead you anywhere. They are just endpoints and are mentioned here for reference only.)

* http://152.7.99.200:5000/problem for problem metrics only
* https://peerlogic.csc.ncsu.edu/sentiment/analyze_reviews_bulk for sentiment metrics only
* http://152.7.99.200:5000/suggestions for suggestions metrics only

===API Action===

In order to make the API call, the partial view "_response_analysis.html.erb" is rendered in "response.html.erb" view file which will be responsible for sending a JSON input to the web service. The input will contain the review comment written by the user and when the student hits the "Get review feedback button" the comments will be sent to these api calls in the following json format:

Below is a sample input
'''Sample Input:'''

{"reviews" : [
{
"id" : 1,
"text" : "this is a sample test. I am writing a long test just to make sure api if working as expected. Earlier had some issue processing the test due to size of the test used in the request api."
},
{
"id" : 2,
"text" : "this is a sample test. I am writing a long test just to make sure api if working as expected. Earlier had some issue processing the test due to size of the test used in the request api."
}
]}

Once the request is sent, we expect the output to be in the following format:

'''Sample Output: (for sentiment analysis API call)'''
{"sentiments": [
{
"id": 1,
"neg": "0.00",
"neu": "0.95",
"pos": "0.05",
"sentiment": "0.11",
"text": "Comment 1."
},
{
"id": 2,
"neg": "0.00",
"neu": "0.95",
"pos": "0.05",
"sentiment": "0.11",
"text": "Comment 2."
}
]}

'''Sample Output: (for problem detection API call)'''
{"reviews": [
{
"id": 1,
"problems": "Present",
"text": "Comment 1."
},
{
"id": 2,
"problems": "Present",
"text": "Comment 2."
}
]}

'''Sample Output: (for suggestion detection API call)'''
{"reviews": [
{
"id": 1,
"suggestions": "Present",
"text": "Comment 1."
},
{
"id": 2,
"suggestions": "Present",
"text": "Comment 2."
}
]}

These outputs (which is a JSON) will be parsed and the concerned metrics such as the sentiment, problem and suggestion will be extracted so the user will be able to view a summarized result of how well their review comments are. In addition, the result will be presented in a colorful tabular format to the user after they hit the "Get Review Feedback" button. Also, the total time taken for making these API calls will be displayed below the table.

==Testing plan==
We aim to perform automatic and manual testing for this project in order to achieve better reliability for this implementation.

As for this project, very few lines of code have been written in ruby (fetch_review_metric method in response_controller.rb) we will be testing that method in response controller using rspec tests.

'''Rspec tests for the same have been written in response_controller_spec.rb'''

===View Tests===
* The functionality was written on the client side in javascript solely in _response_analysis.html.erb
* To test this view, any type of review must be accessible as a student.
* There is a button at the bottom of the review called 'Get Review Feedback'.
* When pressing button, API calls are issued and the metrics will show up within the table (a sample of which is displayed below).
* API calls are slow and will take time to process until the 'Loading...' text disappears.
* You can modify the comments and click the 'Get Review Feedback' button again to get new feedback, that too can be achieved without the need of saving the review, but still saving the review first is a better option to approach this.
* All the review feedback for the comments will be displayed in a colorful table.

=== Sample image of the table ===

[[File:Table_metrics.png]]

==Important Links==

* [https://github.com/expertiza/expertiza/pull/1952 Github Pull Request]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2021_-_E2112._Integrate_Suggestion_Detection_Algorithm Expertiza wiki page link] (the link is mentioned here for records. It redirects to this same page.)
* [https://docs.google.com/document/d/1uzr5pybVKYr_K1Q8wSd4t-Id9nqTt3k1ePseDjY-RJg/edit#heading=h.fxfungdw1d5r Google Doc Project Description]
* [https://github.com/harshkachhadia/expertiza/tree/beta Github Repository Link for this expertiza fork] (make sure you change branch to 'beta' branch if the page doesn't load by default to beta branch)

CSC/ECE 517 Spring 2021 - E2112. Integrate Suggestion Detection Algorithm

2021-04-30T17:02:32Z

Hmkachha:

==Introduction==
=== Team ===
Dr. Gehringer (mentor),
John Bumgardner (mentor)
* Harsh Kachhadia (hmkachha)
* Parimal Mehta (pmehta3)
* Jatin Chinchkar (jchinch)
* Jordan Farthing (mjfarthi)

==Project Background==

Peer-review systems like Expertiza utilize a lot of students’ input to determine each other’s performance. At the same time, we hope students learn from the reviews they receive to improve their own performance. In order to make this happen, we would like to have everyone give quality reviews instead of generic ones. Currently we have a few classifiers that can detect useful features of review comments, such as whether they contain suggestions. The suggestion-detection algorithm has been coded as a web service, and other detection algorithms, such as problem detection and sentiment analysis, also exist as newer web services..but they need to be integrated properly using API calls in expertiza code.

=== Implementation Overview ===

Initially, we had planned to work on the work already done by the previous students [https://github.com/expertiza/expertiza/pull/1427 Spring 2019 pull request]. But later on we faced many issues such as: 1) The API call links were outdated 2) The new link that we found were incompatible with the previous work 3) The planned task of adding new API calls as per Carl Colglaizer's Framework turned out to be irrelevant or not required for this project, so we dropped it.

So we decided to start with integrating these API Calls from scratch.

'''Features we added in this project'''
* Setting up a config file 'review_metric.yml' where instructor can select what review metric to display for the current assignments
* Based on the selection made by professor, API calls(sentiment, problem, sugegstion) are made and a colorful table is displayed below the review form for student to review
* The total time taken for making these API calls will be displayed below the table.

'''Files that are modified or added in this project'''
* review_metrics.yml
* response.html.erb
* _rseponse_analysis.html.erb
* response_controller.rb
* load_config.rb

=== Control Flow ===

[[File:Review_metric.png]]

To inspect implementation in detail, check out the 'Javascript Functionality'

=== Javascript Functionality ===

In the partial view file _response_analysis.html.erb file, we added new javascript functions to make, process and display output of API calls.

* ''' review_metric.yml config file'''

In this file, the configuration for this functionality on which metrics to display in the table, can be set by the
instructor. Instructor can change which metric to display or not display in feedback by changing the value for that
particular metric as 'true' or 'false'.

[[File:Configfile.png|800px]]

* ''' response_controller.rb'''

In this file, we added a method 'fetch_review_metric' which fetches the configurations set by instructor in the review_metric.yml file by
the instructor and passes those fetched values to the response.html.erb view using the 'new' or 'edit' method.

[[File:Response_controller.png|800px]]

* ''' response.html.rb'''

Here, we added a line that renders the partial _response_analysis.html.erb after the Save button to show the 'get review feedback' button and
display the metrics table. Also, we fetch the passed configuration data here.

[[File:response_html.png|800px]]

* ''' _response_analysis.html.erb - fetch_response_comments() function'''

This function fetches the comments written by the user in the review form and formats the collected comments as per the expectation of the API
calls.

[[File:Fetchcomments.png|800px]]

* ''' _response_analysis.html.erb - getReviewFeedback() function'''

This function makes calls to respective APIs and get their output based on the configuration received from the review_metrics.yml file.

[[File:Makesapicalls.png|800px]]

* ''' _response_analysis.html.erb - makeARequest() function'''

This is the driver function for making API call request to any url and data that is passed to it.

[[File:Makearequest.png|800px]]

* ''' _response_analysis.html.erb - combine_api_output() function'''

This function combines the output received from different API responses, combines them and formats the combined data to one that is suitable for
table generation.

[[File:Combineapioutput.png|800px]]

* ''' _response_analysis.html.erb - generateTable() function'''

This code generates a colorful table dynamically on the UI so that the reviewer can get a visual feedback on the comments that he/she wrote.

[[File:Generatetable.png|800px]]

=== API Details/Endpoints Appendix I ===

Here are the various endpoints for the deployment of Suggestion Detection Algorithm.

(We can't make the API links unclickable for this design doc, but clicking on them won't lead you anywhere. They are just endpoints and are mentioned here for reference only.)

* http://152.7.99.200:5000/problem for problem metrics only
* https://peerlogic.csc.ncsu.edu/sentiment/analyze_reviews_bulk for sentiment metrics only
* http://152.7.99.200:5000/suggestions for suggestions metrics only

===API Action===

In order to make the API call, the partial view "_response_analysis.html.erb" is rendered in "response.html.erb" view file which will be responsible for sending a JSON input to the web service. The input will contain the review comment written by the user and when the student hits the "Get review feedback button" the comments will be sent to these api calls in the following json format:

Below is a sample input
'''Sample Input:'''

{"reviews" : [
{
"id" : 1,
"text" : "this is a sample test. I am writing a long test just to make sure api if working as expected. Earlier had some issue processing the test due to size of the test used in the request api."
},
{
"id" : 2,
"text" : "this is a sample test. I am writing a long test just to make sure api if working as expected. Earlier had some issue processing the test due to size of the test used in the request api."
}
]}

Once the request is sent, we expect the output to be in the following format:

'''Sample Output: (for sentiment analysis API call)'''
{"sentiments": [
{
"id": 1,
"neg": "0.00",
"neu": "0.95",
"pos": "0.05",
"sentiment": "0.11",
"text": "Comment 1."
},
{
"id": 2,
"neg": "0.00",
"neu": "0.95",
"pos": "0.05",
"sentiment": "0.11",
"text": "Comment 2."
}
]}

'''Sample Output: (for problem detection API call)'''
{"reviews": [
{
"id": 1,
"problems": "Present",
"text": "Comment 1."
},
{
"id": 2,
"problems": "Present",
"text": "Comment 2."
}
]}

'''Sample Output: (for suggestion detection API call)'''
{"reviews": [
{
"id": 1,
"suggestions": "Present",
"text": "Comment 1."
},
{
"id": 2,
"suggestions": "Present",
"text": "Comment 2."
}
]}

These outputs (which is a JSON) will be parsed and the concerned metrics such as the sentiment, problem and suggestion will be extracted so the user will be able to view a summarized result of how well their review comments are. In addition, the result will be presented in a colorful tabular format to the user after they hit the "Get Review Feedback" button. Also, the total time taken for making these API calls will be displayed below the table.

==Testing plan==
We aim to perform automatic and manual testing for this project in order to achieve better reliability for this implementation.

As for this project, very few lines of code have been written in ruby (fetch_review_metric method in response_controller.rb) we will be testing that method in response controller using rspec tests.

'''Rspec tests for the same have been written in response_controller_spec.rb'''

===View Tests===
* The functionality was written on the client side in javascript solely in _response_analysis.html.erb
* To test this view, any type of review must be accessible as a student.
* There is a button at the bottom of the review called 'Get Review Feedback'.
* When pressing button, API calls are issued and the metrics will show up within the table (a sample of which is displayed below).
* API calls are slow and will take time to process until the 'Loading...' text disappears.
* You can modify the comments and click the 'Get Review Feedback' button again to get new feedback, that too can be achieved without the need of saving the review, but still saving the review first is a better option to approach this.
* All the review feedback for the comments will be displayed in a colorful table.

=== Sample image of the table ===

[[File:Table_metrics.png]]

==Important Links==

* [https://github.com/expertiza/expertiza/pull/1952 Github Pull Request]
* [https://docs.google.com/document/d/1uzr5pybVKYr_K1Q8wSd4t-Id9nqTt3k1ePseDjY-RJg/edit#heading=h.fxfungdw1d5r Google Doc Project Description]
* [https://github.com/harshkachhadia/expertiza/tree/beta Github Repository Link for this expertiza fork] (make sure you change branch to 'beta' branch if the page doesn't load by default to beta branch)

CSC/ECE 517 Spring 2021 - E2112. Integrate Suggestion Detection Algorithm

2021-04-30T17:00:59Z

Hmkachha: /* Project Background */

==Introduction==
=== Team ===
Dr. Gehringer (mentor),
John Bumgardner (mentor)
* Harsh Kachhadia (hmkachha)
* Parimal Mehta (pmehta3)
* Jatin Chinchkar (jchinch)
* Jordan Farthing (mjfarthi)

==Project Background==

Peer-review systems like Expertiza utilize a lot of students’ input to determine each other’s performance. At the same time, we hope students learn from the reviews they receive to improve their own performance. In order to make this happen, we would like to have everyone give quality reviews instead of generic ones. Currently we have a few classifiers that can detect useful features of review comments, such as whether they contain suggestions. The suggestion-detection algorithm has been coded as a web service, and other detection algorithms, such as problem detection and sentiment analysis, also exist as newer web services..but they need to be integrated properly using API calls in expertiza code.

=== Implementation Overview ===

Initially, we had planned to work on the work already done by the previous students [https://github.com/expertiza/expertiza/pull/1427 Spring 2019 pull request]. But later on we faced many issues such as: 1) The API call links were outdated 2) The new link that we found were incompatible with the previous work 3) The planned task of adding new API calls as per Carl Colglaizer's Framework turned out to be irrelevant or not required for this project, so we dropped it.

So we decided to start with integrating these API Calls from scratch.

'''Features we added in this project'''
* Setting up a config file 'review_metric.yml' where instructor can select what review metric to display for the current assignments
* Based on the selection made by professor, API calls(sentiment, problem, sugegstion) are made and a colorful table is displayed below the review form for student to review
* The total time taken for making these API calls will be displayed below the table.

'''Files that are modified or added in this project'''
* review_metrics.yml
* response.html.erb
* _rseponse_analysis.html.erb
* response_controller.rb
* load_config.rb

=== Control Flow ===

[[File:Review_metric.png]]

To inspect implementation in detail, check out the 'Javascript Functionality'

=== Javascript Functionality ===

In the partial view file _response_analysis.html.erb file, we added new javascript functions to make, process and display output of API calls.

* ''' review_metric.yml config file'''

In this file, the configuration for this functionality on which metrics to display in the table, can be set by the
instructor. Instructor can change which metric to display or not display in feedback by changing the value for that
particular metric as 'true' or 'false'.

[[File:Configfile.png|800px]]

* ''' response_controller.rb'''

In this file, we added a method 'fetch_review_metric' which fetches the configurations set by instructor in the review_metric.yml file by
the instructor and passes those fetched values to the response.html.erb view using the 'new' or 'edit' method.

[[File:Response_controller.png|800px]]

* ''' response.html.rb'''

Here, we added a line that renders the partial _response_analysis.html.erb after the Save button to show the 'get review feedback' button and
display the metrics table. Also, we fetch the passed configuration data here.

[[File:response_html.png|800px]]

* ''' _response_analysis.html.erb - fetch_response_comments() function'''

This function fetches the comments written by the user in the review form and formats the collected comments as per the expectation of the API
calls.

[[File:Fetchcomments.png|800px]]

* ''' _response_analysis.html.erb - getReviewFeedback() function'''

This function makes calls to respective APIs and get their output based on the configuration received from the review_metrics.yml file.

[[File:Makesapicalls.png|800px]]

* ''' _response_analysis.html.erb - makeARequest() function'''

This is the driver function for making API call request to any url and data that is passed to it.

[[File:Makearequest.png|800px]]

* ''' _response_analysis.html.erb - combine_api_output() function'''

This function combines the output received from different API responses, combines them and formats the combined data to one that is suitable for
table generation.

[[File:Combineapioutput.png|800px]]

* ''' _response_analysis.html.erb - generateTable() function'''

This code generates a colorful table dynamically on the UI so that the reviewer can get a visual feedback on the comments that he/she wrote.

[[File:Generatetable.png|800px]]

=== API Details/Endpoints Appendix I ===

Here are the various endpoints for the deployment of Suggestion Detection Algorithm.

(We can't make the API links unclickable for this design doc, but clicking on them won't lead you anywhere. They are just endpoints and are mentioned here for reference only.)

* http://152.7.99.200:5000/problem for problem metrics only
* https://peerlogic.csc.ncsu.edu/sentiment/analyze_reviews_bulk for sentiment metrics only
* http://152.7.99.200:5000/suggestions for suggestions metrics only

===API Action===

In order to make the API call, the partial view "_response_analysis.html.erb" is rendered in "response.html.erb" view file which will be responsible for sending a JSON input to the web service. The input will contain the review comment written by the user and when the student hits the "Get review feedback button" the comments will be sent to these api calls in the following json format:

Below is a sample input
'''Sample Input:'''

{"reviews" : [
{
"id" : 1,
"text" : "this is a sample test. I am writing a long test just to make sure api if working as expected. Earlier had some issue processing the test due to size of the test used in the request api."
},
{
"id" : 2,
"text" : "this is a sample test. I am writing a long test just to make sure api if working as expected. Earlier had some issue processing the test due to size of the test used in the request api."
}
]}

Once the request is sent, we expect the output to be in the following format:

'''Sample Output: (for sentiment analysis API call)'''
{"sentiments": [
{
"id": 1,
"neg": "0.00",
"neu": "0.95",
"pos": "0.05",
"sentiment": "0.11",
"text": "Comment 1."
},
{
"id": 2,
"neg": "0.00",
"neu": "0.95",
"pos": "0.05",
"sentiment": "0.11",
"text": "Comment 2."
}
]}

'''Sample Output: (for problem detection API call)'''
{"reviews": [
{
"id": 1,
"problems": "Present",
"text": "Comment 1."
},
{
"id": 2,
"problems": "Present",
"text": "Comment 2."
}
]}

'''Sample Output: (for suggestion detection API call)'''
{"reviews": [
{
"id": 1,
"suggestions": "Present",
"text": "Comment 1."
},
{
"id": 2,
"suggestions": "Present",
"text": "Comment 2."
}
]}

These outputs (which is a JSON) will be parsed and the concerned metrics such as the sentiment, problem and suggestion will be extracted so the user will be able to view a summarized result of how well their review comments are. In addition, the result will be presented in a colorful tabular format to the user after they hit the "Get Review Feedback" button. Also, the total time taken for making these API calls will be displayed below the table.

==Testing plan==
We aim to perform automatic and manual testing for this project in order to achieve better reliability for this implementation.

As for this project, very few lines of code have been written in ruby (fetch_review_metric method in response_controller.rb) we will be testing that method in response controller using rspec tests.

'''Rspec tests for the same have been written in response_controller_spec.rb'''

===View Tests===
* The functionality was written on the client side in javascript solely in _response_analysis.html.erb
* To test this view, any type of review must be accessible as a student.
* There is a button at the bottom of the review called 'Get Review Feedback'.
* When pressing button, API calls are issued and the metrics will show up within the table (a sample of which is displayed below).
* API calls are slow and will take time to process until the 'Loading...' text disappears.
* You can modify the comments and click the 'Get Review Feedback' button again to get new feedback, that too can be achieved without the need of saving the review, but still saving the review first is a better option to approach this.
* All the review feedback for the comments will be displayed in a colorful table.

=== Sample image of the table ===

[[File:Table_metrics.png]]

==Important Links==

* [https://github.com/expertiza/expertiza/pull/1952 Github Pull Request]
* [https://docs.google.com/document/d/1uzr5pybVKYr_K1Q8wSd4t-Id9nqTt3k1ePseDjY-RJg/edit#heading=h.fxfungdw1d5r Google Doc Project Description]

CSC/ECE 517 Spring 2021 - E2112. Integrate Suggestion Detection Algorithm

2021-04-30T16:48:10Z

Hmkachha: /* Team */

==Introduction==
=== Team ===
Dr. Gehringer (mentor),
John Bumgardner (mentor)
* Harsh Kachhadia (hmkachha)
* Parimal Mehta (pmehta3)
* Jatin Chinchkar (jchinch)
* Jordan Farthing (mjfarthi)

==Project Background==

Peer-review systems like Expertiza utilize a lot of students’ input to determine each other’s performance. At the same time, we hope students learn from the reviews they receive to improve their own performance. In order to make this happen, we would like to have everyone give quality reviews instead of generic ones. Currently we have a few classifiers that can detect useful features of review comments, such as whether they contain suggestions. The suggestion-detection algorithm has been coded as a web service, and other detection algorithms, such as problem detection and sentiment analysis, also exist as newer web services..but they need to be integrated properly using API calls in expertiza code.

=== Control Flow ===

[[FIle:Review_metric.png]]

=== Implementation Overview ===

Initially, we had planned to work on the work already done by the previous students [https://github.com/expertiza/expertiza/pull/1427 Spring 2019 pull request]. But later on we faced many issues such as: 1) The API call links were outdated 2) The new link that we found were incompatible with the previous work 3) The planned task of adding new API calls as per Carl Colglaizer's Framework turned out to be irrelevant or not required for this project, so we dropped it.

So we decided to start with integrating these API Calls from scratch.

'''Features we added in this project'''
* Setting up a config file 'review_metric.yml' where instructor can select what review metric to display for the current assignments
* Based on the selection made by professor, API calls(sentiment, problem, sugegstion) are made and a colorful table is displayed below the review form for student to review
* The total time taken for making these API calls will be displayed below the table.

'''Files that are modified or added in this project'''
* review_metrics.yml
* response.html.erb
* _rseponse_analysis.html.erb
* response_controller.rb
* load_config.rb

=== Javascript Functionality ===

In the partial view file _response_analysis.html.erb file, we added new javascript functions to make, process and display output of API calls.

* ''' review_metric.yml config file'''

In this file, we can setup the configuration for this functionality on which metrics to display in the table, which can be set by the
instructor.

[[File:Configfile.png|800px]]

* ''' response_controller.rb'''

In this file, we added a method 'fetch_review_metric' which fetches the configurations set by instructor in the review_metric.yml file by
the instructor and passes those fetched values to the response.html.erb view.

[[File:Response_controller.png|800px]]

* ''' response.html.rb'''

Here, we added a line that renders the partial _response_analysis.html.erb after the Save button to show the 'get review feedback' button and
display the metrics table. Also, we fetch the passed configuration data here.

[[File:response_html.png|800px]]

* ''' _response_analysis.html.erb - fetch_response_comments() function'''

This function fetches the comments written by the user in the review form and formats the collected comments as per the expectation of the API
calls.

[[File:Fetchcomments.png|800px]]

* ''' _response_analysis.html.erb - getReviewFeedback() function'''

This function makes calls to respective APIs and get their output based on the configuration received from the review_metrics.yml file.

[[File:Makesapicalls.png|800px]]

* ''' _response_analysis.html.erb - makeARequest() function'''

This is the driver function for making API call request to any url and data that is passed to it.

[[File:Makearequest.png|800px]]

* ''' _response_analysis.html.erb - combine_api_output() function'''

This function combines the output received from different API responses, combines them and formats the combined data to one that is suitable for
table generation.

[[File:Combineapioutput.png|800px]]

* ''' _response_analysis.html.erb - generateTable() function'''

This code generates a colorful table dynamically on the UI so that the reviewer can get a visual feedback on the comments that he/she wrote.

[[File:Generatetable.png|800px]]

=== API Details/Endpoints Appendix I ===

Here are the various endpoints for the deployment of Suggestion Detection Algorithm.

(We can't make the API links unclickable for this design doc, but clicking on them won't lead you anywhere. They are just endpoints and are mentioned here for reference only.)

* http://152.7.99.200:5000/problem for problem metrics only
* https://peerlogic.csc.ncsu.edu/sentiment/analyze_reviews_bulk for sentiment metrics only
* http://152.7.99.200:5000/suggestions for suggestions metrics only

===API Action===

In order to make the API call, the partial view "_response_analysis.html.erb" is rendered in "response.html.erb" view file which will be responsible for sending a JSON input to the web service. The input will contain the review comment written by the user and when the student hits the "Get review feedback button" the comments will be sent to these api calls in the following json format:

Below is a sample input
'''Sample Input:'''

{"reviews" : [
{
"id" : 1,
"text" : "this is a sample test. I am writing a long test just to make sure api if working as expected. Earlier had some issue processing the test due to size of the test used in the request api."
},
{
"id" : 2,
"text" : "this is a sample test. I am writing a long test just to make sure api if working as expected. Earlier had some issue processing the test due to size of the test used in the request api."
}
]}

Once the request is sent, we expect the output to be in the following format:

'''Sample Output: (for sentiment analysis API call)'''
{"sentiments": [
{
"id": 1,
"neg": "0.00",
"neu": "0.95",
"pos": "0.05",
"sentiment": "0.11",
"text": "Comment 1."
},
{
"id": 2,
"neg": "0.00",
"neu": "0.95",
"pos": "0.05",
"sentiment": "0.11",
"text": "Comment 2."
}
]}

'''Sample Output: (for problem detection API call)'''
{"reviews": [
{
"id": 1,
"problems": "Present",
"text": "Comment 1."
},
{
"id": 2,
"problems": "Present",
"text": "Comment 2."
}
]}

'''Sample Output: (for suggestion detection API call)'''
{"reviews": [
{
"id": 1,
"suggestions": "Present",
"text": "Comment 1."
},
{
"id": 2,
"suggestions": "Present",
"text": "Comment 2."
}
]}

These outputs (which is a JSON) will be parsed and the concerned metrics such as the sentiment, problem and suggestion will be extracted so the user will be able to view a summarized result of how well their review comments are. In addition, the result will be presented in a colorful tabular format to the user after they hit the "Get Review Feedback" button. Also, the total time taken for making these API calls will be displayed below the table.

==Testing plan==
We aim to perform automatic and manual testing for this project in order to achieve better reliability for this implementation.

As for this project, very few lines of code have been written in ruby (fetch_review_metric method in response_controller.rb) we will be testing that method in response controller using rspec tests.

'''Rspec tests for the same have been written in response_controller_spec.rb'''

===View Tests===
* The functionality was written on the client side in javascript solely in _response_analysis.html.erb
* To test this view, any type of review must be accessible as a student.
* There is a button at the bottom of the review called 'Get Review Feedback'.
* When pressing button, API calls are issued and the metrics will show up within the table (a sample of which is displayed below).
* API calls are slow and will take time to process until the 'Loading...' text disappears.
* You can modify the comments and click the 'Get Review Feedback' button again to get new feedback, that too can be achieved without the need of saving the review, but still saving the review first is a better option to approach this.
* All the review feedback for the comments will be displayed in a colorful table.

=== Sample image of the table ===

[[File:Table_metrics.png]]

==Important Links==

* [https://github.com/expertiza/expertiza/pull/1952 Github Pull Request]
* [https://docs.google.com/document/d/1uzr5pybVKYr_K1Q8wSd4t-Id9nqTt3k1ePseDjY-RJg/edit#heading=h.fxfungdw1d5r Google Doc Project Description]

CSC/ECE 517 Spring 2021 - E2112. Integrate Suggestion Detection Algorithm

2021-04-30T16:47:44Z

Hmkachha:

==Introduction==
=== Team ===
Dr. Gehringer (mentor)
John Bumgardner (mentor)
* Harsh Kachhadia (hmkachha)
* Parimal Mehta (pmehta3)
* Jatin Chinchkar (jchinch)
* Jordan Farthing (mjfarthi)

==Project Background==

Peer-review systems like Expertiza utilize a lot of students’ input to determine each other’s performance. At the same time, we hope students learn from the reviews they receive to improve their own performance. In order to make this happen, we would like to have everyone give quality reviews instead of generic ones. Currently we have a few classifiers that can detect useful features of review comments, such as whether they contain suggestions. The suggestion-detection algorithm has been coded as a web service, and other detection algorithms, such as problem detection and sentiment analysis, also exist as newer web services..but they need to be integrated properly using API calls in expertiza code.

=== Control Flow ===

[[FIle:Review_metric.png]]

=== Implementation Overview ===

Initially, we had planned to work on the work already done by the previous students [https://github.com/expertiza/expertiza/pull/1427 Spring 2019 pull request]. But later on we faced many issues such as: 1) The API call links were outdated 2) The new link that we found were incompatible with the previous work 3) The planned task of adding new API calls as per Carl Colglaizer's Framework turned out to be irrelevant or not required for this project, so we dropped it.

So we decided to start with integrating these API Calls from scratch.

'''Features we added in this project'''
* Setting up a config file 'review_metric.yml' where instructor can select what review metric to display for the current assignments
* Based on the selection made by professor, API calls(sentiment, problem, sugegstion) are made and a colorful table is displayed below the review form for student to review
* The total time taken for making these API calls will be displayed below the table.

'''Files that are modified or added in this project'''
* review_metrics.yml
* response.html.erb
* _rseponse_analysis.html.erb
* response_controller.rb
* load_config.rb

=== Javascript Functionality ===

In the partial view file _response_analysis.html.erb file, we added new javascript functions to make, process and display output of API calls.

* ''' review_metric.yml config file'''

In this file, we can setup the configuration for this functionality on which metrics to display in the table, which can be set by the
instructor.

[[File:Configfile.png|800px]]

* ''' response_controller.rb'''

In this file, we added a method 'fetch_review_metric' which fetches the configurations set by instructor in the review_metric.yml file by
the instructor and passes those fetched values to the response.html.erb view.

[[File:Response_controller.png|800px]]

* ''' response.html.rb'''

Here, we added a line that renders the partial _response_analysis.html.erb after the Save button to show the 'get review feedback' button and
display the metrics table. Also, we fetch the passed configuration data here.

[[File:response_html.png|800px]]

* ''' _response_analysis.html.erb - fetch_response_comments() function'''

This function fetches the comments written by the user in the review form and formats the collected comments as per the expectation of the API
calls.

[[File:Fetchcomments.png|800px]]

* ''' _response_analysis.html.erb - getReviewFeedback() function'''

This function makes calls to respective APIs and get their output based on the configuration received from the review_metrics.yml file.

[[File:Makesapicalls.png|800px]]

* ''' _response_analysis.html.erb - makeARequest() function'''

This is the driver function for making API call request to any url and data that is passed to it.

[[File:Makearequest.png|800px]]

* ''' _response_analysis.html.erb - combine_api_output() function'''

This function combines the output received from different API responses, combines them and formats the combined data to one that is suitable for
table generation.

[[File:Combineapioutput.png|800px]]

* ''' _response_analysis.html.erb - generateTable() function'''

This code generates a colorful table dynamically on the UI so that the reviewer can get a visual feedback on the comments that he/she wrote.

[[File:Generatetable.png|800px]]

=== API Details/Endpoints Appendix I ===

Here are the various endpoints for the deployment of Suggestion Detection Algorithm.

(We can't make the API links unclickable for this design doc, but clicking on them won't lead you anywhere. They are just endpoints and are mentioned here for reference only.)

* http://152.7.99.200:5000/problem for problem metrics only
* https://peerlogic.csc.ncsu.edu/sentiment/analyze_reviews_bulk for sentiment metrics only
* http://152.7.99.200:5000/suggestions for suggestions metrics only

===API Action===

In order to make the API call, the partial view "_response_analysis.html.erb" is rendered in "response.html.erb" view file which will be responsible for sending a JSON input to the web service. The input will contain the review comment written by the user and when the student hits the "Get review feedback button" the comments will be sent to these api calls in the following json format:

Below is a sample input
'''Sample Input:'''

{"reviews" : [
{
"id" : 1,
"text" : "this is a sample test. I am writing a long test just to make sure api if working as expected. Earlier had some issue processing the test due to size of the test used in the request api."
},
{
"id" : 2,
"text" : "this is a sample test. I am writing a long test just to make sure api if working as expected. Earlier had some issue processing the test due to size of the test used in the request api."
}
]}

Once the request is sent, we expect the output to be in the following format:

'''Sample Output: (for sentiment analysis API call)'''
{"sentiments": [
{
"id": 1,
"neg": "0.00",
"neu": "0.95",
"pos": "0.05",
"sentiment": "0.11",
"text": "Comment 1."
},
{
"id": 2,
"neg": "0.00",
"neu": "0.95",
"pos": "0.05",
"sentiment": "0.11",
"text": "Comment 2."
}
]}

'''Sample Output: (for problem detection API call)'''
{"reviews": [
{
"id": 1,
"problems": "Present",
"text": "Comment 1."
},
{
"id": 2,
"problems": "Present",
"text": "Comment 2."
}
]}

'''Sample Output: (for suggestion detection API call)'''
{"reviews": [
{
"id": 1,
"suggestions": "Present",
"text": "Comment 1."
},
{
"id": 2,
"suggestions": "Present",
"text": "Comment 2."
}
]}

These outputs (which is a JSON) will be parsed and the concerned metrics such as the sentiment, problem and suggestion will be extracted so the user will be able to view a summarized result of how well their review comments are. In addition, the result will be presented in a colorful tabular format to the user after they hit the "Get Review Feedback" button. Also, the total time taken for making these API calls will be displayed below the table.

==Testing plan==
We aim to perform automatic and manual testing for this project in order to achieve better reliability for this implementation.

As for this project, very few lines of code have been written in ruby (fetch_review_metric method in response_controller.rb) we will be testing that method in response controller using rspec tests.

'''Rspec tests for the same have been written in response_controller_spec.rb'''

===View Tests===
* The functionality was written on the client side in javascript solely in _response_analysis.html.erb
* To test this view, any type of review must be accessible as a student.
* There is a button at the bottom of the review called 'Get Review Feedback'.
* When pressing button, API calls are issued and the metrics will show up within the table (a sample of which is displayed below).
* API calls are slow and will take time to process until the 'Loading...' text disappears.
* You can modify the comments and click the 'Get Review Feedback' button again to get new feedback, that too can be achieved without the need of saving the review, but still saving the review first is a better option to approach this.
* All the review feedback for the comments will be displayed in a colorful table.

=== Sample image of the table ===

[[File:Table_metrics.png]]

==Important Links==

* [https://github.com/expertiza/expertiza/pull/1952 Github Pull Request]
* [https://docs.google.com/document/d/1uzr5pybVKYr_K1Q8wSd4t-Id9nqTt3k1ePseDjY-RJg/edit#heading=h.fxfungdw1d5r Google Doc Project Description]